RE: [PATCH v2] usb: chipidea: Hook into mux framework to toggle usb switch

[Peter Chen]

 
 
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -3,6 +3,8 @@ config USB_CHIPIDEA
>   depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD
> && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
>   select EXTCON
>   select RESET_CONTROLLER
> + select MULTIPLEXER
> + select MUX_GPIO

The above two configurations are only used at your specific platforms, please 
add
them at either your platform defconfig or the related hardware driver's 
Kconfig. 

>   help
> Say Y here if your system has a dual role high speed USB
> controller based on ChipIdea silicon IP. It supports:
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index
> 33ae87f..8fa0991 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -61,6 +61,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "ci.h"
>  #include "udc.h"
> @@ -687,6 +688,10 @@ static int ci_get_platdata(struct device *dev,
>   if (of_find_property(dev->of_node, "non-zero-ttctrl-ttha", NULL))
>   platdata->flags |= CI_HDRC_SET_NON_ZERO_TTHA;
> 
> + platdata->usb_switch = devm_mux_control_get_optional(dev, "usb_switch");
> + if (IS_ERR(platdata->usb_switch))
> + return PTR_ERR(platdata->usb_switch);
> +
>   ext_id = ERR_PTR(-ENODEV);
>   ext_vbus = ERR_PTR(-ENODEV);
>   if (of_property_read_bool(dev->of_node, "extcon")) { diff --git
> a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c index 
> af45aa32..d9d2d00
> 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "../host/ehci.h"
> 
> @@ -161,6 +162,10 @@ static int host_start(struct ci_hdrc *ci)
>   if (ci_otg_is_fsm_mode(ci)) {
>   otg->host = >self;
>   hcd->self.otg_port = 1;
> + } else {
> + ret = mux_control_select(ci->platdata->usb_switch, 1);
> + if (ret)
> + goto disable_reg;

What will happen if ci->platdata->usb_switch  is NULL?

>   }
>   }
> 
> @@ -181,6 +186,8 @@ static void host_stop(struct ci_hdrc *ci)
>   struct usb_hcd *hcd = ci->hcd;
> 
>   if (hcd) {
> + if (!ci_otg_is_fsm_mode(ci))
> + mux_control_deselect(ci->platdata->usb_switch);

Ditto.

>   if (ci->platdata->notify_event)
>   ci->platdata->notify_event(ci,
>   CI_HDRC_CONTROLLER_STOPPED_EVENT);
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index
> 9852ec5..209d3f6 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "ci.h"
>  #include "udc.h"
> @@ -1965,16 +1966,26 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
> 
>  static int udc_id_switch_for_device(struct ci_hdrc *ci)  {
> + int ret = 0;
> +
>   if (ci->is_otg)
>   /* Clear and enable BSV irq */
>   hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
>   OTGSC_BSVIS | OTGSC_BSVIE);
> 
> - return 0;
> + if (!ci_otg_is_fsm_mode(ci))
> + ret = mux_control_select(ci->platdata->usb_switch, 0);
> +

Ditto

> + if (ci->is_otg && ret)
> + hw_write_otgsc(ci, OTGSC_BSVIE | OTGSC_BSVIS,
> OTGSC_BSVIS);
> +
> + return ret;
>  }
> 
>  static void udc_id_switch_for_host(struct ci_hdrc *ci)  {
> + mux_control_deselect(ci->platdata->usb_switch);
> +
>   /*
>* host doesn't care B_SESSION_VALID event
>* so clear and disbale BSV irq
> diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h index
> 07f9936..9ea55a1 100644
> --- a/include/linux/usb/chipidea.h
> +++ b/include/linux/usb/chipidea.h
> @@ -10,6 +10,7 @@
>  #include 
> 
>  struct ci_hdrc;
> +struct mux_control;
> 
>  /**
>   * struct ci_hdrc_cable - structure for external connector cable state 
> tracking @@ -
> 76,6 +77,7 @@ struct ci_hdrc_platform_data {
>   /* VBUS and ID signal state tracking, using extcon framework */
>   struct ci_hdrc_cablevbus_extcon;
>   struct ci_hdrc_cableid_extcon;
> + struct mux_control  *usb_switch;
>   u32 phy_clkgate_delay_us;
 
If CONFIG_USB_CHIPIDEA_HOST is not defined, it may cause build error

Peter
 
--
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 resend] usb: chipidea: Don't select EXTCON

[Peter Chen]

 
>  drivers/usb/chipidea/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig index
> 785f0ed037f7..97509172d536 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -1,7 +1,6 @@
>  config USB_CHIPIDEA
>   tristate "ChipIdea Highspeed Dual Role Controller"
>   depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD
> && !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
> - select EXTCON
>   select RESET_CONTROLLER
>   help
> Say Y here if your system has a dual role high speed USB
> --
> 2.17.0

Hi Jisheng,

Sorry to reply late, are you really care 2KB code side? Since many users use
EXTCON to handle vbus and id, it is hard just delete it. I could accept patch
for your specific platforms, like:

+   select EXTCON if !ARCH_

But please note, even your board uses SoC id/vbus pin to detect related external
signal, the other boards use the same SoC may use external gpios to do it.

Peter
--
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] USB: Increment wakeup count on remote wakeup.

[Ravi Chandra Sadineni]

Hi Alan,
Thanks for reviewing the change. Appreciate your time.  I tried to
address your comments in the V2 of the patch.

