On 2018-10-25 23:55, Ajay Gupta wrote:
> Hi Heikki and Andy
> [...]
Shouldn't you return -ETIMEDOUT if count == 0?
>>> Yes. Good catch. Does the below fix looks ok?
>>>
>>> do {
>>> status = ccg_write(uc, CCGX_RAB_INTR_REG, &data,
>>> sizeof(data));
>>>
Raydium USB touchscreen fails to set config if LPM is enabled:
[2.030658] usb 1-8: New USB device found, idVendor=2386, idProduct=3119
[2.030659] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[2.030660] usb 1-8: Product: Raydium Touch System
[2.030661] usb 1-8: M
Hi Wolfram-san,
> From: Wolfram Sang, Sent: Friday, October 26, 2018 7:58 AM
> > static const struct dev_pm_ops usbhsc_pm_ops = {
> > .suspend= usbhsc_suspend,
> > .resume = usbhsc_resume,
>
> Unrelated to this patch, but I wonder right now: is there a re
On Wed, Oct 24, 2018 at 04:51:34PM +0300, Jarkko Nikula wrote:
> Platform drivers don't need dummy runtime PM callbacks that just return
> success in order to have runtime PM happening. This has changed since
> following commits:
>
> 05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callback
On Wed, Oct 24, 2018 at 04:51:33PM +0300, Jarkko Nikula wrote:
> Platform drivers don't need dummy runtime PM callbacks that just return
> success in order to have runtime PM happening. This has changed since
> following commits:
>
> 05aa55dddb9e ("PM / Runtime: Lenient generic runtime pm callback
From: Ajay Gupta
Hi Heikki and Wolfram,
These two changes add support for USB Type-C interface on latest NVIDIA GPU
card.
The Type-C controller used is Cypress CCGx and is over I2C interface.
I2C host controller has known limitation of sending STOP after every read. Since
each read can be of 4
From: Ajay Gupta
Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
over I2C interface.
This UCSI I2C driver uses I2C bus driver interface for communicating
with Type-C controller.
Signed-off-by: Ajay Gupta
---
Changes from v1 -> v2
Fixed identation in drivers/usb/typec/ucsi
From: Ajay Gupta
Latest NVIDIA GPU card has USB Type-C interface. There is a
Type-C controller which can be accessed over I2C.
This driver adds I2C bus driver to communicate with Type-C controller.
I2C client driver will be part of USB Type-C UCSI driver.
Signed-off-by: Ajay Gupta
---
Changes
Hi Heikki and Andy
[...]
> > > Shouldn't you return -ETIMEDOUT if count == 0?
> > Yes. Good catch. Does the below fix looks ok?
> >
> > do {
> > status = ccg_write(uc, CCGX_RAB_INTR_REG, &data,
> > sizeof(data));
> > if (status < 0)
> >
Hi Heikki,
> > > I still didn't understand why can't this just be taken care of in
> > > your I2C host driver? Why can't you just read 4 bytes at a time in
> > > your master_xfer hook until you have received as much as the message
> > > is asking, and only after that return?
> >
> > The I2C host ha
Hi Andy,
> > > > > > Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller
> > > > > > over I2C interface.
> > > > > >
> > > > > > This UCSI I2C driver uses I2C bus driver interface for
> > > > > > communicating with Type-C controller.
> > >
> > > > > > + /*
> > > > > > +* Flush CCGx
Hi Colin,
On 10/16/2018 12:03 PM, Colin King wrote:
> From: Colin Ian King
>
> Currently the call to atoi is being passed a single char string
> that is not null terminated, so there is a potential read overrun
> along the stack when parsing for an integer value. Fix this by
> instead using a 2
On Thu, 25 Oct 2018, Mathias Nyman wrote:
> On 25.10.2018 12:52, Hao Wei Tee wrote:
> > On 25/10/18 4:45 PM, Mathias Nyman wrote:
> >> Reproducing the issue with a recent kernel with xhci traces enabled should
> >> show the reason for EPROTO error.
> >>
> >> Add xhci traces before triggering the
I did test double reads and always saw the same value both times.
Another piece of info: I tested this software on an older vortex86dx
and saw the same issue. It is plausible that a vortex86dx and
vortex86dx3 could have the same flawed EHCI. Or perhaps there's some
other systemic issue that I'm
From: Daniel Goertzen
> Sent: 24 October 2018 17:47
>
> I am developing a custom USB device that makes use of isochronous IN
> transfers. It works fine from my laptop (xHCI) however on an embedded
> target (vortex86dx3, EHCI) I am seeing mysterious EFBIG errors. After
> adding lots of debug to e
On 25.10.2018 12:52, Hao Wei Tee wrote:
On 25/10/18 4:45 PM, Mathias Nyman wrote:
Reproducing the issue with a recent kernel with xhci traces enabled should show
the reason for EPROTO error.
Add xhci traces before triggering the issue with:
mount -t debugfs none /sys/kernel/debug
echo 81920 >
On Thu, 25 Oct 2018, Dennis Wassenberg wrote:
> Hi all,
>
> I have a question regarding the usb hub driver (drivers/usb/core/hub.c).
>
> There is the following scenario. I am using the Lenovo T580 device with the
> Lenovo UltraDock CS18 docking station. If I plug an usb-c device to the
> docki
Hi Frieder,
On Thu, Sep 20, 2018 at 10:52 AM Frieder Schrempf
wrote:
>
> Hi,
>
> I have a question concerning the setup for a board with an onboard USB
> hub. The SoC (i.MX6S) is expected to provide a 12 MHz clock on one of
> the clock output pins as a reference for the USB hub.
>
> Now I was loo
Hi,
Using kernel 4.19 its exactly the same behavior.
Best regards,
Dennis
On 25.10.18 14:28, Greg Kroah-Hartman wrote:
> On Thu, Oct 25, 2018 at 02:20:50PM +0200, Dennis Wassenberg wrote:
>> The code change for Kernel 4.14 look as follows:
>
> 4.14 is a year old now, can you try 4.19 to see i
On Thu, Oct 25, 2018 at 02:20:50PM +0200, Dennis Wassenberg wrote:
> The code change for Kernel 4.14 look as follows:
4.14 is a year old now, can you try 4.19 to see if it works better?
Lots of good xhci fixes and features have been added since then.
thanks,
greg k-h
Hi all,
I have a question regarding the usb hub driver (drivers/usb/core/hub.c).
There is the following scenario. I am using the Lenovo T580 device with the
Lenovo UltraDock CS18 docking station. If I plug an usb-c device to the docking
station there is one device which will not be recognized (
On 25/10/18 4:45 PM, Mathias Nyman wrote:
Reproducing the issue with a recent kernel with xhci traces enabled should show
the reason for EPROTO error.
Add xhci traces before triggering the issue with:
mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
On Wed, Oct 24, 2018 at 05:43:27PM +, Ajay Gupta wrote:
> Hi Andy
>
> > > > > Latest NVIDIA GPU cards have a Cypress CCGx Type-C controller over
> > > > > I2C interface.
> > > > >
> > > > > This UCSI I2C driver uses I2C bus driver interface for
> > > > > communicating with Type-C controller.
>
Hi Peter,
> > I still didn't understand why can't this just be taken care of in your
> > I2C host driver? Why can't you just read 4 bytes at a time in your
> > master_xfer hook until you have received as much as the message is
> > asking, and only after that return?
>
> The I2C host hardware *can
On 2018-10-25 10:17, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Oct 23, 2018 at 06:56:59PM +, Ajay Gupta wrote:
+ /* i2c adapter (ccgx-ucsi) can read 4 byte max */
>>>
>>> By "i2c adapter" do you mean this Cypress CCGx controller, or the NVIDIA I2C
>>> host adapter?
>> It mean NVIDIA I2C h
On Thu, Oct 25, 2018 at 10:27:20AM +0300, Heikki Krogerus wrote:
> On Wed, Oct 24, 2018 at 08:07:09PM +0300, Sergei Shtylyov wrote:
> > Hello!
> >
> > On 10/24/2018 06:05 PM, Heikki Krogerus wrote:
> >
> > > When the connections are defined in firmware, struct
> > > device_connection will have th
On 25.10.2018 06:37, Hao Wei Tee wrote:
Hi,
There are multiple reports[1][2][3] (more elsewhere on the internet) of USB 3
GbE adapters throwing EPROTO errors on USB transfer especially when the devices
are under load. Both of the two common chipsets (Realtek RTL8153 (r8152[4]) and
Asix AX88179 (
Hi,
On Tue, Oct 23, 2018 at 06:56:59PM +, Ajay Gupta wrote:
> > > + /* i2c adapter (ccgx-ucsi) can read 4 byte max */
> >
> > By "i2c adapter" do you mean this Cypress CCGx controller, or the NVIDIA I2C
> > host adapter?
> It mean NVIDIA I2C host adapter with name "ccgx-ucsi"
>
> > > + whil
On Wed, Oct 24, 2018 at 08:33:53AM -0700, Randy Dunlap wrote:
> On 10/24/18 8:05 AM, Heikki Krogerus wrote:
> > This will prepare the device connection API for connections
> > described in firmware.
> >
> > Signed-off-by: Heikki Krogerus
> > ---
> > include/linux/device.h | 6 ++
> > 1 file
On Wed, Oct 24, 2018 at 08:07:09PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 10/24/2018 06:05 PM, Heikki Krogerus wrote:
>
> > When the connections are defined in firmware, struct
> > device_connection will have the fwnode member pointing to
> > the device node (struct fwnode_handle) of the r
30 matches
Mail list logo
