From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Rob Herring <robh+dt@kernel.org>, Nicholas Piggin <npiggin@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
Frank Rowand <frowand.list@gmail.com>
Subject: Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Date: Thu, 06 Apr 2017 06:58:01 +1000 [thread overview]
Message-ID: <1491425881.4166.90.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAL_JsqLEvjb8S-+-JEa4ALHeCWHiR1A_4ur9kd3pBRJaFYWVKw@mail.gmail.com>
On Wed, 2017-04-05 at 10:58 -0500, Rob Herring wrote:
> Well, I'd like to avoid expanding usage of flat DT parsing in the
> kernel. But you could just put this function into arch/powerpc and I'd
> never see it, but I like that even less. Mainly, I just wanted to
> raise the point.
>
> Your argument works until you need that setup in assembly code, then
> you are in the situation that you need to either handle the setup in
> bootloader/firmware or have an simple way to determine that condition.
The main issue is that changing that is a very very invasive change in
an extremely fragile and rather nasty area of code shared by 32 and 64-
bit for which we don't even have easy access to all the machines to
test with anymore :)
It's probably not impossible, but it would delay the new cpu feature
stuff that Nick is making by a lot, probably monthes, making it nearly
impossible to get back into distros etc...
So while it might be something to consider, I would definitely keep
that as a separate unit of work to do later.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
To: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linuxppc-dev
<linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
Frank Rowand
<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
Date: Thu, 06 Apr 2017 06:58:01 +1000 [thread overview]
Message-ID: <1491425881.4166.90.camel@kernel.crashing.org> (raw)
In-Reply-To: <CAL_JsqLEvjb8S-+-JEa4ALHeCWHiR1A_4ur9kd3pBRJaFYWVKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2017-04-05 at 10:58 -0500, Rob Herring wrote:
> Well, I'd like to avoid expanding usage of flat DT parsing in the
> kernel. But you could just put this function into arch/powerpc and I'd
> never see it, but I like that even less. Mainly, I just wanted to
> raise the point.
>
> Your argument works until you need that setup in assembly code, then
> you are in the situation that you need to either handle the setup in
> bootloader/firmware or have an simple way to determine that condition.
The main issue is that changing that is a very very invasive change in
an extremely fragile and rather nasty area of code shared by 32 and 64-
bit for which we don't even have easy access to all the machines to
test with anymore :)
It's probably not impossible, but it would delay the new cpu feature
stuff that Nick is making by a lot, probably monthes, making it nearly
impossible to get back into distros etc...
So while it might be something to consider, I would definitely keep
that as a separate unit of work to do later.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-04-05 20:58 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-05 12:37 [PATCH 0/3] latest cpufeatures patch series Nicholas Piggin
2017-04-05 12:37 ` [PATCH 1/3] powerpc/64s: POWER9 no LPCR VRMASD bits Nicholas Piggin
2017-04-05 12:37 ` [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle Nicholas Piggin
2017-04-05 12:37 ` Nicholas Piggin
[not found] ` <CAL_JsqK4zbACwWVb-rsrvBb4hjBCexrqKRKrzSiZrZH5w=bKqQ@mail.gmail.com>
[not found] ` <20170406003251.533e2845@roar.ozlabs.ibm.com>
2017-04-05 15:58 ` Rob Herring
2017-04-05 15:58 ` Rob Herring
2017-04-05 20:58 ` Benjamin Herrenschmidt [this message]
2017-04-05 20:58 ` Benjamin Herrenschmidt
2017-04-06 0:38 ` Nicholas Piggin
2017-04-06 0:38 ` Nicholas Piggin
2017-04-06 14:09 ` Rob Herring
2017-04-06 14:09 ` Rob Herring
2017-04-10 5:43 ` Nicholas Piggin
2017-04-10 5:43 ` Nicholas Piggin
2017-04-10 13:42 ` Rob Herring
2017-04-10 13:42 ` Rob Herring
2017-04-07 6:40 ` Michael Ellerman
2017-04-07 6:40 ` Michael Ellerman
2017-04-05 12:37 ` [PATCH 3/3] powerpc/64s: cpufeatures: add initial implementation for cpufeatures Nicholas Piggin
2017-04-06 8:59 ` kbuild test robot
2017-04-10 7:21 ` Nicholas Piggin
-- strict thread matches above, loose matches on Subject: below --
2017-04-12 17:48 [PATCH 0/3] cpufeatures merge candidate Nicholas Piggin
2017-04-12 17:48 ` [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle Nicholas Piggin
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=1491425881.4166.90.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=robh+dt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.