Re: [PATCH 12/15] sound: add missing HAS_IOPORT and GENERIC_HARDIRQS dependencies

[Heiko Carstens <heiko.carstens@de.ibm.com>]

On Wed, Feb 06, 2013 at 06:26:02PM +0100, Takashi Iwai wrote:
> At Thu, 07 Feb 2013 02:13:19 +0100,
> Arnd Bergmann wrote:
> > On Wednesday 06 February 2013 18:05:14 Takashi Iwai wrote:
> > > At Wed,  6 Feb 2013 17:24:00 +0100,
> > > Heiko Carstens wrote:
> > > #if defined(CONFIG_HAS_IOPORT) && defined(CONFIG_GENERIC_IOMAP)
> > > extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
> > > extern void ioport_unmap(void __iomem *p);
> > > #else
> > > static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> > > {
> > > 	return (void __iomem *) port;
> > > }
> > > 
> > > static inline void ioport_unmap(void __iomem *p)
> > > {
> > > }
> > > #endif /* CONFIG_HAS_IOPORT */
> > 
> > No, it is intentional that the CONFIG_HAS_IOPORT symbol refers to
> > the fact that you can use the ioport_map function, in order to
> > disallow building drivers that depend on this function when it
> > is unavailable. I actually want to change this, but in the opposite
> > way of what you are proposing:
> > 
> > I think CONFIG_HAS_IOPORT should refer to the fact that the
> > inb/outb family of functions are usuable and be unset when
> > they are not provided, and I would introduce a new
> > CONFIG_HAS_IOPORT_MAP symbol for those (few) platforms that
> > have a working inb/outb but no ioport_map.
> 
> Yet another Kconfig, but sounds reasonable :)

Right... I just wanted to make s390 compile with the Kconfig methods we use
since nearly a decade and not change the world ;)

> > > > sound/soc/codecs/wm8903.c: In function ‘wm8903_set_pdata_irq_trigger’:
> > > > sound/soc/codecs/wm8903.c:1954:9: error: implicit declaration of function ‘irq_get_irq_data’
> > > 
> > > Ditto, how about defining
> > > 
> > > #ifndef CONFIG_GENERIC_HARDIRQS
> > > #define irq_get_irq_data(x)  NULL
> > > #endif
> > > 
> > > somewhere appropriately?
> > > 
> > 
> > Why not just make CONFIG_GENERIC_HARDIRQS mandatory for all
> > platforms. It is use almost everywhere now.
> 
> I wonder it, too...

I haven't looked into it, but I doubt if that is possible without large
effort, if at all. s390 doesn't have any irq chips, nor something like
edge or level triggered irqs.
Instead we have floating interrupts. Does that fit into the concept of
GENERIC_HARDIRQS at all?
If so, we can give it a try, sure. But that won't happen any time soon.

Or are you simply proposing we should have both, our own irq handling plus
GENERIC_HARDIRQS with dummy functions?