| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
The Intel USBIO driver is x86 only, other architectures have ACPI
so add an appropriate depenecy plus compile test.
Fixes: 121a0f839dbb3 ("usb: misc: Add Intel USBIO bridge driver")
Signed-off-by: Peter Robinson <[email protected]>
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a driver for the Intel USBIO USB IO-expander used by the MIPI cameras
on various new (Meteor Lake and later) Intel laptops.
This is an USB bridge driver which adds auxbus child devices for the GPIO,
I2C and SPI functions of the USBIO chip and which exports IO-functions for
the drivers for the auxbus child devices to communicate with the USBIO
device's firmware.
Co-developed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Israel Cepeda <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the usb251xb assumes i2c control. But from HW point of
view, the hub supports usage case without any i2c, we only want the
gpio controls.
Refactor the code so that register writes for configuration are only
performed if the device has a i2c_client provided and also register as
a platform driver. This allows the driver to be used to manage GPIO
based control of the device.
Signed-off-by: Jisheng Zhang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Use the modern PM macros for the suspend and resume functions to be
automatically dropped by the compiler when CONFIG_PM or
CONFIG_PM_SLEEP are disabled, without having to use __maybe_unused.
Signed-off-by: Jisheng Zhang <[email protected]>
Reviewed-by: Richard Leitner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
| |
Obviously file on the website was renamed.
Signed-off-by: Petr Vorel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EUD_MODE_MANAGER2 register is mapped to a memory region that is marked
as read-only for operating system running at EL1, enforcing access
restrictions that prohibit direct memory-mapped writes via writel().
Attempts to write to this region from HLOS can result in silent failures
or memory access violations, particularly when toggling EUD (Embedded
USB Debugger) state. To ensure secure register access, modify the driver
to use qcom_scm_io_writel(), which routes the write operation to Qualcomm
Secure Channel Monitor (SCM). SCM has the necessary permissions to access
protected memory regions, enabling reliable control over EUD state.
SC7280, the only user of EUD is also affected, indicating that this could
never have worked on a properly fused device.
Fixes: 9a1bf58ccd44 ("usb: misc: eud: Add driver support for Embedded USB Debugger(EUD)")
Signed-off-by: Melody Olvera <[email protected]>
Reviewed-by: Konrad Dybcio <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Reviewed-by: Souradeep Chowdhury <[email protected]>
Signed-off-by: Komal Bajaj <[email protected]>
Link: https://lore.kernel.org/r/20250731-eud_mode_manager_secure_access-v8-1-4a5dcbb79f41@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When `devm_add_action_or_reset()` fails, it is due to a failed memory
allocation and will thus return `-ENOMEM`. `dev_err_probe()` doesn't do
anything when error is `-ENOMEM`. Therefore, remove the useless call to
`dev_err_probe()` when `devm_add_action_or_reset()` fails, and just
return the value instead.
Signed-off-by: Waqar Hameed <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The Camera is built into the Thinkbook 16 G7 QOY and directly attached on the
usb_2 controller (dwc3 USB2 only). It has a separate power supply that needs
to be controlled for PM.
Add the support for this device for the power supply.
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Jens Glathe <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When multiple Apple devices are connected concurrently, the
apple-mfi-fastcharge driver fails to probe the subsequent devices with
the following error:
sysfs: cannot create duplicate filename '/class/power_supply/apple_mfi_fastcharge'
apple-mfi-fastcharge 5-2.4.3.3: probe of 5-2.4.3.3 failed with error -17
This happens because the driver uses a fixed power supply name
("apple_mfi_fastcharge") for all devices, causing a sysfs name
conflict when a second device is connected.
Fix this by generating unique names using the USB bus and device
number (e.g., "apple_mfi_fastcharge_5-12"). This ensures each
connected device gets a unique power supply entry in sysfs.
The change requires storing a copy of the power_supply_desc structure
in the per-device mfi_device struct, since the name pointer needs to
remain valid for the lifetime of the power supply registration.
Fixes: 249fa8217b84 ("USB: Add driver to control USB fast charge for iOS devices")
Signed-off-by: Charalampos Mitrodimas <[email protected]>
Link: https://lore.kernel.org/r/20250602-apple-mfi-fastcharge-duplicate-sysfs-v1-1-5d84de34fac6@posteo.net
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
Move this API to the canonical timer_*() namespace.
[ tglx: Redone against pre rc1 ]
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt updates from Greg KH:
"Here is the big set of USB and Thunderbolt changes for 6.16-rc1.
Included in here are the following:
- USB offload support for audio devices.
I think this takes the record for the most number of patch series
(30+) over the longest period of time (2+ years) to get merged
properly.
Many props go to Wesley Cheng for seeing this effort through, they
took a major out-of-tree hacked-up-monstrosity that was created by
multiple vendors for their specific devices, got it all merged into
a semi-coherent set of changes, and got all of the different major
subsystems to agree on how this should be implemented both with
changes to their code as well as userspace apis, AND wrangled the
hardware companies into agreeing to go forward with this, despite
making them all redo work they had already done in their private
device trees.
This feature offers major power savings on embedded devices where a
USB audio stream can continue to flow while the rest of the system
is sleeping, something that devices running on battery power really
care about. There are still some more small tweaks left to be done
here, and those patches are still out for review and arguing among
the different hardware companies, but this is a major step forward
and a great example of how to do upstream development well.
- small number of thunderbolt fixes and updates, things seem to be
slowing down here (famous last words...)
- xhci refactors and reworking to try to handle some rough corner
cases in some hardware implementations where things don't always
work properly
- typec driver updates
- USB3 power management reworking and updates
- Removal of some old and orphaned UDC gadget drivers that had not
been used in a very long time, dropping over 11 thousand lines from
the tree, always a nice thing, making up for the 12k lines added
for the USB offload feature.
- lots of little updates and fixes in different drivers
All of these have been in linux-next for over 2 weeks, the USB offload
logic has been in there for 8 weeks now, with no reported issues"
* tag 'usb-6.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (172 commits)
ALSA: usb-audio: qcom: fix USB_XHCI dependency
ASoC: qdsp6: fix compile-testing without CONFIG_OF
usb: misc: onboard_usb_dev: fix build warning for CONFIG_USB_ONBOARD_DEV_USB5744=n
usb: typec: tipd: fix typo in TPS_STATUS_HIGH_VOLAGE_WARNING macro
USB: typec: fix const issue in typec_match()
USB: gadget: udc: fix const issue in gadget_match_driver()
USB: gadget: fix up const issue with struct usb_function_instance
USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB
USB: serial: bus: fix const issue in usb_serial_device_match()
usb: usbtmc: Fix timeout value in get_stb
usb: usbtmc: Fix read_stb function and get_stb ioctl
ALSA: qc_audio_offload: try to reduce address space confusion
ALSA: qc_audio_offload: avoid leaking xfer_buf allocation
ALSA: qc_audio_offload: rename dma/iova/va/cpu/phys variables
ALSA: usb-audio: qcom: Fix an error handling path in qc_usb_audio_probe()
usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence
dt-bindings: usb: ti,usb8041: Add binding for TI USB8044 hub controller
usb: misc: onboard_usb_dev: Add support for TI TUSB8044 hub
usb: gadget: lpc32xx_udc: Use USB API functions rather than constants
usb: gadget: epautoconf: Use USB API functions rather than constants
...
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CONFIG_USB_ONBOARD_DEV_USB5744=n
When the USB5744 option is disabled, the onboard_usb driver warns about
unused functions:
drivers/usb/misc/onboard_usb_dev.c:358:12: error: 'onboard_dev_5744_i2c_write_byte' defined but not used [-Werror=unused-function]
358 | static int onboard_dev_5744_i2c_write_byte(struct i2c_client *client, u16 addr, u8 data)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/usb/misc/onboard_usb_dev.c:313:12: error: 'onboard_dev_5744_i2c_read_byte' defined but not used [-Werror=unused-function]
313 | static int onboard_dev_5744_i2c_read_byte(struct i2c_client *client, u16 addr, u8 *data)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Extend the #ifdef block a little further to cover all of these functions.
Ideally we'd use use if(IS_ENABLED()) instead, but that doesn't currently
work because the i2c_transfer() and i2c_smbus_write_word_data() function
declarations are hidden when CONFIG_I2C is disabled.
Fixes: 1143d41922c0 ("usb: misc: onboard_usb_dev: Fix usb5744 initialization sequence")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce i2c APIs to read/write for proper configuration register
programming. It ensures that read-modify-write sequence is performed
and reserved bit in Runtime Flags 2 register are not touched.
Also legacy smbus block write inserted an extra count value into the
i2c data stream which breaks the register write on the usb5744.
Switching to new read/write i2c APIs fixes both issues.
Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support")
Cc: stable <[email protected]>
Signed-off-by: Jonathan Stroud <[email protected]>
Co-developed-by: Radhey Shyam Pandey <[email protected]>
Signed-off-by: Radhey Shyam Pandey <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The TUSB8044 is similar to the TUSB8041. This adds the PID/VID values
and allows to specify the reset GPIO signal on the board.
Signed-off-by: Mike Looijmans <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |\
| | |
| | |
| | |
| | |
| | | |
We need the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Parade PS5511 is 4+1 port USB 3.2 gen 1 hub with a reset pin and two power
supplies (3V3 and 1V1).
Add the support for this hub for the reset pin control and power supply.
Signed-off-by: Pin-yen Lin <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Realtek RTL8188ETV 2.4 GHz WiFi modules (detected as RTL8188EU by the
RTL8XXXXU driver) are found soldered into some embedded devices, such as
the Fernsehfee 3.0 set-top box.
They require a 3.3V power supply.
Signed-off-by: J. Neuschäfer <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer cleanups from Thomas Gleixner:
"Another set of timer API cleanups:
- Convert init_timer*(), try_to_del_timer_sync() and
destroy_timer_on_stack() over to the canonical timer_*()
namespace convention.
There is another large conversion pending, which has not been included
because it would have caused a gazillion of merge conflicts in next.
The conversion scripts will be run towards the end of the merge window
and a pull request sent once all conflict dependencies have been
merged"
* tag 'timers-cleanups-2025-05-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
treewide, timers: Rename destroy_timer_on_stack() as timer_destroy_on_stack()
treewide, timers: Rename try_to_del_timer_sync() as timer_delete_sync_try()
timers: Rename init_timers() as timers_init()
timers: Rename NEXT_TIMER_MAX_DELTA as TIMER_NEXT_MAX_DELTA
timers: Rename __init_timer_on_stack() as __timer_init_on_stack()
timers: Rename __init_timer() as __timer_init()
timers: Rename init_timer_on_stack_key() as timer_init_key_on_stack()
timers: Rename init_timer_key() as timer_init_key()
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| | |
Move this API to the canonical timer_*() namespace.
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/all/[email protected]
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Cypress HX3 USB3.0 hubs use different PID values depending
on the product variant. The comment in compatibles table is
misleading, as the currently used PIDs (0x6504 and 0x6506 for
USB 3.0 and USB 2.0, respectively) are defaults for the CYUSB331x,
while CYUSB330x and CYUSB332x variants use different values.
Based on the datasheet [1], update the compatible usb devices table
to handle different types of the hub.
The change also includes vendor mode PIDs, which are used by the
hub in I2C Master boot mode, if connected EEPROM contains invalid
signature or is blank. This allows to correctly boot the hub even
if the EEPROM will have broken content.
Number of vcc supplies and timing requirements are the same for all
HX variants, so the platform driver's match table does not have to
be extended.
[1] https://www.infineon.com/dgdl/Infineon-HX3_USB_3_0_Hub_Consumer_Industrial-DataSheet-v22_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ecb53f644b8
Table 9. PID Values
Fixes: b43cd82a1a40 ("usb: misc: onboard-hub: add support for Cypress HX3 USB 3.0 family")
Cc: stable <[email protected]>
Signed-off-by: Lukasz Czechowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.
Conversion was done with coccinelle plus manual fixups where necessary.
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This hub is powered by digital and analog 3V3 power rails, so provide
the possibility to use different regulators for digital (vdd) and analog
(vdda) power rails.
Signed-off-by: Catalin Popescu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Use dev_err_probe to silence EPROBE_DEFER error on boot:
[ 0.757677] usb251xb 1-002c: failed to get ofdata: -517
Signed-off-by: Dominique Martinet <[email protected]>
Acked-by: Richard Leitner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
support
USB5744 SMBus initialization is done once in probe() and doing it in resume
is not supported so avoid going into suspend and reset the HUB.
There is a sysfs property 'always_powered_in_suspend' to implement this
feature but since default state should be set to a working configuration
so override this property value.
It fixes the suspend/resume testcase on Kria KR260 Robotics Starter Kit.
Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support")
Cc: [email protected]
Signed-off-by: Radhey Shyam Pandey <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Ensure type safety by using min_t() instead of min().
Also add the explicit `unsigned int` as scripts/checkpatch.pl warns about:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Signed-off-by: Sabyrzhan Tasbolatov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some Lenovo platforms, the patch works around problems with ov2740
sensor initialization, which manifest themself like below:
[ 4.540476] ov2740 i2c-INT3474:01: error -EIO: failed to find sensor
[ 4.542066] ov2740 i2c-INT3474:01: probe with driver ov2740 failed with error -5
or
[ 7.742633] ov2740 i2c-INT3474:01: chip id mismatch: 2740 != 0
[ 7.742638] ov2740 i2c-INT3474:01: error -ENXIO: failed to find sensor
and also by random failures of video stream start.
Issue can be reproduced by this script:
n=0
k=0
while [ $n -lt 50 ] ; do
sudo modprobe -r ov2740
sleep `expr $RANDOM % 5`
sudo modprobe ov2740
if media-ctl -p | grep -q ov2740 ; then
let k++
fi
let n++
done
echo Success rate $k/$n
Without the patch, success rate is approximately 15 or 50 tries.
With the patch it does not fail.
This problem is some hardware or firmware malfunction, that can not be
easy debug and fix. While setting small autosuspend delay is not perfect
workaround as user can configure it to any value, it will prevent
the failures by default.
Additionally setting small autosuspend delay should have positive effect
on power consumption as for most ljca workloads device is used for just
a few milliseconds flowed by long periods of at least 100ms of inactivity
(usually more).
Fixes: acd6199f195d ("usb: Add support for Intel LJCA device")
Cc: [email protected]
Reviewed-by: Hans de Goede <[email protected]>
Tested-by: Hans de Goede <[email protected]> # ThinkPad X1 Yoga Gen 8, ov2740
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not mark interface as ready to suspend when we are still waiting
for response messages from the device.
Fixes: acd6199f195d ("usb: Add support for Intel LJCA device")
Cc: [email protected]
Reviewed-by: Hans de Goede <[email protected]>
Tested-by: Hans de Goede <[email protected]> # ThinkPad X1 Yoga Gen 8, ov2740
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Stanislaw Gruszka <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |\
| |
| |
| |
| |
| | |
We need the USB fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes for some reported problems for 6.12-rc3.
Include in here is:
- fix for yurex driver that was caused in -rc1
- build error fix for usbg network filesystem code
- onboard_usb_dev build fix
- dwc3 driver fixes for reported errors
- gadget driver fix
- new USB storage driver quirk
- xhci resume bugfix
All of these have been in linux-next for a while with no reported
issues"
* tag 'usb-6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
net/9p/usbg: Fix build error
USB: yurex: kill needless initialization in yurex_read
Revert "usb: yurex: Replace snprintf() with the safer scnprintf() variant"
usb: xhci: Fix problem with xhci resume from suspend
usb: misc: onboard_usb_dev: introduce new config symbol for usb5744 SMBus support
usb: dwc3: core: Stop processing of pending events if controller is halted
usb: dwc3: re-enable runtime PM after failed resume
usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip
usb: gadget: core: force synchronous registration
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This prevented the compiler from catching the patch
that broke the driver.
Signed-off-by: Oliver Neukum <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035.
This patch leads to passing 0 to simple_read_from_buffer()
as a fifth argument, turning the read method into a nop.
The change is fundamentally flawed, as it breaks the driver.
Signed-off-by: Oliver Neukum <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
support
Introduce new kernel config symbol for Microchip usb5744 SMBus programming
support. Since usb5744 i2c initialization routine uses i2c SMBus APIs these
APIs should only be invoked when kernel has I2C support. This new kernel
config describes the dependency on I2C kernel support and fix the below
build issues when USB_ONBOARD_DEV=y and CONFIG_I2C=m.
riscv64-linux-ld: drivers/usb/misc/onboard_usb_dev.o:
undefined reference to `i2c_find_device_by_fwnode'
drivers/usb/misc/onboard_usb_dev.c:408:(.text+0xb24): undefined
reference to `i2c_smbus_write_block_data'
<snip>
Parsing of the i2c-bus bus handle is not put under usb5744 kernel config
check as the intention is to report an error when DT is configured for
usb5744 SMBus support and kernel has USB_ONBOARD_DEV_USB5744 disabled.
Fixes: 6782311d04df ("usb: misc: onboard_usb_dev: add Microchip usb5744 SMBus programming support")
Signed-off-by: Radhey Shyam Pandey <[email protected]>
Suggested-by: Matthias Kaehlcke <[email protected]>
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Acked-by: Matthias Kaehlcke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
[Syzbot reported two possible deadlocks]
The first possible deadlock is:
WARNING: possible recursive locking detected
6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted
--------------------------------------------
syz-executor363/2651 is trying to acquire lock:
ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x15d/0x2c0 drivers/usb/misc/chaoskey.c:322
but task is already holding lock:
ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_release+0x7f/0x2c0 drivers/usb/misc/chaoskey.c:299
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(chaoskey_list_lock);
lock(chaoskey_list_lock);
*** DEADLOCK ***
The second possible deadlock is:
WARNING: possible circular locking dependency detected
6.12.0-rc1-syzkaller-00027-g4a9fe2a8ac53 #0 Not tainted
------------------------------------------------------
kworker/0:2/804 is trying to acquire lock:
ffffffff899dadb0 (minor_rwsem){++++}-{3:3}, at: usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186
but task is already holding lock:
ffffffff89b120e8 (chaoskey_list_lock){+.+.}-{3:3}, at: chaoskey_disconnect+0xa8/0x2a0 drivers/usb/misc/chaoskey.c:235
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (chaoskey_list_lock){+.+.}-{3:3}:
__mutex_lock_common kernel/locking/mutex.c:608 [inline]
__mutex_lock+0x175/0x9c0 kernel/locking/mutex.c:752
chaoskey_open+0xdd/0x220 drivers/usb/misc/chaoskey.c:274
usb_open+0x186/0x220 drivers/usb/core/file.c:47
chrdev_open+0x237/0x6a0 fs/char_dev.c:414
do_dentry_open+0x6cb/0x1390 fs/open.c:958
vfs_open+0x82/0x3f0 fs/open.c:1088
do_open fs/namei.c:3774 [inline]
path_openat+0x1e6a/0x2d60 fs/namei.c:3933
do_filp_open+0x1dc/0x430 fs/namei.c:3960
do_sys_openat2+0x17a/0x1e0 fs/open.c:1415
do_sys_open fs/open.c:1430 [inline]
__do_sys_openat fs/open.c:1446 [inline]
__se_sys_openat fs/open.c:1441 [inline]
__x64_sys_openat+0x175/0x210 fs/open.c:1441
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (minor_rwsem){++++}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3161 [inline]
check_prevs_add kernel/locking/lockdep.c:3280 [inline]
validate_chain kernel/locking/lockdep.c:3904 [inline]
__lock_acquire+0x250b/0x3ce0 kernel/locking/lockdep.c:5202
lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5825
down_write+0x93/0x200 kernel/locking/rwsem.c:1577
usb_deregister_dev+0x7c/0x1e0 drivers/usb/core/file.c:186
chaoskey_disconnect+0xb7/0x2a0 drivers/usb/misc/chaoskey.c:236
usb_unbind_interface+0x1e8/0x970 drivers/usb/core/driver.c:461
device_remove drivers/base/dd.c:569 [inline]
device_remove+0x122/0x170 drivers/base/dd.c:561
__device_release_driver drivers/base/dd.c:1273 [inline]
device_release_driver_internal+0x44a/0x610 drivers/base/dd.c:1296
bus_remove_device+0x22f/0x420 drivers/base/bus.c:576
device_del+0x396/0x9f0 drivers/base/core.c:3864
usb_disable_device+0x36c/0x7f0 drivers/usb/core/message.c:1418
usb_disconnect+0x2e1/0x920 drivers/usb/core/hub.c:2304
hub_port_connect drivers/usb/core/hub.c:5361 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5661 [inline]
port_event drivers/usb/core/hub.c:5821 [inline]
hub_event+0x1bed/0x4f40 drivers/usb/core/hub.c:5903
process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229
process_scheduled_works kernel/workqueue.c:3310 [inline]
worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391
kthread+0x2c1/0x3a0 kernel/kthread.c:389
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(chaoskey_list_lock);
lock(minor_rwsem);
lock(chaoskey_list_lock);
lock(minor_rwsem);
*** DEADLOCK ***
[Analysis]
The first is AA lock, it because wrong logic, it need a unlock.
The second is AB lock, it needs to rearrange the order of lock usage.
Fixes: 422dc0a4d12d ("USB: chaoskey: fail open after removal")
Reported-by: [email protected]
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=685e14d04fe35692d3bc
Signed-off-by: Edward Adam Davis <[email protected]>
Tested-by: [email protected]
Reported-by: [email protected]
Tested-by: [email protected]
Tested-by: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Cc: Oliver Neukum <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
chaoskey_open() takes the lock only to increase the
counter of openings. That means that the mutual exclusion
with chaoskey_disconnect() cannot prevent an increase
of the counter and chaoskey_open() returning a success.
If that race is hit, chaoskey_disconnect() will happily
free all resources associated with the device after
it has dropped the lock, as it has read the counter
as zero.
To prevent this race chaoskey_open() has to check
the presence of the device under the lock.
However, the current per device lock cannot be used,
because it is a part of the data structure to be
freed. Hence an additional global mutex is needed.
The issue is as old as the driver.
Signed-off-by: Oliver Neukum <[email protected]>
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=422188bce66e76020e55
Fixes: 66e3e591891da ("usb: Add driver for Altus Metrum ChaosKey device (v2)")
Rule: add
Link: https://lore.kernel.org/stable/20241002132201.552578-1-oneukum%40suse.com
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The IO yurex_write() needs to wait for in order to have a device
ready for writing again can take a long time time.
Consequently the sleep is done in an interruptible state.
Therefore others waiting for yurex_write() itself to finish should
use mutex_lock_interruptible.
Signed-off-by: Oliver Neukum <[email protected]>
Fixes: 6bc235a2e24a5 ("USB: add driver for Meywa-Denki & Kayac YUREX")
Rule: add
Link: https://lore.kernel.org/stable/20240924084415.300557-1-oneukum%40suse.com
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
iowarrior_read() uses the iowarrior dev structure, but does not use any
lock on the structure. This can cause various bugs including data-races,
so it is more appropriate to use a mutex lock to safely protect the
iowarrior dev structure. When using a mutex lock, you should split the
branch to prevent blocking when the O_NONBLOCK flag is set.
In addition, it is unnecessary to check for NULL on the iowarrior dev
structure obtained by reading file->private_data. Therefore, it is
better to remove the check.
Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.")
Signed-off-by: Jeongjun Park <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/usb to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
Signed-off-by: Uwe Kleine-König <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
no_llseek had been defined to NULL two years ago, in commit 868941b14441
("fs: remove no_llseek")
To quote that commit,
At -rc1 we'll need do a mechanical removal of no_llseek -
git grep -l -w no_llseek | grep -v porting.rst | while read i; do
sed -i '/\<no_llseek\>/d' $i
done
would do it.
Unfortunately, that hadn't been done. Linus, could you do that now, so
that we could finally put that thing to rest? All instances are of the
form
.llseek = no_llseek,
so it's obviously safe.
Signed-off-by: Al Viro <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The write code path touches the bbu member in a non atomic manner
without taking the spinlock. Fix it.
The bug is as old as the driver.
Signed-off-by: Oliver Neukum <[email protected]>
CC: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As we process the second byte of a control transfer, transfers
of less than 2 bytes must be discarded.
This bug is as old as the driver.
SIgned-off-by: Oliver Neukum <[email protected]>
CC: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a small window during probing when IO is running
but the backlight is not registered. Processing events
during that time will crash. The completion handler
needs to check for a backlight before scheduling work.
The bug is as old as the driver.
Signed-off-by: Oliver Neukum <[email protected]>
CC: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
usb5744 supports SMBus Configuration and it may be configured via the
SMBus slave interface during the hub start-up configuration stage.
To program it driver uses i2c-bus phandle (added in commit '02be19e914b8
dt-bindings: usb: Add support for Microchip usb5744 hub controller') to
get i2c client device and then based on usb5744 compatible check calls
usb5744 i2c default initialization sequence.
Apart from the USB command attach, prevent the hub from suspend.
when the USB Attach with SMBus (0xAA56) command is issued to the hub,
the hub is getting enumerated and then it puts in a suspend mode.
This causes the hub to NAK any SMBus access made by the SMBus Master
during this period and not able to see the hub's slave address while
running the "i2c probe" command.
Prevent the MCU from putting the HUB in suspend mode through register
write. The BYPASS_UDC_SUSPEND bit (Bit 3) of the RuntimeFlags2
register at address 0x411D controls this aspect of the hub. The
BYPASS_UDC_SUSPEND bit in register 0x411Dh must be set to ensure that the
MCU is always enabled and ready to respond to SMBus runtime commands.
This register needs to be written before the USB attach command is issued.
The byte sequence is as follows:
Slave addr: 0x2d 00 00 05 00 01 41 1D 08
Slave addr: 0x2d 99 37 00
Slave addr: 0x2d AA 56 00
Also since usb5744 i2c initialization routine uses i2c SMBus APIs invoke
these APIs only when i2c driver is enabled in the kernel configuration.
Signed-off-by: Radhey Shyam Pandey <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce dedicated field 'power_on_delay_us' in onboard platform data
and update its delay for USB5744 configuration. Hub itself requires some
delay after reset to get to state where configuration data is going to
be accepted. Without delay upcoming support for configuration via SMBUS
is reporting a failure on the first SMBus write.
i2c 2-002d: error -ENXIO: BYPASS_UDC_SUSPEND bit configuration failed
Similar delay is likely also required for default configuration but
because there is enough time (code execution) between reset and usage
of the hub any issue is not visible but it doesn't mean delay shouldn't
be reflected.
Signed-off-by: Radhey Shyam Pandey <[email protected]>
Suggested-by: Matthias Kaehlcke <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
based on the alias from of_device_id table.
Signed-off-by: Liao Chen <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |\
| |
| |
| |
| |
| | |
We need the usb / thunderbolt fixes in here as well.
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add LJCA GPIO support for the Lunar Lake platform.
New HID taken from out of tree ivsc-driver git repo.
Link: https://github.com/intel/ivsc-driver/commit/47e7c4a446c8ea8c741ff5a32fa7b19f9e6fd47e
Cc: stable <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bindings require two compatibles to be used: qcom,sc7280-eud
followed by fallback qcom,eud. The convention is to use fallback
compatible in OF device ID tables, unless some device-specific quirks
are needed.
This will also simplify matching any new devices - they will use
existing OF device ID entry, instead of adding a new one.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The of_property_for_each_u32() macro needs five parameters, two of which
are primarily meant as internal variables for the macro itself (in the
for() clause). Yet these two parameters are used by a few drivers, and this
can be considered misuse or at least bad practice.
Now that the kernel uses C11 to build, these two parameters can be avoided
by declaring them internally, thus changing this pattern:
struct property *prop;
const __be32 *p;
u32 val;
of_property_for_each_u32(np, "xyz", prop, p, val) { ... }
to this:
u32 val;
of_property_for_each_u32(np, "xyz", val) { ... }
However two variables cannot be declared in the for clause even with C11,
so declare one struct that contain the two variables we actually need. As
the variables inside this struct are not meant to be used by users of this
macro, give the struct instance the noticeable name "_it" so it is visible
during code reviews, helping to avoid new code to use it directly.
Most usages are trivially converted as they do not use those two
parameters, as expected. The non-trivial cases are:
- drivers/clk/clk.c, of_clk_get_parent_name(): easily doable anyway
- drivers/clk/clk-si5351.c, si5351_dt_parse(): this is more complex as the
checks had to be replicated in a different way, making code more verbose
and somewhat uglier, but I refrained from a full rework to keep as much
of the original code untouched having no hardware to test my changes
All the changes have been build tested. The few for which I have the
hardware have been runtime-tested too.
Reviewed-by: Andre Przywara <[email protected]> # drivers/clk/sunxi/clk-simple-gates.c, drivers/clk/sunxi/clk-sun8i-bus-gates.c
Acked-by: Bartosz Golaszewski <[email protected]> # drivers/gpio/gpio-brcmstb.c
Acked-by: Nicolas Ferre <[email protected]> # drivers/irqchip/irq-atmel-aic-common.c
Acked-by: Jonathan Cameron <[email protected]> # drivers/iio/adc/ti_am335x_adc.c
Acked-by: Uwe Kleine-König <[email protected]> # drivers/pwm/pwm-samsung.c
Acked-by: Richard Leitner <[email protected]> # drivers/usb/misc/usb251xb.c
Acked-by: Mark Brown <[email protected]> # sound/soc/codecs/arizona.c
Reviewed-by: Richard Fitzgerald <[email protected]> # sound/soc/codecs/arizona.c
Acked-by: Michael Ellerman <[email protected]> # arch/powerpc/sysdev/xive/spapr.c
Acked-by: Stephen Boyd <[email protected]> # clk
Signed-off-by: Luca Ceresoli <[email protected]>
Acked-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Rob Herring (Arm) <[email protected]>
|