[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <e15befc1-2b38-4824-8112-31f6cfe3dd41@app.fastmail.com>
Date: Tue, 25 Apr 2023 22:13:15 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc: Linux-Arch <linux-arch@...r.kernel.org>,
linux-kernel@...r.kernel.org,
"Niklas Schnelle" <schnelle@...ux.ibm.com>,
"Palmer Dabbelt" <palmer@...belt.com>,
"Thomas Huth" <thuth@...hat.com>
Subject: Re: [GIT PULL] asm-generic updates for 6.4
On Tue, Apr 25, 2023, at 20:27, Linus Torvalds wrote:
> On Mon, Apr 24, 2023 at 2:16 PM Arnd Bergmann <arnd@...db.de> wrote:
>>
>> These are various cleanups, fixing a number of uapi header files to no
>> longer reference CONFIG_* symbols, and one patch that introduces the
>> new CONFIG_HAS_IOPORT symbol for architectures that provide working
>> inb()/outb() macros
>
> Strange. I was sure we had this, but you're right, we only had HAS_IOMEM.
>
> And then we had that HAS_IOPORT_MAP which was kind of related.
>
> Anyway, the new HAS_IOPORT looks like something we should always had
> had, I have no complaints, I was just expressing surprise that it
> wasn't already there ;)
Yes, we've discussed this over a long time, and thankfully Niklas has
a nice series that we should be able to complete soon. There was an
older series he did a few years ago that you Nak'ed because it silently
turned outb/inb operations into nops on architectures without PIO
capabilities. The coming series is what we did in response to that,
and it's clearly the right solution, it's just tedious to work out
the exact details for how to deal with individual drivers that
can work both with and without PIO support, e.g. i8250 uarts.
Arnd
Powered by blists - more mailing lists