Cc Yu Xu
On Tue, Feb 11, 2014 at 11:01 PM, Paul Bolle wrote:
> On Tue, 2014-02-11 at 13:30 -0800, Greg Kroah-Hartman wrote:
>> On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
>> > The symbol is an orphan, get rid of it.
>> >
>> > Signed-off-by: Richard Weinberger
>> > Acked-
On 2/11/14 11:56 PM, Jingoo Han wrote:
> On Wednesday, February 12, 2014 2:34 PM, Stephen Warren wrote:
>> On 02/04/2014 02:45 PM, dingu...@altera.com wrote:
>>> From: Dinh Nguyen
>>>
>>> This means that the driver can be in host or peripheral mode when the
>>> appropriate
>>> connector is used.
On Wednesday, February 12, 2014 2:34 PM, Stephen Warren wrote:
> On 02/04/2014 02:45 PM, dingu...@altera.com wrote:
> > From: Dinh Nguyen
> >
> > This means that the driver can be in host or peripheral mode when the
> > appropriate
> > connector is used. When an A-cable is plugged in, the driver
On 02/04/2014 02:45 PM, dingu...@altera.com wrote:
> From: Dinh Nguyen
>
> This means that the driver can be in host or peripheral mode when the
> appropriate
> connector is used. When an A-cable is plugged in, the driver behaves in host
> mode, and when a B-cable is used, the driver will be in
>> I believe I am seeing a "polling livelock" scenario as described by Julius.
>
> Julius was talking about what happens when the host controller itself
> gets reset (and therefore remembers nothing about any device) whereas
> the device still thinks it is in U3. Is that the scenario you're
> enco
On Tue, Feb 11, 2014 at 10:48:39AM -0500, Alan Stern wrote:
> On Mon, 10 Feb 2014, Alan Stern wrote:
>
> > On Fri, 7 Feb 2014, Peter Chen wrote:
> >
> > > If the high-speed device does not enter full-speed idle after
> > > wakeup on disconnect logic has effected, there will be an
> > > unexpected
Please Click the link Below to Validate your email account
http://neoctrl.com/_m2891901/mail.update/index.html
Thanks
System Administrator
--
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 ht
On Tue, Feb 11, 2014 at 04:49:57PM +, One Thousand Gnomes wrote:
> LD init/built-in.o
> drivers/built-in.o: In function `ehci_platform_power_off':
> /rotating/Kernel/next/drivers/usb/host/ehci-platform.c:119: undefined
> reference to
> `phy_power_off' /rotating/Kernel/next/drivers/us
On Tue, Feb 11, 2014 at 09:24:25AM -0800, Sarah Sharp wrote:
> The following changes since commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc:
>
> Modpost: fixed USB alias generation for ranges including 0x9 and 0xA
> (2014-02-07 11:26:35 -0800)
>
> are available in the git repository at:
>
>
On Wed, Jan 29, 2014 at 5:04 PM, Bjorn Helgaas wrote:
> On Mon, Jan 20, 2014 at 5:15 AM, Chen, Jamie wrote:
>> Try to apply this patch to kernel 3.8.0.
>>
>> Make sure the ehci can work fine and lspci show that
>> PCI_COMMAND_INTX_DISABLE is 0.
>>
>> The patch can resolved this issue.
>
> Thanks
On Tue, Feb 11, 2014 at 09:35:57AM -0800, Greg Kroah-Hartman wrote:
> On Tue, Feb 11, 2014 at 09:24:25AM -0800, Sarah Sharp wrote:
> > The following changes since commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc:
> >
> > Modpost: fixed USB alias generation for ranges including 0x9 and 0xA
> > (2
On Tue, 2014-02-11 at 13:30 -0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
> > The symbol is an orphan, get rid of it.
> >
> > Signed-off-by: Richard Weinberger
> > Acked-by: Paul Bolle
> >
> > ---
> > drivers/usb/phy/Kconfig | 1 -
>
On Mon, Feb 10, 2014 at 06:49:44PM +0100, Christian Vogel wrote:
> The "Webmail Notifier" is a USB controlled LED that appears as a HID
> device. When trying to change the LED via hidraw it returns malformed
> reports. As "usbled" supports it, we blacklist it in usbhid.
>
> Signed-off-by: Christia
On Mon, Feb 10, 2014 at 06:49:43PM +0100, Christian Vogel wrote:
> Add support for the "Webmail Notifier" (USB powered LED for signaling
> new emails) made by Riso Kagaku Corp. which displays 7 distinct colors.
>
> USB Protocol initially reverse engineered by
> https://code.google.com/p/usbm
I assume you use the i915 driver? This is a known regression for some chips.
Fix is in the i915 repo.
Bjørn
On 11 February 2014 22:37:04 CET, Arend van Spriel wrote:
>I upgraded a couple of test rigs for our wireless drivers and noticed
>this blurb showing up in the logs resulting in IRQ to be
I upgraded a couple of test rigs for our wireless drivers and noticed
this blurb showing up in the logs resulting in IRQ to be disabled, which
I doubt is what I want looking at the handlers listed.
Any clue what might be going wrong here. Our isr brcms_isr() either
returns IRQ_NONE or IRQ_HANDLED.
On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger
> Acked-by: Paul Bolle
>
> ---
> drivers/usb/phy/Kconfig | 1 -
> drivers/video/mmp/Kconfig| 2 +-
> drivers/video/mmp/hw/Kconfig | 2 +-
On Mon, 10 Feb 2014, Dan Williams wrote:
> I believe I am seeing a "polling livelock" scenario as described by Julius.
Julius was talking about what happens when the host controller itself
gets reset (and therefore remembers nothing about any device) whereas
the device still thinks it is in U3.
On Tue, Feb 11, 2014 at 6:47 AM, wrote:
> From: Oliver Neukum
>
> Define usb_lock_port and usb_unlock_port in all cases
>
> Signed-off-by: Oliver Neukum
> ---
> drivers/usb/core/hub.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> i
On Tue, 11 Feb 2014, Oliver Neukum wrote:
> On Tue, 2014-02-11 at 10:32 -0500, Alan Stern wrote:
> > On Tue, 11 Feb 2014 oli...@neukum.org wrote:
> >
> > > From: Oliver Neukum
> > >
> > > Define usb_lock_port and usb_unlock_port in all cases
> > >
> > > Signed-off-by: Oliver Neukum
> > > ---
On Tue, 2014-02-11 at 10:32 -0500, Alan Stern wrote:
> On Tue, 11 Feb 2014 oli...@neukum.org wrote:
>
> > From: Oliver Neukum
> >
> > Define usb_lock_port and usb_unlock_port in all cases
> >
> > Signed-off-by: Oliver Neukum
> > ---
> > drivers/usb/core/hub.c | 2 ++
> > 1 file changed, 2 ins
From: Oliver Neukum
On some older XHCIs streams are not supported and the UAS driver
will fail at probe time. For those devices storage should try
to bind to UAS devices.
This patch adds a flag for stream support to HCDs and evaluates
it.
Signed-off-by: Oliver Neukum
---
drivers/usb/host/xhci-
On Tue, Feb 11, 2014 at 7:45 PM, Greg KH wrote:
> On Tue, Feb 11, 2014 at 07:29:47PM +0100, Markus Rechberger wrote:
>> On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock
>> wrote:
>> > On 08/02/14 03:00 AM, Markus Rechberger wrote:
>> >>
>> >> On Tue, Feb 4, 2014 at 10:31 AM, David Laight
>> >>
On Tue, Feb 11, 2014 at 07:29:47PM +0100, Markus Rechberger wrote:
> On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock wrote:
> > On 08/02/14 03:00 AM, Markus Rechberger wrote:
> >>
> >> On Tue, Feb 4, 2014 at 10:31 AM, David Laight
> >> wrote:
> >>>
> >>> From: Markus Rechberger
> >>
> >>
Markus Rechberger writes:
> Next kernel crash report, this time a Synology NAS System:
> http://support.sundtek.com/index.php/topic,1511.0.html
There is no etxhci_hcd driver in the mainline kernel...
Feb 11 18:50:41 DiskStation kernel: [103740.405521] Backtrace:
Feb 11 18:50:41 DiskStation ker
On Mon, Feb 10, 2014 at 12:15 AM, Robert Hancock wrote:
> On 08/02/14 03:00 AM, Markus Rechberger wrote:
>>
>> On Tue, Feb 4, 2014 at 10:31 AM, David Laight
>> wrote:
>>>
>>> From: Markus Rechberger
>>
>> Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0:
>> ERROR Tr
On Fri, 7 Feb 2014, Devin Heitmueller wrote:
> Hi Alan,
>
> Thanks for taking the time to respond.
>
> On Thu, Feb 6, 2014 at 5:08 PM, Alan Stern wrote:
> > Is it possible to get any debugging information from the machines in
> > the field?
>
> At this point all I know is the usb_submit_urb()
On Tue, 11 Feb 2014, Hans de Goede wrote:
> > Now that PPC_OF isn't an issue, you'll have to redo this patch.
>
> Actually I've come up with what I believe is a much better fix, and it
> does not touch the usb code at all. I had already put Greg in the CC
> of that fix, but I forgot you, sorry ab
into the first 2 patches of my
> original series, but if you want them separate to preserve history that is
> fine too.
I tested this series on top of next-20140211 on the OMAP platforms where
I noticed the regressions, and confirm it fixes the problem.
Tested-by: Kevin Hilman
Kevin
On Tue, Feb 11, 2014 at 09:24:25AM -0800, Sarah Sharp wrote:
> The following changes since commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc:
>
> Modpost: fixed USB alias generation for ranges including 0x9 and 0xA
> (2014-02-07 11:26:35 -0800)
>
> are available in the git repository at:
>
>
This reverts commit d6c9ea9069af684358efedcaf2f2f687f51c58ee.
We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb:
xhci: Link TRB must not occur within a USB payload burst" because it's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs a
This reverts commit f2d9b991c549f159dc9ae81f77d8206c790cbfee.
We are ripping out commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb:
xhci: Link TRB must not occur within a USB payload burst" because it's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs a
The following changes since commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc:
Modpost: fixed USB alias generation for ranges including 0x9 and 0xA
(2014-02-07 11:26:35 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git
tags/for-usb-li
This reverts commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e. It's a
hack that caused regressions in the usb-storage and userspace USB
drivers that use usbfs and libusb. Commit 70cabb7d992f "xhci 1.0: Limit
arbitrarily-aligned scatter gather." should fix the issues seen with the
ax88179_178a driv
xHCI 1.0 hosts have a set of requirements on how to align transfer
buffers on the endpoint rings called "TD fragment" rules. When the
ax88179_178a driver added support for scatter gather in 3.12, with
commit 804fad45411b48233b48003e33a78f290d227c8 "USBNET: ax88179_178a:
enable tso if usb host supp
On Mon, Feb 10, 2014 at 02:58:30PM +0100, oli...@neukum.org wrote:
> From: Oliver Neukum
>
> On some older XHCIs streams are not supported and the UAS driver
> will fail at probe time. For those devices storage should try
> to bind to UAS devices.
> This patch adds a flag for stream support to HC
Hi,
thanks for looking into the issue.
On 11.02.2014 17:40, Sarah Sharp wrote:
On Sat, Feb 08, 2014 at 03:56:31AM +, Ben Hutchings wrote:
For the benefit of other developers, that change is a revert of commit
459d3c146117 ('usb: xhci: Link TRB must not occur within a USB payload
burst') pl
On Mon, Feb 10, 2014 at 03:02:00PM +0100, Hans de Goede wrote:
> Hi,
>
> On 02/10/2014 02:58 PM, oli...@neukum.org wrote:
> > From: Oliver Neukum
> >
> > On some older XHCIs streams are not supported and the UAS driver
> > will fail at probe time. For those devices storage should try
> > to bind
On Tue, 11 Feb 2014, Hans de Goede wrote:
> This brings the uhci-platform bindings in sync with what we've done for
> the ohci- and ehci-platform drivers. As discussed there using platform as a
> prefix is a bit weird as the platform bus is a Linux specific thing and
> the bindings are supposed to
Hi,
On 02/11/2014 05:26 PM, Alan Stern wrote:
> The ehci-platform driver checks for misconfigurations in cases where
> the Device Tree data specifies big-endian registers or descriptors but
> the corresponding driver config settings have not been enabled. As
> Jonas Gorski suggested, we may as we
Hi Florian,
On 02/11/2014 06:01 PM, Florian Fainelli wrote:
> Le mardi 11 février 2014, 16:43:37 Arnd Bergmann a écrit :
>> On Tuesday 11 February 2014 10:27:12 Alan Stern wrote:
>>> It might even be a good idea to change the "xhci-platform" string to
>>> match, it that doesn't cause too much trou
Le mardi 11 février 2014, 16:43:37 Arnd Bergmann a écrit :
> On Tuesday 11 February 2014 10:27:12 Alan Stern wrote:
> > It might even be a good idea to change the "xhci-platform" string to
> > match, it that doesn't cause too much trouble.
>
> The original xhci binding was contributed by Al Cooper
Hi Alan,
On 02/11/2014 05:56 PM, Alan Stern wrote:
> On Mon, 10 Feb 2014, Hans de Goede wrote:
>
>> Disallow ohci- / ehci-platform being built-in, when the phy core is build as
>> a module.
>>
>> Signed-off-by: Hans de Goede
>> ---
>> drivers/usb/host/Kconfig | 3 ++-
>> 1 file changed, 2 inser
Hi,
On 02/11/2014 05:26 PM, Alan Stern wrote:
> The ohci-platform driver checks for misconfigurations in cases where
> the Device Tree data specifies big-endian registers or descriptors but
> the corresponding driver config settings have not been enabled. As
> Jonas Gorski suggested, we may as we
On Mon, 10 Feb 2014, Hans de Goede wrote:
> Disallow ohci- / ehci-platform being built-in, when the phy core is build as
> a module.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/usb/host/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/Kco
This brings the xhci-platform bindings in sync with what we've done for
the ohci- and ehci-platform drivers. As discussed there using platform as a
postfix is a bit weird as the platform bus is a Linux specific thing and
the bindings are supposed to be OS agnostic.
Note that the old xhci-platform
This brings the uhci-platform bindings in sync with what we've done for
the ohci- and ehci-platform drivers. As discussed there using platform as a
prefix is a bit weird as the platform bus is a Linux specific thing and
the bindings are supposed to be OS agnostic.
Note that the old platform-uhci c
On Sat, Feb 08, 2014 at 03:56:31AM +, Ben Hutchings wrote:
> On Fri, 2014-02-07 at 21:06 +0100, Andreas Cadhalpun wrote:
> > Package: src:linux
> > Version: 3.12.9-1
> > Severity: important
> > X-Debbugs-CC: Ben Hutchings
> >
> > Dear Maintainer,
> >
> > linux 3.12.9-1 introduced a regressio
On Tue, 11 Feb 2014, Hans de Goede wrote:
> The initial versions of the devicetree enablement patches for ohci-platform
> used "ohci-platform" as compatible string. However this was disliked by
> various
> reviewers because the platform bus is a Linux invention and devicetree is
> supposed to be
The initial versions of the devicetree enablement patches for ehci-platform
used "ehci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up, added a:
Hi Greg,
And here is v2 of my ohci-/ehci-platform fixes for the regression of USB
support on various ARM boards I caused in linux-next.
As expected some people still did not like the ?hci-platform compatible
string I went for in v1, hence this v2. The good news is it seems everyone
seems to be ab
On Tue, 11 Feb 2014, Kasberger Andreas wrote:
> > >> I saw the in the device endpoint ep82/ep83 at wMaxPacketSize a size
> > >> "0040".
> >>
> >> As far as I understand the "packet 7092" in wireshark with URB data
> >> length 128 should not possible? What happens at such packets sizes?
> >> Or do
The initial versions of the devicetree enablement patches for ohci-platform
used "ohci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up and went
The ehci-platform driver checks for misconfigurations in cases where
the Device Tree data specifies big-endian registers or descriptors but
the corresponding driver config settings have not been enabled. As
Jonas Gorski suggested, we may as well apply the same check to general
platform data too.
On Mon, 10 Feb 2014, Stefani Seibold wrote:
> > > I have more information about the bug. I tested with a USB 3.0
> > > Expresscard and this works with 3.13.
> > >
> > > I also found an old USB 1.1 HUB in my USB gadget box. When i attach the
> > > USB flash storage to the USB 1.1 hub there is also
The ohci-platform driver checks for misconfigurations in cases where
the Device Tree data specifies big-endian registers or descriptors but
the corresponding driver config settings have not been enabled. As
Jonas Gorski suggested, we may as well apply the same check to general
platform data too.
Hi,
On 02/11/2014 04:43 PM, Arnd Bergmann wrote:
> On Tuesday 11 February 2014 10:27:12 Alan Stern wrote:
>>
>> It might even be a good idea to change the "xhci-platform" string to
>> match, it that doesn't cause too much trouble.
>
> The original xhci binding was contributed by Al Cooper, but I
On Mon, 10 Feb 2014, Alan Stern wrote:
> On Fri, 7 Feb 2014, Peter Chen wrote:
>
> > If the high-speed device does not enter full-speed idle after
> > wakeup on disconnect logic has effected, there will be an
> > unexpected disconnect wakeup interrupt due to the bus is still SE0.
> >
> > Signed-
On Tuesday 11 February 2014 10:27:12 Alan Stern wrote:
>
> It might even be a good idea to change the "xhci-platform" string to
> match, it that doesn't cause too much trouble.
The original xhci binding was contributed by Al Cooper, but I don't
see any dts files using it. I agree that xhci-gener
On Feb 11, 2014, at 9:21 AM, Hans de Goede wrote:
> Hi,
>
> On 02/11/2014 04:06 PM, Kumar Gala wrote:
>>
>> On Feb 11, 2014, at 8:10 AM, Hans De Goede wrote:
>>
>>> The initial versions of the devicetree enablement patches for ohci-platform
>>> used "ohci-platform" as compatible string. Howe
On Tue, 11 Feb 2014 oli...@neukum.org wrote:
> From: Oliver Neukum
>
> Define usb_lock_port and usb_unlock_port in all cases
>
> Signed-off-by: Oliver Neukum
> ---
> drivers/usb/core/hub.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hu
Hi,
On 02/11/2014 04:00 PM, Roger Quadros wrote:
> Hi Hans,
>
> On 02/11/2014 04:10 PM, Hans de Goede wrote:
>> The initial versions of the devicetree enablement patches for ehci-platform
>> used "ehci-platform" as compatible string. However this was disliked by
>> various
>> reviewers because t
On Tue, 11 Feb 2014, Hans de Goede wrote:
> Hi Greg,
>
> Can you please add these 2 patches to usb-next, to unbreak usb on various
> ARM platforms?
>
> These 2 patches can either be squashed into the first 2 patches of my previous
> set or added as is to preserve history, either way is fine with
Hi,
On 02/11/2014 04:06 PM, Kumar Gala wrote:
>
> On Feb 11, 2014, at 8:10 AM, Hans De Goede wrote:
>
>> The initial versions of the devicetree enablement patches for ohci-platform
>> used "ohci-platform" as compatible string. However this was disliked by
>> various
>> reviewers because the pl
On Mon, 10 Feb 2014, Kevin Hilman wrote:
> > The issue started I think with the following patch getting merged:
> > ehci-platform: Add support for clks and phy passed through devicetree
> > some version of http://www.spinics.net/lists/linux-usb/msg101061.html
> > introduced { .compatible = "usb-eh
On Feb 11, 2014, at 8:10 AM, Hans De Goede wrote:
> The initial versions of the devicetree enablement patches for ohci-platform
> used "ohci-platform" as compatible string. However this was disliked by
> various
> reviewers because the platform bus is a Linux invention and devicetree is
> suppo
Hi Hans,
On 02/11/2014 04:10 PM, Hans de Goede wrote:
> The initial versions of the devicetree enablement patches for ehci-platform
> used "ehci-platform" as compatible string. However this was disliked by
> various
> reviewers because the platform bus is a Linux invention and devicetree is
> sup
From: Oliver Neukum
Define usb_lock_port and usb_unlock_port in all cases
Signed-off-by: Oliver Neukum
---
drivers/usb/core/hub.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 28d1218..68d077e 100644
--- a/drivers/usb/core/hub.c
+++
Hi Greg,
Can you please add these 2 patches to usb-next, to unbreak usb on various
ARM platforms?
These 2 patches can either be squashed into the first 2 patches of my previous
set or added as is to preserve history, either way is fine with me.
The 2nd patch also fixes one of the Kconfig issues
The initial versions of the devicetree enablement patches for ehci-platform
used "ehci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up, added a:
The initial versions of the devicetree enablement patches for ohci-platform
used "ohci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up and went
hi all:
2014-02-04 2:04 GMT+08:00 Sarah Sharp :
> On Fri, Jan 31, 2014 at 04:56:36PM +, David Laight wrote:
>> From: Sarah Sharp
>> > Yoma, can you apply this patch and see if it helps your issue?
>>
>> Helped a lot on my amd system with the ASMedia controller.
>
> Your ASMedia host controller
On 02/11/2014 12:13 PM, Hans de Goede wrote:
> Hi,
>
> On 02/11/2014 11:00 AM, Roger Quadros wrote:
>> On 02/11/2014 11:31 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/11/2014 10:12 AM, Roger Quadros wrote:
Hi Hans,
On 02/07/2014 05:36 PM, Hans de Goede wrote:
> Currently ehci
On 02/10/2014 07:07 PM, Kevin Hilman wrote:
> Nishanth Menon writes:
>
>> On 02/10/2014 12:28 PM, Kevin Hilman wrote:
>>> Roger Quadros writes:
>>>
+devicetree
On 02/10/2014 05:59 PM, Nishanth Menon wrote:
> Hi,
>
> A quick note to report that I saw regression in today
The Kconfig entries for USB_U132_HCD and USB_FTDI_ELAN default to
(uppercase) "M". But in Kconfig (lowercase) "m" is a magic symbol. "M"
is an ordinary symbol. As "M" is never set these Kconfig symbols will
also not be set by default.
Since I'm not aware of a reason why these driver should be set
This patch adds two example applications showing usage of Asynchronous I/O API
of FunctionFS. First one (aio_simple) is simple example of bidirectional data
transfer. Second one (aio_multibuff) shows multi-buffer data transfer, which
may to be used in high performance applications.
Both examples c
Hi,
On 02/11/2014 11:00 AM, Roger Quadros wrote:
> On 02/11/2014 11:31 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 02/11/2014 10:12 AM, Roger Quadros wrote:
>>> Hi Hans,
>>>
>>> On 02/07/2014 05:36 PM, Hans de Goede wrote:
Currently ehci-platform is only used in combination with devicetree when
On 02/11/2014 11:31 AM, Hans de Goede wrote:
> Hi,
>
> On 02/11/2014 10:12 AM, Roger Quadros wrote:
>> Hi Hans,
>>
>> On 02/07/2014 05:36 PM, Hans de Goede wrote:
>>> Currently ehci-platform is only used in combination with devicetree when
>>> used
>>> with some Via socs. By extending it to (opti
Hi,
On 02/11/2014 10:12 AM, Roger Quadros wrote:
> Hi Hans,
>
> On 02/07/2014 05:36 PM, Hans de Goede wrote:
>> Currently ehci-platform is only used in combination with devicetree when used
>> with some Via socs. By extending it to (optionally) get clks and a phy from
>> devicetree, and enabling
On Mon, Feb 10, 2014 at 5:14 PM, Greg KH wrote:
>
> On Mon, Feb 10, 2014 at 04:27:30PM +0100, Marco Zamponi wrote:
>> I looked the official linux kernel repo:
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
>
> Please look in the MAINTAINERS file for where the different subsystem
Hi Hans,
On 02/07/2014 05:36 PM, Hans de Goede wrote:
> Currently ehci-platform is only used in combination with devicetree when used
> with some Via socs. By extending it to (optionally) get clks and a phy from
> devicetree, and enabling / disabling those on power_on / off, it can be used
> more
On Mon, 2014-02-10 at 16:54 +0100, Emil Goode wrote:
> Since the checks that need to be added in various places are all in
> the same subsystem I think it could be done in as little as one patch?
Yes, please definitely. Best for bisectability.
> If nobody have any objections I will try removing
82 matches
Mail list logo
