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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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
> > > > > 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.
That sounds reasonable to me.

 -George

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