Re: [PATCH 3/4] usbdevfs: Use scatter-gather lists for large bulk transfers

[Hans de Goede]

Hi,

On 07/06/2012 07:51 PM, Greg Kroah-Hartman wrote:

On Wed, Jul 04, 2012 at 09:18:03AM +0200, Hans de Goede wrote:

+static void snoop_urb_data(struct urb *urb, unsigned len)
+{
+   int i, size;
+
+   if (!usbfs_snoop)
+   return;
+
+   if (urb->num_sgs == 0) {
+   print_hex_dump(KERN_DEBUG, "data: ", DUMP_PREFIX_NONE, 32, 1,
+   urb->transfer_buffer, len, 1);
+   return;
+   }
+
+   for (i = 0; i < urb->num_sgs && len; i++) {
+   size = (len > USB_SG_SIZE) ? USB_SG_SIZE : len;
+   print_hex_dump(KERN_DEBUG, "data: ", DUMP_PREFIX_NONE, 32, 1,
+   sg_virt(&urb->sg[i]), size, 1);
+   len -= size;
+   }
+}


Minor cleanup in the future, can't this be merged with snoop_urb() that
way you don't have to do the logic checking in the places you call this
function instead of snoop_urb()?  That would make it a bit simpler for
the "normal" code path, right?


Alan already made the same remark :) The problem is that snoop_urb is
also used for logging the synchronous urb ioctls, where there is no urb.
So making snoop_urb generic would require it gaining a struct urb *
argument while keeping its unsigned char *data and int data_len
arguments, and add an if (urb) ... else in there, so this way seems
better.

Regards,

Hans
--
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/hcd: Ensure scatter-gather is not used for isoc transfers

[Hans de Goede]

Hi,

On 07/06/2012 07:52 PM, Greg Kroah-Hartman wrote:

On Wed, Jul 04, 2012 at 09:18:04AM +0200, Hans de Goede wrote:

We don't support sg for isoc transfers, enforce this.

Signed-off-by: Hans de Goede 
Acked-by: Alan Stern 
---
  drivers/usb/core/hcd.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 140d3e1..3d2f48f 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1389,7 +1389,12 @@ int usb_hcd_map_urb_for_dma(struct usb_hcd *hcd, struct 
urb *urb,
&& !(urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP)) {
if (hcd->self.uses_dma) {
if (urb->num_sgs) {
-   int n = dma_map_sg(
+   int n;
+
+   /* We don't support sg for isoc transfers ! */
+   BUG_ON(usb_endpoint_xfer_isoc(&urb->ep->desc));


No, sorry, I will not take new BUG_ON() calls in any drivers.  You just
crashed a machine, and there is no way that a user can recover.  What
are they supposed to do here?  Who are they going to tell to fix the
issue?

I can see a WARN_ON() and then handle the error properly, but don't
crash a box, that's just rude.


Well this bug_on is intended for driver authors, so that users never get
hit by this because it is catched during development. The problem is that
currently trying to sg with isoc transfers fails silently (all the
data gets dma-ed to / from physical address 0). So the idea is that if
a driver author makes the same mistake I did while working on the
scatter-gather support for usbfs (where I tried to use it for isoc
initially too), they don't end up scratching their head as long as
I did :)

With that said / explained I completely agree. I guess a WARN_ON + error
return is also better for developers, as with a panic the actual reason may
well have scrolled off screen / data may be lost etc.

So I'll respin this one.

Regards,

Hans
--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Oleksij Rempel]

On 07.07.2012 11:20, Eric Ding wrote:
> On 07/06/2012 11:47 PM, Alan Stern wrote:
>> On Fri, 6 Jul 2012, Alan Cox wrote:
>>
 Yes, but we still need to know the reason why.  Neither Rafael nor I 
 has been able to figure out why that commit messed things up.
>>>
>>> Was the driver doing any dynamic autosuspend at all until that point ?
>>
>> I don't know...  but whatever it was doing before the commit, it should 
>> be doing the same thing afterward.
> 
> I'm really out of my league here; I only submitted a bug report because
> my webcam stopped working, never imagining it'd lead to 4-5 days of
> kernel bisection (which I've never done before) and/or submitting a
> kernel patch.  Still, though, if I can be of any further help in getting
> to the bottom of this, I'd like to try.
> 
> I thought that getting some comparative usbmon logs might help, but I'm
> not equipped to parse them.  To generate these logs, I ran guvcview once
> after plugging in the webcam, then did the following upon quiting
> guvcview: start listening via usbmon, sleep for four seconds, start
> guvcview again and stop listening via usbmon after four seconds.
> 
> I did this both at commit e1620d5 (the commit which triggered this
> issue) and once at commit 9975961 (one commit prior).  Going through
> these motions also confirmed that the problem is readily reproducible
> the second time I start guvcview at e1620d5, but not at 9975961.  I've
> attached both logs in case they're helpful.
> 
> Please let me know if there's anything more I can do to help.
> 
> Thanks,
> Eric
> 

In both logs you send the cam start to stream video. Major difference is
that, after suspend/resume it need more time (about 10 seconds) to start
stream. Is it correct?

-- 
Regards,
Oleksij


--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Eric Ding]

On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
> On 07.07.2012 11:20, Eric Ding wrote:
>> On 07/06/2012 11:47 PM, Alan Stern wrote:
>>> On Fri, 6 Jul 2012, Alan Cox wrote:
>>>
> Yes, but we still need to know the reason why.  Neither Rafael nor I 
> has been able to figure out why that commit messed things up.

 Was the driver doing any dynamic autosuspend at all until that point ?
>>>
>>> I don't know...  but whatever it was doing before the commit, it should 
>>> be doing the same thing afterward.
>>
>> I thought that getting some comparative usbmon logs might help, but I'm
>> not equipped to parse them.  To generate these logs, I ran guvcview once
>> after plugging in the webcam, then did the following upon quiting
>> guvcview: start listening via usbmon, sleep for four seconds, start
>> guvcview again and stop listening via usbmon after four seconds.
>>
>> I did this both at commit e1620d5 (the commit which triggered this
>> issue) and once at commit 9975961 (one commit prior).  Going through
>> these motions also confirmed that the problem is readily reproducible
>> the second time I start guvcview at e1620d5, but not at 9975961.  I've
>> attached both logs in case they're helpful.
>
> In both logs you send the cam start to stream video. Major difference is
> that, after suspend/resume it need more time (about 10 seconds) to start
> stream. Is it correct?

My tests didn't continue a full 10 seconds after I restarted the webcam,
so I'm not sure I follow your question.  In the second case (with
e1620d5), the camera never returns a "normal" video image -- instead, it
gets a garbled video image of horizontal stripes, which change with what
the camera lens is seeing, but are obviously not the correct image.

The stream does take longer to come up on the second time than the
first, though, during which I see the following error message in
guvcview 1-3 times:

 Could not grab image (select timeout): Resource temporarily unavailable

Sorry if I'm not answering your question helpfully!

Eric
--
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/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework

[Laurent Pinchart]

Hi Bhupesh,

On Tuesday 03 July 2012 23:42:59 Bhupesh SHARMA wrote:
> Hi Laurent,
> 
> Thanks for your review and sorry for being late with my replies.
> I have a lot on my plate these days :)

No worries, I'm no less busy anyway :-)

> On Tuesday, June 19, 2012 4:19 AM Laurent Pinchart wrote:
> > On Friday 01 June 2012 15:08:57 Bhupesh Sharma wrote:

[snip]

> > > diff --git a/drivers/usb/gadget/uvc_queue.c
> > > b/drivers/usb/gadget/uvc_queue.c
> > > index 0cdf89d..907ece8 100644
> > > --- a/drivers/usb/gadget/uvc_queue.c
> > > +++ b/drivers/usb/gadget/uvc_queue.c

[snip]

> > > +static int uvc_buffer_prepare(struct vb2_buffer *vb)
> > >  {

[snip]

> > > +   buf->state = UVC_BUF_STATE_QUEUED;
> > > +   buf->mem = vb2_plane_vaddr(vb, 0);
> > > +   buf->length = vb2_plane_size(vb, 0);
> > > +   if (vb->v4l2_buf.type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> > > +   buf->bytesused = 0;
> > > +   else
> > > +   buf->bytesused = vb2_get_plane_payload(vb, 0);
> > 
> > The driver doesn't support the capture type at the moment so this might be
> > a bit overkill, but I think it's a good idea to support capture in the
> > queue imeplementation. I plan to try and merge the uvcvideo and uvcgadget
> > queue implementations at some point.
> 
> I am thinking now whether we really need to support UVC as a capture type
> video device. The use cases that I can think of now, UVC always seems to be
> a output device.
> 
> Any use-case where you think UVC can be a capture device?

It could be useful for video output devices. I know of at least one UVC output 
device (albeit not Linux-based), which I used to implement and test video 
output in the UVC host driver. As the host driver supports video output 
devices, supporting them in the gadget driver can be useful as well.

> > > +   return 0;
> > > +}

[snip]

> > >  static struct uvc_buffer *
> > >  uvc_queue_next_buffer(struct uvc_video_queue *queue, struct uvc_buffer
> > > *buf)

[snip]

> > > -   buf->buf.sequence = queue->sequence++;
> > > -   do_gettimeofday(&buf->buf.timestamp);
> > 
> > videobuf2 doesn't fill the sequence number or timestamp fields, so you
> > either need to keep this here or move it to the caller.
> 
> Yes I think these fields are only valid for video capture devices.
> As my use-case was only an output UVC video device, I didn't add the same.
> 
> Please let me know your views on the same.

Good point. The spec isn't clear about this, so I'd rather keep these two 
lines for now.

> > > +   vb2_set_plane_payload(&buf->buf, 0, buf->bytesused);
> > > +   vb2_buffer_done(&buf->buf, VB2_BUF_STATE_DONE);
> > > 
> > > -   wake_up(&buf->wait);
> > > 
> > > return nextbuf;
> > >  }

[snip]

> > > diff --git a/drivers/usb/gadget/uvc_v4l2.c
> > b/drivers/usb/gadget/uvc_v4l2.c
> > > index f6e083b..9c2b45b 100644
> > > --- a/drivers/usb/gadget/uvc_v4l2.c
> > > +++ b/drivers/usb/gadget/uvc_v4l2.c
> > > @@ -144,20 +144,23 @@ uvc_v4l2_release(struct file *file)
> > > 
> > > struct uvc_device *uvc = video_get_drvdata(vdev);
> > > struct uvc_file_handle *handle = to_uvc_file_handle(file-
> > >
> > >private_data);
> > >
> > > struct uvc_video *video = handle->device;
> > > 
> > > +   int ret;
> > > 
> > > uvc_function_disconnect(uvc);
> > > 
> > > -   uvc_video_enable(video, 0);
> > > -   mutex_lock(&video->queue.mutex);
> > > -   if (uvc_free_buffers(&video->queue) < 0)
> > > -   printk(KERN_ERR "uvc_v4l2_release: Unable to free "
> > > -   "buffers.\n");
> > > -   mutex_unlock(&video->queue.mutex);
> > > +   ret = uvc_video_enable(video, 0);
> > > +   if (ret < 0) {
> > > +   printk(KERN_ERR "uvc_v4l2_release: uvc video disable
> > 
> > failed\n");
> > 
> > > +   return ret;
> > > +   }
> > 
> > This shouldn't prevent uvc_v4l2_release() from succeeding. In practive
> > uvc_video_enable(0) will never fail, so you can remove the error check.
> 
> To be honest, I saw once the 'uvc_video_enable(0)' failing that's why I
> added this check. I don't remember the exact instance of the failure, but
> I can try to check again and then will come back on the same.

The only reason I see for uvc_video_enable(video, 0) to fail is if the video 
endpoint hasn't been allocated. As the V4L2 device node is registered after 
allocating the endpoint, I'm surprised to hear that you saw it failing. If you 
can reproduce the problem I'd be curious to have more information.

> > > +
> > > +   uvc_free_buffers(&video->queue);
> > > 
> > > file->private_data = NULL;
> > > v4l2_fh_del(&handle->vfh);
> > > v4l2_fh_exit(&handle->vfh);
> > > kfree(handle);
> > > +
> > > return 0;
> > >  }

