Re: [PATCH v2 1/2] Revert "USB: serial: ch341: add new Product ID for CH341A"

From: Johan Hovold <johan@kernel.org>
To: Frank Zago <frank@zago.net>
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 11:55:24 +0200	[thread overview]
Message-ID: <YJumDN4w4KS3Iuap@hovoldconsulting.com> (raw)
In-Reply-To: <8b3c348f-9e05-29f9-9197-8ddf1c8a9e8b@zago.net>

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?

> 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.

> 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?

Johan