I don't know how to do it.
~/github $ git clone https://github.com/torvalds/linux.git
~/github $ cd linux
~/github/linux $ git bisect start
~/github/linux $ git bisect bad v4.9
~/github/linux $ git bisect good v4.8
fatal: BUG: attempt to snprintf into too-small buffer
2017-01-30 8:58 GMT+02:00 Gre
On Thu, Feb 02, 2017 at 12:26:41PM +0200, Vitaly Tonkacheyev wrote:
> I don't know how to do it.
> ~/github $ git clone https://github.com/torvalds/linux.git
> ~/github $ cd linux
> ~/github/linux $ git bisect start
> ~/github/linux $ git bisect bad v4.9
> ~/github/linux $ git bisect good v4.8
> fa
Hi Rob,
On Wed, Feb 1, 2017 at 9:43 PM, Rob Herring wrote:
> On Mon, Jan 30, 2017 at 01:26:12PM +0530, Raviteja Garimella wrote:
>> The device node is used for UDCs integrated into Broadcom's
>> iProc family of SoCs'. The UDC is based on Synopsys Designware
>> Cores AHB Subsystem USB Device Contr
From: Colin Ian King
The 2nd check for a non-zero return from copy_to_user is redundant as
it is has already been made a few lines earlier. This check was made
redundant because of previous fix to the copy_to_user error return
check.
Detected by CoverityScan, CID#114347 ("Logically Dead Code")
I opened a pull request for this patch
https://github.com/torvalds/linux/pull/388
Hope it could restart the discussion
Peace and love,
Raz
-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Thursday, January 5, 2017 9:08 PM
To: Greg Kroah-Hartman
Cc: Raz Manor
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.
Cc:
Signed-off-by: Colin Ian King
---
drivers/usb/stora
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.
>
>
On Thu, Feb 02, 2017 at 12:50:02PM +, Raz Manor wrote:
> I opened a pull request for this patch
> https://github.com/torvalds/linux/pull/388
Linux development does not work with github pull requests, sorry.
Please see Documentation/development_process/ for how we all work
together. Please se
This patch adds a driver for configuration of the Microchip USB251xB/xBi
USB 2.0 hub controller series with USB 2.0 upstream connectivity, SMBus
configuration interface and two to four USB 2.0 downstream ports.
Furthermore add myself as a maintainer for this driver.
The datasheet can be found at
FTDI devices use a receive latency timer to periodically empty the
receive buffer and report modem and line status (also when the buffer is
empty).
When a break or error condition is detected the corresponding status
flags will be set on a packet with nonzero data payload and the flags
are not upd
On Wed, Jun 29, 2016 at 11:59:06PM +0200, Michael Walle wrote:
> Am 2016-05-27 20:02, schrieb Johan Hovold:
> > On Fri, May 13, 2016 at 12:17:24PM +0200, mich...@walle.cc wrote:
> >> Hi,
> >>
> >> if the internal buffer is full, a read() returns a steady stream of
> >> zeros until one valid charac
On 02/01/2017 10:55 PM, Rafał Miłecki wrote:
> On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:
>> On 02/01/2017 04:56 PM, Rafał Miłecki wrote:
>>> On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:
On 01/31/2017 05:11 PM, Rafał Miłecki wrote:
> Thanks a lot Jacek for this explanation (and sor
On 02/02/2017 09:44 PM, Jacek Anaszewski wrote:
On 02/01/2017 10:55 PM, Rafał Miłecki wrote:
On 02/01/2017 10:26 PM, Jacek Anaszewski wrote:
On 02/01/2017 04:56 PM, Rafał Miłecki wrote:
On 01/31/2017 10:34 PM, Jacek Anaszewski wrote:
On 01/31/2017 05:11 PM, Rafał Miłecki wrote:
Thanks a lot
Add new USB IDs for cp2104/5 devices on Bx50v3 boards due to the design change
Signed-off-by: Ken Lin
---
drivers/usb/serial/cp210x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index fff718352e0c..691e3e5f0e61 100644
--- a/driv
14 matches
Mail list logo