RE: usb device to ether is not identification in 64bit Windows OS

[Lipengcheng]

Hi,
In windows official web, download a new linux.inf file, and add our 
hisilicon usb id. Now it can be used correct identification in PC windows 64bit 
OS. At the same time, it can also be used correctly in PC windows 32bit OS.
windows official web: 
https://msdn.microsoft.com/zh-cn/windows/hardware/drivers/network/remote-ndis-inf-template
the new file(add hisilicon usb id):

; Remote NDIS template device setup file
; Copyright (c) Microsoft Corporation
;
; This is the template for the INF installation script  for the RNDIS-over-USB
; host driver that leverages the newer NDIS 6.x miniport (rndismp6.sys) for
; improved performance. This INF works for Windows 7, Windows Server 2008 R2,
; and later operating systems on x86, amd64 and ia64 platforms.

[Version]
Signature   = "$Windows NT$"
Class   = Net
ClassGUID   = {4d36e972-e325-11ce-bfc1-08002be10318}
Provider= %Microsoft%
DriverVer   = 07/21/2008,6.0.6000.16384
;CatalogFile= device.cat

[Manufacturer]
%Microsoft% = RndisDevices,NTx86,NTamd64,NTia64

; Decoration for x86 architecture
[RndisDevices.NTx86]
%RndisDevice%= RNDIS.NT.6.0, USB\VID_0525_a4a2, 
USB\VID_1d6b_0104_00, USB\VID_0525_A4A2_0318

; Decoration for x64 architecture
[RndisDevices.NTamd64]
%RndisDevice%= RNDIS.NT.6.0, USB\VID_0525_a4a2, 
USB\VID_1d6b_0104_00, USB\VID_0525_A4A2_0318

; Decoration for ia64 architecture
[RndisDevices.NTia64]
%RndisDevice%= RNDIS.NT.6.0, USB\VID_0525_a4a2, 
USB\VID_1d6b_0104_00, USB\VID_0525_A4A2_0318

;@@@ This is the common setting for setup
[ControlFlags]
ExcludeFromSelect=*

; DDInstall section
; References the in-build Netrndis.inf
[RNDIS.NT.6.0]
Characteristics = 0x84   ; NCF_PHYSICAL + NCF_HAS_UI
BusType = 15
; NEVER REMOVE THE FOLLOWING REFERENCE FOR NETRNDIS.INF
include = netrndis.inf
needs   = usbrndis6.ndi
AddReg  = Rndis_AddReg
*IfType= 6; IF_TYPE_ETHERNET_CSMACD.
*MediaType = 16   ; NdisMediumNative802_11
*PhysicalMediaType = 14   ; NdisPhysicalMedium802_3

; DDInstal.Services section
[RNDIS.NT.6.0.Services]
include = netrndis.inf
needs   = usbrndis6.ndi.Services

; Optional registry settings. You can modify as needed.
[RNDIS_AddReg] 
HKR, NDI\params\RndisProperty, ParamDesc,  0, %Rndis_Property%
HKR, NDI\params\RndisProperty, type,   0, "edit"
HKR, NDI\params\RndisProperty, LimitText,  0, "12"
HKR, NDI\params\RndisProperty, UpperCase,  0, "1"
HKR, NDI\params\RndisProperty, default,0, " "
HKR, NDI\params\RndisProperty, optional,   0, "1"

; No sys copyfiles - the sys files are already in-build 
; (part of the operating system).

; Modify these strings for your device as needed.
[Strings]
Microsoft = "Microsoft Corporation"
RndisDevice   = "Remote NDIS6 based Device"
Rndis_Property = "Optional RNDIS Property"

> -Original Message-
> From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
> Sent: Monday, September 19, 2016 12:46 AM
> To: Lipengcheng
> Cc: cor...@lwn.net; linux-usb@vger.kernel.org; linux-...@vger.kernel.org; 
> linux-ker...@vger.kernel.org
> Subject: Re: usb device to ether is not identification in 64bit Windows OS
> 
> On Sun, Sep 18, 2016 at 01:16:59PM +, Lipengcheng wrote:
> > Hi,
> > kernel version：4.8.0
> > file:Documentation / usb / linux.inf
> > problem:PC windows is 32bit OS, using Ethernet gadget driver, it can
> > be correct identification. But PC windows is 64bit OS, while modifying
> > linux.inf file LinuxDevice parameters, it can not correct
> > identification, the serial port can be printed correctly:g_ether
> > gadget: high-speed config # 2: RNDIS. I suspect that the linux.inf
> > files are not mismatch 64bit windows OS.
> 
> Given that everyone here does not use Windows at all, you are going to be on 
> your own here, sorry.  If you do come up with an updated .inf
> file, we will be glad to take a patch.
> 
> good luck,
> 
> greg k-h

