Message-ID: <CAL_jEz_9aMMBHk43vZp5yber5q5ENLELv1nsv1f7ZtYQMVd8tA@mail.gmail.com>
Date:	Fri, 16 Oct 2015 10:11:12 -0500
From:	Konstantin Shkolnyy <konstantin.shkolnyy@...il.com>
To:	Johan Hovold <johan@...nel.org>
Cc:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] USB: serial: cp210x: Workaround for cp2108 failure due
 to GET_LINE_CTL bug

On Fri, Oct 16, 2015 at 8:27 AM, Johan Hovold <johan@...nel.org> wrote:
> On Thu, Oct 15, 2015 at 06:23:31PM -0500, Konstantin Shkolnyy wrote:
>> cp2108 GET_LINE_CTL returns the 16-bit value with the 2 bytes swapped.
>> However, SET_LINE_CTL functions properly. When the driver tries to modify
>> the register, it reads it, modifies some bits and writes back. Because the
>> read bytes were swapped, this often results in an invalid value to be written.
>> In turn, this causes cp2108 respond with a stall. The stall sometimes doesn't
>> clear properly and cp2108 starts responding to following valid commands also
>> with stalls, effectively failing.
>
> That sounds weird. Are you saying that all or only some cp2108 devices
> would be affected by this? And only for the line-control register?

The bug exists in all current cp2108 devices and affects only
GET_LINE_CTL. But it may be fixed in a future revision.

> What is the endianess of your host by the way?

I'm using an Intel-based Dell desktop, so its LE.

[...]
>> @@ -343,6 +344,10 @@ static int cp210x_get_config(struct usb_serial_port *port, u8 request,
>>               return result;
>>       }
>>
>> +     /* Workaround for swapped bytes in 16-bit value from CP210X_GET_LINE_CTL */
>> +     if (spriv->swap_get_line_ctl && request == CP210X_GET_LINE_CTL && size == 2)
>> +             swab16s((u16 *)data);
>> +
>
> If we determine we need this, then it should probably be isolated to a
> dedicated line-control helper function.

I feel that you want to kill cp210x_get_config. I can easily see why
you don't like it :-) I'll gladly replace all
"cp210x_get_config(GET_LINE_CTL)" calls with a new
"cp210x_get_line_ctl" helper if you don';t mind.

[...]
>> +     port = serial->port[0];
>>
>>       spriv = kzalloc(sizeof(*spriv), GFP_KERNEL);
>>       if (!spriv)
>>               return -ENOMEM;
>>
>> +     /* get_config and set_config rely on this spriv field */
>>       cur_altsetting = serial->interface->cur_altsetting;
>>       spriv->bInterfaceNumber = cur_altsetting->desc.bInterfaceNumber;
>>
>> +     /* Detect CP2108 bug and activate workaround.
>> +      * Write a known good value 0x800, read it back.
>> +      * If it comes back swapped the bug is detected.
>> +      */
>> +
>> +     /* The following get_config won't swap the bytes */
>> +     spriv->swap_get_line_ctl = false;
>> +
>> +     /* must be set before calling get_config and set_config */
>>       usb_set_serial_data(serial, spriv);
>>
>> +     line_ctl = 0x800;
>> +
>> +     err = cp210x_set_config(port, CP210X_SET_LINE_CTL, &line_ctl, 2);
>
> Calling port functions before the ports have been fully initialised
> isn't very nice, even if it works for this driver. This should probably
> be done in a helper function that accesses this register directly (and

So usb_control_msg should be fine to call here, right?

> perhaps also avoids overwriting the default setting).

You mean save and restore the register setting around this bug detection?

[...]

Thanks,
Konstantin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists