FWIW, it's not a great idea to throw all of the i2c drivers into a kernel what will ever be booted, because of the i2c address assignment situation.
> On Nov 12, 2018, at 2:15 PM, Brad Spencer <b...@anduin.eldar.org> wrote: > > > co...@sdf.org writes: > >> This is an automatically generated list with some hand touchups, feel >> free to do whatever with it. I only generated the output. >> > > Random ramblings below... > > [snip] > >> am2315temp > > The am2315 will, in theory, work on any reasonable i2c bus, but has only > been tested on a RPIish sort of thing. > > [snip] > >> gpioirq >> gpiopps > > The gpioirq and gpiopps drivers should function with any system with > gpio(4) support. But again, only tested on the RPI. > > [snip] > >> si70xxtemp > > The si70xx will also, in theory, work on any fairly well behaved i2c > bus. In particular, you need to be able a zero length read cycle... or > we need to implement the ability to perform clock stretching on the i2c > bus. Only tested and messed with on a RPI. > > > Maybe support will appear some day for one of the USB to i2c chips that > exist in the world... [hint: there is one on Adafruit that is FTDI > based and fully documented], and it will be more obvious how the above > would be useful on more than the RPI. > > I don't know where it leaves these with respect to a ALL sort of config > file. Nothing should really be harmed by including any of them in such > a file. > > > > > -- > Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org -- thorpej
