[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <04275b02-0f04-4aed-9e05-7346daf7f102@app.fastmail.com>
Date: Wed, 01 Nov 2023 11:55:29 +0000
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Arnd Bergmann" <arnd@...db.de>,
Linux-Arch <linux-arch@...r.kernel.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
"Baoquan He" <bhe@...hat.com>
Subject: Re: Overhead of io{read,write}{8,16,32,64} on x86
在2023年11月1日十一月 上午9:08,Arnd Bergmann写道:
[...]
> My feeling is that converting to ioread/iowrite is generally a win
> for any driver that already needs to support both cases (e.g.
> serial-8250) since this can unify the two code paths.
>
> However, for drivers that only support inb()/outb() today, I don't
> see a real benefit in converting them from the traditional methods.
Unfortunately, there are tons of old system trying to mimic PC do
rely on those drivers :-(
I think the universal target is to remove provision of inb()/outb()
family on archs other than x86, and perhaps remove PCI_IOBASE
as well because we can manage io regions with ioremap afterwards.
Besides PnP system may need an overhaul to handle enablement of
ISA device, presumably the ability of receiving information from
OF and platform code can be helpful.
> Another question is whether we actually want to keep the ISA-only
> drivers around. Usually once you look closely, any particular
> ISA driver tends to be entirely unused already and can be removed,
> aside from a few known devices that are either soldered-down on
> motherboards or that have an LPC variant using the same ISA driver.
Well for MIPS Alpha PPC m68k I guess that's worth it. Those systems
tends to have random hardware pieces from PC, including ISA EISA slots.
Thanks.
>
> Arnd
--
- Jiaxun
Powered by blists - more mailing lists