From: "Jiaxun Yang" <jiaxun.yang@flygoat.com>
To: "Arnd Bergmann" <arnd@arndb.de>, Linux-Arch <linux-arch@vger.kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
"Baoquan He" <bhe@redhat.com>
Subject: Re: Overhead of io{read,write}{8,16,32,64} on x86
Date: Wed, 01 Nov 2023 11:55:29 +0000 [thread overview]
Message-ID: <04275b02-0f04-4aed-9e05-7346daf7f102@app.fastmail.com> (raw)
In-Reply-To: <f548e9e7-e499-4e26-87d9-c45ce69236a1@app.fastmail.com>
在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
prev parent reply other threads:[~2023-11-01 11:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-31 21:41 Overhead of io{read,write}{8,16,32,64} on x86 Jiaxun Yang
2023-11-01 9:08 ` Arnd Bergmann
2023-11-01 10:28 ` Peter Zijlstra
2023-11-01 11:55 ` Jiaxun Yang [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=04275b02-0f04-4aed-9e05-7346daf7f102@app.fastmail.com \
--to=jiaxun.yang@flygoat.com \
--cc=arnd@arndb.de \
--cc=bhe@redhat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/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.