linux-kernel - Re: [RFC Patch] gpio: add GPIO hogging mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <3D00ADB3-00B3-40A8-8263-444BCADDAC33@gmail.com>
Date:	Wed, 29 Oct 2014 10:53:44 +0200
From:	Pantelis Antoniou <pantelis.antoniou@...il.com>
To:	Benoit Parrot <bparrot@...com>
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	linux-gpio@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	devicetree@...r.kernel.org
Subject: Re: [RFC Patch] gpio: add GPIO hogging mechanism

Hi Benoit,

> On Oct 21, 2014, at 23:09 , Benoit Parrot <bparrot@...com> wrote:
> 
> Based on Boris Brezillion work this is a reworked patch
> of his initial GPIO hogging mechanism.
> This patch provides a way to initally configure specific GPIO
> when the gpio controller is probe.
> 
> The actual DT scanning to collect the GPIO specific data is performed
> as part of the gpiochip_add().
> 
> The purpose of this is to allows specific GPIOs to be configured
> without any driver specific code.
> This particularly usueful because board design are getting
> increassingly complex and given SoC pins can now have upward
> of 10 mux values a lot of connections are now dependent on
> external IO muxes to switch various modes and combination.
> 
> Specific drivers should not necessarily need to be aware of
> what accounts to a specific board implementation. This board level
> "description" should be best kept as part of the dts file.
> 

This look like it’s going to the right direction. I have a few general
comments at first.

1) It relies on dubious DT binding of having sub-nodes of the
gpio device implicitly defining hogs.

2) There is no way for having hogs inserted dynamically as far as I can tell, and
no way to remove a hog either.

3) I’m not very fond of having this being part of the gpio controller. This
configuration conceptually has little to do with the gpio controller per se,
it is more of a board specific thing. Why not come up with a gpio-hog driver that
references GPIOs? That way with a single gpio-hog driver instance you could setup
all the GPIO-hogging configuration for all GPIOs on the board, even one that
lie on different GPIO controllers.


> Signed-off-by: Benoit Parrot <bparrot@...com>
> ---
> Documentation/devicetree/bindings/gpio/gpio.txt | 33 +++++++++
> drivers/gpio/gpiolib-of.c                       | 99 +++++++++++++++++++++++++
> drivers/gpio/gpiolib.c                          | 81 ++++++++++++++++++++
> include/linux/of_gpio.h                         | 11 +++
> 4 files changed, 224 insertions(+)
> 

Regards

— Pantelis

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/