RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data

[Subbaraya Sundeep Bhatta]

Hi Nathan and Peter,

Is this patch applied? Please let me know I have some other patches to send on 
top of this.

Thanks,
Sundeep

> -Original Message-
> From: Subbaraya Sundeep Bhatta
> Sent: Tuesday, September 01, 2015 12:22 PM
> To: 'Peter Chen'; Punnaiah Choudary Kalluri
> Cc: Nathan Sullivan; sundeep subbaraya; robh...@kernel.org;
> pawel.m...@arm.com; Mark Rutland; ijc+devicet...@hellion.org.uk; Kumar
> Gala; Greg Kroah-Hartman; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
> 
> Hi,
> 
> > -Original Message-
> > From: Peter Chen [mailto:peter.c...@freescale.com]
> > Sent: Monday, August 31, 2015 7:59 AM
> > To: Punnaiah Choudary Kalluri
> > Cc: Nathan Sullivan; sundeep subbaraya; Subbaraya Sundeep Bhatta;
> > robh...@kernel.org; pawel.m...@arm.com; Mark Rutland;
> > ijc+devicet...@hellion.org.uk; Kumar Gala; Greg Kroah-Hartman;
> > devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> > u...@vger.kernel.org
> > Subject: Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
> >
> > On Mon, Aug 31, 2015 at 09:01:51AM +0530, punnaiah choudary kalluri
> > wrote:
> > > On Mon, Aug 31, 2015 at 6:10 AM, Peter Chen
> >  wrote:
> > > > On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote:
> > > >> On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote:
> > > >> > On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote:
> > > >> > > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary
> > kalluri wrote:
> > > >> > > > Hi,
> > > >> > > >
> > > >> > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen
> >  wrote:
> > > >> > > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep
> > subbaraya wrote:
> > > >> > > > >> Hi,
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan
> >  wrote:
> > > >> > > > >> > The Xilinx Zynq udc does not need the
> > > >> > > > >> > CI_HDRC_DISABLE_STREAMING flag, unlike the default
> > > >> > > > >> > platform data.  Add platform data specific to the Zynq udc.
> > > >> > > > >> >
> > > >> > > > >> > Based on a patch by the same name from the Xilinx
> > > >> > > > >> > vendor
> > tree.
> > > >> > > > >>
> > > >> > > > >> I am that Xilinx guy who sent this patch :). It is in
> > > >> > > > >> Xilinx tree as temporary fix and I did not debug further
> > > >> > > > >> why UDC works only when streaming is enabled.
> > > >> > > > >> Probably this is right time to post my question here.
> > > >> > > > >> I was expecting like:
> > > >> > > > >> Streaming disabled - both low bandwidth and high
> > > >> > > > >> bandwidth systems should work fine Streaming enabled -
> > > >> > > > >> only for high bandwidth systems but this is not the
> > > >> > > > >> case, Zynq UDC works only when Streaming is enabled.
> > > >> > > > >> Please correct me if I am wrong.
> > > >> > > > >
> > > >> > > > > You are right, stream mode disabled should work at anytime.
> > > >> > > > > It is so strange why zynq UDC only works when stream mode
> > > >> > > > > is
> > enabled.
> > > >> > > >
> > > >> > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS
> > > >> > > > controllervDoc 2.20a,  this is what it says about SDIS
> > > >> > > > (streaming mode disable option)
> > > >> > > >
> > > >> > > > Before activating this mode, the user must check if the TX
> > > >> > > > latency buffers per endpoint are able to accommodate at
> > > >> > > > least one entire maximum size packet. The RX buffer size
> > > >> > > > must, at least, double the TX buffer size per endpoint. To
> > > >> > > > optimize the stream disable performance, system bus burst
> > > >> > > > must be set as high as possible.
> > > >> > > > When the stream disable mode is used, the burst size
> > > >> > > > (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a
> > integer
> > > >> > > > sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH
> > > >> > > > for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If
> > > >> > > > this is not respected the controller will not work properly
> > > >> > > > in stream disable mode.
> > > >> > > > The stream disable mode should just be used in situations
> > > >> > > > where the available system bandwidth is low or the system
> > > >> > > > bus access latency is high, in order to avoid underruns and
> > > >> > > > overruns in the latency buffers. This works for all types
> > > >> > > > of endpoints, except for ISO endpoints.
> > > >> > > > Such a system can't ensure the real time support that the
> > > >> > > > ISO endpoints require, so the ISO endpoints are not
> > > >> > > > supported when the SDIS bit is set.
> > > >> > > >
> > > >> > > > Definitely we need to root cause why disable streaming mode
> > > >> > > > is not working for zynq but from controller spec point of
> > > >> > > > view it is possible that controller not work properly in
> > > >> > > > stream disable mode.
> > > >>

RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data

[Subbaraya Sundeep Bhatta]

Please ignore got the answer.

> -Original Message-
> From: Subbaraya Sundeep Bhatta
> Sent: Wednesday, September 23, 2015 12:29 PM
> To: 'Peter Chen'; Punnaiah Choudary Kalluri
> Cc: 'Nathan Sullivan'; 'sundeep subbaraya'; 'robh...@kernel.org';
> 'pawel.m...@arm.com'; 'Mark Rutland'; 'ijc+devicet...@hellion.org.uk'; 'Kumar
> Gala'; 'Greg Kroah-Hartman'; 'devicet...@vger.kernel.org'; 'linux-
> ker...@vger.kernel.org'; 'linux-usb@vger.kernel.org'
> Subject: RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
> 
> Hi Nathan and Peter,
> 
> Is this patch applied? Please let me know I have some other patches to send on
> top of this.
> 
> Thanks,
> Sundeep
> 
> > -Original Message-
> > From: Subbaraya Sundeep Bhatta
> > Sent: Tuesday, September 01, 2015 12:22 PM
> > To: 'Peter Chen'; Punnaiah Choudary Kalluri
> > Cc: Nathan Sullivan; sundeep subbaraya; robh...@kernel.org;
> > pawel.m...@arm.com; Mark Rutland; ijc+devicet...@hellion.org.uk; Kumar
> > Gala; Greg Kroah-Hartman; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; linux-usb@vger.kernel.org
> > Subject: RE: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
> >
> > Hi,
> >
> > > -Original Message-
> > > From: Peter Chen [mailto:peter.c...@freescale.com]
> > > Sent: Monday, August 31, 2015 7:59 AM
> > > To: Punnaiah Choudary Kalluri
> > > Cc: Nathan Sullivan; sundeep subbaraya; Subbaraya Sundeep Bhatta;
> > > robh...@kernel.org; pawel.m...@arm.com; Mark Rutland;
> > > ijc+devicet...@hellion.org.uk; Kumar Gala; Greg Kroah-Hartman;
> > > devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> > > u...@vger.kernel.org
> > > Subject: Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform
> > > data
> > >
> > > On Mon, Aug 31, 2015 at 09:01:51AM +0530, punnaiah choudary kalluri
> > > wrote:
> > > > On Mon, Aug 31, 2015 at 6:10 AM, Peter Chen
> > >  wrote:
> > > > > On Fri, Aug 28, 2015 at 09:42:56AM -0500, Nathan Sullivan wrote:
> > > > >> On Fri, Aug 28, 2015 at 09:30:12AM +0800, Peter Chen wrote:
> > > > >> > On Thu, Aug 27, 2015 at 09:33:07AM -0500, Nathan Sullivan wrote:
> > > > >> > > On Thu, Aug 27, 2015 at 01:11:30PM +0530, punnaiah choudary
> > > kalluri wrote:
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > On Thu, Aug 27, 2015 at 10:03 AM, Peter Chen
> > >  wrote:
> > > > >> > > > > On Thu, Aug 27, 2015 at 10:59:22AM +0530, sundeep
> > > subbaraya wrote:
> > > > >> > > > >> Hi,
> > > > >> > > > >>
> > > > >> > > > >>
> > > > >> > > > >> On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan
> > >  wrote:
> > > > >> > > > >> > The Xilinx Zynq udc does not need the
> > > > >> > > > >> > CI_HDRC_DISABLE_STREAMING flag, unlike the default
> > > > >> > > > >> > platform data.  Add platform data specific to the Zynq 
> > > > >> > > > >> > udc.
> > > > >> > > > >> >
> > > > >> > > > >> > Based on a patch by the same name from the Xilinx
> > > > >> > > > >> > vendor
> > > tree.
> > > > >> > > > >>
> > > > >> > > > >> I am that Xilinx guy who sent this patch :). It is in
> > > > >> > > > >> Xilinx tree as temporary fix and I did not debug
> > > > >> > > > >> further why UDC works only when streaming is enabled.
> > > > >> > > > >> Probably this is right time to post my question here.
> > > > >> > > > >> I was expecting like:
> > > > >> > > > >> Streaming disabled - both low bandwidth and high
> > > > >> > > > >> bandwidth systems should work fine Streaming enabled -
> > > > >> > > > >> only for high bandwidth systems but this is not the
> > > > >> > > > >> case, Zynq UDC works only when Streaming is enabled.
> > > > >> > > > >> Please correct me if I am wrong.
> > > > >> > > > >
> > > > >> > > > > You are right, stream mode disabled should work at anytime.
> > > > >> > > > > It is so strange why zynq UDC only works when stream
> > > > >> > > > > mode is
> > > enabled.
> > > > >> > > >
> > > > >> > > > I am referring the section 8.5.2 in Synopsys usb 2.0 HS
> > > > >> > > > controllervDoc 2.20a,  this is what it says about SDIS
> > > > >> > > > (streaming mode disable option)
> > > > >> > > >
> > > > >> > > > Before activating this mode, the user must check if the
> > > > >> > > > TX latency buffers per endpoint are able to accommodate
> > > > >> > > > at least one entire maximum size packet. The RX buffer
> > > > >> > > > size must, at least, double the TX buffer size per
> > > > >> > > > endpoint. To optimize the stream disable performance,
> > > > >> > > > system bus burst must be set as high as possible.
> > > > >> > > > When the stream disable mode is used, the burst size
> > > > >> > > > (VUSB_HS_RX_BURST and VUSB_HS_TX_BURST) must be a
> > > integer
> > > > >> > > > sub-multiple of the latency buffer size (VUSB_HS_RX_DEPTH
> > > > >> > > > for RX buffer and VUSB_HS_TX_CHAN for the TX buffer). If
> > > > >> > > > this is not respected the controller will not work
> > > > >> > > > properly in stream disable mode.
> > > > >> > > > The stream disable mode should just be used in situations
>

Re: [PATCH 3/3] usb: gadget: f_midi: free request when usb_ep_queue fails

[Peter Chen]

On Tue, Sep 22, 2015 at 07:59:10PM +0100, Felipe F. Tonello wrote:
> This fix a memory leak that will occur in this case.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index e92aff5..e6a114b 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -550,9 +550,11 @@ static void f_midi_transmit(struct f_midi *midi, struct 
> usb_request *req)
>   int err;
>  
>   err = usb_ep_queue(ep, req, GFP_ATOMIC);
> - if (err < 0)
> + if (err < 0) {
>   ERROR(midi, "%s queue req: %d\n",
> midi->in_ep->name, err);
> + free_ep_req(ep, req);
> + }
>   } else {
>   free_ep_req(ep, req);
>   }
> -- 
> 2.1.4
> 

I may know your problem, current midi library, alsa and this driver
allow device sends as much data as possible, but without block the
sending until host reads data, it only allocates the request buffer
(using midi_alloc_ep_req), but without free, so after you send
enough data, it is out of memory.

-- 

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

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

[Scott Branden]

Hi John,

Could you please review the v3 Patch.  I believe we have address all of 
your comments?


On 15-09-10 06:13 PM, Scott Branden wrote:

