From: Phil Elwell <phil@raspberrypi.org>
To: Frank Rowand <frowand.list@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Dynamic overlay failure in 4.19 & 4.20
Date: Tue, 4 Jun 2019 20:39:04 +0100 [thread overview]
Message-ID: <db0fdbc6-33ce-d7b6-c807-896905fe4a90@raspberrypi.org> (raw)
In-Reply-To: <4d5b9fba-3879-0729-119a-f7d585a74cc1@gmail.com>
Hi Frank,
On 04/06/2019 19:20, Frank Rowand wrote:
> Hi Phil,
>
> On 6/4/19 5:15 AM, Phil Elwell wrote:
>> Hi,
>>
>> In the downstream Raspberry Pi kernel we are using configfs to apply overlays at
>> runtime, using a patchset from Pantelis that hasn't been accepted upstream yet.
>> Apart from the occasional need to adapt to upstream changes, this has been working
>> well for us.
>>
>> A Raspberry Pi user recently noticed that this mechanism was failing for an overlay in
>> 4.19. Although the overlay appeared to be applied successfully, pinctrl was reporting
>> that one of the two fragments contained an invalid phandle, and an examination of the
>> live DT agreed - the target of the reference, which was in the other fragment, was
>> missing the phandle property.
>>
>> 5.0 added two patches - [1] to stop blindly copying properties from the overlay fragments
>> into the live tree, and [2] to explicitly copy across the name and phandle properties.
>> These two commits should be treated as a pair; the former requires the properties that
>> are legitimately defined by an overlay to be added via a changeset, but this mechanism
>> deliberately skips the name and phandle; the latter addresses this shortcoming. However,
>> [1] was back-ported to 4.19 and 4.20 but [2] wasn't, hence the problem.
>
> I have relied upon Greg's statement that he would handle the stable kernels, and that
> the process of doing so would not impact (or would minimally impact) maintainers. If
> I think something should go into stable, I will tag it as such, but otherwise I ignore
> the stable branches. For overlay related code specifically, my base standard is that
> overlay support is an under development, not yet ready for prime time feature and thus
> I do not tag my overlay patches for stable.
>
> Your research and analysis above sound like there are on target (thanks for providing
> the clear and detailed explanation!), so if you want the stable branches to work for
> overlays (out of tree, as you mentioned) I would suggest you email Greg, asking that
> the second patch be added to the stable branches. Since the two patches you pointed
> out are put of a larger series, you might also want to check which of the other
> patches in that series were included in stable or left out from stable. My suggestion
> that you request Greg add the second patch continues to rely on the concept that
> stable does not add to my workload, so I have not carefully analyzed whether adding
> the patch actually is the correct and full fix, but instead am relying on your good
> judgment that it is.
<useful context snipped>
Thank you - I'll email Greg directly as you suggest, with your answer as supporting
evidence.
Phil
prev parent reply other threads:[~2019-06-04 19:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 12:15 Dynamic overlay failure in 4.19 & 4.20 Phil Elwell
2019-06-04 18:20 ` Frank Rowand
2019-06-04 19:39 ` Phil Elwell [this message]
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=db0fdbc6-33ce-d7b6-c807-896905fe4a90@raspberrypi.org \
--to=phil@raspberrypi.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pantelis.antoniou@konsulko.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).