Re: [GIT PULL] usb: chipidea: changes for v4.19-rc1

[gre...@linuxfoundation.org]

On Fri, Jul 27, 2018 at 03:35:54AM +, Peter Chen wrote:
>  The following changes since commit dc748b66dbfbbfa187044f007d42d9cc01e5ab11:
> 
>   dt-bindings: usb: new ehci-npcm7xx dt (2018-06-25 21:59:15 +0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ 
> tags/usb-ci-v4.19-rc1

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

Re: DWC2 maintainership change

[Greg Kroah-Hartman (gre...@linuxfoundation.org)]

On Thu, Mar 15, 2018 at 04:00:25AM +, John Youn wrote:
> Hi Felipe, Greg,
> 
> I won't be able to continue maintainership of dwc2.
> 
> Minas Harutyunyan, has been doing most of the communication on linux-usb 
> lately and much of the maintenance and development work. He has excellent 
> knowledge of the controller, having worked with it since its inception many 
> years ago.
> 
> I propose that he take over as the new maintainer.

No objection to me, send in a patch.

And thanks for your time being the maintainer, it's much appreciated.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: dwc3: gadget: only unmap requests from DMA if mapped

[gre...@linuxfoundation.org]

On Tue, Oct 03, 2017 at 06:41:54PM +, Thinh Nguyen wrote:
> Hi,
> 
> On 9/11/2017 12:42 AM, Felipe Balbi wrote:
> > 
> > Hi,
> > 
> > Thinh Nguyen  writes:
> >>> Felipe Balbi  writes:
>  Thinh Nguyen  writes:
> 
> > Hi Felipe,
> >
> > On 9/7/2017 12:16 AM, Felipe Balbi wrote:
> >  drivers/usb/dwc3/gadget.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index 9e41605a..6b299c7 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -191,14 +191,16 @@ void dwc3_gadget_giveback(struct dwc3_ep 
> > *dep, struct dwc3_request *req,
> >  
> > req->started = false;
> > list_del(>list);
> > -   req->trb = NULL;
> > req->remaining = 0;
> >  
> > if (req->request.status == -EINPROGRESS)
> > req->request.status = status;
> >  
> > -   usb_gadget_unmap_request_by_dev(dwc->sysdev,
> > -   >request, req->direction);
> > +   if (req->trb)
>  This check does not account for control data transfer. TRBs for ep0 
>  are
>  not set to its req->trb. ep0out request needs to be unmapped, 
>  otherwise
>  device will receive bogus data.
> 
>  Our internal test showed that the device failed to interpret control
>  data from host. I bisected to this patch.
> >>
> >> what was the testing? How can I reproduce it?
> >
> > This is a regression. The internal test found the issue when it does a
> > 3-stage Control Write Transfer. You can reproduce this issue with just 1
> > out data packet of size > 0. Read and check the data on control request
> > completion.
> 
>  okay, is this enough to fix the problem for you?
> 
>  modified   drivers/usb/dwc3/ep0.c
>  @@ -48,6 +48,9 @@ static void dwc3_ep0_prepare_one_trb(struct dwc3_ep 
>  *dep,
>   dwc = dep->dwc;
>   trb = >ep0_trb[dep->trb_enqueue];
> 
>  +if (!req->trb)
>  +req->trb = trb;
>  +
>   if (chain)
>   dep->trb_enqueue++;
> >>>
> >>> sorry, no. this is totally wrong :-) Here's a better version:
> >>>
> >>> modified   drivers/usb/dwc3/ep0.c
> >>> @@ -990,6 +990,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 
> >>> *dwc,
> >>>DWC3_TRBCTL_CONTROL_DATA,
> >>>true);
> >>>
> >>> + req->trb = >ep0_trb[dep->trb_enqueue - 1]; > +
> >>>   /* Now prepare one extra TRB to align transfer size */
> >>>   dwc3_ep0_prepare_one_trb(dep, dwc->bounce_addr,
> >>>maxpacket - rem,
> >>> @@ -1015,6 +1017,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 
> >>> *dwc,
> >>>DWC3_TRBCTL_CONTROL_DATA,
> >>>true);
> >>>
> >>> + req->trb = >ep0_trb[dep->trb_enqueue - 1]; > +
> >>>   /* Now prepare one extra TRB to align transfer size */
> >>>   dwc3_ep0_prepare_one_trb(dep, dwc->bounce_addr,
> >>>0, DWC3_TRBCTL_CONTROL_DATA,
> >>> @@ -1029,6 +1033,9 @@ static void __dwc3_ep0_do_control_data(struct dwc3 
> >>> *dwc,
> >>>   dwc3_ep0_prepare_one_trb(dep, req->request.dma,
> >>>   req->request.length, 
> >>> DWC3_TRBCTL_CONTROL_DATA,
> >>>   false);
> >>> +
> >>> + req->trb = >ep0_trb[dep->trb_enqueue];
> >>> +
> >>>   ret = dwc3_ep0_start_trans(dep);
> >>>   }
> >>>
> >>> (didn't even compile test)
> >>>
> >>>
> >>
> >> Yes this works.
> > 
> > Thank you, I'll send this as a formal patch after merge window closes.
> > 
> 
> The fix for this patch is now in mainline. Please also apply it to 
> stable kernel 4.13.x. Otherwise this regression will remain for the 
> kernel 4.13.x.
> 
> Upstream:
> commit 551684708356 ("usb: dwc3: ep0: fix DMA starvation by assigning 
> req->trb on ep0")

Now queued up, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: pl2303: adding TD620 Device ID

[gre...@linuxfoundation.org]

On Tue, Sep 19, 2017 at 09:41:48PM +, Schoon, Michael wrote:
> Signed-off-by: Michael Schoon 

No changelog at all?  I know I can't take patches like that, hopefully
Johan has the same rule :)

> ---
>  drivers/usb/serial/pl2303.c | 1 +
>  drivers/usb/serial/pl2303.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index a585b47..eab0e55 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -94,6 +94,7 @@ static const struct usb_device_id id_table[] = {
>  { USB_DEVICE(HP_VENDOR_ID, HP_LD960_PRODUCT_ID) },
>  { USB_DEVICE(HP_VENDOR_ID, HP_LCM220_PRODUCT_ID) },
>  { USB_DEVICE(HP_VENDOR_ID, HP_LCM960_PRODUCT_ID) },
> +   { USB_DEVICE(HP_VENDOR_ID, HP_TD620_PRODUCT_ID) },
>  { USB_DEVICE(CRESSI_VENDOR_ID, CRESSI_EDY_PRODUCT_ID) },
>  { USB_DEVICE(ZEAGLE_VENDOR_ID, ZEAGLE_N2ITION3_PRODUCT_ID) },
>  { USB_DEVICE(SONY_VENDOR_ID, SONY_QN3USB_PRODUCT_ID) },

Your patch has had the tabs turned into spaces, making this impossible
to apply.  Try testing it out first by emailing it to yourself.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Consult on the Multifunction Composite Gadget problem

[gre...@linuxfoundation.org]

On Sat, Jul 01, 2017 at 08:41:20AM +, Lipengcheng wrote:
> Hi,
> 
> Now I am prepared based on 3.18 linux kernel development Multifunction
> Composite Gadget, which RNDIS + CDC Serial + USB Webcam Gadget, the kernel
> community has this development plan, or what needs attention.

I have no idea what you are asking here, please be more specific.

Also note that 3.18 is very old and obsolete and should never be used
for a new device.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Fri, Mar 17, 2017 at 10:56:37AM +, Ajay Kaher wrote:
> There is race condition when two USB class drivers try to call
> init_usb_class at the same time and leads to crash.
> code path: probe->usb_register_dev->init_usb_class
> 
> To solve this, mutex locking has been added in init_usb_class() and 
> destroy_usb_class().
> 
> As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
> because usb_class can never be NULL there.
> 
> Signed-off-by: Ajay Kaher 
> Acked-by: Alan Stern 
> ---
>  drivers/usb/core/file.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..422ce7b 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS   256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
>  
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
>  
>  static void destroy_usb_class(void)
>  {
> - if (usb_class)
> - kref_put(_class->kref, release_usb_class);
> + mutex_lock(_usb_class_mutex);
> + kref_put(_class->kref, release_usb_class);
> + mutex_unlock(_usb_class_mutex);
>  }
>  
>  int usb_major_init(void)
> @@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
>   if (intf->minor >= 0)
>   return -EADDRINUSE;
>  
> + mutex_lock(_usb_class_mutex);
>   retval = init_usb_class();
> + mutex_unlock(_usb_class_mutex);
> +
>   if (retval)
>   return retval;
>  

I get the following errors when trying to apply this patch:

Applying: USB: Proper handling of Race Condition when two USB class drivers try 
to call init_usb_class simultaneously
.git/rebase-apply/patch:13: trailing whitespace.
static DEFINE_MUTEX(init_usb_class_mutex);
.git/rebase-apply/patch:23: trailing whitespace.
mutex_lock(_usb_class_mutex);
.git/rebase-apply/patch:24: trailing whitespace.
kref_put(_class->kref, release_usb_class);
.git/rebase-apply/patch:25: trailing whitespace.
mutex_unlock(_usb_class_mutex);
.git/rebase-apply/patch:33: trailing whitespace.
mutex_lock(_usb_class_mutex);
error: patch failed: drivers/usb/core/file.c:27
error: drivers/usb/core/file.c: patch does not apply
Patch failed at 0001 USB: Proper handling of Race Condition when two USB class 
drivers try to call init_usb_class simultaneously


Are you sure you made this in the correct format?  Seems that the patch
has dos line-ends :(

Please fix up and resend.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Thu, Mar 09, 2017 at 11:34:25AM +, Ajay Kaher wrote:
> From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001
> From: Ajay Kaher 
> Date: Thu, 9 Mar 2017 16:07:54 +0530
> Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when 
> two
>  USB class drivers try to call init_usb_class simultaneously

Why is your subject line have the word "subject" in it?

Please fix your email client so you don't have the whole git commit
header in the body of the email like you do here.

Also, no need to say "Core:" or "BugFix:"

> 
> There is race condition when two USB class drivers try to call
> init_usb_class at the same time and leads to crash.
> code path: probe->usb_register_dev->init_usb_class
>  
> To solve this, mutex locking has been added in init_usb_class() and 
> destroy_usb_class().
> 
> As pointed by Alan, removed "if (usb_class)" test from destroy_usb_class()
> because usb_class can never be NULL there.
> 
> Signed-off-by: Ajay Kaher 
> Acked-by: Alan Stern 
> ---
>  drivers/usb/core/file.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..422ce7b 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
>  #define MAX_USB_MINORS 256
>  static const struct file_operations *usb_minors[MAX_USB_MINORS];
>  static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
> 
>  static int usb_open(struct inode *inode, struct file *file)
>  {
> @@ -109,8 +110,9 @@ static void release_usb_class(struct kref *kref)
> 
>  static void destroy_usb_class(void)
>  {
> - if (usb_class)
> -  kref_put(_class->kref, release_usb_class);
> + mutex_lock(_usb_class_mutex);
> + kref_put(_class->kref, release_usb_class);
> + mutex_unlock(_usb_class_mutex);
>  }
> 
>  int usb_major_init(void)
> @@ -171,7 +173,10 @@ int usb_register_dev(struct usb_interface *intf,
>   if (intf->minor >= 0)
>return -EADDRINUSE;
> 
> + mutex_lock(_usb_class_mutex);
>   retval = init_usb_class();
> + mutex_unlock(_usb_class_mutex);
> +
>   if (retval)
>return retval;
> 

All tabs were turned into spaces and this patch can not be applied :(

Please fix up and try again.  Send a patch to yourself first to see if
it works properly before sending it to us.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Tue, Mar 07, 2017 at 04:35:37AM +, Ajay Kaher wrote:
>  
>  
>  
> > On Fri, 3 Mar 2017, Ajay Kaher wrote:
> > 
> > > > usb_class->kref is not accessible outside the file.c
> > > > as usb_class is _static_ inside the file.c and
> > > > pointer of usb_class->kref is not passed anywhere.
> > > > 
> > > > Hence as you wanted, there are no references of usb_class->kref
> > > > other than taken by init_usb_class() and released by 
> > >destroy_usb_class().
> > > 
> > > Verified the code again, I hope my last comments clarifed the things
> > > which came in your mind and helps you to accept the patch :)
> >  
> > Your main point is that usb_class->kref is accessed from only two
> > points, both of which are protected by the new mutex.  This means there
> > is no reason for the value to be a struct kref at all.  You should
> > change it to an int (and change its name).  Leaving it as a kref will
> > make readers wonder why it needs to be updated atomically.
> 
> At many places in Linux kernel, instances of Kref have been used within
> Mutex, SpinLock and don’t have any side effect.
> 
> Making to int and handle (i.e. get/put) it within file.c seems
> not good as we have Kref. Instead, we can have non_atomic version of kref.
> We can discuss about non_atomic kref in another thread, if you are interested.
> 
> > Also, why does destroy_usb_class() have that "if (usb_class) "test? 
> > Isn't it true that usb_class can never be NULL there?
> 
> Removed in Patch v4.
> 
> thanks,
> ajay kaher
>  
>   
> Signed-off-by: Ajay Kaher
>  

Can you resend this in a format that I can apply it in?  I suggest
reading Documentation/SubmittingPatches.  If you have any questions
about the correct format, please let me know.

Also add Alan's ack to it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[gre...@linuxfoundation.org]

On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote:
> > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote:
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that might lead to use-after-free
> > > situations.
> > 
> > Looks good. Let me know how do you want to route the patch to upstream.
> 
> Greg, you previously mentioned that driver's conversions can go via your 
> tree. Does this still apply?
> Or should I be asking maintainers to merge these patches via their trees? 

You should ask them to take them through their trees, if they have them.
I'll be glad to scoop up all of the remaining ones that get missed, or
for subsystems that do not have trees.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Wed, Feb 01, 2017 at 07:24:44AM +, Ajay Kaher wrote:
>  
> >> At boot time, probe function of multiple connected devices
> >> (proprietary devices) execute simultaneously.
> >
> >What exactly do you mean here?  How can probe happen "simultaneously"?
> >The USB core prevents this, right?
> 
> I have observed two scenarios to call probe function:
> 
> Scenario #1: Driver inserted and attaching USB Device:
> Yes, you are right, two probes at same time is not happening
> in this scenario.
> 
> Scenario #2: USB Device attached and inserting Driver:
> In this case probe has been called in context of insmod,
> refer following code flow:
> init -> usb_register_driver -> driver_register -> bus_add_driver ->
> driver_attach -> bus_for_each_dev -> __driver_attach ->
> driver_probe_device -> usb_probe_interface -> probe -> usb_register_dev
> 
> I have observed the crash in Scenario #2, as two probes executes at
> same time in this scenario. And init_usb_class_mutex lock require to
> prevent race condition.

What about the fact that in __driver_attach() we call device_lock() so
that probe never gets called at the same time for the same device?

Or are you saying that you can load multiple USB modules at the same
time?  If so, how is insmod running on multiple cpus at the same time?
I thought we had a global lock there to prevent that from happening
(i.e. only one module can be loaded at a time.)  Or is that what has
recently changed?

What is causing your modules to be loaded from userspace?  What type of
device is this happening for?  And why haven't we seen this before?
What kernel versions have you had a problem with this?

And what for what drivers specifically?

> >> And because of the following code path race condition happens:
> >> probe->usb_register_dev->init_usb_class
> >
> >Why is this just showing up now, and hasn't been an issue for the decade
> >or so this code has been around?  What changed?
> >
> >> Tested with these changes, and problem has been solved.
> >
> >What changes?
> 
> Tested with my patch (i.e. locking with init_usb_class_mutex).

I don't see a patch here :(

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Tue, Jan 31, 2017 at 05:21:46AM +, Ajay Kaher wrote:
> 
>  
> At boot time, probe function of multiple connected devices
> (proprietary devices) execute simultaneously.

What exactly do you mean here?  How can probe happen "simultaneously"?
The USB core prevents this, right?

And what do you mean exactly by "(proprietary devices)"?

> And because of the following code path race condition happens:
> probe->usb_register_dev->init_usb_class

Why is this just showing up now, and hasn't been an issue for the decade
or so this code has been around?  What changed?

> Tested with these changes, and problem has been solved.

What changes?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

[gre...@linuxfoundation.org]

On Mon, Jan 30, 2017 at 08:25:25AM +, Ajay Kaher wrote:
>  

First off, you are sending html email, which the mailing list keeps
rejecting, why are you ignoring that?



> 
> There is race condition when two USB class drivers try to call
> 
> init_usb_class at the same time and leads to crash.
> 
>  
> 
> The main reason for this is one of the Class drivers allocates memory
> for usb_class structure and initializes its member. In the meantime NULL
> check for usb_class structure fails and assumes that usb_class structure
> is properly initialized and crashed while trying to access its members.
> 
>  
> 
> To avoid this race condition locking required before calling
> init_usb_class from function usb_register_dev.
> 
>  
> 
>  
> 
> Signed-off-by: Ajay Kaher

Does this look correct?  Please work with some of the samsung kernel
developers for how to properly submit a patch.

And finally, how are two drivers calling init_usb_class() at the same
time?  What code path causes that?  Have you seen this happen, and if
so, what drivers caused it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: unable to handle EVENT RING FULL error in xhci

[gre...@linuxfoundation.org]

On Fri, Jan 20, 2017 at 07:59:48AM +, Anurag Kumar Vulisha wrote:
> Hi,

Hi!

Minor nit, vger.kernel.org rejects html emails, so this didn't make it
through to that list.  Now it should with my response :)

> I have a usecase where I want to stream a stereo video from the ZED Stereo
> Camera  (www.stereolabs.com) by connecting it  to our ZynqMP SOC based 
> platform
> using the USB 3.0 interface. This camera keeps on streaming 48k chunks of BULK
> data to the HOST. Initially the data is received correctly, but after some 
> time
> I noticed frame corruption on the BULK packets received by HOST controller. On
> debugging I found that HOST event ring is full and it issues “EVENT RING FULL
> ERROR” and this error seems to be not handled in XHCI. I am using linux 4.6
> kernel for testing . Please help me in by giving any suggestions on how to
> handle this issue? Currently I increased the TRB_PER_SEGMENT from 256 to 512
> but the issue seems to delayed and gets reproduced after some more time.
> 
> To increase the TRB_PER_SEGMENT from 256 to 512 I made the below changes
> 
> xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
> TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size * 4);
> 
> Is this the correct way ? or I am doing wrong.
> 
> It would be very helpful if you can help me in solving this issue

4.6 is very old and obsolete and behind in a lot of xhci fixes.  Can you
test 4.9.4 or even better yet, Linus's 4.10-rc4 tree to see if the issue
is still there?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] usb: host: xhci: plat: add support for otg_set_host() call

[gre...@linuxfoundation.org]

Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Mon, Jan 02, 2017 at 09:35:21AM +, Manish Narani wrote:
> Hi Greg,
> 
> 
> I need to have this infrastructure while implementing DWC3 OTG driver.
> The current scenario is that we are using xHCI drivers with High-Speed
> OTG because DWC3 uses xHCI framework. So I wanted to confirm that
> before adding DWC3 OTG driver, this support should be already there. I
> am planning to add DWC3 OTG driver after this patch is added.
> 
> Please let me know your valuable suggestions on this.

Post your whole series, that shows how you are using the new
infrastructure, otherwise how are we supposed to know this?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] usb: host: xhci: plat: add support for otg_set_host() call

[gre...@linuxfoundation.org]

On Mon, Jan 02, 2017 at 06:30:02AM +, Manish Narani wrote:
> Ping !!
> 
> -Original Message-
> From: Manish Narani [mailto:manish.nar...@xilinx.com]
> Sent: Thursday, December 15, 2016 1:24 PM
> To: mathias.ny...@intel.com; gre...@linuxfoundation.org; 
> linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org
> Cc: Anurag Kumar Vulisha <anura...@xilinx.com>; Punnaiah Choudary Kalluri 
> <punn...@xilinx.com>; Anirudha Sarangi <anir...@xilinx.com>; Manish Narani 
> <mnar...@xilinx.com>
> Subject: [RFC PATCH] usb: host: xhci: plat: add support for otg_set_host() 
> call
> 
> This patch will add support for OTG host initialization. This will help OTG 
> drivers to populate their host subsystem.

Don't add new infrastructure that is not used at all :(
--
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: hub: no error logs in case of enomem

[gre...@linuxfoundation.org]

On Wed, Nov 30, 2016 at 02:32:07PM +, Atul Raj wrote:
> All kmalloc-based functions print enough information on failures.
> 
> Signed-off-by: Atul Raj 
> ---
>  drivers/usb/core/hub.c | 1 -
>  1 file changed, 1 deletion(-)

I told you to wait, relax, and work on drivers/staging/ instead.

Sorry, I'm not going to take this as obviously you are not following
directions very well and are now wasting other people's time for no good
reason.

best of luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: host: replace symbolic permission with octal

[gre...@linuxfoundation.org]

On Wed, Nov 30, 2016 at 01:49:02PM +, Amit Kumar Kushwaha wrote:
> This patch handles warning message for preferring octal
> permissions over Symbolic permission for module parameter

That makes no sense at all.  What warning message?  Build time?  Run
time?

Please do cleanup patches on drivers/staging/ until you know how to do
them, don't start on the "core" kernel, as you will just annoy
maintainers (hint, you cc:ed too many people...)

good luck!

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: usb device to ether is not identification in 64bit Windows OS

[gre...@linuxfoundation.org]

On Sun, Sep 18, 2016 at 01:16:59PM +, Lipengcheng wrote:
> Hi,
> kernel version：4.8.0
> file:Documentation / usb / linux.inf
> problem:PC windows is 32bit OS, using Ethernet gadget driver, it can
> be correct identification. But PC windows is 64bit OS, while modifying
> linux.inf file LinuxDevice parameters, it can not correct
> identification, the serial port can be printed correctly:g_ether
> gadget: high-speed config # 2: RNDIS. I suspect that the linux.inf
> files are not mismatch 64bit windows OS.

Given that everyone here does not use Windows at all, you are going to
be on your own here, sorry.  If you do come up with an updated .inf
file, we will be glad to take a patch.

good luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DTS Support for max3421 SPI-USB Host controller

[gre...@linuxfoundation.org]

On Fri, Sep 02, 2016 at 12:02:12PM +, Hoefle Marco wrote:
> Hello Jaewon Kim,
> Please find the extended driver which allows configuring the gpout feature of 
> the  MAX3421 via DeviceTree.
> Please check and if ok I'll send a patch.

A patch is the only way we can review a driver.

Please submit it in that form and we will be glad to review it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5] Axi-usb: Add support for 64-bit addressing.

[gre...@linuxfoundation.org]

On Fri, Sep 02, 2016 at 06:02:14AM +, Nava kishore Manne wrote:
> This email and any attachments are intended for the sole use of the named 
> recipient(s) and contain(s) confidential information that may be proprietary, 
> privileged or copyrighted under applicable law. If you are not the intended 
> recipient, do not read, copy, or forward this email message or any 
> attachments. Delete this email message and any attachments immediately.
> 

Now deleted.

I have told you this before, this type of footer guarantees that your
patches, or emails, will not get reviewed.  It is the exact opposite of
working in public together.

Please have your company fix this.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: core: fix a double free in the usb driver

[gre...@linuxfoundation.org]

On Fri, May 27, 2016 at 01:38:17AM +, Chung-Geol Kim wrote:
> There is a double free problem in the usb driver.

Which driver?

> This is caused by delayed deregister for scsi device.
> <*> at Insert USB Storage
> -  USB bus #1 register
>  usb_create_hcd (primary-kref==1)
>  * primary-bandwidth_mutex(alloc))
> usb_get_hcd(primary-kref==2)
> -  USB bus #2 register
> usb_create_hcd (second-kref==1)
>  * second-bandwidth_mutex==primary-bandwidth_mutex
>  usb_get_hcd(second-kref==2)
> -  scsi_device_get
> usb_get_hcd(second-kref==3)
> 
> <*> at remove USB Storage (Normal)
> -  scsi_device_put
> usb_put_hcd(second-kref==2)
> -  USB bus #2 deregister
>  usb_release_dev(second-kref==1)
> usb_release_dev(second-kref==0)  -> hcd_release()
> -  USB bus #1 deregister
>  usb_release_dev(primary-kref==1)
>  usb_release_dev(primary-kref==0) -> hcd_release()
> *(primary-bandwidth_mutex free)
> 
> at remove USB Storage 
> -  USB bus #2 deregister
>  usb_release_dev(second-kref==2)
> usb_release_dev(second-kref==1)
> -  USB bus #1 deregister
>  usb_release_dev(primary-kref==1)
>  usb_release_dev(primary-kref==0) -> hcd_release()
>  *(primary-bandwidth_mutex free)
> -  scsi_device_put
>  usb_put_hcd(second-kref==0)  -> hcd_release(*)
>  * at this, second->primary==0 therefore try to
> free the primary-bandwidth_mutex.(already freed)

The formatting for this is all confused, can you fix it up?

> 
> To fix this problem kfree(hcd->bandwidth_mutex);
> should be executed at only (hcd->primary_hcd==hcd).
> 
> Signed-off-by: Chunggeol Kim 

We need an email address at the end of this line, look at how the
commits in the kernel git history look like for examples.

> ---
> drivers/usb/core/hcd.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index 34b837a..60077f3 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -2608,7 +2608,7 @@ static void hcd_release(struct kref *kref)
> struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref);
> 
> mutex_lock(_port_peer_mutex);
> - if (usb_hcd_is_primary_hcd(hcd)) {
> + if (hcd == hcd->primary_hcd) {

That doesn't make sense, usb_hcd_is_primary_hcd() is the same as this
check, what are you changing here?

> kfree(hcd->address0_mutex);
> kfree(hcd->bandwidth_mutex);
> }

Your patch itself is also corrupted, and can't be applied, can you also
resolve this and resend?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] USB: serial: option: add more ZTE device ids

