-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/9/15 4:04 AM, Jean Delvare wrote:
Hi Jeff,
Le Sunday 08 March 2015 à 19:07 -0400, Jeff Mahoney a écrit :
On 3/8/15 5:01 AM, Jean Delvare wrote:
I've just sent a patch adding the missing MODULE_DEVICE_TABLE to the bh1780gli driver: http://marc.info/?l=linux-kernel&m=142580461109630&w=2
Note that DT/OF-based systems are not affected, and this does not prevent the driver from being used on the other systems either, all that is missing is module auto-loading. But I couldn't find any piece of kernel code instantiating this device anyway, so the only case where it would make a difference is if someone instantiates the device manually from user-space through sysfs.
Huh. Ok. Shows how much I know about how the i2c subsystem works. Is it the case that there are probably a bunch of drivers like this that would never be loaded on e.g. x86 systems?
It's very hard to say. Some I2C device drivers (most notably in drivers/hwmon) implement a detect callback which allows the driver to probe for devices and instantiate these by itself. Such drivers can be used on any system even if you don't see any piece of kernel code instantiating the device explicitly.
Also note that instantiating i2c devices through sysfs is a totally legitimate way to operate. While use cases include device emulation and driver development, it is also possible to use this mechanism to declare devices on real systems. This could even replace the in-kernel self-probing at some point in time.
So I think we have 3 options when it comes to deciding which I2C device drivers should be enabled in our kernels:
1* Enable every new driver everywhere (except specialized kernel flavors), just in case. Very easy, but a waste of build time, update time and disk space.
2* Disable every new driver everywhere by default and wait for users to ask for the drivers they actually need. We'd get cleaner and smaller kernels, but this probably requires more human interactions than we can afford, and user experience would degrade.
3* Try to guess which drivers may be needed on each platform based on the device nature. For example we know that x86 systems typically don't use I2C RTC chips. The problem is that borders are getting blurred between architectures with regards to target systems and intended uses, so I'm afraid that in the end we can't exclude much and we're basically back to option 1.
None of these options is really pleasant. I think we are using option 3 at the moment, and it is not worse than the other 2 so I'm fine with that.
Ok, I'll leave it alone then. Thanks, - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJU/aHIAAoJEB57S2MheeWyfzMP/A5lNs/tb1Ze/nsZs6q98+70 hk8cK5SnBMbcGzol8R/u1jzxEmUW596lOFbTwySS1osie5JZD/O9IdMacA2OjFV5 ymbrO850b+43sZWQeOVfWIM2jap2sS6TM9ATIfHbiF6MF8+VOWD1cmhY4gW56FJe rkgUQ6bghqhU356ic21IOWU6OAWuUnFN/OBwcs0fViT7/0X3anslEOO1pmcCED3j gwjyyHrGp8jaXSfdhPgm5NFAZLm+dNRhhUmpyvRmY3ZOjNdzhQZjEZpBdAalA00z 5wrORCQx2IQbu64idZxo0kXk5SVOZw/+687vc6TaCUcMMpg70cnzI2iRgzs5hcrN iYv2fP1aDOtvlD3oFOIzdSrZ/8Paf+Zk7rKP1iCeIo8KQrVbQJz9FhXs03A9Fk6e aIlfOo1ojZtW6ommrUh3yU1ll5mJEJuODxjq4aFqQkAALlc5A4MW4pMeak4eZRrd iunY0RIAgsY+kJ6BXJFA00l2Rf9iEbjTRy41JOKsjiD88GBtGNiIBVn2xi+8TKal uPhm9OxEmRAC8qsOZQ/o/qqDuqX2qp+UR0HqQUY6URFjJ5m6GAAgGcvmaGVbTlZx mZohDLt4w/HqdQSOzloGnKk2IKoGgGfqLLbwvxdeIvgJzY186a5vEjzAI3RlRpPy C0TOJmNvRql79z0t54w8 =MWpA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org