[snip]

> > > diff --git a/drivers/usb/gadget/uvc_video.c
> > > b/drivers/usb/gadget/uvc_video.c
> > > index b0e53a8..195bbb6 100644
> > > --- a/drivers/usb/gadget/uvc_video.c
> > > +++ b/drivers/usb/gadget/uvc_video.c
> > 
> > [snip]
> > 
> > > @@ -161,6 +161,7 @@ static void
> > > 
> > >  uvc_video_complete(stru

Re: [PATCH 5/5] usb: gadget/uvc: Add support for 'USB_GADGET_DELAYED_STATUS' response for a set_intf(alt-set 1) command

[Laurent Pinchart]

Hi Bhupesh,

On Tuesday 03 July 2012 23:47:14 Bhupesh SHARMA wrote:
> On Wednesday, June 20, 2012 3:19 AM Laurent Pinchart wrote:
> > On Friday 01 June 2012 15:08:58 Bhupesh Sharma wrote:
> > > This patch adds the support in UVC webcam gadget design for providing
> > > USB_GADGET_DELAYED_STATUS in response to a set_interface(alt setting 1)
> > > command issue by the Host.
> > > 
> > > The current UVC webcam gadget design generates a STREAMON event
> > > corresponding to a set_interface(alt setting 1) command from the Host.
> > > This STREAMON event will eventually be routed to a real V4L2 device.
> > > 
> > > To start video streaming, it may be required to perform some register
> > > writes to a camera sensor device over slow external busses like I2C or
> > > SPI. So, it makes sense to ensure that we delay the STATUS stage of the
> > > set_interface(alt setting 1) command.
> > > 
> > > Otherwise, a lot of ISOC IN tokens sent by the Host will be replied to
> > > by zero-length packets by the webcam device. On certain Hosts this may
> > > even> lead to ISOC URBs been cancelled from the Host side.
> > > 
> > > So, as soon as we finish doing all the "streaming" related stuff on the
> > > real V4L2 device, we call a STREAMON ioctl on the UVC side and from here
> > > we call the 'usb_composite_setup_continue' function to complete the
> > > status stage of the set_interface(alt setting 1) command.
> > 
> > That sounds good, thank you for coming up with a solution to this
> > issue.
> > 
> > > Further, we need to ensure that we queue no video buffers on the UVC
> > > webcam gadget, until we de-queue a video buffer from the V4L2 device.
> > > Also, we need to enable UVC video related stuff at the first QBUF ioctl
> > > call itself, as the application will call the STREAMON on UVC side only
> > > when it has dequeued sufficient buffers from the V4L2 side and queued
> > > them to the UVC gadget. So, the UVC video enable stuff cannot be done in
> > > STREAMON ioctl call.
> > 
> > Is that really required ? First of all, the userspace application can
> > queue buffers before it calls VIDIOC_STREAMON. Assuming it doesn't, the
> > gadget driver calls uvc_video_enable() at streamon time, which then calls
> > uvc_video_pump(). As no buffer is queued, the function will return without
> > queuing any USB request, so we shouldn't have any problem.
> 
> I think that while working with a real video device, it will be possible to
> queue a buffer at UVC end only when atleast one buffer has been dequeued
> from the V4L2 device side (and has some real data).
> 
> This is because for a uvc buffer being queued we need to pass the v4l2
> buffer's buffer.start and buffer.length in the qbuf call at UVC side.

I agree with you, queuing a buffer on the UVC gadget side will usually require 
starting capture and waiting for a frame on a V4L2 source device. However, 
unless I'm mistaken, the UVC gadget code already deals with that situation 
correctly. As I explained, when your application calls VIDIOC_STREAMON on the 
UVC gadget, the uvc_video_pump() will not find any V4L2 buffer to be 
transferred, and will return without queuing any URB. It will then be called 
again by VIDIOC_QBUF, and will then start the transfer.

Adding support for USB_GADGET_DELAYED_STATUS is thus a good idea, but the pre-
streaming state is in my opinion not needed. Feel free to prove me wrong 
though :-)

> > > For the same we add two more UVC states:
> > >   - PRE_STREAMING : not even a single buffer has been queued to UVC
> > >   - BUF_QUEUED_STREAMING_OFF : one video buffer has been queued to UVC
> > >   but we have not yet enabled STREAMING on UVC side.
> > > 
> > > Signed-off-by: Bhupesh Sharma 

-- 
Regards,

Laurent Pinchart

--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Oleksij Rempel]

On 07.07.2012 13:38, Eric Ding wrote:
> On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
>> On 07.07.2012 11:20, Eric Ding wrote:
>>> On 07/06/2012 11:47 PM, Alan Stern wrote:
 On Fri, 6 Jul 2012, Alan Cox wrote:

>> Yes, but we still need to know the reason why.  Neither Rafael nor I 
>> has been able to figure out why that commit messed things up.
>
> Was the driver doing any dynamic autosuspend at all until that point ?

 I don't know...  but whatever it was doing before the commit, it should 
 be doing the same thing afterward.
>>>
>>> I thought that getting some comparative usbmon logs might help, but I'm
>>> not equipped to parse them.  To generate these logs, I ran guvcview once
>>> after plugging in the webcam, then did the following upon quiting
>>> guvcview: start listening via usbmon, sleep for four seconds, start
>>> guvcview again and stop listening via usbmon after four seconds.
>>>
>>> I did this both at commit e1620d5 (the commit which triggered this
>>> issue) and once at commit 9975961 (one commit prior).  Going through
>>> these motions also confirmed that the problem is readily reproducible
>>> the second time I start guvcview at e1620d5, but not at 9975961.  I've
>>> attached both logs in case they're helpful.
>>
>> In both logs you send the cam start to stream video. Major difference is
>> that, after suspend/resume it need more time (about 10 seconds) to start
>> stream. Is it correct?
> 
> My tests didn't continue a full 10 seconds after I restarted the webcam,
> so I'm not sure I follow your question.  In the second case (with
> e1620d5), the camera never returns a "normal" video image -- instead, it
> gets a garbled video image of horizontal stripes, which change with what
> the camera lens is seeing, but are obviously not the correct image.
> 
> The stream does take longer to come up on the second time than the
> first, though, during which I see the following error message in
> guvcview 1-3 times:
> 
>  Could not grab image (select timeout): Resource temporarily unavailable
> 
> Sorry if I'm not answering your question helpfully!
> 
> Eric
> 

Ok,  i guess i know your problem but i doubt it will be completely fixed
by changing powermanagement behavior. Two logitech cams i tested is
really easy to confuse/brake/freeze. Just turn off the stream before it
will send first frame. It looks like it take longer to boot buildin
controller or image processor. On second (hot) start it take less time.
If the cam was suspended it need this boot time again. The problem, even
if we do hot start and turn of stream before first frame, like some apps
did, the cam will brake again. By disabling auto suspend, we will reduce
probability to brake it, but not fix it.

Some times i have the splitimage issue too, but i can't 100% reproduce it.
-- 
Regards,
Oleksij


--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Eric Ding]

On 07/07/2012 09:11 PM, Oleksij Rempel wrote:
> On 07.07.2012 13:38, Eric Ding wrote:
>> On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
>>> On 07.07.2012 11:20, Eric Ding wrote:
 On 07/06/2012 11:47 PM, Alan Stern wrote:
> On Fri, 6 Jul 2012, Alan Cox wrote:
>
>>> Yes, but we still need to know the reason why.  Neither Rafael nor I 
>>> has been able to figure out why that commit messed things up.
>>
>> Was the driver doing any dynamic autosuspend at all until that point ?
>
> I don't know...  but whatever it was doing before the commit, it should 
> be doing the same thing afterward.

 I thought that getting some comparative usbmon logs might help, but I'm
 not equipped to parse them.  To generate these logs, I ran guvcview once
 after plugging in the webcam, then did the following upon quiting
 guvcview: start listening via usbmon, sleep for four seconds, start
 guvcview again and stop listening via usbmon after four seconds.

 I did this both at commit e1620d5 (the commit which triggered this
 issue) and once at commit 9975961 (one commit prior).  Going through
 these motions also confirmed that the problem is readily reproducible
 the second time I start guvcview at e1620d5, but not at 9975961.  I've
 attached both logs in case they're helpful.
>>>
>>> In both logs you send the cam start to stream video. Major difference is
>>> that, after suspend/resume it need more time (about 10 seconds) to start
>>> stream. Is it correct?
>>
>> My tests didn't continue a full 10 seconds after I restarted the webcam,
>> so I'm not sure I follow your question.  In the second case (with
>> e1620d5), the camera never returns a "normal" video image -- instead, it
>> gets a garbled video image of horizontal stripes, which change with what
>> the camera lens is seeing, but are obviously not the correct image.
> 
> Ok,  i guess i know your problem but i doubt it will be completely fixed
> by changing powermanagement behavior. Two logitech cams i tested is
> really easy to confuse/brake/freeze. Just turn off the stream before it
> will send first frame. It looks like it take longer to boot buildin
> controller or image processor. On second (hot) start it take less time.
> If the cam was suspended it need this boot time again. The problem, even
> if we do hot start and turn of stream before first frame, like some apps
> did, the cam will brake again. By disabling auto suspend, we will reduce
> probability to brake it, but not fix it.
> 
> Some times i have the splitimage issue too, but i can't 100% reproduce it.

So does your description of the problem explain why commit e1620d5
causes this problem to happen 100% of the time on the second start, even
though I cannot reproduce this problem at all before that commit?  Isn't
that the mystery that still remains unsolved?  Do the usbmon logs not
answer that question?

Going back also to the patch I submitted, it seems (at least in my
testing) that USB_QUIRK_RESET_RESUME does work around this issue
consistently, at least for my webcam.

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

Re: [PATCH v8 06/14] USB: Chipidea: rename struct ci13xxx variables from udc to ci

[Richard Zhao]

On Fri, Jul 06, 2012 at 11:07:21AM -0700, Greg KH wrote:
> On Fri, Jun 29, 2012 at 05:48:54PM +0800, Richard Zhao wrote:
> > struct ci13xxx represent the controller, which may be device or host,
> > so name its variables as ci.
> > 
> > Signed-off-by: Richard Zhao 
> > Reviewed-by: Felipe Balbi 
> > Signed-off-by: Alexander Shishkin 
> > Reviewed-by: Marek Vasut 
> 
> This patch fails to apply (the 5/14 had some fuzz, but I fixed that by
> hand.
#5 is good. Thanks.
> )  Odds are it's due to Felipe's other changes now in my tree.
> Care to rediff this, and the rest of the series against the usb-next
> branch and resend them so that I can apply them?
I'll send out v9 REBASE.

Thanks
Richard
> 
> I've applied the first 5 in this series already, so you don't have to
> resend them.
> 
> 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 v9 REBASE 0/9] add imx usb driver based on Greg next tree

[Richard Zhao]

The work is based on  ci13xxx rework done by Alexander Shishkin.

To let Greg pick up, I also added patches Alex queued that I depends on.

This patch series can also be found at:
https://github.com/riczhao/kernel-imx/commits/topics/usb-driver

Status:
  - this version only support host
  - usbotg controler works at host role

Changes since last version:
 - Rebase patch that Greg failed to merge.


Richard Zhao (9):
  USB: Chipidea: rename struct ci13xxx variables from udc to ci
  USB: Chipidea: add unified ci13xxx_{add,remove}_device for platform
drivers
  USB: Chipidea: add ci13xxx device id management
  usb: chipidea: select USB_EHCI_ROOT_HUB_TT in USB_CHIPIDEA_HOST of