Best regards,
Pengcheng Li

Re: [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Kishon Vijay Abraham I]

Hi,

On Monday 19 September 2016 01:26 AM, Martin Blumenstingl wrote:
> Hi Kishon,
> 
> On Fri, Sep 16, 2016 at 10:19 AM, Kishon Vijay Abraham I  
> wrote:
>> Hi,
>>
>> On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
>>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman  wrote:
 However, the problem with all of the solutions proposed (runtime PM ones
 included) is that we're forcing a board-specific design issue (2 devices
 sharing a reset line) into a driver that should not have any
 board-specific assumptions in it.

 For example, if this driver is used on another platform where different
 PHYs have different reset lines, then one of them (the unlucky one who
 is not probed first) will never get reset.  So any form of per-device
 ref-counting is not a portable solution.
>>> maybe we should also consider Ben's solution: he played with the USB
>>> PHY on his Meson8b board. His approach was to have only one USB PHY
>>> driver instance which exposes two PHYs.
>>> The downside of this: the driver would have to know the offset of the
>>> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
>>> the reset using runtime PM without any hacks.
>>
>> I think the offset information can come from the devicetree too. The phy can 
>> be
>> modeled something like below.
>>
>> usb-phys@c000 {
>> compatible = "amlogic,meson-gxbb-usb2-phy";
>> reg = <0x0 0xc000 0x0 0x40>;
>> #address-cells = <2>;
>> #size-cells = <2>;
>> ranges = <0x0 0x0 0x0 0xc000 0x0 0x40>;
>> resets = < 34>;
>>
>> usb0_phy: usb_phy@0 {
>> #phy-cells = <0>;
>> reg = <0x0 0x0 0x0 0x20>;
>> clocks = < CLKID_USB  CLKID_USB0>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>>
>> usb1_phy: usb_phy@20 {
>> #phy-cells = <0>;
>> reg = <0x0 0x20 0x0 0x20>;
>> clocks = < CLKID_USB  CLKID_USB1>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>> };
>>
>> This way the driver will be probed only once (the reset can be done during
>> probe). The phy driver should scan the dt node and for every sub-node it
>> invokes phy_create?
> I'll recap what we have discussed so far (so you don't have to re-read
> the whole thread):
> The reference driver treats both USB PHYs as separate devices (the
> datasheet has no information about the PHYs though). The only
> "special" thing is the shared reset line -> together with Philipp
> Zabel (the reset framework maintainer) we decided to make
> reset_control_reset work for shared reset lines.
> 
> That means we can keep the two PHYs as separate devices inside the
> .dts, while keeping everything else separate (just like the reference
> driver)
> Is this fine for you and Arnd?

yeah.. I'm fine with that.

Thanks
Kishon
> 
> 
> Regards,
> Martin
> 
--
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 2/3] r8152: support ECM mode

[kbuild test robot]