On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern  wrote:
> On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:
>
>> On chromebooks we depend on wakeup count to identify the wakeup source.
>> But currently USB devices do not increment the wakeup count when they
>> trigger the remote wake. This patch addresses the same.
>>
>> Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
>>
>> On USB 2.0 devices, a wake capable device, if wake enabled, drives
>> resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
>> The upstream facing port then sets C_PORT_SUSPEND bit and reports a
>> port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
>> has resumed before driving the resume signal from the host and
>> C_PORT_SUSPEND is set, then the device attached to the given port might
>> be the reason for the last system wakeup. Increment the wakeup count for
>> the same.
>>
>> On USB 3.0 devices, a function may signal that it wants to exit from device
>> suspend by sending a Function Wake Device Notification to the host (USB3.0
>> spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
>> wakeup count.
>>
>> Signed-off-by: ravisadin...@chromium.org
>> ---
>>  drivers/usb/core/hcd.c |  1 +
>>  drivers/usb/core/hub.c | 12 ++--
>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index 777036ae63674..79f95a878fb6e 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -2375,6 +2375,7 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
>>  {
>>   unsigned long flags;
>>
>> + pm_wakeup_event(dev, 0);
>
> Instead of dev, you probably want to use hcd->self.sysdev.  Or maybe
> hcd->self.controller, although the difference probably doesn't matter
> for your purposes.

Trying to increment the wakeup count for the roothub. So pointed dev
to >self.root_hub->dev. Hope this is fine.

>
> On the other hand, this wakeup event may already have been counted by
> the host controller's bus subsystem.  Does it matter if the same wakeup
> event gets counted twice?
>
> (This is inevitable with USB devices, in any case.  If a device sends a
> wakeup request, it will be counted for that device, for all the
> intermediate hubs, and for the host controller.)

We are o.k. with the wake-up count getting incremented for the
intermediate hubs. We just want to identify the leaf hid devices, if
they are cause of the remote wake. This way, we can differentiate user
triggered wake from a automatic wakes (Ex: wakes triggered by WOLAN
packets from USB ethernet adapter).

We are also o.k. with the wake-up count getting incremented twice. All
we look for is a change in the wake-up count for the interested
devices.
>
>> @@ -3432,10 +3437,13 @@ int usb_port_resume(struct usb_device *udev, 
>> pm_message_t msg)
>>
>>   usb_lock_port(port_dev);
>>
>> - /* Skip the initial Clear-Suspend step for a remote wakeup */
>>   status = hub_port_status(hub, port1, , );
>> - if (status == 0 && !port_is_suspended(hub, portstatus))
>> + /* Skip the initial Clear-Suspend step for a remote wakeup */
>
> What is the reason for moving the comment line down after the
> hub_port_status() call?
Sorry. This was a mistake. Changed this back in V2.
>
> Alan Stern
>
>> + if (status == 0 && !port_is_suspended(hub, portstatus)) {
>> + if (portchange & USB_PORT_STAT_C_SUSPEND)
>> + pm_wakeup_event(>dev, 0);
>>   goto SuspendCleared;
>> + }
>>
>>   /* see 7.1.7.7; affects power usage, but not budgeting */
>>   if (hub_is_superspeed(hub->hdev))
>>
>

Thanks,
Ravi
--
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] USB: Increment wakeup count on remote wakeup.

[Ravi Chandra Sadineni]

On chromebooks we depend on wakeup count to identify the wakeup source.
But currently USB devices do not increment the wakeup count when they
trigger the remote wake. This patch addresses the same.

Resume condition is reported differently on USB 2.0 and USB 3.0 devices.

On USB 2.0 devices, a wake capable device, if wake enabled, drives
resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
The upstream facing port then sets C_PORT_SUSPEND bit and reports a
port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
has resumed before driving the resume signal from the host and
C_PORT_SUSPEND is set, then the device attached to the given port might
be the reason for the last system wakeup. Increment the wakeup count for
the same.

On USB 3.0 devices, a function may signal that it wants to exit from device
suspend by sending a Function Wake Device Notification to the host (USB3.0
spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
wakeup count.

Signed-off-by: Ravi Chandra Sadineni 
---
 drivers/usb/core/hcd.c |  2 ++
 drivers/usb/core/hub.c | 10 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 777036ae63674..ee0f3ec57ce49 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2374,7 +2374,9 @@ static void hcd_resume_work(struct work_struct *work)
 void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
 {
unsigned long flags;
+   struct device *dev = >self.root_hub->dev;
 
+   pm_wakeup_event(dev, 0);
spin_lock_irqsave (_root_hub_lock, flags);
if (hcd->rh_registered) {
set_bit(HCD_FLAG_WAKEUP_PENDING, >flags);
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f6ea16e9f6bb9..aa9968d90a48c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -653,12 +653,17 @@ void usb_wakeup_notification(struct usb_device *hdev,
unsigned int portnum)
 {
struct usb_hub *hub;
+   struct usb_port *port_dev;
 
if (!hdev)
return;
 
hub = usb_hub_to_struct_hub(hdev);
if (hub) {
+   port_dev = hub->ports[portnum - 1];
+   if (port_dev && port_dev->child)
+   pm_wakeup_event(_dev->child->dev, 0);
+
set_bit(portnum, hub->wakeup_bits);
kick_hub_wq(hub);
}
@@ -3434,8 +3439,11 @@ int usb_port_resume(struct usb_device *udev, 
pm_message_t msg)
 
/* Skip the initial Clear-Suspend step for a remote wakeup */
status = hub_port_status(hub, port1, , );
-   if (status == 0 && !port_is_suspended(hub, portstatus))
+   if (status == 0 && !port_is_suspended(hub, portstatus)) {
+   if (portchange & USB_PORT_STAT_C_SUSPEND)
+   pm_wakeup_event(>dev, 0);
goto SuspendCleared;
+   }
 
/* see 7.1.7.7; affects power usage, but not budgeting */
if (hub_is_superspeed(hub->hdev))
-- 
2.13.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: ConfigFS, FunctionFS, and MS XInput

[Daniel Hefti]

Thanks for your feedback!  I think I'm beginning to better understand 
what's going on. When I originally got the X360-emulated device working 
on the loopback interface, I left out several class descriptors and an 
interface with no endpoints (but has a vendor-specific descriptor 
following it).  Reason being, whenever I attempted to add those 
descriptors (either by pushing the bytes manually or creating a 
descriptor-like struct and pushing that (effectively the same thing)) to 
endpoint 0, I would get: OSError 22: Invalid Argument.


Here's the 4 class & vendor descriptors in question:

1: [17,33,0,1,1,37,129,20,0,0,0,0,19,2,8,0,0,]
2: [27,33,0,1,1,1,131,64,1,4,32,22,133,0,0,0,0,0,0,22,5,0,0,0,0,0,0,]
3: [9,33,0,1,1,34,134,7,0,]
4: [6,65,0,1,1,3]

They're all after an interface descriptor and before their endpoint 
descriptors.


So, that's my current roadblock.  I don't know how to send those.  Can 
you/someone help describe to me how (or where I can find out how) I can 
do so?  (Sending class/vendor descriptors and interfaces with no 
endpoints.)  Is that something I can do with FunctionFS?


Mean time.  I'm going to be looking over the generic XInput device 
again, but I may end up running into the same problem there.



On 4/17/2018 8:56 AM, Krzysztof Opasiak wrote:



On 04/17/2018 04:03 AM, Daniel Hefti wrote:

Hey guys,

I've been banging my head against the wall for a couple of days trying 
to get a Raspberry Pi 0W to talk to Windows (8.1/10) as an XInput game 
controller using ConfigFS and FunctionFS, having little success.  I've 
tried to build both a generic XInput device and one that attempts to 
emulate an X360 controller.  The X360 controller seems to get 
"further", in that Windows says it recognizes the device and the 
drivers are working.  Whatever that means.  The generic version just 
shows up as an unrecognized device (with the name I've given it).  
Neither are getting or able to send any data from/to their respective 
endpoints.  The X360 version, I tested locally via loopback/dummy UDC, 
and the xboxdrv driver can detect and read controller state 
messages/reports I send it, so at least that much works.  Not sure 
what I could possibly be missing.


I can say I've successfully created HID USB game controller devices. 
Those are accessible from Windows, but, unfortunately, many Windows 
games don't support HID particularly well, and I'm trying to avoid 
someone having to use something like XOutput as a workaround to get 
this device to work.


I do have Wireshark with USBPCap installed, so I can at least capture 
some of the data, which I did, but  it wasn't really leading me 
anywhere, possibly due to my lack of knowledge in this particular 
subject.  Unfortunately, I didn't save my pcap results.  I'll likely 
end up doing it again once I've given my head some time to heal.


Any insights?  References?  Something you think could help guide me in 
the right direction?  There's plenty of documentation and example 
implementations out there for HID devices, but not so much for XInput 
devices and functionfs in general, so any help would be greatly 
appreciated!


Did you check that you provided all drivers that a physical device does?
Maybe windows requires correct OS descriptors for that device?
That's just some guesses...


--
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/1] usb: core: Add quirk for HP v222w 16GB Mini

[sathyanarayanan . kuppuswamy]

From: Kamil Lulko 

Add DELAY_INIT quirk to fix the following problem with HP
v222w 16GB Mini:

usb 1-3: unable to read config index 0 descriptor/start: -110
usb 1-3: can't read configurations, error -110
usb 1-3: can't set config #1, error -110

Signed-off-by: Kamil Lulko 
Signed-off-by: Kuppuswamy Sathyanarayanan 

---

Changes since v1:
 * Fixed indentation.

 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 920f48a..c55def2 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -186,6 +186,9 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x03f0, 0x0701), .driver_info =
USB_QUIRK_STRING_FETCH_255 },
 
+   /* HP v222w 16GB Mini USB Drive */
+   { USB_DEVICE(0x03f0, 0x3f40), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Creative SB Audigy 2 NX */
{ USB_DEVICE(0x041e, 0x3020), .driver_info = USB_QUIRK_RESET_RESUME },
 
-- 
2.7.4

--
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 regression for Android phone and sound card in 4.14

[Nazar Mokrynskyi]

Still an issue as of 4.17-rc1 for sound card.

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

17.03.18 19:04, Nazar Mokrynskyi пише:
> With kernel 4.16-rc5 it is still happening to USB sound card, Android phone 
> issue was probably related to something else and is already fixed.
>
> Very annoying to unplug sound card after each reboot, any ideas why this 
> might happen?
>
> Sincerely, Nazar Mokrynskyi
> github.com/nazar-pc
>
> 13.02.18 01:26, Nazar Mokrynskyi пише:
>> Starting from 4.14 and continuing in 4.15 I observe 2 bugs that I think are 
>> related and didn't exist in 4.13.
>>
>> The first would be more difficult to reproduce: USB sound card Creative SB 
>> Omni Surround 5.1 after system boot only shows 2.0 stereo output option, 
>> while it also supports 5.1 and PulseAudio configured accordingly. If unplug 
>> and plug it back in, 5.1 mode appears and I can select between 2.0 and 5.1. 
>> You can boot with stock Ubuntu 17.10 and 18.04 as of right now and the first 
>> one will work properly and second one will have mentioned bug.
>>
>> Second bug is easier to reproduce: when connecting Nexus 6P via USB cable, 
>> it appears in file manager devices list (Nemo, Nautilus, etc.), but when it 
>> is unplugged it doesn't disappear when running kernels 4.14 and 4.15. I have 
>> 7 Nexus 6P entries already, unplugging and plugging back looks like this:
>>
>> [200038.821988] usb 3-1: new high-speed USB device number 4 using xhci_hcd
>> [200039.043611] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>> [200039.043612] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [200039.043614] usb 3-1: Product: Nexus 6P
>> [200039.043614] usb 3-1: Manufacturer: Huawei
>> [200039.043615] usb 3-1: SerialNumber: 8XV7N1612893
>> [202243.949672] usb 3-1: USB disconnect, device number 4
>> [205549.671959] usb 3-1: new high-speed USB device number 5 using xhci_hcd
>> [205549.893327] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>> [205549.893328] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [205549.893329] usb 3-1: Product: Nexus 6P
>> [205549.893329] usb 3-1: Manufacturer: Huawei
>> [205549.893330] usb 3-1: SerialNumber: 8XV7N1612893
>> [205550.602646] usb 3-1: USB disconnect, device number 5
>> [205553.456007] usb 3-1: new high-speed USB device number 6 using xhci_hcd
>> [205553.680392] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>> [205553.680394] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [205553.680394] usb 3-1: Product: Nexus 6P
>> [205553.680395] usb 3-1: Manufacturer: Huawei
>> [205553.680396] usb 3-1: SerialNumber: 8XV7N1612893
>> [206021.635511] usb 3-1: USB disconnect, device number 6
>> [206024.169853] usb 3-1: new high-speed USB device number 7 using xhci_hcd
>> [206024.392921] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>> [206024.392923] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [206024.392924] usb 3-1: Product: Nexus 6P
>> [206024.392925] usb 3-1: Manufacturer: Huawei
>> [206024.392925] usb 3-1: SerialNumber: 8XV7N1612893
>> [206034.058208] usb 3-1: USB disconnect, device number 7
>> [206036.914005] usb 3-1: new high-speed USB device number 8 using xhci_hcd
>> [206037.136891] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>> [206037.136893] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [206037.136894] usb 3-1: Product: Nexus 6P
>> [206037.136895] usb 3-1: Manufacturer: Huawei
>> [206037.136895] usb 3-1: SerialNumber: 8XV7N1612893
>> [206080.923547] usb 3-1: USB disconnect, device number 8
>> [206083.526585] usb 3-1: new high-speed USB device number 9 using xhci_hcd
>> [206083.752601] usb 3-1: New USB device found, idVendor=18d1, idProduct=4ee1
>> [206083.752602] usb 3-1: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=3
>> [206083.752603] usb 3-1: Product: Nexus 6P
>> [206083.752604] usb 3-1: Manufacturer: Huawei
>> [206083.752605] usb 3-1: SerialNumber: 8XV7N1612893
>>
>> These 2 issues appeared at the same time, so I think they are related.
>> Let me know if you can't reproduce them and need any additional information 
>> and CC me on answers as I'm not subscribed to this mailing list.
>>
--
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 0/3] USB: musb: dsps: phy fix and DT-topology support

[Martin Blumenstingl]

Hello Johan,

On Thu, Apr 19, 2018 at 9:43 AM, Johan Hovold  wrote:
> On Wed, Apr 18, 2018 at 09:18:30PM +0200, Martin Blumenstingl wrote:
>> Hi Johan,
>>
>> On Fri, Apr 13, 2018 at 5:15 PM, Johan Hovold  wrote:
>> > I've been carrying a patch out-of-tree since my work on improving the
>> > USB device-tree support which is needed to be able to describe USB
>> > topologies for musb based controllers.
>> >
>> > This patch, which associates the platform controller device with the
>> > glue device device-tree node, did not play well with the recent changes
>> > which added generic phy support to USB core however.
>> I'm the one who added this
>>
>> > Like the recent dwc2 regression fixed by Arnd after the device-tree
>> > #phy-cell changes, the generic phy code in USB core can now also fail
>> > indefinitly with -EPROBE_DEFER when the controller uses a legacy USB
>> > phy.
>> >
>> > The second patch addresses this for musb, which handles its own (legacy
>> > and generic) phys, but something more may possibly now be needed for
>> > other platforms with legacy phys.
>> I'm not sure if I understand the problem yet - could you please
>> explain with your words what "legacy PHYs" are and how the "conflict"
>> with the PHY handling in USB core?
>>
>> I am aware of two PHY subsystems:
>> - drivers/phy
>> -- also called "generic PHY framework"
>> -- uses a "phys" property
>
> Right, and these are sometimes referred to as generic PHYs, as opposed
> to...
>
>> - drivers/usb/phy
>> -- also called "USB PHY framework"
>> -- AFAIK this should not be used for new drivers
>
> ...the legacy ones.
>
>> -- uses an "usb-phy" property
>
> This is unfortunately not always the case however; some legacy USB phys
> are also referred to using a "phys" property...
oh, I was not aware of that. this explains the issue you're seeing...
thank you for the explanation!

>> the new PHY handling in USB core only parses the "phys" property and
>> thus should not conflict with "usb-phy" (the legacy property)
>
>> however, I probably missed something so I'd appreciate an explanation
>> how things can break
>
> ...and that is the problem. Specifically, since last fall when a number
> of legacy-phy nodes had a #phy-cells property added to them (to silence
> DTC warnings), the generic PHY subsubsystem can now return -EPROBE_DEFER
> indefinitely when looking up a phy as it finds a matching device-tree
> node, but for which there will never be a generic phy registered (since
> it's handled by a legacy-phy driver).
>
> I referred to Arnd's workaround for "usb-nop-xceiv" devices
>
> b7563e2796f8 ("phy: work around 'phys' references to
> usb-nop-xceiv devices")
>
> which has some more background on this.
thank you for this pointer too

> So if we have any other host controllers out there using
> "phys"-properties with legacy phys other than "usb-nop-xceiv", then
> these will now fail to register (with -EPROBE_DEFER) unless
> hcd->skip_phy_initialization is set (or we blacklist them as well in the
> generic phy code).
>
> I'm not aware of any further examples, but we're sure to find out soon
> enough if there are.
>
> Perhaps we should blacklist also "ti,am335x-usb-phy" in the generic phy
> code even if hcd->skip_phy_initialization is still needed for musb for
> the time being anyway.
>
> Johan


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

REPLY ME

[Abdul Salif]

Dear Friend,

Compliments of the day. I hope that this letter does not surprise you
because we have not met. However, I urge you to treat the information
with it's contains with due and utmost attention. Apart from being
eternally grateful to you, I also assure that you shall be adequately
compensated.

My name is Abdul Salif an attorney at law, I am the only registered
attorney to Late business tycoon Eng. Sallas Adams Who died with the
entire family in an auto crash on the 29th october 2006 in
Ouagadougou, the capital of Burkina Faso and While he was alive,he
deposited huge sum of amount with a Security Company in here,valued
$10.5 Million (Ten Million five hundred thousand us dollars).

The Security Company have informed me that the demurrage on the
consignment has risen so high and they have called to inform my client
to come forward to claim his consignment without knowing that my
client is dead. I am planning to present you to the company as the
beneficiary to the consignment.

If you agree,we can arrange the moderlities of sharing the money as
soon the consignment is released. 40% to you while 60% for me. You can
forward your informations like your full names and address, Telephone
and Fax numbers.

All I require is your honest co-operation to enable us accomplish this
transaction.I guarantee you that this will be executed under a
legitimate arrangement that will protect you from any breach of the
law.


I await for your urgent response.
Yours Faithfully,
Abdul Salif
--
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/4] usb: gadget: composite: add function to increment delayed_status

[Laurent Pinchart]

Hi Paul,

(CC'ing Felipe Balbi and Roger Quadros)

Thank you for the patch.

Have you used scripts/get_maintainer.pl ? It should point you to Felipe Balbi, 
the maintainer of the USB gadget subsystem, who I recommend you CC, at least 
on patch 2/4. The script also points to Greg, who I don't think needs to be 
CC'ed as he doesn't deal with USB gadget as much as with USB in general, and 
who is fairly busy as usual.

While the get_maintainer script doesn't point to Roger, his name can be found 
as the author of the USB_GADGET_DELAYED_STATUS mechanism. He authored commit 
1b9ba000177e ("usb: gadget: composite: Allow function drivers to pause control 
transfers") with his nokia.com address back then, but git log --author 'Roger 
Quadros' shows that he's still active on USB and working for TI now. I've thus 
CC'ed him on this reply.

On Wednesday, 18 April 2018 06:18:14 EEST Paul Elder wrote:
> The completion of the usb status phase from uvc_function_set_alt needs
> to be delayed until uvc_v4l2_streamon/off. This is currently done by
> uvc_function_set_alt returning USB_GADGET_DELAYED_STATUS and
> composite_setup detecting this to increment cdev->delayed_status.
> However, if uvc_v4l2_streamon/off is called in between this return and
> increment, uvc_function_setup_continue within uvc_v4l2_streamon/off will
> WARN that cdev->delayed_status is zero.

While this is correct, I wouldn't mention UVC here as the patch is for the USB 
composite gadget framework and isn't specific to UVC. You should write a more 
generic explanation of the problem to explain why the race between returning 
USB_GADGET_DELAYED_STATUS (and processing it in the caller) and calling 
usb_composite_setup_continue() can't be properly solved in gadget drivers, 
thus requiring a new function.

> To fix situations like this, add a function to increment
> cdev->delayed_status.
> 
> Signed-off-by: Paul Elder 
> ---
>  drivers/usb/gadget/composite.c | 6 ++
>  include/linux/usb/composite.h  | 2 ++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> index 77c7ecca816a..c02ab640a7ae 100644
> --- a/drivers/usb/gadget/composite.c
> +++ b/drivers/usb/gadget/composite.c
> @@ -1548,6 +1548,12 @@ static int fill_ext_prop(struct usb_configuration *c,
> int interface, u8 *buf) return 0;
>  }
> 
> +void usb_composite_setup_delay(struct usb_composite_dev *cdev)
> +{
> + cdev->delayed_status++;

According to include/linux/usb/composite.h, the delayed_status field should be 
protected by cdev->lock, which you should use here.

I've read through the code and found out that, while all callers of 
reset_config(), as well as usb_composite_setup_continue(), correctly take the 
lock, it isn't taken around f->set_alt() in composite_setup(). This causes the 
race condition. I wonder if a simpler fix wouldn't be to take the lock before 
calling f->set_alt() and releasing it after incrementing delayed_status. I am 
however worried that this could lead to deadlocks if one of the existing 
set_alt() handlers calls a function that takes the same lock. Another worry 
is that some of the .set_alt() handlers might not expect to be called with 
interrupts disabled. This should be analyzed, and I hope that Roger and/or 
Felipe will have some insight on this.

If usb_composite_setup_delay() turns out to be the preferred solution, it 
would be nice to document the function with kerneldoc.

Finally, I just came to wonder whether the UVC gadget driver really needs to 
defer the status phase of the SET_INTERFACE request, or if it couldn't just 
proceed normally.

> +}
> +EXPORT_SYMBOL(usb_composite_setup_delay);
> +
>  /*
>   * The setup() callback implements all the ep0 functionality that's
>   * not handled lower down, in hardware or the hardware driver(like
> diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
> index cef0e44601f8..049f77a4d42b 100644
> --- a/include/linux/usb/composite.h
> +++ b/include/linux/usb/composite.h
> @@ -524,6 +524,8 @@ extern int composite_setup(struct usb_gadget *gadget,
>  extern void composite_suspend(struct usb_gadget *gadget);
>  extern void composite_resume(struct usb_gadget *gadget);
> 
> +extern void usb_composite_setup_delay(struct usb_composite_dev *c);
> +
>  /*
>   * Some systems will need runtime overrides for the  product identifiers
>   * published in the device descriptor, either numbers or strings or both.

-- 
Regards,

Laurent Pinchart



--
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 0/5] usb: gadget: uvc: fix racing between uvc_function_set_alt and streamon/off

[Laurent Pinchart]

Hi Paul,

Thank you for the patch series. I believe you've already noticed that the 
subject line of the cover letter should have mentioned 0/4 instead of 0/5.

On Wednesday, 18 April 2018 06:20:15 EEST Paul Elder wrote:
> Down the call stack from the ioctl handler for VIDIOC_STREAMON,
> uvc_video_alloc_requests contains a BUG_ON, which in the high level,
> triggers when VIDIOC_STREAMON ioctl is issued without VIDIOC_STREAMOFF
> being issued previously.
> 
> This can happen in a few ways, such as if the userspace uvc gadget
> application simply doesn't issue VIDIOC_STREAMOFF. Another way is if
> uvc_function_set_alt with alt 0 is called after it is called with 1 but
> before VIDIOC_STREAMON is called; in this case, UVC_EVENT_STREAMON will

I assume you meant UVC_EVENT_STREAMOFF here.

> not be queued to userspace, and therefore userspace will never call
> VIDIOC_STREAMOFF.
> 
> To fix this, add two more uvc states: starting and stopping. The
> starting state starts when uvc_function_set_alt 1 is called, and ends
> in uvc_v4l2_streamon, when the state is changed to streaming.

Nitpicking, as we're talking about states, I would say "is entered" instead of 
"starts" and "is exited" instead of "ends".

> The stopping state starts when uvc_function_set_alt 0 is called, and ends
> in uvc_v4l2_streamoff, when the state is changed to connected.
> 
> Along with this fix, the completion of the usb status phase needs to be
> delayed until uvc_v4l2_streamon/off. This is already the case for
> uvc_function_set_alt 1, so add this to when alt is 0. However, the
> delayed_status is only incremented when this function returns, so if
> uvc_v4l2_streamon/off is called in between returning and incrementing,
> then uvc_function_setup_continue will WARN that delayed_status is zero.
> 
> To fix this, add and use usb_composite_setup_delay,
> which increments the delayed_status. Then, uvc_function_set_alt
> returns 0 instead of USB_GADGET_DELAYED_STATUS.
> 
> Finally, there is another way to trigger the aforementioned BUG: start
> streaming and (physically) disconnect usb. To fix this, call
> uvcg_video_enable 0 in uvc_function_disable.

This is a clear and detailed cover letter, good job ! I'll review the 
individual patches now.

> Paul Elder (4):
>   usb: gadget: uvc: synchronize streamon/off with uvc_function_set_alt
>   usb: gadget: composite: add function to increment delayed_status
>   usb: gadget: uvc: synchronize usb status phase delay for
> uvc_function_set_alt
>   usb: gadget: uvc: disable stream when disconnected
> 
>  drivers/usb/gadget/composite.c |  6 ++
>  drivers/usb/gadget/function/f_uvc.c| 24 +---
>  drivers/usb/gadget/function/uvc.h  |  2 ++
>  drivers/usb/gadget/function/uvc_v4l2.c | 21 +++--
>  include/linux/usb/composite.h  |  2 ++
>  5 files changed, 50 insertions(+), 5 deletions(-)

-- 
Regards,

Laurent Pinchart



--
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/3] usb: gadget: configfs: Create control_config group

[Krzysztof Opasiak]

On 19.04.2018 21:02, Jerry Zhang wrote:
[...]



As main usecase for this code is FunctionFS I think that we should
consider adding some flag to FunctionFS to mark instance as only for
such purpouse. I mean sth like FFS_CONTROL_ONLY which would make
FunctionFS igore the descs (or allow to provide 0 of them) and make this
function usable only for this purpouse (disallow linking to real config
and allow only for linking to this fake one).

I'm not sure what you mean the purpose of the flag to be. Would it be
required for it to handle requests (so both ALL_CTRL and CONTROL_ONLY must
be enabled)? Since userspace already has to link the functions, this seems
more like an "are you sure?" switch as opposed to providing concrete
functionality.
Unless you mean that it wouldn't be required, but allowed in order for user
to write no descriptors. Ffs allows for pretty bare bones descriptors
already (1 speed, 1 interface, with no endpoints). If we want to allow 0
speeds to be provided we might as well allow that generally. It wouldn't be
useful in most cases, but that is similar to providing no endpoints anyway.


The purpose would be:
1) Allow writing no descriptors (maybe also skip the strings) when this 
flag is set

2) Disallow linking such an instance to real configuration
3) Disallow linking real function implementation to our "magic config"

Obviously you are right that it's not required but this improves 
usability. Even now our ConfigFS interface is pretty complicated and 
gives user many chances for "silent misconfiguration". It would be nice 
to protect user against stupid and very hard to debug mistakes rather 
than giving this child even more weapon;)


Best regards,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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/3] usb: gadget: configfs: Create control_config group

[Jerry Zhang]

> [...]
> >
> > + cfg = >control_config;
> > + c = >c;
> > + list_for_each_entry_safe(f, tmp, >func_list, list) {
> > + if (f->req_match && f->setup) {
> > + list_del(>list);
> > + if (usb_add_function(>c, f))
> > + list_add(>list, >func_list);
> > + }
> > + }

> shouldn't we goto error here instead of silently ignoring error?
yeah you're right


> > +
> >   usb_ep_autoconfig_reset(cdev->gadget);
> >   return 0;
> >
> > @@ -1391,11 +1407,33 @@ static void configfs_composite_unbind(struct
usb_gadget *gadget)
> >   set_gadget_data(gadget, NULL);
> >   }
> >
> > +static int configfs_composite_setup(struct usb_gadget *gadget,
> > + const struct usb_ctrlrequest *c)
> > +{
> > + struct usb_composite_dev *cdev = get_gadget_data(gadget);
> > + struct gadget_info *gi = container_of(cdev, struct gadget_info,
cdev);
> > +
> > + struct config_usb_cfg *cfg = >control_config;
> > + struct usb_function *f;
> > + int value = composite_setup(gadget, c);

> I think it would be more readable if you call this function later in the
> code instead of during initialization of variable.
ack


> > +
> > + if (value >= 0)
> > + return value;
> > +
> > + list_for_each_entry(f, >c.functions, list) {
> > + if (f->req_match(f, c, false)) {
> > + value = f->setup(f, c);
> > + break;
> > + }
> > + }
> > + return value;
> > +}
> > +
> >   static const struct usb_gadget_driver configfs_driver_template = {
> >   .bind   = configfs_composite_bind,
> >   .unbind = configfs_composite_unbind,
> >
> > - .setup  = composite_setup,
> > + .setup  = configfs_composite_setup,
> >   .reset  = composite_disconnect,
> >   .disconnect = composite_disconnect,
> >
> > @@ -1461,6 +1499,18 @@ static struct config_group *gadgets_make(
> >   if (!gi->composite.gadget_driver.function)
> >   goto err;
> >
> > + gi->control_config.c.label = "control_config";
> > + /* composite requires some value, but it doesn't matter */
> > + gi->control_config.c.bConfigurationValue = 42;
> > + INIT_LIST_HEAD(>control_config.func_list);
> > + config_group_init_type_name(>control_config.group,
> > + "control_config", _config_type);
> > + configfs_add_default_group(>control_config.group, >group);
> > +
> > + if (usb_add_config_only(>cdev, >control_config.c))
> > + goto err;
> > + list_del(>control_config.c.list);
> > +

> I know that you are trying to reuse as much code as possible but in my
> humble opinion we should make a separate config_item_type for this to
> drop things related to string bMaxPower etc as all those values are then
> later ignored in the kernel so it looks like it doesn't make any sense
> to allow users to set them.
Fair enough. I was debating between the two but chose this route to get my
patch out faster


> As main usecase for this code is FunctionFS I think that we should
> consider adding some flag to FunctionFS to mark instance as only for
> such purpouse. I mean sth like FFS_CONTROL_ONLY which would make
> FunctionFS igore the descs (or allow to provide 0 of them) and make this
> function usable only for this purpouse (disallow linking to real config
> and allow only for linking to this fake one).
I'm not sure what you mean the purpose of the flag to be. Would it be
required for it to handle requests (so both ALL_CTRL and CONTROL_ONLY must
be enabled)? Since userspace already has to link the functions, this seems
more like an "are you sure?" switch as opposed to providing concrete
functionality.
Unless you mean that it wouldn't be required, but allowed in order for user
to write no descriptors. Ffs allows for pretty bare bones descriptors
already (1 speed, 1 interface, with no endpoints). If we want to allow 0
speeds to be provided we might as well allow that generally. It wouldn't be
useful in most cases, but that is similar to providing no endpoints anyway.

--Jerry
--
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/3] usb: gadget: configfs: Create control_config group

[Krzysztof Opasiak]

On 17.04.2018 03:17, Jerry Zhang wrote:
[...]
  
+	cfg = >control_config;

+   c = >c;
+   list_for_each_entry_safe(f, tmp, >func_list, list) {
+   if (f->req_match && f->setup) {
+   list_del(>list);
+   if (usb_add_function(>c, f))
+   list_add(>list, >func_list);
+   }
+   }


shouldn't we goto error here instead of silently ignoring error?


+
usb_ep_autoconfig_reset(cdev->gadget);
return 0;
  
@@ -1391,11 +1407,33 @@ static void configfs_composite_unbind(struct usb_gadget *gadget)

set_gadget_data(gadget, NULL);
  }
  
+static int configfs_composite_setup(struct usb_gadget *gadget,

+   const struct usb_ctrlrequest *c)
+{
+   struct usb_composite_dev *cdev = get_gadget_data(gadget);
+   struct gadget_info *gi = container_of(cdev, struct gadget_info, cdev);
+
+   struct config_usb_cfg *cfg = >control_config;
+   struct usb_function *f;
+   int value = composite_setup(gadget, c);


I think it would be more readable if you call this function later in the 
code instead of during initialization of variable.



+
+   if (value >= 0)
+   return value;
+
+   list_for_each_entry(f, >c.functions, list) {
+   if (f->req_match(f, c, false)) {
+   value = f->setup(f, c);
+   break;
+   }
+   }
+   return value;
+}
+
  static const struct usb_gadget_driver configfs_driver_template = {
.bind   = configfs_composite_bind,
.unbind = configfs_composite_unbind,
  
-	.setup  = composite_setup,

+   .setup  = configfs_composite_setup,
.reset  = composite_disconnect,
.disconnect = composite_disconnect,
  
@@ -1461,6 +1499,18 @@ static struct config_group *gadgets_make(

if (!gi->composite.gadget_driver.function)
goto err;
  
+	gi->control_config.c.label = "control_config";

+   /* composite requires some value, but it doesn't matter */
+   gi->control_config.c.bConfigurationValue = 42;
+   INIT_LIST_HEAD(>control_config.func_list);
+   config_group_init_type_name(>control_config.group,
+   "control_config", _config_type);
+   configfs_add_default_group(>control_config.group, >group);
+
+   if (usb_add_config_only(>cdev, >control_config.c))
+   goto err;
+   list_del(>control_config.c.list);
+


I know that you are trying to reuse as much code as possible but in my 
humble opinion we should make a separate config_item_type for this to 
drop things related to string bMaxPower etc as all those values are then 
later ignored in the kernel so it looks like it doesn't make any sense 
to allow users to set them.


As main usecase for this code is FunctionFS I think that we should 
consider adding some flag to FunctionFS to mark instance as only for 
such purpouse. I mean sth like FFS_CONTROL_ONLY which would make 
FunctionFS igore the descs (or allow to provide 0 of them) and make this 
function usable only for this purpouse (disallow linking to real config 
and allow only for linking to this fake one).


Best regards,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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: NULL pointer dereference in xhci_suspend

[Nazar Mokrynskyi]

19.04.18 14:17, Mathias Nyman пише:
> On 18.04.2018 20:30, Nazar Mokrynskyi wrote:
>> Hi everyone, I'm running a VM using libvirt on kernel 4.15 (Ubuntu 18.04).
>>
>> ASMedia USB 3.1 Gen 2 controller is assigned to VM like this:
>>
>>  
>>    
>>  
>>    
>>    
>>    > function='0x0'/>
>>  
>>
>> Occasionally VM start fails with following error and I'm unable to start a 
>> VM anymore until reboot:
>>
>> [40061.976095] BUG: unable to handle kernel NULL pointer dereference at 
>> 0228
>> [40061.976107] IP: xhci_suspend+0x3a/0x490
>> [40061.976109] PGD 0 P4D 0
>> [40061.976115] Oops:  [#1] SMP PTI
>> [40061.976118] Modules linked in: cpuid vhost_net vhost tap vfio_pci 
>> vfio_virqfd vfio_iommu_type1 vfio xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
>> nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
>> nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 
>> xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables 
>> devlink iptable_filter binfmt_misc snd_hda_codec_hdmi intel_rapl 
>> x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass 
>> intel_cstate nls_iso8859_1 mxm_wmi snd_hda_intel snd_usb_audio snd_hda_codec 
>> snd_usbmidi_lib snd_hda_core snd_rawmidi snd_hwdep snd_seq_device joydev 
>> input_leds intel_rapl_perf snd_pcm cdc_acm snd_timer snd mei_me soundcore 
>> mei shpchp wmi nvidia_uvm(POE) acpi_pad mac_hid sch_fq_codel lp parport bfq 
>> ip_tables
>> [40061.976185]  x_tables autofs4 btrfs xor zstd_compress raid6_pq 
>> algif_skcipher af_alg dm_crypt hid_generic usbhid hid uas usb_storage 
>> crct10dif_pclmul crc32_pclmul nvidia_drm(POE) ghash_clmulni_intel 
>> nvidia_modeset(POE) pcbc i915 nvidia(POE) aesni_intel aes_x86_64 crypto_simd 
>> i2c_algo_bit glue_helper cryptd drm_kms_helper e1000e syscopyarea 
>> sysfillrect sysimgblt fb_sys_fops ptp nvme pps_core drm nvme_core ahci 
>> ipmi_devintf libahci ipmi_msghandler video
>> [40061.976230] CPU: 7 PID: 29745 Comm: kworker/7:0 Tainted: P   OE   
>>  4.15.0-17-generic #18-Ubuntu
>> [40061.976232] Hardware name: Micro-Star International Co., Ltd. 
>> MS-7B45/Z370 GAMING PRO CARBON (MS-7B45), BIOS A.51 03/29/2018
>> [40061.976239] Workqueue: pm pm_runtime_work
>> [40061.976245] RIP: 0010:xhci_suspend+0x3a/0x490
>> [40061.976248] RSP: 0018:a5dca0747c40 EFLAGS: 00010246
>> [40061.976252] RAX: ffea RBX: 913dc3106000 RCX: 
>> 
>> [40061.976254] RDX:  RSI: 0001 RDI: 
>> 913dc3106230
>> [40061.976257] RBP: a5dca0747c78 R08:  R09: 
>> a5dca0747db8
>> [40061.976259] R10:  R11: 01cc R12: 
>> 913dc3106000
>> [40061.976262] R13: 913dc3106000 R14: 913dc3106230 R15: 
>> b86efaa0
>> [40061.976265] FS:  () GS:913e2e7c() 
>> knlGS:
>> [40061.976268] CS:  0010 DS:  ES:  CR0: 80050033
>> [40061.976271] CR2: 0228 CR3: 00031460a003 CR4: 
>> 003606e0
>> [40061.976274] DR0:  DR1:  DR2: 
>> 
>> [40061.976276] DR3:  DR6: fffe0ff0 DR7: 
>> 0400
>> [40061.976278] Call Trace:
>> [40061.976286]  ? pci_pm_runtime_resume+0xa0/0xa0
>> [40061.976292]  xhci_pci_suspend+0x5a/0xd0
>> [40061.976297]  suspend_common+0x85/0x160
>> [40061.976302]  hcd_pci_runtime_suspend+0x1b/0x50
>> [40061.976306]  pci_pm_runtime_suspend+0x64/0x180
>> [40061.976311]  ? pci_pm_runtime_resume+0xa0/0xa0
>> [40061.976315]  __rpm_callback+0xca/0x210
>> [40061.976320]  ? __switch_to_asm+0x34/0x70
>> [40061.976324]  ? __switch_to_asm+0x40/0x70
>> [40061.976329]  rpm_callback+0x24/0x80
>> [40061.976333]  ? pci_pm_runtime_resume+0xa0/0xa0
>> [40061.976338]  rpm_suspend+0x137/0x640
>> [40061.976343]  rpm_idle+0x58/0x2a0
>> [40061.976348]  pm_runtime_work+0x92/0xa0
>> [40061.976353]  process_one_work+0x1de/0x410
>> [40061.976357]  worker_thread+0x32/0x410
>> [40061.976362]  kthread+0x121/0x140
>> [40061.976366]  ? process_one_work+0x410/0x410
>> [40061.976371]  ? kthread_create_worker_on_cpu+0x70/0x70
>> [40061.976376]  ? do_syscall_64+0x73/0x130
>> [40061.976380]  ? SyS_exit_group+0x14/0x20
>> [40061.976383]  ret_from_fork+0x35/0x40
>> [40061.976387] Code: 41 54 53 48 83 ec 10 4c 8b 2f 41 8b 85 28 02 00 00 85 
>> c0 0f 84 d1 01 00 00 83 f8 04 0f 85 51 04 00 00 48 8b 57 08 b8 ea ff ff ff 
>> <83> ba 28 02 00 00 04 0f 85 04 01 00 00 41 89 f6 49 89 fc e8 9e
>> [40061.976443] RIP: xhci_suspend+0x3a/0x490 RSP: a5dca0747c40
>> [40061.976445] CR2: 0228
>> [40061.976449] ---[ end trace 5f17622537522ef8 ]---
>>
>> Nothing was attached to this controller when error happened.
>
> Looks like xhci controller was runtime suspended before everything was set up.
>
> Normally PCI core will enable runtime pm, forbid it, and increase usage 
> counter (0 -> 1) before 

Re: [PATCH] net: qmi_wwan: add Wistron Neweb D19Q1

[David Miller]

From: Pawel Dembicki 
Date: Wed, 18 Apr 2018 16:03:24 +0200

> This modem is embedded on dlink dwr-960 router.
> The oem configuration states:
 ...
> Tested on openwrt distribution
> 
> Signed-off-by: Pawel Dembicki 

Applied and queued up for -stable.
--
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 v4 2/3] lan78xx: Read LED states from Device Tree

[Phil Elwell]

Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:

0=link/activity  1=link1000/activity
2=link100/activity   3=link10/activity
4=link100/1000/activity  5=link10/1000/activity
6=link10/100/activity14=off15=on

These values are given symbolic constants in a dt-bindings header.

Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.

Signed-off-by: Phil Elwell 
Reviewed-by: Andrew Lunn 
---
 MAINTAINERS |  1 +
 drivers/net/phy/microchip.c | 25 ++
 drivers/net/usb/lan78xx.c   | 32 -
 include/dt-bindings/net/microchip-lan78xx.h | 21 +++
 include/linux/microchipphy.h|  3 +++
 5 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d..23735d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14573,6 +14573,7 @@ M:  Microchip Linux Driver Support 

 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/usb/lan78xx.*
+F: include/dt-bindings/net/microchip-lan78xx.h
 
 USB MASS STORAGE DRIVER
 M: Alan Stern 
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 0f293ef..ef5e160 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
 #define DRIVER_DESC"Microchip LAN88XX PHY driver"
@@ -70,6 +72,8 @@ static int lan88xx_probe(struct phy_device *phydev)
 {
struct device *dev = >mdio.dev;
struct lan88xx_priv *priv;
+   u32 led_modes[4];
+   int len;
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -77,6 +81,27 @@ static int lan88xx_probe(struct phy_device *phydev)
 
priv->wolopts = 0;
 
+   len = of_property_read_variable_u32_array(dev->of_node,
+ "microchip,led-modes",
+ led_modes,
+ 0,
+ ARRAY_SIZE(led_modes));
+   if (len >= 0) {
+   u32 reg = 0;
+   int i;
+
+   for (i = 0; i < len; i++) {
+   if (led_modes[i] > 15)
+   return -EINVAL;
+   reg |= led_modes[i] << (i * 4);
+   }
+   for (; i < ARRAY_SIZE(led_modes); i++)
+   reg |= LAN78XX_FORCE_LED_OFF << (i * 4);
+   (void)phy_write(phydev, LAN78XX_PHY_LED_MODE_SELECT, reg);
+   } else if (len == -EOVERFLOW) {
+   return -EINVAL;
+   }
+
/* these values can be used to identify internal PHY */
priv->chip_id = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_ID);
priv->chip_rev = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_REV);
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a823f01..6b03b97 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "lan78xx.h"
 
@@ -1760,6 +1761,7 @@ static int lan78xx_mdiobus_write(struct mii_bus *bus, int 
phy_id, int idx,
 
 static int lan78xx_mdio_init(struct lan78xx_net *dev)
 {
+   struct device_node *node;
int ret;
 
dev->mdiobus = mdiobus_alloc();
@@ -1788,7 +1790,13 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
break;
}
 
-   ret = mdiobus_register(dev->mdiobus);
+   node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
+   if (node) {
+   ret = of_mdiobus_register(dev->mdiobus, node);
+   of_node_put(node);
+   } else {
+   ret = mdiobus_register(dev->mdiobus);
+   }
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
@@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
 
+   if (phydev->mdio.dev.of_node) {
+   u32 reg;
+   int len;
+
+   len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
+ "microchip,led-modes",
+ sizeof(u32));
+   if (len 

[PATCH v4 0/3] lan78xx: Read configuration from Device Tree

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

This patch set adds support for reading the MAC address and LED modes from
Device Tree.

v4:
- Rename nodes in bindings doc.

v3:
- Move LED setting into PHY driver.

v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.

Phil Elwell (3):
  lan78xx: Read MAC address from DT if present
  lan78xx: Read LED states from Device Tree
  dt-bindings: Document the DT bindings for lan78xx

 .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 
 MAINTAINERS|  2 +
 drivers/net/phy/microchip.c| 25 
 drivers/net/usb/lan78xx.c  | 74 +++---
 include/dt-bindings/net/microchip-lan78xx.h| 21 ++
 include/linux/microchipphy.h   |  3 +
 6 files changed, 156 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h

-- 
2.7.4

--
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 v4 3/3] dt-bindings: Document the DT bindings for lan78xx

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

Document the supported properties in a bindings file.

Signed-off-by: Phil Elwell 
Reviewed-by: Andrew Lunn 
---
 .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 ++
 MAINTAINERS|  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt

diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt 
b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 000..76786a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,54 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+The Device Tree properties, if present, override the OTP and EEPROM.
+
+Required properties:
+- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
+
+Optional properties:
+- local-mac-address:   see ethernet.txt
+- mac-address: see ethernet.txt
+
+Optional properties of the embedded PHY:
+- microchip,led-modes: a 0..4 element vector, with each element configuring
+  the operating mode of an LED. Omitted LEDs are turned off. Allowed values
+  are defined in "include/dt-bindings/net/microchip-lan78xx.h".
+
+Example:
+
+/* Based on the configuration for a Raspberry Pi 3 B+ */
+ {
+   usb-port@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb-port@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethernet: ethernet@1 {
+   compatible = "usb424,7800";
+   reg = <1>;
+   local-mac-address = [ 00 11 22 33 44 55 ];
+
+   mdio {
+   #address-cells = <0x1>;
+   #size-cells = <0x0>;
+   eth_phy: ethernet-phy@1 {
+   reg = <1>;
+   microchip,led-modes = <
+   
LAN78XX_LINK_1000_ACTIVITY
+   
LAN78XX_LINK_10_100_ACTIVITY
+   >;
+   };
+   };
+   };
+   };
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 23735d9..91cb961 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14572,6 +14572,7 @@ M:  Woojung Huh 
 M: Microchip Linux Driver Support 
 L: net...@vger.kernel.org
 S: Maintained
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 F: drivers/net/usb/lan78xx.*
 F: include/dt-bindings/net/microchip-lan78xx.h
 
-- 
2.7.4

--
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 v4 1/3] lan78xx: Read MAC address from DT if present

[Phil Elwell]

There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.

Signed-off-by: Phil Elwell 
---
 drivers/net/usb/lan78xx.c | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0867f72..a823f01 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "lan78xx.h"
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
@@ -1652,34 +1653,31 @@ static void lan78xx_init_mac_address(struct lan78xx_net 
*dev)
addr[5] = (addr_hi >> 8) & 0xFF;
 
if (!is_valid_ether_addr(addr)) {
-   /* reading mac address from EEPROM or OTP */
-   if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
-addr) == 0) ||
-   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
-   if (is_valid_ether_addr(addr)) {
-   /* eeprom values are valid so use them */
-   netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
-   } else {
-   /* generate random MAC */
-   random_ether_addr(addr);
-   netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
-   }
-
-   addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
-   addr_hi = addr[4] | (addr[5] << 8);
-
-   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
-   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+   if (!eth_platform_get_mac_address(>udev->dev, addr)) {
+   /* valid address present in Device Tree */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+   } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ETH_ALEN, addr) == 0) ||
+   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+  is_valid_ether_addr(addr)) {
+   /* eeprom values are valid so use them */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
  "MAC address set to random addr");
}
+
+   addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+   addr_hi = addr[4] | (addr[5] << 8);
+
+   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
 
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
-- 
2.7.4

