linux-kernel - Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver

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, 10 Oct 2013 10:37:08 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Inki Dae <inki.dae@...sung.com>
Cc:	'Olof Johansson' <olof@...om.net>,
	'Sean Paul' <seanpaul@...omium.org>,
	devicetree@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	'DRI mailing list' <dri-devel@...ts.freedesktop.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 3/5] drm/bridge: Add PTN3460 bridge driver

On Thu, Oct 10, 2013 at 01:18:05PM +0900, Inki Dae wrote:

> > > I still think the pin could be replaced with a regulator. But
> > > lvds-bridge node has "powerdown-gpio" property - it say this board
> > > will use gpio pin - specific to board.  So it seems no problem.

> > No, don't model things that aren't regulators as regulators - it's just
> > confusing from a usability standpoint and causes breakage when the pins
> > don't behave like regulators.

> It seems that there was your missing point. That _is not_ what I mentioned.
> I mean that other boards can use a regulator instead of gpio pin.

What I'm saying is no boards should use a regulator to control that
GPIO pin, obviously if they're controlling the actual regulators that's
fine but the reset signal should not be controlled via the regulator
API (there are some unfortunate cases where people have done that
already but let's not have any more).

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)