All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.