Am 27.05.2016 13:23, schrieb Dan Carpenter:
> This loop is supposed to set all the .num values to -1 but it's doesn't
> set the first element and it sets one element beyond the end of the
> array. Really there is no reason for it to be done backwards. And
> "ret" is the wrong variable to use fo
Am 27.05.2016 14:23, schrieb Michal Nazarewicz:
> On Fri, May 27 2016, Dan Carpenter wrote:
>> This loop is supposed to set all the .num values to -1 but it's doesn't
>> set the first element and it sets one element beyond the end of the
>> array. Really there is no reason for it to be done back
much better readable than the original.
nice work
re,
wh
Am 28.05.2016 06:48, schrieb Dan Carpenter:
> This loop is supposed to set all the .num[] values to -1 but it's off by
> one so it skips the first element and sets one element past the end of
> the array.
>
> I've cleaned up the loop a li
Am 19.11.2012 22:34, schrieb Cyril Roelandt:
> Found using the following semantic patch:
>
> @@
> @@
> spin_lock_irqsave(...);
> ... when != spin_unlock_irqrestore(...);
> * GFP_KERNEL
>
>
> Signed-off-by: Cyril Roelandt
> ---
> drivers/usb/gadget/uvc_video.c |2 +-
> 1 file changed, 1 i
Hello List,
is someone aware of a problem with DTR in that driver ?
I use: Linux version 3.4.53-MMI-SW.401_0.1-43
My test was to use TIOCMBIS to set RTS and DTR while
RTS is fine DTR is dead.
re,
wh
ps: please mail me directly i am not a list member.
--
To unsubscribe from this list: send the
I am aware of it, the system is a prototype and they wanted
to stay with something they know.
I will ask for am update.
re,
wh
Am 29.02.2016 17:10, schrieb Greg KH:
> On Mon, Feb 29, 2016 at 02:47:45PM +0100, walter harms wrote:
>> Hello List,
>>
>> is someone aware of
Am 29.02.2016 17:10, schrieb Greg KH:
> On Mon, Feb 29, 2016 at 02:47:45PM +0100, walter harms wrote:
>> Hello List,
>>
>> is someone aware of a problem with DTR in that driver ?
>>
>> I use: Linux version 3.4.53-MMI-SW.401_0.1-43
>
> That's a very
Am 17.03.2016 18:04, schrieb Greg KH:
> On Thu, Mar 17, 2016 at 05:41:13PM +0100, walter harms wrote:
>>
>>
>> Am 29.02.2016 17:10, schrieb Greg KH:
>>> On Mon, Feb 29, 2016 at 02:47:45PM +0100, walter harms wrote:
>>>> Hello List,
>>>>
>
Am 02.02.2017 14:19, schrieb Colin King:
> From: Colin Ian King
>
> If jumpshot_get_status continues to return a failed result then the
> wait loop will spin forever because the waitcount counter is never
> being incremented and we don't ever timeout. Fix this by incrementing
> waitcount.
>
>
Am 17.11.2012 16:06, schrieb Dan Carpenter:
> If param->length is zero, then this could lead to a divide by zero bug
> later in the function when we do: size %= max;
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
> index f10bd97..7667b
Am 05.04.2013 07:43, schrieb Dan Carpenter:
> "len" comes from the USB transfer and it's probably correct. The thing
> is that we already have similar checks like:
>
> if (data[i] >= serial->num_ports) {
>
> So adding a sanity test here matches the rest of the code and is a good
> idea
Am 01.08.2019 09:47, schrieb Christophe JAILLET:
> There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()'
> here. These calls are done from probe functions and using GFP_KERNEL should
> be safe.
> The memory itself is used within some interrupts, but it is not a
> problem, once i
Am 20.11.2017 18:40, schrieb Colin King:
> From: Colin Ian King
>
> The assignment of DIV to itself is redundant and can be removed.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/usb/serial/iuu_phoenix.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/usb/serial/iuu_phoe
Hello List,
does some use linux with an Edgeport/416 ?
I have a strange problem. the device is resetting soon
after i started using it (but not immediately).
I do not see a kernel OOPS but a common pattern is:
2019-08-20T15:19:39.825812+00:00 omnfrmo10 kernel: [683270.658623] usb 7-1.1.2:
New US
>> Von: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> ow...@vger.kernel.org] Im Auftrag von walter harms
>> Gesendet: Mittwoch, 21. August 2019 13:18
>> An: linux-usb@vger.kernel.org
>> Cc: g...@kroah.com
>> Betreff: problems with Edgeport/416
>>
Am 21.08.2019 14:20, schrieb Greg KH:
> On Wed, Aug 21, 2019 at 01:48:46PM +0200, walter harms wrote:
>>
>>
>> Am 21.08.2019 13:20, schrieb Greg KH:
>>> On Wed, Aug 21, 2019 at 12:27:24PM +0200, walter harms wrote:
>>>> Hello List,
>>>>
Am 21.08.2019 15:20, schrieb Schmid, Carsten:
>>
>> Different computer but same cables i guess the device is ok.
>>
> But maybe the USB port of the computer is broken.
>
>> NTL I found that little gem:
>> https://www.fclose.com/linux-kernels/594677/usb-io_ti-add-heartbeat-to-
>> keep-idle-ep-41
Am 21.08.2019 16:24, schrieb Schmid, Carsten:
>>
>> this should it be,
>>
> Suspicious: line 141 of the log:
> [765647.193393] usb 7-1.1.2: reset full-speed USB device number 15 using
> uhci_hcd
>
> Can you please collect another log around reset, additionally enabling uhci
> dyndbg using
> e
Am 11.10.2019 15:35, schrieb Dan Carpenter:
> The problem is that sizeof() is unsigned long so negative error codes
> are type promoted to high positive values and the condition becomes
> false.
>
> Fixes: 1d427be4a39d ("USB: legousbtower: fix slab info leak at probe")
> Signed-off-by: Dan Carp
19 matches
Mail list logo
