From: Frank Zago <frank@zago.net>
To: Johan Hovold <johan@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
Jan-Niklas Burfeind <kernel@aiyionpri.me>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Wolfram Sang <wsa@kernel.org>,
linux-usb@vger.kernel.org, gunar@schorcht.net
Subject: Re: [PATCH v2 1/2] Revert "USB: serial: ch341: add new Product ID for CH341A"
Date: Wed, 12 May 2021 20:00:41 -0500 [thread overview]
Message-ID: <17a4178a-48b7-284c-1c3d-85c570bccf01@zago.net> (raw)
In-Reply-To: <YJumDN4w4KS3Iuap@hovoldconsulting.com>
On 5/12/21 4:55 AM, Johan Hovold wrote:
> On Tue, May 11, 2021 at 08:07:31PM -0500, Frank Zago wrote:
>> Hello,
>>
>> On 5/10/21 2:40 AM, Johan Hovold wrote:
>>> On Thu, Apr 22, 2021 at 07:28:51PM -0500, Frank Zago wrote:
>>>> From: frank zago <frank@zago.net>
>>>>
>>>> The 0x5512 USB PID is for the I2C/GPIO/SPI interfaces. UART is
>>>> still present but only the TX and RX pins are available; DTS,
>>>> DTR, ... are used for other things. Remove the PID, and let a
>>>> I2C driver bind to it.
>>>>
>>>> Existing CH341 boards usually have physical jumpers to switch
>>>> between the 3 modes.
>>>>
>>>> This reverts commit 46ee4abb10a07bd8f8ce910ee6b4ae6a947d7f63.
>>>
>>> You can't just revert something which people clearly depend on
>>> and therefore added to the kernel in the first place.
>>
>> That device in UART mode was already supported by the serial
>> driver. The original submitter just had to move a jumper on his
>> board. There was no need to patch the kernel.
>
> How do you know that the author used a dev board? And are you really
> sure that there are no devices out there which always operate in
> this mode?
The author of commit 46ee4abb10a07bd8 put a link to his device. I have
the same one (or a clone) and it works fine in serial mode without the patch.
I have a different model that works the same way. A jumper selects the mode.
I can't be sure that no one has ever built a board with that chip, selecting
the wrong mode. But the chip is about 10 years old now; someone would have noticed.
>
>> That product ID also supports UART but in a limited way, as only
>> the RX and TX pins are available. However it is the only one that
>> supports i2c/spi/gpio, and that's why I have to revert the patch.
>
> I understand why you did it. My point is that you cannot just claim
> that PID and say that it's only to be used for I2C/SPI without even
> trying to make a case for why that should be ok.
That's the only PID that works for I2C/SPI/GPIO. Right now the serial driver is
claiming it. I don't know what else to say. If I can't revert that patch, my driver
can't be used without blacklisting the serial driver.
>
>> If that's desired, the new driver could add support for that as
>> well, but I don't think it's worth the effort.
>
> We obviously don't want a second serial driver for these devices.
>
>>> Can you reprogram the device with a newly allocated PID to be
>>> used for i2c-only instead?
>>
>> It is possible if the device has an SPI flash connected to it, but
>> none of the cheap boards have that.
>
> That's unfortunate. In principle, your approach is the right one,
> that is, to use a dedicated PID do determine when to configure an
> alternate mode. But since we already know that some people are using
> the PID in question in serial mode, it's not that clear cut.
>
> How do you intend to switch between i2c and spi mode?
i2c, spi and gpio can all be used simultaneously. I have a working spi implementation,
but I'm still testing it. Basically if a user wants to use spi, then 3 specific gpios
will be reserved for MOSI/MISO/CLK (using gpiochip_request_own_desc), with possibly
one or more used for the chip select.
How a user books spi is up in the air right now. That might be done through a sysfs command.
Frank.
next prev parent reply other threads:[~2021-05-13 1:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 0:28 [PATCH v2 1/2] Revert "USB: serial: ch341: add new Product ID for CH341A" Frank Zago
2021-04-23 0:28 ` [PATCH v2 2/2] USB: misc: Add driver for the WCH CH341 in I2C/GPIO mode Frank Zago
2021-05-10 7:53 ` Johan Hovold
2021-05-10 7:40 ` [PATCH v2 1/2] Revert "USB: serial: ch341: add new Product ID for CH341A" Johan Hovold
2021-05-12 1:07 ` Frank Zago
2021-05-12 9:55 ` Johan Hovold
2021-05-13 1:00 ` Frank Zago [this message]
2021-05-13 11:31 ` Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17a4178a-48b7-284c-1c3d-85c570bccf01@zago.net \
--to=frank@zago.net \
--cc=bgolaszewski@baylibre.com \
--cc=gregkh@linuxfoundation.org \
--cc=gunar@schorcht.net \
--cc=johan@kernel.org \
--cc=kernel@aiyionpri.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).