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 :)
> ---
> drivers/usb/serial/pl2303.c | 1 +
> drivers/usb/serial/pl2303.h | 1 +
> 2 files changed, 2
Hi Andrey
2017-09-19 21:38 GMT+09:00 Andrey Konovalov :
> On Tue, Sep 19, 2017 at 1:47 PM, Kim Jaejoong wrote:
>> Hi, Andrey Konovalov
>>
>> Thanks for the report.
>>
>> 2017-09-19 2:33 GMT+09:00 Andrey Konovalov :
>>> Hi!
>>>
>>> I've got the following crash while fuzzing the kernel with syzkall
On Mon, Sep 11, 2017 at 4:29 PM, Benson Leung wrote:
> Hi Oliver,
>
> On Mon, Sep 11, 2017 at 01:02:52PM -0700, Benson Leung wrote:
>> Thanks for the pointer. I'll respin the patch with the no_resume version of
>> usb_autopm_get_interface and retest.
>>
>
> I went and tried this patch but with usb
Signed-off-by: Michael Schoon
---
drivers/usb/serial/pl2303.c | 1 +
drivers/usb/serial/pl2303.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index a585b47..eab0e55 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial
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 be done" you want to clear that flag _before_ doing the task. If
>> you clear the flag _af
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 be done" you want to clear that flag _before_ doing the task. If
>> you clear the flag _after_
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 be done" you want to clear that flag _before_ doing the task. If
> you clear the flag _after_ doing the task you end up with the risk
> that this will hap
Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
>
> ALSO NOTE: If somehow some of the types of work need to be repeated if
> usbnet_defer_kevent() is called multiple times then that should be
> quite easy to accomplish without dropping any work on the floor. We
> can just keep
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 to a usb
switch on some platforms, and connected directly to a usb port
On Mon, Sep 18 2017 at 3:01:32 pm BST, Albert Weichselbraun
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
>> > - Booting with a kernel that does not do a PCI reset yields the
>> > following to
On 19/09/17 18:40, Krzysztof Kozlowski wrote:
> On Mon, Sep 18, 2017 at 12:02:13PM +0200, Andrzej Pietrasiewicz wrote:
>> Odroid XU4 board does not enumerate SuperSpeed devices.
>> This patch makes exynos5 series chips use USB SUSPHY quirk,
>> which solves the problem.
>>
>> Signed-off-by: Andrzej
Douglas Anderson writes:
> Every once in a while when my system is under a bit of stress I see
> some spammy messages show up in my logs that say:
>
> kevent X may have been dropped
>
> As far as I can tell these messages aren't terribly useful.
I agree, FWIW. These messages just confuse users
Douglas Anderson writes:
> If rx_submit() returns an error code then nobody calls usb_free_urb().
> That means it's leaked.
Nope. rx_submit() will call usb_free_urb() before returning an error:
static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
..
if (!skb) {
On Mon, Sep 18, 2017 at 12:02:13PM +0200, Andrzej Pietrasiewicz wrote:
> Odroid XU4 board does not enumerate SuperSpeed devices.
> This patch makes exynos5 series chips use USB SUSPHY quirk,
> which solves the problem.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> arch/arm/boot/dts/exynos54xx
On Tue, Sep 19, 2017 at 7:17 PM, Alan Stern wrote:
> On Tue, 19 Sep 2017, Andrey Konovalov wrote:
>
>> On Fri, Sep 15, 2017 at 8:57 PM, Alan Stern
>> wrote:
>> > On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>> >
>> >> On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern
>> >> wrote:
>> >> > On Thu, 14
On Tue, 19 Sep 2017, Andrey Konovalov wrote:
> On Fri, Sep 15, 2017 at 8:57 PM, Alan Stern wrote:
> > On Thu, 14 Sep 2017, Andrey Konovalov wrote:
> >
> >> On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern
> >> wrote:
> >> > On Thu, 14 Sep 2017, Andrey Konovalov wrote:
> >> >
> >> >> Looked at this a
On Tue, Sep 19, 2017 at 9:15 AM, Douglas Anderson wrote:
> Every once in a while when my system is under a bit of stress I see
> some spammy messages show up in my logs that say:
>
> kevent X may have been dropped
>
> As far as I can tell these messages aren't terribly useful. The
> comments ar
Hi,
Thank you for the reviews and patches!
On 09/08/2017 05:45 PM, Peter Rosin wrote:
On 2017-09-05 18:42, Hans de Goede wrote:
Intel Cherrytrail SoCs have an internal USB mux for muxing the otg-port
USB data lines between the xHCI host controller and the dwc3 gadget
controller. On some Cherry
If rx_submit() returns an error code then nobody calls usb_free_urb().
That means it's leaked.
NOTE: This problem was found solely by code inspection and not due to
any failing test cases.
Signed-off-by: Douglas Anderson
---
drivers/net/usb/usbnet.c | 9 ++---
1 file changed, 6 insertions(
Every once in a while when my system is under a bit of stress I see
some spammy messages show up in my logs that say:
kevent X may have been dropped
As far as I can tell these messages aren't terribly useful. The
comments around the messages make me think that either workqueues used
to work di
In general when you've got a flag communicating that "something needs
to be done" you want to clear that flag _before_ doing the task. If
you clear the flag _after_ doing the task you end up with the risk
that this will happen:
1. Requester sets flag saying task A needs to be done.
2. Worker come
Andreas Böhler writes:
> On 19/09/17 14:25, Bjørn Mork wrote:
>> Bjørn Mork writes:
>>
>> What happens if you kill the mbim-proxy process? Are you then able to
>> use the modem again without resetting it?
>
> I was unable to test that: It can only be killed using SIGKILL, any new
> mbim-proxy p
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 the state of the flexcom driver on resume.
> >
On 19/09/17 14:25, Bjørn Mork wrote:
> Bjørn Mork writes:
>
> What happens if you kill the mbim-proxy process? Are you then able to
> use the modem again without resetting it?
I was unable to test that: It can only be killed using SIGKILL, any new
mbim-proxy processes are then unable to open t
On Fri, Sep 15, 2017 at 8:57 PM, Alan Stern wrote:
> On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>
>> On Thu, Sep 14, 2017 at 7:49 PM, Alan Stern
>> wrote:
>> > On Thu, 14 Sep 2017, Andrey Konovalov wrote:
>> >
>> >> Looked at this a little more.
>> >>
>> >> dummy_timer() stucks in an infinite
On 08.09.2017 20:35, Curt Meyers wrote:
On 09/05/2017 02:56 PM, Curt Meyers wrote:
On 09/04/2017 04:13 AM, Mathias Nyman wrote:
On 04.09.2017 13:46, Felipe Balbi wrote:
Hi,
Mathias Nyman writes:
Unfortunately config endpoint command doesn't log endpoint context in this log,
it should call
On Tue, Sep 19, 2017 at 01:54:57PM +0200, Andrey Konovalov wrote:
> On Mon, Sep 18, 2017 at 8:50 PM, Greg Kroah-Hartman
> wrote:
> > On Mon, Sep 18, 2017 at 07:22:24PM +0200, Andrey Konovalov wrote:
> >> Hi!
> >>
> >> I've got the following crash while fuzzing the kernel with syzkaller.
> >>
> >>
On Tue, Sep 19, 2017 at 1:47 PM, Kim Jaejoong wrote:
> Hi, Andrey Konovalov
>
> Thanks for the report.
>
> 2017-09-19 2:33 GMT+09:00 Andrey Konovalov :
>> Hi!
>>
>> I've got the following crash while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 1
Hi,
sorry about the long delay
On 07.09.2017 18:49, Hans de Goede wrote:
Hi,
On 07-09-17 15:14, Mathias Nyman wrote:
On 05.09.2017 19:42, Hans de Goede wrote:
The Intel cherrytrail xhci controller has an extended cap mmio-range
which contains registers to control the muxing to the xhci (host
Bjørn Mork writes:
> Thanks a lot. These are very useful. The thing is that I really cannot
> see anything going wrong there. The "failed" capture just ends with a
> sequence of successful MBIM indications being read from the firmware.
>
> So whatever goes wrong looks like something entirely
On Mon, Sep 18, 2017 at 8:50 PM, Greg Kroah-Hartman
wrote:
> On Mon, Sep 18, 2017 at 07:22:24PM +0200, Andrey Konovalov wrote:
>> Hi!
>>
>> I've got the following crash while fuzzing the kernel with syzkaller.
>>
>> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>>
>> It seems there'
Hi, Andrey Konovalov
Thanks for the report.
2017-09-19 2:33 GMT+09:00 Andrey Konovalov :
> Hi!
>
> I've got the following crash while fuzzing the kernel with syzkaller.
>
> On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18).
>
> It seems that there's no proper check on the hdesc->bNumDes
Hello and thanks,
> You should use the serial (tty) interface for this (see f_serial.c / serial.c)
Not keen on that for binary data.
> No. g_zero is meant only for testing purposes.
Indeed.
Problem is looking solved using GadgetFS working on the target board.
Promise my next set of USB questi
Andreas Böhler writes:
> On 18/09/17 22:18, Bjørn Mork wrote:
>> Andreas Böhler writes:
>>>
>>> I can also provide you with Wireshark USB traces, if that helps?
>>
>> It might help. We are obviously interacting badly with the firmware.
>> Seeing where and how it stops would be useful.
>
> Attac
On 15/09/2017 at 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 ne
On Tue, Sep 19, 2017 at 05:40:04PM +0800, Joe Lee wrote:
> From: asmtswfae
Shouldn't the name here match the name up in your From: email line?
>
> For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS
> settings, those ports will be enabled anyway after you remove a devic
From: asmtswfae
For AMD Promontory xHCI host, although you can disable USB 2.0 ports in BIOS
settings, those ports will be enabled anyway after you remove a device on
that port and re-plug it in again. It's a known limitation of the chip.
As a workaround we can clear the PORT_WAKE_BITS.
Signed-o
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 the state of the flexcom driver on resume.
>
> Signed-off-by: Romain Izard
Tested-by: Nicolas F
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 16/09/17 19:36, g...@novadsp.com wrote:
> Greetings,
>
> I'm trying to find the simplest way to develop a bulk mode gadget that
> exposes a standard userland IO int
Consider the following case: udc controller supports SuperSpeed.
If we first load a HighSpeed gadget followed by a SuperSpeed gadget,
the SuperSpeed gadget will be limited to HighSpeed as UDC core
driver doesn't call ->udc_set_speed() in the second case.
Call ->udc_set_speed() unconditionally to
Am Dienstag, den 12.09.2017, 11:19 +0200 schrieb Massimo Burcheri:
>
> I asked the manufacturer service why the device reports the wrong product id.
> I got the reply now:
>
> "In order to use UAS that must be enabled in the firmware as well. On that
> device it is not enabled and the official pr
On Mon, Sep 18, 2017 at 09:11:57PM +0200, Andreas Engel wrote:
> Add the USB device id for the ELV TFD500 data logger.
>
> Signed-off-by: Andreas Engel
Thanks for the v2. Now applied.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to major
42 matches
Mail list logo
