From: Frank Rowand <frowand.list@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
Rob Herring <robh+dt@kernel.org>,
Nathan Fontenot <nfont@linux.vnet.ibm.com>,
Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/4] of: remove *phandle properties from expanded device tree
Date: Tue, 20 Jun 2017 23:18:30 -0700 [thread overview]
Message-ID: <594A0FB6.2000102@gmail.com> (raw)
In-Reply-To: <87mv92szsw.fsf@concordia.ellerman.id.au>
Hi Rob,
Michael has an issue that means this patch series is not OK in the
current form. I will work on a v7 to see if I can resolve the
issue.
-Frank
On 06/20/17 21:57, Michael Ellerman wrote:
> Hi Frank,
>
> frowand.list@gmail.com writes:
>> From: Frank Rowand <frank.rowand@sony.com>
>>
>> Remove "phandle", "linux,phandle", and "ibm,phandle" properties from
>> the internal device tree. The phandle will still be in the struct
>> device_node phandle field and will still be displayed as if it is
>> a property in /proc/device_tree.
>>
>> This is to resolve the issue found by Stephen Boyd [1] when he changed
>> the type of struct property.value from void * to const void *. As
>> a result of the type change, the overlay code had compile errors
>> where the resolver updates phandle values.
>>
>> [1] http://lkml.iu.edu/hypermail/linux/kernel/1702.1/04160.html
>>
>> - Add sysfs infrastructure to report np->phandle, as if it was a property.
>> - Do not create "phandle" "ibm,phandle", and "linux,phandle" properties
>> in the expanded device tree.
>> - Remove phandle properties in of_attach_node(), for nodes dynamically
>> attached to the live tree. Add the phandle sysfs entry for these nodes.
>> - When creating an overlay changeset, duplicate the node phandle in
>> __of_node_dup().
>> - Remove no longer needed checks to exclude "phandle" and "linux,phandle"
>> properties in several locations.
>> - A side effect of these changes is that the obsolete "linux,phandle" and
>> "ibm,phandle" properties will no longer appear in /proc/device-tree (they
>> will appear as "phandle").
>
> Sorry but I don't think that can work for us.
>
> Our DLPAR (ie. CPU/memory/device hotplug) stuff on PowerVM uses
> "ibm,phandle", and it's not the same thing as "phandle" /
> "linux,phandle".
>
> I don't know the code well myself, but the spec (PAPR) says:
>
> Note: If the “ibm,phandle” property exists, there are two “phandle”
> namespaces which must be kept separate. One is that actually used by
> the OF client interface, the other is properties in the device tree
> making reference to device tree nodes. These requirements are written
> to maintain backward compatibility with older FW versions predating
> these requirements; if the “ibm,phandle” property is not present, the
> OS may assume that any device tree properties which refer to this node
> will have a phandle value matching that returned by client interface
> services.
>
> I have systems here that still use "ibm,phandle". I also see at least
> some of the userspace code that looks for "ibm,phandle", and nothing
> else.
>
> The note above actually implies that the current Linux code is wrong,
> when it uses "ibm,phandle" as the value of np->phandle.
>
> So sorry that's a big mess, but we can't just rip out those properties.
>
> I think the minimal change would be to treat "ibm,phandle" like a normal
> property, I think that would allow our tools to keep working?
>
>
> The other thing that worries me is that by renaming (effectively)
> "linux,phandle" to "phandle", we lose the ability to accurately
> regenerate the device tree from /proc/device-tree. In theory it
> shouldn't matter, but I worry that in practice something will break.
>
> What if we just kept a single bit flag somewhere indicating if the name of
> the phandle property we found was "phandle" or "linux,phandle", and
> create the sysfs phandle using that name?
>
> cheers
>
next prev parent reply other threads:[~2017-06-21 6:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-20 22:02 [PATCH v6 0/4] of: remove *phandle properties from expanded device tree frowand.list
2017-06-20 22:02 ` frowand.list-Re5JQEeQqe8AvxtiuMwx3w
2017-06-20 22:02 ` [PATCH v6 1/4] " frowand.list
2017-06-21 4:57 ` Michael Ellerman
2017-06-21 4:57 ` Michael Ellerman
2017-06-21 4:57 ` Michael Ellerman
2017-06-21 6:18 ` Frank Rowand [this message]
2017-06-21 19:25 ` Frank Rowand
2017-06-21 23:56 ` Frank Rowand
2017-06-21 23:56 ` Frank Rowand
2017-06-22 15:54 ` Rob Herring
2017-08-02 18:16 ` Frank Rowand
2017-06-20 22:02 ` [PATCH v6 2/4] of: make __of_attach_node() static frowand.list
2017-06-21 23:46 ` Stephen Boyd
2017-06-21 23:46 ` Stephen Boyd
2017-06-20 22:02 ` [PATCH v6 3/4] of: be consistent in form of file mode frowand.list
2017-06-20 22:02 ` frowand.list-Re5JQEeQqe8AvxtiuMwx3w
2017-06-20 22:02 ` [PATCH v6 4/4] of: detect invalid phandle in overlay frowand.list
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=594A0FB6.2000102@gmail.com \
--to=frowand.list@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=nfont@linux.vnet.ibm.com \
--cc=robh+dt@kernel.org \
--cc=tyreld@linux.vnet.ibm.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 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.