When the non-transmitted BSSID profile is found, immediately return
from the search to not return the wrong profile_len when the profile
is found in a multiple BSSID element that isn't the last one in the
frame.
Fixes: 5023b14cf4 ("mac80211: support profile split between elements")
Reported-by: Michael-CY Lee <michael-cy.lee@mediatek.com>
Link: https://patch.msgid.link/20250630154501.f26cd45a0ecd.I28e0525d06e8a99e555707301bca29265cf20dc8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In disconnect paths paths, local frame buffers are used
to build deauthentication frames to send them over the
air and as notifications to userspace. Some internal
error paths (that, given no other bugs, cannot happen)
don't always initialize the buffers before sending them
to userspace, so in the presence of other bugs they can
leak stack content. Initialize the buffers to avoid the
possibility of this happening.
Suggested-by: Zhongqiu Han <quic_zhonhan@quicinc.com>
Link: https://patch.msgid.link/20250701072213.13004-2-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211 identifies a short beacon by the presence of the next
TBTT field, however the standard actually doesn't explicitly state that
the next TBTT can't be in a long beacon or even that it is required in
a short beacon - and as a result this validation does not work for all
vendor implementations.
The standard explicitly states that an S1G long beacon shall contain
the S1G beacon compatibility element as the first element in a beacon
transmitted at a TBTT that is not a TSBTT (Target Short Beacon
Transmission Time) as per IEEE80211-2024 11.1.3.10.1. This is validated
by 9.3.4.3 Table 9-76 which states that the S1G beacon compatibility
element is only allowed in the full set and is not allowed in the
minimum set of elements permitted for use within short beacons.
Correctly identify short beacons by the lack of an S1G beacon
compatibility element as the first element in an S1G beacon frame.
Fixes: 9eaffe5078 ("cfg80211: convert S1G beacon to scan results")
Signed-off-by: Simon Wadsworth <simon@morsemicro.com>
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20250701075541.162619-1-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Make several autosuspend functions mark last busy stamp and update
the documentation accordingly (Sakari Ailus).
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEcM8Aw/RY0dgsiRUR7l+9nS/U47UFAmhjrvQSHHJqd0Byand5
c29ja2kubmV0AAoJEO5fvZ0v1OO1aigIAKypscFSfd/WsAlP4orLtd4xiLi7KQHa
NrOYv7sZBVHgx4S9BGqHavYM3qhOBH5qCg+yBtqb8v6vp/TIlJjF2v3+C8uAXAnl
9GI5Gc6sZp/lMhf5Vb4Ibf58/P9lg4A7mIvM+LtfeEUMTlRrp47Q/RQ0ah7S4tDj
rFyC92QmBnkDLoyQp5IbCWkdjlqGgyTZzz/+XnfV9fWwX1aiXqaB4EZ2nXSAlyBx
awvA4/t662SWlHsdQqll9vS/+ZB39LEWwa1jJ7XGIK8t6GSH+TTys3S9/PHR/ua3
Dlcd+14plDGlSOy97hY+z6NdSgxH/qcpRgFduu5KwVqEwo2fqNkeV9Q=
=pFYw
-----END PGP SIGNATURE-----
Merge tag 'pm-runtime-6.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into gpio/for-next
Runtime PM updates related to autosuspend for 6.17
Make several autosuspend functions mark last busy stamp and update
the documentation accordingly (Sakari Ailus).
Simplify the code by using lock guards for the bgpio_lock. While at it:
move the gpio/driver.h include into its correct place alphabetically.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-5-6b77aab684d8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As the first step in removing the fields specific to the gpio-mmio
module from struct gpio_chip, we introduce a new set of generic GPIO
chip interfaces that are meant to replace the existing bgpio_ ones.
The new initialization function - gpio_generic_chip_init() - takes a
configuration structure as argument instead of 9 separate parameters.
This will allow easy extension if needed in the future. We hide the
locking details behind a set of helpers in order to be able to move the
raw spinlock out of struct gpio_chip without the users noticing.
For now, the new APIs just wrap the existing ones. Once all users have
been converted to the new interfaces, we'll pull them into gpio-mmio and
implement them in a backward-compatible way while also moving all fields
specific to the generic GPIO chip into struct gpio_generic_chip.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250702-gpio-mmio-rework-v2-1-6b77aab684d8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Remove struct bgpio_pdata after converting its users to generic device
properties.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEFp3rbAvDxGAT0sefEacuoBRx13IFAmhreU4ACgkQEacuoBRx
13LIJQ//VJTGNN3xgAVop4t9aMa+4OBnE1F8l18Di8H8/ZOe7PiAc6BAleioHl+h
zuc6uwgOZQUnUdEAYRVHkQJnI/1N65PO+DUFGQD4pABM7R1oW37aE7VNnW5HkjWh
WQl1mxIBdKyuR65HbCS76Ek/WzP3Qh37yNSS1gI9ISbbbHW77A3w88miBZwFVRof
KcNGM+oARbJC8ARAw+i+HsVODTouE7fH2Tr8aum2OExZs+wjroi3iLQQaup2lb9Y
gZzNN/pdOktVjk0/7HRJI/9zRDDxR3N7S/KXsyBd7vBfvM/RDqFHq8/o7K+HrXR1
pxp5fqqW29S82P2+7YTnU65pLJeyC2oEWwGJN+bB46dVG8BEBAa1s94UVCJF4Zq5
/rC69U5NxBL7XUolQ9WxiEXXlh1c0unlH/CJMiXcllR3DpYls3MIfymWKQvomve8
z7ub6gWTal0oW9TO3y8flPHBBslS0pZCgqmdenJdoLc+rc+cQRt2hmaquaOMbPqR
kqK+NI4aBdJ9JessW7I4zrWLRD8LhzT2zidyLgDwN1ghck1WD/Of0g7M8I1U2AZN
LmXRdPmDrHpKV7E/x3+Clsmq9n1A6q7i0PEcON1cv99LofK3vIWe3eBZvVyySnT7
szjVqngNlzePbRTTlsRcaOYPCcHu3yNxmLPwynqvL/pjjmJqaPQ=
=k0Ui
-----END PGP SIGNATURE-----
Merge tag 'gpio-mmio-remove-bgpio-pdata-for-v6.17-rc1' into gpio/for-next
Immutable branch between GPIO, MFD and ARM-SoC for v6.17-rc1
Remove struct bgpio_pdata after converting its users to generic device
properties.
LDO5 regulator is used to power the i.MX8MM NVCC_SD2 I/O supply, that is
used for the SD2 card interface and also for some GPIOs.
When the SD card interface is not enabled the regulator subsystem could
turn off this supply, since it is not used anywhere else, however this
will also remove the power to some other GPIOs, for example one I/O that
is used to power the ethernet phy, leading to a non working ethernet
interface.
[ 31.820515] On-module +V3.3_1.8_SD (LDO5): disabling
[ 31.821761] PMIC_USDHC_VSELECT: disabling
[ 32.764949] fec 30be0000.ethernet end0: Link is Down
Fix this keeping the LDO5 supply always on.
Cc: stable@vger.kernel.org
Fixes: 6a57f224f7 ("arm64: dts: freescale: add initial support for verdin imx8m mini")
Fixes: f5aab0438e ("regulator: pca9450: Fix enable register for LDO5")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
With no more users, we can now remove struct bgpio_pdata. Move the
relevant bits from bgpio_parse_fw() into bgpio_pdev_probe() while
maintaining the logical ordering (get flags before calling
bgpio_init()).
Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-6-ebf34d273497@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The GPIO device in crag6410 is registered with struct bgpio_pdata passed
as platform_data to the gpio-mmio driver. We want to remove the
bgpio_pdata from the kernel and the gpio-mmio driver is now also able to
get the relevant values from the software node. Set up device properties
and switch to using platform_device_info to register the device as
platform_add_devices() doesn't allow us to pass device properties to the
driver model.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-5-ebf34d273497@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The two latch GPIO devices in ams-delta are registered with struct
bgpio_pdata passed as platform_data to the gpio-mmio driver. We want to
remove the bgpio_pdata from the kernel and the gpio-mmio driver is now
also able to get the relevant values from the software node. Set up
device properties and switch to using platform_device_info to register
the devices as platform_add_devices() doesn't allow us to pass device
properties to the driver model.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-4-ebf34d273497@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Replace struct bgpio_pdata - that we plan to remove - with software
nodes containing properties encoding the same values thatr can now be
parsed by gpio-mmio.
Acked-by: Lee Jones <lee@kernel.org>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-3-ebf34d273497@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Ahead of removing struct bgpio_pdata support from the gpio-mmio generic
module, let's add support for getting the relevant values from generic
device properties. "label" is a semi-standardized property in some GPIO
drivers so let's go with it. There's no standard "base" property, so
let's use the name "gpio-mmio,base" to tie it to this driver
specifically. The number of GPIOs will be retrieved using
gpiochip_get_ngpios() so there's no need to look it up in the software
node.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-2-ebf34d273497@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
There are no more users of the "basic-mmio-gpio-be" platform device ID
in the kernel. We can safely drop it.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250701-gpio-mmio-pdata-v2-1-ebf34d273497@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the legacy generic
gpio-reg module to using them. We have to update the two legacy ARM
platforms that use it at the same time as they call the set_multiple()
callbacks directly (they shouldn't but it's old technical debt I
suppose).
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250623-gpiochip-set-rv-gpio-v3-1-90f0e170a846@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The WFHWSIZE constant defines the maximum size for the hardware-specific
waveform representation buffer. It is currently local to
drivers/pwm/core.c, which makes it inaccessible to external tools like
bindgen.
Move the constant to include/linux/pwm.h to make it part of the public
API. As part of this change, rename it to PWM_WFHWSIZE to follow
standard kernel conventions for namespacing macros in public headers.
This allows bindgen to automatically generate a corresponding constant
for the Rust PWM abstractions, ensuring the value remains synchronized
between the C core and Rust code and preventing future maintenance
issues.
Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
Link: https://lore.kernel.org/r/20250702-rust-next-pwm-working-fan-for-sending-v7-1-67ef39ff1d29@samsung.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
We have the distinction between pwm_apply_atomic() and
pwm_apply_might_sleep() since commit c748a6d77c (pwm: Rename
pwm_apply_state() to pwm_apply_might_sleep()) contained in v6.8-rc1.
Locking in the core was introduced in commit 1cc2e1faaf ("pwm: Add
more locking", contained in v6.13-rc1) to serialize per-chip callbacks
and device removal.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250624100500.1429163-2-u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The pwm core already serializes .apply(). twl6030's .request() and .free()
are also already serialized against .apply() because there is only a single
PWM. So the mutex doesn't add any additional protection and can be dropped.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/c1c7f646190f7cb2fe43b10959aa8dade80cb79e.1750788649.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Both mutexes are only used in one function each. These functions are only
called by the .apply() callback. As the .apply() calls are serialized by
the core since commit 1cc2e1faaf ("pwm: Add more locking") the mutexes
have no effect apart from runtime overhead. Drop them.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
Link: https://lore.kernel.org/r/4f7a2da37adbfe4743564245119045826d86eca6.1750788649.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The pwm core serializes calls to .apply(), so the driver local lock isn't
needed for that. It only has the effect to serialize .apply() with
.request() and .free() for a different PWM, and .request() and .free
against each other. But given that .request and .free() only do a single
regmap operation under the lock and regmap itself serializes register
accesses, it might happen without the lock that the calls are interleaved
now, but affecting different PWMs, so nothing bad can happen.
So the mutex has no effect and can be dropped.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/6b72104e5e1823170c7c9664189cc0f2ca5c2347.1750788649.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The pwm core serializes calls to .apply(), so the spinlock adds no
additional protection. Disabling the irq is also irrelevant as the driver
isn't an atomic one and so the callbacks cannot be called from atomic
context.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/d4931dc0c0d657d80722cfe7d97cb4fb4ccec90e.1750788649.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The two functions making use of the lock are only called transitively from
.apply(). Calls to .apply() are already serialized by the pwm core so the
lock in the driver has no effect and can safely be dropped.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/5ad3417aecd4dc6eca9699e21691e3725ea0bb87.1750788649.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Add trivial PWM driver for Argon40 Fan HAT, which is a RaspberryPi
blower fan hat which can be controlled over I2C. Model this device
as a PWM, so the pwm-fan can be attached to it and handle thermal
zones and RPM management in a generic manner.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://lore.kernel.org/r/20250629220757.936212-3-marek.vasut+renesas@mailbox.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Document trivial PWM on Argon40 Fan HAT, which is a RaspberryPi
blower fan hat which can be controlled over I2C.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://lore.kernel.org/r/20250629220757.936212-2-marek.vasut+renesas@mailbox.org
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
Add support for the PWM IP version 3.0.2, found in MediaTek's
Dimensity 9400 MT6991 and in the MT8196 Chromebook SoC: this
needs a new register offset array and also a different offset
for the PWM_CK_26M_SEL register.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250623120118.109170-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
