mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matt Porter <mporter@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Matt Porter <matt@ohporter.com>,
	Russell King <linux@arm.linux.org.uk>,
	<linux-omap@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] omap: board-omap3evm: add required smsc911x regulators
Date: Fri, 10 Feb 2012 13:50:33 -0500	[thread overview]
Message-ID: <20120210185033.GC40045@h115-84.vpn.ti.com> (raw)
In-Reply-To: <20120210174046.GQ1426@atomide.com>

On Fri, Feb 10, 2012 at 09:40:47AM -0800, Tony Lindgren wrote:
> * Matt Porter <matt@ohporter.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

  reply	other threads:[~2012-02-10 18:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08 22:06 Matt Porter
2012-02-10 17:40 ` Tony Lindgren
2012-02-10 18:50   ` Matt Porter [this message]
2012-02-10 22:53     ` Tony Lindgren
2012-02-13 16:44       ` Matt Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120210185033.GC40045@h115-84.vpn.ti.com \
    --to=mporter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=matt@ohporter.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®