[PATCH v2] usb: chipidea: reuse the platform_data to store the ci info
From: Rong Wang
Chipidea puts ci information to drvdata, but this overwrites the drvdata
placed by EHCI core. EHCI core thinks drvdata is ehci_hcd. We can find this
from codes like ehci-sysfs.c:
static ssize_t show_companion(struct device *dev,
struct device_attribute *attr,
char *buf) {
struct ehci_hcd *ehci;
ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
...
}
So overwritting drvdata from chipidea driver actually breaks a part of
functionalities of EHCI core.
Since the platform_data would not be accessed after the device is added to
system after the probe process, so it's safe to move to platform_data here.
This fix is not elegant but currently it is the quickest fix.
Signed-off-by: Rong Wang
Signed-off-by: Barry Song
---
-v2: rebase againest 4.3 usb-next
drivers/usb/chipidea/core.c| 12 ++--
drivers/usb/chipidea/host.c| 5 ++---
drivers/usb/chipidea/otg_fsm.c | 14 +++---
3 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3feebf7..63c8cd6 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -915,7 +915,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
}
}
- platform_set_drvdata(pdev, ci);
+ dev->platform_data = ci;
ret = devm_request_irq(dev, ci->irq, ci_irq, IRQF_SHARED,
ci->platdata->name, ci);
if (ret)
@@ -948,7 +948,7 @@ deinit_phy:
static int ci_hdrc_remove(struct platform_device *pdev)
{
- struct ci_hdrc *ci = platform_get_drvdata(pdev);
+ struct ci_hdrc *ci = dev_get_platdata(&pdev->dev);
if (ci->supports_runtime_pm) {
pm_runtime_get_sync(&pdev->dev);
@@ -1003,7 +1003,7 @@ static void ci_controller_suspend(struct ci_hdrc *ci)
static int ci_controller_resume(struct device *dev)
{
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
dev_dbg(dev, "at %s\n", __func__);
@@ -1035,7 +1035,7 @@ static int ci_controller_resume(struct device *dev)
#ifdef CONFIG_PM_SLEEP
static int ci_suspend(struct device *dev)
{
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
if (ci->wq)
flush_workqueue(ci->wq);
@@ -1068,7 +1068,7 @@ static int ci_suspend(struct device *dev)
static int ci_resume(struct device *dev)
{
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
int ret;
if (device_may_wakeup(dev))
@@ -1090,7 +1090,7 @@ static int ci_resume(struct device *dev)
static int ci_runtime_suspend(struct device *dev)
{
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
dev_dbg(dev, "at %s\n", __func__);
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 3d24304..8bd54be 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -44,7 +44,7 @@ static int ehci_ci_portpower(struct usb_hcd *hcd, int
portnum, bool enable)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
struct ehci_ci_priv *priv = (struct ehci_ci_priv *)ehci->priv;
struct device *dev = hcd->self.controller;
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
int ret = 0;
int port = HCS_N_PORTS(ehci->hcs_params);
@@ -80,7 +80,7 @@ static int ehci_ci_portpower(struct usb_hcd *hcd, int
portnum, bool enable)
static int ehci_ci_reset(struct usb_hcd *hcd)
{
struct device *dev = hcd->self.controller;
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
int ret;
ret = ehci_setup(hcd);
@@ -117,7 +117,6 @@ static int host_start(struct ci_hdrc *ci)
if (!hcd)
return -ENOMEM;
- dev_set_drvdata(ci->dev, ci);
hcd->rsrc_start = ci->hw_bank.phys;
hcd->rsrc_len = ci->hw_bank.size;
hcd->regs = ci->hw_bank.abs;
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 00ab59d..8dbf1d4 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -36,7 +36,7 @@ get_a_bus_req(struct device *dev, struct device_attribute
*attr, char *buf)
{
char*next;
unsignedsize, t;
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
next = buf;
size = PAGE_SIZE;
@@ -51,7 +51,7 @@ static ssize_t
set_a_bus_req(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
- struct ci_hdrc *ci = dev_get_drvdata(dev);
+ struct ci_hdrc *ci = dev_get_platdata(dev);
if
Re: [PATCH V2] dummy_hcd: replace timeval with timespec64
On Thursday 17 September 2015 11:09:49 WEN Pingbo wrote: > The millisecond of the last second will be normal if tv_sec is > overflowed. But for y2038 consistency and demonstration purpose, > and avoiding further risks, we need to remove 'timeval' in this > driver, to avoid similair problems. > > V2 Updates: > - using monotonic time here by replacing getnstimeofday() with > ktime_get_ts64(), to avoid leap second issues. The frame time in USB > is always 1ms, no matter what speed, so ktime_get_ts64() have enough > resolution to cover this. > - using NSEC_PER_MSEC instead of hard code. > > Signed-off-by: Pingbo Wen > Cc: Y2038 > Cc: linux-ker...@vger.kernel.org > Cc: Arnd Bergmann > Cc: Felipe Balbi > Signed-off-by: WEN Pingbo > The patch looks good to me now, Reviewed-by: Arnd Bergmann Regarding the changelog, I notice you have a duplicate Signed-off-by line, one of the two should be removed. Also, The "V2 update" portion should be split into the part that you want in the changelog, without the '-' bullet points (in this case, the explanation for monontonic time), and the purely informational part that makes sense for the review but not for the git history (what changes were done against previous versions of the patch), which should go below the '---' line under the Signed-off-by chain, so it gets removed when imported to git. If Felipe decides to do these changes himself when he applies the patch, that's fine, otherwise please send the patch again as 'V3' tomorrow. Arnd -- 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: First kernel patch (optimization)
From: Jaime Arrocha > Sent: 17 September 2015 02:50 .. > One interesting observation I found was that in O0 and O2, it does make > a call to strlen while in O1 it calculates > the length of the string using: > You want an 'xor %rcx,%rcx' here. > repnz scas%es:(%rdi),%al > not%rcx > sub $0x2,%rcx > > Why does it do that? Is the code above faster? If yes, why not do it in > O2 too? Because 'repnz scasb' is slow, especially on some cpu types. It may win for -Os on 32 bit systems. Pentium 4 netburst have about 40 clocks setup for all the 'rep' instructions, later cpus are better but you might still be talking double figures. On 64 bit cpu there are much faster ways of detecting a zero byte in a 64 bit word by using shifts and masks - so the function call can be a win. David
Re: [PATCH 2/2] mmc: vub300: Remove unneded semicolons
On 16 September 2015 at 11:30, Javier Martinez Canillas wrote: > They aren't needed and are just creating null statements so remove it. > > Signed-off-by: Javier Martinez Canillas Thanks, applied for next! Kind regards Uffe > > --- > > drivers/mmc/host/vub300.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/mmc/host/vub300.c b/drivers/mmc/host/vub300.c > index fbabbb82b354..1e819f98b94f 100644 > --- a/drivers/mmc/host/vub300.c > +++ b/drivers/mmc/host/vub300.c > @@ -563,7 +563,7 @@ static void add_offloaded_reg(struct vub300_mmc_host > *vub300, > i += 1; > continue; > } > - }; > + } > __add_offloaded_reg_to_fifo(vub300, register_access, func); > } > > @@ -1372,7 +1372,7 @@ static void download_offload_pseudocode(struct > vub300_mmc_host *vub300) > l += snprintf(vub300->vub_name + l, > sizeof(vub300->vub_name) - l, "_%04X%04X", > sf->vendor, sf->device); > - }; > + } > snprintf(vub300->vub_name + l, sizeof(vub300->vub_name) - l, ".bin"); > dev_info(&vub300->udev->dev, "requesting offload firmware %s\n", > vub300->vub_name); > @@ -1893,7 +1893,7 @@ static int satisfy_request_from_offloaded_data(struct > vub300_mmc_host *vub300, > i += 1; > continue; > } > - }; > + } > if (vub300->total_offload_count == 0) > return 0; > else if (vub300->fn[func].offload_count == 0) > -- > 2.4.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings
Coccinelle suggests the following patch. But the code is curious. Is the function expected to always return a failure value? thanks, julia On Thu, 17 Sep 2015, kbuild test robot wrote: > TO: Andrzej Pietrasiewicz > CC: kbuild-...@01.org > CC: Felipe Balbi > CC: Laurent Pinchart > CC: "Greg Kroah-Hartman" > CC: linux-usb@vger.kernel.org > CC: linux-ker...@vger.kernel.org > > drivers/usb/gadget/function/uvc_configfs.c:866:5-8: Unneeded variable: "ret". > Return "- EINVAL" on line 891 > > > Remove unneeded variable used to store return value. > > Generated by: scripts/coccinelle/misc/returnvar.cocci > > CC: Andrzej Pietrasiewicz > Signed-off-by: Fengguang Wu > --- > > Please take the patch only if it's a positive warning. Thanks! > > uvc_configfs.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > --- a/drivers/usb/gadget/function/uvc_configfs.c > +++ b/drivers/usb/gadget/function/uvc_configfs.c > @@ -863,7 +863,6 @@ static int uvcg_streaming_header_drop_li > struct uvcg_streaming_header *src_hdr; > struct uvcg_format *target_fmt = NULL; > struct uvcg_format_ptr *format_ptr, *tmp; > - int ret = -EINVAL; > > src_hdr = to_uvcg_streaming_header(src); > mutex_lock(su_mutex); /* for navigating configfs hierarchy */ > @@ -888,7 +887,7 @@ static int uvcg_streaming_header_drop_li > out: > mutex_unlock(&opts->lock); > mutex_unlock(su_mutex); > - return ret; > + return -EINVAL; > > } > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/1] xhci: replace custom implementation of readq / writeq
On Thu, 2015-08-27 at 12:39 +0300, Andy Shevchenko wrote:
> The readq() and writeq() helpers are available in the
> asm-generic/io-64-nonatomic-hi-lo.h and asm-generic/io-64-nonatomic
> -lo-hi.h
> headers. Replace custom implementation by the generic helpers.
>
Mathias, any comments on this one?
> Signed-off-by: Andy Shevchenko
> ---
> drivers/usb/host/xhci.h | 14 --
> 1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index dbda41e..151d1e4 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -29,6 +29,8 @@
> #include
> #include
>
> +#include
> +
> /* Code sharing between pci-quirks and xhci hcd */
> #include "xhci-ext-caps.h"
> #include "pci-quirks.h"
> @@ -1651,20 +1653,12 @@ static inline struct usb_hcd
> *xhci_to_hcd(struct xhci_hcd *xhci)
> static inline u64 xhci_read_64(const struct xhci_hcd *xhci,
> __le64 __iomem *regs)
> {
> - __u32 __iomem *ptr = (__u32 __iomem *) regs;
> - u64 val_lo = readl(ptr);
> - u64 val_hi = readl(ptr + 1);
> - return val_lo + (val_hi << 32);
> + return lo_hi_readq(regs);
> }
> static inline void xhci_write_64(struct xhci_hcd *xhci,
>const u64 val, __le64 __iomem
> *regs)
> {
> - __u32 __iomem *ptr = (__u32 __iomem *) regs;
> - u32 val_lo = lower_32_bits(val);
> - u32 val_hi = upper_32_bits(val);
> -
> - writel(val_lo, ptr);
> - writel(val_hi, ptr + 1);
> + lo_hi_writeq(val, regs);
> }
>
> static inline int xhci_link_trb_quirk(struct xhci_hcd *xhci)
--
Andy Shevchenko
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] dummy_hcd: replace timeval with timespec64
WEN Pingbo wrote:
> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
> /* there are both host and device side versions of this call ... */
> static int dummy_g_get_frame(struct usb_gadget *_gadget)
> {
> - struct timeval tv;
> + struct timespec64 tv;
tv is very often used for timeval structs.
I suggest also changing the variable name, for example to ts, to
avoid some possible confusion.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: uvc: fix returnvar.cocci warnings
Hi Julia, W dniu 17.09.2015 o 10:57, Julia Lawall pisze: Coccinelle suggests the following patch. But the code is curious. Is the function expected to always return a failure value? Thank you for catching this. The function is not expected to always return a failure value. Fortunately it does not matter anyway because the return value of the drop_link() operation is silently ignored by its caller in fs/configfs/symlink.c, functions configfs_symlink() and configfs_unlink(). For my comments see inline. thanks, julia On Thu, 17 Sep 2015, kbuild test robot wrote: TO: Andrzej Pietrasiewicz CC: kbuild-...@01.org CC: Felipe Balbi CC: Laurent Pinchart CC: "Greg Kroah-Hartman" CC: linux-usb@vger.kernel.org CC: linux-ker...@vger.kernel.org drivers/usb/gadget/function/uvc_configfs.c:866:5-8: Unneeded variable: "ret". Return "- EINVAL" on line 891 Remove unneeded variable used to store return value. Generated by: scripts/coccinelle/misc/returnvar.cocci CC: Andrzej Pietrasiewicz Signed-off-by: Fengguang Wu --- Please take the patch only if it's a positive warning. Thanks! uvc_configfs.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/usb/gadget/function/uvc_configfs.c +++ b/drivers/usb/gadget/function/uvc_configfs.c @@ -863,7 +863,6 @@ static int uvcg_streaming_header_drop_li struct uvcg_streaming_header *src_hdr; struct uvcg_format *target_fmt = NULL; struct uvcg_format_ptr *format_ptr, *tmp; - int ret = -EINVAL; src_hdr = to_uvcg_streaming_header(src); mutex_lock(su_mutex); /* for navigating configfs hierarchy */ @@ -888,7 +887,7 @@ static int uvcg_streaming_header_drop_li out: mutex_unlock(&opts->lock); mutex_unlock(su_mutex); - return ret; + return -EINVAL; return 0; Thanks, AP -- 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: gadget: uvc: fix returnvar.cocci warnings
> Fortunately it does not matter anyway because the return value > of the drop_link() operation is silently ignored by its caller in > fs/configfs/symlink.c, functions configfs_symlink() and configfs_unlink(). Should such an implementation detail be also reconsidered once more? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/1] xhci: replace custom implementation of readq / writeq
On 17.09.2015 12:23, Andy Shevchenko wrote: On Thu, 2015-08-27 at 12:39 +0300, Andy Shevchenko wrote: The readq() and writeq() helpers are available in the asm-generic/io-64-nonatomic-hi-lo.h and asm-generic/io-64-nonatomic -lo-hi.h headers. Replace custom implementation by the generic helpers. Mathias, any comments on this one? Yes, looks good, added to queue -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] dummy_hcd: replace timeval with timespec64
On Thursday, September 17, 2015 05:59 PM, Peter Stuge wrote:
> WEN Pingbo wrote:
>> +++ b/drivers/usb/gadget/udc/dummy_hcd.c
>> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
>> /* there are both host and device side versions of this call ... */
>> static int dummy_g_get_frame(struct usb_gadget *_gadget)
>> {
>> -struct timeval tv;
>> +struct timespec64 tv;
>
> tv is very often used for timeval structs.
>
> I suggest also changing the variable name, for example to ts, to
> avoid some possible confusion.
>
Hi Peter,
Thanks for pointing it out, I will fix it in next version.
Pingbo
--
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 woes continued
On Thu, 17 Sep 2015, Eugen Rogoza wrote:
> > Also removing the XHCI_LPM_SUPPORT flag should do the trick, for example
> > for Intel hosts:
> >
> > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > index 2be1b7b..8f2eafb 100644
> > --- a/drivers/usb/host/xhci-pci.c
> > +++ b/drivers/usb/host/xhci-pci.c
> > @@ -127,7 +127,6 @@ static void xhci_pci_quirks(struct device *dev, struct
> > xhci_hcd *xhci)
> > xhci->quirks |= XHCI_TRUST_TX_LENGTH;
> >
> > if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> > - xhci->quirks |= XHCI_LPM_SUPPORT;
> > xhci->quirks |= XHCI_INTEL_HOST;
> > xhci->quirks |= XHCI_AVOID_BEI;
> > }
> >
> > I can't remember any way to do this runtime
>
> I'm experiencing the same random disconnect/connect issue with xhci as
> Hans-Peter. My HDD enclosure is based on ASMedia 1051 (vid=174c, pid=55aa)
>
> I was also suspecting USB3 hardware LPM and didn't know how to disable it as
> well. So I removed the line suggested by Mathias and recompiled the kernel.
> No changes. My usbmon output is also attached.
>
> The enclosure works perfectly in xhci mode under Windows 7 with Intel USB3.0
> drivers. It also works perfectly under Linux in ehci mode as well as in xhci
> mode on a different host (older USB 3.0 controller from a different vendor).
The usbmon trace shows that your drive disconnects spontaneously after
a period of inactivity. In some cases after 6 seconds, in one case
after 25 seconds.
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: Applying Patch to Change Max Packet Size for Device
On Wed, 16 Sep 2015, Todd Efflam wrote: > We were using EHCI with the 2.6.35 kernel. When disabling XHCI in > 3.14 and using EHCI the device still doesn't work however. > > The reason we are stuck with 3.14 is we use the Yocto build system and > their latest support is for 3.14. If the problem affects both the EHCI and xHCI controllers, why do you want to work around by changing only xhci-hcd? Wouldn't it be better to change the USB core? What type of endpoint is this, anyway (control, bulk, interrupt, or isochronous)? If the device and the computer have differing ideas about what the maxpacket size is, aren't transfers larger than the smaller of the two sizes likely to fail? 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
[GIT PULL] USB-serial fixes for v4.3-rc2
Hi Greg, Here are a few new device IDs for v4.3-rc2. Thanks, Johan The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-4.3-rc2 for you to fetch changes up to 19ab6bc5674a30fdb6a2436b068d19a3c17dc73e: USB: option: add ZTE PIDs (2015-09-14 09:56:41 +0200) USB-serial fixes for v4.3-rc2 Just some new ZTE device IDs. Signed-off-by: Johan Hovold Liu.Zhao (1): USB: option: add ZTE PIDs drivers/usb/serial/option.c | 24 1 file changed, 24 insertions(+) -- 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: [GIT PULL] USB-serial fixes for v4.3-rc2
On Thu, Sep 17, 2015 at 06:08:55PM +0200, Johan Hovold wrote: > Hi Greg, > > Here are a few new device IDs for v4.3-rc2. > > Thanks, > Johan > > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git > tags/usb-serial-4.3-rc2 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: gadget: mass_storage: allow for deeper queue lengths
Instead of allowing a range of 2 to 4 requests,
let's allow the user choose up to 32 requests
as that will give us a better chance of keeping
controller busy.
We still maintain default of 2 so users shouldn't
be affected.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/Kconfig | 2 +-
drivers/usb/gadget/function/f_mass_storage.c | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index bcf83c0a6e62..33834aa09ed4 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -113,7 +113,7 @@ config USB_GADGET_VBUS_DRAW
config USB_GADGET_STORAGE_NUM_BUFFERS
int "Number of storage pipeline buffers"
- range 2 4
+ range 2 32
default 2
help
Usually 2 buffers are enough to establish a good buffering
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index a6eb537d7768..5277e7c4a82a 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2662,10 +2662,12 @@ EXPORT_SYMBOL_GPL(fsg_common_put);
/* check if fsg_num_buffers is within a valid range */
static inline int fsg_num_buffers_validate(unsigned int fsg_num_buffers)
{
- if (fsg_num_buffers >= 2 && fsg_num_buffers <= 4)
+#define FSG_MAX_NUM_BUFFERS32
+
+ if (fsg_num_buffers >= 2 && fsg_num_buffers <= FSG_MAX_NUM_BUFFERS)
return 0;
pr_err("fsg_num_buffers %u is out of range (%d to %d)\n",
- fsg_num_buffers, 2, 4);
+ fsg_num_buffers, 2, FSG_MAX_NUM_BUFFERS);
return -EINVAL;
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued
Instead of clearing DWC3_PENDING_REQUEST when we start transfer, let's do it when the request is actually queued, that way we know for sure that we're clearing in the right time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d28dc6df4e55..2cc6a33438dc 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -948,7 +948,6 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep, u16 cmd_param, dwc3_trace(trace_dwc3_gadget, "%s: endpoint busy", dep->name); return -EBUSY; } - dep->flags &= ~DWC3_EP_PENDING_REQUEST; /* * If we are getting here after a short-out-packet we don't enqueue any @@ -1117,6 +1116,10 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req) if (ret && ret != -EBUSY) dev_dbg(dwc->dev, "%s: failed to kick transfers\n", dep->name); + + if (!ret) + dep->flags &= ~DWC3_EP_PENDING_REQUEST; + return ret; } -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usb: dwc3: gadget: improve ep_queue's error reporting
We shouldn't return -EBUSY, that's used only internally
when the core still has transfers in flight on a given
endpoint.
Also, combine the error reporting so that we don't have
to duplicate it.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2cc6a33438dc..858d88373305 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1080,10 +1080,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
if (!usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
!(dep->flags & DWC3_EP_BUSY)) {
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
- return ret;
+ goto out;
}
/*
@@ -1113,14 +1110,10 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
}
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
-
if (!ret)
dep->flags &= ~DWC3_EP_PENDING_REQUEST;
- return ret;
+ goto out;
}
/*
@@ -1134,10 +1127,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
WARN_ON_ONCE(!dep->resource_index);
ret = __dwc3_gadget_kick_transfer(dep, dep->resource_index,
false);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
- return ret;
+ goto out;
}
/*
@@ -1145,14 +1135,17 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
* right away, otherwise host will not know we have streams to be
* handled.
*/
- if (dep->stream_capable) {
+ if (dep->stream_capable)
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
- }
- return 0;
+out:
+ if (ret && ret != -EBUSY)
+ dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
+ dep->name);
+ if (ret == -EBUSY)
+ ret = 0;
+
+ return ret;
}
static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued
On Thu, Sep 17, 2015 at 11:42:38AM -0500, Felipe Balbi wrote: > Instead of clearing DWC3_PENDING_REQUEST when > we start transfer, let's do it when the request > is actually queued, that way we know for sure > that we're clearing in the right time. > > Signed-off-by: Felipe Balbi looks like I forgot one patch, sorry. -- balbi signature.asc Description: Digital signature
[PATCH RESEND 2/4] usb: dwc3: gadget: clear DWC3_PENDING_REQUEST when request is queued
Instead of clearing DWC3_PENDING_REQUEST when we start transfer, let's do it when the request is actually queued, that way we know for sure that we're clearing in the right time. Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index d28dc6df4e55..2cc6a33438dc 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -948,7 +948,6 @@ static int __dwc3_gadget_kick_transfer(struct dwc3_ep *dep, u16 cmd_param, dwc3_trace(trace_dwc3_gadget, "%s: endpoint busy", dep->name); return -EBUSY; } - dep->flags &= ~DWC3_EP_PENDING_REQUEST; /* * If we are getting here after a short-out-packet we don't enqueue any @@ -1117,6 +1116,10 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, struct dwc3_request *req) if (ret && ret != -EBUSY) dev_dbg(dwc->dev, "%s: failed to kick transfers\n", dep->name); + + if (!ret) + dep->flags &= ~DWC3_EP_PENDING_REQUEST; + return ret; } -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 1/4] usb: dwc3: gadget: start requests as soon as they come
In an attempt to make dwc3 slightly faster, let's
start usb_requests as soon as they come as that will
let us avoid a XFER_NOT_READY event and save a little
bit of time.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1ea565f307e4..d28dc6df4e55 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1072,6 +1072,22 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
list_add_tail(&req->list, &dep->request_list);
/*
+* If there are no pending requests and the endpoint isn't already
+* busy, we will just start the request straight away.
+*
+* This will save one IRQ (XFER_NOT_READY) and possibly make it a
+* little bit faster.
+*/
+ if (!usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
+ !(dep->flags & DWC3_EP_BUSY)) {
+ ret = __dwc3_gadget_kick_transfer(dep, 0, true);
+ if (ret && ret != -EBUSY)
+ dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
+ dep->name);
+ return ret;
+ }
+
+ /*
* There are a few special cases:
*
* 1. XferNotReady with empty list of requests. We need to kick the
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 4/4] usb: gadget: mass_storage: allow for deeper queue lengths
Instead of allowing a range of 2 to 4 requests,
let's allow the user choose up to 32 requests
as that will give us a better chance of keeping
controller busy.
We still maintain default of 2 so users shouldn't
be affected.
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/Kconfig | 2 +-
drivers/usb/gadget/function/f_mass_storage.c | 6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index bcf83c0a6e62..33834aa09ed4 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -113,7 +113,7 @@ config USB_GADGET_VBUS_DRAW
config USB_GADGET_STORAGE_NUM_BUFFERS
int "Number of storage pipeline buffers"
- range 2 4
+ range 2 32
default 2
help
Usually 2 buffers are enough to establish a good buffering
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index a6eb537d7768..5277e7c4a82a 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2662,10 +2662,12 @@ EXPORT_SYMBOL_GPL(fsg_common_put);
/* check if fsg_num_buffers is within a valid range */
static inline int fsg_num_buffers_validate(unsigned int fsg_num_buffers)
{
- if (fsg_num_buffers >= 2 && fsg_num_buffers <= 4)
+#define FSG_MAX_NUM_BUFFERS32
+
+ if (fsg_num_buffers >= 2 && fsg_num_buffers <= FSG_MAX_NUM_BUFFERS)
return 0;
pr_err("fsg_num_buffers %u is out of range (%d to %d)\n",
- fsg_num_buffers, 2, 4);
+ fsg_num_buffers, 2, FSG_MAX_NUM_BUFFERS);
return -EINVAL;
}
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 3/4] usb: dwc3: gadget: improve ep_queue's error reporting
We shouldn't return -EBUSY, that's used only internally
when the core still has transfers in flight on a given
endpoint.
Also, combine the error reporting so that we don't have
to duplicate it.
Signed-off-by: Felipe Balbi
---
drivers/usb/dwc3/gadget.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2cc6a33438dc..858d88373305 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1080,10 +1080,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
if (!usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
!(dep->flags & DWC3_EP_BUSY)) {
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
- return ret;
+ goto out;
}
/*
@@ -1113,14 +1110,10 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
}
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
-
if (!ret)
dep->flags &= ~DWC3_EP_PENDING_REQUEST;
- return ret;
+ goto out;
}
/*
@@ -1134,10 +1127,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
WARN_ON_ONCE(!dep->resource_index);
ret = __dwc3_gadget_kick_transfer(dep, dep->resource_index,
false);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
- return ret;
+ goto out;
}
/*
@@ -1145,14 +1135,17 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
* right away, otherwise host will not know we have streams to be
* handled.
*/
- if (dep->stream_capable) {
+ if (dep->stream_capable)
ret = __dwc3_gadget_kick_transfer(dep, 0, true);
- if (ret && ret != -EBUSY)
- dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
- dep->name);
- }
- return 0;
+out:
+ if (ret && ret != -EBUSY)
+ dev_dbg(dwc->dev, "%s: failed to kick transfers\n",
+ dep->name);
+ if (ret == -EBUSY)
+ ret = 0;
+
+ return ret;
}
static int dwc3_gadget_ep_queue(struct usb_ep *ep, struct usb_request *request,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/3] usb: xhci-platform: Configure 64-bit DMA mask if the platform is capable
The xhci platform driver does not work with system that only supports 64-bit DMA as it requests 32-bit DMA mask during driver initialization. This patch set addresses this issue and also adds XHCI-compliant USB Controller ACPI identification into xhci-platform driver. Changes from v7: - Only use dma_coerce_mask_and_coherent when dma_mask is NULL - Check the controller DMA capability and configure 32-bit dma_mask if it only supports 32-bit DMA - Patches is generated over v4.3-rc1 Changes from v6: -Add WARN_ON if dma_mask is NULL -Use dma_coerce_mask_and_coherent to assign dma_mask and coherent_dma_mask Change from v5: -Change comment to "XHCI-compliant USB Controller" as "PNP0D10" ID is not X-Gene specific -Change comment -Assign dma_mask to coherent_dma_mask if dma_mask is NULL to make sure dma_set_mask_and_coherent does not fail prematurely. Changes from v4: -Remove #ifdef CONFIG_ACPI -Change comment -Assign dma_mask to coherent_dma_mask if dma_mask is NULL to make sure dma_set_mask_and_coherent does not fail prematurely. Changes from v3: -Regenerate the patch over 4.2-rc5 -No code change Changes from v2 -Replaced tristate with a boolean as the driver doesn't compile as a module -Correct --help-- to ---help--- Changes from v1 -Consolidated to use dma_set_mask_and_coherent -Got rid of the check against sizeof(dma_addr_t) -Renamed from "add support for APM X-Gene to xhci-platform" -Removed changes to arm64/Kconfig -Made CONFIG_USB_XHCI_PLATFORM a user selectable config option drivers/usb/host/xhci-plat.c | 29 ++--- drivers/usb/host/xhci.c | 10 ++ 2 files changed, 32 insertions(+), 7 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/3] usb: make xhci platform driver use 64 bit or 32 bit DMA
The xhci platform driver needs to work on systems that
either only support 64-bit DMA or only support 32-bit DMA.
Attempt to set a coherent dma mask for 64-bit DMA, and
attempt again with 32-bit DMA if that fails.
[dhdang: regenerate the patch over v4.3-rc1 and address new comments]
Signed-off-by: Mark Langsdorf
Tested-by: Mark Salter
Signed-off-by: Duc Dang
---
drivers/usb/host/xhci-plat.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 890ad9d..34c93e8 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -93,14 +93,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq < 0)
return -ENODEV;
- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
- ret = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
- if (ret)
- return ret;
- if (!pdev->dev.dma_mask)
- pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
+ /* Try to set 64-bit DMA first */
+ if (WARN_ON(!pdev->dev.dma_mask))
+ /* Platform did not initialize dma_mask */
+ ret = dma_coerce_mask_and_coherent(&pdev->dev,
+ DMA_BIT_MASK(64));
else
- dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
+
+ /* If seting 64-bit DMA mask fails, fall back to 32-bit DMA mask */
+ if (ret) {
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev));
if (!hcd)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/3] usb: Add support for ACPI identification to xhci-platform
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.
[dhdang: regenerate the patch over v4.3-rc1 and address new comments]
Signed-off-by: Mark Langsdorf
Signed-off-by: Duc Dang
---
drivers/usb/host/xhci-plat.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 34c93e8..05647e6 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "xhci.h"
#include "xhci-mvebu.h"
@@ -268,6 +269,13 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* XHCI-compliant USB Controller */
+ { "PNP0D10", },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -275,6 +283,7 @@ static struct platform_driver usb_xhci_driver = {
.name = "xhci-hcd",
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+ .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
};
MODULE_ALIAS("platform:xhci-hcd");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/3] usb: xhci: configure 32-bit DMA if the controller does not support 64-bit DMA
This change avoids DMA error in the cases where dma_mask and
coherent_dma_mask of a 32-bit controller get configured as
DMA_BIT_MASK(64) when running on a 64-bit system.
Signed-off-by: Duc Dang
---
drivers/usb/host/xhci.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 6b0f4a4..8cb8f39 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4908,6 +4908,16 @@ int xhci_gen_setup(struct usb_hcd *hcd,
xhci_get_quirks_t get_quirks)
!dma_set_mask(dev, DMA_BIT_MASK(64))) {
xhci_dbg(xhci, "Enabling 64-bit DMA addresses.\n");
dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
+ } else {
+ /*
+* This is to avoid error in cases where a 32-bit USB
+* controller is used on a 64-bit capable system.
+*/
+ retval = dma_set_mask(dev, DMA_BIT_MASK(32));
+ if (retval)
+ return retval;
+ xhci_dbg(xhci, "Enabling 32-bit DMA addresses.\n");
+ dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
}
xhci_dbg(xhci, "Calling HCD init\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 02/32] usb: dwc2: host: create a function to handle port_resume
Hi,
On Wed, Sep 9, 2015 at 3:20 AM, Mian Yousaf Kaukab
wrote:
> From: Gregory Herrero
>
> port resume sequence may be used in different places. Create a
> function to handle it. Moreover, make hprt0 read-modify-write atomic.
>
> Signed-off-by: Gregory Herrero
> Signed-off-by: Mian Yousaf Kaukab
> Tested-by: Robert Baldyga
> ---
> drivers/usb/dwc2/hcd.c | 30 ++
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
> index 007a3d5..0cef770 100644
> --- a/drivers/usb/dwc2/hcd.c
> +++ b/drivers/usb/dwc2/hcd.c
> @@ -1484,6 +1484,27 @@ static void dwc2_port_suspend(struct dwc2_hsotg
> *hsotg, u16 windex)
> }
> }
>
> +/* Must NOT be called with interrupt disabled or spinlock held */
> +static void dwc2_port_resume(struct dwc2_hsotg *hsotg)
> +{
> + unsigned long flags;
> + u32 hprt0;
> +
> + spin_lock_irqsave(&hsotg->lock, flags);
> + hprt0 = dwc2_read_hprt0(hsotg);
> + hprt0 |= HPRT0_RES;
> + hprt0 &= ~HPRT0_SUSP;
> + writel(hprt0, hsotg->regs + HPRT0);
Just from a completely "what changed" point of view, you have made a
non-obvious behavior change here. Previously the code only masked out
HPRT0_SUSP in the 2nd write, not the first. Was that a bug in the old
code, or does it just not matter?
> + spin_unlock_irqrestore(&hsotg->lock, flags);
> +
> + msleep(USB_RESUME_TIMEOUT);
> +
> + spin_lock_irqsave(&hsotg->lock, flags);
> + hprt0 &= ~HPRT0_RES;
> + writel(hprt0, hsotg->regs + HPRT0);
Just curious: since you released and re-grabbed the lock, shouldn't
you re-read HPRT0?
Also: one thing that was added in my local tree here was to make
things parallel to dwc2_port_suspend() and update "hsotg->lx_state"
here. I'm not sure if it was added it because there as a real issue
or if it just seemed better...
> + spin_unlock_irqrestore(&hsotg->lock, flags);
> +}
> +
> /* Handles hub class-specific requests */
> static int dwc2_hcd_hub_control(struct dwc2_hsotg *hsotg, u16 typereq,
> u16 wvalue, u16 windex, char *buf, u16
> wlength)
> @@ -1532,14 +1553,7 @@ static int dwc2_hcd_hub_control(struct dwc2_hsotg
> *hsotg, u16 typereq,
> writel(0, hsotg->regs + PCGCTL);
> usleep_range(2, 4);
In my local tree we already had a dwc2_port_resume() function and it
included the two lines above. I presume you didn't include them in
your patch because future callers of dwc2_port_resume() don't want
those lines. That's fine, but I figured I'd mention it...
>
> - hprt0 = dwc2_read_hprt0(hsotg);
> - hprt0 |= HPRT0_RES;
> - writel(hprt0, hsotg->regs + HPRT0);
> - hprt0 &= ~HPRT0_SUSP;
> - msleep(USB_RESUME_TIMEOUT);
> -
> - hprt0 &= ~HPRT0_RES;
> - writel(hprt0, hsotg->regs + HPRT0);
> + dwc2_port_resume(hsotg);
> break;
>
> case USB_PORT_FEAT_POWER:
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 02/32] usb: dwc2: host: create a function to handle port_resume
Hi, On Thu, Sep 17, 2015 at 12:41 PM, Doug Anderson wrote: >> + spin_unlock_irqrestore(&hsotg->lock, flags); >> + >> + msleep(USB_RESUME_TIMEOUT); >> + >> + spin_lock_irqsave(&hsotg->lock, flags); >> + hprt0 &= ~HPRT0_RES; >> + writel(hprt0, hsotg->regs + HPRT0); > > Just curious: since you released and re-grabbed the lock, shouldn't > you re-read HPRT0? > > Also: one thing that was added in my local tree here was to make > things parallel to dwc2_port_suspend() and update "hsotg->lx_state" > here. I'm not sure if it was added it because there as a real issue > or if it just seemed better... LOL. That will teach me. I just got to the next patch and see that you removed it from dwc2_port_suspend(). Sorry for the noise. I'll try to read more of the series before I respond more... -Doug -- 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 v8 1/3] usb: make xhci platform driver use 64 bit or 32 bit DMA
On Thursday 17 September 2015 11:19:46 Duc Dang wrote: > The xhci platform driver needs to work on systems that > either only support 64-bit DMA or only support 32-bit DMA. > Attempt to set a coherent dma mask for 64-bit DMA, and > attempt again with 32-bit DMA if that fails. > > [dhdang: regenerate the patch over v4.3-rc1 and address new comments] > Signed-off-by: Mark Langsdorf > Tested-by: Mark Salter > Signed-off-by: Duc Dang > Acked-by: Arnd Bergmann -- 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: Applying Patch to Change Max Packet Size for Device
On Wed, Sep 16, 2015 at 8:27 PM, Todd Efflam wrote: > We were using EHCI with the 2.6.35 kernel. When disabling XHCI in > 3.14 and using EHCI the device still doesn't work however. > > The reason we are stuck with 3.14 is we use the Yocto build system and > their latest support is for 3.14. You could just build 4.2 or 4.3-rc1 manually and deploy it. We use Yocto with kernel 4.1 without issues. Which CPU are you using? -- 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: Applying Patch to Change Max Packet Size for Device
Thanks everyone. Here are some responses: On Wed, Sep 16, 2015 at 4:33 PM, Greg KH wrote: > Really? I thought you said the error was in the xhci driver, not ehci, > for 3.14. We tested with both and it failed with both, sorry for not being clear. > Can't you just plug your device into a desktop running a 4.2 kernel to > see what it does? It actually does work with 4.2, so if all else fails we may update to this kernel. On Thu, Sep 17, 2015 at 8:49 AM, Alan Stern wrote: > If the problem affects both the EHCI and xHCI controllers, why do you > want to work around by changing only xhci-hcd? Wouldn't it be better > to change the USB core? We're looking into this and have realized this is probably the best place to make a patch, thank you. > What type of endpoint is this, anyway (control, bulk, interrupt, or > isochronous)? We're using an isochronous transfer. On Thu, Sep 17, 2015 at 12:57 PM, Fabio Estevam wrote: > You could just build 4.2 or 4.3-rc1 manually and deploy it. > > We use Yocto with kernel 4.1 without issues. Thanks, we may try this if we don't get a patch up and running. Thanks again, Todd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 03/32] usb: dwc2: host: add flag to reflect bus state
Hi, On Wed, Sep 9, 2015 at 3:20 AM, Mian Yousaf Kaukab wrote: > /* Update lx_state */ > - hsotg->lx_state = DWC2_L2; > + hsotg->bus_suspended = 1; /* Update comment */ -Doug -- 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 v8 1/3] usb: make xhci platform driver use 64 bit or 32 bit DMA
On Thu, Sep 17, 2015 at 12:51 PM, Arnd Bergmann wrote: > On Thursday 17 September 2015 11:19:46 Duc Dang wrote: >> The xhci platform driver needs to work on systems that >> either only support 64-bit DMA or only support 32-bit DMA. >> Attempt to set a coherent dma mask for 64-bit DMA, and >> attempt again with 32-bit DMA if that fails. >> >> [dhdang: regenerate the patch over v4.3-rc1 and address new comments] >> Signed-off-by: Mark Langsdorf >> Tested-by: Mark Salter >> Signed-off-by: Duc Dang >> > > Acked-by: Arnd Bergmann Thanks, Arnd. -- Regards, Duc Dang. -- 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: Applying Patch to Change Max Packet Size for Device
On Thu, 17 Sep 2015, Todd Efflam wrote: > On Thu, Sep 17, 2015 at 8:49 AM, Alan Stern wrote: > > If the problem affects both the EHCI and xHCI controllers, why do you > > want to work around by changing only xhci-hcd? Wouldn't it be better > > to change the USB core? > > We're looking into this and have realized this is probably the best > place to make a patch, thank you. Then you should look at usb_parse_endpoint() in drivers/usb/core/config.c. It already makes a bunch of adjustments along similar lines to what you need. 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 V5 1/1] usb:serial add Fintek F81532/534 driver
Johan Hovold 於 2015/9/14 下午 09:33 寫道: > On Tue, Jul 21, 2015 at 09:58:19AM +0800, Peter Hung wrote: >> This driver is for Fintek F81532/F81534 USB to Serial Ports IC. >> > So as I mentioned above, always accept data if there's room in the fifo. > Then kick of a write urb, if TX_EMPTY is set for any of the ports and > fill the urb based on those flags as well. > I'll try to improve it with V6, but it'll need more time to do modification & verification. So V6 will release lately. Thank you for your advice. -- With Best Regards, Peter Hung -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3] dummy_hcd: replace timeval with timespec64
The millisecond of the last second will be normal if tv_sec is
overflowed. But for y2038 consistency and demonstration purpose,
and avoiding further risks, we need to remove 'timeval' in this
driver, to avoid similair problems.
Signed-off-by: Pingbo Wen
Reviewed-by: Arnd Bergmann
---
V3 Updates:
- using ts64 variable name to avoid confusion
V2 Updates:
- using monotonic time here by replacing getnstimeofday() with
ktime_get_ts64(), to avoid leap second issues. The frame time in USB
is always 1ms, no matter what speed, so ktime_get_ts64() have enough
resolution to cover this.
- using NSEC_PER_MSEC instead of hard code.
drivers/usb/gadget/udc/dummy_hcd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/dummy_hcd.c
b/drivers/usb/gadget/udc/dummy_hcd.c
index 1379ad4..2ac9a13 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = {
/* there are both host and device side versions of this call ... */
static int dummy_g_get_frame(struct usb_gadget *_gadget)
{
- struct timeval tv;
+ struct timespec64 ts64;
- do_gettimeofday(&tv);
- return tv.tv_usec / 1000;
+ ktime_get_ts64(&ts64);
+ return ts64.tv_nsec / NSEC_PER_MSEC;
}
static int dummy_wakeup(struct usb_gadget *_gadget)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 27/32] usb: dwc2: gadget: kill ep0 requests before reinitializing core
On 9/9/2015 3:21 AM, Mian Yousaf Kaukab wrote:
> Make sure there are no requests pending on ep0 before reinitializing
> core. Otherwise, dwc2_hsotg_enqueue_setup will fail afterwards.
>
> Signed-off-by: Mian Yousaf Kaukab
> Tested-by: Robert Baldyga
> ---
> drivers/usb/dwc2/gadget.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index c7da6b7..a6a1a6a 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -2287,6 +2287,9 @@ void dwc2_hsotg_core_init_disconnected(struct
> dwc2_hsotg *hsotg,
> {
> u32 val;
>
> + /* Kill any ep0 requests as controller will be reinitialized */
> + kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
> +
I am seeing this hang when I start off as a B-device, then plug
in an A-cable with no device attached on the other end. Then
unplug it.
I haven't verified but it is probably due to the
dwc2_hsotg_complete_request() (called from kill_all_requests)
expecting lock to be held. But this is not locked when called
from dwc2_conn_id_status_change().
John
--
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: First kernel patch (optimization)
On Wed, Sep 16, 2015 at 01:26:51PM -0400, Josh Boyer wrote: > > That isn't true. It helps the submitter understand the workflow and > expectations. What you meant to say is that it doesn't help you. The problem is that workflow isn't the hard part. It's the part that can be taught most easily, sure. But people seem to get really hung up on it, and I fear that we have people who never progress beyond sending trivial patches and spelling fixes and white space fixes and micro-optimizations. If the "you too can be a kernel developer" classes and web sites and tutorials also taught people how to take performance measurements, and something about the scientific measurement, that would be something. Or if it taught people how to create tests and to run regression testing. Or if it taught people how to try to do fuzz testing, and then once they find a sequence which causes crash, how to narrow down the failure to a specific part of the kernel, and how to fix and confirm that the kernel no longer crashes with the fix --- that would be useful. If they can understand kernel code; if they can understand the scientific measurement; if they can understand how to do performance measurements --- being able to properly format patches is something which most kernel developers can very easily guide a new contributor to do correctly. Or in the worst case, it doesn't take much time for me to fix a whitespace problem and just tell the contributor --- by the way, I fixed up this minor issue; could you please make sure you do this in the future? But if a test hasn't been tested, or if the contributor things it's a micro-optimization, but it actually takes more CPU time and/or more stack space and/or bloats the kernel --- that's much more work for the kernel maintainer to have to deal with when reviewing a patch. So I have a very strong disagreement with the belief that teaching people the workflow is the more important thing. In my mind, that's like first focusing on the proper how to properly fill out a golf score card, and the ettiquette and traditions around handicaps, etc --- before making sure the prospective player is good at putting and driving. Personally, I'm terrible at putting and driving, so spending a lot of time learning how to fill out a golf score card would be a waste of my time. A good kernel programmer has to understand systems thinking; how to figure out abstractions and when it's a good thing to add a new layer of abstraction and when it's better to rework an exsting abstraction layer. If we have someone who knows the workflow, but which doesn't understand systems thinking, or how to do testing, then what? Great, we've just created another Nick Krause. Do you think encouraging a Nick Krause helps anyone? If people really are hung up on learning the workflow, I don't mind if they want to learn that part and send some silly micro-optimization or spelling fix or whitespace fix. But it's really, really important that they move beyond that. And if they aren't capable of moving beyond that, trying to inflate are recruitment numbers by encouraging someone who can only do trivial fixes means that we may be get what we can easily measure --- but it may not be what we really need as a community. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"
On Wed, Sep 16, 2015 at 08:54:25AM -0500, Rob Herring wrote: > On 09/15/2015 08:49 PM, Peter Chen wrote: > > Some SoCs needs three clock to let controller work, but others only > > need one, add one property to differentiate this. > > A given licensed IP block is going to have the same number of clock > inputs from SOC to SOC. Yes, I agree with you. > So different numbers of clocks is a bit suspect. > I guess there can be variations in bus clocks or other outside logic. There are legacy platforms, no one knows exactly what the other clocks are used for, and the former i.mx usb driver (see drivers/usb/gadget/udc/fsl_mxc_udc.c) uses like this way. So, I just follow it. > > > > > Signed-off-by: Peter Chen > > --- > > Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > > b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > > index f15a317..4900092 100644 > > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt > > @@ -54,6 +54,9 @@ i.mx specific properties > >argument that indicate usb controller index > > - disable-over-current: disable over current detect > > - external-vbus-divider: enables off-chip resistor divider for Vbus > > +- need-three-clocks: the SoC before imx6 series (except for imx23/imx28) > > + needs three clcoks for controller, others only need one. Without this > > + property, the driver will consider this controller only need one clock. > > That's pretty ugly and unnecessary. Either use the compatible string to > determine Since there are too many SoCs to use it, I just didn't want to add judgement for platforms, and thought using feature property is simpler. If you doesn't agree, I will use other ways. > if you have 3 clocks or just always try to retrieve the 3 > clocks in the driver and fall back to 1. > It is not easy to use this way, one-clock platforms have no dev_id for clock, but three-clock platforms have. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] USB: EHCI: fix dereference of ERR_PTR
On Wed, Sep 16, 2015 at 12:54:03PM -0400, Alan Stern wrote: > On Wed, 16 Sep 2015, Sudip Mukherjee wrote: > > > On error find_tt() returns either a NULL pointer or the error value in > > ERR_PTR. But we were dereferencing it directly without even checking if > > find_tt() returned a valid pointer or not. > > > > Signed-off-by: Sudip Mukherjee > > --- > > @@ -1373,6 +1375,8 @@ static void reserve_release_iso_bandwidth(struct > > ehci_hcd *ehci, > > } > > > > tt = find_tt(stream->ps.udev); > > + if (IS_ERR_OR_NULL(tt)) > > + return; > > if (sign > 0) > > list_add_tail(&stream->ps.ps_list, &tt->ps_list); > > else > > This patch isn't needed. In both reserve_release_intr_bandwidth() and > reserve_release_iso_bandwidth() it is known that find_tt() will return > a valid pointer. > > This is because each of those functions is called from only one place. > For example, reserve_release_intr_bandwidth() is called only at the end > of qh_schedule(). But near the start of qh_schedule() there is earlier > call to tt_find(), and there we do test for error pointers. If the > first call doesn't return an error then the second call won't either. > > The same sort of thing happens in reserve_release_iso_bandwidth(). Yes, I should have looked more before sending. Sorry for the noise. But in those checkes for find_tt() only IS_ERR is checked, shouldn't we check for IS_ERR_OR_NULL as find_tt() can return NULL also? regards sudip -- 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: renesas_usbhs: Add support for R-Car H3
This patch adds a compatible string to support for R-Car H3.
Since the HS-USB controller of R-Car H3 is almost the same specification
with R-Car Gen2 (these have 16 pipes and usb-dmac), this patch
sets the "type" of renesas_usbhs_driver_param to USBHS_TYPE_RCAR_GEN2.
Signed-off-by: Yoshihiro Shimoda
---
This patch is based on the latest Felipe's usb.git / testing/next
branch (The commit id = b1ede0faf6e4961842f80e5e2fc1bf5373fef235).
Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 1 +
drivers/usb/renesas_usbhs/common.c | 4
2 files changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 64a4ca6..7d48f63 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -5,6 +5,7 @@ Required properties:
- "renesas,usbhs-r8a7790"
- "renesas,usbhs-r8a7791"
- "renesas,usbhs-r8a7794"
+ - "renesas,usbhs-r8a7795"
- reg: Base address and length of the register for the USBHS
- interrupts: Interrupt specifier for the USBHS
- clocks: A list of phandle + clock specifier pairs
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index 7b98e1d..2becd6b 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -476,6 +476,10 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7794",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+ {
+ .compatible = "renesas,usbhs-r8a7795",
+ .data = (void *)USBHS_TYPE_RCAR_GEN2,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, usbhs_of_match);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
Hi, On Wednesday 16 September 2015 12:14 PM, Chunfeng Yun wrote: > support usb3.0 phy of mt65xx SoCs few nitpicks: change $subject. This driver is no longer in usb directory. It can be just "phy: add usb3.0 phy driver for mt65xx SoCs". > > Signed-off-by: Chunfeng Yun > --- > drivers/phy/Kconfig | 9 + > drivers/phy/Makefile | 1 + > drivers/phy/phy-mt65xx-usb3.c | 456 > ++ > 3 files changed, 466 insertions(+) > create mode 100644 drivers/phy/phy-mt65xx-usb3.c > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 47da573..ec436c1 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -206,6 +206,15 @@ config PHY_HIX5HD2_SATA > help > Support for SATA PHY on Hisilicon hix5hd2 Soc. > > +config PHY_MT65XX_USB3 > + tristate "Mediatek USB3.0 PHY Driver" > + depends on ARCH_MEDIATEK && OF > + select GENERIC_PHY > + help > + Say 'Y' here to add support for Mediatek USB3.0 PHY driver > + for mt65xx SoCs. it supports two usb2.0 ports and > + one usb3.0 port. > + > config PHY_SUN4I_USB > tristate "Allwinner sunxi SoC USB PHY driver" > depends on ARCH_SUNXI && HAS_IOMEM && OF > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index a5b18c1..a7cc629 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -23,6 +23,7 @@ obj-$(CONFIG_TI_PIPE3) += > phy-ti-pipe3.o > obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o > obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o > obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o > +obj-$(CONFIG_PHY_MT65XX_USB3)+= phy-mt65xx-usb3.o > obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o > obj-$(CONFIG_PHY_SUN9I_USB) += phy-sun9i-usb.o > obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o > diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c > new file mode 100644 > index 000..1f00b05 > --- /dev/null > +++ b/drivers/phy/phy-mt65xx-usb3.c > @@ -0,0 +1,456 @@ > +/* > + * Copyright (c) 2015 MediaTek Inc. > + * Author: Chunfeng Yun > + * > + * 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 > + > +/* > + * for sifslv2 register, but exclude port's; > + * relative to USB3_SIF2_BASE base address > + */ > +#define SSUSB_SIFSLV_SPLLC 0x > + > +/* offsets of sub-segment in each port registers */ > +#define SSUSB_SIFSLV_U2PHY_COM_BASE 0x > +#define SSUSB_SIFSLV_U3PHYD_BASE 0x0100 > +#define SSUSB_USB30_PHYA_SIV_B_BASE 0x0300 > +#define SSUSB_SIFSLV_U3PHYA_DA_BASE 0x0400 > + > +#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) > +#define PA0_RG_U2PLL_FORCE_ONBIT(15) > + > +#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) > +#define PA2_RG_SIF_U2PLL_FORCE_ENBIT(18) > + > +#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) > +#define PA5_RG_U2_HSTX_SRCTRLGENMASK(14, 12) > +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) > +#define PA5_RG_U2_HS_100U_U3_EN BIT(11) > + > +#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) > +#define PA6_RG_U2_ISO_EN BIT(31) > +#define PA6_RG_U2_BC11_SW_EN BIT(23) > +#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) > + > +#define U3P_U2PHYACR4(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) > +#define P2C_RG_USB20_GPIO_CTLBIT(9) > +#define P2C_USB20_GPIO_MODE BIT(8) > +#define P2C_U2_GPIO_CTR_MSK (P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) > + > +#define U3D_U2PHYDCR0(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) > +#define P2C_RG_SIF_U2PLL_FORCE_ONBIT(24) > + > +#define U3P_U2PHYDTM0(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) > +#define P2C_FORCE_UART_ENBIT(26) > +#define P2C_FORCE_DATAIN BIT(23) > +#define P2C_FORCE_DM_PULLDOWNBIT(21) > +#define P2C_FORCE_DP_PULLDOWNBIT(20) > +#define P2C_FORCE_XCVRSELBIT(19) > +#define P2C_FORCE_SUSPENDM BIT(18) > +#define P2C_FORCE_TERMSELBIT(17) > +#define P2C_RG_DATAINGENMASK(13, 10) > +#define P2C_RG_DATAIN_VAL(x) ((0xf & (x)) << 10) > +#define P2C_RG_DMPULLDOWNBIT(7) > +#define P2C_RG_DPPULLDOWN
Re: USB client crash on Vybrid with USB gadget RNDIS connection
On Wed, Sep 16, 2015 at 02:48:50PM +0530, maitysancha...@gmail.com wrote: > On 15-09-16 15:54:21, Peter Chen wrote: > > On Wed, Sep 16, 2015 at 02:18:49PM +0530, maitysancha...@gmail.com wrote: > > > Hello Peter, > > > > > > > > > > > Enable CONFIG_DEBUG_LIST, it has below position if you > > > > run make menuconfig > > > > Kernel hacking ---> > > > > [*] Debug linked list manipulation > > > > > > > > > > Sorry for the delay. When I enabled this config the first time my test > > > application ran for 24 hours or so and I did not get any stack traces. > > > > > > I restarted the test again and finally got the trace below. You were > > > spot on, its a list corruption issue. I modified the trace a bit after > > > copying to remove the sprinkled debug messages throughout the trace > > > from my test application. > > > > > > [ 622.204134] WARNING: CPU: 0 PID: 0 at lib/list_debug.c:59 > > > __list_del_entry+0xc4/0xe8() > > > [ 622.212870] list_del corruption. prev->next should be 8db63600, but > > > was 36008db6 > > > > You see the higher 16 bits were swapped with lower 16 bits, and the > > virtual memory address should begin from 0x8, right? > > Yes, I saw that but beats me how this happens. > > > > > Check with Vybrid errata to see if all ARM/memory system have applied. > > What do you mean by "all ARM/memory system have applied" ? I checked with the > Vybrid errata > and I do not see anything related. > Just system level errata, like ARM Cortex A5, memory (L1/L2 Cache), etc. Would you please do more tests to see if the error pattern is always the same? And print the address to store prev-next. -- Best Regards, Peter Chen -- 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
