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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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
> >> > that?
> >> >
> >> > 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.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel