[PATCH] USB: gadget: remove unused parameter from udc_stop in usb_gadget_ops
This patch removes parameter struct usb_gadget_driver* from udc_stop() function
in struct usb_gadget_ops. This parameter is useless in udc_stop() function, and
UDC drivers can work well without it, so removeing it makes code clearer.
This patch modifies UDC drivers to make them compatible witch changed API.
It also modifies udc-core.c, where udc_stop() function is used.
Signed-off-by: Robert Baldyga
Signed-off-by: Kyungmin Park
---
drivers/usb/chipidea/udc.c |6 ++
drivers/usb/dwc3/gadget.c |3 +--
drivers/usb/gadget/amd5536udc.c| 10 --
drivers/usb/gadget/at91_udc.c |6 ++
drivers/usb/gadget/atmel_usba_udc.c|6 ++
drivers/usb/gadget/bcm63xx_udc.c |3 +--
drivers/usb/gadget/dummy_hcd.c | 10 --
drivers/usb/gadget/fotg210-udc.c |3 +--
drivers/usb/gadget/fsl_qe_udc.c|8 +++-
drivers/usb/gadget/fsl_udc_core.c |6 ++
drivers/usb/gadget/fusb300_udc.c |3 +--
drivers/usb/gadget/goku_udc.c |6 ++
drivers/usb/gadget/lpc32xx_udc.c |8 ++--
drivers/usb/gadget/m66592-udc.c|3 +--
drivers/usb/gadget/mv_u3d_core.c |5 ++---
drivers/usb/gadget/mv_udc_core.c |7 +++
drivers/usb/gadget/net2272.c |8 +++-
drivers/usb/gadget/net2280.c |8 +++-
drivers/usb/gadget/omap_udc.c |6 ++
drivers/usb/gadget/pch_udc.c |6 ++
drivers/usb/gadget/pxa25x_udc.c|8 +++-
drivers/usb/gadget/pxa27x_udc.c|8 +++-
drivers/usb/gadget/r8a66597-udc.c |3 +--
drivers/usb/gadget/s3c-hsotg.c |6 ++
drivers/usb/gadget/s3c-hsudc.c |6 +-
drivers/usb/gadget/s3c2410_udc.c |6 ++
drivers/usb/gadget/udc-core.c | 10 --
drivers/usb/musb/musb_gadget.c |8 +++-
drivers/usb/renesas_usbhs/mod_gadget.c |3 +--
include/linux/usb/gadget.h |3 +--
30 files changed, 64 insertions(+), 118 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index b34c819..b9a09ad 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1527,8 +1527,7 @@ static int ci_udc_pullup(struct usb_gadget *_gadget, int
is_on)
static int ci_udc_start(struct usb_gadget *gadget,
struct usb_gadget_driver *driver);
-static int ci_udc_stop(struct usb_gadget *gadget,
- struct usb_gadget_driver *driver);
+static int ci_udc_stop(struct usb_gadget *gadget);
/**
* Device operations part of the API to the USB controller hardware,
* which don't involve endpoints (or i/o)
@@ -1658,8 +1657,7 @@ static int ci_udc_start(struct usb_gadget *gadget,
/**
* ci_udc_stop: unregister a gadget driver
*/
-static int ci_udc_stop(struct usb_gadget *gadget,
- struct usb_gadget_driver *driver)
+static int ci_udc_stop(struct usb_gadget *gadget)
{
struct ci_hdrc *ci = container_of(gadget, struct ci_hdrc, gadget);
unsigned long flags;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 5c0cb96..e33225a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1587,8 +1587,7 @@ err0:
return ret;
}
-static int dwc3_gadget_stop(struct usb_gadget *g,
- struct usb_gadget_driver *driver)
+static int dwc3_gadget_stop(struct usb_gadget *g)
{
struct dwc3 *dwc = gadget_to_dwc(g);
unsigned long flags;
diff --git a/drivers/usb/gadget/amd5536udc.c b/drivers/usb/gadget/amd5536udc.c
index f0ff4a6..c7bfa62 100644
--- a/drivers/usb/gadget/amd5536udc.c
+++ b/drivers/usb/gadget/amd5536udc.c
@@ -1402,8 +1402,7 @@ static int udc_wakeup(struct usb_gadget *gadget)
static int amd5536_udc_start(struct usb_gadget *g,
struct usb_gadget_driver *driver);
-static int amd5536_udc_stop(struct usb_gadget *g,
- struct usb_gadget_driver *driver);
+static int amd5536_udc_stop(struct usb_gadget *g);
/* gadget operations */
static const struct usb_gadget_ops udc_ops = {
.wakeup = udc_wakeup,
@@ -1944,7 +1943,7 @@ static int amd5536_udc_start(struct usb_gadget *g,
/* shutdown requests and disconnect from gadget */
static void
-shutdown(struct udc *dev, struct usb_gadget_driver *driver)
+shutdown(struct udc *dev)
__releases(dev->lock)
__acquires(dev->lock)
{
@@ -1960,8 +1959,7 @@ __acquires(dev->lock)
}
/* Called by gadget driver to unregister itself */
-static int amd5536_udc_stop(struct usb_gadget *g,
- struct usb_gadget_driver *driver)
+static int amd5536_udc_stop(struct usb_gadget *g)
{
struct udc *dev = to_amd5536_udc(g);
unsigned long flags;
@@ -1969,7 +1967,7 @@ static int amd5536_udc_stop(struct usb_gadget *g,
spin_lock_irqsave(&dev->lock, flags);
udc_mask_unused_
Re: "EHCI: BIOS handoff failed (BIOS bug?) 01010001" on Celeron N2805 (Bay Trail) / Gateway LT41P
Sebastien: Thanks for the info. I just tried Linux 3.13.0-0.rc3.git5.1.fc21.i686 (from Fedora rawhide) and I still get the same error messages and USB still doesn't work. I saw a post about Atom Z3740D (Bay Trail-T) in a Dell Venue 8 Pro, and his USB works OK (but seems to use the xhci_hcd driver : [1.842164] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.842326] ehci-pci: EHCI PCI platform driver [1.842470] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.842617] ohci-pci: OHCI PCI platform driver [1.843140] xhci_hcd :00:14.0: xHCI Host Controller [1.843363] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 1 [1.843964] xhci_hcd :00:14.0: cache line size of 64 is not supported [1.844006] xhci_hcd :00:14.0: irq 103 for MSI/MSI-X [1.844507] usb usb1: Product: xHCI Host Controller [1.844627] usb usb1: Manufacturer: Linux 3.13.0-0.rc2.git0.1.1.fc20.i686 xhci_hcd [1.846595] xhci_hcd :00:14.0: xHCI Host Controller [1.846816] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 [1.847423] usb usb2: Product: xHCI Host Controller [1.847555] usb usb2: Manufacturer: Linux 3.13.0-0.rc2.git0.1.1.fc20.i686 xhci_hcd [3.152500] usb 1-2: new high-speed USB device number 2 using xhci_hcd [3.456530] usb 1-2.1: new full-speed USB device number 3 using xhci_hcd [3.659527] usb 1-2.3: new low-speed USB device number 4 using xhci_hcd [3.870523] usb 1-2.4: new high-speed USB device number 5 using xhci_hcd Whereas my Gateway LT41P uses ehci & ohci : [ 65.497196] pci :00:1d.0: EHCI: BIOS handoff failed (BIOS bug?) 01010001 [ 67.083013] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 67.087660] ehci-pci: EHCI PCI platform driver [ 67.100338] ehci-pci :00:1d.0: EHCI Host Controller [ 67.107369] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 1 [ 67.112162] ehci-pci :00:1d.0: debug port 2 [ 67.120972] ehci-pci :00:1d.0: cache line size of 64 is not supported [ 67.121724] ehci-pci :00:1d.0: irq 23, io mem 0x90705000 [ 67.131786] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [ 67.148118] usb usb1: Product: EHCI Host Controller [ 67.152623] usb usb1: Manufacturer: Linux 3.13.0-0.rc3.git5.1.fc21.i686 ehci_hcd [ 67.193364] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 67.197795] ohci-pci: OHCI PCI platform driver [ 67.517839] usb 1-1: new high-speed USB device number 2 using ehci-pci [ 83.198813] usb 1-1: new high-speed USB device number 3 using ehci-pci [ 98.877636] usb 1-1: new high-speed USB device number 4 using ehci-pci [ 109.430911] usb 1-1: new high-speed USB device number 5 using ehci-pci A clue? A workaround ? On Mon, Dec 16, 2013 at 10:01 AM, Dufour, Sebastien wrote: > >> -Original Message- >> From: linux-usb-ow...@vger.kernel.org >> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Ken Harris >> >> I have a fabulous Gateway LT41P04u (w/ Insydeh20 BIOS v2.03) and a Celeron >> N2805 (Bay Trail) >> >> I managed to boot Fedora on it (a bit tricky since it has "Secure Boot" and >> the UEFI is 32 bit, but Fedora only has an EFI installer for >> 64 bit). >> >> Anyway... it does boot, but the USB does not work. >> >> I get messages like: >> >> [ 61.785031] pci :00:1d.0: EHCI: BIOS handoff failed (BIOS bug?) >> 01010001 >> [ 78.351714] usb 1-1: device not accepting address 2, error -110 >> [ 94.018631] usb 1-1: device not accepting address 3, error -110 >> >> Any ideas for work arounds or fixes ? I can supply additional debug info if >> that will help. >> >> I've attached the dmesg and lspci log. > >> Thanks, >> Ken > > Hello, > > I have the same handoff error message, but not the others. > I am using a 3.13-rc4 kernel on a Haswell ULT (lynx point). > My USB works ok in 2.0. hope this help to investigate. > > I googled it and I found that someone rized this commit id thanks to a bisect > research: > https://groups.google.com/a/lists.one-eyed-alien.net/forum/#!topic/usb-storage/280l89lzjik > > > seb > - > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 4,572,000 Euros > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > -- 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] xhci: fix array index out of the bounds in function last_trb() and last_trb_on_last_seg()
> From: Wang, Lin X
> David is right, this patch may lead to the last trb in an event ring
> unprocessed according to the
> current logic, you can reject this patch, although I think index
> out-of-bounds is reasonable.
>
> If applying this patch, then corresponding function(inc_deq()) should be
> modified, maybe like the
> following way:
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index d26cd94..0dbaa56 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -185,7 +185,7 @@ static void inc_deq(struct xhci_hcd *xhci, struct
> xhci_ring *ring)
> } else {
> ring->dequeue++;
> }
> - } while (last_trb(xhci, ring, ring->deq_seg, ring->dequeue));
> + } while (last_trb(xhci, ring, ring->deq_seg, ring->dequeue) &&
> ring->type != TYPE_EVENT);
There are far too many conditionals in this code already.
Adding an extra one that serves no purpose is silly.
The C language explicitly allows you to take the address of the first
item beyond the end of an array and to use that in expressions
involving pointers to other array members.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 5/9] usb: s3c-hsotg: Use the new Exynos USB phy driver with the generic phy framework
Hi Matt,
I am afraid it is not possible. This patch cannot go in without the
new phy driver. It would break Exynos USB functionality. This
is because it changes s3c-hsotg to use the new phy driver.
I am working on an updated patch series addressing all the comments.
time permitting I want to post an alternative version - integrating
as much as possible in a single file. This way it would be possible
to have a hands-on comparison of the two approaches we were
discussing with Kishon.
I estimate that I post it this week.
Best wishes,
--
Kamil Debski
Samsung R&D Institute Poland
> -Original Message-
> From: Matt Porter [mailto:mpor...@linaro.org]
> Sent: Monday, December 16, 2013 10:40 PM
> To: Kamil Debski
> Cc: linux-ker...@vger.kernel.org; linux-samsung-...@vger.kernel.org;
> linux-usb@vger.kernel.org; devicet...@vger.kernel.org;
> kyungmin.p...@samsung.com; kis...@ti.com; t.f...@samsung.com;
> s.nawro...@samsung.com; m.szyprow...@samsung.com;
> gautam.vi...@samsung.com; mat.krawc...@gmail.com;
> yulgon@samsung.com; p.pan...@samsung.com; av.tikhomi...@samsung.com;
> jg1@samsung.com; ga...@codeaurora.org; Felipe Balbi
> Subject: Re: [PATCH v4 5/9] usb: s3c-hsotg: Use the new Exynos USB phy
> driver with the generic phy framework
>
> On Thu, Dec 05, 2013 at 01:29:35PM +0100, Kamil Debski wrote:
> > Change the used phy driver to the new Exynos USB phy driver that uses
> > the generic phy framework.
> >
> > Signed-off-by: Kamil Debski
> > Signed-off-by: Kyungmin Park
> > ---
> > .../devicetree/bindings/usb/samsung-hsotg.txt |4
> > drivers/usb/gadget/s3c-hsotg.c | 11 ++
> -
> > 2 files changed, 10 insertions(+), 5 deletions(-)
>
> Kamil,
>
> Can we separate this patch out of this series? My bcm281xx series is
> ready to go except for this dependency. Felipe has noted that there's
> only a week until he locks his tree down for 3.14 [1]. I'm willing to
> update this versus the comment Kishon made on fixing the example if you
> don't have time before then. Let me know.
>
> [1] https://lkml.org/lkml/2013/12/16/555
>
> Thanks,
> Matt
>
> > diff --git a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > index b83d428..9340d06 100644
> > --- a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > +++ b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > @@ -24,6 +24,8 @@ Required properties:
> > - first entry: must be "otg"
> > - vusb_d-supply: phandle to voltage regulator of digital section,
> > - vusb_a-supply: phandle to voltage regulator of analog section.
> > +- phys: from general PHY binding: phandle to the PHY device
> > +- phy-names: from general PHY binding: should be "usb2-phy"
> >
> > Example
> > -
> > @@ -36,5 +38,7 @@ Example
> > clock-names = "otg";
> > vusb_d-supply = <&vusb_reg>;
> > vusb_a-supply = <&vusbdac_reg>;
> > + phys = <&usb2phy 0>;
> > + phy-names = "device";
> > };
> >
> > diff --git a/drivers/usb/gadget/s3c-hsotg.c
> > b/drivers/usb/gadget/s3c-hsotg.c index eccb147..db096fd 100644
> > --- a/drivers/usb/gadget/s3c-hsotg.c
> > +++ b/drivers/usb/gadget/s3c-hsotg.c
> > @@ -31,6 +31,7 @@
> > #include #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -162,7 +163,7 @@ struct s3c_hsotg_ep { struct s3c_hsotg {
> > struct device*dev;
> > struct usb_gadget_driver *driver;
> > - struct usb_phy *phy;
> > + struct phy *phy;
> > struct s3c_hsotg_plat*plat;
> >
> > spinlock_t lock;
> > @@ -2905,7 +2906,7 @@ static void s3c_hsotg_phy_enable(struct
> s3c_hsotg *hsotg)
> > dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
> >
> > if (hsotg->phy)
> > - usb_phy_init(hsotg->phy);
> > + phy_power_on(hsotg->phy);
> > else if (hsotg->plat->phy_init)
> > hsotg->plat->phy_init(pdev, hsotg->plat->phy_type); } @@ -
> 2922,7
> > +2923,7 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg *hsotg)
> > struct platform_device *pdev = to_platform_device(hsotg->dev);
> >
> > if (hsotg->phy)
> > - usb_phy_shutdown(hsotg->phy);
> > + phy_power_off(hsotg->phy);
> > else if (hsotg->plat->phy_exit)
> > hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type); } @@ -
> 3529,7
> > +3530,7 @@ static void s3c_hsotg_delete_debug(struct s3c_hsotg *hsotg)
> > static int s3c_hsotg_probe(struct platform_device *pdev) {
> > struct s3c_hsotg_plat *plat = dev_get_platdata(&pdev->dev);
> > - struct usb_phy *phy;
> > + struct phy *phy;
> > struct device *dev = &pdev->dev;
> > struct s3c_hsotg_ep *eps;
> > struct s3c_hsotg *hsotg;
> > @@ -3544,7 +3545,7 @@ static int s3c_hsotg_probe(struct
> platform_device *pdev)
> > return -ENOMEM;
> > }
> >
> > - phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB
[PATCH v2] xhci: Remove unused variable 'addr' in inc_deq() and inc_enq().
This patch remove unused variable 'addr' in inc_deq() and inc_enq().
Signed-off-by: Lin Wang
---
drivers/usb/host/xhci-ring.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 53c2e29..630f6e4 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -156,8 +156,6 @@ static void next_trb(struct xhci_hcd *xhci,
*/
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
{
- unsigned long long addr;
-
ring->deq_updates++;
/*
@@ -186,8 +184,6 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring
*ring)
ring->dequeue++;
}
} while (last_trb(xhci, ring, ring->deq_seg, ring->dequeue));
-
- addr = (unsigned long long) xhci_trb_virt_to_dma(ring->deq_seg,
ring->dequeue);
}
/*
@@ -212,7 +208,6 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring
*ring,
{
u32 chain;
union xhci_trb *next;
- unsigned long long addr;
chain = le32_to_cpu(ring->enqueue->generic.field[3]) & TRB_CHAIN;
/* If this is not event ring, there is one less usable TRB */
@@ -264,7 +259,6 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring
*ring,
ring->enqueue = ring->enq_seg->trbs;
next = ring->enqueue;
}
- addr = (unsigned long long) xhci_trb_virt_to_dma(ring->enq_seg,
ring->enqueue);
}
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] xhci: fix array index out of the bounds in function last_trb() and last_trb_on_last_seg()
> From: Sarah Sharp
> On Mon, Dec 16, 2013 at 03:20:28PM -, David Laight wrote:
> > > I know all these difference clearly, inc_deq() is indeed a common
> > > function for different rings, but lasr_trb() & last_trb_on_last_seg()
> > > inside it use different condition to determine the last trb in an
> > > event ring and an non-event ring; and sorry, i still not find why last
> > > trb in an event ring skipped by H/W according to the current logic.
> > >
> > > Thanks!
> > >
> >
> > Read the specs and the code.
>
> State your objections clearly.
>
> Based on my analysis, this patch will produce correct behavior with the
> event ring:
>
> http://marc.info/?l=linux-usb&m=138697807827548&w=2
>
> Am I missing something?
> -/* Is this TRB a link TRB or was the last TRB the last TRB in this event ring
> - * segment? I.e. would the updated event TRB pointer step off the end of the
> - * event seg?
> +/* Is this TRB a link TRB or was the last TRB in this event ring segment?
> + * I.e. would the updated event TRB pointer step off the end of the event
> + * seg?
> */
> static int last_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
> struct xhci_segment *seg, union xhci_trb *trb)
> {
> if (ring == xhci->event_ring)
> - return trb == &seg->trbs[TRBS_PER_SEGMENT];
> + return trb == &seg->trbs[TRBS_PER_SEGMENT - 1];
> else
> return TRB_TYPE_LINK_LE32(trb->link.control);
> }
It would be extremely confusing for the above function to behave
differently for event and other rings.
Actually last_trb() could just be:
return trb == seg->last_trb;
provided an appropriate 'last_trb' field was set.
If we assume that there are no empty ring segments (ie adjacent LINK TRBs),
and that it is never actually called with a pointer to a link trb.
Then the inc_deq() code could just be:
ring->deq_updates++;
ring->num_trbs_free++;
if (last_trb(xhci, ring, ring->deq_seg, ++ring->dequeue)) {
ring->deq_seg = ring->deq_seg->next;
ring->dequeue = ring->deq_seg->trbs;
if (ring->deq_seg == ring->first_seg) /* not sure of name */
ring->cycle_state ^= 1;
}
David
--
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] phy: core: properly handle failure of pm_runtime_get functions
Hi,
On Friday 13 December 2013 12:01 AM, Felipe Balbi wrote:
> In case pm_runtime_get*() fails, it still
> increments pm usage counter, so we *must*
> make sure to pm_runtime_put() even in those
> cases.
But shouldn't the fix be in pm_runtime_get()?
Cheers
Kishon
>
> This patch fixes that mistake the same way
> usbcore treats those possible failures.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/phy/phy-core.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index 03cf8fb..5b61123 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -94,19 +94,27 @@ static struct phy_provider *of_phy_provider_lookup(struct
> device_node *node)
>
> int phy_pm_runtime_get(struct phy *phy)
> {
> + int ret;
> +
> if (!pm_runtime_enabled(&phy->dev))
> return -ENOTSUPP;
>
> - return pm_runtime_get(&phy->dev);
> + ret = pm_runtime_get(&phy->dev);
> + if (ret < 0 && ret != -EINPROGRESS)
> + pm_runtime_put_noidle(&phy->dev);
> }
> EXPORT_SYMBOL_GPL(phy_pm_runtime_get);
>
> int phy_pm_runtime_get_sync(struct phy *phy)
> {
> + int ret;
> +
> if (!pm_runtime_enabled(&phy->dev))
> return -ENOTSUPP;
>
> - return pm_runtime_get_sync(&phy->dev);
> + ret = pm_runtime_get_sync(&phy->dev);
> + if (ret < 0)
> + pm_runtime_put_sync(&phy->dev);
> }
> EXPORT_SYMBOL_GPL(phy_pm_runtime_get_sync);
>
>
--
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: gadget: nokia: fix error recovery path for optional functions
In the nokia gadget some USB functions (obex 1 and 2, phonet) are optional.
If at the start of nokia_bind_config e.g. fi_phonet is an error pointer,
which can happen because we don't fail the bind process if
usb_get_function_instance() fails for fi_phonet, then f_phonet is NULL, and
phonet_stat = usb_add_function(c, f_phonet);
is never called and phonet_stat remains 0.
If, in these circumstances, we hit the err_conf label then !phonet_stat
evaluates to true and we try usb_remove_function() with its second
parameter being f_phonet which is NULL and it causes NULL pointer
dereference.
This patch changes the initial values of (obex1|obex2|phonet)_stat to a
nonzero value so that if the err_conf label is hit while the respective
functions have not been acquired the usb_remove_function() is not called
for those functions.
Signed-off-by: Andrzej Pietrasiewicz
---
v1..v2:
- obex1/obex2/phonet_stat now initialized to -ENODEV instead of -1
drivers/usb/gadget/nokia.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/nokia.c b/drivers/usb/gadget/nokia.c
index 0a8099a..9598ed7 100644
--- a/drivers/usb/gadget/nokia.c
+++ b/drivers/usb/gadget/nokia.c
@@ -126,9 +126,9 @@ static int __init nokia_bind_config(struct
usb_configuration *c)
struct usb_function *f_ecm;
struct usb_function *f_obex2 = NULL;
int status = 0;
- int obex1_stat = 0;
- int obex2_stat = 0;
- int phonet_stat = 0;
+ int obex1_stat = -ENODEV;
+ int obex2_stat = -ENODEV;
+ int phonet_stat = -ENODEV;
if (!IS_ERR(fi_phonet)) {
f_phonet = usb_get_function(fi_phonet);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb/gadget: should use u16 type variable to store MaxPower
>From 7e827a0d300e084f74c65122baa5e3193f9a7f18 Mon Sep 17 00:00:00 2001
From: "Du, Changbin"
Date: Mon, 16 Dec 2013 20:32:13 +0800
Subject: [PATCH] usb/gadget: should use u16 type variable to store MaxPower
The MaxPower field is of u16 type. So using u8 type variable can break
data (high byte lost).
Signed-off-by: Du, Changbin
---
drivers/usb/gadget/composite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 2018ba1..8a34173 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1714,7 +1714,7 @@ composite_resume(struct usb_gadget *gadget)
{
struct usb_composite_dev*cdev = get_gadget_data(gadget);
struct usb_function *f;
- u8 maxpower;
+ u16 maxpower;
/* REVISIT: should we have config level
* suspend/resume callbacks?
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/9] usb: s3c-hsotg: Use the new Exynos USB phy driver with the generic phy framework
On Tue, Dec 17, 2013 at 10:41:56AM +0100, Kamil Debski wrote:
> Hi Matt,
>
> I am afraid it is not possible. This patch cannot go in without the
> new phy driver. It would break Exynos USB functionality. This
> is because it changes s3c-hsotg to use the new phy driver.
To clarify, I'm proposing that I would bring back the original patch
from my earlier postings on the bcm281xx series that preserves the old
style usb phy support as a fallback along with the pdata path.
> I am working on an updated patch series addressing all the comments.
> time permitting I want to post an alternative version - integrating
> as much as possible in a single file. This way it would be possible
> to have a hands-on comparison of the two approaches we were
> discussing with Kishon.
>
> I estimate that I post it this week.
Ok, thanks. In the meantime I'll update my original version of this
patch in case your work can't be taken in this window.
-Matt
> > -Original Message-
> > From: Matt Porter [mailto:mpor...@linaro.org]
> > Sent: Monday, December 16, 2013 10:40 PM
> > To: Kamil Debski
> > Cc: linux-ker...@vger.kernel.org; linux-samsung-...@vger.kernel.org;
> > linux-usb@vger.kernel.org; devicet...@vger.kernel.org;
> > kyungmin.p...@samsung.com; kis...@ti.com; t.f...@samsung.com;
> > s.nawro...@samsung.com; m.szyprow...@samsung.com;
> > gautam.vi...@samsung.com; mat.krawc...@gmail.com;
> > yulgon@samsung.com; p.pan...@samsung.com; av.tikhomi...@samsung.com;
> > jg1@samsung.com; ga...@codeaurora.org; Felipe Balbi
> > Subject: Re: [PATCH v4 5/9] usb: s3c-hsotg: Use the new Exynos USB phy
> > driver with the generic phy framework
> >
> > On Thu, Dec 05, 2013 at 01:29:35PM +0100, Kamil Debski wrote:
> > > Change the used phy driver to the new Exynos USB phy driver that uses
> > > the generic phy framework.
> > >
> > > Signed-off-by: Kamil Debski
> > > Signed-off-by: Kyungmin Park
> > > ---
> > > .../devicetree/bindings/usb/samsung-hsotg.txt |4
> > > drivers/usb/gadget/s3c-hsotg.c | 11 ++
> > -
> > > 2 files changed, 10 insertions(+), 5 deletions(-)
> >
> > Kamil,
> >
> > Can we separate this patch out of this series? My bcm281xx series is
> > ready to go except for this dependency. Felipe has noted that there's
> > only a week until he locks his tree down for 3.14 [1]. I'm willing to
> > update this versus the comment Kishon made on fixing the example if you
> > don't have time before then. Let me know.
> >
> > [1] https://lkml.org/lkml/2013/12/16/555
> >
> > Thanks,
> > Matt
> >
> > > diff --git a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > > b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > > index b83d428..9340d06 100644
> > > --- a/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > > +++ b/Documentation/devicetree/bindings/usb/samsung-hsotg.txt
> > > @@ -24,6 +24,8 @@ Required properties:
> > > - first entry: must be "otg"
> > > - vusb_d-supply: phandle to voltage regulator of digital section,
> > > - vusb_a-supply: phandle to voltage regulator of analog section.
> > > +- phys: from general PHY binding: phandle to the PHY device
> > > +- phy-names: from general PHY binding: should be "usb2-phy"
> > >
> > > Example
> > > -
> > > @@ -36,5 +38,7 @@ Example
> > > clock-names = "otg";
> > > vusb_d-supply = <&vusb_reg>;
> > > vusb_a-supply = <&vusbdac_reg>;
> > > + phys = <&usb2phy 0>;
> > > + phy-names = "device";
> > > };
> > >
> > > diff --git a/drivers/usb/gadget/s3c-hsotg.c
> > > b/drivers/usb/gadget/s3c-hsotg.c index eccb147..db096fd 100644
> > > --- a/drivers/usb/gadget/s3c-hsotg.c
> > > +++ b/drivers/usb/gadget/s3c-hsotg.c
> > > @@ -31,6 +31,7 @@
> > > #include #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -162,7 +163,7 @@ struct s3c_hsotg_ep { struct s3c_hsotg {
> > > struct device*dev;
> > > struct usb_gadget_driver *driver;
> > > - struct usb_phy *phy;
> > > + struct phy *phy;
> > > struct s3c_hsotg_plat*plat;
> > >
> > > spinlock_t lock;
> > > @@ -2905,7 +2906,7 @@ static void s3c_hsotg_phy_enable(struct
> > s3c_hsotg *hsotg)
> > > dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
> > >
> > > if (hsotg->phy)
> > > - usb_phy_init(hsotg->phy);
> > > + phy_power_on(hsotg->phy);
> > > else if (hsotg->plat->phy_init)
> > > hsotg->plat->phy_init(pdev, hsotg->plat->phy_type); } @@ -
> > 2922,7
> > > +2923,7 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg *hsotg)
> > > struct platform_device *pdev = to_platform_device(hsotg->dev);
> > >
> > > if (hsotg->phy)
> > > - usb_phy_shutdown(hsotg->phy);
> > > + phy_power_off(hsotg->phy);
> > > else if (hsotg->plat->phy_exit)
> > > hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type); } @@ -
> > 3529,7
> > > +3530,7 @@ static void s3c_hsotg_del
RE: [PATCH v4 3/9] phy: Add new Exynos USB PHY driver
Hi Anton, > From: Anton Tikhomirov [mailto:av.tikhomi...@samsung.com] > Sent: Tuesday, December 10, 2013 3:43 AM > > Hi Kamil, > > Same USB2.0 PHY may be used by several HCDs, for example EHCI and OHCI. > Consider the situation, when EHCI stops using the PHY and calls > power_off, then OHCI becomes non-operational. In other words, PHY > power_on and power_off calls must be balanced. > > Shall we handle it in your driver? (usage count?) Please look in the drivers/phy/phy-core.c file. Usage count is handled there - see phy_power_on and phy_power_off functions. I understand that after both EHCI and OHCI power on the phy, the usage count is 2. So powering off one of them (EHCI for instance) the usage count is still 1, so the OHCI should still work properly. [snip] Best wishes, -- Kamil Debski Samsung R&D Institute Poland -- 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: [RFC 1/2] fix our current target reap infrastructure.
On Mon, 2013-12-16 at 10:57 -0500, Alan Stern wrote:
> On Mon, 16 Dec 2013, James Bottomley wrote:
>
> > This patch eliminates the reap_ref and replaces it with a proper kref.
> > On last put of this kref, the target is removed from visibility in
> > sysfs. The final call to scsi_target_reap() for the device is done from
> > __scsi_remove_device() and only if the device was made visible. This
> > ensures that the target disappears as soon as the last device is gone
> > rather than waiting until final release of the device (which is often
> > too long).
>
> Reviewed-by: Alan Stern
>
> Two small suggested changes:
>
> > @@ -441,29 +466,32 @@ static struct scsi_target *scsi_alloc_target(struct
> > device *parent,
> > return starget;
> >
> > found:
> > - found_target->reap_ref++;
> > + if (!kref_get_unless_zero(&found_target->reap_ref))
> > + /*
> > +* release routine already fired. Target is dead, but
> > +* STARGET_DEL may not yet be set (set in the release
> > +* routine), so set here as well, just in case
> > +*/
> > + found_target->state = STARGET_DEL;
> > spin_unlock_irqrestore(shost->host_lock, flags);
> > if (found_target->state != STARGET_DEL) {
> > put_device(dev);
> > return found_target;
> > }
> > - /* Unfortunately, we found a dying target; need to
> > -* wait until it's dead before we can get a new one */
> > + /*
> > +* Unfortunately, we found a dying target; need to wait until it's
> > +* dead before we can get a new one. There is an anomaly here. We
> > +* *should* call scsi_target_reap() to balance the kref_get() of the
> > +* reap_ref above. However, since the target is in state STARGET_DEL,
> > +* it's already invisible and the reap_ref is irrelevant. If we call
> > +* scsi_target_reap() we might spuriously do another device_del() on
> > +* an already invisible target.
> > +*/
> > put_device(&found_target->dev);
> > flush_scheduled_work();
> > goto retry;
>
> Since scsi_target_reap_usercontext() is now gone, scsi_target_destroy()
> doesn't rely on a work queue any more. Therefore something like
> msleep(1) would be more appropriate than flush_scheduled_work().
I suppose so. In theory with the removal of the work queue, going from
final release to list del should be deterministic, so we should run into
this less. I quite like the flush_scheduled_work, because it pushes out
all the pending work for devices on other targets (so accelerates host
remove). However, I suppose it does now look wrong in this context.
> > --- a/include/scsi/scsi_device.h
> > +++ b/include/scsi/scsi_device.h
> > @@ -257,7 +257,7 @@ struct scsi_target {
> > struct list_headsiblings;
> > struct list_headdevices;
> > struct device dev;
> > - unsigned intreap_ref; /* protected by the host lock */
> > + struct kref reap_ref; /* last put renders device invisible
> > */
>
> s/device/target/
Will update, thanks.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: gadget: storage: make FSG_BUFLEN configurable on Kconfig
On Mon, Dec 16 2013, Felipe Balbi wrote: > On Mon, Dec 16, 2013 at 09:20:20PM +, Paul Zimmerman wrote: >> > From: linux-usb-ow...@vger.kernel.org >> > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi >> > Sent: Monday, December 16, 2013 11:42 AM >> > >> > By making that configurable on Kconfig, we won't >> > need to modify source code when we want to change >> > the way f_mass_storage behaves for a specific >> > product. >> >> Shouldn't this value also be configurable via module params / sysfs, >> the same way that USB_GADGET_STORAGE_NUM_BUFFERS is? I know new module >> parameters are frowned upon, but the mass storage gadget has quite a >> few of them already, so for consistency I think this one should be too. >> >> Plus, in my experience, this value is the one that needs tuning for >> performance, while NUM_BUFFERS is fine with its default value. So if >> NUM_BUFFERS is allowed to be configured at runtime, this one should be >> too. > > I have no problems with that. Let's see what Michal and Alan think. What > do you guys think ? Sounds good to me, but perhaps instead of adding new module parameters, or sysfs entries, it'll be better to work on getting this done via configfs. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- signature.asc Description: PGP signature
Re: [PATCH v2] usb: gadget: nokia: fix error recovery path for optional functions
On Tue, Dec 17 2013, Andrzej Pietrasiewicz wrote:
> In the nokia gadget some USB functions (obex 1 and 2, phonet) are optional.
>
> If at the start of nokia_bind_config e.g. fi_phonet is an error pointer,
> which can happen because we don't fail the bind process if
> usb_get_function_instance() fails for fi_phonet, then f_phonet is NULL, and
>
> phonet_stat = usb_add_function(c, f_phonet);
>
> is never called and phonet_stat remains 0.
>
> If, in these circumstances, we hit the err_conf label then !phonet_stat
> evaluates to true and we try usb_remove_function() with its second
> parameter being f_phonet which is NULL and it causes NULL pointer
> dereference.
>
> This patch changes the initial values of (obex1|obex2|phonet)_stat to a
> nonzero value so that if the err_conf label is hit while the respective
> functions have not been acquired the usb_remove_function() is not called
> for those functions.
>
> Signed-off-by: Andrzej Pietrasiewicz
As before:
Acked-by: Michal Nazarewicz
> ---
> v1..v2:
>
> - obex1/obex2/phonet_stat now initialized to -ENODEV instead of -1
>
> drivers/usb/gadget/nokia.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/nokia.c b/drivers/usb/gadget/nokia.c
> index 0a8099a..9598ed7 100644
> --- a/drivers/usb/gadget/nokia.c
> +++ b/drivers/usb/gadget/nokia.c
> @@ -126,9 +126,9 @@ static int __init nokia_bind_config(struct
> usb_configuration *c)
> struct usb_function *f_ecm;
> struct usb_function *f_obex2 = NULL;
> int status = 0;
> - int obex1_stat = 0;
> - int obex2_stat = 0;
> - int phonet_stat = 0;
> + int obex1_stat = -ENODEV;
> + int obex2_stat = -ENODEV;
> + int phonet_stat = -ENODEV;
>
> if (!IS_ERR(fi_phonet)) {
> f_phonet = usb_get_function(fi_phonet);
> --
> 1.7.0.4
>
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
[PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
From: Andreas Naumann
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it has not been
initialized yet.
Signed-off-by: Andreas Naumann
---
Even though I find the implementation a bit awkward this should fix
the issue without breaking anything else. Hope everyone is happy
with this.
drivers/usb/musb/omap2430.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 4315d35..fbe2c08 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -48,6 +48,7 @@ struct omap2430_glue {
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
struct device *control_otghs;
+ u8 initialized;
};
#define glue_to_musb(g)platform_get_drvdata(g->musb)
@@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
}
musb_writel(musb->mregs, OTG_INTERFSEL, l);
+ glue->initialized = 1;
pr_debug("HS USB OTG: revision 0x%x, sysconfig 0x%02x, "
"sysstatus 0x%x, intrfsel 0x%x, simenable 0x%x\n",
@@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->musb = musb;
glue->status= OMAP_MUSB_UNKNOWN;
+ glue->initialized = 0;
if (np) {
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
@@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device *dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb->mregs, OTG_INTERFSEL,
+ if(glue->initialized)
+ musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
usb_phy_set_suspend(musb->xceiv, 0);
--
1.8.4.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: "EHCI: BIOS handoff failed (BIOS bug?) 01010001" on Celeron N2805 (Bay Trail) / Gateway LT41P
On Tue, 17 Dec 2013, Ken Harris wrote: > Sebastien: > > Thanks for the info. I just tried Linux 3.13.0-0.rc3.git5.1.fc21.i686 > (from Fedora rawhide) and I still get the same error messages and USB > still doesn't work. I saw a post about Atom Z3740D (Bay Trail-T) in a > Dell Venue 8 Pro, and his USB works OK (but seems to use the xhci_hcd > driver : > Whereas my Gateway LT41P uses ehci & ohci : > A clue? A workaround ? > >> [ 61.785031] pci :00:1d.0: EHCI: BIOS handoff failed (BIOS bug?) > >> 01010001 Since the problem lies in the BIOS, you should check if any BIOS updates are available. 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] phy: core: properly handle failure of pm_runtime_get functions
On Tue, 17 Dec 2013, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 13 December 2013 12:01 AM, Felipe Balbi wrote: > > In case pm_runtime_get*() fails, it still > > increments pm usage counter, so we *must* > > make sure to pm_runtime_put() even in those > > cases. > > But shouldn't the fix be in pm_runtime_get()? No, it should not. pm_runtime_get() behaves exactly as intended. See Documentation/power/runtime_pm.txt. 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 V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:
> From: Andreas Naumann
>
> This is a hard to reproduce problem which leads to non-functional
> USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
> e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
> of OTG_INTERFSEL over suspend.
> Since the resume function is also called early in driver init, it uses a
> non-initialized value (which is 0 and a non-supported setting in DM37xx
> for INTERFSEL). Shortly after the correct value is set. Apparently this
> works most time, but not always.
>
> Fix it by not writing the value on runtime resume if it has not been
> initialized yet.
>
> Signed-off-by: Andreas Naumann
> ---
> Even though I find the implementation a bit awkward this should fix
> the issue without breaking anything else. Hope everyone is happy
> with this.
>
> drivers/usb/musb/omap2430.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 4315d35..fbe2c08 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -48,6 +48,7 @@ struct omap2430_glue {
> enum omap_musb_vbus_id_status status;
> struct work_struct omap_musb_mailbox_work;
> struct device *control_otghs;
> + u8 initialized;
> };
> #define glue_to_musb(g) platform_get_drvdata(g->musb)
>
> @@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
> }
>
> musb_writel(musb->mregs, OTG_INTERFSEL, l);
> + glue->initialized = 1;
>
> pr_debug("HS USB OTG: revision 0x%x, sysconfig 0x%02x, "
> "sysstatus 0x%x, intrfsel 0x%x, simenable 0x%x\n",
> @@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device *pdev)
> glue->dev = &pdev->dev;
> glue->musb = musb;
> glue->status= OMAP_MUSB_UNKNOWN;
> + glue->initialized = 0;
You don't need to do this. 'glue' was already allocated with kzalloc().
>
> if (np) {
> pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> @@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device *dev)
>
> if (musb) {
> omap2430_low_level_init(musb);
> - musb_writel(musb->mregs, OTG_INTERFSEL,
> + if(glue->initialized)
Are you sure this is thread safe?
If you're sending this patch it means runtime_resume can be called
before omap2430_must_init(), but how about at the same time?
You defined 'initialized' as u8 type, then read/write operations won't
be atomic in ARM.
Br, David Cohen
> + musb_writel(musb->mregs, OTG_INTERFSEL,
> musb->context.otg_interfsel);
>
> usb_phy_set_suspend(musb->xceiv, 0);
> --
> 1.8.4.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
--
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 v7 7/9] phy: add Broadcom Kona USB2 PHY DT binding
Add a binding that describes the Broadcom Kona USB2 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter
Acked-by: Kishon Vijay Abraham I
---
Documentation/devicetree/bindings/phy/bcm-phy.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/bcm-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/bcm-phy.txt
b/Documentation/devicetree/bindings/phy/bcm-phy.txt
new file mode 100644
index 000..3dc8b3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-phy.txt
@@ -0,0 +1,15 @@
+BROADCOM KONA USB2 PHY
+
+Required properties:
+ - compatible: brcm,kona-usb2-phy
+ - reg: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+ usbphy: usb-phy@3f13 {
+ compatible = "brcm,kona-usb2-phy";
+ reg = <0x3f13 0x28>;
+ #phy-cells = <0>;
+ };
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/9] phy: add phy_get_bus_width()/phy_set_bus_width() calls
This adds a pair of APIs that allows the generic PHY subsystem to
provide information on the PHY bus width. The PHY provider driver may
use phy_set_bus_width() to set the bus width that the PHY supports.
The controller driver may then use phy_get_bus_width() to fetch the
PHY bus width in order to properly configure the controller.
Signed-off-by: Matt Porter
Acked-by: Kishon Vijay Abraham I
---
include/linux/phy/phy.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 6d72269..e273e5a 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -38,6 +38,14 @@ struct phy_ops {
};
/**
+ * struct phy_attrs - represents phy attributes
+ * @bus_width: Data path width implemented by PHY
+ */
+struct phy_attrs {
+ u32 bus_width;
+};
+
+/**
* struct phy - represents the phy device
* @dev: phy device
* @id: id of the phy device
@@ -46,6 +54,7 @@ struct phy_ops {
* @mutex: mutex to protect phy_ops
* @init_count: used to protect when the PHY is used by multiple consumers
* @power_count: used to protect when the PHY is used by multiple consumers
+ * @phy_attrs: used to specify PHY specific attributes
*/
struct phy {
struct device dev;
@@ -55,6 +64,7 @@ struct phy {
struct mutexmutex;
int init_count;
int power_count;
+ struct phy_attrsattrs;
};
/**
@@ -127,6 +137,14 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+static inline int phy_get_bus_width(struct phy *phy)
+{
+ return phy->attrs.bus_width;
+}
+static inline void phy_set_bus_width(struct phy *phy, int bus_width)
+{
+ phy->attrs.bus_width = bus_width;
+}
struct phy *phy_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
void phy_put(struct phy *phy);
@@ -199,6 +217,16 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_get_bus_width(struct phy *phy)
+{
+ return -ENOSYS;
+}
+
+static inline void phy_set_bus_width(struct phy *phy, int bus_width)
+{
+ return;
+}
+
static inline struct phy *phy_get(struct device *dev, const char *string)
{
return ERR_PTR(-ENOSYS);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 0/9] USB Device Controller support for BCM281xx
Changes since v6: - Drop dependency on the Exynos generic phy conversion series - Bring back original patch that converts s3c-hsotg to use the generic phy layer with a fall back to the old usb style phy support. Changes since v5: - tweak s3c-hsotg Kconfig help message to be more generic Changes since v4: - phy_set/get_bus_width now use an int for bus_width Changes since v3: - Rebased on 3.13-rc3 - Move struct phy bus_width attribute back into struct phy_attrs - Fix build issue on !GENERIC_PHY - Update dwc2 binding to reflect optional phy properties - Rename bcm-kona-phy.txt binding to bcm-phy.txt - Reorder bcm kona phy includes and use bitops - phy-names changed to "usb2-phy" to match updated s3c-hsotg generic phy-ification series Changes since v2: - Rebased on 3.13-rc1 - Fix braces in phy_get_bus_width()/phy_set_bus_width() - Drop generic phy conversion to use the same support from the Exynos generic phy conversion series - Modify dts support to match the "device" phy name required in the v3 Exynos generic phy conversion - Add s3c-hsotg phy_init/phy_exit support - Fix typo on reg property in kona phy binding - Replace phy driver reg struct with offset defines - Move phy soft reset to phy driver init - Fix dts node names to match ePAPR conventions Changes since v1: - Convert USB phy driver to generic phy subsystem - Add phy bus width apis - Drop dwc2 phy bus width DT property in favor of querying the phy provider for bus width - Add generic phy/clock properties to dwc2 DT binding - Add generic phy subsystem support to s3c-hsotg with the existing usb phy and pdata phy methods as a fallback - Split bindings out to separate patches to match the latest DT binding review guidelines This series adds USB Device Controller support for the Broadcom BCM281xx family of parts. BCM281xx contains a DWC2 OTG block and s3c-hsotg is used to support UDC operation. Part 1 adds phy bus width support to the generic phy subsystem Parts 2-6 allows s3c-hsotg to build on non-Samsung platforms, supports the dwc2 binding, adds generic phy layer support, and supports fetching phy bus width using the generic phy layer. Parts 7-8 add a generic phy binding and driver for the BCM Kona USB PHY. Part 9 adds the DT nodes to enable UDC support on both BCM281xx boards in the kernel. This series depends on: - "Update Kona drivers to use clocks" v4 series https://lkml.org/lkml/2013/12/5/508 (relevant portion now queued for 3.14) Matt Porter (9): phy: add phy_get_bus_width()/phy_set_bus_width() calls staging: dwc2: update DT binding to add generic clock/phy properties usb: gadget: s3c-hsotg: enable build for other platforms usb: gadget: s3c-hsotg: add snps,dwc2 compatible string usb: gadget: s3c-hsotg: enable generic phy support usb: gadget: s3c-hsotg: get phy bus width from phy subsystem phy: add Broadcom Kona USB2 PHY DT binding phy: add Broadcom Kona USB2 PHY driver ARM: dts: add usb udc support to bcm281xx Documentation/devicetree/bindings/phy/bcm-phy.txt | 15 ++ Documentation/devicetree/bindings/staging/dwc2.txt | 12 ++ arch/arm/boot/dts/bcm11351-brt.dts | 6 + arch/arm/boot/dts/bcm11351.dtsi| 18 +++ arch/arm/boot/dts/bcm28155-ap.dts | 8 ++ drivers/phy/Kconfig| 6 + drivers/phy/Makefile | 1 + drivers/phy/phy-bcm-kona-usb2.c| 158 + drivers/usb/gadget/Kconfig | 7 +- drivers/usb/gadget/s3c-hsotg.c | 72 +++--- drivers/usb/gadget/s3c-hsotg.h | 1 + include/linux/phy/phy.h| 28 12 files changed, 309 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/bcm-phy.txt create mode 100644 drivers/phy/phy-bcm-kona-usb2.c -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/9] usb: gadget: s3c-hsotg: enable build for other platforms
Remove unused Samsung-specific machine include and Kconfig
dependency on S3C.
Signed-off-by: Matt Porter
Reviewed-by: Markus Mayer
Reviewed-by: Tim Kryger
---
drivers/usb/gadget/Kconfig | 7 +++
drivers/usb/gadget/s3c-hsotg.c | 2 --
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index a91e642..181e760 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -294,11 +294,10 @@ config USB_PXA27X
gadget drivers to also be dynamically linked.
config USB_S3C_HSOTG
- tristate "S3C HS/OtG USB Device controller"
- depends on S3C_DEV_USB_HSOTG
+ tristate "Designware/S3C HS/OtG USB Device controller"
help
- The Samsung S3C64XX USB2.0 high-speed gadget controller
- integrated into the S3C64XX series SoC.
+ The Designware USB2.0 high-speed gadget controller
+ integrated into many SoCs.
config USB_S3C2410
tristate "S3C2410 USB Device Controller"
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 9875d9c..db797f2 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -36,8 +36,6 @@
#include
#include
-#include
-
#include "s3c-hsotg.h"
static const char * const s3c_hsotg_supply_names[] = {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 8/9] phy: add Broadcom Kona USB2 PHY driver
Add a driver for the internal Broadcom Kona USB 2.0 PHY found
on the BCM281xx family of SoCs.
Signed-off-by: Matt Porter
---
drivers/phy/Kconfig | 6 ++
drivers/phy/Makefile| 1 +
drivers/phy/phy-bcm-kona-usb2.c | 158
3 files changed, 165 insertions(+)
create mode 100644 drivers/phy/phy-bcm-kona-usb2.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a344f3d..2e87fa8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,10 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config BCM_KONA_USB2_PHY
+ tristate "Broadcom Kona USB2 PHY Driver"
+ depends on GENERIC_PHY
+ help
+ Enable this to support the Broadcom Kona USB 2.0 PHY.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..c447f1a 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
+obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
new file mode 100644
index 000..0046781
--- /dev/null
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -0,0 +1,158 @@
+/*
+ * phy-bcm-kona-usb2.c - Broadcom Kona USB2 Phy Driver
+ *
+ * Copyright (C) 2013 Linaro Limited
+ * Matt Porter
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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
+#include
+#include
+
+#define OTGCTL (0)
+#define OTGCTL_OTGSTAT2BIT(31)
+#define OTGCTL_OTGSTAT1BIT(30)
+#define OTGCTL_PRST_N_SW BIT(11)
+#define OTGCTL_HRESET_NBIT(10)
+#define OTGCTL_UTMI_LINE_STATE1BIT(9)
+#define OTGCTL_UTMI_LINE_STATE0BIT(8)
+
+#define P1CTL (8)
+#define P1CTL_SOFT_RESET BIT(1)
+#define P1CTL_NON_DRIVING BIT(0)
+
+struct bcm_kona_usb {
+ void __iomem *regs;
+};
+
+static void bcm_kona_usb_phy_power(struct bcm_kona_usb *phy, int on)
+{
+ u32 val;
+
+ val = readl(phy->regs + OTGCTL);
+ if (on) {
+ /* Configure and power PHY */
+ val &= ~(OTGCTL_OTGSTAT2 | OTGCTL_OTGSTAT1 |
+OTGCTL_UTMI_LINE_STATE1 | OTGCTL_UTMI_LINE_STATE0);
+ val |= OTGCTL_PRST_N_SW | OTGCTL_HRESET_N;
+ } else {
+ val &= ~(OTGCTL_PRST_N_SW | OTGCTL_HRESET_N);
+ }
+ writel(val, phy->regs + OTGCTL);
+}
+
+static int bcm_kona_usb_phy_init(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+ u32 val;
+
+ /* Soft reset PHY */
+ val = readl(phy->regs + P1CTL);
+ val &= ~P1CTL_NON_DRIVING;
+ val |= P1CTL_SOFT_RESET;
+ writel(val, phy->regs + P1CTL);
+ writel(val & ~P1CTL_SOFT_RESET, phy->regs + P1CTL);
+ /* Reset needs to be asserted for 2ms */
+ mdelay(2);
+ writel(val | P1CTL_SOFT_RESET, phy->regs + P1CTL);
+
+ return 0;
+}
+
+static int bcm_kona_usb_phy_power_on(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+ bcm_kona_usb_phy_power(phy, 1);
+
+ return 0;
+}
+
+static int bcm_kona_usb_phy_power_off(struct phy *gphy)
+{
+ struct bcm_kona_usb *phy = phy_get_drvdata(gphy);
+
+ bcm_kona_usb_phy_power(phy, 0);
+
+ return 0;
+}
+
+static struct phy_ops ops = {
+ .init = bcm_kona_usb_phy_init,
+ .power_on = bcm_kona_usb_phy_power_on,
+ .power_off = bcm_kona_usb_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int bcm_kona_usb2_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct bcm_kona_usb *phy;
+ struct resource *res;
+ struct phy *gphy;
+ struct phy_provider *phy_provider;
+
+ phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ phy->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(phy->regs))
+ return PTR_ERR(phy->regs);
+
+ platform_set_drvdata(pdev, phy);
+
+ phy_provider = devm_of_phy_provider_register(dev,
+
Re: [PATCH] xhci: fix array index out of the bounds in function last_trb() and last_trb_on_last_seg()
On Tue, Dec 17, 2013 at 09:35:39AM -, David Laight wrote:
> > From: Wang, Lin X
> > David is right, this patch may lead to the last trb in an event ring
> > unprocessed according to the
> > current logic, you can reject this patch, although I think index
> > out-of-bounds is reasonable.
> >
> > If applying this patch, then corresponding function(inc_deq()) should be
> > modified, maybe like the
> > following way:
> >
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index d26cd94..0dbaa56 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -185,7 +185,7 @@ static void inc_deq(struct xhci_hcd *xhci, struct
> > xhci_ring *ring)
> > } else {
> > ring->dequeue++;
> > }
> > - } while (last_trb(xhci, ring, ring->deq_seg, ring->dequeue));
> > + } while (last_trb(xhci, ring, ring->deq_seg, ring->dequeue) &&
> > ring->type != TYPE_EVENT);
Ah, ok, I see where I misread the code now. Thanks for figuring that
out, David.
> There are far too many conditionals in this code already.
> Adding an extra one that serves no purpose is silly.
>
> The C language explicitly allows you to take the address of the first
> item beyond the end of an array and to use that in expressions
> involving pointers to other array members.
The out-of-bounds pointer math is fine as it stands. I'll simply drop
this patch.
Sarah Sharp
--
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 v7 4/9] usb: gadget: s3c-hsotg: add snps,dwc2 compatible string
Enable support for the dwc2 binding.
Signed-off-by: Matt Porter
---
drivers/usb/gadget/s3c-hsotg.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index db797f2..cbfbf41 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -3726,6 +3726,7 @@ static int s3c_hsotg_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id s3c_hsotg_of_ids[] = {
{ .compatible = "samsung,s3c6400-hsotg", },
+ { .compatible = "snps,dwc2", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, s3c_hsotg_of_ids);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 9/9] ARM: dts: add usb udc support to bcm281xx
Adds USB OTG/PHY and clock support to BCM281xx and enables
UDC support on the bcm11351-brt and bcm28155-ap boards.
Signed-off-by: Matt Porter
Reviewed-by: Markus Mayer
Reviewed-by: Tim Kryger
---
arch/arm/boot/dts/bcm11351-brt.dts | 6 ++
arch/arm/boot/dts/bcm11351.dtsi| 18 ++
arch/arm/boot/dts/bcm28155-ap.dts | 8
3 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/bcm11351-brt.dts
b/arch/arm/boot/dts/bcm11351-brt.dts
index 23cd16d..396b704 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -44,5 +44,11 @@
status = "okay";
};
+ usbotg: usb@3f12 {
+ status = "okay";
+ };
+ usbphy: usb-phy@3f13 {
+ status = "okay";
+ };
};
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 1246885..0fbb455 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -243,4 +243,22 @@
#clock-cells = <0>;
};
};
+
+ usbotg: usb@3f12 {
+ compatible = "snps,dwc2";
+ reg = <0x3f12 0x1>;
+ interrupts = ;
+ clocks = <&usb_otg_ahb_clk>;
+ clock-names = "otg";
+ phys = <&usbphy>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usbphy: usb-phy@3f13 {
+ compatible = "brcm,kona-usb2-phy";
+ reg = <0x3f13 0x28>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
diff --git a/arch/arm/boot/dts/bcm28155-ap.dts
b/arch/arm/boot/dts/bcm28155-ap.dts
index 08e47c2..a3bc436 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -43,4 +43,12 @@
cd-gpios = <&gpio 14 0>;
status = "okay";
};
+
+ usbotg: usb@3f12 {
+ status = "okay";
+ };
+
+ usbphy: usb-phy@3f13 {
+ status = "okay";
+ };
};
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 5/9] usb: gadget: s3c-hsotg: enable generic phy support
Adds support for the generic PHY subsystem. Generic PHY
support is probed and then the driver falls back to checking
for an old style USB PHY and pdata if not found.
Signed-off-by: Matt Porter
---
drivers/usb/gadget/s3c-hsotg.c | 55 ++
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index cbfbf41..8f9bcdb 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -30,6 +30,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -138,6 +140,7 @@ struct s3c_hsotg_ep {
* @dev: The parent device supplied to the probe function
* @driver: USB gadget driver
* @phy: The otg phy transceiver structure for phy control.
+ * @uphy: The otg phy transceiver structure for old USB phy control.
* @plat: The platform specific configuration data. This can be removed once
* all SoCs support usb transceiver.
* @regs: The memory area mapped for accessing registers.
@@ -159,7 +162,8 @@ struct s3c_hsotg_ep {
struct s3c_hsotg {
struct device*dev;
struct usb_gadget_driver *driver;
- struct usb_phy *phy;
+ struct phy *phy;
+ struct usb_phy *uphy;
struct s3c_hsotg_plat*plat;
spinlock_t lock;
@@ -2901,8 +2905,11 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg *hsotg)
dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
- if (hsotg->phy)
- usb_phy_init(hsotg->phy);
+ if (hsotg->phy) {
+ phy_init(hsotg->phy);
+ phy_power_on(hsotg->phy);
+ } else if (hsotg->uphy)
+ usb_phy_init(hsotg->uphy);
else if (hsotg->plat->phy_init)
hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
}
@@ -2918,8 +2925,11 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg
*hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
- if (hsotg->phy)
- usb_phy_shutdown(hsotg->phy);
+ if (hsotg->phy) {
+ phy_power_off(hsotg->phy);
+ phy_exit(hsotg->phy);
+ } else if (hsotg->uphy)
+ usb_phy_shutdown(hsotg->uphy);
else if (hsotg->plat->phy_exit)
hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
}
@@ -3526,7 +3536,8 @@ static void s3c_hsotg_delete_debug(struct s3c_hsotg
*hsotg)
static int s3c_hsotg_probe(struct platform_device *pdev)
{
struct s3c_hsotg_plat *plat = dev_get_platdata(&pdev->dev);
- struct usb_phy *phy;
+ struct phy *phy;
+ struct usb_phy *uphy;
struct device *dev = &pdev->dev;
struct s3c_hsotg_ep *eps;
struct s3c_hsotg *hsotg;
@@ -3541,19 +3552,26 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
return -ENOMEM;
}
- phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ /*
+* Attempt to find a generic PHY, then look for an old style
+* USB PHY, finally fall back to pdata
+*/
+ phy = devm_phy_get(&pdev->dev, "usb2-phy");
if (IS_ERR(phy)) {
- /* Fallback for pdata */
- plat = dev_get_platdata(&pdev->dev);
- if (!plat) {
- dev_err(&pdev->dev, "no platform data or transceiver
defined\n");
- return -EPROBE_DEFER;
- } else {
+ uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (IS_ERR(uphy)) {
+ /* Fallback for pdata */
+ plat = dev_get_platdata(&pdev->dev);
+ if (!plat) {
+ dev_err(&pdev->dev,
+ "no platform data or transceiver defined\n");
+ return -EPROBE_DEFER;
+ }
hsotg->plat = plat;
- }
- } else {
+ } else
+ hsotg->uphy = uphy;
+ } else
hsotg->phy = phy;
- }
hsotg->dev = dev;
@@ -3620,6 +3638,9 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
goto err_supplies;
}
+ if (hsotg->phy)
+ phy_init(hsotg->phy);
+
/* usb phy enable */
s3c_hsotg_phy_enable(hsotg);
@@ -3713,6 +3734,8 @@ static int s3c_hsotg_remove(struct platform_device *pdev)
}
s3c_hsotg_phy_disable(hsotg);
+ if (hsotg->phy)
+ phy_exit(hsotg->phy);
clk_disable_unprepare(hsotg->clk);
return 0;
--
1.8.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 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
Hi Dan,
Am 16.12.2013 um 20:40 schrieb Dan Williams:
> On Fri, 2013-12-13 at 15:43 +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi,
>>
>> Am 02.10.2013 um 09:00 schrieb Dr. H. Nikolaus Schaller:
>>
>>> Hi Jan,
>>>
>>> we are using a GTM601 modem (Firmware 1.7) for a while and have spotted an
>>> issue that under some conditions the modem sends a packed wIndex over USB
>>> that is rejected by the hso driver making troubles afterwards. Not
>>> rejecting makes
>>> it work fine.
>>>
>>> BR,
>>> Nikolaus Schaller
>>>
>>> ---
>>>
>>> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
>>> From: "H. Nikolaus Schaller"
>>> Date: Thu, 15 Nov 2012 14:40:57 +0100
>>> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION
>>> GTM601 during RING indication
>>>
>>> It has been observed that the GTM601 with 1.7 firmware sometimes sends a
>>> value
>>> wIndex that has bit 0x04 set instead of being reset as the code expects. So
>>> we
>>> mask it for the error check.
>>>
>>> See
>>> http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
>>>
>>> Signed-off-by: NeilBrown
>>> Signed-off-by: H. Nikolaus Schaller
>>> ---
>>> drivers/net/usb/hso.c |3 ++-
>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
>>> index cba1d46..d146e26 100644
>>> --- a/drivers/net/usb/hso.c
>>> +++ b/drivers/net/usb/hso.c
>>> @@ -1503,7 +1503,8 @@ static void tiocmget_intr_callback(struct urb *urb)
>>> if (serial_state_notification->bmRequestType != BM_REQUEST_TYPE ||
>>> serial_state_notification->bNotification != B_NOTIFICATION ||
>>> le16_to_cpu(serial_state_notification->wValue) != W_VALUE ||
>>> - le16_to_cpu(serial_state_notification->wIndex) != W_INDEX ||
>>> + (le16_to_cpu(serial_state_notification->wIndex) & ~0x4) !=
>>> + W_INDEX ||
>>> le16_to_cpu(serial_state_notification->wLength) != W_LENGTH) {
>>> dev_warn(&usb->dev,
>>> "hso received invalid serial state notification\n");
>>> --
>>> 1.7.7.4
>>>
>>>
>>
>> I have found this (better) proposal by OPTION, but wonder what did happen to
>> it.
>> It neither shows in mainline 3.13-rc nor linux-next:
>>
>> https://lkml.org/lkml/2013/10/9/263
>
> Likely because nobody formally submitted the patch with a signed-off-by,
> which indicates their intent that the patch is tested, correct, and can
> be merged to the kernel.
Ok, I see. I just wasn't aware of the proposal at all since I missed the
discussion
and wasn't on CC.
Therefore I have added Eric to the CC.
>
> I looked at this today, and I'm left wondering how any port other than
> HSO_PORT_MODEM can get the notification via tiocmget_intr_callback().
> "serial->tiocmget" is only created for HSO_PORT_MODEM serial ports (see
> hso_create_bulk_serial_device()):
>
> if ((port & HSO_PORT_MASK) == HSO_PORT_MODEM) {
> num_urbs = 2;
> serial->tiocmget = kzalloc(sizeof(struct hso_tiocmget),
> GFP_KERNEL);
>
> and the code in tiocmget_intr_callback() does this:
>
> tiocmget = serial->tiocmget;
> if (!tiocmget)
> return;
>
> which should mean that only a HSO_PORT_MODEM will ever process the
> notification. Further, the tiocmget interrupt URB is only created and
> submitted if serial->tiocmget != NULL, so only HSO_PORT_MODEM should
> ever be calling into tiocmget_intr_callback().
Ok, that looks plausible.
>
> So I think Eric's patch is actually wrong because it will *always* pass
> the new check.
>
> The original code had the correct intention, but the original code was
> obviously wrong for newer devices where the port layout is read from
> firmware and not from static tables, and thus for recent devices where
> the modem interface is not USB interface #2.
This explains why we did run into the problem with the GTM601.
>
> Can you confirm/deny that the 'modem' interface for your GTM601 is USB
> interface #6? For example, my Icon 452 has the following USB interface
> layout:
>
> 0: Diag
> 1: GPS
> 2: GPS control
> 3: Application
> 4: Control
> 5: Network
> 6: Modem
>
> So like the GTM601, I would expect any RING notifications to appear for
> wIndex=0x06.
Interestingly I see:
0: Diagnostic
1: GPS
2: GPS Control
3: Application
4: Control
5: Modem
I.e. there is no Network interface. Originally we did focus on /dev/ttyHS3
to access the Application interface, but people reported that it is not stable
or always so. Therefore we have some udev rule to add symbolic names
(e.g. /dev/ttyHS_Application):
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=GTA04/udev-rules/hso.rules;hb=HEAD
So I think the assignment is not even always the same on the same device.
And I am a little puzzled why we do see the wIndex == 6 if it is the interface
number. Maybe it happens only in some scenario where the Modem become
[PATCH v7 6/9] usb: gadget: s3c-hsotg: get phy bus width from phy subsystem
Adds support for querying the phy bus width from the generic phy
subsystem. Configure UTMI bus width in GUSBCFG based on this value.
Signed-off-by: Matt Porter
Acked-by: Kishon Vijay Abraham I
---
drivers/usb/gadget/s3c-hsotg.c | 14 +-
drivers/usb/gadget/s3c-hsotg.h | 1 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index 8f9bcdb..93ba8b6 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -146,6 +146,7 @@ struct s3c_hsotg_ep {
* @regs: The memory area mapped for accessing registers.
* @irq: The IRQ number we are using
* @supplies: Definition of USB power supplies
+ * @phyif: PHY interface width
* @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
* @num_of_eps: Number of available EPs (excluding EP0)
* @debug_root: root directrory for debugfs.
@@ -174,6 +175,7 @@ struct s3c_hsotg {
struct regulator_bulk_data supplies[ARRAY_SIZE(s3c_hsotg_supply_names)];
+ u32 phyif;
unsigned intdedicated_fifos:1;
unsigned char num_of_eps;
@@ -2279,7 +2281,7 @@ static void s3c_hsotg_core_init(struct s3c_hsotg *hsotg)
*/
/* set the PLL on, remove the HNP/SRP and set the PHY */
- writel(GUSBCFG_PHYIf16 | GUSBCFG_TOutCal(7) |
+ writel(hsotg->phyif | GUSBCFG_TOutCal(7) |
(0x5 << 10), hsotg->regs + GUSBCFG);
s3c_hsotg_init_fifo(hsotg);
@@ -3638,6 +3640,16 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
goto err_supplies;
}
+ /* Set default UTMI width */
+ hsotg->phyif = GUSBCFG_PHYIf16;
+
+ /*
+* If using the generic PHY framework, check if the PHY bus
+* width is 8-bit and set the phyif appropriately.
+*/
+ if (hsotg->phy && (phy_get_bus_width(phy) == 8))
+ hsotg->phyif = GUSBCFG_PHYIf8;
+
if (hsotg->phy)
phy_init(hsotg->phy);
diff --git a/drivers/usb/gadget/s3c-hsotg.h b/drivers/usb/gadget/s3c-hsotg.h
index d650b12..85f549f 100644
--- a/drivers/usb/gadget/s3c-hsotg.h
+++ b/drivers/usb/gadget/s3c-hsotg.h
@@ -55,6 +55,7 @@
#define GUSBCFG_HNPCap (1 << 9)
#define GUSBCFG_SRPCap (1 << 8)
#define GUSBCFG_PHYIf16(1 << 3)
+#define GUSBCFG_PHYIf8 (0 << 3)
#define GUSBCFG_TOutCal_MASK (0x7 << 0)
#define GUSBCFG_TOutCal_SHIFT (0)
#define GUSBCFG_TOutCal_LIMIT (0x7)
--
1.8.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] xhci: fix array index out of the bounds in function last_trb() and last_trb_on_last_seg()
On Tue, Dec 17, 2013 at 10:15:46AM -, David Laight wrote:
> > From: Sarah Sharp
> > On Mon, Dec 16, 2013 at 03:20:28PM -, David Laight wrote:
> > > > I know all these difference clearly, inc_deq() is indeed a common
> > > > function for different rings, but lasr_trb() & last_trb_on_last_seg()
> > > > inside it use different condition to determine the last trb in an
> > > > event ring and an non-event ring; and sorry, i still not find why last
> > > > trb in an event ring skipped by H/W according to the current logic.
> > > >
> > > > Thanks!
> > > >
> > >
> > > Read the specs and the code.
> >
> > State your objections clearly.
> >
> > Based on my analysis, this patch will produce correct behavior with the
> > event ring:
> >
> > http://marc.info/?l=linux-usb&m=138697807827548&w=2
> >
> > Am I missing something?
>
> > -/* Is this TRB a link TRB or was the last TRB the last TRB in this event
> > ring
> > - * segment? I.e. would the updated event TRB pointer step off the end of
> > the
> > - * event seg?
> > +/* Is this TRB a link TRB or was the last TRB in this event ring segment?
> > + * I.e. would the updated event TRB pointer step off the end of the event
> > + * seg?
> > */
> > static int last_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
> > struct xhci_segment *seg, union xhci_trb *trb)
> > {
> > if (ring == xhci->event_ring)
> > - return trb == &seg->trbs[TRBS_PER_SEGMENT];
> > + return trb == &seg->trbs[TRBS_PER_SEGMENT - 1];
> > else
> > return TRB_TYPE_LINK_LE32(trb->link.control);
> > }
>
>
> It would be extremely confusing for the above function to behave
> differently for event and other rings.
> Actually last_trb() could just be:
> return trb == seg->last_trb;
> provided an appropriate 'last_trb' field was set.
>
> If we assume that there are no empty ring segments (ie adjacent LINK TRBs),
> and that it is never actually called with a pointer to a link trb.
That second assumption is not true, unfortunately. inc_deq() is not the
only code that manipulates the ring->dequeue function. If we issue a
Set TR dequeue command to move the hardware dequeue pointer to a link
TRB (which we can do if the TD to be canceled ended just before the link
TRB), update_ring_for_set_deq_completion() will leave ring->dequeue
pointing to a link TRB. That means inc_deq() could be called with a
link TRB. So the code below would have to be changed to avoid updating
num_trbs_free in that case.
> Then the inc_deq() code could just be:
>
> ring->deq_updates++;
> ring->num_trbs_free++;
>
> if (last_trb(xhci, ring, ring->deq_seg, ++ring->dequeue)) {
> ring->deq_seg = ring->deq_seg->next;
> ring->dequeue = ring->deq_seg->trbs;
> if (ring->deq_seg == ring->first_seg) /* not sure of name */
> ring->cycle_state ^= 1;
> }
The cycle state is only changed when the enqueue pointer makes it past
the segment with the toggle bit. It shouldn't be modified for the
dequeue pointer.
And yes, inc_deq() could do with some simplification. David, are you
interested in creating a patch to simplify this code? I haven't gotten
v2 revisions from a couple of patches you previously sent, so I wasn't
sure if you're still interested in creating xHCI patches.
Sarah Sharp
--
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: "EHCI: BIOS handoff failed (BIOS bug?) 01010001" on Celeron N2805 (Bay Trail) / Gateway LT41P
On Tue, Dec 17, 2013 at 11:56:25AM -0500, Alan Stern wrote: > On Tue, 17 Dec 2013, Ken Harris wrote: > > > Sebastien: > > > > Thanks for the info. I just tried Linux 3.13.0-0.rc3.git5.1.fc21.i686 > > (from Fedora rawhide) and I still get the same error messages and USB > > still doesn't work. I saw a post about Atom Z3740D (Bay Trail-T) in a > > Dell Venue 8 Pro, and his USB works OK (but seems to use the xhci_hcd > > driver : > > > Whereas my Gateway LT41P uses ehci & ohci : > > > A clue? A workaround ? > > > >> [ 61.785031] pci :00:1d.0: EHCI: BIOS handoff failed (BIOS bug?) > > >> 01010001 > > Since the problem lies in the BIOS, you should check if any BIOS > updates are available. Are you enabling CONFIG_USB_XHCI_HCD in your .config? Maybe the BIOS expects your OS to switch the ports over to xHCI, but you don't have the driver compiled? If you do have CONFIG_USB_XHCI_HCD turned on for 3.13, please make sure CONFIG_USB_DEBUG is turned on as well, and send me the resulting dmesg, starting from boot. That should let me see which (if any) ports are being switched over from EHCI to xHCI. Other things to look for in your BIOS settings are things labeled "xHCI mode". It may have options like "enabled", "disabled", "Auto", or "Smart Auto". You want it to be set to either "enabled" or one of the "auto" options. Sarah Sharp -- 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 v7 2/9] staging: dwc2: update DT binding to add generic clock/phy properties
dwc2/s3c-hsotg require a single clock to be specified and optionally a generic phy. On the s3c-hsotg driver old style USB phy support is present as a fallback so the generic phy properties are optional. Signed-off-by: Matt Porter Acked-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/staging/dwc2.txt | 12 1 file changed, 12 insertions(+) diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt index 1a1b7cf..a1753ed 100644 --- a/Documentation/devicetree/bindings/staging/dwc2.txt +++ b/Documentation/devicetree/bindings/staging/dwc2.txt @@ -5,6 +5,14 @@ Required properties: - compatible : "snps,dwc2" - reg : Should contain 1 register range (address and length) - interrupts : Should contain 1 interrupt +- clocks: clock provider specifier +- clock-names: shall be "otg" +Refer to clk/clock-bindings.txt for generic clock consumer properties + +Optional properties: +- phys: phy provider specifier +- phy-names: shall be "device" +Refer to phy/phy-bindings.txt for generic phy consumer properties Example: @@ -12,4 +20,8 @@ Example: compatible = "ralink,rt3050-usb, snps,dwc2"; reg = <0x101c 4>; interrupts = <18>; + clocks = <&usb_otg_ahb_clk>; + clock-names = "otg"; + phys = <&usbphy>; + phy-names = "usb2-phy"; }; -- 1.8.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: xhci: Rename xhci_queue_xxx_tx() to xhci_queue_xxx_urb()
Hi David,
This patch is fine in general, however I can't seem to get it to apply.
I tried 3.12, 3.13-rc4, and my for-usb-next-queue branch, and `git am`
failed on all three kernels. Can you rebase this against either
3.13-rc4 or my for-usb-next-queue branch?
Thanks,
Sarah Sharp
On Wed, Nov 13, 2013 at 05:01:46PM -, David Laight wrote:
> The xhci_queue_bulk_tx() function is used for both OUT and IN
> transactions, but the name implies that it is only used for transmits.
> Rename it to xhci_queue_bulk_urb() to avoid any confusion.
>
> Similarly rename the functions for ctrl, intr and isoc URB.
> Rename the existing xhci_queue_isoc_tx() to write_isoc_trbs() to allow
> consistent naming.
>
> Signed-off-by: David Laight
> ---
> drivers/usb/host/xhci-ring.c | 16
> drivers/usb/host/xhci.c | 8
> drivers/usb/host/xhci.h | 8
> 3 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 8bce4c3..45a4cde 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -3146,7 +3146,7 @@ static void giveback_first_trb(struct xhci_hcd *xhci,
> int slot_id,
> * (comprised of sg list entries) can take several service intervals to
> * transmit.
> */
> -int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
> +int xhci_queue_intr_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
> struct urb *urb, int slot_id, unsigned int ep_index)
> {
> struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci,
> @@ -3174,7 +3174,7 @@ int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> urb->dev->speed == USB_SPEED_FULL)
> urb->interval /= 8;
> }
> - return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
> + return xhci_queue_bulk_urb(xhci, mem_flags, urb, slot_id, ep_index);
> }
>
> /*
> @@ -3228,7 +3228,7 @@ static u32 xhci_v1_0_td_remainder(int running_total,
> int trb_buff_len,
> return (total_packet_count - packets_transferred) << 17;
> }
>
> -int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
> +int xhci_queue_bulk_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
> struct urb *urb, int slot_id, unsigned int ep_index)
> {
> struct xhci_ring *ep_ring;
> @@ -3370,7 +3370,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t
> mem_flags,
> }
>
> /* Caller must have locked xhci->lock */
> -int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
> +int xhci_queue_ctrl_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
> struct urb *urb, int slot_id, unsigned int ep_index)
> {
> struct xhci_ring *ep_ring;
> @@ -3557,7 +3557,7 @@ static unsigned int
> xhci_get_last_burst_packet_count(struct xhci_hcd *xhci,
> }
>
> /* This is for isoc transfer */
> -static void xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
> +static void write_isoc_trbs(struct xhci_hcd *xhci, gfp_t mem_flags,
> struct urb *urb, int slot_id, unsigned int ep_index)
> {
> struct xhci_ring *ep_ring;
> @@ -3702,11 +3702,11 @@ static void xhci_queue_isoc_tx(struct xhci_hcd *xhci,
> gfp_t mem_flags,
> /*
> * Check transfer ring to guarantee there is enough room for the urb.
> * Update ISO URB start_frame and interval.
> - * Update interval as xhci_queue_intr_tx does. Just use xhci frame_index to
> + * Update interval as xhci_queue_intr_urb does. Just use xhci frame_index to
> * update the urb->start_frame by now.
> * Always assume URB_ISO_ASAP set, and NEVER use urb->start_frame as input.
> */
> -int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags,
> +int xhci_queue_isoc_urb(struct xhci_hcd *xhci, gfp_t mem_flags,
> struct urb *urb, int slot_id, unsigned int ep_index)
> {
> struct xhci_virt_device *xdev;
> @@ -3762,7 +3762,7 @@ int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci,
> gfp_t mem_flags,
> urb->interval /= 8;
> }
>
> - xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index);
> + write_isoc_trbs(xhci, mem_flags, urb, slot_id, ep_index);
> return 0;
> }
>
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 4f378f3..076292f 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1302,7 +1302,7 @@ int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb
> *urb, gfp_t mem_flags)
> spin_lock_irqsave(&xhci->lock, flags);
> if (xhci->xhc_state & XHCI_STATE_DYING)
> goto dying;
> - ret = xhci_queue_ctrl_tx(xhci, GFP_ATOMIC, urb,
> + ret = xhci_queue_ctrl_urb(xhci, GFP_ATOMIC, urb,
> slot_id, ep_index);
> if (ret)
> goto free_priv;
> @@ -1323,7 +1323,7 @@ int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb
> *urb, gfp_t me
Re: xhci_hcd debugging status, please?
On Mon, Dec 16, 2013 at 10:04:57AM +0100, Oliver Neukum wrote: > On Fri, 2013-12-13 at 14:39 +0100, Udo van den Heuvel wrote: > > On 2013-12-10 16:03, Oliver Neukum wrote: > > >> Thanks, but some of the messages look quite hardcoded. > > >> Is there a patch to get rid of them? > > > > > > More patches concerning dynamic debugging are in the queue for 3.14 > > > It looks like on your system it is by default switched on. You > > > can switch it off at boot time in the kernel command line as documented > > > in Documentation/dynamic-debug-howto.txt > > > > Default debugging is a bit unusual. > > Can we please change this so that my dmesg is left at peace by default? > > (unless really needed...) > > 3.14 should change it. Could you test that? 3.14 is not out. Do you mean Greg's usb-next queue? https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/log/?h=usb-next A simple fix is to turn off CONFIG_USB_DEBUG. That's what causes the xHCI dynamic debugging to be enabled by default. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] usb: ohci-at91: fix irq and iomem resource retrieval
Hello Greg,
Just a reminder to let you know this patch fixes a bug in the at91 ohci
driver
which appenrently showed up in 3.13-rc1 release, but is caused by bad
assumptions on platform device resources order.
Without this patch the ohci usb host controller is completely unusable
on at91
platforms.
Best Regards,
Boris
On 08/12/2013 15:59, Boris BREZILLON wrote:
When using dt resources retrieval (interrupts and reg properties) there is
no predefined order for these resources in the platform dev resources
table.
Retrieve resources using platform_get_resource and platform_get_irq
functions instead of direct resource table entries to avoid resource type
mismatch.
Signed-off-by: Boris BREZILLON
Acked-by: Nicolas Ferre
Signed-off-by: Alan Stern
Reviewed-by: Tomasz Figa
---
Changes since v3:
- replace platform_get_resource call with IORESOURCE_IRQ argument by
platform_get_irq
Changes since v2:
- split the patch series to isolate the urgent fix provided by this patch
Changes since v1:
- none
drivers/usb/host/ohci-at91.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 418444e..8c356af 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -136,23 +136,27 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
struct ohci_hcd *ohci;
int retval;
struct usb_hcd *hcd = NULL;
-
- if (pdev->num_resources != 2) {
- pr_debug("hcd probe: invalid num_resources");
- return -ENODEV;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ int irq;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_dbg(dev, "hcd probe: missing memory resource\n");
+ return -ENXIO;
}
- if ((pdev->resource[0].flags != IORESOURCE_MEM)
- || (pdev->resource[1].flags != IORESOURCE_IRQ)) {
- pr_debug("hcd probe: invalid resource type\n");
- return -ENODEV;
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_dbg(dev, "hcd probe: missing irq resource\n");
+ return irq;
}
hcd = usb_create_hcd(driver, &pdev->dev, "at91");
if (!hcd)
return -ENOMEM;
- hcd->rsrc_start = pdev->resource[0].start;
- hcd->rsrc_len = resource_size(&pdev->resource[0]);
+ hcd->rsrc_start = res->start;
+ hcd->rsrc_len = resource_size(res);
if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
pr_debug("request_mem_region failed\n");
@@ -199,7 +203,7 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
ohci->num_ports = board->ports;
at91_start_hc(pdev);
- retval = usb_add_hcd(hcd, pdev->resource[1].start, IRQF_SHARED);
+ retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval == 0)
return retval;
--
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: XHCI - USB3 HDD not recognised
On Sat, Dec 14, 2013 at 11:59:15AM +, Chris Clayton wrote: > On 12/13/13 16:38, Sarah Sharp wrote: > > On Fri, Dec 13, 2013 at 02:31:47PM +, Chris Clayton wrote: > >> Hi, > > > > Hi Chris, > > > > Hi Sarah and thanks for the reply. > > > Thanks for the bug report! > > > >> Firstly, I'm not subscribed, so please cc me on any replies. > >> > >> I see the problem I describe below on 3.12.[0..5] and on the current 3.13 > >> development kernel, including a kernel pulled > >> from Linus' tree just a few minutes ago. The diagnostics below and the > >> config file attached are from 3.12.5. I can > >> easily repeat on 3.13 if that would be more useful. > >> > >> My Fujitsu Lifebook AH531 laptop has an expresscard slot and I bought an > >> expresscard USB3.0 card. So, after looking at the two different dmesg outputs, I think either your host controller or the device is just not working at USB 3.0 speeds. When you hot-plug the device, the host doesn't give a port status event at all, so there's really nothing the xHCI driver can do. Even when you plug in the host with the hard drive attached, it only detects it as a USB 2.0 device. It really feels like the hardware is just broken. Have you tried this host and device combination under Windows? I hate to say it, but perhaps you want to try a different vendor for either the host or device? If you plug in other USB 2.0 or 1.1 devices into the xHCI expresscard, do those work? E.g. a mouse, keyboard, hub, etc. If they do, I would lean towards trying to find a replacement USB 3.0 hard drive. If they don't, I would try to replace the xHCI host. Or if the host is cheaper to replace, maybe try replacing that first? Sorry I can't be of more help, I just don't know how to fix this. The only thing I could possibly think would help is enabling the compliance mode polling. Maybe the USB 3.0 port is stuck in compliance mode, and can't give the xHCI host a port status change event? Can you send me the output of `sudo lspci -vvv -n` and `sudo lspci`? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] hso: fix problem with wrong status code sent by OPTION GTM601 during RING indication
On Tue, 2013-12-17 at 20:56 +0100, Dr. H. Nikolaus Schaller wrote:
> Hi Dan,
>
> Am 16.12.2013 um 20:40 schrieb Dan Williams:
>
> > On Fri, 2013-12-13 at 15:43 +0100, Dr. H. Nikolaus Schaller wrote:
> >> Hi,
> >>
> >> Am 02.10.2013 um 09:00 schrieb Dr. H. Nikolaus Schaller:
> >>
> >>> Hi Jan,
> >>>
> >>> we are using a GTM601 modem (Firmware 1.7) for a while and have spotted an
> >>> issue that under some conditions the modem sends a packed wIndex over USB
> >>> that is rejected by the hso driver making troubles afterwards. Not
> >>> rejecting makes
> >>> it work fine.
> >>>
> >>> BR,
> >>> Nikolaus Schaller
> >>>
> >>> ---
> >>>
> >>> From f5c7e15b61f2ce4fe3105ff914f6bfaf5d74af0d Mon Sep 17 00:00:00 2001
> >>> From: "H. Nikolaus Schaller"
> >>> Date: Thu, 15 Nov 2012 14:40:57 +0100
> >>> Subject: [PATCH 1/1] hso: fix problem with wrong status code sent by
> >>> OPTION
> >>> GTM601 during RING indication
> >>>
> >>> It has been observed that the GTM601 with 1.7 firmware sometimes sends a
> >>> value
> >>> wIndex that has bit 0x04 set instead of being reset as the code expects.
> >>> So we
> >>> mask it for the error check.
> >>>
> >>> See
> >>> http://lists.goldelico.com/pipermail/gta04-owner/2012-February/001643.html
> >>>
> >>> Signed-off-by: NeilBrown
> >>> Signed-off-by: H. Nikolaus Schaller
> >>> ---
> >>> drivers/net/usb/hso.c |3 ++-
> >>> 1 files changed, 2 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
> >>> index cba1d46..d146e26 100644
> >>> --- a/drivers/net/usb/hso.c
> >>> +++ b/drivers/net/usb/hso.c
> >>> @@ -1503,7 +1503,8 @@ static void tiocmget_intr_callback(struct urb *urb)
> >>> if (serial_state_notification->bmRequestType != BM_REQUEST_TYPE ||
> >>> serial_state_notification->bNotification != B_NOTIFICATION ||
> >>> le16_to_cpu(serial_state_notification->wValue) != W_VALUE ||
> >>> - le16_to_cpu(serial_state_notification->wIndex) != W_INDEX ||
> >>> + (le16_to_cpu(serial_state_notification->wIndex) & ~0x4) !=
> >>> + W_INDEX ||
> >>> le16_to_cpu(serial_state_notification->wLength) != W_LENGTH) {
> >>> dev_warn(&usb->dev,
> >>>"hso received invalid serial state notification\n");
> >>> --
> >>> 1.7.7.4
> >>>
> >>>
> >>
> >> I have found this (better) proposal by OPTION, but wonder what did happen
> >> to it.
> >> It neither shows in mainline 3.13-rc nor linux-next:
> >>
> >> https://lkml.org/lkml/2013/10/9/263
> >
> > Likely because nobody formally submitted the patch with a signed-off-by,
> > which indicates their intent that the patch is tested, correct, and can
> > be merged to the kernel.
>
> Ok, I see. I just wasn't aware of the proposal at all since I missed the
> discussion
> and wasn't on CC.
>
> Therefore I have added Eric to the CC.
>
> >
> > I looked at this today, and I'm left wondering how any port other than
> > HSO_PORT_MODEM can get the notification via tiocmget_intr_callback().
> > "serial->tiocmget" is only created for HSO_PORT_MODEM serial ports (see
> > hso_create_bulk_serial_device()):
> >
> > if ((port & HSO_PORT_MASK) == HSO_PORT_MODEM) {
> > num_urbs = 2;
> > serial->tiocmget = kzalloc(sizeof(struct hso_tiocmget),
> >GFP_KERNEL);
> >
> > and the code in tiocmget_intr_callback() does this:
> >
> > tiocmget = serial->tiocmget;
> > if (!tiocmget)
> > return;
> >
> > which should mean that only a HSO_PORT_MODEM will ever process the
> > notification. Further, the tiocmget interrupt URB is only created and
> > submitted if serial->tiocmget != NULL, so only HSO_PORT_MODEM should
> > ever be calling into tiocmget_intr_callback().
>
> Ok, that looks plausible.
>
> >
> > So I think Eric's patch is actually wrong because it will *always* pass
> > the new check.
> >
> > The original code had the correct intention, but the original code was
> > obviously wrong for newer devices where the port layout is read from
> > firmware and not from static tables, and thus for recent devices where
> > the modem interface is not USB interface #2.
>
> This explains why we did run into the problem with the GTM601.
>
> >
> > Can you confirm/deny that the 'modem' interface for your GTM601 is USB
> > interface #6? For example, my Icon 452 has the following USB interface
> > layout:
> >
> > 0: Diag
> > 1: GPS
> > 2: GPS control
> > 3: Application
> > 4: Control
> > 5: Network
> > 6: Modem
> >
> > So like the GTM601, I would expect any RING notifications to appear for
> > wIndex=0x06.
>
> Interestingly I see:
>
> 0: Diagnostic
> 1: GPS
> 2: GPS Control
> 3: Application
> 4: Control
> 5: Modem
>
> I.e. there is no Network interface. Originally we did focus on /dev/ttyHS3
How are you determining the number here? Are you using:
cat /sys/class/tty/ttyHS_Modem/device/bInterfaceNumber
to determine the actual USB interface number associated wi
USB sound auto-suspend not working
Hi Oliver and Takashi, I've noticed that in the last couple kernel releases or so, I can't get USB webcams to suspend. It turns out that the USB sound interface is keeping the device active, even when the device is not playing sound. This goes back as far as 3.10, but I haven't tried older kernels. This is testing on Ubuntu 13.10. Commit 88a8516a2128a6d078a106ead48092240e8a138f "ALSA: usbaudio: implement USB autosuspend" went into kernel 2.6.39. The commit message says the device is prevented from suspending if the pcm or midi channel files are open. I plugged in a USB speaker, and ran lsof to see which files were open (output is attached). AFAICT, only the USB sound device's control files are open, and I don't have any midi files. Any ideas as to why USB sound auto-suspend isn't working? Sarah Sharp -- 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: [alsa-devel] USB sound auto-suspend not working
On Tue, Dec 17, 2013 at 02:55:48PM -0800, Sarah Sharp wrote: > I plugged in a USB speaker, and ran lsof to see which files were open > (output is attached). AFAICT, only the USB sound device's control files > are open, and I don't have any midi files. The attachment seems to have gone AWOL (at least on the list)? signature.asc Description: Digital signature
Re: [PATCH 0/7] usb: dwc3: pm_runtime implementation
On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote: > hi all, > > these patches add pm_runtime support for all glue layers. > > I plan to add pm_runtime support for dwc3 after these > patches are merged upstream. > > Please test. At first time I failed to notice you were removing #ifdef's around pm callback functions. Instead of saying DWC3 will start to have warnings when CONFIG_PM is not selected, I'd say your patch set is now a dependence of my RFC :) https://lkml.org/lkml/2013/12/13/4 Br, David Cohen > > Felipe Balbi (7): > usb: dwc3: keystone: add basic PM support > usb: dwc3: omap: add basic pm_runtime support > usb: dwc3: pci: add pm_runtime support > usb: dwc3: omap: fix pm_runtime usage > usb: dwc3: omap: fix order of pm_runtime vs child removal > usb: dwc3: exynos: remove DEV_PM_OPS hackery > usb: dwc3: exynos: add pm_runtime support > > drivers/usb/dwc3/dwc3-exynos.c | 73 +++--- > drivers/usb/dwc3/dwc3-keystone.c | 97 > ++-- > drivers/usb/dwc3/dwc3-omap.c | 45 +++ > drivers/usb/dwc3/dwc3-pci.c | 66 --- > 4 files changed, 239 insertions(+), 42 deletions(-) > > -- > 1.8.4.GIT > > -- > 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 0/7] usb: dwc3: pm_runtime implementation
On Tue, Dec 17, 2013 at 03:31:40PM -0800, David Cohen wrote: > On Thu, Dec 12, 2013 at 03:38:38PM -0600, Felipe Balbi wrote: > > hi all, > > > > these patches add pm_runtime support for all glue layers. > > > > I plan to add pm_runtime support for dwc3 after these > > patches are merged upstream. > > > > Please test. > > At first time I failed to notice you were removing #ifdef's around pm > callback functions. Instead of saying DWC3 will start to have warnings > when CONFIG_PM is not selected, I'd say your patch set is now a > dependence of my RFC :) I guess I said it in wrong order :P Your patch set depends on my RFC. > https://lkml.org/lkml/2013/12/13/4 > > Br, David Cohen > > > > > Felipe Balbi (7): > > usb: dwc3: keystone: add basic PM support > > usb: dwc3: omap: add basic pm_runtime support > > usb: dwc3: pci: add pm_runtime support > > usb: dwc3: omap: fix pm_runtime usage > > usb: dwc3: omap: fix order of pm_runtime vs child removal > > usb: dwc3: exynos: remove DEV_PM_OPS hackery > > usb: dwc3: exynos: add pm_runtime support > > > > drivers/usb/dwc3/dwc3-exynos.c | 73 +++--- > > drivers/usb/dwc3/dwc3-keystone.c | 97 > > ++-- > > drivers/usb/dwc3/dwc3-omap.c | 45 +++ > > drivers/usb/dwc3/dwc3-pci.c | 66 --- > > 4 files changed, 239 insertions(+), 42 deletions(-) > > > > -- > > 1.8.4.GIT > > > > -- > > 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
[PATCH v2 3/3] usb: musb: fix setting JZ4740 gadget periphal mode on reset
JZ4740 USB Device Controller is not OTG compatible and does not have
DEVCTL register in silicon.
During ethernet-over-usb transactions, on reset, musb driver tries to
read from DEVCTL and consequently sets device as host (A-Device)
instead of peripheral (B-Device), which makes it a composite device to
the USB gadget driver.
This induces a kernel panic during power down where the USB gadget
driver does a null pointer dereference when trying to access the
composite device configuration.
On reset, do not rely on DEVCTL value for setting gadget peripheral
mode. Use is_otg flag instead to set it to B-Device.
Signed-off-by: Apelete Seketeli
---
drivers/usb/musb/musb_gadget.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 32fb057..cb50163 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2119,7 +2119,15 @@ __acquires(musb->lock)
/* Normal reset, as B-Device;
* or else after HNP, as A-Device
*/
- if (devctl & MUSB_DEVCTL_BDEVICE) {
+ if (!musb->g.is_otg) {
+ /* USB device controllers that are not OTG compatible
+* may not have DEVCTL register in silicon.
+* In that case, do not rely on devctl for setting
+* peripheral mode.
+*/
+ musb->xceiv->state = OTG_STATE_B_PERIPHERAL;
+ musb->g.is_a_peripheral = 0;
+ } else if (devctl & MUSB_DEVCTL_BDEVICE) {
musb->xceiv->state = OTG_STATE_B_PERIPHERAL;
musb->g.is_a_peripheral = 0;
} else {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] usb: musb: add support for JZ4740 usb device controller
Add support for Ingenic JZ4740 USB Device Controller through a
specific musb glue layer.
The platform data already available in tree for that USB Device
Controller was previously used by an out-of-tree USB gadget driver
which was not relying on the musb driver and was written by Ingenic
and the Qi-Hardware community.
JZ4740 UDC not being OTG compatible and missing some hardware
registers, this musb glue layer is written from scratch to be used in
gadget mode only and take silicon design specifics into account.
Signed-off-by: Apelete Seketeli
Signed-off-by: Lars-Peter Clausen
---
arch/mips/include/asm/mach-jz4740/platform.h |1 +
arch/mips/jz4740/board-qi_lb60.c |1 +
arch/mips/jz4740/platform.c | 40 +++--
drivers/usb/musb/Kconfig |8 +-
drivers/usb/musb/Makefile|1 +
drivers/usb/musb/jz4740.c| 201 ++
6 files changed, 235 insertions(+), 17 deletions(-)
create mode 100644 drivers/usb/musb/jz4740.c
diff --git a/arch/mips/include/asm/mach-jz4740/platform.h
b/arch/mips/include/asm/mach-jz4740/platform.h
index 05988c2..069b43a 100644
--- a/arch/mips/include/asm/mach-jz4740/platform.h
+++ b/arch/mips/include/asm/mach-jz4740/platform.h
@@ -21,6 +21,7 @@
extern struct platform_device jz4740_usb_ohci_device;
extern struct platform_device jz4740_udc_device;
+extern struct platform_device jz4740_udc_xceiv_device;
extern struct platform_device jz4740_mmc_device;
extern struct platform_device jz4740_rtc_device;
extern struct platform_device jz4740_i2c_device;
diff --git a/arch/mips/jz4740/board-qi_lb60.c b/arch/mips/jz4740/board-qi_lb60.c
index 8a5ec0e..c01900e 100644
--- a/arch/mips/jz4740/board-qi_lb60.c
+++ b/arch/mips/jz4740/board-qi_lb60.c
@@ -427,6 +427,7 @@ static struct platform_device qi_lb60_audio_device = {
static struct platform_device *jz_platform_devices[] __initdata = {
&jz4740_udc_device,
+ &jz4740_udc_xceiv_device,
&jz4740_mmc_device,
&jz4740_nand_device,
&qi_lb60_keypad,
diff --git a/arch/mips/jz4740/platform.c b/arch/mips/jz4740/platform.c
index df65677..1be41e2 100644
--- a/arch/mips/jz4740/platform.c
+++ b/arch/mips/jz4740/platform.c
@@ -21,6 +21,8 @@
#include
+#include
+
#include
#include
#include
@@ -56,29 +58,35 @@ struct platform_device jz4740_usb_ohci_device = {
.resource = jz4740_usb_ohci_resources,
};
-/* UDC (USB gadget controller) */
-static struct resource jz4740_usb_gdt_resources[] = {
- {
- .start = JZ4740_UDC_BASE_ADDR,
- .end= JZ4740_UDC_BASE_ADDR + 0x1000 - 1,
- .flags = IORESOURCE_MEM,
+/* USB Device Controller */
+struct platform_device jz4740_udc_xceiv_device = {
+ .name = "usb_phy_gen_xceiv",
+ .id = 0,
+};
+
+static struct resource jz4740_udc_resources[] = {
+ [0] = {
+ .start = JZ4740_UDC_BASE_ADDR,
+ .end = JZ4740_UDC_BASE_ADDR + 0x1 - 1,
+ .flags = IORESOURCE_MEM,
},
- {
- .start = JZ4740_IRQ_UDC,
- .end= JZ4740_IRQ_UDC,
- .flags = IORESOURCE_IRQ,
+ [1] = {
+ .start = JZ4740_IRQ_UDC,
+ .end = JZ4740_IRQ_UDC,
+ .flags = IORESOURCE_IRQ,
+ .name = "mc",
},
};
struct platform_device jz4740_udc_device = {
- .name = "jz-udc",
- .id = -1,
- .dev = {
- .dma_mask = &jz4740_udc_device.dev.coherent_dma_mask,
+ .name = "musb-jz4740",
+ .id = -1,
+ .dev = {
+ .dma_mask = &jz4740_udc_device.dev.coherent_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
},
- .num_resources = ARRAY_SIZE(jz4740_usb_gdt_resources),
- .resource = jz4740_usb_gdt_resources,
+ .num_resources = ARRAY_SIZE(jz4740_udc_resources),
+ .resource = jz4740_udc_resources,
};
/* MMC/SD controller */
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 57dfc0c..a45ed15 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -93,6 +93,12 @@ config USB_MUSB_BLACKFIN
config USB_MUSB_UX500
tristate "Ux500 platforms"
+config USB_MUSB_JZ4740
+ tristate "JZ4740"
+ depends on MACH_JZ4740
+ depends on USB_MUSB_GADGET
+ depends on USB_OTG_BLACKLIST_HUB
+
endchoice
config USB_MUSB_AM335X_CHILD
@@ -100,7 +106,7 @@ config USB_MUSB_AM335X_CHILD
choice
prompt 'MUSB DMA mode'
- default MUSB_PIO_ONLY if ARCH_MULTIPLATFORM
+ default MUSB_PIO_ONLY if ARCH_MULTIPLATFORM || USB_MUSB_JZ4740
default USB_UX500_DMA if USB_MUSB_UX500
default USB_INVENTRA_DMA if USB_MUSB_OMAP2PLUS || USB_MUSB_BLACKFIN
default USB_TI_CPPI_DMA if USB_MUSB_DAVINCI
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Mak
[PATCH v2 0/3] Add USB support for Ingenic JZ4740
Hello, Following the fix I submitted a few weeks ago, here is a set of patches that adds USB support for the Ingenic JZ4740 MIPS SoC. The JZ4740 is found in the Ben NanoNote handheld computer which is built by the Qi-Hardware community. Even though Ben NanoNote is already supported in the kernel, we were relying on an out-of-tree gadget driver to make use of the JZ4740 USB Device Controller. The patches that come as a follow-up of this message are an attempt to provide USB support through an musb glue layer. Changes since v1: - usb: musb-jz4740: Don't manually free device managed resources - usb: musb-jz4740: Move musb_hdrc_config to the glue driver - usb: musb-jz4740: Move jz4740 specific fifo config to the jz4740 glue - usb: musb-jz4740: Mask host mode only IRQ bits - usb: musb-jz4740: Remove set_vbus callback - usb: musb_gadget: Use is_otg flag to set gadget peripheral mode on reset Changes were rebased on top of Felipe Balbi's USB Subsystem master branch, built and tested on device successfully. The following changes since commit 9bdff34517bc49d8e98558659e077ea9f9df3d60: Merge branch 'next' are available in the git repository at: git://seketeli.fr/~apelete/linux-usb.git musb-jz4740 Apelete Seketeli (3): mips: qi_lb60: add defconfig for Ben NanoNote usb: musb: add support for JZ4740 usb device controller usb: musb: fix setting JZ4740 gadget periphal mode on reset arch/mips/configs/qi_lb60_defconfig | 188 arch/mips/include/asm/mach-jz4740/platform.h |1 + arch/mips/jz4740/board-qi_lb60.c |1 + arch/mips/jz4740/platform.c | 40 +++-- drivers/usb/musb/Kconfig |8 +- drivers/usb/musb/Makefile|1 + drivers/usb/musb/jz4740.c| 201 ++ drivers/usb/musb/musb_gadget.c | 10 +- 8 files changed, 432 insertions(+), 18 deletions(-) create mode 100644 arch/mips/configs/qi_lb60_defconfig create mode 100644 drivers/usb/musb/jz4740.c -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] mips: qi_lb60: add defconfig for Ben NanoNote
Add defconfig for the Ben NanoNote handheld computer which is built around QI_LB60 board and Ingenic JZ4740 MIPS SoC. Signed-off-by: Apelete Seketeli --- arch/mips/configs/qi_lb60_defconfig | 188 +++ 1 file changed, 188 insertions(+) create mode 100644 arch/mips/configs/qi_lb60_defconfig diff --git a/arch/mips/configs/qi_lb60_defconfig b/arch/mips/configs/qi_lb60_defconfig new file mode 100644 index 000..2b96547 --- /dev/null +++ b/arch/mips/configs/qi_lb60_defconfig @@ -0,0 +1,188 @@ +CONFIG_MACH_JZ4740=y +# CONFIG_COMPACTION is not set +# CONFIG_CROSS_MEMORY_ATTACH is not set +CONFIG_HZ_100=y +CONFIG_PREEMPT=y +# CONFIG_SECCOMP is not set +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SYSVIPC=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS_ALL=y +CONFIG_EMBEDDED=y +# CONFIG_VM_EVENT_COUNTERS is not set +# CONFIG_COMPAT_BRK is not set +CONFIG_SLAB=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y +# CONFIG_EFI_PARTITION is not set +# CONFIG_IOSCHED_CFQ is not set +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_IP_MROUTE=y +CONFIG_IP_MROUTE_MULTIPLE_TABLES=y +# CONFIG_INET_XFRM_MODE_TRANSPORT is not set +# CONFIG_INET_XFRM_MODE_TUNNEL is not set +# CONFIG_INET_XFRM_MODE_BEET is not set +# CONFIG_INET_LRO is not set +# CONFIG_INET_DIAG is not set +CONFIG_TCP_CONG_ADVANCED=y +# CONFIG_TCP_CONG_BIC is not set +# CONFIG_TCP_CONG_CUBIC is not set +CONFIG_TCP_CONG_WESTWOOD=y +# CONFIG_TCP_CONG_HTCP is not set +# CONFIG_IPV6 is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +# CONFIG_FIRMWARE_IN_KERNEL is not set +CONFIG_MTD=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_NAND=y +CONFIG_MTD_NAND_JZ4740=y +CONFIG_MTD_UBI=y +CONFIG_NETDEVICES=y +# CONFIG_WLAN is not set +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +# CONFIG_KEYBOARD_ATKBD is not set +CONFIG_KEYBOARD_GPIO=y +CONFIG_KEYBOARD_MATRIX=y +# CONFIG_INPUT_MOUSE is not set +CONFIG_INPUT_MISC=y +# CONFIG_SERIO is not set +CONFIG_LEGACY_PTY_COUNT=2 +# CONFIG_DEVKMEM is not set +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +# CONFIG_SERIAL_8250_DMA is not set +CONFIG_SERIAL_8250_NR_UARTS=2 +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +# CONFIG_HW_RANDOM is not set +CONFIG_SPI=y +CONFIG_SPI_GPIO=y +CONFIG_POWER_SUPPLY=y +CONFIG_BATTERY_JZ4740=y +CONFIG_CHARGER_GPIO=y +# CONFIG_HWMON is not set +CONFIG_MFD_JZ4740_ADC=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_FB=y +CONFIG_FB_JZ4740=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y +# CONFIG_BACKLIGHT_CLASS_DEVICE is not set +# CONFIG_VGA_CONSOLE is not set +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_LOGO=y +# CONFIG_LOGO_LINUX_MONO is not set +# CONFIG_LOGO_LINUX_VGA16 is not set +# CONFIG_LOGO_LINUX_CLUT224 is not set +CONFIG_SOUND=y +CONFIG_SND=y +# CONFIG_SND_SUPPORT_OLD_API is not set +# CONFIG_SND_VERBOSE_PROCFS is not set +# CONFIG_SND_DRIVERS is not set +# CONFIG_SND_SPI is not set +# CONFIG_SND_MIPS is not set +CONFIG_SND_SOC=y +CONFIG_SND_JZ4740_SOC=y +CONFIG_SND_JZ4740_SOC_QI_LB60=y +CONFIG_USB=y +CONFIG_USB_OTG_BLACKLIST_HUB=y +CONFIG_USB_MUSB_HDRC=y +CONFIG_USB_MUSB_GADGET=y +CONFIG_USB_MUSB_JZ4740=y +CONFIG_NOP_USB_XCEIV=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DEBUG=y +CONFIG_USB_ETH=y +# CONFIG_USB_ETH_RNDIS is not set +CONFIG_MMC=y +CONFIG_MMC_UNSAFE_RESUME=y +# CONFIG_MMC_BLOCK_BOUNCE is not set +CONFIG_MMC_JZ4740=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_JZ4740=y +CONFIG_DMADEVICES=y +CONFIG_DMA_JZ4740=y +CONFIG_PWM=y +CONFIG_PWM_JZ4740=y +CONFIG_EXT2_FS=y +CONFIG_EXT3_FS=y +# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set +# CONFIG_EXT3_FS_XATTR is not set +# CONFIG_DNOTIFY is not set +CONFIG_VFAT_FS=y +CONFIG_PROC_KCORE=y +# CONFIG_PROC_PAGE_MONITOR is not set +CONFIG_TMPFS=y +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_SUMMARY=y +CONFIG_JFFS2_COMPRESSION_OPTIONS=y +# CONFIG_JFFS2_ZLIB is not set +CONFIG_UBIFS_FS=y +CONFIG_UBIFS_FS_ADVANCED_COMPR=y +# CONFIG_NETWORK_FILESYSTEMS is not set +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_CODEPAGE_737=y +CONFIG_NLS_CODEPAGE_775=y +CONFIG_NLS_CODEPAGE_850=y +CONFIG_NLS_CODEPAGE_852=y +CONFIG_NLS_CODEPAGE_855=y +CONFIG_NLS_CODEPAGE_857=y +CONFIG_NLS_CODEPAGE_860=y +CONFIG_NLS_CODEPAGE_861=y +CONFIG_NLS_CODEPAGE_862=y +CONFIG_NLS_CODEPAGE_863=y +CONFIG_NLS_CODEPAGE_864=y +CONFIG_NLS_CODEPAGE_865=y +CONFIG_NLS_CODEPAGE_866=y +CONFIG_NLS_CODEPAGE_869=y +CONFIG_NLS_CODEPAGE_936=y +CONFIG_NLS_CODEPAGE_950=y +CONFIG_NLS_CODEPAGE_932=y +CONFIG_NLS_CODEPAGE_949=y +CONFIG_NLS_CODEPAGE_874=y +CONFIG_NLS_ISO8859_8=y +CONFIG_NLS_CODEPAGE_1250=y +CONFIG_NLS_CODEPAGE_1251=y +CONFIG_NLS_ASCII=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_ISO8859_2=y +CONFIG_NLS_ISO8859_3=y +CONFIG_NLS_ISO8859_4=y +CONFIG_NLS_ISO8859_5=y +CONFIG_NLS_ISO8859_6=y +CON
RE: [PATCH v4 3/9] phy: Add new Exynos USB PHY driver
Hi Kamil, > Hi Anton, > > > From: Anton Tikhomirov [mailto:av.tikhomi...@samsung.com] > > Sent: Tuesday, December 10, 2013 3:43 AM > > > > Hi Kamil, > > > > Same USB2.0 PHY may be used by several HCDs, for example EHCI and > OHCI. > > Consider the situation, when EHCI stops using the PHY and calls > > power_off, then OHCI becomes non-operational. In other words, PHY > > power_on and power_off calls must be balanced. > > > > Shall we handle it in your driver? (usage count?) > > Please look in the drivers/phy/phy-core.c file. Usage count is handled > there - see phy_power_on and phy_power_off functions. I understand that > after both EHCI and OHCI power on the phy, the usage count is 2. So > powering off one of them (EHCI for instance) the usage count is still > 1, so the OHCI should still work properly. Oops, sorry, missed that. > > [snip] > > Best wishes, > -- > Kamil Debski > Samsung R&D Institute Poland -- 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: "EHCI: BIOS handoff failed (BIOS bug?) 01010001" on Celeron N2805 (Bay Trail) / Gateway LT41P
On Tue, Dec 17, 2013 at 1:03 PM, Sarah Sharp wrote: >> On Tue, 17 Dec 2013, Ken Harris wrote: >> > Sebastien: >> > >> > Thanks for the info. I just tried Linux 3.13.0-0.rc3.git5.1.fc21.i686 >> > (from Fedora rawhide) and I still get the same error messages and USB >> > still doesn't work. I saw a post about Atom Z3740D (Bay Trail-T) in a >> > Dell Venue 8 Pro, and his USB works OK (but seems to use the xhci_hcd >> > driver : >> >> > Whereas my Gateway LT41P uses ehci & ohci > Are you enabling CONFIG_USB_XHCI_HCD in your .config? Maybe the BIOS > expects your OS to switch the ports over to xHCI, but you don't have the > driver compiled? > If you do have CONFIG_USB_XHCI_HCD turned on for 3.13, please make sure > CONFIG_USB_DEBUG is turned on as well, and send me the resulting dmesg, > starting from boot. That should let me see which (if any) ports are > being switched over from EHCI to xHCI. > Other things to look for in your BIOS settings are things labeled "xHCI > mode". It may have options like "enabled", "disabled", "Auto", or > "Smart Auto". You want it to be set to either "enabled" or one of the > "auto" options. > > Sarah Sharp Sarah ! Thanks for looking at this. Yes, Fedora has CONFIG_USB_XHCI_HCD=y . When you say, "switch the ports over to xHCI" ... I assume your mean this patch : [PATCH] xhci: Add BayTrail to list of Intel switchable hosts ( http://www.spinics.net/lists/linux-usb/msg86204.html ). I don't see CONFIG_USB_DEBUG set in Fedora, but they do distribute debug kernels (eg : kernel-PAEdebug-3.11.10-301.fc20.i686 ), so perhaps that includes setting CONFIG_USB_DEBUG ? My original post has the output of a debug kernel : http://www.spinics.net/lists/linux-usb/msg99549.html . If that's not good enough, I can try to compile a kernel with CONFIG_USB_DEBUG, but it looks like there is no "xHCI switch" code in Fedora: >From my (noobish) reading of the Fedora source ( http://mirrors.kernel.org/fedora/development/rawhide/source/SRPMS/k/kernel-3.13.0-0.rc3.git5.1.fc21.src.rpm : linux-3.12 patch-3.13-rc3 patch-3.13-rc3-git5 ), I don't see any reference to the switchable code (ie : 'find -type f |xargs egrep "PCI_DEVICE_ID_INTEL_LYNX_POINT|intel_switchabl"' returns nothing). FYI, I filed a Redhat bug : https://bugzilla.redhat.com/show_bug.cgi?id=1039245 FYI, my BIOS doesn't have any USB options (just AHCI). FYI, the Dell Venue 8 Pro user (adam) is also using Fedora, but I suspect that his BIOS has enabled xHCI, so he doesn't need the "xHCI switchable" code. I haven't built a kernel in a while, but I can try to apply the patch and see if that fixed the problem. Thanks again, Ken -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xhci_suspend optimized for hibernate
This patch improves xhci suspend time during a hibernate call by
removing redundant saves and stores. It adds a new hc_driver callback
called pci_poweroff which any host can define. It will be called on
hibernate instead of pci_suspend if it exists. The patch then implements
this call for xhci (xhci_pci_poweroff), which instructs xhci_suspend to
skip any calls which save the current state, since the hibernate image
has already been generate and all subsequent info will be lost. This
improves the suspend time by a bit.
This is a patch is an implementation of a feature suggested by Alan
Stern and Sarah Sharp: http://marc.info/?l=linux-usb&m=136147059529127&w=2
xhci_suspend is called both during system suspend, and after the memory image
is created during system hibernate. On suspend, the driver directs the xHC to
save registers (and anything in scratchpad pages), and does a bunch of other
cleanup. On resume from suspend, the registers, pages, and dequeue pointers
are restored. On hibernate, we also save state. However, xhci_suspend is
called after the hibernate memory image is created, so any memory writes
(e.g. to zero rings or save dequeue pointers) will be lost on resume. On
resume from hibernate, we basically wipe out any changes in the host and
driver, and re-initialize from scratch. So it's useless to save state when
xhci_suspend is called as part of the hibernate state. - Sarah Sharp
Signed-off-by: Todd Brandt
drivers/usb/core/hcd-pci.c | 27 ---
drivers/usb/host/xhci-pci.c | 18 +-
drivers/usb/host/xhci-plat.c | 2 +-
drivers/usb/host/xhci.c | 30 +-
drivers/usb/host/xhci.h | 2 +-
include/linux/usb/hcd.h | 3 +++
6 files changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index dfe9d0f..1499da5 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -428,7 +428,8 @@ static int check_root_hub_suspended(struct device *dev)
}
#if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
-static int suspend_common(struct device *dev, bool do_wakeup)
+static int suspend_common(struct device *dev, bool do_wakeup,
+ unsigned int pm_event)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
struct usb_hcd *hcd = pci_get_drvdata(pci_dev);
@@ -452,9 +453,15 @@ static int suspend_common(struct device *dev, bool
do_wakeup)
if (do_wakeup && hcd->shared_hcd &&
HCD_WAKEUP_PENDING(hcd->shared_hcd))
return -EBUSY;
- retval = hcd->driver->pci_suspend(hcd, do_wakeup);
- suspend_report_result(hcd->driver->pci_suspend, retval);
-
+ if ((pm_event == PM_EVENT_HIBERNATE) &&
+ hcd->driver->pci_poweroff) {
+ retval = hcd->driver->pci_poweroff(hcd);
+ suspend_report_result(hcd->driver->pci_poweroff,
+ retval);
+ } else {
+ retval = hcd->driver->pci_suspend(hcd, do_wakeup);
+ suspend_report_result(hcd->driver->pci_suspend, retval);
+ }
/* Check again in case wakeup raced with pci_suspend */
if ((retval == 0 && do_wakeup && HCD_WAKEUP_PENDING(hcd)) ||
(retval == 0 && do_wakeup && hcd->shared_hcd &&
@@ -532,7 +539,12 @@ static int resume_common(struct device *dev, int event)
static int hcd_pci_suspend(struct device *dev)
{
- return suspend_common(dev, device_may_wakeup(dev));
+ return suspend_common(dev, device_may_wakeup(dev), PM_EVENT_SUSPEND);
+}
+
+static int hcd_pci_poweroff(struct device *dev)
+{
+ return suspend_common(dev, device_may_wakeup(dev), PM_EVENT_HIBERNATE);
}
static int hcd_pci_suspend_noirq(struct device *dev)
@@ -598,6 +610,7 @@ static int hcd_pci_restore(struct device *dev)
#else
#define hcd_pci_suspendNULL
+#define hcd_pci_poweroff NULL
#define hcd_pci_suspend_noirq NULL
#define hcd_pci_resume_noirq NULL
#define hcd_pci_resume NULL
@@ -611,7 +624,7 @@ static int hcd_pci_runtime_suspend(struct device *dev)
{
int retval;
- retval = suspend_common(dev, true);
+ retval = suspend_common(dev, true, PM_EVENT_SUSPEND);
if (retval == 0)
powermac_set_asic(to_pci_dev(dev), 0);
dev_dbg(dev, "hcd_pci_runtime_suspend: %d\n", retval);
@@ -644,7 +657,7 @@ const struct dev_pm_ops usb_hcd_pci_pm_ops = {
.freeze_noirq = check_root_hub_suspended,
.thaw_noirq = NULL,
.thaw = NULL,
- .poweroff = hcd_pci_suspend,
+ .poweroff = hcd_pci_poweroff,
.poweroff_noirq = hcd_pci_suspend_noirq,
.restore_noirq = hcd_pci_resume_noirq,
.restore= hcd_pci_
Re: "EHCI: BIOS handoff failed (BIOS bug?) 01010001" on Celeron N2805 (Bay Trail) / Gateway LT41P
Ken Harris wrote: >On Tue, Dec 17, 2013 at 1:03 PM, Sarah Sharp > wrote: > >>> On Tue, 17 Dec 2013, Ken Harris wrote: > >>> > Sebastien: >>> > >>> > Thanks for the info. I just tried Linux >3.13.0-0.rc3.git5.1.fc21.i686 >>> > (from Fedora rawhide) and I still get the same error messages and >USB >>> > still doesn't work. I saw a post about Atom Z3740D (Bay Trail-T) >in a >>> > Dell Venue 8 Pro, and his USB works OK (but seems to use the >xhci_hcd >>> > driver : >>> >>> > Whereas my Gateway LT41P uses ehci & ohci > >> Are you enabling CONFIG_USB_XHCI_HCD in your .config? Maybe the BIOS >> expects your OS to switch the ports over to xHCI, but you don't have >the >> driver compiled? > >> If you do have CONFIG_USB_XHCI_HCD turned on for 3.13, please make >sure >> CONFIG_USB_DEBUG is turned on as well, and send me the resulting >dmesg, >> starting from boot. That should let me see which (if any) ports are >> being switched over from EHCI to xHCI. > >> Other things to look for in your BIOS settings are things labeled >"xHCI >> mode". It may have options like "enabled", "disabled", "Auto", or >> "Smart Auto". You want it to be set to either "enabled" or one of >the >> "auto" options. >> >> Sarah Sharp > >Sarah ! > >Thanks for looking at this. > >Yes, Fedora has CONFIG_USB_XHCI_HCD=y . When you say, "switch the >ports over to xHCI" ... I assume your mean this patch : > >[PATCH] xhci: Add BayTrail to list of Intel switchable hosts ( >http://www.spinics.net/lists/linux-usb/msg86204.html ). > >I don't see CONFIG_USB_DEBUG set in Fedora, but they do distribute >debug kernels (eg : kernel-PAEdebug-3.11.10-301.fc20.i686 ), so >perhaps that includes setting CONFIG_USB_DEBUG ? My original post has >the output of a debug kernel : >http://www.spinics.net/lists/linux-usb/msg99549.html . > >If that's not good enough, I can try to compile a kernel with >CONFIG_USB_DEBUG, but it looks like there is no "xHCI switch" code in >Fedora: > >From my (noobish) reading of the Fedora source ( >http://mirrors.kernel.org/fedora/development/rawhide/source/SRPMS/k/kernel-3.13.0-0.rc3.git5.1.fc21.src.rpm >: linux-3.12 patch-3.13-rc3 patch-3.13-rc3-git5 ), I don't see any >reference to the switchable code (ie : 'find -type f |xargs egrep >"PCI_DEVICE_ID_INTEL_LYNX_POINT|intel_switchabl"' returns nothing). > >FYI, I filed a Redhat bug : >https://bugzilla.redhat.com/show_bug.cgi?id=1039245 > >FYI, my BIOS doesn't have any USB options (just AHCI). > >FYI, the Dell Venue 8 Pro user (adam) is also using Fedora, but I >suspect that his BIOS has enabled xHCI, so he doesn't need the "xHCI >switchable" code. > >I haven't built a kernel in a while, but I can try to apply the patch >and see if that fixed the problem. > >Thanks again, >Ken USB does seem to work without much trouble on the v8p, yeah (one of the few things that does). I've been busy with the fedora 20 release, but I'll probably get back to playing with it in a day or two. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net http://www.happyassassin.net -- 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: "EHCI: BIOS handoff failed (BIOS bug?) 01010001" on Celeron N2805 (Bay Trail) / Gateway LT41P
FYI, when I boot MS Windows 8.1, it says the USB controller is "Intel EHCI 0F34" (w/ "usbehci.sys" driver). On Tue, Dec 17, 2013 at 7:12 PM, Adam Williamson wrote: > Ken Harris wrote: >>On Tue, Dec 17, 2013 at 1:03 PM, Sarah Sharp >> wrote: >> On Tue, 17 Dec 2013, Ken Harris wrote: >> > Sebastien: > > Thanks for the info. I just tried Linux >>3.13.0-0.rc3.git5.1.fc21.i686 > (from Fedora rawhide) and I still get the same error messages and >>USB > still doesn't work. I saw a post about Atom Z3740D (Bay Trail-T) >>in a > Dell Venue 8 Pro, and his USB works OK (but seems to use the >>xhci_hcd > driver : > Whereas my Gateway LT41P uses ehci & ohci >> >>> Are you enabling CONFIG_USB_XHCI_HCD in your .config? Maybe the BIOS >>> expects your OS to switch the ports over to xHCI, but you don't have >>the >>> driver compiled? >> >>> If you do have CONFIG_USB_XHCI_HCD turned on for 3.13, please make >>sure >>> CONFIG_USB_DEBUG is turned on as well, and send me the resulting >>dmesg, >>> starting from boot. That should let me see which (if any) ports are >>> being switched over from EHCI to xHCI. >> >>> Other things to look for in your BIOS settings are things labeled >>"xHCI >>> mode". It may have options like "enabled", "disabled", "Auto", or >>> "Smart Auto". You want it to be set to either "enabled" or one of >>the >>> "auto" options. >>> >>> Sarah Sharp >> >>Sarah ! >> >>Thanks for looking at this. >> >>Yes, Fedora has CONFIG_USB_XHCI_HCD=y . When you say, "switch the >>ports over to xHCI" ... I assume your mean this patch : >> >>[PATCH] xhci: Add BayTrail to list of Intel switchable hosts ( >>http://www.spinics.net/lists/linux-usb/msg86204.html ). >> >>I don't see CONFIG_USB_DEBUG set in Fedora, but they do distribute >>debug kernels (eg : kernel-PAEdebug-3.11.10-301.fc20.i686 ), so >>perhaps that includes setting CONFIG_USB_DEBUG ? My original post has >>the output of a debug kernel : >>http://www.spinics.net/lists/linux-usb/msg99549.html . >> >>If that's not good enough, I can try to compile a kernel with >>CONFIG_USB_DEBUG, but it looks like there is no "xHCI switch" code in >>Fedora: >> > >From my (noobish) reading of the Fedora source ( >>http://mirrors.kernel.org/fedora/development/rawhide/source/SRPMS/k/kernel-3.13.0-0.rc3.git5.1.fc21.src.rpm >>: linux-3.12 patch-3.13-rc3 patch-3.13-rc3-git5 ), I don't see any >>reference to the switchable code (ie : 'find -type f |xargs egrep >>"PCI_DEVICE_ID_INTEL_LYNX_POINT|intel_switchabl"' returns nothing). >> >>FYI, I filed a Redhat bug : >>https://bugzilla.redhat.com/show_bug.cgi?id=1039245 >> >>FYI, my BIOS doesn't have any USB options (just AHCI). >> >>FYI, the Dell Venue 8 Pro user (adam) is also using Fedora, but I >>suspect that his BIOS has enabled xHCI, so he doesn't need the "xHCI >>switchable" code. >> >>I haven't built a kernel in a while, but I can try to apply the patch >>and see if that fixed the problem. >> >>Thanks again, >>Ken > > USB does seem to work without much trouble on the v8p, yeah (one of the few > things that does). I've been busy with the fedora 20 release, but I'll > probably get back to playing with it in a day or two. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net > http://www.happyassassin.net -- 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: dwc3: ep0: Handle variable-length Data Stage
Hi,
On Tue, Dec 17, 2013 at 03:59:31PM +0900, Anton Tikhomirov wrote:
> In accordance with specification, when sent data length is
please mention section of specification.
> an exact multiple of wMaxPacketSize for the pipe and less
> than requested by host, the function shall return a zero-length
> packet (ZLP) to indicate the end of the Data stage to a USB host.
hmm... so in USB3 mode that would be host requesting 513 bytes and us
sending only 512.
> @@ -619,6 +619,7 @@ struct dwc3_scratchpad_array {
> * @three_stage_setup: set if we perform a three phase setup
> * @ep0_bounced: true when we used bounce buffer
> * @ep0_expect_in: true when we expect a DATA IN transfer
> + * @ep0_zlp_sent: true when ZLP was sent
I would rather have a ep0_needs_zlp flag.
> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
> index 21a3520..cf72561 100644
> --- a/drivers/usb/dwc3/ep0.c
> +++ b/drivers/usb/dwc3/ep0.c
> @@ -782,6 +782,9 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
> return;
> }
>
> + if (dwc->ep0_zlp_sent)
> + goto finish_zlp;
> +
> length = trb->size & DWC3_TRB_SIZE_MASK;
>
> if (dwc->ep0_bounced) {
> @@ -802,14 +805,24 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
> /* for some reason we did not get everything out */
>
> dwc3_ep0_stall_and_restart(dwc);
> - } else {
> - /*
> - * handle the case where we have to send a zero packet. This
> - * seems to be case when req.length > maxpacket. Could it be?
> - */
> - if (r)
> - dwc3_gadget_giveback(ep0, r, 0);
> + return;
> }
> +
> + /* handle the case where we have to send a zero packet */
> + if ((epnum & 1) && ur->zero &&
> + (ur->length % ep0->endpoint.maxpacket == 0)) {
> + int ret;
> +
> + ret = dwc3_ep0_start_trans(dwc, epnum, dwc->ctrl_req_addr, 0,
> + DWC3_TRBCTL_CONTROL_DATA);
> + WARN_ON(ret < 0);
> + dwc->ep0_zlp_sent = 1;
> + return;
> + }
note that this causes a slight bug. Code expects to receive a
NRDY_STATUS, but we're sending another CONTROL_DATA which means we will
receive XFER_COMPLETE_DATA.
It's only working because Control(Data) lost its XferNotReady handling
due to a silicon bug we found. If someone ever patches that handler,
this will be a hard-to-track problem.
how have you tested this ? Any changes to ep0 handling must come with a
libusb-based testcase so I can make sure nothing else gets broken (yes,
new requirement :-)
Also make sure to run testusb for control endpoints and leave it running
for weeks. You should be able to survive 4 weeks of stress test without
any issues.
Don't forget to run through USB30CV ch9 on USB3 and USB2 modes.
Sorry dude, but I can't accept regressions and this code has been
exercised pretty well.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: phy: fix driver dependencies
Hi Felipe, On Mon, 16 Dec 2013 23:27:49 -0600 Felipe Balbi wrote: > > On Mon, Dec 16, 2013 at 09:27:02PM -0800, Greg KH wrote: > > On Mon, Dec 16, 2013 at 11:12:28PM -0600, Felipe Balbi wrote: > > > > > > On Tue, Dec 10, 2013 at 09:01:18PM -0600, Felipe Balbi wrote: > > > > On Tue, Dec 10, 2013 at 05:27:31PM -0800, Greg KH wrote: > > > > > On Tue, Dec 10, 2013 at 05:00:06PM -0600, Felipe Balbi wrote: > > > > > > both isp1301-omap and fsl_usb2_otg drivers > > > > > > depend on usb_bus_start_enum() which is only > > > > > > defined if CONFIG_USB != n. There is a problem, > > > > > > however, where both those drivers could be > > > > > > statically linked, while CONFIG_USB=m. > > > > > > > > > > > > Fix the problem by fixing driver dependency. > > > > > > > > > > > > Signed-off-by: Felipe Balbi > > > > > > --- > > > > > > > > > > > > Greg, I'll send this to you in a pull request > > > > > > tomorrow. > > > > > > > > > > I can take this as-is right now if you want me to, no need for a full > > > > > pull request, I still do take patches :) > > > > > > > > > > Just let me know, > > > > > > > > please go ahead, I don't think I'll have any other important fixes for > > > > this -rc. (famous last words). > > > > > > Gentle ping on this patch, we still have build errors on randconfig due > > > to lack of this patch in mainline. > > > > Ick, sorry, it got lost in my travels, I'll go get to this right now... > > Thanks Greg. I am still getting this error despite your patch being in the tree ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpy93RschuJx.pgp Description: PGP signature
Re: [PATCH V3] usb: musb: Fix unstable init of OTG_INTERFSEL.
Am 17.12.2013 18:22, schrieb David Cohen:
On Tue, Dec 17, 2013 at 05:48:33PM +0100, anaum...@ultratronik.de wrote:
From: Andreas Naumann
This is a hard to reproduce problem which leads to non-functional
USB-OTG port in 0.1%-1% of all boots. Tracked it down to commit
e25bec160158abe86c276d7d206264afc3646281, which introduces save/restore
of OTG_INTERFSEL over suspend.
Since the resume function is also called early in driver init, it uses a
non-initialized value (which is 0 and a non-supported setting in DM37xx
for INTERFSEL). Shortly after the correct value is set. Apparently this
works most time, but not always.
Fix it by not writing the value on runtime resume if it has not been
initialized yet.
Signed-off-by: Andreas Naumann
---
Even though I find the implementation a bit awkward this should fix
the issue without breaking anything else. Hope everyone is happy
with this.
drivers/usb/musb/omap2430.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 4315d35..fbe2c08 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -48,6 +48,7 @@ struct omap2430_glue {
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
struct device *control_otghs;
+ u8 initialized;
};
#define glue_to_musb(g) platform_get_drvdata(g->musb)
@@ -383,6 +384,7 @@ static int omap2430_musb_init(struct musb *musb)
}
musb_writel(musb->mregs, OTG_INTERFSEL, l);
+ glue->initialized = 1;
pr_debug("HS USB OTG: revision 0x%x, sysconfig 0x%02x, "
"sysstatus 0x%x, intrfsel 0x%x, simenable 0x%x\n",
@@ -509,6 +511,7 @@ static int omap2430_probe(struct platform_device *pdev)
glue->dev= &pdev->dev;
glue->musb = musb;
glue->status = OMAP_MUSB_UNKNOWN;
+ glue->initialized= 0;
You don't need to do this. 'glue' was already allocated with kzalloc().
ok
if (np) {
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
@@ -646,7 +649,8 @@ static int omap2430_runtime_resume(struct device *dev)
if (musb) {
omap2430_low_level_init(musb);
- musb_writel(musb->mregs, OTG_INTERFSEL,
+ if(glue->initialized)
Are you sure this is thread safe?
If you're sending this patch it means runtime_resume can be called
before omap2430_must_init(), but how about at the same time?
You defined 'initialized' as u8 type, then read/write operations won't
be atomic in ARM.
You're right, wasnt thinking of that. Shall I use atomic_t and helpers?
Br, David Cohen
+ musb_writel(musb->mregs, OTG_INTERFSEL,
musb->context.otg_interfsel);
usb_phy_set_suspend(musb->xceiv, 0);
--
1.8.4.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
--
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: 答复: Re: 答复: Re: 答复: Re: 答复: Re: 【PATCH】USB：add new zte 3g-modem's pid to option.c
Signed-off-by:Jun zhang
--- drivers/usb/serial/option.c 2013-11-21 04:37:52.0 +0800
+++ option_bac.c2013-11-28 14:13:54.480576688 +0800
@@ -1419,6 +1419,17 @@
.driver_info = (kernel_ulong_t)&net_intf3_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0178, 0xff, 0xff,
0xff),
.driver_info = (kernel_ulong_t)&net_intf3_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xffe9, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8b, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8c, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8d, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8e, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff8f, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff90, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff91, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff92, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff93, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff94, 0xff, 0xff,
0xff) },
/* NOTE: most ZTE CDMA devices should be driven by zte_ev, not option */
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718,
0xff, 0xff, 0xff),
