On Mon, Jan 20, 2014 at 09:56:14AM +0800, Li Jun wrote:
> Leave vbus on/off hanlded by OTG fsm if in OTG mode, init OTG port number.
>
It is better split this to two patches, one for vbus, another is for
OTG port.
Peter
> Signed-off-by: Li Jun
> ---
> drivers/usb/chipidea/host.c | 13 ++
On Mon, Jan 20, 2014 at 09:56:11AM +0800, Li Jun wrote:
> This patchset adds USB OTG HNP and SRP support on chipidea usb driver,
> existing OTG port role swtich function by ID pin status kept unchanged,
> based on that, if select CONFIG_USB_OTG_FSM, OTG HNP and SRP will be
> supported.
It is bette
%s/initlization/initialization
Reply-To:
In-Reply-To: <1390182980-8349-3-git-send-email-b47...@freescale.com>
On Mon, Jan 20, 2014 at 09:56:13AM +0800, Li Jun wrote:
> This patch adds OTG fsm related initizations when do otg init,
> add a seperate file for OTG fsm related utilities.
%s/initliza
On Mon, Jan 20, 2014 at 09:56:12AM +0800, Li Jun wrote:
> According to:"On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> Specification July 27, 2012 Revision 2.0 version 1.1a"
> - From a_host to a_wait_bcon if !b_conn
> - Add transition from a_host to a_wait_vfall if id state is hig
On Fri, 2014-02-07 at 21:06 +0100, Andreas Cadhalpun wrote:
> Package: src:linux
> Version: 3.12.9-1
> Severity: important
> X-Debbugs-CC: Ben Hutchings
>
> Dear Maintainer,
>
> linux 3.12.9-1 introduced a regression in xhci_hcd: USB3 does not work
> any more! (see the Kernel log below)
> This
Hi Alan,
Thanks for taking the time to respond.
On Thu, Feb 6, 2014 at 5:08 PM, Alan Stern wrote:
> Is it possible to get any debugging information from the machines in
> the field?
At this point all I know is the usb_submit_urb() is returning -EBIGF.
In the 3.7 ehci_hcd driver that can come fr
Hi,
On 02/07/2014 11:31 PM, Greg Kroah-Hartman wrote:
On Fri, Feb 07, 2014 at 04:36:39PM +0100, Hans de Goede wrote:
Hi Greg,
Here is v9 of my ohci-platform and ehci-platform patchset, It is just a
rebase (with some manual conflict resolution), to make it easier for you
to throw this into usb-
On Fri, Jan 31, 2014 at 02:29:52AM -0200, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Using module_platform_driver() can make the code simpler.
>
> Signed-off-by: Fabio Estevam
> ---
> Build-tested only
No you didn't:
drivers/usb/host/xhci-plat.o: In function `usb_xhci_driver_init':
On Fri, Feb 07, 2014 at 04:36:39PM +0100, Hans de Goede wrote:
> Hi Greg,
>
> Here is v9 of my ohci-platform and ehci-platform patchset, It is just a
> rebase (with some manual conflict resolution), to make it easier for you
> to throw this into usb-next, there are no other changes.
I've applied
On Fri, 31 Jan 2014, Dan Williams wrote:
> 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.
The nomenclature is a little confusing. Let's agree that "port runtime
PM operations" will refer to usb_port_runtime
On Fri, 7 Feb 2014, Dan Williams wrote:
> >> You know, I believe these races would go away if we could delay port
> >> pm runtime activation until after the initial discovery of the entire
> >> hub topology. One potential way of solving this is to proceed with
> >> converting khubd to a workqueue
On Fri, Feb 7, 2014 at 12:08 PM, Alan Stern wrote:
> On Fri, 7 Feb 2014, Dan Williams wrote:
>
>> On Fri, Feb 7, 2014 at 7:17 AM, Alan Stern wrote:
>> > On Fri, 7 Feb 2014, Dan Williams wrote:
>> >
>> >> >> + /* power on our usb3 peer before this usb2 port to prevent a usb3
>> >> >> + *
On Fri, 7 Feb 2014, Dan Williams wrote:
> On Fri, Feb 7, 2014 at 7:17 AM, Alan Stern wrote:
> > On Fri, 7 Feb 2014, Dan Williams wrote:
> >
> >> >> + /* power on our usb3 peer before this usb2 port to prevent a usb3
> >> >> + * device from degrading to its usb2 connection
> >> >> +
On Fri, Feb 7, 2014 at 7:17 AM, Alan Stern wrote:
> On Fri, 7 Feb 2014, Dan Williams wrote:
>
>> >> + /* power on our usb3 peer before this usb2 port to prevent a usb3
>> >> + * device from degrading to its usb2 connection
>> >> + */
>> >> + if (!hub_is_superspeed(hdev) && peer)
On Fri, Feb 7, 2014 at 7:15 AM, Alan Stern wrote:
> On Fri, 7 Feb 2014, Dan Williams wrote:
>
>> >> +static int pair_port(struct device *dev, void *data)
>> >> +{
>> >> + struct usb_port *peer = data;
>> >> + struct usb_port *port_dev = to_usb_port(dev);
>> >
>> > Isn't this backward? dat
Hi,
On 01/15/2014 11:52 PM, Maxime Ripard wrote:
Hi Hans,
Please keep me in CC for all the Allwinner-related patches.
Ok will do.
On Tue, Jan 14, 2014 at 11:58:25PM +0100, Hans de Goede wrote:
The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
through a single set of
Hi,
On 01/15/2014 04:00 PM, Kishon Vijay Abraham I wrote:
On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
through a single set of registers. Besides this there are also some other
phy related bits which need po
This uses the already documented devicetree booleans for this, see:
Documentation/devicetree/bindings/usb/usb-ehci.txt
Signed-off-by: Hans de Goede
---
drivers/usb/host/ehci-platform.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/
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-platform from devicetree in various cases.
Specifically after this commit it can be used for the
Note this commit uses the same devicetree booleans for this as the ones
already existing in the usb-ehci bindings, see:
Documentation/devicetree/bindings/usb/usb-ehci.txt
Signed-off-by: Hans de Goede
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 3 +++
drivers/usb/host/ohci-platform.
Hi Greg,
Here is v9 of my ohci-platform and ehci-platform patchset, It is just a
rebase (with some manual conflict resolution), to make it easier for you
to throw this into usb-next, there are no other changes.
Thanks & Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe l
Currently ehci-platform is only used in combination with devicetree when used
with some Via socs. By extending it to (optionally) get clks and a phy from
devicetree, and enabling / disabling those on power_on / off, it can be used
more generically. Specifically after this commit it can be used for
On Fri, 7 Feb 2014, vichy wrote:
> Hi Alan:
>
> 2014-01-31 2:23 GMT+08:00 Alan Stern :
> > On Fri, 31 Jan 2014, vichy wrote:
> >
> >> Hi all:
> >> I have some questions about bandwidth calculation
> >> 1. why tt time need to include one maxp bus time ?
> >> qh->tt_usecs = NS_TO_US (th
Please don't top-post.
On Fri, 7 Feb 2014, Zoran Markovic wrote:
> I believe there may still be use cases where you want to wake up the
> same CPU that scheduled the work.
Won't the majority of cases not care which CPU is used? Therefore,
shouldn't the default behavior be to use the power-effic
On Fri, Feb 07, 2014 at 10:20:57AM -0500, Alan Stern wrote:
> Please don't top-post.
>
> On Fri, 7 Feb 2014, Zoran Markovic wrote:
>
> > I believe there may still be use cases where you want to wake up the
> > same CPU that scheduled the work.
>
> Won't the majority of cases not care which CPU i
On Fri, 7 Feb 2014, Oliver Neukum wrote:
> Hi,
>
> something like this?
Patches in attachments are hard to review in email replies.
Isn't this overkill? All you want to know is whether the bus supports
bulk streams. A single flag bit in the hcd structure would suffice;
you don't need to add a
On Fri, 7 Feb 2014, Dan Williams wrote:
> >> + /* power on our usb3 peer before this usb2 port to prevent a usb3
> >> + * device from degrading to its usb2 connection
> >> + */
> >> + if (!hub_is_superspeed(hdev) && peer)
> >> + pm_runtime_get_sync(&peer->dev);
> >> +
On Fri, 7 Feb 2014, Dan Williams wrote:
> >> +static int pair_port(struct device *dev, void *data)
> >> +{
> >> + struct usb_port *peer = data;
> >> + struct usb_port *port_dev = to_usb_port(dev);
> >
> > Isn't this backward? data is the port you want to match, and dev
> > is the device (
From: Emil Goode
> On Fri, Feb 07, 2014 at 10:38:04AM +0100, Bjørn Mork wrote:
> > Emil Goode writes:
> > > On Thu, Feb 06, 2014 at 03:28:13PM +, David Laight wrote:
> > >> From: Igor Gnatenko
> > >> > On Thu, 2014-02-06 at 13:56 +0100, Emil Goode wrote:
> > >> > > The AX88772B occasionally s
On Fri, Feb 07, 2014 at 10:08:58AM +0100, Marco Zamponi wrote:
> I can't seem to find the place...
Where did you look?
--
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/majord
On Fri, Feb 07, 2014 at 10:38:04AM +0100, Bjørn Mork wrote:
> Emil Goode writes:
> > On Thu, Feb 06, 2014 at 03:28:13PM +, David Laight wrote:
> >> From: Igor Gnatenko
> >> > On Thu, 2014-02-06 at 13:56 +0100, Emil Goode wrote:
> >> > > The AX88772B occasionally send rx packets that cross urb
Hi,
On 02/07/2014 11:03 AM, Oliver Neukum wrote:
On Wed, 2014-02-05 at 22:08 +0100, Hans de Goede wrote:
Hi Oliver,
On 02/05/2014 09:13 PM, oli...@neukum.org wrote:
From: Oliver Neukum
uas_probe() calls usb_alloc_streams(). That can fail on XHCI
with -ENOSYS if the controller doesn't suppor
Hi Alan:
2014-01-31 2:23 GMT+08:00 Alan Stern :
> On Fri, 31 Jan 2014, vichy wrote:
>
>> Hi all:
>> I have some questions about bandwidth calculation
>> 1. why tt time need to include one maxp bus time ?
>> qh->tt_usecs = NS_TO_US (think_time +
>> usb_calc_bus_time
On 10:06 Tue 21 Jan , Nicolas Ferre wrote:
> On 21/01/2014 09:12, Bo Shen :
> > Hi J,
> >
> > On 01/21/2014 01:49 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 11:39 Mon 20 Jan , Bo Shen wrote:
> >>> Hi J,
> >>>
> >>> On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
I believe there may still be use cases where you want to wake up the
same CPU that scheduled the work.
Thanks for the Ack. Can you please queue this for 3.14?
Regards, Zoran
On 2 February 2014 08:10, Alan Stern wrote:
> On Sat, 1 Feb 2014, Zoran Markovic wrote:
>
>> From: Shaibal Dutta
>>
>> A
On Thu, Feb 6, 2014 at 1:12 PM, Alan Stern wrote:
> On Fri, 31 Jan 2014, Dan Williams wrote:
>
>> 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 n
I
On Thu, Feb 6, 2014 at 1:09 PM, Alan Stern wrote:
> On Fri, 31 Jan 2014, Dan Williams wrote:
>
>> 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 ac
On Wed, 2014-02-05 at 22:08 +0100, Hans de Goede wrote:
> Hi Oliver,
>
> On 02/05/2014 09:13 PM, oli...@neukum.org wrote:
> > From: Oliver Neukum
> >
> > uas_probe() calls usb_alloc_streams(). That can fail on XHCI
> > with -ENOSYS if the controller doesn't support streams. In that
> > case devic
On Thu, Feb 6, 2014 at 1:05 PM, Alan Stern wrote:
> On Fri, 31 Jan 2014, Dan Williams wrote:
>
>> 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 tha
Emil Goode writes:
> On Thu, Feb 06, 2014 at 03:28:13PM +, David Laight wrote:
>> From: Igor Gnatenko
>> > On Thu, 2014-02-06 at 13:56 +0100, Emil Goode wrote:
>> > > The AX88772B occasionally send rx packets that cross urb boundaries
>> > > and the remaining partial packet is sent with no hea
On Thu, Feb 6, 2014 at 12:57 PM, Alan Stern wrote:
> On Fri, 31 Jan 2014, Dan Williams wrote:
>
>> For example:
>
> Topic sentence? A reader seeing this could be forgiven for wondering
> "Example of what?".
>
Ok, fixed.
>> usb2/2-1/2-1:1.0/port1/peer => ../../../../usb3/3-1/3-1:1.0/port1
>> usb
I can't seem to find the place...
Thanks!
--
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 Thu, Feb 6, 2014 at 12:46 PM, Alan Stern wrote:
> On Fri, 31 Jan 2014, Dan Williams wrote:
>
>> 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, p
43 matches
Mail list logo
