While Linux uses a different driver, the Ilitek
ILI210x/ILI2117/ILI2120/ILI251x touchscreen controller Device Tree
binding documentation is very similar.
- Drop the fixed reg value, as some controllers use a different
address,
- Make reset-gpios optional, as it is not always wired.
dt-bindings: timer: samsung,exynos4210-mct: define strict clock order
The DTS should always have fixed clock order, even if it comes with
clock-names property. Drop the pattern to make the order strict.
Existing DTS already match this.
Starting from LLVM 14, having an unpacked struct nested in a packed
struct triggers a warning. c.f. [1].
This is a false positive because the field is always being accessed
with the relevant put_unaligned_*() function. Adding __packed to the
structure declaration silences the warning.
Oliver Hartkopp [Wed, 18 May 2022 15:45:27 +0000 (17:45 +0200)]
can: can-dev: remove obsolete CAN LED support
Since commit 30f3b42147ba6f ("can: mark led trigger as broken") the
CAN specific LED support was disabled and marked as BROKEN. As the
common LED support with CONFIG_LEDS_TRIGGER_NETDEV should do this work
now the code can be removed as preparation for a CAN netdevice Kconfig
rework.
Jakub Kicinski [Tue, 17 May 2022 00:23:45 +0000 (17:23 -0700)]
can: can-dev: move to netif_napi_add_weight()
We want to remove the weight argument from the basic version of the
netif_napi_add() call. Move all the callers in drivers/net/can that
pass a custom weight (i.e. not NAPI_POLL_WEIGHT or 64) to the
netif_napi_add_weight() API.
Oliver Hartkopp [Tue, 17 May 2022 14:56:53 +0000 (16:56 +0200)]
can: isotp: isotp_bind(): do not validate unused address information
With commit 2aa39889c463 ("can: isotp: isotp_bind(): return -EINVAL on
incorrect CAN ID formatting") the bind() syscall returns -EINVAL when
the given CAN ID needed to be sanitized. But in the case of an unconfirmed
broadcast mode the rx CAN ID is not needed and may be uninitialized from
the caller - which is ok.
This patch makes sure the result of an inproper CAN ID format is only
provided when the address information is needed.
Jakub Kicinski [Thu, 19 May 2022 20:01:07 +0000 (13:01 -0700)]
Merge tag 'wireless-next-2022-05-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v5.19
Second set of patches for v5.19 and most likely the last one. rtw89
got support for 8852ce devices and mt76 now supports Wireless Ethernet
Dispatch.
Major changes:
cfg80211/mac80211
- support disabling EHT mode
rtw89
- add support for Realtek 8852ce devices
mt76
- Wireless Ethernet Dispatch support for flow offload
- non-standard VHT MCS10-11 support
- mt7921 AP mode support
- mt7921 ipv6 NS offload support
ath11k
- enable keepalive during WoWLAN suspend
- implement remain-on-channel support
* tag 'wireless-next-2022-05-19' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (135 commits)
iwlwifi: mei: fix potential NULL-ptr deref
iwlwifi: mei: clear the sap data header before sending
iwlwifi: mvm: remove vif_count
iwlwifi: mvm: always tell the firmware to accept MCAST frames in BSS
iwlwifi: mvm: add OTP info in case of init failure
iwlwifi: mvm: fix assert 1F04 upon reconfig
iwlwifi: fw: init SAR GEO table only if data is present
iwlwifi: mvm: clean up authorized condition
iwlwifi: mvm: use NULL instead of ERR_PTR when parsing wowlan status
iwlwifi: pcie: simplify MSI-X cause mapping
rtw89: pci: only mask out INT indicator register for disable interrupt v1
rtw89: convert rtw89_band to nl80211_band precisely
rtw89: 8852c: update txpwr tables to HALRF_027_00_052
rtw89: cfo: check mac_id to avoid out-of-bounds
rtw89: 8852c: set TX antenna path
rtw89: add ieee80211::sta_rc_update ops
wireless: Fix Makefile to be in alphabetical order
mac80211: refactor freeing the next_beacon
cfg80211: fix kernel-doc for cfg80211_beacon_data
mac80211: minstrel_ht: support ieee80211_rate_status
...
====================
In current implementation we set the non-mdts limits by calling
nvme_init_non_mdts_limits() from nvme_init_ctrl_finish().
This also tries to set the limits for the discovery controller which
has no I/O queues resulting in the warning message reported by the
nvme_log_error() when running blktest nvme/002: -
[ 2005.155946] run blktests nvme/002 at 2022-04-09 16:57:47
[ 2005.192223] loop: module loaded
[ 2005.196429] nvmet: adding nsid 1 to subsystem blktests-subsystem-0
[ 2005.200334] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
[ 2008.958108] nvmet: adding nsid 1 to subsystem blktests-subsystem-997
[ 2008.962082] nvmet: adding nsid 1 to subsystem blktests-subsystem-998
[ 2008.966102] nvmet: adding nsid 1 to subsystem blktests-subsystem-999
[ 2008.973132] nvmet: creating discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN testhostnqn.
*[ 2008.973196] nvme1: Identify(0x6), Invalid Field in Command (sct 0x0 / sc 0x2) MORE DNR*
[ 2008.974595] nvme nvme1: new ctrl: "nqn.2014-08.org.nvmexpress.discovery"
[ 2009.103248] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery"
Move the call of nvme_init_non_mdts_limits() to nvme_scan_work() after
we verify that I/O queues are created since that is a converging point
for each transport where these limits are actually used.
1. FC :
nvme_fc_create_association()
...
nvme_fc_create_io_queues(ctrl);
...
nvme_start_ctrl()
nvme_scan_queue()
nvme_scan_work()
Hans de Goede [Thu, 19 May 2022 15:21:48 +0000 (17:21 +0200)]
x86/PCI: Add kernel cmdline options to use/ignore E820 reserved regions
Some firmware supplies PCI host bridge _CRS that includes address space
unusable by PCI devices, e.g., space occupied by host bridge registers or
used by hidden PCI devices.
To avoid this unusable space, Linux currently excludes E820 reserved
regions from _CRS windows; see 4dc2287c1805 ("x86: avoid E820 regions when
allocating address space").
However, this use of E820 reserved regions to clip things out of _CRS is
not supported by ACPI, UEFI, or PCI Firmware specs, and some systems have
E820 reserved regions that cover the entire memory window from _CRS. 4dc2287c1805 clips the entire window, leaving no space for hot-added or
uninitialized PCI devices.
For example, from a Lenovo IdeaPad 3 15IIL 81WE:
BIOS-e820: [mem 0x4bc50000-0xcfffffff] reserved
pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window]
pci 0000:00:15.0: BAR 0: [mem 0x00000000-0x00000fff 64bit]
pci 0000:00:15.0: BAR 0: no space for [mem size 0x00001000 64bit]
Future patches will add quirks to enable/disable E820 clipping
automatically.
Add a "pci=no_e820" kernel command line option to disable clipping with
E820 reserved regions. Also add a matching "pci=use_e820" option to enable
clipping with E820 reserved regions if that has been disabled by default by
further patches in this patch-set.
Both options taint the kernel because they are intended for debugging and
workaround purposes until a quirk can set them automatically.
Li Zhengyu [Fri, 8 Apr 2022 10:09:13 +0000 (18:09 +0800)]
RISC-V: Add purgatory
This patch adds purgatory, the name and concept have been taken
from kexec-tools. Purgatory runs between two kernels, and do
verify sha256 hash to ensure the kernel to jump to is fine and
has not been corrupted after loading. Makefile is modified based
on x86 platform.
Li Zhengyu [Fri, 8 Apr 2022 10:09:12 +0000 (18:09 +0800)]
RISC-V: Support for kexec_file on panic
This patch adds support for loading a kexec on panic (kdump) kernel.
It has been tested with vmcore-dmesg on riscv64 QEMU on both an smp
and a non-smp system.
This patch adds support for kexec_file on RISC-V. I tested it on riscv64
QEMU with busybear-linux and single core along with the OpenSBI firmware
fw_jump.bin for generic platform.
On SMP system, it depends on CONFIG_{HOTPLUG_CPU, RISCV_SBI} to
resume/stop hart through OpenSBI firmware, it also needs a OpenSBI that
support the HSM extension.
The pointer to buffer loading kernel binaries is in kernel space for
kexec_fil mode, When copy_from_user copies data from pointer to a block
of memory, it checkes that the pointer is in the user space range, on
RISCV-V that is:
and TASK_SIZE is 0x4000000000 for 64-bits, which now causes
copy_from_user to reject the access of the field 'buf' of struct
kexec_segment that is in range [CONFIG_PAGE_OFFSET - VMALLOC_SIZE,
CONFIG_PAGE_OFFSET), is invalid user space pointer.
This patch fixes this issue by skipping access_ok(), use mempcy() instead.
kexec_file: Fix kexec_file.c build error for riscv platform
When CONFIG_KEXEC_FILE is set for riscv platform, the compilation of
kernel/kexec_file.c generate build error:
kernel/kexec_file.c: In function 'crash_prepare_elf64_headers':
./arch/riscv/include/asm/page.h:110:71: error: request for member 'virt_addr' in something not a structure or union
110 | ((x) >= PAGE_OFFSET && (!IS_ENABLED(CONFIG_64BIT) || (x) < kernel_map.virt_addr))
| ^
./arch/riscv/include/asm/page.h:131:2: note: in expansion of macro 'is_linear_mapping'
131 | is_linear_mapping(_x) ? \
| ^~~~~~~~~~~~~~~~~
./arch/riscv/include/asm/page.h:140:31: note: in expansion of macro '__va_to_pa_nodebug'
140 | #define __phys_addr_symbol(x) __va_to_pa_nodebug(x)
| ^~~~~~~~~~~~~~~~~~
./arch/riscv/include/asm/page.h:143:24: note: in expansion of macro '__phys_addr_symbol'
143 | #define __pa_symbol(x) __phys_addr_symbol(RELOC_HIDE((unsigned long)(x), 0))
| ^~~~~~~~~~~~~~~~~~
kernel/kexec_file.c:1327:36: note: in expansion of macro '__pa_symbol'
1327 | phdr->p_offset = phdr->p_paddr = __pa_symbol(_text);
This occurs is because the "kernel_map" referenced in macro
is_linear_mapping() is suppose to be the one of struct kernel_mapping
defined in arch/riscv/mm/init.c, but the 2nd argument of
crash_prepare_elf64_header() has same symbol name, in expansion of macro
is_linear_mapping in function crash_prepare_elf64_header(), "kernel_map"
actually is the local variable.
Vasily Averin [Thu, 19 May 2022 14:30:49 +0000 (17:30 +0300)]
io_uring: fix incorrect __kernel_rwf_t cast
Currently 'make C=1 fs/io_uring.o' generates sparse warning:
CHECK fs/io_uring.c
fs/io_uring.c: note: in included file (through
include/trace/trace_events.h, include/trace/define_trace.h, i
nclude/trace/events/io_uring.h):
./include/trace/events/io_uring.h:488:1:
warning: incorrect type in assignment (different base types)
expected unsigned int [usertype] op_flags
got restricted __kernel_rwf_t const [usertype] rw_flags
This happen on cast of sqe->rw_flags which is defined as __kernel_rwf_t,
this type is bitwise and requires __force attribute for any casts.
However rw_flags is a member of the union, and its access can be safely
replaced by using of its neighbours, so let's use poll32_events to fix
the sparse warning.
Rob Clark [Thu, 19 May 2022 18:19:30 +0000 (11:19 -0700)]
Merge tag 'msm-next-5.19-fixes' of https://gitlab.freedesktop.org/abhinavk/msm into msm-fixes-staging
5.19 fixes for msm-next
- Limiting WB modes to max sspp linewidth
- Fixing the supported rotations to add 180 back for IGT
- Fix to handle pm_runtime_get_sync() errors to avoid unclocked access
in the bind() path for dpu driver
- Fix the irq_free() without request issue which was a big-time
hitter in the CI-runs.
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Rob Clark <robdclark@chromium.org>
Ulf Hansson [Wed, 11 May 2022 14:57:04 +0000 (16:57 +0200)]
PM: domains: Trust domain-idle-states from DT to be correct by genpd
If genpd has parsed the domain-idle-states from DT, it's reasonable to
believe that the parsed data should be correct for the HW in question.
Based upon this, it seem superfluous to let genpd measure the corresponding
power-on/off latencies for these states.
Therefore, let's improve the behaviour in genpd by avoiding the
measurements for the domain-idle-states that have been parsed from DT.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:57:03 +0000 (16:57 +0200)]
PM: domains: Measure power-on/off latencies in genpd based on a governor
The measurements of the power-on|off latencies in genpd for a PM domain are
superfluous, unless the corresponding genpd has a governor assigned to it,
which would make use of the data.
Therefore, let's improve the behaviour in genpd by making the measurements
conditional, based upon if there's a governor assigned.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:57:02 +0000 (16:57 +0200)]
PM: domains: Allocate governor data dynamically based on a genpd governor
If a genpd doesn't have an associated governor assigned, several variables
in the struct generic_pm_domain becomes superfluous.
Rather than wasting memory in allocated genpds, let's move the variables
from the struct generic_pm_domain into a new separate struct. In this way,
we can instead dynamically decide when we need to allocate the
corresponding data for it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:57:00 +0000 (16:57 +0200)]
PM: domains: Fix initialization of genpd's next_wakeup
In the genpd governor we walk the list of child-domains to take into
account their next_wakeup. If the child-domain itself, doesn't have a
governor assigned to it, we can end up using the next_wakeup value before
it has been properly initialized. To prevent a possible incorrect behaviour
in the governor, let's initialize next_wakeup to KTIME_MAX.
Fixes: c79aa080fb0f ("PM: domains: use device's next wakeup to determine domain idle state") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:59 +0000 (16:56 +0200)]
PM: domains: Fixup QoS latency measurements for IRQ safe devices in genpd
When an IRQ safe device is attached to a non-IRQ safe PM domain, genpd
needs to prevent the PM domain from being powered off. However, genpd still
allows the device to be runtime suspended/resumed, hence it's also
reasonable to think that a governor may be used to validate the QoS latency
constraints.
Unfortunately, genpd_runtime_resume() treats the configuration above, as a
reason to skip measuring the QoS resume latency for the device. This is a
legacy behaviour that was earlier correct, but should have been changed
when genpd was transformed into its current behaviour around how it manages
IRQ safe devices. Luckily, there's no report about problems, so let's just
fixup the behaviour.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:58 +0000 (16:56 +0200)]
PM: domains: Measure suspend/resume latencies in genpd based on governor
The QoS latency measurements for devices in genpd_runtime_suspend|resume()
are superfluous, unless the corresponding genpd has a governor assigned to
it, which would make use of the data.
Therefore, let's improve the behaviour in genpd by making the measurements
conditional, based upon if there's a governor assigned.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:57 +0000 (16:56 +0200)]
PM: domains: Move the next_wakeup variable into the struct gpd_timing_data
If the corresponding genpd for the device doesn't use a governor, the
variable next_wakeup within the struct generic_pm_domain_data becomes
superfluous.
To avoid wasting memory, let's move it into the struct gpd_timing_data,
which is already being allocated based upon if there is governor assigned.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:56 +0000 (16:56 +0200)]
PM: domains: Allocate gpd_timing_data dynamically based on governor
If a genpd doesn't have an associated governor assigned, there's really no
point to allocate the per device gpd_timing_data, as the data isn't being
used by a governor anyway.
To avoid wasting memory, let's therefore convert the corresponding td
variable in the struct generic_pm_domain_data into a pointer and manage the
allocation of its data dynamically.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:55 +0000 (16:56 +0200)]
PM: domains: Skip another warning in irq_safe_dev_in_sleep_domain()
In irq_safe_dev_in_sleep_domain() we correctly skip the dev_warn_once() if
the corresponding genpd for the device, has the GENPD_FLAG_ALWAYS_ON flag
being set. For the same reason (the genpd is always-on in runtime), let's
also skip the warning if the GENPD_FLAG_RPM_ALWAYS_ON flag is set for the
genpd.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:54 +0000 (16:56 +0200)]
PM: domains: Rename irq_safe_dev_in_no_sleep_domain() in genpd
The name "irq_safe_dev_in_no_sleep_domain", doesn't really match the
conditions that are being checked in the function, hence the code becomes a
bit confusing to read.
Let's clarify this by renaming it into "irq_safe_dev_in_sleep_domain" and
let's also take the opportunity to clarify a corresponding comment in the
code.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:53 +0000 (16:56 +0200)]
PM: domains: Don't check PM_QOS_FLAG_NO_POWER_OFF in genpd
Back in the days when genpd supported intermediate power states of its
devices, it made sense to check the PM_QOS_FLAG_NO_POWER_OFF in
genpd_power_off(). This because the attached devices were all being put
into low power state together when the PM domain was also being powered
off.
At this point, the flag PM_QOS_FLAG_NO_POWER_OFF is better checked by
drivers from their ->runtime_suspend() callbacks, like in the
usb_port_runtime_suspend(), for example. Or perhaps an even better option
is to set the QoS resume latency constraint for the device to zero, which
informs the runtime PM core to prevent the device from being runtime
suspended.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:52 +0000 (16:56 +0200)]
PM: domains: Drop redundant code for genpd always-on governor
Due to recent changes, the always-on governor is always used with a genpd
that has the GENPD_FLAG_RPM_ALWAYS_ON flag being set. This means genpd,
doesn't invoke the governor's ->power_down_ok() callback, which makes the
code in the governor redundant, so let's drop it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Wed, 11 May 2022 14:56:51 +0000 (16:56 +0200)]
PM: domains: Add GENPD_FLAG_RPM_ALWAYS_ON for the always-on governor
Rather than relying on the genpd provider to set the corresponding flag,
GENPD_FLAG_RPM_ALWAYS_ON, when the always-on governor is being used, let's
add it in pm_genpd_init(). In this way, it starts to benefits all genpd
providers immediately.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dave Jiang [Mon, 25 Apr 2022 18:03:29 +0000 (11:03 -0700)]
dmaengine: idxd: make idxd_wq_enable() return 0 if wq is already enabled
When calling idxd_wq_enable() and wq is already enabled, code should return 0
and indicate function is successful instead of return error code and fail.
This should also put idxd_wq_enable() in sync with idxd_wq_disable() where
it returns 0 if wq is already disabled.
Samuel Holland [Sun, 24 Apr 2022 17:27:57 +0000 (12:27 -0500)]
dmaengine: sun6i: Add support for 34-bit physical addresses
Recent Allwinner SoCs support >4 GiB of DRAM, so those variants of the
DMA engine support >32 bit physical addresses. This is accomplished by
placing the high bits in the "para" word in the DMA descriptor.
DMA descriptors themselves can be located at >32 bit addresses by
putting the high bits in the LSBs of the descriptor address register,
taking advantage of the required DMA descriptor alignment. However,
support for this is not really necessary, so we can avoid the
complication by allocating them from the DMA_32 zone.
Samuel Holland [Sun, 24 Apr 2022 17:27:56 +0000 (12:27 -0500)]
dmaengine: sun6i: Do not use virt_to_phys
This breaks on RISC-V, because dma_pool_alloc returns addresses which
are not in the linear map. Instead, plumb through the physical address
which is already known anyway.
Samuel Holland [Sun, 24 Apr 2022 17:27:55 +0000 (12:27 -0500)]
dt-bindings: dma: sun50i-a64: Add compatible for D1
D1 has a DMA controller similar to the one in other Allwinner SoCs.
Add its compatible, and include it in the list of variants with a
separate MBUS clock gate.
Initialize slave_bw in dma_prep*() functions as the parameter is not
set for DMA_MEM_TO_MEM case in get_transfer_param(). Though the case
may never occur, initializing it avoids warning from certain static
checkers
Amelie Delaunay [Thu, 5 May 2022 11:56:11 +0000 (13:56 +0200)]
dmaengine: stm32-dma: add device_pause/device_resume support
At any time, a DMA transfer can be suspended to be restarted later before
the end of the DMA transfer.
In order to restart from the point where the transfer was stopped,
DMA_SxNDTR has to be read after disabling the channel by clearing the EN
bit in DMA_SxCR register, to know the number of data items already
collected.
Peripheral and/or memory addresses have to be updated in order to adjust
the address pointers.
SxNDTR register has to be updated with the remaining number of data items
to be transferred (the value read when the channel was disabled).
Then the channel can be re-enabled to resume the transfer from the point
it was suspended.
If the channel was configured in circular or double-buffer mode, the
circular or double-buffer mode must be disabled before re-enabling the
channel to be able to reconfigure SxNDTR register and re-activate circular
or double-buffer mode on next Transfer Complete interrupt where channel
will be disabled by HW. This is due to the fact that on resume, re-writing
SxNDTR register value updates internal HW auto-reload data counter, and
then it truncates all next transfers after a pause/resume sequence.
Amelie Delaunay [Thu, 5 May 2022 11:56:10 +0000 (13:56 +0200)]
dmaengine: stm32-dma: rename pm ops before dma pause/resume introduction
dmaengine framework offers device_pause and device_resume ops to pause an
on-going transfer and resume it later.
To avoid any misunderstanding with system sleep pm ops, rename pm ops into
stm32_dma_pm_suspend and stm32_dma_pm_resume.
Amelie Delaunay [Thu, 5 May 2022 11:56:09 +0000 (13:56 +0200)]
dmaengine: stm32-dma: pass DMA_SxSCR value to stm32_dma_handle_chan_done()
stm32_dma_handle_chan_done() is called on Transfer Complete interrupt.
As DMA_SxSCR register is read in interrupt handler, pass the value as
parameter of stm32_dma_handle_chan_done(). Also return directly if
chan->desc is null to remove one ident level.
Then, stm32_dma_configure_next_sg() is doing something only if
Double-Buffer Mode (DBM) is enabled, so, check it is enabled prior calling
stm32_dma_configure_next_sg(), to remove one ident level in
stm32_dma_configure_next_sg().
Amelie Delaunay [Thu, 5 May 2022 11:56:08 +0000 (13:56 +0200)]
dmaengine: stm32-dma: introduce stm32_dma_sg_inc to manage chan->next_sg
chan->next_sg is used to know which transfer will start after the ongoing
one. It is incremented for each new transfer, either on transfer start for
non-cyclic transfers, or on transfer complete interrupt for cyclic
transfers.
For cyclic transfer, when the last item is reached, chan->next_sg must be
reinitialized to the first item.
Amelie Delaunay [Wed, 4 May 2022 16:17:24 +0000 (18:17 +0200)]
dmaengine: stm32-dmamux: avoid reset of dmamux if used by coprocessor
One of the two DMA controllers managed by the DMAMUX can be used by the
coprocessor. It is defined in the device tree with dma-masters.
When the two DMA controllers are used by the main CPU,
dma-masters = <&dma1, &dma2>; is specified in the device tree.
When one of the controllers is used by coprocessor (so not managed by
Linux), dma-masters = <&dma1>; is specified in the device tree.
In this case, Linux driver must not reset the DMAMUX, because it could have
been configured by the coprocessor to use the second DMA controller.
count is the number of DMA controllers defined in dma-masters property.
Reset only if resets property is found and valid in device tree, and if
the two DMA controllers are under Linux control.
Zhang Rui [Thu, 19 May 2022 14:37:32 +0000 (22:37 +0800)]
ACPI: video: improve PM notifer callback
PM notifier callbacks should check for supported events rather than filter
out the unsupported events. So that it won't break when a new event is
introduced.
No functional change in this patch.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Amelie Delaunay [Wed, 4 May 2022 15:53:22 +0000 (17:53 +0200)]
dmaengine: stm32-mdma: use dev_dbg on non-busy channel spurious it
If interrupt occurs while !chan->busy, it means channel has been disabled
between the raise of the interruption and the read of status and ien, so,
spurious interrupt can be silently discarded.
Amelie Delaunay [Wed, 4 May 2022 15:53:21 +0000 (17:53 +0200)]
dmaengine: stm32-mdma: fix chan initialization in stm32_mdma_irq_handler()
The parameter to pass back to the handler function when irq has been
requested is a struct stm32_mdma_device pointer, not a struct
stm32_mdma_chan pointer.
Even if chan is reinit later in the function, remove this wrong
initialization.
Amelie Delaunay [Wed, 4 May 2022 15:53:20 +0000 (17:53 +0200)]
dmaengine: stm32-mdma: remove GISR1 register
GISR1 was described in a not up-to-date documentation when the stm32-mdma
driver has been developed. This register has not been added in reference
manual of STM32 SoC with MDMA, which have only 32 MDMA channels.
So remove it from stm32-mdma driver.
Colin Ian King [Wed, 18 May 2022 08:45:36 +0000 (09:45 +0100)]
powercap: intel_rapl: remove redundant store to value after multiply
There is no need to store the result of the multiply back to variable value
after the multiplication. The store is redundant, replace *= with just *.
Cleans up clang scan build warning:
warning: Although the value stored to 'value' is used in the enclosing
expression, the value is never actually read from 'value'
[deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The driver is using functions from a compilation unit which is enabled
by CONFIG_CPU_SUP_INTEL. Add that dependency to Kconfig explicitly
otherwise:
drivers/platform/x86/intel/ifs/load.o: in function `ifs_load_firmware':
load.c:(.text+0x3b8): undefined reference to `intel_cpu_collect_info'
Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/YoZay8YR0zRGyVu+@zn.tnic Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Pierre Gondois [Wed, 18 May 2022 09:09:01 +0000 (11:09 +0200)]
cpufreq: CPPC: Enable dvfs_possible_from_any_cpu
The communication mean of the _CPC desired performance can be
PCC, System Memory, System IO, or Functional Fixed Hardware (FFH).
PCC, SystemMemory and SystemIo address spaces are available from any
CPU. Thus, dvfs_possible_from_any_cpu should be enabled in such case.
For FFH, let the FFH implementation do smp_call_function_*() calls.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pierre Gondois [Wed, 18 May 2022 09:09:00 +0000 (11:09 +0200)]
cpufreq: CPPC: Enable fast_switch
The communication mean of the _CPC desired performance can be
PCC, System Memory, System IO, or Functional Fixed Hardware.
commit b7898fda5bc7 ("cpufreq: Support for fast frequency switching")
fast_switching is 'for switching CPU frequencies from interrupt
context'.
Writes to SystemMemory and SystemIo are fast and suitable this.
This is not the case for PCC and might not be the case for FFH.
Enable fast_switching for the cppc_cpufreq driver in above cases.
Add cppc_allow_fast_switch() to check the desired performance
register address space and set fast_switching accordingly.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pierre Gondois [Wed, 18 May 2022 09:08:59 +0000 (11:08 +0200)]
ACPI: CPPC: Assume no transition latency if no PCCT
The transition_delay_us (struct cpufreq_policy) is currently defined
as:
Preferred average time interval between consecutive invocations of
the driver to set the frequency for this policy. To be set by the
scaling driver (0, which is the default, means no preference).
The transition_latency represents the amount of time necessary for a
CPU to change its frequency.
A PCCT table advertises mutliple values:
- pcc_nominal: Expected latency to process a command, in microseconds
- pcc_mpar: The maximum number of periodic requests that the subspace
channel can support, reported in commands per minute. 0 indicates no
limitation.
- pcc_mrtt: The minimum amount of time that OSPM must wait after the
completion of a command before issuing the next command,
in microseconds.
cppc_get_transition_latency() allows to get the max of them.
commit d4f3388afd48 ("cpufreq / CPPC: Set platform specific
transition_delay_us") allows to select transition_delay_us based on
the platform, and fallbacks to cppc_get_transition_latency()
otherwise.
If _CPC objects are not using PCC channels (no PPCT table), the
transition_delay_us is set to CPUFREQ_ETERNAL, leading to really long
periods between frequency updates (~4s).
If the desired_reg, where performance requests are written, is in
SystemMemory or SystemIo ACPI address space, there is no delay
in requests. So return 0 instead of CPUFREQ_ETERNAL, leading to
transition_delay_us being set to LATENCY_MULTIPLIER us (1000 us).
This patch also adds two macros to check the address spaces.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pierre Gondois [Wed, 18 May 2022 09:08:58 +0000 (11:08 +0200)]
ACPI: bus: Set CPPC _OSC bits for all and when CPPC_LIB is supported
The _OSC method allows the OS and firmware to communicate about
supported features/capabitlities. It also allows the OS to take
control of some features.
In ACPI 6.4, s6.2.11.2 Platform-Wide OSPM Capabilities, the CPPC
(resp. v2) bit should be set by the OS if it 'supports controlling
processor performance via the interfaces described in the _CPC
object'.
The OS supports CPPC and parses the _CPC object only if
CONFIG_ACPI_CPPC_LIB is set. Replace the x86 specific
boot_cpu_has(X86_FEATURE_HWP) dynamic check with an arch
generic CONFIG_ACPI_CPPC_LIB build-time check.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pierre Gondois [Wed, 18 May 2022 09:08:57 +0000 (11:08 +0200)]
ACPI: CPPC: Check _OSC for flexible address space
ACPI 6.2 Section 6.2.11.2 'Platform-Wide OSPM Capabilities':
Starting with ACPI Specification 6.2, all _CPC registers can be in
PCC, System Memory, System IO, or Functional Fixed Hardware address
spaces. OSPM support for this more flexible register space scheme is
indicated by the “Flexible Address Space for CPPC Registers” _OSC bit
Otherwise (cf ACPI 6.1, s8.4.7.1.1.X), _CPC registers must be in:
- PCC or Functional Fixed Hardware address space if defined
- SystemMemory address space (NULL register) if not defined
Add the corresponding _OSC bit and check it when parsing _CPC objects.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Heikki Krogerus [Thu, 19 May 2022 12:21:03 +0000 (15:21 +0300)]
platform/x86: intel_cht_int33fe: Set driver data
Module removal fails because cht_int33fe_typec_remove()
tries to access driver data that does not exist. Fixing by
assigning the data at the end of probe.
Fixes: 915623a80b5a ("platform/x86: intel_cht_int33fe: Switch to DMI modalias based loading") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20220519122103.78546-1-heikki.krogerus@linux.intel.com Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Zhang Rui [Thu, 19 May 2022 14:35:08 +0000 (22:35 +0800)]
thermal: intel: pch: improve the cooling delay log
Previously, during suspend, intel_pch_thermal driver logs for every
cooling iteration, about the current PCH temperature and number of cooling
iterations that have been tried, like below
[ 100.955526] intel_pch_thermal 0000:00:14.2: CPU-PCH current temp [53C] higher than the threshold temp [50C], sleep 1 times for 100 ms duration
[ 101.064156] intel_pch_thermal 0000:00:14.2: CPU-PCH current temp [53C] higher than the threshold temp [50C], sleep 2 times for 100 ms duration
After changing the default delay_cnt to 600, in practice, it is common to
see tens of the above messages if the system is suspended when PCH
overheats. Thus, change this log message from dev_warn to dev_dbg because
it is only useful when we want to check the temperature trend.
At the same time, there is always a one-line message given by the driver
with the patch applied, with below four possibilities.
1. PCH is cool, no cooling delay needed
[ 1791.902853] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [48C]
2. PCH overheats and becomes cool after the cooling delays
[ 1475.511617] intel_pch_thermal 0000:00:12.0: CPU-PCH is cool [49C] after 30700 ms delay
3. PCH still overheats after the overall cooling timeout
[ 2250.157487] intel_pch_thermal 0000:00:12.0: CPU-PCH is hot [60C] after 60000 ms delay. S0ix might fail
4. PCH aborts cooling because of wakeup event detected during the delay
[ 1933.639509] intel_pch_thermal 0000:00:12.0: Wakeup event detected, abort cooling
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Zhang Rui [Thu, 19 May 2022 14:35:07 +0000 (22:35 +0800)]
thermal: intel: pch: enhance overheat handling
Commit ef63b043ac86 ("thermal: intel: pch: fix S0ix failure due to PCH
temperature above threshold") introduces delay loop mechanism that allows
PCH temperature to go down below threshold during suspend so it won't
block S0ix. And the default overall delay timeout is 1 second.
However, in practice, we found that the time it takes to cool the PCH down
below threshold highly depends on the initial PCH temperature when the
delay starts, as well as the ambient temperature.
And in some cases, the 1 second delay is not sufficient. As a result, the
system stays in a shallower power state like PCx instead of S0ix, and
drains the battery power, without user' notice.
To make sure S0ix is not blocked by the PCH overheating, we
1. expand the default overall timeout to 60 seconds.
2. make sure the temperature is below threshold rather than equal to it.
At the same time, as the cooling delay can be much longer and many wakeup
events (ACPI Power Button press, USB mouse move, etc) becomes valid in the
suspend_noirq phase, add detection of wakeup event so that the driver
does not delay blindly when the system suspend is likely to abort soon.
This patch may introduce longer suspend time, but only in the cases when
the system overheats and Linux used to enter a shallower S2idle state,
say, PCx instead of S0ix.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Zhang Rui [Thu, 19 May 2022 14:35:05 +0000 (22:35 +0800)]
PM: wakeup: expose pm_wakeup_pending to modules
intel_pch_thermal driver needs a long delay to cool itself (60 seconds
in maximum) during suspend. When a wakeup event occures during the
delay, it is better for the intel_pch_thermal driver to detect this and
quit cooling because the suspend is likely to abort anyway.
Thus expose pm_wakeup_pending to modules so that intel_pch_thermal
driver can be aware of the wakeup events.
Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
platform/x86: intel-hid: fix _DSM function index handling
intel_hid_dsm_fn_mask is a bit mask containing one bit for each function
index. Fix the function index check in intel_hid_evaluate_method
accordingly, which was missed in commit 97ab4516205e ("platform/x86:
intel-hid: fix _DSM function index handling").
Fixes: 97ab4516205e ("platform/x86: intel-hid: fix _DSM function index handling") Cc: stable@vger.kernel.org Signed-off-by: Michael Niewöhner <linux@mniewoehner.de> Link: https://lore.kernel.org/r/66f813f5bcc724a0f6dd5adefe6a9728dbe509e3.camel@mniewoehner.de Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Merge tag 'icc-5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next
Georgi writes:
interconnect changes for 5.19
These are the interconnect changes for the 5.19-rc1 merge window
consisting of driver updates.
Driver changes:
- New driver for SC8280XP
- New driver for SDX65
- SC8180X driver fixes
- Constify various data structures in that are never modified
- Fix clock rate caching in RPM drivers.
- Misc fixes and clean-ups
Zhang Wensheng [Wed, 18 May 2022 07:45:16 +0000 (15:45 +0800)]
driver core: fix deadlock in __device_attach
In __device_attach function, The lock holding logic is as follows:
...
__device_attach
device_lock(dev) // get lock dev
async_schedule_dev(__device_attach_async_helper, dev); // func
async_schedule_node
async_schedule_node_domain(func)
entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);
/* when fail or work limit, sync to execute func, but
__device_attach_async_helper will get lock dev as
well, which will lead to A-A deadlock. */
if (!entry || atomic_read(&entry_count) > MAX_WORK) {
func;
else
queue_work_node(node, system_unbound_wq, &entry->work)
device_unlock(dev)
As shown above, when it is allowed to do async probes, because of
out of memory or work limit, async work is not allowed, to do
sync execute instead. it will lead to A-A deadlock because of
__device_attach_async_helper getting lock dev.
To fix the deadlock, move the async_schedule_dev outside device_lock,
as we can see, in async_schedule_node_domain, the parameter of
queue_work_node is system_unbound_wq, so it can accept concurrent
operations. which will also not change the code logic, and will
not lead to deadlock.
Hao Luo [Mon, 16 May 2022 19:09:51 +0000 (12:09 -0700)]
kernfs: Separate kernfs_pr_cont_buf and rename_lock.
Previously the protection of kernfs_pr_cont_buf was piggy backed by
rename_lock, which means that pr_cont() needs to be protected under
rename_lock. This can cause potential circular lock dependencies.
If there is an OOM, we have the following call hierarchy:
pr_cont_kernfs_name() will grab rename_lock and call printk. So we have
the following lock dependencies:
kernfs_rename_lock -> console_sem
Sometimes, printk does a wakeup before releasing console_sem, which has
the dependence chain:
console_sem -> p->pi_lock -> rq->lock
Now, imagine one wants to read cgroup_name under rq->lock, for example,
printing cgroup_name in a tracepoint in the scheduler code. They will
be holding rq->lock and take rename_lock:
rq->lock -> kernfs_rename_lock
Now they will deadlock.
A prevention to this circular lock dependency is to separate the
protection of pr_cont_buf from rename_lock. In principle, rename_lock
is to protect the integrity of cgroup name when copying to buf. Once
pr_cont_buf has got its content, rename_lock can be dropped. So it's
safe to drop rename_lock after kernfs_name_locked (and
kernfs_path_from_node_locked) and rely on a dedicated pr_cont_lock
to protect pr_cont_buf.
Ulf Hansson [Sat, 14 May 2022 15:20:44 +0000 (17:20 +0200)]
cpuidle: riscv-sbi: Fix code to allow a genpd governor to be used
The intent is to use a genpd governor when there are some states that needs
to be managed. Although, the current code ends up to never assign a
governor, let's fix this.
Fixes: 6abf32f1d9c50 ("cpuidle: Add RISC-V SBI CPU idle driver") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Anup Patel <anup@brainfault.org> Tested-by: Anup Patel <anup@brainfault.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ulf Hansson [Sat, 14 May 2022 15:20:32 +0000 (17:20 +0200)]
cpuidle: psci: Fix regression leading to no genpd governor
While factoring out the PM domain related code from PSCI domain driver into
a set of library functions, a regression when initializing the genpds got
introduced. More precisely, we fail to assign a genpd governor, so let's
fix this.
Fixes: 9d976d6721df ("cpuidle: Factor-out power domain related code from PSCI domain driver") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dietmar Eggemann [Fri, 13 May 2022 09:34:33 +0000 (11:34 +0200)]
topology: Remove unused cpu_cluster_mask()
default_topology[] uses cpu_clustergroup_mask() for the CLS level
(guarded by CONFIG_SCHED_CLUSTER) which is currently provided by x86
(arch/x86/kernel/smpboot.c) and arm64 (drivers/base/arch_topology.c).
Fixes: 778c558f49a2 ("sched: Add cluster scheduler level in core and related Kconfig for ARM64") Acked-by: Barry Song <baohua@kernel.org> Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Link: https://lore.kernel.org/r/20220513093433.425163-1-dietmar.eggemann@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
driver core: Extend deferred probe timeout on driver registration
The deferred probe timer that's used for this currently starts at
late_initcall and runs for driver_deferred_probe_timeout seconds. The
assumption being that all available drivers would be loaded and
registered before the timer expires. This means, the
driver_deferred_probe_timeout has to be pretty large for it to cover the
worst case. But if we set the default value for it to cover the worst
case, it would significantly slow down the average case. For this
reason, the default value is set to 0.
Also, with CONFIG_MODULES=y and the current default values of
driver_deferred_probe_timeout=0 and fw_devlink=on, devices with missing
drivers will cause their consumer devices to always defer their probes.
This is because device links created by fw_devlink defer the probe even
before the consumer driver's probe() is called.
Instead of a fixed timeout, if we extend an unexpired deferred probe
timer on every successful driver registration, with the expectation more
modules would be loaded in the near future, then the default value of
driver_deferred_probe_timeout only needs to be as long as the worst case
time difference between two consecutive module loads.
So let's implement that and set the default value to 10 seconds when
CONFIG_MODULES=y.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Rob Herring <robh@kernel.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Will Deacon <will@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Kevin Hilman <khilman@kernel.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Mark Brown <broonie@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Cc: linux-gpio@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: iommu@lists.linux-foundation.org Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20220429220933.1350374-1-saravanak@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chanwoo Choi [Thu, 19 May 2022 01:07:53 +0000 (10:07 +0900)]
PM / devfreq: passive: Return non-error when not-supported event is required
Each devfreq governor specifies the supported governor event
such as GOV_START and GOV_STOP. When not-supported event is required,
just return non-error. But, commit ce9a0d88d97a ("PM / devfreq: Add
cpu based scaling support to passive governor") returned the error
value. So that return non-error value when not-supported event is required.
Fixes: ce9a0d88d97a ("PM / devfreq: Add cpu based scaling support to passive governor") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add devm_register_restart_handler() helper that registers sys-off
handler using restart mode and with a default priority. Most drivers
will want to register restart handler with a default priority, so this
helper will reduce the boilerplate code and make code easier to read and
follow.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add devm_register_power_off_handler() helper that registers sys-off
handler using power-off mode and with a default priority. Most drivers
will want to register power-off handler with a default priority, so this
helper will reduce the boilerplate code and make code easier to read and
follow.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:33 +0000 (02:32 +0300)]
soc/tegra: pmc: Use sys-off handler API to power off Nexus 7 properly
Nexus 7 Android tablet can be turned off using a special bootloader
command which is conveyed to bootloader by putting magic value into the
special scratch register and then rebooting normally. This power-off
method should be invoked if USB cable is connected. Bootloader then will
display battery status and power off the device. This behaviour is
borrowed from downstream kernel and matches user expectations, otherwise
it looks like device got hung during power-off and it may wake up on
USB disconnect.
Switch PMC driver to sys-off handler API, which provides drivers with
chained power-off callbacks functionality that is required for powering-off
devices properly. It also brings resource-managed API for the restart
handler registration that makes PMC driver code cleaner.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:31 +0000 (02:32 +0300)]
regulator: pfuze100: Use devm_register_sys_off_handler()
Use devm_register_sys_off_handler() that replaces global
pm_power_off_prepare variable and allows to register multiple
power-off handlers.
Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:30 +0000 (02:32 +0300)]
ACPI: power: Switch to sys-off handler API
Switch to sys-off API that replaces legacy pm_power_off callbacks,
allowing us to remove global pm_* variables and support chaining of
all restart and power-off modes consistently.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:29 +0000 (02:32 +0300)]
memory: emif: Use kernel_can_power_off()
Replace legacy pm_power_off with kernel_can_power_off() helper that
is aware about chained power-off handlers.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:28 +0000 (02:32 +0300)]
mips: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:27 +0000 (02:32 +0300)]
ia64: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:26 +0000 (02:32 +0300)]
x86: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:25 +0000 (02:32 +0300)]
sh: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:24 +0000 (02:32 +0300)]
m68k: Switch to new sys-off handler API
Kernel now supports chained power-off handlers. Use
register_power_off_handler() that registers power-off handlers and
do_kernel_power_off() that invokes chained power-off handlers. Legacy
pm_power_off() will be removed once all drivers will be converted to
the new sys-off API.
Normally arch code should adopt only the do_kernel_power_off() at first,
but m68k is a special case because it uses pm_power_off() "inside out",
i.e. pm_power_off() invokes machine_power_off() [in fact it does nothing],
while it's machine_power_off() that should invoke the pm_power_off(), and
thus, we can't convert platforms to the new API separately. There are only
two platforms changed here, so it's not a big deal.
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:23 +0000 (02:32 +0300)]
powerpc: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:22 +0000 (02:32 +0300)]
xen/x86: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Juergen Gross <jgross@suse.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:21 +0000 (02:32 +0300)]
parisc: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Helge Deller <deller@gmx.de> # parisc Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:20 +0000 (02:32 +0300)]
arm64: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:19 +0000 (02:32 +0300)]
riscv: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Palmer Dabbelt <palmer@dabbelt.com> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:18 +0000 (02:32 +0300)]
csky: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Acked-by: Guo Ren <guoren@kernel.org> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:17 +0000 (02:32 +0300)]
ARM: Use do_kernel_power_off()
Kernel now supports chained power-off handlers. Use do_kernel_power_off()
that invokes chained power-off handlers. It also invokes legacy
pm_power_off() for now, which will be removed once all drivers will
be converted to the new sys-off API.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Dmitry Osipenko [Mon, 9 May 2022 23:32:16 +0000 (02:32 +0300)]
kernel/reboot: Add register_platform_power_off()
Add platform-level registration helpers that will ease transition of the
arch/platform power-off callbacks to the new sys-off based API, allowing
us to remove the global pm_power_off variable in the future.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
projects / people / ms / linux.git / log
