Messages in this thread | | | Date | Mon, 16 Dec 2013 14:31:53 +0100 | Subject | Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver | From | Linus Walleij <> |
| |
On Mon, Dec 16, 2013 at 1:15 PM, Sebastian Reichel <sre@debian.org> wrote: > On Mon, Dec 16, 2013 at 10:48:06AM +0100, Linus Walleij wrote:
>> I.e. it doesn't look device-specific at all, just like some >> generic glue code that could be useful to many such >> scenarios. > > I like the idea. > > Probably the remaining gpio exporting code can be converted into > some generic gpio-sysfs-export driver as well.
I am very reluctant in letting device trees specify exports of GPIOs to userspace, not so much because it's Linux-specific but for the fact that people are doing things in userspace that should not be done in userspace.
Last time it was proposed I asked to the specific usecase, exactly why userspace needed this handle on a physical GPIO line, and why it can't use another userspace interface (example: leds, keys etc.)
> What do you think about the following? > > /* > * driver, which provides generic reset notifications > */ > cmt_reset: reset-notifier { > compatible = "linux,reset-notification"; > > interrupts = <gpio>; > };
Looks good to me.
> /* > * driver, which exports the specified gpios in sysfs with the > * supplied names. The device will be named according to the > * label > */ > cmt_gpios: gpio-sysfs-export { > compatible = "linux,gpio-sysfs-export"; > label = "nokia-cmt"; > > gpios = <A>, <B>, ...; > gpio-names = "A", "B", ...; > };
Please follow the discussion on this topic: http://marc.info/?l=linux-gpio&m=138201170431416&w=2
>> Why are you using a tasklet rather than a work >> for this? > > No particular reason. I just took this over from Nokia's code.
Can you try to use a work instead?
Yours, Linus Walleij
| |