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..
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
abres...@chromium.org wrote:
On Thu, May 14, 2015 at 12:40 AM, Lee Jones
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 Thu, 2015-05-21 at 09:38 +0200, Krzysztof Opasiak wrote:
On 05/21/2015 09:18 AM, Bastien Nocera wrote:
snip
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 run the
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:
snip
Does one need specific hardware to make this work? This is a
tablet,
so I usually use a USB OTG adapter to plug in
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:
snip
Does one need specific hardware to make this work? This is a
tablet,
so I usually use a USB OTG adapter to plug
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 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:
snip
Does one need specific hardware to make this work? This is a
tablet,
so I
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
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 try to register
On 05/21/2015 05:22 AM, David Cohen wrote:
Hi,
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
A minor comment: s/it's/its/
module will fail to load and all will be well in the world.
However, if the
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 Wed, May 20, 2015 at 4:52 PM, Thierry Reding
thierry.red...@gmail.com 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
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
Android phone in developer mode) on a stock distribution, on a device
that used to run
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
Android phone
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
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
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':
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,
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),
Alan Stern wrote:
Hi Herton,
On Thu, May 21, 2015 at 2:04 PM, Herton R. Krzesinski her...@redhat.com 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
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 r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/Kconfig | 10 ++
drivers/phy/Makefile | 1 +
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 r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/Kconfig | 10 +++
drivers/phy/Makefile |
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 r...@kernel.org
Cc: Kishon Vijay Abraham I kis...@ti.com
---
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.
OK, this may be a stupid idea,
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 successfully loaded in the first
On Mon, May 18, 2015 at 7:59 AM, Tony Lindgren t...@atomide.com 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.
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
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
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
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
On Wed, May 20, 2015 at 10:13 PM, Peter Chen peter.c...@freescale.com
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
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
abres...@chromium.org
We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: Subbaraya Sundeep Bhatta sbha...@xilinx.com
Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support)
Cc: sta...@vger.kernel.org #v3.5+
---
v2 changes:
Added Fixes and Cc in
Fixed the incorrect macro definitions correctly as per databook.
Signed-off-by: Subbaraya Sundeep Bhatta sbha...@xilinx.com
Fixes: b09bb64239c8 (usb: dwc3: gadget: implement Global Command support)
Cc: sta...@vger.kernel.org #v3.5+
---
v2 changes:
Added Fixes and Cc in commit message.
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 we'll
We need to return error to caller if command is not sent to
controller succesfully.
Signed-off-by: Subbaraya Sundeep Bhatta sbha...@xilinx.com
Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver)
Cc: sta...@vger.kernel.org
---
v2 changes:
Added Fixes and Cc in commit message.
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. The check
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. A
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 during
From: Dennis O'Brien dennis.obr...@eqware.net
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
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 patrick.ripha...@xsens.com
Applied, thanks.
Johan
--
To unsubscribe from this list: send the
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 carry out
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
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?
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
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
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_initcall
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 certain
circumstances. A
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 check which udc is enabled.
No
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
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),
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, indeed.
If it's a
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
USB_DWC3 config is the one to enable.
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 android kernel
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
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
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:
Then avoiding the
59 matches
Mail list logo