[gre...@linuxfoundation.org]

From: lei liu <liu.le...@zte.com.cn>

More ZTE device ids.

Signed-off-by: lei liu <liu.le...@zte.com.cn>
Cc: stable <sta...@vger.kernel.org>
[properly sort them - gregkh]
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index c6f497f16526..c25ca7f77c42 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1602,7 +1602,79 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)_intf3_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x0178, 0xff, 0xff, 
0xff),
.driver_info = (kernel_ulong_t)_intf3_blacklist },
-   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xffe9, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff42, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff43, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff44, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff45, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff46, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff47, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff48, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff49, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff4a, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff4b, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff4c, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff4d, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff4e, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff4f, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff50, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff51, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff52, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff53, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff54, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff55, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff56, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff57, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff58, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff59, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5a, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5b, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5c, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5d, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5e, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff5f, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff60, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff61, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff62, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff63, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff64, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff65, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff66, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff67, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff68, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff69, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6a, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6b, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6c, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6d, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6e, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff6f, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff70, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff71, 0xff, 0xff, 
0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff72, 0xff, 0xff, 
0xff) },
+   { USB_D

Re: add device id to linux kernel

[gre...@linuxfoundation.org]

On Tue, May 03, 2016 at 07:56:54AM +0700, Lars Melin wrote:
> On 2016-05-02 20:43, gre...@linuxfoundation.org wrote:
> > On Mon, May 02, 2016 at 09:22:57AM +0300, Felipe Balbi wrote:
> > > 
> > > Hi,
> > > 
> > > 刘磊 <lei35...@163.com> writes:
> > > > dear linuxfoundation:
> > > >  I am liulei come from ZTEMT.  We need add some device ID to linux 
> > > > kernel, We need some help from yours.
> > > > Looking forward to you reply, thanks!
> > > > 
> > > > 
> > > > Signed-off-by:lei liu<liu.le...@zte.com.cn>
> > 
> > 
> > 
> > > Do all these devices really exist ? If they do, then please just send
> > > this as a proper patch and it should be simple to get it merged. See
> > > Documentation/SubmittingPatches for some hints as to how to write proper
> > > patches, but basically, your patch needs a commit log with a
> > > Signed-off-by line.
> > 
> > There is a signed-off-by line :)
> > 
> > --
> The patch is anyway wrong since it is inserted in the wrong place and the
> id's are reverse sorted.

