[PATCH v3 35/38] video: handle HAS_IOPORT dependencies
Niklas Schnelle
schnelle at linux.ibm.com
Thu Mar 23 14:17:38 UTC 2023
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 at linux.ibm.com> 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 at kernel.org>
> > > Signed-off-by: Niklas Schnelle <schnelle at linux.ibm.com>
> >
> > 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
More information about the dri-devel
mailing list