Running the driver through kasan gives an interesting splat:
BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c
Read of size 20 at addr f1db2e64 by task swapper/0/1
(...)
isp1760_register from isp1760_plat_probe+0x1d8/0x220
(...)
This happens because the loop reading the regmap fields for the
different ISP1760 variants look like this:
for (i = 0; i < HC_FIELD_MAX; i++) { ... }
Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long.
However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[],
isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are
dynamically sized during compilation.
Fix this by putting an empty assignment to the [HC_FIELD_MAX]
and [DC_FIELD_MAX] array member at the end of each array.
This will make the array one member longer than it needs to be,
but avoids the risk of overwriting whatever is inside
[HC_FIELD_MAX - 1] and is simple and intuitive to read. Also
add comments explaining what is going on.
Fixes: 1da9e1c068 ("usb: isp1760: move to regmap for register access")
Cc: stable@vger.kernel.org
Cc: Rui Miguel Silva <rui.silva@linaro.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Reviewed-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220516091424.391209-1-linus.walleij@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The support for xHCI controllers with only one roothub, and the code
to defer primary roothub registation until second roothub got merged
to usb-next for 5.19 at the same time.
commit 873f323618 ("xhci: prepare for operation w/o shared hcd")
commit b7a4f9b5d0 ("xhci: Set HCD flag to defer primary roothub
registration")
These got merged in such a way that the flag to defer primary roothub
registration is set even for xHC controllers with just one roothub.
Fix this by setting the defer flag in a codepath taken only if we have
two roothubs
Fixes: 873f323618 ("xhci: prepare for operation w/o shared hcd")
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220516094850.19788-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This includes following Thunderbolt/USB4 changes for the v5.19 merge
window:
* Improvements for Thunderbolt 1 DisplayPort tunneling
* Link USB4 ports to their USB Type-C connectors
* Lane bonding support for host-to-host (XDomain) connections
* Buffer allocation improvement for devices with no DisplayPort
adapters
* Few cleanups and minor fixes.
All these have been in linux-next with no reported issues except that
there is a minor merge conflict with the kunit-next tree because one of
the commits touches the driver KUnit tests.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmKDb1UgHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKCU8hAAlsj3PujQLBIt
51KiwFV7P0DG8eiDUhAqYYFn4P49z0T5LPEYsyrfDoX9NjwYe+As/PaPNhgSCWMk
nEEhH2iepJILzfDrDML+JQEn+3UhdIfISgtzaNodNqHbpppFWoYKHrB5x5lacg42
u0HWt954deMw9tVnWJRHmP8jhxp1anvJd+ZNq+xwLdem10y0Cd0ta1cFWZvCsQ+U
LHTxv2NOK+2AntLyii8tJ85KgmnFzEhh4N8ckjgnb2pbzqx9jtYP5s3UoUIoY9NP
obAy84Rknpevug3lFF7oyBDsYD3Nonxno8MLNybIG4/iKtAGAZN3NS4vtY66invQ
fIu1ZzNvsaj3K/VG3GRJq4gCXE4o0Vv0Njmh53tQxtL4KaHzMkP9LeuBORtWG6Ku
zPwH1sYPwqorsh+CmYHaztUy+uVKhZ7pk2RU2QoKXpRnfXrOs8+iFwvjWiCmZwU5
CE+M+ClbNAfZECFFctMq8uq9RGG58guTG814Zgr8oqUMNU3mnE7E8caRc9l5sx5Z
Jeruo3Fba99Q6KhheGqM7yRzbLvMymqWlyAus1j51MWdbYoMJkMdXR/CFCG12Ee9
MR6wqWCK5rSR47v0/1HEZZ0TJutMzUm4Bm3OVswBB25DDbxWeC5vy2hXzRiT6vDJ
9R6ozF6efuR0nfSvuknoL9N3x/jM/QQ=
=gccx
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v5.19 merge window
This includes following Thunderbolt/USB4 changes for the v5.19 merge
window:
* Improvements for Thunderbolt 1 DisplayPort tunneling
* Link USB4 ports to their USB Type-C connectors
* Lane bonding support for host-to-host (XDomain) connections
* Buffer allocation improvement for devices with no DisplayPort
adapters
* Few cleanups and minor fixes.
All these have been in linux-next with no reported issues except that
there is a minor merge conflict with the kunit-next tree because one of
the commits touches the driver KUnit tests.
* tag 'thunderbolt-for-v5.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Add KUnit test for devices with no DisplayPort adapters
thunderbolt: Fix buffer allocation of devices with no DisplayPort adapters
thunderbolt: Add support for XDomain lane bonding
thunderbolt: Ignore port locked error in tb_port_wait_for_link_width()
thunderbolt: Split setting link width and lane bonding into own functions
thunderbolt: Move tb_port_state() prototype to correct place
thunderbolt: Add debug logging when lane is enabled/disabled
thunderbolt: Link USB4 ports to their USB Type-C connectors
misc/mei: Add NULL check to component match callback functions
thunderbolt: Use different lane for second DisplayPort tunnel
thunderbolt: Dump path config space entries during discovery
thunderbolt: Use decimal number with port numbers
thunderbolt: Fix typo in comment
thunderbolt: Replace usage of found with dedicated list iterator variable
Alder Lake N TCSS xHCI needs to be runtime suspended whenever possible
to allow the TCSS hardware block to enter D3 and thus save energy
Cc: stable@kernel.org
Suggested-by: Gopal Vamshi Krishna <vamshi.krishna.gopal@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-10-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The XHCI_RESET_EP_QUIRK was added in 2009 to support prototype xHC
hardware from Fresco Logic that needed an additional configure endpoint
command after a reset endpoint.
That hardware should not have made it to the market.
Now, 13 years later its about time we get rid of it.
quirk was added in commit ac9d8fe7c6 ("USB: xhci: Add quirk for Fresco
Logic xHCI hardware.")
Print a debug message about the removed quirk if against all odds we run
into this controller.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-9-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't enable U1 or U2 Link powermanagenet (LPM) states for USB3
devices connected to tier 2 or further hubs.
For unknown reasons we previously only prevented U1.
Be consistent, and prevent both U1/U2 states if tier policy doesn't
allow LPM.
Also check the tier policy a bit earlier, and return if U1/U2 is
not allowed. This avoids unnecessary xhci MEL commands.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-8-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 'stop endpoint' command timer was started when a 'stop endpoint'
command was added to the command queue.
This can trigger unwanted timeouts if there are several pending commands
in the queue that xHC needs to handle first.
The generic command timer, which was added later than the 'stop endpoint'
timeout timer, times each command currently being handled by xHC hardware.
A timed out stop endpoint command was treated as a more severe issue than
other failed commands, so the separate stop endpoint timer was left
unchanged.
Use the generic command timer for stop endpoint commands. Identify if
the timed out command was a stop endpoint command in the generic handler,
and treat it with the same severity as earlier.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-7-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Activate the just added extension for xhci-plat and omit the shared
hcd if either of the root hubs has no ports.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch prepares xhci-plat for the following scenario
- If either of the root hubs has no ports, then omit shared hcd
- Main hcd can be USB3 if there are no USB2 ports
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-5-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is in preparation of an extension where in case of a
root hub with no ports no shared hcd will be created.
Whether one of the root hubs has no ports we figure our in
usb_add_hcd() for the primary hcd. Therefore create the shared hcd
only after this call.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch prepares xhci for the following scenario:
- If either of the root hubs has no ports, then omit shared hcd
- Main hcd can be USB3 if there are no USB2 ports
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Factoring out parts of xhci_gen_setup() has two motivations:
- When adding functionaliy to omit shared hcd if not needed in a
subsequent patch, we'll have to call xhci_hcd_init_usb3_data()
from two places.
- It reduces size of xhci_gen_setup() and makes it better readable.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20220511220450.85367-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Set "HCD_FLAG_DEFER_RH_REGISTER" to hcd->flags in xhci_run() to defer
registering primary roothub in usb_add_hcd() if xhci has two roothubs.
This will make sure both primary roothub and secondary roothub will be
registered along with the second HCD.
This is required for cold plugged USB devices to be detected in certain
PCIe USB cards (like Inateck USB card connected to AM64 EVM or J7200 EVM).
This patch has been added and reverted earier as it triggered a race
in usb device enumeration.
That race is now fixed in 5.16-rc3, and in stable back to 5.4
commit 6cca13de26 ("usb: hub: Fix locking issues with address0_mutex")
commit 6ae6dc22d2 ("usb: hub: Fix usb enumeration issue due to address0
race")
[minor rebase change, and commit message update -Mathias]
CC: stable@vger.kernel.org # 5.4+
Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Tested-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20220510091630.16564-3-kishon@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It has been observed with certain PCIe USB cards (like Inateck connected
to AM64 EVM or J7200 EVM) that as soon as the primary roothub is
registered, port status change is handled even before xHC is running
leading to cold plug USB devices not detected. For such cases, registering
both the root hubs along with the second HCD is required. Add support for
deferring roothub registration in usb_add_hcd(), so that both primary and
secondary roothubs are registered along with the second HCD.
This patch has been added and reverted earier as it triggered a race
in usb device enumeration.
That race is now fixed in 5.16-rc3, and in stable back to 5.4
commit 6cca13de26 ("usb: hub: Fix locking issues with address0_mutex")
commit 6ae6dc22d2 ("usb: hub: Fix usb enumeration issue due to address0
race")
CC: stable@vger.kernel.org # 5.4+
Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Tested-by: Chris Chiu <chris.chiu@canonical.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20220510091630.16564-2-kishon@ti.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch resolves kernel-doc warnings to add return value description
in function comments.
Addressed warnings:
drivers/usb/host/ehci-xilinx-of.c:37: warning: No description found for return value of 'ehci_xilinx_port_handed_over'
drivers/usb/host/ehci-xilinx-of.c:117: warning: No description found for return value of 'ehci_hcd_xilinx_of_probe'
drivers/usb/host/ehci-xilinx-of.c:201: warning: No description found for return value of 'ehci_hcd_xilinx_of_remove'
Signed-off-by: Piyush Mehta <piyush.mehta@xilinx.com>
Link: https://lore.kernel.org/r/20220509170252.28271-1-piyush.mehta@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch removes the unused variables assignment warning.
Value assigned to variable bufferspace is overwritten, before
it can be used. This makes such variable assignment useless.
Reported Coverity warning: UNUSED_VALUE
Signed-off-by: Piyush Mehta <piyush.mehta@xilinx.com>
Link: https://lore.kernel.org/r/20220506175349.10102-1-piyush.mehta@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch resolves checkpatch warnings for xilinx EHCI driver.
Addressed warnings:
WARNING: quoted string split across lines
50: FILE: drivers/usb/host/ehci-xilinx-of.c:50:
+ "The USB host controller does not support full speed "
+ "nor low speed devices\n");
WARNING: quoted string split across lines
53: FILE: drivers/usb/host/ehci-xilinx-of.c:53:
+ "You can reconfigure the host controller to have "
+ "full speed support\n");
Signed-off-by: Piyush Mehta <piyush.mehta@xilinx.com>
Link: https://lore.kernel.org/r/20220510132252.26001-1-piyush.mehta@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a KUnit test to check that buffer allocation works also for devices
with no DP adapters.
Signed-off-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
For the case of a device without DisplayPort adapters we calculate
incorrectly the amount of buffers. Fix the calculation for this case.
Signed-off-by: Gil Fine <gil.fine@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Putting USB gadgets on a new bus of their own encounters a problem
when multiple gadgets are present: They all have the same name! The
driver core fails with a "sys: cannot create duplicate filename" error
when creating any of the /sys/bus/gadget/devices/<gadget-name>
symbolic links after the first.
This patch fixes the problem by adding a ".N" suffix to each gadget's
name when the gadget is registered (where N is a unique ID number),
thus making the names distinct.
Reported-and-tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: fc274c1e99 ("USB: gadget: Add a new bus for gadgets")
Link: https://lore.kernel.org/r/YnqKAXKyp9Vq/pbn@rowland.harvard.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just like the header is tracking the formats in a linked list, in this
patch we track the frames in a linked list of the formats. It
simplifies the parsing of the configfs structure.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220421211427.3400834-6-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The functions and structs of the configfs interface should also be used
by the uvc gadget driver. This patch prepares the stack by moving the
common structs and functions to the common header file.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220421211427.3400834-5-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some configfs variables like bDefaultFrameIndex are always starting by
1. This patch adds a check to prevent setting those variables to 0.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220421211427.3400834-4-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Align DWC3 USB node names with DT schema ("usb" is expected) and correct
the unit addresses to match the "reg" property. This also implies
overriding nodes by label, instead of full path.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220504131923.214367-7-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The bindings defined strict clocks but several variants do not use them
in such order. Split the clocks and clock-names per variants to match
current DTS usage. In few cases this might not be complete match, due
to incomplete DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220504131923.214367-5-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add compatibles for dedicated USB DWC3 blocks on Qualcomm IPQ8074,
MSM8994, QCS404 and SM6125. They differ against other variants in clock
and/or interrupts.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220504131923.214367-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the controller hasn't DMA'ed the Setup data from its fifo, it won't
process the End Transfer command. Polling for the command completion may
block the driver from servicing the Setup phase and cause a timeout.
Previously we only check and delay issuing End Transfer in the case of
endpoint dequeue. Let's do that for all End Transfer scenarios.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/2fcf3b5d90068d549589a57a27a79f76c6769b04.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver shouldn't be able to issue End Transfer to the control
endpoint at anytime. Typically we should only do so in error cases such
as invalid/unexpected direction of Data Phase as described in the
control transfer flow of the programming guide. It _may_ end started
data phase during controller deinitialization from soft disconnect or
driver removal. However, that should not happen because the driver
should be maintained in EP0_SETUP_PHASE during driver tear-down. On
soft-connect, the controller should be reset from a soft-reset and there
should be no issue starting the control endpoint.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/3c6643678863a26702e4115e9e19d7d94a30d49c.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since we can't guarantee that the host won't send new Setup packet
before going through the device-initiated disconnect, don't prepare
beyond the Setup stage and keep the device in EP0_SETUP_PHASE. This
ensures that the device-initated disconnect sequence can go through
gracefully. Note that the controller won't service the End Transfer
command if it can't DMA out the Setup packet.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/6bacec56ecabb2c6e49a09cedfcac281fdc97de0.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the GEVNTCOUNT indicates events in the event buffer, the driver needs
to acknowledge them before the controller can halt. Simply let the
interrupt handler acknowledges the remaining event generated by the
controller while polling for DSTS.DEVCTLHLT. This avoids disabling irq
and taking care of race condition between the interrupt handlers and
pullup().
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/ea306ec93c41ccafbdb5d16404ff3b6eca299613.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Don't do soft-disconnect if it's previously done. Likewise, don't do
soft-connect if the device is currently connected and running. It would
break normal operation.
Currently the caller of pullup() (udc's sysfs soft_connect) only checks
if it had initiated disconnect to prevent repeating soft-disconnect. It
doesn't check for soft-connect. To be safe, let's keep the check here
regardless whether the udc core is fixed.
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/1c1345bd66c97a9d32f77d63aaadd04b7b037143.1650593829.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch adds a USB GPIO based reset for dwc3-xilinx driver. The PHY
needs to be reset after the completion of phy initialization. As part
of the reset, check for gpio-reset binding before toggling the pin.
This feature is advantageous when the user toggle GPIO to trigger the
ULPI-PHY reset.
Delay of milliseconds is added in between low and high to meet the setup
and hold time requirement of the reset. The reset-gpio error handling is
added for error notification.
Some GPIO controllers must be accessed using message-based buses, like
I2C or SPI, to address this problem, updates GPIO access with sleep API.
This reset is specific to the zynqMp.
Signed-off-by: Piyush Mehta <piyush.mehta@xilinx.com>
Link: https://lore.kernel.org/r/20220504075309.6244-3-piyush.mehta@xilinx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The generic property, used in most of the drivers and defined in generic
dma-common DT bindings, is 'dma-channels'.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220503065201.51818-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The generic property, used in most of the drivers and defined in generic
dma-common DT bindings, is 'dma-channels'.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220503065201.51818-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is no longer needed. The sysdev pointer is now used when
assigning the ACPI companions to the xHCI ports and USB
devices.
Assigning the ACPI companion here resulted in the
fwnode->secondary pointer to be replaced also for the parent
dwc3 device since the primary fwnode (the ACPI companion)
was shared. That was unintentional and it created potential
side effects like resource leaks.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20220428111056.3558-3-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The controller device (hcd) does not always have the ACPI
companion assigned to it at all. We can not rely on it when
finding the ACPI companion for the root hub. Instead we need
to use the sysdev pointer.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20220428111056.3558-2-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add binding to support the mtu3 driver on the MT8195 SoC.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Macpaul Lin <macpaul.lin@mediatek.com>
Link: https://lore.kernel.org/r/20220426134106.242353-2-fparent@baylibre.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