I'll go fix it up...

--
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: add device id to linux kernel

[gre...@linuxfoundation.org]

On Mon, May 02, 2016 at 09:22:57AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> 刘磊  writes:
> > dear linuxfoundation:
> > I am liulei come from ZTEMT.  We need add some device ID to linux 
> > kernel, We need some help from yours. 
> > Looking forward to you reply, thanks!
> >
> >
> > Signed-off-by:lei liu



> Do all these devices really exist ? If they do, then please just send
> this as a proper patch and it should be simple to get it merged. See
> Documentation/SubmittingPatches for some hints as to how to write proper
> patches, but basically, your patch needs a commit log with a
> Signed-off-by line.

There is a signed-off-by line :)

--
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/2] usbip: modifications to event handler

[gre...@linuxfoundation.org]

On Wed, Mar 23, 2016 at 01:54:21AM +, fx IWATA NOBUO wrote:
> Hello Greg,
> 
> > adds errors and the second fixes it.
> 
> I divided patches as
> 1/2 event handler itself
> 2/2 programs use event handler.
> 
> So, programs use event handler which will be modified by 2/2 has errors at 
> 1/2.

That's a problem, we can not accept patches like this.

> > You need to fix patch 1/2
> 
> Could I send as one patch?

Maybe, it's your decision on how to do this best.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] usbip: modifications to event handler

[gre...@linuxfoundation.org]

On Tue, Mar 22, 2016 at 11:45:16PM +, fx IWATA NOBUO wrote:
> Hi,
> 
> The errors are cleared by patch 2/2.

That's not ok, you can not have one patch that adds errors and the
second fixes it.  Each has to have no problems on their own.

> Should I complete in patch 1/2?

You need to fix patch 1/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: 答复: 答复: 【xhci】suspend and resume core dump problem

[gre...@linuxfoundation.org]

On Tue, Mar 22, 2016 at 03:51:27AM +, Lipengcheng wrote:
> Hi,
>Thanks Lu Baolu,
> >The core dump says "PC is at xhci_mem_cleanup+0x4e4/0x574 [xhci_hcd] ".
> >But this call flow shows error happens in dma allocation. Which is correct?
> >Or, anything I misunderstood?
>  Sorry . I am not description clear . 
>  Because the interrupt makes the memory allocation fails, then enter the 
> error handling procedures(xhci_mem_cleanup).In the function,it is core dump. 

What is generating that interrupt?

--
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】suspend and resume core dump problem

[gre...@linuxfoundation.org]

On Tue, Mar 22, 2016 at 11:36:47AM +0800, Lu Baolu wrote:
> Hi,
> 
> On 03/22/2016 11:17 AM, Lipengcheng wrote:
> > Hi,
> >   Thanks for your reply.
> >   When the suspend and resume process , the operation of press ctrl + c 
> > will produce an interruput and cause to allocate memory failed. It causes 
> > the usb3 module can not be used and core dump after resume process.
> > Software call flow:
> > |xhci_resume
> > ||xhci_init
> > |||xhci_mem_init
> >  dma_alloc_coherent 
> > |dma_alloc_from_contiguous
> > In dma_alloc_from_contiguous return -4 (Interrupted system call).
> 
> The core dump says "PC is at xhci_mem_cleanup+0x4e4/0x574 [xhci_hcd] ".
> But this call flow shows error happens in dma allocation. Which is correct?
> Or, anything I misunderstood?

Why is that function failing?  That seems suspicious.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 答复: 【xhci】suspend and resume core dump problem

[gre...@linuxfoundation.org]

On Tue, Mar 22, 2016 at 03:17:08AM +, Lipengcheng wrote:
> Hi,
>   Thanks for your reply.
>   When the suspend and resume process , the operation of press ctrl + c will 
> produce an interruput and cause to allocate memory failed. It causes the usb3 
> module can not be used and core dump after resume process.

what are you pressing ctrl+c on?  Why would that do anything on a USB
keyboard to interrupt the host?

> Software call flow:
> |xhci_resume
> ||xhci_init
> |||xhci_mem_init
>  dma_alloc_coherent 
> |dma_alloc_from_contiguous
> In dma_alloc_from_contiguous return -4 (Interrupted system call).

Is this in some type of emulator?

> 
> Core dump information：
> 
> Vi Resume OK
> PM resume OK
> usb usb1: root hub lost power or was reset
> usb usb2: root hub lost power or was reset
> ^Cusb usb3: root hub lost power or was reset
> usb usb4: root hub lost power or was reset
> usb usb5: root hub lost power or was reset
> usb usb6: root hub lost power or was reset
> hiusb-xhci hiusb-xhci.0: Couldn't initialize memory
> Unable to handle kernel NULL pointer dereference at virtual address 
> pgd = a7324000
> [] *pgd=27265831, *pte=, *ppte=
> Internal error: Oops: 817 [#1] SMP ARM
> Modules linked in: tntfs(PO) xhci_hcd ohci_hcd ehci_hcd hi_pmoc(O) hi_vi(O) 
> hi_keyled(O) hi_aenc(O) hi_venc(O) hi_png(O) hi_jpge(O) hi_jpeg(O) hi_ir(O) 
> hi_fb(O) hi_pwm(O) hi_mce(O) hi_avplay(O) hi_pvr(O) hi_sync(O) hi_vou(O) 
> hi_aiao(O) hi_adsp(O) hi_hdmi(O) hi_cipher(O) hi_vdec(O) hi_vpss(O) hi_pq(O) 
> hi_pdm(O) hi_svdec(O) hi_vfmw(O) hi_adec(O) hi_demux(O) hi_otp(O) hi_tde(O) 
> mali(O) hi_i2c(O) hi_gpio_i2c(O) hi_gpio(O) hi_common(O) hi_mmz(O) hi_media(O)
> CPU: 0 PID: 1113 Comm: sample_pmoc Tainted: P   O 3.10.0_s40 #1

Can you remove all of your "custom" and closed source kernel drivers?

Also 3.10 is very old and obsolete, please work with the company that is
forcing you to use such a kernel version, as you are paying for support
from them.

Does this happen on 4.5?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 【xhci】suspend and resume core dump problem

[gre...@linuxfoundation.org]

On Tue, Mar 22, 2016 at 01:31:40AM +, Lipengcheng wrote:
>Hi, 
>   we have a problem like that we can start kernel successfully without 
> processing any other operations, but failed after pressing ctrl + c. After 
> our analsys, it is because of that, ctrl + c will produce an interruput,it 
> will be dealed with in xhci_resume->xhci_init->xhci_mem_init so that 
> dma_alloc_coherent fail, finally it will be calm down in the FUNCITON 
> LIST_DEL(>tt_list).
> As the modification , set flag to GFP_ATOMIC, disabling interrupt requests 
> will not be core dump, could you please tell me can I modify like this?
> 
> Thanks very much
> 
> Best Regards,
> 
> Pengcheng Li
> 
> 
> Modify 1:
>   xhci->dcbaa = dma_alloc_coherent(dev, sizeof(*xhci->dcbaa), ,
> - GFP_KERNEL);
> + GFP_ATOMIC);
> Modify 2:
>   xhci->erst.entries = dma_alloc_coherent(dev,
>   sizeof(struct xhci_erst_entry) * ERST_NUM_SEGS, ,
> - GFP_KERNEL);
> + GFP_ATOMIC);
> Modify 3:
> - retval = xhci_mem_init(xhci, GFP_KERNEL);
> + retval = xhci_mem_init(xhci, GFP_ATOMIC);
>   xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Finished xhci_init");

Why isn't the 'flags' variable being use here instead of hard-coding
GFP_KERNEL?  Hm, it looks like that variable doesn't really make much
sense as it's only ever called with GFP_KERNEL...

Anyway, this is during init, there should not be any locks happening, so
you can sleep, so using GFP_KERNEL is correct, I don't understand why
GFP_ATOMIC is needed here.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ehci and ohci reset number doubt

[gre...@linuxfoundation.org]

On Thu, Mar 17, 2016 at 02:16:56AM +, Lipengcheng wrote:
>  
> 
> Hi,



Please resend in non-html format so that the mailing list does not
reject your messages.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] usb: Use memdup_user to reuse the code

[gre...@linuxfoundation.org]

On Wed, Dec 09, 2015 at 08:02:53AM +, Pathak, Rahul (R.) wrote:
> Hello Alan,
> 
> Should I resend  this patch version  with the tear line correction?

Yes please.
--
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: Use memdup_user to reuse the code

[gre...@linuxfoundation.org]

On Wed, Dec 09, 2015 at 08:02:53AM +, Pathak, Rahul (R.) wrote:
> Hello Alan,
> 
> Should I resend  this patch version  with the tear line correction?

Why wouldn't you?
--
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][v2] drivers:usb:fsl: Replace macros with enumerated type

[gre...@linuxfoundation.org]

On Fri, Jun 26, 2015 at 05:12:04PM +, Badola Nikhil wrote:
  -Original Message-
  From: Nikhil Badola [mailto:nikhil.bad...@freescale.com]
  Sent: Monday, June 15, 2015 3:47 PM

