linux-kernel - Re: [PATCH v2 1/1] tty: i3c: add TTY over I3C master support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZTfVV3DW8jqH6ek9@lizhi-Precision-Tower-5810>
Date:   Tue, 24 Oct 2023 10:31:51 -0400
From:   Frank Li <Frank.li@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     alexandre.belloni@...tlin.com, conor.culhane@...vaco.com,
        imx@...ts.linux.dev, jirislaby@...nel.org, joe@...ches.com,
        linux-i3c@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org, miquel.raynal@...tlin.com
Subject: Re: [PATCH v2 1/1] tty: i3c: add TTY over I3C master support

On Tue, Oct 24, 2023 at 11:30:33AM +0200, Greg KH wrote:
> On Mon, Oct 23, 2023 at 12:26:42PM -0400, Frank Li wrote:
> > On Sat, Oct 21, 2023 at 07:02:40PM +0200, Greg KH wrote:
> > > Note, your subject line needs to change.
> > > 
> > > On Fri, Oct 20, 2023 at 12:00:27PM -0400, Frank Li wrote:
> > > > In typical embedded Linux systems, UART consoles require at least two pins,
> > > > TX and RX. In scenarios where I2C/I3C devices like sensors or PMICs are
> > > > present, we can save these two pins by using this driver. Pins is crucial
> > > 
> > > "Pins are crucial"
> > > 
> > > > resources, especially in small chip packages.
> > > > 
> > > > This introduces support for using the I3C bus to transfer console tty data,
> > > > effectively replacing the need for dedicated UART pins. This not only
> > > > conserves valuable pin resources but also facilitates testing of I3C's
> > > > advanced features, including early termination, in-band interrupt (IBI)
> > > > support, and the creation of more complex data patterns. Additionally,
> > > > it aids in identifying and addressing issues within the I3C controller
> > > > driver.
> > > 
> > > But where is the serial data ending up at?  Not a normal uart, what is
> > > on the other end?  And do line settings mean anything here?
> > 
> > Currently, it use slave i3c code. 
> > https://lore.kernel.org/imx/20231018215809.3477437-1-Frank.Li@nxp.com/T/#t
> > 
> > idealy build an i3c->usb dongle to bride it to usb acm. 
> 
> So no one has built such a thing yet to determine if any of this works?

It is easy to proof concept by I3C slave code and USB gadget ACM, then pipe
two tty (ttyACM0 and ttySI3C0 together).

Of we also can implement a USB to I3C class standard, base on this, reuse
this tty driver at host side.

Frank

> 
> > > > +static DEFINE_IDR(i3c_tty_minors);
> > > > +static DEFINE_MUTEX(i3c_tty_minors_lock);
> > > 
> > > I thought idr didn't need a mutex anymore, are you sure this is still
> > > needed?
> > > 
> > > > +static struct tty_driver *i3c_tty_driver;
> > > > +
> > > > +#define I3C_TTY_MINORS		256
> > > 
> > > Do you really need 256 minors?
> > 
> > Any resource concern about it. Maybe 32/64 is enough. I refer from USB tty
> > driver.
> 
> USB serial devices are quite common, and in some places, replaced PCI
> serial cards for modem connections.  So for them, we do actually use all
> 256 minors.
> 
> But for this, it's a debugging device, how are you going to have so many
> different debugging ports on a system at once?
> 
> How about making it small, like 8, and see if you ever actually exceed
> that in real life?
> 
> thanks,
> 
> greg k-h