On 1/25/12 4:16 PM, Andrew Morton wrote: > On Wed, 25 Jan 2012 16:04:16 -0700 > Philip Prindeville <philipp@xxxxxxxxxxxxxxxxxxxxx> wrote: > >>> This is odd. There are no references to this from outside this file >>> and it's hard to see how a wireless driver could use this - any such >>> driver would have to load this module on *all* machines (even non-x86) >>> simply to resolve this symbol. >> >> It's for an out-of-tree driver that's only ever built for Alix hardware. > > This should have been changelogged! And a code comment would be good, > too - if it confused me now, it will confused others later. And such a > code comment will help prevent others from coming in and "cleaning up" > the code later on. Ok. There currently wasn't a ChangeLog in arch/x86/platform/geode so I can add one. > Out-of-tree drivers are unpopular. Where is this driver, what is its > license and what are the prospects of making it in-tree? It's complicated. Generic GPIO supports polled-keys for input, and LEDs for outputs as you know. There's no generic output mechanism for (say) an RFKILL line on the bus. If/when this materialized, I'll modify the alix driver to register that device in addition to the soft-reset button and the output LEDs (for the alix.6 device only). There's also a certain amount of churn going on right now in coreboot about supporting the 'alix.6' as a variant of the 'alix.2' (the coreboot build machinery doesn't support this, and we need to hack kconfig to make this happen, i.e. have kconfig be queryable from shell scripts like coreboot's abuild)... so for now most people burn an alix.2 coreboot image onto their alix.6. So there's a chain of dependencies that need to be resolved to get the ideal solution in place... but not wanting the perfect be the enemy of the good, I wanted to get what's available today out there with the caveat that something better is in the pipeline. > I don't personally have problems with helping out-of-tree drivers but > making it EXPORT_SYMBOL_GPL() would set minds at rest. Ok. I'll make that patch and resubmit... >> Since it's only 4 bytes and one exported symbol, I figured it was acceptable... >> >> I can remove it, resubmit, and use a patch locally in my tree if that's preferable > > What we should do depends on the above issues... -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