This patch contains a fix for a real world interop problem found
when using the Synopsis DWC2 USB controller with isochronous audio as
detailed in the commit message.

Changes from v2:
  - created s2c_hsotg_chage_ep_iso_parity function to call function in 3 places 
in code
  - used hsotg->num_of_eps instead of MAX_EPS_CHANNELS

Changes from v1:
  - Address code review comments as per previous responses:
  - renamed parity_set to has_correct_parity and reorder some logic


Roman Bacik (1):
   usb: dwc2: gadget: parity fix in isochronous mode

  drivers/usb/dwc2/core.h   |  1 +
  drivers/usb/dwc2/gadget.c | 58 ++-
  drivers/usb/dwc2/hw.h |  1 +
  3 files changed, 54 insertions(+), 6 deletions(-)



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

RE: [PATCH v2 14/32] usb: dwc2: host: wait 3ms for controller stabilization

[Kaukab, Yousaf]

> -Original Message-
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> Sent: Tuesday, September 22, 2015 9:42 PM
> To: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com;
> john.y...@synopsys.com; Herrero, Gregory
> Cc: he...@sntech.de; diand...@chromium.org; r.bald...@samsung.com;
> dingu...@opensource.altera.com; zhangfei@linaro.org;
> david.a.co...@linux.intel.com
> Subject: Re: [PATCH v2 14/32] usb: dwc2: host: wait 3ms for controller
> stabilization
> 
> On 09/22/2015 04:16 PM, Mian Yousaf Kaukab wrote:
> 
> > From: Gregory Herrero 
> >
> > Some high speed mass storage devices fail to enumerate with following
> > error:
> >
> > Cannot enable port %i.  Maybe the USB cable is bad?
> >
> > This happens only when the device is plugged while the controller is
> > in hibernation state. After exiting hibernation, the controller
> > detects the device as a low speed device and fail to enumerate it.
> >
> > Problem occurs only if HPRT0.PWR bit is programmed in a too short
> > delay after exiting hibernation. Dumping hprt register in
> > _dwc2_hcd_resume() directly after dwc2_exit_hibernation() shows that
> > HPRT0.LNSTS (D+/D- level) becomes valid approximately 2ms after
> > exiting hibernation.
> 
> > Since dwc2_exit_hibernation() is called from atomic context, move the
> > delay out of this function.
> 
> Hm, I don't see Gregory moving anything in this patch...
> 
Perhaps keep is more appropriate word. I'll replace move with keep if
I end up doing another revision of this series.

BR,
Yousaf

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

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

[John Youn]

On 9/23/2015 12:36 AM, Scott Branden wrote:
> Hi John,
> 
> Could you please review the v3 Patch.  I believe we have address all of 
> your comments?
> 

Yes I've been meaning to test it on our platforms. I should be
able to get to it tomorrow.

Regards,
John

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

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

[John Youn]

On 9/23/2015 1:11 AM, John Youn wrote:
> On 9/23/2015 12:36 AM, Scott Branden wrote:
>> Hi John,
>>
>> Could you please review the v3 Patch.  I believe we have address all of 
>> your comments?
>>
> 
> Yes I've been meaning to test it on our platforms. I should be
> able to get to it tomorrow.
> 

Also if you could rebase off of Felipe's testing/next branch it
would make it easier when it comes time to merge it in.

Regards,
John

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

Re: request to add information for USB 3G dongle

[Bjørn Mork]

Rolf Leggewie  writes:

> Hello,
>
> I found the following in my syslog.
>
> Aug  2 22:16:01 localhost usb_modeswitch[7313]: usb_modeswitch: switched
> to 19d2:0063 on 2/18
> Aug  2 22:16:02 localhost usb_modeswitch[7313]: usb_modeswitch: add
> device ID 19d2:0063 to driver option
> Aug  2 22:16:02 localhost usb_modeswitch[7313]: usb_modeswitch: please
> report the device ID to the Linux USB developers!
>
> This is a fairly old Vodafone-branded ZTE 3G dongle.  Feel free to ask
> me more information, I'll be happy to provide.  For what it's worth, the
> dongle seems to work just fine.
>
> $ lsusb -d 19d2:0063
> Bus 002 Device 018: ID 19d2:0063 ZTE WCDMA Technologies MSM K3565-Z HSDPA

That's odd.  Wonder why usb_modeswitch believes this is necessary?

That device ID was added to the option driver with commit c420befde6b2
("USB: option: add ZTE device ids and remove ONDA ids") in Linux v2.6.32.


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

Re: First kernel patch (optimization)

[Alexander Holler]

Am 20.09.2015 um 12:41 schrieb Alexander Holler:

Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:



As far as what you want to do next, you have a personal "proof of
concept" patch that seems to work well enough for you.  Great!  I'm
sure you can keep using it for your own purposes.  If you can convince
someone with the skills to get the patch to an upstreamable state, it
is my judgement that this is doable, so this puts your feature in a
much better state than the FALLOC_FL_NO_HIDE_STALE flag.  However,
there is still a non-trivial amount of work left to do to turn your
"proof of concept" patch into something that is upstremable, including
changing the interface to using the FS_SECRM_FL flag.  And your
whining that other people should change *their* priorities to match
*yours* is not likely to help.


Besides that I have absolutely no knowledge about
FALLOC_FL_NO_HIDE_STALE or the FS_SECRM_FL flag, I've never whined. I've
complained about the tone very often used on this list. And it doesn't


Just to explain why I'm still quiet happy with my very simple approach 
to use a simple modified discard mechanism to wipe files:


My main use case (an that of several other people I know) is to have a 
simple way to wipe photos on sd-cards or to wipe other files I've copied 
once onto (vfat-formatted) usb-sticks while never having modified these 
files afterwards.


And that works like a charm and doesn't need complicated patches which 
might be very different for every filesystem.


And the check (and returning an error) if a file is already in use when 
trying to wipe it, makes it unnecessary to introduce something more 
complicated to schedule wiping. I also don't care if something is left 
in swap or similiar. So instead of trying to perfectly solve a big 
problem (which already was unsuccessful tried in case of the Linux 
kernel), I've just reduced the problem to fit the main use cases most 
people have and solved that with a very simple, but working approach.


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

signals causing errors in stable tree in XHCI driver

[Oliver Neukum]

Hi,

I looked at xhci_configure_endpoint() in the stable tree.
There is a serious bug:

/* Wait for the configure endpoint command to complete */
timeleft = wait_for_completion_interruptible_timeout(

^ -ERESTARTSYS in the signal case

cmd_completion,
XHCI_CMD_DEFAULT_TIMEOUT);
if (timeleft <= 0) {
xhci_warn(xhci, "%s while waiting for %s command\n",
timeleft == 0 ? "Timeout" : "Signal",
ctx_change == 0 ?
"configure endpoint" :
"evaluate context");
/* cancel the configure endpoint command */
ret = xhci_cancel_cmd(xhci, command, cmd_trb);
if (ret < 0)
return ret;
return -ETIME;

^ -ERESTARTSYS is swallowed
 
}

A simple ill-timed signal can cause a timeout to be reported.

This issue is fixed in upstream with
c311e391a7efd101250c0e123286709b7e736249
That change and its dependencies are really no stable material.
So how about a fix along the lines of:

/* Wait for the configure endpoint command to complete */
-   timeleft = wait_for_completion_interruptible_timeout(
+   timeleft = wait_for_completion_timeout(

I have a patch ready to submit.

Regards
Oliver


--
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] media: uvcvideo: handle urb completion in a tasklet

[Mian Yousaf Kaukab]

urb completion callback is executed in either host controllers
interrupt context or a tasklet (if hcd has set HCD_BH flag).

If hcd is calling urb->complete from interrupt context, to keep
preempt disable time short, add urbs to a list on completion and
schedule a tasklet to process the list.

Moreover, save timestamp and sof number in the urb completion callback
to avoid any delays.

Signed-off-by: Mian Yousaf Kaukab 
---
[Rename from media: uvcvideo: handle urb completion in a work queue]

History:
v2:
 - Change to use tasklet instead of workqueue
 - Don't use local tasklet if hcd is aleady using tasklet for
   completion callback
v1:
 - Use global work queue instead of creating ordered queue.
 - Add completed urbs to a list and process all on the list when work
   is scheduled
 - Save timestamp and sof number in urb completion callback and use
   in uvc_video_clock_decode() and uvc_video_decode_start()
 - Fix race between usb_submit_urb() from uvc_video_complete() and
   usb_kill_urb() from uvc_uninit_video()

 drivers/media/usb/uvc/uvc_driver.c |   8 +++
 drivers/media/usb/uvc/uvc_isight.c |   3 +-
 drivers/media/usb/uvc/uvc_video.c  | 144 -
 drivers/media/usb/uvc/uvcvideo.h   |  18 -
 4 files changed, 134 insertions(+), 39 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_driver.c 
b/drivers/media/usb/uvc/uvc_driver.c
index 4b5b3e8..218d4f5 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -1945,6 +1946,13 @@ static int uvc_probe(struct usb_interface *intf,
"supported.\n", ret);
}
 
+   /*
+* This shouldn't be here. But since not all hcd are using tasklet for
+* urb completion callback, Check this from hcd and only use tasklet
+* for handling urb completion if hcd is not already using it.
+*/
+   dev->hcd_uses_bh = hcd_giveback_urb_in_bh(bus_to_hcd(udev->bus));
+
uvc_trace(UVC_TRACE_PROBE, "UVC device initialized.\n");
usb_enable_autosuspend(udev);
return 0;
diff --git a/drivers/media/usb/uvc/uvc_isight.c 
b/drivers/media/usb/uvc/uvc_isight.c
index 8510e725..7f93d09 100644
--- a/drivers/media/usb/uvc/uvc_isight.c
+++ b/drivers/media/usb/uvc/uvc_isight.c
@@ -99,9 +99,10 @@ static int isight_decode(struct uvc_video_queue *queue, 
struct uvc_buffer *buf,
return 0;
 }
 
