Re: [alsa-devel] linux-next: Tree for Oct 12 (sound/soc/codecs/wm1250-ev1)
On 10/11/2011 11:54 PM, Stephen Rothwell wrote:
Hi all,
The linux-next tree is now available from git://github.com/sfrothwell/linux-next.git as a temporary measure while the kernel.org servers are unavailable.
It may also turn up on git.kernel.org (depending on the mirroring). The patch is still absent, however.
When no GPIO kconfig options are enabled: (not GPIOLIB, not GENERIC_GPIO):
sound/soc/codecs/wm1250-ev1.c:32:14: error: array type has incomplete element type sound/soc/codecs/wm1250-ev1.c:126:18: warning: type defaults to 'int' in type name sound/soc/codecs/wm1250-ev1.c:126:18: warning: type defaults to 'int' in type name sound/soc/codecs/wm1250-ev1.c:126:18: error: negative width in bit-field '<anonymous>' sound/soc/codecs/wm1250-ev1.c:134:42: warning: type defaults to 'int' in type name sound/soc/codecs/wm1250-ev1.c:134:42: warning: type defaults to 'int' in type name sound/soc/codecs/wm1250-ev1.c:134:42: error: negative width in bit-field '<anonymous>' sound/soc/codecs/wm1250-ev1.c:155:34: warning: type defaults to 'int' in type name sound/soc/codecs/wm1250-ev1.c:155:34: warning: type defaults to 'int' in type name sound/soc/codecs/wm1250-ev1.c:155:34: error: negative width in bit-field '<anonymous>'
This was on an i386 build, but that shouldn't matter.
On Wed, Oct 12, 2011 at 05:46:01PM -0700, Randy Dunlap wrote:
When no GPIO kconfig options are enabled: (not GPIOLIB, not GENERIC_GPIO):
As ever the consumer side GPIO API is supposed to stub itself out when not in use.
On 10/13/2011 03:24 AM, Mark Brown wrote:
On Wed, Oct 12, 2011 at 05:46:01PM -0700, Randy Dunlap wrote:
When no GPIO kconfig options are enabled: (not GPIOLIB, not GENERIC_GPIO):
As ever the consumer side GPIO API is supposed to stub itself out when not in use.
You are listed as MODULE_AUTHOR(). Can we expect a fix?
I don't see how stubs help with source lines like: struct wm1250_priv { struct gpio gpios[WM1250_EV1_NUM_GPIOS]; };
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).
participants (2)
-
Mark Brown
-
Randy Dunlap