From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: "Hugo Villeneuve" <hugo@hugovil.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
"Hugo Villeneuve" <hvilleneuve@dimonoff.com>
Subject: Re: [PATCH v2 02/15] serial: core: add uart_iotype_mmio/legacy_io helper functions
Date: Mon, 4 May 2026 17:30:23 +0300 [thread overview]
Message-ID: <afitf0I1izLup5TR@ashevche-desk.local> (raw)
In-Reply-To: <alpine.DEB.2.21.2605041220540.23161@angie.orcam.me.uk>
On Mon, May 04, 2026 at 12:44:41PM +0100, Maciej W. Rozycki wrote:
> On Mon, 4 May 2026, Andy Shevchenko wrote:
...
> > > > Why do we use 'legacy'? Still in use in modern CPUs...
> > >
> > > Deprecated in PCIe and not available in numerous systems. Also actually
> > > called "legacy" in some serial port datasheets aged ~20 years now. While
> > > some contemporary CPUs indeed retain the port I/O address space, it's for
> > > legacy use anyway, you don't want to rely on it in new designs.
> >
> > For the holder of the new (modern) CPU which supports the IO ports, this is
> > definitely not a legacy interface despite on whatever PCIe or other datasheets
> > call it.
>
> I appreciate your point of view, however I disagree that the presence of an
> interface in a contemporary chip makes the interface modern.
I appreciate a bike shedding.
> I see the port I/O space so much legacy as say the PC/AT DMA controller
> (8237 pair), which is similarly present in current x86 chipsets. If this
> stuff was not present, such as say the PC/AT interrupt controller (8259A
> pair), which I believe has been removed from some x86 system designs, then
> it would be obsolete/removed rather than legacy.
>
> It is analogous to PCI/e systems that lack a southbridge and are called
> "legacy-free", as the whole southbridge stuff, the main consumer of the
> port I/O space still remaining in use, is legacy nowadays (the other one I
> know of being the 8255-based PC parallel port, which has been considered a
> legacy interface as well, even though you can still buy and plug one into
> a modern PCIe system).
>
> NB I have a couple of modern x86 CPUs around too that support the port
> I/O space, but it doesn't change my view as to the nomenclature.
Is the regular user assumed to go to dig to the mailing list (at best) or drawn
into the search of the documentation for all this? In their perspective they
possess modern CPU with support of that technology. If the same user possesses
the HW uses that ("legacy") technology, it doesn't make so in their eyes.
On top of that the additional word occupies more space in the code, making it
harder to read. It's just a redundant word. I see no value at all of using it.
P.S.
I see no value in this discussion. And I see no point to add a word where it's
not needed at all.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-05-04 14:30 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 17:53 [PATCH v2 00/15] serial: add new I/O type for SPI and I2C bus devices Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 01/15] serial: 8250_hub6: add hub6_match_port() Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 02/15] serial: core: add uart_iotype_mmio/legacy_io helper functions Hugo Villeneuve
2026-04-30 15:08 ` Andy Shevchenko
2026-04-30 15:30 ` Hugo Villeneuve
2026-05-01 11:48 ` Andy Shevchenko
2026-05-02 23:25 ` Maciej W. Rozycki
2026-05-04 8:48 ` Andy Shevchenko
2026-05-04 11:44 ` Maciej W. Rozycki
2026-05-04 14:30 ` Andy Shevchenko [this message]
2026-05-04 15:20 ` Maciej W. Rozycki
2026-05-04 15:59 ` Andy Shevchenko
2026-04-28 17:53 ` [PATCH v2 03/15] serial: core: use uart_iotype_*() to simplify uart_match_port() Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 04/15] serial: core: use uart_iotype_*() to simplify uart_line_info() Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 05/15] serial: core: replace snprintf with more robust scnprintf Hugo Villeneuve
2026-04-30 15:07 ` Andy Shevchenko
2026-05-04 15:27 ` Hugo Villeneuve
2026-05-04 15:59 ` Andy Shevchenko
2026-04-28 17:53 ` [PATCH v2 06/15] serial: core: fix indentation/alignment Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 07/15] serial: core: use uart_iotype_*() to simplify uart_report_port() Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 08/15] serial: earlycon: use uart_iotype_*() to simplify code Hugo Villeneuve
2026-04-30 15:03 ` Andy Shevchenko
2026-05-04 15:40 ` Hugo Villeneuve
2026-05-04 16:01 ` Andy Shevchenko
2026-04-28 17:53 ` [PATCH v2 09/15] serial: 8250: " Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 10/15] serial: 8250_rsa: " Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 11/15] serial: core: add new I/O type for SPI and I2C bus devices Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 12/15] serial: sc16is7xx: use new UPIO_BUS as iotype Hugo Villeneuve
2026-04-28 17:53 ` [PATCH v2 13/15] serial: max310x: " Hugo Villeneuve
2026-04-28 17:54 ` [PATCH v2 14/15] serial: max3100: " Hugo Villeneuve
2026-04-28 17:54 ` [PATCH v2 15/15] serial: uniformize serial port I/O infos display Hugo Villeneuve
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=afitf0I1izLup5TR@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hugo@hugovil.com \
--cc=hvilleneuve@dimonoff.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=macro@orcam.me.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox