From: Andrew Morton <akpm@osdl.org>
To: jayakumar.alsa@gmail.com
Cc: perex@suse.cz, mj@ucw.cz, alsa-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.13.1 1/1] CS5535 AUDIO ALSA driver
Date: Tue, 20 Sep 2005 17:23:09 -0700 [thread overview]
Message-ID: <20050920172309.626db866.akpm@osdl.org> (raw)
In-Reply-To: <47f5dce305092017031a2ba375@mail.gmail.com>
jayakumar alsa <jayakumar.alsa@gmail.com> wrote:
>
> > > +
> > > +static unsigned short snd_cs5535audio_codec_read(cs5535audio_t *cs5535au,
> >
> > typedefs are unpopular in-kernel. We generally don't get too fussed if a
> > driver maintainer really wants them there. The main objection is that we
> > now have two names for the same thing. Plus they cannot be used when
> > forward-declaring a structure.
>
> I just used those typedefs in order to match the style in all the
> other alsa drivers. For example:
>
> % egrep typedef $lintree/sound/pci/*.c
> als4000.c:typedef struct {
> atiixp.c:typedef struct snd_atiixp atiixp_t;
> atiixp.c:typedef struct snd_atiixp_dma atiixp_dma_t;
> atiixp.c:typedef struct snd_atiixp_dma_ops atiixp_dma_ops_t;
> atiixp.c:typedef struct atiixp_dma_desc {
> azt3328.c:typedef struct _snd_azf3328 azf3328_t;
> azt3328.c:typedef struct azf3328_mixer_reg {
> bt87x.c:typedef struct snd_bt87x bt87x_t;
> cmipci.c:typedef struct snd_stru_cmipci cmipci_t;
> <snip>
>
> I'm not sure what to do. I'd be happy to take them out. But I woudn't
> mind leaving them in if that's what alsa convention is.
I'd be inclined to stick with the alsa style. That's just an fyi if you
plan on working in other places.
> > We have kzalloc() now.
>
> Yes, Takashi pointed that out too. But I did the patch against 13.1
> which doesn't have kzalloc. I guess I'll redo the patch against -mm
> and switch to kzalloc.
2.6.14-rc2 has kzalloc(). Generally, patches should only be based on -mm
if there's other stuff in -mm which they depend upon.
> >
> > > + addr = (u32)substream->runtime->dma_addr;
> >
> > Nope, _snd_pcm_runtime.addr has type dma_addr_t, which is an opaque type,
> > 64-bit on some platforms. I expect this driver will blow up on those
> > platforms.
>
> The 5535 hw's dma descriptor is only 32 bit capable. I guess I should
> look into informing the dma alloc that the buffers need to be in the
> lower 32. Would it be okay to drop the upper then?
An IOMMU permits 64-bit platforms to use 32-bit PCI devices.
> >From a practical standpoint, the 5535 is only used in x86-32
> embeddeded systems so high mem probably won't occur. But you are
> right, I'll go and try make it right.
Yup, try to honour the provided type system as much as poss.
> > +#define cs_writel(reg, val) outl(val, (int) cs5535au->port + reg)
> > +#define cs_writeb(reg, val) outb(val, (int) cs5535au->port + reg)
> > +#define cs_readl(reg) inl((unsigned short) (cs5535au->port + reg))
> > +#define cs_readw(reg) inw((unsigned short) (cs5535au->port + reg))
> > +#define cs_readb(reg) inb((unsigned short) (cs5535au->port + reg))
> >
> > erk. subsystem-wide helper macros which reference local variables?
>
> Ok. I'll change that.
well, again, if that's alsa-style then you might choose to retain it. But
it'd be an unpopular approach in most other kernel code.
next prev parent reply other threads:[~2005-09-21 0:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 6:39 [PATCH 2.6.13.1 1/1] CS5535 AUDIO ALSA driver jayakumar.alsa
2005-09-20 22:28 ` Andrew Morton
2005-09-21 0:03 ` jayakumar alsa
2005-09-21 0:23 ` Andrew Morton [this message]
2005-09-21 8:31 ` Christoph Hellwig
2005-09-29 13:21 ` [Alsa-devel] " Takashi Iwai
2005-12-06 17:42 ` Christoph Hellwig
2005-12-06 18:41 ` Takashi Iwai
2005-09-29 13:04 ` Takashi Iwai
2005-09-21 7:08 ` jayakumar alsa
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=20050920172309.626db866.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=alsa-devel@lists.sourceforge.net \
--cc=jayakumar.alsa@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mj@ucw.cz \
--cc=perex@suse.cz \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox