Hi Henry,
On 07/09/2022 14:49, Henry Wang wrote:
-----Original Message-----
From: Bertrand Marquis <bertrand.marq...@arm.com>
But in any case we should only add one pair here for sure, as you say
the
only implication is to add a couple of 0 in the worst case.
I agree. The only drawback is the need to modify the already introduced
properties
to be coherent.
Agree, someone will need to do a pass on the whole doc which might be
easier with all things in.
Well, not only docs. If we decide to use a single pair of #address-cells and
#size-cells, then
we need to modify the code that expects different properties e.g.
xen,static-mem-{address/size}-cells.
Right I forgot that some parts are already in.
So we will need an extra patch to handle those.
I think I've addressed all comments from Julien regarding my series,
If it is not too late for you would you be able to resend your series
without the 'address-cells'/'size-cells' change? This will give me the
opportunity to have an other review today.
so I think I've got some bandwidth to do the clean-up patch tomorrow
after the agreement, unless someone would like to do it himself?
Renaming "xen,static-mem-..." is a bit tricky because they have been
defined in Xen 4.16.
I couldn't find any support statement specific to the static memory
feature. So it would technically fall under the "dom0less" section which
is security supported.
That said, I don't think we can consider that the static memory feature
is even supported because, until yesterday, the code wasn't properly
handling request to balloon in/out. So I would view this is a tech
preview (Could someone send a patch to clarify SUPPORT.MD)?
This would mean that would be that we could consider the binding
unstable and we could do a straight renaming. That said, I can
understand this may be undesirable.
If that's the case then we would need to keep the current binding as-is.
So we would have two options:
1) Provide a new compatible so #address-cells #size-cells can be
used. The current binding can be deprecated
2) Leave as-is and accept the difference
I don't have a strong opinion on which way to go. Whichever, it would be
good to write down the rationale in the commit message of the "future"
patch.
I would not block this series on the renaming for existing property
(what matter is the new ones are consistent with the discussion). The
renaming could be done afterwards. I would even say post the feature
freeze on Friday because this could be considered as a bug fix (assuming
you agree as the release manager :)).
Cheers,
--
Julien Grall
