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

[Pranavkumar Sawargaonkar <pranavkumar@xxxxxxxxxx>]

Hi Ian,

On 3 February 2014 22:34, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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.
Even i think this is the best way among all these patchy options :P
Tomorrow I will send a new patch with removal of dts stuff from xen
driver so that it will always work irrespective of linux stuff.
Once linux side comes to conclusion and merged i will reintroduce dts
stuff in this driver.

>
> #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.
>
-
Pranav

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