Re: [PATCH 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
On Wed, Jan 31, 2018 at 4:57 PM, Andrzej Hajda wrote:
> OF graph describes USB data lanes between USB-PHY and respective MUIC.
> Since graph is present and DWC driver can use it to get extcon, obsolete
> extcon property can be removed.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index 427ff861b441..b20b42659206 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -828,6 +828,17 @@
> };
> };
> };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + muic_to_usb: endpoint {
> + remote-endpoint =
> <&usb_to_muic>;
> + };
> + };
> };
> };
>
> @@ -1242,12 +1253,17 @@
>
> &usbdrd_dwc3 {
> dr_mode = "otg";
> - extcon = <&muic>;
Look ok for me.
Does this depend on #1 patch for DWC?
Best regards,
Krzysztof
--
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 5/5] USB: serial: f81232: fix bulk_in/out size
Hi Johan,
Johan Hovold 於 2018/1/30 下午 12:11 寫道:
On Mon, Jan 22, 2018 at 03:58:47PM +0800, Ji-Ze Hong (Peter Hong) wrote:
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index a054f69446fd..f3ee537d643c 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -769,8 +769,7 @@ static struct usb_serial_driver f81232_device = {
},
.id_table = id_table,
.num_ports =1,
- .bulk_in_size = 256,
- .bulk_out_size =256,
+ .bulk_out_size =16,
So it seems you should really be setting bulk_in_size to 64 here (and
possibly leave bulk_out_size unset) as that would appear to match your
device buffer sizes.
Yes, we want to set the bulk_in_size as 64. The public datasheet has
some error with bulk in/out, the correct size is 64.
We had test the bulk_out_size set the same with internal TX FIFO will
make the best performance in tests, but it's ok to set 64. In my opinion
, I'll prefer to set 16.
The following information is the F81232 dump by lsusb:
Bus 002 Device 007: ID 1934:0706 Feature Integration Technology Inc.
(Fintek)
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize016
idVendor 0x1934 Feature Integration Technology Inc. (Fintek)
idProduct 0x0706
bcdDevice0.01
iManufacturer 1 FINTEK
iProduct2 USB TO UART BRIDGE
iSerial 3 88635600168801
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 10
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x
(Bus Powered)
Thanks
--
With Best Regards,
Peter Hong
--
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] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Hi Alan, Thank you for your commenting. On Wed, 31 Jan 2018 11:02:47 -0500, Alan Stern wrote: >> To address above scenario, this patch introduces timer_running flag to >> ohci_hcd structure. Setting true to ohci->timer_running indicates >> io_watchdog_func() is scheduled or is running. ohci_urb_enqueue() >> checks the flag when it schedules the watchdog (step 4 and 12 above), >> so ohci->prev_frame_no is not overwritten while io_watchdog_func() is >> running. > > Instead of adding an extra flag variable, which has to be kept in sync > with the timer routine, how about defining a special sentinel value for > prev_frame_no? For example: > > #define IO_WATCHDOG_OFF 0xff00 > > Then whenever the timer isn't scheduled or running, set > ohci->prev_frame_no to IO_WATCHDOG_OFF. And instead of testing > timer_pending(), compare prev_frame_no to this special value. > > I think that approach will be slightly more robust. It's reasonable since ohci->prev_frame_no is not used while the watchdog timer is stopped. I think we must choose an invalid frame number for the special sentinel value, but I'm not sure which value is adequate for it. Is 0xff00 an invalid frame number, otherwise how about simply -1(0x)? Thanks, Shigeru-- 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
[no subject]
-- Guten Tag: Sind Sie in finanziellen Schwierigkeiten? Benötigen Sie ein Darlehen mit niedrigem Zinssatz? Wenn ja, kontaktieren Sie uns jetzt mit Ihr Name: Land: Darlehensbetrag: Telefonnummer: Darlehens Dauer: Staat: Sex: Beruf: Monatliches Einkommen: Alter: Privatadresse: -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: host: ehci: use correct device pointer for dma ops
commit a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
converted to use hcd->self.sysdev for DMA operations instead of
hcd->self.controller, but forgot to do it for hcd test mode. Replace
the correct one in this commit.
Fixes: a8c06e407ef9 ("usb: separate out sysdev pointer from usb_bus")
Signed-off-by: Peter Chen
---
drivers/usb/host/ehci-hub.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index facafdf..d7641cb 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -774,12 +774,12 @@ static struct urb *request_single_step_set_feature_urb(
atomic_inc(&urb->use_count);
atomic_inc(&urb->dev->urbnum);
urb->setup_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->setup_packet,
sizeof(struct usb_ctrlrequest),
DMA_TO_DEVICE);
urb->transfer_dma = dma_map_single(
- hcd->self.controller,
+ hcd->self.sysdev,
urb->transfer_buffer,
urb->transfer_buffer_length,
DMA_FROM_DEVICE);
--
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: [resend] Questions about "usb usb8-port1: cannot disable (err = -32)"
Hi Mathias, > From: Mathias Nyman, Sent: Wednesday, January 31, 2018 9:25 PM > > On 30.01.2018 17:54, Alan Stern wrote: > > On Tue, 30 Jan 2018, Mathias Nyman wrote: > > > >>> Question 2: > >>>- How do I resolve the issue? (I don't have any idea for now...) > >> > >> Is there any other issue than the error messags? > >> > >> we could read the portstatus in hub_port_disable() and only set the port > >> link state > >> to U3 if the port is in currently in a suitable (U0) state. > >> > >> Or then just make sure xhci_hub_control() doesn't print out any warning > >> when setting > >> link state to U3 when PORT_PE is not set, and silence hub_port_disable() > >> messages as well. > > > > I like the second idea. If xhci_hub_control() returned -ENODEV when > > asked to set the USB_PORT_FEAT_LINK_STATE feature to U3 and PORT_PE > > was clear, then hub_port_disable() wouldn't complain. > > > > Sounds like a plan, I'll submit it after rc1 > > https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=for-usb-linus&id=4b42a60487f891d03268af668 > 23a16c31c53801d Thank you very much for the patch. I tested this branch on my environment (R-Car H3) and worked correctly. So, Tested-by: Yoshihiro Shimoda Best regards, Yoshihiro Shimoda > -Mathias
Re: [PATCH 2/2] sparc,leon: Select USB_UHCI_BIG_ENDIAN_{MMIO,DESC}
From: James Hogan Date: Wed, 31 Jan 2018 22:24:46 + > Now that USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC are moved > outside of the USB_SUPPORT conditional, simply select them from > SPARC_LEON rather than by the symbol's defaults in drivers/usb/Kconfig, > similar to how it is done for USB_EHCI_BIG_ENDIAN_MMIO and > USB_EHCI_BIG_ENDIAN_DESC. > > Signed-off-by: James Hogan Acked-by: David S. Miller -- 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 3/5] USB: serial: f81232: enable remote wakeup via RX/RI pin
Hi Johan, Johan Hovold 於 2018/1/30 上午 11:57 寫道: On Mon, Jan 22, 2018 at 03:58:45PM +0800, Ji-Ze Hong (Peter Hong) wrote: The F81232 can do remote wakeup via RX/RI pin with pulse. This patch will use device_set_wakeup_enable to enable this feature. This is a policy decision that should be made by user space by setting the power/wakeup attribute, and not something that something that drivers should enable directly themselves. Perhaps you really wanted to use device_set_wakeup_capable()? But then you also need to honour the current setting in suspend() as well. How have you tested this feature? Our USB-To-Serial support RI/ RX remote wakeup by Modem, Fax or other peripherals and we had tested it by following procedure with device_set_wakeup_enable() enabled: 1. Using pm-suspend to S3 2. Trigger a pulse to RI/RX to wake up system. In our test, we can do remote wakeup only with device_set_wakeup_enable() enabled. Should we add device_set_wakeup_capable() & device_set_wakeup_enable() like following link?? https://elixir.free-electrons.com/linux/latest/source/drivers/media/rc/mceusb.c#L1476 Thanks -- With Best Regards, Peter Hong -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] usb: host: ehci: always enable interrupt for qtd completion at test mode
At former code, the SETUP stage does not enable interrupt for qtd completion, it relies on IAA watchdog to complete interrupt, then the transcation would be considered timeout if the flag need_io_watchdog is cleared by platform code. In this commit, we always add enable interrupt for qtd completion, then the qtd completion can be notified by hardware interrupt. Signed-off-by: Peter Chen --- drivers/usb/host/ehci-q.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c index 8815832..4cc2609 100644 --- a/drivers/usb/host/ehci-q.c +++ b/drivers/usb/host/ehci-q.c @@ -1192,6 +1192,8 @@ static int submit_single_step_set_feature( qtd_fill(ehci, qtd, urb->setup_dma, sizeof(struct usb_ctrlrequest), token | (2 /* "setup" */ << 8), 8); + /* Always enable interrupt on qtd completion */ + qtd->hw_token |= cpu_to_hc32(ehci, QTD_IOC); submit_async(ehci, urb, &qtd_list, GFP_ATOMIC); return 0; /*Return now; we shall come back after 15 seconds*/ @@ -1231,9 +1233,7 @@ static int submit_single_step_set_feature( /* dont fill any data in such packets */ qtd_fill(ehci, qtd, 0, 0, token, 0); - /* by default, enable interrupt on urb completion */ - if (likely(!(urb->transfer_flags & URB_NO_INTERRUPT))) - qtd->hw_token |= cpu_to_hc32(ehci, QTD_IOC); + qtd->hw_token |= cpu_to_hc32(ehci, QTD_IOC); submit_async(ehci, urb, &qtd_list, GFP_KERNEL); -- 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: host: xhci-hub: avoid xhci_warn() when PORT_PE was clear.
Hi,
> From: Mathias Nyman, Sent: Wednesday, January 31, 2018 9:29 PM
>
> On 31.01.2018 13:58, Yoshihiro Shimoda wrote:
> > The commit 37be66767e3c ("usb: hub: Fix auto-remount of safely removed
> > or ejected USB-3 devices") causes the following error when we
> > disconnected a usb 3.0 device on some environment (e.g. R-Car H3):
> >
> > xhci-hcd ee00.usb: Cannot set link state.
> > usb usb8-port1: cannot disable (err = -32)
> >
> > According to Figure 35 in xhci spec, the PED (PORT_PE) will
> > be set to 0 after the usb3 root hub enters "Error" or "Disconnected"
> > state. So, this patch avoids the error messages to return -ENODEV when
> > asked to set the USB_PORT_FEAT_LINK_STATE feature to U3 and PORT_PE
> > was clear.
> >
> > Suggested-by: Mathias Nyman
> > Suggested-by: Alan Stern
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/usb/host/xhci-hub.c | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> > index 2a90229..7e95f9e 100644
> > --- a/drivers/usb/host/xhci-hub.c
> > +++ b/drivers/usb/host/xhci-hub.c
> > @@ -1229,8 +1229,11 @@ int xhci_hub_control(struct usb_hcd *hcd, u16
> > typeReq, u16 wValue,
> > * port link state above '3' (U3) and the port
> > * must be enabled.
> > */
> > - if ((temp & PORT_PE) == 0 ||
> > - (link_state > USB_SS_PORT_LS_U3)) {
> > + if ((temp & PORT_PE) == 0) {
> > + retval = -ENODEV;
> > + break;
> > + }
> > + if (link_state > USB_SS_PORT_LS_U3) {
> > xhci_warn(xhci, "Cannot set link state.\n");
> > goto error;
> > }
> >
>
> Thanks.
> Didn't notice this before writing a similar patch.
> Anyway, I'll make sure one of them goes forward after rc1
I think your patch is better than my patch.
So, I'll test your patch later.
Best regards,
Yoshihiro Shimoda
> -Mathias
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
On Wed, Jan 31, 2018 at 04:58:58PM +0200, Mathias Nyman wrote: > On 30.01.2018 08:06, Herbert Poetzl wrote: >> On Mon, Jan 29, 2018 at 02:26:52PM +0200, Mathias Nyman wrote: >>> On 20.01.2018 06:20, Herbert Poetzl wrote: I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI Controller for running Linux. Now most things seem to work fine (some problems with UEFI but that was kind of expected), but the xhci_hcd module is filling up my log files with a repeated message (ever 4 seconds): [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 2137.036981] xhci_hcd :00:14.0: Cannot set link state. [ 2137.037767] usb usb2-port1: cannot disable (err = -32) Now I have no idea where usb2-port1 is or why it should have a bad cable, the only USB devices I know of are the USB drive I've booted the system from and the wireless keyboard/mouse combo I'm using. Both seem to work just fine and plugging those into different USB ports doesn't change the message. Bus 002 Device 002: ID 1b1c:1a00 Corsair Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Note: I have no idea what the Hitachi device is. The current kernel is 4.14.13 (from Mageia 6). Any idea what the problem here is and how I can fix or work around it? Please let me know if you need any additional information on the system or environment. >>> lsusb -v could show more details about the misbehaving device. >>> Output of dmesg could tell something as well >> During testing I found out that there is a correlation between >> the BIOS and the observed error. >> When I unplug the power supply for a few seconds, the problem >> will completely disappear until the next time I enter the BIOS >> and change something there (doesn't matter what and doesn't >> affect the result). >> It also seems to be related to the 'mystical' Hitachi device >> I couldn't figure out what it is for or why it sits on each >> USB bus. >> You can find all the suggested output here ... >> http://vserver.13thfloor.at/Stuff/XHCI_HCD/ >> where 'failing' means that the problem is present and 'working' >> means that everything seems fine. > The Hitachi device is a built-in USB3 HUB, (USB3 so it supports > both USB2 and USB3 sides) I wasn't able to find the USB ID online and the Linux USB ID database only seems to know the vendor not the device IDs ... > In the failing case the USB3 side of the hub doesn't properly > finish reset, and gets stuck in a retry loop. > It's possible that we keep retrying a warm reset even if device > would require something else to reset it properly(normal reset, > or disable device in between) Well, I'm currently testing on that platform, so it would be easy for me to try some patches for that ... Thanks for looking into it, Herbert > -Mathias -- 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] option: Add support for Quectel EP06
On Wed, 2018-01-31 at 16:32 -0600, Dan Williams wrote: > On Thu, 2018-02-01 at 09:17 +1100, Johan Hovold wrote: > > On Wed, Jan 31, 2018 at 09:56:01AM +0100, Kristian Evensen wrote: > > > Hi Johan, > > > > > > On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold > > > wrote: > > > > This will probably have to do for now, but we already have > > > > another > > > > blacklist struct with the same content which we could rename > > > > and > > > > reuse. > > > > > > I noticed the same, but wasn't quite sure about the policy on > > > renaming/recycling and added a new blacklist entry. I can rename > > > the > > > entry and update references as part of this commit. What would be > > > an > > > appropriate name, something straight-forward like > > > "net_intf4_intf5_blacklist"? > > > > Yeah, the policy isn't entirely clear to me either. ;) The > > net_blacklist > > are used to blacklist a single network interface, but here the > > other > > interface was used for ADB and for the other driver it was for an > > audio > > interface I think. > > When I added/consolidated this feature a long time back I didn't > think > we'd end up with as many common entries as we have. I think it's > fine > to re-use use a common entry, but if you do and the common entry is > named after a vendor/model, then make it generic. IIRC I considered just dumping the BIT(x) into the .driver_info but then we'd only have 16 bits for each of send_setup and reserved on 32- bit arches and I wasn't sure that was enough. I've seen some devices with lots of interfaces. But doing it this way might have been clearer than a sidecar struct like option_blacklist_info. Dan > Dan > > > You can just add the duplicate entry for now and if this comes up > > again, > > we'll figure out a new (naming) policy. > > > > Thanks, > > 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 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] option: Add support for Quectel EP06
On Thu, 2018-02-01 at 09:17 +1100, Johan Hovold wrote: > On Wed, Jan 31, 2018 at 09:56:01AM +0100, Kristian Evensen wrote: > > Hi Johan, > > > > On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold > > wrote: > > > This will probably have to do for now, but we already have > > > another > > > blacklist struct with the same content which we could rename and > > > reuse. > > > > I noticed the same, but wasn't quite sure about the policy on > > renaming/recycling and added a new blacklist entry. I can rename > > the > > entry and update references as part of this commit. What would be > > an > > appropriate name, something straight-forward like > > "net_intf4_intf5_blacklist"? > > Yeah, the policy isn't entirely clear to me either. ;) The > net_blacklist > are used to blacklist a single network interface, but here the other > interface was used for ADB and for the other driver it was for an > audio > interface I think. When I added/consolidated this feature a long time back I didn't think we'd end up with as many common entries as we have. I think it's fine to re-use use a common entry, but if you do and the common entry is named after a vendor/model, then make it generic. Dan > You can just add the duplicate entry for now and if this comes up > again, > we'll figure out a new (naming) policy. > > Thanks, > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
Move the Kconfig symbols USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC out of drivers/usb/host/Kconfig, which is conditional upon USB && USB_SUPPORT, so that it can be freely selected by platform Kconfig symbols in architecture code. For example once the MIPS_GENERIC platform selects are fixed in the patch "MIPS: Fix typo BIG_ENDIAN to CPU_BIG_ENDIAN", the MIPS 32r6_defconfig warns like so: warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_MMIO which has unmet direct dependencies (USB_SUPPORT && USB) warning: (MIPS_GENERIC) selects USB_UHCI_BIG_ENDIAN_DESC which has unmet direct dependencies (USB_SUPPORT && USB) Signed-off-by: James Hogan Cc: Greg Kroah-Hartman Cc: Corentin Labbe Cc: linux-usb@vger.kernel.org --- drivers/usb/Kconfig | 8 drivers/usb/host/Kconfig | 8 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index f699abab1787..65812a2f60b4 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -19,6 +19,14 @@ config USB_EHCI_BIG_ENDIAN_MMIO config USB_EHCI_BIG_ENDIAN_DESC bool +config USB_UHCI_BIG_ENDIAN_MMIO + bool + default y if SPARC_LEON + +config USB_UHCI_BIG_ENDIAN_DESC + bool + default y if SPARC_LEON + menuconfig USB_SUPPORT bool "USB support" depends on HAS_IOMEM diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index b80a94e632af..2763a640359f 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -625,14 +625,6 @@ config USB_UHCI_ASPEED bool default y if ARCH_ASPEED -config USB_UHCI_BIG_ENDIAN_MMIO - bool - default y if SPARC_LEON - -config USB_UHCI_BIG_ENDIAN_DESC - bool - default y if SPARC_LEON - config USB_FHCI_HCD tristate "Freescale QE USB Host Controller support" depends on OF_GPIO && QE_GPIO && QUICC_ENGINE -- git-series 0.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] usb: Move USB_UHCI_BIG_ENDIAN_* and select from SPARC_LEON
This series moves USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC
to a place where they can be easily selected from architecture code,
like USB_EHCI_BIG_ENDIAN_* are.
Patch 1 is primarily to fix MIPS generic platform warnings when this
patch ("MIPS: fix typo BIG_ENDIAN to CPU_BIG_ENDIAN") is applied:
https://patchwork.linux-mips.org/patch/18495/
It'd be awesome if this could get included in 4.16 so that the MIPS
patch can also be included without introducing warnings.
Patch 2 allows SPARC_LEON to do the same thing as MIPS_GENERIC does,
which seemed like a natural progression.
Cc: Greg Kroah-Hartman
Cc: "David S. Miller"
Cc: Corentin Labbe
Cc: linux-usb@vger.kernel.org
Cc: sparcli...@vger.kernel.org
James Hogan (2):
usb: Move USB_UHCI_BIG_ENDIAN_* out of USB_SUPPORT
sparc,leon: Select USB_UHCI_BIG_ENDIAN_{MMIO,DESC}
arch/sparc/Kconfig | 2 ++
drivers/usb/Kconfig | 6 ++
drivers/usb/host/Kconfig | 8
3 files changed, 8 insertions(+), 8 deletions(-)
base-commit: 6045f241b48f07b2fb80905bf49671f457a8c037
--
git-series 0.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] sparc,leon: Select USB_UHCI_BIG_ENDIAN_{MMIO,DESC}
Now that USB_UHCI_BIG_ENDIAN_MMIO and USB_UHCI_BIG_ENDIAN_DESC are moved outside of the USB_SUPPORT conditional, simply select them from SPARC_LEON rather than by the symbol's defaults in drivers/usb/Kconfig, similar to how it is done for USB_EHCI_BIG_ENDIAN_MMIO and USB_EHCI_BIG_ENDIAN_DESC. Signed-off-by: James Hogan Cc: "David S. Miller" Cc: Greg Kroah-Hartman Cc: Corentin Labbe Cc: sparcli...@vger.kernel.org Cc: linux-usb@vger.kernel.org --- arch/sparc/Kconfig | 2 ++ drivers/usb/Kconfig | 2 -- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig index 6bf594ace663..8767e45f1b2b 100644 --- a/arch/sparc/Kconfig +++ b/arch/sparc/Kconfig @@ -430,6 +430,8 @@ config SPARC_LEON depends on SPARC32 select USB_EHCI_BIG_ENDIAN_MMIO select USB_EHCI_BIG_ENDIAN_DESC + select USB_UHCI_BIG_ENDIAN_MMIO + select USB_UHCI_BIG_ENDIAN_DESC ---help--- If you say Y here if you are running on a SPARC-LEON processor. The LEON processor is a synthesizable VHDL model of the diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 65812a2f60b4..148f3ee70286 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -21,11 +21,9 @@ config USB_EHCI_BIG_ENDIAN_DESC config USB_UHCI_BIG_ENDIAN_MMIO bool - default y if SPARC_LEON config USB_UHCI_BIG_ENDIAN_DESC bool - default y if SPARC_LEON menuconfig USB_SUPPORT bool "USB support" -- git-series 0.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] option: Add support for Quectel EP06
On Wed, Jan 31, 2018 at 09:56:01AM +0100, Kristian Evensen wrote: > Hi Johan, > > On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold wrote: > > This will probably have to do for now, but we already have another > > blacklist struct with the same content which we could rename and > > reuse. > > I noticed the same, but wasn't quite sure about the policy on > renaming/recycling and added a new blacklist entry. I can rename the > entry and update references as part of this commit. What would be an > appropriate name, something straight-forward like > "net_intf4_intf5_blacklist"? Yeah, the policy isn't entirely clear to me either. ;) The net_blacklist are used to blacklist a single network interface, but here the other interface was used for ADB and for the other driver it was for an audio interface I think. You can just add the duplicate entry for now and if this comes up again, we'll figure out a new (naming) policy. Thanks, 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
[PATCH v4 15/15] usb: gadget: mass_storage: Set max_speed to SSP
Increase max_speed of the mass_storage driver for UDCs that support
SuperSpeed Plus. The composite driver will pass this value to UDC core
to set the device speed on probe (actual speed may be different
depending on whether the USB controller supports it or other external
factors).
Signed-off-by: Thinh Nguyen
---
drivers/usb/gadget/legacy/mass_storage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/legacy/mass_storage.c
b/drivers/usb/gadget/legacy/mass_storage.c
index ef3d25259b0e..fd5595ac5bf7 100644
--- a/drivers/usb/gadget/legacy/mass_storage.c
+++ b/drivers/usb/gadget/legacy/mass_storage.c
@@ -225,7 +225,7 @@ static int msg_unbind(struct usb_composite_dev *cdev)
static struct usb_composite_driver msg_driver = {
.name = "g_mass_storage",
.dev= &msg_device_desc,
- .max_speed = USB_SPEED_SUPER,
+ .max_speed = USB_SPEED_SUPER_PLUS,
.needs_serial = 1,
.strings= dev_strings,
.bind = msg_bind,
--
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 v4 13/15] usb: dwc3: Add workaround for isoc start transfer failure
In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed
isochronous IN, BIT[15:14] of the 16-bit microframe number reported by
the XferNotReady event are invalid. The driver uses this number to
schedule the isochronous transfer and passes it to the START TRANSFER
command. Because this number is invalid, the command may fail. If
BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER
command will pass and the transfer will start at the scheduled time, if
it is off by 1, the command will still pass, but the transfer will start
2 seconds in the future. All other conditions the START TRANSFER command
will fail with bus-expiry.
In order to workaround this issue, we can issue multiple START TRANSFER
commands with different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11
and do an END TRANSFER command. Each combination is 2 seconds apart. 4
seconds into the future will cause a bus-expiry failure. As the result,
within the 4 possible combinations for BIT[15:14], there will be 2
successful and 2 failure START COMMAND status. One of the 2 successful
command status will result in a 2-second delay. The smaller BIT[15:14]
value is the correct one.
Since there are only 4 outcomes and the results are ordered, we can
simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00
and 'b01 to deduce the smallest successful combination.
+-+-+
| BIT(15) | BIT(14) |
+=+=+
test0 | 0 |0|
+-+-+
test1 | 0 |1|
+-+-+
With test0 and test1 BIT[15:14] combinations, here is the logic:
if test0 passes and test1 passes, BIT[15:14] is 'b00
if test0 passes and test1 fails, BIT[15:14] is 'b11
if test0 fails and test1 fails, BIT[15:14] is 'b10
if test0 fails and test1 passes, BIT[15:14] is 'b01
Synopsys STAR 9001202023: Wrong microframe number for isochronous IN
endpoints.
Signed-off-by: Thinh Nguyen
---
drivers/usb/dwc3/core.c | 2 +
drivers/usb/dwc3/core.h | 13
drivers/usb/dwc3/gadget.c | 189 --
3 files changed, 199 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index ddcfa2a60d4b..d27ddfcc3b8a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1073,6 +1073,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
"snps,is-utmi-l1-suspend");
device_property_read_u8(dev, "snps,hird-threshold",
&hird_threshold);
+ dwc->dis_start_transfer_quirk = device_property_read_bool(dev,
+ "snps,dis-start-transfer-quirk");
dwc->usb3_lpm_capable = device_property_read_bool(dev,
"snps,usb3_lpm_capable");
device_property_read_u8(dev, "snps,rx-thr-num-pkt-prd",
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 71cf53a06e49..c09cd0c6354e 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -555,6 +555,10 @@ struct dwc3_event_buffer {
* @name: a human readable name e.g. ep1out-bulk
* @direction: true for TX, false for RX
* @stream_capable: true when streams are enabled
+ * @frame_number_15_14: BIT[15:14] of the frame number to test isochronous
+ * START TRANSFER command failure workaround
+ * @test0_status: the result of testing START TRANSFER command with
+ * frame_number_15_14 = 'b00 (non-zero means failure)
*/
struct dwc3_ep {
struct usb_ep endpoint;
@@ -608,6 +612,10 @@ struct dwc3_ep {
unsigneddirection:1;
unsignedstream_capable:1;
+
+ /* Isochronous START TRANSFER workaround for STAR 9001202023 */
+ u8 frame_number_15_14;
+ int test0_status;
};
enum dwc3_phy {
@@ -862,6 +870,8 @@ struct dwc3_scratchpad_array {
* @pullups_connected: true when Run/Stop bit is set
* @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
* @three_stage_setup: set if we perform a three phase setup
+ * @dis_start_transfer_quirk: set if start_transfer failure SW workaround is
+ * not needed for DWC_usb31 version 1.70a-ea06 and below
* @usb3_lpm_capable: set if hadrware supports Link Power Management
* @disable_scramble_quirk: set if we enable the disable scramble quirk
* @u2exit_lfps_quirk: set if we enable u2exit lfps quirk
@@ -982,10 +992,12 @@ struct dwc3 {
#define DWC3_REVISION_IS_DWC31 0x8000
#define DWC3_USB31_REVISION_110A (0x3131302a | DWC3_REVISION_IS_DWC31)
#define DWC3_USB31_REVISION_120A (0x3132302a | DWC3_REVISION_IS_DWC31)
+#define DWC3_USB31_REVISION_170A (0x3137302a | DWC3_REVISION_IS_DWC31)
u32 ver_type;
#define DWC31_VERSIONTYPE_EA01 0x65613031
+#define DWC31_
[PATCH v4 14/15] usb: dwc3: Check controller type before setting speed
DWC_usb3 speed can only be set up to SuperSpeed. Limit the setting to SuperSpeed only should the value be higher. Otherwise, the controller will read an invalid speed value and set the device to an incorrect speed. Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index f873ebb40ea8..1d31554101ad 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2203,7 +2203,10 @@ static void dwc3_gadget_set_speed(struct usb_gadget *g, reg |= DWC3_DCFG_SUPERSPEED; break; case USB_SPEED_SUPER_PLUS: - reg |= DWC3_DCFG_SUPERSPEED_PLUS; + if (dwc3_is_usb31(dwc)) + reg |= DWC3_DCFG_SUPERSPEED_PLUS; + else + reg |= DWC3_DCFG_SUPERSPEED; break; default: dev_err(dwc->dev, "invalid speed (%d)\n", speed); -- 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 v4 11/15] usb: dwc3: Track DWC_usb31 VERSIONTYPE
Add a new field to dwc3 structure to track VERSIONTYPE. The VERSIONTYPE
is represented in ASCII in the 32-bit VERSIONTYPE register. In
DWC_usb31, sub releases for each version are tracked with VERSIONTYPE
such as "ea01" and "ea02".
Signed-off-by: Thinh Nguyen
---
drivers/usb/dwc3/core.c | 2 ++
drivers/usb/dwc3/core.h | 5 +
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 92f9fe7312c3..ddcfa2a60d4b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -642,6 +642,7 @@ static bool dwc3_core_is_valid(struct dwc3 *dwc)
{
u32 reg;
+ dwc->ver_type = 0;
reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
/* This should read as U3 followed by revision number */
@@ -652,6 +653,7 @@ static bool dwc3_core_is_valid(struct dwc3 *dwc)
/* Detected DWC_usb31 IP */
dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
dwc->revision |= DWC3_REVISION_IS_DWC31;
+ dwc->ver_type = dwc3_readl(dwc->regs, DWC3_VER_TYPE);
} else {
return false;
}
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index fd794972802d..71cf53a06e49 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -810,6 +810,7 @@ struct dwc3_scratchpad_array {
* @u1u2: only used on revisions <1.83a for workaround
* @maximum_speed: maximum speed requested (mainly for testing purposes)
* @revision: revision register contents
+ * @ver_type: VERSIONTYPE register contents, a sub release of a revision
* @dr_mode: requested mode of operation
* @current_dr_role: current role of operation when in dual-role mode
* @desired_dr_role: desired role of operation when in dual-role mode
@@ -982,6 +983,10 @@ struct dwc3 {
#define DWC3_USB31_REVISION_110A (0x3131302a | DWC3_REVISION_IS_DWC31)
#define DWC3_USB31_REVISION_120A (0x3132302a | DWC3_REVISION_IS_DWC31)
+ u32 ver_type;
+
+#define DWC31_VERSIONTYPE_EA01 0x65613031
+
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
enum dwc3_link_statelink_state;
--
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 v4 12/15] usb: dwc3: Add disabling of start_transfer failure quirk
In DWC_usb31 version 1.70a-ea06 and prior needs a SW workaround for isoc START TRANSFER command failure. However, some affected versions may have RTL patches to fix this without a SW workaround. Add this quirk to disable the SW workaround when it is not needed. Synopsys STAR 9001202023: Wrong microframe number for isochronous IN endpoints. Cc: John Youn Signed-off-by: Thinh Nguyen --- Documentation/devicetree/bindings/usb/dwc3.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index e2c1edcd83dd..98b4da23c595 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -15,6 +15,9 @@ Optional properties: - phys: from the *Generic PHY* bindings - phy-names: from the *Generic PHY* bindings; supported names are "usb2-phy" or "usb3-phy". + - snps,dis-start-transfer-quirk: when set, disable isoc START TRANSFER command + failure SW work-around for DWC_usb31 version 1.70a-ea06 + and prior. - snps,usb3_lpm_capable: determines if platform is USB3 LPM capable - snps,disable_scramble_quirk: true when SW should disable data scrambling. Only really useful for FPGA builds. -- 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 v4 10/15] usb: dwc3: Dump LSP and BMU debug info
Dump LSP and BMU debug info.
Signed-off-by: Thinh Nguyen
---
drivers/usb/dwc3/core.h| 5 +
drivers/usb/dwc3/debugfs.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index e53ae6038bbe..fd794972802d 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -100,6 +100,11 @@
#define DWC3_GHWPARAMS70xc15c
#define DWC3_GDBGFIFOSPACE 0xc160
#define DWC3_GDBGLTSSM 0xc164
+#define DWC3_GDBGBMU 0xc16c
+#define DWC3_GDBGLSPMUX0xc170
+#define DWC3_GDBGLSP 0xc174
+#define DWC3_GDBGEPINFO0 0xc178
+#define DWC3_GDBGEPINFO1 0xc17c
#define DWC3_GPRTBIMAP_HS0 0xc180
#define DWC3_GPRTBIMAP_HS1 0xc184
#define DWC3_GPRTBIMAP_FS0 0xc188
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 00e65530c81e..f09072395afe 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -81,6 +81,11 @@ static const struct debugfs_reg32 dwc3_regs[] = {
dump_register(GHWPARAMS7),
dump_register(GDBGFIFOSPACE),
dump_register(GDBGLTSSM),
+ dump_register(GDBGBMU),
+ dump_register(GDBGLSPMUX),
+ dump_register(GDBGLSP),
+ dump_register(GDBGEPINFO0),
+ dump_register(GDBGEPINFO1),
dump_register(GPRTBIMAP_HS0),
dump_register(GPRTBIMAP_HS1),
dump_register(GPRTBIMAP_FS0),
--
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 v4 09/15] usb: dwc3: Check for ESS TX/RX threshold config
Check and configure TX/RX threshold for DWC_usb31. Update dwc3 structure
with new fields to store these threshold configurations.
Signed-off-by: Thinh Nguyen
---
drivers/usb/dwc3/core.c | 55 +
drivers/usb/dwc3/core.h | 8 +++
2 files changed, 63 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 87043dd15b20..92f9fe7312c3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -830,6 +830,43 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}
+ /*
+* Must config both number of packets and max burst settings to enable
+* RX and/or TX threshold.
+*/
+ if (dwc3_is_usb31(dwc) && dwc->dr_mode == USB_DR_MODE_HOST) {
+ u8 rx_thr_num = dwc->rx_thr_num_pkt_prd;
+ u8 rx_maxburst = dwc->rx_max_burst_prd;
+ u8 tx_thr_num = dwc->tx_thr_num_pkt_prd;
+ u8 tx_maxburst = dwc->tx_max_burst_prd;
+
+ if (rx_thr_num && rx_maxburst) {
+ reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG);
+ reg |= DWC31_RXTHRNUMPKTSEL_PRD;
+
+ reg &= ~DWC31_RXTHRNUMPKT_PRD(~0);
+ reg |= DWC31_RXTHRNUMPKT_PRD(rx_thr_num);
+
+ reg &= ~DWC31_MAXRXBURSTSIZE_PRD(~0);
+ reg |= DWC31_MAXRXBURSTSIZE_PRD(rx_maxburst);
+
+ dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg);
+ }
+
+ if (tx_thr_num && tx_maxburst) {
+ reg = dwc3_readl(dwc->regs, DWC3_GTXTHRCFG);
+ reg |= DWC31_TXTHRNUMPKTSEL_PRD;
+
+ reg &= ~DWC31_TXTHRNUMPKT_PRD(~0);
+ reg |= DWC31_TXTHRNUMPKT_PRD(tx_thr_num);
+
+ reg &= ~DWC31_MAXTXBURSTSIZE_PRD(~0);
+ reg |= DWC31_MAXTXBURSTSIZE_PRD(tx_maxburst);
+
+ dwc3_writel(dwc->regs, DWC3_GTXTHRCFG, reg);
+ }
+ }
+
return 0;
err4:
@@ -998,6 +1035,10 @@ static void dwc3_get_properties(struct dwc3 *dwc)
u8 lpm_nyet_threshold;
u8 tx_de_emphasis;
u8 hird_threshold;
+ u8 rx_thr_num_pkt_prd;
+ u8 rx_max_burst_prd;
+ u8 tx_thr_num_pkt_prd;
+ u8 tx_max_burst_prd;
/* default to highest possible threshold */
lpm_nyet_threshold = 0xff;
@@ -1032,6 +1073,14 @@ static void dwc3_get_properties(struct dwc3 *dwc)
&hird_threshold);
dwc->usb3_lpm_capable = device_property_read_bool(dev,
"snps,usb3_lpm_capable");
+ device_property_read_u8(dev, "snps,rx-thr-num-pkt-prd",
+ &rx_thr_num_pkt_prd);
+ device_property_read_u8(dev, "snps,rx-max-burst-prd",
+ &rx_max_burst_prd);
+ device_property_read_u8(dev, "snps,tx-thr-num-pkt-prd",
+ &tx_thr_num_pkt_prd);
+ device_property_read_u8(dev, "snps,tx-max-burst-prd",
+ &tx_max_burst_prd);
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
@@ -1079,6 +1128,12 @@ static void dwc3_get_properties(struct dwc3 *dwc)
dwc->hird_threshold = hird_threshold
| (dwc->is_utmi_l1_suspend << 4);
+ dwc->rx_thr_num_pkt_prd = rx_thr_num_pkt_prd;
+ dwc->rx_max_burst_prd = rx_max_burst_prd;
+
+ dwc->tx_thr_num_pkt_prd = tx_thr_num_pkt_prd;
+ dwc->tx_max_burst_prd = tx_max_burst_prd;
+
dwc->imod_interval = 0;
}
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 7d15d92f622a..e53ae6038bbe 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -835,6 +835,10 @@ struct dwc3_scratchpad_array {
* @test_mode_nr: test feature selector
* @lpm_nyet_threshold: LPM NYET response threshold
* @hird_threshold: HIRD threshold
+ * @rx_thr_num_pkt_prd: periodic ESS receive packet count
+ * @rx_max_burst_prd: max periodic ESS receive burst size
+ * @tx_thr_num_pkt_prd: periodic ESS transmit packet count
+ * @tx_max_burst_prd: max periodic ESS transmit burst size
* @hsphy_interface: "utmi" or "ulpi"
* @connected: true when we're connected to a host, false otherwise
* @delayed_status: true when gadget driver asks for delayed status
@@ -995,6 +999,10 @@ struct dwc3 {
u8 test_mode_nr;
u8 lpm_nyet_threshold;
u8 hird_threshold;
+ u8 rx_thr_num_pkt_prd;
+ u8 rx_max_burst_prd;
+ u8 tx_thr_
[PATCH v4 08/15] usb: dwc3: Make TX/RX threshold configurable
DWC_usb31 periodic transfer at 48K+ bytes per interval may need modification to the TX/RX packet threshold to achieve optimal result. Add properties to make it configurable. By default, periodic ESS TX and RX threshold are not enabled. To enable TX or RX threshold (host mode only), both packet threshold count and max burst size properties must be set to a valid non-zero value 1-16. DWC_usb31 programming guide section 1.2.3 and 1.2.4. Cc: John Youn Signed-off-by: Thinh Nguyen --- Documentation/devicetree/bindings/usb/dwc3.txt | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 52fb41046b34..e2c1edcd83dd 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -55,6 +55,22 @@ Optional properties: - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ register for post-silicon frame length adjustment when the fladj_30mhz_sdbnd signal is invalid or incorrect. + - snps,rx-thr-num-pkt-prd: periodic ESS RX packet threshold count - host mode + only. Set this and rx-max-burst-prd to a valid, + non-zero value 1-16 (DWC_usb31 programming guide + section 1.2.4) to enable periodic ESS RX threshold. + - snps,rx-max-burst-prd: max periodic ESS RX burst size - host mode only. Set + this and rx-thr-num-pkt-prd to a valid, non-zero value + 1-16 (DWC_usb31 programming guide section 1.2.4) to + enable periodic ESS RX threshold. + - snps,tx-thr-num-pkt-prd: periodic ESS TX packet threshold count - host mode + only. Set this and tx-max-burst-prd to a valid, + non-zero value 1-16 (DWC_usb31 programming guide + section 1.2.3) to enable periodic ESS TX threshold. + - snps,tx-max-burst-prd: max periodic ESS TX burst size - host mode only. Set + this and tx-thr-num-pkt-prd to a valid, non-zero value + 1-16 (DWC_usb31 programming guide section 1.2.3) to + enable periodic ESS TX threshold. - tx-fifo-resize: determines if the FIFO *has* to be reallocated. -- 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 v4 05/15] usb: dwc3: Add DWC_usb31 GRXTHRCFG bit fields
Add new GRXTHRCFG bit field macros for DWC_usb31. The GRXTHRCFG register fields for DWC_usb31 is as follows: +---+--+--+ | BITS | Name | Description | +===+==+==+ | 31:27 | reserved | | | 26| UsbRxPktCntSel | Async ESS receive packet | | | | threshold enable | | 25:21 | UsbRxPktCnt | Async ESS receive packet | | | | threshold count | | 20:16 | UsbMaxRxBurstSize| Async ESS Max receive burst size | | 15| UsbRxThrNumPktSel_HS_Prd | HS high bandwidth periodic | | | | receive packet threshold enable | | 14:13 | UsbRxThrNumPkt_HS_Prd| HS high bandwidth periodic | | | | receive packet threshold count | | 12:11 | reserved | | | 10| UsbRxThrNumPktSel_Prd| Periodic ESS receive packet | | | | threshold enable | | 9:5 | UsbRxThrNumPkt_Prd | Periodic ESS receive packet | | | | threshold count | | 4:0 | UsbMaxRxBurstSize_Prd| Max periodic ESS RX burst size | +---+--+--+ Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/core.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 70666d336e86..61c2b78d5809 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -171,6 +171,16 @@ #define DWC3_GRXTHRCFG_RXPKTCNT(n) (((n) & 0xf) << 24) #define DWC3_GRXTHRCFG_PKTCNTSEL BIT(29) +/* Global RX Threshold Configuration Register for DWC_usb31 only */ +#define DWC31_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 16) +#define DWC31_GRXTHRCFG_RXPKTCNT(n)(((n) & 0x1f) << 21) +#define DWC31_GRXTHRCFG_PKTCNTSEL BIT(26) +#define DWC31_RXTHRNUMPKTSEL_HS_PRDBIT(15) +#define DWC31_RXTHRNUMPKT_HS_PRD(n)(((n) & 0x3) << 13) +#define DWC31_RXTHRNUMPKTSEL_PRD BIT(10) +#define DWC31_RXTHRNUMPKT_PRD(n) (((n) & 0x1f) << 5) +#define DWC31_MAXRXBURSTSIZE_PRD(n)((n) & 0x1f) + /* Global Configuration Register */ #define DWC3_GCTL_PWRDNSCALE(n)((n) << 19) #define DWC3_GCTL_U2RSTECN BIT(16) -- 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 v4 06/15] usb: dwc3: gadget: Check IP revision for GRXTHRCFG
DWC_usb31 controller has a different UsbRxPktCnt bit fields from GRXTHRCFG register. Check for DWC_usb31 IP revision to read the appropriate value. Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/gadget.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 0bbc21ab6912..24cbd79481e8 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1858,7 +1858,11 @@ static int __dwc3_gadget_start(struct dwc3 *dwc) * bursts of data without going through any sort of endpoint throttling. */ reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG); - reg &= ~DWC3_GRXTHRCFG_PKTCNTSEL; + if (dwc3_is_usb31(dwc)) + reg &= ~DWC31_GRXTHRCFG_PKTCNTSEL; + else + reg &= ~DWC3_GRXTHRCFG_PKTCNTSEL; + dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg); dwc3_gadget_setup_nump(dwc); -- 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 v4 07/15] usb: dwc3: Add DWC_usb31 GTXTHRCFG reg fields
Add new GTXTHRCFG bit field macros for DWC_usb31. The GTXTHRCFG register fields for DWC_usb31 is as follows: +---+--+---+ | BITS | Name | Description | +===+==+===+ | 31:27 | reserved | | | 26| UsbTxPktCntSel | Async ESS transmit packet | | | | threshold enable | | 25:21 | UsbTxPktCnt | Async ESS transmit packet | | | | threshold count | | 20:16 | UsbMaxTxBurstSize| Async ESS Max transmit burst size | | 15| UsbTxThrNumPktSel_HS_Prd | HS high bandwidth periodic| | | | transmit packet threshold enable | | 14:13 | UsbTxThrNumPkt_HS_Prd| HS high bandwidth periodic| | | | transmit packet threshold count | | 12:11 | reserved | | | 10| UsbTxThrNumPktSel_Prd| Periodic ESS transmit packet | | | | threshold enable | | 9:5 | UsbTxThrNumPkt_Prd | Periodic ESS transmit packet | | | | threshold count | | 4:0 | UsbMaxTxBurstSize_Prd| Max periodic ESS TX burst size| +---+--+---+ Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/core.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 61c2b78d5809..7d15d92f622a 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -181,6 +181,16 @@ #define DWC31_RXTHRNUMPKT_PRD(n) (((n) & 0x1f) << 5) #define DWC31_MAXRXBURSTSIZE_PRD(n)((n) & 0x1f) +/* Global TX Threshold Configuration Register for DWC_usb31 only */ +#define DWC31_GTXTHRCFG_MAXTXBURSTSIZE(n) (((n) & 0x1f) << 16) +#define DWC31_GTXTHRCFG_TXPKTCNT(n)(((n) & 0x1f) << 21) +#define DWC31_GTXTHRCFG_PKTCNTSEL BIT(26) +#define DWC31_TXTHRNUMPKTSEL_HS_PRDBIT(15) +#define DWC31_TXTHRNUMPKT_HS_PRD(n)(((n) & 0x3) << 13) +#define DWC31_TXTHRNUMPKTSEL_PRD BIT(10) +#define DWC31_TXTHRNUMPKT_PRD(n) (((n) & 0x1f) << 5) +#define DWC31_MAXTXBURSTSIZE_PRD(n)((n) & 0x1f) + /* Global Configuration Register */ #define DWC3_GCTL_PWRDNSCALE(n)((n) << 19) #define DWC3_GCTL_U2RSTECN BIT(16) -- 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 v4 04/15] usb: dwc3: Check IP revision for GTXFIFOSIZ
DWC_usb31 controller has different GTXFIFOSIZE bit field for TXFDEF. Check for DWC_usb31 IP revision to read the appropriate bit fields. Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 639dd1b163a0..0bbc21ab6912 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -2100,7 +2100,10 @@ static int dwc3_gadget_init_endpoints(struct dwc3 *dwc, u8 total) mdwidth /= 8; size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(num)); - size = DWC3_GTXFIFOSIZ_TXFDEF(size); + if (dwc3_is_usb31(dwc)) + size = DWC31_GTXFIFOSIZ_TXFDEF(size); + else + size = DWC3_GTXFIFOSIZ_TXFDEF(size); /* FIFO Depth is in MDWDITH bytes. Multiply */ size *= mdwidth; -- 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 v4 03/15] usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields
Update two GTXFIFOSIZ bit fields for the DWC_usb31 controller. TXFDEP is a 15-bit value instead of 16-bit value, and bit 15 is TXFRAMNUM. The GTXFIFOSIZ register for DWC_usb31 is as follows: +---+---+--+ | BITS | Name | Description | +===+===+==+ | 31:16 | TXFSTADDR | Transmit FIFOn RAM Start Address | | 15| TXFRAMNUM | Asynchronous/Periodic TXFIFO | | 14:0 | TXFDEP| TXFIFO Depth | +---+---+--+ Signed-off-by: Thinh Nguyen --- drivers/usb/dwc3/core.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h index 4a4a4c98508c..70666d336e86 100644 --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -239,6 +239,8 @@ #define DWC3_GUSB3PIPECTL_TX_DEEPH(n) ((n) << 1) /* Global TX Fifo Size Register */ +#define DWC31_GTXFIFOSIZ_TXFRAMNUM BIT(15) /* DWC_usb31 only */ +#define DWC31_GTXFIFOSIZ_TXFDEF(n) ((n) & 0x7fff) /* DWC_usb31 only */ #define DWC3_GTXFIFOSIZ_TXFDEF(n) ((n) & 0x) #define DWC3_GTXFIFOSIZ_TXFSTADDR(n) ((n) & 0x) -- 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 v4 02/15] usb: core: urb: Check SSP isoc ep comp descriptor
The maximum bytes per interval for USB SuperSpeed Plus can be set by
isoc endpoint companion descriptor when it is above 48K. If the
descriptor is provided, then use its value.
USB 3.1 spec 9.6.8
Signed-off-by: Thinh Nguyen
---
drivers/usb/core/urb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 9fdf137c4865..0ab4b896e3f3 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -433,6 +433,14 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
max *= mult;
}
+ if (dev->speed == USB_SPEED_SUPER_PLUS &&
+ USB_SS_SSP_ISOC_COMP(ep->ss_ep_comp.bmAttributes)) {
+ struct usb_ssp_isoc_ep_comp_descriptor *isoc_ep_comp;
+
+ isoc_ep_comp = &ep->ssp_isoc_ep_comp;
+ max = le32_to_cpu(isoc_ep_comp->dwBytesPerInterval);
+ }
+
/* "high bandwidth" mode, 1-3 packets/uframe? */
if (dev->speed == USB_SPEED_HIGH)
max *= usb_endpoint_maxp_mult(&ep->desc);
--
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 v4 00/15] usb: dwc3: Add new updates for DWC_usb31
This patch series adds new updates and some fixes for DWC_usb31. Changes in v4: - Correctly refer "databook" as "programming guide" - Document more detail about enabling of ESS periodic tx/rx threshold Changes in v3: - Add "usb: dwc3: Check controller type before setting speed" to series Changes in v2: - Add another patch to the series to increase mass_storage max_speed - Separate "usb: dwc3: ep0: Reset TRB counter for ep0 IN" from series - Separate "usb: dwc3: gadget: Set maxpacket size for ep0 IN" from series - Use msleep() instead of mdelay() for SoftReset PHY sync delay - Rename new USB31 macros from DWC3_USB31_* to DWC31_* - Rename device properties and replace '_' with '-' - Minor fixes in the commit messages Thinh Nguyen (15): usb: dwc3: Add SoftReset PHY synchonization delay usb: core: urb: Check SSP isoc ep comp descriptor usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields usb: dwc3: Check IP revision for GTXFIFOSIZ usb: dwc3: Add DWC_usb31 GRXTHRCFG bit fields usb: dwc3: gadget: Check IP revision for GRXTHRCFG usb: dwc3: Add DWC_usb31 GTXTHRCFG reg fields usb: dwc3: Make TX/RX threshold configurable usb: dwc3: Check for ESS TX/RX threshold config usb: dwc3: Dump LSP and BMU debug info usb: dwc3: Track DWC_usb31 VERSIONTYPE usb: dwc3: Add disabling of start_transfer failure quirk usb: dwc3: Add workaround for isoc start transfer failure usb: dwc3: Check controller type before setting speed usb: gadget: mass_storage: Set max_speed to SSP Documentation/devicetree/bindings/usb/dwc3.txt | 19 +++ drivers/usb/core/urb.c | 8 + drivers/usb/dwc3/core.c| 72 - drivers/usb/dwc3/core.h| 53 +++ drivers/usb/dwc3/debugfs.c | 5 + drivers/usb/dwc3/gadget.c | 205 - drivers/usb/gadget/legacy/mass_storage.c | 2 +- 7 files changed, 354 insertions(+), 10 deletions(-) -- 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 v4 01/15] usb: dwc3: Add SoftReset PHY synchonization delay
>From DWC_usb31 programming guide section 1.3.2, once DWC3_DCTL_CSFTRST
bit is cleared, we must wait at least 50ms before accessing the PHY
domain (synchronization delay).
Signed-off-by: Thinh Nguyen
---
drivers/usb/dwc3/core.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 07832509584f..87043dd15b20 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -228,12 +228,23 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
do {
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
if (!(reg & DWC3_DCTL_CSFTRST))
- return 0;
+ goto done;
udelay(1);
} while (--retries);
return -ETIMEDOUT;
+
+done:
+ /*
+* For DWC_usb31 controller, once DWC3_DCTL_CSFTRST bit is cleared,
+* we must wait at least 50ms before accessing the PHY domain
+* (synchronization delay). DWC_usb31 programming guide section 1.3.2.
+*/
+ if (dwc3_is_usb31(dwc))
+ msleep(50);
+
+ return 0;
}
/*
--
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] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
On Wed, 31 Jan 2018, Haiqing Bai wrote: > Running io_watchdog_func() while ohci_urb_enqueue() is running can > cause a race condition where ohci->prev_frame_no is corrupted and the > watchdog can mis-detect following error: > > ohci-platform 664a0800.usb: frame counter not updating; disabled > ohci-platform 664a0800.usb: HC died; cleaning up > > Specifically, following scenario causes a race condition: > > 1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) > and enters the critical section > 2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it > returns false > 3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number > read by ohci_frame_no(ohci) > 4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer() > 5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, > flags) and exits the critical section > 6. Later, ohci_urb_enqueue() is called > 7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags) > and enters the critical section > 8. The timer scheduled on step 4 expires and io_watchdog_func() runs > 9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags) > and waits on it because ohci_urb_enqueue() is already in the > critical section on step 7 > 10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it > returns false > 11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number > read by ohci_frame_no(ohci) because the frame number proceeded > between step 3 and 6 > 12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer() > 13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock, > flags) and exits the critical section, then wake up > io_watchdog_func() which is waiting on step 9 > 14. io_watchdog_func() enters the critical section > 15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no > variable to the frame number > 16. io_watchdog_func() compares frame_no and ohci->prev_frame_no > > On step 16, because this calling of io_watchdog_func() is scheduled on > step 4, the frame number set in ohci->prev_frame_no is expected to the > number set on step 3. However, ohci->prev_frame_no is overwritten on > step 11. Because step 16 is executed soon after step 11, the frame > number might not proceed, so ohci->prev_frame_no must equals to > frame_no. That is a nasty bug! > To address above scenario, this patch introduces timer_running flag to > ohci_hcd structure. Setting true to ohci->timer_running indicates > io_watchdog_func() is scheduled or is running. ohci_urb_enqueue() > checks the flag when it schedules the watchdog (step 4 and 12 above), > so ohci->prev_frame_no is not overwritten while io_watchdog_func() is > running. Instead of adding an extra flag variable, which has to be kept in sync with the timer routine, how about defining a special sentinel value for prev_frame_no? For example: #define IO_WATCHDOG_OFF 0xff00 Then whenever the timer isn't scheduled or running, set ohci->prev_frame_no to IO_WATCHDOG_OFF. And instead of testing timer_pending(), compare prev_frame_no to this special value. I think that approach will be slightly more robust. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] USB: dwc3: get extcon device by OF graph bindings
Hi, This small patchset tries to address issue with broken DT extcon property in case of USB controller - DWC3. It exposes similar problem as in proposed USB connector bindings[1] - extcon device is required by devices not always connected directly to extcon device. Here we have: DWC3 -> USB-PHY -> MUIC -> USB-connector ^ MHL-bridge-^ More details and proposition of generic solution in first patch [1]: https://marc.info/?i=20180131134435.12216-1-a.hajda%40samsung.com Regards Andrzej Andrzej Hajda (2): USB: dwc3: get extcon device by OF graph bindings arm64: dts: exynos: add OF graph between USB-PHY and MUIC .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 +- drivers/usb/dwc3/drd.c | 41 +++--- 2 files changed, 45 insertions(+), 14 deletions(-) -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] USB: dwc3: get extcon device by OF graph bindings
extcon device is used to detect host/device connection. Since extcon
OF property is deprecated, alternative method should be added.
This method uses OF graph bindings to locate extcon.
Signed-off-by: Andrzej Hajda
---
Hi all,
This patch implements alternative method to get extcon from DWC3.
The code works but is hacky, as DWC3 must traverse different DT nodes
to get extcon, in case of TM2 it is USB-PHY and MUIC, but other
platforms can have different paths.
I would be glad if it can be merged as is for now, but additional work
must be done to make it generic.
I guess on DT binding side it is OK. So the problem should be addressed
in the code.
My rough idea is to implement kind of extcon aliases/forwarder mechanism,
ie. USB-PHY will expect on its output remote port extcon, and it should register
extcon-forwarder pointing to this extcon. This way DWC3 can look for the extcon
on its PHY phandle, and it will receive via forwarding mechanism extcon
exposed by MUIC.
As I said this is rough idea for discussion, other propositions are welcome.
Regards
Andrzej
---
drivers/usb/dwc3/drd.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
index cc8ab9a8e9d2..eee2eca3d513 100644
--- a/drivers/usb/dwc3/drd.c
+++ b/drivers/usb/dwc3/drd.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include "debug.h"
#include "core.h"
@@ -38,24 +39,38 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
return NOTIFY_DONE;
}
+struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
+{
+ struct device *dev = dwc->dev;
+ struct device_node *np_phy, *np_conn;
+ struct extcon_dev *edev;
+
+ if (of_property_read_bool(dev->of_node, "extcon"))
+ return extcon_get_edev_by_phandle(dwc->dev, 0);
+
+ np_phy = of_parse_phandle(dev->of_node, "phys", 0);
+ np_conn = of_graph_get_remote_node(np_phy, -1, -1);
+ edev = extcon_get_edev_by_of_node(np_conn);
+ of_node_put(np_conn);
+ of_node_put(np_phy);
+
+ return edev;
+}
+
int dwc3_drd_init(struct dwc3 *dwc)
{
int ret;
- if (dwc->dev->of_node) {
- if (of_property_read_bool(dwc->dev->of_node, "extcon"))
- dwc->edev = extcon_get_edev_by_phandle(dwc->dev, 0);
-
- if (IS_ERR(dwc->edev))
- return PTR_ERR(dwc->edev);
+ dwc->edev = dwc3_get_extcon(dwc);
+ if (IS_ERR(dwc->edev))
+ return PTR_ERR(dwc->edev);
- dwc->edev_nb.notifier_call = dwc3_drd_notifier;
- ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
- &dwc->edev_nb);
- if (ret < 0) {
- dev_err(dwc->dev, "couldn't register cable notifier\n");
- return ret;
- }
+ dwc->edev_nb.notifier_call = dwc3_drd_notifier;
+ ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
+ &dwc->edev_nb);
+ if (ret < 0) {
+ dev_err(dwc->dev, "couldn't register cable notifier\n");
+ return ret;
}
dwc3_drd_update(dwc);
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm64: dts: exynos: add OF graph between USB-PHY and MUIC
OF graph describes USB data lanes between USB-PHY and respective MUIC.
Since graph is present and DWC driver can use it to get extcon, obsolete
extcon property can be removed.
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 427ff861b441..b20b42659206 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -828,6 +828,17 @@
};
};
};
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ muic_to_usb: endpoint {
+ remote-endpoint =
<&usb_to_muic>;
+ };
+ };
};
};
@@ -1242,12 +1253,17 @@
&usbdrd_dwc3 {
dr_mode = "otg";
- extcon = <&muic>;
};
&usbdrd30_phy {
vbus-supply = <&safeout1_reg>;
status = "okay";
+
+ port {
+ usb_to_muic: endpoint {
+ remote-endpoint = <&muic_to_usb>;
+ };
+ };
};
&xxti {
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK
On 30.01.2018 08:06, Herbert Poetzl wrote: On Mon, Jan 29, 2018 at 02:26:52PM +0200, Mathias Nyman wrote: On 20.01.2018 06:20, Herbert Poetzl wrote: I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI Controller for running Linux. Now most things seem to work fine (some problems with UEFI but that was kind of expected), but the xhci_hcd module is filling up my log files with a repeated message (ever 4 seconds): [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 2137.036981] xhci_hcd :00:14.0: Cannot set link state. [ 2137.037767] usb usb2-port1: cannot disable (err = -32) Now I have no idea where usb2-port1 is or why it should have a bad cable, the only USB devices I know of are the USB drive I've booted the system from and the wireless keyboard/mouse combo I'm using. Both seem to work just fine and plugging those into different USB ports doesn't change the message. Bus 002 Device 002: ID 1b1c:1a00 Corsair Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Note: I have no idea what the Hitachi device is. The current kernel is 4.14.13 (from Mageia 6). Any idea what the problem here is and how I can fix or work around it? Please let me know if you need any additional information on the system or environment. lsusb -v could show more details about the misbehaving device. Output of dmesg could tell something as well During testing I found out that there is a correlation between the BIOS and the observed error. When I unplug the power supply for a few seconds, the problem will completely disappear until the next time I enter the BIOS and change something there (doesn't matter what and doesn't affect the result). It also seems to be related to the 'mystical' Hitachi device I couldn't figure out what it is for or why it sits on each USB bus. You can find all the suggested output here ... http://vserver.13thfloor.at/Stuff/XHCI_HCD/ where 'failing' means that the problem is present and 'working' means that everything seems fine. The Hitachi device is a built-in USB3 HUB, (USB3 so it supports both USB2 and USB3 sides) In the failing case the USB3 side of the hub doesn't properly finish reset, and gets stuck in a retry loop. It's possible that we keep retrying a warm reset even if device would require something else to reset it properly(normal reset, or disable device in between) -Mathias -- 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
[RFC PATCH v2 0/5] dt-bindings: add bindings for USB physical connector
Hi, This patchset introduces USB physical connector bindings, together with working example. I have added comments in relevant patches to describe possible issues. In v2 I have addressed comments by Rob and Laurent, thanks Changes are described in patches. Regards Andrzej Andrzej Hajda (4): dt-bindings: add bindings for USB physical connector arm64: dts: exynos: add micro-USB connector node to TM2 platforms arm64: dts: exynos: add OF graph between MHL and USB connector extcon: add possibility to get extcon device by OF node Maciej Purski (1): drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL .../bindings/connector/usb-connector.txt | 48 +++ .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 37 - drivers/extcon/extcon.c| 44 +++--- drivers/gpu/drm/bridge/sil-sii8620.c | 97 +- include/linux/extcon.h | 6 ++ 5 files changed, 216 insertions(+), 16 deletions(-) create mode 100644 Documentation/devicetree/bindings/connector/usb-connector.txt -- 2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 3/5] arm64: dts: exynos: add OF graph between MHL and USB connector
OF graph describes MHL data lanes between MHL and respective USB
connector.
Signed-off-by: Andrzej Hajda
---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index e5a6a2303060..427ff861b441 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -779,9 +779,22 @@
clocks = <&pmu_system_controller 0>;
clock-names = "xtal";
- port {
- mhl_to_hdmi: endpoint {
- remote-endpoint = <&hdmi_to_mhl>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ mhl_to_hdmi: endpoint {
+ remote-endpoint = <&hdmi_to_mhl>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ mhl_to_musb_con: endpoint {
+ remote-endpoint = <&musb_con_to_mhl>;
+ };
};
};
};
@@ -803,6 +816,18 @@
compatible = "usb-b-connector";
label = "micro-USB";
type = "micro";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ musb_con_to_mhl: endpoint {
+ remote-endpoint =
<&mhl_to_musb_con>;
+ };
+ };
+ };
+ };
};
};
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 5/5] drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL
From: Maciej Purski
Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.
Signed-off-by: Maciej Purski
Signed-off-by: Andrzej Hajda
---
This is rework of the patch by Maciej with following changes:
- use micro-USB port bindings to get extcon, instead of extcon property,
- fixed remove sequence,
- fixed extcon get state logic.
Code finding extcon node is hacky IMO, I guess ultimately it should be done
via some framework (maybe even extcon), or at least via helper, I hope it
can stay as is until the proper solution will be merged.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 97 ++--
1 file changed, 94 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 9e785b8e0ea2..565cc352ca81 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -25,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -81,6 +83,10 @@ struct sii8620 {
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
+ struct extcon_dev *extcon;
+ struct notifier_block extcon_nb;
+ struct work_struct extcon_wq;
+ int cable_state;
struct list_head mt_queue;
struct {
int r_size;
@@ -2175,6 +2181,77 @@ static void sii8620_init_rcp_input_dev(struct sii8620
*ctx)
ctx->rc_dev = rc_dev;
}
+static void sii8620_cable_out(struct sii8620 *ctx)
+{
+ disable_irq(to_i2c_client(ctx->dev)->irq);
+ sii8620_hw_off(ctx);
+}
+
+static void sii8620_extcon_work(struct work_struct *work)
+{
+ struct sii8620 *ctx =
+ container_of(work, struct sii8620, extcon_wq);
+ int state = extcon_get_state(ctx->extcon, EXTCON_DISP_MHL);
+
+ if (state == ctx->cable_state)
+ return;
+
+ ctx->cable_state = state;
+
+ if (state > 0)
+ sii8620_cable_in(ctx);
+ else
+ sii8620_cable_out(ctx);
+}
+
+static int sii8620_extcon_notifier(struct notifier_block *self,
+ unsigned long event, void *ptr)
+{
+ struct sii8620 *ctx =
+ container_of(self, struct sii8620, extcon_nb);
+
+ schedule_work(&ctx->extcon_wq);
+
+ return NOTIFY_DONE;
+}
+
+static int sii8620_extcon_init(struct sii8620 *ctx)
+{
+ struct extcon_dev *edev;
+ struct device_node *musb, *muic;
+ int ret;
+
+ /* get micro-USB connector node */
+ musb = of_graph_get_remote_node(ctx->dev->of_node, 1, -1);
+ /* next get micro-USB Interface Controller node */
+ muic = of_get_next_parent(musb);
+
+ if (!muic) {
+ dev_info(ctx->dev, "no extcon found, switching to 'always on'
mode\n");
+ return 0;
+ }
+
+ edev = extcon_get_edev_by_of_node(muic);
+ of_node_put(muic);
+ if (IS_ERR(edev)) {
+ if (PTR_ERR(edev) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(ctx->dev, "Invalid or missing extcon\n");
+ return PTR_ERR(edev);
+ }
+
+ ctx->extcon = edev;
+ ctx->extcon_nb.notifier_call = sii8620_extcon_notifier;
+ INIT_WORK(&ctx->extcon_wq, sii8620_extcon_work);
+ ret = extcon_register_notifier(edev, EXTCON_DISP_MHL, &ctx->extcon_nb);
+ if (ret) {
+ dev_err(ctx->dev, "failed to register notifier for MHL\n");
+ return ret;
+ }
+
+ return 0;
+}
+
static inline struct sii8620 *bridge_to_sii8620(struct drm_bridge *bridge)
{
return container_of(bridge, struct sii8620, bridge);
@@ -2307,13 +2384,20 @@ static int sii8620_probe(struct i2c_client *client,
if (ret)
return ret;
+ ret = sii8620_extcon_init(ctx);
+ if (ret < 0) {
+ dev_err(ctx->dev, "failed to initialize EXTCON\n");
+ return ret;
+ }
+
i2c_set_clientdata(client, ctx);
ctx->bridge.funcs = &sii8620_bridge_funcs;
ctx->bridge.of_node = dev->of_node;
drm_bridge_add(&ctx->bridge);
- sii8620_cable_in(ctx);
+ if (!ctx->extcon)
+ sii8620_cable_in(ctx);
return 0;
}
@@ -2322,8 +2406,15 @@ static int sii8620_remove(struct i2c_client *client)
{
struct sii8620 *ctx = i2c_get_clientdata(client);
- disable_irq(to_i2c_client(ctx->dev)->irq);
- sii8620_hw_off(ctx);
+ if (ctx->extcon) {
+ extcon_unregister_notifier(ctx->extcon, EXTCON_DISP_MHL,
+ &ctx->extcon_nb);
+ flush_work(&c
[RFC PATCH v2 4/5] extcon: add possibility to get extcon device by OF node
Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.
Signed-off-by: Andrzej Hajda
Acked-by: Chanwoo Choi
---
v2: changed label to follow local convention (Chanwoo)
---
drivers/extcon/extcon.c | 44 ++--
include/linux/extcon.h | 6 ++
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
index cb38c2747684..c4972c4cb3bd 100644
--- a/drivers/extcon/extcon.c
+++ b/drivers/extcon/extcon.c
@@ -1336,6 +1336,28 @@ void extcon_dev_unregister(struct extcon_dev *edev)
EXPORT_SYMBOL_GPL(extcon_dev_unregister);
#ifdef CONFIG_OF
+
+/*
+ * extcon_get_edev_by_of_node - Get the extcon device from devicetree.
+ * @node : OF node identyfying edev
+ *
+ * Return the pointer of extcon device if success or ERR_PTR(err) if fail.
+ */
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+ struct extcon_dev *edev;
+
+ mutex_lock(&extcon_dev_list_lock);
+ list_for_each_entry(edev, &extcon_dev_list, entry)
+ if (edev->dev.parent && edev->dev.parent->of_node == node)
+ goto out;
+ edev = ERR_PTR(-EPROBE_DEFER);
+out:
+ mutex_unlock(&extcon_dev_list_lock);
+
+ return edev;
+}
+
/*
* extcon_get_edev_by_phandle - Get the extcon device from devicetree.
* @dev: the instance to the given device
@@ -1363,25 +1385,27 @@ struct extcon_dev *extcon_get_edev_by_phandle(struct
device *dev, int index)
return ERR_PTR(-ENODEV);
}
- mutex_lock(&extcon_dev_list_lock);
- list_for_each_entry(edev, &extcon_dev_list, entry) {
- if (edev->dev.parent && edev->dev.parent->of_node == node) {
- mutex_unlock(&extcon_dev_list_lock);
- of_node_put(node);
- return edev;
- }
- }
- mutex_unlock(&extcon_dev_list_lock);
+ edev = extcon_get_edev_by_of_node(node);
of_node_put(node);
- return ERR_PTR(-EPROBE_DEFER);
+ return edev;
}
+
#else
+
+struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node)
+{
+ return ERR_PTR(-ENOSYS);
+}
+
struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev, int index)
{
return ERR_PTR(-ENOSYS);
}
+
#endif /* CONFIG_OF */
+
+EXPORT_SYMBOL_GPL(extcon_get_edev_by_of_node);
EXPORT_SYMBOL_GPL(extcon_get_edev_by_phandle);
/**
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index 6d94e82c8ad9..b47e0c7f01fe 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -230,6 +230,7 @@ extern void devm_extcon_unregister_notifier_all(struct
device *dev,
* Following APIs get the extcon_dev from devicetree or by through extcon name.
*/
extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
+extern struct extcon_dev *extcon_get_edev_by_of_node(struct device_node *node);
extern struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index);
@@ -283,6 +284,11 @@ static inline struct extcon_dev
*extcon_get_extcon_dev(const char *extcon_name)
return ERR_PTR(-ENODEV);
}
+static inline struct extcon_dev *extcon_get_edev_by_of_node(struct device_node
*node)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline struct extcon_dev *extcon_get_edev_by_phandle(struct device *dev,
int index)
{
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector
These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriate graph bindings.
Signed-off-by: Andrzej Hajda
---
v2:
- moved connector type(A,B,C) to compatible string (Rob),
- renamed size property to type (Rob),
- changed type description to be less confusing (Laurent),
- removed vendor specific compatibles (implied by graph port number),
- added requirement of connector being a child of IC (Rob),
- removed max-mode (subtly suggested by Rob, it should be detected anyway
by USB Controller in runtime, downside is that device is not able to
report its real capabilities, maybe better would be to make it optional(?)),
- assigned port numbers to data buses (Rob).
Regards
Andrzej
Signed-off-by: Andrzej Hajda
---
.../bindings/connector/usb-connector.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/connector/usb-connector.txt
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt
b/Documentation/devicetree/bindings/connector/usb-connector.txt
new file mode 100644
index ..02020f5d760a
--- /dev/null
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -0,0 +1,48 @@
+USB Connector
+=
+
+USB connector node represents physical USB connector. It should be
+a child of USB interface controller.
+
+Required properties:
+- compatible: describes type of the connector, must be one of:
+"usb-a-connector", "usb-b-connector", "usb-c-connector",
+
+Optional properties:
+- label: symbolic name for the connector
+- type: size of the connector, should be specified in case of USB-A, USB-B
+ non-standard (large) connector sizes: "mini", "micro"
+
+Required nodes:
+- any data bus to the connector should be modeled using the OF graph bindings
+ specified in bindings/graph.txt, unless the bus is between parent node and
+ the connector. Since single connector can have multpile data buses every bus
+ has assigned OF graph port number as follows:
+0: High Speed (HS), present in all connectors,
+1: Super Speed (SS), present in SS capable connectors,
+2: Sideband use (SBU), present in USB-C,
+3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB
+
+Example
+---
+
+muic_max77843@66 {
+ ...
+ musb_con: connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@3 {
+ reg = <3>;
+ musb_con_mhl_in: endpoint {
+ remote-endpoint = <&mhl_out>;
+ };
+ };
+ };
+ };
+};
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 2/5] arm64: dts: exynos: add micro-USB connector node to TM2 platforms
Since USB connector bindings are available we can describe it on TM2(e).
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e93d91a3ed..e5a6a2303060 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -798,6 +798,12 @@
muic: max77843-muic {
compatible = "maxim,max77843-muic";
+
+ musb_con: musb_connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ };
};
regulators {
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: host: xhci-hub: avoid xhci_warn() when PORT_PE was clear.
On 31.01.2018 13:58, Yoshihiro Shimoda wrote:
The commit 37be66767e3c ("usb: hub: Fix auto-remount of safely removed
or ejected USB-3 devices") causes the following error when we
disconnected a usb 3.0 device on some environment (e.g. R-Car H3):
xhci-hcd ee00.usb: Cannot set link state.
usb usb8-port1: cannot disable (err = -32)
According to Figure 35 in xhci spec, the PED (PORT_PE) will
be set to 0 after the usb3 root hub enters "Error" or "Disconnected"
state. So, this patch avoids the error messages to return -ENODEV when
asked to set the USB_PORT_FEAT_LINK_STATE feature to U3 and PORT_PE
was clear.
Suggested-by: Mathias Nyman
Suggested-by: Alan Stern
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/host/xhci-hub.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 2a90229..7e95f9e 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1229,8 +1229,11 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
* port link state above '3' (U3) and the port
* must be enabled.
*/
- if ((temp & PORT_PE) == 0 ||
- (link_state > USB_SS_PORT_LS_U3)) {
+ if ((temp & PORT_PE) == 0) {
+ retval = -ENODEV;
+ break;
+ }
+ if (link_state > USB_SS_PORT_LS_U3) {
xhci_warn(xhci, "Cannot set link state.\n");
goto error;
}
Thanks.
Didn't notice this before writing a similar patch.
Anyway, I'll make sure one of them goes forward after rc1
-Mathias
--
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: [resend] Questions about "usb usb8-port1: cannot disable (err = -32)"
On 30.01.2018 17:54, Alan Stern wrote:
On Tue, 30 Jan 2018, Mathias Nyman wrote:
On 26.01.2018 03:47, Yoshihiro Shimoda wrote:
I resent this email with adding Mathias, Alan and Greg as CC.
-Original Message-
From: Yoshihiro Shimoda, Sent: Thursday, January 18, 2018 6:03 PM
To: linux-usb@vger.kernel.org
Subject: Questions about "usb usb8-port1: cannot disable (err = -32)"
Hi,
My environment (R-Car H3) outputs the following error when I disconnected
a usb 3.0 SSD device from the xhci host controller.
[ 267.755777] xhci-hcd ee00.usb: Cannot set link state.
[ 267.761188] usb usb8-port1: cannot disable (err = -32)
[ 267.772166] usb 8-1: USB disconnect, device number 2
But, the environment can detect connection again.
I investigate this issue and found the following commit is related:
37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3
devices
The xhci-hub.c has the following code:
if ((temp & PORT_PE) == 0 ||
(link_state > USB_SS_PORT_LS_U3)) {
xhci_warn(xhci, "Cannot set link state.\n");
goto error;
}
And, the code above will be called by hub_set_port_link_state(...,
USB_SS_PORT_LS_U3)
in hub_port_disable():
/*
* USB-3 does not have a similar link state as USB-2 that will avoid
negotiating
* a connection with a plugged-in cable but will signal the host when the
cable
* is unplugged. Disable remote wake and set link state to U3 for USB-3
devices
*/
static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
{
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_device *hdev = hub->hdev;
int ret = 0;
if (!hub->error) {
if (hub_is_superspeed(hub->hdev)) {
hub_usb3_port_prepare_disable(hub, port_dev);
ret = hub_set_port_link_state(hub, port_dev->portnum,
USB_SS_PORT_LS_U3);
The hub_port_disable() will be called by port_event():
/*
* Warm reset a USB3 protocol port if it's in
* SS.Inactive state.
*/
if (hub_port_warm_reset_required(hub, port1, portstatus)) {
dev_dbg(&port_dev->dev, "do warm reset\n");
if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|| udev->state == USB_STATE_NOTATTACHED) {
if (hub_port_reset(hub, port1, NULL,
HUB_BH_RESET_TIME, true) < 0)
hub_port_disable(hub, port1, 1);
However, according to Figure 35 in xhci spec, the PED will be set to 0
after the usb3 root hub enters "Error" or "Disconnected" state.
So, IIUC, a usb driver should not call hub_set_port_link_state() in such a case.
Question 1:
- Is my understanding correct?
Yes, The idea behind using hub_set_port_link_state(U3) in hub_port_disable() is
for
cases when device is _not_ physically unplugged, but instead user does a
"eject" for
a usb mass storage device which will end up calling hub_port_disable() as well.
Setting it to U3 will prevent a "ejected" device from being re-enumerated and
mounted
one second later.
Question 2:
- How do I resolve the issue? (I don't have any idea for now...)
Is there any other issue than the error messags?
we could read the portstatus in hub_port_disable() and only set the port link
state
to U3 if the port is in currently in a suitable (U0) state.
Or then just make sure xhci_hub_control() doesn't print out any warning when
setting
link state to U3 when PORT_PE is not set, and silence hub_port_disable()
messages as well.
I like the second idea. If xhci_hub_control() returned -ENODEV when
asked to set the USB_PORT_FEAT_LINK_STATE feature to U3 and PORT_PE
was clear, then hub_port_disable() wouldn't complain.
Sounds like a plan, I'll submit it after rc1
https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=for-usb-linus&id=4b42a60487f891d03268af66823a16c31c53801d
-Mathias
--
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] usb: host: xhci-hub: avoid xhci_warn() when PORT_PE was clear.
The commit 37be66767e3c ("usb: hub: Fix auto-remount of safely removed
or ejected USB-3 devices") causes the following error when we
disconnected a usb 3.0 device on some environment (e.g. R-Car H3):
xhci-hcd ee00.usb: Cannot set link state.
usb usb8-port1: cannot disable (err = -32)
According to Figure 35 in xhci spec, the PED (PORT_PE) will
be set to 0 after the usb3 root hub enters "Error" or "Disconnected"
state. So, this patch avoids the error messages to return -ENODEV when
asked to set the USB_PORT_FEAT_LINK_STATE feature to U3 and PORT_PE
was clear.
Suggested-by: Mathias Nyman
Suggested-by: Alan Stern
Signed-off-by: Yoshihiro Shimoda
---
drivers/usb/host/xhci-hub.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 2a90229..7e95f9e 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -1229,8 +1229,11 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
* port link state above '3' (U3) and the port
* must be enabled.
*/
- if ((temp & PORT_PE) == 0 ||
- (link_state > USB_SS_PORT_LS_U3)) {
+ if ((temp & PORT_PE) == 0) {
+ retval = -ENODEV;
+ break;
+ }
+ if (link_state > USB_SS_PORT_LS_U3) {
xhci_warn(xhci, "Cannot set link state.\n");
goto error;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [resend] Questions about "usb usb8-port1: cannot disable (err = -32)"
Hi Mathias, Alan,
> -Original Message-
> From: Alan Stern, Sent: Wednesday, January 31, 2018 12:54 AM
>
> On Tue, 30 Jan 2018, Mathias Nyman wrote:
>
> > On 26.01.2018 03:47, Yoshihiro Shimoda wrote:
> > > I resent this email with adding Mathias, Alan and Greg as CC.
> > >
> > > -Original Message-
> > > From: Yoshihiro Shimoda, Sent: Thursday, January 18, 2018 6:03 PM
> > > To: linux-usb@vger.kernel.org
> > > Subject: Questions about "usb usb8-port1: cannot disable (err = -32)"
> > >
> > > Hi,
> > >
> > > My environment (R-Car H3) outputs the following error when I disconnected
> > > a usb 3.0 SSD device from the xhci host controller.
> > >
> > > [ 267.755777] xhci-hcd ee00.usb: Cannot set link state.
> > > [ 267.761188] usb usb8-port1: cannot disable (err = -32)
> > > [ 267.772166] usb 8-1: USB disconnect, device number 2
> > >
> > > But, the environment can detect connection again.
> > >
> > > I investigate this issue and found the following commit is related:
> > >37be6676 usb: hub: Fix auto-remount of safely removed or ejected USB-3
> > > devices
> > >
> > > The xhci-hub.c has the following code:
> > > if ((temp & PORT_PE) == 0 ||
> > > (link_state > USB_SS_PORT_LS_U3)) {
> > > xhci_warn(xhci, "Cannot set link
> > > state.\n");
> > > goto error;
> > > }
> > >
> > > And, the code above will be called by hub_set_port_link_state(...,
> > > USB_SS_PORT_LS_U3)
> > > in hub_port_disable():
> > > /*
> > > * USB-3 does not have a similar link state as USB-2 that will avoid
> > > negotiating
> > > * a connection with a plugged-in cable but will signal the host when
> > > the cable
> > > * is unplugged. Disable remote wake and set link state to U3 for USB-3
> > > devices
> > > */
> > > static int hub_port_disable(struct usb_hub *hub, int port1, int set_state)
> > > {
> > > struct usb_port *port_dev = hub->ports[port1 - 1];
> > > struct usb_device *hdev = hub->hdev;
> > > int ret = 0;
> > >
> > > if (!hub->error) {
> > > if (hub_is_superspeed(hub->hdev)) {
> > > hub_usb3_port_prepare_disable(hub, port_dev);
> > > ret = hub_set_port_link_state(hub,
> > > port_dev->portnum,
> > >USB_SS_PORT_LS_U3);
> > >
> > > The hub_port_disable() will be called by port_event():
> > > /*
> > > * Warm reset a USB3 protocol port if it's in
> > > * SS.Inactive state.
> > > */
> > > if (hub_port_warm_reset_required(hub, port1, portstatus)) {
> > > dev_dbg(&port_dev->dev, "do warm reset\n");
> > > if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
> > > || udev->state == USB_STATE_NOTATTACHED)
> > > {
> > > if (hub_port_reset(hub, port1, NULL,
> > > HUB_BH_RESET_TIME, true) < 0)
> > > hub_port_disable(hub, port1, 1);
> > >
> > > However, according to Figure 35 in xhci spec, the PED will be set to 0
> > > after the usb3 root hub enters "Error" or "Disconnected" state.
> > > So, IIUC, a usb driver should not call hub_set_port_link_state() in such
> > > a case.
> > >
> > > Question 1:
> > > - Is my understanding correct?
> >
> > Yes, The idea behind using hub_set_port_link_state(U3) in
> > hub_port_disable() is for
> > cases when device is _not_ physically unplugged, but instead user does a
> > "eject" for
> > a usb mass storage device which will end up calling hub_port_disable() as
> > well.
> > Setting it to U3 will prevent a "ejected" device from being re-enumerated
> > and mounted
> > one second later.
Thank you for the reply!
> > >
> > > Question 2:
> > > - How do I resolve the issue? (I don't have any idea for now...)
> >
> > Is there any other issue than the error messags?
No, any other issue happens.
> > we could read the portstatus in hub_port_disable() and only set the port
> > link state
> > to U3 if the port is in currently in a suitable (U0) state.
> >
> > Or then just make sure xhci_hub_control() doesn't print out any warning
> > when setting
> > link state to U3 when PORT_PE is not set, and silence hub_port_disable()
> > messages as well.
>
> I like the second idea. If xhci_hub_control() returned -ENODEV when
> asked to set the USB_PORT_FEAT_LINK_STATE feature to U3 and PORT_PE
> was clear, then hub_port_disable() wouldn't complain.
Thank you for the suggestion. I tested such a code and then it seems good on my
environment.
So, I will submit such a patch later.
Best regards,
Yoshihiro Shimoda
> Alan Stern
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> Mo
Re: uas failing on multiple disk access on a jmicron JMS567 bridge
Hello Actually the mentioned ones are the very first synthomps that something is going wrong: Jan 27 08:56:06 Menionubuntu systemd[1]: dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device: Dev dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device appeared twice wi$ Jan 27 08:56:06 Menionubuntu systemd[2308]: dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device: Dev dev-disk-by\x2duuid-ba1e0d88\x2d2e26\x2d499d\x2d8fe3\x2d458b9c53349a.device appeared twice$ Jan 27 08:57:31 Menionubuntu systemd[1]: Started Session 6 of user menion. Jan 27 08:57:54 Menionubuntu kernel: [ 631.779771] sd 0:0:0:1: [sdb] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.779792] sd 0:0:0:1: [sdb] tag#1 CDB: Write(10) 2a 00 00 35 ca 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.780155] sd 0:0:0:1: [sdb] tag#14 uas_eh_abort_handler 0 uas-tag 15 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.780173] sd 0:0:0:1: [sdb] tag#14 CDB: Write(10) 2a 00 00 35 c6 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.783903] sd 0:0:0:1: [sdb] tag#13 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.783920] sd 0:0:0:1: [sdb] tag#13 CDB: Write(10) 2a 00 00 35 c2 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.787408] sd 0:0:0:1: [sdb] tag#12 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.787429] sd 0:0:0:1: [sdb] tag#12 CDB: Write(10) 2a 00 00 35 be 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.791055] sd 0:0:0:1: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.791076] sd 0:0:0:1: [sdb] tag#0 CDB: Write(10) 2a 00 00 35 ba 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.795040] sd 0:0:0:1: [sdb] tag#11 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.795062] sd 0:0:0:1: [sdb] tag#11 CDB: Write(10) 2a 00 00 35 b6 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.797905] sd 0:0:0:1: [sdb] tag#10 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.797925] sd 0:0:0:1: [sdb] tag#10 CDB: Write(10) 2a 00 00 35 b2 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.801819] sd 0:0:0:1: [sdb] tag#9 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.801838] sd 0:0:0:1: [sdb] tag#9 CDB: Write(10) 2a 00 00 35 ae 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.805521] sd 0:0:0:1: [sdb] tag#8 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.805543] sd 0:0:0:1: [sdb] tag#8 CDB: Write(10) 2a 00 00 35 aa 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.808320] sd 0:0:0:1: [sdb] tag#7 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.808338] sd 0:0:0:1: [sdb] tag#7 CDB: Write(10) 2a 00 00 35 a6 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.812207] sd 0:0:0:1: [sdb] tag#6 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.812224] sd 0:0:0:1: [sdb] tag#6 CDB: Write(10) 2a 00 00 35 a2 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.815606] sd 0:0:0:1: [sdb] tag#5 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.815623] sd 0:0:0:1: [sdb] tag#5 CDB: Write(10) 2a 00 00 35 9e 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.819379] sd 0:0:0:1: [sdb] tag#4 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.819397] sd 0:0:0:1: [sdb] tag#4 CDB: Write(10) 2a 00 00 35 9a 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.823351] sd 0:0:0:1: [sdb] tag#3 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.823372] sd 0:0:0:1: [sdb] tag#3 CDB: Write(10) 2a 00 00 35 96 70 00 04 00 00 Jan 27 08:57:54 Menionubuntu kernel: [ 631.826296] sd 0:0:0:1: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 28 inflight: CMD OUT Jan 27 08:57:54 Menionubuntu kernel: [ 631.826317] sd 0:0:0:1: [sdb] tag#27 CDB: Write(10) 2a 00 00 35 92 70 00 04 00 00 you can see that short while after the two HD are mounted I start to get any sort of USB command errors. The enclosure can run 5 HDD, but when I took the logs, only 2 HDD were mounted, so I think I can exclude any kind of power supply issue also because in BOT mode I didn't get any kind of problem 3 days of operation. I cannot tell if the firmware is buggy, but it is a quite standard 40.16 Jlink firmware version. If you go to the mailing list logs, with the same subject there is another user reporting the same problem fixed by the same workaround (blacklist and use BOT mode) Also, if you google a little bit around, there are a number of same issue
[PATCH] ohci-hcd: Fix race condition caused by ohci_urb_enqueue() and io_watchdog_func()
Running io_watchdog_func() while ohci_urb_enqueue() is running can
cause a race condition where ohci->prev_frame_no is corrupted and the
watchdog can mis-detect following error:
ohci-platform 664a0800.usb: frame counter not updating; disabled
ohci-platform 664a0800.usb: HC died; cleaning up
Specifically, following scenario causes a race condition:
1. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
2. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
3. ohci_urb_enqueue() sets ohci->prev_frame_no to a frame number
read by ohci_frame_no(ohci)
4. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
5. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section
6. Later, ohci_urb_enqueue() is called
7. ohci_urb_enqueue() calls spin_lock_irqsave(&ohci->lock, flags)
and enters the critical section
8. The timer scheduled on step 4 expires and io_watchdog_func() runs
9. io_watchdog_func() calls spin_lock_irqsave(&ohci->lock, flags)
and waits on it because ohci_urb_enqueue() is already in the
critical section on step 7
10. ohci_urb_enqueue() calls timer_pending(&ohci->io_watchdog) and it
returns false
11. ohci_urb_enqueue() sets ohci->prev_frame_no to new frame number
read by ohci_frame_no(ohci) because the frame number proceeded
between step 3 and 6
12. ohci_urb_enqueue() schedules io_watchdog_func() with mod_timer()
13. ohci_urb_enqueue() calls spin_unlock_irqrestore(&ohci->lock,
flags) and exits the critical section, then wake up
io_watchdog_func() which is waiting on step 9
14. io_watchdog_func() enters the critical section
15. io_watchdog_func() calls ohci_frame_no(ohci) and set frame_no
variable to the frame number
16. io_watchdog_func() compares frame_no and ohci->prev_frame_no
On step 16, because this calling of io_watchdog_func() is scheduled on
step 4, the frame number set in ohci->prev_frame_no is expected to the
number set on step 3. However, ohci->prev_frame_no is overwritten on
step 11. Because step 16 is executed soon after step 11, the frame
number might not proceed, so ohci->prev_frame_no must equals to
frame_no.
To address above scenario, this patch introduces timer_running flag to
ohci_hcd structure. Setting true to ohci->timer_running indicates
io_watchdog_func() is scheduled or is running. ohci_urb_enqueue()
checks the flag when it schedules the watchdog (step 4 and 12 above),
so ohci->prev_frame_no is not overwritten while io_watchdog_func() is
running.
Author: Yoshida, Shigeru
Signed-off-by: Haiqing Bai
---
drivers/usb/host/ohci-hcd.c | 7 +++
drivers/usb/host/ohci-hub.c | 4 +++-
drivers/usb/host/ohci.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index ee9676349333..2c7fa0c05854 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -233,10 +233,12 @@ static int ohci_urb_enqueue (
/* Start up the I/O watchdog timer, if it's not running */
if (!timer_pending(&ohci->io_watchdog) &&
list_empty(&ohci->eds_in_use) &&
+ !ohci->timer_running &&
!(ohci->flags & OHCI_QUIRK_QEMU)) {
ohci->prev_frame_no = ohci_frame_no(ohci);
mod_timer(&ohci->io_watchdog,
jiffies + IO_WATCHDOG_DELAY);
+ ohci->timer_running = 1;
}
list_add(&ed->in_use_list, &ohci->eds_in_use);
@@ -501,6 +503,7 @@ static int ohci_init (struct ohci_hcd *ohci)
return 0;
timer_setup(&ohci->io_watchdog, io_watchdog_func, 0);
+ ohci->timer_running = 0;
ohci->hcca = dma_alloc_coherent (hcd->self.controller,
sizeof(*ohci->hcca), &ohci->hcca_dma, GFP_KERNEL);
@@ -732,6 +735,7 @@ static void io_watchdog_func(struct timer_list *t)
struct td *td, *td_start, *td_next;
unsignedframe_no;
unsigned long flags;
+ int timer_running = 0;
spin_lock_irqsave(&ohci->lock, flags);
@@ -841,10 +845,12 @@ static void io_watchdog_func(struct timer_list *t)
&ohci->regs->donehead);
mod_timer(&ohci->io_watchdog,
jiffies + IO_WATCHDOG_DELAY);
+ timer_running = 1;
}
}
done:
+ ohci->timer_running = timer_running;
spin_unlock_irqrestore(&ohci->lock, flags);
}
@@ -973,6 +979,7 @@ static void ohci_stop (struct usb_hcd *hcd)
if (quirk_nec(ohci))
flush_work(&ohci->nec_work);
del_timer_sync(&ohci->io_watchdog);
+ ohci->timer_runni
Re: [PATCH] option: Add support for Quectel EP06
Hi Johan, On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold wrote: > This will probably have to do for now, but we already have another > blacklist struct with the same content which we could rename and > reuse. I noticed the same, but wasn't quite sure about the policy on renaming/recycling and added a new blacklist entry. I can rename the entry and update references as part of this commit. What would be an appropriate name, something straight-forward like "net_intf4_intf5_blacklist"? BR, Kristian -- 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