--
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 v1 0/2] usb: dwc2: gadget: Fixes for LPM

[Simon Shields]

Hi all,

On 10/04/2018 10:21 PM, Grigor Tovmasyan wrote:
> Here are two little fixes for LPM feature.
>
> First one is coverity warning fix.
>
> The Second one was asserted by Stefan Wahren.
>
> Changes from version 0:
>
> 1/2:
> - Instead of converting parameter in the CHECK_RANGE macro
>   to int, changed hird_threshold type from u8 to int.
>
>
> Grigor Tovmasyan (2):
>usb: dwc2: gadget: Fix coverity issue
>usb: dwc2: gadget: Change LPM default values
>
>   drivers/usb/dwc2/core.h   | 2 +-
>   drivers/usb/dwc2/params.c | 8 
>   2 files changed, 5 insertions(+), 5 deletions(-)

The second patch in this series fixes a regression in 4.17-rc1 using dwc2 in 
gadget
mode on Exynos4412, introduced by commit 7455f8b7f0b3 ("usb: dwc2: Enable
LPM"). The regression is that using the cdc_acm serial gadget (and
presumably other gadgets) serial console output will only sporadically
show up on the host (it seems to only show up as input is sent).

However, I'm unsure if completely disabling LPM is the correct fix, as the dwc2
revision in Exynos4412 (0x4f54281a) should support LPM according to the
source.

I'm not really sure how to debug this any further (vendor kernel
releases contain no mention of LPM in the gadget drivers), so any pointers
in that direction would be much appreciated.

Cheers,
Simon
--
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] USB: Increment wakeup count on remote wakeup.

[Rajat Jain]

On Thu, Apr 19, 2018 at 8:01 AM, Alan Stern  wrote:
> On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:
>
>> On chromebooks we depend on wakeup count to identify the wakeup source.
>> But currently USB devices do not increment the wakeup count when they
>> trigger the remote wake. This patch addresses the same.
>>
>> Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
>>
>> On USB 2.0 devices, a wake capable device, if wake enabled, drives
>> resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
>> The upstream facing port then sets C_PORT_SUSPEND bit and reports a
>> port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
>> has resumed before driving the resume signal from the host and
>> C_PORT_SUSPEND is set, then the device attached to the given port might
>> be the reason for the last system wakeup. Increment the wakeup count for
>> the same.
>>
>> On USB 3.0 devices, a function may signal that it wants to exit from device
>> suspend by sending a Function Wake Device Notification to the host (USB3.0
>> spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
>> wakeup count.
>>
>> Signed-off-by: ravisadin...@chromium.org
>> ---
>>  drivers/usb/core/hcd.c |  1 +
>>  drivers/usb/core/hub.c | 12 ++--
>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index 777036ae63674..79f95a878fb6e 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -2375,6 +2375,7 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
>>  {
>>   unsigned long flags;
>>
>> + pm_wakeup_event(dev, 0);
>
> Instead of dev, you probably want to use hcd->self.sysdev.  Or maybe
> hcd->self.controller, although the difference probably doesn't matter
> for your purposes.
>
> On the other hand, this wakeup event may already have been counted by
> the host controller's bus subsystem.  Does it matter if the same wakeup
> event gets counted twice?

No. The context is that we're interested in making user space behave
differently if the wake up source was a user input device (e.g. USB
keyboard) v/s some other kind of USB device. So all that matters is
that the USB device wakeup count gets incremented.

>
> (This is inevitable with USB devices, in any case.  If a device sends a
> wakeup request, it will be counted for that device, for all the
> intermediate hubs, and for the host controller.)
>
>> @@ -3432,10 +3437,13 @@ int usb_port_resume(struct usb_device *udev, 
>> pm_message_t msg)
>>
>>   usb_lock_port(port_dev);
>>
>> - /* Skip the initial Clear-Suspend step for a remote wakeup */
>>   status = hub_port_status(hub, port1, , );
>> - if (status == 0 && !port_is_suspended(hub, portstatus))
>> + /* Skip the initial Clear-Suspend step for a remote wakeup */
>
> What is the reason for moving the comment line down after the
> hub_port_status() call?
>
> Alan Stern
>
>> + if (status == 0 && !port_is_suspended(hub, portstatus)) {
>> + if (portchange & USB_PORT_STAT_C_SUSPEND)
>> + pm_wakeup_event(>dev, 0);
>>   goto SuspendCleared;
>> + }
>>
>>   /* see 7.1.7.7; affects power usage, but not budgeting */
>>   if (hub_is_superspeed(hub->hdev))
>>
>
--
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 resend v3 3/3] dt-bindings: Document the DT bindings for lan78xx

[Rob Herring]

On Thu, Apr 19, 2018 at 10:16 AM, Phil Elwell  wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications without an EEPROM or programmed OTP.
>
> Document the supported properties in a bindings file.
>
> Signed-off-by: Phil Elwell 
> ---
>  .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 
> ++
>  MAINTAINERS|  1 +
>  2 files changed, 55 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/microchip,lan78xx.txt
>
> diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt 
> b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
> new file mode 100644
> index 000..a5d701b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
> @@ -0,0 +1,54 @@
> +Microchip LAN78xx Gigabit Ethernet controller
> +
> +The LAN78XX devices are usually configured by programming their OTP or with
> +an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
> +The Device Tree properties, if present, override the OTP and EEPROM.
> +
> +Required properties:
> +- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
> +
> +Optional properties:
> +- local-mac-address:   see ethernet.txt
> +- mac-address: see ethernet.txt
> +
> +Optional properties of the embedded PHY:
> +- microchip,led-modes: a 0..4 element vector, with each element configuring
> +  the operating mode of an LED. Omitted LEDs are turned off. Allowed values
> +  are defined in "include/dt-bindings/net/microchip-lan78xx.h".
> +
> +Example:
> +
> +/* Based on the configuration for a Raspberry Pi 3 B+ */
> + {
> +   usb1@1 {

Same comments as in the dts file:

usb-port@1

> +   compatible = "usb424,2514";
> +   reg = <1>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   usb1_1@1 {

usb-port@1

> +   compatible = "usb424,2514";
> +   reg = <1>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   ethernet: usbether@1 {

ethernet@1

> +   compatible = "usb424,7800";
> +   reg = <1>;
> +   local-mac-address = [ 00 11 22 33 44 55 ];
> +
> +   mdio {
> +   #address-cells = <0x1>;
> +   #size-cells = <0x0>;
> +   eth_phy: ethernet-phy@1 {
> +   reg = <1>;
> +   microchip,led-modes = <
> +   
> LAN78XX_LINK_1000_ACTIVITY
> +   
> LAN78XX_LINK_10_100_ACTIVITY
> +   >;
> +   };
> +   };
> +   };
> +   };
> +   };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 23735d9..91cb961 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14572,6 +14572,7 @@ M:  Woojung Huh 
>  M: Microchip Linux Driver Support 
>  L: net...@vger.kernel.org
>  S: Maintained
> +F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
>  F: drivers/net/usb/lan78xx.*
>  F: include/dt-bindings/net/microchip-lan78xx.h
>
> --
> 2.7.4
>
--
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 5/6] USB: USB 3.2 Add sysfs entries for a usb device rx_lanes and tx_lanes

[Mathias Nyman]

Add rx_lanes and tx_lanes lane count sysfs entries for a usb device
struct usb_devuce rx_lanes and tx_lanes variables.

Shows number of lanes used by the usb device

Data rate of a device is the lane speed * lane count, for example
USB 3.2 Gen 2x2 device uses 10Gbps signaling per lane, and has dual-lane
support 10Gbps * 2 = 20Gbps

Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/sysfs.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index 27bb340..ea18284 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -175,6 +175,26 @@ static ssize_t speed_show(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RO(speed);
 
+static ssize_t rx_lanes_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_device *udev;
+
+   udev = to_usb_device(dev);
+   return sprintf(buf, "%d\n", udev->rx_lanes);
+}
+static DEVICE_ATTR_RO(rx_lanes);
+
+static ssize_t tx_lanes_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+   struct usb_device *udev;
+
+   udev = to_usb_device(dev);
+   return sprintf(buf, "%d\n", udev->tx_lanes);
+}
+static DEVICE_ATTR_RO(tx_lanes);
+
 static ssize_t busnum_show(struct device *dev, struct device_attribute *attr,
   char *buf)
 {
@@ -790,6 +810,8 @@ static struct attribute *dev_attrs[] = {
_attr_bNumConfigurations.attr,
_attr_bMaxPacketSize0.attr,
_attr_speed.attr,
+   _attr_rx_lanes.attr,
+   _attr_tx_lanes.attr,
_attr_busnum.attr,
_attr_devnum.attr,
_attr_devpath.attr,
-- 
2.7.4

--
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 6/6] Documentation sysfs-bus-usb: Add rx_lanes and tx_lanes introduced in USB 3.2

[Mathias Nyman]

rx_lanes and tx_lanes sysfs entries show the number of lanes in use by a
device.
USB 3.2 adds support for Dual-lane (symmetrical), using 2 rx lanes and
2 tx lanes for normal non Inter-Chip SSIC devices.
USB 3.1 and older are all single lane.

SSIC devices can have up to 4 lanes per direction in use,
with different number of rx and tx lanes.

Signed-off-by: Mathias Nyman 
---
 Documentation/ABI/testing/sysfs-bus-usb | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-usb 
b/Documentation/ABI/testing/sysfs-bus-usb
index c702c78..c6e9b30 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -236,3 +236,21 @@ Description:
Supported values are 0 - 15.
More information on how besl values map to microseconds can be 
found in
USB 2.0 ECN Errata for Link Power Management, section 4.10)
+
+What:  /sys/bus/usb/devices/.../rx_lanes
+Date:  March 2018
+Contact:   Mathias Nyman 
+Description:
+   Number of rx lanes the device is using.
+   USB 3.2 adds Dual-lane support, 2 rx and 2 tx lanes over Type-C.
+   Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes 
per
+   direction. Devices before USB 3.2 are single lane (rx_lanes = 1)
+
+What:  /sys/bus/usb/devices/.../tx_lanes
+Date:  March 2018
+Contact:   Mathias Nyman 
+Description:
+   Number of tx lanes the device is using.
+   USB 3.2 adds Dual-lane support, 2 rx and 2 tx -lanes over 
Type-C.
+   Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes 
per
+   direction. Devices before USB 3.2 are single lane (tx_lanes = 1)
-- 
2.7.4

--
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/6] USB: Add support to store lane count used by USB 3.2

[Mathias Nyman]

USB 3.2 specification adds Dual-lane support, doubling the maximum
SuperSpeedPlus data rate from 10Gbps to 20Gbps.

Dual-lane takes into use a second set of rx and tx wires/pins in the
Type-C cable and connector.

Add "rx_lanes" and "tx_lanes" variables to struct usb_device to store
the numer of lanes in use. Number of lanes can be read using the extended
port status hub request that was introduced in USB 3.1.

Extended port status rx and tx lane count are zero based, maximum
lanes supported by non inter-chip (SSIC) USB 3.2 is 2 (dual lane) with
rx and tx lane count symmetric. SSIC devices support asymmetric lanes
up to 4 lanes per direction.

If extended port status is not available then default to one lane.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/hub.c| 8 
 include/linux/usb.h   | 4 
 include/uapi/linux/usb/ch11.h | 5 +
 3 files changed, 17 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index f6ea16e..97ee2f9 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2746,6 +2746,14 @@ static int hub_port_wait_reset(struct usb_hub *hub, int 
port1,
if (!udev)
return 0;
 
+   if (hub_is_superspeedplus(hub->hdev)) {
+   /* extended portstatus Rx and Tx lane count are zero based */
+   udev->rx_lanes = USB_EXT_PORT_RX_LANES(ext_portstatus) + 1;
+   udev->tx_lanes = USB_EXT_PORT_TX_LANES(ext_portstatus) + 1;
+   } else {
+   udev->rx_lanes = 1;
+   udev->tx_lanes = 1;
+   }
if (hub_is_wusb(hub))
udev->speed = USB_SPEED_WIRELESS;
else if (hub_is_superspeedplus(hub->hdev) &&
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 0173597..beffcee 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -551,6 +551,8 @@ struct usb3_lpm_parameters {
  * @route: tree topology hex string for use with xHCI
  * @state: device state: configured, not attached, etc.
  * @speed: device speed: high/full/low (or error)
+ * @rx_lanes: number of rx lanes in use, USB 3.2 adds dual-lane support
+ * @tx_lanes: number of tx lanes in use, USB 3.2 adds dual-lane support
  * @tt: Transaction Translator info; used with low/full speed dev, highspeed 
hub
  * @ttport: device port on that tt hub
  * @toggle: one bit for each endpoint, with ([0] = IN, [1] = OUT) endpoints
@@ -624,6 +626,8 @@ struct usb_device {
u32 route;
enum usb_device_state   state;
enum usb_device_speed   speed;
+   unsigned intrx_lanes;
+   unsigned inttx_lanes;
 
struct usb_tt   *tt;
int ttport;
diff --git a/include/uapi/linux/usb/ch11.h b/include/uapi/linux/usb/ch11.h
index 29c120c..fb0cd24 100644
--- a/include/uapi/linux/usb/ch11.h
+++ b/include/uapi/linux/usb/ch11.h
@@ -197,6 +197,11 @@ struct usb_port_status {
 #define USB_EXT_PORT_STAT_RX_LANES 0x0f00
 #define USB_EXT_PORT_STAT_TX_LANES 0xf000
 
+#define USB_EXT_PORT_RX_LANES(p) \
+   (((p) & USB_EXT_PORT_STAT_RX_LANES) >> 8)
+#define USB_EXT_PORT_TX_LANES(p) \
+   (((p) & USB_EXT_PORT_STAT_TX_LANES) >> 12)
+
 /*
  * wHubCharacteristics (masks)
  * See USB 2.0 spec Table 11-13, offset 3
-- 
2.7.4

--
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/6] usb: set root hub lane counts

[Mathias Nyman]

Set the the rx_lane and tx_lane count to "2" for USB 3.2 hosts.
For all other older hosts set the default lane counts to 1

Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/hcd.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index b1463aa..09a6774 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2814,6 +2814,9 @@ int usb_add_hcd(struct usb_hcd *hcd,
hcd->self.root_hub = rhdev;
mutex_unlock(_port_peer_mutex);
 
+   rhdev->rx_lanes = 1;
+   rhdev->tx_lanes = 1;
+
switch (hcd->speed) {
case HCD_USB11:
rhdev->speed = USB_SPEED_FULL;
@@ -2828,6 +2831,8 @@ int usb_add_hcd(struct usb_hcd *hcd,
rhdev->speed = USB_SPEED_SUPER;
break;
case HCD_USB32:
+   rhdev->rx_lanes = 2;
+   rhdev->tx_lanes = 2;
case HCD_USB31:
rhdev->speed = USB_SPEED_SUPER_PLUS;
break;
-- 
2.7.4

--
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 4/6] USB: show USB 3.2 Dual-lane devices as Gen Xx2 during device enumeration

[Mathias Nyman]

USB 3.2 specification adds a Gen XxY notion for USB3 devices where
X is the signaling rate on the wire. Gen 1xY is 5Gbps Superspeed
and Gen 2xY is 10Gbps SuperSpeedPlus. Y is the lane count.

For normal, non inter-chip (SSIC) devies the rx and tx lane count is
symmetric, and the maximum lane count for USB 3.2 devices is 2 (dual-lane).

SSIC devices may have asymmetric lane counts, with up to four
lanes per direction. The USB 3.2 specification doesn't point out
how to use the Gen XxY notion for these devices, so we limit the Gen Xx2
notion to symmertic Dual lane devies.
For other devices just show Gen1 or Gen2

Gen 1 5Gbps
Gen 2 10Gbps
Gen 1x2 10Gbps Dual-lane  (USB 3.2)
Gen 2x2 20Gbps Dual-lane  (USB 3.2)

Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/hub.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 97ee2f9..8d33d0c 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4598,9 +4598,12 @@ hub_port_init(struct usb_hub *hub, struct usb_device 
*udev, int port1,
if (udev->speed >= USB_SPEED_SUPER) {
devnum = udev->devnum;
dev_info(>dev,
-   "%s SuperSpeed%s USB device 
number %d using %s\n",
+   "%s SuperSpeed%s%s USB device 
number %d using %s\n",
(udev->config) ? "reset" : 
"new",
-(udev->speed == USB_SPEED_SUPER_PLUS) 
? "Plus" : "",
+(udev->speed == USB_SPEED_SUPER_PLUS) ?
+   "Plus Gen 2" : " Gen 1",
+(udev->rx_lanes == 2 && udev->tx_lanes 
== 2) ?
+   "x2" : "",
 devnum, driver_name);
}
 
-- 
2.7.4

--
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/6] usb: define HCD_USB32 speed option for hosts that support USB 3.2 dual-lane

[Mathias Nyman]

Hosts that support USB 3.2 Enhaned SuperSpeed can set their hcd speed
to HCD_USB32 to let usb core and host drivers know that the controller
supports new USB 3.2 dual-lane features.

make sure usb core handle HCD_USB32 hosts correctly, for now similar
to HCD_USB32.

Signed-off-by: Mathias Nyman 
---
 drivers/usb/core/hcd.c  | 3 +++
 include/linux/usb/hcd.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 777036a..b1463aa 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -568,6 +568,7 @@ static int rh_call_control (struct usb_hcd *hcd, struct urb 
*urb)
switch (wValue & 0xff00) {
case USB_DT_DEVICE << 8:
switch (hcd->speed) {
+   case HCD_USB32:
case HCD_USB31:
bufp = usb31_rh_dev_descriptor;
break;
@@ -592,6 +593,7 @@ static int rh_call_control (struct usb_hcd *hcd, struct urb 
*urb)
break;
case USB_DT_CONFIG << 8:
switch (hcd->speed) {
+   case HCD_USB32:
case HCD_USB31:
case HCD_USB3:
bufp = ss_rh_config_descriptor;
@@ -2825,6 +2827,7 @@ int usb_add_hcd(struct usb_hcd *hcd,
case HCD_USB3:
rhdev->speed = USB_SPEED_SUPER;
break;
+   case HCD_USB32:
case HCD_USB31:
rhdev->speed = USB_SPEED_SUPER_PLUS;
break;
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index aef50cb..cb9b76b 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -261,6 +261,7 @@ struct hc_driver {
 #defineHCD_USB25   0x0030  /* Wireless USB 1.0 (USB 2.5)*/
 #defineHCD_USB30x0040  /* USB 3.0 */
 #defineHCD_USB31   0x0050  /* USB 3.1 */
+#defineHCD_USB32   0x0060  /* USB 3.2 */
 #defineHCD_MASK0x0070
 #defineHCD_BH  0x0100  /* URB complete in BH context */
 
-- 
2.7.4

--
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/6] USB 3.2 initial support

[Mathias Nyman]

Hi

A new version based on earlier suggestions and feedback.

The USB 3.2 specification adds support for Dual-lane, doubling the
maximum rate to 20Gbps by taking into use another set of rx and tx
wires and pins in the Type-C cable and connector.

The changes to support this in USB core and xhci driver seems to be minor.
USB 3.1 support already added the extended port status request returning
lane count. it just wasn't used before.

These patches add rx_lanes and tx_lanes variables to store the number of lanes
in use, and exposes them via sysfs.
It adds a Gen XxY notion to the string displayed when a new device is connected.
X in Gen XxY stands for signaling rate,
Y for lane count, as described in the USB 3.2 specification.

Example for clarification:
Gen 1 = 5Gbps, SuperSpeed, one lane, same as USB3.0, and USB 3.1 Gen1
Gen 2 = 10Gbps, SuperSpeedPlus, one lane, same as USB 3.1 Gen2
Gen 1x2 = 10Gbps, SuperSpeed, Dual-lane (2 x 5Gbps)
Gen 2x2 = 20Gbps, SuperSpeedPlus, Dual-lane (2 x 10Gbps)

changes since v1:
 - define HCD_USB32 speed option for hosts that support Dual-lane USB3.2
 - save both rx and tx lane counts instead of one "lanes"
 - expose rx_lanes and tx_lanes via sysfs
 - only show "x2" part in "Gen Xx2" for symmertic dual lane devices

Mathias Nyman (6):
  usb: define HCD_USB32 speed option for hosts that support USB 3.2
dual-lane
  USB: Add support to store lane count used by USB 3.2
  usb: set root hub lane counts
  USB: show USB 3.2 Dual-lane devices as Gen Xx2 during device
enumeration
  USB: USB 3.2 Add sysfs entries for a usb device rx_lanes and tx_lanes
  Documentation sysfs-bus-usb: Add rx_lanes and tx_lanes introduced in
USB 3.2

 Documentation/ABI/testing/sysfs-bus-usb | 18 ++
 drivers/usb/core/hcd.c  |  8 
 drivers/usb/core/hub.c  | 15 +--
 drivers/usb/core/sysfs.c| 22 ++
 include/linux/usb.h |  4 
 include/linux/usb/hcd.h |  1 +
 include/uapi/linux/usb/ch11.h   |  5 +
 7 files changed, 71 insertions(+), 2 deletions(-)

-- 
2.7.4

--
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 v3 3/3] dt-bindings: Document the DT bindings for lan78xx

[Andrew Lunn]

On Thu, Apr 19, 2018 at 03:32:05PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications without an EEPROM or programmed OTP.
> 
> Document the supported properties in a bindings file.
> 
> Signed-off-by: Phil Elwell 

Reviewed-by: Andrew Lunn 

Andrew
--
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 resend v3 0/3] lan78xx: Read configuration from Device Tree

[Phil Elwell]

[ Resending due to incorrect distribution list ]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

This patch set adds support for reading the MAC address and LED modes from
Device Tree.

v3:
- Move LED setting into PHY driver.

v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.

Phil Elwell (3):
  lan78xx: Read MAC address from DT if present
  lan78xx: Read LED states from Device Tree
  dt-bindings: Document the DT bindings for lan78xx

 .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 
 MAINTAINERS|  2 +
 drivers/net/phy/microchip.c| 25 
 drivers/net/usb/lan78xx.c  | 74 +++---
 include/dt-bindings/net/microchip-lan78xx.h| 21 ++
 include/linux/microchipphy.h   |  3 +
 6 files changed, 156 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h

-- 
2.7.4

--
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 resend v3 2/3] lan78xx: Read LED states from Device Tree

[Phil Elwell]

Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:

0=link/activity  1=link1000/activity
2=link100/activity   3=link10/activity
4=link100/1000/activity  5=link10/1000/activity
6=link10/100/activity14=off15=on

These values are given symbolic constants in a dt-bindings header.

Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.

Signed-off-by: Phil Elwell 
---
 MAINTAINERS |  1 +
 drivers/net/phy/microchip.c | 25 ++
 drivers/net/usb/lan78xx.c   | 32 -
 include/dt-bindings/net/microchip-lan78xx.h | 21 +++
 include/linux/microchipphy.h|  3 +++
 5 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d..23735d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14573,6 +14573,7 @@ M:  Microchip Linux Driver Support 

 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/usb/lan78xx.*
+F: include/dt-bindings/net/microchip-lan78xx.h
 
 USB MASS STORAGE DRIVER
 M: Alan Stern 
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 0f293ef..ef5e160 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
 #define DRIVER_DESC"Microchip LAN88XX PHY driver"
@@ -70,6 +72,8 @@ static int lan88xx_probe(struct phy_device *phydev)
 {
struct device *dev = >mdio.dev;
struct lan88xx_priv *priv;
+   u32 led_modes[4];
+   int len;
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -77,6 +81,27 @@ static int lan88xx_probe(struct phy_device *phydev)
 
priv->wolopts = 0;
 
+   len = of_property_read_variable_u32_array(dev->of_node,
+ "microchip,led-modes",
+ led_modes,
+ 0,
+ ARRAY_SIZE(led_modes));
+   if (len >= 0) {
+   u32 reg = 0;
+   int i;
+
+   for (i = 0; i < len; i++) {
+   if (led_modes[i] > 15)
+   return -EINVAL;
+   reg |= led_modes[i] << (i * 4);
+   }
+   for (; i < ARRAY_SIZE(led_modes); i++)
+   reg |= LAN78XX_FORCE_LED_OFF << (i * 4);
+   (void)phy_write(phydev, LAN78XX_PHY_LED_MODE_SELECT, reg);
+   } else if (len == -EOVERFLOW) {
+   return -EINVAL;
+   }
+
/* these values can be used to identify internal PHY */
priv->chip_id = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_ID);
priv->chip_rev = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_REV);
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a823f01..6b03b97 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "lan78xx.h"
 
@@ -1760,6 +1761,7 @@ static int lan78xx_mdiobus_write(struct mii_bus *bus, int 
phy_id, int idx,
 
 static int lan78xx_mdio_init(struct lan78xx_net *dev)
 {
+   struct device_node *node;
int ret;
 
dev->mdiobus = mdiobus_alloc();
@@ -1788,7 +1790,13 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
break;
}
 
-   ret = mdiobus_register(dev->mdiobus);
+   node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
+   if (node) {
+   ret = of_mdiobus_register(dev->mdiobus, node);
+   of_node_put(node);
+   } else {
+   ret = mdiobus_register(dev->mdiobus);
+   }
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
@@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
 
+   if (phydev->mdio.dev.of_node) {
+   u32 reg;
+   int len;
+
+   len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
+ "microchip,led-modes",
+ sizeof(u32));
+   if (len >= 0) {
+   /* Ensure 

Re: [PATCH v3 2/3] lan78xx: Read LED states from Device Tree

[Andrew Lunn]

> @@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
>   mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
>   phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
>  
> + if (phydev->mdio.dev.of_node) {
> + u32 reg;
> + int len;
> +
> + len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
> +   "microchip,led-modes",
> +   sizeof(u32));
> + if (len >= 0) {
> + /* Ensure the appropriate LEDs are enabled */
> + lan78xx_read_reg(dev, HW_CFG, );
> + reg &= ~(HW_CFG_LED0_EN_ |
> +  HW_CFG_LED1_EN_ |
> +  HW_CFG_LED2_EN_ |
> +  HW_CFG_LED3_EN_);
> + reg |= (len > 0) * HW_CFG_LED0_EN_ |
> + (len > 1) * HW_CFG_LED1_EN_ |
> + (len > 2) * HW_CFG_LED2_EN_ |
> + (len > 3) * HW_CFG_LED3_EN_;
> + lan78xx_write_reg(dev, HW_CFG, reg);
> + }
> + }
> +

Humm. Not nice. But i cannot think of a cleaner way of doing this.

Reviewed-by: Andrew Lunn 

Andrew
--
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 resend v3 1/3] lan78xx: Read MAC address from DT if present

[Phil Elwell]

There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.

Signed-off-by: Phil Elwell 
---
 drivers/net/usb/lan78xx.c | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0867f72..a823f01 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "lan78xx.h"
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
@@ -1652,34 +1653,31 @@ static void lan78xx_init_mac_address(struct lan78xx_net 
*dev)
addr[5] = (addr_hi >> 8) & 0xFF;
 
if (!is_valid_ether_addr(addr)) {
-   /* reading mac address from EEPROM or OTP */
-   if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
-addr) == 0) ||
-   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
-   if (is_valid_ether_addr(addr)) {
-   /* eeprom values are valid so use them */
-   netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
-   } else {
-   /* generate random MAC */
-   random_ether_addr(addr);
-   netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
-   }
-
-   addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
-   addr_hi = addr[4] | (addr[5] << 8);
-
-   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
-   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+   if (!eth_platform_get_mac_address(>udev->dev, addr)) {
+   /* valid address present in Device Tree */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+   } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ETH_ALEN, addr) == 0) ||
+   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+  is_valid_ether_addr(addr)) {
+   /* eeprom values are valid so use them */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
  "MAC address set to random addr");
}
+
+   addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+   addr_hi = addr[4] | (addr[5] << 8);
+
+   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
 
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
-- 
2.7.4

--
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 resend v3 3/3] dt-bindings: Document the DT bindings for lan78xx

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

Document the supported properties in a bindings file.

Signed-off-by: Phil Elwell 
---
 .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 ++
 MAINTAINERS|  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt

diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt 
b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 000..a5d701b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,54 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+The Device Tree properties, if present, override the OTP and EEPROM.
+
+Required properties:
+- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
+
+Optional properties:
+- local-mac-address:   see ethernet.txt
+- mac-address: see ethernet.txt
+
+Optional properties of the embedded PHY:
+- microchip,led-modes: a 0..4 element vector, with each element configuring
+  the operating mode of an LED. Omitted LEDs are turned off. Allowed values
+  are defined in "include/dt-bindings/net/microchip-lan78xx.h".
+
+Example:
+
+/* Based on the configuration for a Raspberry Pi 3 B+ */
+ {
+   usb1@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb1_1@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethernet: usbether@1 {
+   compatible = "usb424,7800";
+   reg = <1>;
+   local-mac-address = [ 00 11 22 33 44 55 ];
+
+   mdio {
+   #address-cells = <0x1>;
+   #size-cells = <0x0>;
+   eth_phy: ethernet-phy@1 {
+   reg = <1>;
+   microchip,led-modes = <
+   
LAN78XX_LINK_1000_ACTIVITY
+   
LAN78XX_LINK_10_100_ACTIVITY
+   >;
+   };
+   };
+   };
+   };
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 23735d9..91cb961 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14572,6 +14572,7 @@ M:  Woojung Huh 
 M: Microchip Linux Driver Support 
 L: net...@vger.kernel.org
 S: Maintained
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 F: drivers/net/usb/lan78xx.*
 F: include/dt-bindings/net/microchip-lan78xx.h
 
-- 
2.7.4

--
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] USB: Increment wakeup count on remote wakeup.

[Alan Stern]

On Wed, 18 Apr 2018, Ravi Chandra Sadineni wrote:

> On chromebooks we depend on wakeup count to identify the wakeup source.
> But currently USB devices do not increment the wakeup count when they
> trigger the remote wake. This patch addresses the same.
> 
> Resume condition is reported differently on USB 2.0 and USB 3.0 devices.
> 
> On USB 2.0 devices, a wake capable device, if wake enabled, drives
> resume signal to indicate a remote wake (USB 2.0 spec section 7.1.7.7).
> The upstream facing port then sets C_PORT_SUSPEND bit and reports a
> port change event (USB 2.0 spec section 11.24.2.7.2.3). Thus if a port
> has resumed before driving the resume signal from the host and
> C_PORT_SUSPEND is set, then the device attached to the given port might
> be the reason for the last system wakeup. Increment the wakeup count for
> the same.
> 
> On USB 3.0 devices, a function may signal that it wants to exit from device
> suspend by sending a Function Wake Device Notification to the host (USB3.0
> spec section 8.5.6.4) Thus on receiving the Function Wake, increment the
> wakeup count.
> 
> Signed-off-by: ravisadin...@chromium.org
> ---
>  drivers/usb/core/hcd.c |  1 +
>  drivers/usb/core/hub.c | 12 ++--
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 777036ae63674..79f95a878fb6e 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -2375,6 +2375,7 @@ void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
>  {
>   unsigned long flags;
>  
> + pm_wakeup_event(dev, 0);

Instead of dev, you probably want to use hcd->self.sysdev.  Or maybe
hcd->self.controller, although the difference probably doesn't matter 
for your purposes.

On the other hand, this wakeup event may already have been counted by
the host controller's bus subsystem.  Does it matter if the same wakeup
event gets counted twice?

(This is inevitable with USB devices, in any case.  If a device sends a 
wakeup request, it will be counted for that device, for all the 
intermediate hubs, and for the host controller.)

> @@ -3432,10 +3437,13 @@ int usb_port_resume(struct usb_device *udev, 
> pm_message_t msg)
>  
>   usb_lock_port(port_dev);
>  
> - /* Skip the initial Clear-Suspend step for a remote wakeup */
>   status = hub_port_status(hub, port1, , );
> - if (status == 0 && !port_is_suspended(hub, portstatus))
> + /* Skip the initial Clear-Suspend step for a remote wakeup */

What is the reason for moving the comment line down after the 
hub_port_status() call?

Alan Stern

> + if (status == 0 && !port_is_suspended(hub, portstatus)) {
> + if (portchange & USB_PORT_STAT_C_SUSPEND)
> + pm_wakeup_event(>dev, 0);
>   goto SuspendCleared;
> + }
>  
>   /* see 7.1.7.7; affects power usage, but not budgeting */
>   if (hub_is_superspeed(hub->hdev))
> 

--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Tushar Nimkar]

On 2018-04-19 14:18, Oliver Neukum wrote:

Am Mittwoch, den 18.04.2018, 12:34 +0530 schrieb Tushar Nimkar:

Oliver/Greg,
Weather you are able to reproduce the issue?
Did you tested it on dwc3 previously?


I don't even have a dwc3.

Great, so uas on dwc3 new to all...

May I suggest that you try to determine whether the issue
happens on the same SCSI command? We need to know what
triggers it.


It is not same command for sure...But as i told previously, occurs
while 1) read_capacity_16(0x9e) or 2) REPORT_LUN(0xa0) or 3) 
INQUIRY(0x12) command

(I can say while sd_revalidate_disk)
If issue occur no status "missing" for above (one of the or more) 
command/s in LeCroy.




Sorry
Oliver


don't be we all can figure it out for sure :)

--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Tushar Nimkar]

On 2018-04-19 14:15, Oliver Neukum wrote:

Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:

On 2018-04-17 12:03, Tushar Nimkar wrote:


Hi,


I have doubt that sequential scan(scsi_sequential_lun_scan) work well
for uas device(SCSI>3)..
Why? As I have seen in most cases failed to enumerate during 
REPORT_LUN

command...and there is older way to scan disk is also present,
so I was thinking to try that.. did following things

starget->no_report_luns = 1  ---> for my target while uas_target_alloc
(for try)


In general the spec is one thing and reality is another thing.
You can depend really only on what recent versions of Windows do.


did not get you!




Found it is doing sequential scan but popuating 256 entries in cat
proc/partiction
for one disk
root@OpenWrt:/# cat proc/partitions
major minor  #blocks  name

80  488386584 sda
81  488384032 sda1
8   48  488386584 sdd
8   49  488384032 sdd1
8   64  488386584 sde
8   65  488384032 sde1
8   80  488386584 sdf
8   81  488384032 sdf1
8   96  488386584 sdg
8   97  488384032 sdg1
8  112  488386584 sdh
8  113  488384032 sdh1
  256 total.

...though it is SCSI>3 device ,it should support both sequential as 
well

as REPORT_LUN?


In theory.


oh, so no backward old way of scanning(sequential)?


Do not know weather this is the cause for the issue or not ...but if 
so

need to think on this too :)


Well, does your original issue go away if you use NO_REPORT_LUN



most of the time it works (observerd non working case too!) but 256 
similar logs will come on console

.

[  217.464158] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
disabled erect stream ring
[  217.464162] xhci-hcd xhci-hcd.0.auto: @7d933690  
00
[  217.464608] sd 1:0:0:200: [sdgs] 976773168 512-byte logical blocks: 
(500
[  217.464987] scsi 1:0:0:201: Direct-Access Samsung  Portable SSD 
T3  06

[  217.465329] sd 1:0:0:200: [sdgs] Write Protect is off
[  217.465585] sd 1:0:0:200: [sdgs] Write cache: enabled, read cache: 
enablert DPO or FUA
[  217.465695] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for 
disabled erect stream ring
[  217.465699] xhci-hcd xhci-hcd.0.auto: @7d933b00  
00

[  217.466264]  sdgr: sdgr1
[  217.466525] sd 1:0:0:201: [sdgt] 976773168 512-byte logical blocks: 
(500
[  217.466656] scsi 1:0:0:202: Direct-Access Samsung  Portable SSD 
T3  06

...


Did one more thing along with starget->no_report_luns = 1 , 
shost->max_lun = 1 instead if (= 256) [uas.c]
It Enumerates and no 256 cat proc/partitions entries. But doesn't not 
seems good to me to restrict max_lun to 1 :(



and does your device have multiple LUNs?

how to check that? maybe yes ...


Regards
Oliver


--
Best Regards,
Tushar R Nimkar

QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member of Code Aurora Forum, hosted by The Linux Foundation


--
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 v4 02/13] dt-bindings: usb: add documentation for typec port controller(TCPCI)

[Jun Li]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2018年4月16日 22:28
> To: Jun Li 
> Cc: gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com;
> li...@roeck-us.net; a.ha...@samsung.com; shufan_...@richtek.com; Peter
> Chen ; devicet...@vger.kernel.org;
> linux-usb@vger.kernel.org; dl-linux-imx ;
> de...@driverdev.osuosl.org
> Subject: Re: [PATCH v4 02/13] dt-bindings: usb: add documentation for typec
> port controller(TCPCI)
> 
> On Mon, Apr 16, 2018 at 6:54 AM, Jun Li  wrote:
> > Hi
> >> -Original Message-
> >> From: Rob Herring [mailto:r...@kernel.org]
> >> Sent: 2018年4月10日 4:04
> >> To: Jun Li 
> >> Cc: gre...@linuxfoundation.org; heikki.kroge...@linux.intel.com;
> >> li...@roeck-us.net; a.ha...@samsung.com; shufan_...@richtek.com;
> >> Peter Chen ; devicet...@vger.kernel.org;
> >> linux-usb@vger.kernel.org; dl-linux-imx ;
> >> de...@driverdev.osuosl.org
> >> Subject: Re: [PATCH v4 02/13] dt-bindings: usb: add documentation for
> >> typec port controller(TCPCI)
> >>
> >> On Thu, Mar 29, 2018 at 12:06:07AM +0800, Li Jun wrote:
> 
> [...]
> 
> >> > +ptn5110@50 {
> >> > +   compatible = "usb-tcpci,ptn5110";
> >> > +   reg = <0x50>;
> >> > +   interrupt-parent = <>;
> >> > +   interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> >> > +
> >> > +   usb_con: connector {
> >>
> >> How is the OF graph done in this case? You need some link to the USB
> controller.
> >
> > The platform(i.MX8MQ EVK) for this is still on the way of start
> > upstream, I was Planning to add this part with enabling USB3 function,
> > as of how this will be done, I only have usb3 ss data(no display port or
> Sideband), is something like below OK?
> >
> > typec: ptn5110@50 {
> > compatible = "nxp,ptn5110";
> > ...
> >
> > usb_con: connector {
> > compatible = "usb-c-connector";
> > label = "USB-C";
> > ...
> >
> > ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > port@1 {
> > reg = <1>;
> > usb_con_ss: endpoint {
> > remote-endpoint = <_phy_ss>;
> > };
> > };
> > };
> > };
> > };
> >
> > _phy0 {
> > status = "okay";
> >
> > port {
> > usb3_phy_ss: endpoint {
> 
> Normally, the graph connection would be to the USB controller, not the phy as
> the phy is just referred to with a "phys" property.

Understood, I will put this into a USB controller node. Thanks.

Jun
> 
> > remote-endpoint = <_con_ss>;
> > };
> > };
> > }
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

[PATCH v3 0/3] lan78xx: Read configuration from Device Tree

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

This patch set adds support for reading the MAC address and LED modes from
Device Tree.

v3:
- Move LED setting into PHY driver.

v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.

Phil Elwell (3):
  lan78xx: Read MAC address from DT if present
  lan78xx: Read LED states from Device Tree
  dt-bindings: Document the DT bindings for lan78xx

 .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 
 MAINTAINERS|  2 +
 drivers/net/phy/microchip.c| 25 
 drivers/net/usb/lan78xx.c  | 74 +++---
 include/dt-bindings/net/microchip-lan78xx.h| 21 ++
 include/linux/microchipphy.h   |  3 +
 6 files changed, 156 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h

-- 
2.7.4

--
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 v3 1/3] lan78xx: Read MAC address from DT if present

[Phil Elwell]

There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.

Signed-off-by: Phil Elwell 
---
 drivers/net/usb/lan78xx.c | 42 --
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index 0867f72..a823f01 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "lan78xx.h"
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
@@ -1652,34 +1653,31 @@ static void lan78xx_init_mac_address(struct lan78xx_net 
*dev)
addr[5] = (addr_hi >> 8) & 0xFF;
 
if (!is_valid_ether_addr(addr)) {
-   /* reading mac address from EEPROM or OTP */
-   if ((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
-addr) == 0) ||
-   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET, ETH_ALEN,
- addr) == 0)) {
-   if (is_valid_ether_addr(addr)) {
-   /* eeprom values are valid so use them */
-   netif_dbg(dev, ifup, dev->net,
- "MAC address read from EEPROM");
-   } else {
-   /* generate random MAC */
-   random_ether_addr(addr);
-   netif_dbg(dev, ifup, dev->net,
- "MAC address set to random addr");
-   }
-
-   addr_lo = addr[0] | (addr[1] << 8) |
- (addr[2] << 16) | (addr[3] << 24);
-   addr_hi = addr[4] | (addr[5] << 8);
-
-   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
-   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
+   if (!eth_platform_get_mac_address(>udev->dev, addr)) {
+   /* valid address present in Device Tree */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from Device Tree");
+   } else if (((lan78xx_read_eeprom(dev, EEPROM_MAC_OFFSET,
+ETH_ALEN, addr) == 0) ||
+   (lan78xx_read_otp(dev, EEPROM_MAC_OFFSET,
+ ETH_ALEN, addr) == 0)) &&
+  is_valid_ether_addr(addr)) {
+   /* eeprom values are valid so use them */
+   netif_dbg(dev, ifup, dev->net,
+ "MAC address read from EEPROM");
} else {
/* generate random MAC */
random_ether_addr(addr);
netif_dbg(dev, ifup, dev->net,
  "MAC address set to random addr");
}
+
+   addr_lo = addr[0] | (addr[1] << 8) |
+ (addr[2] << 16) | (addr[3] << 24);
+   addr_hi = addr[4] | (addr[5] << 8);
+
+   ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
+   ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
}
 
ret = lan78xx_write_reg(dev, MAF_LO(0), addr_lo);
-- 
2.7.4

--
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 v3 2/3] lan78xx: Read LED states from Device Tree

[Phil Elwell]

Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:

0=link/activity  1=link1000/activity
2=link100/activity   3=link10/activity
4=link100/1000/activity  5=link10/1000/activity
6=link10/100/activity14=off15=on

These values are given symbolic constants in a dt-bindings header.

Also use the presence of the DT property to indicate that the
LEDs should be enabled - necessary in the event that no valid OTP
or EEPROM is available.

Signed-off-by: Phil Elwell 
---
 MAINTAINERS |  1 +
 drivers/net/phy/microchip.c | 25 ++
 drivers/net/usb/lan78xx.c   | 32 -
 include/dt-bindings/net/microchip-lan78xx.h | 21 +++
 include/linux/microchipphy.h|  3 +++
 5 files changed, 81 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d..23735d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14573,6 +14573,7 @@ M:  Microchip Linux Driver Support 

 L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/usb/lan78xx.*
+F: include/dt-bindings/net/microchip-lan78xx.h
 
 USB MASS STORAGE DRIVER
 M: Alan Stern 
diff --git a/drivers/net/phy/microchip.c b/drivers/net/phy/microchip.c
index 0f293ef..ef5e160 100644
--- a/drivers/net/phy/microchip.c
+++ b/drivers/net/phy/microchip.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define DRIVER_AUTHOR  "WOOJUNG HUH "
 #define DRIVER_DESC"Microchip LAN88XX PHY driver"
@@ -70,6 +72,8 @@ static int lan88xx_probe(struct phy_device *phydev)
 {
struct device *dev = >mdio.dev;
struct lan88xx_priv *priv;
+   u32 led_modes[4];
+   int len;
 
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -77,6 +81,27 @@ static int lan88xx_probe(struct phy_device *phydev)
 
priv->wolopts = 0;
 
+   len = of_property_read_variable_u32_array(dev->of_node,
+ "microchip,led-modes",
+ led_modes,
+ 0,
+ ARRAY_SIZE(led_modes));
+   if (len >= 0) {
+   u32 reg = 0;
+   int i;
+
+   for (i = 0; i < len; i++) {
+   if (led_modes[i] > 15)
+   return -EINVAL;
+   reg |= led_modes[i] << (i * 4);
+   }
+   for (; i < ARRAY_SIZE(led_modes); i++)
+   reg |= LAN78XX_FORCE_LED_OFF << (i * 4);
+   (void)phy_write(phydev, LAN78XX_PHY_LED_MODE_SELECT, reg);
+   } else if (len == -EOVERFLOW) {
+   return -EINVAL;
+   }
+
/* these values can be used to identify internal PHY */
priv->chip_id = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_ID);
priv->chip_rev = phy_read_mmd(phydev, 3, LAN88XX_MMD3_CHIP_REV);
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a823f01..6b03b97 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "lan78xx.h"
 
@@ -1760,6 +1761,7 @@ static int lan78xx_mdiobus_write(struct mii_bus *bus, int 
phy_id, int idx,
 
 static int lan78xx_mdio_init(struct lan78xx_net *dev)
 {
+   struct device_node *node;
int ret;
 
dev->mdiobus = mdiobus_alloc();
@@ -1788,7 +1790,13 @@ static int lan78xx_mdio_init(struct lan78xx_net *dev)
break;
}
 
-   ret = mdiobus_register(dev->mdiobus);
+   node = of_get_child_by_name(dev->udev->dev.of_node, "mdio");
+   if (node) {
+   ret = of_mdiobus_register(dev->mdiobus, node);
+   of_node_put(node);
+   } else {
+   ret = mdiobus_register(dev->mdiobus);
+   }
if (ret) {
netdev_err(dev->net, "can't register MDIO bus\n");
goto exit1;
@@ -2077,6 +2085,28 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
mii_adv = (u32)mii_advertise_flowctrl(dev->fc_request_control);
phydev->advertising |= mii_adv_to_ethtool_adv_t(mii_adv);
 
+   if (phydev->mdio.dev.of_node) {
+   u32 reg;
+   int len;
+
+   len = of_property_count_elems_of_size(phydev->mdio.dev.of_node,
+ "microchip,led-modes",
+ sizeof(u32));
+   if (len >= 0) {
+   /* Ensure 

[PATCH v3 0/3] lan78xx: Read configuration from Device Tree

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

This patch set adds support for reading the MAC address and LED modes from
Device Tree.

v3:
- Move LED setting into PHY driver.

v2:
- Use eth_platform_get_mac_address.
- Support up to 4 LEDs, and move LED mode constants into dt-bindings header.
- Improve bindings document.
- Remove EEE support.

Phil Elwell (3):
  lan78xx: Read MAC address from DT if present
  lan78xx: Read LED states from Device Tree
  dt-bindings: Document the DT bindings for lan78xx

 .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 
 MAINTAINERS|  2 +
 drivers/net/phy/microchip.c| 25 
 drivers/net/usb/lan78xx.c  | 74 +++---
 include/dt-bindings/net/microchip-lan78xx.h| 21 ++
 include/linux/microchipphy.h   |  3 +
 6 files changed, 156 insertions(+), 23 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 create mode 100644 include/dt-bindings/net/microchip-lan78xx.h

-- 
2.7.4

--
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 v3 3/3] dt-bindings: Document the DT bindings for lan78xx

[Phil Elwell]

The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.

Document the supported properties in a bindings file.

Signed-off-by: Phil Elwell 
---
 .../devicetree/bindings/net/microchip,lan78xx.txt  | 54 ++
 MAINTAINERS|  1 +
 2 files changed, 55 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/microchip,lan78xx.txt

diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.txt 
b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
new file mode 100644
index 000..a5d701b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.txt
@@ -0,0 +1,54 @@
+Microchip LAN78xx Gigabit Ethernet controller
+
+The LAN78XX devices are usually configured by programming their OTP or with
+an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
+The Device Tree properties, if present, override the OTP and EEPROM.
+
+Required properties:
+- compatible: Should be one of "usb424,7800", "usb424,7801" or "usb424,7850".
+
+Optional properties:
+- local-mac-address:   see ethernet.txt
+- mac-address: see ethernet.txt
+
+Optional properties of the embedded PHY:
+- microchip,led-modes: a 0..4 element vector, with each element configuring
+  the operating mode of an LED. Omitted LEDs are turned off. Allowed values
+  are defined in "include/dt-bindings/net/microchip-lan78xx.h".
+
+Example:
+
+/* Based on the configuration for a Raspberry Pi 3 B+ */
+ {
+   usb1@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   usb1_1@1 {
+   compatible = "usb424,2514";
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethernet: usbether@1 {
+   compatible = "usb424,7800";
+   reg = <1>;
+   local-mac-address = [ 00 11 22 33 44 55 ];
+
+   mdio {
+   #address-cells = <0x1>;
+   #size-cells = <0x0>;
+   eth_phy: ethernet-phy@1 {
+   reg = <1>;
+   microchip,led-modes = <
+   
LAN78XX_LINK_1000_ACTIVITY
+   
LAN78XX_LINK_10_100_ACTIVITY
+   >;
+   };
+   };
+   };
+   };
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 23735d9..91cb961 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14572,6 +14572,7 @@ M:  Woojung Huh 
 M: Microchip Linux Driver Support 
 L: net...@vger.kernel.org
 S: Maintained
+F: Documentation/devicetree/bindings/net/microchip,lan78xx.txt
 F: drivers/net/usb/lan78xx.*
 F: include/dt-bindings/net/microchip-lan78xx.h
 
-- 
2.7.4

--
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 00/61] tree-wide: simplify getting .drvdata

[Wolfram Sang]

I got tired of fixing this in Renesas drivers manually, so I took the big
hammer. Remove this cumbersome code pattern which got copy-pasted too much
already:

-   struct platform_device *pdev = to_platform_device(dev);
-   struct ep93xx_keypad *keypad = platform_get_drvdata(pdev);
+   struct ep93xx_keypad *keypad = dev_get_drvdata(dev);

I send this out as one patch per directory per subsystem. I think they should
be applied individually. If you prefer a broken out series per subsystem, I can
provide this as well. Just mail me.

A branch (tested by buildbot; only with all commits squashed into one commit
before) can be found here:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
coccinelle/get_drvdata

Open for other comments, suggestions, too, of course.

Here is the cocci-script I created (after  iterations by manually checking
samples):

@@
struct device* d;
identifier pdev;
expression *ptr;
@@
(
-   struct platform_device *pdev = to_platform_device(d);
|
-   struct platform_device *pdev;
...
-   pdev = to_platform_device(d);
)
<... when != pdev
-   >dev
+   d
...>

ptr =
-   platform_get_drvdata(pdev)
+   dev_get_drvdata(d)

<... when != pdev
-   >dev
+   d
...>

Kind regards,

   Wolfram


Wolfram Sang (61):
  ARM: plat-samsung: simplify getting .drvdata
  ata: simplify getting .drvdata
  auxdisplay: simplify getting .drvdata
  bus: simplify getting .drvdata
  clk: samsung: simplify getting .drvdata
  crypto: simplify getting .drvdata
  dma: simplify getting .drvdata
  dmaengine: dw: simplify getting .drvdata
  dmaengine: qcom: simplify getting .drvdata
  gpio: simplify getting .drvdata
  gpu: drm: msm: simplify getting .drvdata
  gpu: drm: msm: adreno: simplify getting .drvdata
  gpu: drm: msm: disp: mdp5: simplify getting .drvdata
  gpu: drm: msm: dsi: simplify getting .drvdata
  gpu: drm: omapdrm: displays: simplify getting .drvdata
  gpu: drm: vc4: simplify getting .drvdata
  hid: simplify getting .drvdata
  iio: common: cros_ec_sensors: simplify getting .drvdata
  iio: common: hid-sensors: simplify getting .drvdata
  input: keyboard: simplify getting .drvdata
  input: misc: simplify getting .drvdata
  input: mouse: simplify getting .drvdata
  input: touchscreen: simplify getting .drvdata
  iommu: simplify getting .drvdata
  media: platform: am437x: simplify getting .drvdata
  media: platform: exynos4-is: simplify getting .drvdata
  media: platform: s5p-mfc: simplify getting .drvdata
  mmc: host: simplify getting .drvdata
  mtd: devices: simplify getting .drvdata
  mtd: nand: onenand: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  net: ethernet: cadence: simplify getting .drvdata
  net: ethernet: davicom: simplify getting .drvdata
  net: ethernet: smsc: simplify getting .drvdata
  net: ethernet: ti: simplify getting .drvdata
  net: ethernet: wiznet: simplify getting .drvdata
  perf: simplify getting .drvdata
  pinctrl: simplify getting .drvdata
  pinctrl: intel: simplify getting .drvdata
  platform: x86: simplify getting .drvdata
  power: supply: simplify getting .drvdata
  ptp: simplify getting .drvdata
  pwm: simplify getting .drvdata
  rtc: simplify getting .drvdata
  slimbus: simplify getting .drvdata
  spi: simplify getting .drvdata
  staging: greybus: simplify getting .drvdata
  staging: iio: adc: simplify getting .drvdata
  staging: nvec: simplify getting .drvdata
  thermal: simplify getting .drvdata
  thermal: int340x_thermal: simplify getting .drvdata
  thermal: st: simplify getting .drvdata
  tty: serial: simplify getting .drvdata
  uio: simplify getting .drvdata
  usb: mtu3: simplify getting .drvdata
  usb: phy: simplify getting .drvdata
  video: fbdev: simplify getting .drvdata
  video: fbdev: omap2: omapfb: displays: simplify getting .drvdata
  watchdog: simplify getting .drvdata
  net: dsa: simplify getting .drvdata
  ASoC: atmel: simplify getting .drvdata

 arch/arm/plat-samsung/adc.c|  3 +-
 drivers/ata/pata_samsung_cf.c  |  8 ++---
 drivers/auxdisplay/arm-charlcd.c   |  6 ++--
 drivers/bus/brcmstb_gisb.c | 12 +++
 drivers/clk/samsung/clk-s3c2410-dclk.c |  6 ++--
 drivers/crypto/exynos-rng.c|  6 ++--
 drivers/crypto/picoxcell_crypto.c  |  6 ++--
 drivers/dma/at_hdmac.c |  9 ++---
 drivers/dma/at_xdmac.c |  9 ++---
 drivers/dma/dw/platform.c  |  6 ++--
 drivers/dma/fsldma.c   |  6 ++--
 drivers/dma/idma64.c   |  6 ++--
 drivers/dma/qcom/hidma.c   |  3 +-
 drivers/dma/qcom/hidma_mgmt_sys.c  |  6 ++--
 drivers/dma/ste_dma40.c| 12 +++
 drivers/dma/txx9dmac.c |  8 ++---
 

[PATCH 56/61] usb: phy: simplify getting .drvdata

[Wolfram Sang]

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy. Please apply individually.

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

diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index b36fa8b953d0..27bdb7222527 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -96,8 +96,7 @@ static int am335x_phy_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int am335x_phy_suspend(struct device *dev)
 {
-   struct platform_device  *pdev = to_platform_device(dev);
-   struct am335x_phy *am_phy = platform_get_drvdata(pdev);
+   struct am335x_phy *am_phy = dev_get_drvdata(dev);
 
/*
 * Enable phy wakeup only if dev->power.can_wakeup is true.
@@ -117,8 +116,7 @@ static int am335x_phy_suspend(struct device *dev)
 
 static int am335x_phy_resume(struct device *dev)
 {
-   struct platform_device  *pdev = to_platform_device(dev);
-   struct am335x_phy   *am_phy = platform_get_drvdata(pdev);
+   struct am335x_phy   *am_phy = dev_get_drvdata(dev);
 
phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, am_phy->dr_mode, true);
 
-- 
2.11.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

[PATCH 55/61] usb: mtu3: simplify getting .drvdata

[Wolfram Sang]

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy. Please apply individually.

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

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 628d5ce356ca..46551f6d16fd 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -447,8 +447,7 @@ static int mtu3_remove(struct platform_device *pdev)
  */
 static int __maybe_unused mtu3_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct ssusb_mtk *ssusb = platform_get_drvdata(pdev);
+   struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
 
dev_dbg(dev, "%s\n", __func__);
 
@@ -466,8 +465,7 @@ static int __maybe_unused mtu3_suspend(struct device *dev)
 
 static int __maybe_unused mtu3_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct ssusb_mtk *ssusb = platform_get_drvdata(pdev);
+   struct ssusb_mtk *ssusb = dev_get_drvdata(dev);
int ret;
 
dev_dbg(dev, "%s\n", __func__);
-- 
2.11.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

Re: [PATCH 0/2] Allow xhci-plat using a second clock

[Gregory CLEMENT]

Hi Mathias,
 
 On jeu., avril 19 2018, Mathias Nyman  wrote:

> On 18.04.2018 17:20, Gregory CLEMENT wrote:
>> Hi Mathias,
>> On mer., févr. 14 2018, Gregory CLEMENT
>>  wrote:
>>
>>> Hello,
>>>
>>> The purpose of this series is to allow xhci-plat using a second
>>> clock. It is needed on the Armada 7K/8K but could be used by other
>>> SoCs.
>>>
>>> The first patch is just a fix found while I was working on this
>>> feature.
>>
>> I've just realized that this series sent 2 months ago was not merged in
>> v4.17. The issue is that now the USB support on the Armada 7K/8K is
>> broken, because the clock support part was already merged.
>>
>> You already had a look on this series one month ago. The issue you had
>> was about getting an approval for the extension of the binding [1]. I
>> pinged Rob about it [2] one month ago but we didn't get any
>> feedback. However, Rob already approved the similar changes I introduced
>> in an other for mv_xor_v2: [3].
>>
>> So would it be possible to apply this series on v4.17-rc ?
>
> Patch 2/2 no longer applies due to clk suspend/resume changes in:
>
> commit d56e57ca030c8b4296944a2ae61ac167bf979c07
> usb: host: xhci-plat: revert "usb: host: xhci-plat: enable clk in resume 
> timing"
>
> Not sure how that change affects Armada 7K/8K
> Can you rebase and resend the series?

It's done!

About the suspend/resume part it does not affect Armada 7K/8K because we
don't support it yet.

However I am a bit surprised by the commit log because reverting a
common part because of a specific implementation looks wrong. I expect
issues when we will add PM support but we will see that later.

Gregory

>
> -Mathias
>

-- 
Gregory Clement, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
--
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/2] usb: host: xhci-plat: Fix clock resource by adding a register clock

[Gregory CLEMENT]

On Armada 7K/8K we need to explicitly enable the register clock. This
clock is optional because not all the SoCs using this IP need it but at
least for Armada 7K/8K it is actually mandatory.

The change was done at xhci-plat level and not at a xhci-mvebu.c because,
it is expected that other SoC would have this kind of constraint.

The binding documentation is updating accordingly.

Signed-off-by: Gregory CLEMENT 
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt |  5 -
 drivers/usb/host/xhci-plat.c   | 25 ++
 drivers/usb/host/xhci.h|  3 ++-
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index c4c00dff4b56..bd1dd316fb23 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -28,7 +28,10 @@ Required properties:
   - interrupts: one XHCI interrupt should be described here.
 
 Optional properties:
-  - clocks: reference to a clock
+  - clocks: reference to the clocks
+  - clock-names: mandatory if there is a second clock, in this case
+the name must be "core" for the first clock and "reg" for the
+second one
   - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
   - usb3-lpm-capable: determines if platform is USB3 LPM capable
   - quirk-broken-port-ped: set if the controller has broken port disable 
mechanism
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index f0231fea524e..596e7a71b666 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -157,6 +157,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
struct resource *res;
struct usb_hcd  *hcd;
struct clk  *clk;
+   struct clk  *reg_clk;
int ret;
int irq;
 
@@ -226,17 +227,27 @@ static int xhci_plat_probe(struct platform_device *pdev)
hcd->rsrc_len = resource_size(res);
 
/*
-* Not all platforms have a clk so it is not an error if the
-* clock does not exists.
+* Not all platforms have clks so it is not an error if the
+* clock do not exist.
 */
+   reg_clk = devm_clk_get(>dev, "reg");
+   if (!IS_ERR(reg_clk)) {
+   ret = clk_prepare_enable(reg_clk);
+   if (ret)
+   goto put_hcd;
+   } else if (PTR_ERR(reg_clk) == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   goto put_hcd;
+   }
+
clk = devm_clk_get(>dev, NULL);
if (!IS_ERR(clk)) {
ret = clk_prepare_enable(clk);
if (ret)
-   goto put_hcd;
+   goto disable_reg_clk;
} else if (PTR_ERR(clk) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
-   goto put_hcd;
+   goto disable_reg_clk;
}
 
xhci = hcd_to_xhci(hcd);
@@ -252,6 +263,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
device_wakeup_enable(hcd->self.controller);
 
xhci->clk = clk;
+   xhci->reg_clk = reg_clk;
xhci->main_hcd = hcd;
xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
dev_name(>dev), hcd);
@@ -322,6 +334,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
 disable_clk:
clk_disable_unprepare(clk);
 
+disable_reg_clk:
+   clk_disable_unprepare(reg_clk);
+
 put_hcd:
usb_put_hcd(hcd);
 
@@ -337,6 +352,7 @@ static int xhci_plat_remove(struct platform_device *dev)
struct usb_hcd  *hcd = platform_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
+   struct clk *reg_clk = xhci->reg_clk;
 
xhci->xhc_state |= XHCI_STATE_REMOVING;
 
@@ -347,6 +363,7 @@ static int xhci_plat_remove(struct platform_device *dev)
usb_put_hcd(xhci->shared_hcd);
 
clk_disable_unprepare(clk);
+   clk_disable_unprepare(reg_clk);
usb_put_hcd(hcd);
 
pm_runtime_set_suspended(>dev);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 05c909b04f14..6dfc4867dbcf 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1729,8 +1729,9 @@ struct xhci_hcd {
int page_shift;
/* msi-x vectors */
int msix_count;
-   /* optional clock */
+   /* optional clocks */
struct clk  *clk;
+   struct clk  *reg_clk;
/* data structures */
struct xhci_device_context_array *dcbaa;
struct xhci_ring*cmd_ring;
-- 
2.16.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 

[PATCH v2 0/2] Allow xhci-plat using a second clock

[Gregory CLEMENT]

Hello,

The purpose of this series is to allow xhci-plat using a second
clock. It is needed on the Armada 7K/8K but could be used by other
SoCs.

The first patch is just an other fix found while I was working on this
feature.

Thanks,

Gregory

Changelog:
v1 -> v2:

 - Rebased on v4.17-rc1

Gregory CLEMENT (2):
  usb: host: xhci-plat: Remove useless test before clk_disable_unprepare
  usb: host: xhci-plat: Fix clock resource by adding a register clock

 Documentation/devicetree/bindings/usb/usb-xhci.txt |  5 +++-
 drivers/usb/host/xhci-plat.c   | 31 --
 drivers/usb/host/xhci.h|  3 ++-
 3 files changed, 29 insertions(+), 10 deletions(-)

-- 
2.16.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 v2 1/2] usb: host: xhci-plat: Remove useless test before clk_disable_unprepare

[Gregory CLEMENT]

clk_disable_unprepare() already checks that the clock pointer is valid.
No need to test it before calling it.

Signed-off-by: Gregory CLEMENT 
---
 drivers/usb/host/xhci-plat.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df327dcc2bac..f0231fea524e 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -320,8 +320,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
usb_put_hcd(xhci->shared_hcd);
 
 disable_clk:
-   if (!IS_ERR(clk))
-   clk_disable_unprepare(clk);
+   clk_disable_unprepare(clk);
 
 put_hcd:
usb_put_hcd(hcd);
@@ -347,8 +346,7 @@ static int xhci_plat_remove(struct platform_device *dev)
usb_remove_hcd(hcd);
usb_put_hcd(xhci->shared_hcd);
 
-   if (!IS_ERR(clk))
-   clk_disable_unprepare(clk);
+   clk_disable_unprepare(clk);
usb_put_hcd(hcd);
 
pm_runtime_set_suspended(>dev);
-- 
2.16.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: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

[Felipe Balbi]

Hi,

Bin Liu  writes:
>> Felipe Balbi  writes:
>> >>> Bin Liu  writes:
>> >>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
>> >>> >> Hi guys,
>> >>> >> 
>> >>> >> I've been working on this series for a while now. I feels like after
>> >>> >> this series the transfer management code is far easier to read and
>> >>> >> understand.
>> >>> >> 
>> >>> >> Based on my tests, I have no regressions. Tested g_mass_storage and 
>> >>> >> all
>> >>> >> of testusb's tests (including ISOC).
>> >>> >> 
>> >>> >> Patches are also available on dwc3-improve-isoc-endpoints in my k.org
>> >>> >> tree. Test reports would be VERY, VERY, VERY welcome. Please give 
>> >>> >> this a
>> >>> >> go so we avoid regressions on v4.18.
>> >>> >
>> >>> > Have you tested g_webcam? I just tested your 
>> >>> > dwc3-improve-isoc-endpoints
>> >>> 
>> >>> for isoc I only tested g_zero.
>> >>
>> >> Then writting down details on what I observed probably won't help you :(
>> 
>> I got webcam running here, it sure _is_ helpful to let me know how you
>
> Great!
>
>> trigger the problem ;-) Also, high-speed or super-speed?
>
> Both. Long story short - super-speed doesn't stream the yuv video,
> gadget side kernel prints "VS request completed with status -18."
> flooding messages.

this means Missed Isoc.

> high-speed does stream the video, but stopping the host application
> (both yavta and luvcview) causes gadget side kernel prints error message
> (I didn't keep the log). Then restart the host application doesn't
> stream the video any more.
>
> To run the test:
> gadget side:
>   # modprobe g_webcam (streaming_maxpacket=3072 for super-speed)
>   # uvc-gadget
> host side:
>   $ yavta -c -f YUYV -t 1/30 -s 640x360 -n4 /dev/video1, or
>   $ luvcview -d /dev/video1 -f yuv

running with yavta here. I see a lot of Missed Isoc. That shouldn't
happen if we're just updating transfers. Perhaps the controller needs to
Start Transfer per-interval? Though that would be pretty lame, I don't
think that's the case.

I'll debug more tomorrow.

>> >>> > branch on TI VAYU evm, it has issues in both high-speed and super-speed
>> >>> > connections. It works fine with v4.17-rc1.
>> >>> >
>> >>> > If it suppose to work with g-webcam, please let me know if you want
>> >>> > the details of the problems I see - the log is very long in super-speed
>> >>> > failure.
>> >>> 
>> >>> Sure, give me some details of what's going on. Some bisection would be
>> >>> great too, then I'll know which patch to blame and where to focus fixes.
>> >>
>> >> Roger has a copy of your previous work here:
>> >>
>> >> g...@github.com:rogerq/linux.git, branch balbi-dwc3-improve-isoc-endpoints
>> >>
>> >> I just tested it and it works fine with g_webcam.
>> >>
>> >> Do you think this information will help you? If so it saves me time on
>> >> bisect ;)
>> >
>> > What's the SHA1 on that? I can diff it locally and see if I can find
>> > problems.
>> 
>> I got this one from Roger. There's nothing in there that should cause
>> any changes to the behavior.
>> 
>> Please capture tracepoints of both working and failing cases and send to
>> me. More details at [1]
>
> I will try to capture the traces tomorrow.

thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

[Bin Liu]

On Thu, Apr 19, 2018 at 02:18:21PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Felipe Balbi  writes:
> >>> Bin Liu  writes:
> >>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
> >>> >> Hi guys,
> >>> >> 
> >>> >> I've been working on this series for a while now. I feels like after
> >>> >> this series the transfer management code is far easier to read and
> >>> >> understand.
> >>> >> 
> >>> >> Based on my tests, I have no regressions. Tested g_mass_storage and all
> >>> >> of testusb's tests (including ISOC).
> >>> >> 
> >>> >> Patches are also available on dwc3-improve-isoc-endpoints in my k.org
> >>> >> tree. Test reports would be VERY, VERY, VERY welcome. Please give this 
> >>> >> a
> >>> >> go so we avoid regressions on v4.18.
> >>> >
> >>> > Have you tested g_webcam? I just tested your dwc3-improve-isoc-endpoints
> >>> 
> >>> for isoc I only tested g_zero.
> >>
> >> Then writting down details on what I observed probably won't help you :(
> 
> I got webcam running here, it sure _is_ helpful to let me know how you

Great!

> trigger the problem ;-) Also, high-speed or super-speed?

Both. Long story short - super-speed doesn't stream the yuv video,
gadget side kernel prints "VS request completed with status -18."
flooding messages.

high-speed does stream the video, but stopping the host application
(both yavta and luvcview) causes gadget side kernel prints error message
(I didn't keep the log). Then restart the host application doesn't
stream the video any more.

To run the test:
gadget side:
# modprobe g_webcam (streaming_maxpacket=3072 for super-speed)
# uvc-gadget
host side:
$ yavta -c -f YUYV -t 1/30 -s 640x360 -n4 /dev/video1, or
$ luvcview -d /dev/video1 -f yuv

> 
> >>> > branch on TI VAYU evm, it has issues in both high-speed and super-speed
> >>> > connections. It works fine with v4.17-rc1.
> >>> >
> >>> > If it suppose to work with g-webcam, please let me know if you want
> >>> > the details of the problems I see - the log is very long in super-speed
> >>> > failure.
> >>> 
> >>> Sure, give me some details of what's going on. Some bisection would be
> >>> great too, then I'll know which patch to blame and where to focus fixes.
> >>
> >> Roger has a copy of your previous work here:
> >>
> >> g...@github.com:rogerq/linux.git, branch balbi-dwc3-improve-isoc-endpoints
> >>
> >> I just tested it and it works fine with g_webcam.
> >>
> >> Do you think this information will help you? If so it saves me time on
> >> bisect ;)
> >
> > What's the SHA1 on that? I can diff it locally and see if I can find
> > problems.
> 
> I got this one from Roger. There's nothing in there that should cause
> any changes to the behavior.
> 
> Please capture tracepoints of both working and failing cases and send to
> me. More details at [1]

I will try to capture the traces tomorrow.

> 
> [1] 
> https://www.kernel.org/doc/html/v4.16/driver-api/usb/dwc3.html#reporting-bugs

Regards,
-Bin.
>
--
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 0/1] usb: gadget: udc: fsl: Introduce FSL_USB2_PHY_UTMI_DUAL

[Tiago Brusamarello]

Initialization for SoCs with dual role phy is being bypassed since
FSL_USB2_PHY_UTMI_DUAL macro is not being evaluated in the FSL gadget
driver. In this state a controller configured in peripheral mode will
not work as a gadget. This patch addresses this issue.

Tested on 4.14.32 using a hardware with the T1024 SoC.

Nikhil Badola (1):
  drivers: usb: Introduce FSL_USB2_PHY_UTMI_DUAL for usb gadget

 drivers/usb/gadget/udc/fsl_udc_core.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.7.4
--
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: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

[Felipe Balbi]

Hi,

Felipe Balbi  writes:
>>> Bin Liu  writes:
>>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
>>> >> Hi guys,
>>> >> 
>>> >> I've been working on this series for a while now. I feels like after
>>> >> this series the transfer management code is far easier to read and
>>> >> understand.
>>> >> 
>>> >> Based on my tests, I have no regressions. Tested g_mass_storage and all
>>> >> of testusb's tests (including ISOC).
>>> >> 
>>> >> Patches are also available on dwc3-improve-isoc-endpoints in my k.org
>>> >> tree. Test reports would be VERY, VERY, VERY welcome. Please give this a
>>> >> go so we avoid regressions on v4.18.
>>> >
>>> > Have you tested g_webcam? I just tested your dwc3-improve-isoc-endpoints
>>> 
>>> for isoc I only tested g_zero.
>>
>> Then writting down details on what I observed probably won't help you :(

I got webcam running here, it sure _is_ helpful to let me know how you
trigger the problem ;-) Also, high-speed or super-speed?

>>> > branch on TI VAYU evm, it has issues in both high-speed and super-speed
>>> > connections. It works fine with v4.17-rc1.
>>> >
>>> > If it suppose to work with g-webcam, please let me know if you want
>>> > the details of the problems I see - the log is very long in super-speed
>>> > failure.
>>> 
>>> Sure, give me some details of what's going on. Some bisection would be
>>> great too, then I'll know which patch to blame and where to focus fixes.
>>
>> Roger has a copy of your previous work here:
>>
>> g...@github.com:rogerq/linux.git, branch balbi-dwc3-improve-isoc-endpoints
>>
>> I just tested it and it works fine with g_webcam.
>>
>> Do you think this information will help you? If so it saves me time on
>> bisect ;)
>
> What's the SHA1 on that? I can diff it locally and see if I can find
> problems.

I got this one from Roger. There's nothing in there that should cause
any changes to the behavior.

Please capture tracepoints of both working and failing cases and send to
me. More details at [1]

[1] 
https://www.kernel.org/doc/html/v4.16/driver-api/usb/dwc3.html#reporting-bugs

-- 
balbi


signature.asc
Description: PGP signature

Re: NULL pointer dereference in xhci_suspend

[Mathias Nyman]

On 18.04.2018 20:30, Nazar Mokrynskyi wrote:

Hi everyone, I'm running a VM using libvirt on kernel 4.15 (Ubuntu 18.04).

ASMedia USB 3.1 Gen 2 controller is assigned to VM like this:

     
   
     
   
   
   
     

Occasionally VM start fails with following error and I'm unable to start a VM 
anymore until reboot:

[40061.976095] BUG: unable to handle kernel NULL pointer dereference at 
0228
[40061.976107] IP: xhci_suspend+0x3a/0x490
[40061.976109] PGD 0 P4D 0
[40061.976115] Oops:  [#1] SMP PTI
[40061.976118] Modules linked in: cpuid vhost_net vhost tap vfio_pci 
vfio_virqfd vfio_iommu_type1 vfio xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 
xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables 
devlink iptable_filter binfmt_misc snd_hda_codec_hdmi intel_rapl 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass 
intel_cstate nls_iso8859_1 mxm_wmi snd_hda_intel snd_usb_audio snd_hda_codec 
snd_usbmidi_lib snd_hda_core snd_rawmidi snd_hwdep snd_seq_device joydev 
input_leds intel_rapl_perf snd_pcm cdc_acm snd_timer snd mei_me soundcore mei 
shpchp wmi nvidia_uvm(POE) acpi_pad mac_hid sch_fq_codel lp parport bfq 
ip_tables
[40061.976185]  x_tables autofs4 btrfs xor zstd_compress raid6_pq 
algif_skcipher af_alg dm_crypt hid_generic usbhid hid uas usb_storage 
crct10dif_pclmul crc32_pclmul nvidia_drm(POE) ghash_clmulni_intel 
nvidia_modeset(POE) pcbc i915 nvidia(POE) aesni_intel aes_x86_64 crypto_simd 
i2c_algo_bit glue_helper cryptd drm_kms_helper e1000e syscopyarea sysfillrect 
sysimgblt fb_sys_fops ptp nvme pps_core drm nvme_core ahci ipmi_devintf libahci 
ipmi_msghandler video
[40061.976230] CPU: 7 PID: 29745 Comm: kworker/7:0 Tainted: P   OE    
4.15.0-17-generic #18-Ubuntu
[40061.976232] Hardware name: Micro-Star International Co., Ltd. MS-7B45/Z370 
GAMING PRO CARBON (MS-7B45), BIOS A.51 03/29/2018
[40061.976239] Workqueue: pm pm_runtime_work
[40061.976245] RIP: 0010:xhci_suspend+0x3a/0x490
[40061.976248] RSP: 0018:a5dca0747c40 EFLAGS: 00010246
[40061.976252] RAX: ffea RBX: 913dc3106000 RCX: 
[40061.976254] RDX:  RSI: 0001 RDI: 913dc3106230
[40061.976257] RBP: a5dca0747c78 R08:  R09: a5dca0747db8
[40061.976259] R10:  R11: 01cc R12: 913dc3106000
[40061.976262] R13: 913dc3106000 R14: 913dc3106230 R15: b86efaa0
[40061.976265] FS:  () GS:913e2e7c() 
knlGS:
[40061.976268] CS:  0010 DS:  ES:  CR0: 80050033
[40061.976271] CR2: 0228 CR3: 00031460a003 CR4: 003606e0
[40061.976274] DR0:  DR1:  DR2: 
[40061.976276] DR3:  DR6: fffe0ff0 DR7: 0400
[40061.976278] Call Trace:
[40061.976286]  ? pci_pm_runtime_resume+0xa0/0xa0
[40061.976292]  xhci_pci_suspend+0x5a/0xd0
[40061.976297]  suspend_common+0x85/0x160
[40061.976302]  hcd_pci_runtime_suspend+0x1b/0x50
[40061.976306]  pci_pm_runtime_suspend+0x64/0x180
[40061.976311]  ? pci_pm_runtime_resume+0xa0/0xa0
[40061.976315]  __rpm_callback+0xca/0x210
[40061.976320]  ? __switch_to_asm+0x34/0x70
[40061.976324]  ? __switch_to_asm+0x40/0x70
[40061.976329]  rpm_callback+0x24/0x80
[40061.976333]  ? pci_pm_runtime_resume+0xa0/0xa0
[40061.976338]  rpm_suspend+0x137/0x640
[40061.976343]  rpm_idle+0x58/0x2a0
[40061.976348]  pm_runtime_work+0x92/0xa0
[40061.976353]  process_one_work+0x1de/0x410
[40061.976357]  worker_thread+0x32/0x410
[40061.976362]  kthread+0x121/0x140
[40061.976366]  ? process_one_work+0x410/0x410
[40061.976371]  ? kthread_create_worker_on_cpu+0x70/0x70
[40061.976376]  ? do_syscall_64+0x73/0x130
[40061.976380]  ? SyS_exit_group+0x14/0x20
[40061.976383]  ret_from_fork+0x35/0x40
[40061.976387] Code: 41 54 53 48 83 ec 10 4c 8b 2f 41 8b 85 28 02 00 00 85 c0 0f 84 
d1 01 00 00 83 f8 04 0f 85 51 04 00 00 48 8b 57 08 b8 ea ff ff ff <83> ba 28 02 
00 00 04 0f 85 04 01 00 00 41 89 f6 49 89 fc e8 9e
[40061.976443] RIP: xhci_suspend+0x3a/0x490 RSP: a5dca0747c40
[40061.976445] CR2: 0228
[40061.976449] ---[ end trace 5f17622537522ef8 ]---

Nothing was attached to this controller when error happened.


Looks like xhci controller was runtime suspended before everything was set up.

Normally PCI core will enable runtime pm, forbid it, and increase usage counter (0 
-> 1) before pci driver probe is called.
xhci_pci_probe() increases usage count again (1 -> 2) before creating two hcds.
the first hcd is created using  usb_hcd_pci_probe() which decreases usage (2 -> 
1),
xhci_pci_probe() creates and adds second hcd manually, after which it decreases 
usage (1 -> 0)

I'm not sure how running a VM affects this, but in case usage 

[PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

Historically, the clocks and resets are handled on the glue layer
side instead of the DWC3 core.  For simple cases, dwc3-of-simple.c
takes care of arbitrary number of clocks and resets.  The DT node
structure typically looks like as follows:

  dwc3-glue {
  compatible = "foo,dwc3";
  clocks = ...;
  resets = ...;
  ...

  dwc3 {
  compatible = "snps,dwc3";
  ...
  };
  }

By supporting the clocks and the reset in the dwc3/core.c, it will
be turned into a single node:

  dwc3 {
  compatible = "foo,dwc3", "snps,dwc3";
  clocks = ...;
  resets = ...;
  ...
  }

This commit adds the binding of clocks and resets specific to this IP.
The number of clocks should generally be the same across SoCs, it is
just some SoCs either tie clocks together or do not provide software
control of some of the clocks.

I took the clock names from the Synopsys datasheet: "ref" (ref_clk),
"bus_early" (bus_clk_early), and "suspend" (suspend_clk).

I found only one reset line in the datasheet, hence the reset-names
property is omitted.

Supporting those clocks and resets is the requirement for new platforms.
Enforcing the new binding breaks existing platforms since they specify
clocks and resets in their glue layer node, but nothing in the core
node.  I listed such exceptional cases in the DT binding.  The driver
code is loosened up to accept no clock/reset.  This change is based
on the discussion [1].

I inserted reset_control_deassert() and clk_bulk_enable() before the
first register access, i.e. dwc3_cache_hwparams().

[1] https://patchwork.kernel.org/patch/10284265/

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Make clocks specific to this IP based on Synopsys datasheet
  - Use clk_bulk API
  - Add description to struct header

 Documentation/devicetree/bindings/usb/dwc3.txt | 21 ++
 drivers/usb/dwc3/core.c| 89 +-
 drivers/usb/dwc3/core.h|  8 +++
 3 files changed, 116 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 0dbd308..feb1cc33 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -7,6 +7,27 @@ Required properties:
  - compatible: must be "snps,dwc3"
  - reg : Address and length of the register set for the device
  - interrupts: Interrupts used by the dwc3 controller.
+ - clock-names: should contain "ref", "bus_early", "suspend"
+ - clocks: list of phandle and clock specifier pairs corresponding to
+   entries in the clock-names property.
+ - resets: a single pair of phandle and reset specifier
+
+Exception for clocks and resets:
+  clocks and resets are optional if the parent node (i.e. glue-layer)
+  is compatible to one of the following:
+"amlogic,meson-axg-dwc3"
+"amlogic,meson-gxl-dwc3"
+"cavium,octeon-7130-usb-uctl"
+"qcom,dwc3"
+"samsung,exynos5250-dwusb3"
+"samsung,exynos7-dwusb3"
+"sprd,sc9860-dwc3"
+"st,stih407-dwc3"
+"ti,am437x-dwc3"
+"ti,dwc3"
+"ti,keystone-dwc3"
+"rockchip,rk3399-dwc3"
+"xlnx,zynqmp-dwc3"
 
 Optional properties:
  - usb-phy : array of phandle for the PHY device.  The first element
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 8e66edd..15e1613 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -8,6 +8,7 @@
  * Sebastian Andrzej Siewior 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -24,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -266,6 +268,12 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
return 0;
 }
 
+static const struct clk_bulk_data dwc3_core_clks[] = {
+   { .id = "ref" },
+   { .id = "bus_early" },
+   { .id = "suspend" },
+};
+
 /*
  * dwc3_frame_length_adjustment - Adjusts frame length if required
  * @dwc3: Pointer to our controller context structure
@@ -667,6 +675,9 @@ static void dwc3_core_exit(struct dwc3 *dwc)
usb_phy_set_suspend(dwc->usb3_phy, 1);
phy_power_off(dwc->usb2_generic_phy);
phy_power_off(dwc->usb3_generic_phy);
+   clk_bulk_disable(dwc->num_clks, dwc->clks);
+   clk_bulk_unprepare(dwc->num_clks, dwc->clks);
+   reset_control_assert(dwc->reset);
 }
 
 static bool dwc3_core_is_valid(struct dwc3 *dwc)
@@ -1256,6 +1267,12 @@ static int dwc3_probe(struct platform_device *pdev)
if (!dwc)
return -ENOMEM;
 
+   dwc->clks = devm_kmemdup(dev, dwc3_core_clks, sizeof(dwc3_core_clks),
+GFP_KERNEL);
+   if (!dwc->clks)
+   return -ENOMEM;
+
+   dwc->num_clks = ARRAY_SIZE(dwc3_core_clks);
dwc->dev = dev;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1286,6 

[PATCH v2 0/2] usb: dwc3: support clocks and resets for DWC3 core

[Masahiro Yamada]

In the current design of DWC3 driver,
the DT typically becomes a nested structure like follows:

  dwc3-glue {
  compatible = "foo,dwc3";
  ...

  dwc3 {
  compatible = "snps,dwc3";
  ...
  };
  }

The current DWC3 core (drivers/usb/dwc3/core.c) can not handle
clocks / resets at all.

The only solution we have now, is to put DWC3 core node under
the glue layer node, then add clocks and resets there.
Actually, dwc3-of-simple.c exists to handle clocks and resets.

As always for digital circuits, DWC3 core IP itself needs clock input.
This is specific to this IP.  So, supporting clocks and resets in
dwc3/core.c makes sense.

In this version, the number of clocks (and names) is specific
to this IP, with clock names taken from Synopsys datasheet.


Masahiro Yamada (2):
  usb: dwc3: use local copy of resource to fix-up register offset
  usb: dwc3: support clocks and resets for DWC3 core

 Documentation/devicetree/bindings/usb/dwc3.txt |  21 +
 drivers/usb/dwc3/core.c| 119 +++--
 drivers/usb/dwc3/core.h|   8 ++
 3 files changed, 123 insertions(+), 25 deletions(-)

-- 
2.7.4

--
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/2] usb: dwc3: use local copy of resource to fix-up register offset

[Masahiro Yamada]

It is not a good idea to directly modify the resource of a platform
device.  Modify its local copy, and pass it to devm_ioremap_resource()
so that we do not need to restore it in the failure path and the remove
hook.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Masami Hiramatsu 
---

Changes in v2: None

 drivers/usb/dwc3/core.c | 32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a15648d..8e66edd 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1245,7 +1245,7 @@ static void dwc3_check_params(struct dwc3 *dwc)
 static int dwc3_probe(struct platform_device *pdev)
 {
struct device   *dev = >dev;
-   struct resource *res;
+   struct resource *res, dwc_res;
struct dwc3 *dwc;
 
int ret;
@@ -1270,20 +1270,19 @@ static int dwc3_probe(struct platform_device *pdev)
dwc->xhci_resources[0].flags = res->flags;
dwc->xhci_resources[0].name = res->name;
 
-   res->start += DWC3_GLOBALS_REGS_START;
-
/*
 * Request memory region but exclude xHCI regs,
 * since it will be requested by the xhci-plat driver.
 */
-   regs = devm_ioremap_resource(dev, res);
-   if (IS_ERR(regs)) {
-   ret = PTR_ERR(regs);
-   goto err0;
-   }
+   dwc_res = *res;
+   dwc_res.start += DWC3_GLOBALS_REGS_START;
+
+   regs = devm_ioremap_resource(dev, _res);
+   if (IS_ERR(regs))
+   return PTR_ERR(regs);
 
dwc->regs   = regs;
-   dwc->regs_size  = resource_size(res);
+   dwc->regs_size  = resource_size(_res);
 
dwc3_get_properties(dwc);
 
@@ -1350,29 +1349,14 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
 
-err0:
-   /*
-* restore res->start back to its original value so that, in case the
-* probe is deferred, we don't end up getting error in request the
-* memory region the next time probe is called.
-*/
-   res->start -= DWC3_GLOBALS_REGS_START;
-
return ret;
 }
 
 static int dwc3_remove(struct platform_device *pdev)
 {
struct dwc3 *dwc = platform_get_drvdata(pdev);
-   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 
pm_runtime_get_sync(>dev);
-   /*
-* restore res->start back to its original value so that, in case the
-* probe is deferred, we don't end up getting error in request the
-* memory region the next time probe is called.
-*/
-   res->start -= DWC3_GLOBALS_REGS_START;
 
dwc3_debugfs_exit(dwc);
dwc3_core_exit_mode(dwc);
-- 
2.7.4

--
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: Bluetooth controller falling off USB bus after an hour of continuous BT headset usage

[Oliver Neukum]

Am Mittwoch, den 18.04.2018, 16:42 +0200 schrieb Dominik 'Rathann'
Mierzejewski:
> On Thursday, 15 March 2018 at 16:53, Dominik 'Rathann' Mierzejewski wrote:
> [...]
> > Could you give me any pointers for debugging this? I cannot trigger
> > this on-demand, but when I'm in a conference call, it occurs within
> > an hour or two of continuous usage of my BT headset in HFP mode.
> > 
> > I originally reported it against the Bluetooth stack here:
> > https://bugzilla.kernel.org/show_bug.cgi?id=198803
> > but I'm not sure if it's an issue with Bluetooth stack or the USB stack.
> > You can find dmesg and lsusb output attached there.
> 
> Anyone?

This is a USB issue. Your logs show merely disconnect with a subsequent
reenummeration. Switch on dynamic debugging for XHCI at least.
There is nothing useful in the logs to go on otherwise.
At a hunch try whether "usbcore.autosuspend=-1" on the kernel
command line helps.

Regards
Oliver

--
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: sr 6:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

[Oliver Neukum]

Am Mittwoch, den 18.04.2018, 10:34 -0300 schrieb Cristian:
> Hello,
> 
> Open bug in launchpad.net
> https://bugs.launchpad.net/bugs/1765043

Hi,

some more details perhaps? Did this happen during enumeration?
With or without a medium? And so on.

sr should be able to deal with such things. Please take this to linux-
scsi, as Alan suggested and provide at least a full dmesg with your
report.

Regards
Oliver

--
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] USB: Increment wakeup count on remote wakeup.

[kbuild test robot]

Hi Ravi,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.17-rc1 next-20180419]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ravi-Chandra-Sadineni/USB-Increment-wakeup-count-on-remote-wakeup/20180419-165317
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: x86_64-randconfig-x013-201815 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/usb//core/hcd.c: In function 'usb_hcd_resume_root_hub':
>> drivers/usb//core/hcd.c:2378:18: error: 'dev' undeclared (first use in this 
>> function); did you mean 'cdev'?
 pm_wakeup_event(dev, 0);
 ^~~
 cdev
   drivers/usb//core/hcd.c:2378:18: note: each undeclared identifier is 
reported only once for each function it appears in

vim +2378 drivers/usb//core/hcd.c

  2364  
  2365  /**
  2366   * usb_hcd_resume_root_hub - called by HCD to resume its root hub
  2367   * @hcd: host controller for this root hub
  2368   *
  2369   * The USB host controller calls this function when its root hub is
  2370   * suspended (with the remote wakeup feature enabled) and a remote
  2371   * wakeup request is received.  The routine submits a workqueue request
  2372   * to resume the root hub (that is, manage its downstream ports again).
  2373   */
  2374  void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
  2375  {
  2376  unsigned long flags;
  2377  
> 2378  pm_wakeup_event(dev, 0);
  2379  spin_lock_irqsave (_root_hub_lock, flags);
  2380  if (hcd->rh_registered) {
  2381  set_bit(HCD_FLAG_WAKEUP_PENDING, >flags);
  2382  queue_work(pm_wq, >wakeup_work);
  2383  }
  2384  spin_unlock_irqrestore (_root_hub_lock, flags);
  2385  }
  2386  EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
  2387  

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


.config.gz
Description: application/gzip

Re: [PATCH] USB: Increment wakeup count on remote wakeup.

[kbuild test robot]

Hi Ravi,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.17-rc1 next-20180419]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ravi-Chandra-Sadineni/USB-Increment-wakeup-count-on-remote-wakeup/20180419-165317
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: i386-randconfig-s0-201815 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/usb/core/hcd.c: In function 'usb_hcd_resume_root_hub':
>> drivers/usb/core/hcd.c:2378:18: error: 'dev' undeclared (first use in this 
>> function)
 pm_wakeup_event(dev, 0);
 ^~~
   drivers/usb/core/hcd.c:2378:18: note: each undeclared identifier is reported 
only once for each function it appears in

vim +/dev +2378 drivers/usb/core/hcd.c

  2364  
  2365  /**
  2366   * usb_hcd_resume_root_hub - called by HCD to resume its root hub
  2367   * @hcd: host controller for this root hub
  2368   *
  2369   * The USB host controller calls this function when its root hub is
  2370   * suspended (with the remote wakeup feature enabled) and a remote
  2371   * wakeup request is received.  The routine submits a workqueue request
  2372   * to resume the root hub (that is, manage its downstream ports again).
  2373   */
  2374  void usb_hcd_resume_root_hub (struct usb_hcd *hcd)
  2375  {
  2376  unsigned long flags;
  2377  
> 2378  pm_wakeup_event(dev, 0);
  2379  spin_lock_irqsave (_root_hub_lock, flags);
  2380  if (hcd->rh_registered) {
  2381  set_bit(HCD_FLAG_WAKEUP_PENDING, >flags);
  2382  queue_work(pm_wq, >wakeup_work);
  2383  }
  2384  spin_unlock_irqrestore (_root_hub_lock, flags);
  2385  }
  2386  EXPORT_SYMBOL_GPL(usb_hcd_resume_root_hub);
  2387  

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


.config.gz
Description: application/gzip

Re: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Oliver Neukum]

Am Mittwoch, den 18.04.2018, 12:34 +0530 schrieb Tushar Nimkar:
> Oliver/Greg,
> Weather you are able to reproduce the issue?
> Did you tested it on dwc3 previously?

I don't even have a dwc3.
May I suggest that you try to determine whether the issue
happens on the same SCSI command? We need to know what
triggers it.

Sorry
Oliver

--
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: Fwd: usb: uas: device reset most the time while enumeration- usb3.0

[Oliver Neukum]

Am Mittwoch, den 18.04.2018, 12:44 +0530 schrieb Tushar Nimkar:
> On 2018-04-17 12:03, Tushar Nimkar wrote:

Hi,

> I have doubt that sequential scan(scsi_sequential_lun_scan) work well 
> for uas device(SCSI>3)..
> Why? As I have seen in most cases failed to enumerate during REPORT_LUN 
> command...and there is older way to scan disk is also present,
> so I was thinking to try that.. did following things
> 
> starget->no_report_luns = 1  ---> for my target while uas_target_alloc 
> (for try)

In general the spec is one thing and reality is another thing.
You can depend really only on what recent versions of Windows do.

> 
> Found it is doing sequential scan but popuating 256 entries in cat 
> proc/partiction
> for one disk
> root@OpenWrt:/# cat proc/partitions
> major minor  #blocks  name
> 
> 80  488386584 sda
> 81  488384032 sda1
> 8   48  488386584 sdd
> 8   49  488384032 sdd1
> 8   64  488386584 sde
> 8   65  488384032 sde1
> 8   80  488386584 sdf
> 8   81  488384032 sdf1
> 8   96  488386584 sdg
> 8   97  488384032 sdg1
> 8  112  488386584 sdh
> 8  113  488384032 sdh1
> 256 total.
> 
> ...though it is SCSI>3 device ,it should support both sequential as well 
> as REPORT_LUN?

In theory.

> Do not know weather this is the cause for the issue or not ...but if so 
> need to think on this too :)

Well, does your original issue go away if you use NO_REPORT_LUN
and does your device have multiple LUNs?

Regards
Oliver

--
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 resend] usb: chipidea: Don't select EXTCON

[Jisheng Zhang]

Not all chipidea users need EXTCON, so it's better to avoid
unconditionally select EXTCON, this could save us 2KB kernel Image size.

Signed-off-by: Jisheng Zhang 
---
 drivers/usb/chipidea/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 785f0ed037f7..97509172d536 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -1,7 +1,6 @@
 config USB_CHIPIDEA
tristate "ChipIdea Highspeed Dual Role Controller"
depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && 
!USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
-   select EXTCON
select RESET_CONTROLLER
help
  Say Y here if your system has a dual role high speed USB
-- 
2.17.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

Re: [PATCH 0/3] USB: musb: dsps: phy fix and DT-topology support

[Johan Hovold]

On Wed, Apr 18, 2018 at 09:18:30PM +0200, Martin Blumenstingl wrote:
> Hi Johan,
> 
> On Fri, Apr 13, 2018 at 5:15 PM, Johan Hovold  wrote:
> > I've been carrying a patch out-of-tree since my work on improving the
> > USB device-tree support which is needed to be able to describe USB
> > topologies for musb based controllers.
> >
> > This patch, which associates the platform controller device with the
> > glue device device-tree node, did not play well with the recent changes
> > which added generic phy support to USB core however.
> I'm the one who added this
> 
> > Like the recent dwc2 regression fixed by Arnd after the device-tree
> > #phy-cell changes, the generic phy code in USB core can now also fail
> > indefinitly with -EPROBE_DEFER when the controller uses a legacy USB
> > phy.
> >
> > The second patch addresses this for musb, which handles its own (legacy
> > and generic) phys, but something more may possibly now be needed for
> > other platforms with legacy phys.
> I'm not sure if I understand the problem yet - could you please
> explain with your words what "legacy PHYs" are and how the "conflict"
> with the PHY handling in USB core?
> 
> I am aware of two PHY subsystems:
> - drivers/phy
> -- also called "generic PHY framework"
> -- uses a "phys" property

Right, and these are sometimes referred to as generic PHYs, as opposed
to...

> - drivers/usb/phy
> -- also called "USB PHY framework"
> -- AFAIK this should not be used for new drivers

...the legacy ones.

> -- uses an "usb-phy" property

This is unfortunately not always the case however; some legacy USB phys
are also referred to using a "phys" property...

> the new PHY handling in USB core only parses the "phys" property and
> thus should not conflict with "usb-phy" (the legacy property)

> however, I probably missed something so I'd appreciate an explanation
> how things can break

...and that is the problem. Specifically, since last fall when a number
of legacy-phy nodes had a #phy-cells property added to them (to silence
DTC warnings), the generic PHY subsubsystem can now return -EPROBE_DEFER
indefinitely when looking up a phy as it finds a matching device-tree
node, but for which there will never be a generic phy registered (since
it's handled by a legacy-phy driver).

I referred to Arnd's workaround for "usb-nop-xceiv" devices

b7563e2796f8 ("phy: work around 'phys' references to
usb-nop-xceiv devices")

which has some more background on this.

So if we have any other host controllers out there using
"phys"-properties with legacy phys other than "usb-nop-xceiv", then
these will now fail to register (with -EPROBE_DEFER) unless
hcd->skip_phy_initialization is set (or we blacklist them as well in the
generic phy code).

I'm not aware of any further examples, but we're sure to find out soon
enough if there are.

Perhaps we should blacklist also "ti,am335x-usb-phy" in the generic phy
code even if hcd->skip_phy_initialization is still needed for musb for
the time being anyway.

Johan
--
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: [RFT/PATCH 00/38] usb: dwc3: gadget: Rework & Refactoring

[Felipe Balbi]

Hi,

Bin Liu  writes:
> On Wed, Apr 18, 2018 at 08:20:28AM +0300, Felipe Balbi wrote:
>> 
>> Hi Bin,
>> 
>> Bin Liu  writes:
>> > On Mon, Apr 09, 2018 at 02:26:14PM +0300, Felipe Balbi wrote:
>> >> Hi guys,
>> >> 
>> >> I've been working on this series for a while now. I feels like after
>> >> this series the transfer management code is far easier to read and
>> >> understand.
>> >> 
>> >> Based on my tests, I have no regressions. Tested g_mass_storage and all
>> >> of testusb's tests (including ISOC).
>> >> 
>> >> Patches are also available on dwc3-improve-isoc-endpoints in my k.org
>> >> tree. Test reports would be VERY, VERY, VERY welcome. Please give this a
>> >> go so we avoid regressions on v4.18.
>> >
>> > Have you tested g_webcam? I just tested your dwc3-improve-isoc-endpoints
>> 
>> for isoc I only tested g_zero.
>
> Then writting down details on what I observed probably won't help you :(
>
>> > branch on TI VAYU evm, it has issues in both high-speed and super-speed
>> > connections. It works fine with v4.17-rc1.
>> >
>> > If it suppose to work with g-webcam, please let me know if you want
>> > the details of the problems I see - the log is very long in super-speed
>> > failure.
>> 
>> Sure, give me some details of what's going on. Some bisection would be
>> great too, then I'll know which patch to blame and where to focus fixes.
>
> Roger has a copy of your previous work here:
>
> g...@github.com:rogerq/linux.git, branch balbi-dwc3-improve-isoc-endpoints
>
> I just tested it and it works fine with g_webcam.
>
> Do you think this information will help you? If so it saves me time on
> bisect ;)

What's the SHA1 on that? I can diff it locally and see if I can find
problems.

-- 
balbi
--
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