Hi Balbi,
On Wed, Apr 30, 2014 at 02:58:29PM -0500, Felipe Balbi wrote:
> On Thu, May 01, 2014 at 02:36:08AM -0400, Zhuang Jin Can wrote:
> > At least we should giveback the current request to the
> > gadget. Otherwise, the gadget will be stuck without knowing
> > anything.
> >
> > It was oberved
A further question:
I'm quite sure that the read is supposed to deliver more than 64 bytes, and I
know for sure that the endpoint descriptor specifies a pacaket size of 64
bytes. My understanding is that this is still okay, but that the endpoint is
supposed to split the larger packet up into a
On Wed, Apr 30, 2014 at 03:03:53PM -0500, Felipe Balbi wrote:
> On Thu, May 01, 2014 at 03:16:04AM -0400, Zhuang Jin Can wrote:
> > endpoint.maxburst may be 0 if a gadget doesn't call config_ep_by_speed()
> > to update it from the companion descriptor.
> > And endpoint.maxburst - 1 returns 1b w
> >
> >>
> >> On Wed, Apr 23, 2014 at 10:30 PM, Peter Chen
> >> wrote:
> >>
> >> > Oh, sorry. I forget to send it to Greg yesterday. If you can wait, I
> >> > will send it next time (within two weeks) with other patches, if
> >> > can't, I can send it today.
> >>
> >> Ok, no need to hush. Just w
On Thu, 1 May 2014, Zhuang Jin Can wrote:
> > again, you found a bug on the gadget driver. Fix that. composite.c
> > guarantees that for those functions which don't pass bMaxBurst,
> > gadget->maxburst will be set to *at least* 1.
> >
> I agree the real fix should be in the gadget driver. The pat
On Thu, 1 May 2014, Dave Mielke wrote:
> A further question:
>
> I'm quite sure that the read is supposed to deliver more than 64 bytes, and I
> know for sure that the endpoint descriptor specifies a pacaket size of 64
> bytes. My understanding is that this is still okay, but that the endpoint
On Wed, 30 Apr 2014, Dan Williams wrote:
> > I'm kind of doubtful about this. Remember, if the hub is being reset
> > then it probably isn't working correctly. There's a good chance that
> > asking it to change a port's power level will fail.
> >
> > It would be better if the port suspend and
On Wed, 30 Apr 2014, Vivek Gautam wrote:
> Change to use struct device instead of struct platform_device
> for some static functions.
>
> Signed-off-by: Vivek Gautam
> Cc: Alan Stern
> Acked-by: Jingoo Han
> ---
For all four patches in this series:
Acked-by: Alan Stern
--
To unsubscribe fr
Give me some time (actually some days), I will try this and update you.
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Thursday, May 01, 2014 1:42 AM
> To: Paul Fertser
> Cc: Felipe Balbi; Li Yang-Leo-R58472; linux-usb@vger.kernel.org; linux-
> ker...@vger.kernel.o
On Wed, Apr 30 2014, Alan Stern wrote:
> Okay, good. Below is a patch which I hope will fix your problem. You
> can leave diag1 in place if you want, but remove all the other patches.
Hi Alan,
Yes, it works very well with latest git-kernel (3.15-rc3).
Thanks,
--
Peter
--
To unsub
Hi,
On Thu, May 01, 2014 at 04:44:52PM -0400, Zhuang Jin Can wrote:
> On Wed, Apr 30, 2014 at 02:58:29PM -0500, Felipe Balbi wrote:
> > On Thu, May 01, 2014 at 02:36:08AM -0400, Zhuang Jin Can wrote:
> > > At least we should giveback the current request to the
> > > gadget. Otherwise, the gadget w
Hi,
On Thu, May 01, 2014 at 09:45:17AM -0400, Alan Stern wrote:
> On Thu, 1 May 2014, Zhuang Jin Can wrote:
>
> > > again, you found a bug on the gadget driver. Fix that. composite.c
> > > guarantees that for those functions which don't pass bMaxBurst,
> > > gadget->maxburst will be set to *at le
Hi Vivek,
Please see my comments inline.
On 30.04.2014 07:19, Vivek Gautam wrote:
Add support to consume phy provided by Generic phy framework.
Keeping the support for older usb-phy intact right now, in order
to prevent any functionality break in absence of relevant
device tree side change for
Hi Vivek,
I believe the same comments as for the patch for ohci-exynos apply for
this patch as well.
Best regards,
Tomasz
On 30.04.2014 07:19, Vivek Gautam wrote:
From: Kamil Debski
Add the phy provider, supplied by new Exynos-usb2phy using
Generic phy framework.
Keeping the support for ol
Hello,
I'm trying to run the mainline kernel on my Beaglebone Black and things
are working quite well, apart from USB. There have been a few patches
recently that have improved things, but right now I'm at the point where
I could do with a pointer in the right direction.
The main issue now
On Thu, 1 May 2014, Dan Williams wrote:
> > @@ -122,6 +127,11 @@ static int usb_port_runtime_suspend(stru
> > == PM_QOS_FLAGS_ALL)
> > return -EAGAIN;
> >
> > + if (hub->in_reset) {
> > + port_dev->power_is_on = 0;
> > + ret
On Thu, May 1, 2014 at 12:02 PM, Alan Stern wrote:
> On Thu, 1 May 2014, Dan Williams wrote:
>
>> > @@ -122,6 +127,11 @@ static int usb_port_runtime_suspend(stru
>> > == PM_QOS_FLAGS_ALL)
>> > return -EAGAIN;
>> >
>> > + if (hub->in_reset) {
>> > +
On Thu, May 1, 2014 at 12:09 PM, Dan Williams wrote:
> On Thu, May 1, 2014 at 12:02 PM, Alan Stern wrote:
>> On Thu, 1 May 2014, Dan Williams wrote:
>>
>>> > @@ -122,6 +127,11 @@ static int usb_port_runtime_suspend(stru
>>> > == PM_QOS_FLAGS_ALL)
>>> > retu
Hi,
With the following configure options, musb_hdrc and tusb6010 make
dependency loop:
CONFIG_USB_MUSB_HDRC=m
CONFIG_USB_MUSB_TUSB6010=m
CONFIG_USB_TUSB_OMAP_DMA=y
tusb6010.ko provides function `tusb_get_revision` which is used by
tusb6010_omap.o which is a part of musb_hdrc.ko
In its tur
Some OHCI controllers from ATI/AMD seem to have difficulty with
"global" USB suspend, that is, suspending an entire USB bus without
setting the suspend feature for each port connected to a device. When
we try to resume the child devices, the controller gives timeout
errors on the unsuspended ports
On Thu, 1 May 2014, Dan Williams wrote:
> > I'll throw this at the front of my series when resubmitting.
>
> Whoops, this patch is missing its own "Subject:".
Call it: "USB: mutual exclusion for resetting a hub and power-managing
a port".
Alan Stern
--
To unsubscribe from this list: send the l
Hi,
On Thu, May 01, 2014 at 11:13:19PM +0400, Matwey V. Kornilov wrote:
>
> Hi,
>
> With the following configure options, musb_hdrc and tusb6010 make dependency
> loop:
>
> CONFIG_USB_MUSB_HDRC=m
> CONFIG_USB_MUSB_TUSB6010=m
> CONFIG_USB_TUSB_OMAP_DMA=y
>
> tusb6010.ko provides function `tusb_
01.05.2014 23:40, Felipe Balbi пишет:
Hi,
On Thu, May 01, 2014 at 11:13:19PM +0400, Matwey V. Kornilov wrote:
Hi,
With the following configure options, musb_hdrc and tusb6010 make dependency
loop:
CONFIG_USB_MUSB_HDRC=m
CONFIG_USB_MUSB_TUSB6010=m
CONFIG_USB_TUSB_OMAP_DMA=y
tusb6010.ko provi
Hi,
On Thu, May 01, 2014 at 11:44:03PM +0400, Matwey V. Kornilov wrote:
> 01.05.2014 23:40, Felipe Balbi пишет:
> >Hi,
> >
> >On Thu, May 01, 2014 at 11:13:19PM +0400, Matwey V. Kornilov wrote:
> >>
> >>Hi,
> >>
> >>With the following configure options, musb_hdrc and tusb6010 make dependency
> >>l
On Wed, Apr 30, 2014 at 12:16:09PM -0500, Felipe Balbi wrote:
> Hi Greg,
>
> here's my second pull request for this -rc cycle.
>
> Please consider merging to your usb-linux branch.
Pulled and pushed out, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
On Tue, Apr 29, 2014 at 8:12 AM, Alan Stern wrote:
> On Mon, 28 Apr 2014, Dan Williams wrote:
>> ...and as I go to add this I notice that prior to the "use
>> pm_request_resume" suggestion we don't de-reference port_dev->child in
>> usb_port_runtime_resume(). This realization plus the usage count
On Mon, Apr 28, 2014 at 1:29 PM, Alan Stern wrote:
> On Wed, 19 Mar 2014, Dan Williams wrote:
[..]
>> --- a/drivers/usb/core/port.c
>> +++ b/drivers/usb/core/port.c
>> @@ -104,6 +104,8 @@ static int usb_port_runtime_resume(struct device *dev)
>> if (retval < 0)
>>
On Wed, 2014-04-30 at 11:27 -0500, Felipe Balbi wrote:
> On Thu, Apr 24, 2014 at 06:48:11PM +0300, Ivan T. Ivanov wrote:
> > From: Tim Bird
> >
> > Fix the value used for Parallel Transceiver Select (PTS) for the MSM USB
> > controller. This is a standard chipidea PORTSC definition, where
> > a
28 matches
Mail list logo
