From: Peter Stuge
> But what about that alignment? It seems that userspace
> needs to start caring about alignment with xhci, right?
No because there is a copy_to/from_user() in the middle.
The ehci/ohci/uhci all require that fragments be a multiple of the
usb message size (512 bytes for USB2).
S
On 01/30/2014 04:30 PM, Peter Stuge wrote:
> Robert Baldyga wrote:
>> v3:
> ..
>> +++ b/tools/usb/aio_multibuff/host_app/Makefile
>> @@ -0,0 +1,13 @@
>> +CC = gcc
>> +LIBUSB_CFLAGS = $(shell pkg-config --cflags libusb-1.0)
>> +LIBUSB_LIBS = $(shell pkg-config --libs libusb-1.0)
>> +WARNINGS = -Wall
On 01/30/2014 11:40 AM, David Laight wrote:
> From: Robert Baldyga
> This patch adds two example applications showing usage of Asynchronous I/O API
>> of FunctionFS. First one (aio_simple) is simple example of bidirectional data
>> transfer. Second one (aio_multibuff) shows multi-buffer data transf
From: Sarah Sharp
> We need to step back and reassess the larger picture here, instead of
> trying to fire-fight all the regressions caused by the link TRB commit
> (35773dac5f86 "usb: xhci: Link TRB must not occur within a USB payload
> burst").
Some of the breakage seems to have been related to
The Keystone PM management layer has been implemented using PM bus for
power management clocks. As result, most of Keystone drivers don't need
to manage clocks directly. They just need to enable runtime PM and use it
to handle their PM state and clocks.
Hence, remove clock management code and swit
David Laight wrote:
> > We shouldn't need to make userspace start to worry about alignment at
> > all. libusb worked in the past, before the link TRB fix went in. We
> > *cannot* break userspace USB drivers. The breakage needs to be fixed in
> > the USB core or the xHCI driver.
>
> Userspace do
From: Peter Stuge [mailto:pe...@stuge.se]
> > Userspace doesn't care since everything gets copied into aligned
> > kernel fragments - otherwise the other usb controllers wouldn't work.
>
> OK, but not so great if someone wants to squeeze the most performance
> possible out of USB also from userspa
Using the userspace test application ffs-test.c with the g_ffs module
I noticed that the "iInterface" field in the Interface descriptor
often has a zero value (Shown on the host side) which leads to the
corresponding language string not being shown. In my tests values
ranged from 0x09 to 0x0C, but
On Friday 31 January 2014 08:20 AM, Grygorii Strashko wrote:
> The Keystone PM management layer has been implemented using PM bus for
> power management clocks. As result, most of Keystone drivers don't need
> to manage clocks directly. They just need to enable runtime PM and use it
> to handle the
Some further digging suggests that there was support for the MAX3421 in a
couple of Linux based satellite receivers, specficially the IpBox 250s
and DGStation Mutant-200s
The producer of the later was even subject to a GPL violation and
resolution where they made a kernel patch available, althoug
Hi,
On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
> The Keystone PM management layer has been implemented using PM bus for
> power management clocks. As result, most of Keystone drivers don't need
> to manage clocks directly. They just need to enable runtime PM and use it
> to
From: Sarah Sharp
> On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
> > FWIW, the plan looks fine to me. Just adding a couple of hints to
> > simplify the implementation.
> >
> > Sarah Sharp writes:
> >
> > > Let's do this fix the right way, instead of wall papering over the
> > > iss
Sarah,
On Fri, Jan 31, 2014 at 2:29 AM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Using module_platform_driver() can make the code simpler.
>
> Signed-off-by: Fabio Estevam
> ---
> Build-tested only
>
> Changes since v1:
> - Mark the patch as 1/2
>
> drivers/usb/host/xhci-plat.c | 11 +---
On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
>> The Keystone PM management layer has been implemented using PM bus for
>> power management clocks. As result, most of Keystone drivers don't need
>> to manage clo
On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
> >> The Keystone PM management layer has been implemented using PM bus for
> >> power man
On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
>> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
The Keystone PM management
In order to get an ASMedia xhci controller to even detect a device
being inserted I had to split the writeq() and readq().
The following patch is sufficient on amd64.
I've not yet tried to make the ax88179 card work.
David
[PATCH] xhci: Do not use 64bit accesses to the controller registe
On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
> > On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
> >> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Fri, Jan 31, 2014
From: Sarah Sharp
> Yoma, can you apply this patch and see if it helps your issue?
Helped a lot on my amd system with the ASMedia controller.
David
...
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 64ea21971be2..74a69b887346 100644
> > --- a/drivers/usb/core/
From: David Laight
> From: Sarah Sharp
> > Yoma, can you apply this patch and see if it helps your issue?
>
> Helped a lot on my amd system with the ASMedia controller.
I lied :-)
Sometimes it is detected at 480MB - in which case it comes up immediately.
Other times it is detected at 5000MB and
Hi,
On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> The DWC2 driver should now be in good enough shape to move out of
> staging. I have stress tested it overnight on RPI running mass
> storage and Ethernet transfers in parallel, and for several days
> on our proprietary PCI-based
Hi,
On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
> Hi,
>
> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> > The DWC2 driver should now be in good enough shape to move out of
> > staging. I have stress tested it overnight on RPI running mass
> > storage and Ethe
On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
> > Hi,
> >
> > On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> > > The DWC2 driver should now be in good enough shape to move out of
> > > stagi
On Thu, Jan 30, 2014 at 09:32:49PM -0500, Mark Lord wrote:
> On 14-01-30 06:26 PM, Sarah Sharp wrote:
> > On Thu, Jan 30, 2014 at 05:20:40PM -0500, Mark Lord wrote:
> >> On 14-01-30 04:41 PM, Sarah Sharp wrote:
> >>>
> >>> Mark and David, can you pull the 3.13-td-changes-reverted branch again,
> >>
On Fri, Jan 31, 2014 at 08:17:58AM +0800, Ming Lei wrote:
> On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
> wrote:
> > On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
> >> FWIW, the plan looks fine to me. Just adding a couple of hints to
> >> simplify the implementation.
> >>
> >> Sara
On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
> > Hi,
> >
> > On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
> > > The DWC2 driver should now be in good enough shape to move out of
> > > stagi
On Friday 31 January 2014 11:45 AM, Felipe Balbi wrote:
> On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
>> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
>>> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
On Friday 31 January 2014 10:19 AM, Fel
On Fri, Jan 31, 2014 at 04:37:47PM +, David Laight wrote:
> In order to get an ASMedia xhci controller to even detect a device
> being inserted I had to split the writeq() and readq().
> The following patch is sufficient on amd64.
I've reverted the commits that introduced the readq and writeq
On 01/31/2014 12:37 PM, Paul Zimmerman wrote:
>> From: Andre Heider [mailto:a.hei...@gmail.com]
>> Sent: Friday, January 31, 2014 11:04 AM
>> On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
>>> On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
On Mon, Jan 13, 2014 at
> From: Andre Heider [mailto:a.hei...@gmail.com]
> Sent: Friday, January 31, 2014 11:04 AM
>
> On Fri, Jan 31, 2014 at 12:15:26PM -0600, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Jan 31, 2014 at 07:12:36PM +0100, Andre Heider wrote:
> > > Hi,
> > >
> > > On Mon, Jan 13, 2014 at 01:50:09PM -0800,
[Cc-ing the USB mailing list as well.]
On Mon, Jan 27, 2014 at 06:13:57PM +0200, Valentina Manea wrote:
> Hi Sarah,
Hi Valentina,
> As you probably know, I am working on a set of drivers called USB/IP.
> These drivers have some issues that I'm not sure how to approach and
> since you are working
On Fri, 31 Jan 2014, Felipe Balbi wrote:
> probe()
> {
> ...
>
> clk_get(dev, "fck");
> clk_prepare(clk);
> clk_enable(clk);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
> ...
> }
> note that because of pm_run
On 01/31/2014 11:23 AM, Sarah Sharp wrote:
> On Fri, Jan 31, 2014 at 04:37:47PM +, David Laight wrote:
>> In order to get an ASMedia xhci controller to even detect a device
>> being inserted I had to split the writeq() and readq().
>> The following patch is sufficient on amd64.
>
> I've reve
On Fri, 31 Jan 2014, Sarah Sharp wrote:
> > 2. This question somehow resembles the previous. When a device is
> > shared, I don't want it to be available on the host it is physically
> > attached to anymore.
>
> What do you mean by this? Do you mean that when the stub driver on the
> server star
On Fri, Jan 31, 2014 at 04:13:19PM -0500, Alan Stern wrote:
> On Fri, 31 Jan 2014, Felipe Balbi wrote:
>
> > probe()
> > {
> > ...
> >
> > clk_get(dev, "fck");
> > clk_prepare(clk);
> > clk_enable(clk);
> > pm_runtime_set_active(dev);
> > pm_runtime_enable(dev);
> > pm
Hi,
On Fri, Jan 31, 2014 at 02:20:48PM -0500, Santosh Shilimkar wrote:
[ snip ]
> > note that because of pm_runtime_set_active() that first
> > pm_runtime_get_sync() in probe() will simply increase the reference
> > counter without calling my ->runtime_resume() callback, which is exactly
> > wha
From: Shaibal Dutta
Allow the scheduler to select the best CPU to handle hub initalization
and LED blinking work. This extends idle residency times on idle CPUs
and conserves power.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: Greg Kroah-Hartman
Cc: Alan Stern
On Friday 31 January 2014 05:15 PM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 02:20:48PM -0500, Santosh Shilimkar wrote:
>
> [ snip ]
>
>>> note that because of pm_runtime_set_active() that first
>>> pm_runtime_get_sync() in probe() will simply increase the reference
>>> counter with
ACPI identifies peer ports by setting their 'group_token' and
'group_position' _PLD data to the same value. If a platform has tier
mismatch [1] , ACPI can override the default, USB3 defined, peer port
association for internal hubs. External hubs follow the default peer
association scheme.
Locati
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 m
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
Toggling port power currently leads to three unintended disconnect
scenarios that are addressed by this rework of port power recovery and
usb device resume:
1/ Superspeed devices downgrade to their hispeed connection: fix this by
preventing superspeed poweroff until the peer port is suspended.
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
Assume that the peer of a superspeed port is the port with the same id
on the shared_hcd root hub. This identification scheme is required of
external hubs by the USB3 spec [1]. However, for root hubs, tier mismatch
may be in effect [2]. Tier mismatch can only be enumerated via platform
firmware.
Three reasons:
1/ It's an invalid operation on usb3 ports
2/ There's no guarantee of when / if a usb2 port has entered an error
state relative to PORT_POWER request
3/ The port is active / powered at this point, so khubd will clear it as
a matter of course
Signed-off-by: Dan Williams
---
d
Work around a remote wakeup vs port poweroff request race. A wakeup request
sets the timer, but by the time it expires the port has been turned off, so we
hit:
if ((raw_port_status & PORT_RESET) ||
!(raw_port_status & PORT_PE))
In preparation for synchronizing port handling with pm_runtime
transitions refactor port handling into its own subroutine.
We expect that clearing some status flags will be required regardless of
the port state, so handle those first and group all non-trivial actions
at the bottom of the routine.
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.
The port pm_runtime implementation unconditionally clears FEAT_C_ENABLE
after clearing PORT_POWER, but the bit is reserved on usb3 hub ports.
We expect khubd to be suspended at this time so we need to clear any
errors for usb2 ports.
Signed-off-by: Dan Williams
---
drivers/usb/core/port.c |3
In general we do not want khubd to act on port status changes that are
the result of in progress resets or port pm runtime operations.
Specifically port power control testing has been able to trigger an
unintended disconnect in hub_port_connect_change(), paraphrasing:
if ((portstatus & USB
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
[sarah]: wordsmithing
[djbw]: updates for peer port changes
Signed-off-by: Dan Williams
---
Documentation/usb/power-management.txt | 2
Make port power recovery behave similarly to the power session recovery
that occurs after a system / hub suspend event. Arrange for a
usb_device to always complete a usb_port_resume() run prior to the next
khubd run. This serves several purposes:
1/ The device may need a reset on power-session l
Resuming a powered down port sometimes results in the port state being
stuck in USB_SS_PORT_LS_POLLING:
hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
port1: can't get reconnection after setting port power on, status -110
hub 3-0:1.0: port 1 status .02e0 after resume,
On Thu, 30 Jan 2014, Dennis New wrote:
> Indeed, "ohci_quirk_zfmicro" (as mentioned in that marc.info link)
> would crash my kernel/system (I think when some graphics switch would
> happen) :). So I tried "ohci_quirk_amd700", since there were already
> some PCI_VENDOR_ID_ATI quirks in ohci-pci.c t
On Fri, 31 Jan 2014, Zoran Markovic wrote:
> From: Shaibal Dutta
>
> Allow the scheduler to select the best CPU to handle hub initalization
> and LED blinking work. This extends idle residency times on idle CPUs
> and conserves power.
>
> This functionality is enabled when CONFIG_WQ_POWER_EFFIC
On 01/31/2014 11:12 AM, Andre Heider wrote:
> On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote:
>> The DWC2 driver should now be in good enough shape to move out of
>> staging. I have stress tested it overnight on RPI running mass
>> storage and Ethernet transfers in parallel, and for
On Sat, Feb 1, 2014 at 3:00 AM, Sarah Sharp
wrote:
> On Fri, Jan 31, 2014 at 08:17:58AM +0800, Ming Lei wrote:
>> On Fri, Jan 31, 2014 at 6:15 AM, Sarah Sharp
>> wrote:
>> > On Thu, Jan 30, 2014 at 10:50:21PM +0100, Bjørn Mork wrote:
>> >> FWIW, the plan looks fine to me. Just adding a couple of
57 matches
Mail list logo
