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

Borislav Petkov
2004-09-30T17:23:12Z

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.