On Tue, Sep 10, 2013 at 10:18:04AM +0200, Marek Vasut wrote:
> Dear Peter Chen,
>
> > On Mon, Sep 09, 2013 at 04:41:15PM +0200, Marek Vasut wrote:
> > > Dear Peter Chen,
> > >
> >
> > Please see my commit log, the mx6sl-phy has some improvements compared
> > to mx6q-phy.
>
> But they're not yet
On Tue, Sep 10, 2013 at 6:27 PM, Tom Gundersen wrote:
> On Tue, Sep 10, 2013 at 7:31 PM, Alan Stern wrote:
>> On Tue, 10 Sep 2013, Tom Gundersen wrote:
>>
>>> Hi Alan,
>>>
>>> On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern
>>> wrote:
>>> > On Tue, 10 Sep 2013, Tom Gundersen wrote:
>>> >
>>> >> Sup
Hello.
On 09/11/2013 01:30 AM, Tom Gundersen wrote:
Support for specifying soft dependencies in the modules themselves was
introduced in commit 7cb14ba.
Please also specify that commit's summary line in parens.
In Arch we have always been shipping a module.d(5) fragment ordering ohci/uhc
On Tue, Mar 26, 2013 at 5:34 PM, Yinghai Lu wrote:
> On Tue, Mar 26, 2013 at 2:54 PM, Bjorn Helgaas wrote:
>
>> Where are we at with this? I don't see Sarah's patch in the tree, and
>> I haven't applied any changes, so my guess is this is still broken.
>
> Yes, the fix is in the linus tree.
>
>
On Tue, Sep 10, 2013 at 7:31 PM, Alan Stern wrote:
> On Tue, 10 Sep 2013, Tom Gundersen wrote:
>
>> Hi Alan,
>>
>> On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern
>> wrote:
>> > On Tue, 10 Sep 2013, Tom Gundersen wrote:
>> >
>> >> Support for specifying soft dependencies in the modules themselves wa
Support for specifying soft dependencies in the modules themselves was
introduced in commit 7cb14ba.
In Arch we have always been shipping a module.d(5) fragment ordering ohci/uhci
after ehci. If this ordering is really necessary, it would be great to move it
to the kernel and getting the correct f
On Tue, Sep 10, 2013 at 10:44:07AM +0530, navin patidar wrote:
> ret == 0 means success, anything else is failure.
>
Hopefully, it's only returning negative error codes. Otherwise it needs
a different fix.
There isn't an official kernel style on if "if (ret < 0)" is better than
"if (ret)". Som
Yo Rodolfo!
On Tue, 10 Sep 2013 09:31:05 +0200
Rodolfo Giometti wrote:
> I have nothing against with this solution but consider that reporting
> a PPS signal through USB bus may add unknown delays that may vanish
> clock stability... as far as I know you should not use USB serial port
> with PPS
On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
> On 09/09/2013 06:06 AM, Mark Brown wrote:
> >On Sat, Sep 07, 2013 at 07:19:06PM -0500, Daniel Santos wrote:
> >>I have some secondary (and less important) questions about how to
> >>integrate this with device drivers that want a DT /
On Tue, 10 Sep 2013, Tom Gundersen wrote:
> Hi Alan,
>
> On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern wrote:
> > On Tue, 10 Sep 2013, Tom Gundersen wrote:
> >
> >> Support for specifying soft dependencies in the modules themselves was
> >> introduced in commit 7cb14ba.
> >>
> >> In Arch we have a
Hi Johan
Thanks for your quick comments. I hopefully have more time to work on
this code now, so v3 will not take as long as v2 did.
> > All data transfers are made on port0, yet the locks are taken on PortN.
> > urb->context points to PortN, even though the URL is for port0.
>
> You probably me
On Tue, 10 Sep 2013, Tom Gundersen wrote:
> Support for specifying soft dependencies in the modules themselves was
> introduced in commit 7cb14ba.
>
> In Arch we have always been shipping a module.d(5) fragment ordering ohci/uhci
> after ehci. If this ordering is really necessary, it would be gre
Support for specifying soft dependencies in the modules themselves was
introduced in commit 7cb14ba.
In Arch we have always been shipping a module.d(5) fragment ordering ohci/uhci
after ehci. If this ordering is really necessary, it would be great to move it
to the kernel and getting the correct f
On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern wrote:
> Where is MODULE_SOFTDEP defined? It isn't mentioned in any .h files in
> my kernel tree.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7cb14ba75d57910cc4b62115dd5db7bd83c93684
Kay
--
To unsubscribe from this list:
Hi Alan,
On Tue, Sep 10, 2013 at 7:02 PM, Alan Stern wrote:
> On Tue, 10 Sep 2013, Tom Gundersen wrote:
>
>> Support for specifying soft dependencies in the modules themselves was
>> introduced in commit 7cb14ba.
>>
>> In Arch we have always been shipping a module.d(5) fragment ordering
>> ohci/
On Tue, Sep 10, 2013 at 08:24:51AM +0200, Takashi Iwai wrote:
> Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
> mysterious wakeups after shutdown occasionally. After discussing with
> BIOS engineers, they explained that the new BIOS expects that the
> wakeup sources are cleare
On Sat, Sep 07, 2013 at 05:03:52AM +0800, Sarah Sharp wrote:
> On Fri, Sep 06, 2013 at 02:02:04PM -0700, Sarah Sharp wrote:
> > On Fri, Sep 06, 2013 at 06:24:43PM +0800, Huang Rui wrote:
> > > The following patch is required to resolve remote wake issues with
> > > certain devices.
> > >
> > > Iss
On Fri, Sep 06, 2013 at 11:42:09PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2013 at 06:24:44PM +0800, Huang Rui wrote:
> > static void dl_done_list (struct ohci_hcd *);
> > static void finish_unlinks (struct ohci_hcd *, u16);
> > +static inline int root_port_reset (struct ohci_hcd *, un
At Tue, 10 Sep 2013 08:38:50 -0700,
Sarah Sharp wrote:
>
> On Tue, Sep 10, 2013 at 08:24:51AM +0200, Takashi Iwai wrote:
> > Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show
> > mysterious wakeups after shutdown occasionally. After discussing with
> > BIOS engineers, they explai
On Fri, Sep 06, 2013 at 11:37:28PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2013 at 06:24:42PM +0800, Huang Rui wrote:
> > It add a remote wakeup pci quirk for some special AMD platforms. This
> > quirk filters southbridge revision which is 0x39 or 0x3a.
> >
> > Signed-off-by: Huang Rui
On Tue, Sep 10, 2013 at 11:37:44PM +0800, Huang Rui wrote:
> > > +EXPORT_SYMBOL_GPL(usb_amd_remote_wakeup_quirk);
> >
> > Nothing calls this function, so why have you added it here?
> >
> > The way you have broken up the patches is a bit odd. You are creating
> > functions that aren't called yet
On Sat, Sep 07, 2013 at 12:08:27AM +0800, Alan Stern wrote:
> On Fri, 6 Sep 2013, Huang Rui wrote:
>
> > The following patch is required to resolve remote wake issues with
> > certain devices.
> >
> > Issue description:
> > If the remote wake is issued from the device in a specific timing
> > con
On Fri, Sep 06, 2013 at 11:32:51PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2013 at 06:24:41PM +0800, Huang Rui wrote:
> > It adds all issue mice on AMD special platforms for remote wakeup quirk.
> >
> > Some mice with on Pixart controller would trigger remote wakeup quirk on
> > some AM
On Fri, Sep 06, 2013 at 11:32:51PM +0800, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2013 at 06:24:41PM +0800, Huang Rui wrote:
> > It adds all issue mice on AMD special platforms for remote wakeup quirk.
> >
> > Some mice with on Pixart controller would trigger remote wakeup quirk on
> > some AM
usb_function_{de}activate makes it possible to have several "gadget
functions", inside one composite device, to be able to prevent the gadget
to enumerate until an prepared condition has triggered (i.e. userspace
daemon has started)
This patch simplifies and renames the functions to its actual mea
It is required by the OMAP glue driver, but it already depends
on it. The core driver should not depend on it. This will
allow the use of the PCI glue driver again.
Signed-off-by: Heikki Krogerus
---
drivers/usb/dwc3/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/dwc3/Kco
Greetings
I use this medium to inform you that my late client made you a beneficiary to
his Will and Testament, Please kindly contact me immediately to enable me
fufill my late clients wish.
Barr Colin Lee.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a m
Adding the device list from the Windows driver description files
included with a new Qualcomm MDM9615 based device, "Alcatel-sbell
ASB TL131 TDD LTE", from China Mobile. This device is tested
and verified to work. The others are assumed to work based on
using the same Windows driver.
Many of the
Dear Peter Chen,
> On Mon, Sep 09, 2013 at 04:41:15PM +0200, Marek Vasut wrote:
> > Dear Peter Chen,
> >
> > > With the auto setting, the PHY's clock and power can be
> > > recovered correctly from low power mode, it is ganranteed by IC logic.
> > >
> > > Besides, we enable the IC fixes for this
On Tue, Sep 10, 2013 at 03:34:39PM +0800, Peter Chen wrote:
> There is a pending TD which is not freed after request finishes,
> we do this due to a controller bug. This TD needs to be freed when
> the driver is removed. It prints below error message when unload
> chipidea driver at current code:
>
On 09/09/2013 07:45 PM, Johan Hovold wrote:
On Mon, Sep 09, 2013 at 06:01:16PM +0200, Paul Chavent wrote:
Do the same way as in serialcore.c for uart_handle_dcd_change. It
removes duplicated code around the usb_serial_handle_dcd_change calls.
Signed-off-by: Paul Chavent
---
drivers/usb/se
On Mon, Sep 09, 2013 at 06:01:15PM +0200, Paul Chavent wrote:
> Hi.
>
> This series enable the PPS reporting for USB serial devices.
I have nothing against with this solution but consider that reporting
a PPS signal through USB bus may add unknown delays that may vanish
clock stability... as far
Hi.
At the bottom of the description of the patch set, i warn about the
latencies and jitter.
I did "real" test with a pps generated by a workstation (i haven't
tested with a precise pps yet), so the the jitter don't mean anything.
But the magnitude of difference between uart and usb pps is
There is a pending TD which is not freed after request finishes,
we do this due to a controller bug. This TD needs to be freed when
the driver is removed. It prints below error message when unload
chipidea driver at current code:
"ci_hdrc ci_hdrc.0: dma_pool_destroy ci_hw_td, b0001000 busy"
It indi
34 matches
Mail list logo
