On Tue, Sep 22, 2015 at 10:54 PM, Chris Read <chrisrfq@xxxxxxxxx> wrote: > On Mon, Sep 21, 2015 at 4:55 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> On Wed, Sep 2, 2015 at 6:35 AM, Chris Read <chrisrfq@xxxxxxxxx> wrote: >>> There are some hardware aspects/parameters >>> of exporting that aren't controllable from userspace, such as whether or not >>> reversing the direction of a GPIO is safe. >> >> The original argument as to why kernel should handle hardware >> is to keep things safe and under control. >> >> I don't understand this argument really, should the kernel give you >> a gun but stop you from shooting yourself in the foot with it or >> what do you mean? Then the stance of kernel not to give out guns >> is better. > > From my embedded perspective a board designer wants to keep > hardware safe and under control too. He may want or need to expose > controls or status to userspace applications, though, and what he > wants to have exposed may vary from board to board. I just feel that > exposing them via the DT could be OK, whereas others do not. It is really not a matter of feeling. The DT's job is to describe what the hardware is and how it is connected together - not the way in which it may be used. In your case, the DT describes a given range of pins as not being used (typically, any unclaimed GPIO) and the sysfs kernel option allows these GPIOs to be exposed to user-space. It is then up to the priviledged userspace (via init scripts and/or udev rules) to export and configure these GPIOs in the way they are supposed to be by regular users. This basically covers what you wanted to do exclusively by DT, but with a stronger role separation. IIUC a good old init script could just do what you want, using chmod to restrict write access to a GPIO value or the ability to change direction. I also suspect the same could be achieved with udev (especially since this series has just been merged: http://www.spinics.net/lists/linux-gpio/msg07844.html , see the link for an example of a rule). Board differenciation can also be handled at boot time, with init doing different things depending on the board model. Again, similarly to what you would do with DT, but without the it being involved in describing the system semantics. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
