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: <1398848062.19894.38.camel@paszta.hi.pengutronix.de>
Date:	Wed, 30 Apr 2014 10:54:22 +0200
From:	Philipp Zabel <p.zabel@...gutronix.de>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:	linux-kernel@...r.kernel.org,
	Arnd Bergmann Arnd Bergmann <arnd@...db.de>,
	Mark Rutland <mark.rutland@....com>,
	Roger Quadros <rogerq@...com>,
	Stephen Warren <swarren@...dotorg.org>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	kernel@...gutronix.de
Subject: Re: [PATCH v4 1/2] Documentation: Add GPIO reset binding to reset
 binding documentation

Hi Maxime,

Am Donnerstag, den 17.04.2014, 13:58 +0200 schrieb Maxime Ripard:
> I still feel like we should really treat gpios like just another reset
> controller, ie. using the resets property.

I now feel like we really shouldn't. If we do anything but use the
generic gpio bindings for reset gpios, we might force every OS or
bootloader using the device tree to implement some kind of reset
controller framework, even for hardware that only has gpio resets.

> I understand that you chose this pattern to be pretty much compatible
> with what have been done so fare, bu I don't see how to fulfill that
> goal completely, since most of the devices are actually using
> reset-gpios, but some are using other names too (including
> reset-gpio).

Yes, that is a problem that applies to all gpios, not only to reset
gpios, though.

> So if we can't be fully backward compatible, I don't see the benefit
> of being inconsistent with how reset controllers are used in general,

See above.

> and more globally on how gpios are tied for regulators for example.

Reset controllers are rather more similar to gpio or interrupt
controllers. Those also have a number of entities per device node,
as opposed to regulators.

> That would also make reset-gpio a regular reset driver, instead of
> adding logic to the core itself to handle this special case.

Which is what I initially tried and moved away from.

regards
Philipp

--
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