From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pranavkumar Sawargaonkar Subject: Re: [PATCH V6] xen: arm: platforms: Adding reset support for xgene arm64 platform. Date: Mon, 3 Feb 2014 22:55:11 +0530 Message-ID: References: <1390822488-22183-1-git-send-email-pranavkumar@linaro.org> <1390924071.7753.115.camel@kazak.uk.xensource.com> <1390931022.31814.32.camel@kazak.uk.xensource.com> <1390999123.31814.96.camel@kazak.uk.xensource.com> <1391447061.10515.63.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1391447061.10515.63.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Anup Patel , Patch Tracking , George Dunlap , patches@apm.com, xen-devel@lists.xen.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org Hi Ian, On 3 February 2014 22:34, 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 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