[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH V6] xen: arm: platforms: Adding reset support for xgene arm64 platform.

On 02/03/2014 05:04 PM, Ian Campbell wrote:
On Thu, 2014-01-30 at 11:38 +0530, Pranavkumar Sawargaonkar wrote:
Hi Ian,

On 29 January 2014 18:08, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
On Tue, 2014-01-28 at 23:27 +0530, Pranavkumar Sawargaonkar wrote:

I also don't see any patch to linux/Documentation/devicetree/bindings,
as was requested in that posting from 6 months ago. Where can I find

It seems like the patch to arch/arm64/boot/dts/apm-storm.dtsi also
hasn't landed?
Yeah it is dangling and since new patch is already posted i think we
can wait for final DT bindings.
It seems from the thread that the final bindings are going to differ
significantly from what is implemented in Xen and proposed in the above
thread. (with a syscon driver that the reset driver references).

Now if you want this to be fixed , i can quickly submit a V7 in which
mask field will be just hard-coded to 1 hence xen code will always
work even if linux code does gets changed.
Looks like the Linux driver uses 0xffffffff if the mask isn't given --
that seems like a good approach.

I think we'll just have to accept that until the binding is specified
and documented (in linux/Documentation/devicetree/bindings) then we may
have to be prepared to change the Xen implementation to match the final
spec without regard to backwards compat. If we aren't happy with that
then I should revert the patch now and we will have to live without
reboot support in the meantime.
Please do not revert the patch , I think we can go ahead with current patch.
Once linux side is concluded i will fix minor changes in xen code
based on new DT bindigs..
It doesn't sounds to me like it is going to be minor changes.
Yes binding are changed in new drivers but now question is what to do
in current state where new driver is not submitted ?

My take is we have 3 opts :
1. Keep current reboot driver in xen as it is and use it with old
bindings. (since that is the one merged in linux)
2. I will send a new patch (will take 1hr max for me to do it) with
addresses hardcoded instead of reading it from dts.
     This will help for xen to have reboot driver for xgene.
3. Remove this driver completely from xen as of now.
None of the options are brilliant :-/

I think on balance #2 is probably the way to go.

#1 would set a precedent for using formally undefined bindings which I
think we should avoid.

#3 has obvious downsides, but given that we have already accepted the
functionality it seems a shame to revert it entirely.

That sounds reasonable to me.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.