linux-kernel - Re: [PATCH] gpio: New driver for GPO emulation using PWM generators

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]

Date:	Thu, 29 Nov 2012 13:18:11 +0100
From:	Peter Ujfalusi <peter.ujfalusi@...com>
To:	Thierry Reding <thierry.reding@...onic-design.de>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Linus Walleij <linus.walleij@...aro.org>,
	Rob Landley <rob@...dley.net>,
	<devicetree-discuss@...ts.ozlabs.org>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	<linux-omap@...r.kernel.org>
Subject: Re: [PATCH] gpio: New driver for GPO emulation using PWM generators

On 11/28/2012 08:30 PM, Thierry Reding wrote:
> I must say I'm not terribly thrilled to integrate something like this
> into the PWM subsystem.

I agree. I would not really want to add my name to something like this either...

> I wish hardware engineers wouldn't come up with such designs.

I have checked and rechecked the schematics and datasheets. Still can not
understand how anyone would come to this HW solution (when the twl4030 have at
least 4 unused GPIO line left unconnected).

> But since this seems to be a real use-case, if we want to
> support it we should try and find the "right" solution.
> 
> Reading the above sounds overly complicated. Couldn't we, instead of
> instantiating an extra driver, just register a GPIO chip if a chip wants
> to support this functionality? Where the GPIO chip's request callback
> requests the given PWM so that it cannot be used elsewhere? The
> direction_input callback would need to always fail and the set callback
> can configure the PWM either to 0% or 100% duty-cycle depending on the
> desired output value.

The original driver was doing exactly this. Basically I have added a GPO chip
(which was just a translator from PWM to GPO). In DT it looked like this:

twl_pwm: pwm {
	compatible = "ti,twl4030-pwmled";
	#pwm-cells = <2>;
};

pwm_gpo1: gpo1 {
	compatible = "pwm-gpo";
	#gpio-cells = <1>;
	gpio-controller;
	pwms = <&twl_pwm 0 7812500>;
	pwm-names = "nUSBHOST_PWR_EN";
};

user@1 {
	compatible = "example,testuser";
	gpios = <&pwm_gpo1 0>;
};

When we boot with DT the pwm_get() needs pwms phandle from the device you are
calling it in order to find the PWM in question. If we do not have DT entry
for the GPO driver, we need to build up a pwm_lookup table to ensure that the
pwm_get() will find the PWM we want to handle.

We could implement the GPIO related code under for example
drivers/pwm/pwm-as-gpo.c
But then I should merge the code from drivers/gpio/gpio-pwm.c inside.
This is not nice either since we will have a GPIO driver living under pwm/
directory and I'm not sure how this would use the pwm API when the GPO
functionality is requested.

-- 
Péter
--
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/