From: Greg KH <gregkh@linuxfoundation.org>
To: Frank Li <Frank.li@nxp.com>
Cc: alexandre.belloni@bootlin.com, conor.culhane@silvaco.com,
imx@lists.linux.dev, jirislaby@kernel.org, joe@perches.com,
linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, miquel.raynal@bootlin.com
Subject: Re: [PATCH v2 1/1] tty: i3c: add TTY over I3C master support
Date: Tue, 24 Oct 2023 17:05:47 +0200 [thread overview]
Message-ID: <2023102442-immorally-repost-e736@gregkh> (raw)
In-Reply-To: <ZTfVV3DW8jqH6ek9@lizhi-Precision-Tower-5810>
On Tue, Oct 24, 2023 at 10:31:51AM -0400, Frank Li wrote:
> 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).
So you have not actually tested this? why write a driver that no one is
using?
> Of we also can implement a USB to I3C class standard, base on this, reuse
> this tty driver at host side.
Is there a USB I3C standard? I see i3c descriptors assigned by the
USB-IF, but haven't dug to see if there's more than that anywhere...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Frank Li <Frank.li@nxp.com>
Cc: alexandre.belloni@bootlin.com, conor.culhane@silvaco.com,
imx@lists.linux.dev, jirislaby@kernel.org, joe@perches.com,
linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org, miquel.raynal@bootlin.com
Subject: Re: [PATCH v2 1/1] tty: i3c: add TTY over I3C master support
Date: Tue, 24 Oct 2023 17:05:47 +0200 [thread overview]
Message-ID: <2023102442-immorally-repost-e736@gregkh> (raw)
In-Reply-To: <ZTfVV3DW8jqH6ek9@lizhi-Precision-Tower-5810>
On Tue, Oct 24, 2023 at 10:31:51AM -0400, Frank Li wrote:
> 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).
So you have not actually tested this? why write a driver that no one is
using?
> Of we also can implement a USB to I3C class standard, base on this, reuse
> this tty driver at host side.
Is there a USB I3C standard? I see i3c descriptors assigned by the
USB-IF, but haven't dug to see if there's more than that anywhere...
thanks,
greg k-h
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2023-10-24 15:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 16:00 [PATCH v2 1/1] tty: i3c: add TTY over I3C master support Frank Li
2023-10-20 16:00 ` Frank Li
2023-10-21 17:02 ` Greg KH
2023-10-21 17:02 ` Greg KH
2023-10-23 16:26 ` Frank Li
2023-10-23 16:26 ` Frank Li
2023-10-24 9:30 ` Greg KH
2023-10-24 9:30 ` Greg KH
2023-10-24 14:31 ` Frank Li
2023-10-24 14:31 ` Frank Li
2023-10-24 15:05 ` Greg KH [this message]
2023-10-24 15:05 ` Greg KH
2023-10-24 15:59 ` Frank Li
2023-10-24 15:59 ` Frank Li
2023-10-24 16:04 ` Frank Li
2023-10-24 16:04 ` Frank Li
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=2023102442-immorally-repost-e736@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=Frank.li@nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=conor.culhane@silvaco.com \
--cc=imx@lists.linux.dev \
--cc=jirislaby@kernel.org \
--cc=joe@perches.com \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.