[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxBHL6YzF2dAWf3q@kroah.com>
Date: Thu, 1 Sep 2022 07:46:23 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>, davem@...emloft.net,
pabeni@...hat.com, edumazet@...gle.com,
Michal Michalik <michal.michalik@...el.com>,
netdev@...r.kernel.org, richardcochran@...il.com,
Gurucharan <gurucharanx.g@...el.com>,
Jiri Slaby <jirislaby@...nel.org>,
Johan Hovold <johan@...nel.org>
Subject: Re: [PATCH net 3/3] ice: Add set_termios tty operations handle to
GNSS
On Wed, Aug 31, 2022 at 02:54:39PM -0700, Jakub Kicinski wrote:
> On Mon, 29 Aug 2022 15:00:49 -0700 Tony Nguyen wrote:
> > From: Michal Michalik <michal.michalik@...el.com>
> >
> > Some third party tools (ex. ubxtool) try to change GNSS TTY parameters
> > (ex. speed). While being optional implementation, without set_termios
> > handle this operation fails and prevents those third party tools from
> > working.
What tools are "blocked" by this? And what is the problem they have
with just the default happening here? You are now doing nothing, while
if you do not have the callback, at least a basic "yes, we accepted
these values" happens which was intended for userspace to not know that
there was a problem here.
> TTY interface in ice driver is virtual and doesn't need any change
> > on set_termios, so is left empty. Add this mock to support all Linux TTY
> > APIs.
"mock"?
> >
> > Fixes: 43113ff73453 ("ice: add TTY for GNSS module for E810T device")
> > Signed-off-by: Michal Michalik <michal.michalik@...el.com>
> > Tested-by: Gurucharan <gurucharanx.g@...el.com> (A Contingent worker at Intel)
> > Signed-off-by: Tony Nguyen <anthony.l.nguyen@...el.com>
>
> Please CC GNSS and TTY maintainers on the patches relating to
> the TTY/GNSS channel going forward.
>
> CC: Greg, Jiri, Johan
>
> We'll pull in a day or two if there are no objections.
Please see above, I'd like to know what is really failing here and why
as forcing drivers to have "empty" functions like this is not good and
never the goal.
thanks,
greg k-h
Powered by blists - more mailing lists