Hi Hayes,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Hayes-Wang/r8152-configuration-setting/20160907-192351
config: x86_64-randconfig-s0-09190146 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `rtl_ecm_bind':
   r8152.c:(.text+0x64b43c): undefined reference to `usbnet_cdc_bind'
   r8152.c:(.text+0x64b59e): undefined reference to `usbnet_cdc_unbind'
>> drivers/built-in.o:(.rodata+0x272438): undefined reference to 
>> `usbnet_cdc_unbind'
>> drivers/built-in.o:(.rodata+0x272460): undefined reference to 
>> `usbnet_cdc_status'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: Gadget regression with u_ether in Linux next

[Harish Jenny K N]

> On Saturday 17 September 2016 12:03 AM, Tony Lindgren wrote:

> Hi,
>
> Looks like commit c9ffc78745f8 ("usb: gadget: NCM: Protect dev->port_usb
> using dev->lock") causes hangs for me with Linux next.
>
> Reverting c9ffc78745f8 makes the issues go away, some more info below.
>
> Regards,
>
> Tony
Sorry. There was a mistake with the commit. spinlock not acquired in if 
(dev->wrap) condition was also being tried to get unlocked.

Please revert/remove the commit.

Thanks,
Harish
--
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 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB

[Martin Blumenstingl]

Hi Kishon,

On Fri, Sep 16, 2016 at 10:19 AM, Kishon Vijay Abraham I  wrote:
> Hi,
>
> On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman  wrote:
>>> However, the problem with all of the solutions proposed (runtime PM ones
>>> included) is that we're forcing a board-specific design issue (2 devices
>>> sharing a reset line) into a driver that should not have any
>>> board-specific assumptions in it.
>>>
>>> For example, if this driver is used on another platform where different
>>> PHYs have different reset lines, then one of them (the unlucky one who
>>> is not probed first) will never get reset.  So any form of per-device
>>> ref-counting is not a portable solution.
>> maybe we should also consider Ben's solution: he played with the USB
>> PHY on his Meson8b board. His approach was to have only one USB PHY
>> driver instance which exposes two PHYs.
>> The downside of this: the driver would have to know the offset of the
>> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
>> the reset using runtime PM without any hacks.
>
> I think the offset information can come from the devicetree too. The phy can 
> be
> modeled something like below.
>
> usb-phys@c000 {
> compatible = "amlogic,meson-gxbb-usb2-phy";
> reg = <0x0 0xc000 0x0 0x40>;
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xc000 0x0 0x40>;
> resets = < 34>;
>
> usb0_phy: usb_phy@0 {
> #phy-cells = <0>;
> reg = <0x0 0x0 0x0 0x20>;
> clocks = < CLKID_USB  CLKID_USB0>;
> clock-names = "usb_general", "usb";
> status = "disabled";
> };
>
> usb1_phy: usb_phy@20 {
> #phy-cells = <0>;
> reg = <0x0 0x20 0x0 0x20>;
> clocks = < CLKID_USB  CLKID_USB1>;
> clock-names = "usb_general", "usb";
> status = "disabled";
> };
> };
>
> This way the driver will be probed only once (the reset can be done during
> probe). The phy driver should scan the dt node and for every sub-node it
> invokes phy_create?
I'll recap what we have discussed so far (so you don't have to re-read
the whole thread):
The reference driver treats both USB PHYs as separate devices (the
datasheet has no information about the PHYs though). The only
"special" thing is the shared reset line -> together with Philipp
Zabel (the reset framework maintainer) we decided to make
reset_control_reset work for shared reset lines.

That means we can keep the two PHYs as separate devices inside the
.dts, while keeping everything else separate (just like the reference
driver)
Is this fine for you and Arnd?


Regards,
Martin
--
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 2/3] r8152: support ECM mode

[kbuild test robot]

Hi Hayes,

[auto build test ERROR on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Hayes-Wang/r8152-configuration-setting/20160907-192351
config: i386-randconfig-x0-09182136 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `r815x_mdio_write':
>> r8152.c:(.text+0x19a664): undefined reference to `usbnet_write_cmd'
   drivers/built-in.o: In function `r815x_mdio_read':
>> r8152.c:(.text+0x19a6ae): undefined reference to `usbnet_read_cmd'
   drivers/built-in.o: In function `rtl_usbnet_disconnect':
>> r8152.c:(.text+0x19aaa9): undefined reference to `usbnet_disconnect'
   drivers/built-in.o: In function `rtl_ecm_bind':
>> r8152.c:(.text+0x19c143): undefined reference to `usbnet_cdc_bind'
   r8152.c:(.text+0x19c175): undefined reference to `usbnet_write_cmd'
>> r8152.c:(.text+0x19c1e8): undefined reference to `usbnet_cdc_unbind'
   drivers/built-in.o: In function `rtl_usbnet_suspend':
>> r8152.c:(.text+0x19d3ab): undefined reference to `usbnet_suspend'
   drivers/built-in.o: In function `rtl_usbnet_probe':
>> r8152.c:(.text+0x19d7bd): undefined reference to `usbnet_probe'
   drivers/built-in.o: In function `rtl_usbnet_reset_resume':
>> r8152.c:(.text+0x19ec33): undefined reference to `usbnet_resume'
   drivers/built-in.o: In function `rtl_usbnet_resume':
   r8152.c:(.text+0x19ec68): undefined reference to `usbnet_resume'
   drivers/built-in.o: In function `lkdtm_rodata_do_nothing':
>> (.rodata+0x3538c): undefined reference to `usbnet_cdc_unbind'
   drivers/built-in.o: In function `lkdtm_rodata_do_nothing':
>> (.rodata+0x3539c): undefined reference to `usbnet_manage_power'
   drivers/built-in.o: In function `lkdtm_rodata_do_nothing':
>> (.rodata+0x353a0): undefined reference to `usbnet_cdc_status'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH 2/2] musb: sunxi: Force session end on babble errors in host-mode

[Hans de Goede]

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.

Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control).

This commit calls sun4i_usb_phy_force_session_end() on babble errors
in host-mode, fixing the musb controller being stuck in this state
on systems without Vbus control; and also fixes the need to unplug
the usb-b -> usb-a cable to get out of this state on systems with
Vbus control.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb/sunxi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 1408245..5079d90 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -192,8 +192,18 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
*__hci)
 * normally babble never happens treat it as disconnect.
 */
if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {
+   struct sunxi_glue *glue =
+   dev_get_drvdata(musb->controller->parent);
+
+   dev_warn(musb->controller->parent, "babble, treating as 
disconnect\n");
+
musb->int_usb &= ~MUSB_INTR_BABBLE;
musb->int_usb |= MUSB_INTR_DISCONNECT;
+   /*
+* Fix the musb controller sometimes getting stuck in
+* bdevice state after a babble error.
+*/
+   sun4i_usb_phy_force_session_end(glue->phy);
}
 
if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
-- 
2.9.3

--
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 1/2] phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function

[Hans de Goede]

The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.

Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control). The phy-sun4i-usb code already has code to force a session
end for devices without Vbus control.

This commit adds a sun4i_usb_phy_force_session_end() function exporting
this functionality to the sunxi-musb glue, so that it can force a session
end to fixup the stuck state after a babble error.

Signed-off-by: Hans de Goede 
---
 drivers/phy/phy-sun4i-usb.c   | 11 +++
 include/linux/phy/phy-sun4i-usb.h |  7 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 43c0d98..06f4e11a 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -470,6 +470,17 @@ void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, 
bool enabled)
 }
 EXPORT_SYMBOL_GPL(sun4i_usb_phy_set_squelch_detect);
 
+void sun4i_usb_phy_force_session_end(struct phy *_phy)
+{
+   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+
+   data->id_det = -1;
+   data->force_session_end = true;
+   queue_delayed_work(system_wq, >detect, 0);
+}
+EXPORT_SYMBOL_GPL(sun4i_usb_phy_force_session_end);
+
 static const struct phy_ops sun4i_usb_phy_ops = {
.init   = sun4i_usb_phy_init,
.exit   = sun4i_usb_phy_exit,
diff --git a/include/linux/phy/phy-sun4i-usb.h 
b/include/linux/phy/phy-sun4i-usb.h
index 50aed92..3bb773f 100644
--- a/include/linux/phy/phy-sun4i-usb.h
+++ b/include/linux/phy/phy-sun4i-usb.h
@@ -23,4 +23,11 @@
  */
 void sun4i_usb_phy_set_squelch_detect(struct phy *phy, bool enabled);
 
+/**
+ * sun4i_usb_force_session_end() - Force the current session to end
+ *by reporting VBus low for 200+ ms
+ * @phy: reference to a sun4i usb phy
+ */
+void sun4i_usb_phy_force_session_end(struct phy *phy);
+
 #endif
-- 
2.9.3

--
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: usb device to ether is not identification in 64bit Windows OS

[gre...@linuxfoundation.org]

On Sun, Sep 18, 2016 at 01:16:59PM +, Lipengcheng wrote:
> Hi,
> kernel version：4.8.0
> file:Documentation / usb / linux.inf
> problem:PC windows is 32bit OS, using Ethernet gadget driver, it can
> be correct identification. But PC windows is 64bit OS, while modifying
> linux.inf file LinuxDevice parameters, it can not correct
> identification, the serial port can be printed correctly:g_ether
> gadget: high-speed config # 2: RNDIS. I suspect that the linux.inf
> files are not mismatch 64bit windows OS.

Given that everyone here does not use Windows at all, you are going to
be on your own here, sorry.  If you do come up with an updated .inf
file, we will be glad to take a patch.

good luck,

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

[PATCH v2 0/3] usb: trivial cleanups with list_first_entry_or_null()

[Masahiro Yamada]

Replace the chain of list_empty() and list_first_entry()
with list_first_entry_or_null().

Changes in v2:
 - Split into per-driver patches


Masahiro Yamada (3):
  usb: dwc2: cleanup with list_first_entry_or_null()
  usb: dwc3: cleanup with list_first_entry_or_null()
  usb: renesas_usbhs: cleanup with list_first_entry_or_null()

 drivers/usb/dwc2/gadget.c| 6 ++
 drivers/usb/dwc3/gadget.h| 5 +
 drivers/usb/renesas_usbhs/fifo.c | 5 +
 3 files changed, 4 insertions(+), 12 deletions(-)

-- 
1.9.1

--
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 v2 3/3] usb: renesas_usbhs: cleanup with list_first_entry_or_null()

[Masahiro Yamada]

The combo of list_empty() check and return list_first_entry()
can be replaced with list_first_entry_or_null().

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/renesas_usbhs/fifo.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/fifo.c b/drivers/usb/renesas_usbhs/fifo.c
index 857e783..d1af831 100644
--- a/drivers/usb/renesas_usbhs/fifo.c
+++ b/drivers/usb/renesas_usbhs/fifo.c
@@ -100,10 +100,7 @@ static void __usbhsf_pkt_del(struct usbhs_pkt *pkt)
 
 static struct usbhs_pkt *__usbhsf_pkt_get(struct usbhs_pipe *pipe)
 {
-   if (list_empty(>list))
-   return NULL;
-
-   return list_first_entry(>list, struct usbhs_pkt, node);
+   return list_first_entry_or_null(>list, struct usbhs_pkt, node);
 }
 
 static void usbhsf_fifo_clear(struct usbhs_pipe *pipe,
-- 
1.9.1

--
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 v2 1/3] usb: dwc2: cleanup with list_first_entry_or_null()

[Masahiro Yamada]

The combo of list_empty() check and return list_first_entry()
can be replaced with list_first_entry_or_null().

Signed-off-by: Masahiro Yamada 
Acked-by: John Youn 
---

 drivers/usb/dwc2/gadget.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index af46adf..28a250a 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1098,10 +1098,8 @@ static int dwc2_hsotg_ep_sethalt(struct usb_ep *ep, int 
value, bool now);
  */
 static struct dwc2_hsotg_req *get_ep_head(struct dwc2_hsotg_ep *hs_ep)
 {
-   if (list_empty(_ep->queue))
-   return NULL;
-
-   return list_first_entry(_ep->queue, struct dwc2_hsotg_req, queue);
+   return list_first_entry_or_null(_ep->queue, struct dwc2_hsotg_req,
+   queue);
 }
 
 /**
-- 
1.9.1

--
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 v2 2/3] usb: dwc3: cleanup with list_first_entry_or_null()

[Masahiro Yamada]

The combo of list_empty() check and return list_first_entry()
can be replaced with list_first_entry_or_null().

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/dwc3/gadget.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
index e4a1d97..3129bcf 100644
--- a/drivers/usb/dwc3/gadget.h
+++ b/drivers/usb/dwc3/gadget.h
@@ -62,10 +62,7 @@ struct dwc3;
 
 static inline struct dwc3_request *next_request(struct list_head *list)
 {
-   if (list_empty(list))
-   return NULL;
-
-   return list_first_entry(list, struct dwc3_request, list);
+   return list_first_entry_or_null(list, struct dwc3_request, list);
 }
 
 static inline void dwc3_gadget_move_started_request(struct dwc3_request *req)
-- 
1.9.1

--
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: [PATCHv2] usb: musb: Fix unbalanced platform_disable

[Tony Lindgren]

* Laurent Pinchart  [160918 05:13]:
> 
> FYI, while this patch allows me to boot my Panda board with NFS over usbnet, 
> it only works with cold boots. A warm reboot results in the following 
> warning, 
> and no ethernet traffic going through. The USB device is detected by the host 
> though.

Yeah I noticed too that we still have issues. For example doing rmmod of
omap2430 with gadget configured and connected will produce a hardirq-safe
hardirq-unsafe lock order error. That also happens with reboot with gadget
configured and connected.

> I'm not sure whether this is a regression introduced by commit a83e17d0f73b 
> ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer") or an 
> entirely different issue;
...
> [5.711303] [] (_raw_spin_unlock_irqrestore) from [] 
> (musb_gadget_queue+0x128/0x4ac)
> [5.711303] [] (musb_gadget_queue) from [] 
> (usb_ep_queue+0x38/0x1d4)
> [5.729766] [] (usb_ep_queue) from [] 
> (rx_submit+0xc8/0x19c)
> [5.737548] [] (rx_submit) from [] (rx_fill+0x7c/0xa0)
> [5.737548] [] (rx_fill) from [] (eth_start+0x28/0x48)
> [5.751983] [] (eth_start) from [] (eth_open+0x6c/0x7c)
> [5.751983] [] (eth_open) from [] 
> (__dev_open+0x9c/0x104)

This could be something else though. Care to email me your .config, maybe
this is related to legacy g_ether being built in?

Anyways, please also give the following patch a try. The reason why we
currently have no chance of getting musb_platform_enable/disable balanced
is because we need to try to set the musb devctl session bit in various
places and possibly retry too. So musb_start should really be called
musb_try_start_session() or something.

So I think the only sane thing to do at this point is to revert the changes
trying to enable/disable USB PHY from omap2430_musb_enable/disable. The other
fixes are OK too as they get us a bit closer to making the platform glue calls
balanced.

Regards,

Tony

8< --
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -337,6 +337,7 @@ static int omap2430_musb_init(struct musb *musb)
}
musb->isr = omap2430_musb_interrupt;
phy_init(musb->phy);
+   phy_power_on(musb->phy);
 
l = musb_readl(musb->mregs, OTG_INTERFSEL);
 
@@ -373,9 +374,6 @@ static void omap2430_musb_enable(struct musb *musb)
struct musb_hdrc_platform_data *pdata = dev_get_platdata(dev);
struct omap_musb_board_data *data = pdata->board_data;
 
-   if (!WARN_ON(!musb->phy))
-   phy_power_on(musb->phy);
-
omap2430_set_power(musb, true, glue->cable_connected);
 
switch (glue->status) {
@@ -413,9 +411,6 @@ static void omap2430_musb_disable(struct musb *musb)
struct device *dev = musb->controller;
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
 
-   if (!WARN_ON(!musb->phy))
-   phy_power_off(musb->phy);
-
if (glue->status != MUSB_UNKNOWN)
omap_control_usb_set_mode(glue->control_otghs,
USB_MODE_DISCONNECT);
@@ -429,6 +424,7 @@ static int omap2430_musb_exit(struct musb *musb)
struct omap2430_glue *glue = dev_get_drvdata(dev->parent);
 
omap2430_low_level_exit(musb);
+   phy_power_off(musb->phy);
phy_exit(musb->phy);
musb->phy = NULL;
cancel_work_sync(>omap_musb_mailbox_work);
--
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

usb device to ether is not identification in 64bit Windows OS

[Lipengcheng]

Hi,
kernel version：4.8.0
file:Documentation / usb / linux.inf
problem:PC windows is 32bit OS, using Ethernet gadget driver, it can be correct 
identification. But PC windows is 64bit OS, while modifying linux.inf file 
LinuxDevice parameters, it can not correct identification, the serial port can 
be printed correctly:g_ether gadget: high-speed config # 2: RNDIS. I suspect 
that the linux.inf files are not mismatch 64bit windows OS.

Best regards,
Pengcheng Li

Re: [PATCHv2] usb: musb: Fix unbalanced platform_disable

[Laurent Pinchart]

Hi Tony,

On Monday 12 Sep 2016 08:39:49 Tony Lindgren wrote:
> Commit a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling
> for 2430 glue layer") moved PHY enable/disable calls to happen from
> omap2430_musb_enable/disable(). That broke enumeration for several
> devices as PM runtime in the PHY will never enable it.
> 
> The root cause of the problem is unpaired calls from musb_core.c to
> musb_platform_enable/disable in musb_core.c as reported by
> Andreas Kemnade .
> 
> As musb_platform_enable/disable are being called from various functions,
> let's not attempt to make them paiered immediately. This would require
> fixing all the callers like musb_remove.
> 
> Instead, let's first fix the regression in a minimal way by removing
> the initial call to musb_platform_disable.
> 
> AFAIK the initial musb_platform_disable call has always been just an
> attempted workaround for the 2430 glue layer announcing itself too
> early before the gadgets are configured. And that issue finally
> got fixed with commit a118df07f5b1 ("usb: musb: Don't set d+ high
> before enable for 2430 glue layer").
> 
> We now also need to fix the twl4030-phy accordingly making it's
> PM runtime call only needed in twl4030_phy_power_on and have it
> autosuspend. The cable state will keep the phy active when connected.
> 
> Cc: Kishon Vijay Abraham I 
> Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling
> for 2430 glue layer")
> Reported-by: Andreas Kemnade 
> Acked-by: Andreas Kemnade 
> Reported-by: Laurent Pinchart 
> Tested-by: Laurent Pinchart 
> Acked-by: Laurent Pinchart 
> Signed-off-by: Tony Lindgren 

FYI, while this patch allows me to boot my Panda board with NFS over usbnet, 
it only works with cold boots. A warm reboot results in the following warning, 
and no ethernet traffic going through. The USB device is detected by the host 
though.

I'm not sure whether this is a regression introduced by commit a83e17d0f73b 
("usb: musb: Improve PM runtime and phy handling for 2430 glue layer") or an 
entirely different issue;

[5.509918] [ cut here ]
[5.509918] WARNING: CPU: 0 PID: 1 at 
/home/laurent/src/kernel/omap4/linux-2.6/drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x220/0x348
[5.528137] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read): 
Data Access in User mode during Functional access
[5.539825] Modules linked in:
[5.539825] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc2-00806-
g37c4efacd6b9 #4
[5.539825] Hardware name: Generic OMAP4 (Flattened Device Tree)
[5.551361] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[5.565826] [] (show_stack) from [] 
(dump_stack+0xa8/0xe0)
[5.565826] [] (dump_stack) from [] (__warn+0xd8/0x104)
[5.565826] [] (__warn) from [] 
(warn_slowpath_fmt+0x38/0x48)
[5.588623] [] (warn_slowpath_fmt) from [] 
(l3_interrupt_handler+0x220/0x348)
[5.588623] [] (l3_interrupt_handler) from [] 
(__handle_irq_event_percpu+0x98/0x3ec)
[5.588623] [] (__handle_irq_event_percpu) from [] 
(handle_irq_event_percpu+0x1c/0x58)
[5.588623] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x38/0x5c)
[5.627380] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xcc/0x1a4)
[5.627380] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x18/0x28)
[5.636352] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x64/0xdc)
[5.654541] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x48/0x9c)
[5.654541] [] (gic_handle_irq) from [] 
(__irq_svc+0x70/0x98)
[5.654541] Exception stack(0xee8b7d18 to 0xee8b7d60)
[5.676483] 7d00:   
0001 ee8b5328
[5.676483] 7d20:  ee8b4d80 6153 eee28010 eee28010 6153 
0002 c1603ae4
[5.693664] 7d40: c0d029cc 016b c0f19314 ee8b7d68 c019268c c0872788 
2153 
[5.693664] [] (__irq_svc) from [] 
(_raw_spin_unlock_irqrestore+0x34/0x44)
[5.711303] [] (_raw_spin_unlock_irqrestore) from [] 
(musb_gadget_queue+0x128/0x4ac)
[5.711303] [] (musb_gadget_queue) from [] 
(usb_ep_queue+0x38/0x1d4)
[5.729766] [] (usb_ep_queue) from [] 
(rx_submit+0xc8/0x19c)
[5.737548] [] (rx_submit) from [] (rx_fill+0x7c/0xa0)
[5.737548] [] (rx_fill) from [] (eth_start+0x28/0x48)
[5.751983] [] (eth_start) from [] (eth_open+0x6c/0x7c)
[5.751983] [] (eth_open) from [] 
(__dev_open+0x9c/0x104)
[5.766815] [] (__dev_open) from [] 
(__dev_change_flags+0x88/0x150)
[5.775238] [] (__dev_change_flags) from [] 
(dev_change_flags+0x18/0x48)
[5.775238] [] (dev_change_flags) from [] 
(ip_auto_config+0x194/0x1148)
[5.792907] [] (ip_auto_config) from [] 
(do_one_initcall+0x3c/0x174)
[5.792907] [] (do_one_initcall) from [] 

[GIT PULL] USB driver fixes for 4.8-rc7

[Greg KH]

The following changes since commit 9395452b4aab7bc2475ef8935b4a4fb99d778d70:

  Linux 4.8-rc6 (2016-09-11 20:02:25 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.8-rc7

for you to fetch changes up to e06226e66beafd6118aa81b511d88cb549ad7ea5:

  Merge tag 'usb-serial-4.8-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus 
(2016-09-16 17:42:10 +0200)


USB fixes for 4.8-rc7

Here are 2 small fixes, and one new device id, for 4.8-rc7

The fixes solve a build error that was reported in your tree for the
blackfin arch, and resolve an issue with a number of broken USB devices
that reported the wrong interval rate.  Included here is also a new
device id for the usb-serial driver.

All have been in linux-next with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Alan Stern (1):
  USB: change bInterval default to 10 ms

Daniele Palmas (1):
  USB: serial: simple: add support for another Infineon flashloader

Greg Kroah-Hartman (1):
  Merge tag 'usb-serial-4.8-rc7' of 
git://git.kernel.org/.../johan/usb-serial into usb-linus

Tony Lindgren (1):
  usb: musb: Fix tusb6010 compile error on blackfin

 drivers/usb/core/config.c  | 28 +---
 drivers/usb/musb/Kconfig   |  2 +-
 drivers/usb/serial/usb-serial-simple.c |  3 ++-
 3 files changed, 20 insertions(+), 13 deletions(-)
--
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 v16 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Neil,

Sorry for late reply due yo my holiday.

On 10 September 2016 at 05:19, NeilBrown  wrote:
> On Fri, Sep 09 2016, Baolin Wang wrote:
>
>>>
>>> In practice, the USB PHY and the Power manager will often be in the same
>>> IC (the PMIC) so the driver for one could look at the registers for the
>>> other.
>>> But there is no guarantee that the hardware works like that.  It is
>>> best to create a generally design.
>>
>> Yes, we hope to create one generally design, so we need to consider
>> this situation: the power supply getting the charger type by accessing
>> PMIC registers. The registers which save the charger type are not
>> always belong to the USB PHY, may be just some registers on PMIC.
>
> If the power_supply can directly detect the type of charger, then it
> doesn't need any usb-charger-infrastructure to tell it.  It can handle
> current selection entirely internally.
> Surely the only interesting case for a framework to address is the one
> where the power_supply cannot directly detect the charger type.

But power supply also need one plugged or unplugged event to set
current from USB charger framework. Another hand, considering one
generic framework, since power supply support API (e.g.:
power_supply_get_property()) to get charger type for others, we should
integrate power supply into USB charger framework.

>
>>
>> Now in mainline kernel, there are 3 methods can get the charger type
>> which need to integrate with USB charger framework:
>> 1. power supply
>> 2. extcon (need to add as you suggested)
>> 3. others (by 'get_charger_type' callback of USB charger)
>
> There is no "get_charger_type" now in the mainline kernel.

We want to create one generic framework, thus we should consider some
users want to implement the function to get charger type by accessing
PMIC registers or else.

>

 Suppose the USB configuration requests 100mA, then we should set the
 USB charger current is 100mA by __usb_charger_set_cur_limit_by_type()
 funtion, then notify this to power driver.
>>>
>>> ahh I had missed something there.  It's a while since I looked
>>> closely at these patches.
>>>
>>> Only this usage of usb_charger_set_cur_limit_by_type() is really
>>> nonsensical.
>>>
>>> If the cable is detected as being DCP or CDP or ACA (or ACA/DOCK) then
>>> the number negotiated with the USB configuration is not relevant and
>>> should be ignored.  There is a guaranteed minimum which is at least the
>>> maximum that *can* be negotiated.
>>
>> Yes. If it is not relevant, we will no't set the current from USB
>> configuration. Just when your charger type is SDP and the USB
>> enumeration is done, we can get the USB configuration from host to set
>> current.
>
> But you do!
> The mA number from the USB configuration is passed to usb_gadget_vbus_draw.
> Your patch passes that to usb_charger_set_cur_limit_by_type()
> which calls __usb_charger_set_cur_limit_by_type() which will set the
> cur_limit for whichever type uchger->type currently is.
>
> So when it is not relevant, your code *does* set some current limit.

Suppose the charger type is DCP(it is not relevant to the mA number
from the USB configuration ), it will not do the USB enumeration, then
no USB configuration from host to set current.

-- 
Baolin.wang
Best Regards
--
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

USB hot-plug not working (ASUS TP301UA-C4028T)

[Pierre de Villemereuil]

Dear kernel devs,

I'm using openSUSE Tumbleweed (kernel 4.7.2-2-default) on an ASUS Vivobook 
Flip TP301UA-C4028T, see here for specs:
https://www.asus.com/Notebooks/ASUS-VivoBook-Flip-TP301UA/specifications/

Since my install in July, USB hot-plug (a.k.a. plug'n'play) is not working. To 
make any USB device working (I tested many USB keys, a slideshow remote 
control and a mouse), it has to be plugged on boot up or wake up from suspend. 
Using the following command also make the system aware that USB is connected:
udevadm trigger

More information can be found on the following thread on the openSUSE forums:
https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected

Since, from what I shared on that thread didn't lead anywhere suspicious, the 
guy that helped me there found my problem much curious and encouraged me to 
report this bug to this mailing list.

I'm no IT guys, but I'll happily type any command that could give you more 
input (much of the input is already available in the forum thread).

Hope this will be of any help!

Cheers,
Pierre.
--
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