| Age | Commit message (Collapse) | Author |
|---|
|
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_settime() function needs to be created. This
function will access the same registers than the common
ksz_ptp_settime().
Extract the register accesses into a dedicated function so it can be
used later by the KSZ8463 support.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-9-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_restart_perout() function needs to be created. This
function will use the same request initialization as the common
ksz_ptp_restart_perout() function.
Extract the inialization into a dedicated function so it can be used
later by the KSZ8463 support.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-8-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_enable_perout() function needs to be created. This
function will use the same algorithm to compute the periodic cycles as
the common ksz_ptp_enable_perout() function.
Extract these algorithms into a dedicated function so they can be used
later by the KSZ8463 support.
Add some checks on the period to ensure the request is valid and will
not cause divide by zero issues if the periodic output is restarted.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-7-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The KSZ8463 supports periodic outputs but doesn't handle them in the same
way as the other KSZ switches. To add proper support for the KSZ8463, a
dedicated ksz8463_ptp_enable_perout() function needs to be created. This
function will use the same algorithm to select the output pin as the
common ksz_ptp_enable_perout() function.
Extract the pin selection algorithm into a dedicated function so it can
be used later by the KSZ8463 support.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-6-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
KSZ8463 also has periodic output capabilities but the way its outputs
are driven differs from the other switches. It will need its own set of
PTP callbacks to implements this behaviour.
Extract the PTP callbacks configuration in a dedicated function to be
called before the PTP registration to ease the use of others callbacks
when needed.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-5-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The pulse width validity is checked against an hardcoded mask. KSZ8463
uses a smaller register than other switches so this check won't work for
it.
Move the mask as a ksz_ptp_tou_pulse_verify()'s input to allow changing
it for KSZ8463 case.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-4-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The number of periodic signals available is hardcoded to 3 while
KSZ8463 can produce 12 different periodic signals.
Add an n_per_out attribute to the struct ksz_chip_data to make this
setting configurable.
Set it to 3 for all the PTP-capable switches.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-3-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The number of periodic output pins available is hardcoded to 2 while
KSZ8463 has 12 pins that can be used as periodic outputs.
Add an n_pin attribute to the struct ksz_chip_data to make this setting
configurable.
Set it to 2 for all the PTP-capable switches.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-2-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When a periodic output is initialized, its period and start time are
stored to initialize it back in case of restart. These information
aren't enough if the request contains flags or targets a pin that isn't
the first output of the switch. At restarts, these two arguments are
always set to 0.
The 'flag issue' isn't concrete so far because the driver doesn't
advertise any .supported_perout_flags so any flag request gets rejected
by the upper layer.
I don't know if other switches use non-zero indexes but the KSZ8463 has
twelve periodic outputs, so this index has to also be saved from now on.
Save the full request when a periodic output is successfully started.
Use the saved request when the periodic output is restarted.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260925-ksz-perout-v4-1-d675bd21ce49@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The conversion to the dedicated RSS context operations replaced the
pointer to struct otx2_rss_ctx with an inline u32 ind_tbl[] array.
However, otx2_rss_init() still uses sizeof(*rss->ind_tbl) to set rss_size.
This now yields the size of one u32 (4), rather than the 256 entries in
the indirection table.
The RSS initialization and hardware programming loops use rss_size,
so only four entries are initialized and programmed despite the NIX LF
being allocated a 256-entry table. On an OCTEON CN102 with eight RX
queues, the table contained 0, 1, 2, 3 followed by zeros. Traffic was
concentrated on queue 0 and ethtool -X equal 8 did not correct the table.
Use ARRAY_SIZE() to count the indirection table entries. On the same
hardware, this restores the full table repeating queue numbers 0 through
7, and bidirectional multi-flow traffic increments multiple RX queues.
Runtime testing on an Asterfusion ET2500 (OCTEON CN102 A0).
Fixes: 62e01d8c4170 ("eth: otx2: migrate to the *_rxfh_context ops")
Cc: stable@vger.kernel.org
Closes: https://lore.kernel.org/netdev/361df563-e29e-43bf-8806-24bdfefed33d@nocloud.org/
Signed-off-by: Jari Seppälä <jase@nocloud.org>
Reviewed-by: Ratheesh Kannoth <rkannoth@marvell.com>
Link: https://patch.msgid.link/20260928084711.2462571-1-jase@nocloud.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
stmmac_tso_xmit() fills the MSS context descriptor and stores the new MSS
in tx_q->mss right away, but the descriptor only gets its OWN bit much
later, right before the frame is handed to the DMA. Every error path in
between - the dma_map_single() of the linear part and the
skb_frag_dma_map() of each fragment - returns with tx_q->mss already
updated while the MAC is still programmed with the previous MSS.
The context descriptor is now handled like the data descriptors are:
tx_q->cur_tx is not advanced while it is being filled, so the slot stays
where the next transmit fills it, and the error paths release it
explicitly instead of leaving a descriptor the DMA will stop on in the
middle of the ring. With the queue no longer wedged by that descriptor,
the stale cached MSS is what remains: the next skb carrying the same
gso_size compares equal to the cached value, no context descriptor is
emitted, and the hardware segments the TCP stream with the MSS of an
earlier frame, generating frames whose payload size does not match what
the stack accounted for.
Drop the cached value on those paths instead. Zero is what
stmmac_reset_tx_queue() leaves behind, so the next TSO frame programs the
context descriptor again.
The store itself stays ahead of the mappings, as before, rather than
moving next to the OWN bit: stmmac_tx_err() reinitialises the channel and
clears tx_q->mss from the DMA interrupt handler, which takes no TX queue
lock, so it can run in the middle of stmmac_tso_xmit(). Publishing the
cache after the descriptor has been handed over would widen the window in
which such a reset is overwritten with an MSS that the reinitialised
channel was never programmed with.
Found by manual code inspection and AI tools.
Not triggered or tested on real hardware.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Fixes: f748be531d70 ("stmmac: support new GMAC4")
Signed-off-by: Linkui Xiao <xiaolinkui@kylinos.cn>
Link: https://patch.msgid.link/20260928123422.1698785-1-xiaolinkui@126.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
register_netdev() exposes the interface to userspace which might trigger
operations like close on it. Those access the HRESP/LPI tasks and
might therefore use them uninitialised.
Fix this race by initialising both `struct work_struct` before
register_netdev().
Theoretical bugfix. The main reason for fix is to avoid future Sashiko
reports which triggers if we grow the race condition (by touching those
workqueues at open for example). The likeliness of this bug sounds
tiny, but I've not spent any time trying to reproduce it.
Cc: stable+noautosel@kernel.org # fix for an unproven driver init path race
Fixes: c5092ba3155e ("net: macb: Convert tasklet API to new bottom half workqueue mechanism")
Reported-by: sashiko <sashiko@sashiko.dev>
Link: https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918-macb-close-v1-0-05e32ce98813%40bootlin.com
Link: https://lore.kernel.org/netdev/179010942347.2160803.5970158668197373074@kernel.org/
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260925-macb-netdev-register-race-v1-1-752f90ce1c39@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When retrieving the MAC address, ax88172a_bind() checks the return
value of asix_read_cmd() against ETH_ALEN to detect short reads.
Commit c28d9a285668 ("ax88172a: fix ax88172a_unbind() failures") added
an -EIO assignment to ensure that this failure path returns a negative
error code, even when asix_read_cmd() returns a non-negative short-read
length.
Short-read handling was subsequently added to asix_read_cmd() by commit
920a9fa27e78 ("net: asix: add proper error handling of usb read errors").
The helper now converts short reads to -ENODATA while preserving
negative errors from the underlying USB read operation.
The MAC address short-read check in ax88172a_bind() is therefore
redundant now, and overwriting the return value with -EIO is no longer
necessary to ensure that the failure path returns a negative error code.
Check only for negative return values and remove the -EIO assignment
to preserve the error returned by asix_read_cmd() through the existing
cleanup path.
Signed-off-by: Xinsheng Zhu <xinsheng.zhu.ny@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260928044011.63926-1-xinsheng.zhu.ny@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When the switch uses a random base MAC address it does not mark each
port's address as random:
$ dmesg | grep "MAC addr"
sparx5-switch e00c0000.switch: MAC addr was not set, use random MAC
$ cat /sys/class/net/eth0/addr_assign_type
0
0 is NET_ADDR_PERM, so userspace thinks this is a stable address.
With a random MAC reported as NET_ADDR_PERM, systemd's
MACAddressPolicy=persistent [1] leaves it unchanged, so a DHCP client
gets a new IP address every boot and a static reservation can't be used.
Reporting it as NET_ADDR_RANDOM makes systemd replace it with a stable
address derived from the interface name and machine-id.
Fixes: f3cad2611a77 ("net: sparx5: add hostmode with phylink support")
Signed-off-by: Quentin Freimanis <quentin@q-lab.dev>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Link: https://patch.msgid.link/20260928045012.30178-1-quentin@q-lab.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Now that the timeout-related functions were removed from drm_utils.h,
the header has exclusively panel orientation and backlight quirk getters.
Therefore, rename the header accordingly and update all files that
include it. The files amdgpu_dm.c, amdgpu_dm_connector.c and panthor_drv.c
include the header but don't use it, so drop the include there.
No functional change.
Suggested-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-7-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
vc4_wait_bo_ioctl() converts its timeout with usecs_to_jiffies(), which
takes an unsigned int. The microsecond value derived from the u64
timeout_ns is narrowed to fit, so any timeout above UINT_MAX microseconds,
around ~71 minutes, wraps into a much shorter one. Unlike the equivalent
problem in the other drivers, this one is not limited to 32-bit.
Use the shared helper, which takes the duration in ns and clamps the
result to MAX_JIFFY_OFFSET.
Fixes: 21bd85f82ec2 ("drm/vc4: Use DMA Resv to implement VC4 wait BO IOCTL")
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-6-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
nsecs_to_jiffies_timeout() originated here and has since been copied into
another driver. It is now available in "drm_timeout.c", so use it and drop
the local definition.
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-5-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
v3d carried an exact copy of i915's nsecs_to_jiffies_timeout(). Now
that the conversion lives in "drm_timeout.c", drop the copy and use it.
The core helper also returns 0 for a zero timeout. i915 has that check in
to_wait_timeout(), but v3d only ever copied the conversion, so
DRM_IOCTL_V3D_WAIT_BO with timeout_ns == 0 was turned into a one jiffy
wait and could block for a tick before reporting -ETIME. It now returns
without waiting.
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-4-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
amdgpu_gem_timeout() converts an absolute deadline in ns into jiffies,
which is what drm_timeout_abs_to_jiffies() already does for the other
drivers whose wait UAPI takes a deadline. Use the shared helper and keep
only the part that is specific to amdgpu, which was improved with a
clearer comment.
Two details change along this conversion: the helper rounds up rather than
truncating, so a deadline less than a tick away now waits for one jiffy
instead of returning 0. It also uses nsecs_to_jiffies64(), so the
conversion no longer truncates on 32-bit, where a large deadline could
previously be reduced to an arbitrary shorter one.
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-3-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
drm_timeout_abs_to_jiffies() covers the drivers whose wait UAPI takes an
absolute deadline, but there is no equivalent for the drivers that
express a wait as a duration. Drivers such as i915 and v3d convert the
value themselves.
Converting a nanosecond duration to jiffies needs some care.
nsecs_to_jiffies() returns unsigned long, so on 32-bit a large
userspace-supplied timeout overflows its range and is silently truncated.
i915 already handles both cases in a local helper, which v3d has a copy
of. Add the same conversion to the core, so that it is available to any
driver and both copies can be dropped.
Differently from drm_timeout_abs_to_jiffies(), the new function enforces
that a timeout in jiffies is a positive value and therefore, returns an
unsigned value.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-2-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
drm_timeout_abs_to_jiffies() began as a static helper inside the syncobj
wait implementation and was later exported in place, so that it could be
called by multiple drivers (e.g. panfrost, lima, tegra and accel
drivers). All of them reach it through drm_utils.h.
Give it a file of its own, so that timeout conversion helpers have a
home, which will be useful when we add new timeout handlers. Also create
a drm_timeout.h header to host all timeout-related helpers.
The function was moved to the new file as it is, including the use of
"signed long" as the return type. Note that the return and parameters
types should be reconsidered in the future to better represent the
non-negative nature of a timeout.
No functional change.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260915-drm-timeout-helpers-v3-1-f2ae987d861f@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
|
|
Add pinctrl driver for StarFive JHB100 SoC Peripheral-3(per3) pinctrl
controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC Peripheral-2 Power OK
(per2pok) pinctrl controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC Peripheral-2(per2) pinctrl
controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC Peripheral-1(per1) pinctrl
controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC Peripheral-0(per0) pinctrl
controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC System-2(sys2) pinctrl
controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC System-1(sys1) pinctrl
controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC System-0 Host(sys0h) pinctrl
controller.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add pinctrl driver for StarFive JHB100 SoC System-0(sys0) pinctrl
controller.
Simultaneously add a generic pinctrl driver framework for registering
the pinctrl of other domains (sys1, sys2, and so on) in the JHB100 SoC.
Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
Signed-off-by: Alex Soo <yuklin.soo@starfivetech.com>
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
Add 'input-debounce-ns' to the generic parameters used for parsing DT
files, along with the corresponding configuration parameter
PIN_CONFIG_INPUT_DEBOUNCE_NS. This allows debounce time to be specified
in nanoseconds as an alternative to the existing 'input-debounce'
property which uses microseconds
Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
During S3 suspend, pci_pm_suspend_noirq() puts PCIe bridges with downstream
devices in a low-power state (D3hot or D3cold) when the platform allows it.
The hibernate poweroff_noirq path never did this: it only called
pci_prepare_to_sleep() for devices with no subordinate, so bridges with
active children were left in D0.
On many designs the platform firmware leaves bridges alone when the system
enters S4. This prevents being able to meet various energy certification
criteria for different parts of the world, particularly in designs with a
dGPU.
Align the hibernate flow with suspend by making pci_pm_poweroff_noirq()
use pci_pm_suspend_noirq_common() instead of the open-coded
pci_prepare_to_sleep() call. This reuses exactly the logic the S3
suspend path uses, including the skip_bus_pm handling that keeps a
bridge in D0 when a downstream device must stay in D0 (e.g. a
configured wakeup source) and the pm_suspend_no_platform() bus-PM skip.
This alone is safe for the normal power-off-and-reboot path, since the
hibernation image is snapshotted before poweroff_noirq runs and
restoring it always goes through a full boot that re-enumerates and
retrains the PCIe links.
It isn't enough if hibernation_platform_enter() aborts after
dpm_suspend_end(PMSG_HIBERNATE) but before power-off: that recovers via
dpm_resume_start(PMSG_RESTORE) without rebooting, which calls
pci_pm_restore_noirq() instead of pci_pm_resume_noirq(). Give
pci_pm_restore_noirq() the same D3cold handling pci_pm_resume_noirq()
already has, so a bridge coming out of D3cold gets
pci_pm_bridge_power_up_actions() before its children's restore_noirq
callbacks run against a possibly untrained link.
Mirror the suspend_noirq guard for drivers as well: if a driver's
poweroff_noirq callback already left the device in a low-power state
without saving its configuration, skip pci_pm_suspend_noirq_common() and
go straight to the fixups, exactly as pci_pm_suspend_noirq() does. This
avoids having the core call pci_save_state() on a device the driver has
already powered down, whose configuration space may no longer be
readable, which could otherwise corrupt the saved state used on a
poweroff abort.
Because the poweroff_noirq path now mirrors the already-shipping
suspend_noirq path and is guarded identically, bridges that must remain
in D0 are unaffected; only bridges that S3 suspend would have powered
down are now also powered down at hibernate.
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Eric Naim <dnaim@cachyos.org>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Cc: AceLan Kao <acelan.kao@canonical.com>
Cc: Kai-Heng Feng <kaihengf@nvidia.com>
Cc: Mark Pearson <mpearson-lenovo@squebb.ca>
Cc: Denis Benato <benato.denis96@gmail.com>
Cc: Merthan Karakaş <m3rthn.k@gmail.com>
Link: https://patch.msgid.link/20260930213923.566846-3-superm1@kernel.org
|
|
In order to unify suspend and hibernate code paths without code duplication
the common code should be in common helpers. Move the common code from
pci_pm_suspend_noirq() into a pci_pm_suspend_noirq_common() helper. No
intended functional changes.
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Eric Naim <dnaim@cachyos.org>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Link: https://patch.msgid.link/20260930213923.566846-2-superm1@kernel.org
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
More features:
- ath10k: NVMEM device tree bindings
- ath12k: QMI firmware alignments
- mm81x: AP improvements
- mac80211:
- CIP (control frame integrity) support
- NAN improvements
- cfg80211:
- improvements for AP regulatory checks
* tag 'wireless-next-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (67 commits)
wifi: mac80211: Gracefully deauthenticate on association timeout
wifi: libertas: fix RX OOB access from device-controlled pkt_ptr
wifi: mwifiex: Reattach interfaces on suspend failure
wifi: b43legacy: work around stack frame size warning
wifi: cw1200: fix link_id_db OOB access via device-controlled link ID
wifi: mwifiex: bound SDIO fw dump count by memory table size
wifi: mac80211: start next ROC after purging an interface
wifi: mac80211: fix potential ack-skb leak on error path
wifi: mac80211: mesh: don't send peering close in listen
wifi: mac80211_hwsim: Support NAN deferred schedule completion
wifi: mac80211: Restrict probe request rates for minimal content
wifi: nl80211: allow a NAN peer schedule with 2 channels in the same slot
wifi: cfg80211: use sysfs_emit_at() in addresses_show
wifi: cfg80211: require zero terminator in valid_regdb country table
wifi: cfg80211: fix NAN local schedule update ordering and allocation
wifi: mac80211: Fix a race when expiring a mesh path
wifi: cfg80211: validate monitor channel set against radio usage
wifi: nl80211: reject color-change requests that change 6 GHz power type
wifi: nl80211: defer AP beacon regulatory check to start_ap
wifi: radiotap: add definitions for UHR U-SIG
...
====================
Link: https://patch.msgid.link/20260930124547.228697-29-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Successfully initialized controllers are moved to intc_parent_list,
but the final cleanup only frees the descriptors. The device node
references taken with of_node_get() and the interrupt parent
references are therefore leaked on the normal return path. Drop both
before kfree(), as the intc_desc_list cleanup already does.
Fixes: 8363ccb917c6 ("of/irq: add missing of_node_put")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260917124247.2151674-1-vulab@iscas.ac.cn
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Still more fixes coming in, notably:
- ath11k: avoid running out of stations on HW restart
- mac80211:
- drop too large fragmented MPDUs
- mesh path handling fixes
- validation improvements
- reject CSA with bad 320 MHz bandwidth
- cfg80211: fix RTS for single radio devices
* tag 'wireless-2026-09-30' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (27 commits)
wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()
wifi: mac80211: reject invalid 320 MHz CSA bandwidth
wifi: mac80211: set info->band for 802.3 encap offload frames
wifi: mac80211: prevent AP VLAN tx from other interfaces
wifi: cfg80211: preserve hidden-group beacon IE ownership
wifi: mac80211: keep fallback association elements alive
wifi: mac80211: shut down RX BA session timer on teardown
wifi: mac80211: validate TX status rate metadata
wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE
wifi: ath9k: reject short WMI command responses
wifi: ath9k: Clean up device initialisation guards
wifi: ath11k: reset ar->num_stations on hardware start
wifi: cfg80211: fix RTS threshold setting for single-radio PHY
wifi: mac80211: handle empty FILS association request payload
wifi: mac80211: minstrel_ht: validate fixed rate index
wifi: p54: validate firmware record lengths
wifi: mac80211: fix mesh fast xmit path deletion UAF
wifi: mac80211: drop oversized fragments to avoid extra_len overflow
wifi: wlcore: Fix runtime PM leak in wlcore_remove()
wifi: mac80211: drain PS delivery work during station teardown
...
====================
Link: https://patch.msgid.link/20260930124440.224799-3-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
of_find_compatible_node() returns a referenced device node, but
EXCLUDED_DEFAULT_CELLS_PLATFORMS used the result only as a boolean and
discarded the reference. This leaked a reference each time the
address-cells or size-cells warning condition was evaluated on a
coreboot system.
Use a helper that checks for the coreboot node with a scoped reference,
so the reference is dropped once the check is done.
Fixes: 8600058ba28a7 ("of: Add coreboot firmware to excluded default cells list")
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
Link: https://patch.msgid.link/20260924011358.734722-1-oss.patchbox@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
|
|
The ring stats arrays were sized in one place and indexed in another,
with nothing reconciling the two. ice_vsi_alloc_stat_arrays() gave up as
soon as a container existed:
if (pf->vsi_stats[vsi->idx])
/* realloc will happen in rebuild path */
return 0;
while ice_vsi_alloc_ring_stats() walks the arrays with
ice_for_each_alloc_txq() / ice_for_each_alloc_rxq(), that is, up to
vsi->alloc_txq / vsi->alloc_rxq. Whenever the arrays are shorter than
the count ice_vsi_set_num_qs() ends up computing, that loop reads and
stores past the end of the kmalloc'ed pointer arrays.
Deferring to "the rebuild path" does not hold. It cannot get the size
right, and some paths never call it at all.
ice_devlink_reinit_down() is one of the latter. It calls ice_vsi_decfg()
directly, which does not free pf->vsi_stats[], and nothing on the way
down releases the main VSI's entry either: ice_dealloc_vsis() runs only
from ice_init()/ice_deinit(), and the single entry that ice_unload()
does drop is the control VSI's, via ice_deinit_fdir(). The main VSI's
arrays therefore survive the reload, while ice_devlink_reinit_up() runs
ice_vsi_cfg() and recomputes the count from
netif_get_num_default_rss_queues(), which follows cpu_online_mask.
Sizing the arrays with most CPUs offline and then onlining them is
enough, no VF involved:
for c in /sys/devices/system/cpu/cpu[0-9]*/online; do echo 0 > $c; done
echo 0000:18:00.0 > /sys/bus/pci/drivers/ice/unbind
echo 0000:18:00.0 > /sys/bus/pci/drivers/ice/bind
for c in /sys/devices/system/cpu/cpu[0-9]*/online; do echo 1 > $c; done
devlink dev reload pci/0000:18:00.0 action driver_reinit
The unbind/bind is what makes the arrays actually be allocated at the
small size; a reload alone only reuses them.
The read then runs off the end of tx_ring_stats[] and picks up whatever
follows it in kmalloc-32. Here that was a string, 0x74756f5f6c697475
spelling "util_out" in memory order. It is stored into ring->ring_stats
and faults on the first dereference, in ice_setup_tx_ring(), call trace:
RIP: 0010:ice_setup_tx_ring+0x8d/0xe0 [ice]
ice_vsi_setup_tx_rings+0x2a/0x80 [ice]
ice_vsi_open+0x28/0x170 [ice]
ice_open_internal+0xc9/0x160 [ice]
__dev_open+0x138/0x2b0
__dev_change_flags+0x1d5/0x250
netif_change_flags+0x21/0x60
do_setlink.constprop.0+0x336/0xcf0
rtnl_newlink+0x4a4/0x9b0
Even where the rebuild path does run, it sizes the arrays before
ice_vsi_decfg() returns the queues to the PF pool, and for an
ICE_VSI_PF VSI with no explicit request it derives the count from that
shared pool. Nothing serializes it against the recount in
ice_vsi_set_num_qs(), so a concurrent release, say
"echo 0 > sriov_numvfs", leaves the final count larger than the arrays
that were already installed.
ice_vsi_alloc_stat_arrays() runs from ice_vsi_cfg_def(), right after
ice_vsi_alloc_def() called ice_vsi_set_num_qs(), so it is the first
place where the queue count is final. Make it the only authority: keep
the existing arrays when they are already long enough, and otherwise
grow them with ice_vsi_install_stat_arrays(), which carries the
surviving entries over. The check only forces a grow: while both arrays
are long enough they are kept, an oversized one being merely wasteful.
Once either is too short the whole container is replaced, and then the
other one follows the final count too, shrinking if that is what it
takes.
Michal Schmidt hit the same corruption through the VF path, where a
guest raises its queue count with VIRTCHNL_OP_REQUEST_QUEUES and the
following VF reset reconfigures the VSI with the larger count while the
old, shorter arrays are still installed:
BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x385/0x4a0 [ice]
Workqueue: ice ice_service_task [ice]
Call Trace:
kasan_report+0xd7/0x120
ice_vsi_alloc_ring_stats+0x385/0x4a0 [ice]
ice_vsi_cfg_def+0x12e2/0x2060 [ice]
ice_vsi_cfg+0xb5/0x3c0 [ice]
ice_reset_vf+0x858/0xf80 [ice]
ice_vc_request_qs_msg+0x1da/0x290 [ice]
ice_vc_process_vf_msg+0xb15/0x1430 [ice]
__ice_clean_ctrlq+0x70d/0x9d0 [ice]
ice_service_task+0x840/0xf20 [ice]
process_one_work+0x690/0xff0
worker_thread+0x4d9/0xd20
kthread+0x322/0x410
ret_from_fork+0x332/0x660
ret_from_fork_asm+0x1a/0x30
Allocated by task 2439:
kasan_save_stack+0x1c/0x40
kasan_save_track+0x10/0x30
__kasan_kmalloc+0x96/0xb0
__kmalloc_noprof+0x1d8/0x580
ice_vsi_cfg_def+0x115c/0x2060 [ice]
ice_vsi_cfg+0xb5/0x3c0 [ice]
ice_vsi_setup+0x180/0x320 [ice]
ice_start_vfs+0x1f3/0x590 [ice]
ice_ena_vfs+0x66d/0x798 [ice]
ice_sriov_configure.cold+0xe4/0x121 [ice]
sriov_numvfs_store+0x279/0x480
kernfs_fop_write_iter+0x331/0x4f0
vfs_write+0x4c4/0xe40
ksys_write+0x10c/0x240
do_syscall_64+0xd9/0x650
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The buggy address belongs to the object at ffff88810affea40
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes to the right of
allocated 32-byte region [ffff88810affea40, ffff88810affea60)
Fixes: 288ecf491b16 ("ice: Accumulate ring statistics over reset")
Reported-by: Michal Schmidt <mschmidt@redhat.com>
Closes: https://redhat.atlassian.net/browse/RHEL-164321
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-7-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ice_vsi_realloc_stat_arrays() resized the ring stats arrays in place
with krealloc_array(), sizing them from vsi->req_txq/req_rxq. That is
not what ice_vsi_set_num_qs() computes later in ice_vsi_cfg_def(), so
after a rebuild the arrays could end up shorter than vsi->alloc_txq /
vsi->alloc_rxq, and ice_vsi_alloc_ring_stats() then walked past their
end.
The VF case shows the divergence. ice_sriov_set_msix_vec_count() writes
vsi->req_txq and then calls ice_vsi_rebuild(), so the old resizer sized
from req_txq, while ice_vsi_get_num_qs() reads vf->num_req_qs ?:
vf->num_vf_qs and ignores req_txq entirely. Once a guest has raised
vf->num_req_qs through VIRTCHNL_OP_REQUEST_QUEUES the two disagree and
the arrays come out shorter than the alloc_txq/alloc_rxq the rebuild
installs. The reset that such a request triggers is a different path,
ice_vf_reconfig_vsi(), which does not use this resizer at all; that one
is handled by the next patch.
Replace it with ice_vsi_resize_stat_arrays(), which allocates a fresh
struct ice_vsi_stats instead, sized with ice_vsi_get_num_qs() and the
queues ice_vsi_decfg() is about to return to the PF pool, which is
exactly what ice_vsi_set_num_qs() will compute once they are back
there, barring a concurrent change of the PF pool; the next patch stops
relying on that. Copy the surviving entry pointers over and install
the new structure, all before ice_vsi_decfg() runs. The entries that
did not fit are freed by ice_vsi_free_unused_stat_arrays(); the old
container itself then goes through __ice_vsi_free_stats() with
@free_entries set to false, since the entries it still points at now
belong to the new structure.
Allocating up front also means a failure no longer leaves a half-updated
ice_vsi_stats behind, with the Tx array already swapped and its surplus
Tx entries already freed, but the Rx allocation failed.
Put the allocate-install-free-surplus sequence in
ice_vsi_install_stat_arrays(), next to ice_vsi_new_stat_arrays(), so
that only the sizing decision is left in the resizer.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-6-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ice_vsi_set_num_qs() mixed two things: deciding how many queues a VSI
gets, and applying all the side effects of that decision. Split the
decision out into ice_vsi_get_num_qs(), returning both counts at once.
To make that possible, group alloc_txq and alloc_rxq in struct ice_vsi
with struct_group_tagged(), which gives the return type without adding
any new storage. Field order changes slightly, num_txq now follows
alloc_rxq, but nothing depends on it.
ice_vsi_get_num_qs() takes @held_txq and @held_rxq from the start, even
though the only caller so far passes zero for both. They let a caller
ask what the counts would be once the queues the VSI currently owns are
back in the PF pool. A later commit adds the caller that needs this: the
rebuild path has to size its ring stats arrays before ice_vsi_decfg()
releases the queues, yet the arrays must match what ice_vsi_set_num_qs()
computes afterwards.
While reshaping the whole body, drop the kernel-doc line promising a
return value; ice_vsi_set_num_qs() returns void.
No functional change intended.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-5-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Split the allocation of a struct ice_vsi_stats and its two ring stats
arrays out of ice_vsi_alloc_stat_arrays(), which is left with just the
lookup and the store into pf->vsi_stats[].
The sole caller keeps passing the very same queue counts as before,
vsi->alloc_txq and vsi->alloc_rxq. A later commit adds a second caller
in the rebuild path, which cannot use vsi->alloc_* because it has to
size the arrays before the VSI is reconfigured.
Note that the error path no longer clears pf->vsi_stats[vsi->idx]; the
early return above guarantees it is already NULL.
No functional change intended.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-4-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Record the length of each ring stats array in struct ice_vsi_stats, so
that freeing the array entries no longer needs the owning VSI. Keep the
new fields in sync in both places that size the arrays.
With that, the body of ice_vsi_free_stats() becomes independent of the
VSI and can be split out as __ice_vsi_free_stats(). The @free_entries
parameter is always true here; a later commit adds a caller that frees
only the array container, after its entries have been handed over to a
freshly allocated stats structure.
The free path now stops at the recorded length instead of the VSI queue
count, so it follows the real allocation rather than a number that can
disagree with it. Sizing still does not: "ice: rebuild ring stats arrays
instead of reallocating them in place" starts using the lengths to carry
entries over, and only "ice: size ring stats arrays from the final queue
count" makes them authoritative for the allocation path.
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-3-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
ice_vsi_alloc_stat_arrays() returns early for ICE_VSI_CHNL, so a channel
VSI never gets an entry in pf->vsi_stats[]. ice_vsi_realloc_stat_arrays()
dereferences that entry unconditionally, and ice_vsi_rebuild() calls it
before anything else, so the NULL is not filtered out anywhere.
The path is live. ice_prepare_for_reset() removes the queue channels only
for resets other than a PFR, so a PFR leaves the channel VSIs in place,
and ice_rebuild() then calls ice_rebuild_channels(), which rebuilds every
ICE_VSI_CHNL VSI it finds. A PF reset with ADQ (mqprio hardware offload)
configured thus dereferences NULL.
That combination is reset recovery on top of an active mqprio offload,
which is why it went unnoticed. It was found while refactoring this code,
not reported by a user.
I'm leaning towards removing our limited (compared to OOT ADQ) support,
but it's outside of this series. Bug could be triggered by:
tc qdisc del dev "$IF" root 2>/dev/null || true
tc qdisc add dev "$IF" root mqprio num_tc 2 \
map 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 \
queues 2@0 2@2 hw 1 mode channel
sleep 3
ethtool --reset "$IF" irq dma filter offload
Workqueue: ice ice_service_task [ice]
RIP: 0010:ice_vsi_rebuild+0x289/0x380 [ice]
ice_rebuild_channels+0xd6/0x320 [ice]
ice_rebuild+0x4f6/0x540 [ice]
ice_do_reset+0x9f/0x1a0 [ice]
ice_service_task+0x4a/0x460 [ice]
Fixes: 5995ef88e3a8 ("ice: realloc VSI stats arrays")
Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260925132636.123300-2-przemyslaw.kitszel@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Switch amdgpu_dm test helpers from the local STATIC_IFN_KUNIT
macro to VISIBLE_IF_KUNIT.
The two are not identical: STATIC_IFN_KUNIT was gated on
CONFIG_DRM_AMD_DC_KUNIT_TEST, while VISIBLE_IF_KUNIT is gated on
CONFIG_KUNIT. Helpers therefore become non-static whenever KUnit
is enabled, not only when the AMD DC tests are built.
However, given that DRM_AMD_DC_KUNIT_TEST depends on KUNIT,
tests remain behaviourally unchanged.
kernel-doc still needs to strip the qualifier. amdgpu_dm_color.c
is pulled into Documentation/gpu and several documented functions
use it.
Include <kunit/visibility.h> from dm_helpers.h, which is where the
local macros used to live.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use plane_descriptors[k] for the loop bound, matching the loop body.
Fixes: 7f7d7ea1fa51 ("drm/amd/display: Add new sources for DCN6")
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Lu Yao <yaolu@kylinos.cn>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
dc_state_create_copy() can return NULL on allocation failure.
dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts()
and continues execution, returning success. dm_resume() then
dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the
following dc_state->stream_count loop, crashing during GPU reset
recovery.
Return -ENOMEM immediately if the copy fails, so the caller aborts
suspend instead of leaving a NULL cached state for resume.
Fixes: 8092aa3ab8f7 ("drm/amd/display: Add null checker before passing variables")
Reviewed-by: George Zhang <george.zhang@amd.com>
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Tested-by: Dan Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
If drm_edp_backlight_enable() fails, dp_aux_backlight_update_status()
still marks the backlight as enabled. From then on every brightness
change only updates the level and the enable is never retried, so the
panel stays dark until something blanks and unblanks the backlight.
Return the error instead, so the next update tries to enable again.
Fixes: 10f7b40e4f30 ("drm/panel: add basic DP AUX backlight support")
Signed-off-by: Oleg Keri <okerixx@gmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260925132558.27518-1-okerixx@gmail.com
|
|
PM_EVENT_POWEROFF (0x0800) and PMSG_POWEROFF were already defined in
include/linux/pm.h, and pm_op(), pm_late_early_op() and pm_noirq_op()
already dispatch PM_EVENT_POWEROFF to the same ops->poweroff*() callbacks
as PM_EVENT_HIBERNATE. Add the matching entry to resume_event() so that
when a poweroff suspend sequence is aborted (for example a device's
->poweroff_noirq() callback fails and the PM core rolls the
already-suspended devices back), those devices are resumed with
PMSG_RESTORE and their ->restore*() callbacks run.
Map it to PMSG_RESTORE, mirroring the existing PM_EVENT_HIBERNATE
handling. This is correct because both events suspend via
ops->poweroff*(), whose counterpart is ops->restore*(). Mapping to
PMSG_ON would be a no-op: it is what the default return already yields,
and pm_op()/pm_late_early_op()/pm_noirq_op() have no PM_EVENT_ON case,
so they would return NULL and silently skip every resume callback on the
abort path.
This completes the PMSG_POWEROFF infrastructure needed to support
differentiating between hibernation and shutdown sequences when
re-using callbacks for common code.
Hibernation is started by writing a hibernation method (such as 'platform'
'shutdown', or 'reboot') to use into /sys/power/disk and writing 'disk' to
/sys/power/state.
Shutdown is initiated with the reboot() syscall with arguments on whether
to halt the system or power it off.
Tested-by: Eric Naim <dnaim@cachyos.org>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
[ rjw: Subject tweak ]
Link: https://patch.msgid.link/20260926225555.2916525-1-mario.limonciello@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
NV140WU2-M70 raw edid:
00 ff ff ff ff ff ff 00 09 e5 ae 38 00 00 00 00
14 24 01 04 a5 1e 13 78 07 7a 95 97 5d 59 95 29
20 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 24 31 80 a0 70 b0 3c 40 30 20
36 00 2d bc 10 00 00 1a 00 00 00 fd 00 28 3c 4c
4c 10 01 0a 20 20 20 20 20 20 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc
00 4e 56 31 34 30 57 55 32 2d 4d 37 30 0a 01 35
70 20 79 02 00 20 00 0c 9a 0e 00 ae 38 00 00 00
00 14 1a 00 21 01 1d c8 0b 5d 07 80 07 b0 04 88
74 b9 5d 99 85 95 97 42 20 02 35 54 b0 5c b0 5c
66 32 12 78 22 00 14 3f 66 02 85 7f 07 9f 00 2f
00 1f 00 af 04 3b 00 02 00 05 00 81 00 15 74 1a
00 00 03 01 28 3c 00 00 53 42 53 42 3c 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 8d 90
Signed-off-by: Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260930063856.183763-1-zhouhaikun5@huaqin.corp-partner.google.com
|
|
ad_sd_buffer_postenable() allocates sigma_delta->samples_buf with
devm_krealloc() at runtime, so its devres entry sits after all
probe-time entries of the driver. devm resources are released in
reverse allocation order, which means unbind frees samples_buf before
iio_device_unregister() disables the buffers and detaches the trigger
pollfunc. The data ready IRQ is still enabled at that point, so
ad_sd_trigger_handler() can still run and memcpy() incoming samples
into the freed samples_buf.
Fix this by preallocating the buffer in
devm_ad_sd_setup_buffer_and_trigger(), before the triggered buffer and
the IRQ are set up, so it is freed only after iio_device_unregister()
has drained the trigger handler via free_irq(). Size it for the worst
case of all sequencer slots being active; ad_sd_validate_scan_mask()
already caps the number of active channels at num_slots.
This issue was found by an in-house static analysis tool.
Fixes: 8bea9af887de ("iio: adc: ad_sigma_delta: Add sequencer support")
Cc: stable@vger.kernel.org
Co-developed-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
|
