Re: [PATCH] usbip: Fix vep_free_request() null pointer checks on input args

On Tue, Jan 22, 2019 at 04:05:28PM -0700, shuah wrote: > On 1/19/19 1:17 AM, Greg KH wrote: > > On Fri, Jan 18, 2019 at 02:29:30PM -0700, Shuah Khan wrote: > > > From: Shuah Khan > > > > > > Fix vep_free_request() to return when usb_ep and usb_request are null > > > instead of calling WARN_ON. >

Re: [PATCH 1/4] tty: sisusb_con, convert addr macros to functions

On Tue, Jan 22, 2019 at 04:26:12PM +0100, Jiri Slaby wrote: > On 22. 01. 19, 16:23, Greg KH wrote: > > On Tue, Jan 22, 2019 at 04:11:59PM +0100, Jiri Slaby wrote: > >> Convert SISUSB_VADDR and SISUSB_HADDR to inline functions. Now, there > >> are no more hidden accesses to local variables (vc_data

Re: [PATCH 8/8] net: macb: add sam9x60-macb compatibility string

Hi David, On 16/01/2019 at 10:57, Nicolas Ferre wrote: > Add a new compatibility string for this product. It's using > at91sam9260-macb layout but has a newer hardware revision: it's safer > to use its own string. > > Signed-off-by: Nicolas Ferre I'm thinking of pushing this patch with the othe

Re: [PATCH] USB: serial: cp210x: support all gpios on CP2102N QFN28 package

On Thu, Jan 24, 2019 at 01:48:39PM +, Mans Rullgard wrote: > The QFN28 package version of the CP2102N has three additional gpio pins. > Add support for these. > > Signed-off-by: Mans Rullgard Thanks for investigating and enabling support for the remaining pins. Now applied. Johan

Re: [PATCH v3 04/10] usb: ehci-orion: add S2RAM support

Hi Alan, Alan Stern wrote on Wed, 23 Jan 2019 14:58:44 -0500 (EST): > On Mon, 21 Jan 2019, Miquel Raynal wrote: > > > Add suspend/resume callbacks to reset the host controller properly > > during S2RAM operation. > > > > Signed-off-by: Miquel Raynal > > --- > > drivers/usb/host/ehci-orion.c

[PATCH v4 02/10] usb: host: xhci: mvebu: add reset on resume quirk

From: Ofer Heifetz The mvebu xHCI host driver does not have suspend/resume support. Use of the XHCI_RESET_ON_RESUME quirk is mandatory in order to avoid failures after resume. This will work only if no USB device is plugged-in. While at it, mention in the Kconfig file that this IP is also presen

[PATCH v4 01/10] usb: core: comply to PHY framework

Current implementation of the USB core does not take into account the new PHY framework. Correct the situation by adding a call to phy_set_mode() before phy_power_on(). Signed-off-by: Miquel Raynal --- drivers/usb/core/hcd.c | 5 + drivers/usb/core/phy.c | 28 d

[PATCH v4 00/10] A3700 USB S2RAM support

Hello, As part of an effort to bring suspend to RAM support to Armada 3700 SoCs (main target: ESPRESSObin), this series handles the work around the USB2 and USB32 IPs. First, a change in the core adds support for the new PHY framework by following the phy_set_mode()/phy_power_on() sequence (patch

[PATCH v4 06/10] dt-bindings: phy: mvebu-utmi: add UTMI PHY bindings

Add bindings for Marvell Armada 3700 USB2 UTMI+ PHY. Signed-off-by: Miquel Raynal Reviewed-by: Rob Herring --- .../bindings/phy/phy-mvebu-utmi.txt | 38 +++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-mvebu-utmi.txt d

[PATCH v4 05/10] phy: add A3700 UTMI PHY driver

Marvell Armada 3700 SoC has two USB controllers, each of them being wired to an internal UTMI PHY. Add a driver to control them. Igal Liberman worked on supporting the PHY, I took the while 'register configuration' from his work and rewrote almost entirely the driver/bindings around it. Co-develo

[PATCH v4 03/10] usb: ehci-orion: avoid double PHY initialization

No need to initialize the PHY from the driver's probe. It is done by the core automatically and doing it twice would increment the phy->powercount counter to 2 instead of 1. During later suspend operation, the counter will be decremented to one, no phy->power_off() will occur and worse than that, t

[PATCH v4 07/10] MAINTAINERS: phy: fill Armada 3700 PHY drivers entry

Update the Armada 3700 PHY drivers entry with the recently added UTMI PHY driver. Signed-off-by: Miquel Raynal --- MAINTAINERS | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index abfd80f21b24..2a08a097e107 100644 --- a/MAINTAINERS +++ b/MAINTAIN

[PATCH v4 04/10] usb: ehci-orion: add S2RAM support

Add suspend/resume callbacks to reset the host controller properly during S2RAM operation. Signed-off-by: Miquel Raynal --- drivers/usb/host/ehci-orion.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c index 31

[PATCH v4 09/10] ARM64: dts: marvell: armada-37xx: declare USB2 UTMI PHYs

On Marvell Armada 3700 SoCs there are two USB2 UTMI PHYs. They are both very similar but only one has OTG/charging capabilities. Because there are USB host registers and PHY registers mixed in a single area, a system controller is also created and referenced from both the USB host node and the PHY

[PATCH v4 08/10] ARM64: dts: marvell: armada-37xx: fix USB2 memory region

The specification splits the USB2 memory region into three sections: 1/ 0xD005E000-0xD005EFFF: USB2 Host Controller Registers 2/ 0xD005F000-0xD005F7FF: USB2 UTMI PHY Registers 3/ 0xD005F800-0xD005: USB2 Host Miscellaneous Registers Section 1/ belongs to the USB2 node but section 2/ belongs to

[PATCH v4 10/10] ARM64: dts: marvell: armada-37xx: link USB hosts with their PHYs

Reference the PHY nodes from the USB controller nodes. The USB3 host controller is wired to: * the first PHY of the COMPHY IP * the OTG-capable UTMI PHY The USB2 host controller is wired to: * the host-only UTMI PHY Signed-off-by: Miquel Raynal --- arch/arm64/boot/dts/marvell/armada-37xx

Re: usb: dwc2: usb data transmitted to incorrect usb endpoint

Hi Minas, On Fri, Jan 25, 2019 at 2:54 AM Minas Harutyunyan wrote: > I not found yet where from come this bug. > > Meanwhile, could you please: > 1. Test same scenario in BDMA mode Sorry but I'm not familiar with BDMA mode. DId not find it in the Altera reference manual or inside the kernel doc

[PATCH 4/6] arm64: tegra: Add XUSB and pad controller on Tegra186

From: Thierry Reding Adds the XUSB pad and XUSB controllers on Tegra186. Signed-off-by: Thierry Reding --- arch/arm64/boot/dts/nvidia/tegra186.dtsi | 135 +++ 1 file changed, 135 insertions(+) diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvi

[PATCH 6/6] arm64: tegra: Remove regulator hacks on Jetson TX2

From: Thierry Reding Various regulators were marked as always-on for Jetson TX2. At this point, all of the regulators are properly hooked up, so this workaround is no longer required. Signed-off-by: Thierry Reding --- .../arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 23 --- 1 fi

[PATCH 2/6] usb: host: xhci-tegra: Selectively program IPFS

From: JC Kuo Starting with Tegra186, the XUSB controller no longer has the IPFS wrapper. This commit adds a "has_ipfs" field to struct tegra_xusb_soc that can be used to declare the existence of the IPFS wrapper. For the existing chips (i.e. Tegra124 and Tegra210), the new field is set to true.

[PATCH 1/6] dt-bindings: usb: xhci-tegra: Add Tegra186 support

From: Thierry Reding Extend the bindings to cover the set of features found in Tegra186. Signed-off-by: Thierry Reding --- .../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124

[PATCH 3/6] usb: host: xhci-tegra: Add Tegra186 XUSB support

From: JC Kuo This commit adds Tegra186 XUSB host mode controller support. This is very similar to the existing support for Tegra124 and Tegra210, except that the number of ports and PHYs differs and the IPFS wrapper being gone. Signed-off-by: JC Kuo Signed-off-by: Thierry Reding --- drivers/u

[PATCH 5/6] arm64: tegra: Enable XUSB on P2771

From: Thierry Reding Enable the relevant pads for XUSB support on P2771- and hook up the USB supply voltage regulators to the ports. Signed-off-by: Thierry Reding --- .../boot/dts/nvidia/tegra186-p2771-.dts | 115 ++ .../arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 19

Re: usb: dwc2: usb data transmitted to incorrect usb endpoint

Hi Maynard, On 1/25/2019 3:24 PM, Maynard Cabiente wrote: > Hi Minas, > > On Fri, Jan 25, 2019 at 2:54 AM Minas Harutyunyan > wrote: >> I not found yet where from come this bug. >> >> Meanwhile, could you please: >> 1. Test same scenario in BDMA mode > > Sorry but I'm not familiar with BDMA mo

[GIT PULL] USB driver fixes for 5.0-rc4

The following changes since commit 1c7fc5cbc33980acd13d668f1c8f0313d6ae9fd8: Linux 5.0-rc2 (2019-01-14 10:41:12 +1200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.0-rc4 for you to fetch changes up to 4f9b838927812b5949a9899

Re: [PATCH v1 07/12] usb: roles: Find the usb role switch by also matching against the device node

On Mon, Jan 21, 2019 at 03:51:35PM +0200, Heikki Krogerus wrote: > Hi, > > On Mon, Jan 21, 2019 at 04:36:13PM +0800, Chen Yu wrote: > > Have the fwnode_get_name() patches been accepted? > > No, I didn't have a user for the function anymore: > https://lkml.org/lkml/2018/12/17/284 > > > And I will

[PATCH 7/8] device connection: Prepare support for firmware described connections

When the connections are defined in firmware, struct device_connection will have the fwnode member pointing to the device node (struct fwnode_handle) of the requested device. The endpoint member for the device names will not be used at all in that case. Signed-off-by: Heikki Krogerus --- drivers

[PATCH 4/8] usb: typec: mux: Find the muxes by also matching against the device node

When the connections are defined in firmware, struct device_connection will have the fwnode member pointing to the device node (struct fwnode_handle) of the requested device, and the endpoint will not be used at all in that case. Signed-off-by: Heikki Krogerus --- drivers/usb/typec/mux.c | 78 ++

[PATCH 2/8] usb: typec: Rationalize the API for the muxes

We can replace the second parameter that is passed to the typec_mux_get() function with alt mode description structure, and simply pass NULL with accessory modes. With accessory modes there is no need for additional identification (in practice the accessory mode can only be Audio Accessory if muxi

[PATCH 0/8] device connection: Add support for device graphs

Hi, This series adds support for OF and ACPI device graph parsing to the device connection API. Handling the graph is straightforward, but because I'm adding that fwnode member to struct device_connection, I had to make sure all the existing users consider it. The plan is to only support matchin

[PATCH 3/8] device connection: Add fwnode member to struct device_connection

This will prepare the device connection API for connections described in firmware. Signed-off-by: Heikki Krogerus --- include/linux/device.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/linux/device.h b/include/linux/device.h index 5663003a95eb..1fb077f5a936 100644 --- a/inc

[PATCH 1/8] platform/x86: intel_cht_int33fe: Remove connection for the alt mode mux

Driver for fusb302 does not support alternate modes, so the connection is not really needed for now. Removing that connection description allows us to improve the USB Type-C mux API. Signed-off-by: Heikki Krogerus --- drivers/platform/x86/intel_cht_int33fe.c | 11 --- 1 file changed, 4 i

[PATCH 8/8] device connection: Find device connections also from device graphs

If connections between devices are described in OF graph or ACPI device graph, we can find them by using the fwnode_graph_*() functions. Signed-off-by: Heikki Krogerus --- drivers/base/devcon.c | 39 --- 1 file changed, 36 insertions(+), 3 deletions(-) diff -

[PATCH 5/8] usb: roles: Find the muxes by also matching against the device node

When the connections are defined in firmware, struct device_connection will have the fwnode member pointing to the device node (struct fwnode_handle) of the requested device, and the endpoint will not be used at all in that case. Signed-off-by: Heikki Krogerus --- drivers/usb/roles/class.c | 21

[PATCH 6/8] usb: typec: Find the ports by also matching against the device node

When the connections are defined in firmware, struct device_connection will have the fwnode member pointing to the device node (struct fwnode_handle) of the requested device, and the endpoint will not be used at all in that case. Signed-off-by: Heikki Krogerus --- drivers/usb/typec/class.c | 24

Re: [PATCH 1/7] usb: typec: ucsi: add get_fw_info function

On Thu, Jan 24, 2019 at 05:45:48PM +, Ajay Gupta wrote: > Hi Heikki, > > > > Function is to get the details of ccg firmware and device version. > > > > > > Signed-off-by: Ajay Gupta > > > --- > > > drivers/usb/typec/ucsi/ucsi_ccg.c | 76 > > > ++- > > > 1 file cha

Re: [PATCH 2/7] usb: typec: ucsi: add ccg command framework

On Thu, Jan 24, 2019 at 07:15:35PM +, Ajay Gupta wrote: > Hi Heikki > > > > Used to send command to ccg controller > > > > > > Signed-off-by: Ajay Gupta > > > --- > > > drivers/usb/typec/ucsi/ucsi_ccg.c | 252 > > > -- > > > 1 file changed, 243 insertions(+), 9 de

Re: [PATCH] usbip: Fix vep_free_request() null pointer checks on input args

On 1/25/19 1:02 AM, Greg KH wrote: On Tue, Jan 22, 2019 at 04:05:28PM -0700, shuah wrote: On 1/19/19 1:17 AM, Greg KH wrote: On Fri, Jan 18, 2019 at 02:29:30PM -0700, Shuah Khan wrote: From: Shuah Khan Fix vep_free_request() to return when usb_ep and usb_request are null instead of calling W

Re: [PATCH v3] usb: warm-reset ports on hub resume, if requested

On 18.01.2019 13:28, Jan-Marek Glogowski wrote: Just adding some CC of commit signers from get_maintainer.pl Am 16.01.19 um 18:07 schrieb Jan-Marek Glogowski: On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE link state bit is set. Greping all the kernel for this bit shows that the

Re: MUSB interrupt storm on device removal

On Thu, Jan 24, 2019 at 04:31:19PM +, Måns Rullgård wrote: > Bin Liu writes: > > > On Thu, Jan 24, 2019 at 12:56:33PM +, Måns Rullgård wrote: > >> Johan Hovold writes: > >> > >> > On Wed, Jan 23, 2019 at 08:50:38PM +, Måns Rullgård wrote: > >> >> Bin Liu writes: > >> >> > >> >> >>

[PATCH] usbip: Fix vep_free_request() null pointer checks on input args

Fix vep_free_request() to return when usb_ep and usb_request are null instead of calling WARN_ON. Signed-off-by: Shuah Khan --- drivers/usb/usbip/vudc_dev.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/usbip/vudc_dev.c b/drivers/usb/usbip/vudc_dev.c index 163

Re: [PATCH v3] usb: warm-reset ports on hub resume, if requested

Am 25.01.19 um 16:14 schrieb Mathias Nyman: > On 18.01.2019 13:28, Jan-Marek Glogowski wrote: >> Just adding some CC of commit signers from get_maintainer.pl >> >> Am 16.01.19 um 18:07 schrieb Jan-Marek Glogowski: >>> On plug-in of my USB-C device, its USB_SS_PORT_LS_SS_INACTIVE >>> link state bit

Re: [PATCH] usb: musb: Fix potential NULL dereference

On Wed, Jan 23, 2019 at 08:51:42PM +0300, Matwey V. Kornilov wrote: > We assign "urb->hcpriv = qh;" a few lines down. The valid qh for the urb is > hep->hcpriv in this code path. > > Fixes: 714bc5ef3eda ("musb: potential use after free") > Signed-off-by: Matwey V. Kornilov > --- > drivers/usb/mu

Re: [PATCH] usb: musb: Fix potential NULL dereference

On Thu, Jan 24, 2019 at 09:47:02PM +0300, Matwey V. Kornilov wrote: > By the way, why do we need to store the qh in urb->hcpriv? > qh can always be accessible through urb->ep->hcpriv > Wouldn't it be better to drop entire urb->hcpriv usage? I am not sure why. The code is there since the first comm

Re: [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic

On Mon, Jan 21, 2019 at 10:03:53AM +0200, Mike Rapoport wrote: > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > index ae34e3a..2c61ea4 100644 > --- a/arch/arm64/mm/numa.c > +++ b/arch/arm64/mm/numa.c > @@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64 > start_pfn, u6

RE: [PATCH 2/7] usb: typec: ucsi: add ccg command framework

Hi Heikki > > > > Used to send command to ccg controller > > > > > > > > Signed-off-by: Ajay Gupta > > > > --- > > > > drivers/usb/typec/ucsi/ucsi_ccg.c | 252 > > > > -- > > > > 1 file changed, 243 insertions(+), 9 deletions(-) > > > > > > > > diff --git a/drivers/usb

Re: [PATCH v2 06/21] memblock: memblock_phys_alloc_try_nid(): don't panic

On Fri, Jan 25, 2019 at 05:45:02PM +, Catalin Marinas wrote: > On Mon, Jan 21, 2019 at 10:03:53AM +0200, Mike Rapoport wrote: > > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > > index ae34e3a..2c61ea4 100644 > > --- a/arch/arm64/mm/numa.c > > +++ b/arch/arm64/mm/numa.c > > @@ -237,

Re: [PATCH] usb: musb: Fix potential NULL dereference

On Fri, 25 Jan 2019, Bin Liu wrote: > On Thu, Jan 24, 2019 at 09:47:02PM +0300, Matwey V. Kornilov wrote: > > By the way, why do we need to store the qh in urb->hcpriv? > > qh can always be accessible through urb->ep->hcpriv > > Wouldn't it be better to drop entire urb->hcpriv usage? > > I am not

XHCI ISSUE: xhci_hcd: disabling already-disabled device

Hi Greg, we run weekly 48-hour S3/S2idle stress tests on each release candidate, and I found a single instance (out of 2794 runs) of this warning on the Lenovo Yoga 920 with linux 5.0.0-rc2 running S3 suspend/resume. I noticed a similar issue in bugzilla and you commented that these issues should

Re: [GIT PULL] USB driver fixes for 5.0-rc4

The pull request you sent on Fri, 25 Jan 2019 13:22:21 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git tags/usb-5.0-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b48cef32b6a5103dddf52aadbeda90ab0f7ef673 Thank you! -- Deet-doot-dot, I am a

Re: [PATCH v4 04/10] usb: ehci-orion: add S2RAM support

On Fri, 25 Jan 2019, Miquel Raynal wrote: > Add suspend/resume callbacks to reset the host controller properly > during S2RAM operation. > > Signed-off-by: Miquel Raynal > --- > drivers/usb/host/ehci-orion.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/u

Re: usb: dwc2: usb data transmitted to incorrect usb endpoint

Hi Minas, On Fri, Jan 25, 2019 at 2:54 AM Minas Harutyunyan wrote: > Besides, mentioned by you timestamp <23.918 564 900>, where BULK IN data > messed between EP1IN and EP2IN, I found in USB trace one more invalid > traffic packets sequence. See in trace at timestamp <24.169 347 217>: on > same E