From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754424AbcGTOhH (ORCPT ); Wed, 20 Jul 2016 10:37:07 -0400 Received: from mail-yw0-f176.google.com ([209.85.161.176]:36814 "EHLO mail-yw0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754389AbcGTOg5 (ORCPT ); Wed, 20 Jul 2016 10:36:57 -0400 MIME-Version: 1.0 In-Reply-To: <20160720090220.GQ7132@piout.net> References: <1465970379-14703-1-git-send-email-andrew.smirnov@gmail.com> <1465970379-14703-4-git-send-email-andrew.smirnov@gmail.com> <20160619142934.GA8522@rob-hp-laptop> <20160621204904.GA9779@rob-hp-laptop> <20160621210739.GY5809@piout.net> <20160719224728.GP7132@piout.net> <20160720090220.GQ7132@piout.net> From: Andrey Smirnov Date: Wed, 20 Jul 2016 07:36:55 -0700 Message-ID: Subject: Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options To: Alexandre Belloni Cc: Rob Herring , rtc-linux@googlegroups.com, Alessandro Zummo , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 20, 2016 at 2:02 AM, Alexandre Belloni wrote: > On 19/07/2016 at 16:56:56 -0700, Andrey Smirnov wrote : >> >> I don't see any value in doing that, could you give me a realistic >> >> example of a scenario in which a user would want to spend some of >> >> uptime with RTC oscillator fault detection/glitch filtering disabled >> >> and then enable it? >> >> >> > >> > Well, the issue is not being dynamic, it is differentiating between >> > hardware description and user configuration. Configuration must not be in >> > DT. >> >> Why? And I don't mean in a generic sense, but in this particular case. >> What is gained by not having this bit of configuration, whose only >> consumer is the driver, in the device tree file? >> > > Because configuration doesn't belong to DT. DT is about hardware > description, not configuration. That doesn't really answer my question. You just re-iterating some maxim without explaining what is the point behind applying it. > > >> > And this choice is definitively not hardware related (as opposed to >> > the trickle charging that depends on the battery that is used on the >> > board). >> >> There's most certainly plenty of precedents of non hardware-related in >> device tree, first two that come to mind are "chosen" node and >> "local-mac-address" property and, granted, those might be >> exceptions/legacy bindings that are just there to stay, but even if >> you look at RTC subsystem rtc-cmos.txt, atmel,at91sam-rtc.txt and >> possibly rtc-st-lpc.txt are providing bindings that are not exactly >> hardware related. >> >> Rtc-cmos.txt is especially noticeable example since it literally does >> what I am trying to do -- allows the user to specify initial values to >> certain registers that would be initialized by the driver. >> > > Well, the RTC subsystem has been left unmaintained for a while and it is > not because we made mistakes in the past that we have to make them > again. > > rtc-st-lpc is only hardware related. The mode it is used in is board > dependant. And I have a plan to change how the gpbr register is > allocated for the at91 RTT. I agree that rtc-cmos is an example of what > not to do. > >> > Well, it doesn't leak abstraction as long as all the RTC that are able >> > to disable the oscillator failure detection use the same ABI. >> >> Correct me if I am wrong, but no such, at least semi-standardized, ABI >> exist as of today, correct? If that is so, then what you are saying is >> that the abstraction doesn't leak as long as you put it inside of a >> new abstraction that doesn't leak. I am not arguing that it is >> impossible to create a new one that would allow to hide hardware >> differences, I am positive it is, what I am arguing is that to do so >> is a lot of work for as far as I can see for no gain. >> > > You are correct, that ABI doesn't exist and I'm asking to create it. > That is how kernel development happens. OK, I don't think this is going anywhere. I am sure by now you know very well, that I am not going to agree to that. I'll just drop this part, gut the patchset to it's bare minimum and re-submit it. Andrey From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: rtc-linux@googlegroups.com Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com. [2607:f8b0:4002:c05::233]) by gmr-mx.google.com with ESMTPS id v70si199409ywc.2.2016.07.20.07.36.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 07:36:56 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id r9so47156075ywg.0 for ; Wed, 20 Jul 2016 07:36:56 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160720090220.GQ7132@piout.net> References: <1465970379-14703-1-git-send-email-andrew.smirnov@gmail.com> <1465970379-14703-4-git-send-email-andrew.smirnov@gmail.com> <20160619142934.GA8522@rob-hp-laptop> <20160621204904.GA9779@rob-hp-laptop> <20160621210739.GY5809@piout.net> <20160719224728.GP7132@piout.net> <20160720090220.GQ7132@piout.net> From: Andrey Smirnov Date: Wed, 20 Jul 2016 07:36:55 -0700 Message-ID: Subject: [rtc-linux] Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options To: Alexandre Belloni Cc: Rob Herring , rtc-linux@googlegroups.com, Alessandro Zummo , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , On Wed, Jul 20, 2016 at 2:02 AM, Alexandre Belloni wrote: > On 19/07/2016 at 16:56:56 -0700, Andrey Smirnov wrote : >> >> I don't see any value in doing that, could you give me a realistic >> >> example of a scenario in which a user would want to spend some of >> >> uptime with RTC oscillator fault detection/glitch filtering disabled >> >> and then enable it? >> >> >> > >> > Well, the issue is not being dynamic, it is differentiating between >> > hardware description and user configuration. Configuration must not be in >> > DT. >> >> Why? And I don't mean in a generic sense, but in this particular case. >> What is gained by not having this bit of configuration, whose only >> consumer is the driver, in the device tree file? >> > > Because configuration doesn't belong to DT. DT is about hardware > description, not configuration. That doesn't really answer my question. You just re-iterating some maxim without explaining what is the point behind applying it. > > >> > And this choice is definitively not hardware related (as opposed to >> > the trickle charging that depends on the battery that is used on the >> > board). >> >> There's most certainly plenty of precedents of non hardware-related in >> device tree, first two that come to mind are "chosen" node and >> "local-mac-address" property and, granted, those might be >> exceptions/legacy bindings that are just there to stay, but even if >> you look at RTC subsystem rtc-cmos.txt, atmel,at91sam-rtc.txt and >> possibly rtc-st-lpc.txt are providing bindings that are not exactly >> hardware related. >> >> Rtc-cmos.txt is especially noticeable example since it literally does >> what I am trying to do -- allows the user to specify initial values to >> certain registers that would be initialized by the driver. >> > > Well, the RTC subsystem has been left unmaintained for a while and it is > not because we made mistakes in the past that we have to make them > again. > > rtc-st-lpc is only hardware related. The mode it is used in is board > dependant. And I have a plan to change how the gpbr register is > allocated for the at91 RTT. I agree that rtc-cmos is an example of what > not to do. > >> > Well, it doesn't leak abstraction as long as all the RTC that are able >> > to disable the oscillator failure detection use the same ABI. >> >> Correct me if I am wrong, but no such, at least semi-standardized, ABI >> exist as of today, correct? If that is so, then what you are saying is >> that the abstraction doesn't leak as long as you put it inside of a >> new abstraction that doesn't leak. I am not arguing that it is >> impossible to create a new one that would allow to hide hardware >> differences, I am positive it is, what I am arguing is that to do so >> is a lot of work for as far as I can see for no gain. >> > > You are correct, that ABI doesn't exist and I'm asking to create it. > That is how kernel development happens. OK, I don't think this is going anywhere. I am sure by now you know very well, that I am not going to agree to that. I'll just drop this part, gut the patchset to it's bare minimum and re-submit it. Andrey -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Smirnov Subject: Re: [PATCH 03/13] RTC: ds1307: Add DS1341 specific power-saving options Date: Wed, 20 Jul 2016 07:36:55 -0700 Message-ID: References: <1465970379-14703-1-git-send-email-andrew.smirnov@gmail.com> <1465970379-14703-4-git-send-email-andrew.smirnov@gmail.com> <20160619142934.GA8522@rob-hp-laptop> <20160621204904.GA9779@rob-hp-laptop> <20160621210739.GY5809@piout.net> <20160719224728.GP7132@piout.net> <20160720090220.GQ7132@piout.net> Reply-To: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Sender: rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: <20160720090220.GQ7132-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org> List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Alexandre Belloni Cc: Rob Herring , rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Alessandro Zummo , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On Wed, Jul 20, 2016 at 2:02 AM, Alexandre Belloni wrote: > On 19/07/2016 at 16:56:56 -0700, Andrey Smirnov wrote : >> >> I don't see any value in doing that, could you give me a realistic >> >> example of a scenario in which a user would want to spend some of >> >> uptime with RTC oscillator fault detection/glitch filtering disabled >> >> and then enable it? >> >> >> > >> > Well, the issue is not being dynamic, it is differentiating between >> > hardware description and user configuration. Configuration must not be in >> > DT. >> >> Why? And I don't mean in a generic sense, but in this particular case. >> What is gained by not having this bit of configuration, whose only >> consumer is the driver, in the device tree file? >> > > Because configuration doesn't belong to DT. DT is about hardware > description, not configuration. That doesn't really answer my question. You just re-iterating some maxim without explaining what is the point behind applying it. > > >> > And this choice is definitively not hardware related (as opposed to >> > the trickle charging that depends on the battery that is used on the >> > board). >> >> There's most certainly plenty of precedents of non hardware-related in >> device tree, first two that come to mind are "chosen" node and >> "local-mac-address" property and, granted, those might be >> exceptions/legacy bindings that are just there to stay, but even if >> you look at RTC subsystem rtc-cmos.txt, atmel,at91sam-rtc.txt and >> possibly rtc-st-lpc.txt are providing bindings that are not exactly >> hardware related. >> >> Rtc-cmos.txt is especially noticeable example since it literally does >> what I am trying to do -- allows the user to specify initial values to >> certain registers that would be initialized by the driver. >> > > Well, the RTC subsystem has been left unmaintained for a while and it is > not because we made mistakes in the past that we have to make them > again. > > rtc-st-lpc is only hardware related. The mode it is used in is board > dependant. And I have a plan to change how the gpbr register is > allocated for the at91 RTT. I agree that rtc-cmos is an example of what > not to do. > >> > Well, it doesn't leak abstraction as long as all the RTC that are able >> > to disable the oscillator failure detection use the same ABI. >> >> Correct me if I am wrong, but no such, at least semi-standardized, ABI >> exist as of today, correct? If that is so, then what you are saying is >> that the abstraction doesn't leak as long as you put it inside of a >> new abstraction that doesn't leak. I am not arguing that it is >> impossible to create a new one that would allow to hide hardware >> differences, I am positive it is, what I am arguing is that to do so >> is a lot of work for as far as I can see for no gain. >> > > You are correct, that ABI doesn't exist and I'm asking to create it. > That is how kernel development happens. OK, I don't think this is going anywhere. I am sure by now you know very well, that I am not going to agree to that. I'll just drop this part, gut the patchset to it's bare minimum and re-submit it. Andrey -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit https://groups.google.com/d/optout.