Sorry, I joined the mailing list after this thread was posted, so don't have the original list of recipients.
Regarding making this an architecture driver: yes, I prefer this approach. I'd also like to see support for the S/W button added in. The button could be used to either force a soft reboot, or else be used as an RF-KILL button. >> Is there any other alix-specific initialization code in the >> kernel? If so, you should consider relocating the device registration >> with the rest of the alix setup code. > > Agreed. I confess that I don't understand the linux driver structure > enough to shift the code further though Yeah, I was going to write a leds-geos.c driver, and ran into the same problem. I couldn't get the leds stuff to take as a "platform" driver. This could be better documented, I think. > Maybe an arch/x86/platform/geode as a > place to collect platform drivers for the various geode-based machines > out there (alix, soekris, etc)? Though honestly, I'm not that > interested in doing the work to migrate stuff over to there. I might be convinced to help out with this. >> I think given that we already have a similar driver in the leds area >> which does platform alike setup, this gives some justification for >> doing the same with the Alix leds? Additionally if we ever find we >> need Alix specific setup code then the code is ready to be used as is >> by the platform code? As above, the drivers should support all of the user-selectable GPIO functionality, i.e. LEDs and switches. > I was unsure if the trend was to have one module which initialised all > Alix platform stuff (whatever it needs), or to split by function? > Looking at other platform modules they seem to be somewhat fine grained > so I went with a specific "ALIX Led Module" approach? Other platforms tend to dump all of the initialization into a single container. -Philip _______________________________________________ Linux-geode mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-geode
