Bug#715370: Acknowledgement (linux-image-3.9-1-486: CONFIG_GPIO_CS5535 has been set to 'y' when it should be 'M')
right. having enormous difficulty tracking this down, but there appears to be some kernel config dependencies of CONFIG_GPIO_CS5535 which are set to Y which are forcing CONFIG_GPIO_CS5535 to y. ... but that actually turns out not to be the main problem: the main problem is that although GPIO_CS5535 has been converted (since 3.2.0) to the standard GPIO format, CONFIG_GPIO_SYSFS isn't set, making it impossible to gain access to it! as this is for an AMD Geode LX (PC-Engines alix6f2), gaining access to the GPIO in order to pull relays, change the LED status and so on, is somewhat essential. could i therefore request that CONFIG_GPIO_SYSFS be set to Y so that GPIO - which is protected by having to explicitly take action in userspace in order to gain access to it anyway - is accessible? l. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715370: Acknowledgement (linux-image-3.9-1-486: CONFIG_GPIO_CS5535 has been set to 'y' when it should be 'M')
Yes, CONFIG_GPIO_CS5535 is forced to 'Y' because the OLPC XO-1 power management settings (CONFIG_OLPC_XO1_PM, CONFIG_OLPC_XO1_SCI, and a few other related options) are boolean. Making the PM code modular is the only way to fix this, but doing so would be racy due to the various hooks that are registered (and really, are required by the system). It's not impossible, simply difficult. The right answer would be to have a module that doesn't allow removal. There may be additional issues as well, I don't recall. As far as CONFIG_GPIO_SYSFS, I don't know why that's unset. I'm assuming it's the case because GPIOs aren't widely used on x86, and twiddling GPIO lines from userspace even less so? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
