On Wed, May 24, 2017 at 12:43 AM, Alan Stern wrote:
>>
>> Output of `cat /sys/kernel/debug/usb/usbmon/1u`:
>> Runtime PM disabled as attachment.
>
> When you say "runtime PM disabled", you mean that it is disabled for
> the EHCI controller but enabled for other devices, right?
Yes, disabled for t
On Wed, May 24, 2017 at 12:22 AM, Francesco Lavra
wrote:
> On Sun, May 21, 2017 at 4:42 PM, Francesco Lavra
> wrote:
>> Hi,
>> I'm using the dwc2 OTG controller as a USB audio gadget (g_audio driver),
>> and I'm having trouble with making it work at high data rates, e.g. 192 kHz
>> sampling rate
On 05/23/2017 06:28 PM, Badhri Jagan Sridharan wrote:
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low level drivers can
however reject the request if the specific port type is not supported.
Signed-off-by: Badhri Jagan Sridhara
Dear Linux Kernel USB hackers,
I'm facing the following overall problem / use case:
* there is an embedded device, attached to USB, with complex internal
software, which every so often needs to be physically power cycled in
order to reset all of its internal state. In the particular case it'
On 05/23, Fabien Lahoudere wrote:
> Hi,
>
> We investigate on the topic and now our device tree look like:
>
> in imx53.dtsi:
>
> usbh2: usb@53f80400 {
> compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> reg = <0x53f80400 0x0200>;
> interrupts = <16>;
> clocks = <&cl
Hi Felipe,
On 5/11/2017 6:12 PM, Thinh Nguyen wrote:
> On 4/11/2017 11:03 PM, Felipe Balbi wrote:
>> Thinh Nguyen writes:
>> Felipe Balbi writes:
>>> Thinh Nguyen writes:
This patch fixes a commit that causes a hang from device waiting for
data with the wrong sequence
From: David S. Miller (da...@davemloft.net)
Sent: Tue, 23 May 2017 11:26:25 -0400
> From: Oliver Neukum
> Date: Tue, 23 May 2017 10:42:48 +0200
>
>>
>> We could use a counter. After the first failure, do it once, after the
>> second twice and so on. And reset the counter as a higher order
>> all
On Sun, May 21, 2017 at 4:42 PM, Francesco Lavra
wrote:
> Hi,
> I'm using the dwc2 OTG controller as a USB audio gadget (g_audio driver),
> and I'm having trouble with making it work at high data rates, e.g. 192 kHz
> sampling rate or 6 channels.
> When I load the g_audio driver with the above par
Hi,
We investigate on the topic and now our device tree look like:
in imx53.dtsi:
usbh2: usb@53f80400 {
compatible = "fsl,imx53-usb", "fsl,imx27-usb";
reg = <0x53f80400 0x0200>;
interrupts = <16>;
clocks = <&clks IMX5_CLK_USBOH3_GATE>;
fsl,usbmisc = <&usbm
* Alan Stern [170523 09:57]:
> On Mon, 22 May 2017, Tony Lindgren wrote:
> > Alan, do you have some better ideas for the ohci_platform_remove()
> > path below?
...
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -290,7 +294,14 @@ static int ohci_platfor
On Mon, 22 May 2017, Tony Lindgren wrote:
> This driver is no longer needed and can be removed. The reason why
> it's safe to remove this driver is that most omap devices don't have a
> USB low-speed or full-speed compatible PHY installed and configured
> with drivers/mfd/omap-usb-host.c. This mea
On Mon, 22 May 2017, Tony Lindgren wrote:
> This is needed in preparation of adding support for omap3 and
> later OHCI. The runtime PM will only do something on platforms
> that implement it.
>
> Cc: devicet...@vger.kernel.org
> Cc: Hans de Goede
> Cc: Rob Herring
> Cc: Roger Quadros
> Cc: Seb
On Tue, 23 May 2017, Marek Pikarski wrote:
> Hi Alan,
> First of all, many thanks for the reply! Please read my comments below...
>
> On 22.05.2017 21:46, Alan Stern wrote:
> > On Mon, 22 May 2017, Marek Pikarski wrote:
> >
> >> Hi!
> >>
> >> I am currently hunting the source of an issue that we
On Tue, 23 May 2017, Kai-Heng Feng wrote:
> >> Sorry for not explaining the original question well enough - the real
> >> problem is that after enabling runtime PM on EHCI, the two physical
> >> ports on the right side of the laptop no longer response to any
> >> device, e.g. an USB storage or an
From: Romain Perier
Date: Tue, 23 May 2017 10:53:36 +0200
> Hello,
>
>
> Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
>> On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
>>> The PCI pool API is deprecated. This commit replaces the PCI pool old
>>> API by the appropriate functi
From: Oliver Neukum
Date: Tue, 23 May 2017 10:42:48 +0200
> Am Montag, den 22.05.2017, 11:54 -0400 schrieb David Miller:
>>
>> Unfortunately without a real notifier of some sort (there isn't one, and
>> it isn't actually easy to come up with a clean way to do this which is
>> probably why it doe
* Roger Quadros [170523 00:14]:
> On 22/05/17 19:00, Tony Lindgren wrote:
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device
> > *dev)
> > struct usb_hcd *hcd = platform_get_drvd
On 05/23/2017 06:39 AM, Heikki Krogerus wrote:
On Tue, May 23, 2017 at 06:16:28AM -0700, Guenter Roeck wrote:
On 05/23/2017 03:46 AM, Heikki Krogerus wrote:
Hi,
On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:
User space applications in some cases have the need to enfor
On Tue, May 23, 2017 at 06:16:28AM -0700, Guenter Roeck wrote:
> On 05/23/2017 03:46 AM, Heikki Krogerus wrote:
> > Hi,
> >
> > On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:
> > > User space applications in some cases have the need to enforce a
> > > specific port type(DF
On 05/23/2017 03:46 AM, Heikki Krogerus wrote:
Hi,
On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:
User space applications in some cases have the need to enforce a
specific port type(DFP/UFP/DRP). This change allows userspace to
attempt setting the desired port type. Low
Hi Alan,
First of all, many thanks for the reply! Please read my comments below...
On 22.05.2017 21:46, Alan Stern wrote:
On Mon, 22 May 2017, Marek Pikarski wrote:
Hi!
I am currently hunting the source of an issue that we have with an USB
modem. There could even be some HW / board design iss
On Tue, May 23, 2017 at 06:42:46PM +0800, yd_tseng wrote:
> Hi Greg,
>
> One of our xHCI host controlers has 3 extended speed protocol lists. The
> content of extended speed protocol lists is shown as below.
> In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
> is set a
On Tue, May 23, 2017 at 06:50:49PM +0800, YD wrote:
> From: YD Tseng
>
> Hi Greg and Mathias,
Why is this here? :)
Hint, send what you want in the changelog, in the changelog area,
anything else you want to say, put below the --- line, like
Documentation/SubmittingPatches says to do.
>
> Thi
On 23.05.2017 12:50, Mathias Nyman wrote:
On 22.05.2017 18:42, Greg KH wrote:
On Fri, May 19, 2017 at 02:53:20PM +0200, Jason A. Donenfeld wrote:
I'm having this issue on kernel 4.11.0 and 4.11.1. It usually happens
after a while of ordinary USB use. Afterwards, USB does not work. If I
rmmod al
Hi Greg,
One of our xHCI host controlers has 3 extended speed protocol lists. The
content of extended speed protocol lists is shown as below.
In xhci-mem.c, the USB 3.1 speed is parsed first, the min_rev of usb3_rhub
is set as 0x10. And then USB 3.0 is parsed. However, the min_rev of
usb3_rhu
On 22.05.2017 21:24, Xavier . wrote:
Hello and thanks
dmesg.4.12-rc1.with_dyndbg_pendrive_connected_at_boot_1r.txt (1r and
2n are very different on xhci)
[0.00] Linux version 4.12.0-041200rc1-generic (kernel@gomeisa)
(gcc version 6.3.0 20170510 (Ubuntu 6.3.0-17ubuntu1) ) #201705131731
From: YD Tseng
Hi Greg and Mathias,
This patch works around for parsing extended speed protocol lists.
If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
it could show as one 3.1 roothub.
Changes since v1:
- change diff path
Signed-off-by: YD Tseng
---
diff -up linux/
Hi,
On Mon, May 22, 2017 at 01:05:42PM -0700, Badhri Jagan Sridharan wrote:
> User space applications in some cases have the need to enforce a
> specific port type(DFP/UFP/DRP). This change allows userspace to
> attempt setting the desired port type. Low level drivers can
> however reject the requ
Hi,
On 2017년 05월 17일 22:12, Damien Riegel wrote:
> Hi,
>
> On Fri, Apr 14, 2017 at 02:43:27PM -0400, Damien Riegel wrote:
>> This patchset adds a way for the MSM USB phy to notify a power supply
>> when the charging state changes. It achieves that using the extcon
>> subsystem.
>>
>> The first pa
On 22.05.2017 18:42, Greg KH wrote:
On Fri, May 19, 2017 at 02:53:20PM +0200, Jason A. Donenfeld wrote:
I'm having this issue on kernel 4.11.0 and 4.11.1. It usually happens
after a while of ordinary USB use. Afterwards, USB does not work. If I
rmmod all the modules and reinsert them, it works f
On Tue, May 23, 2017 at 03:00:47PM +0800, YD wrote:
> From: YD Tseng
>
> Hi Mathias,
>
> This patch works around for parsing extended speed protocol lists.
> If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
> it could show as one 3.1 roothub.
>
> Signed-off-by: YD Tseng
On Tue, May 23, 2017 at 10:44:05AM +1000, Benjamin Herrenschmidt wrote:
> The Aspeed 2400/2500 families have a variant of UHCI which requires
> some quirks to the driver to work:
>
> - The register offsets are different. We add a remapping helper.
>
> - All accesses have to be done via 32-bit l
On Tue, May 23, 2017 at 10:53:36AM +0200, Romain Perier wrote:
> Hello,
>
>
> Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
> > On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
> >> The PCI pool API is deprecated. This commit replaces the PCI pool old
> >> API by the appropriate fu
Sorry about that, -v output here:
Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProto
Am Montag, den 22.05.2017, 15:55 +0200 schrieb Daniel Duris:
> Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp.
> Bus 004 Device 003: ID 2109:0813 VIA Labs, Inc.
> Bus 004 Device 002: ID 05e3:0617 Genesys Logic, Inc.
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus
Hi,
On Mon, May 22, 2017 at 09:00:07AM -0700, Tony Lindgren wrote:
> This driver is no longer needed and can be removed. The reason why
> it's safe to remove this driver is that most omap devices don't have a
> USB low-speed or full-speed compatible PHY installed and configured
> with drivers/mfd/
Hello,
Le 23/05/2017 à 09:27, Leon Romanovsky a écrit :
> On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
>> The PCI pool API is deprecated. This commit replaces the PCI pool old
>> API by the appropriate function with the DMA pool API.
>>
>> Signed-off-by: Romain Perier
>> Review
Am Montag, den 22.05.2017, 11:54 -0400 schrieb David Miller:
>
> Unfortunately without a real notifier of some sort (there isn't one, and
> it isn't actually easy to come up with a clean way to do this which is
> probably why it doesn't exist yet in the first place) I really cannot
> recommend any
On Monday 22 May 2017 03:32 AM, Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
>
> Signed-off-by: Wolfram Sang
Acked-by: Kishon Vijay Abraham I
> ---
> arch/arm/mach-omap2/common.h| 2 +-
> arch/arm/mach-o
On Mon, May 22, 2017 at 06:48:58PM +0200, Romain Perier wrote:
> The PCI pool API is deprecated. This commit replaces the PCI pool old
> API by the appropriate function with the DMA pool API.
>
> Signed-off-by: Romain Perier
> Reviewed-by: Peter Senna Tschudin
> Acked-by: Doug Ledford
> Tested-b
> For my own reference:
> Acked-for-MFD-by: Lee Jones
>
> I guess this will be going through the MFD tree?
I'd prefer that, yes. Thanks!
signature.asc
Description: PGP signature
On Mon, 22 May 2017, Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
>
> Signed-off-by: Wolfram Sang
> ---
> arch/arm/mach-omap1/board-h2-mmc.c | 2 +-
> arch/arm/mach-omap1/board-h2.c | 2 +-
> arch/arm/mac
On Mon, 22 May 2017, Wolfram Sang wrote:
> include/linux/i2c is not for client devices. Move the header file to a
> more appropriate location.
>
> Signed-off-by: Wolfram Sang
> ---
> arch/arm/mach-omap2/common.h| 2 +-
> arch/arm/mach-omap2/omap_twl.c | 2 +-
> drivers/gpio
Hi,
On 22/05/17 19:00, Tony Lindgren wrote:
> This is needed in preparation of adding support for omap3 and
> later OHCI. The runtime PM will only do something on platforms
> that implement it.
>
> Cc: devicet...@vger.kernel.org
> Cc: Hans de Goede
> Cc: Rob Herring
> Cc: Roger Quadros
> Cc: S
On 22/05/17 19:00, Tony Lindgren wrote:
> This driver is no longer needed and can be removed. The reason why
> it's safe to remove this driver is that most omap devices don't have a
> USB low-speed or full-speed compatible PHY installed and configured
> with drivers/mfd/omap-usb-host.c. This means
From: YD Tseng
Hi Mathias,
This patch works around for parsing extended speed protocol lists.
If the xHCI controller supports USB 3.1 and 3.0 extended speed protocol,
it could show as one 3.1 roothub.
Signed-off-by: YD Tseng
---
A file is modified.
drivers/usb/host/xhci-mem.c Mo
47 matches
Mail list logo