-void uvc_video_decode_isight(struct urb *urb, struct uvc_streaming *stream,
+void uvc_video_decode_isight(struct uvc_urb *uu, struct uvc_streaming *stream,
struct uvc_buffer *buf)
 {
+   struct urb *urb = uu->urb;
int ret, i;
 
for (i = 0; i < urb->number_of_packets; ++i) {
diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index f839654..2dfb233 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -379,15 +379,14 @@ static inline void uvc_video_get_ts(struct timespec *ts)
 
 static void
 uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
-  const __u8 *data, int len)
+  const __u8 *data, int len, u16 host_sof,
+  struct timespec *ts)
 {
struct uvc_clock_sample *sample;
unsigned int header_size;
bool has_pts = false;
bool has_scr = false;
unsigned long flags;
-   struct timespec ts;
-   u16 host_sof;
u16 dev_sof;
 
switch (data[1] & (UVC_STREAM_PTS | UVC_STREAM_SCR)) {
@@ -435,9 +434,6 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct 
uvc_buffer *buf,
 
stream->clock.last_sof = dev_sof;
 
-   host_sof = usb_get_current_frame_number(stream->dev->udev);
-   uvc_video_get_ts(&ts);
-
/* The UVC specification allows device implementations that can't obtain
 * the USB frame number to keep their own frame counters as long as they
 * match the size and frequency of the frame number associated with USB
@@ -473,7 +469,7 @@ uvc_video_clock_decode(struct uvc_streaming *stream, struct 
uvc_buffer *buf,
sample->dev_stc = get_unaligned_le32(&data[header_size - 6]);
sample->dev_sof = dev_sof;
sample->host_sof = host_sof;
-   sample->host_ts = ts;
+   sample->host_ts = *ts;
 
/* Update the sliding window head and count. */
stream->clock.head = (stream->clock.head + 1) % stream->clock.size;
@@ -964,7 +960,8 @@ static void uvc_video_stats_stop(struct uvc_streaming 
*stream)
  * uvc_video_decode_end will never be called with a NULL buffer.
  */
 static int uvc_video_decode_start(struct uvc_streaming *stream,
-   struct uvc_buffer *buf, const __u8 *data, int len)
+   struct uvc_buffer *buf, const __u8 *data, int len,
+   u16 host_sof, struct timespec *ts)
 {
__u8 fid;
 
@@ -989,7 +986,7 @@ stati

[hid:for-4.4/debugfs-fixes 1/1] drivers/hid/hid-debug.c:1281:2-26: WARNING: NULL check before freeing functions like kfree, debugfs_remove, debugfs_remove_recursive or usb_free_urb is not needed. Mayb

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git 
for-4.4/debugfs-fixes
head:   9c537bf6cad4782573d873674a267c7cdc842ac9
commit: 9c537bf6cad4782573d873674a267c7cdc842ac9 [1/1] HID: debug: Check result 
of debugfs_create_dir() and debugfs_create_file()


coccinelle warnings: (new ones prefixed by >>)

>> drivers/hid/hid-debug.c:1281:2-26: WARNING: NULL check before freeing 
>> functions like kfree, debugfs_remove, debugfs_remove_recursive or 
>> usb_free_urb is not needed. Maybe consider reorganizing relevant code to 
>> avoid passing NULL values.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
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: MIDI gadget allocating too much from coherent pool

[Felipe Tonello]

Hi Peter,

On Wed, Sep 23, 2015 at 4:09 AM, Peter Chen  wrote:
> On Tue, Sep 22, 2015 at 07:51:34PM +0100, Felipe Tonello wrote:
>> Hi all,
>>
>> On Tue, Sep 22, 2015 at 10:13 AM, Felipe Tonello  
>> wrote:
>> > Hi Peter,
>> >
>> > On Tue, Sep 22, 2015 at 8:03 AM, Peter Chen  
>> > wrote:
>> >> On Tue, Sep 22, 2015 at 09:07:23AM +0100, Felipe Tonello wrote:
>> >>> On Tue, Sep 22, 2015 at 12:41 AM, Peter Chen  
>> >>> wrote:
>> >>> > On Mon, Sep 21, 2015 at 03:25:28PM +0100, Felipe Tonello wrote:
>> >>> >> Hi all,
>> >>> >>
>> >>> >> I actually found the problem but can't really understand. The ci_irq()
>> >>> >> handler (from core.c) is not been called after a ep_queue() from
>> >>> >> f_midi_transmit().
>> >>> >>
>> >>> >> Is there any reason for that?
>> >>> >>
>> >>> >> I used mass_storage gadget, made file transfers and others, and the
>> >>> >> interrupt handler was been called as expected.
>> >>> >>
>> >>> >
>> >>> > Which Soc are you using? And which kernel version are you using?
>> >>>
>> >>> i.MX6Q (industrial temp) and v4.2. We are using the imx6 REX module[1].
>> >>>
>> >>> We checked the errata and didn't seem to have anything relevant.
>> >>>
>> >>> I wonder: was f_midi ever working properly, ie, complete callback ever 
>> >>> called?
>> >>>
>> >>
>> >> Would you give your cpu revision number, and show me
>> >> how to reproduce it? I can test at my board.
>> >
>> > MCIMX6QAVT10AC
>> >
>> > To reproduce:
>> >  * add this line to the f_midi_complete() function under the "case 0":
>> >
>> > VDBG(cdev, "%s normal completion (%d), %d/%d\n", ep->name, status,
>> > req->actual, req->length);
>> >
>> >  * build a kernel with verbose debug enabled on USB gadget subsystem
>> >  * load g_ether module (this will create an ALSA card and device)
>> >  * connect device to host via usb otg cable.
>> >  * to list the ALSA device, run `amidi -l', use the device listed as 
>> > "f_midi"
>> >  * send midi message using `amidi -p hw:1,0 -S 901010', my device is
>> > hw:1,0, check the output of amidi -l.
>> >  * run `dmesg'  you should see the message above, but if doesn't then
>> > probably the complete callback wasn't called as well.
>> >
>> > OBS: We have set the OTG_ID pin to type B (device), so no need to OTG
>> > cable on our side.
>>
>> I realized that when the device is connected to the host but the host
>> is not reading data, the device's interrupt will never be triggered.
>> Is that what is supposed to happen?
>>
>> For example: if I send lots of data via `amidi -s' from the device to
>> the host, but until I run `amidi -d' (which dumps data from buffer) on
>> the host the interrupt on the device is never triggered.
>>
>> I will send two or three small patches that improve the situation.
>> Freeing the request when not needed any more.
>>
>
> No, it is supposed. If the device does not queue request before host
> sends data, the device can't know when the host sends data.

That's why my patch 2 is necessary.

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

Re: [PATCH 3/3] usb: gadget: f_midi: free request when usb_ep_queue fails

[Felipe Tonello]

Hi Peter,

On Wed, Sep 23, 2015 at 8:09 AM, Peter Chen  wrote:
> On Tue, Sep 22, 2015 at 07:59:10PM +0100, Felipe F. Tonello wrote:
>> This fix a memory leak that will occur in this case.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index e92aff5..e6a114b 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -550,9 +550,11 @@ static void f_midi_transmit(struct f_midi *midi, struct 
>> usb_request *req)
>>   int err;
>>
>>   err = usb_ep_queue(ep, req, GFP_ATOMIC);
>> - if (err < 0)
>> + if (err < 0) {
>>   ERROR(midi, "%s queue req: %d\n",
>> midi->in_ep->name, err);
>> + free_ep_req(ep, req);
>> + }
>>   } else {
>>   free_ep_req(ep, req);
>>   }
>> --
>> 2.1.4
>>
>
> I may know your problem, current midi library, alsa and this driver
> allow device sends as much data as possible, but without block the
> sending until host reads data, it only allocates the request buffer
> (using midi_alloc_ep_req), but without free, so after you send
> enough data, it is out of memory.

Yes. Also there is the case where the usb cable is not conected, thus
failing to hardware enqueue the request, causing a memory leak on this
request.

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

Re: [PATCH 2/3] usb: gadget: f_midi: free usb request when done

[Felipe Tonello]

Hi Peter,

On Wed, Sep 23, 2015 at 4:10 AM, Peter Chen  wrote:
> On Tue, Sep 22, 2015 at 07:59:09PM +0100, Felipe F. Tonello wrote:
>> req->actual == req->length means that there is no data left to enqueue,
>> so free the request.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index edb84ca..e92aff5 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -258,7 +258,10 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
>> *req)
>>   } else if (ep == midi->in_ep) {
>>   /* Our transmit completed. See if there's more to go.
>>* f_midi_transmit eats req, don't queue it again. */
>> - f_midi_transmit(midi, req);
>> + if (req->actual < req->length)
>> + f_midi_transmit(midi, req);
>> + else
>> + free_ep_req(ep, req);
>>   return;
>>   }
>
> It is incorrect, if no reqeust in queue, how device knows when
> the host sends data?

This is the complete function of the IN endpoint.

Actually I believe the proper patch is to enqueue this request again
if req->actual < req->length is true. Because the data is still there,
just not fully completed. Asking to transmit the request again will
cause to read new data from ALSA MIDI module, which it can possibly
steal data from a real ALSA request from f_midi_in_trigger. If that
doesn't happen (req->length == 0), the request will be freed anyway.

Any thoughts?

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

Re: MIDI gadget allocating too much from coherent pool

[Felipe Tonello]

On Wed, Sep 23, 2015 at 12:39 PM, Felipe Tonello  wrote:
> Hi Peter,
>
> On Wed, Sep 23, 2015 at 4:09 AM, Peter Chen  wrote:
>> On Tue, Sep 22, 2015 at 07:51:34PM +0100, Felipe Tonello wrote:
>>> Hi all,
>>>
>>> On Tue, Sep 22, 2015 at 10:13 AM, Felipe Tonello  
>>> wrote:
>>> > Hi Peter,
>>> >
>>> > On Tue, Sep 22, 2015 at 8:03 AM, Peter Chen  
>>> > wrote:
>>> >> On Tue, Sep 22, 2015 at 09:07:23AM +0100, Felipe Tonello wrote:
>>> >>> On Tue, Sep 22, 2015 at 12:41 AM, Peter Chen  
>>> >>> wrote:
>>> >>> > On Mon, Sep 21, 2015 at 03:25:28PM +0100, Felipe Tonello wrote:
>>> >>> >> Hi all,
>>> >>> >>
>>> >>> >> I actually found the problem but can't really understand. The 
>>> >>> >> ci_irq()
>>> >>> >> handler (from core.c) is not been called after a ep_queue() from
>>> >>> >> f_midi_transmit().
>>> >>> >>
>>> >>> >> Is there any reason for that?
>>> >>> >>
>>> >>> >> I used mass_storage gadget, made file transfers and others, and the
>>> >>> >> interrupt handler was been called as expected.
>>> >>> >>
>>> >>> >
>>> >>> > Which Soc are you using? And which kernel version are you using?
>>> >>>
>>> >>> i.MX6Q (industrial temp) and v4.2. We are using the imx6 REX module[1].
>>> >>>
>>> >>> We checked the errata and didn't seem to have anything relevant.
>>> >>>
>>> >>> I wonder: was f_midi ever working properly, ie, complete callback ever 
>>> >>> called?
>>> >>>
>>> >>
>>> >> Would you give your cpu revision number, and show me
>>> >> how to reproduce it? I can test at my board.
>>> >
>>> > MCIMX6QAVT10AC
>>> >
>>> > To reproduce:
>>> >  * add this line to the f_midi_complete() function under the "case 0":
>>> >
>>> > VDBG(cdev, "%s normal completion (%d), %d/%d\n", ep->name, status,
>>> > req->actual, req->length);
>>> >
>>> >  * build a kernel with verbose debug enabled on USB gadget subsystem
>>> >  * load g_ether module (this will create an ALSA card and device)
>>> >  * connect device to host via usb otg cable.
>>> >  * to list the ALSA device, run `amidi -l', use the device listed as 
>>> > "f_midi"
>>> >  * send midi message using `amidi -p hw:1,0 -S 901010', my device is
>>> > hw:1,0, check the output of amidi -l.
>>> >  * run `dmesg'  you should see the message above, but if doesn't then
>>> > probably the complete callback wasn't called as well.
>>> >
>>> > OBS: We have set the OTG_ID pin to type B (device), so no need to OTG
>>> > cable on our side.
>>>
>>> I realized that when the device is connected to the host but the host
>>> is not reading data, the device's interrupt will never be triggered.
>>> Is that what is supposed to happen?
>>>
>>> For example: if I send lots of data via `amidi -s' from the device to
>>> the host, but until I run `amidi -d' (which dumps data from buffer) on
>>> the host the interrupt on the device is never triggered.
>>>
>>> I will send two or three small patches that improve the situation.
>>> Freeing the request when not needed any more.
>>>
>>
>> No, it is supposed. If the device does not queue request before host
>> sends data, the device can't know when the host sends data.
>
> That's why my patch 2 is necessary.

Sorry, patch number 3. Although I feel that number 2 is also an
improvement, but not bug fix.

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

[PATCH v2 1/3] usb: chipidea: core: fix when building without CONFIG_PM support

[Felipe F. Tonello]

If CONFIG_PM or CONFIG_PM_SLEEP is not set, driver will not compile
properly.

Signed-off-by: Felipe F. Tonello 
---

Changes for v2:
 * removed unnecessary #ifdef CONFIG_PM_SLEEP.

 drivers/usb/chipidea/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 3ad48e1..382b4af 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -1009,18 +1009,20 @@ static int ci_runtime_resume(struct device *dev)
return ci_controller_resume(dev);
 }
 
-#endif /* CONFIG_PM */
 static const struct dev_pm_ops ci_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(ci_suspend, ci_resume)
SET_RUNTIME_PM_OPS(ci_runtime_suspend, ci_runtime_resume, NULL)
 };
+#endif /* CONFIG_PM */
 
 static struct platform_driver ci_hdrc_driver = {
.probe  = ci_hdrc_probe,
.remove = ci_hdrc_remove,
.driver = {
.name   = "ci_hdrc",
+#ifdef CONFIG_PM
.pm = &ci_pm_ops,
+#endif
},
 };
 
-- 
2.1.4

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

[PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

[Felipe F. Tonello]

req->actual == req->length means that there is no data left to enqueue,
so free the request.

Signed-off-by: Felipe F. Tonello 
---

Changes in v2:
 * Re enqueue not fully completed requests, instead of read ALSA buffers.

 drivers/usb/gadget/function/f_midi.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index edb84ca..62356cf 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -256,10 +256,12 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
*req)
/* We received stuff. req is queued again, below */
f_midi_handle_out_data(ep, req);
} else if (ep == midi->in_ep) {
-   /* Our transmit completed. See if there's more to go.
-* f_midi_transmit eats req, don't queue it again. */
-   f_midi_transmit(midi, req);
-   return;
+   /* Our transmit completed. If there is no more to go,
+  don't queue it again. */
+   if (req->actual == req->length) {
+   free_ep_req(ep, req);
+   return;
+   }
}
break;
 
-- 
2.1.4

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

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

[Andrew Feldhaus]

On 22/09/2015 22:25, Roland Weber wrote:

But there's also a guy who reports that external USB drives are
no longer detected during boot after he updated the BIOS to v1.10.
http://community.acer.com/t5/E-and-M-Series/Acer-ES1-111M-doesn-t-detect-USB-Drives-at-boot-phase-anymore/td-p/364139

Frankly, I don't dare to upgrade the BIOS right now. I need the
machine in working condition starting Friday next week, until
around Christmas.

Hi Roland,

I totally understand your reluctance to update the BIOS at such a 
critical time (and mid-debugging) but just to let you know: I have an 
ES1-111M running BIOS v1.13 and have had no problems booting from an 
external USB stick to install Debian (using legacy mode -- I haven't 
tried UEFI).  It also worked fine under v1.10 (factory-installed).


Thanks so much to you all for looking into the USB issues on this 
system.  My own 111M freezes at shutdown if 'noapic' is not specified on 
the (stock Debian 3.16.0-4) kernel command line and throws all sorts of 
EHCI errors otherwise so I look forward to the results of your efforts 
in due time.


Best regards,


Andrew

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

[RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

[Subbaraya Sundeep Bhatta]

This patch adds binding doc info for generic ULPI PHYs
platform driver.

Signed-off-by: Subbaraya Sundeep Bhatta 
---
 .../devicetree/bindings/usb/ulpi-platform-phy.txt  |   34 
 1 files changed, 34 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt

diff --git a/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt 
b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
new file mode 100644
index 000..7b8cbb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
@@ -0,0 +1,34 @@
+Platform driver for generic ULPI PHYs
+
+Required properties:
+- compatible   : Should be "ulpi-phy"
+- reg  : Physical base address and size of the USB
+ controller registers map to which this PHY
+ is connected.
+- view-port: Should contain viewport register offset of the
+ USB controller to which this PHY is connected
+Optional properties:
+- drv-vbus : required if turning VBUS on/off has to be driven
+ by writing to PHY. This feature depends on board
+ design.
+
+Example:
+Below example shows the PHY binding for Chipidea USB controller which has
+ulpi viewport register at 0x0170
+
+   usb_phy0: phy0 {
+   compatible = "ulpi-phy";
+   reg = <0xe0002000 0x1000>;
+   view-port = <0x0170>;
+   drv-vbus;
+   };
+
+   usb0: usb@e0002000 {
+compatible = "chipidea,usb2";
+interrupt-parent = <&intc>;
+interrupts = <0 21 4>;
+reg = <0xe0002000 0x1000>;
+phy_type = "ulpi";
+   dr_mode = "host";
+   usb-phy = <&usb_phy0>;
+};
-- 
1.7.1

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

[RFC PATCH 2/2] usb: phy: Add platform driver support for ULPI PHYs

[Subbaraya Sundeep Bhatta]

Based on board design USB controller needs explicit software
access to ULPI PHY for controlling VBUS. This patch adds platform
driver support for generic ULPI PHYs and provides a USB2 PHY device
to controllers.

Signed-off-by: Subbaraya Sundeep Bhatta 
---
 drivers/usb/phy/Kconfig |   12 +++
 drivers/usb/phy/Makefile|1 +
 drivers/usb/phy/phy-platform-ulpi.c |  143 +++
 3 files changed, 156 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/phy/phy-platform-ulpi.c

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7d3beee..2956ad4 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -201,6 +201,18 @@ config USB_RCAR_PHY
  To compile this driver as a module, choose M here: the
  module will be called phy-rcar-usb.
 
+config USB_PLATFORM_ULPI_PHY
+   tristate "Platform driver support for ULPI PHYs"
+   depends on ARCH_ZYNQ || COMPILE_TEST
+   select USB_PHY
+   select USB_ULPI_VIEWPORT
+   help
+ Say Y here to add support for the Platform driver for ULPI PHYs.
+ This adds platform driver support for all generic ULPI PHYs and is
+ typically used if usb controller driver needs explicit access to PHY.
+ 
+ To compile this driver as a module, choose M here.
+
 config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM || ARM64
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 19c0dcc..8431b6b 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_USB_QCOM_8X16_PHY)   += phy-qcom-8x16-usb.o
 obj-$(CONFIG_USB_MV_OTG)   += phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)  += phy-mxs-usb.o
 obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
+obj-$(CONFIG_USB_PLATFORM_ULPI_PHY)+= phy-platform-ulpi.o
 obj-$(CONFIG_USB_ULPI) += phy-ulpi.o
 obj-$(CONFIG_USB_ULPI_VIEWPORT)+= phy-ulpi-viewport.o
 obj-$(CONFIG_KEYSTONE_USB_PHY) += phy-keystone.o
diff --git a/drivers/usb/phy/phy-platform-ulpi.c 
b/drivers/usb/phy/phy-platform-ulpi.c
new file mode 100644
index 000..fb89363
--- /dev/null
+++ b/drivers/usb/phy/phy-platform-ulpi.c
@@ -0,0 +1,143 @@
+/*
+ * Platform driver for generic ULPI PHYs.
+ *
+ * Copyright (C) 2015 Xilinx, Inc.
+ *
+ * Author: Subbaraya Sundeep 
+ *
+ * This program is free software; you can redistribute it
+ * and/or modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2 of the License, or (at your option) any
+ * later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct ulpi_phy - The ULPI PHY
+ * @usb_phy: pointer to usb phy
+ * @regs: base address of USB controller to which PHY is connected
+ * @vp_offset: ulpi viewport register offset of USB controller
+ * @flags: initial required settings of PHY
+ */
+
+struct ulpi_phy {
+   struct usb_phy  *usb_phy;
+   void __iomem *regs;
+   unsigned int vp_offset;
+   unsigned int flags;
+};
+
+/**
+ * usbphy_set_vbus - Sets VBUS by writing to PHY.
+ * @phy: pointer to PHY
+ * @on: 1 - turn on VBUS
+ * 0 - turn off VBUS
+ * Return: 0 for success and error value on failure
+ */
+static int usbphy_set_vbus(struct usb_phy *phy, int on)
+{
+   unsigned int flags = usb_phy_io_read(phy, ULPI_OTG_CTRL);
+
+   flags &= ~(ULPI_OTG_CTRL_DRVVBUS | ULPI_OTG_CTRL_DRVVBUS_EXT);
+
+   if (on) {
+   if (phy->flags & ULPI_OTG_DRVVBUS)
+   flags |= ULPI_OTG_CTRL_DRVVBUS;
+
+   if (phy->flags & ULPI_OTG_DRVVBUS_EXT)
+   flags |= ULPI_OTG_CTRL_DRVVBUS_EXT;
+   }
+
+   return usb_phy_io_write(phy, flags, ULPI_OTG_CTRL);
+}
+
+/**
+ * ulpi_phy_probe - The device probe function for driver initialization.
+ * @pdev: pointer to the platform device structure.
+ *
+ * Return: 0 for success and error value on failure
+ */
+static int ulpi_phy_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct resource *res;
+   struct ulpi_phy *uphy;
+   bool flag;
+   int ret;
+
+   uphy = devm_kzalloc(&pdev->dev, sizeof(*uphy), GFP_KERNEL);
+   if (!uphy)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   uphy->regs = devm_ioremap(&pdev->dev, res->start, resource_size(res));
+   if (IS_ERR(uphy->regs))
+   return PTR_ERR(uphy->regs);
+
+   ret = of_property_read_u32(np, "view-port", &uphy->vp_offset);
+   if (IS_ERR(uphy->regs)) {
+   dev_err(&pdev->dev, "view-port register not specified\n");
+   return PTR_ERR(uphy->regs);
+   }
+
+   flag = of_property_read_bool(np, "drv-vbus");
+   if (flag)
+   uphy->flags |= ULPI_OTG_DRVVBUS | ULPI_OTG_DR

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

[Sergei Shtylyov]

Hello.

On 9/23/2015 3:01 PM, Felipe F. Tonello wrote:


req->actual == req->length means that there is no data left to enqueue,
so free the request.

Signed-off-by: Felipe F. Tonello 
---

Changes in v2:
  * Re enqueue not fully completed requests, instead of read ALSA buffers.

  drivers/usb/gadget/function/f_midi.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index edb84ca..62356cf 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -256,10 +256,12 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
*req)
/* We received stuff. req is queued again, below */
f_midi_handle_out_data(ep, req);
} else if (ep == midi->in_ep) {
-   /* Our transmit completed. See if there's more to go.
-* f_midi_transmit eats req, don't queue it again. */
-   f_midi_transmit(midi, req);
-   return;
+   /* Our transmit completed. If there is no more to go,
+  don't queue it again. */


   The preferred multi-line comment style is this:

/*
 * bla
 * bla
 */

MBR, Sergei

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

Re: [PATCH 2/3] usb: gadget: f_midi: free usb request when done

[Alan Stern]

On Wed, 23 Sep 2015, Felipe Tonello wrote:

> Hi Peter,
> 
> On Wed, Sep 23, 2015 at 4:10 AM, Peter Chen  wrote:
> > On Tue, Sep 22, 2015 at 07:59:09PM +0100, Felipe F. Tonello wrote:
> >> req->actual == req->length means that there is no data left to enqueue,
> >> so free the request.
> >>
> >> Signed-off-by: Felipe F. Tonello 
> >> ---
> >>  drivers/usb/gadget/function/f_midi.c | 5 -
> >>  1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/gadget/function/f_midi.c 
> >> b/drivers/usb/gadget/function/f_midi.c
> >> index edb84ca..e92aff5 100644
> >> --- a/drivers/usb/gadget/function/f_midi.c
> >> +++ b/drivers/usb/gadget/function/f_midi.c
> >> @@ -258,7 +258,10 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
> >> *req)
> >>   } else if (ep == midi->in_ep) {
> >>   /* Our transmit completed. See if there's more to go.
> >>* f_midi_transmit eats req, don't queue it again. */
> >> - f_midi_transmit(midi, req);
> >> + if (req->actual < req->length)
> >> + f_midi_transmit(midi, req);
> >> + else
> >> + free_ep_req(ep, req);
> >>   return;
> >>   }
> >
> > It is incorrect, if no reqeust in queue, how device knows when
> > the host sends data?
> 
> This is the complete function of the IN endpoint.
> 
> Actually I believe the proper patch is to enqueue this request again
> if req->actual < req->length is true. Because the data is still there,
> just not fully completed. Asking to transmit the request again will
> cause to read new data from ALSA MIDI module, which it can possibly
> steal data from a real ALSA request from f_midi_in_trigger. If that
> doesn't happen (req->length == 0), the request will be freed anyway.
> 
> Any thoughts?

Please pardon me for jumping in in the middle of a conversation.  I 
know practically zero about f_midi.  But nevertheless...

How can you ever have req->actual < req->length for a usb_request on an
IN endpoint?  The only way that can happen is if some sort of error or
exceptional event occurred, for example, if the transfer was cancelled
before it could run to completion.  In such cases I doubt that you
really want to retransmit the data.  Particularly since part of it
probably was received by the host -- do you really want to send that
part of the data a second time?

Don't bother to answer if this doesn't make any sense...

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 2/3] usb: gadget: f_midi: free usb request when done

[Felipe Tonello]

Hi Alan,

On Wed, Sep 23, 2015 at 3:30 PM, Alan Stern  wrote:
> On Wed, 23 Sep 2015, Felipe Tonello wrote:
>
>> Hi Peter,
>>
>> On Wed, Sep 23, 2015 at 4:10 AM, Peter Chen  wrote:
>> > On Tue, Sep 22, 2015 at 07:59:09PM +0100, Felipe F. Tonello wrote:
>> >> req->actual == req->length means that there is no data left to enqueue,
>> >> so free the request.
>> >>
>> >> Signed-off-by: Felipe F. Tonello 
>> >> ---
>> >>  drivers/usb/gadget/function/f_midi.c | 5 -
>> >>  1 file changed, 4 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> >> b/drivers/usb/gadget/function/f_midi.c
>> >> index edb84ca..e92aff5 100644
>> >> --- a/drivers/usb/gadget/function/f_midi.c
>> >> +++ b/drivers/usb/gadget/function/f_midi.c
>> >> @@ -258,7 +258,10 @@ f_midi_complete(struct usb_ep *ep, struct 
>> >> usb_request *req)
>> >>   } else if (ep == midi->in_ep) {
>> >>   /* Our transmit completed. See if there's more to 
>> >> go.
>> >>* f_midi_transmit eats req, don't queue it again. 
>> >> */
>> >> - f_midi_transmit(midi, req);
>> >> + if (req->actual < req->length)
>> >> + f_midi_transmit(midi, req);
>> >> + else
>> >> + free_ep_req(ep, req);
>> >>   return;
>> >>   }
>> >
>> > It is incorrect, if no reqeust in queue, how device knows when
>> > the host sends data?
>>
>> This is the complete function of the IN endpoint.
>>
>> Actually I believe the proper patch is to enqueue this request again
>> if req->actual < req->length is true. Because the data is still there,
>> just not fully completed. Asking to transmit the request again will
>> cause to read new data from ALSA MIDI module, which it can possibly
>> steal data from a real ALSA request from f_midi_in_trigger. If that
>> doesn't happen (req->length == 0), the request will be freed anyway.
>>
>> Any thoughts?
>
> Please pardon me for jumping in in the middle of a conversation.  I
> know practically zero about f_midi.  But nevertheless...
>
> How can you ever have req->actual < req->length for a usb_request on an
> IN endpoint?  The only way that can happen is if some sort of error or
> exceptional event occurred, for example, if the transfer was cancelled
> before it could run to completion.  In such cases I doubt that you
> really want to retransmit the data.  Particularly since part of it
> probably was received by the host -- do you really want to send that
> part of the data a second time?

That is a fair point.

IMO we should always free the request upon a completion. Never
retransmit, since ALSA trigger will do that anyway.

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

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

[Alan Stern]

On Tue, 22 Sep 2015, Roland Weber wrote:

> Hi Alan,
> 
> > Did you turn off the computer before booting these kernels (i.e., a
> > "cold" boot) or did you reboot when the machine was already running (a
> > "warm" boot)?
> 
> I didn't pay attention to that. Most likely, I prepared the debug session
> on 3.17.8, warm-booted into kernel-f, froze the machine, then cold-booted
> into kernel-g.
> Now I tried again, making sure to cold-boot into both kernels. The
> differences you noticed are gone, both -f and -g behave as listed for -g.
> See below for the full output. And -f still freezes, while -g does not.
> 
> > Here's the corresponding part of the -g kernel log:
> > 
> > > [1.017430] pci :00:02.0: Video device with shadowed ROM
> > > [1.017971] PCI: CLS 64 bytes, default 64
> [...]
> > and for the -g kernel:
> > 
> > > /sys/kernel/debug/usb/ehci/:00:1d.0/registers now contains:
> > > bus pci, device :00:1d.0
> > > EHCI Host Controller
> > > EHCI 1.00, rh state running
> > > ownership 0001

Okay.  This value for ownership is still wrong, though.

> > Have you checked to see if any BIOS updates are available?
> 
> The machine is on v1.08, there have been two updates since:
> v1.13: 1. add Elan touchpad support
>2. update EC to v1.5
> v1.10: 1. Add battery ID
> 
> But there's also a guy who reports that external USB drives are
> no longer detected during boot after he updated the BIOS to v1.10.
> http://community.acer.com/t5/E-and-M-Series/Acer-ES1-111M-doesn-t-detect-USB-Drives-at-boot-phase-anymore/td-p/364139
> 
> Frankly, I don't dare to upgrade the BIOS right now. I need the
> machine in working condition starting Friday next week, until
> around Christmas. I'll be teaching lectures once a week and bought
> the machine to drive the projector. Most of my spare time will be
> consumed by preparing the lectures for the next three months.
> If the machine stops booting from external USB devices, I couldn't
> reinstall it anymore, nor could I flash a fixed BIOS. I'll have
> to set up dual boot with Linux and FreeDOS before I can risk a
> BIOS upgrade. Currently, that doesn't fit into my time budget.

All right.  Maybe at some point in the future.  The thing is, I don't 
want to patch the kernel only to find that the problem has already been 
fixed in a newer BIOS.

> > there are a few other thing you can try.  Under a kernel with 
> > CONFIG_PM enabled, before unbinding the driver try doing:
> > 
> > echo on >/sys/bus/pci/devices/:00:1d.0/usb3/power/control
> > 
> > That alone might cause the system to freeze
> 
> It does. I tried with kernel-f and got two lines of output:
> usb usb3: usb auto-resume
> ehci-pci :00:1d.0: resume root hub
> (freeze)
> 
> > Here's another experiment.  At the start of ehci_halt(), before the
> > spin_lock_irq(), add this:
> > 
> > if (ehci->rh_state == EHCI_RH_SUSPENDED) {
> // I added a printk here
> > ehci_writel(ehci, CMD_RUN, &ehci->regs->command);
> > msleep(10);
> > }
> > 
> > This may end up doing about the same thing as the previous test.
> 
> It does. The last few lines of the debug output are:
> ehci_halt: entry
> ehci_halt: EHCI_RH_SUSPENDED, running patch writel
> ehci_halt: about to readl prematurely
> (freeze)

The unavoidable conclusion is that your system doesn't work right when 
this root hub is suspended.  (I still think it's the BIOS's fault.)

Which suggests yet another test: Under a kernel with CONFIG_PM and
CONFIG_PM_SLEEP enabled, what happens when you suspend the system
(i.e., suspend-to-RAM) and then wake it up?  For this experiment, it
may help to add "no_console_suspend" to the boot command line.

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 11159] reset high speed USB device using ehci_hcd

[Alan Stern]

On Wed, 23 Sep 2015 bugzilla-dae...@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=11159
> 
> KES777  changed:
> 
>What|Removed |Added
> 
>  CC||kes-...@yandex.ru
> 
> --- Comment #94 from KES777  ---
> I were injured this problem too. When I install clean system 17.0 Linux mint
> all were OK. During some updates by 'Update manager' on 17.1 the problem were
> rised.
> 
> The hardware has not been changed
> 
> This is my post:
> http://askubuntu.com/questions/01/system-is-loading-about-10-min-what-is-comming-on
> with messages on logs.
> 
> This problem does not exists when rebooting. It is only when cool start.

> --- Comment #95 from KES777  ---
> Linux keshome 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014
> x86_64 x86_64 x86_64 GNU/Linux

Can you try installing version 4.2 of the kernel?  3.13 is kind of old, 
and things may have improved since it was released.

Alan Stern

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

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

[Scott Branden]

On 15-09-23 01:18 AM, John Youn wrote:

On 9/23/2015 1:11 AM, John Youn wrote:

On 9/23/2015 12:36 AM, Scott Branden wrote:

Hi John,

Could you please review the v3 Patch.  I believe we have address all of
your comments?



Yes I've been meaning to test it on our platforms. I should be
able to get to it tomorrow.



Also if you could rebase off of Felipe's testing/next branch it
would make it easier when it comes time to merge it in.


Could you point me at Felipe's git repo as I am unfamiliar with the 
location?


Thanks,
 Scott



Regards,
John



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

Re: [PATCH 2/3] usb: gadget: at91_udc: mention proper dependency

[Sudip Mukherjee]

On Mon, Sep 21, 2015 at 04:40:57PM +0530, Sudip Mukherjee wrote:
> On Sun, Sep 20, 2015 at 11:15:28AM -0500, Felipe Balbi wrote:
> > On Sat, Sep 19, 2015 at 10:42:58PM +0530, Sudip Mukherjee wrote:
> > > While building allmodconfig on avr32 the build failed with the error:
> > > "at91_pmc_base" [drivers/usb/gadget/udc/atmel_usba_udc.ko] undefined!
> > > 
> > > On checking the code it turned out that if CONFIG_OF is defined then it
> > > is using at91_pmc_read() which is using at91_pmc_base. And unless
> > > COMMON_CLK_AT91 is defined we donot have at91_pmc_base. And
> > > COMMON_CLK_AT91 is available with AT91 architecture.
> > > Mention the dependency such that this driver builds with avr32 only if
> > > OF is not enabled.
> > > 
> > > Signed-off-by: Sudip Mukherjee 
> > > ---
> > > 
> > > Tested build with at91_dt_defconfig and allmodconfig of avr32. Build log
> > > at:
> > > https://travis-ci.org/sudipm-mukherjee/parport/builds/81168845
> > > 
> > >  drivers/usb/gadget/udc/Kconfig | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/usb/gadget/udc/Kconfig 
> > > b/drivers/usb/gadget/udc/Kconfig
> > > index 9a3a6b0..cdbff54 100644
> > > --- a/drivers/usb/gadget/udc/Kconfig
> > > +++ b/drivers/usb/gadget/udc/Kconfig
> > > @@ -55,7 +55,7 @@ config USB_LPC32XX
> > >  
> > >  config USB_ATMEL_USBA
> > >   tristate "Atmel USBA"
> > > - depends on AVR32 || ARCH_AT91
> > > + depends on ((AVR32 && !OF) || ARCH_AT91)
> > 
> > any chance you can add || COMPILE_TEST here ? I'd like to make
> > sure this builds on my end too.
> With "depends on ((AVR32 && !OF) || ARCH_AT91 || COMPILE_TEST)"
> normal allmodconfig builiding for x86_64 failed with:
> 
> drivers/usb/gadget/udc/atmel_usba_udc.c: In function ‘usba_start’:
> drivers/usb/gadget/udc/atmel_usba_udc.c:1783:25: error: ‘USBA_ENABLE_MASK’ 
> undeclared (first use in this function)
>   usba_writel(udc, CTRL, USBA_ENABLE_MASK);
>  ^
> drivers/usb/gadget/udc/atmel_usba_udc.c: In function ‘usba_stop’:
> drivers/usb/gadget/udc/atmel_usba_udc.c:1800:25: error: ‘USBA_DISABLE_MASK’ 
> undeclared (first use in this function)
>   usba_writel(udc, CTRL, USBA_DISABLE_MASK);
>  ^
> 
> Looks like USBA_DISABLE_MASK and USBA_ENABLE_MASK is defined under
> #if defined(CONFIG_AVR32). :(
Can i check anything else here? Like I said with COMPILE_TEST
allmodconfig on x86_64 is failing.

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

Re: [PATCH 1/3] avr32: fix build failure

[Sudip Mukherjee]

On Mon, Sep 21, 2015 at 01:31:44PM +0530, Sudip Mukherjee wrote:
> On Mon, Sep 21, 2015 at 09:33:00AM +0200, Hans-Christian Egtvedt wrote:
> > Around Mon 21 Sep 2015 12:09:01 +0530 or thereabout, Sudip Mukherjee wrote:
> > > On Mon, Sep 21, 2015 at 08:09:42AM +0200, Hans-Christian Egtvedt wrote:
> > >> Around Sat 19 Sep 2015 22:42:57 +0530 or thereabout, Sudip Mukherjee 
> > >> wrote:
> > >> > While building avr32 with allmodconfig, the build used to fail with the
> > >> > message:
> > >> > error: implicit declaration of function 'pci_iomap'
> > >> > error: implicit declaration of function 'pci_iounmap'
> > >> 
> > >> What has changed recently that start pulling in these? AVR32 does not 
> > >> have
> > >> PCI at all, and will never have it either. Is this exposing a bug 
> > >> somewhere
> > >> else?
> > > It looks like pci_iomap and pci_iounmap doesnot depend on CONFIG_PCI.
> > > So drivers/net/ethernet/via/via-rhine.c is calling these functions even
> > > if PCI is disabled. The build log is at:
> > > https://travis-ci.org/sudipm-mukherjee/parport/jobs/81127188
> > > 
> > > You can find a similar discussion at:
> > > http://www.linux-mips.org/archives/linux-mips/2013-06/msg00510.html
> > 
> > If multiple architectures have similar problems, then a more global
> > definition of these unused functions could be added.
> > 
> > Just move the implementation for MIPS into include/asm-generic/io.h ?
> > 
> > That way we do not have to implement and identical stub for every device not
> > supporting PCI.
> 
> include/asm-generic/io.h is having:
> #ifndef CONFIG_GENERIC_IOMAP
> struct pci_dev;
> extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned
>   long max);
> 
> #ifndef pci_iounmap
> #define pci_iounmap pci_iounmap
> static inline void pci_iounmap(struct pci_dev *dev, void __iomem *p)
> {
> }
> #endif
> #endif /* CONFIG_GENERIC_IOMAP */
> 
> and CONFIG_GENERIC_IOMAP is not defined when I do allmodconfig with
> avr32. I have not seen this earlier, maybe in my patch pci_iounmap() was
> not required. But pci_iomap is declared as extern so we need have it
> somewhere.
Hi Hans,
Please suggest.

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

Re: [PATCH 2/4] doc: dt-binding: ci-hdrc-usb2: add i.mx specific binding "need-three-clocks"

[Rob Herring]

On Thu, Sep 17, 2015 at 9:35 PM, Peter Chen  wrote:
> On Wed, Sep 16, 2015 at 08:54:25AM -0500, Rob Herring wrote:
>> On 09/15/2015 08:49 PM, Peter Chen wrote:
>> > Some SoCs needs three clock to let controller work, but others only
>> > need one, add one property to differentiate this.

[...]

>> > diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt 
>> > b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> > index f15a317..4900092 100644
>> > --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> > +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt
>> > @@ -54,6 +54,9 @@ i.mx specific properties
>> >argument that indicate usb controller index
>> >  - disable-over-current: disable over current detect
>> >  - external-vbus-divider: enables off-chip resistor divider for Vbus
>> > +- need-three-clocks: the SoC before imx6 series (except for imx23/imx28)
>> > +  needs three clcoks for controller, others only need one. Without this
>> > +  property, the driver will consider this controller only need one clock.
>>
>> That's pretty ugly and unnecessary. Either use the compatible string to
>> determine
>
> Since there are too many SoCs to use it, I just didn't want to add
> judgement for platforms, and thought using feature property is simpler.
> If you doesn't agree, I will use other ways.
>
>> if you have 3 clocks or just always try to retrieve the 3
>> clocks in the driver and fall back to 1.
>>
>
> It is not easy to use this way, one-clock platforms have no dev_id for
> clock, but three-clock platforms have.

You just need to try to retrieve the 3rd clock by name. If that
succeeds, retrieve clocks 1 and 2. If you can't retrieve the 3rd
clock, the just get the 1st clock with no name.

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

Re: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

[Bin Liu]

Hi,

On 09/22/2015 04:18 PM, Felipe Balbi wrote:

On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:

Hi,

On 09/22/2015 09:40 AM, Felipe Balbi wrote:

On Mon, Sep 21, 2015 at 10:50:56AM -0500, Bin Liu wrote:

Some USB phy drivers have different handling for the controller in each
dr_mode. But the phy driver does not have visibility to the dr_mode of
the controller.

This adds an api to return the dr_mode of the controller which
associates the given phy node.

Signed-off-by: Bin Liu 



doesn't apply anymore. Probably because of Heikki's series which I just
added to testing/next.

Please rebase there.


I have to rewrite my patch. Before Heikki's patch of_usb_get_dr_mode() takes
parameter 'struct *device_node', but now usb_get_dr_mode() takes parameter
'struct *device'. The logic in my patch iterates over of nodes, I am not
sure how to get the 'struct *device' from a of node yet...


okay.

There is no way to get the 'struct *device' to the controller in the phy 
driver, because the controller device might not be registered yet by the 
time the phy probe is called.


So I have to put back the implementation of the removed 
of_usb_get_dr_mode() into this new of_usb_get_dr_mode_by_phy() function. 
Please let me know if this is acceptable then I will send the v5.


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

Re: [PATCH 1/3] avr32: fix build failure

[Hans-Christian Egtvedt]

Around Wed 23 Sep 2015 21:26:01 +0530 or thereabout, Sudip Mukherjee wrote:
> On Mon, Sep 21, 2015 at 01:31:44PM +0530, Sudip Mukherjee wrote:
>> On Mon, Sep 21, 2015 at 09:33:00AM +0200, Hans-Christian Egtvedt wrote:
>> > Around Mon 21 Sep 2015 12:09:01 +0530 or thereabout, Sudip Mukherjee wrote:
>> > > On Mon, Sep 21, 2015 at 08:09:42AM +0200, Hans-Christian Egtvedt wrote:
>> > >> Around Sat 19 Sep 2015 22:42:57 +0530 or thereabout, Sudip Mukherjee 
>> > >> wrote:
>> > >> > While building avr32 with allmodconfig, the build used to fail with 
>> > >> > the
>> > >> > message:
>> > >> > error: implicit declaration of function 'pci_iomap'
>> > >> > error: implicit declaration of function 'pci_iounmap'
>> > >> 
>> > >> What has changed recently that start pulling in these? AVR32 does not 
>> > >> have
>> > >> PCI at all, and will never have it either. Is this exposing a bug 
>> > >> somewhere
>> > >> else?
>> > > It looks like pci_iomap and pci_iounmap doesnot depend on CONFIG_PCI.
>> > > So drivers/net/ethernet/via/via-rhine.c is calling these functions even
>> > > if PCI is disabled. The build log is at:
>> > > https://travis-ci.org/sudipm-mukherjee/parport/jobs/81127188
>> > > 
>> > > You can find a similar discussion at:
>> > > http://www.linux-mips.org/archives/linux-mips/2013-06/msg00510.html
>> > 
>> > If multiple architectures have similar problems, then a more global
>> > definition of these unused functions could be added.
>> > 
>> > Just move the implementation for MIPS into include/asm-generic/io.h ?
>> > 
>> > That way we do not have to implement and identical stub for every device 
>> > not
>> > supporting PCI.
>> 
>> include/asm-generic/io.h is having:
>> #ifndef CONFIG_GENERIC_IOMAP
>> struct pci_dev;
>> extern void __iomem *pci_iomap(struct pci_dev *dev, int bar, unsigned
>>  long max);
>> 
>> #ifndef pci_iounmap
>> #define pci_iounmap pci_iounmap
>> static inline void pci_iounmap(struct pci_dev *dev, void __iomem *p)
>> {
>> }
>> #endif
>> #endif /* CONFIG_GENERIC_IOMAP */
>> 
>> and CONFIG_GENERIC_IOMAP is not defined when I do allmodconfig with
>> avr32. I have not seen this earlier, maybe in my patch pci_iounmap() was
>> not required. But pci_iomap is declared as extern so we need have it
>> somewhere.
> Hi Hans,
> Please suggest.

I can ack the original change, but it will only lead to a cluttered code
base. The real problem is somewhere else, where it looks like the
CONFIG_GENERIC_IOMAP symbol assumes PCI is for everybody. I would like if
somebody addressed that problem instead.

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

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

[John Youn]

On 9/23/2015 8:39 AM, Scott Branden wrote:
> On 15-09-23 01:18 AM, John Youn wrote:
>> On 9/23/2015 1:11 AM, John Youn wrote:
>>> On 9/23/2015 12:36 AM, Scott Branden wrote:
 Hi John,

 Could you please review the v3 Patch.  I believe we have address all of
 your comments?

>>>
>>> Yes I've been meaning to test it on our platforms. I should be
>>> able to get to it tomorrow.
>>>
>>
>> Also if you could rebase off of Felipe's testing/next branch it
>> would make it easier when it comes time to merge it in.
> 
> Could you point me at Felipe's git repo as I am unfamiliar with the 
> location?
> 

git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git


Regards,
John

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

[PATCH] USB: whiteheat: fix potential null-deref at probe

[Johan Hovold]

Fix potential null-pointer dereference at probe by making sure that the
required endpoints are present.

The whiteheat driver assumes there are at least five pairs of bulk
endpoints, of which the final pair is used for the "command port". An
attempt to bind to an interface with fewer bulk endpoints would
currently lead to an oops.

Fixes CVE-2015-5257.

Reported-by: Moein Ghasemzadeh 
Cc: stable 
Signed-off-by: Johan Hovold 
---

Greg,

Could you take this one directly for 4.3-rc3?

Thanks,
Johan


 drivers/usb/serial/whiteheat.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c
