[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101005214220.GB19895@sirena.org.uk>
Date: Tue, 5 Oct 2010 22:42:21 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Samu Onkalo <samu.p.onkalo@...ia.com>, linux-i2c@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] misc: Driver for APDS990X ALS and proximity sensors
On Tue, Oct 05, 2010 at 12:23:23PM +0100, Alan Cox wrote:
> > + chip->regs[0].supply = reg_vcc;
> > + chip->regs[1].supply = reg_vled;
> Shouldn't these come from the provided platform data ? and again if there
> isn't a platform one supplied just skip the regulators. There are going
No, don't do this. The device should just request the supplies that
correspond to the physical supplies for the device and let the regulator
API worry about actually providing regulators to match it. If
regulators are getting passed in as platform data something has gone
wrong.
> to be cases of boxes with regulator API stuff in use but who don't have
> regulators for that device.
If there genuinely is no supply present on the pin then the device needs
to know that; if there is a supply present but it's not software managed
then the regulator API can cope with that.
Trying to handle this in individual device drivers just results in reams
of cut'n'paste code in device drivers, frequently requring the addition
of platform data to devices that would not otherwise require any. We've
tried it, it's painful. Having the machine specific data provided as a
generic regulator API service provides a great degree of simplification.
--
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