snip

 Could you please provide comments for this patch and the subsequent
 patches in this patch set, if any.

It's the middle of the merge window right now, there's nothing I can do
with this until after it is over.  Please wait until then to expect a
response, and even then, give me a week or so to dig out from under the
pending-patch load.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New maintainer for dwc2

[gre...@linuxfoundation.org]

On Mon, Jan 12, 2015 at 11:14:54PM +, Paul Zimmerman wrote:
 Hi everyone,
 
 I will be leaving Synopsys on Friday, Jan 16th, so the dwc2 driver
 will need a new maintainer.
 
 I am recommending John Youn johny...@synopsys.com as the new
 maintainer.
 
 On the plus side, John has quite a bit of experience with the dwc2
 controller, and has previous experience submitting kernel patches (for
 the xhci and dwc3 drivers). And being a Synopsys employee, he will have
 access to internal resources for support.
 
 On the minus side, John has not worked directly with the in-kernel dwc2
 driver until very recently, and has not done maintainer work before.
 
 If no one has any objections, I will submit a patch to MAINTAINERS in a
 couple of days making John the new dwc2 maintainer.

I don't have any objections.  John will still be sending patches to
Felipe through email, and not directly to me, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: enable all functions remote wakeup for USB3 composite device

[gre...@linuxfoundation.org]

On Sun, Nov 30, 2014 at 03:51:37AM +, Li, Aixiong wrote:
 Hi all,
 
 The patch format still have some problem since I copied it from the html 
 mail. I fix it in this mail. :)

And it's still not in any format that I can apply it in.  Your company
has training on how to properly do this, please use that training to
learn how to do it so that you don't waste our time...

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB: enable all functions remote wakeup for USB3 composite device

[gre...@linuxfoundation.org]

On Sat, Nov 29, 2014 at 04:22:41PM +, Li, Aixiong wrote:
 Hi USB maintainers,

Your email is sent in html format and rejected by the mailing list,
please fix up and try again.
--
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 4/4] usb: xhci: rework root port wake bits if controller isn't allowed to wakeup

[gre...@linuxfoundation.org]

On Mon, Nov 17, 2014 at 02:57:05PM +, David Laight wrote:
 From: Felipe Balbi
  
  On Fri, Nov 14, 2014 at 07:23:52PM +0200, Mathias Nyman wrote:
   From: Lu Baolu baolu...@linux.intel.com
  
   When system is being suspended, if host device is not allowed to do 
   wakeup,
   xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
   platforms may generate spurious wakeup, even if PCI PME# is disabled.
  
   The initial commit ff8cbf250b44 (xhci: clear root port wake on bits),
   which also got into stable, turned out to not work correctly and had to
   be reverted, and is now rewritten.
  
   Cc: stable sta...@vger.kernel.org
  
  how far back ? Apparently, also, 2.6.37+
 
 Isn't xhci completely broken before some relatively recent kernel?

Really?  It actually seems to work _better_ for most people on older
kernels...

 ISTR a massive USB/xhci patch that a lot of things depend on.
 Is it worth backporting to kernels without that patch?

What exact patch are you referring to?

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIX ME in oxu210p-hcd.c

[gre...@linuxfoundation.org]

On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote:
 
 
 On 14-09-21 07:53 PM, Peter Chen wrote:
  
   
  Subject: Re: FIX ME in oxu210p-hcd.c
 
 
  I found a unfixed FIX ME in the file stated in my above message. I am
  wondering what to set hcd-self.comtroller-dma_mask to as it's now been
  defined to NULL and clearly even as a newbie this seem incorrect.
  Regards Nick
  
  Usually, it is set at its controller driver or pass through through device 
  tree or
  platform data.
  
  Peter
  
 Sorry Peter,
 I apologize for asking for more help here but I will paste the function below 
 and with my changes.
 Please let me known if I am wrong and how to fix it as I new here.
 Sorry for Wasting Your Time,

Then please do not.  Just because your other email addresses were banned
from lkml, don't keep popping up and bothering people, it's rude, and
will cause this address to be banned as well.

--
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: FIX ME in oxu210p-hcd.c

[gre...@linuxfoundation.org]

On Sun, Sep 21, 2014 at 10:17:38PM -0400, nick wrote:
 
 
 On 14-09-21 10:11 PM, gre...@linuxfoundation.org wrote:
  On Sun, Sep 21, 2014 at 10:03:28PM -0400, nick wrote:
 
 
  On 14-09-21 07:53 PM, Peter Chen wrote:
 
   
  Subject: Re: FIX ME in oxu210p-hcd.c
 
 
  I found a unfixed FIX ME in the file stated in my above message. I am
  wondering what to set hcd-self.comtroller-dma_mask to as it's now been
  defined to NULL and clearly even as a newbie this seem incorrect.
  Regards Nick
 
  Usually, it is set at its controller driver or pass through through 
  device tree or
  platform data.
 
  Peter
 
  Sorry Peter,
  I apologize for asking for more help here but I will paste the function 
  below and with my changes.
  Please let me known if I am wrong and how to fix it as I new here.
  Sorry for Wasting Your Time,
  
  Then please do not.  Just because your other email addresses were banned
  from lkml, don't keep popping up and bothering people, it's rude, and
  will cause this address to be banned as well.
  
 Sorry Greg,
 I don't want to get banned again. I was trying to help out and learn, I was 
 apologizing not
 for wasting time as much as for making sure I wasn't wasting maintainer time 
 again. I also 
 am coming to the conclusion that my terrible patches were a waste of time and 
 I am trying 
 to get back into helping out.

You were asked to finish the Eudyptula challenge before bothering any
other kernel developers with questions / patches.  Until that happens,
you are in my killfile, now with yet-another-email-address.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIX ME in oxu210p-hcd.c

[gre...@linuxfoundation.org]

Damm, didn't configure my kill-file correctly, and this snuck in, so
might as well respond...

On Sun, Sep 21, 2014 at 10:36:18PM -0400, nick wrote:
 On 14-09-21 10:24 PM, gre...@linuxfoundation.org wrote:
  Sorry Greg,
  I don't want to get banned again. I was trying to help out and learn, I 
  was apologizing not
  for wasting time as much as for making sure I wasn't wasting maintainer 
  time again. I also 
  am coming to the conclusion that my terrible patches were a waste of time 
  and I am trying 
  to get back into helping out.
  
  You were asked to finish the Eudyptula challenge before bothering any
  other kernel developers with questions / patches.  Until that happens,
  you are in my killfile, now with yet-another-email-address.
  
 Greg K-H,
 I really don't want you to get any more upset with me then you already are. 
 The reason I gave up on the
 challenge was it was mostly driver based and I wanted to learn more in other 
 areas. If you would like to
 discuss with me your concerns about my work on this list and how I can aid 
 more please let me known.

You stopped so early in the challenge, you really have no idea what it
is mostly about, so don't make rash statements like that.

Again, unless you finish it, you will be ignored by me, and probably by
everyone else as well.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Take dwc2 driver through Felipe's tree?

[gre...@linuxfoundation.org]

On Fri, Sep 19, 2014 at 08:52:07PM +, Paul Zimmerman wrote:
 Hi Greg,
 
 How would you feel about Felipe taking the dwc2 driver into his tree?
 There has been quite a bit of increased activity with dwc2 lately, and
 I know you already have more than enough stuff on your plate already.
 So this would mean one less thing for you to worry about. Plus it
 would mean an extra layer of review before getting to you.
 
 I've already talked to Felipe about it, and he's fine with it. If
 you're OK with it, I think I just need to send a patch adding a T:
 line to the MAINTAINERS entry, showing Felipe's tree?
 
 I guess we would want to do this just before you close your USB tree,
 and you could announce it then?

No objection from me.  I'm working in my patch backlog right now, should
get through them by the end of the day, so feel free to send me a
MAINTAINERS patch I can use.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] usb: dwc2: Revert patches causing problems

[gre...@linuxfoundation.org]

On Thu, Sep 11, 2014 at 07:11:20PM +, Paul Zimmerman wrote:
  From: Robert Baldyga [mailto:r.bald...@samsung.com]
  Sent: Thursday, September 11, 2014 5:53 AM
  
  These two patches breaks dwc2 driver. The first one causes build break,
  the second breaks gadget at Samsung platforms.
  
  Best regards
  Robert Baldyga
  
  Robert Baldyga (2):
Revert usb: dwc2: Update Kconfig to support dual-role
Revert usb: dwc2: move samsung,s3c6400-hsotg into common platform
  
   drivers/usb/dwc2/Kconfig| 63 
  +++--
   drivers/usb/dwc2/Makefile   | 21 +++
   drivers/usb/dwc2/gadget.c   |  1 +
   drivers/usb/dwc2/platform.c |  1 -
   4 files changed, 38 insertions(+), 48 deletions(-)
 
 Yep, I can confirm the build breakage. Greg, we should revert these two
 before you send your update for the next -rc, if it's not too late.
 
 Dinh, before resending the series, please test that each individual
 patch does not break the build.

I tested and didn't see the build breakage on my end, but I don't
test-build arm stuff...

Anyway, this is in the usb-next branch, not usb-linus, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

[gre...@linuxfoundation.org]

On Tue, Aug 19, 2014 at 06:33:04AM +, Sharma, Sanjeev wrote:
 Hi Greg,
 
 Any feedback on this patch ?

The merge window ended 2 days ago, _and_ I'm at the kernel summit this
week, _and_ my queue is currently sitting at:
$ mdfrm -c ~/mail/todo/
1317 messages in /home/gregkh/mail/todo/

So please be patient.  I'll get to it in a few weeks.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND v3 00/12] usb: dwc2/gadget: fix series

[gre...@linuxfoundation.org]

On Tue, Aug 19, 2014 at 03:46:58PM +, Paul Zimmerman wrote:
  From: Robert Baldyga [mailto:r.bald...@samsung.com]
  Sent: Tuesday, August 19, 2014 1:54 AM
  
  Hi Paul,
  
  I'm resending this patchset rebased on linux-next. Now it should apply.
  
  Thanks,
  Robert Baldyga
  
  Changelog:
  v3: https://lkml.org/lkml/2014/8/4/617
  - use endpoint index instead of FIFO index for EPFIFO
  - extend patch description
  
  v2: https://lkml.org/lkml/2014/7/16/199
  - add patch usb: dwc2/gadget: avoid disabling ep0
  - fix FIFO flushing when it's assigned to endpoint dynamically
  - write to proper FIFO in s3c_hsotg_write_fifo() function
  - use real FIFO size in kill_all_requests
  - fix comment in s3c_hsotg_init_fifo() function
  
  v1: https://lkml.org/lkml/2014/6/23/67
  
  Andrzej Pietrasiewicz (1):
usb: dwc2/gadget: Fix comment text
  
  Kamil Debski (3):
usb: dwc2/gadget: fix phy disable sequence
usb: dwc2/gadget: fix phy initialization sequence
usb: dwc2/gadget: move phy bus legth initialization
  
  Marek Szyprowski (5):
usb: dwc2/gadget: hide some not really needed debug messages
usb: dwc2/gadget: ensure that all fifos have correct memory buffers
usb: dwc2/gadget: break infinite loop in endpoint disable code
usb: dwc2/gadget: do not call disconnect method in pullup
usb: dwc2/gadget: delay enabling irq once hardware is configured
  properly
  
  Robert Baldyga (3):
usb: dwc2/gadget: assign TX FIFO dynamically
usb: dwc2/gadget: disable clock when it's not needed
usb: dwc2/gadget: avoid disabling ep0
  
   drivers/usb/dwc2/core.h   |   3 +
   drivers/usb/dwc2/gadget.c | 184 
  +++---
   2 files changed, 111 insertions(+), 76 deletions(-)
 
 Thanks Robert.
 
 For the entire series,
 Acked-by: Paul Zimmerman pa...@synopsys.com
 
 Greg, can you please apply this to your usb-next tree? Thanks.

For 3.17-final, or 3.18-rc1?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/12] usb: dwc2/gadget: fix series

[gre...@linuxfoundation.org]

On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote:
  From: Paul Zimmerman
  Sent: Friday, July 18, 2014 12:19 PM
  
   From: Robert Baldyga [mailto:r.bald...@samsung.com]
   Sent: Friday, July 18, 2014 4:39 AM
  
   This patchset contains fixes for dwc2 gadget driver. It touches PHY,
   FIFO configuration, initialization sequence and adds many other small 
   fixes.
  
   Best regards
   Robert Baldyga
   Samsung RD Institute Poland
  
   Changelog:
   v3:
