[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171017184603.yluoukqq6hj2cgcb@sirena.co.uk>
Date: Tue, 17 Oct 2017 19:46:03 +0100
From: Mark Brown <broonie@...nel.org>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Brian Norris <briannorris@...omium.org>,
Thierry Reding <thierry.reding@...il.com>,
Jeffy Chen <jeffy.chen@...k-chips.com>,
lkml <linux-kernel@...r.kernel.org>,
Heiko Stübner <heiko@...ech.de>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Doug Anderson <dianders@...omium.org>, tfiga@...omium.org,
seanpaul@...omium.org,
"linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>
Subject: Re: [RFC PATCH v4 7/8] pwm: Add dummy pwmchip for orphan pwms
On Tue, Oct 17, 2017 at 11:24:24AM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 17, 2017 at 10:04 AM, Brian Norris <briannorris@...omium.org> wrote:
> > BTW, since you seem to have an opinion about device links: is it
> > expected that all consumer drivers will make explicit calls to
> > device_link_add()? I thought this should be avoided, if possible (e.g.,
> > this can be handled in pwm_get()).
> Ideally we would not have this in core kernel API (pwm_get, gpiod_get,
> regulator_get, etc) but retrieve it form the firmware (device tree,
> ACPI) and use this data not only on suspend/resume but for probing as
Right, the major initial push here was for ordering of probes so doing
it in subsystems or drivers is too late.
> well. *How exactly* can we do that is still not clear though, so maybe
> we could plug the biggest holes by actually adding device links calls
> to the main devm_<object>_get() users...
I would expect we can get a long way in the DT by doing a pass over the
tree and adding links between device nodes in cases where phandle
references exist. There is a potential issue with circular links which
I'm just going to handwave away right now but I'd expect that to help
otherwise.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists