An endpoint conflict occurs when the USB is working in device mode
during an isochronous communication. When the endpointA IN direction
is an isochronous IN endpoint, and the host sends an IN token to
endpointA on another device, then the OUT transaction may be missed
regardless the OUT endpoint nu
Hi Sasha,
i was OOO last week.
Let me check why the patch doesn't apply in the older kernel series.
I originally developed it on a 4.14.86 and ported it to 5.1.
Shouldn't be a big problem, its a "one line mover" only.
BR
Carsten
> -Ursprüngliche Nachricht-
> Von: Sasha Levin [mailto:sa
Am Samstag, den 01.06.2019, 09:52 +0200 schrieb Marco Zatta:
> This patch fixes the chipmunk-like voice that manifets randomly when
> using the integrated mic of the Logitech Webcam HD C270.
>
> The issue was solved initially for this device by commit
> 2394d67e446bf616a0885167d5f0d397bdacfdfc but
Il giorno gio, 30/05/2019 alle 06.25 -0700, Greg KH ha scritto:
> [...]
Hi,
> Any chance you can use 'git bisect' to find the offending commit?
Yes, I am doing it as I managed to build the kernel from source
>
> And did you accidentally turn on "sync" for the filesystem?
Sorry, I don't think so
On Sun, Jun 02, 2019 at 09:24:43PM +1000, Vladimir Yerilov wrote:
> Good day,
>
> There's a problem with ucsi starting from 5.2-rc1 (maybe earlier
> versions of 5.2 are affected too).
> Recently I've tried these versions of rc3 (commits), all have this issue:
> 3ab4436f688c2d2f221793953cd05435ca84
On Sun, 2 Jun 2019, Christian Lamparter wrote:
> This patch follows Alan Stern's recent patch:
> "p54: Fix race between disconnect and firmware loading"
>
> that overhauled carl9170 buggy firmware loading and driver
> unbinding procedures.
>
> Since the carl9170 code was adapted from p54 it uses
No, I can't.
Unfortunately, this exceeds the scope of my knowledge. I simply don't
know enough to understand your request correctly. What I can is to
compile and try some pre-rc1 5.2 kernel and see how it goes. Also I
managed to trace the source of this problem more precisely.
The issue happens on
Hi Sasha,
i have (back)ported the patch to the older kernels mentioned below
where the original patch failed.
The patch appended to this mail applies to v4.14.121, v4.9.178, v4.4.180 and
v3.18.140.
Some changes within the xhci driver prevented git from finding the correct
position.
Hope this h
On Fri, 31 May 2019 at 20:11, Greg KH wrote:
> Can you run 'git bisect' to determine the exact commit that caused this
> problem? That would be most helpful.
Oh for goodness sake. Sorry, I was being an idiot. After half a day of
building bisect scripts and another 3 hours of waiting for
compile
On Mon, 3 Jun 2019, Geoff Winkless wrote:
> On Fri, 31 May 2019 at 20:11, Greg KH wrote:
>
> > Can you run 'git bisect' to determine the exact commit that caused this
> > problem? That would be most helpful.
>
> Oh for goodness sake. Sorry, I was being an idiot. After half a day of
> building
On Mon, 3 Jun 2019 at 16:29, Alan Stern wrote:
> On Mon, 3 Jun 2019, Geoff Winkless wrote:
>
> > Thanks (and also to Alan) for the help, apologies for wasting your time.
>
> Just goes to show we all have our blind spots. I didn't realize what
> was going on either, and I should have.
You're too
In some cases the "Allocate & copy" block in ffs_epfile_io() is not
executed. Consequently, in such a case ffs_alloc_buffer() is never called
and struct ffs_io_data is not initialized properly. This in turn leads to
problems when ffs_free_buffer() is called at the end of ffs_epfile_io().
This patc
In some cases the "Allocate & copy" block in ffs_epfile_io() is not
executed. Consequently, in such a case ffs_alloc_buffer() is never called
and struct ffs_io_data is not initialized properly. This in turn leads to
problems when ffs_free_buffer() is called at the end of ffs_epfile_io().
This patc
Hi Heikki and Wolfram
These patches add support for runtime power management for UCSI CCGx driver.
I have tested them with NVIDIA GPU card which has i2c interface to talk to
CCG controller. I have added runtime pm support for the i2c bus driver as well.
Third version (v4) of patches fix comments
From: Ajay Gupta
Cypress USB Type-C CCGx controller firmware version 3.1.10
(which is being used in many NVIDIA GPU cards) has known issue of
not triggering interrupt when a USB device is hot plugged to runtime
resume the controller. If any GPU card gets latest kernel with runtime
pm support but
From: Ajay Gupta
Cypress USB Type-C CCGx controller firmware version 3.1.10
(which is being used in many NVIDIA GPU cards) has known issue of
not triggering interrupt when a USB device is hot plugged to runtime
resume the controller. If any GPU card gets latest kernel with runtime
pm support but
From: Ajay Gupta
Added a local variable "send_stop" to simplify "goto" statements.
The "send_stop" handles below two case
1) When first i2c start fails and so i2c stop is not sent before
exiting
2) When i2c stop failed after all transfers and we do not need to
send another stop before exiting.
From: Ajay Gupta
Enable runtime pm support with autosuspend delay of three second.
This is to make sure I2C client device Cypress CCGx has completed
all transaction.
Signed-off-by: Ajay Gupta
---
Changes from v3->v4:
- Added comment on why stub gpu_i2c_suspend() is needed for
ru
From: Ajay Gupta
The change enables runtime pm support to UCSI CCG driver.
Added ucsi_resume() function to enable notification after
system reusme. Exported both ucsi_resume() and ucsi_send_command()
symbols in ucsi.c for modular build.
Signed-off-by: Ajay Gupta
---
Changes from v3->v4 : None
On Mon, 3 Jun 2019, Geoff Winkless wrote:
> On Mon, 3 Jun 2019 at 16:29, Alan Stern wrote:
> > On Mon, 3 Jun 2019, Geoff Winkless wrote:
> >
> > > Thanks (and also to Alan) for the help, apologies for wasting your time.
> >
> > Just goes to show we all have our blind spots. I didn't realize what
On Mon, Jun 03, 2019 at 11:58:10AM +0200, Oliver Neukum wrote:
> Are you sure only the C270 is affected?
>
> Regards
> Oliver
>
Hello Oliver,
No, unfortunately I am not sure but I am missing the hardware to
properly test. I am quite sure that it fixes the problem in the C270
Hi Alan, Greg,
When running software in a jailed environment where sysfs or udev is not
readily available and one can only have an FD to usbdevfs device passed
into the jail, there is a desire to allow libusb working. Alan recently
added USBDEVFS_GET_SPEED, but we are still missing bus number and
dev_err() is more appropriate for printing error messages inside
drivers, so switch to dev_err().
Signed-off-by: Fabio Estevam
---
drivers/usb/chipidea/core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index
On Mon, Jun 03, 2019 at 05:24:10PM -0700, Dmitry Torokhov wrote:
> Hi Alan, Greg,
>
> When running software in a jailed environment where sysfs or udev is not
> readily available and one can only have an FD to usbdevfs device passed
> into the jail, there is a desire to allow libusb working. Alan
On Tue, Jun 04, 2019 at 12:58:38AM +1000, Vladimir Yerilov wrote:
> No, I can't.
>
> Unfortunately, this exceeds the scope of my knowledge. I simply don't
> know enough to understand your request correctly. What I can is to
> compile and try some pre-rc1 5.2 kernel and see how it goes. Also I
> ma
On Mon, Jun 03, 2019 at 01:13:48PM +0200, Andrea Vai wrote:
> Il giorno gio, 30/05/2019 alle 06.25 -0700, Greg KH ha scritto:
> > [...]
> Hi,
>
> > Any chance you can use 'git bisect' to find the offending commit?
> Yes, I am doing it as I managed to build the kernel from source
Great! What did
On Mon, Jun 03, 2019 at 11:09:01PM -0300, Fabio Estevam wrote:
> dev_err() is more appropriate for printing error messages inside
> drivers, so switch to dev_err().
>
> Signed-off-by: Fabio Estevam
> ---
> drivers/usb/chipidea/core.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Hi Sasha,
>
> i have (back)ported the patch to the older kernels mentioned below
> where the original patch failed.
>
> The patch appended to this mail applies to v4.14.121, v4.9.178, v4.4.180 and
> v3.18.140.
> Some changes within the xhci driver prevented git from finding the correct
> positi
28 matches
Mail list logo
