Thanks for the reply, Alan.
The USB device is initially in link state 0, and only after the "cold"
reset in link state SS.inactive. After the following warm reset, it is
in link state 0 again.
> ... but the code is in the wrong place. The check needs to occur
> before hub_port_finish_reset, not
On Thu, 2015-05-21 at 08:42 +0200, Krzysztof Opasiak wrote:
> On 05/20/2015 06:42 PM, Bastien Nocera wrote:
> > Hey,
> >
> > After discussing this with Andrzej, I'm no closer to being able to
> > get
> > this working...
> >
> > I'm trying to run adbd (the service that would usually run on an
> >
On Wed, May 20, 2015 at 4:52 PM, Thierry Reding
wrote:
> I'm a little confused by the simple-mfd approach. The only code I see in
> linux-next for this is a single line that adds the "simple-mfd" string
> to the OF device ID table in drivers/of/platform.c. As far as I can tell
> this will merely
> >>ULPI registers it's bus at module_init so if the bus fails to register, the
> >A minor comment: s/it's/its/
> >
> >>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 but we'd still
On Thu, May 21, 2015 at 01:40:43PM +0800, Lu Baolu wrote:
> The intention of this change is to fix below kernel panic when
> USB_ULPI_BUS was configured as buildin.
That is actually incorrect. Having the bus build-in does not cause
this panic..
> [0.746856] kernel BUG at drivers/base/driver.c:153
On 05/21/2015 09:18 AM, Bastien Nocera wrote:
On Thu, 2015-05-21 at 08:42 +0200, Krzysztof Opasiak wrote:
On 05/20/2015 06:42 PM, Bastien Nocera wrote:
Hey,
After discussing this with Andrzej, I'm no closer to being able to
get
this working...
I'm trying to run adbd (the service that would
On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote:
> On 05/21/2015 09:18 AM, Bastien Nocera wrote:
> >
> > Does one need specific hardware to make this work? This is a
> > tablet,
> > so I usually use a USB OTG adapter to plug in
> > keyboard/mouse/network,
> > but I unplug all this to
On 05/21/2015 09:50 AM, Bastien Nocera wrote:
On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote:
On 05/21/2015 09:18 AM, Bastien Nocera wrote:
Does one need specific hardware to make this work? This is a
tablet,
so I usually use a USB OTG adapter to plug in
keyboard/mouse/network
On Thu, 2015-05-21 at 09:50 +0200, Bastien Nocera wrote:
> On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote:
> > On 05/21/2015 09:18 AM, Bastien Nocera wrote:
> > >
>
> > > Does one need specific hardware to make this work? This is a
> > > tablet,
> > > so I usually use a USB OTG adapt
On 05/21/2015 10:00 AM, Bastien Nocera wrote:
On Thu, 2015-05-21 at 09:50 +0200, Bastien Nocera wrote:
On Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote:
On 05/21/2015 09:18 AM, Bastien Nocera wrote:
Does one need specific hardware to make this work? This is a
tablet,
so I usual
On 05/21/2015 03:33 PM, Heikki Krogerus wrote:
On Thu, May 21, 2015 at 01:40:43PM +0800, Lu Baolu wrote:
The intention of this change is to fix below kernel panic when
USB_ULPI_BUS was configured as buildin.
That is actually incorrect. Having the bus build-in does not cause
this panic..
[0.
On Thu, 2015-05-21 at 10:09 +0200, Krzysztof Opasiak wrote:
> Could you specify exactly the model?
Onda v975w
> If android is running fine on it you may check android kernel config
> for
> this device and check which udc is enabled.
No kernel sources from this Chinese vendor. But it looks like
On Wed, 20 May 2015, Thierry Reding wrote:
> On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > wrote:
> > > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones
> > > > 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, but we'd still try to register drivers later onto
a non-existent bus,
On 05/21/2015 10:39 AM, Bastien Nocera wrote:
On Thu, 2015-05-21 at 10:09 +0200, Krzysztof Opasiak wrote:
Could you specify exactly the model?
Onda v975w
If android is running fine on it you may check android kernel config
for
this device and check which udc is enabled.
No kernel sources
Today, the API for the extcon drivers was changed, along
with all drivers in drivers/extcon. However, one extcon driver
instead lives in drivers/usb/phy/ and did not get change.
Gcc warns about the now incorrect API usage:
drivers/usb/phy/phy-tahvo.c: In function 'tahvo_usb_probe':
drivers/usb/ph
>
> On Wed, May 20, 2015 at 10:13 PM, Peter Chen
> wrote:
> > On Tue, May 19, 2015 at 09:10:05PM -0500, Rob Herring wrote:
> >> The Marvell 28nm HSIC PHY requires the port to be forced to HS mode
> >> after the port power is applied. This is done using the test mode in
> >> the PORTSC register.
Hi Heikki, Sasha and others,
Please ignore this patch. I should not squash these two patches into one and
sign it off behalf of other people. I apologize for this and I'm sorry
if this lets
you feel affronted.
Thanks,
Baolu
On 05/21/2015 04:57 PM, Lu Baolu wrote:
ULPI registers its bus at m
On Thu, May 21, 2015 at 09:40:01AM +0100, Lee Jones wrote:
> On Wed, 20 May 2015, Thierry Reding wrote:
> > On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> > > On Tue, 19 May 2015, Andrew Bresticker wrote:
> > > > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > > > wrote:
> >
On Thu, May 21, 2015 at 06:07:25PM +0800, Lu, Baolu wrote:
> Hi Heikki, Sasha and others,
>
> Please ignore this patch. I should not squash these two patches into one and
> sign it off behalf of other people. I apologize for this and I'm sorry if
> this lets
> you feel affronted.
No worries. So w
Fixed the incorrect macro definitions correctly as per databook.
Signed-off-by: Subbaraya Sundeep Bhatta
Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support)
Cc: #v3.5+
---
v2 changes:
Added Fixes and Cc in commit message.
drivers/usb/dwc3/core.h |4 ++--
1 fil
We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: Subbaraya Sundeep Bhatta
Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support)
Cc: #v3.5+
---
v2 changes:
Added Fixes and Cc in commit message.
drivers/usb/dwc3/gadget
We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: Subbaraya Sundeep Bhatta
Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver)
Cc:
---
v2 changes:
Added Fixes and Cc in commit message.
drivers/usb/dwc3/gadget.c |2 ++
1 f
Dear Mathias,
just a heads up: retesting with 4.0.4 revealed, that this issue isn't fixed
for my scanner still. To recap: driving the scanner through a ehci port is
fine, and fails miserably with xhci.
OK:
T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 4
D: Ver= 2.00 Cls=09(h
Hi
The fix went upstream, but caused regression for other users, and had to be
reverted.
The cause of the regression was found but the new version was never properly
tested and
got left behind as more urgent issues arrived.
I still need to attend a few other issues before taking up this again
Hi Takashi,
>> The data is cached in RAM. More specifically, the former loaded
>> firmware files are reloaded and saved at suspend for each device
>> object. See fw_pm_notify() in firmware_class.c.
>
> OK, this may be a stupid idea, but do we know the firmware
> was succ
Hi,
On Thursday 14 May 2015 04:18 AM, Rob Herring wrote:
Add driver for USB PHY found in Marvell PXA1928 SOC.
Signed-off-by: Rob Herring
Cc: Kishon Vijay Abraham I
---
drivers/phy/Kconfig | 10 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-mv-usb2.c | 329 ++
At Thu, 21 May 2015 14:07:11 +0200,
Marcel Holtmann wrote:
>
> Hi Takashi,
>
> >> The data is cached in RAM. More specifically, the former loaded
> >> firmware files are reloaded and saved at suspend for each device
> >> object. See fw_pm_notify() in firmware_class.c.
> >
> >>>
Hi,
On Thursday 14 May 2015 04:18 AM, Rob Herring wrote:
Add PHY driver for the Marvell HSIC 28nm PHY. This PHY is found in PXA1928
SOC.
Signed-off-by: Rob Herring
Cc: Kishon Vijay Abraham I
---
drivers/phy/Kconfig | 10 +++
drivers/phy/Makefile | 1 +
drivers/phy/phy-mv-hsi
On Thursday 21 May 2015 06:15 PM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 14 May 2015 04:18 AM, Rob Herring wrote:
Add PHY driver for the Marvell HSIC 28nm PHY. This PHY is found in PXA1928
SOC.
Signed-off-by: Rob Herring
Cc: Kishon Vijay Abraham I
---
drivers/phy/Kconfig |
On Thu, 21 May 2015, Takashi Iwai wrote:
> Then avoiding the failed firmware is no solution, indeed.
> If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during resume under ce
On Thu, 21 May 2015, Robert Schlabbach wrote:
> Thanks for the reply, Alan.
>
> The USB device is initially in link state 0, and only after the "cold"
> reset in link state SS.inactive. After the following warm reset, it is
> in link state 0 again.
>
> > ... but the code is in the wrong place.
Hi Alan,
>> Then avoiding the failed firmware is no solution, indeed.
>> If it's a new probe, it should be never executed during resume.
>
> Can you expand this comment? What's wrong with probing during resume?
>
> The USB stack does carry out probes during resume under certain
> circumstances.
From: Dennis O'Brien
Removes Vernier Software & Technology devices from the ldusb
driver and the hid_ignore_list table of the usbhid driver in the
Linux tree. These devices will now be supported via the hidraw
driver.
A user space driver for these devices will be found in the
Go! Software Deve
On Tue, May 19, 2015 at 10:03:01AM +0200, Patrick Riphagen wrote:
> This adds support for new Xsens device, Motion Tracker Development Board,
> using Xsens' own Vendor ID
>
> Signed-off-by: Patrick Riphagen
Applied, thanks.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linu
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan Stern wrote:
>
> On Thu, 21 May 2015, Takashi Iwai wrote:
>
> > Then avoiding the failed firmware is no solution, indeed.
> > If it's a new probe, it should be never executed during resume.
>
> Can you expand this comment? What's wrong with probing
On Thu, 21 May 2015, Marcel Holtmann wrote:
> Hi Alan,
>
> >> Then avoiding the failed firmware is no solution, indeed.
> >> If it's a new probe, it should be never executed during resume.
> >
> > Can you expand this comment? What's wrong with probing during resume?
> >
> > The USB stack does
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
>
> On Thu, 21 May 2015, Takashi Iwai wrote:
>
> > At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> > Alan Stern wrote:
> > >
> > > On Thu, 21 May 2015, Takashi Iwai wrote:
> > >
> > > > Then avoiding the failed firmware is no solution, ind
On Thu, 2015-05-21 at 11:08 +0200, Krzysztof Opasiak wrote:
> On 05/21/2015 10:39 AM, Bastien Nocera wrote:
> > On Thu, 2015-05-21 at 10:09 +0200, Krzysztof Opasiak wrote:
> > > Could you specify exactly the model?
> >
> > Onda v975w
> >
> > > If android is running fine on it you may check androi
Hi Bastien,
Could you specify exactly the model?
>>>
>>> Onda v975w
>>>
If android is running fine on it you may check android kernel
config
for
this device and check which udc is enabled.
>>>
>>> No kernel sources from this Chinese vendor. But it looks like the
>>> US
On 05/21/15 17:35, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
Then avoiding the failed firmware is no solution
At Thu, 21 May 2015 19:27:41 +0200,
Arend van Spriel wrote:
>
> On 05/21/15 17:35, Takashi Iwai wrote:
> > At Thu, 21 May 2015 11:26:17 -0400 (EDT),
> > Alan Stern wrote:
> >>
> >> On Thu, 21 May 2015, Takashi Iwai wrote:
> >>
> >>> At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> >>> Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
> At Thu, 21 May 2015 11:26:17 -0400 (EDT),
> Alan Stern wrote:
> >
> > On Thu, 21 May 2015, Takashi Iwai wrote:
> >
> > > At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> > > Alan Stern wrote:
> > > >
> > > > On Thu, 21 May 2015, Takashi Iwai wrote:
> > > >
I received a report from an user of following mouse which needs this quirk:
usb 1-1.6: USB disconnect, device number 58
usb 1-1.6: new low speed USB device number 59 using ehci_hcd
usb 1-1.6: New USB device found, idVendor=04f2, idProduct=1053
usb 1-1.6: New USB device strings: Mfr=1, Product=2, S
At Thu, 21 May 2015 13:37:56 -0400 (EDT),
Alan Stern wrote:
>
> On Thu, 21 May 2015, Takashi Iwai wrote:
>
> > At Thu, 21 May 2015 11:26:17 -0400 (EDT),
> > Alan Stern wrote:
> > >
> > > On Thu, 21 May 2015, Takashi Iwai wrote:
> > >
> > > > At Thu, 21 May 2015 10:18:08 -0400 (EDT),
> > > > Ala
On 05/21/2015 11:11 AM, Takashi Iwai wrote:
At Thu, 21 May 2015 13:37:56 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
A
Hi Herton,
On Thu, May 21, 2015 at 2:04 PM, Herton R. Krzesinski wrote:
> I received a report from an user of following mouse which needs this quirk:
>
> usb 1-1.6: USB disconnect, device number 58
> usb 1-1.6: new low speed USB device number 59 using ehci_hcd
> usb 1-1.6: New USB device found, i
Hi,
(this is the first time I'm reporting a but against the kernel - so
please bear with me, and if I'm doing anything wrong or anything is
missing, please let me know!)
I have a Thinkpad x220t with an Ericsson F5521gw WWAN interface,
running Archlinux.
Since updating my kernel from 3.19.3 to 4.
On Thu, 2015-05-21 at 19:08 +0200, Marcel Holtmann wrote:
> Hi Bastien,
>
> > > > > Could you specify exactly the model?
> > > >
> > > > Onda v975w
> > > >
> > > > > If android is running fine on it you may check android
> > > > > kernel
> > > > > config
> > > > > for
> > > > > this device and
On 05/21/15 19:32, Takashi Iwai wrote:
At Thu, 21 May 2015 19:27:41 +0200,
Arend van Spriel wrote:
On 05/21/15 17:35, Takashi Iwai wrote:
At Thu, 21 May 2015 11:26:17 -0400 (EDT),
Alan Stern wrote:
On Thu, 21 May 2015, Takashi Iwai wrote:
At Thu, 21 May 2015 10:18:08 -0400 (EDT),
Alan Ster
On Mon, May 18, 2015 at 7:59 AM, Tony Lindgren wrote:
> [PATCH] dmaengine: omap-dma: Add support for memcpy
Hi Tom,
To follow up on your corresponding mail to the gumstix list [1], I
tried on the 3.17.8 kernel on an Overo COM (DM37390) with the
suggested dmaengine patch applied. Using "hdparm -
On 05/21/2015 08:26 AM, Alan Stern wrote:
On Thu, 21 May 2015, Marcel Holtmann wrote:
Hi Alan,
Then avoiding the failed firmware is no solution, indeed.
If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
Th
Many drivers and modules depend on ULPI bus registeration to
register ULPI interfaces and drivers. It's more appropriate
to register ULPI bus in subsys_initcall instead of module_init.
Kernel panic has been reported with some kind of kernel config.
[0.746856] kernel BUG at drivers/base/driver.c:1
Dear Felipe,
If you review this patch, I'll apply it on extcon tree.
Best Regards,
Chanwoo Choi
On 05/21/2015 06:39 PM, Arnd Bergmann wrote:
> Today, the API for the extcon drivers was changed, along
> with all drivers in drivers/extcon. However, one extcon driver
> instead lives in drivers/usb/
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 and drivers. It's more appropriate
> to register ULPI bus in subsys_initcall instead of module_init.
>
> Kernel panic has been reported with some
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 and drivers. It's more appropriate
> > to register ULPI bus in subsys_initc
Hi Laura,
> Then avoiding the failed firmware is no solution, indeed.
> If it's a new probe, it should be never executed during resume.
Can you expand this comment? What's wrong with probing during resume?
The USB stack does carry out probes during resume under certa
On 05/22/2015 11:11 AM, 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 and drivers. It's more appropriate
to re
58 matches
Mail list logo