index 6c3734d2b45a..d3ea90bef84d 100644
--- a/drivers/usb/serial/whiteheat.c
+++ b/drivers/usb/serial/whiteheat.c
@@ -80,6 +80,8 @@ static int  whiteheat_firmware_download(struct usb_serial 
*serial,
 static int  whiteheat_firmware_attach(struct usb_serial *serial);
 
 /* function prototypes for the Connect Tech WhiteHEAT serial converter */
+static int whiteheat_probe(struct usb_serial *serial,
+   const struct usb_device_id *id);
 static int  whiteheat_attach(struct usb_serial *serial);
 static void whiteheat_release(struct usb_serial *serial);
 static int  whiteheat_port_probe(struct usb_serial_port *port);
@@ -116,6 +118,7 @@ static struct usb_serial_driver whiteheat_device = {
.description =  "Connect Tech - WhiteHEAT",
.id_table = id_table_std,
.num_ports =4,
+   .probe =whiteheat_probe,
.attach =   whiteheat_attach,
.release =  whiteheat_release,
.port_probe =   whiteheat_port_probe,
@@ -217,6 +220,34 @@ static int whiteheat_firmware_attach(struct usb_serial 
*serial)
 /*
  * Connect Tech's White Heat serial driver functions
  */
+
+static int whiteheat_probe(struct usb_serial *serial,
+   const struct usb_device_id *id)
+{
+   struct usb_host_interface *iface_desc;
+   struct usb_endpoint_descriptor *endpoint;
+   size_t num_bulk_in = 0;
+   size_t num_bulk_out = 0;
+   size_t min_num_bulk;
+   unsigned int i;
+
+   iface_desc = serial->interface->cur_altsetting;
+
+   for (i = 0; i < iface_desc->desc.bNumEndpoints; i++) {
+   endpoint = &iface_desc->endpoint[i].desc;
+   if (usb_endpoint_is_bulk_in(endpoint))
+   ++num_bulk_in;
+   if (usb_endpoint_is_bulk_out(endpoint))
+   ++num_bulk_out;
+   }
+
+   min_num_bulk = COMMAND_PORT + 1;
+   if (num_bulk_in < min_num_bulk || num_bulk_out < min_num_bulk)
+   return -ENODEV;
+
+   return 0;
+}
+
 static int whiteheat_attach(struct usb_serial *serial)
 {
struct usb_serial_port *command_port;
-- 
2.4.9

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

Re: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

[Hans de Goede]

Hi,

On 23-09-15 19:10, Bin Liu wrote:

Hi,

On 09/22/2015 04:18 PM, Felipe Balbi wrote:

On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:

Hi,

On 09/22/2015 09:40 AM, Felipe Balbi wrote:

On Mon, Sep 21, 2015 at 10:50:56AM -0500, Bin Liu wrote:

Some USB phy drivers have different handling for the controller in each
dr_mode. But the phy driver does not have visibility to the dr_mode of
the controller.

This adds an api to return the dr_mode of the controller which
associates the given phy node.

Signed-off-by: Bin Liu 



doesn't apply anymore. Probably because of Heikki's series which I just
added to testing/next.

Please rebase there.


I have to rewrite my patch. Before Heikki's patch of_usb_get_dr_mode() takes
parameter 'struct *device_node', but now usb_get_dr_mode() takes parameter
'struct *device'. The logic in my patch iterates over of nodes, I am not
sure how to get the 'struct *device' from a of node yet...


okay.


There is no way to get the 'struct *device' to the controller in the phy 
driver, because the controller device might not be registered yet by the time 
the phy probe is called.

So I have to put back the implementation of the removed of_usb_get_dr_mode() 
into this new of_usb_get_dr_mode_by_phy() function. Please let me know if this 
is acceptable then I will send the v5.


Sounds to me like it is better to revert the API change / removal of 
of_usb_get_dr_mode()
as a separate patch and then stick with your v4 patch.

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

Overly conservative xHCI bandwidth estimation

[Steinar H. Gunderson]

Hi again,

I'm trying to figure out why my xHCI controller refuses me to run two very
similar video cards at the same time. I'm not sure if this is a bug or if I'm
just misunderstanding, so let me see if I understand this right:

The interface of each card has two relevant alternates, 2 and 4. Number 2 has 
bInterval=1, bMaxBurst=11, Mult=2, which from what I can see should be
11*(2+1)*1024 byte / 125µs, or 2.16 Gbit/sec. Number 4 has bInterval=1,
bMaxBurst=8, Mult=1, which should be 8*(1+1)*1024 byte / 125 µs, or 1.04 
Gbit/sec.

I can run one card in alternates 2 or 4, no problem. But if I put another
card in the other USB port (my Lenovo X240 has one on each side) and try to
activate that too, I get

  [  287.919173] usb 2-2: Not enough bandwidth for altsetting 4

I've tried on another machine and it works fine there, so my code should,
at least on the surface of it, be fine. I've verified that the error is
COMP_BW_ERR (not COMP_2ND_BW_ERR).

My xHCI controller is 8086:9c31 (I believe this is Intel). lsusb -v with both
devices plugged in is attached. I'm running 4.3-rc2. There are no external
USB hubs in the mix.

So this is my question: Why can I run one card at 2.16 Gbit/sec but not two
at 1.04 Gbit/sec each? (Shouldn't the USB3 bus be 5 Gbit/sec?) Is there any
way to debug these issues, or is the controller just deciding and unwilling
to give out any information? Is the information of the bandwidth domains/
bus instances available anywhere? Am I misunderstanding something
fundamentally?

Thanks!

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Bus 001 Device 002: ID 8087:8000 Intel Corp. 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 1 Single TT
  bMaxPacketSize064
  idVendor   0x8087 Intel Corp.
  idProduct  0x8000 
  bcdDevice0.04
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 9 Hub
  bInterfaceSubClass  0 Unused
  bInterfaceProtocol  0 Full speed (or root) hub
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0002  1x 2 bytes
bInterval  12
Hub Descriptor:
  bLength  11
  bDescriptorType  41
  nNbrPorts 8
  wHubCharacteristic 0x0009
Per-port power switching
Per-port overcurrent protection
TT think time 8 FS bits
  bPwrOn2PwrGood0 * 2 milli seconds
  bHubContrCurrent  0 milli Ampere
  DeviceRemovable0x00 0x00
  PortPwrCtrlMask0xff 0xff
 Hub Port Status:
   Port 1: .0100 power
   Port 2: .0100 power
   Port 3: .0100 power
   Port 4: .0100 power
   Port 5: .0100 power
   Port 6: .0100 power
   Port 7: .0100 power
   Port 8: .0100 power
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x0001
  Self Powered

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass9 Hub
  bDeviceSubClass 0 Unused
  bDeviceProtocol 0 Full speed (or root) hub
  bMaxPacketSize064
  idVendor   0x1d6b Linux Foundation
  idProduct  0x0002 2.0 root hub
  bcdDevice4.03
  iManufacturer   3 Linux 4.3.0-rc2 ehci_hcd
  iProduct2 EHCI Host Controller
  iSerial 1 :00:1d.0
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   25
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower0mA
Interface Descriptor:
  bLength 

Re[2]: [Bug 11159] reset high speed USB device using ehci_hcd

[Eugen Konkov]

Hi, Alan.

I can try, but this seems the escape from problem and not solution (((
3.13 is not going to be updated anymore?? 

Вы писали 23 сентября 2015 г., 12:12:59:

AS> On Wed, 23 Sep 2015 bugzilla-dae...@bugzilla.kernel.org wrote:

>> https://bugzilla.kernel.org/show_bug.cgi?id=11159

>> KES777  changed:

>>What|Removed |Added
>> 
>>  CC||kes-...@yandex.ru

>> --- Comment #94 from KES777  ---
>> I were injured this problem too. When I install clean system 17.0 Linux mint
>> all were OK. During some updates by 'Update manager' on 17.1 the problem were
>> rised.

>> The hardware has not been changed

>> This is my post:
>> http://askubuntu.com/questions/01/system-is-loading-about-10-min-what-is-comming-on
>> with messages on logs.

>> This problem does not exists when rebooting. It is only when cool start.

>> --- Comment #95 from KES777  ---
>> Linux keshome 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014
>> x86_64 x86_64 x86_64 GNU/Linux

AS> Can you try installing version 4.2 of the kernel?  3.13 is kind of old, 
AS> and things may have improved since it was released.

AS> Alan Stern





-- 
С уважением,
 Eugen  mailto:kes-...@yandex.ru

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

Re: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

[Bin Liu]

Hi,

On 09/23/2015 02:53 PM, Hans de Goede wrote:

Hi,

On 23-09-15 19:10, Bin Liu wrote:

Hi,

On 09/22/2015 04:18 PM, Felipe Balbi wrote:

On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:

Hi,

On 09/22/2015 09:40 AM, Felipe Balbi wrote:

On Mon, Sep 21, 2015 at 10:50:56AM -0500, Bin Liu wrote:

Some USB phy drivers have different handling for the controller in
each
dr_mode. But the phy driver does not have visibility to the
dr_mode of
the controller.

This adds an api to return the dr_mode of the controller which
associates the given phy node.

Signed-off-by: Bin Liu 



doesn't apply anymore. Probably because of Heikki's series which I
just
added to testing/next.

Please rebase there.


I have to rewrite my patch. Before Heikki's patch
of_usb_get_dr_mode() takes
parameter 'struct *device_node', but now usb_get_dr_mode() takes
parameter
'struct *device'. The logic in my patch iterates over of nodes, I am
not
sure how to get the 'struct *device' from a of node yet...


okay.


There is no way to get the 'struct *device' to the controller in the
phy driver, because the controller device might not be registered yet
by the time the phy probe is called.

So I have to put back the implementation of the removed
of_usb_get_dr_mode() into this new of_usb_get_dr_mode_by_phy()
function. Please let me know if this is acceptable then I will send
the v5.


Sounds to me like it is better to revert the API change / removal of
of_usb_get_dr_mode()
as a separate patch and then stick with your v4 patch.


+1

Regards,
-Bin.



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

Problems with printk logs and my driver

[Eric Curtin]

Hi Guys,

Just wondering what I am doing wrong. I can't see my logs. I figured
out what driver is used for my keyboard and started adding logging:

[curtine@localhost ~]$ sudo lsusb -v | grep eyboard -B 13
Bus 001 Device 003: ID 04ca:008d Lite-On Technology Corp.
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize032
  idVendor   0x04ca Lite-On Technology Corp.
  idProduct  0x008d
  bcdDevice0.39
  iManufacturer   1 Lite-On Technology Corp.
  iProduct2 HP Wireless Keyboard Kit
--
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   1
  bInterfaceClass 3 Human Interface Device
  bInterfaceSubClass  1 Boot Interface Subclass
  bInterfaceProtocol  1 Keyboard
[curtine@localhost ~]$ sudo lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
|__ Port 4: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 4: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 7: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 7: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 9: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 9: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M

So, first I added a little logging and then some more, but I can't see
any of it (see patch at bottom of email, I used KERN_EMERG, it's just
temporary logging).

I'm think I'm doing most things right, this is how I compile my code I
wrote a little script (I'm on fedora):

#!/bin/sh

find /boot -name '*4.3*' | xargs sudo rm -rf
find /lib/modules -name '*4.3*' | xargs sudo rm -rf

set -e

cd $HOME/git/linux
# make -j5 oldconfig
printf "completed 1\n"
make -j5 bzImage
printf "completed 2\n"
make -j5 modules
printf "completed 3\n"
sudo make -j5 modules_install
printf "completed 4\n"
sudo make -j5 install

I reboot, load new kernel, blah blah. When I type keys I don't see my
logs in dmesg, I don't see them in /var/log/messages either, I don't
see them in /home/curtine/log.log either when I do a:

sudo killall klogd
sudo /sbin/klogd -f /home/curtine/log.log

What am I doing wrong here?

Also, as regards etiquette on these mailing lists, is it ok to
regularly cc linux-ker...@vger.kernel.org?

diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
index 9a332e6..2038d94 100644
--- a/drivers/hid/usbhid/usbkbd.c
+++ b/drivers/hid/usbhid/usbkbd.c
@@ -112,6 +112,7 @@ struct usb_kbd {

 static void usb_kbd_irq(struct urb *urb)
 {
+   printk(KERN_EMERG "usb_kbd_irq");
struct usb_kbd *kbd = urb->context;
int i;

@@ -166,6 +167,7 @@ resubmit:
 static int usb_kbd_event(struct input_dev *dev, unsigned int type,
 unsigned int code, int value)
 {
+   printk(KERN_EMERG "usb_kbd_event");
unsigned long flags;
struct usb_kbd *kbd = input_get_drvdata(dev);

@@ -202,6 +204,7 @@ static int usb_kbd_event(struct input_dev *dev,
unsigned int type,

 static void usb_kbd_led(struct urb *urb)
 {
+   printk(KERN_EMERG "usb_kbd_led");
unsigned long flags;
struct usb_kbd *kbd = urb->context;

@@ -230,6 +233,7 @@ static void usb_kbd_led(struct urb *urb)

 static int usb_kbd_open(struct input_dev *dev)
 {
+   printk(KERN_EMERG "usb_kbd_open");
struct usb_kbd *kbd = input_get_drvdata(dev);

kbd->irq->dev = kbd->usbdev;
@@ -241,6 +245,7 @@ static int usb_kbd_open(struct input_dev *dev)

 static void usb_kbd_close(struct input_dev *dev)
 {
+   printk(KERN_EMERG "usb_kbd_close");
struct usb_kbd *kbd = input_get_drvdata(dev);

usb_kill_urb(kbd->irq);
@@ -248,6 +253,7 @@ static void usb_kbd_close(struct input_dev *dev)

 static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd)
 {
+   printk(KERN_EMERG "usb_kbd_alloc_mem");
if (!(kbd->irq = usb_alloc_urb(0, GFP_KERNEL)))
return -1;
if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL)))
@@ -264,6 +270,7 @@ static int usb_kbd_alloc_mem(struct usb_device
*dev, struct usb_kbd *kbd)

 static void usb_kbd_free_mem(struct usb_device *dev, struct usb_kbd *kbd)
 {
+   printk(KERN_EMERG "usb_kbd_free_mem");
usb_free_urb(kbd->irq);
usb_free

Re: Problems with printk logs and my driver

[Alan Stern]

On Thu, 24 Sep 2015, Eric Curtin wrote:

> Hi Guys,
> 
> Just wondering what I am doing wrong. I can't see my logs. I figured
> out what driver is used for my keyboard and started adding logging:
> 
> [curtine@localhost ~]$ sudo lsusb -v | grep eyboard -B 13
> Bus 001 Device 003: ID 04ca:008d Lite-On Technology Corp.

...

> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
> |__ Port 4: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
> |__ Port 4: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
> |__ Port 7: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
> |__ Port 7: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
> |__ Port 7: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M

...

> So, first I added a little logging and then some more, but I can't see
> any of it (see patch at bottom of email, I used KERN_EMERG, it's just
> temporary logging).
> 
> I'm think I'm doing most things right, this is how I compile my code I
> wrote a little script (I'm on fedora):

...

> I reboot, load new kernel, blah blah. When I type keys I don't see my
> logs in dmesg, I don't see them in /var/log/messages either, I don't
> see them in /home/curtine/log.log either when I do a:
> 
> sudo killall klogd
> sudo /sbin/klogd -f /home/curtine/log.log
> 
> What am I doing wrong here?

You made a very simple mistake.  See below.

> Also, as regards etiquette on these mailing lists, is it ok to
> regularly cc linux-ker...@vger.kernel.org?

It's okay.  But there's no need to do it if your topic is limited to a 
single subsystem.

> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> index 9a332e6..2038d94 100644
> --- a/drivers/hid/usbhid/usbkbd.c
> +++ b/drivers/hid/usbhid/usbkbd.c
> @@ -112,6 +112,7 @@ struct usb_kbd {
> 
>  static void usb_kbd_irq(struct urb *urb)
>  {
> +   printk(KERN_EMERG "usb_kbd_irq");
> struct usb_kbd *kbd = urb->context;
> int i;
> 
...

Your mistake was thinking that the driver for your keyboard is usbkbd.  
It isn't.  It's usbhid, as you can see in the "lsusb -t" output above.

Even though the source code for usbkbd is located in the usbhid 
directory, they are separate drivers.  Look at the Kconfig file in 
drivers/hid/usbhid and you'll see.

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 v2 1/3] usb: chipidea: core: fix when building without CONFIG_PM support

[Peter Chen]

On Wed, Sep 23, 2015 at 12:56:58PM +0100, Felipe F. Tonello wrote:
> If CONFIG_PM or CONFIG_PM_SLEEP is not set, driver will not compile
> properly.
> 

Would you post the warning or error messages?

I just tried at v4.3-rc1 (v4.2 should be same), without any problems.

Peter
> Signed-off-by: Felipe F. Tonello 
> ---
> 
> Changes for v2:
>  * removed unnecessary #ifdef CONFIG_PM_SLEEP.
> 
>  drivers/usb/chipidea/core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 3ad48e1..382b4af 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -1009,18 +1009,20 @@ static int ci_runtime_resume(struct device *dev)
>   return ci_controller_resume(dev);
>  }
>  
> -#endif /* CONFIG_PM */
>  static const struct dev_pm_ops ci_pm_ops = {
>   SET_SYSTEM_SLEEP_PM_OPS(ci_suspend, ci_resume)
>   SET_RUNTIME_PM_OPS(ci_runtime_suspend, ci_runtime_resume, NULL)
>  };
> +#endif /* CONFIG_PM */
>  
>  static struct platform_driver ci_hdrc_driver = {
>   .probe  = ci_hdrc_probe,
>   .remove = ci_hdrc_remove,
>   .driver = {
>   .name   = "ci_hdrc",
> +#ifdef CONFIG_PM
>   .pm = &ci_pm_ops,
> +#endif
>   },
>  };
>  
> -- 
> 2.1.4
> 

-- 

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

Re: [PATCH 3/3] usb: gadget: f_midi: free request when usb_ep_queue fails

[Peter Chen]

On Wed, Sep 23, 2015 at 12:40:46PM +0100, Felipe Tonello wrote:
> Hi Peter,
> 
> On Wed, Sep 23, 2015 at 8:09 AM, Peter Chen  wrote:
> > On Tue, Sep 22, 2015 at 07:59:10PM +0100, Felipe F. Tonello wrote:
> >> This fix a memory leak that will occur in this case.
> >>
> >> Signed-off-by: Felipe F. Tonello 
> >> ---
> >>  drivers/usb/gadget/function/f_midi.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/gadget/function/f_midi.c 
> >> b/drivers/usb/gadget/function/f_midi.c
> >> index e92aff5..e6a114b 100644
> >> --- a/drivers/usb/gadget/function/f_midi.c
> >> +++ b/drivers/usb/gadget/function/f_midi.c
> >> @@ -550,9 +550,11 @@ static void f_midi_transmit(struct f_midi *midi, 
> >> struct usb_request *req)
> >>   int err;
> >>
> >>   err = usb_ep_queue(ep, req, GFP_ATOMIC);
> >> - if (err < 0)
> >> + if (err < 0) {
> >>   ERROR(midi, "%s queue req: %d\n",
> >> midi->in_ep->name, err);
> >> + free_ep_req(ep, req);
> >> + }
> >>   } else {
> >>   free_ep_req(ep, req);
> >>   }
> >> --
> >> 2.1.4
> >>
> >
> > I may know your problem, current midi library, alsa and this driver
> > allow device sends as much data as possible, but without block the
> > sending until host reads data, it only allocates the request buffer
> > (using midi_alloc_ep_req), but without free, so after you send
> > enough data, it is out of memory.
> 
> Yes. Also there is the case where the usb cable is not conected, thus
> failing to hardware enqueue the request, causing a memory leak on this
> request.
> 

If the usb cable is not connected, the related endpoints should be
not enabled. Would you really observe enqueue the request without
cable connected?

-- 

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

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

[Peter Chen]

On Wed, Sep 23, 2015 at 01:01:44PM +0100, Felipe F. Tonello wrote:
> req->actual == req->length means that there is no data left to enqueue,
> so free the request.
> 
> Signed-off-by: Felipe F. Tonello 
> ---
> 
> Changes in v2:
>  * Re enqueue not fully completed requests, instead of read ALSA buffers.
> 
>  drivers/usb/gadget/function/f_midi.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_midi.c 
> b/drivers/usb/gadget/function/f_midi.c
> index edb84ca..62356cf 100644
> --- a/drivers/usb/gadget/function/f_midi.c
> +++ b/drivers/usb/gadget/function/f_midi.c
> @@ -256,10 +256,12 @@ f_midi_complete(struct usb_ep *ep, struct usb_request 
> *req)
>   /* We received stuff. req is queued again, below */
>   f_midi_handle_out_data(ep, req);
>   } else if (ep == midi->in_ep) {
> - /* Our transmit completed. See if there's more to go.
> -  * f_midi_transmit eats req, don't queue it again. */
> - f_midi_transmit(midi, req);
> - return;
> + /* Our transmit completed. If there is no more to go,
> +don't queue it again. */
> + if (req->actual == req->length) {
> + free_ep_req(ep, req);
> + return;
> + }

I find f_midi_transmit will judge if there are more data, if without
data, it will free the request.

Besides, does one trigger only do one transfer? Sorry, I can't make my
aplaymidi to receive data, probably due to hardware without midi
support?

root@imx6qpsabreauto:~# aplaymidi
ALSA lib
/var/lib/jenkins/workspace/fido-3.14.28-X11-consolidated_new/temp_build_dir/build_all/tmp/work/cortexa9hf-vfp-neon-mx6qdl-poky-linux-gnueabi/alsa-lib/1.0.28-r0/alsa-lib-1.0.28/src/seq/seq_hw.c:457:(snd_seq_hw_open)
open /dev/snd/seq failed: No such file or directory
Cannot open sequencer - No such file or directory

-- 

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

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

[John Youn]

On 9/10/2015 6:14 PM, Scott Branden wrote:
> This patch contains a fix for a real world interop problem found
> when using the Synopsis DWC2 USB controller with isochronous audio as
> detailed in the commit message.
> 
> Changes from v2:
>  - created s2c_hsotg_chage_ep_iso_parity function to call function in 3 
> places in code
>  - used hsotg->num_of_eps instead of MAX_EPS_CHANNELS
> 
> Changes from v1:
>  - Address code review comments as per previous responses:
>  - renamed parity_set to has_correct_parity and reorder some logic
> 
> 
> Roman Bacik (1):
>   usb: dwc2: gadget: parity fix in isochronous mode
> 
>  drivers/usb/dwc2/core.h   |  1 +
>  drivers/usb/dwc2/gadget.c | 58 
> ++-
>  drivers/usb/dwc2/hw.h |  1 +
>  3 files changed, 54 insertions(+), 6 deletions(-)
> 

This seems to break slave mode on my platform. It seems to be
dropping a lot of packets. I tried bInterval=4,5,6, ISO OUT.
I'll need to take a closer look to determine why. Probably later
this week.

Are you able to run in slave mode on your platform? If so can you
try it out?

Regards,
John

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

Re: Problems with printk logs and my driver

[Jiri Kosina]

On Wed, 23 Sep 2015, Alan Stern wrote:

> Your mistake was thinking that the driver for your keyboard is usbkbd.  
> It isn't.  It's usbhid, as you can see in the "lsusb -t" output above.

As Eric is absolutely not the first person ever who got confused by this 
(and I can certainly understand the reasons for this confusion), I've been 
thinking for quite some time already about renaming this driver (and 
usbmouse as well). We'd probably want to make obvious from the name that 
this isn't regular usb keyboard driver.

Any opinions on usbkbd-simple or usbkbd-dummy? The most accurate would of 
course be usbkbd-boot, but that might be equally confusing.

The drawback I can see in renaming the driver is various embedded folks 
having he name hardcoded in their scripts.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

[Clemens Ladisch]

Peter Chen wrote:
> I can't make my aplaymidi to receive data

> # aplaymidi
> open /dev/snd/seq failed: No such file or directory

modprobe snd-seq

There are mechanisms to load it automatically, but your embedded system
might not bother about any of them.  Or CONFIG_SND_SEQUENCER isn't
enabled at all.

In any case, raw MIDI (with the amidi tool) should work.


Regards,
Clemens
--
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