On Wed, 2023-03-15 at 12:19 +0200, Ville Syrjälä wrote: > On Wed, Mar 15, 2023 at 09:16:50AM +0100, Geert Uytterhoeven wrote: > > Hi Niklas, > > > > On Tue, Mar 14, 2023 at 1:13 PM Niklas Schnelle <schnelle@xxxxxxxxxxxxx> wrote: > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > those drivers using them and guard inline code in headers. > > > > > > Co-developed-by: Arnd Bergmann <arnd@xxxxxxxxxx> > > > Signed-off-by: Niklas Schnelle <schnelle@xxxxxxxxxxxxx> > > > > Thanks for your patch! > > > > > --- a/drivers/video/fbdev/Kconfig > > > +++ b/drivers/video/fbdev/Kconfig > > > > > @@ -1284,7 +1285,7 @@ config FB_ATY128_BACKLIGHT > > > > > > config FB_ATY > > > tristate "ATI Mach64 display support" if PCI || ATARI > > > - depends on FB && !SPARC32 > > > + depends on FB && HAS_IOPORT && !SPARC32 > > > > On Atari, this works without ATARI_ROM_ISA, hence it must not depend > > on HAS_IOPORT. > > The only call to inb() is inside a section protected by #ifdef > > CONFIG_PCI. So: > > That piece of code is a nop anyway. We immediately overwrite > clk_wr_offset with a hardcoded selection after the register reads. > So if you nuke that nop code then no IOPORT dependency required > at all. > I agree this "looks" like a nop but are we sure the inb() doesn't have side effects? (for reference drivers/video/fbdev/aty/aty/atyfb_base.c: atyfb_setup_generc() towards the end) It does feel a bit out of scope for this series but if it's really a nop nuking it surely is the cleaner solution. Thanks, Niklas
