From: Mark Brown <broonie@kernel.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Nathan Chancellor <natechancellor@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Cheng-Jui.Wang@mediatek.com,
Android Kernel Team <kernel-team@android.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Daniel Mentz <danielmentz@google.com>,
linux-spi@vger.kernel.org
Subject: Re: [PATCH v1 2/2] spi: Populate fwnode in of_register_spi_device()
Date: Fri, 6 Nov 2020 15:10:11 +0000 [thread overview]
Message-ID: <20201106151011.GE49612@sirena.org.uk> (raw)
In-Reply-To: <CAGETcx9_En10j0DwktXtPDrx=Aqdr2iWEuHmYB-=SnfODTmMfg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]
On Thu, Nov 05, 2020 at 11:26:44AM -0800, Saravana Kannan wrote:
> On Thu, Nov 5, 2020 at 9:12 AM Mark Brown <broonie@kernel.org> wrote:
> > > of_node_get(nc);
> > > spi->dev.of_node = nc;
> > > + spi->dev.fwnode = of_fwnode_handle(nc);
> > Why is this a manual step in an individual subsystem rather than
> > something done in the driver core
> It can't be done in driver core because "fwnode" is the abstraction
> driver core uses. It shouldn't care or know if the firmware is DT,
> ACPI or something else -- that's the whole point of fwnode.
Clearly it *can* be done in the driver core, the question is do we want
to. The abstraction thing feels weaker at init than use after init,
"init from X" is a common enough pattern. If it's done by the driver
core there would be no possibility of anything that creates devices
getting things wrong here, and the driver core already has a bunch of
integration with both DT and ACPI so it seems like a weird boundary to
have.
> > and wouldn't that just be a case of
> > checking to see if there is a fwnode already set and only initializing
> > if not anyway?
> Honestly, we should be deleting device.of_node and always use
> device.fwnode. But that's a long way away (lots of clean up). The
> "common" place to do this is where a struct device is created from a
> firmware (device_node, acpi_device, etc). I don't see a "common place"
> for when a device is created out of a device_node, so I think this
> patch is a reasonable middle ground.
That is obviously a much bigger job that's going to require going
through subsystems (and their drivers) properly to eliminate references
to of_node, I'm not clear how doing this little bit per subsystem rather
than in the core helps or hinders going through and doing that. I don't
think you'll ever have a single place where a device is constructed, and
I'm not sure that that is even desirable, since there are per subsystem
things that need doing.
I'd be totally happy with eliminating all references to of_node from the
subsystem but for this it seems more sensible to do it in the driver
core and cover everything rather than running around everything that
creates a device from DT individually and having stuff fall through the
cracks - it's been a year since the equivalent change was made in I2C
for example, we've had new buses merged in that time never mind SPI not
being covered.
BTW I'm also missing patch 1 and the cover letter for this series, not
sure what's going on there?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-11-06 15:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-04 20:54 [PATCH v1 1/2] driver core: Fix lockdep warning on wfs_lock Saravana Kannan
2020-11-04 20:54 ` [PATCH v1 2/2] spi: Populate fwnode in of_register_spi_device() Saravana Kannan
2020-11-05 17:12 ` Mark Brown
2020-11-05 19:26 ` Saravana Kannan
2020-11-06 15:10 ` Mark Brown [this message]
2020-11-06 19:12 ` Saravana Kannan
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=20201106151011.GE49612@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Cheng-Jui.Wang@mediatek.com \
--cc=clang-built-linux@googlegroups.com \
--cc=danielmentz@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=rafael@kernel.org \
--cc=saravanak@google.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®