On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
> ULPI registers it's bus at module_init so if the bus fails to register, the
> module will fail to load and all will be well in the world.
>
> However, if the ULPI code is built-in rather than a module, the bus
> initialization may fail
On Sun, May 24, 2015 at 12:19:48AM -0700, Greg KH wrote:
> On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
> > ULPI registers it's bus at module_init so if the bus fails to register, the
> > module will fail to load and all will be well in the world.
> >
> > However, if the ULPI code
Why do we even need that? If you take patch that makes ulpi_init a
subsys_initcall you won't have this problem, and no additional weird
hacks and errors will be needed
On Sun, May 24, 2015 at 11:09 AM, Sudip Mukherjee
wrote:
> On Sun, May 24, 2015 at 12:19:48AM -0700, Greg KH wrote:
>> On Wed, Ma
On Thu, May 21, 2015 at 08:11:27PM -0700, David Cohen wrote:
> On Thu, May 21, 2015 at 08:09:54PM -0700, David Cohen wrote:
> > Hi,
> >
> > On Fri, May 22, 2015 at 10:07:05AM +0800, Lu Baolu wrote:
> > > Many drivers and modules depend on ULPI bus registeration to
> > > register ULPI interfaces an
On Thu, May 21, 2015 at 04:57:52PM +0800, Lu Baolu wrote:
> ULPI registers its bus at module_init, so if the bus fails to register, the
> module will fail to load and all will be well in the world.
>
> However, if the ULPI code is built-in rather than a module, the bus
> initialization may fail, b
Aww, that's too bad. Let me know if you'd like me to test a modified version
when you get the time.
--Mike Mammarella
On May 21, 2015, at 4:18 AM, Mathias Nyman wrote:
> Hi
>
> The fix went upstream, but caused regression for other users, and had to be
> reverted.
> The cause of the regressio
On Fri, May 22, 2015 at 11:33:57AM +, Yoshihiro Shimoda wrote:
> Hi Arnd,
>
> > Sent: Friday, May 22, 2015 8:07 PM
> >
> > After the renesas_usbhs driver is enabled in ARM multi_v7_defconfig,
> > we now get a new warning:
> >
> > renesas_usbhs/mod.c: In function 'usbhs_interrupt':
> > renesa
Hello,
> I see your point and what you have done in patches.
> I'm only showing you that you may achieve almost the same effect
> without any changes in kernel.
I tested wstunnel.
The performance comparison in my environment is as following.
Round trip time of keyboard key down and up URBs at ho
> >>>
> >>> FunctionFS is very specific, because read/write operations are
> >>> directly translated into USB requests, which are asynchronous, so
> >>> you cannot use O_NONBLOCK.
> >>>
> >>> If you need non-blocking API you can use Asynchronous I/O (AIO). You
> >>> can find some examples in kern
> -Original Message-
> From: Greg KH [mailto:g...@kroah.com]
> Sent: Monday, September 29, 2014 11:56 AM
> To: Badola Nikhil-B46172
> Cc: linux-usb@vger.kernel.org
> Subject: Re: [PATCH] drivers: usb :fsl: Add support for USB controller
> version-
> 2.5
>
> On Mon, Sep 29, 2014 at 03:46:0
On 05/23/2015 12:08 AM, David Cohen wrote:
Hi,
On Fri, May 22, 2015 at 07:29:15PM +0800, Lu Baolu wrote:
Phy drivers and the ulpi interface providers depend on the
registeration of the ulpi bus. Ulpi registers the bus in
module_init(). This could result in a load order issue, i.e.
It's stil
On Fri, May 22, 2015 at 10:06 PM, Alan Stern wrote:
> On Fri, 22 May 2015, Rong Wang wrote:
>
>> Hi,
>>
>> We have one USB 2.0 Controller on an ARM SoC, with internal PHY
>> confirming to UTMI.
>> The PHY would detect unexpected disconnect (amplitude of the
>> differential envelop still < 625 mV)
12 matches
Mail list logo
