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
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 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 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
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
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: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_
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
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
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
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
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, 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
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
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
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,
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,
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
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
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, 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
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 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 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 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 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
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
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
28 matches
Mail list logo
