[alsa-devel] linux-next: Tree for Oct 12 (sound/soc/codecs/wm1250-ev1)

[Mark Brown]

On Thu, Oct 13, 2011 at 11:28:49AM -0700, Randy Dunlap wrote:

> You are listed as MODULE_AUTHOR().  Can we expect a fix?

I dunno; like I say I don't see an issue in the driver here (the driver
usage of the GPIOs is optional), the GPIO build options are pretty
fiddly and I just wrote the mail below.

> I don't see how stubs help with source lines like:
> struct wm1250_priv {
> 	struct gpio gpios[WM1250_EV1_NUM_GPIOS];
> };

So, clearly there's an issue with the API not stubbing itself out
terribly well here; the obvious solution would appear to be to have a
definition of the struct to go along with the stubs.  I guess you see
some sort of problem with this, though?  It does work well enough for
other similar APIs like regulator_bulk_*() so I'd expect it to work here.

To be honest though I'm more concerned that this is being reported as an
issue in a specific driver than I am about the actual issue (which one
does have to try pretty hard to see, I'd be astonished if someone saw it
outside of deliberate testing).  As a result of the number of randconfig
type tests you do I'd guess you're aware of the APIs like GPIO which are
expected to stub themselves out when disabled.  As with the usage in
this driver there's a huge proportion of users which can optionally use
the API but don't actually need it and which therefore shouldn't have
build time dependencies, and clearly scattering ifdefs throughout the
code isn't great either.  These things do fix the *configs but they
reduce the coverage we get with our automated testing and they make the
code harder to work with.

The main reason I'm pushing back in this way is that as we start to get
more and more embedded hardware in subsystems maintained by people from
a PC background it becomes more and more important that people like you
who do this who do a lot of this kernel wide testing are directing these
issues appropriately by checking to see if what's going wrong is a
result of the driver or if it's a result of one of the service APIs like
GPIO or regulator (and hopefully soon clk) not being transparent enough.

Subsystem maintainers who usually work on PCs likely won't be aware of
what's going on with this sort of stuff except in so far as they get
reports of *config issues since PCs don't generally have to deal with
the haphazard board dependant setup that is so common in the embedded
space and random driver authors aren't going to be reliably familiar
with either that or build coverage type things either as the
configurations that break are generally not too realistic anyway.

I don't mean to get at you personally here - while you do do a lot of
good work here you're not the only person who does this sort of testing
and hence reports issues in this manner, and obviously there's a lot of
maintainers too.  I think it's mostly an education thing but I'm not
sure what the best way to go about spreading the word is, if nothing
else I don't know how to reach all the build coverage people (who I
think are key here).