Re: [PATCH] 2.6.9-rc3 fix warnings in sound/drivers/opl3/opl3_lib.c

[Borislav Petkov <petkov@uni-muenster.de>]

On Thursday 30 September 2004 18:07, Takashi Iwai wrote:
> At Thu, 30 Sep 2004 16:52:28 +0100,
>
> viro@parcelfarce.linux.theplanet.co.uk wrote:
> > On Thu, Sep 30, 2004 at 04:25:44PM +0100, 
viro@parcelfarce.linux.theplanet.co.uk wrote:
> > > On Thu, Sep 30, 2004 at 02:28:53PM +0200, Borislav Petkov wrote:
> > > > Hi there,
> > > >    I get these warnings while compiling 2.6.9-rc3:
> > > >    sound/drivers/opl3/opl3_lib.c: In function
> > > > `snd_opl3_cs4281_command': sound/drivers/opl3/opl3_lib.c:101:
> > > > warning: passing arg 2 of `writel'  makes pointer from integer
> > > > without a cast sound/drivers/opl3/opl3_lib.c:104: warning: passing
> > > > arg 2 of `writel'  makes pointer from integer without a cast
> > > >
> > > >    Hope this fix is correct.
> > >
> > > It looks very odd.  At the very least we don't want to overload the
> > > fields in question (->r_port and ->l_port) that way.
> >
> > *Yuck*
> >
> > ALSA code, as pretty as ever.  No, that's not a fix; it's only shutting
> > the rightfully complaining compiler up.
> >
> > What happens there is a dirty kludge created for the benefit of a single
> > driver (sound/pci/cs4281.c).  Said driver has a bunch of registers
> > memory-mapped, while its relatives use port IO instead.  Driver does
> > (correctly) ioremap(); then it overloads the arguments of
> > snd_opl3_create() normally used for port numbers and shoves *address
> > obtained from ioremap and divided by 4* in them.
>
> This ugly shift was already removed in the current version
> in linux-sound bk.  The l_port and r_port point the iomem pointers now
> on cs4281 like others.  I don't know why the author of cs4281
> implemented in such a way.
>
> BTW, all __iomem fixes are already there, too.
>
> > Sigh...  At the very least that kind of abuse should stop.  FWIW, I would
> > suggest having cs4281.c set the ->command() directly and killing that
> > crap with ->l_port/->r_port overloading.
>
> Yes, it'd be definitely better.
> Will work on it.
>
>
> Takashi

Ups,
tip of the iceberg, :) I actually thought that this would be too easy to be 
true.

Regards,
Boris.