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: <CACRpkdawaM5dMqoyeb=UqzaCeEdfSD-dQ+AMxwe5L9FQQsWKyw@mail.gmail.com>
Date:	Mon, 14 Dec 2015 14:42:23 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Robert Jarzmik <robert.jarzmik@...e.fr>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <zonque@...il.com>
Subject: Re: [PATCH 0/4] gpio: pxa: integrate with pincontrol

On Thu, Dec 10, 2015 at 6:31 PM, Robert Jarzmik <robert.jarzmik@...e.fr> wrote:
> Linus Walleij <linus.walleij@...aro.org> writes:
>
>>>    - the GPDR (gpio direction register) shared access bothers me a bit
>>
>> How is it shared and between what users?
>
> It's shared between the pin controller and the gpio controller.

OK then it may be one of these cases where we should jit the pin controller
and the GPIO controller together in the same file (under drivers/pinctrl)
to simplify the mess. We can do that in the NEXT merge window because
right now I don't want any more crisscross between gpio and pin control
as there are refactorings I'm piling up.

Another option is e.g. accessing the registers through regmap-mmio but
it feels a bit like overkill for this...

> The odd thing with the pxa architecture is that the GPDR bit selects between 2
> different alternate functions, even when the pin is not a GPIO. Strange design,
> isn't it ?

Probably just unfortunate naming.

In my presentation "building GPIO and pin control from the ground up" I
try to explain a bit how hardware engineers design these things...
http://dflund.se/~triad/papers/pincontrol.pdf

> As a consequence, both the gpio driver and pinctrl have to modify it, for
> different purposes :
>  - pinctrl will modify it to select a specific alternate function
>  - gpio driver will modify it when the pin is a GPIO, to modify its direction.

OK. Solutions per above, I guess it currently just optimistically hope
we do not fiddle the same bit in parallell from the two drivers (which
is maybe even possible to prove to be true).

Yours,
Linus Walleij
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