All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Borislav Petkov <petkov@uni-muenster.de>,
	linux-kernel@vger.kernel.org, bbpetkov@yahoo.de
Subject: Re: [PATCH] 2.6.9-rc3 fix warnings in sound/drivers/opl3/opl3_lib.c
Date: Thu, 30 Sep 2004 18:07:10 +0200	[thread overview]
Message-ID: <s5hekkjpwpd.wl@alsa2.suse.de> (raw)
In-Reply-To: <20040930155228.GE23987@parcelfarce.linux.theplanet.co.uk>

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

  reply	other threads:[~2004-09-30 16:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-30 12:28 [PATCH] 2.6.9-rc3 fix warnings in sound/drivers/opl3/opl3_lib.c Borislav Petkov
2004-09-30 15:25 ` viro
2004-09-30 15:52   ` viro
2004-09-30 16:07     ` Takashi Iwai [this message]
2004-09-30 16:50       ` Takashi Iwai
2004-09-30 17:12         ` Takashi Iwai
2004-09-30 17:01       ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hekkjpwpd.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=bbpetkov@yahoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petkov@uni-muenster.de \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.