Kconfig
  usb: otg: add notify_connect/notify_disconnect callback
  USB: notify phy when root hub port connect change
  usb: chipidea: permit driver bindings pass phy pointer
  usb: otg: add basic mxs phy driver support
  usb: chipidea: add imx platform driver

 .../devicetree/bindings/usb/ci13xxx-imx.txt|   18 +
 Documentation/devicetree/bindings/usb/mxs-phy.txt  |   13 +
 drivers/usb/chipidea/Kconfig   |1 +
 drivers/usb/chipidea/Makefile  |3 +
 drivers/usb/chipidea/ci.h  |   28 +-
 drivers/usb/chipidea/ci13xxx_imx.c |  198 ++
 drivers/usb/chipidea/ci13xxx_msm.c |   46 +-
 drivers/usb/chipidea/ci13xxx_pci.c |   34 +-
 drivers/usb/chipidea/core.c|   58 ++
 drivers/usb/chipidea/debug.c   |  146 ++---
 drivers/usb/chipidea/host.c|1 +
 drivers/usb/chipidea/udc.c |  631 ++--
 drivers/usb/core/hub.c |8 +
 drivers/usb/otg/Kconfig|   10 +
 drivers/usb/otg/Makefile   |1 +
 drivers/usb/otg/mxs-phy.c  |  186 ++
 include/linux/usb/chipidea.h   |   12 +-
 include/linux/usb/otg.h|   21 +
 18 files changed, 953 insertions(+), 462 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
 create mode 100644 Documentation/devicetree/bindings/usb/mxs-phy.txt
 create mode 100644 drivers/usb/chipidea/ci13xxx_imx.c
 create mode 100644 drivers/usb/otg/mxs-phy.c

-- 
1.7.9.5


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

[PATCH v9 REBASE 2/9] USB: Chipidea: add unified ci13xxx_{add,remove}_device for platform drivers

[Richard Zhao]

Platform drivers do the similar things to add/remove ci13xxx device, so
create a unified one.

Signed-off-by: Richard Zhao 
Reviewed-by: Felipe Balbi 
Signed-off-by: Alexander Shishkin 
---
 drivers/usb/chipidea/ci13xxx_msm.c |   34 ++--
 drivers/usb/chipidea/ci13xxx_pci.c |   34 +---
 drivers/usb/chipidea/core.c|   43 
 include/linux/usb/chipidea.h   |7 ++
 4 files changed, 63 insertions(+), 55 deletions(-)

