Re: [Xen-devel] [PATCH v5 3/7] xen/arm: zynqmp: introduce zynqmp specific defines

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 12 Dec 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 11/12/2018 19:22, Stefano Stabellini wrote:
> > On Tue, 11 Dec 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 03/12/2018 21:03, Stefano Stabellini wrote:
> > > What is the plan there?
> > 
> > The plan is to extract the node_id from a power-domain node on device
> > tree. Each device would have a phandler to link to the right
> > power-domain node which contains a power-domain-id attribute. The
> > power-domain-id attribute is the node_id here.
> > 
> > The power-domain-id changes to the Xilinx MPSoC device tree are under
> > discussion with the device tree community.
> 
> If I understand correctly, we will never be able to remove the hardcoded
> values in Xen. This is because some device-tree may not have the bindings. Am
> I correct?

If we want to support running on existing hardware and firmware releases,
then you are correct. We won't be able to remove the hardcoded values.
That ship has sailed, not much we can do about it.

If in the future we decide to drop support for older firmware releases
and ask users to update their firmare/devicetrees, then we'll be able to
remove the hardcoded values. I think it is something we can consider.
In fact, I would rather break compatibility than not providing support
for basic power management functionalities at all.

I think it is better to introduce basic EEMI support now, even if in a
couple of Xen releases from now we'll make the decision to drop the
hardcoded values and require new Xilinx device trees. Xilinx users are
used to updating firmware on these boards every 6 months, and it would
beneficial for them to be able to take a Xen Project release rather than
be forced to use a Xilinx Xen release to have support for power
management. When the new bindings become available, as we introduce
support for them in Xen, we can decide whether to keep the hardcoded
values or whether we should take the opportunity to drop them.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel