A couple of weeks ago, Sekhar reported a warning issue happening in
CPPI 4.1. The teardown sequence was not correctly programmed.
The caused was a couple of difference between the DSPS and the DA8xx.
These differences are the way to program the autoreq, the teardown and
the DMA mode.
This series in
The DA8xx and DSPS platforms don't use the same address for few registers.
On Da8xx, this is causing some issues (e.g. teardown that doesn't work).
Configure the address of the register during the init and use them instead
of constants.
Reported-by: nsek...@ti.com
Signed-off-by: Alexandre Bailon
Currently, the number of channels is set to 15 but in the case of DA8xx,
the number of channels is 4.
Update the driver to configure the number of channels at runtime.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/musb_cppi41.c | 31 ++-
1 file changed, 26 inse
The way to configure the DMA mode on DA8xx is different from DSPS.
Add a new function to configure DMA mode on DA8xx and use a callback
to call the right function based on the platform.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/musb_cppi41.c | 40 +-
There is some registers defined in da8xx.c though they are not used.
These registers are also defined and used in musb_cppi41.c
Remove these defines from da8xx.c.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/da8xx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/musb/d
On Wed, Sep 20, 2017 at 08:15:38AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 19, 2017 at 09:41:48PM +, Schoon, Michael wrote:
> > Signed-off-by: Michael Schoon
>
> No changelog at all? I know I can't take patches like that, hopefully
> Johan has the same rule :)
Indeed, I do.
Please a
Am Dienstag, den 19.09.2017, 13:51 -0700 schrieb Guenter Roeck:
> On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum wrote:
> >
> > Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
> > >
[..]
> > > NOTES:
> > > - No known bugs are fixed by this; it's just found by code inspection.
Am Dienstag, den 19.09.2017, 13:53 -0700 schrieb Doug Anderson:
> Hi,
>
> On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum wrote:
> >
> > Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
> > >
> > > In general when you've got a flag communicating that "something needs
> > > to b
2017-09-19 17:25 GMT+02:00 Lee Jones :
> On Tue, 19 Sep 2017, Nicolas Ferre wrote:
>
>> On 15/09/2017 at 16:04, Romain Izard wrote:
>> > The controller used by a flexcom module is configured at boot, and left
>> > alone after this. As the configuration will be lost after backup mode,
>> > restore t
On 20/09/2017 at 10:30:31 +0200, Romain Izard wrote:
> 2017-09-19 17:25 GMT+02:00 Lee Jones :
> > On Tue, 19 Sep 2017, Nicolas Ferre wrote:
> >
> >> On 15/09/2017 at 16:04, Romain Izard wrote:
> >> > The controller used by a flexcom module is configured at boot, and left
> >> > alone after this. As
Hello!
On 9/20/2017 10:35 AM, Alexandre Bailon wrote:
Currently, the number of channels is set to 15 but in the case of DA8xx,
the number of channels is 4.
Update the driver to configure the number of channels at runtime.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/musb_cppi41.c |
From: "yinbo.zhu"
When a transaction error (defined in Section 4.10.2.3, "USB
Transaction Error" of the xHCI Specification) occurs on the
USB, the host controller reports this through a transfer
event with the completion code "USB Transaction Error". When
this happens, the endpoint is placed in t
On Wed, Sep 20, 2017 at 05:24:41PM +0800, yinbo@nxp.com wrote:
> From: "yinbo.zhu"
For some reason I doubt your "legal name" has a "." in it :(
Please fix this up, and the same string in the signed-off-by: line, at
the least, in order for us to be able to take this patch.
thanks,
greg k-h
On Wed, Sep 20, 2017 at 05:24:41PM +0800, yinbo@nxp.com wrote:
> From: "yinbo.zhu"
>
> When a transaction error (defined in Section 4.10.2.3, "USB
> Transaction Error" of the xHCI Specification) occurs on the
> USB, the host controller reports this through a transfer
> event with the completi
This patch makes the driver work with USB Type-C Port
Manager (tcpm.c) to provide USB PD functionality.
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/Kconfig | 4 +-
drivers/usb/typec/typec_wcove.c | 594 ++--
2 files changed, 447 insertions(+),
On Wed, Sep 20, 2017 at 6:57 AM, Kim Jaejoong wrote:
> Hi Andrey
>
> 2017-09-19 21:38 GMT+09:00 Andrey Konovalov :
>> Hi Kim,
>>
>> I'm not sure. Is there a check on the bLength field of a
>> hid_descriptor struct? Can it be less than sizeof(struct
>> hid_descriptor)? If so, we still do an out-of-
Hi,
Alexey Khoroshilov writes:
>>> diff --git a/drivers/usb/gadget/udc/pch_udc.c
>>> b/drivers/usb/gadget/udc/pch_udc.c
>>> index 84dcbcd756f0..a305f8392082 100644
>>> --- a/drivers/usb/gadget/udc/pch_udc.c
>>> +++ b/drivers/usb/gadget/udc/pch_udc.c
>>> @@ -1767,7 +1767,7 @@ static struct usb_r
Hi,
Jerry Zhang writes:
> Currently, f_midi_free uses snd_card_free, which will wait
> until the user has released the sound card before
> returning. However, if the user doesn't release the sound
> card, then f_midi_free can block for an arbitrary amount
> of time, which also blocks any gadget
On 20.09.2017 12:24, yinbo@nxp.com wrote:
From: "yinbo.zhu"
When a transaction error (defined in Section 4.10.2.3, "USB
Transaction Error" of the xHCI Specification) occurs on the
USB, the host controller reports this through a transfer
event with the completion code "USB Transaction Error"
Thanks for the feedback. I'll review and resubmit.
-Original Message-
From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold
Sent: Wednesday, September 20, 2017 2:47 AM
To: Schoon, Michael
Cc: jo...@kernel.org; linux-usb@vger.kernel.org; Greg Kroah-Hartman
Subject: Re:
The Subject: line should specify which type of USB host controller the
patch is for. The kernel contains lots of different USB host
controller drivers. How are we supposed to know that Erratum A-007463
applies to dwc3 xHCI controllers?
The Subject: line should say something like:
[PATCH v1] USB
On 15/09/2017 16:04, Romain Izard wrote:
> The atmel serial port driver reported the following warning on suspend:
> atmel_usart f802.serial: ttyS1: Unable to drain transmitter
>
> As the ATMEL_US_TXEMPTY status bit in ATMEL_US_CSR is always cleared
> when the transmitter is disabled, we need
Hi!
I've got the following crash while fuzzing the kernel with syzkaller.
On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
It looks like cdc_parse_cdc_header() doesn't validate buflen before
accessing buffer[1], buffer[2] and so on. The only check present is
while (buflen > 0).
On Wed, 20 Sep 2017, Kim Jaejoong wrote:
> To. usb & input guys.
>
> While dig this report, i was wondering about bNumDescriptors in HID
> descriptor.
> HID document from usb.org said, 'this number must be at least one (1)
> as a Report descriptor will always be present.'
>
> There is no mentio
Hi asmtswfae,
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.14-rc1]
[cannot apply to next-20170920]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Joe-Lee/xhci-AMD
Quoting Hans de Goede (2017-09-19 11:35:50)
> Hi,
>
> On 09/08/2017 05:54 PM, Peter Rosin wrote:
> > On 2017-09-08 17:45, Peter Rosin wrote:
> >> From: Stephen Boyd
> >>
> >> Sometimes drivers only use muxes under certain scenarios. For
> >> example, the chipidea usb controller may be connected t
I'm obviously missing something here but am not quite sure what.
My usermode code* is set up to emulate an existing FX3 device. Bulk reads
and writes are all fine as are vendor-specific commands that are host to
device. However anything that is device to host never appears on the wire.
The gene
On Wed, 20 Sep 2017 g...@novadsp.com wrote:
> I'm obviously missing something here but am not quite sure what.
>
> My usermode code* is set up to emulate an existing FX3 device. Bulk reads
> and writes are all fine as are vendor-specific commands that are host to
> device. However anything that
On 09/20/2017 11:21 AM, Sergei Shtylyov wrote:
> Hello!
>
> On 9/20/2017 10:35 AM, Alexandre Bailon wrote:
>
>> Currently, the number of channels is set to 15 but in the case of DA8xx,
>> the number of channels is 4.
>> Update the driver to configure the number of channels at runtime.
>>
>> Signe
Hello and thanks
> Do you mean: Any control-IN data (device to host) never appears on the
wire? After all, you said that bulk reads and writes
> are fine.
Correct. Data sent via the bulk endpoint is visible. Data sent device to
host on EP0 in response to my vendor commands is not. Now this is v
On Mon, 11 Sep 2017, Andrey Konovalov wrote:
> Hi!
>
> It seems that gadget->ops can be NULL so it probably needs to be
> checked as well as gadget->ops->ioctl in dev_ioctl() in
> drivers/usb/gadget/legacy/inode.c.
Actually, I suspect the problem is that gadget is NULL, not
gadget->ops.
> kasa
On Wed, Sep 20, 2017 at 7:59 PM, Alan Stern wrote:
> On Mon, 11 Sep 2017, Andrey Konovalov wrote:
>
>> Hi!
>>
>> It seems that gadget->ops can be NULL so it probably needs to be
>> checked as well as gadget->ops->ioctl in dev_ioctl() in
>> drivers/usb/gadget/legacy/inode.c.
>
> Actually, I suspect
On Mon, Sep 18, 2017 at 1:14 PM, Alan Stern wrote:
> On Mon, 18 Sep 2017, Kris Lindgren wrote:
>
>> So I upgrade to 17.04 which is using the 4.10 kernel.
>>
>> Without any modification the filesystem fails to mount.
>>
>> Unloading the usb_storage module and reloading it with
>> quirks=0bc2:3332:w
Currently, the number of channels is set to 15 but in the case of DA8xx,
the number of channels is 4.
Update the driver to configure the number of channels at runtime.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/musb_cppi41.c | 31 ++-
1 file changed, 26 inse
The DA8xx and DSPS platforms don't use the same address for few registers.
On Da8xx, this is causing some issues (e.g. teardown that doesn't work).
Configure the address of the register during the init and use them instead
of constants.
Reported-by: nsek...@ti.com
Signed-off-by: Alexandre Bailon
A couple of weeks ago, Sekhar reported a warning issue happening in
CPPI 4.1. The teardown sequence was not correctly programmed.
The caused was a couple of difference between the DSPS and the DA8xx.
These differences are the way to program the autoreq, the teardown and
the DMA mode.
This series in
The way to configure the DMA mode on DA8xx is different from DSPS.
Add a new function to configure DMA mode on DA8xx and use a callback
to call the right function based on the platform.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/musb_cppi41.c | 40 +-
There is some registers defined in da8xx.c though they are not used.
These registers are also defined and used in musb_cppi41.c
Remove these defines from da8xx.c.
Signed-off-by: Alexandre Bailon
---
drivers/usb/musb/da8xx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/usb/musb/d
On Tue, 2017-09-19 at 19:32 +0100, Marc Zyngier wrote:
> On Mon, Sep 18 2017 at 3:01:32 pm BST, Albert Weichselbraun weichselbraun.net> wrote:
> > On Mon, 2017-09-18 at 12:46 +0100, Marc Zyngier wrote:
> > > On 18/09/17 09:49, Albert Weichselbraun wrote:
> > > > Hi Marc,
> > > >
> > > > 100% ack
In the earlier commit dad3f793f20f ("usb: dwc2: Make sure we
disconnect the gadget state"), I was trying to fix up the
fact that we somehow weren't disconnecting the gadget state,
so that when the OTG port was plugged in the second time we
would get warnings about the state tracking being wrong.
T
So here are a few dwc2 fixes that I've been using with HiKey.
I'm not totally sure these are all ideal, but they avoid edge case
issues that we have been running into with switching between
gadget mode and host mode.
I'd guess the first two are potentially -stable material, and
the last might be w
We've found that while in host mode, using Android, if one runs
the command:
stop adbd
The existing usb devices being utilized in host mode are disconnected.
This is most visible with usb networking devices.
This seems to be due to adbd closing the file:
/dev/usb-ffs/adb/ep0
Which calls ffs_e
It has been noticed that the dwc2 udc state reporting doesn't
seem to work (at least on HiKey boards). Where after the initial
setup, the sysfs /sys/class/udc/f72c.usb/state file would
report "configured" no matter the state of the OTG port.
This patch adds a call so that we report to the UDC
On Wed, 20 Sep 2017 g...@novadsp.com wrote:
> Hello and thanks
>
> > Do you mean: Any control-IN data (device to host) never appears on the
> wire? After all, you said that bulk reads and writes
> > are fine.
>
> Correct. Data sent via the bulk endpoint is visible. Data sent device to
> host o
On Fri, Sep 15, 2017 at 06:58:46PM +0200, Jules Maselbas wrote:
> Adds bindings documentation for the max3421 driver.
>
> Signed-off-by: Jules Maselbas
> ---
> .../devicetree/bindings/usb/maxim,max3421.txt | 24
> ++
> 1 file changed, 24 insertions(+)
> create mode 100
On Sat, Sep 16, 2017 at 01:42:20PM +0300, Serge Semin wrote:
> The driver used to be developed with legacy GPIO API support. It's
> better to use descriptor-based interface for several reasons. First
> of all the legacy API doesn't support the ACTIVE_LOW/HIGH flag of dts
> nodes, which is essential
On Sat, Sep 16, 2017 at 01:42:19PM +0300, Serge Semin wrote:
> This parameters may be varied in accordance with hardware specifics.
> So lets add the corresponding settings to the usb251x driver dts
> specification.
>
> Signed-off-by: Serge Semin
> ---
> Documentation/devicetree/bindings/usb/usb
On Wed, 20 Sep 2017, Kris Lindgren wrote:
> Hi Alan,
>
> Sorry for the delay. This did indeed solve the problem. I rebuilt
> the kernel with that patch applied and without any special quirks
> loaded against the usb_storage driver, the drive mounts without issue.
>
> dmesg output:
> [ 1343.583
On Sat, Sep 16, 2017 at 02:31:09AM +0300, Serge Semin wrote:
> USB2517i hubs are very like USB251xb devices series. They have almost
> the same configuration registers space except number of ports, led
> configurations and lack of battery settings. All these peculiarities
> are reflected in this pa
On Wed, Sep 20, 2017 at 03:52:35PM -0500, Rob Herring wrote:
> On Sat, Sep 16, 2017 at 02:31:09AM +0300, Serge Semin wrote:
> > USB2517i hubs are very like USB251xb devices series. They have almost
> > the same configuration registers space except number of ports, led
> > configurations and lack o
On Wed, Sep 20, 2017 at 03:52:55PM -0500, Rob Herring wrote:
> On Sat, Sep 16, 2017 at 01:42:19PM +0300, Serge Semin wrote:
> > This parameters may be varied in accordance with hardware specifics.
> > So lets add the corresponding settings to the usb251x driver dts
> > specification.
> >
> > Sign
On Wed, Sep 20, 2017 at 03:52:57PM -0500, Rob Herring wrote:
> On Sat, Sep 16, 2017 at 01:42:20PM +0300, Serge Semin wrote:
> > The driver used to be developed with legacy GPIO API support. It's
> > better to use descriptor-based interface for several reasons. First
> > of all the legacy API doesn
On Wed, Sep 20, 2017 at 3:00 PM, Alan Stern wrote:
> On Wed, 20 Sep 2017, Kris Lindgren wrote:
>
>> Hi Alan,
>>
>> Sorry for the delay. This did indeed solve the problem. I rebuilt
>> the kernel with that patch applied and without any special quirks
>> loaded against the usb_storage driver, the
The .data assignment appears to be redundant to the WORK_STOP bit for
stopping the timer. Also, it appears this timer is entirely unused
as it is only ever started under #define VERBOSE, which is explicitly
undefined.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linu
If the probe fails, udc_remove() will not be called, so there is no
reason to make del_timer_sync() calls conditional. As a result, use of
the .data field can be dropped, in support of making removing this field
entirely from struct timer_list.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Ravitej
Hi Alan
2017-09-21 0:50 GMT+09:00 Alan Stern :
> On Wed, 20 Sep 2017, Kim Jaejoong wrote:
>
>> To. usb & input guys.
>>
>> While dig this report, i was wondering about bNumDescriptors in HID
>> descriptor.
>> HID document from usb.org said, 'this number must be at least one (1)
>> as a Report des
Hello USB devs,
I have a JMicron HDD dock using an USB3.0 interface. It mounts OK
initially then after a while (random times) writing/reading fails and
the HDD is unmounted.
I use this for doing backups and am having interminable problems.
The following is from "dmesg -Tw"
[Thu Sep 21 13:22:30
Hi,
Alan Stern writes:
> The Subject: line should specify which type of USB host controller the
> patch is for. The kernel contains lots of different USB host
> controller drivers. How are we supposed to know that Erratum A-007463
> applies to dwc3 xHCI controllers?
>
> The Subject: line shou
58 matches
Mail list logo
