On Wed, May 1, 2013 at 10:56 AM, Luke Kenneth Casson Leighton <l...@lkcl.net> wrote:
>> It *is* still enabled, but it's built-in on the 486 flavour because >> OLPC_XO1_SCI selects it. > > thanks ben... investigating further: > > # PCI GPIO expanders: > # > CONFIG_GPIO_CS5535=y > # CONFIG_GPIO_LANGWELL is not set > CONFIG_GPIO_PCH=m > CONFIG_GPIO_ML_IOH=m > # CONFIG_GPIO_RDC321X is not set > > bizarre. so why the heck is.... i think it's changed quite a lot from > 2.6.32, no major-minor numbers any more, to a generic GPIO interface > which i've not yet understood/tracked down. > > so yes, more work to do but at least a route to investigate. thanks ben. right. the issue is this: CONFIG_GPIO_CS5535 appears to hook into the standard linux kernel gpio subsystem (gpiolib), which is *not* exposed to userspace unless you set CONFIG_EXPERIMENTAL, CONFIG_SYSFS and CONFIG_SYSFS_GPIO. contrast this with 2.6.32 where CONFIG_CS5535_GPIO exposed GPIO directly into userspace as a major/minor device and you see what the issue is. # # Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks. # CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y CONFIG_GPIOLIB=y # CONFIG_DEBUG_GPIO is not set # CONFIG_GPIO_SYSFS is not set right. that's the problem - CONFIG_GPIO_SYSFS isn't set. as this alix6f2 board is being used for pulling relays on powered equipment which is mission-critical, using the LEDs for status information, resetting the internal MiniPCIe modem if it goes belly-up and so on, this is a major functional step backwards, and we may have to return to the 2.6.32 kernel.... with *no* watchdog support. also of note is that i had to put this into modprobe.d for 2.6.32: cs5535_gpio options cs5535_gpio mask=0xffffffff this allows us to use GPIOs which were allocated to LEDs, buzzer and so on on *this* device, whereas other devices may use those GPIOs for functions that may not be appropriate for general use. in resolving this it would be appreciated to bear in mind that we *need* that mask value. also, if the GPIO_CS5535 module is built-in and GPIO_SYSFS is enabled as well, then there's the possibility that people will randomly poke around ... but only the once :) if these are done as modules then even if GPIO_SYSFS is built-in and populates /sys/class/gpio it will at least be empty until modprobe gpio_cs5535 is called (and in our case with the mask parameter), and that will only really be done by people who know what they're doing. now to work out how to re-open this bug :) l. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
