Re: wifi driver or USB might leads suspend/resume failure on thinkpad X1 carbon
On Mon, Mar 10, 2014 at 2:11 PM, Emmanuel Grumbach wrote: > Hi, > > On Mon, Mar 10, 2014 at 7:05 AM, Shuduo Sang wrote: >> Hi, >> >> Sorry for cross posting. I'm suffering an issue my Thinkpad X1 Carbon >> can't resume after suspend recently. I tried many ways including >> latest vanilla kernel, latest stable 3.13 and 3.11 kernel but it still >> happens. I found it will not happen when I turn off WIFI device or USB >> 3.0 in BIOS. So I suspect something need fix in either wifi driver or >> USB side. Since Windows 7 works good so I suppose no hardware issue. >> Anyone has some ideas to fix it or debug it? >> >> Thanks, >> Shuduo >> > > If you disable WiFi only (without touching USB 3.0 in BIOS), it works? > How do you disable WiFi? Rfkill or removing iwlwifi? > I have disabled WIFI device in BIOS, then its suspend/resume works. >> >> lspci -vnn output: >> .. >> sniped >> .. >> 00:1d.0 USB controller: Intel Corporation Lynx Point-LP USB EHCI #1 >> (rev 04) (prog-if 20 [EHCI]) >> Subsystem: Lenovo Device 2218 >> Flags: bus master, medium devsel, latency 0, IRQ 23 >> Memory at f052d000 (32-bit, non-prefetchable) [size=1K] >> Capabilities: [50] Power Management version 3 >> Capabilities: [58] Debug port: BAR=1 offset=00a0 >> Capabilities: [98] PCI Advanced Features >> Kernel driver in use: ehci-pci >> .. >> 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83) >> Subsystem: Intel Corporation Dual Band Wireless-AC 7260 >> Flags: bus master, fast devsel, latency 0, IRQ 59 >> Memory at f040 (64-bit, non-prefetchable) [size=8K] >> Capabilities: [c8] Power Management version 3 >> Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ >> Capabilities: [40] Express Endpoint, MSI 00 >> Capabilities: [100] Advanced Error Reporting >> Capabilities: [140] Device Serial Number 7c-7a-91-ff-ff-5e-4c-cd >> Capabilities: [14c] Latency Tolerance Reporting >> Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 >> Kernel driver in use: iwlwifi >> Kernel modules: iwlwifi >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: fix wrong port number reported when setting USB2.0 hardware LPM.
This patch fix wrong port number reported when trying to enable/disable USB2.0 hardware LPM. Signed-off-by: Lin Wang --- drivers/usb/host/xhci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 6fe577d..972f00d 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4064,7 +4064,7 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd, field = le32_to_cpu(udev->bos->ext_cap->bmAttributes); xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", - enable ? "enable" : "disable", port_num); + enable ? "enable" : "disable", port_num + 1); if (enable) { /* Host supports BESL timeout instead of HIRD */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] r8152: add skb_cow_head
Call skb_cow_head() before editing the tx packet header. The header would be reallocated if it is shared. Signed-off-by: Hayes Wang --- drivers/net/usb/r8152.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index c7ef30d..faad39b 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -1376,6 +1376,11 @@ static int msdn_giant_send_check(struct sk_buff *skb) { const struct ipv6hdr *ipv6h; struct tcphdr *th; + int ret; + + ret = skb_cow_head(skb, 0); + if (ret) + goto out1; ipv6h = ipv6_hdr(skb); th = tcp_hdr(skb); @@ -1383,7 +1388,8 @@ static int msdn_giant_send_check(struct sk_buff *skb) th->check = 0; th->check = ~tcp_v6_check(0, &ipv6h->saddr, &ipv6h->daddr, 0); - return 0; +out1: + return ret; } static int r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, @@ -1412,8 +1418,11 @@ static int r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc, break; case htons(ETH_P_IPV6): + if (msdn_giant_send_check(skb)) { + ret = TX_CSUM_TSO; + goto unavailable; + } opts1 |= GTSENDV6; - msdn_giant_send_check(skb); break; default: -- 1.8.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wifi driver or USB might leads suspend/resume failure on thinkpad X1 carbon
Hi, On Mon, Mar 10, 2014 at 7:05 AM, Shuduo Sang wrote: > Hi, > > Sorry for cross posting. I'm suffering an issue my Thinkpad X1 Carbon > can't resume after suspend recently. I tried many ways including > latest vanilla kernel, latest stable 3.13 and 3.11 kernel but it still > happens. I found it will not happen when I turn off WIFI device or USB > 3.0 in BIOS. So I suspect something need fix in either wifi driver or > USB side. Since Windows 7 works good so I suppose no hardware issue. > Anyone has some ideas to fix it or debug it? > > Thanks, > Shuduo > If you disable WiFi only (without touching USB 3.0 in BIOS), it works? How do you disable WiFi? Rfkill or removing iwlwifi? > > lspci -vnn output: > .. > sniped > .. > 00:1d.0 USB controller: Intel Corporation Lynx Point-LP USB EHCI #1 > (rev 04) (prog-if 20 [EHCI]) > Subsystem: Lenovo Device 2218 > Flags: bus master, medium devsel, latency 0, IRQ 23 > Memory at f052d000 (32-bit, non-prefetchable) [size=1K] > Capabilities: [50] Power Management version 3 > Capabilities: [58] Debug port: BAR=1 offset=00a0 > Capabilities: [98] PCI Advanced Features > Kernel driver in use: ehci-pci > .. > 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83) > Subsystem: Intel Corporation Dual Band Wireless-AC 7260 > Flags: bus master, fast devsel, latency 0, IRQ 59 > Memory at f040 (64-bit, non-prefetchable) [size=8K] > Capabilities: [c8] Power Management version 3 > Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [40] Express Endpoint, MSI 00 > Capabilities: [100] Advanced Error Reporting > Capabilities: [140] Device Serial Number 7c-7a-91-ff-ff-5e-4c-cd > Capabilities: [14c] Latency Tolerance Reporting > Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 > Kernel driver in use: iwlwifi > Kernel modules: iwlwifi > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/9] ARM: dts: i.MX51: Add a second usbphy.
> > > > > > > > > > > > diff --git a/arch/arm/boot/dts/imx51.dtsi > > > > > b/arch/arm/boot/dts/imx51.dtsi index e508e6f..917b6ed 100644 > > > > > --- a/arch/arm/boot/dts/imx51.dtsi > > > > > +++ b/arch/arm/boot/dts/imx51.dtsi > > > > > @@ -100,6 +100,13 @@ > > > > > clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > > > > clock-names = "main_clk"; > > > > > }; > > > > > + > > > > > + usbphy1: usbphy@1 { > > > > > + compatible = "usb-nop-xceiv"; > > > > > + reg = <1>; > > > > > + clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > > > > + clock-names = "main_clk"; > > > > > + }; > > > > > > > > Is this the ulpi phy for host1 controller? Why the clock is the > > > > same with utmi phy clock for otg controller. > > > > > > As far as I know, for i.MX51 this is as it should be. > > > > > > > Are you sure? From clock file, they are different ccm clock gate. > > clk-imx51-imx53.c ? I think you confuse with i.MX50/53. > Yes 341 clk[IMX5_CLK_USB_PHY1_GATE] = imx_clk_gate2("usb_phy1_gate", "usb_phy_sel", MXC_CCM_CCGR4, 10); 342 clk[IMX5_CLK_USB_PHY2_GATE] = imx_clk_gate2("usb_phy2_gate", "usb_phy_sel", MXC_CCM_CCGR4, 12);
Re: [PATCH 2/9] ARM: dts: i.MX51: Add a second usbphy.
Понедельник, 10 марта 2014, 5:50 UTC от Peter Chen : > > > > > > > > > diff --git a/arch/arm/boot/dts/imx51.dtsi > > > > b/arch/arm/boot/dts/imx51.dtsi index e508e6f..917b6ed 100644 > > > > --- a/arch/arm/boot/dts/imx51.dtsi > > > > +++ b/arch/arm/boot/dts/imx51.dtsi > > > > @@ -100,6 +100,13 @@ > > > > clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > > > clock-names = "main_clk"; > > > > }; > > > > + > > > > + usbphy1: usbphy@1 { > > > > + compatible = "usb-nop-xceiv"; > > > > + reg = <1>; > > > > + clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > > > + clock-names = "main_clk"; > > > > + }; > > > > > > Is this the ulpi phy for host1 controller? Why the clock is the same > > > with utmi phy clock for otg controller. > > > > As far as I know, for i.MX51 this is as it should be. > > > > Are you sure? From clock file, they are different ccm clock gate. clk-imx51-imx53.c ? I think you confuse with i.MX50/53. ---
Re: [PATCH 1/9] usb: chipidea: usbmisc: Add USB Host support for i.MX25/i.MX35 CPUs
Hi Fabio, Le Sun, 9 Mar 2014 22:21:59 -0300, Fabio Estevam a écrit : > On Fri, Mar 7, 2014 at 2:04 PM, Denis Carikli wrote: > > > +static int usbmisc_imx25_init(struct imx_usbmisc_data *data) > > +{ > > + void __iomem *reg = NULL; > > This variable is not used and causes a warning. Please remove it. > > After applying this patch things go further when I boot with a USB > thumb connected to the USB Host1 port: > > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > usbcore: registered new interface driver usb-storage > 53ff4400.usb supply vbus not found, using dummy regulator > ci_hdrc ci_hdrc.0: EHCI Host Controller > ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 > ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 1 port detected > > > usb 1-1: new full-speed USB device number 2 using ci_hdrc > > (Not sure why it says full-speed device. When I connect the same > device to a PC it says high-speed) > because i.MX25 and i.MX35 only have a full speed phy on the host port. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/9] ARM: dts: i.MX51: Add a second usbphy.
> > > > > > diff --git a/arch/arm/boot/dts/imx51.dtsi > > > b/arch/arm/boot/dts/imx51.dtsi index e508e6f..917b6ed 100644 > > > --- a/arch/arm/boot/dts/imx51.dtsi > > > +++ b/arch/arm/boot/dts/imx51.dtsi > > > @@ -100,6 +100,13 @@ > > > clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > > clock-names = "main_clk"; > > > }; > > > + > > > + usbphy1: usbphy@1 { > > > + compatible = "usb-nop-xceiv"; > > > + reg = <1>; > > > + clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > > + clock-names = "main_clk"; > > > + }; > > > > Is this the ulpi phy for host1 controller? Why the clock is the same > > with utmi phy clock for otg controller. > > As far as I know, for i.MX51 this is as it should be. > Are you sure? From clock file, they are different ccm clock gate. > However, I doubt the usefulness of forcing "fsl,usbphy = <&usbphy1>" > below. > Yes, for ulpi phy, it should use ulpi phy driver (drivers/usb/phy/phy-ulpi.c), not generic phy driver. Peter N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
wifi driver or USB might leads suspend/resume failure on thinkpad X1 carbon
Hi, Sorry for cross posting. I'm suffering an issue my Thinkpad X1 Carbon can't resume after suspend recently. I tried many ways including latest vanilla kernel, latest stable 3.13 and 3.11 kernel but it still happens. I found it will not happen when I turn off WIFI device or USB 3.0 in BIOS. So I suspect something need fix in either wifi driver or USB side. Since Windows 7 works good so I suppose no hardware issue. Anyone has some ideas to fix it or debug it? Thanks, Shuduo lspci -vnn output: .. sniped .. 00:1d.0 USB controller: Intel Corporation Lynx Point-LP USB EHCI #1 (rev 04) (prog-if 20 [EHCI]) Subsystem: Lenovo Device 2218 Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at f052d000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 3 Capabilities: [58] Debug port: BAR=1 offset=00a0 Capabilities: [98] PCI Advanced Features Kernel driver in use: ehci-pci .. 03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 83) Subsystem: Intel Corporation Dual Band Wireless-AC 7260 Flags: bus master, fast devsel, latency 0, IRQ 59 Memory at f040 (64-bit, non-prefetchable) [size=8K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 7c-7a-91-ff-ff-5e-4c-cd Capabilities: [14c] Latency Tolerance Reporting Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1 Len=014 Kernel driver in use: iwlwifi Kernel modules: iwlwifi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: fix wrong port number reported when setting USB2.0 hardware LPM.
This patch fix wrong port number reported when trying to enable/disable USB2.0 hardware LPM. Signed-off-by: Lin Wang --- drivers/usb/host/xhci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 6fe577d..972f00d 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4064,7 +4064,7 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd, field = le32_to_cpu(udev->bos->ext_cap->bmAttributes); xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", - enable ? "enable" : "disable", port_num); + enable ? "enable" : "disable", port_num + 1); if (enable) { /* Host supports BESL timeout instead of HIRD */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] ARM: dts: i.MX35: Add USB support.
On Fri, Mar 07, 2014 at 06:04:20PM +0100, Denis Carikli wrote: > Signed-off-by: Denis Carikli > --- > arch/arm/boot/dts/imx35.dtsi | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi > index e59ccb4..1c15b56 100644 > --- a/arch/arm/boot/dts/imx35.dtsi > +++ b/arch/arm/boot/dts/imx35.dtsi > @@ -292,6 +292,15 @@ > status = "disabled"; > }; > > + usbphy0: usbphy@0 { > + compatible = "usb-nop-xceiv"; > + }; > + > + usbphy1: usbphy@1 { > + compatible = "usb-nop-xceiv"; > + }; > + > + Can we put these (also imx25.dtsi) in the same way that imx51.dtsi organizes it? Shawn > usbotg: usb@53ff4000 { > compatible = "fsl,imx35-usb", "fsl,imx27-usb"; > reg = <0x53ff4000 0x0200>; > @@ -299,6 +308,7 @@ > clocks = <&clks 9>, <&clks 73>, <&clks 28>; > clock-names = "ipg", "ahb", "per"; > fsl,usbmisc = <&usbmisc 0>; > + fsl,usbphy = <&usbphy0>; > status = "disabled"; > }; > > @@ -309,6 +319,7 @@ > clocks = <&clks 9>, <&clks 73>, <&clks 28>; > clock-names = "ipg", "ahb", "per"; > fsl,usbmisc = <&usbmisc 1>; > + fsl,usbphy = <&usbphy1>; > status = "disabled"; > }; > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] usb: chipidea: usbmisc: Add USB Host support for i.MX25/i.MX35 CPUs
Воскресенье, 9 марта 2014, 22:21 -03:00 от Fabio Estevam : > Hi Denis, > > On Fri, Mar 7, 2014 at 2:04 PM, Denis Carikli wrote: > > > +static int usbmisc_imx25_init(struct imx_usbmisc_data *data) > > +{ > > + void __iomem *reg = NULL; > > This variable is not used and causes a warning. Please remove it. > > After applying this patch things go further when I boot with a USB > thumb connected to the USB Host1 port: ... > (Not sure why it says full-speed device. When I connect the same > device to a PC it says high-speed) ... > (Then system hangs here). > > If I boot without the USB thumb connected, then I reach the prompt, > however after inserting the USB pen drive into USBH1 there is no > detection. > > Any ideas? Fabio, start with to make work USB port on your board in the bootloader. Then with the previous driver (ehci-mxc). Most likely problem is a wrong (or missing) clock. As I mentioned earlier, DTS has incorrect clock nodes. ---
Re: [PATCH 2/9] ARM: dts: i.MX51: Add a second usbphy.
Понедельник, 10 марта 2014, 8:52 +08:00 от Peter Chen : > On Fri, Mar 07, 2014 at 06:04:16PM +0100, Denis Carikli wrote: > > Signed-off-by: Denis Carikli > > --- > > arch/arm/boot/dts/imx51.dtsi |8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi > > index e508e6f..917b6ed 100644 > > --- a/arch/arm/boot/dts/imx51.dtsi > > +++ b/arch/arm/boot/dts/imx51.dtsi > > @@ -100,6 +100,13 @@ > > clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > clock-names = "main_clk"; > > }; > > + > > + usbphy1: usbphy@1 { > > + compatible = "usb-nop-xceiv"; > > + reg = <1>; > > + clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > > + clock-names = "main_clk"; > > + }; > > Is this the ulpi phy for host1 controller? Why the clock is the same with > utmi phy > clock for otg controller. As far as I know, for i.MX51 this is as it should be. However, I doubt the usefulness of forcing "fsl,usbphy = <&usbphy1>" below. > > soc { > > @@ -239,6 +246,7 @@ > > interrupts = <14>; > > clocks = <&clks IMX5_CLK_USBOH3_GATE>; > > fsl,usbmisc = <&usbmisc 1>; > > + fsl,usbphy = <&usbphy1>; > > status = "disabled"; > > }; ---
[PATCH] xhci: fix wrong port number reported when setting USB2.0 hardware LPM.
This patch fix wrong port number reported when trying to enable/disable USB2.0 hardware LPM. Signed-off-by: Lin Wang --- drivers/usb/host/xhci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 6fe577d..972f00d 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4064,7 +4064,7 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd, field = le32_to_cpu(udev->bos->ext_cap->bmAttributes); xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", - enable ? "enable" : "disable", port_num); + enable ? "enable" : "disable", port_num + 1); if (enable) { /* Host supports BESL timeout instead of HIRD */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: fix wrong port number reported when setting USB2.0 hardware LPM.
This patch fix wrong port number reported when trying to enable/disable USB2.0 hardware LPM. Signed-off-by: Lin Wang --- drivers/usb/host/xhci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index 6fe577d..972f00d 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -4064,7 +4064,7 @@ int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd, field = le32_to_cpu(udev->bos->ext_cap->bmAttributes); xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", - enable ? "enable" : "disable", port_num); + enable ? "enable" : "disable", port_num + 1); if (enable) { /* Host supports BESL timeout instead of HIRD */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH net-next 0/7] r8152: tx/rx improvement
David Miller [mailto:da...@davemloft.net] > Sent: Saturday, March 08, 2014 5:28 AM > To: hayesw...@realtek.com > Cc: net...@vger.kernel.org; nic_s...@realtek.com; > linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org > Subject: Re: [PATCH net-next 0/7] r8152: tx/rx improvement [...] > Note that if you ever add ->ndo_poll_controller support to > this driver, > you will have to revert your spin_lock_irq{save,restore}() changes to > your ->ndo_start_xmit. > > Because the transmit function can indeed be invoked from hard IRQ > context once you support netpoll. Thank you for your reminder. I would notice that. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] ARM: imx_v6_v7_defconfig: Enable drivers for i.MX51 USB Host support.
On Fri, Mar 07, 2014 at 06:04:22PM +0100, Denis Carikli wrote: > Signed-off-by: Denis Carikli > --- > arch/arm/configs/imx_v6_v7_defconfig |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/imx_v6_v7_defconfig > b/arch/arm/configs/imx_v6_v7_defconfig > index 09e9743..772f14f 100644 > --- a/arch/arm/configs/imx_v6_v7_defconfig > +++ b/arch/arm/configs/imx_v6_v7_defconfig > @@ -209,8 +209,10 @@ CONFIG_USB_STORAGE=y > CONFIG_USB_CHIPIDEA=y > CONFIG_USB_CHIPIDEA_UDC=y > CONFIG_USB_CHIPIDEA_HOST=y > +CONFIG_USB_OTG_FSM=y Why it is needed? > CONFIG_NOP_USB_XCEIV=y > CONFIG_USB_MXS_PHY=y > +CONFIG_USB_ULPI=y > CONFIG_USB_GADGET=y > CONFIG_USB_ETH=m > CONFIG_USB_MASS_STORAGE=m > -- > 1.7.9.5 > > > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] ARM: imx_v4_v5_defconfig: Enable drivers for i.MX25/i.MX35 USB Host support.
On Fri, Mar 07, 2014 at 06:04:23PM +0100, Denis Carikli wrote: > Signed-off-by: Denis Carikli > --- > arch/arm/configs/imx_v4_v5_defconfig |8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/configs/imx_v4_v5_defconfig > b/arch/arm/configs/imx_v4_v5_defconfig > index f1aeb7d..f7c4fbf 100644 > --- a/arch/arm/configs/imx_v4_v5_defconfig > +++ b/arch/arm/configs/imx_v4_v5_defconfig > @@ -47,6 +47,7 @@ CONFIG_ZBOOT_ROM_BSS=0x0 > CONFIG_FPE_NWFPE=y > CONFIG_FPE_NWFPE_XP=y > CONFIG_PM_DEBUG=y > +CONFIG_PM_RUNTIME=y Why it is needed? > CONFIG_NET=y > CONFIG_PACKET=y > CONFIG_UNIX=y > @@ -80,6 +81,7 @@ CONFIG_MTD_UBI=y > CONFIG_EEPROM_AT24=y > CONFIG_EEPROM_AT25=y > CONFIG_ATA=y > +CONFIG_BLK_DEV_SD=y > CONFIG_PATA_IMX=y > CONFIG_NETDEVICES=y > CONFIG_CS89x0=y > @@ -153,6 +155,12 @@ CONFIG_USB_HID=m > CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_MXC=y > +CONFIG_USB_STORAGE=y > +CONFIG_USB_CHIPIDEA=y > +CONFIG_USB_CHIPIDEA_UDC=y > +CONFIG_USB_CHIPIDEA_HOST=y > +CONFIG_USB_OTG_FSM=y Why it is needed? > +CONFIG_NOP_USB_XCEIV=y > CONFIG_MMC=y > CONFIG_MMC_UNSAFE_RESUME=y > CONFIG_MMC_SDHCI=y > -- > 1.7.9.5 > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/9] ARM: dts: i.MX35: Add USB support.
On Fri, Mar 07, 2014 at 06:04:20PM +0100, Denis Carikli wrote: > Signed-off-by: Denis Carikli > --- > arch/arm/boot/dts/imx35.dtsi | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi > index e59ccb4..1c15b56 100644 > --- a/arch/arm/boot/dts/imx35.dtsi > +++ b/arch/arm/boot/dts/imx35.dtsi > @@ -292,6 +292,15 @@ > status = "disabled"; > }; > > + usbphy0: usbphy@0 { > + compatible = "usb-nop-xceiv"; > + }; > + > + usbphy1: usbphy@1 { > + compatible = "usb-nop-xceiv"; > + }; > + > + > usbotg: usb@53ff4000 { > compatible = "fsl,imx35-usb", "fsl,imx27-usb"; > reg = <0x53ff4000 0x0200>; > @@ -299,6 +308,7 @@ > clocks = <&clks 9>, <&clks 73>, <&clks 28>; > clock-names = "ipg", "ahb", "per"; > fsl,usbmisc = <&usbmisc 0>; > + fsl,usbphy = <&usbphy0>; > status = "disabled"; > }; > > @@ -309,6 +319,7 @@ > clocks = <&clks 9>, <&clks 73>, <&clks 28>; > clock-names = "ipg", "ahb", "per"; > fsl,usbmisc = <&usbmisc 1>; > + fsl,usbphy = <&usbphy1>; > status = "disabled"; > }; > > -- > 1.7.9.5 > > > Have you any other patches which are still not in mainline? At ci_hdrc_imx.c, we only get one clk, but for imx soc before than imx6, it needs three clks at our dts? -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: dts: i.MX51: Add a second usbphy.
On Fri, Mar 07, 2014 at 06:04:16PM +0100, Denis Carikli wrote: > Signed-off-by: Denis Carikli > --- > arch/arm/boot/dts/imx51.dtsi |8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi > index e508e6f..917b6ed 100644 > --- a/arch/arm/boot/dts/imx51.dtsi > +++ b/arch/arm/boot/dts/imx51.dtsi > @@ -100,6 +100,13 @@ > clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > clock-names = "main_clk"; > }; > + > + usbphy1: usbphy@1 { > + compatible = "usb-nop-xceiv"; > + reg = <1>; > + clocks = <&clks IMX5_CLK_USB_PHY_GATE>; > + clock-names = "main_clk"; > + }; Is this the ulpi phy for host1 controller? Why the clock is the same with utmi phy clock for otg controller. > }; > > soc { > @@ -239,6 +246,7 @@ > interrupts = <14>; > clocks = <&clks IMX5_CLK_USBOH3_GATE>; > fsl,usbmisc = <&usbmisc 1>; > + fsl,usbphy = <&usbphy1>; > status = "disabled"; > }; > > -- > 1.7.9.5 > > > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] usb: chipidea: usbmisc: Add USB Host support for i.MX25/i.MX35 CPUs
On Sat, Mar 08, 2014 at 09:32:15AM +0400, Alexander Shiyan wrote: > Пятница, 7 марта 2014, 18:04 +01:00 от Denis Carikli : > > Signed-off-by: Denis Carikli > > --- > > drivers/usb/chipidea/usbmisc_imx.c | 59 > > > > 1 file changed, 59 insertions(+) > > > > diff --git a/drivers/usb/chipidea/usbmisc_imx.c > > b/drivers/usb/chipidea/usbmisc_imx.c > > index cd061ab..d956ad0 100644 > > --- a/drivers/usb/chipidea/usbmisc_imx.c > > +++ b/drivers/usb/chipidea/usbmisc_imx.c > ... > > + val = readl(usbmisc->base); > > + val &= ~(MX25_OTG_SIC_MASK | MX25_OTG_PP_BIT); > > + val |= (MXC_EHCI_INTERFACE_DIFF_UNI & MXC_EHCI_INTERFACE_MASK) > > << MX25_OTG_SIC_SHIFT; > > + val |= (MX25_OTG_PM_BIT | MX25_OTG_OCPOL_BIT); > > + writel(val, usbmisc->base); > > At the moment, we only enable/disable interface and manage overcurrent option > in the usbmisc driver. > Is it worth it to handle type of interface here? > All usb related things which are not included at chipidea core can be in usbmisc driver. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] usb: chipidea: usbmisc: Add USB Host support for i.MX25/i.MX35 CPUs
Hi Denis, On Fri, Mar 7, 2014 at 2:04 PM, Denis Carikli wrote: > +static int usbmisc_imx25_init(struct imx_usbmisc_data *data) > +{ > + void __iomem *reg = NULL; This variable is not used and causes a warning. Please remove it. After applying this patch things go further when I boot with a USB thumb connected to the USB Host1 port: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver usbcore: registered new interface driver usb-storage 53ff4400.usb supply vbus not found, using dummy regulator ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected usb 1-1: new full-speed USB device number 2 using ci_hdrc (Not sure why it says full-speed device. When I connect the same device to a PC it says high-speed) usb 1-1: not running at top speed; connect to a high speed hub usb-storage 1-1:1.0: USB Mass Storage device detected usb-storage 1-1:1.0: Quirks match for vid 0457 pid 0151: 80 scsi0 : usb-storage 1-1:1.0 scsi 0:0:0:0: Direct-Access Ut163USB2FlashStorage 0.00 PQ: 0 ANSI: 2 sd 0:0:0:0: [sda] 248000 512-byte logical blocks: (126 MB/121 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Asking for cache data failed sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Asking for cache data failed sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Asking for cache data failed sd 0:0:0:0: [sda] Assuming drive cache: write through sd 0:0:0:0: [sda] Attached SCSI removable disk fec 50038000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx Sending DHCP requests ., OK IP-Config: Got DHCP answer from 192.168.0.1, my address is 192.168.0.8 IP-Config: Complete: device=eth0, hwaddr=00:04:00:00:00:00, ipaddr=192.168.0.8, mask=255.255.251 host=192.168.0.8, domain=, nis-domain=(none) bootserver=192.168.0.1, rootserver=192.168.0.2, rootpath= nameserver0=192.168.0.1 ALSA device list: No soundcards found. VFS: Mounted root (nfs filesystem) readonly on device 0:13. devtmpfs: mounted Freeing unused kernel memory: 276K (c0697000 - c06dc000) starting pid 536, tty '': '/etc/rc.d/rcS' Mounting /proc and /sys Starting the hotplug events dispatcher udevd Synthesizing initial hotplug events imx-sdma 53fd4000.sdma: firmware not found (Then system hangs here). If I boot without the USB thumb connected, then I reach the prompt, however after inserting the USB pen drive into USBH1 there is no detection. Any ideas? Thanks, Fabio Estevam -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2 10/13] r8152: support IPv6
From: Ben Hutchings Date: Sun, 09 Mar 2014 19:47:55 + > On Wed, 2014-03-05 at 14:49 +0800, Hayes Wang wrote: >> Support hw IPv6 checksum for TCP and UDP packets. >> >> Note that the hw has the limitation of the range of the transport >> offset. Besides, the TCP Pseudo Header of the IPv6 TSO of the hw >> bases on the Microsoft document which excludes the packet length. >> >> Signed-off-by: Hayes Wang >> --- >> drivers/net/usb/r8152.c | 107 >> ++-- >> 1 file changed, 104 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c >> index 8f6d0f8..8e208f30 100644 >> --- a/drivers/net/usb/r8152.c >> +++ b/drivers/net/usb/r8152.c > [...] >> +static int msdn_giant_send_check(struct sk_buff *skb) >> +{ >> +const struct ipv6hdr *ipv6h; >> +struct tcphdr *th; >> + >> +ipv6h = ipv6_hdr(skb); >> +th = tcp_hdr(skb); >> + >> +th->check = 0; >> +th->check = ~tcp_v6_check(0, &ipv6h->saddr, &ipv6h->daddr, 0); > [...] > > I think you need to call skb_cow_head() before editing the header here. This made me notice that several drivers open-code this: if (skb_header_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) goto drop; If someone is looking for a quick cleanup, transforming these to use skb_cow_head() would be nice. That way other driver authors will be less likely to copy the expanded code. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug#738113: linux-image-3.12-1-amd64: regression in xhci_hcd: USB3 doesn't work anymore
On Fri, 2014-03-07 at 10:32 -0800, Sarah Sharp wrote: > On Tue, Feb 11, 2014 at 06:11:09PM +0100, Andreas Cadhalpun wrote: > > Hi, > > > > thanks for looking into the issue. > > > > On 11.02.2014 17:40, Sarah Sharp wrote: > > >On Sat, Feb 08, 2014 at 03:56:31AM +, Ben Hutchings wrote: > > >>For the benefit of other developers, that change is a revert of commit > > >>459d3c146117 ('usb: xhci: Link TRB must not occur within a USB payload > > >>burst') plus this effective revert of commit fc76051c453b ('USB: XHCI: > > >>mark no_sg_constraint'): > > > > > >I hope that's unrelated. I was effectively going to do the same thing > > >upstream (except allow the no_sg_constraint to be set on 0.96 and > > >earlier hosts). > > > > I don't know what else changed from 3.12.8-1 to 3.12.9-1, but this > > was the only point in the changelog mentioning xhci. > > Alan and I concluded that the cause of this issue is clearing the > no_sg_constraint flag for 1.0 xHCI hosts. The patches to revert the > commits that caused the issues are on their way to the USB subsystem > maintainer (Greg): > > http://marc.info/?l=linux-kernel&m=139420433008427&w=2 > http://marc.info/?l=linux-kernel&m=139420429908418&w=2 > http://marc.info/?l=linux-kernel&m=139420432208425&w=2 > > The second commit is needed, since once we allow arbitrarily-aligned > scatter-gather, the ASIX driver will use it, which causes the USB to > ethernet adapter to drop packets occasionally. > > So we're basically back where we started before 3.12. [...] I thought we were already there. Thanks for letting us know about the additional reverts - I'll apply them in the next Debian update for 3.13. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: [PATCH net-next v2 10/13] r8152: support IPv6
On Wed, 2014-03-05 at 14:49 +0800, Hayes Wang wrote: > Support hw IPv6 checksum for TCP and UDP packets. > > Note that the hw has the limitation of the range of the transport > offset. Besides, the TCP Pseudo Header of the IPv6 TSO of the hw > bases on the Microsoft document which excludes the packet length. > > Signed-off-by: Hayes Wang > --- > drivers/net/usb/r8152.c | 107 > ++-- > 1 file changed, 104 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c > index 8f6d0f8..8e208f30 100644 > --- a/drivers/net/usb/r8152.c > +++ b/drivers/net/usb/r8152.c [...] > +static int msdn_giant_send_check(struct sk_buff *skb) > +{ > + const struct ipv6hdr *ipv6h; > + struct tcphdr *th; > + > + ipv6h = ipv6_hdr(skb); > + th = tcp_hdr(skb); > + > + th->check = 0; > + th->check = ~tcp_v6_check(0, &ipv6h->saddr, &ipv6h->daddr, 0); [...] I think you need to call skb_cow_head() before editing the header here. Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure. signature.asc Description: This is a digitally signed message part
Re: [GIT PULL] PHY for 3.15
On Sunday 09 March 2014 11:49 PM, gre...@linuxfoundation.org wrote: > On Sun, Mar 09, 2014 at 11:15:46PM +0530, Kishon Vijay Abraham I wrote: >> Hi Greg, >> >> Pls find the updated PULL request. >> >> It contains new PHY drivers (SATA, USB) adapted to generic PHY framework >> for a couple of platforms and a bunch of cleanups and fixes. The >> Documentation problem with the old PULL request has been fixed in this. >> >> Pls let me know If I have to make any other changes. >> >> Thanks >> Kishon >> >> The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691: >> >>Linux 3.14-rc4 (2014-02-23 17:40:03 -0800) >> >> are available in the git repository at: >> >>git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git >> tags/for_3.15 >> >> for you to fetch changes up to 88e670fe9d240c751fd9735ae3ee2906ed68e63d: >> >>PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver (2014-03-09 >> 12:45:13 +0530) >> > > line-wrap :( huh.. fixed my client now. > > Anyway, pulled and pushed out, thanks. Thanks :-) Regards Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] PHY for 3.15
On Sun, Mar 09, 2014 at 11:15:46PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Pls find the updated PULL request. > > It contains new PHY drivers (SATA, USB) adapted to generic PHY framework > for a couple of platforms and a bunch of cleanups and fixes. The > Documentation problem with the old PULL request has been fixed in this. > > Pls let me know If I have to make any other changes. > > Thanks > Kishon > > The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691: > >Linux 3.14-rc4 (2014-02-23 17:40:03 -0800) > > are available in the git repository at: > >git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > tags/for_3.15 > > for you to fetch changes up to 88e670fe9d240c751fd9735ae3ee2906ed68e63d: > >PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver (2014-03-09 > 12:45:13 +0530) > line-wrap :( Anyway, pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] PHY for 3.15
Hi Greg, Pls find the updated PULL request. It contains new PHY drivers (SATA, USB) adapted to generic PHY framework for a couple of platforms and a bunch of cleanups and fixes. The Documentation problem with the old PULL request has been fixed in this. Pls let me know If I have to make any other changes. Thanks Kishon The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691: Linux 3.14-rc4 (2014-02-23 17:40:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git tags/for_3.15 for you to fetch changes up to 88e670fe9d240c751fd9735ae3ee2906ed68e63d: PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver (2014-03-09 12:45:13 +0530) Add new PHY drivers for SATA and USB in exynos, for USB in sunxi, and a multi-purpose PHY in APM, all adapted to generic PHY framework. Adapted USB3 PHY driver in OMAP to generic PHY driver and also used the same driver for SATA in OMAP. It also includes miscellaneous cleanups and fixes. Austin Beam (1): phy: omap-usb2: Provide workaround for USB2PHY false disconnect George Cherian (2): phy: omap-usb2: Adapt phy-omap-usb2 for AM437x phy: omap-usb2: Add different compatible for OMAP5 Hans de Goede (1): PHY: sunxi: Add driver for sunxi usb phy Kamil Debski (4): phy: core: Add an exported of_phy_get function phy: core: Add devm_of_phy_get to phy-core phy: Add new Exynos USB 2.0 PHY driver phy: Add Exynos 5250 support to the Exynos USB 2.0 PHY driver Kishon Vijay Abraham I (4): drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2 phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/ phy: rename struct omap_control_usb to struct omap_control_phy Loc Ho (2): Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver Roger Quadros (7): phy: omap-control: update dra7 and am437 usb2 bindings phy: ti-pipe3: cleanup clock handling phy: ti-pipe3: Add SATA DPLL support phy: ti-pipe3: Don't get 'wkupclk' and 'refclk' for SATA PHY phy: ti-pipe3: streamline PHY operations phy: ti-pipe3: Fix suspend/resume and module reload phy: omap: Depend on OMAP_OCP2SCP bus driver Sachin Kamat (3): usb: phy: twl4030-usb: Silence checkpatch warnings usb: phy: twl4030-usb: Remove redundant semicolon usb: phy: bcm-kona-usb2: Use PTR_ERR_OR_ZERO Sebastian Hesselbarth (1): phy: mvebu-sata: prepare new Dove DT Kconfig variable Sylwester Nawrocki (2): phy: Select PHY_EXYNOS_MIPI_VIDEO by default for ARCH_EXYNOS phy: Select PHY_EXYNOS_DP_VIDEO by default for ARCH_EXYNOS Yuvaraj Kumar C D (1): PHY: Exynos: Add Exynos5250 SATA PHY driver .../devicetree/bindings/phy/apm-xgene-phy.txt | 79 + .../devicetree/bindings/phy/samsung-phy.txt| 54 + .../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 + Documentation/phy/samsung-usb2.txt | 135 ++ drivers/phy/Kconfig| 107 +- drivers/phy/Makefile |9 + drivers/phy/phy-bcm-kona-usb2.c|4 +- drivers/phy/phy-core.c | 76 +- drivers/phy/phy-exynos4210-usb2.c | 261 +++ drivers/phy/phy-exynos4x12-usb2.c | 328 drivers/phy/phy-exynos5250-sata.c | 251 +++ drivers/phy/phy-exynos5250-usb2.c | 404 + drivers/{usb => }/phy/phy-omap-control.c | 169 +- drivers/phy/phy-omap-usb2.c| 131 +- drivers/phy/phy-samsung-usb2.c | 228 +++ drivers/phy/phy-samsung-usb2.h | 67 + drivers/phy/phy-sun4i-usb.c| 331 drivers/phy/phy-ti-pipe3.c | 470 ++ drivers/phy/phy-twl4030-usb.c |6 +- drivers/phy/phy-xgene.c| 1750 drivers/usb/musb/omap2430.c|2 +- drivers/usb/phy/Kconfig| 21 - drivers/usb/phy/Makefile |2 - drivers/usb/phy/phy-omap-usb3.c| 361 drivers/usb/phy/phy-twl6030-usb.c |2 +- .../omap_control_usb.h => phy/omap_control_phy.h} | 36 +- include/linux/{usb => phy}/omap_usb.h | 14 +- include/linux/phy/phy.h| 15 + 28 files changed, 4792 insertions(+), 547 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt create mode 100644 Documentation/devicet
Re: drivers/input/input.c and a broken USB HID Contour ShuttlePRO v2
It seems that I will need help from both mailing lists. I've researched more and would like to propose this idea ... and I need feedback from the input and usb kernel maintainers in order to get my idea right. So for the input part I would like to propose to introduce a new input property INPUT_PROP_REL_IS_ABS with value 0x04 (this would be the next available "propbit" in input land (include/linux/input.h). #define INPUT_PROP_REL_IS_ABS 0x04 /* relative events report absolute coordinates */ When handling EV_REL events in drivers/input/input.c we then could check for the propbit being set and then always pass events from such devices to the handlers. This would allow us to selectively enable this fix for broken devices only. static int input_get_disposition(struct input_dev *dev, unsigned int type, unsigned int code, int value) { ... if (is_event_supported(code, dev->relbit, REL_MAX) && (value || test_bit(INPUT_PROP_REL_IS_ABS, dev->propbit)) disposition = INPUT_PASS_TO_HANDLERS; As for the USB part I'm currently lost. My idea is to have a contour USB device module that gets registered as a HID (sub?) driver so the generic HID can do all the normal handling. The part I don't know yet is how to switch on the propbit I mentioned in the previous paragraph. Can this be done in the input_mapped function of such an HID subdriver? Do I need to chain my own input_mapped to the generic one? I have to admit that I'm lost at this time, as this is my first journey into Linux driver land and Linux USB HID territory... So in my simple mind I would think of something like... static int contour_input_mapped(struct hid_device *hdev, struct hid_input *hi, struct hid_field *field, struct hid_usage *usage, unsigned long **bit, int *max) { __set_bit(INPUT_PROP_REL_IS_ABS, hi->input->propbit); return 0; } static const struct hid_device_id contour_devices[] = { { HID_USB_DEVICE(0x0b33, 0x0030) } { } }; static struct hid_driver contour_driver = { .name = "contour", .id_table = contour_devices, .input_mapped = contour_input_mapped, }; module_hid_driver(contour_driver); MODULE_DESCRIPTION("Driver for Contour ShuttlePRO v2"); MODULE_LICENSE("GPL"); So, please bear with me and help is greatly appreciated! -- TheDiveO On 09.03.2014 18:19, Greg KH wrote: On Sun, Mar 09, 2014 at 04:55:32PM +0100, Harald Albrecht wrote: I would like to improve support for the multimedia controllers from Contour company, as there currently get relative events swalled by input.c. The background: Contour seems to have messed up the USB HID descriptions of their multimedia controller devices in that these report to use relative axis when in fact they are creating EV_REL events with absolute coordinate values. The problem here is, that mapping these events to EV_ABS will break all existing software that supports these devices. Unfortunately, drivers/input/input.c correctly swallows any relative events with a relative movement value of zero... case EV_REL: if (is_event_supported(code, dev->relbit, REL_MAX) && value) disposition = INPUT_PASS_TO_HANDLERS; break; Simply removing the "&& value" would most probably have adverse effect on many software. Unfortunately, there is yet no "quirks" handling present in input.c. How can I add such quirks handling in a way that would be acceptable by the kernel maintainers? The people on linux-in...@vger.kernel.org (now cc:ed) might know more... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drivers/input/input.c and a broken USB HID Contour ShuttlePRO v2
On Sun, Mar 09, 2014 at 04:55:32PM +0100, Harald Albrecht wrote: > I would like to improve support for the multimedia controllers from > Contour company, as there currently get relative events swalled by input.c. > > The background: Contour seems to have messed up the USB HID descriptions > of their multimedia controller devices in that these report to use > relative axis when in fact they are creating EV_REL events with absolute > coordinate values. The problem here is, that mapping these events to > EV_ABS will break all existing software that supports these devices. > > Unfortunately, drivers/input/input.c correctly swallows any relative > events with a relative movement value of zero... > > case EV_REL: >if (is_event_supported(code, dev->relbit, REL_MAX) && value) > disposition = INPUT_PASS_TO_HANDLERS; >break; > > Simply removing the "&& value" would most probably have adverse effect > on many software. Unfortunately, there is yet no "quirks" handling > present in input.c. > > How can I add such quirks handling in a way that would be acceptable by > the kernel maintainers? The people on linux-in...@vger.kernel.org (now cc:ed) might know more... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Resend of usbip-utils migration patches and various other fixes
On Sun, Mar 09, 2014 at 05:53:51PM +0200, Valentina Manea wrote: > I was notified that one of the patches in the series (staging: usbip: > claim ports used by shared devices) breaks the build. > I take full responsability for this as I haven't compiled the kernel > with allyesconfig and I am sorry. No worries, it happens to all of us :) > This can be fixed by moving struct dev_state, usb_hub_claim_port() and > usb_hub_release_port() declarations from include/linux/usb.h to > usbip/stub.h, and leaving the declarations in usb/core/usb.h > untouched. > > Should the fix come as a separate patch or v2 of the broken one? No, I can't redo the patch that I've already committed. As "dev_state" is a very generic term, how about we just rename it to something more USB specific, like usb_dev_state? That way it would fix the build issue, and keep it from being a problem in the future in other drivers. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 00/28] PHY for 3.15
On Sun, Mar 09, 2014 at 01:05:36PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Saturday 08 March 2014 10:12 PM, Greg KH wrote: > > On Sat, Mar 08, 2014 at 02:59:01PM +0530, Kishon Vijay Abraham I wrote: > >> Hi Greg, > >> > >> Here's the PULL REQUEST for 3.15 merge window. > >> More users are starting to use the generic PHY framework including USB and > >> SATA PHY in exynos, USB in sunxi and multi-purpose PHY (currently only > >> SATA) > >> in APM. There is also a patch to adapt USB3 PHY driver (PIPE3) used in OMAP > >> to generic PHY framework and use the same driver for SATA. > >> It also includes few fixes and cleanups. > >> > >> Please let me know if you want me to make any changes. > >> > >> Cheers > >> Kishon > >> > >> The following changes since commit > >> cfbf8d4857c26a8a307fb7cd258074c9dcd8c691: > >> > >>Linux 3.14-rc4 (2014-02-23 17:40:03 -0800) > >> > >> are available in the git repository at: > >> > >>git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > >> tags/for_3.15 > >> > >> for you to fetch changes up to 303fd52cda953d14dc82ac82b570761599eb9ab2: > >> > >>PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver (2014-03-08 > >> 12:39:51 +0530) > > > > When merging this with my usb-next tree, I get the following merge > > issue, which I don't know how to resolve: > > CONFLICT (modify/delete): Documentation/devicetree/bindings/usb/usb-phy.txt > > deleted in HEAD and modified in a0100026249158ec7aae606b553efae7cb37f616. > > Version a0100026249158ec7aae606b553efae7cb37f616 of > > Documentation/devicetree/bindings/usb/usb-phy.txt left in tree. > > > > Any suggestions as to what I should do here? > > There were 3 patches that modified usb-phy.txt but the file was moved to > phy/ti-phy.txt in balbi's branch. I've resent the patches that modified > this file and have also updated tags/for_3.15. > > Let me know If I have to resend the PULL request. Please do, because I want to see the updated diffstat that I am supposed to be receiving. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
drivers/input/input.c and a broken USB HID Contour ShuttlePRO v2
I would like to improve support for the multimedia controllers from Contour company, as there currently get relative events swalled by input.c. The background: Contour seems to have messed up the USB HID descriptions of their multimedia controller devices in that these report to use relative axis when in fact they are creating EV_REL events with absolute coordinate values. The problem here is, that mapping these events to EV_ABS will break all existing software that supports these devices. Unfortunately, drivers/input/input.c correctly swallows any relative events with a relative movement value of zero... case EV_REL: if (is_event_supported(code, dev->relbit, REL_MAX) && value) disposition = INPUT_PASS_TO_HANDLERS; break; Simply removing the "&& value" would most probably have adverse effect on many software. Unfortunately, there is yet no "quirks" handling present in input.c. How can I add such quirks handling in a way that would be acceptable by the kernel maintainers? Any help greatly appreciated! -- TheDiveO -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Resend of usbip-utils migration patches and various other fixes
I was notified that one of the patches in the series (staging: usbip: claim ports used by shared devices) breaks the build. I take full responsability for this as I haven't compiled the kernel with allyesconfig and I am sorry. This can be fixed by moving struct dev_state, usb_hub_claim_port() and usb_hub_release_port() declarations from include/linux/usb.h to usbip/stub.h, and leaving the declarations in usb/core/usb.h untouched. Should the fix come as a separate patch or v2 of the broken one? Thanks, Valentina -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MAX3421E: device giving NAKs forever?
On Fri, 7 Mar 2014, David Mosberger wrote: > Felipe, > > Thanks for the tip about usbmon --- that looks interesting. Of > course, as luck would have it, turning on usbmon changes behavior: > dd'ing to a mass-storage device (/dev/sda1) used to fail after > ~500KiB. With usbmon, it fails only after about 2MiB. > > I attached two logs: first one is the usb-storage debug output without > usbmon (fails after about 500KB of writing to /dev/sda1), second is > with usbmon (fails about 2MiB of writing to /dev/sda1). I didn't see anything unusual in the logs. It looks like you'll have to use a bus analyzer to see the actual packets on the wire. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci: extend quirk for Renesas cards
After suspend another Renesas PCI-X USB 3.0 card doesn't work. 03:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720202 USB 3.0 Host Controller [1912:0015] (rev 02) (prog-if 30 [XHCI]) Reported-and-tested-by: Anatoly K. Reference: http://redmine.russianfedora.pro/issues/1315 Signed-off-by: Igor Gnatenko --- drivers/usb/host/xhci-pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 04f986d..13d4add 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -143,9 +143,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) xhci->quirks |= XHCI_TRUST_TX_LENGTH; } if (pdev->vendor == PCI_VENDOR_ID_RENESAS && - pdev->device == 0x0015 && - pdev->subsystem_vendor == PCI_VENDOR_ID_SAMSUNG && - pdev->subsystem_device == 0xc0cd) + pdev->device == 0x0015) xhci->quirks |= XHCI_RESET_ON_RESUME; if (pdev->vendor == PCI_VENDOR_ID_VIA) xhci->quirks |= XHCI_RESET_ON_RESUME; -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] [PATCH] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
The same issue like with Panther Point chipsets. If the USB ports are switched to xHCI on shutdown, the xHCI host will send a spurious interrupt, which will wake the system. Some BIOS have work around for this, but not all. One example is Compulab's mini-desktop, the Intense-PC2. The bug can be avoided if the USB ports are switched back to EHCI on shutdown. Signed-off-by: Denis Turischev --- drivers/usb/host/xhci-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 3c898c1..9233d12 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) */ if (pdev->subsystem_vendor == PCI_VENDOR_ID_HP) xhci->quirks |= XHCI_SPURIOUS_WAKEUP; + + xhci->quirks |= XHCI_SPURIOUS_REBOOT; } if (pdev->vendor == PCI_VENDOR_ID_ETRON && pdev->device == PCI_DEVICE_ID_ASROCK_P67) { -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html