On Tue, Feb 07, 2017 at 12:09:50PM +0100, Uwe Kleine-König wrote: > Now additionally I want to initialize some gpios but allow them to be > grabbed later. IMHO there are the following new cases: > > It should be possible to: > > a) change the value of a gpio initially configured as output > b) change the direction of a gpio initially configured as output > c) change the direction of a gpio initially configured as input > > IMHO the dts should describe which case should be applied to a given > gpio. Isn't it the job of the board firmware to ensure that the hardware is setup to a reasonably sane state for the board? You give an example of holding GPIOs low in Linux for "ESD reasons" later in this thread, but if you're only doing that in Linux, what if Linux isn't running yet, and the GPIO has been left floating by the board firmware? Fixing this in Linux is really too late. Floating GPIOs are also a source of higher current drain - a GPIO sitting mid-rail turns both transistors on for a MOS input, which gives a direct path across the power supply. The quicker that the GPIOs can be initialised, the less wasted power there is. So, that's another argument for board firmware doing the basic GPIO initialisation and not stuffing this into DT and having the kernel do it. We could then talk about floating GPIOs that activate higher power devices, and the arguments for doing GPIO initialisation as early as possible in board firmware continue to stack up. IMHO, initial configuration of GPIOs is the job of board firmware, not the kernel. I see no sane reason to push that into the kernel. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- 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
