Florian Bruhin m...@the-compiler.org writes:
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
On 05/22/15 09:37, Arend van Spriel wrote:
On 05/22/15 02:21, Laura Abbott wrote:
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
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
I am trying to get the full-speed USB host working on an custom AM3517
device with the 3.18.12 kernel. The hardware works (a 2.6.37 kernel has
been used for testing).
Does anyone have any experience of 3.18 (or similarly recent kernel on
an AM3517 system) or have any pointers as where to start
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)
and assert the HostDisconnect signal to the Controller to indicate a
disconnection event.
When the
On Thu, May 21, 2015 at 09:54:20AM +, Peter Chen wrote:
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
On 05/22/15 02:21, Laura Abbott wrote:
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?
On 05/22/2015 02:46 PM, Lu, Baolu wrote:
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
On Thu, May 21, 2015 at 7:51 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
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.
[...]
+
From: Fabio Estevam fabio.este...@freescale.com
Since commit 1c6c69525b40 (genirq: Reject bogus threaded irq requests)
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch
From: Fabio Estevam fabio.este...@freescale.com
Since commit 1c6c69525b40 (genirq: Reject bogus threaded irq requests)
threaded IRQs without a primary handler need to be requested with
IRQF_ONESHOT, otherwise the request will fail.
So pass the IRQF_ONESHOT flag in this case.
The semantic patch
This drive works on USB 2.0 but not USB 3.0.
I saw a procedure on here to use this statement in the modprobe.d
directory: options usb-storage quirks=Vendor_ID:Product_ID:u
That did not work.
I get the same response that I did before when plugging it into a USB
3.0 port.
May 22 18:16:45 (none)
Hi,
On Fri, May 22, 2015 at 11:13:22PM +0300, Ben Dooks wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/05/15 16:50, Felipe Balbi wrote:
Hi,
On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
I am trying to get the full-speed USB host working on an custom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/05/15 16:50, Felipe Balbi wrote:
Hi,
On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
I am trying to get the full-speed USB host working on an custom
AM3517 device with the 3.18.12 kernel. The hardware works (a
2.6.37 kernel
On Thu, 21 May 2015, Alan Stern wrote:
I suspect you have not divided up all the actions in the correct way.
Look at everything in hub_port_finish_reset and think carefully about
where each one belongs.
I had taken a very conservative approach to only minimally alter the
behavior
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.
ulpi phy drivers or the ulpi interface providers loading
before the bus registeration.
This patch fixes this load order
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':
renesas_usbhs/mod.c:246:7: warning: 'intenb1' may be used uninitialized in this
function [-Wmaybe-uninitialized]
gcc correctly points to a problem
On Wed, Apr 01, 2015 at 06:29:05PM +0100, Baxter, Jim wrote:
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
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':
renesas_usbhs/mod.c:246:7: warning: 'intenb1' may be used uninitialized in
this function
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..0b0a5e7 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -132,6 +132,10 @@ int ulpi_register_driver(struct ulpi_driver *drv)
if (!drv-probe)
return
The tx_curr_frame_payload field is u32. When we try to calculate a
small negative delta based on it, we end up with a positive integer
close to 2^32 instead. So the tx_bytes pointer increases by about
2^32 for every transmitted frame.
Fix by calculating the delta as a signed long.
Cc: Ben
On Thu, 2015-05-21 at 22:46 +0200, Arend van Spriel wrote:
On 05/21/15 19:32, Takashi Iwai wrote:
Well, if the probe requires the access to a user-space file, it can't
be done during resume. That's the very problem we're seeing now.
The firmware loader can't help much alone if it's a new
Le 17/03/2015 17:15, Boris Brezillon a écrit :
Hello,
This series reworks clock handling in atmel USB host drivers, and while
doing so fixes a regression introduced by 3440ef1 (ARM: at91/dt: fix USB
high-speed clock to select UTMI).
Best Regards,
Boris
Boris Brezillon (5):
USB:
On Fri, May 22, 2015 at 01:16:38PM +0300, Heikki Krogerus wrote:
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..0b0a5e7 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -132,6 +132,10 @@ int ulpi_register_driver(struct
Hi
On 19.05.2015 21:39, Andrew Bresticker wrote:
Hi Mathias,
On Mon, May 4, 2015 at 10:36 AM, Andrew Bresticker
abres...@chromium.org wrote:
xhci_gen_setup() sets the hcd_priv field for the primary HCD, but not
for the shared HCD, requiring xHCI host-controller drivers to set it
between
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)
and assert the HostDisconnect signal to the Controller to indicate
Hi,
On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
I am trying to get the full-speed USB host working on an custom AM3517
device with the 3.18.12 kernel. The hardware works (a 2.6.37 kernel has
been used for testing).
Does anyone have any experience of 3.18 (or similarly recent
Returning non-zero value from ready callback makes ffs instance
return error from writing strings and enter FFS_CLOSING state.
This means that this this function is not truly ready and
close callback will not be called. This commit fix
ffs_ready_callback() to undo all side effects of this function
Originally FFS_FL_CALL_CLOSED_CALLBACK flag has been used to
indicate if we should call ffs_closed_callback().
Commit 4b187fceec3c (usb: gadget: FunctionFS: add devices
management code) changed its semantic to indicate if we should
call ffs_closed() function which does a little bit more.
This
On Fri, May 15, 2015 at 12:09:53AM -0500, Peter E. Berger wrote:
From: Peter E. Berger pber...@brimson.com
When using newer Edgeport devices such as the EP/416, idle ports are
automatically bounced (disconnected and then reconnected) approximately
every 60 seconds. This breaks programs
On 05/21/2015 06:26 PM, Bastien Nocera wrote:
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 05/22/2015 06:16 AM, Heikki Krogerus wrote:
diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c
index 0e6f968..0b0a5e7 100644
--- a/drivers/usb/common/ulpi.c
+++ b/drivers/usb/common/ulpi.c
@@ -132,6 +132,10 @@ int ulpi_register_driver(struct ulpi_driver
*drv)
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 still not an issue :(
I'd say unnecessary probe
On Fri, May 15, 2015 at 12:09:54AM -0500, Peter E. Berger wrote:
From: Peter E. Berger pber...@brimson.com
The io_ti driver fails to download firmware to Edgeport devices such
as the EP/416, even when the on-disk firmware image
(/lib/firmware/edgeport/down3.bin) is more current than the
On Fri, May 22, 2015 at 03:50:47PM +0800, Lu, Baolu wrote:
On 05/22/2015 02:46 PM, Lu, Baolu wrote:
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
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.
Even though I agree subsys_initcall is
On 22 May 2015 19:22:47 CEST, Ben Hutchings ben.hutchi...@codethink.co.uk
wrote:
On Fri, 2015-05-22 at 13:15 +0200, Bjørn Mork wrote:
The tx_curr_frame_payload field is u32. When we try to calculate a
small negative delta based on it, we end up with a positive integer
close to 2^32 instead.
From: Bjørn Mork bj...@mork.no
Date: Fri, 22 May 2015 13:15:22 +0200
The tx_curr_frame_payload field is u32. When we try to calculate a
small negative delta based on it, we end up with a positive integer
close to 2^32 instead. So the tx_bytes pointer increases by about
2^32 for every
On Fri, 2015-05-22 at 13:15 +0200, Bjørn Mork wrote:
The tx_curr_frame_payload field is u32. When we try to calculate a
small negative delta based on it, we end up with a positive integer
close to 2^32 instead. So the tx_bytes pointer increases by about
2^32 for every transmitted frame.
On Fri, 22 May 2015, Robert Schlabbach wrote:
On Thu, 21 May 2015, Alan Stern wrote:
I suspect you have not divided up all the actions in the correct way.
Look at everything in hub_port_finish_reset and think carefully about
where each one belongs.
I had taken a very conservative
40 matches
Mail list logo
