From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753706AbbESM6L (ORCPT ); Tue, 19 May 2015 08:58:11 -0400 Received: from smarthost01c.mail.zen.net.uk ([212.23.1.5]:33787 "EHLO smarthost01c.mail.zen.net.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751198AbbESM6I (ORCPT ); Tue, 19 May 2015 08:58:08 -0400 Message-ID: <1432040283.3047.54.camel@linaro.org> Subject: Re: [PATCH v2 3/5] arm64: Juno: Add memory mapped timer node From: "Jon Medhurst (Tixy)" To: Liviu Dudau Cc: Mark Rutland , devicetree , Arnd Bergmann , Ian Campbell , Marc Zyngier , Catalin Marinas , Will Deacon , LKML , Rob Herring , Sudeep Holla , Olof Johansson , LAKML Date: Tue, 19 May 2015 13:58:03 +0100 In-Reply-To: <20150519113116.GH2175@e106497-lin.cambridge.arm.com> References: <1431970109-8902-1-git-send-email-Liviu.Dudau@arm.com> <1431970109-8902-4-git-send-email-Liviu.Dudau@arm.com> <1432033003.3047.43.camel@linaro.org> <20150519113116.GH2175@e106497-lin.cambridge.arm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-smarthost01c-IP: [82.69.122.217] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2015-05-19 at 12:31 +0100, Liviu Dudau wrote: > On Tue, May 19, 2015 at 11:56:43AM +0100, Jon Medhurst (Tixy) wrote: > > On Mon, 2015-05-18 at 18:28 +0100, Liviu Dudau wrote: > > > Juno based boards have a memory mapped timer @ 0x2a810000. This > > > is disabled on r0 version of the board due to an SoC errata. > > > > So wouldn't it make more sense then to disable it in the dts for r0? As > > it is, you disable it in the common file below then have to later > > re-enable it in juno-r1.dts. > > From what I have seen in the existing DTs the preffer approach seems to be of > disabling by default the node declared in the common files and enable > it in the DT that makes use of it. Yes, I does look that way, and I agree consistency usually wins out over any arguments over log or obviousness. > If there is any guidance on how to describe this sort of situations I > would really love to read it. I know of none, but I'd speculate the principal we've discovered is to fail safe and have potentially absent or broken hardware disabled by default. -- Tixy