linux-kernel - Re: [PATCH] omap: board-omap3evm: add required smsc911x regulators

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: <20120210185033.GC40045@h115-84.vpn.ti.com>
Date:	Fri, 10 Feb 2012 13:50:33 -0500
From:	Matt Porter <mporter@...com>
To:	Tony Lindgren <tony@...mide.com>
CC:	Matt Porter <matt@...orter.com>,
	Russell King <linux@....linux.org.uk>,
	<linux-omap@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] omap: board-omap3evm: add required smsc911x regulators

On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote:
> * Matt Porter <matt@...orter.com> [120208 13:35]:
> > This fixes smsc911x support on omap3evm that has been broken since
> > the smsc911x driver was updated to require the existence of vdd33a
> > and vddvario supplies.
> 
> Great. Few comments:
> 
> 1. Could you please include the smsc911x commit and subject here too
>    so it clearly shows the regression?

Sure. Will do for v2.

> 2. Also, why don't you add this fixed regulator to gpmc-smsc911.c?
> 
> That way it gets fixed for other too, like zoom2/3.

Ok, so I considered that at first and had two concerns that made me just
do it in the omap3evm specific way and see what the feedback was.

1) If we do a generic implementation in gpmc-smsc911x.c, there needs to
be a way to override it. Another board may have a variable supply that
feeds this consumer.

2) Technically, this omap3evm specific implementation matches the hardware
in that the osk_3v3 rail is software controllable. Granted, I commented
that we simply don't hook up the gpio at this time since this real
hardware regulator has always been silently asserted on by the nature of
the reset state of the TWL GPIOs and the board level pull downs as well.

So that said, I don't need #2 to make omap3evm work and I don't think
anybody cares yet to actually turn that regulator off (as it will kill
other things that appear to not have regulator support anyway). It looks
like you talked me into respinning it as a generic implementation. Only
question is whether I should bother consider not-yet-existing boards that
may not want that generic regulator.

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