From: "Joachim Förster" <mls.JOFT@gmx.de>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel <alsa-devel@alsa-project.org>,
Lorenz Kolb <lorenz.kolb@lkmail.de>,
"linuxppc-embedded@ozlabs.org" <linuxppc-embedded@ozlabs.org>
Subject: Re: [alsa-devel] [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver
Date: Fri, 10 Aug 2007 13:50:40 +0200 [thread overview]
Message-ID: <1186746640.8965.21.camel@localhost> (raw)
In-Reply-To: <s5hsl6sws0s.wl%tiwai@suse.de>
Hi Takashi,
again some question came up (while correcting all the other issues):
On Thu, 2007-08-09 at 19:13 +0200, Takashi Iwai wrote:
> > +static int __init
> > +snd_ml403_ac97cr_create(struct snd_card *card, struct platform_device *pfdev,
> > + struct snd_ml403_ac97cr **rml403_ac97cr)
>
> It's no longer __init as long as you use platform_device.
> It should be __devinit instead.
Ok, I changed that (for create(), pcm(), mixer(), etc.). Do I have to
change it for the module_init and module_exit functions, too? I guess,
they are not in the "scope" of platform device, right? So, they will
keep __init / __exit ?
> > --- /dev/null
> > +++ b/sound/ppc/pcm-indirect2.h
> (snip)
> > +#ifdef SND_PCM_INDIRECT2_STAT
> > +static inline void snd_pcm_indirect2_stat(struct snd_pcm_substream *substream,
> > + struct snd_pcm_indirect2 *rec)
>
> Remove inline from the functions in this file. They are too lengthy.
>
> sound/pcm-indirect.h contain inline functions becuase they are
> relatively small, and I didn't want to add them in the core module
> unconditionally.
I looked at my functions again. And I think we could still go with
inline for the *_interrupt() and *_pointer() functions since they have
just a few lines.
With both *_transfer() functions - I don't know. In fact they shouldn't
be much longer than yours in pcm-indirect.h . They seem long, because
there are lot of comments and the #ifdef SND_PCM_INDIRECT2_STAT stuff,
which is/was a debugging feature, which _won't_ be compiled in without
CONFIG_SND_DEBUG.
[I removed inline from the _stat() and _min_periods() function - that's
true, they are too long.]
The other thing I thought about, is: Is it ok to have non-inline
functions in a header file? Don't we need a .c file + .h ? (Are there
any CodingStyle rules about that?)
Joachim
next prev parent reply other threads:[~2007-08-10 11:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 10:36 [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver Joachim Förster
2007-08-09 17:13 ` [alsa-devel] " Takashi Iwai
2007-08-09 19:44 ` Joachim Förster
2007-08-09 22:27 ` Takashi Iwai
2007-08-10 11:50 ` Joachim Förster [this message]
2007-08-10 12:07 ` Takashi Iwai
2007-08-11 16:23 ` [PATCHv2 1/2] Xilinx " Joachim Förster
2007-08-15 18:45 ` [PATCH] [ML403-AC97CR] Fix (device/driver) name registered with platform bus Joachim Foerster
2007-08-11 16:24 ` [PATCHv2 2/2] [VIRTEX] Register AC97 Controller Reference with the " Joachim Förster
2007-08-09 17:49 ` [PATCH 1/2] Xlinx ML403 AC97 Controller Reference device driver Grant Likely
2007-08-09 20:01 ` Joachim Förster
2007-08-09 20:07 ` Grant Likely
2007-08-09 22:30 ` Takashi Iwai
2007-08-09 18:17 ` Stephen Neuendorffer
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=1186746640.8965.21.camel@localhost \
--to=mls.joft@gmx.de \
--cc=alsa-devel@alsa-project.org \
--cc=linuxppc-embedded@ozlabs.org \
--cc=lorenz.kolb@lkmail.de \
--cc=tiwai@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).