pm_runtime_get/put_sync() can sleep so don't hold spinlock while
calling them.
This patch prevents a BUG() during system suspend when
CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
Bug is present in Kernel versions v3.9 onwards.
Reported-by: Tomi Valkeinen
Signed-off-by: Roger Quadros
Tested-by: Tomi V
When we are doing compliance test with xHCI, we found that if we
enable CONFIG_USB_SUSPEND and plug in a bad device which causes
over-current condition to the root port, software will not be noticed.
The reason is that current code don't set hub->change_bits in
hub_activate() when over-current happ
Hi,
On 12/18/2013 04:06 PM, Lee Jones wrote:
>> pm_runtime_get/put_sync() can sleep so don't hold spinlock while
>> calling them.
>>
>> This patch prevents a BUG() when CONFIG_DEBUG_ATOMIC_SLEEP is enabled.
>> Bug is present in Kernel versions v3.9 onwards.
>>
>> Reported-by: Tomi Valkeinen
>> Si
From: "wenlin.kang"
When read data from g_printer, we see a Segmentation fault. eg:
Unable to handle kernel paging request at virtual address bf048000 pgd
= cf038000 [bf048000] *pgd=8e8cf811, *pte=, *ppte=
Internal error: Oops: 7 [#1] PREEMPT ARM Modules linked in: bluetooth
rfco
From: "wenlin.kang"
The problem occurs in follow path.
printer_read()
|
+---setup_rx_reqs()
|
+---usb_ep_queue()
|
+---...
|
+---rx_comp
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70.
The omap-usb-host driver expects the 60MHz functional clock
of the USB host module to be named as "init_60m_fclk".
Add this information in the DT binding document.
CC: Lee Jones
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/mfd/omap-usb-host.txt | 4
The USB PHY gets its clock from AUXCLK3. Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-com
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/pdata-quirks.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/a
USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
reference clock to be named "init_60m_fclk". Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/
Hi Benoit & Tony,
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It depends on the TI Clock DT conversion patches [1] and is based
on 3.13-rc7
[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/289895
Changelog:
v4:
- Updated DT binding document for
On 01/07/2014 08:43 PM, Arnd Bergmann wrote:
> On Tuesday 07 January 2014, Roger Quadros wrote:
>> USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
>> reference clock to be named "init_60m_fclk". Provide this
>> information.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/boo
Hi Greg,
On Tue, Jan 07, 2014 at 08:16:20PM -0800, Greg KH wrote:
>
> A: No.
> Q: Should I include quotations after my reply?
>
> http://daringfireball.net/2007/07/on_top
>
> On Wed, Jan 08, 2014 at 03:49:07AM +, Tang, Jianqiang wrote:
> > Hi,
> > 1) I met this issue one time just boot up
On Tue, Jan 07, 2014 at 07:41:27PM +0800, Conor O'Gorman wrote:
> Hi,
>
> I'm seeing peak rates of about 50 Mbps write speeds, and 150 Mbps read.
> Setup is host AMD SB700/SB800/Hudson-2/3 and Atheros SoC, using testusb
> tool with usbtest module and g_zero gadget module on TI AM335x.
>
> Is th
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Wed, Jan 08, 2014 at 03:49:07AM +, Tang, Jianqiang wrote:
> Hi,
> 1) I met this issue one time just boot up our Linux Platform(Kernel3.10)
> with XHCI driver, then kernel panic happen.
>
>
Great observation,
Sarah located a patch that is queued for the 3.14 kernel and that has a similar
effect. So future kernels could work with that one as well.
The patch I provided (being very small and safe) can still be suggested for
maintainers of older kernels in various long-term maintained
I tried the patch you pointed and it has a similar effect. The cameras work
with it as well.
From: Sarah Sharp [sarah.a.sh...@linux.intel.com]
Sent: Friday, January 03, 2014 15:06
To: Marius Silaghi
Cc: linux-usb@vger.kernel.org
Subject: Re: xHCI driver
Hi,
1) I met this issue one time just boot up our Linux Platform(Kernel3.10) with
XHCI driver, then kernel panic happen.
And this issue reported once by other internal team.
Nothing special of reproduce step and do not need special Hardware I think.
Just random issue which will happen
On Tue, Jan 07, 2014 at 05:44:26PM -0800, David Cohen wrote:
> From: jianqian
>
> There is a possible kernel panic faced on xhci_suspend().
> Due to kernel modified the hub autosupend_delay to 0s, after usb1 root
> hub finishes initialization, it will trigger runtime_suspend and then
> it will tr
On Tue, Jan 07, 2014 at 05:44:26PM -0800, David Cohen wrote:
> From: jianqian
>
> There is a possible kernel panic faced on xhci_suspend().
> Due to kernel modified the hub autosupend_delay to 0s, after usb1 root
> hub finishes initialization, it will trigger runtime_suspend and then
> it will tr
From: jianqian
There is a possible kernel panic faced on xhci_suspend().
Due to kernel modified the hub autosupend_delay to 0s, after usb1 root
hub finishes initialization, it will trigger runtime_suspend and then
it will trigger xhci runtime suspend. But at that time, if
xhci->shared_hcd is stil
On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote:
> On 01/07/2014 01:21 PM, Sarah Sharp wrote:
>
> > Can you please try the attached patch, on top of the previous three
> > patches, and send me dmesg?
>
> Hi Sarah, I just now finished running 0001-More-debugging.patch for the
> first time. T
On Tue, Dec 24, 2013 at 04:19:18AM +, Marius Silaghi wrote:
> From: Marius C Silaghi
>
> This patch is generated against the last kernel version in the github kernel
> repository.
We work off of the git.kernel.org trees, not github :)
> Some older families of USB2 cameras (STC-XUSB)
On Mon, Jan 06, 2014 at 10:10:44AM +0800, Peter Chen wrote:
> From: Chris Ruehl
>
> * init the sts flag to 0 (missed)
> * fix write the real bit not sts value
> * Set PORTCS_STS and DEVLC_STS only if sts = 1
>
> Signed-off-by: Chris Ruehl
> Signed-off-by: Peter Chen
> ---
> drivers/usb/chipid
On Mon, Jan 06, 2014 at 10:10:45AM +0800, Peter Chen wrote:
> From: Chris Ruehl
>
> hw_phymode_configure configures the PORTSC registers and allow the
> following phy_inits to operate on the right parameters. This fix a problem
> where the UPLI (ISP1504) could not be detected, because the Viewpor
On Mon, Jan 06, 2014 at 10:10:42AM +0800, Peter Chen wrote:
> According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
> register error issue", All USB register write operations must
> use the ARM SWP instruction. So, we implement special hw_write
> and hw_test_and_clear for imx28.
>
> Dis
On Mon, Jan 06, 2014 at 10:10:41AM +0800, Peter Chen wrote:
> According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
> register error issue", All USB register write operations must
> use the ARM SWP instruction. So, we implement a special ehci_write
> for imx28.
>
> Discussion for it at
On Mon, Jan 06, 2014 at 09:42:26AM +0100, Marc Kleine-Budde wrote:
> Hello Peter and Greg,
>
> On 01/06/2014 03:10 AM, Peter Chen wrote:
> > According to Freescale imx28 Errata, "ENGR119653 USB: ARM to USB
> > register error issue", All USB register write operations must
> > use the ARM SWP instru
On Tue, Jan 07, 2014 at 02:21:08PM -0800, Dan Williams wrote:
> On Tue, Jan 7, 2014 at 1:58 PM, Greg KH wrote:
> > On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote:
> >> Alan, Sarah,
> >>
> >> This revision boils down the port power control fixes to the
> >> bare minimum to get the imp
On Sat, 2014-01-04 at 11:27 -0500, Alan Stern wrote:
> On Fri, 3 Jan 2014, James Bottomley wrote:
>
> > > I'm still concerned about one thing. The previous patch does this in
> > > scsi_alloc_target():
> > >
> > > > found:
> > > > - found_target->reap_ref++;
> > > > + if (!kref_get
On Tue, Jan 07, 2014 at 12:00:00PM -0800, walt wrote:
> Okay, I used log_buf_len to make dmesg bigger and now I think I have
> the whole thing. It's attached.
Walt, can you make sure the patch I sent you was applied? The output
doesn't look like it is.
Sarah Sharp
--
To unsubscribe from this li
On Tue, Jan 07, 2014 at 11:03:00AM +0100, Takashi Iwai wrote:
> At Mon, 06 Jan 2014 14:34:28 +0200,
> Denis Turischev wrote:
> >
> > Hi Sarah,
> >
> > On 01/03/2014 02:03 AM, Sarah Sharp wrote:
> > > Denis, do all of Compulab's Haswell systems reboot on shutdown? Are
> > > they all running a Pho
On Tue, Jan 7, 2014 at 1:58 PM, Greg KH wrote:
> On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote:
>> Alan, Sarah,
>>
>> This revision boils down the port power control fixes to the
>> bare minimum to get the implementation functional and reliable.
>> Data structure changes are constra
On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote:
> Alan, Sarah,
>
> This revision boils down the port power control fixes to the
> bare minimum to get the implementation functional and reliable.
> Data structure changes are constrained to struct usb_port and
> gone are the clumsier at
On Tue, Jan 07, 2014 at 01:45:29PM -0800, Julius Werner wrote:
> >> I'd like to know if this is going to be considered for merge or if
> >> I'll have to look elsewhere for a solution.
> >
> > It's queued up for 3.14-rc1 (you can always check linux-next for this
> > type of thing...) Do you also ne
On Wed, Dec 25, 2013 at 09:51:28PM -0500, Alan Stern wrote:
> Okay, now we know that usb_enable_interface takes a long time. That
> routine does nothing but call usb_enable_endpoint, which does nothing
> but call usb_hcd_reset_endpoint, which calls the xhci_endpoint_reset
> routine.
>
> So we
>> I'd like to know if this is going to be considered for merge or if
>> I'll have to look elsewhere for a solution.
>
> It's queued up for 3.14-rc1 (you can always check linux-next for this
> type of thing...) Do you also need/want this in older (i.e. stable)
> kernel releases?
Oh right... sorry
On Tue, Jan 07, 2014 at 10:32:08AM -0500, Alan Stern wrote:
> > I think in my case quirk_usb_handoff_xhci is called during boot that
> > will switch the ports to the XHCI.
>
> That's what I said. Early PCI processing occurs during boot.
Sure, I was referring to "run only when the computer is tu
On Tue, Jan 07, 2014 at 01:21:15PM -0800, Julius Werner wrote:
> Hi, has there been any movement on this patch? It happens to fix a problem
> that we have been experiencing with races between authorize/deauthorize and
> device removal.
You are using wireless usb?
> I'd like to know if this is goi
On Tue, Jan 07, 2014 at 01:58:32PM +, David Laight wrote:
> The dmesg contains:
>
> [ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error
> writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
>
> An 8MB transfer will need at least 128 ring entries (TRB
Hi,
On 01/07/2014 10:16 PM, Arnd Bergmann wrote:
On Tuesday 07 January 2014 22:03:11 Hans de Goede wrote:
+
+Optional properties:
+ - clocks: array of clocks
+ - clock-names: clock names "ahb" and/or "ohci"
Where does "ahb" come from, what does it mean, and how is it relevant
to generic platf
Hi, has there been any movement on this patch? It happens to fix a problem
that we have been experiencing with races between authorize/deauthorize and
device removal. I'd like to know if this is going to be considered for merge
or if I'll have to look elsewhere for a solution.
--
To unsubscribe fro
On Tue, Jan 07, 2014 at 05:29:48AM -0800, walt wrote:
> On 01/06/2014 04:31 PM, Sarah Sharp wrote:
> > Hi Walt,
> >
> > I have a couple of patches for you to test.
>
> > Please only apply the first patch (which is diagnostic only), trigger
> > your issue, and send me the resulting dmesg. Then tr
On Tuesday 07 January 2014 22:03:11 Hans de Goede wrote:
> >> +
> >> +Optional properties:
> >> + - clocks: array of clocks
> >> + - clock-names: clock names "ahb" and/or "ohci"
> >
> > Where does "ahb" come from, what does it mean, and how is it relevant
> > to generic platforms?
>
> ahb is an AR
Hi,
On 01/06/2014 04:45 PM, Mark Rutland wrote:
On Sun, Jan 05, 2014 at 11:04:39PM +, Hans de Goede wrote:
Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.
This should
Hi,
On 01/06/2014 04:49 PM, Alan Stern wrote:
On Mon, 6 Jan 2014, Hans de Goede wrote:
Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.
This should allow using ohci-platf
Since reporting this bug I've invested some time to get myself familiar
with USB protocol and analyzed attached capture files. It seems like
device resetoccurs after device returns urb_status=-75 (-EOVERFLOW).
This can be seen in attachment
https://bugzilla.kernel.org/attachment.cgi?id=120901 i
If a port is powered-off, or in the process of being powered-off, prevent
khubd from operating on it. Otherwise, the following sequence of events
leading to an unintended disconnect may occur:
Events:
(0)
(1) hub 2-2:1.0: hub_resume
(2) hub 2-2:1.0: port 1: status 0301 change
(3) hub 2-2:1.
From: Lan Tianyu
describe the mechanisms for controlling port power policy and
discovering the port power state.
Cc: Oliver Neukum
Signed-off-by: Lan Tianyu
Signed-off-by: Sarah Sharp
Signed-off-by: Dan Williams
---
Documentation/usb/power-management.txt | 210 +
Port power testing sometimes result in a port being powered-off while
C_PORT_RESET and C_PORT_LINK_STATE are active. Per the spec these bits
should be automatically cleared by being in the logical powered off
state. Handle this for hubs that do not follow the spec.
Signed-off-by: Dan Williams
-
The port pm_runtime implementation unconditionally clears FEAT_C_ENABLE
after clearing PORT_POWER, but the bit is reserved on usb3 hub ports.
It also takes steps to re-disable the port if it fails to reconnect
which again is broken on usb3 ports and unnecessary on usb2 ports.
Signed-off-by: Dan W
While a device is going through reset-resume khubd may run and trigger a
disconnect since it sees the device not in the suspended state. This does not
happen in the hub_suspend() case because the hub->urb is dead and we clear the
connect status prior to restarting khubd. In the port suspend case
ACPI identifies peer ports by setting their 'group_token' and 'group_position'
_PLD data to the same value. If a platform has tier mismatch (see Appendix D
figure 131 in the xhci spec), ACPI can override the default peer port
association (for internal hubs).
Location data is cached as an opaque c
ClearPortFeature(PORT_POWER) on a usb3 port places the port in either a
DSPORT.Powered-off-detect / DSPORT.Powered-off-reset loop, or the
DSPORT.Powered-off state. There is no way to ensure that RX
terminations will persist in this state, so it is possible a device will
degrade to its usb2 connect
For example:
usb2/2-1/2-1:1.0/port1/peer => ../../../../usb3/3-1/3-1:1.0/port1
usb2/2-1/2-1:1.0/port2/peer => ../../../../usb3/3-1/3-1:1.0/port2
usb2/2-1/2-1:1.0/port3/peer => ../../../../usb3/3-1/3-1:1.0/port3
usb2/2-1/2-1:1.0/port4/peer => ../../../../usb3/3-1/3-1:1.0/port4
usb2/2-0:1.0/port1/pe
Given that root hub port peers are already established external hub peer
ports can be determined by traversing the device topology:
1/ ascend to the parent hub and find the upstream port_dev
2/ walk ->peer to find the peer port
3/ descend to the peer hub via ->child
4/ find the port with the ma
Assume that the peer of a superspeed port is the port with the same id on the
shared_hcd root hub.
This may be a lie if tier mismatch is in effect. Platform firmware can
fix it after the port is registered.
Signed-off-by: Dan Williams
---
drivers/usb/core/hub.c |5
drivers/usb/core/h
Alan, Sarah,
This revision boils down the port power control fixes to the
bare minimum to get the implementation functional and reliable.
Data structure changes are constrained to struct usb_port and
gone are the clumsier attempts at wider reworks from v1 [1] and
v2 [2]. No device model changes t
Okay, I used log_buf_len to make dmesg bigger and now I think I have
the whole thing. It's attached.
dmesg2.gz
Description: application/gzip
On Tue, Jan 07, 2014 at 09:29:30AM +, David Laight wrote:
> > From: 'David Cohen'
> > On Mon, Jan 06, 2014 at 09:26:20AM +, David Laight wrote:
> > > > From: David Cohen
> > > > On Fri, Dec 20, 2013 at 09:26:35AM -, David Laight wrote:
> > > > > > From: David Cohen
> > > > > The effect
On 01/07/2014 05:58 AM, David Laight wrote:
> The dmesg contains:
>
> [ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error
> writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
>
> An 8MB transfer will need at least 128 ring entries (TRB) even if the requ
As of Matt Mooney's major refactoring in 2011, usbip port
option was left out. Add support for this option in
a manner similar to the old implementation.
Sample output:
Imported USB devices
Port 00: at Full Speed(12Mbps)
unknown vendor : unknown product (1687:6211)
On Tue, Jan 07 2014, Marco Zamponi wrote:
> Actually, I was referring to gadgetFS all along.
In that case everything I've written may be inapplicable.
> Shouldn't the usb.c user space application be compliant (e.g. pass all
> the CV Tests) ?
Yes it should.
--
Best regards,
There is a race in the hub driver between hub_disconnect() and
recursively_mark_NOTATTACHED(). This race can be triggered if the
driver is unbound from a device at the same time as the bus's root hub
is removed. When the race occurs, it can cause an oops:
BUG: unable to handle kernel NULL pointe
On Tue, 7 Jan 2014, Du, ChangbinX wrote:
> > > Changbin, after looking more closely I realized there was a second
> > > aspect to this race: recursively_mark_NOTATTACHED uses hub->ports[i]
> > > while hub_disconnect removes the port devices. You ought to be able
> > > to cause an oops by insertin
On Tue, 7 Jan 2014, Holger Hans Peter Freyther wrote:
> On Mon, Jan 06, 2014 at 04:44:51PM -0500, Alan Stern wrote:
>
> > Finally, blacklisting xhci-hcd won't solve the problem at hand, because
> > the ports get switched from EHCI to xHCI during early PCI processing,
> > before xhci-hcd is loaded
On Tue, Jan 07, 2014 at 02:38:36PM +0800, Shen Guang wrote:
> On Tue, Jan 7, 2014 at 11:53 AM, Greg KH wrote:
> > On Tue, Jan 07, 2014 at 11:35:50AM +0800, 沈光 wrote:
> >> On Tue, Jan 7, 2014 at 10:40 AM, Greg KH
> >> wrote:
> >> > On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote:
> >> >> set h
On Tuesday 07 January 2014, Roger Quadros wrote:
> USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
> reference clock to be named "init_60m_fclk". Provide this
> information.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap5.dtsi | 2 ++
> 1 file changed, 2 insertio
The dmesg contains:
[ 538.728064] EXT4-fs warning (device dm-0): ext4_end_bio:316: I/O error
writing to inode 23330865 (offset 0 size 8388608 starting block 812628)
An 8MB transfer will need at least 128 ring entries (TRB) even if the request
is a single contiguous memory block.
Are you using
> From: walt
...
> Thanks Sarah. dmesg0 is from the diagnostic patch only. dmesg1 has all
> three patches applied. Some of the messages in dmesg1 fell off the end of
> the kernel buffer, so I may need to make the buffer larger next time but
> I'll need a reminder of how to do it.
>
> As you sus
From: Wei Yongjun
Remove duplicated include.
Signed-off-by: Wei Yongjun
---
drivers/usb/gadget/s3c-hsotg.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index c0ff1cb..1172eae 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b
From: Wei Yongjun
The variable 'dev' is initialized but never used
otherwise, so remove the unused variable.
Signed-off-by: Wei Yongjun
---
drivers/usb/gadget/gr_udc.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/gadget/gr_udc.c b/drivers/usb/gadget/gr_udc.c
index 5f9c659.
On 01/06/2014 04:31 PM, Sarah Sharp wrote:
> On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
>> With the dmesg, I can finally see what happened:
>>
>> [ 188.703059] xhci_hcd :03:00.0: Cancel URB 8800b7d2e0c0, dev 1, ep
>> 0x2, starting at offset 0xbb7b9000
>> [ 188.703072]
Bjørn Mork [mailto:bj...@mork.no]
> Sent: Monday, January 06, 2014 5:22 PM
> To: Hayeswang
> Cc: oli...@neukum.org; net...@vger.kernel.org; nic_swsd;
> linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org
> Subject: Re: [PATCH net-next v2 6/6] r8152: support RTL8153
[...]
> Exactly the same d
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/pdata-quirks.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/a
The USB PHY gets its clock from AUXCLK3. Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-com
Hi Benoit & Tony,
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board.
It depends on the TI Clock DT conversion patches [1].
[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/289895
cheers,
-roger
Roger Quadros (4):
ARM: dts: OMAP5: Add 60MHz clock refe
USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
reference clock to be named "init_60m_fclk". Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70.
Hello Arnd,
On 07/01/2014 12:54, Arnd Bergmann wrote:
After commit 99f14bd4d1 "Merge 3.13-rc5 into usb-next" (in linux-next as of
today), I'm getting this error building any at91 kernel:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:190:4: error: l
After commit 99f14bd4d1 "Merge 3.13-rc5 into usb-next" (in linux-next as of
today), I'm getting this error building any at91 kernel:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:190:4: error: label 'err' used but not defined
goto err;
^
drive
Hi,
I'm seeing peak rates of about 50 Mbps write speeds, and 150 Mbps read.
Setup is host AMD SB700/SB800/Hudson-2/3 and Atheros SoC, using testusb
tool with usbtest module and g_zero gadget module on TI AM335x.
Is this to be expected?
Is this a limitation of the controllers or the test setup
HI Kishon
On Tue, Jan 7, 2014 at 3:19 PM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Monday 30 December 2013 03:13 PM, Vivek Gautam wrote:
>> Hi Kishon,
>>
>>
>> On Tue, Dec 24, 2013 at 11:15 PM, Kishon Vijay Abraham I
>> wrote:
>>> Hi,
>>>
>>>
>>> On Thursday 05 December 2013 01:44 PM, Vivek
Actually, I was referring to gadgetFS all along. Shouldn't the usb.c
user space application be compliant (e.g. pass all the CV Tests) ?
On Tue, Jan 7, 2014 at 11:10 AM, Michal Nazarewicz wrote:
> On Tue, Jan 07 2014, Marco Zamponi wrote:
>> I am testing now the unchanged usb.c example
>> (www.lin
On Tue, Jan 07 2014, Marco Zamponi wrote:
> I am testing now the unchanged usb.c example
> (www.linux-usb.org/gadget/usb.c) as user space application on my ARM
> Cortex A5 with atmel_usba_udc driver.
Note that usb.c uses GadgetFS *not* FunctionFS. Unfortunately there are
slight incompatibilities
At Mon, 06 Jan 2014 14:34:28 +0200,
Denis Turischev wrote:
>
> Hi Sarah,
>
> On 01/03/2014 02:03 AM, Sarah Sharp wrote:
> > Denis, do all of Compulab's Haswell systems reboot on shutdown? Are
> > they all running a Phoenix BIOS? Can you send me the output of `sudo
> > lspci -vvv -s` for the xHC
Hi,
On Monday 30 December 2013 03:13 PM, Vivek Gautam wrote:
> Hi Kishon,
>
>
> On Tue, Dec 24, 2013 at 11:15 PM, Kishon Vijay Abraham I
> wrote:
>> Hi,
>>
>>
>> On Thursday 05 December 2013 01:44 PM, Vivek Gautam wrote:
>>>
>>> Hi Kishon,
>>>
>>>
>>> On Wed, Dec 4, 2013 at 7:58 PM, Kishon Vij
> From: Of Holger Freyther
> > xhci_hcd does not work with the Canon Lide scanners and has issues
> > with the suspend/resume handling. My Acer Aspire S5 notebook only
> > exposes USB3.0 ports and the distribution kernels generally have
> > xhci_hcd enabled and I don't have any USB3.0 hardware eith
Per dwc3 2.70a spec in the Device-Specific Event (DEVT), the field of
Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits
not 8 bits. And the following reserved field uses [31:25] bits not
[31:24] bits, and it has 7 bits.
So in dwc3_event_devt, the bit mask should be:
event_info
Per dwc3 2.70a spec in the Device-Specific Event (DEVT), the field of
Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits
not 8 bits. And the following reserved field uses [31:25] bits not
[31:24] bits, and it has 7 bits.
So in dwc3_event_devt, the bit mask should be:
event_info
> From: 'David Cohen'
> On Mon, Jan 06, 2014 at 09:26:20AM +, David Laight wrote:
> > > From: David Cohen
> > > On Fri, Dec 20, 2013 at 09:26:35AM -, David Laight wrote:
> > > > > From: David Cohen
> > > > The effect of this change is really to remove the first allocation and
> > > > add 8
> > Changbin, after looking more closely I realized there was a second
> > aspect to this race: recursively_mark_NOTATTACHED uses hub->ports[i]
> > while hub_disconnect removes the port devices. You ought to be able
> > to cause an oops by inserting a delay just after the loop where
> > usb_hub_re
On Tue, Jan 07, 2014 at 12:19:58AM -0800, Dan Williams wrote:
> Hi Holger,
>
> Is there another thread somewhere that details the issues this device
> has with xhci?
The initial report from 2012 is here[1]. I asked again[2] in May 2013
and now in December[3]. From time to time I have issues with
For otgsc, both enable bits and status bits are in it. So we need
to make sure the status bits are not be cleared when write enable
bits. It can fix one bug that we plug in/out Micro AB cable fast,
and sometimes, the IDIS will be cleared wrongly when handle last
ID interrupt (ID 0->1), so the curre
It only happens to me once in a full moon too. Not something I can reproduce at
will.
--
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 http://vger.kernel.org/majordomo-info.html
On Mon, Dec 23, 2013 at 11:21 AM, Holger Hans Peter Freyther
wrote:
> From: Holger Hans Peter Freyther
>
> xhci_hcd does not work with the Canon Lide scanners and has issues
> with the suspend/resume handling. My Acer Aspire S5 notebook only
> exposes USB3.0 ports and the distribution kernels gen
Thank You Michal,
I am testing now the unchanged usb.c example
(www.linux-usb.org/gadget/usb.c) as user space application on my ARM
Cortex A5 with atmel_usba_udc driver.
When I run the Command Verifier, all Tests up to "Interface Descriptor
Test" are passed.
"Endpoint Descriptor Test - Configured
97 matches
Mail list logo
