linux-kernel - RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 6 May 2022 14:03:15 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Geert Uytterhoeven' <geert@...ux-m68k.org>
CC:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Arnd Bergmann <arnd@...nel.org>, Rich Felker <dalias@...c.org>,
        "open list:IA64 (Itanium) PLATFORM" <linux-ia64@...r.kernel.org>,
        "open list:SUPERH" <linux-sh@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "open list:MIPS" <linux-mips@...r.kernel.org>,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        "open list:SPARC + UltraSPARC (sparc/sparc64)" 
        <sparclinux@...r.kernel.org>,
        "open list:RISC-V ARCHITECTURE" <linux-riscv@...ts.infradead.org>,
        Will Deacon <will@...nel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Helge Deller <deller@....de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Russell King <linux@...linux.org.uk>,
        Ingo Molnar <mingo@...hat.com>,
        linux-pci <linux-pci@...r.kernel.org>,
        Bjorn Helgaas <helgaas@...nel.org>,
        Matt Turner <mattst88@...il.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Arnd Bergmann <arnd@...db.de>,
        Niklas Schnelle <schnelle@...ux.ibm.com>,
        "open list:M68K ARCHITECTURE" <linux-m68k@...ts.linux-m68k.org>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "moderated list:ARM PORT" <linux-arm-kernel@...ts.infradead.org>,
        Richard Henderson <rth@...ddle.net>,
        Michal Simek <monstr@...str.eu>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "open list:PARISC ARCHITECTURE" <linux-parisc@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Palmer Dabbelt <palmer@...belt.com>,
        "open list:ALPHA PORT" <linux-alpha@...r.kernel.org>,
        Borislav Petkov <bp@...en8.de>,
        "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" 
        <linuxppc-dev@...ts.ozlabs.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: RE: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it
 as necessary

From: Geert Uytterhoeven
> Sent: 06 May 2022 14:09
...
> > The same is really true for other bus type - including ISA and EISA.
> > (Ignoring the horrid of probing ISI bus devices - hopefully they
> > are in the ACPI tables??_
> > If a driver is probed on a ISA bus there ought to be functions
> > equivalent to pci_ioremap() (for both memory and IO addresses)
> > that return tokens appropriate for the specific bus.
> >
> > That is all a different load of churn.
> 
> A loooong time ago,  it was suggested to add register accessor
> functions to struct device, so e.g. readl(dev, offset) would call
> into these accessors, which would implement the bus-specific behavior.
> No more worries about readl(), __raw_readl(), ioread32b(), or whatever
> quirk is needed, at the (small on nowadays' machines) expense of
> some indirection...

I was just thinking that the access functions might need a 'device'.
Although you also need the BAR (or equivalent).
So readl(dev, bar_token, offset) or readl(dev, bar_token + offset).
Clearly the 'dev' parameter could be compiled out for non-DEBUG
build on x86 - leaving the current(ish) object code.

You don't want an indirect call (this year), but maybe real
function call and a few tests won't make that much difference.
They might affect PCIe writes, but PCIe reads are so slow you
need to avoid them whenever possible.
I've not timed reads into something like an ethernet chip,
but into our fpga they are probably 1000 clocks+.

OTOH I wouldn't want any overhead on the PIO fifo reads
on one of our small ppc devices.
We push a lot of data though that fifo and anything extra
would kill performance.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)