diff --git a/drivers/usb/chipidea/ci13xxx_msm.c 
b/drivers/usb/chipidea/ci13xxx_msm.c
index 5a2fe5f..b01feb3 100644
--- a/drivers/usb/chipidea/ci13xxx_msm.c
+++ b/drivers/usb/chipidea/ci13xxx_msm.c
@@ -58,43 +58,23 @@ static struct ci13xxx_platform_data ci13xxx_msm_platdata = {
 static int __devinit ci13xxx_msm_probe(struct platform_device *pdev)
 {
struct platform_device *plat_ci;
-   int ret;
 
dev_dbg(&pdev->dev, "ci13xxx_msm_probe\n");
 
-   plat_ci = platform_device_alloc("ci_hdrc", -1);
-   if (!plat_ci) {
-   dev_err(&pdev->dev, "can't allocate ci_hdrc platform device\n");
-   return -ENOMEM;
+   plat_ci = ci13xxx_add_device(&pdev->dev,
+   pdev->resource, pdev->num_resources,
+   &ci13xxx_msm_platdata);
+   if (IS_ERR(plat_ci)) {
+   dev_err(&pdev->dev, "ci13xxx_add_device failed!\n");
+   return PTR_ERR(plat_ci);
}
 
-   ret = platform_device_add_resources(plat_ci, pdev->resource,
-   pdev->num_resources);
-   if (ret) {
-   dev_err(&pdev->dev, "can't add resources to platform device\n");
-   goto put_platform;
-   }
-
-   ret = platform_device_add_data(plat_ci, &ci13xxx_msm_platdata,
-  sizeof(ci13xxx_msm_platdata));
-   if (ret)
-   goto put_platform;
-
-   ret = platform_device_add(plat_ci);
-   if (ret)
-   goto put_platform;
-
platform_set_drvdata(pdev, plat_ci);
 
pm_runtime_no_callbacks(&pdev->dev);
pm_runtime_enable(&pdev->dev);
 
return 0;
-
-put_platform:
-   platform_device_put(plat_ci);
-
-   return ret;
 }
 
 static int __devexit ci13xxx_msm_remove(struct platform_device *pdev)
@@ -102,7 +82,7 @@ static int __devexit ci13xxx_msm_remove(struct 
platform_device *pdev)
struct platform_device *plat_ci = platform_get_drvdata(pdev);
 
pm_runtime_disable(&pdev->dev);
-   platform_device_unregister(plat_ci);
+   ci13xxx_remove_device(plat_ci);
 
return 0;
 }
diff --git a/drivers/usb/chipidea/ci13xxx_pci.c 
b/drivers/usb/chipidea/ci13xxx_pci.c
index cdcac3a..918e149 100644
--- a/drivers/usb/chipidea/ci13xxx_pci.c
+++ b/drivers/usb/chipidea/ci13xxx_pci.c
@@ -75,13 +75,6 @@ static int __devinit ci13xxx_pci_probe(struct pci_dev *pdev,
pci_set_master(pdev);
pci_try_set_mwi(pdev);
 
-   plat_ci = platform_device_alloc("ci_hdrc", -1);
-   if (!plat_ci) {
-   dev_err(&pdev->dev, "can't allocate ci_hdrc platform device\n");
-   retval = -ENOMEM;
-   goto disable_device;
-   }
-
memset(res, 0, sizeof(res));
res[0].start= pci_resource_start(pdev, 0);
res[0].end  = pci_resource_end(pdev, 0);
@@ -89,32 +82,17 @@ static int __devinit ci13xxx_pci_probe(struct pci_dev *pdev,
res[1].start= pdev->irq;
res[1].flags= IORESOURCE_IRQ;
 
-   retval = platform_device_add_resources(plat_ci, res, nres);
-   if (retval) {
-   dev_err(&pdev->dev, "can't add resources to platform device\n");
-   goto put_platform;
+   plat_ci = ci13xxx_add_device(&pdev->dev, res, nres, platdata);
+   if (IS_ERR(plat_ci)) {
+   dev_err(&pdev->dev, "ci13xxx_add_device failed!\n");
+   retval = PTR_ERR(plat_ci);
+   goto disable_device;
}
 
-   retval = platform_device_add_data(plat_ci, platdata, sizeof(*platdata));
-   if (retval)
-   goto put_platform;
-
-   dma_set_coherent_mask(&plat_ci->dev, pdev->dev.coherent_dma_mask);
-   plat_ci->dev.dma_mask = pdev->dev.dma_mask;
-   plat_ci->dev.dma_parms = pdev->dev.dma_parms;
-   plat_ci->dev.parent = &pdev->dev;
-
pci_set_drvdata(pdev, plat_ci);
 
-   retval = platform_device_add(plat_ci);
-   if (retval)
-   goto put_platform;
-
return 0;
 
- put_platform:
-   pci_set_drvdata(pdev, NULL);
-   platform_device_put(plat_ci);
  disable_device:
pci_disable_device(pdev);
  done:
@@ -133,7 +111,7 @@ static void __devexit ci13xxx_pci_remove(struct pci_dev 
*pdev)
 {
struct platform_device *plat_ci = pci_get_drvdata(pdev);
 
-   platform_device_unregister(plat_ci);
+   ci13xxx_remove_device(plat_ci);
pci_set_drvdata(pde

[PATCH v9 REBASE 3/9] USB: Chipidea: add ci13xxx device id management

[Richard Zhao]

We use ida_simple_get and ida_simple_remove to manage the ids.

Signed-off-by: Richard Zhao 
Reviewed-by: Felipe Balbi 
Signed-off-by: Alexander Shishkin 
---
 drivers/usb/chipidea/core.c |   21 -
 1 file changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 8b9d06f..39603d7 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -56,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -332,17 +333,24 @@ static irqreturn_t ci_irq(int irq, void *data)
return ci->role == CI_ROLE_END ? ret : ci_role(ci)->irq(ci);
 }
 
+static DEFINE_IDA(ci_ida);
+
 struct platform_device *ci13xxx_add_device(struct device *dev,
struct resource *res, int nres,
struct ci13xxx_platform_data *platdata)
 {
struct platform_device *pdev;
-   int ret;
+   int id, ret;
 
-   /* FIXME: find a way to choose id */
-   pdev = platform_device_alloc("ci_hdrc", -1);
-   if (!pdev)
-   return ERR_PTR(-ENOMEM);
+   id = ida_simple_get(&ci_ida, 0, 0, GFP_KERNEL);
+   if (id < 0)
+   return ERR_PTR(id);
+
+   pdev = platform_device_alloc("ci_hdrc", id);
+   if (!pdev) {
+   ret = -ENOMEM;
+   goto put_id;
+   }
 
pdev->dev.parent = dev;
pdev->dev.dma_mask = dev->dma_mask;
@@ -365,6 +373,8 @@ struct platform_device *ci13xxx_add_device(struct device 
*dev,
 
 err:
platform_device_put(pdev);
+put_id:
+   ida_simple_remove(&ci_ida, id);
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(ci13xxx_add_device);
@@ -372,6 +382,7 @@ EXPORT_SYMBOL_GPL(ci13xxx_add_device);
 void ci13xxx_remove_device(struct platform_device *pdev)
 {
platform_device_unregister(pdev);
+   ida_simple_remove(&ci_ida, pdev->id);
 }
 EXPORT_SYMBOL_GPL(ci13xxx_remove_device);
 
-- 
1.7.9.5


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

[PATCH v9 REBASE 4/9] usb: chipidea: select USB_EHCI_ROOT_HUB_TT in USB_CHIPIDEA_HOST of Kconfig

[Richard Zhao]

ci13xxx host needs Root Hub Transaction Translators.

Reported-by: Shawn Guo 
Signed-off-by: Richard Zhao 
Acked-by: Felipe Balbi 
Signed-off-by: Alexander Shishkin 
Acked-by: Marek Vasut 
---
 drivers/usb/chipidea/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index fd36dc8..8337fb5 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -20,6 +20,7 @@ config USB_CHIPIDEA_UDC
 
 config USB_CHIPIDEA_HOST
bool "ChipIdea host controller"
+   select USB_EHCI_ROOT_HUB_TT
help
  Say Y here to enable host controller functionality of the
  ChipIdea driver.
-- 
1.7.9.5


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

[PATCH v9 REBASE 5/9] usb: otg: add notify_connect/notify_disconnect callback

[Richard Zhao]

This let usb phy driver has a chance to change hw settings when connect
status change.

Signed-off-by: Richard Zhao 
Acked-by: Felipe Balbi 
Tested-by: Subodh Nijsure 
---
 include/linux/usb/otg.h |   21 +
 1 file changed, 21 insertions(+)

diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 0cb2ec2..45824be 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -128,6 +128,9 @@ struct usb_phy {
int (*set_suspend)(struct usb_phy *x,
int suspend);
 
+   /* notify phy connect status change */
+   int (*notify_connect)(struct usb_phy *x, int port);
+   int (*notify_disconnect)(struct usb_phy *x, int port);
 };
 
 
@@ -277,6 +280,24 @@ usb_phy_set_suspend(struct usb_phy *x, int suspend)
 }
 
 static inline int
+usb_phy_notify_connect(struct usb_phy *x, int port)
+{
+   if (x->notify_connect)
+   return x->notify_connect(x, port);
+   else
+   return 0;
+}
+
+static inline int
+usb_phy_notify_disconnect(struct usb_phy *x, int port)
+{
+   if (x->notify_disconnect)
+   return x->notify_disconnect(x, port);
+   else
+   return 0;
+}
+
+static inline int
 otg_start_srp(struct usb_otg *otg)
 {
if (otg && otg->start_srp)
-- 
1.7.9.5


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

[PATCH v9 REBASE 7/9] usb: chipidea: permit driver bindings pass phy pointer

[Richard Zhao]

Sometimes, the driver bindings may know what phy they use.
For example, when using device tree, the usb controller may have a
phandler pointing to usb phy.

Signed-off-by: Richard Zhao 
Reviewed-by: Marek Vasut 
Acked-by: Felipe Balbi 
Tested-by: Subodh Nijsure 
---
 drivers/usb/chipidea/ci.h|2 ++
 drivers/usb/chipidea/core.c  |4 
 drivers/usb/chipidea/host.c  |1 +
 drivers/usb/chipidea/udc.c   |   11 +++
 include/linux/usb/chipidea.h |3 +++
 5 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 9655e35..d738603 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -160,6 +160,8 @@ struct ci13xxx {
 
struct ci13xxx_platform_data*platdata;
int vbus_active;
+   /* FIXME: some day, we'll not use global phy */
+   boolglobal_phy;
struct usb_phy  *transceiver;
struct usb_hcd  *hcd;
 };
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 39603d7..1083585 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -419,6 +419,10 @@ static int __devinit ci_hdrc_probe(struct platform_device 
*pdev)
 
ci->dev = dev;
ci->platdata = dev->platform_data;
+   if (ci->platdata->phy)
+   ci->transceiver = ci->platdata->phy;
+   else
+   ci->global_phy = true;
 
ret = hw_device_init(ci, base);
if (ret < 0) {
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 4a4fdb8..ebff9f4 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -117,6 +117,7 @@ static int host_start(struct ci13xxx *ci)
hcd->has_tt = 1;
 
hcd->power_budget = ci->platdata->power_budget;
+   hcd->phy = ci->transceiver;
 
ehci = hcd_to_ehci(hcd);
ehci->caps = ci->hw_bank.cap;
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index ba8284e..c7a032a 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1685,7 +1685,8 @@ static int udc_start(struct ci13xxx *ci)
 
ci->gadget.ep0 = &ci->ep0in->ep;
 
-   ci->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
+   if (ci->global_phy)
+   ci->transceiver = usb_get_phy(USB_PHY_TYPE_USB2);
 
if (ci->platdata->flags & CI13XXX_REQUIRE_TRANSCEIVER) {
if (ci->transceiver == NULL) {
@@ -1729,7 +1730,8 @@ static int udc_start(struct ci13xxx *ci)
 remove_trans:
if (!IS_ERR_OR_NULL(ci->transceiver)) {
otg_set_peripheral(ci->transceiver->otg, &ci->gadget);
-   usb_put_phy(ci->transceiver);
+   if (ci->global_phy)
+   usb_put_phy(ci->transceiver);
}
 
dev_err(dev, "error = %i\n", retval);
@@ -1738,7 +1740,7 @@ remove_dbg:
 unreg_device:
device_unregister(&ci->gadget.dev);
 put_transceiver:
-   if (!IS_ERR_OR_NULL(ci->transceiver))
+   if (!IS_ERR_OR_NULL(ci->transceiver) && ci->global_phy)
usb_put_phy(ci->transceiver);
 free_pools:
dma_pool_destroy(ci->td_pool);
@@ -1772,7 +1774,8 @@ static void udc_stop(struct ci13xxx *ci)
 
if (!IS_ERR_OR_NULL(ci->transceiver)) {
otg_set_peripheral(ci->transceiver->otg, NULL);
-   usb_put_phy(ci->transceiver);
+   if (ci->global_phy)
+   usb_put_phy(ci->transceiver);
}
dbg_remove_files(&ci->gadget.dev);
device_unregister(&ci->gadget.dev);
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index be078f0..544825d 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -5,12 +5,15 @@
 #ifndef __LINUX_USB_CHIPIDEA_H
 #define __LINUX_USB_CHIPIDEA_H
 
+#include 
+
 struct ci13xxx;
 struct ci13xxx_platform_data {
const char  *name;
/* offset of the capability registers */
uintptr_tcapoffset;
unsigned power_budget;
+   struct usb_phy  *phy;
unsigned longflags;
 #define CI13XXX_REGS_SHAREDBIT(0)
 #define CI13XXX_REQUIRE_TRANSCEIVERBIT(1)
-- 
1.7.9.5


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

[PATCH v9 REBASE 6/9] USB: notify phy when root hub port connect change

[Richard Zhao]

Phy may need to change settings when port connect change.

Signed-off-by: Richard Zhao 
Tested-by: Subodh Nijsure 
---
 drivers/usb/core/hub.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 4cc8dc9..2ba9d84 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -4037,6 +4038,13 @@ static void hub_port_connect_change(struct usb_hub *hub, 
int port1,
}
}
 
+   if (unlikely(hcd->phy && !hdev->parent)) {
+   if (portstatus & USB_PORT_STAT_CONNECTION)
+   usb_phy_notify_connect(hcd->phy, port1);
+   else
+   usb_phy_notify_disconnect(hcd->phy, port1);
+   }
+
/* Return now if debouncing failed or nothing is connected or
 * the device was "removed".
 */
-- 
1.7.9.5


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

[PATCH v9 REBASE 8/9] usb: otg: add basic mxs phy driver support

[Richard Zhao]

mxs phy is used in Freescale i.MX SoCs, for example
imx23, imx28, imx6Q. This patch adds the basic host
support.

Signed-off-by: Richard Zhao 
Signed-off-by: Marek Vasut 
Cc: Peter Chen 
Acked-by: Felipe Balbi 
Tested-by: Subodh Nijsure 
---
 Documentation/devicetree/bindings/usb/mxs-phy.txt |   13 ++
 drivers/usb/otg/Kconfig   |   10 ++
 drivers/usb/otg/Makefile  |1 +
 drivers/usb/otg/mxs-phy.c |  186 +
 4 files changed, 210 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mxs-phy.txt
 create mode 100644 drivers/usb/otg/mxs-phy.c

diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt 
b/Documentation/devicetree/bindings/usb/mxs-phy.txt
new file mode 100644
index 000..5835b27
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
@@ -0,0 +1,13 @@
+* Freescale MXS USB Phy Device
+
+Required properties:
+- compatible: Should be "fsl,imx23-usbphy"
+- reg: Should contain registers location and length
+- interrupts: Should contain phy interrupt
+
+Example:
+usbphy1: usbphy@020c9000 {
+   compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
+   reg = <0x020c9000 0x1000>;
+   interrupts = <0 44 0x04>;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..13fd1ddf 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -116,6 +116,16 @@ config FSL_USB2_OTG
help
  Enable this to support Freescale USB OTG transceiver.
 
+config USB_MXS_PHY
+   tristate "Freescale MXS USB PHY support"
+   depends on ARCH_MXC || ARCH_MXS
+   select STMP_DEVICE
+   select USB_OTG_UTILS
+   help
+ Enable this to support the Freescale MXS USB PHY.
+
+ MXS Phy is used by some of the i.MX SoCs, for example imx23/28/6x.
+
 config USB_MV_OTG
tristate "Marvell USB OTG support"
depends on USB_EHCI_MV && USB_MV_UDC && USB_SUSPEND
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..a844b8d 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -20,4 +20,5 @@ obj-$(CONFIG_USB_MSM_OTG) += msm_otg.o
 obj-$(CONFIG_AB8500_USB)   += ab8500-usb.o
 fsl_usb2_otg-objs  := fsl_otg.o otg_fsm.o
 obj-$(CONFIG_FSL_USB2_OTG) += fsl_usb2_otg.o
+obj-$(CONFIG_USB_MXS_PHY)  += mxs-phy.o
 obj-$(CONFIG_USB_MV_OTG)   += mv_otg.o
diff --git a/drivers/usb/otg/mxs-phy.c b/drivers/usb/otg/mxs-phy.c
new file mode 100644
index 000..c1a67cb
--- /dev/null
+++ b/drivers/usb/otg/mxs-phy.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Marek Vasut 
+ * on behalf of DENX Software Engineering GmbH
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "mxs_phy"
+
+#define HW_USBPHY_PWD  0x00
+#define HW_USBPHY_CTRL 0x30
+#define HW_USBPHY_CTRL_SET 0x34
+#define HW_USBPHY_CTRL_CLR 0x38
+
+#define BM_USBPHY_CTRL_SFTRST  BIT(31)
+#define BM_USBPHY_CTRL_CLKGATE BIT(30)
+#define BM_USBPHY_CTRL_ENUTMILEVEL3BIT(15)
+#define BM_USBPHY_CTRL_ENUTMILEVEL2BIT(14)
+#define BM_USBPHY_CTRL_ENHOSTDISCONDETECT  BIT(1)
+
+struct mxs_phy {
+   struct usb_phy phy;
+   struct clk *clk;
+};
+
+#define to_mxs_phy(p) container_of((p), struct mxs_phy, phy)
+
+static void mxs_phy_hw_init(struct mxs_phy *mxs_phy)
+{
+   void __iomem *base = mxs_phy->phy.io_priv;
+
+   stmp_reset_block(base + HW_USBPHY_CTRL);
+
+   /* Power up the PHY */
+   writel_relaxed(0, base + HW_USBPHY_PWD);
+
+   /* enable FS/LS device */
+   writel_relaxed(BM_USBPHY_CTRL_ENUTMILEVEL2 |
+   BM_USBPHY_CTRL_ENUTMILEVEL3,
+   base + HW_USBPHY_CTRL_SET);
+}
+
+static int mxs_phy_init(struct usb_phy *phy)
+{
+   struct mxs_phy *mxs_phy = to_mxs_phy(phy);
+
+   clk_prepare_enable(mxs_phy->clk);
+   mxs_phy_hw_init(mxs_phy);
+
+   return 0;
+}
+
+static void mxs_phy_shutdown(struct usb_phy *phy)
+{
+   struct mxs_phy *mxs_phy = to_mxs_phy(phy);
+
+   writel_relaxed(BM_USBPHY_CTRL_CLKGATE,
+   phy->io_priv + HW_USBPHY_CTRL_SET);
+
+   clk_disable_unprepare(mxs_phy->clk);
+}
+
+static int mxs_phy_on_connect(struct usb_phy *phy, int port)
+{
+   dev_dbg(phy->dev, "Connect on port %d\n", port);
+
+   mxs_phy_hw_init(to_mxs_phy(phy));
+   writel_relaxed(BM_USBPHY_CTRL_ENHOSTDISCONDETECT,
+   phy->io

[PATCH v9 REBASE 9/9] usb: chipidea: add imx platform driver

[Richard Zhao]

This patch supports only the host-mode functionality so far.

Signed-off-by: Richard Zhao 
Signed-off-by: Marek Vasut 
Cc: Peter Chen 
Cc: Alexander Shishkin 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Tested-by: Subodh Nijsure 
---
 .../devicetree/bindings/usb/ci13xxx-imx.txt|   18 ++
 drivers/usb/chipidea/Makefile  |3 +
 drivers/usb/chipidea/ci13xxx_imx.c |  198 
 3 files changed, 219 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
 create mode 100644 drivers/usb/chipidea/ci13xxx_imx.c

diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt 
b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
new file mode 100644
index 000..2c29041
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
@@ -0,0 +1,18 @@
+* Freescale i.MX ci13xxx usb controllers
+
+Required properties:
+- compatible: Should be "fsl,imx27-usb"
+- reg: Should contain registers location and length
+- interrupts: Should contain controller interrupt
+
+Optional properties:
+- fsl,usbphy: phandler of usb phy that connects to the only one port
+- vbus-supply: regulator for vbus
+
+Examples:
+usb@02184000 { /* USB OTG */
+   compatible = "fsl,imx6q-usb", "fsl,imx27-usb";
+   reg = <0x02184000 0x200>;
+   interrupts = <0 43 0x04>;
+   fsl,usbphy = <&usbphy1>;
+};
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index b69900a..5c66d9c 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -14,3 +14,6 @@ ifneq ($(CONFIG_PCI),)
obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx_pci.o
 endif
 
+ifneq ($(CONFIG_OF_DEVICE),)
+   obj-$(CONFIG_USB_CHIPIDEA)  += ci13xxx_imx.o
+endif
diff --git a/drivers/usb/chipidea/ci13xxx_imx.c 
b/drivers/usb/chipidea/ci13xxx_imx.c
new file mode 100644
index 000..ef60d06
--- /dev/null
+++ b/drivers/usb/chipidea/ci13xxx_imx.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright (C) 2012 Marek Vasut 
+ * on behalf of DENX Software Engineering GmbH
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ci.h"
+
+#define pdev_to_phy(pdev) \
+   ((struct usb_phy *)platform_get_drvdata(pdev))
+
+struct ci13xxx_imx_data {
+   struct device_node *phy_np;
+   struct usb_phy *phy;
+   struct platform_device *ci_pdev;
+   struct clk *clk;
+   struct regulator *reg_vbus;
+};
+
+static struct ci13xxx_platform_data ci13xxx_imx_platdata __devinitdata  = {
+   .name   = "ci13xxx_imx",
+   .flags  = CI13XXX_REQUIRE_TRANSCEIVER |
+ CI13XXX_PULLUP_ON_VBUS |
+ CI13XXX_DISABLE_STREAMING,
+   .capoffset  = DEF_CAPOFFSET,
+};
+
+static int __devinit ci13xxx_imx_probe(struct platform_device *pdev)
+{
+   struct ci13xxx_imx_data *data;
+   struct platform_device *plat_ci, *phy_pdev;
+   struct device_node *phy_np;
+   struct resource *res;
+   struct regulator *reg_vbus;
+   int ret;
+
+   data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+   if (!data) {
+   dev_err(&pdev->dev, "Failed to allocate CI13xxx-IMX data!\n");
+   return -ENOMEM;
+   }
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   dev_err(&pdev->dev, "Can't get device resources!\n");
+   return -ENOENT;
+   }
+
+   data->clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(data->clk)) {
+   dev_err(&pdev->dev,
+   "Failed to get clock, err=%ld\n", PTR_ERR(data->clk));
+   return PTR_ERR(data->clk);
+   }
+
+   ret = clk_prepare_enable(data->clk);
+   if (ret) {
+   dev_err(&pdev->dev,
+   "Failed to prepare or enable clock, err=%d\n", ret);
+   return ret;
+   }
+
+   phy_np = of_parse_phandle(pdev->dev.of_node, "fsl,usbphy", 0);
+   if (phy_np) {
+   data->phy_np = phy_np;
+   phy_pdev = of_find_device_by_node(phy_np);
+   if (phy_pdev) {
+   struct usb_phy *phy;
+   phy = pdev_to_phy(phy_pdev);
+   if (phy &&
+   try_module_get(phy_pdev->dev.driver->owner)) {
+   usb_phy_init(phy);
+   data->phy = phy;
+   }
+   }
+   }
+
+   /* we only support host now, so enable vbus 

Re: [PATCH V7 2/9] usb: make usb port a real device

[Lan Tianyu]

On 2012/7/7 2:12, Greg KH wrote:

On Fri, Jul 06, 2012 at 02:13:53PM +0800, Lan Tianyu wrote:

Change since v4: remove struct usb_port->udev member since it is not used.

This patch is to make usb port a real device under usb hub interface.
Move port_owner to struct usb_port.


As this adds sysfs files, this patch needs a Documentation/ABI update as
well.


How about this?

Documentation/ABI/testing/sysfs-bus-usb

What:   /sys/bus/usb/devices/.../(hub interface)/portX
Date:   July 2012
Contact Lan Tianyu 
Description:
The /sys/bus/usb/devices/.../(hub interface)/portX
is usb port device's sysfs direcotry.


Also, one minor nit:


+   dev_err(hub->intfdev, "couldn't create port%d "
+   "device.\n", i + 1);


Don't split strings across a line, it makes it impossible to search
for.


Is this Ok? keep line not more than 80 chars.
dev_err(hub->intfdev,
"couldn't create port%d device.\n", i + 1);


thanks,

greg k-h



--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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 V7 9/9] usb : Add usb port's power control attributes

[Lan Tianyu]

On 2012/7/7 2:14, Greg KH wrote:

On Fri, Jul 06, 2012 at 02:14:00PM +0800, Lan Tianyu wrote:

Change since v5: Add usb_autopm_get/put_interface() around the port
power operations in the control attribute's callback to deal with
situation that control attribute is changed when the usb hub is suspended.

Change since v4: Add clear PORT_POWER if power policy is "off" in the
hub_power_on(). Return -EIO if set/clear PORT_POWER fails in the 
store_port_power_control()

This patch is to add two attributes for each usb hub ports to control port's 
power.
Control port's power through setting or clearing PORT_POWER feature.

control has two options. "auto", "on" and "off"
"on" - port power must be on.
"off" - port power must be off.

state reports usb port's power state
"on" - power on
"off" - power off
"error" - can't get power state

Acked-by: Alan Stern
Signed-off-by: Lan Tianyu
---
  Documentation/ABI/testing/sysfs-bus-usb |   25 ++
  drivers/usb/core/hub.c  |  133 ++-
  2 files changed, 157 insertions(+), 1 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-bus-usb 
b/Documentation/ABI/testing/sysfs-bus-usb
index 6df4e6f..abe4ea4 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -208,3 +208,28 @@ Description:
such as ACPI. This file will read either "removable" or
"fixed" if the information is available, and "unknown"
otherwise.
+
+What:  /sys/bus/usb/devices/.../(hub interface)/portX/control
+Date:  June 2012


It is no longer June 2012  :)


Oh. Sorry. Forgot to modify. Time is too quick. :)
Will update soon.

--
Best Regards
Tianyu Lan
linux kernel enabling team
--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Oleksij Rempel]

On 07.07.2012 15:55, Eric Ding wrote:
> On 07/07/2012 09:11 PM, Oleksij Rempel wrote:
>> On 07.07.2012 13:38, Eric Ding wrote:
>>> On 07/07/2012 06:09 PM, Oleksij Rempel wrote:
 On 07.07.2012 11:20, Eric Ding wrote:
> On 07/06/2012 11:47 PM, Alan Stern wrote:
>> On Fri, 6 Jul 2012, Alan Cox wrote:
>>
 Yes, but we still need to know the reason why.  Neither Rafael nor I 
 has been able to figure out why that commit messed things up.
>>>
>>> Was the driver doing any dynamic autosuspend at all until that point ?

>> I don't know...  but whatever it was doing before the commit, it should 
>> be doing the same thing afterward.
>
> I thought that getting some comparative usbmon logs might help, but I'm
> not equipped to parse them.  To generate these logs, I ran guvcview once
> after plugging in the webcam, then did the following upon quiting
> guvcview: start listening via usbmon, sleep for four seconds, start
> guvcview again and stop listening via usbmon after four seconds.
>
> I did this both at commit e1620d5 (the commit which triggered this
> issue) and once at commit 9975961 (one commit prior).  Going through
> these motions also confirmed that the problem is readily reproducible
> the second time I start guvcview at e1620d5, but not at 9975961.  I've
> attached both logs in case they're helpful.

 In both logs you send the cam start to stream video. Major difference is
 that, after suspend/resume it need more time (about 10 seconds) to start
 stream. Is it correct?
>>>
>>> My tests didn't continue a full 10 seconds after I restarted the webcam,
>>> so I'm not sure I follow your question.  In the second case (with
>>> e1620d5), the camera never returns a "normal" video image -- instead, it
>>> gets a garbled video image of horizontal stripes, which change with what
>>> the camera lens is seeing, but are obviously not the correct image.
>>
>> Ok,  i guess i know your problem but i doubt it will be completely fixed
>> by changing powermanagement behavior. Two logitech cams i tested is
>> really easy to confuse/brake/freeze. Just turn off the stream before it
>> will send first frame. It looks like it take longer to boot buildin
>> controller or image processor. On second (hot) start it take less time.
>> If the cam was suspended it need this boot time again. The problem, even
>> if we do hot start and turn of stream before first frame, like some apps
>> did, the cam will brake again. By disabling auto suspend, we will reduce
>> probability to brake it, but not fix it.
>>
>> Some times i have the splitimage issue too, but i can't 100% reproduce it.
> 
> So does your description of the problem explain why commit e1620d5
> causes this problem to happen 100% of the time on the second start, even
> though I cannot reproduce this problem at all before that commit?

Please note, i said "i guess", i'm not sure if it is same issue. With
3.5.0-rc5-00098-g9e85a6f i can't reproduce this issue at least after
fresh start. After long work some times i get some thing similar to your
description.

> Isn't
> that the mystery that still remains unsolved?  Do the usbmon logs not
> answer that question?

no. Same configuration sequence, same responses. I see only one
difference, on e1620d5 the cam needed longer to start streaming.  This
is know on other cams, but they work.

> Going back also to the patch I submitted, it seems (at least in my
> testing) that USB_QUIRK_RESET_RESUME does work around this issue
> consistently, at least for my webcam.

ok. the problem is, e1620d5 moves existing CONFIG_USB_SUSPEND from one
place to another. uvcvideo used autosuspend before. This is why this
quirk make no sense.

-- 
Regards,
Oleksij


--
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: infos about device ZTE MF821D 2G,3G,4G/LTE usb-modem/networkcard

[Thomas Schäfer]

The modem works at /dev/USB2.

In my point of view "19d2 0326" should/could be added to the option driver.

Thomas
--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Alan Stern]

On Sat, 7 Jul 2012, Oleksij Rempel wrote:

> >> Ok,  i guess i know your problem but i doubt it will be completely fixed
> >> by changing powermanagement behavior. Two logitech cams i tested is
> >> really easy to confuse/brake/freeze. Just turn off the stream before it
> >> will send first frame. It looks like it take longer to boot buildin
> >> controller or image processor. On second (hot) start it take less time.
> >> If the cam was suspended it need this boot time again. The problem, even
> >> if we do hot start and turn of stream before first frame, like some apps
> >> did, the cam will brake again. By disabling auto suspend, we will reduce
> >> probability to brake it, but not fix it.

I don't think that was the problem.  As far as I can tell, the problem 
with these Logitech webcams is that they often fail to resume correctly 
following a suspend.  They require a reset before they will start 
working again.

Apparently the behavior before commit e1620d5 was that the webcam
didn't get suspended, and after the commit it did.  Unfortunately
the usbmon traces do not explain this difference; all they show is
when/whether a suspend took place.

For example, the prelog.9975961.out trace shows that the webcam wasn't 
suspended before the trace began, and the postlog.e1620d5.out trace 
shows that it was (although when the webcam was resumed, it did work 
okay -- this was one of the times it didn't crash during the resume).

> >> Some times i have the splitimage issue too, but i can't 100% reproduce it.
> > 
> > So does your description of the problem explain why commit e1620d5
> > causes this problem to happen 100% of the time on the second start, even
> > though I cannot reproduce this problem at all before that commit?
> 
> Please note, i said "i guess", i'm not sure if it is same issue. With
> 3.5.0-rc5-00098-g9e85a6f i can't reproduce this issue at least after
> fresh start. After long work some times i get some thing similar to your
> description.
> 
> > Isn't
> > that the mystery that still remains unsolved?  Do the usbmon logs not
> > answer that question?
> 
> no. Same configuration sequence, same responses. I see only one
> difference, on e1620d5 the cam needed longer to start streaming.  This
> is know on other cams, but they work.
> 
> > Going back also to the patch I submitted, it seems (at least in my
> > testing) that USB_QUIRK_RESET_RESUME does work around this issue
> > consistently, at least for my webcam.

The quirk tells Linux to reset the webcam whenever it is resumed.

> ok. the problem is, e1620d5 moves existing CONFIG_USB_SUSPEND from one
> place to another. uvcvideo used autosuspend before. This is why this
> quirk make no sense.

Well, the quirk does make sense.  What doesn't make sense is why moving 
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change in the autosuspend behavior.  That's what we 
would like to know.

Eric, are your kernel-hacking skills up to debugging this?  I can tell 
you where to look and what to look for.

Alan Stern

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

Re: [PATCH] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Rafael J. Wysocki]

On Saturday, July 07, 2012, Alan Stern wrote:
> On Sat, 7 Jul 2012, Oleksij Rempel wrote:
> 
> > >> Ok,  i guess i know your problem but i doubt it will be completely fixed
> > >> by changing powermanagement behavior. Two logitech cams i tested is
> > >> really easy to confuse/brake/freeze. Just turn off the stream before it
> > >> will send first frame. It looks like it take longer to boot buildin
> > >> controller or image processor. On second (hot) start it take less time.
> > >> If the cam was suspended it need this boot time again. The problem, even
> > >> if we do hot start and turn of stream before first frame, like some apps
> > >> did, the cam will brake again. By disabling auto suspend, we will reduce
> > >> probability to brake it, but not fix it.
> 
> I don't think that was the problem.  As far as I can tell, the problem 
> with these Logitech webcams is that they often fail to resume correctly 
> following a suspend.  They require a reset before they will start 
> working again.
> 
> Apparently the behavior before commit e1620d5 was that the webcam
> didn't get suspended, and after the commit it did.  Unfortunately
> the usbmon traces do not explain this difference; all they show is
> when/whether a suspend took place.
> 
> For example, the prelog.9975961.out trace shows that the webcam wasn't 
> suspended before the trace began, and the postlog.e1620d5.out trace 
> shows that it was (although when the webcam was resumed, it did work 
> okay -- this was one of the times it didn't crash during the resume).
> 
> > >> Some times i have the splitimage issue too, but i can't 100% reproduce 
> > >> it.
> > > 
> > > So does your description of the problem explain why commit e1620d5
> > > causes this problem to happen 100% of the time on the second start, even
> > > though I cannot reproduce this problem at all before that commit?
> > 
> > Please note, i said "i guess", i'm not sure if it is same issue. With
> > 3.5.0-rc5-00098-g9e85a6f i can't reproduce this issue at least after
> > fresh start. After long work some times i get some thing similar to your
> > description.
> > 
> > > Isn't
> > > that the mystery that still remains unsolved?  Do the usbmon logs not
> > > answer that question?
> > 
> > no. Same configuration sequence, same responses. I see only one
> > difference, on e1620d5 the cam needed longer to start streaming.  This
> > is know on other cams, but they work.
> > 
> > > Going back also to the patch I submitted, it seems (at least in my
> > > testing) that USB_QUIRK_RESET_RESUME does work around this issue
> > > consistently, at least for my webcam.
> 
> The quirk tells Linux to reset the webcam whenever it is resumed.
> 
> > ok. the problem is, e1620d5 moves existing CONFIG_USB_SUSPEND from one
> > place to another. uvcvideo used autosuspend before. This is why this
> > quirk make no sense.
> 
> Well, the quirk does make sense.  What doesn't make sense is why moving 
> the runtime PM operation pointers from usb_bus_type to usb_device_type
> should cause any change in the autosuspend behavior.  That's what we 
> would like to know.

I think the reason was the way rpm_suspend() worked at the time of that
commit (it works a bit differently now, but not as much as to avoid the
problem).

Namely, before commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2 the device
had a device type without runtime PM callbacks.  So, rpm_suspend() saw
that dev->type was set and dev->type->pm was set, so it assigned NULL to
callback.  As a result, nothing happened when rpm_callback(callback, dev)
was run.

After the change, though, the runtime callbacks are present in
usb_device_pm_ops, so the same code assigns the address of
usb_runtime_suspend() to callback and the device is actually suspended
by rpm_callback(callback, dev).

Thanks,
Rafael
--
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: Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

Hi, Alan!

So, after about more than a week of bisecting, and thanks to Jonathan  
Nieder's

more-than-precise instructions, the results are in.

On Mon, 25 Jun 2012 11:41:31 -0700, Alan Stern   
wrote:



On Mon, 25 Jun 2012, Octavio Alvarez wrote:

On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern  


wrote:

> What happens if Octavio disables wakeup for that controller before
> suspending?
>
>echo disabled >/sys/bus/pci/devices/:00:0b.0/power/wakeup

On kernel 3.2, it lets suspend work again.


If you build a kernel with CONFIG_USB_DEBUG enabled, what
shows up in /sys/kernel/debug/usb/ohci/*/registers?


[Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ grep . ohci/*/registers
bus pci, device :00:0b.0
OHCI Host Controller
ohci_hcd
OHCI 1.0, NO legacy support registers, rh state running
control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3
cmdstatus 0x0 SOC=0
intrstatus 0x0024 FNO SF
intrenable 0x804a MIE RHSC RD WDH
ed_controlhead 2edac040
hcca frame 0x5fce
fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
fmremaining 0x80002e53 FRT FR=0x2e53
periodicstart 0x2a2f
lsthresh 0x0628
hub poll timer off
roothub.a 01000208 POTPGT=1 NPS NDP=8(8)
roothub.b  PPCM= DR=
roothub.status 8000 DRWE
roothub.portstatus [0] 0x0100 PPS
roothub.portstatus [1] 0x0100 PPS
roothub.portstatus [2] 0x0100 PPS
roothub.portstatus [3] 0x0100 PPS
roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
roothub.portstatus [6] 0x0101 PPS CCS
roothub.portstatus [7] 0x0100 PPS



And what shows up in /sys/kernel/debug/usb/devices?


[Sat Jul 07 12:49:54 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ cat devices

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12   MxCh= 8
B:  Alloc= 29/900 us ( 3%), #Int=  3, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0001 Rev= 3.03
S:  Manufacturer=Linux 3.3.0+ ohci_hcd
S:  Product=OHCI Host Controller
S:  SerialNumber=:00:0b.0
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#=  2 Spd=1.5  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c05a Rev=54.00
S:  Manufacturer=Logitech
S:  Product=USB Optical Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=02 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   6 Ivl=10ms

T:  Bus=02 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#=  3 Spd=1.5  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=046d ProdID=c31d Rev=66.00
S:  Manufacturer=Logitech
S:  Product=USB Keyboard
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 90mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=01 Prot=01 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=82(I) Atr=03(Int.) MxPS=   4 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480  MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1d6b ProdID=0002 Rev= 3.03
S:  Manufacturer=Linux 3.3.0+ ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=:00:0b.1
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms



Also, what does the "lspci -vv" output show for the controller if you
run it with superuser permissions?


[Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ sudo lspci -vv -s :00:0b.1
00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a2)  
(prog-if 20 [EHCI])

Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-  
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 22
Region 0: Memory at d5007000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA  
PME(D0+,D1+,D2+,D3hot+,D3cold+)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ehci_hcd

I also bisected the "3.2 doesn't sleep due to ohci" problem and found this:

commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
Author: Alan Stern 
Date:   Mon Sep 26 11:23:38 2011 -0400

USB: Update USB default wakeup settings

This patch (as1486) implements the kernel's new wakeup policy for USB
host controllers.  Since they don't generate wakeup requests on their
but merely forward requests from their root hubs toward the CPU, they

Re: [PATCH V7 2/9] usb: make usb port a real device

[Greg KH]

On Sat, Jul 07, 2012 at 11:01:53PM +0800, Lan Tianyu wrote:
> On 2012/7/7 2:12, Greg KH wrote:
> >On Fri, Jul 06, 2012 at 02:13:53PM +0800, Lan Tianyu wrote:
> >>Change since v4: remove struct usb_port->udev member since it is not used.
> >>
> >>This patch is to make usb port a real device under usb hub interface.
> >>Move port_owner to struct usb_port.
> >
> >As this adds sysfs files, this patch needs a Documentation/ABI update as
> >well.
> >
> How about this?
> 
> Documentation/ABI/testing/sysfs-bus-usb
> 
> What:   /sys/bus/usb/devices/.../(hub interface)/portX
> Date:   July 2012
> Contact Lan Tianyu 
> Description:
> The /sys/bus/usb/devices/.../(hub interface)/portX
> is usb port device's sysfs direcotry.

Yes, if this properly describes all the files in that directory.

> >Also, one minor nit:
> >
> >>+   dev_err(hub->intfdev, "couldn't create port%d "
> >>+   "device.\n", i + 1);
> >
> >Don't split strings across a line, it makes it impossible to search
> >for.
> 
> Is this Ok? keep line not more than 80 chars.
>   dev_err(hub->intfdev,
>   "couldn't create port%d device.\n", i + 1);

Yes, that is fine.

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

"usb: dwc3: resume phy during gadget initialization on recent cores" breaks phy suspend

[Paul Zimmerman]

Commit "usb: dwc3: resume phy during gadget initialization on recent
cores" breaks phy suspend on cores newer than 1.94a. The core will
still operate, but the power savings provided by phy suspend are lost.

Pratyush, did you see an actual problem caused by the original code?
If so, then you need to reenable phy suspend at some point after
initialization to restore the correct behavior on newer cores.

-- 
Paul

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

Re: [PATCH 3/4] usbdevfs: Use scatter-gather lists for large bulk transfers

[Greg Kroah-Hartman]

On Sat, Jul 07, 2012 at 09:11:27AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 07/06/2012 07:51 PM, Greg Kroah-Hartman wrote:
> >On Wed, Jul 04, 2012 at 09:18:03AM +0200, Hans de Goede wrote:
> >>+static void snoop_urb_data(struct urb *urb, unsigned len)
> >>+{
> >>+   int i, size;
> >>+
> >>+   if (!usbfs_snoop)
> >>+   return;
> >>+
> >>+   if (urb->num_sgs == 0) {
> >>+   print_hex_dump(KERN_DEBUG, "data: ", DUMP_PREFIX_NONE, 32, 1,
> >>+   urb->transfer_buffer, len, 1);
> >>+   return;
> >>+   }
> >>+
> >>+   for (i = 0; i < urb->num_sgs && len; i++) {
> >>+   size = (len > USB_SG_SIZE) ? USB_SG_SIZE : len;
> >>+   print_hex_dump(KERN_DEBUG, "data: ", DUMP_PREFIX_NONE, 32, 1,
> >>+   sg_virt(&urb->sg[i]), size, 1);
> >>+   len -= size;
> >>+   }
> >>+}
> >
> >Minor cleanup in the future, can't this be merged with snoop_urb() that
> >way you don't have to do the logic checking in the places you call this
> >function instead of snoop_urb()?  That would make it a bit simpler for
> >the "normal" code path, right?
> 
> Alan already made the same remark :) The problem is that snoop_urb is
> also used for logging the synchronous urb ioctls, where there is no urb.
> So making snoop_urb generic would require it gaining a struct urb *
> argument while keeping its unsigned char *data and int data_len
> arguments, and add an if (urb) ... else in there, so this way seems
> better.

Ok, fair enough.  If I get annoyed I'll go see if I can figure out how
to simplify it later, as I think I'm the only one that uses it :)

Actually, I'll probably just move it to use the tracepoint
infrastructure, as that's the proper thing to do in the end.

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 V7 2/9] usb: make usb port a real device

[Sarah Sharp]

On Fri, Jul 06, 2012 at 11:12:32AM -0700, Greg KH wrote:
> On Fri, Jul 06, 2012 at 02:13:53PM +0800, Lan Tianyu wrote:
> > Change since v4: remove struct usb_port->udev member since it is not used.
> > 
> > This patch is to make usb port a real device under usb hub interface.
> > Move port_owner to struct usb_port.
> 
> As this adds sysfs files, this patch needs a Documentation/ABI update as
> well.

So do I also need to update Documentation/ABI for the new ltm_capable
sysfs file?

> Also, one minor nit:
> 
> > +   dev_err(hub->intfdev, "couldn't create port%d "
> > +   "device.\n", i + 1);
> 
> Don't split strings across a line, it makes it impossible to search
> for.

Do you prefer 80 char lines or split strings?  checkpatch.pl throws an
error either way, so pick your poison.

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

Re: [PATCH 3/4] usbdevfs: Use scatter-gather lists for large bulk transfers

[Alan Stern]

On Sat, 7 Jul 2012, Greg Kroah-Hartman wrote:

> > >Minor cleanup in the future, can't this be merged with snoop_urb() that
> > >way you don't have to do the logic checking in the places you call this
> > >function instead of snoop_urb()?  That would make it a bit simpler for
> > >the "normal" code path, right?
> > 
> > Alan already made the same remark :) The problem is that snoop_urb is
> > also used for logging the synchronous urb ioctls, where there is no urb.
> > So making snoop_urb generic would require it gaining a struct urb *
> > argument while keeping its unsigned char *data and int data_len
> > arguments, and add an if (urb) ... else in there, so this way seems
> > better.
> 
> Ok, fair enough.  If I get annoyed I'll go see if I can figure out how
> to simplify it later, as I think I'm the only one that uses it :)
> 
> Actually, I'll probably just move it to use the tracepoint
> infrastructure, as that's the proper thing to do in the end.

Or we can get rid of the usbfs URB snooping entirely and tell people 
to use usbmon instead.  The information isn't exactly the same but it's 
pretty close.

Alan Stern

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

Re: [PATCH] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Alan Stern]

On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:

> > Well, the quirk does make sense.  What doesn't make sense is why moving 
> > the runtime PM operation pointers from usb_bus_type to usb_device_type
> > should cause any change in the autosuspend behavior.  That's what we 
> > would like to know.
> 
> I think the reason was the way rpm_suspend() worked at the time of that
> commit (it works a bit differently now, but not as much as to avoid the
> problem).
> 
> Namely, before commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2 the device
> had a device type without runtime PM callbacks.  So, rpm_suspend() saw
> that dev->type was set and dev->type->pm was set, so it assigned NULL to
> callback.  As a result, nothing happened when rpm_callback(callback, dev)
> was run.

I don't follow.  If that were the reason then no USB device would have 
been runtime-suspended before the e1620d commit.

Are you saying this actually was true for some period of time (such as 
between the commit that added the "callback" variable and the e1620d 
commit)?

Alan Stern

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

Re: Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Alan Stern]

On Sat, 7 Jul 2012, Octavio Alvarez wrote:

> > If you build a kernel with CONFIG_USB_DEBUG enabled, what
> > shows up in /sys/kernel/debug/usb/ohci/*/registers?
> 
> [Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ grep . ohci/*/registers
> bus pci, device :00:0b.0
> OHCI Host Controller
> ohci_hcd
> OHCI 1.0, NO legacy support registers, rh state running
> control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3
> cmdstatus 0x0 SOC=0
> intrstatus 0x0024 FNO SF
> intrenable 0x804a MIE RHSC RD WDH
> ed_controlhead 2edac040
> hcca frame 0x5fce
> fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
> fmremaining 0x80002e53 FRT FR=0x2e53
> periodicstart 0x2a2f
> lsthresh 0x0628
> hub poll timer off
> roothub.a 01000208 POTPGT=1 NPS NDP=8(8)
> roothub.b  PPCM= DR=
> roothub.status 8000 DRWE
> roothub.portstatus [0] 0x0100 PPS
> roothub.portstatus [1] 0x0100 PPS
> roothub.portstatus [2] 0x0100 PPS
> roothub.portstatus [3] 0x0100 PPS
> roothub.portstatus [4] 0x0303 LSDA PPS PES CCS
> roothub.portstatus [5] 0x0303 LSDA PPS PES CCS
> roothub.portstatus [6] 0x0101 PPS CCS
> roothub.portstatus [7] 0x0100 PPS

That's normal, except for the status of port 6 (which actually is port
7, since we normally count ports starting from 1).  The port shows
Current Connect Status, so something is connected to it -- but what?

Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG 
enabled?

> > And what shows up in /sys/kernel/debug/usb/devices?
> 
> [Sat Jul 07 12:49:54 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ cat devices
...

Pretty much normal.

> > Also, what does the "lspci -vv" output show for the controller if you
> > run it with superuser permissions?
> 
> [Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ sudo lspci -vv -s :00:0b.1

0b.1 is the EHCI controller.  We want to see the OHCI controller, 0b.0.

> I also bisected the "3.2 doesn't sleep due to ohci" problem and found this:
> 
> commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
> Author: Alan Stern 
> Date:   Mon Sep 26 11:23:38 2011 -0400
> 
>  USB: Update USB default wakeup settings

Yes, that commit enables wakeup for USB host controllers by default.  
Before that, you had to enable wakeup by hand.  The question is: Why
does the controller think it needs to wake up the system?

Can you also post a dmesg log showing a full suspend/immediate-resume 
cycle with CONFIG_USB_DEBUG enabled?

> > And yet the PC doesn't lock up if you unbind ohci-hcd before
> > suspending?
> 
> It suspends but it locks-up while waking up.
> 
> > Maybe you can do a git bisection to find what changed between 3.2 and
> > 3.4 to cause this behavior.
> 
> commit 2feec47d4c5f80b05f1650f5a24865718978eea4
> Author: Bob Moore 
> Date:   Tue Feb 14 15:00:53 2012 +0800
> 
>  ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl  
> registers
> 
>  Adds sleep and wake support for systems with these registers.
>  One new file, hwxfsleep.c
> 
>  Signed-off-by: Bob Moore 
>  Signed-off-by: Len Brown 

Yes, okay, that is indeed totally separate.  You should bring that 
issue up with Bob Moore and Len Brown on the linux-acpi mailing list.

Alan Stern

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

Re: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Jonathan Nieder]

Hi,

Quick administrivia.

Alan Stern wrote:

> Yes, that commit enables wakeup for USB host controllers by default.  
> Before that, you had to enable wakeup by hand.  The question is: Why
> does the controller think it needs to wake up the system?

Yotam Benshalom from https://bugzilla.kernel.org/show_bug.cgi?id=43081
(cc-ed) is experiencing the same symptoms (Nvidia MCP79 OHCI
controller producing immediate wakeups when he tries to resume,
bisects to a6eeeb9f45b5).

> On Sat, 7 Jul 2012, Octavio Alvarez wrote:

>> commit 2feec47d4c5f80b05f1650f5a24865718978eea4
>> Author: Bob Moore 
>> Date:   Tue Feb 14 15:00:53 2012 +0800
>>
>>  ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl  
>> registers
[...]
> Yes, okay, that is indeed totally separate.  You should bring that 
> issue up with Bob Moore and Len Brown on the linux-acpi mailing list.

The Debian bug for this one is .
Please cc me or 680...@bugs.debian.org if bringing it up with ACPI
folks so we can track the discussion.

Thanks again for your hard work.

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

[PATCH RESEND 2/3] usb: storage: add support for write cache quirk

[Namjae Jeon]

From: Namjae Jeon 

Add support for write cache quirk on usb hdd. scsi driver will be set to wce
by detecting write cache quirk in quirk list when plugging usb hdd.

Signed-off-by: Namjae Jeon 
Signed-off-by: Pankaj Kumar 
Signed-off-by: Amit Sahrawat 
Acked-by: Alan Stern 
---
 Documentation/kernel-parameters.txt |2 ++
 drivers/usb/storage/scsiglue.c  |5 +
 drivers/usb/storage/usb.c   |5 -
 include/linux/usb_usual.h   |4 +++-
 4 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index de8d60c..7e7f3af 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2939,6 +2939,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
initial READ(10) command);
o = CAPACITY_OK (accept the capacity
reported by the device);
+   p = WRITE_CACHE (the device cache is ON
+   by default);
r = IGNORE_RESIDUE (the device reports
bogus residue values);
s = SINGLE_LUN (the device has only one
diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c
index 11418da..a3d5436 100644
--- a/drivers/usb/storage/scsiglue.c
+++ b/drivers/usb/storage/scsiglue.c
@@ -236,6 +236,11 @@ static int slave_configure(struct scsi_device *sdev)
US_FL_SCM_MULT_TARG)) &&
us->protocol == USB_PR_BULK)
us->use_last_sector_hacks = 1;
+
+   /* Check if write cache default on flag is set or not */
+   if (us->fflags & US_FL_WRITE_CACHE)
+   sdev->wce_default_on = 1;
+
} else {
 
/* Non-disk-type devices don't need to blacklist any pages
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index e23c30a..d012fe4 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -473,7 +473,7 @@ static void adjust_quirks(struct us_data *us)
US_FL_CAPACITY_OK | US_FL_IGNORE_RESIDUE |
US_FL_SINGLE_LUN | US_FL_NO_WP_DETECT |
US_FL_NO_READ_DISC_INFO | US_FL_NO_READ_CAPACITY_16 |
-   US_FL_INITIAL_READ10);
+   US_FL_INITIAL_READ10 | US_FL_WRITE_CACHE);
 
p = quirks;
while (*p) {
@@ -529,6 +529,9 @@ static void adjust_quirks(struct us_data *us)
case 'o':
f |= US_FL_CAPACITY_OK;
break;
+   case 'p':
+   f |= US_FL_WRITE_CACHE;
+   break;
case 'r':
f |= US_FL_IGNORE_RESIDUE;
break;
diff --git a/include/linux/usb_usual.h b/include/linux/usb_usual.h
index 17df360..e84e769 100644
--- a/include/linux/usb_usual.h
+++ b/include/linux/usb_usual.h
@@ -64,7 +64,9 @@
US_FLAG(NO_READ_CAPACITY_16,0x0008) \
/* cannot handle READ_CAPACITY_16 */\
US_FLAG(INITIAL_READ10, 0x0010) \
-   /* Initial READ(10) (and others) must be retried */
+   /* Initial READ(10) (and others) must be retried */ \
+   US_FLAG(WRITE_CACHE,0x0020) \
+   /* Write Cache status is not available */
 
 #define US_FLAG(name, value)   US_FL_##name = value ,
 enum { US_DO_ALL_FLAGS };
-- 
1.7.9.5

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

[PATCH RESEND 1/3] scsi: set to WCE if usb cache quirk is present.

[Namjae Jeon]

From: Namjae Jeon 

Make use of USB quirk method to identify such HDD while reading
the cache status in sd_probe(). If cache quirk is present for
the HDD, lets assume that cache is enabled and make WCE bit
equal to 1.

Signed-off-by: Namjae Jeon 
Signed-off-by: Pankaj Kumar 
Signed-off-by: Amit Sahrawat 
---
 drivers/scsi/sd.c  |9 +++--
 include/scsi/scsi_device.h |1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 6f72b80..4225064 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2261,8 +2261,13 @@ bad_sense:
sd_printk(KERN_ERR, sdkp, "Asking for cache data failed\n");
 
 defaults:
-   sd_printk(KERN_ERR, sdkp, "Assuming drive cache: write through\n");
-   sdkp->WCE = 0;
+   if (sdp->wce_default_on) {
+   sd_printk(KERN_NOTICE, sdkp, "Assuming drive cache: write 
back\n");
+   sdkp->WCE = 1;
+   } else {
+   sd_printk(KERN_ERR, sdkp, "Assuming drive cache: write 
through\n");
+   sdkp->WCE = 0;
+   }
sdkp->RCD = 0;
sdkp->DPOFUA = 0;
 }
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index b6cf0cf..61ff671 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -156,6 +156,7 @@ struct scsi_device {
unsigned is_visible:1;  /* is the device visible in sysfs */
unsigned can_power_off:1; /* Device supports runtime power off */
unsigned wakeup_by_user:1;  /* user wakes up the ODD */
+   unsigned wce_default_on:1; /* Cache is ON by default */
 
DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events 
*/
struct list_head event_list;/* asserted events */
-- 
1.7.9.5

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

[PATCH RESEND 0/3] scsi: fix internal write cache issue on usb hdd.

[Namjae Jeon]

From: Namjae Jeon 

The numbers of USB HDDs(All USB HDD I checked) does not respond
correctly to scsi mode sense command for retrieving the write cache
page status. Even though write cache is enabled by default, due to
scsi driver assume that cache is not enabled which in turn might lead
to loss of data since data still will be in cache.
This result that all filesystems is not stable on USB HDD when the
device is unplugged abruptly, even though these are having journaling
feature. Our first trying is that scsi driver send ATA command
(ATA Pass through, #85) to USB HDD after failure from normal routine to
know write cache enable.
We have known it is dangerous after testing several USB HDD. some of
HDD is stalled by this command(A-DATA HDD). So we tried to make the
patch James Bottomley's suggestion(usb quirk) on version 2 that add
product ID and verdor ID of USB HDD to USB quirk list after checking
write cache.
All filesystem will be stable on USB HDD registered in quirk list.
And it will be updated continuously.

Namjae Jeon (3):
scsi: set to WCE if usb cache quirk is present.
usb: storage: add support for write cache quirk.
usb: storage: update usb devices for write cache quirk in quirk.

 drivers/scsi/sd.c  |9 +++--
 include/scsi/scsi_device.h |1 +
 drivers/usb/storage/scsiglue.c |5 +
 drivers/usb/storage/usb.c  |5 -
 include/linux/usb_usual.h  |4 +++-
 drivers/usb/storage/unusual_devs.h |   24 
 Documentation/kernel-parameters.txt |2 ++
 7 files changed, 46 insertions(+), 4 deletions(-)
-- 
1.7.9.5

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

[PATCH RESEND 3/3] usb: storage: update usb devices for write cache quirk in quirk list.

[Namjae Jeon]

From: Namjae Jeon 

Update information of Seagate Portable HDD and WD My Passport HDD in
quirk list.

Signed-off-by: Namjae Jeon 
Signed-off-by: Pankaj Kumar 
Signed-off-by: Amit Sahrawat 
Acked-by: Alan Stern 
---
 drivers/usb/storage/unusual_devs.h |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/usb/storage/unusual_devs.h 
b/drivers/usb/storage/unusual_devs.h
index 1719886..62a31be 100644
--- a/drivers/usb/storage/unusual_devs.h
+++ b/drivers/usb/storage/unusual_devs.h
@@ -1267,6 +1267,12 @@ UNUSUAL_DEV( 0x0af0, 0xd357, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
0 ),
 
+/* Reported by Namjae Jeon  */
+UNUSUAL_DEV(0x0bc2, 0x2300, 0x, 0x,
+   "Seagate",
+   "Portable HDD",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_WRITE_CACHE),
+
 /* Reported by Ben Efros  */
 UNUSUAL_DEV( 0x0bc2, 0x3010, 0x, 0x,
"Seagate",
@@ -1468,6 +1474,12 @@ UNUSUAL_DEV(  0x1058, 0x0704, 0x, 0x,
USB_SC_DEVICE, USB_PR_DEVICE, NULL,
US_FL_SANE_SENSE),
 
+/* Reported by Namjae Jeon  */
+UNUSUAL_DEV(0x1058, 0x070a, 0x, 0x,
+   "Western Digital",
+   "My Passport HDD",
+   USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_WRITE_CACHE),
+
 /* Reported by Fabio Venturi 
  * The device reports a vendor-specific bDeviceClass.
  */
-- 
1.7.9.5

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

Re: Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51

[Octavio Alvarez]

On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern   
wrote:



> Also, what does the "lspci -vv" output show for the controller if you
> run it with superuser permissions?

[Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
$ sudo lspci -vv -s :00:0b.1


0b.1 is the EHCI controller.  We want to see the OHCI controller, 0b.0.


Sorry about that.

[Sat Jul 07 20:41:28 -0700 -- alvarezp@octavio:~]
$ sudo lspci -vv -s :00:0b.0
00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev a2)  
(prog-if 10 [OHCI])

Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-  
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 20
Region 0: Memory at d5006000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA  
PME(D0+,D1+,D2+,D3hot+,D3cold+)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ohci_hcd


I also bisected the "3.2 doesn't sleep due to ohci" problem and found  
this:


commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
Author: Alan Stern 
Date:   Mon Sep 26 11:23:38 2011 -0400

 USB: Update USB default wakeup settings


Yes, that commit enables wakeup for USB host controllers by default.
Before that, you had to enable wakeup by hand.  The question is: Why
does the controller think it needs to wake up the system?

Can you also post a dmesg log showing a full suspend/immediate-resume
cycle with CONFIG_USB_DEBUG enabled?


Will do as soon as I reboot into a suitable kernel.

Thanks for your help.

--
Octavio.
--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Eric Ding]

On 07/08/2012 09:52 AM, Alan Stern wrote:
> On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:
> 
>>> Well, the quirk does make sense.  What doesn't make sense is why moving 
>>> the runtime PM operation pointers from usb_bus_type to usb_device_type
>>> should cause any change in the autosuspend behavior.  That's what we 
>>> would like to know.
>>
>> I think the reason was the way rpm_suspend() worked at the time of that
>> commit (it works a bit differently now, but not as much as to avoid the
>> problem).
>>
>> Namely, before commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2 the device
>> had a device type without runtime PM callbacks.  So, rpm_suspend() saw
>> that dev->type was set and dev->type->pm was set, so it assigned NULL to
>> callback.  As a result, nothing happened when rpm_callback(callback, dev)
>> was run.
> 
> I don't follow.  If that were the reason then no USB device would have 
> been runtime-suspended before the e1620d commit.
> 
> Are you saying this actually was true for some period of time (such as 
> between the commit that added the "callback" variable and the e1620d 
> commit)?

I think this is, in fact, what happened.  See rpm_suspend() before and
after commit 9659cc0; I suspect that between commit 9659cc0 and commit
e1620d5, no USB device was being runtime-suspended.  Since this was
after v2.6.38 and before v2.6.39-rc1, though, it wouldn't have been
widely seen or tested, right?

However, that doesn't fully explain why the webcam wouldn't have been
autosuspended in v2.6.38 -- perhaps you all can guess at this more
quickly than I can?  Was enough changed in the runtime PM architecture
from v2.6.38 to e1620d to explain this difference?

Eric
--
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] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Eric Ding]

On 07/08/2012 03:18 AM, Alan Stern wrote:

> Apparently the behavior before commit e1620d5 was that the webcam
> didn't get suspended, and after the commit it did.  Unfortunately
> the usbmon traces do not explain this difference; all they show is
> when/whether a suspend took place.
> 
> For example, the prelog.9975961.out trace shows that the webcam wasn't 
> suspended before the trace began, and the postlog.e1620d5.out trace 
> shows that it was (although when the webcam was resumed, it did work 
> okay -- this was one of the times it didn't crash during the resume).

Let me clarify: the webcam did *not* work okay during the session
represented by postlog.e1620d5.out; it turned back on, but only returned
a garbled video image.  So even here, it really needs the reset-resume
quirk.

> Eric, are your kernel-hacking skills up to debugging this?  I can tell 
> you where to look and what to look for.

I'm not a kernel hacker -- almost all my development/coding experience
is at the application/UI level.  But I can read and modify C, and I can
compile a kernel.  :-)  So if you don't mind a little hand-holding, I am
happy to help however I can.

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

[PATCH v2 1/1] Input: xpad - Handle all variations of Mad Catz Beat Pad

[Yuri Khan]

* Add a quirk to usbhid to ignore this device
---
 drivers/hid/hid-ids.h   |3 +++
 drivers/hid/usbhid/hid-quirks.c |2 ++
 drivers/input/joystick/xpad.c   |1 +
 3 files changed, 6 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d1cdd2d..43c3d75 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -518,6 +518,9 @@
 #define USB_DEVICE_ID_CRYSTALTOUCH 0x0006
 #define USB_DEVICE_ID_CRYSTALTOUCH_DUAL0x0007
 
+#define USB_VENDOR_ID_MADCATZ  0x0738
+#define USB_DEVICE_ID_MADCATZ_BEATPAD  0x4540
+
 #define USB_VENDOR_ID_MCC  0x09db
 #define USB_DEVICE_ID_MCC_PMD1024LS0x0076
 #define USB_DEVICE_ID_MCC_PMD1208LS0x007a
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 0597ee6..8726d33 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -45,6 +45,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD, 
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD 
},
 
+   { USB_VENDOR_ID_MADCATZ, USB_DEVICE_ID_MADCATZ_BEATPAD, 
HID_QUIRK_IGNORE },
+
{ USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, 
HID_QUIRK_FULLSPEED_INTERVAL },
 
{ USB_VENDOR_ID_EMS, USB_DEVICE_ID_EMS_TRIO_LINKER_PLUS_II, 
HID_QUIRK_MULTI_INPUT },
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index ee16fb6..16974ef 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -238,6 +238,7 @@ static struct usb_device_id xpad_table [] = {
XPAD_XBOX360_VENDOR(0x045e),/* Microsoft X-Box 360 
controllers */
XPAD_XBOX360_VENDOR(0x046d),/* Logitech X-Box 360 style 
controllers */
XPAD_XBOX360_VENDOR(0x0738),/* Mad Catz X-Box 360 
controllers */
+   { USB_DEVICE(0x0738, 0x4540) }, /* Mad Catz Beat Pad */
XPAD_XBOX360_VENDOR(0x0e6f),/* 0x0e6f X-Box 360 controllers 
*/
XPAD_XBOX360_VENDOR(0x12ab),/* X-Box 360 dance pads */
XPAD_XBOX360_VENDOR(0x1430),/* RedOctane X-Box 360 
controllers */
-- 
1.7.9.5

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

Re: [PATCH] From 2.6.39-rc1 onward, the Logitech Quickcam Fusion webcam (046d:08c1) stops

[Oleksij Rempel (fishor)]

On 08.07.2012 07:37, Eric Ding wrote:

On 07/08/2012 09:52 AM, Alan Stern wrote:

On Sat, 7 Jul 2012, Rafael J. Wysocki wrote:


Well, the quirk does make sense.  What doesn't make sense is why moving
the runtime PM operation pointers from usb_bus_type to usb_device_type
should cause any change in the autosuspend behavior.  That's what we
would like to know.


I think the reason was the way rpm_suspend() worked at the time of that
commit (it works a bit differently now, but not as much as to avoid the
problem).

Namely, before commit e1620d591a75a10b15cf61dbf8243a0b7e6731a2 the device
had a device type without runtime PM callbacks.  So, rpm_suspend() saw
that dev->type was set and dev->type->pm was set, so it assigned NULL to
callback.  As a result, nothing happened when rpm_callback(callback, dev)
was run.


I don't follow.  If that were the reason then no USB device would have
been runtime-suspended before the e1620d commit.

Are you saying this actually was true for some period of time (such as
between the commit that added the "callback" variable and the e1620d
commit)?


I think this is, in fact, what happened.  See rpm_suspend() before and
after commit 9659cc0; I suspect that between commit 9659cc0 and commit
e1620d5, no USB device was being runtime-suspended.  Since this was
after v2.6.38 and before v2.6.39-rc1, though, it wouldn't have been
widely seen or tested, right?

However, that doesn't fully explain why the webcam wouldn't have been
autosuspended in v2.6.38 -- perhaps you all can guess at this more
quickly than I can?  Was enough changed in the runtime PM architecture
from v2.6.38 to e1620d to explain this difference?

Eric



Hi, can you please do one more test.
Try to reproduce it with MJPEG stream. Use this command:
luvcview -f jpg -C

it will force jpeg (i think your cam support it) and store each frame 
separately. If you can reproduce it, please send me one of this frames.

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