Re: USB will randomly stop working
On Tue, Oct 04, 2016 at 11:07:20PM -0700, Ashton Holmes wrote: > On Tue, Oct 4, 2016 at 10:18 PM, Greg KH wrote: > > On Tue, Oct 04, 2016 at 05:15:17PM -0700, Ashton Holmes wrote: > >> On Tue, Oct 4, 2016 at 12:11 AM, Greg KH > >> wrote: > >> >> Also my knowledge of git isn't that extensive and I got the source > >> >> from the download on the site not from the git repo so it tells me > >> >> there's no .git file but if I can figure out how to run that I'll give > >> >> it a go. > >> > > >> > You can pull Linus's tree from git.kernel.org by doing: > >> > git clone > >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > >> > > >> > and using your .config in that tree. > >> > > >> > There is lots of documentation of how to use 'git bisect' but if you > >> > have any questions, please let us know. > >> > >> Alright this is the output of git bisect > >> e65805251f2db69c9f67ed8062ab82526be5a374 is the first bad commit > > > > That's a great start, but that's the first bad one, you need to now use > > 'git bisect bad' and it will keep going and narrow it down to the commit > > that causes the problem itself. > > All the tutorials I saw ended when it got to the first bad commit. I > went through and compiled 13 different kernels or so so wouldn't that > be the commit that introduced the issue or am I missing something? No, that's one "leaf" of the tree that does not work (it's a merge commit so maybe something in that merge caused the issue). You need to keep going and find the real actual commit that caused the problem. You will probably run into a few 'good' and 'bad' commits from here on and eventually git bisect will spit out a "this is the bad commit" message. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PROBLEM: am3517 usb-ohci not working
Hi,
I am trying to make 4.4 kernel working with old am3517 SOM
(http://www.dave.eu/products/som/texas_instruments/am3505-am3517_lizard).
Most of the peripherals are working know - however I got stuck with
usb ohci driver.
Both USB HS ports are connected to ISP1105, hardware is working with
old 2.6.32 based firmware.
I copied the MUXing (muxing is done by u-boot) and TLL/PHY
initialization from old kernel.
My DT entries are:
/ {
hsusb1_power: hsusb1_power_reg {
compatible = "regulator-fixed";
regulator-name = "hsusb1_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
};
hsusb1_phy: hsusb1_phy {
compatible = "usb-nop-xceiv";
vcc-supply = <&hsusb1_power>;
};
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
vcc-supply = <&hsusb2_power>;
};
};
&usbhshost {
port1-mode = "ohci-phy-6pin-datse0";
port2-mode = "ohci-phy-6pin-datse0";
};
&usbhsehci {
status = "disabled";
};
CORE_120M_FCLK clock is enabled.
Interrupts are working and kernel is notified when I plug in usb
drive. However usb device is it not enumerated.
I got following debug messages:
usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
and finally:
usb usb1-port1: unable to enumerate USB device
also I can see log like this:
ohci-omap3 48064400.ohci: GetStatus roothub.portstatus [0] =
0x00120101 PRSC PESC PPS CCS
GetStatus message appears multiple times when usb device is plugged in.
I can see FSLSLINESTATE in TLL_CHANNEL_CONF changes when usb device is
connected:
./devmem2 0x48062040
Read at address 0x48062040 (0xb6f9b040): 0x1CDB
Can you point me what else should I check to make USB HS working in ohci mode?
Thank you and best regards,
Luke
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB will randomly stop working
On Tue, Oct 4, 2016 at 10:18 PM, Greg KH wrote: > On Tue, Oct 04, 2016 at 05:15:17PM -0700, Ashton Holmes wrote: >> On Tue, Oct 4, 2016 at 12:11 AM, Greg KH wrote: >> >> Also my knowledge of git isn't that extensive and I got the source >> >> from the download on the site not from the git repo so it tells me >> >> there's no .git file but if I can figure out how to run that I'll give >> >> it a go. >> > >> > You can pull Linus's tree from git.kernel.org by doing: >> > git clone >> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> > >> > and using your .config in that tree. >> > >> > There is lots of documentation of how to use 'git bisect' but if you >> > have any questions, please let us know. >> >> Alright this is the output of git bisect >> e65805251f2db69c9f67ed8062ab82526be5a374 is the first bad commit > > That's a great start, but that's the first bad one, you need to now use > 'git bisect bad' and it will keep going and narrow it down to the commit > that causes the problem itself. All the tutorials I saw ended when it got to the first bad commit. I went through and compiled 13 different kernels or so so wouldn't that be the commit that introduced the issue or am I missing something? > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB will randomly stop working
On Tue, Oct 04, 2016 at 05:15:17PM -0700, Ashton Holmes wrote: > On Tue, Oct 4, 2016 at 12:11 AM, Greg KH wrote: > >> Also my knowledge of git isn't that extensive and I got the source > >> from the download on the site not from the git repo so it tells me > >> there's no .git file but if I can figure out how to run that I'll give > >> it a go. > > > > You can pull Linus's tree from git.kernel.org by doing: > > git clone > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > > and using your .config in that tree. > > > > There is lots of documentation of how to use 'git bisect' but if you > > have any questions, please let us know. > > Alright this is the output of git bisect > e65805251f2db69c9f67ed8062ab82526be5a374 is the first bad commit That's a great start, but that's the first bad one, you need to now use 'git bisect bad' and it will keep going and narrow it down to the commit that causes the problem itself. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Anand, On Tue, Oct 4, 2016 at 8:39 PM, Anand Moon wrote: > Hi Vivek, > [snip] > > What I feel is that their need to be some reset of usb phy so that > device are assigned to respective bus ports. The phy resets are what we do in the phy-exynos5-usbdrd driver. In addition to what we have currently in this phy driver, we just need the phy calibration patch [1] for phy configurations. [1] https://lkml.org/lkml/2015/2/2/259 > odroid@odroid:~$ lsusb -t > /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 480M This shows the ethernet device gets detected on the high-speed port of one of the controller. The lsusb output for kernel v4.7.x posted by Michael show that the ethernet device got detected on super-speed port of the controller. So, there seems to be a difference between the two. Or, is this how it is behaving ? Is this lsusb output on 4.8 kernel with the patch [1] ? > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 5000M > |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 5000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/2p, 480M > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=exynos-ohci/3p, 12M > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=exynos-ehci/3p, 480M > |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M > > > Bus 06.Port should register the Realtek Ethernet r8153 device. > But I am not able to trace out how it's should happen. If i understand, below is how the configuration looks like on the board? +---+ +-->| | | | Bus 6 |---+ +---+ |(super-speed) | | | | +---+ | |Controller | | > Ethernet device |2 | | | | +---+ | +---+ | | | | | Bus 5 |---+ +-->| (high-speed)| +---+ +---+ +-->| | | | Bus 4 |---+ +---+ |(super-speed) | | | | +---+ | |Controller | | > (On board hub ?? _OR_ external hub with downstream devices) ??? |1 | | | | +---+ | +---+ | | | | | Bus 3 |---+ +-->| (high-speed)| +---+ Thanks Vivek -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB will randomly stop working
On Tue, Oct 4, 2016 at 12:11 AM, Greg KH wrote: > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > A: No. > Q: Should I include quotations after my reply? > > > http://daringfireball.net/2007/07/on_top Sorry for the quoting. I fixed it in this reply but gmail auto-quotes among other things like using multipart formatted messages. So far I've replied to every email only to get a reply from mailer daemon telling me to use plain text at which point I have to resend it in plain text. I've never really used a mailing list before. > On Mon, Oct 03, 2016 at 01:48:55PM -0700, Ashton Holmes wrote: >> Coming from the kernel? No there's no kernel lines right before that >> that have to do with USB. The kernel line before that is: Oct 2 >> 22:21:45 user-desktop kernel: [ 38.122133] Bluetooth: BNEP socket >> layer initialized. And that's quite a ways up in the file. > > Are you sure? Any other messages might help out here. I'm positive there's no other kernel messages. I did /kernel in vi and the next thing that came up after the bluetooth message was the USB error. There was nothing in between. >> Also my knowledge of git isn't that extensive and I got the source >> from the download on the site not from the git repo so it tells me >> there's no .git file but if I can figure out how to run that I'll give >> it a go. > > You can pull Linus's tree from git.kernel.org by doing: > git clone > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > and using your .config in that tree. > > There is lots of documentation of how to use 'git bisect' but if you > have any questions, please let us know. Alright this is the output of git bisect e65805251f2db69c9f67ed8062ab82526be5a374 is the first bad commit > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: core: remove local_irq_save/restore around urb->complete
On Tue, Oct 04, 2016 at 02:50:09PM -0400, Alan Stern wrote: > On Tue, 4 Oct 2016, Bin Liu wrote: > > > local_irq_save() disables irq completely on non-SMP which causes the > > hard interrupt handler unable to serve interrupts, which loses the > > benefit that the giveback tasklet brings in usb_hcd_giveback_urb(). > > It doesn't lose all the benefit. Interrupts are still enabled before > and after the local_irq_save region. Yeah, but the problem is the irq disabled region is sometimes huge (in ms range in uvc device driver). > > > One example of the issues caused by this disabling local irq is that > > urb->complete in uvc driver takes about 1ms, which holds the host > > controller to not receive packets for so long that causes webcam drops > > data. > > > > I don't see any callers of usb_hcd_giveback_urb() holding a spin_lock, > > so it is safe to remove this local_irq_save/restore() around > > urb->complete. > > How carefully did you look? ehci_urb_done() holds ehci->lock while > calling usb_hcd_giveback_urb(). Obviously not much :( I checked a few level up from ehci_urb_done(), but didn't reach echi->lock... > > Anyway, that's not the problem this code was meant to solve. The > problem is that the completion routine in a USB driver might expect to > be called with interrupts disabled, and therefore might use spin_lock() > instead of spin_lock_irqsave(). You can't remove this local_irq_save() > until you have checked all the completion routines in all the USB > drivers to make sure they don't make this mistake. Ok, I will try to understand it more. Thanks for the comments. Regards, -Bin. > > Alan Stern > > > Signed-off-by: Bin Liu > > --- > > v2: fix build warning > > > > drivers/usb/core/hcd.c | 14 -- > > 1 file changed, 14 deletions(-) > > > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > > index 479e223..c18d480 100644 > > --- a/drivers/usb/core/hcd.c > > +++ b/drivers/usb/core/hcd.c > > @@ -1733,7 +1733,6 @@ static void __usb_hcd_giveback_urb(struct urb *urb) > > struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus); > > struct usb_anchor *anchor = urb->anchor; > > int status = urb->unlinked; > > - unsigned long flags; > > > > urb->hcpriv = NULL; > > if (unlikely((urb->transfer_flags & URB_SHORT_NOT_OK) && > > @@ -1751,20 +1750,7 @@ static void __usb_hcd_giveback_urb(struct urb *urb) > > /* pass ownership to the completion handler */ > > urb->status = status; > > > > - /* > > -* We disable local IRQs here avoid possible deadlock because > > -* drivers may call spin_lock() to hold lock which might be > > -* acquired in one hard interrupt handler. > > -* > > -* The local_irq_save()/local_irq_restore() around complete() > > -* will be removed if current USB drivers have been cleaned up > > -* and no one may trigger the above deadlock situation when > > -* running complete() in tasklet. > > -*/ > > - local_irq_save(flags); > > urb->complete(urb); > > - local_irq_restore(flags); > > - > > usb_anchor_resume_wakeups(anchor); > > atomic_dec(&urb->use_count); > > if (unlikely(atomic_read(&urb->reject))) > -- 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: xhci: add port test modes support for USB2
For USB2 ports, the port test modes TEST_J_State, Test_K_State,
Test_Packet and Test_SE0_NAK can be enabled as described in USB2
spec.
Signed-off-by: Guoqing Zhang
---
drivers/usb/host/xhci-hub.c | 55 +++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index d61fcc4..ccc558c 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -873,16 +873,18 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
u16 wIndex, char *buf, u16 wLength)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct xhci_command *command;
int max_ports;
unsigned long flags;
u32 temp, status;
- int retval = 0;
+ int i, retval = 0;
__le32 __iomem **port_array;
int slot_id;
struct xhci_bus_state *bus_state;
u16 link_state = 0;
u16 wake_mask = 0;
u16 timeout = 0;
+ u16 selector = 0;
max_ports = xhci_get_ports(hcd, &port_array);
bus_state = &xhci->bus_state[hcd_index(hcd)];
@@ -956,6 +958,8 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
link_state = (wIndex & 0xff00) >> 3;
if (wValue == USB_PORT_FEAT_REMOTE_WAKE_MASK)
wake_mask = wIndex & 0xff00;
+ if (wValue == USB_PORT_FEAT_TEST)
+ selector = (wIndex & 0xff00) >> 8;
/* The MSB of wIndex is the U1/U2 timeout */
timeout = (wIndex & 0xff00) >> 8;
wIndex &= 0xff;
@@ -1014,7 +1018,6 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
break;
case USB_PORT_FEAT_LINK_STATE:
temp = readl(port_array[wIndex]);
-
/* Disable port */
if (link_state == USB_SS_PORT_LS_SS_DISABLED) {
xhci_dbg(xhci, "Disable port %d\n", wIndex);
@@ -1131,6 +1134,54 @@ int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq,
u16 wValue,
temp |= PORT_U2_TIMEOUT(timeout);
writel(temp, port_array[wIndex] + PORTPMSC);
break;
+ case USB_PORT_FEAT_TEST:
+ /* 4.19.6 Port Test Modes (USB2 Test Mode) */
+ if (hcd->speed != HCD_USB2)
+ goto error;
+ /* FIXME: Test_Force_Enable case to be implemented */
+ if (!selector || selector > 4)
+ goto error;
+ /* Disable all Device Slots */
+ for (i = 0; i < MAX_HC_SLOTS; i++) {
+ if (!xhci->dcbaa->dev_context_ptrs[i])
+ continue;
+ command = xhci_alloc_command(xhci, false,
+ false, GFP_KERNEL);
+ if (!command)
+ return -ENOMEM;
+ if (xhci_queue_slot_control(xhci, command,
+ TRB_DISABLE_SLOT, i)) {
+ xhci_err(xhci,
+ "Disable slot[%d] fail!\n", i);
+ goto error;
+ }
+ xhci_dbg(xhci, "Disable Slot[%d].\n", i);
+ }
+ /* Put all ports to the Disable state by clear PP */
+ xhci_dbg(xhci, "Disable all port (PP = 0)\n");
+ for (i = 0; i < max_ports; i++) {
+ temp = readl(port_array[i]);
+ temp &= ~PORT_POWER;
+ writel(temp, port_array[i]);
+ }
+ /* Stop the controller */
+ xhci_dbg(xhci, "Stop controller\n");
+ temp = readl(&xhci->op_regs->command);
+ temp &= ~CMD_RUN;
+ writel(temp, &xhci->op_regs->command);
+ if (xhci_handshake(&xhci->op_regs->status,
+ STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC)) {
+ xhci_warn(xhci, "Stop controller timeout\n");
+ return -ETIMEDOUT;
+ }
+ /* Disable runtime PM for test mode */
+ pm_runtime_forbid(hcd->self.controller);
+ /* Set PORTPMSC.PTC field for selected test mode */
+ xhci_dbg(xhci, "Enter Test Mode: %d\n", selector);
+ temp = readl(port_array[wIndex]
[PATCH v2] hwrng: chaoskey - drop workaround for old hwrng core limitation
The hwrng core used to mask 'quality' with 1023; that has been removed
in commit 506bf0c0464ace57169aadcf02ae397999c57bdd ("hwrng: core - allow
perfect entropy from hardware devices"), so we can now just set quality
to 1024.
Signed-off-by: Julien Cristau
---
drivers/usb/misc/chaoskey.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
v2: fixed commit citing format (Sergei Shtylyov)
diff --git a/drivers/usb/misc/chaoskey.c b/drivers/usb/misc/chaoskey.c
index 6ddd08a..aa350dc 100644
--- a/drivers/usb/misc/chaoskey.c
+++ b/drivers/usb/misc/chaoskey.c
@@ -215,19 +215,7 @@ static int chaoskey_probe(struct usb_interface *interface,
dev->hwrng.name = dev->name ? dev->name : chaoskey_driver.name;
dev->hwrng.read = chaoskey_rng_read;
-
- /* Set the 'quality' metric. Quality is measured in units of
-* 1/1024's of a bit ("mills"). This should be set to 1024,
-* but there is a bug in the hwrng core which masks it with
-* 1023.
-*
-* The patch that has been merged to the crypto development
-* tree for that bug limits the value to 1024 at most, so by
-* setting this to 1024 + 1023, we get 1023 before the fix is
-* merged and 1024 afterwards. We'll patch this driver once
-* both bits of code are in the same tree.
-*/
- dev->hwrng.quality = 1024 + 1023;
+ dev->hwrng.quality = 1024;
dev->hwrng_registered = (hwrng_register(&dev->hwrng) == 0);
if (!dev->hwrng_registered)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach
On Tue, Oct 04, 2016 at 12:30:58PM -0500, David Lechner wrote: > On 10/04/2016 08:38 AM, Greg Kroah-Hartman wrote: > > On Tue, Oct 04, 2016 at 11:18:03AM +0200, Kevin Hilman wrote: > > > Hi Greg, > > > > > > On Mon, Sep 5, 2016 at 10:00 PM, David Lechner > > > wrote: > > > > Including mach/* is frowned upon in device drivers, so get rid of it. > > > > > > > > This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy > > > > driver. > > > > > > > > Signed-off-by: David Lechner > > > > Acked-by: Alan Stern > > > > > > Can you pick up this patch? > > > > > > Patches 2 & 3 from this series were picked up by Bin for musb, but > > > this one is still outstanding. > > > > It's not in my todo queue from what I can tell, so it would have to be > > resent and I can pick it up after 4.9-rc1 is out. > > > > thanks, > > > > greg k-h > > > > Are there any magic email headers needed to make sure you don't miss it or > will > > Subject: [RESEND PATCH v6 1/3]... > To: gregkh@... > > do the trick? As you don't want me to take patches 2 and 3, and you will not be sending them, just resend it as a stand-alone patch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb/core: Added devspec sysfs entry for devices behind usb hub
On Tue, Oct 04, 2016 at 12:04:40PM -0700, Vijay Kumar wrote:
> Grub finds incorrect of_node path for devices behind usb hub.
> Added devspec sysfs entry for devices behind usb hub so that
> right of_node path is returned during grub sysfs walk for these
> devices.
>
> Signed-off-by: Vijay Kumar
>
> ---
> drivers/usb/core/sysfs.c | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
> index c953a0f..84d66d5 100644
> --- a/drivers/usb/core/sysfs.c
> +++ b/drivers/usb/core/sysfs.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include "usb.h"
>
> /* Active configuration fields */
> @@ -104,6 +105,17 @@ static ssize_t bConfigurationValue_store(struct device
> *dev,
> static DEVICE_ATTR_IGNORE_LOCKDEP(bConfigurationValue, S_IRUGO | S_IWUSR,
> bConfigurationValue_show, bConfigurationValue_store);
>
> +#ifdef CONFIG_OF
> +static ssize_t devspec_show(struct device *dev, struct device_attribute
> *attr,
> + char *buf)
> +{
> + struct device_node *of_node = dev->of_node;
> +
> + return sprintf(buf, "%s\n", of_node_full_name(of_node));
> +}
> +static DEVICE_ATTR_RO(devspec);
> +#endif
Any way to do this without the #ifdef?
And you need to also update Documentation/ABI if you add a new sysfs
file.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb/core: Added devspec sysfs entry for devices behind usb hub
Grub finds incorrect of_node path for devices behind usb hub.
Added devspec sysfs entry for devices behind usb hub so that
right of_node path is returned during grub sysfs walk for these
devices.
Signed-off-by: Vijay Kumar
---
drivers/usb/core/sysfs.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index c953a0f..84d66d5 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "usb.h"
/* Active configuration fields */
@@ -104,6 +105,17 @@ static ssize_t bConfigurationValue_store(struct device
*dev,
static DEVICE_ATTR_IGNORE_LOCKDEP(bConfigurationValue, S_IRUGO | S_IWUSR,
bConfigurationValue_show, bConfigurationValue_store);
+#ifdef CONFIG_OF
+static ssize_t devspec_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct device_node *of_node = dev->of_node;
+
+ return sprintf(buf, "%s\n", of_node_full_name(of_node));
+}
+static DEVICE_ATTR_RO(devspec);
+#endif
+
/* String fields */
#define usb_string_attr(name) \
static ssize_t name##_show(struct device *dev,
\
@@ -786,6 +798,9 @@ static struct attribute *dev_attrs[] = {
&dev_attr_remove.attr,
&dev_attr_removable.attr,
&dev_attr_ltm_capable.attr,
+#ifdef CONFIG_OF
+ &dev_attr_devspec.attr,
+#endif
NULL,
};
static struct attribute_group dev_attr_grp = {
--
1.7.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 v2] usb: core: remove local_irq_save/restore around urb->complete
On Tue, 4 Oct 2016, Bin Liu wrote: > local_irq_save() disables irq completely on non-SMP which causes the > hard interrupt handler unable to serve interrupts, which loses the > benefit that the giveback tasklet brings in usb_hcd_giveback_urb(). It doesn't lose all the benefit. Interrupts are still enabled before and after the local_irq_save region. > One example of the issues caused by this disabling local irq is that > urb->complete in uvc driver takes about 1ms, which holds the host > controller to not receive packets for so long that causes webcam drops > data. > > I don't see any callers of usb_hcd_giveback_urb() holding a spin_lock, > so it is safe to remove this local_irq_save/restore() around > urb->complete. How carefully did you look? ehci_urb_done() holds ehci->lock while calling usb_hcd_giveback_urb(). Anyway, that's not the problem this code was meant to solve. The problem is that the completion routine in a USB driver might expect to be called with interrupts disabled, and therefore might use spin_lock() instead of spin_lock_irqsave(). You can't remove this local_irq_save() until you have checked all the completion routines in all the USB drivers to make sure they don't make this mistake. Alan Stern > Signed-off-by: Bin Liu > --- > v2: fix build warning > > drivers/usb/core/hcd.c | 14 -- > 1 file changed, 14 deletions(-) > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index 479e223..c18d480 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -1733,7 +1733,6 @@ static void __usb_hcd_giveback_urb(struct urb *urb) > struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus); > struct usb_anchor *anchor = urb->anchor; > int status = urb->unlinked; > - unsigned long flags; > > urb->hcpriv = NULL; > if (unlikely((urb->transfer_flags & URB_SHORT_NOT_OK) && > @@ -1751,20 +1750,7 @@ static void __usb_hcd_giveback_urb(struct urb *urb) > /* pass ownership to the completion handler */ > urb->status = status; > > - /* > - * We disable local IRQs here avoid possible deadlock because > - * drivers may call spin_lock() to hold lock which might be > - * acquired in one hard interrupt handler. > - * > - * The local_irq_save()/local_irq_restore() around complete() > - * will be removed if current USB drivers have been cleaned up > - * and no one may trigger the above deadlock situation when > - * running complete() in tasklet. > - */ > - local_irq_save(flags); > urb->complete(urb); > - local_irq_restore(flags); > - > usb_anchor_resume_wakeups(anchor); > atomic_dec(&urb->use_count); > if (unlikely(atomic_read(&urb->reject))) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: core: remove local_irq_save/restore around urb->complete
local_irq_save() disables irq completely on non-SMP which causes the hard interrupt handler unable to serve interrupts, which loses the benefit that the giveback tasklet brings in usb_hcd_giveback_urb(). One example of the issues caused by this disabling local irq is that urb->complete in uvc driver takes about 1ms, which holds the host controller to not receive packets for so long that causes webcam drops data. I don't see any callers of usb_hcd_giveback_urb() holding a spin_lock, so it is safe to remove this local_irq_save/restore() around urb->complete. Signed-off-by: Bin Liu --- v2: fix build warning drivers/usb/core/hcd.c | 14 -- 1 file changed, 14 deletions(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 479e223..c18d480 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1733,7 +1733,6 @@ static void __usb_hcd_giveback_urb(struct urb *urb) struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus); struct usb_anchor *anchor = urb->anchor; int status = urb->unlinked; - unsigned long flags; urb->hcpriv = NULL; if (unlikely((urb->transfer_flags & URB_SHORT_NOT_OK) && @@ -1751,20 +1750,7 @@ static void __usb_hcd_giveback_urb(struct urb *urb) /* pass ownership to the completion handler */ urb->status = status; - /* -* We disable local IRQs here avoid possible deadlock because -* drivers may call spin_lock() to hold lock which might be -* acquired in one hard interrupt handler. -* -* The local_irq_save()/local_irq_restore() around complete() -* will be removed if current USB drivers have been cleaned up -* and no one may trigger the above deadlock situation when -* running complete() in tasklet. -*/ - local_irq_save(flags); urb->complete(urb); - local_irq_restore(flags); - usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); if (unlikely(atomic_read(&urb->reject))) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: core: remove local_irq_save/restore around urb->complete
local_irq_save() disables irq completely on non-SMP which causes the hard interrupt handler unable to serve interrupts, which loses the benefit that the giveback tasklet brings in usb_hcd_giveback_urb(). One example of the issues caused by this disabling local irq is that urb->complete in uvc driver takes about 1ms, which holds the host controller to receive packets for so long that causes webcam drops data. I don't see any callers of usb_hcd_giveback_urb() holding a spin_lock, so it is safe to remove this local_irq_save/restore() around urb->complete. Signed-off-by: Bin Liu --- drivers/usb/core/hcd.c | 13 - 1 file changed, 13 deletions(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index 479e223..ae093f2 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1751,20 +1751,7 @@ static void __usb_hcd_giveback_urb(struct urb *urb) /* pass ownership to the completion handler */ urb->status = status; - /* -* We disable local IRQs here avoid possible deadlock because -* drivers may call spin_lock() to hold lock which might be -* acquired in one hard interrupt handler. -* -* The local_irq_save()/local_irq_restore() around complete() -* will be removed if current USB drivers have been cleaned up -* and no one may trigger the above deadlock situation when -* running complete() in tasklet. -*/ - local_irq_save(flags); urb->complete(urb); - local_irq_restore(flags); - usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); if (unlikely(atomic_read(&urb->reject))) -- 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: [PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach
On 10/04/2016 08:38 AM, Greg Kroah-Hartman wrote: On Tue, Oct 04, 2016 at 11:18:03AM +0200, Kevin Hilman wrote: Hi Greg, On Mon, Sep 5, 2016 at 10:00 PM, David Lechner wrote: Including mach/* is frowned upon in device drivers, so get rid of it. This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy driver. Signed-off-by: David Lechner Acked-by: Alan Stern Can you pick up this patch? Patches 2 & 3 from this series were picked up by Bin for musb, but this one is still outstanding. It's not in my todo queue from what I can tell, so it would have to be resent and I can pick it up after 4.9-rc1 is out. thanks, greg k-h Are there any magic email headers needed to make sure you don't miss it or will Subject: [RESEND PATCH v6 1/3]... To: gregkh@... do the trick? -- 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: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Vivek, On 4 October 2016 at 17:32, Vivek Gautam wrote: > Hi Michael, > > > On Tue, Oct 4, 2016 at 4:28 PM, Michael Niewöhner > wrote: > >> > > > > > [1.] One line summary of the problem: >> > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 >> > > > > > >> > > > > > [2.] Full description of the problem/report: >> > > > > > No usb 3.0 devices are being detected when attached while USB 2.0 >> > > > > > devices work on the same port. >> > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems >> > > > > > to be >> > > > > > buggy. The usb hub is redetected every time an usb device is >> > > > > > attached. > > [snip] > >>> > > > > > [9.] Other notes, patches, fixes, workarounds: >>> > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 >>> > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 >>> >>> These patches are required to get USB super-speed working on >>> Exynos5420/5800. >>> But they did not make to upstream. There was resistance on adding new >>> phy_calibrate() >>> callback. >>> >>> Without these patches the Exynos5420/5800 will enumerate all >>> super-speed capable devices >>> as high-speed devices. >>> Last time we checked with exynos542x smdk boards and peach-* boards, >>> we could get the >>> Super - speed devices working. I have not tested odroid anytime so >>> don't have much idea about the >>> its intricacies. >>> I guess Anand was able to use these patches to get his kernel working in >>> past. >> >> >> The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very >> unstable - with 4.7. >> >> One more problem appeared since one of the 4.8-RCs: reboot hangs when the >> dwc3 >> module is loaded. If I unload it before reboot / shutdown everything is fine. >> >> >>> >>> When you have a downstream on-board usb hub, ideally it should be able >>> to detect the devices >>> and not reset everytime you connect a new device (like you mentioned >>> earlier). >>> There can be two possible reasons why the hub keeps getting reset ever >>> after applying the above >>> mentioned patches: >>> 1) the clock rates are not proper. >>> 2) the regulator load setting is not enough to drive the hub. >>> >>> Anand, can you please point Michael to an older kernel with which you >>> could test usb on odroid successfully ? >>> You can compare the clocks with an older version and see if there'a >>> any difference. >>> >>> Any possibility of any other framework (such as, bus-freq) trimming >>> down the clock - rates ? >> >> >> >> # v4.7.5 >> >> >> $ cat /sys/kernel/debug/clk/clk_summary | grep usb >> sclk_usbh20_scan_clk 00 48000 >> 0 >> sclk_usbh20 0048000 >> 000 0 >> mout_usbd300 112400 >> 0 >>dout_usbd300 002400 >> 0 >> sclk_usbd300 >> 002400 0 >>dout_usbphy300 112400 >> 0 >> sclk_usbphy300 4424000 >> 000 0 >> mout_usbd301 112400 >> 0 >>dout_usbd301 002400 >> 0 >> sclk_usbd301 >> 002400 0 >>dout_usbphy301 112400 >> 0 >> sclk_usbphy301 3324000 >> 000 0 >> usbd301 11 1 >> usbd300 11 1 >> >> usbh20 33 1 0 > >> >> >> # v4.8.0 >> >> >> $ cat /sys/kernel/debug/clk/clk_summary | grep usb >> sclk_usbh20_scan_clk 00 48000 >> 0 >> sclk_usbh20 004800 >> 0 >> mout_usbd300 112400 >> 0 >>dout_usbd300 002400 >> 0 >> sclk_usbd300 >> 002400 0 >>dout_usbphy300 112400 >> 0 >> sclk_usbphy300 442400 >> 0 >> mout_usbd301 112400 >> 0 >>dout_usbd301 002400 >> 0 >> sclk_usbd301 >> 002400 0 >>dout_usbphy301 112400 >> 0 >> sclk_usbphy30
Re: USB hot-plug not working (ASUS TP301UA-C4028T)
On Tue, 4 Oct 2016, Mathias Nyman wrote: > On 03.10.2016 23:54, Pierre de Villemereuil wrote: > > Hi Mathias, > > > > Just to know: does that mean the firmware from Asus is faulty in here? Do > > you > > think I should contact Asus about this? > > > > Probably, _S0W, _DSM and XFLT code for xHCI are useless in that ACPI DSDT > firmware version. > > But we still want the driver to handle cases like this. > Just wrote the patch. > Adding Alan Stern to CC for PM sanity feedback on it: > > --- > > Author: Mathias Nyman > Date: Tue Oct 4 13:07:59 2016 +0300 > > xhci: Prevent a non-responsive xhci suspend state. > > ACPI may limit the lowest possible runtime suspend PCI D-state to D0. > If xHC is not capable of generating PME# events in D0 we end > up with a non-responsive runtime suspended host without PME# capability > and with interrupts disabled, unable to detect or wake up when a > new usb device is connected. > > This was triggered on a ASUS TP301UA machine. > > Reported-by: Pierre de Villemereuil > Signed-off-by: Mathias Nyman > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c > index d7b0f97..08b021c 100644 > --- a/drivers/usb/host/xhci-pci.c > +++ b/drivers/usb/host/xhci-pci.c > @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool > do_wakeup) > if (xhci->quirks & XHCI_SSIC_PORT_UNUSED) > xhci_ssic_port_unused_quirk(hcd, true); > > + /* Prevent a non-responsive PCI D0 state without PME# wake capability > */ > + if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0) > + if (!pci_pme_capable(pdev, PCI_D0)) > + return -EBUSY; > + > ret = xhci_suspend(xhci, do_wakeup); > if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED)) > xhci_ssic_port_unused_quirk(hcd, false); I've got three comments about this proposal. First, this logic should not apply during system suspend, only during runtime suspend. You don't want to abort putting a laptop to sleep just because the xHCI controller can't generate wakeup signals. Second, this really has nothing to do with the D0 state. The same logic should apply to whatever state is chosen for runtime suspend: If the controller can't generate PME# wakeup signals in that state then the suspend should be aborted. Third, the same reasoning applies to every PCI device that relies on PME#, not just to xHCI controllers. Therefore the new code should be added to drivers/pci/pci-driver.c:pci_pm_runtime_suspend(), not to xhci-pci.c. 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
Re: [PATCH] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
Hi,
Ville Syrjälä writes:
> On Tue, Oct 04, 2016 at 03:23:12PM +0300, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Ville Syrjälä writes:
>> > On Mon, Oct 03, 2016 at 07:08:43PM +0300, Felipe Balbi wrote:
>> >>
>> >> Hi,
>> >>
>> >> ville.syrj...@linux.intel.com writes:
>> >> > From: Ville Syrjälä
>> >> >
>> >> > This reverts commit 55a0237f8f47957163125e20ee9260538c5c341c.
>> >> >
>> >> > commit 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for
>> >> > LST bit") causes my BYT FFRD8 with g_ether to behave poorly. ssh/scp
>> >> > is very sluggish and can even stall entirely. Revert cures it.
>> >> >
>> >> > Cc: Felipe Balbi
>> >> > Cc: sta...@vger.kernel.org
>> >> > Signed-off-by: Ville Syrjälä
>> >>
>> >> Reverting that commit is not the best idea. Let's start with the usual:
>> >>
>> >> - Kernel version
>> >> - dmesg on both sides (host and device)
>> >> - dwc3 tracepoints:
>> >>
>> >> # mkdir -p /t
>> >> # mount -t tracefs none /t
>> >> # echo 8192 > /t/buffer_size_kb
>> >> # echo 1 > /t/events/dwc3/enable
>> >> # echo 0 > /t/events/dwc3/dwc3_readl/enable
>> >> # echo 0 > /t/events/dwc3/dwc3_writel/enable
>> >>
>> >> This should be enough to tell me what's really going on.
>> >
>> > I've attached the (compressed due to size) dmesgs/traces from the device.
>> > For my test I just did 'for i in `seq 1 5` ; dmesg ; done' in an ssh
>> > session, and I did get the lag in the bad run, so presumably the trace
>> > should have caught it. Both were on 4.8 (+ the revert for the good run).
>> >
>> > Host side dmesg just showes me:
>> > usb 3-3.4: new high-speed USB device number 25 using xhci_hcd
>> > cdc_ether 3-3.4:1.0 usb0: register 'cdc_ether' at usb-:00:14.0-3.4,
>> > CDC Ethernet Device, ...
>> > when I boot the device. Nothing extra appears when things lag around.
>> > I'm running 4.5.something on the host.
>>
>> Looking at your logs what I can see is that "revert.trace" doesn't
>> respect gadget driver's IRQ throttling, which means you get an interrupt
>> for each and every request, while "bad.trace" shows dwc3 respecting
>> "no_interrupt" flag passed in by g_ether.
>>
>> The only explanation I have for this behavior when we start respecting
>> gadget driver's flags, is that there's a possible race in u_ether.c
>> where it can go for a long time without an interrupt due to that
>> throttling.
>>
>> This only happens with IN endpoints (the ones which are throttled) and
>> the behavior can be seen in log snippet below:
>>
>> 27782: irq/17-dwc3-2524 [000] d... 666.891969: tx_complete: req
>> 88016da1a6c0 length 1514/1514 flags ZsI tx_qlen 4 qmult 5
>> 27802: ksoftirqd/0-3 [000] .Ns1 666.892047: eth_start_xmit: req
>> 88016da1a6c0 length 0/1514 flags Zsi tx_qlen 5 qmult 5
>> 27808: ksoftirqd/0-3 [000] .Ns2 666.892062: eth_start_xmit: req
>> 88016da1a300 length 0/1514 flags ZsI tx_qlen 6 qmult 5
>> 27814: ksoftirqd/0-3 [000] .Ns2 666.892069: eth_start_xmit: req
>> 88016da1ab40 length 0/1514 flags Zsi tx_qlen 7 qmult 5
>> 27820: ksoftirqd/0-3 [000] .Ns2 666.892075: eth_start_xmit: req
>> 88016da1acc0 length 0/1514 flags Zsi tx_qlen 8 qmult 5
>> 27826: ksoftirqd/0-3 [000] .Ns2 666.892082: eth_start_xmit: req
>> 88016da1ae40 length 0/1514 flags Zsi tx_qlen 9 qmult 5
>> 27832: ksoftirqd/0-3 [000] .Ns2 666.892088: eth_start_xmit: req
>> 88016da1a780 length 0/1514 flags Zsi tx_qlen 10 qmult 5
>> 27884: irq/17-dwc3-2524 [000] d... 666.892213: tx_complete: req
>> 88016da1a840 length 1514/1514 flags Zsi tx_qlen 9 qmult 5
>> 27889: irq/17-dwc3-2524 [000] d... 666.892215: tx_complete: req
>> 88016da1a600 length 1514/1514 flags Zsi tx_qlen 8 qmult 5
>> 27897:sshd-2684 [002] ..s1 666.892223: eth_start_xmit: req
>> 88016da1a840 length 0/1514 flags Zsi tx_qlen 9 qmult 5
>> 27898: irq/17-dwc3-2524 [000] d... 666.892223: tx_complete: req
>> 88016da1a180 length 1514/1514 flags Zsi tx_qlen 8 qmult 5
>> 27903: irq/17-dwc3-2524 [000] d... 666.892225: tx_complete: req
>> 88016da1a240 length 1514/1514 flags Zsi tx_qlen 7 qmult 5
>> 27910:sshd-2684 [002] ..s1 666.892230: eth_start_xmit: req
>> 88016da1a180 length 0/1514 flags Zsi tx_qlen 8 qmult 5
>> 27913: irq/17-dwc3-2524 [000] d... 666.892231: tx_complete: req
>> 88016da1a6c0 length 1514/1514 flags Zsi tx_qlen 7 qmult 5
>> 27920:sshd-2684 [002] ..s1 666.892236: eth_start_xmit: req
>> 88016da1a6c0 length 0/1514 flags Zsi tx_qlen 8 qmult 5
>> 27923: irq/17-dwc3-2524 [000] d... 666.892238: tx_complete: req
>> 88016da1a300 length 1514/1514 flags ZsI tx_qlen 7 qmult 5
>> 27928:sshd-2684 [002] ..s1 666.892242: eth_start_xmit: req
>> 88016da1a240 length 0/1514 flags Zsi tx_qlen 8 qmult 5
>> 27944:sshd-2684 [002] ..s1 666.892253: eth_start_xmit: req
>> 880
Re: [PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach
On Tue, Oct 04, 2016 at 11:18:03AM +0200, Kevin Hilman wrote: > Hi Greg, > > On Mon, Sep 5, 2016 at 10:00 PM, David Lechner wrote: > > Including mach/* is frowned upon in device drivers, so get rid of it. > > > > This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy > > driver. > > > > Signed-off-by: David Lechner > > Acked-by: Alan Stern > > Can you pick up this patch? > > Patches 2 & 3 from this series were picked up by Bin for musb, but > this one is still outstanding. It's not in my todo queue from what I can tell, so it would have to be resent and I can pick it up after 4.9-rc1 is out. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
On Tue, Oct 04, 2016 at 03:23:12PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Ville Syrjälä writes:
> > On Mon, Oct 03, 2016 at 07:08:43PM +0300, Felipe Balbi wrote:
> >>
> >> Hi,
> >>
> >> ville.syrj...@linux.intel.com writes:
> >> > From: Ville Syrjälä
> >> >
> >> > This reverts commit 55a0237f8f47957163125e20ee9260538c5c341c.
> >> >
> >> > commit 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for
> >> > LST bit") causes my BYT FFRD8 with g_ether to behave poorly. ssh/scp
> >> > is very sluggish and can even stall entirely. Revert cures it.
> >> >
> >> > Cc: Felipe Balbi
> >> > Cc: sta...@vger.kernel.org
> >> > Signed-off-by: Ville Syrjälä
> >>
> >> Reverting that commit is not the best idea. Let's start with the usual:
> >>
> >> - Kernel version
> >> - dmesg on both sides (host and device)
> >> - dwc3 tracepoints:
> >>
> >> # mkdir -p /t
> >> # mount -t tracefs none /t
> >> # echo 8192 > /t/buffer_size_kb
> >> # echo 1 > /t/events/dwc3/enable
> >> # echo 0 > /t/events/dwc3/dwc3_readl/enable
> >> # echo 0 > /t/events/dwc3/dwc3_writel/enable
> >>
> >> This should be enough to tell me what's really going on.
> >
> > I've attached the (compressed due to size) dmesgs/traces from the device.
> > For my test I just did 'for i in `seq 1 5` ; dmesg ; done' in an ssh
> > session, and I did get the lag in the bad run, so presumably the trace
> > should have caught it. Both were on 4.8 (+ the revert for the good run).
> >
> > Host side dmesg just showes me:
> > usb 3-3.4: new high-speed USB device number 25 using xhci_hcd
> > cdc_ether 3-3.4:1.0 usb0: register 'cdc_ether' at usb-:00:14.0-3.4,
> > CDC Ethernet Device, ...
> > when I boot the device. Nothing extra appears when things lag around.
> > I'm running 4.5.something on the host.
>
> Looking at your logs what I can see is that "revert.trace" doesn't
> respect gadget driver's IRQ throttling, which means you get an interrupt
> for each and every request, while "bad.trace" shows dwc3 respecting
> "no_interrupt" flag passed in by g_ether.
>
> The only explanation I have for this behavior when we start respecting
> gadget driver's flags, is that there's a possible race in u_ether.c
> where it can go for a long time without an interrupt due to that
> throttling.
>
> This only happens with IN endpoints (the ones which are throttled) and
> the behavior can be seen in log snippet below:
>
> 27782: irq/17-dwc3-2524 [000] d... 666.891969: tx_complete: req
> 88016da1a6c0 length 1514/1514 flags ZsI tx_qlen 4 qmult 5
> 27802: ksoftirqd/0-3 [000] .Ns1 666.892047: eth_start_xmit: req
> 88016da1a6c0 length 0/1514 flags Zsi tx_qlen 5 qmult 5
> 27808: ksoftirqd/0-3 [000] .Ns2 666.892062: eth_start_xmit: req
> 88016da1a300 length 0/1514 flags ZsI tx_qlen 6 qmult 5
> 27814: ksoftirqd/0-3 [000] .Ns2 666.892069: eth_start_xmit: req
> 88016da1ab40 length 0/1514 flags Zsi tx_qlen 7 qmult 5
> 27820: ksoftirqd/0-3 [000] .Ns2 666.892075: eth_start_xmit: req
> 88016da1acc0 length 0/1514 flags Zsi tx_qlen 8 qmult 5
> 27826: ksoftirqd/0-3 [000] .Ns2 666.892082: eth_start_xmit: req
> 88016da1ae40 length 0/1514 flags Zsi tx_qlen 9 qmult 5
> 27832: ksoftirqd/0-3 [000] .Ns2 666.892088: eth_start_xmit: req
> 88016da1a780 length 0/1514 flags Zsi tx_qlen 10 qmult 5
> 27884: irq/17-dwc3-2524 [000] d... 666.892213: tx_complete: req
> 88016da1a840 length 1514/1514 flags Zsi tx_qlen 9 qmult 5
> 27889: irq/17-dwc3-2524 [000] d... 666.892215: tx_complete: req
> 88016da1a600 length 1514/1514 flags Zsi tx_qlen 8 qmult 5
> 27897:sshd-2684 [002] ..s1 666.892223: eth_start_xmit: req
> 88016da1a840 length 0/1514 flags Zsi tx_qlen 9 qmult 5
> 27898: irq/17-dwc3-2524 [000] d... 666.892223: tx_complete: req
> 88016da1a180 length 1514/1514 flags Zsi tx_qlen 8 qmult 5
> 27903: irq/17-dwc3-2524 [000] d... 666.892225: tx_complete: req
> 88016da1a240 length 1514/1514 flags Zsi tx_qlen 7 qmult 5
> 27910:sshd-2684 [002] ..s1 666.892230: eth_start_xmit: req
> 88016da1a180 length 0/1514 flags Zsi tx_qlen 8 qmult 5
> 27913: irq/17-dwc3-2524 [000] d... 666.892231: tx_complete: req
> 88016da1a6c0 length 1514/1514 flags Zsi tx_qlen 7 qmult 5
> 27920:sshd-2684 [002] ..s1 666.892236: eth_start_xmit: req
> 88016da1a6c0 length 0/1514 flags Zsi tx_qlen 8 qmult 5
> 27923: irq/17-dwc3-2524 [000] d... 666.892238: tx_complete: req
> 88016da1a300 length 1514/1514 flags ZsI tx_qlen 7 qmult 5
> 27928:sshd-2684 [002] ..s1 666.892242: eth_start_xmit: req
> 88016da1a240 length 0/1514 flags Zsi tx_qlen 8 qmult 5
> 27944:sshd-2684 [002] ..s1 666.892253: eth_start_xmit: req
> 88016da1a300 length 0/1514 flags Zsi tx_qlen 9 qmult 5
> 27953:sshd-2684 [002] ..s1 666.892262: eth_start_xmit: re
Re: [PATCH] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
Hi,
Ville Syrjälä writes:
> On Mon, Oct 03, 2016 at 07:08:43PM +0300, Felipe Balbi wrote:
>>
>> Hi,
>>
>> ville.syrj...@linux.intel.com writes:
>> > From: Ville Syrjälä
>> >
>> > This reverts commit 55a0237f8f47957163125e20ee9260538c5c341c.
>> >
>> > commit 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for
>> > LST bit") causes my BYT FFRD8 with g_ether to behave poorly. ssh/scp
>> > is very sluggish and can even stall entirely. Revert cures it.
>> >
>> > Cc: Felipe Balbi
>> > Cc: sta...@vger.kernel.org
>> > Signed-off-by: Ville Syrjälä
>>
>> Reverting that commit is not the best idea. Let's start with the usual:
>>
>> - Kernel version
>> - dmesg on both sides (host and device)
>> - dwc3 tracepoints:
>>
>> # mkdir -p /t
>> # mount -t tracefs none /t
>> # echo 8192 > /t/buffer_size_kb
>> # echo 1 > /t/events/dwc3/enable
>> # echo 0 > /t/events/dwc3/dwc3_readl/enable
>> # echo 0 > /t/events/dwc3/dwc3_writel/enable
>>
>> This should be enough to tell me what's really going on.
>
> I've attached the (compressed due to size) dmesgs/traces from the device.
> For my test I just did 'for i in `seq 1 5` ; dmesg ; done' in an ssh
> session, and I did get the lag in the bad run, so presumably the trace
> should have caught it. Both were on 4.8 (+ the revert for the good run).
>
> Host side dmesg just showes me:
> usb 3-3.4: new high-speed USB device number 25 using xhci_hcd
> cdc_ether 3-3.4:1.0 usb0: register 'cdc_ether' at usb-:00:14.0-3.4, CDC
> Ethernet Device, ...
> when I boot the device. Nothing extra appears when things lag around.
> I'm running 4.5.something on the host.
Looking at your logs what I can see is that "revert.trace" doesn't
respect gadget driver's IRQ throttling, which means you get an interrupt
for each and every request, while "bad.trace" shows dwc3 respecting
"no_interrupt" flag passed in by g_ether.
The only explanation I have for this behavior when we start respecting
gadget driver's flags, is that there's a possible race in u_ether.c
where it can go for a long time without an interrupt due to that
throttling.
This only happens with IN endpoints (the ones which are throttled) and
the behavior can be seen in log snippet below:
27782: irq/17-dwc3-2524 [000] d... 666.891969: tx_complete: req
88016da1a6c0 length 1514/1514 flags ZsI tx_qlen 4 qmult 5
27802: ksoftirqd/0-3 [000] .Ns1 666.892047: eth_start_xmit: req
88016da1a6c0 length 0/1514 flags Zsi tx_qlen 5 qmult 5
27808: ksoftirqd/0-3 [000] .Ns2 666.892062: eth_start_xmit: req
88016da1a300 length 0/1514 flags ZsI tx_qlen 6 qmult 5
27814: ksoftirqd/0-3 [000] .Ns2 666.892069: eth_start_xmit: req
88016da1ab40 length 0/1514 flags Zsi tx_qlen 7 qmult 5
27820: ksoftirqd/0-3 [000] .Ns2 666.892075: eth_start_xmit: req
88016da1acc0 length 0/1514 flags Zsi tx_qlen 8 qmult 5
27826: ksoftirqd/0-3 [000] .Ns2 666.892082: eth_start_xmit: req
88016da1ae40 length 0/1514 flags Zsi tx_qlen 9 qmult 5
27832: ksoftirqd/0-3 [000] .Ns2 666.892088: eth_start_xmit: req
88016da1a780 length 0/1514 flags Zsi tx_qlen 10 qmult 5
27884: irq/17-dwc3-2524 [000] d... 666.892213: tx_complete: req
88016da1a840 length 1514/1514 flags Zsi tx_qlen 9 qmult 5
27889: irq/17-dwc3-2524 [000] d... 666.892215: tx_complete: req
88016da1a600 length 1514/1514 flags Zsi tx_qlen 8 qmult 5
27897:sshd-2684 [002] ..s1 666.892223: eth_start_xmit: req
88016da1a840 length 0/1514 flags Zsi tx_qlen 9 qmult 5
27898: irq/17-dwc3-2524 [000] d... 666.892223: tx_complete: req
88016da1a180 length 1514/1514 flags Zsi tx_qlen 8 qmult 5
27903: irq/17-dwc3-2524 [000] d... 666.892225: tx_complete: req
88016da1a240 length 1514/1514 flags Zsi tx_qlen 7 qmult 5
27910:sshd-2684 [002] ..s1 666.892230: eth_start_xmit: req
88016da1a180 length 0/1514 flags Zsi tx_qlen 8 qmult 5
27913: irq/17-dwc3-2524 [000] d... 666.892231: tx_complete: req
88016da1a6c0 length 1514/1514 flags Zsi tx_qlen 7 qmult 5
27920:sshd-2684 [002] ..s1 666.892236: eth_start_xmit: req
88016da1a6c0 length 0/1514 flags Zsi tx_qlen 8 qmult 5
27923: irq/17-dwc3-2524 [000] d... 666.892238: tx_complete: req
88016da1a300 length 1514/1514 flags ZsI tx_qlen 7 qmult 5
27928:sshd-2684 [002] ..s1 666.892242: eth_start_xmit: req
88016da1a240 length 0/1514 flags Zsi tx_qlen 8 qmult 5
27944:sshd-2684 [002] ..s1 666.892253: eth_start_xmit: req
88016da1a300 length 0/1514 flags Zsi tx_qlen 9 qmult 5
27953:sshd-2684 [002] ..s1 666.892262: eth_start_xmit: req
88016da1a600 length 0/1514 flags Zsi tx_qlen 10 qmult 5
Note here that we reached tx_qlen = 10 without any interrupts being requested.
I patched u_ether with below to capture log above:
diff --git a/drivers/usb/gadget/function/u_ether.c
b/drivers/
Re: [PATCH v6 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
On Sat, Sep 24, 2016 at 12:50 AM, Martyn Welch
wrote:
> This patch adds support for the GPIO found on the CP2105.
> This device supports either push-pull or open-drain modes, it doesn't
> provide an explicit input mode, though the state of the GPIO can be read
> when used in open-drain mode. Like with pin use, the mode is configured in
> the one-time programable PROM and can't be changed at runtime.
I see.
So implement .direction_input() and .direction_output()
anyways.
Return failure on .direction_input() if it is in push-pull mode.
Return success on all .direction_output() calls.
Then implement .set_single_ended() and return success for open drain
if the is in open drain, success for push-pull if the line is in push-pull
mode, and failure in all other cases. Simple, but correct.
Add some comments to these functions so it is clear what is going on.
(...)
> +#ifdef CONFIG_GPIOLIB
> +static int cp210x_gpio_request(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
Just:
struct cp210x_serial_private *priv = gpiochip_get_data(gc);
> +static int cp210x_gpio_direction_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + return 0;
> +}
Aha no explicit input mode...
> +static int cp210x_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
gpiochip_get_data
> + struct usb_serial *serial = priv->serial;
> + int result;
> + u8 buf;
> +
> + result = cp210x_read_vendor_block(serial, REQTYPE_INTERFACE_TO_HOST,
> + CP210X_READ_LATCH, &buf,
> sizeof(buf));
> + if (result < 0)
> + return 0;
No just return the error code. We handle this nowadays.
> +
> + return (buf >> gpio) & 0x1;
Do it like this:
return !!(buf & BIT(gpio));
> +static void cp210x_gpio_set(struct gpio_chip *gc, unsigned int gpio, int
> value)
> +{
> + struct cp210x_serial_private *priv =
> + container_of(gc, struct cp210x_serial_private, gc);
gpiochip_get_data()
(...)
+ result = gpiochip_add(&priv->gc);
Use devm_gpiochip_add_data(&serial->interface->dev, &priv->gc, gc);
And you get the pointer you need.
+void cp210x_shared_gpio_remove(struct usb_serial *serial)
+{
+ struct cp210x_serial_private *priv = usb_get_serial_data(serial);
+
+ if (priv->gc.label)
+ gpiochip_remove(&priv->gc);
+}
Should not be needed with the devm_* call above doing garbage collection.
Yours,
Linus Walleij
--
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: DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422
Hi Michael, On Tue, Oct 4, 2016 at 4:28 PM, Michael Niewöhner wrote: > > > > > > [1.] One line summary of the problem: > > > > > > DWC3 USB 3.0 not working on Odroid-XU4 with Exynos 5422 > > > > > > > > > > > > [2.] Full description of the problem/report: > > > > > > No usb 3.0 devices are being detected when attached while USB 2.0 > > > > > > devices work on the same port. > > > > > > USB 3.0 works after applying patches [9.1] and [9.2], but seems > > > > > > to be > > > > > > buggy. The usb hub is redetected every time an usb device is > > > > > > attached. [snip] >> > > > > > [9.] Other notes, patches, fixes, workarounds: >> > > > > > [9.1] https://lkml.org/lkml/2014/4/28/234 >> > > > > > [9.2] https://lkml.org/lkml/2015/2/2/259 >> >> These patches are required to get USB super-speed working on Exynos5420/5800. >> But they did not make to upstream. There was resistance on adding new >> phy_calibrate() >> callback. >> >> Without these patches the Exynos5420/5800 will enumerate all >> super-speed capable devices >> as high-speed devices. >> Last time we checked with exynos542x smdk boards and peach-* boards, >> we could get the >> Super - speed devices working. I have not tested odroid anytime so >> don't have much idea about the >> its intricacies. >> I guess Anand was able to use these patches to get his kernel working in >> past. > > > The patches don't work anymore with 4.8-rc* / 4.8. They worked - but very > unstable - with 4.7. > > One more problem appeared since one of the 4.8-RCs: reboot hangs when the dwc3 > module is loaded. If I unload it before reboot / shutdown everything is fine. > > >> >> When you have a downstream on-board usb hub, ideally it should be able >> to detect the devices >> and not reset everytime you connect a new device (like you mentioned >> earlier). >> There can be two possible reasons why the hub keeps getting reset ever >> after applying the above >> mentioned patches: >> 1) the clock rates are not proper. >> 2) the regulator load setting is not enough to drive the hub. >> >> Anand, can you please point Michael to an older kernel with which you >> could test usb on odroid successfully ? >> You can compare the clocks with an older version and see if there'a >> any difference. >> >> Any possibility of any other framework (such as, bus-freq) trimming >> down the clock - rates ? > > > > # v4.7.5 > > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > sclk_usbh20_scan_clk 00 48000 > 0 > sclk_usbh20 0048000 > 000 0 > mout_usbd300 112400 > 0 >dout_usbd300 002400 > 0 > sclk_usbd300 > 002400 0 >dout_usbphy300 112400 > 0 > sclk_usbphy300 4424000 > 000 0 > mout_usbd301 112400 > 0 >dout_usbd301 002400 > 0 > sclk_usbd301 > 002400 0 >dout_usbphy301 112400 > 0 > sclk_usbphy301 3324000 > 000 0 > usbd301 11 1 > usbd300 11 1 > > usbh20 33 1 0 > > > # v4.8.0 > > > $ cat /sys/kernel/debug/clk/clk_summary | grep usb > sclk_usbh20_scan_clk 00 48000 > 0 > sclk_usbh20 004800 > 0 > mout_usbd300 112400 > 0 >dout_usbd300 002400 > 0 > sclk_usbd300 > 002400 0 >dout_usbphy300 112400 > 0 > sclk_usbphy300 442400 > 0 > mout_usbd301 112400 > 0 >dout_usbd301 002400 > 0 > sclk_usbd301 > 002400 0 >dout_usbphy301 112400 > 0 > sclk_usbphy301 332400 > 0 > usbd301 11 1 This clock should have been 200MHz. > usbd300 1
Re: USB hot-plug not working (ASUS TP301UA-C4028T)
On 03.10.2016 23:54, Pierre de Villemereuil wrote: Hi Mathias, Just to know: does that mean the firmware from Asus is faulty in here? Do you think I should contact Asus about this? Probably, _S0W, _DSM and XFLT code for xHCI are useless in that ACPI DSDT firmware version. But we still want the driver to handle cases like this. Just wrote the patch. Adding Alan Stern to CC for PM sanity feedback on it: --- Author: Mathias Nyman Date: Tue Oct 4 13:07:59 2016 +0300 xhci: Prevent a non-responsive xhci suspend state. ACPI may limit the lowest possible runtime suspend PCI D-state to D0. If xHC is not capable of generating PME# events in D0 we end up with a non-responsive runtime suspended host without PME# capability and with interrupts disabled, unable to detect or wake up when a new usb device is connected. This was triggered on a ASUS TP301UA machine. Reported-by: Pierre de Villemereuil Signed-off-by: Mathias Nyman diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index d7b0f97..08b021c 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -396,6 +396,11 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup) if (xhci->quirks & XHCI_SSIC_PORT_UNUSED) xhci_ssic_port_unused_quirk(hcd, true); + /* Prevent a non-responsive PCI D0 state without PME# wake capability */ + if (pci_choose_state(pdev, PMSG_AUTO_SUSPEND) == PCI_D0) + if (!pci_pme_capable(pdev, PCI_D0)) + return -EBUSY; + ret = xhci_suspend(xhci, do_wakeup); if (ret && (xhci->quirks & XHCI_SSIC_PORT_UNUSED)) xhci_ssic_port_unused_quirk(hcd, false); -- 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] phy: nop: Add a new phy driver for No-Op transceiver
No-Op phy transceiver can be used on platforms that have
controllers which themselves provide PHY functionality and
there's no separate PHY controller available.
This driver provides a basic skeleton for a nop-phy driver.
This can be further extended to add required features.
Inspired by phy-generic driver in drivers/usb/phy.
Signed-off-by: Vivek Gautam
Cc: Kishon Vijay Abraham I
Cc: Felipe Balbi
---
Hi Kishon, Felipe,
This patch has been lying in my tree for sometime.
This introduces a skeletal nop-phy driver based on generic
phy framework.
I mainly use this driver when I have only one phy driver available
for testing for a controller that uses more than one phy.
But this can be further extended to add any feature support for
controllers that don't have a separate PHY controller and that
themselves provide the PHY functionality, a purpose similar
to what drivers/usb/phy/phy-generic.c driver serves.
Do you think we have a requirement for such a driver in the generic
phy layer? I hope this driver can do some good.
Let me know your comments on this.
Thanks
Vivek
Documentation/devicetree/bindings/phy/phy-nop.txt | 22 +++
drivers/phy/Kconfig | 10 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-nop.c | 193 ++
4 files changed, 226 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-nop.txt
create mode 100644 drivers/phy/phy-nop.c
diff --git a/Documentation/devicetree/bindings/phy/phy-nop.txt
b/Documentation/devicetree/bindings/phy/phy-nop.txt
new file mode 100644
index 000..6cb6779
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-nop.txt
@@ -0,0 +1,22 @@
+Generic No-Op PHY
+-
+
+Required properties:
+ - compatible: compatible list, contains "phy-nop".
+ - #phy-cells: must be 0.
+
+Optional properties:
+ - clocks: a list of phandles and clock-specifier pairs,
+ one for each entry in clock-names.
+ - clock-names: must be "main_clk" for phy core clock,
+ "ref_clk" for phy reference clk.
+ - resets: a list of phandles and reset controller specifier pairs,
+ one for each entry in reset-names.
+ - reset-names: must be"phy" for reset of phy block.
+ - vdd-supply: Phandle to a regulator supply to PHY core block.
+
+Example:
+ phy_nop: phy_nop {
+ compatible = "phy-nop";
+ #phy-cells = <0>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index fe00f91..1923c4f 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -489,4 +489,14 @@ config PHY_NS2_PCIE
help
Enable this to support the Broadcom Northstar2 PCIe PHY.
If unsure, say N.
+
+config PHY_NOP
+ tristate "No-Operation PHY transceiver driver"
+ depends on OF || COMPILE_TEST
+ select GENERIC_PHY
+ help
+ Enable this to support the generic no-operation PHY
+ transeiver. This driver can be used with consumers
+ requiring a no-op phy for few of the handlers.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index a534cf5..d6e0e60 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_PHY_PISTACHIO_USB) +=
phy-pistachio-usb.o
obj-$(CONFIG_PHY_CYGNUS_PCIE) += phy-bcm-cygnus-pcie.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
+obj-$(CONFIG_PHY_NOP) += phy-nop.o
diff --git a/drivers/phy/phy-nop.c b/drivers/phy/phy-nop.c
new file mode 100644
index 000..cab01a1
--- /dev/null
+++ b/drivers/phy/phy-nop.c
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct phy_nop:- structure holding NOP PHY attributes.
+ *
+ * @dev: pointer to device.
+ * @phy: pointer to generic phy.
+ * @clk: pointer to phy clock.
+ * @refclk: pointer to phy reference clock.
+ * @vdd: vdd supply to the phy core block.
+ * @rst: pointer to reset controller for the phy block.
+ */
+struct phy_nop {
+ struct device *dev;
+ struct phy *phy;
+ struct clk *clk;
+ struct clk *refclk;
+ struct regulator *vdd;
+ struct reset_control *rst;
+};
+
+static int phy_nop_poweron(struct phy *generic_phy)
+{
+ struct phy_nop *phy = phy_get_drvdata(generic_phy);
+ int ret = 0;
+
+
Re: [PATCH v6 1/3] usb: ohci-da8xx: Remove code that references mach
Hi Greg,
On Mon, Sep 5, 2016 at 10:00 PM, David Lechner wrote:
> Including mach/* is frowned upon in device drivers, so get rid of it.
>
> This replaces usb20_clk and code that pokes CFGCHIP2 with a proper phy
> driver.
>
> Signed-off-by: David Lechner
> Acked-by: Alan Stern
Can you pick up this patch?
Patches 2 & 3 from this series were picked up by Bin for musb, but
this one is still outstanding.
Thanks,
Kevin
> ---
> drivers/usb/host/Kconfig | 1 +
> drivers/usb/host/ohci-da8xx.c | 102
> +++---
> 2 files changed, 56 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 2e710a4..1f0cdab8 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -482,6 +482,7 @@ config USB_OHCI_HCD_DAVINCI
> bool "OHCI support for TI DaVinci DA8xx"
> depends on ARCH_DAVINCI_DA8XX
> depends on USB_OHCI_HCD=y
> + select PHY_DA8XX_USB
> default y
> help
> Enables support for the DaVinci DA8xx integrated OHCI
> diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
> index e5c33bc..3656d7c 100644
> --- a/drivers/usb/host/ohci-da8xx.c
> +++ b/drivers/usb/host/ohci-da8xx.c
> @@ -15,58 +15,50 @@
> #include
> #include
> #include
> -
> -#include
> +#include
> #include
>
> #ifndef CONFIG_ARCH_DAVINCI_DA8XX
> #error "This file is DA8xx bus glue. Define CONFIG_ARCH_DAVINCI_DA8XX."
> #endif
>
> -#define CFGCHIP2 DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG)
> -
> static struct clk *usb11_clk;
> -static struct clk *usb20_clk;
> +static struct phy *usb11_phy;
>
> /* Over-current indicator change bitmask */
> static volatile u16 ocic_mask;
>
> -static void ohci_da8xx_clock(int on)
> +static int ohci_da8xx_enable(void)
> {
> - u32 cfgchip2;
> -
> - cfgchip2 = __raw_readl(CFGCHIP2);
> - if (on) {
> - clk_enable(usb11_clk);
> -
> - /*
> -* If USB 1.1 reference clock is sourced from USB 2.0 PHY, we
> -* need to enable the USB 2.0 module clocking, start its PHY,
> -* and not allow it to stop the clock during USB 2.0 suspend.
> -*/
> - if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX)) {
> - clk_enable(usb20_clk);
> -
> - cfgchip2 &= ~(CFGCHIP2_RESET | CFGCHIP2_PHYPWRDN);
> - cfgchip2 |= CFGCHIP2_PHY_PLLON;
> - __raw_writel(cfgchip2, CFGCHIP2);
> -
> - pr_info("Waiting for USB PHY clock good...\n");
> - while (!(__raw_readl(CFGCHIP2) & CFGCHIP2_PHYCLKGD))
> - cpu_relax();
> - }
> + int ret;
>
> - /* Enable USB 1.1 PHY */
> - cfgchip2 |= CFGCHIP2_USB1SUSPENDM;
> - } else {
> - clk_disable(usb11_clk);
> - if (!(cfgchip2 & CFGCHIP2_USB1PHYCLKMUX))
> - clk_disable(usb20_clk);
> + ret = clk_prepare_enable(usb11_clk);
> + if (ret)
> + return ret;
>
> - /* Disable USB 1.1 PHY */
> - cfgchip2 &= ~CFGCHIP2_USB1SUSPENDM;
> - }
> - __raw_writel(cfgchip2, CFGCHIP2);
> + ret = phy_init(usb11_phy);
> + if (ret)
> + goto err_phy_init;
> +
> + ret = phy_power_on(usb11_phy);
> + if (ret)
> + goto err_phy_power_on;
> +
> + return 0;
> +
> +err_phy_power_on:
> + phy_exit(usb11_phy);
> +err_phy_init:
> + clk_disable_unprepare(usb11_clk);
> +
> + return ret;
> +}
> +
> +static void ohci_da8xx_disable(void)
> +{
> + phy_power_off(usb11_phy);
> + phy_exit(usb11_phy);
> + clk_disable_unprepare(usb11_clk);
> }
>
> /*
> @@ -92,7 +84,9 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
>
> dev_dbg(dev, "starting USB controller\n");
>
> - ohci_da8xx_clock(1);
> + result = ohci_da8xx_enable();
> + if (result < 0)
> + return result;
>
> /*
> * DA8xx only have 1 port connected to the pins but the HC root hub
> @@ -101,8 +95,10 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
> ohci->num_ports = 1;
>
> result = ohci_init(ohci);
> - if (result < 0)
> + if (result < 0) {
> + ohci_da8xx_disable();
> return result;
> + }
>
> /*
> * Since we're providing a board-specific root hub port power control
> @@ -129,7 +125,7 @@ static int ohci_da8xx_init(struct usb_hcd *hcd)
> static void ohci_da8xx_stop(struct usb_hcd *hcd)
> {
> ohci_stop(hcd);
> - ohci_da8xx_clock(0);
> + ohci_da8xx_disable();
> }
>
> static int ohci_da8xx_start(struct usb_hcd *hcd)
> @@ -301,12 +297,18 @@ static int usb_hcd_da8xx_probe(const struct hc_driver
> *driver,
> return -ENODEV;
>
[RESEND PATCH v3 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically
When system has stpped the gadget, we should avoid queuing any requests which will cause tranfer failed. Thus adding some disconnect checking to avoid this situation. Signed-off-by: Baolin Wang --- Changes since v2: - Move disconnect checking into dwc3_send_gadget_ep_cmd(). - Rename completion name and issue complete() at one place. - Move completion initialization into dwc3_gadget_init(). Changes since v1: - Split into 2 separate ptaches. - Choose complete mechanism instead of polling. --- drivers/usb/dwc3/gadget.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 1783406..ca2ae5b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -241,6 +241,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned cmd, int susphy = false; int ret = -EINVAL; + if (!dwc->pullups_connected) + return -ESHUTDOWN; + /* * Synopsys Databook 2.60a states, on section 6.3.2.5.[1-8], that if * we're issuing an endpoint command, we must check if -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v3 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget
When we change the USB function with configfs dynamically, we possibly met this
situation: one core is doing the control transfer, another core is trying to
unregister the USB gadget from userspace, we must wait for completing this
control tranfer, or it will hang the controller to set the DEVCTRLHLT flag.
Signed-off-by: Baolin Wang
---
drivers/usb/dwc3/core.h |2 ++
drivers/usb/dwc3/ep0.c|2 ++
drivers/usb/dwc3/gadget.c | 23 +++
3 files changed, 27 insertions(+)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b2317e7..9128725 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -745,6 +745,7 @@ struct dwc3_scratchpad_array {
* @ep0_usb_req: dummy req used while handling STD USB requests
* @ep0_bounce_addr: dma address of ep0_bounce
* @scratch_addr: dma address of scratchbuf
+ * @ep0_in_setup: One control transfer is completed and enter setup phase
* @lock: for synchronizing
* @dev: pointer to our struct device
* @xhci: pointer to our xHCI child
@@ -843,6 +844,7 @@ struct dwc3 {
dma_addr_t ep0_bounce_addr;
dma_addr_t scratch_addr;
struct dwc3_request ep0_usb_req;
+ struct completion ep0_in_setup;
/* device lock */
spinlock_t lock;
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index fe79d77..06c167a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -311,6 +311,8 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret < 0);
+
+ complete(&dwc->ep0_in_setup);
}
static struct dwc3_ep *dwc3_wIndex_to_dep(struct dwc3 *dwc, __le16 wIndex_le)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index ca2ae5b..fef023a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1437,6 +1437,15 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
if (pm_runtime_suspended(dwc->dev))
return 0;
+ /*
+* Per databook, when we want to stop the gadget, if a control transfer
+* is still in process, complete it and get the core into setup phase.
+*/
+ if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
+ reinit_completion(&dwc->ep0_in_setup);
+ return -EBUSY;
+ }
+
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
if (is_on) {
if (dwc->revision <= DWC3_REVISION_187A) {
@@ -1487,10 +1496,22 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int
is_on)
is_on = !!is_on;
+try_again:
spin_lock_irqsave(&dwc->lock, flags);
ret = dwc3_gadget_run_stop(dwc, is_on, false);
spin_unlock_irqrestore(&dwc->lock, flags);
+ if (ret == -EBUSY) {
+ ret = wait_for_completion_timeout(&dwc->ep0_in_setup,
+ msecs_to_jiffies(500));
+ if (ret == 0) {
+ dev_err(dwc->dev, "timeout to stop gadget.\n");
+ ret = -ETIMEDOUT;
+ } else {
+ goto try_again;
+ }
+ }
+
return ret;
}
@@ -2914,6 +2935,8 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err4;
}
+ init_completion(&dwc->ep0_in_setup);
+
dwc->gadget.ops = &dwc3_gadget_ops;
dwc->gadget.speed = USB_SPEED_UNKNOWN;
dwc->gadget.sg_supported= true;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB will randomly stop working
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Mon, Oct 03, 2016 at 01:48:55PM -0700, Ashton Holmes wrote: > Coming from the kernel? No there's no kernel lines right before that > that have to do with USB. The kernel line before that is: Oct 2 > 22:21:45 user-desktop kernel: [ 38.122133] Bluetooth: BNEP socket > layer initialized. And that's quite a ways up in the file. Are you sure? Any other messages might help out here. > Also my knowledge of git isn't that extensive and I got the source > from the download on the site not from the git repo so it tells me > there's no .git file but if I can figure out how to run that I'll give > it a go. You can pull Linus's tree from git.kernel.org by doing: git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git and using your .config in that tree. There is lots of documentation of how to use 'git bisect' but if you have any questions, please let us know. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "usb: dwc3: gadget: use allocated/queued reqs for LST bit"
Hi again,
Felipe Balbi writes:
> ville.syrj...@linux.intel.com writes:
>> From: Ville Syrjälä
>>
>> This reverts commit 55a0237f8f47957163125e20ee9260538c5c341c.
>>
>> commit 55a0237f8f47 ("usb: dwc3: gadget: use allocated/queued reqs for
>> LST bit") causes my BYT FFRD8 with g_ether to behave poorly. ssh/scp
>> is very sluggish and can even stall entirely. Revert cures it.
>>
>> Cc: Felipe Balbi
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Ville Syrjälä
>
> Reverting that commit is not the best idea. Let's start with the usual:
>
> - Kernel version
> - dmesg on both sides (host and device)
> - dwc3 tracepoints:
>
> # mkdir -p /t
> # mount -t tracefs none /t
> # echo 8192 > /t/buffer_size_kb
> # echo 1 > /t/events/dwc3/enable
> # echo 0 > /t/events/dwc3/dwc3_readl/enable
> # echo 0 > /t/events/dwc3/dwc3_writel/enable
>
> This should be enough to tell me what's really going on.
I have been trying this with SKL running v4.8 vanilla and a laptop
running v4.7.1 from Debian and I can't reproduce it.
The only time when I sort of reproduced was when Network Manager on the
laptop side decided to "reconfigure" the interface after I had ifconfig
foobar 192.168.0.2, so the interface ended up loosing the IP.
I have since configured that interface for static IP and it has been
running for a while without any problems. FYI I sshed from laptop to SKL
and have 'while true; do dmesg; done' running and in another terminal
I'm pinging SKL from laptop.
I'll keep it running for a while longer. Drop by once you're in the
office and I can check what's going on with your device.
cheers
--
balbi
signature.asc
Description: PGP signature
[PATCH v2] ARM64: dts: meson-gxbb-odroidc2: Enable USB Nodes
Enable both gxbb USB controller and add a 5V regulator for the OTG port
VBUS
Signed-off-by: Brian Kim
---
This patch was written on Kevin Hilman's repository[1] and branch[2]:
[1] https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git
[2] v4.8/integ
Chnages since v1:
- rename the usb_pwr node to usb_otg_pwr
- rename the regulator-name "USB_PWR" to "USB_OTG_PWR"
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 29 ++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 8d89edc..bfacaf7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -64,6 +64,18 @@
reg = <0x0 0x0 0x0 0x8000>;
};
+ usb_otg_pwr: regulator-usb-pwrs {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB_OTG_PWR";
+
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+
+ gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
leds {
compatible = "gpio-leds";
blue {
@@ -149,6 +161,23 @@
pinctrl-names = "default";
};
+&usb0_phy {
+ status = "okay";
+ phy-supply = <&usb_otg_pwr>;
+};
+
+&usb1_phy {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
+
/* SD */
&sd_emmc_b {
status = "okay";
--
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
