From: Greg KH <gregkh@linuxfoundation.org>
To: Mathieu Peyrega <mathieu.peyrega@gmail.com>
Cc: linux-serial@vger.kernel.org, jirislaby@kernel.org, giometti@linux.it
Subject: Re: [PATCH] Allow PPS on CTS pin and non-RS232 UARTs
Date: Tue, 21 Dec 2021 11:06:15 +0100 [thread overview]
Message-ID: <YcGnF8KC0lJ180Vc@kroah.com> (raw)
In-Reply-To: <9d5477e0046927fe95badb63e53af7251c5667a5.camel@gmail.com>
On Tue, Dec 21, 2021 at 10:36:39AM +0100, Mathieu Peyrega wrote:
> Le lundi 20 décembre 2021 à 16:43 +0100, Greg KH a écrit :
> > On Sat, Dec 04, 2021 at 04:57:56PM +0100, Mathieu Peyrega wrote:
> > > Le vendredi 03 décembre 2021 à 14:11 +0100, Greg KH a écrit :
> > > > On Thu, Dec 02, 2021 at 11:56:10AM +0100, Mathieu Peyrega wrote:
> > > > >
> > I don't fully understand the point. Isn't the existing pps_ldisc
> > > module
> > > already affecting the whole system ? (with it's builtin fixed
> > > "options"). How different tunable options such as the proposal make
> > > things fundamentally different ? Still I agree that per device
> > > settings
> > > would be better.
> >
> > Per device settings are required, this would prevent multiple devices
> > working in the same system, one using the existing line discipline
> > functionality, and one with your new changes.
>
> Is this per device settings requierement valid also for a new line
> discipline module or is it acceptable if a new "module level settable"
> linee discipline module has also a global behaviour (as current one)
> ?If per tty device setting is requiered pointers/doc on possible
> exemples/mecanismes to achieve this are welcome.
If you make this a new line discipline, that is fine, as you can set
each tty device to have their own discipline.
But do not have options for that line discipline, on a module-basis,
that way will not work (think about multiple devices all using the same
line discipline.)
> > Try this as a new line discipline, should be much easier and simpler
> > overall for everyone.
>
> I have been working a little on this already, was waiting for list
> comments/answers to proceed further.
> Is there a prefered name as the module is mostly a clone of the pps-
> ldisc current one one with first patch changes ? I went for ppsex-ldisc
> for now.
> Is it Ok to share & modify the C structures of pps-ldisc (especially
> tty_ldisc_ops as per initially proposed patch) or should a full new set
> also be added ?
I do not know, let's see what you think would work and post that and we
can go from there.
thanks,
greg k-h
prev parent reply other threads:[~2021-12-21 10:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 10:56 [PATCH] Allow PPS on CTS pin and non-RS232 UARTs Mathieu Peyrega
2021-12-03 13:11 ` Greg KH
2021-12-04 15:57 ` Mathieu Peyrega
2021-12-20 15:43 ` Greg KH
2021-12-21 9:36 ` Mathieu Peyrega
2021-12-21 10:06 ` Greg KH [this message]
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=YcGnF8KC0lJ180Vc@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=giometti@linux.it \
--cc=jirislaby@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mathieu.peyrega@gmail.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.