From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vps0.lunn.ch ([178.209.37.122]:45422 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751338AbdH0Nrm (ORCPT ); Sun, 27 Aug 2017 09:47:42 -0400 Date: Sun, 27 Aug 2017 15:47:29 +0200 From: Andrew Lunn To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Rob Herring , linux-rtc@vger.kernel.org, Alessandro Zummo , Roc He , devicetree@vger.kernel.org, ????????? , linux-kernel@vger.kernel.org, Alexandre Belloni , Mark Rutland , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC 1/3] dt-bindings: rtc: Add Realtek RTD1295 Message-ID: <20170827134729.GE13622@lunn.ch> References: <20170820013632.18375-1-afaerber@suse.de> <20170820013632.18375-2-afaerber@suse.de> <20170823002911.y35nn7jkt34dvjbc@rob-hp-laptop> <629b9ed0-7b2d-7c5c-20b8-17289a76f097@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <629b9ed0-7b2d-7c5c-20b8-17289a76f097@suse.de> Sender: linux-rtc-owner@vger.kernel.org List-ID: > Thanks. Did you read the RFC question in the cover letter as well and > have any comments? Downstream has an rtc-base-year = <2014>; property > that I had left out in this RFC and due to your ack not included in v2. > > Should we default to 2014 in the driver and add an optional base-year > property once we encounter a diverging device, or should we make it > required from the beginning? I did not spot any other rtc binding with > such a property and would appreciate a clarification. Hi Andreas >>From the perspective of the hardware, does it care what the base is? A device using a different base will initially return the wrong time. But once the correct time has been written back, it will be O.K. This only becomes an issue if a device is used with different OSs, which have different bases. Swapping back and forth between OSs then becomes an issue. KISS suggests not having a base in DT until it is actually required. Since it is an additional property, it does not break backwards compatibility when added. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 From: andrew@lunn.ch (Andrew Lunn) Date: Sun, 27 Aug 2017 15:47:29 +0200 Subject: [RFC 1/3] dt-bindings: rtc: Add Realtek RTD1295 In-Reply-To: <629b9ed0-7b2d-7c5c-20b8-17289a76f097@suse.de> References: <20170820013632.18375-1-afaerber@suse.de> <20170820013632.18375-2-afaerber@suse.de> <20170823002911.y35nn7jkt34dvjbc@rob-hp-laptop> <629b9ed0-7b2d-7c5c-20b8-17289a76f097@suse.de> Message-ID: <20170827134729.GE13622@lunn.ch> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org > Thanks. Did you read the RFC question in the cover letter as well and > have any comments? Downstream has an rtc-base-year = <2014>; property > that I had left out in this RFC and due to your ack not included in v2. > > Should we default to 2014 in the driver and add an optional base-year > property once we encounter a diverging device, or should we make it > required from the beginning? I did not spot any other rtc binding with > such a property and would appreciate a clarification. Hi Andreas >>From the perspective of the hardware, does it care what the base is? A device using a different base will initially return the wrong time. But once the correct time has been written back, it will be O.K. This only becomes an issue if a device is used with different OSs, which have different bases. Swapping back and forth between OSs then becomes an issue. KISS suggests not having a base in DT until it is actually required. Since it is an additional property, it does not break backwards compatibility when added. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lunn Subject: Re: [RFC 1/3] dt-bindings: rtc: Add Realtek RTD1295 Date: Sun, 27 Aug 2017 15:47:29 +0200 Message-ID: <20170827134729.GE13622@lunn.ch> References: <20170820013632.18375-1-afaerber@suse.de> <20170820013632.18375-2-afaerber@suse.de> <20170823002911.y35nn7jkt34dvjbc@rob-hp-laptop> <629b9ed0-7b2d-7c5c-20b8-17289a76f097@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <629b9ed0-7b2d-7c5c-20b8-17289a76f097-l3A5Bk7waGM@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andreas =?iso-8859-1?Q?F=E4rber?= Cc: Rob Herring , linux-rtc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alessandro Zummo , Roc He , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ????????? , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alexandre Belloni , Mark Rutland , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org > Thanks. Did you read the RFC question in the cover letter as well and > have any comments? Downstream has an rtc-base-year = <2014>; property > that I had left out in this RFC and due to your ack not included in v2. > > Should we default to 2014 in the driver and add an optional base-year > property once we encounter a diverging device, or should we make it > required from the beginning? I did not spot any other rtc binding with > such a property and would appreciate a clarification. Hi Andreas >>From the perspective of the hardware, does it care what the base is? A device using a different base will initially return the wrong time. But once the correct time has been written back, it will be O.K. This only becomes an issue if a device is used with different OSs, which have different bases. Swapping back and forth between OSs then becomes an issue. KISS suggests not having a base in DT until it is actually required. Since it is an additional property, it does not break backwards compatibility when added. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html