- use endpoint index instead of FIFO index for EPFIFO
- extend patch description
  
   v2: https://lkml.org/lkml/2014/7/16/199
- add patch usb: dwc2/gadget: avoid disabling ep0
- fix FIFO flushing when it's assigned to endpoint dynamically
- write to proper FIFO in s3c_hsotg_write_fifo() function
- use real FIFO size in kill_all_requests
- fix comment in s3c_hsotg_init_fifo() function
  
   v1: https://lkml.org/lkml/2014/6/23/67
  
   Andrzej Pietrasiewicz (1):
 usb: dwc2/gadget: Fix comment text
  
   Kamil Debski (3):
 usb: dwc2/gadget: fix phy disable sequence
 usb: dwc2/gadget: fix phy initialization sequence
 usb: dwc2/gadget: move phy bus legth initialization
  
   Marek Szyprowski (5):
 usb: dwc2/gadget: hide some not really needed debug messages
 usb: dwc2/gadget: ensure that all fifos have correct memory buffers
 usb: dwc2/gadget: break infinite loop in endpoint disable code
 usb: dwc2/gadget: do not call disconnect method in pullup
 usb: dwc2/gadget: delay enabling irq once hardware is configured 
   properly
  
   Robert Baldyga (3):
 usb: dwc2/gadget: assign TX FIFO dynamically
 usb: dwc2/gadget: disable clock when it's not needed
 usb: dwc2/gadget: avoid disabling ep0
  
drivers/usb/dwc2/core.h   |   3 +
drivers/usb/dwc2/gadget.c | 184 
   +++---
2 files changed, 111 insertions(+), 76 deletions(-)
  
  For the entire series:
  
  Acked-by: Paul Zimmerman pa...@synopsys.com
 
 Hi Greg,
 
 I don't see this series from Robert in your tree yet. Is it still in
 your queue, or should Robert resend it?

I thought this was coming in from Felipe's tree, sorry.  It's too late
for 3.17-rc1, I just sent out those patches to Linus.

If someone wants me to take a patch series, please be explicit and say
something like Greg please take these in your tree, otherwise it is
very easy to get lost in my inbox...

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 00/12] usb: dwc2/gadget: fix series

[gre...@linuxfoundation.org]

On Mon, Aug 04, 2014 at 07:53:35PM +, Paul Zimmerman wrote:
  From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
  Sent: Monday, August 04, 2014 12:11 PM
  
  On Mon, Aug 04, 2014 at 06:58:23PM +, Paul Zimmerman wrote:
From: Paul Zimmerman
Sent: Friday, July 18, 2014 12:19 PM
   
 From: Robert Baldyga [mailto:r.bald...@samsung.com]
 Sent: Friday, July 18, 2014 4:39 AM

 This patchset contains fixes for dwc2 gadget driver. It touches PHY,
 FIFO configuration, initialization sequence and adds many other small 
 fixes.

 Best regards
 Robert Baldyga
 Samsung RD Institute Poland

 Changelog:
 v3:
  - use endpoint index instead of FIFO index for EPFIFO
  - extend patch description

 v2: https://lkml.org/lkml/2014/7/16/199
  - add patch usb: dwc2/gadget: avoid disabling ep0
  - fix FIFO flushing when it's assigned to endpoint dynamically
  - write to proper FIFO in s3c_hsotg_write_fifo() function
  - use real FIFO size in kill_all_requests
  - fix comment in s3c_hsotg_init_fifo() function

 v1: https://lkml.org/lkml/2014/6/23/67

 Andrzej Pietrasiewicz (1):
   usb: dwc2/gadget: Fix comment text

 Kamil Debski (3):
   usb: dwc2/gadget: fix phy disable sequence
   usb: dwc2/gadget: fix phy initialization sequence
   usb: dwc2/gadget: move phy bus legth initialization

 Marek Szyprowski (5):
   usb: dwc2/gadget: hide some not really needed debug messages
   usb: dwc2/gadget: ensure that all fifos have correct memory buffers
   usb: dwc2/gadget: break infinite loop in endpoint disable code
   usb: dwc2/gadget: do not call disconnect method in pullup
   usb: dwc2/gadget: delay enabling irq once hardware is configured 
 properly

 Robert Baldyga (3):
   usb: dwc2/gadget: assign TX FIFO dynamically
   usb: dwc2/gadget: disable clock when it's not needed
   usb: dwc2/gadget: avoid disabling ep0

  drivers/usb/dwc2/core.h   |   3 +
  drivers/usb/dwc2/gadget.c | 184 
 +++---
  2 files changed, 111 insertions(+), 76 deletions(-)
   
For the entire series:
   
Acked-by: Paul Zimmerman pa...@synopsys.com
  
   Hi Greg,
  
   I don't see this series from Robert in your tree yet. Is it still in
   your queue, or should Robert resend it?
  
  I thought this was coming in from Felipe's tree, sorry.  It's too late
  for 3.17-rc1, I just sent out those patches to Linus.
  
  If someone wants me to take a patch series, please be explicit and say
  something like Greg please take these in your tree, otherwise it is
  very easy to get lost in my inbox...
 
 Ah, OK. I guess that's my fault.
 
 Still, the mainline merge window is open for two weeks, right? Any reason
 why you can't still send this series to Linus? I'd hate to see Robert
 lose out due to my screwup.

Patches had to be in my tree for the week _before_ the merge window
opened, to get testing in linux-next.  It's been that way for years,
sorry.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch V3 0/2] usb: gadget: zero: Add support for interrupt EP

[gre...@linuxfoundation.org]

On Mon, Jun 09, 2014 at 10:44:38AM +0530, Amit Virdi wrote:
 Felipe, Alan,
 
 On 5/23/2014 12:01 PM, Amit VIRDI wrote:
 This patchset adds support for interrupt EP and the corresponding test cases 
 to
 gadget zero. The code has been rebased and tested on Kernel v3.15-rc5
 
 V2 - V3
   - Rectified wMaxPacketSize for FS from 1023 to 64
   - Modified default value of interrupt interval for FS to 1 ms
 
 V1 - V2
   - Modified the alternate interface from having 6 EPs (2 - Interrupt, 2 
  Bulk, 2
 Isoc) to 2 EPs (Interrupt only)
 
 RFC - V1
   - Added support for configuring interrupt EP attributes from configfs 
  interface
 
 Amit Virdi (2):
usb: gadget: zero: Add support for interrupt EP
usbtest: Add interrupt EP testcases
 
 
 Any comment on this patchset?

Felipe is out for a few weeks, so please be patient, he will return and
get to these.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/2] Re-organize usb common

[gre...@linuxfoundation.org]

On Fri, May 23, 2014 at 01:16:37AM +, Peter Chen wrote:
  
  
  Hi Greg,
  
  This patch set creates usb/common for usb common things, and moves otg
  fsm implementation from usb/phy/ to usb/common/. I have a discussion with
  Felipe about it at below link:
  http://www.spinics.net/lists/linux-usb/msg106357.html
  
  Thanks.
  
  Changes for v2:
  - Fix one typo Alan pointed.
  
  Peter Chen (2):
usb: move usb/usb-common.c to usb/common/usb-common.c
usb: common: rename phy-fsm-usb.c to usb-otg-fsm.c
  
   drivers/usb/Makefile   |2 +-
   drivers/usb/common/Makefile|6 ++
   drivers/usb/{ = common}/usb-common.c  |0
   .../{phy/phy-fsm-usb.c = common/usb-otg-fsm.c}|0
   drivers/usb/core/Kconfig   |9 +
   drivers/usb/phy/Kconfig|9 -
   drivers/usb/phy/Makefile   |1 -
   7 files changed, 16 insertions(+), 11 deletions(-)  create mode 100644
  drivers/usb/common/Makefile  rename drivers/usb/{ = common}/usb-common.c
  (100%)  rename drivers/usb/{phy/phy-fsm-usb.c = common/usb-otg-fsm.c}
  (100%)
  
 
 Hi Greg, does this patch set will in your 3.16 tree? There are coming
 works are related to it, thanks.

It's behind in my patch review queue due to my travels.  I'll be back
next week and will get to this, sorry for the delay.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 0/3] usb: dwc2/s3c-hsotg: move s3c-hsotg driver into dwc2

[gre...@linuxfoundation.org]

On Thu, Apr 17, 2014 at 08:38:11PM +, Paul Zimmerman wrote:
  From: Paul Zimmerman
  Sent: Monday, April 14, 2014 2:14 PM
  
  From: Dinh Nguyen dingu...@altera.com
  
  This is a shortened version of the patch to combine the dwc2/s3c-hsotg into 
  a
  single dual-role driver. The series will only move the s3c-hsotg driver into
  the dwc2 folder, use the defines in the dwc2 hw.h, and removes the 
  s3c-hsotg.h
  defines. This will make the dual-role combining work a bit easier to review 
  in
  the future.
  
  For now, the dwc2 and s3c-hsotg will be separate drivers.
  ---
  Hi Greg,
  
  This is Dinh's series for moving the s3c-hsotg driver into the dwc2 
  directory.
  The gadget part has been tested by Jingoo and Robert at Samsung, and I have
  tested the host part on the Synopsys development board (but not on the
  Raspberry Pi). I would like to have Stephen Warren test this on the Pi, and
  have Felipe ack the first two patches, then I think it should be good to go.
 
 Hi Greg,
 
 I haven't heard back from Stephen about testing on the Raspberry Pi.
 So today I managed to fix my broken Pi and do some quick testing on it,
 and I didn't see any problems. And, Felipe gave his (qualified) Ack. So,
 can you please go ahead and merge these patches to usb-next? Thanks.

Ok, I'll queue them up when I get to the usb patches for 3.16 (still
sifting through for 3.15 patches at the moment...)  This should happen
later next week, thanks.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: move ZTE CDMA device pid from zte_ev.c back to option.c

[gre...@linuxfoundation.org]

On Tue, Apr 08, 2014 at 07:59:28PM +0800, 刘磊 wrote:
 dear linuxfoundation:
     I'm not sure if you receive our mails in lase week , i resend it now.  
 Please confirm whether it is correct format for submit.
 Looking forward to your reply.
     
 modify reason:
 1. Move device pid fffe from zte_ev.c back to option.c for our company.
 2. Modify the parameter from 0x0003 to 0x. the problem may cause the 
 device can not be close. 
 these two points are in the patch, please submit it for me. thanks.
 
 
 
 
 Signed-off-by:lei liuliu.le...@zte.com.cn
 diff -u -r drivers-old/usb/serial/option.c drivers/usb/serial/option.c
 --- drivers-old/usb/serial/option.c   2014-03-24 12:45:42.0 +0800
 +++ drivers/usb/serial/option.c   2014-03-26 15:13:02.232956251 +0800
 @@ -1462,6 +1462,7 @@
   { 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) },
 + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffe, 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),
 
 
 
 
 diff -u -r drivers-old/usb/serial/zte_ev.c drivers/usb/serial/zte_ev.c
 --- drivers-old/usb/serial/zte_ev.c   2014-03-24 12:45:42.0 +0800
 +++ drivers/usb/serial/zte_ev.c   2014-03-26 16:08:52.916827643 +0800
 @@ -258,12 +258,12 @@
  
   /* send 8 cmd */
   /*
 -  * 16.0 CTL    21 22 03 00  00 00 00 00
 +  * 16.0 CTL    21 22 00 00  00 00 00 00
    */
   len = 0;
   result = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
    0x22, 0x21,
 -  0x0003, 0x, NULL, len,
 +  0x, 0x, NULL, len,
    USB_CTRL_GET_TIMEOUT);
   dev_dbg(dev, result = %d\n, result);
  
 @@ -276,7 +276,6 @@
   /* AC8710, AC8710T */
   { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0x, 0xff, 0xff, 0xff) },
    /* AC8700 */
 - { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xfffe, 0xff, 0xff, 0xff) },
   /* MG880 */
   { USB_DEVICE(0x19d2, 0xfffd) },
   { USB_DEVICE(0x19d2, 0xfffc) },
 
 
 
 thanks.
 lei liu


This patch doesn't apply to the tree at all, sorry.  Please read
Documentation/SubmittingPatches for how to do this, and make it against
the 3.15-rc1 kernel release and resend.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About a USB patch on linux kernal

[gre...@linuxfoundation.org]

On Fri, Apr 11, 2014 at 02:41:02AM +, Yanan, SUO(MBB-SZ-TCT) wrote:
 Hi :  
 
   We have check the linux kernel patch list ,but We can’t find ours 
 USB-PIDVID
 patch .

What specific patch is this?  And what patch list did you check?  We
deal with many thousands of patches every month, you are going to have
to be a bit more specific, sorry.

What driver was it for?  What device id did it modify?

   The patch should have appeared in the list ,So could you give us some
 suggestion for this issue?
 
 ( this patch have pushed in the main branch in 12(m)-2013(y) ).

In what release are you referring to?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: move ZTE CDMA device pid from zte_ev.c back to option.c

[gre...@linuxfoundation.org]

On Tue, Apr 08, 2014 at 07:59:28PM +0800, 刘磊 wrote:
 dear linuxfoundation:
     I'm not sure if you receive our mails in lase week , i resend it now.  
 Please confirm whether it is correct format for submit.
 Looking forward to your reply.
     
 modify reason:
 1. Move device pid fffe from zte_ev.c back to option.c for our company.
 2. Modify the parameter from 0x0003 to 0x. the problem may cause the 
 device can not be close. 
 these two points are in the patch, please submit it for me. thanks.
 
 
 
 
 Signed-off-by:lei liuliu.le...@zte.com.cn


Hi,

This is the friendly semi-automated patch-bot of Greg Kroah-Hartman.
You have sent him a patch that has triggered this response.

Right now, the development tree you have sent a patch for is closed
due to the timing of the merge window.  Don't worry, the patch(es) you
have sent are not lost, and will be looked at after the merge window is
over (after the -rc1 kernel is released by Linus).

So thank you for your patience and your patches will be reviewed at this
later time, you do not have to do anything further, this is just a short
note to let you know the patch status and so you don't worry they didn't
make it through.

thanks,

greg k-h's patch email bot
--
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: move ZTE CDMA device pid from zte_ev.c back to option.c

[gre...@linuxfoundation.org]

On Thu, Mar 27, 2014 at 02:40:23PM +0800, 刘磊 wrote:
 dear linuxfoundation:

Linux Foundation is a non-profit group, not a person :)

And please don't send HTML email, the mailing list rejects it.

 Because of the time difference, can not respond promptly.

That's not an issue, don't worry about it.


 May be mail service lead to patch is badly in last mail, now i use other
 mailbox. 
 Two method provide the patch, the html format in mail and take the patch
 file as attachment. 
 
 Signed-off-by:lei liuliu.le...@163.com

This is still corrupted, can you please resend, with the proper
information in the changelog area (as described in the
Documentation/SubmittingPatches file) so that we can apply it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in platform device id

[gre...@linuxfoundation.org]

On Thu, Mar 20, 2014 at 03:01:56PM +, suresh.gu...@freescale.com wrote:
  @@ -2654,6 +2654,8 @@ static const struct platform_device_id
fsl_udc_devtype[] = {
  }, {
  .name = imx-udc-mx51,
  }, {
  +   .name = fsl-usb2-udc,

 why aren't you just using chipidea ?
 [SuresH] This is our legacy driver for all previous and existing
 ppc socs. Many of our customers are already using this, and we
 need to support them on this driver. We do have plans to shift to
 chipidea, but after some time.
   
cool, you already have plans, so we will see a new glue layer for
v3.16 right ? Which means I don't need to take this patch either.
   
   we do have plans, but in remote future. Right now, we need to support
   customers on the present legacy driver. We'll phase out this driver
   slowly when we integrate chipidea. At this time I would request you to
   please accept this patch
  
  Even if Felipe takes the patch, I'll reject it as you should be doing the
  correct thing here, and if it's accepted, it will never be changed...
 
 Hi Greg, I agree that moving to the chipidea driver is the right thing to do.
 However, does this mean that companies have to phase out their current legacy 
 drivers as soon as a new controller specific driver is introduced in kernel ??

If their drivers aren't merged upstream, then yes they do, we can't have
duplicate drivers controlling the same hardware blobs.

 Can't they decide their own schedule based on their own requirements. Our 
 only 
 concern is to keep supporting our customers till we move to the new driver. 

Your support issues / requirements is not any of our business, we just
can't accept duplicate code, which I'm sure you can understand.

 I would really appreciate if you could accept this as this would give us 
 some time to move to chipidea driver.

What is preventing you from doing this within a week or so?  Is it
really that hard of a transistion?  If so, is this a problem with the
chipidea driver or something else?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in platform device id

[gre...@linuxfoundation.org]

On Wed, Mar 19, 2014 at 02:25:25PM +, suresh.gu...@freescale.com wrote:
 Hi
 
  -Original Message-
  From: Felipe Balbi [mailto:ba...@ti.com]
  Sent: Saturday, March 15, 2014 7:10 AM
  To: Gupta Suresh-B42813
  Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-usb@vger.kernel.org;
  linux-ker...@vger.kernel.org
  Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
  platform device id
  
  On Fri, Mar 14, 2014 at 08:52:19PM +, suresh.gu...@freescale.com
  wrote:
   Hi,
   Thanks for reviewing my patches.
   Please find my comments inline
  
   -Original Message-
   From: Felipe Balbi [mailto:ba...@ti.com]
   Sent: Thursday, March 13, 2014 8:56 PM
   To: Gupta Suresh-B42813
   Cc: ba...@ti.com; gre...@linuxfoundation.org;
   linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Gupta
   Suresh-B42813
   Subject: Re: [PATCH] usb: gadget: fsl: Add FSL USB Gadget entry in
   platform device id
  
   On Thu, Mar 13, 2014 at 07:35:31PM +0530, Suresh Gupta wrote:
From: Suresh Gupta b42...@freescale.com
   
Add FSL USB Gadget entry in platform device id table
  
   why this tab ?
   [SuresH] I will remove it in next version.
  
Signed-off-by: Suresh Gupta b42...@freescale.com
---
 drivers/usb/gadget/fsl_udc_core.c | 2 ++
 1 file changed, 2 insertions(+)
   
diff --git a/drivers/usb/gadget/fsl_udc_core.c
b/drivers/usb/gadget/fsl_udc_core.c
index b7dea4e..35b20e6 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2654,6 +2654,8 @@ static const struct platform_device_id
  fsl_udc_devtype[] = {
}, {
.name = imx-udc-mx51,
}, {
+   .name = fsl-usb2-udc,
  
   why aren't you just using chipidea ?
   [SuresH] This is our legacy driver for all previous and existing ppc
   socs. Many of our customers are already using this, and we need to
   support them on this driver. We do have plans to shift to chipidea,
   but after some time.
  
  cool, you already have plans, so we will see a new glue layer for v3.16
  right ? Which means I don't need to take this patch either.
  
 we do have plans, but in remote future. Right now, we need to support
 customers on the present legacy driver. We'll phase out this driver 
 slowly when we integrate chipidea. At this time I would request you 
 to please accept this patch

Even if Felipe takes the patch, I'll reject it as you should be doing
the correct thing here, and if it's accepted, it will never be
changed...

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] PHY for 3.15

[gre...@linuxfoundation.org]

On Sun, Mar 09, 2014 at 11:15:46PM +0530, Kishon Vijay Abraham I wrote:
 Hi Greg,
 
 Pls find the updated PULL request.
 
 It contains new PHY drivers (SATA, USB) adapted to generic PHY framework 
 for a couple of platforms and a bunch of cleanups and fixes. The 
 Documentation problem with the old PULL request has been fixed in this.
 
 Pls let me know If I have to make any other changes.
 
 Thanks
 Kishon
 
 The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691:
 
Linux 3.14-rc4 (2014-02-23 17:40:03 -0800)
 
 are available in the git repository at:
 
git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
 tags/for_3.15
 
 for you to fetch changes up to 88e670fe9d240c751fd9735ae3ee2906ed68e63d:
 
PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver (2014-03-09 
 12:45:13 +0530)
 

line-wrap :(

Anyway, 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

Re: [PATCH 2/7] usb: chipidea: add freescale imx28 special write register method

[gre...@linuxfoundation.org]

On Fri, Jan 10, 2014 at 10:25:54AM +, David Laight wrote:
 From: Peter Chen
 ...
  +#ifdef 
  +static inline void imx28_ci_writel(u32 val, volatile void __iomem *addr)
  +{
  +   __asm__ (swp %0, %0, [%1] : : r(val), r(addr));
  +}
  +#else
  +static inline void imx28_ci_writel(u32 val, volatile void __iomem *addr)
  +{
  +}
  +#endif
  +
  +static inline void __hw_write(struct ci_hdrc *ci, u32 val,
  +   void __iomem *addr)
  +{
  +   if (ci-imx28_write_fix)
  +   imx28_ci_writel(val, addr);
  +   else
  +   iowrite32(val, addr);
  +}
  +
 
 This code ought to be defensive against 'imx28_write_fix' being
 set when the kernel isn't compiled with CONFIG_SOC_IMX28.
 This can easily be done by changing the #else block to do an iowrite().

You missed the long email thread we just had about this earlier in the
week...

 It is worth looking to see if the compiler manages to optimise away
 the 'if' test in this case. It might do better if a #define is used
 instead of the inline function.

It shouldn't make a difference, gcc should optimize it away.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/7] usb: chipidea: add freescale imx28 special write register method

['gre...@linuxfoundation.org']

On Fri, Jan 10, 2014 at 03:09:03PM +, David Laight wrote:
   This code ought to be defensive against 'imx28_write_fix' being
   set when the kernel isn't compiled with CONFIG_SOC_IMX28.
   This can easily be done by changing the #else block to do an iowrite().
  
  You missed the long email thread we just had about this earlier in the
  week...
 
 No - I read most of it, I even commented earlier than the alternate
 definition of imx28_ci_writel() should be iowrite32().

That would work too.

 Getting static branch prediction right can make a significant difference.
 Although each branch is only a few clocks they can soon add up.
 Protocol stack code can easily be dominated by conditionals,
 removing pipeline stalls can easily speed things up by a measurable 10%.

If you can measure a problem with the code as-is, great, I'll be glad to
take a patch, otherwise we are just bike-shedding, and I'm sure the gcc
developers would love a bug report as to how they aren't getting the
static inline empty function logic correct :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/3] usb: ehci: add freescale imx28 special write register method

[gre...@linuxfoundation.org]

On Wed, Dec 04, 2013 at 07:10:42AM +, Peter Chen wrote:
 
  
  
  On Tue, Nov 26, 2013 at 08:11:26PM +0800, Peter Chen wrote:
   According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
   register error issue, All USB register write operations must
   use the ARM SWP instruction. So, we implement a special ehci_write
   for imx28.
  
   Discussion for it at below:
   http://marc.info/?l=linux-usbm=137996395529294w=2
  
   Signed-off-by: Peter Chen peter.c...@freescale.com
   Acked-by: Alan Stern st...@rowland.harvard.edu
   Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
   ---
drivers/usb/host/ehci.h |   18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
  
  
  Hi Greg, will you apply this patch to your 3.13-rcX?
  I will take the other two at this patchset.
  
 
 Hi Greg, if possible, I can apply this patch.
 The compile error will occur if I only apply the [2/3] and [3/3]. 

Ok, that's fine with me, please do so.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] A patch fro support alcatel's new products

[gre...@linuxfoundation.org]

On Wed, Nov 27, 2013 at 05:54:03AM +, Yanan, SUO(MBB-SZ-TCT) wrote:
 Hi :
 
   We want make our new product work well on Linux(fedora, Debian, Ubuntu) 
 Android, and have make patch tested ,It,s perfect.

It is?  :)

Unfortunatly you sent this email in html form, with a base64 attachment,
which means I can't really apply it, and you typed the mailing list
address incorrectly (hand fixed...)

Can you please read the kernel file, Documentation/email_clients.txt and
fix your email client to be able to send the patch properly?

Also, the whitespace in your patch is really odd, why didn't you use
tabs for the device ids?  And you added some new lines for no reason.

Also, do you really need the blasklist bits?  Why?

Can you please clean up the formatting of the patch and resend it not in
html format, so that the mailing list can get it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] usb: chipidea: imx: avoid unnecessary probe defer every time

[gre...@linuxfoundation.org]

On Fri, Nov 22, 2013 at 04:34:14PM +0100, Marek Vasut wrote:
 Hi Peter,
 
 endif
 
 ifneq ($(CONFIG_OF),)

-   obj-$(CONFIG_USB_CHIPIDEA)  += ci_hdrc_imx.o usbmisc_imx.o
+   obj-$(CONFIG_USB_CHIPIDEA)  += usbmisc_imx.o ci_hdrc_imx.o

 endif
   
   How is this supposed to work please? Can you explain me the trick here
   please?
  
  The probe will be executed according to compile order which is decided by
  Makefile, you can try if it can fix your problem you reported several days
  before.
 
 Why does the compile order here matter please? What if I use 'make -j N', 
 which 
 will cause the files to be compiled in parallel?

Yes, but not linked in parallel.  Link order matters, not building
object order.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] usb: chipidea: add freescale imx28 special write register method

[gre...@linuxfoundation.org]

On Mon, Oct 28, 2013 at 11:47:53AM +0100, Marek Vasut wrote:
 Dear Hector Palacios,
 
  Dear Peter,
  
  On 10/25/2013 08:02 AM, Peter Chen wrote:
   According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
   register error issue, All USB register write operations must
   use the ARM SWP instruction. So, we implement special hw_write
   and hw_test_and_clear for imx28.
   
   Discussion for it at below:
   http://marc.info/?l=linux-usbm=137996395529294w=2
   
   Signed-off-by: Peter Chen
   peter.chen-kzfg59tc24xl57midrc...@public.gmane.org ---
   Changes for v2:
   - Rebase to latest usb-next tree
   
 drivers/usb/chipidea/ci.h|   23 +++
 drivers/usb/chipidea/core.c  |2 ++
 drivers/usb/chipidea/host.c  |1 +
 include/linux/usb/chipidea.h |1 +
 4 files changed, 27 insertions(+), 0 deletions(-)
   
   diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
   index 1c94fc5..4eb61d0 100644
   --- a/drivers/usb/chipidea/ci.h
   +++ b/drivers/usb/chipidea/ci.h
   @@ -173,6 +173,8 @@ struct ci_hdrc {
   
 struct dentry   *debugfs;
 boolid_event;
 boolb_sess_valid_event;
   
   + /* imx28 needs swp instruction for writing */
   + boolimx28_write_fix;
   
 };
 
 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
   
   @@ -253,6 +255,13 @@ static inline u32 hw_read(struct ci_hdrc *ci, enum
   ci_hw_regs reg, u32 mask)
   
 return ioread32(ci-hw_bank.regmap[reg])  mask;
 
 }
   
   +#ifdef CONFIG_SOC_IMX28
   +static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
   +{
   + __asm__ (swp %0, %0, [%1] : : r(val32), r(addr));
   +}
   +#endif
   +
   
 /**
 
  * hw_write: writes to a hw register
  * @reg:  register index
   
   @@ -266,7 +275,14 @@ static inline void hw_write(struct ci_hdrc *ci, enum
   ci_hw_regs reg,
   
 data = (ioread32(ci-hw_bank.regmap[reg])  ~mask)
 
 | (data  mask);
   
   +#ifdef CONFIG_SOC_IMX28
   + if (ci-imx28_write_fix)
   + imx28_ci_writel(data, ci-hw_bank.regmap[reg]);
   + else
   + iowrite32(data, ci-hw_bank.regmap[reg]);
   +#else
   
 iowrite32(data, ci-hw_bank.regmap[reg]);
   
   +#endif
   
 }
 
 /**
   
   @@ -281,7 +297,14 @@ static inline u32 hw_test_and_clear(struct ci_hdrc
   *ci, enum ci_hw_regs reg,
   
 {
 
 u32 val = ioread32(ci-hw_bank.regmap[reg])  mask;
   
   +#ifdef CONFIG_SOC_IMX28
   + if (ci-imx28_write_fix)
   + imx28_ci_writel(val, ci-hw_bank.regmap[reg]);
   + else
   + iowrite32(val, ci-hw_bank.regmap[reg]);
   +#else
   
 iowrite32(val, ci-hw_bank.regmap[reg]);
   
   +#endif
   
 return val;
 
 }
  
  Can't we remove the #ifdefs CONFIG_SOC_IMX28 all around?
  The check is done on the new flag ci-imx28_write_fix which exists for all
  platforms, isn't it?.
 
 The SWP instruction is specific to ARM, so you'd need to stub-out the 
 imx28_ci_writel() with ifdef then.

That's better than the mess of #ifdefs this patch adds, which isn't ok
at all :(

--
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 2/5] usb: chipidea: add freescale imx28 special write register method

[gre...@linuxfoundation.org]

On Wed, Oct 30, 2013 at 08:53:42AM +0800, Peter Chen wrote:
 On Tue, Oct 29, 2013 at 04:54:47PM -0700, gre...@linuxfoundation.org wrote:
  On Mon, Oct 28, 2013 at 11:47:53AM +0100, Marek Vasut wrote:
   Dear Hector Palacios,
   
Dear Peter,

On 10/25/2013 08:02 AM, Peter Chen wrote:
 According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB
 register error issue, All USB register write operations must
 use the ARM SWP instruction. So, we implement special hw_write
 and hw_test_and_clear for imx28.
 
 Discussion for it at below:
 http://marc.info/?l=linux-usbm=137996395529294w=2
 
 Signed-off-by: Peter Chen
 peter.chen-kzfg59tc24xl57midrc...@public.gmane.org ---
 Changes for v2:
 - Rebase to latest usb-next tree
 
   drivers/usb/chipidea/ci.h|   23 +++
   drivers/usb/chipidea/core.c  |2 ++
   drivers/usb/chipidea/host.c  |1 +
   include/linux/usb/chipidea.h |1 +
   4 files changed, 27 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
 index 1c94fc5..4eb61d0 100644
 --- a/drivers/usb/chipidea/ci.h
 +++ b/drivers/usb/chipidea/ci.h
 @@ -173,6 +173,8 @@ struct ci_hdrc {
 
   struct dentry   *debugfs;
   boolid_event;
   boolb_sess_valid_event;
 
 + /* imx28 needs swp instruction for writing */
 + boolimx28_write_fix;
 
   };
   
   static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
 
 @@ -253,6 +255,13 @@ static inline u32 hw_read(struct ci_hdrc *ci, 
 enum
 ci_hw_regs reg, u32 mask)
 
   return ioread32(ci-hw_bank.regmap[reg])  mask;
   
   }
 
 +#ifdef CONFIG_SOC_IMX28
 +static inline void imx28_ci_writel(u32 val32, volatile u32 *addr)
 +{
 + __asm__ (swp %0, %0, [%1] : : r(val32), r(addr));
 +}
 +#endif
 +
 
   /**
   
* hw_write: writes to a hw register
* @reg:  register index
 
 @@ -266,7 +275,14 @@ static inline void hw_write(struct ci_hdrc *ci, 
 enum
 ci_hw_regs reg,
 
   data = (ioread32(ci-hw_bank.regmap[reg])  ~mask)
   
   | (data  mask);
 
 +#ifdef CONFIG_SOC_IMX28
 + if (ci-imx28_write_fix)
 + imx28_ci_writel(data, ci-hw_bank.regmap[reg]);
 + else
 + iowrite32(data, ci-hw_bank.regmap[reg]);
 +#else
 
   iowrite32(data, ci-hw_bank.regmap[reg]);
 
 +#endif
 
   }
   
   /**
 
 @@ -281,7 +297,14 @@ static inline u32 hw_test_and_clear(struct 
 ci_hdrc
 *ci, enum ci_hw_regs reg,
 
   {
   
   u32 val = ioread32(ci-hw_bank.regmap[reg])  mask;
 
 +#ifdef CONFIG_SOC_IMX28
 + if (ci-imx28_write_fix)
 + imx28_ci_writel(val, ci-hw_bank.regmap[reg]);
 + else
 + iowrite32(val, ci-hw_bank.regmap[reg]);
 +#else
 
   iowrite32(val, ci-hw_bank.regmap[reg]);
 
 +#endif
 
   return val;
   
   }

Can't we remove the #ifdefs CONFIG_SOC_IMX28 all around?
The check is done on the new flag ci-imx28_write_fix which exists for 
all
platforms, isn't it?.
   
   The SWP instruction is specific to ARM, so you'd need to stub-out the 
   imx28_ci_writel() with ifdef then.
  
  That's better than the mess of #ifdefs this patch adds, which isn't ok
  at all :(
  
 
 You mean try to reduce the number of #ifdef?

Of course you should.
--
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] support new huawei devices in option.c

[gre...@linuxfoundation.org]

On Fri, Oct 11, 2013 at 03:48:21AM +, Fangxiaozhi (Franko) wrote:
 1. Add new supporting declarations to option.c, to support Huawei new devices 
 with new bInterfaceSubClass value.
 Signed-off-by: fangxiaozhi huana...@huawei.com

In the future, can you use an email client that doesn't turn tabs into
spaces, so I don't have to edit the patch by hand?

Also:

 + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x01) },
 + { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x02) },

snip

That's a huge list of ids, is there any way we can just mark all of
these as used by the device in an easier manner?

I'll take this for now, but I have a feeling that this list is just
going to get worse over time, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: About TRB_TO_EP_INDEX() macro using

['gre...@linuxfoundation.org']

On Tue, Aug 06, 2013 at 08:59:32AM +, Du, ChangbinX wrote:
  On Mon, Aug 05, 2013 at 08:07:25AM +, Du, ChangbinX wrote:
   Recently when I check xHCI code, find that some functions try to get EP 
   index
   from a Command Completion Event TRB via TRB_TO_EP_INDEX() macro.
  
   This is totally wrong. The macro definition is:
  
 #define TRB_TO_EP_INDEX(p)  p)  (0x1f  16))  16) - 
   1)
  
   TRB_TO_EP_INDEX only applies to Transfer Event TRB. But for Command
   Completion Event TRB, there is no Endpoint ID field. So, we cannot 
   directly
   get EP index from these TRBs, but we can find it by the TRB Pointer.
  
   Here list two functions for you to check:
 handle_stopped_endpoint()
 handle_reset_ep_completion()
  
  Care to send a patch showing how you would change this if it is
  incorrect?
  
  thanks,
  
  greg k-h
  --
 
 Hello, Greg k-h. I am not very sure about this issue. If this is true, kernel 
 will panic when 
 invoking above functions. I want someone help to confirm if I miss something. 
 If it's really 
 a bug, I will work out a patch to fix it.

That's not how kernel development works, sorry.  If you think this is an
issue, try to reproduce it and then create a patch.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: dwc2: add microframe scheduler from downstream Pi kernel

[gre...@linuxfoundation.org]

On Thu, Jul 18, 2013 at 04:45:55PM +, Paul Zimmerman wrote:
  From: linux-usb-ow...@vger.kernel.org 
  [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Gordon Hollingworth
  Sent: Wednesday, July 17, 2013 11:00 PM
  
  I'd suggest just adding a Raspberry Pi Foundation copyright.
  
  Is that OK or do you need names for SOB?
 
 Ah yes, thanks for reminding me. Yes, I will need SOBs from the main
 contributors. And they must be real names, popcornmix is not
 acceptable as far as I understand. Thanks.

Yes, I need real names, no pseudonyms.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] staging: dwc2: add microframe scheduler from downstream Pi kernel

[gre...@linuxfoundation.org]

On Thu, Jul 18, 2013 at 11:34:47AM -0600, Stephen Warren wrote:
 On 07/18/2013 10:45 AM, Paul Zimmerman wrote:
  From: linux-usb-ow...@vger.kernel.org 
  [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Gordon Hollingworth
  Sent: Wednesday, July 17, 2013 11:00 PM
 
  I'd suggest just adding a Raspberry Pi Foundation copyright.
 
  Is that OK or do you need names for SOB?
  
  Ah yes, thanks for reminding me. Yes, I will need SOBs from the main
  contributors. And they must be real names, popcornmix is not
  acceptable as far as I understand. Thanks.
 
 BTW, Dom has previously given permission to me (I think in an email
 posted to a public list) to modify any S-o-b lines that say popcornmix
 as the real name to say Dom Cobley instead. Of course, this is only
 relevant if the commit in question is already s-o-b popcornmix. And I am
 assuming that popcornmix is always Dom.
 
 (Greg, I assume this kind of agreement is fine, and it's not the case
 that Dom would need to amend all his commits himself to change the s-o-b?)

Yes, I have seen Dom's email that said that, so it's fine for you to
edit the patches to do so, I just can't apply patches with popcornmix
in the changelogs.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH -next] usb: fusbh200-hcd: fix error handling in fusbh200_hcd_fusbh200_probe()

[gre...@linuxfoundation.org]

On Fri, May 31, 2013 at 02:35:41AM +, Wendy Yuan-Hsin Chen(陳元馨) wrote:
 
 -Original Message-
 From: Wei Yongjun [mailto:weiyj...@gmail.com] 
 Sent: Tuesday, May 21, 2013 10:41 AM
 To: gre...@linuxfoundation.org; Wendy Yuan-Hsin Chen(陳元馨)
 Cc: yongjun_...@trendmicro.com.cn; linux-usb@vger.kernel.org
 Subject: [PATCH -next] usb: fusbh200-hcd: fix error handling in 
 fusbh200_hcd_fusbh200_probe()

Why the forward of a previous patch?  I don't see this original one in
my mailboxes anywhere, what happened to it?

 
 From: Wei Yongjun yongjun_...@trendmicro.com.cn
 
 Fix to release all resources when fusbh200_setup() fail instead of only 
 return error.
 
 Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
 
 Acked-by: Yuan-Hsin Chen yhc...@faraday-tech.com
 
 ---
  drivers/usb/host/fusbh200-hcd.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/usb/host/fusbh200-hcd.c 
 b/drivers/usb/host/fusbh200-hcd.c index 79ce799..7f3293b 100644
 --- a/drivers/usb/host/fusbh200-hcd.c
 +++ b/drivers/usb/host/fusbh200-hcd.c
 @@ -5864,7 +5864,7 @@ static int fusbh200_hcd_fusbh200_probe(struct 
 platform_device *pdev)
  
   retval = fusbh200_setup(hcd);
   if (retval)
 - return retval;
 + goto fail_add_hcd;
  
   fusbh200_init(fusbh200);
  
 
 
 * Confidentiality Notice 
 This electronic message and any attachments may contain
 confidential and legally privileged information or
 information which is otherwise protected from disclosure.
 If you are not the intended recipient,please do not disclose
 the contents, either in whole or in part, to anyone,and
 immediately delete the message and any attachments from
 your computer system and destroy all hard copies.
 Thank you for your cooperation.
 ***

This footer prevents me from being able to apply your patch, please
remove it and resend it.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DWC2 driver to staging tree?

[gre...@linuxfoundation.org]

On Fri, Mar 08, 2013 at 09:18:51PM +, Paul Zimmerman wrote:
 Hi Greg,
 
 It looks like the DWC2 driver is not going to be ready for mainline any
 time soon, so would it be acceptable to add it to the staging tree as-is?
 I really need to show some progress being made here, or  my
 management will ask me to stop work on it altogether. If it's in staging,
 I can at least continue to spend some time on it.

That's fine with me.

 If this is acceptable, where in the staging tree would you suggest to put it?

drivers/staging/dwc2  ?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: host: tegra: Reset Tegra USB controller before init

[gre...@linuxfoundation.org]

On Mon, Mar 04, 2013 at 09:55:44AM -0700, Stephen Warren wrote:
 On 03/04/2013 12:55 AM, Venu Byravarasu wrote:
  Stephen Warren wrote at Thursday, February 28, 2013 11:47 PM:
  On 02/27/2013 11:36 PM, Venu Byravarasu wrote:
  To clear any configurations made by U-Boot on Tegra USB controller,
  reset it before init in probe.
 
  diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
 
  @@ -691,6 +692,10 @@ static int tegra_ehci_probe(struct platform_device
  *pdev)
if (err)
goto fail_clk;
 
  + tegra_periph_reset_assert(tegra-clk);
  + udelay(1);
  + tegra_periph_reset_deassert(tegra-clk);
 
  I think this patch might cause unintended consequences.
 
  When the Tegra PHY code is converted to a driver (i.e. has its own
  probe), the initial order of execution of the PHY and EHCI driver probes
  will not be guaranteed.
 
  In particular, since the EHCI probe will attempt to find the PHY
  device, and defer the EHCI probe until it can do so, this guarantees
  that the PHY's probe() will have completed before EHCI's probe()
  completes (although EHCI's probe may start running first some number of
  times, and be retried with -EPROBE_DEFERRED for a variety of reasons).
 
  Now, if the PHY driver's probe() actually touches HW and sets up some
  registers, isn't this reset call going to trash any of that register
  setup? Or, will PHY probe() not touch registers, but only do so during
  the standard PHY open/init op/API calls?
   
  Yes, PHY driver probe does not touch any registers. It just sets up the PHY 
  API hooks.
  These APIs will be called from ehci-tegra.c as part of ehci tegra probe 
  function, after
  getting  PHY handle, which in turn happens after issuing above reset.
  
  Thanks to Stephen  Alan, for the review comments.
 
 OK, in that case I have no objection to this patch.
 
 I'd like to hold off on applying this though; I suspect I'll want to
 take the Tegra USB patches through the Tegra tree rather than the USB
 tree again for the 3.10 kernel cycle. I think I may have screwed the
 pooch on the DT binding I set up for the USB controller clocks, and
 fixing this may require some Tegra DT changes, which would be easiest
 taken through the Tegra tree, and so to reduce conflicts in the USB
 code, taking the rest through there migth just be easiest.
 
 Alan, Greg, if you're OK with this patch now, or for any revised
 version, an Ack so I can take it through the Tegra tree would be great,
 thanks.

Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org
--
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 0/5] DWC2 DesignWare HS OTG driver

[gre...@linuxfoundation.org]

On Thu, Feb 21, 2013 at 07:33:45PM +, Paul Zimmerman wrote:
  -Original Message-
  From: Felipe Balbi [mailto:ba...@ti.com]
  Sent: Thursday, February 21, 2013 12:58 AM
  
  On Thu, Feb 21, 2013 at 03:22:54AM +, Paul Zimmerman wrote:
   Building and validating a new FPGA image is a lengthy task. If I can make
   things work by tweaking some module parameters, so much the better.
   Plus, as part of our validation testing we try with different values for 
   things
   like FIFO sizes and DMA modes. Building a new FPGA image to tweak
   stuff like that is just not practical.
  
  Is there at least part of that stuff which you could just do by default
  without relying on a module parameter ? I mean, if you know default
  value is bogus, can you not compute a good value in runtime and just
  use it ?
  
  I mean, the amount of module parameters in this driver is much more than
  anyone will be able to understand and use correctly. You really want to
  decrease the amount of module parameters. dwc3, for instance, has a
  single module parameter which is used for testing purposes only (forcing
  the IP to work on lower speeds). MUSB has 3 module parameters only,
  net2272 has 4... anyway, usually anything bigger than 4 to 5 module
  parameters will already cause problems, specially on cases where loading
  the driver without any module parameter is likely to not work.
 
 I can pare the user-visible module parameters down to 6, that would
 give us most of what we need for testing purposes. The remainder I
 can leave in the parameter struct, so they can be tweaked at build time,
 but not add module_param() calls for them. How does that sound?

Not good, you shouldn't have any module parameters if at all possible.

As you are saying you only need them for testing, they why not put
them in dynamic files, like debugfs, instead?

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/5] DWC2 DesignWare HS OTG driver

[gre...@linuxfoundation.org]

On Thu, Feb 21, 2013 at 07:57:14PM +, Paul Zimmerman wrote:
  -Original Message-
  From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
  Sent: Thursday, February 21, 2013 11:43 AM
  
  On Thu, Feb 21, 2013 at 07:33:45PM +, Paul Zimmerman wrote:
  
   I can pare the user-visible module parameters down to 6, that would
   give us most of what we need for testing purposes. The remainder I
   can leave in the parameter struct, so they can be tweaked at build time,
   but not add module_param() calls for them. How does that sound?
  
  Not good, you shouldn't have any module parameters if at all possible.
  
  As you are saying you only need them for testing, they why not put
  them in dynamic files, like debugfs, instead?
 
 Hi Greg,
 
 These parameters need to be set at driver initialization time.

Why, what do they control?

 I don't think debugfs will work for that, since the debugfs files
 won't exist before the driver is loaded. Am I wrong?

No, that is correct, but you could wait to initialize your device until
later if needed.  Or disconnect it and reconnect it logically if the
debugfs files are written to.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ARM part of USB patches

[gre...@linuxfoundation.org]

On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote:
 Hi Tony, Greg,
 
 On Tuesday 05 February 2013 08:54 PM, kishon wrote:
 Hi Tony,
 
 As discussed, I'm sending a pull request for the arch/arm part of my USB
 patches. These patches are necessary to get MUSB functional in both dt
 and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch
 series *depends* on some of the patches which are merged in usb-next.
 
 This patch series should go in only after USB. Or else it will break
 compilation.

Then it probably should go through the USB tree, right?  We don't want
to break bisectability.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ARM part of USB patches

[gre...@linuxfoundation.org]

On Tue, Feb 05, 2013 at 10:19:47AM -0800, Tony Lindgren wrote:
 * gre...@linuxfoundation.org gre...@linuxfoundation.org [130205 09:28]:
  On Tue, Feb 05, 2013 at 08:56:13PM +0530, kishon wrote:
   Hi Tony, Greg,
   
   On Tuesday 05 February 2013 08:54 PM, kishon wrote:
   Hi Tony,
   
   As discussed, I'm sending a pull request for the arch/arm part of my USB
   patches. These patches are necessary to get MUSB functional in both dt
   and non-dt boot. Also added dt data for dwc3 present in OMAP. This patch
   series *depends* on some of the patches which are merged in usb-next.
   
   This patch series should go in only after USB. Or else it will break
   compilation.
  
  Then it probably should go through the USB tree, right?  We don't want
  to break bisectability.
 
 Looks like this branch needs to be based on at least 01658f0f (usb: phy:
 add a new driver for usb part of control module) to compile. Probably
 needs other USB patches too to make sense.
 
 This branch has a high likelihood of conflicting with .dts files, so
 Kishon, I suggest you do two branches:
 
 1. A branch for Greg based on top of the USB changes
 
This branch should contain:
 
ARM: OMAP4: remove control module address space from PHY and OTG
ARM: OMAP: devices: create device for usb part of control module
ARM: OMAP2: MUSB: Specify omap4 has mailbox
ARM: OMAP: USB: Add phy binding information
 
Naturally please make sure they compile and boot on their own.
Looks like this will only cause few trivial include merge conflicts
with what I have queued up.
 
You can add my Acked-by: Tony Lindgren t...@atomide.com for those.

If that happens, please send me patches in email, I don't take git
pull requests, especially for something as small as 4 patches.

thanks,

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] USB: PHY: Re-organize Tegra USB PHY driver

[gre...@linuxfoundation.org]

On Thu, Sep 20, 2012 at 10:50:51AM +0530, Venu Byravarasu wrote:
 Hi Greg  Felipe,
 
 Can any of you please review and merge this change?

That's up to Felipe.

--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] USB/host: Cleanup unneccessary irq disable code

[gre...@linuxfoundation.org]

On Thu, Sep 06, 2012 at 02:00:16AM +, Liu, Chuansheng wrote:
 Because the IRQF_DISABLED as the flag is now a NOOP and has been
 deprecated and in hardirq context the interrupt is disabled.
 
 so in usb/host code:
 Removing the usage of flag IRQF_DISABLED;
 Removing the calling local_irq save/restore actions in irq
 handler usb_hcd_irq();
 
 Signed-off-by: liu chuansheng chuansheng@intel.com
 Acked-by: Alan Stern st...@rowland.harvard.edu
 ---
  drivers/usb/core/hcd.c   |   15 ---
  drivers/usb/host/ehci-ls1x.c |2 +-
  drivers/usb/host/ohci-xls.c  |2 +-
  3 files changed, 2 insertions(+), 17 deletions(-)
 
 diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
 index bc84106..f84ddea 100644
 --- a/drivers/usb/core/hcd.c
 +++ b/drivers/usb/core/hcd.c
 @@ -2153,15 +2153,8 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
  irqreturn_t usb_hcd_irq (int irq, void *__hcd)
  {
 struct usb_hcd  *hcd = __hcd;
 -   unsigned long   flags;
 irqreturn_t rc;

All of your whitespace is broken, making this patch impossible to apply.

As I asked before, please fix this.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] USB/host: Cleanup unneccessary irq disable code

[gre...@linuxfoundation.org]

On Sat, Sep 01, 2012 at 09:39:56AM +, Liu, Chuansheng wrote:
 From: liu chuansheng chuansheng@intel.com
 Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code

Don't include the Subject: in the patch body again, that is pointless
and requires me to hand-edit the file.

 Because the IRQF_DISABLED as the flag is now a NOOP and has been
 deprecated and in hardirq context the interrupt is disabled.
 
 so in usb/host code:
 Removing the usage of flag IRQF_DISABLED;
 Removing the calling local_irq save/restore actions in irq
 handler usb_hcd_irq();
 
 Signed-off-by: liu chuansheng chuansheng@intel.com

This patch is corrupted and can not be applied at all.  Please fix your
email client and try again.

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