When considering both NPCA and DBE, it can appear that the
NPCA configuration is invalid, e.g. for an 80 MHz BSS channel
with DBE to 160 MHz:
| primary channel
| NPCA primary channel
| |
V V
| p | | n | | | | | |
| BSS channel |
| DBE channel |
Now the NPCA primary channel is in the same half as the primary
channel, and the NPCA puncturing bitmap could be completely
invalid as a puncturing bitmap when considering the overall
channel.
Split out the validity checks from cfg80211_chandef_valid() to
a new cfg80211_chandef_npca_valid() function that just checks
the NPCA configuration against the BSS chandef.
Link: https://patch.msgid.link/20260428112708.1225df131557.If3a6afadcce05d215b72fd82175f72373a0f6d24@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the device is capable, parse the AP chandef with NPCA.
Also advertise the other NPCA operational parameters to the
underlying driver and track if they change (though not with
BSS critical update etc. yet)
Since NPCA can only be enabled when the chanctx isn't shared,
the channel context code needs to clear/set npca.enabled in
the per-link configuration, except during association since
we can't enable NPCA before having completed association. In
this case, set npca.enabled during the association process.
Link: https://patch.msgid.link/20260428112708.eb1e42c0b6d7.I0acd8445d4600363afb8430922531450399d0fab@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When two interfaces share a channel context, disable NPCA
unless both are AP interfaces that require NPCA. This way,
two AP interfaces can have identical chandefs set up and
share the channel context, but any non-APs cannot share a
chanctx with NPCA (they'd almost certainly have different
BSS color.)
This doesn't mean the chanctx cannot be shared but rather
that NPCA will be disabled on the shared channel context.
Link: https://patch.msgid.link/20260428112708.3832e15f4e78.I08a7c7f47d796f4d5d8f9a682c1fba37db2e4cf5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Put the NPCA parameters into a chandef when parsing data from
the AP to validate them using the cfg80211 code, rather than
implementing that in mac80211 directly.
Note that the parameters are not applied yet, since mac80211
doesn't yet have NPCA support.
Link: https://patch.msgid.link/20260428112708.418e86f9444c.I54430f3018e39a26b4252d71000d7bb7dd744331@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add the necessary fields to the chandef data structure
to represent NPCA (the NPCA primary channel and NPCA
punctured/disabled subchannels bitmap), and the code
to check these for validity, compatibility, as well as
allowing it to be passed for AP mode for capable
devices.
Compatibility is assumed to only be the case when it's
actually identical, enabling later management of this
in channel contexts in mac80211 for multiple APs, but
requiring userspace to set up the identical chandef on
all AP interfaces that share a channel (and BSS color.)
Link: https://patch.msgid.link/20260428112708.46f3872aeb35.I85888dab88a6659ba52db4b3318979ca5bcfc0c8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For UHR, multi-link power-management capability lives there, and
so it's needed that hostapd knows what to advertise, and clients
should have it shown to userspace for information.
Repurpose the existing NL80211_ATTR_ASSOC_MLD_EXT_CAPA_OPS by
renaming it to NL80211_ATTR_EXT_MLD_CAPA_AND_OPS (with a define
for compatibility) and advertise the capabilities.
We can also later use the value, if needed, to set per-station
capabilities on STAs added to AP interfaces.
Link: https://patch.msgid.link/20260428110915.e808e70feed6.I378a7c017bfc1ebb072fa8d5d1db2ac9b45596c9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since 802.11bn D1.4 the DBE capabilities are after the
PHY capabilities, not between MAC and PHY, adjust the
code accordingly.
Also add a struct for DBE capabilities and use it for
checking the correct length instead of hard-coding the
lengths.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260428103657.b40af50f182d.I75306a092dc2c8a9eb7276160f0b7144b4846d18@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The interface frame queue processing code currently
differentiates many frame types and below those the
interface types, but then falls through to per-type
processing. Move this code to the per-type functions,
creating a new ap.c file that gets relevant code, and
this way reduce the number of non-static symbols.
This also helps with adding more cases for UHR later.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260428103649.c00059e68a07.I2269130278390f534d6051fac424402a854a54aa@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Introduce support for continuous ranging and advanced timing
parameters in the FTM request, response, and capability paths.
This enables more flexible ranging scenarios with improved control
over measurement timing and session management.
Co-developed-by: Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com>
Signed-off-by: Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com>
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
Link: https://patch.msgid.link/20260420090856.2152905-14-peddolla.reddy@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Many boards use on-board mux chips (often controlled by GPIOs from an I2C
expander) to switch shared signals between peripherals.
Add a generic pinctrl driver built on top of the mux framework to
centralize mux handling and avoid probe ordering issues. Keep board-level
routing out of individual drivers and supports boot-time only mux
selection.
Ensure correct probe ordering, especially when the GPIO expander is probed
later.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add an optional .release_mux() callback to struct pinmux_ops.
Some drivers acquire additional resources in .set_mux(), such as software
locks. These resources may need to be released when the mux function is no
longer active. Introducing a dedicated .release_mux() callback allows
drivers to clean up such resources.
The callback is optional and does not affect existing drivers.
Commit 2243a87d90 ("pinctrl: avoid duplicated calling
enable_pinmux_setting for a pin") removed the .disable() callback
to resolve two issues:
1. desc->mux_usecount increasing monotonically
2. Hardware glitches caused by repeated .disable()/.enable() calls
Adding .release_mux() does not reintroduce those problems. The callback is
intended only for releasing driver-side resources (e.g. locks) and must not
modify hardware registers.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
parsing logic from map creation. Introduce a new helper
pinctrl_generic_to_map() to handle mapping to kernel data structures, while
keeping DT property parsing in the subnode function.
Improve code structure and enables easier reuse for platforms using
different DT properties (e.g. pinmux) without modifying the
dt_node_to_map-style callback API. Avoid unnecessary coupling to
pinctrl_generic_pins_function_dt_node_to_map(), which provides
functionality not needed when the phandle target is unambiguous.
Maximize code reuse and provide a cleaner extension point for future
pinctrl drivers.
Suggested-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add a generic pinctrl binding for board-level pinmux chips that are
controlled through the multiplexer subsystem.
On some boards, especially development boards, external mux chips are used
to switch SoC signals between different peripherals (e.g. MMC and UART).
The mux select lines are often driven by a GPIO expander over I2C,
as illustrated below:
┌──────┐ ┌─────┐
│ SOC │ │ │ ┌───────┐
│ │ │ │───►│ MMC │
│ │ │ MUX │ └───────┘
│ ├─────►│ │ ┌───────┐
│ │ │ │───►│ UART │
│ │ └─────┘ └───────┘
│ │ ▲
│ │ ┌────┴──────────────┐
│ I2C ├───►│ GPIO Expander │
└──────┘ └───────────────────┘
Traditionally, gpio-hog is used to configure the onboard mux at boot.
However, the GPIO expander may probe later than consumer devices such as
MMC. As a result, the MUX might not be configured when the peripheral
driver probes, leading to initialization failures or data transfer errors.
Introduce a generic pinctrl binding that models the board-level MUX as a
pin control provider and builds proper device links between the MUX, its
GPIO controller, and peripheral devices. This ensures correct probe
ordering and reliable mux configuration.
The implementation leverages the standard multiplexer subsystem, which
provides broad support for onboard mux controllers and avoids the need for
per-driver custom MUX handling.
Allow pinctrl-* pattern as node name because this pinctrl device have not
reg property.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Add new API devm_mux_state_get_from_np() to retrieve a mux control from
a specified child device node.
Make devm_mux_state_get() call devm_mux_state_get_from_np() with a NULL
node parameter, which defaults to using the device's own of_node.
Support the following DT schema:
pinctrl@0 {
uart-func {
mux-state = <&mux_chip 0>;
};
spi-func {
mux-state = <&mux_chip 1>;
};
};
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
When preparing the panel, it seems that it always expects commands to be
transferred in LP mode. However, the disable function removes the
MIPI_DSI_MODE_LPM flag, and no other function re-adds it.
As the unprepare function contains no DSI commands, re-adding the flag
just after disabling the panel should be safe. Add the code re-adding
the flag after the two commands for disabling the panel are sent.
This fixes screen unblanking (after blanking once) on
mt8188-geralt-ciri-sku1 device.
Cc: stable@vger.kernel.org # 6.11+
Fixes: 0ef94554dc ("drm/panel: himax-hx83102: Break out as separate driver")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260425165751.1716569-1-zhengxingda@iscas.ac.cn
When preparing the panel, it seems that it always expects commands to be
transferred in LP mode. However, the disable function removes the
MIPI_DSI_MODE_LPM flag, and no other function re-adds it.
As the unprepare function contains no DSI commands, re-adding the flag
just after disabling the panel should be safe. Add the code re-adding
the flag after the two commands for disabling the panel are sent.
This fixes error messages shown in kernel log when unblanking on
mt8183-kukui-kodama-sku32 device.
Cc: stable@vger.kernel.org
Fixes: a869b9db7a ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260503091708.1079962-1-zhengxingda@iscas.ac.cn
mipi_dsi_dcs_set_display_on() returns an error code, but feiyang_enable()
currently ignores it and always reports success.
Return the DCS command result so callers can observe enable failures.
Signed-off-by: Christian Van <cvan20191@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com
Like a number of other panel drivers, this newly merged driver
needs DRM_DISPLAY_DSC_HELPER to be enabled:
arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-himax-hx83121a.o: in function `himax_prepare':
panel-himax-hx83121a.c:(.text+0x1024): undefined reference to `drm_dsc_pps_payload_pack'
Fixes: a7c61963b7 ("drm/panel: Add Himax HX83121A panel driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260413071043.3829868-1-arnd@kernel.org
Check devm_drm_panel_alloc() return value for ERR_PTR instead of NULL.
devm_drm_panel_alloc() returns an ERR_PTR on failure, never NULL. Using
a NULL check skips the error path and may cause a NULL pointer
dereference.
Fixes: a7c61963b7 ("drm/panel: Add Himax HX83121A panel driver")
Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260327021728.647182-1-nichen@iscas.ac.cn
Document the MDIO interface topology with an ASCII diagram
showing the MAC, PCS (MMD 3), FEC, Separated PMA (MMD 8), and PMD
(MMD 1) blocks and their interconnects. The diagram illustrates how
4 lanes connect the MAC through PCS, FEC, and PMA, then narrow to
2 lanes at the PMD.
The c45 read and write routines are enhanced to support
read and write of the separated PMA for the fbnic.
Co-developed-by: Alexander Duyck <alexanderduyck@fb.com>
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com>
Link: https://patch.msgid.link/20260430150802.3521-4-mike.marciniszyn@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Consolidate the register reads for boiler plate registers
to reduce LOC and cleanup pcs reads for DEVS1 to
fetch overrides for reserved bits that the hardware does not
return.
Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com>
Link: https://patch.msgid.link/20260430150802.3521-3-mike.marciniszyn@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add the constants associated with RS-FEC configuration
and status as well as the indicated separated bits for
DEVS1 to convey a separated PMA.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com>
Link: https://patch.msgid.link/20260430150802.3521-2-mike.marciniszyn@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The RK3588 MIPI CSI-2 receivers are compatible to the ones found in the
RK3568. Introduce a list of compatible variants and add the RK3588 variant
to it.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The get_hsfreq_by_mbps() function searches the freqranges[] table
backward (from highest to lowest index). Because adjacent frequency
bands overlap, a data rate that falls in the overlap region always
lands on the higher-indexed band.
For data rates up to 1500 Mbps (index 42) every band uses
osc_freq_target 335. Starting at index 43 (1461-1640 Mbps) the
osc_freq_target drops to 208. A sensor running at 1498 Mbps sits in
the overlap between index 42 (1414-1588, osc 335) and index 43
(1461-1640, osc 208). The backward search picks index 43, programming
the lower osc_freq_target of 208 instead of the optimal 335.
This causes DDL lock instability and CSI-2 CRC errors on affected
configurations, such as the OmniVision OV08X40 sensor on Intel Arrow
Lake platforms (Dell Pro Max 16).
Rewrite get_hsfreq_by_mbps() to select the optimal band:
1. Among bands whose min/max range covers the data rate, prefer
the one with the higher osc_freq_target.
2. If osc_freq_target is equal, prefer the band whose default_mbps
is closest to the requested rate.
Since the frequency ranges are monotonically increasing, the loop
exits early once min exceeds the requested rate.
For 1498 Mbps this now correctly selects index 42 (osc_freq_target
335, range 1414-1588) instead of index 43 (osc_freq_target 208,
range 1461-1640).
Fixes: 1e7eeb3016 ("media: intel/ipu6: add the CSI2 DPHY implementation")
Cc: stable@vger.kernel.org
Signed-off-by: Marco Nenciarini <mnencia@kcore.it>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The ipu7 driver's TODO specifies that the 'U' suffix should be
removed from hexadecimal values in register definitions.
This patch cleans up the definitions in the header files within the
ipu7 directory to comply with the requirements and improve consistency.
The modification was verified by comparing the disassembly of the
built-in.a archive before and after the change. The MD5 hashes of the
disassembly output remained identical, confirming that this is a
purely cosmetic cleanup with no functional impact on the binary.
Signed-off-by: Lian Xiangyu <lin25001x@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and
then passed to ipu7_bus_initialize_device(), which stores it in
adev->pdata. The ipu7_bus_release() function frees adev->pdata when the
device's reference count drops to zero.
Two error paths incorrectly call kfree(pdata) after the device teardown
has already freed it:
1. When ipu7_mmu_init() fails: put_device() is called, which drops the
reference count to zero and triggers ipu7_bus_release() ->
kfree(pdata). The subsequent kfree(pdata) is a double-free.
2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit()
internally, which calls put_device() -> ipu7_bus_release() ->
kfree(pdata). The subsequent kfree(pdata) is again a double-free.
Note that the kfree(pdata) when ipu7_bus_initialize_device() itself
fails is correct, because in that case auxiliary_device_init() failed
and the release function was never set up, so pdata must be freed
manually.
Additionally, the error code was not saved before calling put_device(),
causing ERR_CAST() to dereference the already-freed adev pointer when
constructing the return value. Fix this by saving the error from
dev_err_probe() before put_device() and returning ERR_PTR() instead.
Remove the redundant kfree(pdata) calls and fix the use-after-free in
the return values of the two affected error paths.
Fixes: b7fe4c0019 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
Cc: stable@vger.kernel.org
Reviewed-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
The I²C device id table is necessary as the device may be, besides through
system firmware, also instantiated in the IPU bridge so matching takes
place using the I²C device id table. Add back the table, with ids for all
supported devices.
Reported-by: Michael Anthony <manthony.nw@outlook.com>
Closes: https://lore.kernel.org/linux-media/AMBP190MB2678E7DC048409068260DCE8ED4AA@AMBP190MB2678.EURP190.PROD.OUTLOOK.COM/
Fixes: 15faf0fa14 ("media: i2c: dw9719: Remove unused i2c device id table")
Cc: stable@vger.kernel.org # for v6.19 and later
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
intel_pch_init_clock_gating() already handles unsupported PCH types,
including PCH_NOP, by doing nothing.
Drop the explicit HAS_PCH_NOP() check from the IVB clock gating
path and always call the display helper directly. This removes one
more direct dependency on display-side PCH macros from
intel_clock_gating.c.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-9-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the remaining pre-HSW display clock gating programming into
display.
This also drops display register includes from intel_clock_gating.c.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-8-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the HSW and BDW display clock gating programming into the display
code. In this case we need two different helpers, because the common
code between these two is split in the middle.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-7-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the GLK-specific display clock gating programming into display
intel_display_clock_gating.c, to remove more dependencies from i915 to
display registers.
Now that all remaining Gen9-family callers moved into display, we can
move the shared Gen9 display clock gating helper into display and
remove the old local helper from intel_clock_gating.c.
Additionally, the SKL_DE_COMPRESSED_HASH_MODE programming was
protected by HAS_LLC(), but that's incidental, because in Gen9
platforms, only SKL and KBL, for which this workaround applies, have
LLC(). In order not to use HAS_LLC() in display code, we can simply
remove this check from the generic Gen9 function and move the
SKL_DE_COMPRESSED_HASH_MODE programming to the KBL and SKL specific
functions. And, intentionally or not, CFL and CML were also using
this workaround, because they also have LLC, even though the comments
were only mentioning SKL and KBL. In order not to change anything
functionally with this patch, the workaround was also added to
intel_display_cfl_init_clock_gating().
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-6-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the BXT-specific display clock gating programming into display
intel_display_clock_gating.c, to remove more dependencies from i915.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-5-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the CFL/CML-specific display clock gating programming into
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-4-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the KBL-specific display clock gating programming into a
display intel_display_clock_gating.c, to remove more dependencies from
i915 to display registers.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-3-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Move the SKL-specific display clock gating programming into a new file
inside display.
This removes dependency from intel_clock_gating.c to the display's
intel_pch.h file, so we can remove the include statement.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260428095104.818360-2-luciano.coelho@intel.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
In wm_adsp_fw_find_test_find_firmware_byindex() the content of
priv->searched_fw_files must be cleared before starting the next iteration.
The files searched for are appended to priv->searched_fw_files, so if it is
not cleared on each iteration it will still contain the searches from the
previous iteration.
Fixes: bf2d44d07d ("ASoC: wm_adsp: Add kunit test for firmware file search")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260505105123.3539778-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
