From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Gerhard Engleder <gerhard@engleder-embedded.com>
Cc: linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
jirislaby@kernel.org, lukas@wunner.de,
Gerhard Engleder <eg@keba.com>, Daniel Gierlinger <gida@keba.com>
Subject: Re: [PATCH v4 2/2] serial: 8250: add driver for KEBA UART
Date: Thu, 27 Nov 2025 21:58:07 +0200 [thread overview]
Message-ID: <aSitT0qmfb19K69H@smile.fi.intel.com> (raw)
In-Reply-To: <3f3092a0-8e9c-4d5c-9f98-3b574f970361@engleder-embedded.com>
On Thu, Nov 27, 2025 at 08:40:41PM +0100, Gerhard Engleder wrote:
> On 26.11.25 22:33, Andy Shevchenko wrote:
> > On Wed, Nov 26, 2025 at 10:06:17PM +0100, Gerhard Engleder wrote:
> > > On 26.11.25 14:17, Andy Shevchenko wrote:
> > > > On Thu, Oct 23, 2025 at 05:12:29PM +0200, Gerhard Engleder wrote:
...
> > > > Can't you call uart_read_port_properties()?
> > > >
> > > > If ever you gain some properties either via FW description or via software
> > > > nodes, they will be automatically used without need to update the driver!
> > >
> > > Yes that would be some nice behavior. But __uart_read_properties()
> > > sets some defaults even if no firmware node exist (UPF_SHARE_IRQ,
> >
> > Is it a problem? Even a single IRQ may be marked shared.
> >
> > > 0 as irq number
> >
> > It doesn't do that, it just skips setting it in that case.
> >
> > > or it fails if not irq number is found).
> >
> > Yeah, this is most "problematic" part in case of this driver. Why is it
> > auxiliary and not platform? With that the __uart_read_properties() needs
> > to be updated to also query IRQ from respective aux device, and aux dev
> > needs implementation of dev_is_auxiliary(). Not that big deal, though.
>
> It is auxiliary and not platform, because gregkh suggested to switch
> from platform to auxiliary. IMO he is right and that is a better fit,
> because auxiliary devices were introduced to split big devices into
> sub devices, which results in smaller drivers with one job for the
> sub device. That's actually what I tried to do with platform devices
> first.
>
> > > So __uart_read_properties() would need to be changed. IMO it makes no sense
> > > to change __uart_read_properties() as this functionality is currently
> > > not required.
> >
> > Yes, but as I said it will give you for free the possibility to use those
> > properties without future modifications of the driver. OTOH, driver is in
> > tree and modifications will be needed one way or another :-)
>
> Yes, if the KEBA UART changes, then modifications would be needed. We
> kept this UART stable now for over 10 years. As it is FPGA based, we
> can keep it stable as long as FPGAs are on the market. In industrial
> automation the products are in the field for 10 years, 20 years or even
> more. We can only support the devices for that long time by keeping
> them compatible. So I don't expect changes now and therefore I would
> not prepare for them.
Fair enough.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-11-27 19:58 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 15:12 [PATCH v4 0/2] serial: add KEBA UART driver Gerhard Engleder
2025-10-23 15:12 ` [PATCH v4 1/2] serial: Keep rs485 settings for devices without firmware node Gerhard Engleder
2025-10-26 9:25 ` Lukas Wunner
2025-11-26 13:10 ` Andy Shevchenko
2025-11-26 20:42 ` Gerhard Engleder
2025-10-23 15:12 ` [PATCH v4 2/2] serial: 8250: add driver for KEBA UART Gerhard Engleder
2025-10-26 9:30 ` Lukas Wunner
2025-11-26 13:17 ` Andy Shevchenko
2025-11-26 21:06 ` Gerhard Engleder
2025-11-26 21:33 ` Andy Shevchenko
2025-11-27 19:40 ` Gerhard Engleder
2025-11-27 19:58 ` Andy Shevchenko [this message]
2025-11-26 15:46 ` Ilpo Järvinen
2025-11-26 21:30 ` Gerhard Engleder
2025-11-27 9:28 ` Ilpo Järvinen
2025-11-27 19:43 ` Gerhard Engleder
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=aSitT0qmfb19K69H@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=eg@keba.com \
--cc=gerhard@engleder-embedded.com \
--cc=gida@keba.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=lukas@wunner.de \
/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.