Hi, sorry for the late reply. I'm currently on vacation and it is no fun to use SSH with a 1s latency while Entel Chile injects RST/ACK packets. I'll read the remaining related mails that have accumulated in my inbox when I'm back home.
On Mon, Oct 15, 2012 at 10:30:15PM +0200, Linus Walleij wrote: > Another patch that is circulating concerns edge triggers and similar, > and it appear that some parts of the GPIO sysfs is for example > redefining and exporting IRQchip properties like trigger edge > in sysfs, while the settings of the irqchip actually used by the driver > is not reflected in the other direction. So you can *set* these things > by writing in the GPIO sysfs, but never trust what you *read* from > there. And you can set what edges an IRQ will trigger on a certain > GPIO, and the way to handle the IRQs from usespace is to poll > on a value. This is not really documented but well ... Part of this sounds like you are not familiar with the GPIOlib sysfs IRQ stuff. The trigger edge set in sysfs is only used when userspace polls the GPIO via sysfs. Drivers that want to register a gpio IRQ should IMHO always explicitly request the edge/level to trigger on and they should request the gpio beforehand. This prevents the gpio from being exported to userspace. Only IRQ triggers accepted by the irq chip are settable in sysfs, so you can trust the value read from that file. > Sadly the main creator of this ABI is David Brownell who is > not able to respond nor maintain it from where he is now. But > we need to think hard about what we shall do with this particular > piece of legacy. Some of the stuff was added by Daniel > Glöckner so requesting advice from him. I'm only guilty of adding the IRQ sysfs interface. > Daniel: are you interested in helping us fixing the GPIOlib > sysfs ABI and kernel internals? I'm a bit afraid of it. Actually I don't know what you want to change to fix the existing sysfs ABI. Personally I'd like to see the following things changed: - /sys/gpio/.../direction does not correspond to hardware before first use of gpio_direction_* due to lack of gpio_get_direction. - Names given to gpios by the chip should just result in symlinks to the usual gpioX directories or (un)exporting of gpios should accept names. Best regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
