[alsa-devel] [PATCH] ALSA: get rid of CONFIG_SND_VERBOSE_PRINTK

[Alan Stern]

On Fri, 7 Jun 2013, Takashi Iwai wrote:

> > > I don't expect that to happen any time soon.  Still, I think it makes
> > > more sense to concentrate on converting the messages below sound/usb
> > > rather than fiddling around with the existing API, which is inadequate
> > > anyway since it doesn't include the device.
> > 
> > I agree with that.
> > 
> > It'd be pretty easy to take that large patch that did
> > snd_printk(fmt, ...) -> snd_dbg(1, fmt, ...) and
> > convert it to snd_card_dbg(card *, fmt, ...)
> > whenever a struct snd_card * was available.
> > 
> > snd_card_dbg() would be either a macro or a function
> > to deference the snd_card * dev and maybe emit
> > "struct snd_card.shortname" with it too.
> > 
> > Want to start with that?
> 
> As discussed earlier, the snd_card instance isn't always appropriate
> for retrieving the device pointer.  It might help some driver codes,
> but not always.
> 
> In the case of sound/usb/*, most of codes rather handle directly the
> USB device pointer (mostly struct usb_interface), thus it's more
> natural to use it directly, IMO.

Agreed -- the lower-level driver should use the underlying device for
their messages.  The natural device for the snd_usb_audio driver to
report is the USB interface.  This would be the audio control interface
in many cases, or it could be the interface that contains the streaming
endpoints, or the interface containing the mixer, or the MIDI
interface...

The relevant data structures don't all store a pointer to the
interface, so I will have to add one.  That's another example of why
the conversion can't simply be done mindlessly.

For log messages in the sound core, it does make sense to use
snd_card->dev, or (preferably) snd_card->card_dev when it is available.  
As Takashi mentioned, the lower drivers often do not set snd_card->dev
as quickly as they should, i.e., they don't call snd_card_set_dev()  
right after creating the snd_card.  The best way to solve this is
probably to add a new routine, a version of snd_card_create() that
accepts the device pointer as an additional argument.

(Or maybe just change snd_card_create() and all its callers in one big 
patch.  It would be a fair amount of work, but doable.)

Alan Stern