From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Gaignard Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Date: Wed, 21 Jun 2017 11:14:34 +0200 Message-ID: References: <1497951359-13334-1-git-send-email-benjamin.gaignard@linaro.org> <20170620100348.zh4ygvjjgnhxvmvl@piout.net> <20170620121011.GA13221@amd> <20170620122400.sm7qqvwyj6cuzarw@piout.net> <20170620132620.GA16881@amd> <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD@SW-EX-MBX02.diasemi.com> <20170620134458.GA10104@amd> <20170620134827.ubvzhh25klaotupv@piout.net> <20170620220805.GA11195@amd> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20170620220805.GA11195@amd> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Pavel Machek Cc: Alexandre Belloni , Steve Twiss , "linaro-kernel-cunTk1MwBs8s++Sfvej+rw@public.gmane.org" , "adi-buildroot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , Alessandro Zummo , Gregory Clement , Ingo Molnar , Jason Cooper , John Stultz , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linus Walleij , Michael Chan , "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , rtc-linux-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org List-Id: linux-tegra@vger.kernel.org 2017-06-21 0:08 GMT+02:00 Pavel Machek : > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> Yes, that's argument against changing rtc _drivers_ for hardware that >> >> can not do better than 32bit. For generic code (such as 44/51 sysfs, >> >> 51/51 suspend test), the change still makes sense. >> >> What I had in mind when writing those patches was to remove the limitations >> coming from those functions usage, even more since they been marked has >> deprecated. >> >> I agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752520AbdFUJOk (ORCPT ); Wed, 21 Jun 2017 05:14:40 -0400 Received: from mail-qk0-f176.google.com ([209.85.220.176]:33281 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751149AbdFUJOg (ORCPT ); Wed, 21 Jun 2017 05:14:36 -0400 MIME-Version: 1.0 In-Reply-To: <20170620220805.GA11195@amd> References: <1497951359-13334-1-git-send-email-benjamin.gaignard@linaro.org> <20170620100348.zh4ygvjjgnhxvmvl@piout.net> <20170620121011.GA13221@amd> <20170620122400.sm7qqvwyj6cuzarw@piout.net> <20170620132620.GA16881@amd> <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD@SW-EX-MBX02.diasemi.com> <20170620134458.GA10104@amd> <20170620134827.ubvzhh25klaotupv@piout.net> <20170620220805.GA11195@amd> From: Benjamin Gaignard Date: Wed, 21 Jun 2017 11:14:34 +0200 Message-ID: Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions To: Pavel Machek Cc: Alexandre Belloni , Steve Twiss , "linaro-kernel@lists.linaro.org" , "adi-buildroot-devel@lists.sourceforge.net" , Alessandro Zummo , Gregory Clement , Ingo Molnar , Jason Cooper , John Stultz , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Linus Walleij , Michael Chan , "netdev@vger.kernel.org" , "rtc-linux@googlegroups.com" , Sebastian Hesselbarth , Support Opensource , Thomas Gleixner , "x86@kernel.org" , Baruch Siach , Hans Ulli Kroll , Vladimir Zapolskiy , Sylvain Lemieux , Barry Song , Maxime Ripard , Chen-Yu Tsai , Thierry Reding , Jonathan Hunter , "linux-tegra@vger.kernel.org" , "patches@opensource.wolfsonmicro.com" , "Rafael J. Wysocki" , Len Brown , "linux-pm@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 2017-06-21 0:08 GMT+02:00 Pavel Machek : > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> Yes, that's argument against changing rtc _drivers_ for hardware that >> >> can not do better than 32bit. For generic code (such as 44/51 sysfs, >> >> 51/51 suspend test), the change still makes sense. >> >> What I had in mind when writing those patches was to remove the limitations >> coming from those functions usage, even more since they been marked has >> deprecated. >> >> I agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Sender: rtc-linux@googlegroups.com Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com. [2607:f8b0:400d:c09::232]) by gmr-mx.google.com with ESMTPS id w77si758917ywg.10.2017.06.21.02.14.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 02:14:35 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id d14so77220656qkb.1 for ; Wed, 21 Jun 2017 02:14:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170620220805.GA11195@amd> References: <1497951359-13334-1-git-send-email-benjamin.gaignard@linaro.org> <20170620100348.zh4ygvjjgnhxvmvl@piout.net> <20170620121011.GA13221@amd> <20170620122400.sm7qqvwyj6cuzarw@piout.net> <20170620132620.GA16881@amd> <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD@SW-EX-MBX02.diasemi.com> <20170620134458.GA10104@amd> <20170620134827.ubvzhh25klaotupv@piout.net> <20170620220805.GA11195@amd> From: Benjamin Gaignard Date: Wed, 21 Jun 2017 11:14:34 +0200 Message-ID: Subject: [rtc-linux] Re: [PATCH 00/51] rtc: stop using rtc deprecated functions To: Pavel Machek Cc: Alexandre Belloni , Steve Twiss , "linaro-kernel@lists.linaro.org" , "adi-buildroot-devel@lists.sourceforge.net" , Alessandro Zummo , Gregory Clement , Ingo Molnar , Jason Cooper , John Stultz , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Linus Walleij , Michael Chan , "netdev@vger.kernel.org" , "rtc-linux@googlegroups.com" , Sebastian Hesselbarth , Support Opensource , Thomas Gleixner , "x86@kernel.org" , Baruch Siach , Hans Ulli Kroll , Vladimir Zapolskiy , Sylvain Lemieux , Barry Song , Maxime Ripard , Chen-Yu Tsai , Thierry Reding , Jonathan Hunter , "linux-tegra@vger.kernel.org" , "patches@opensource.wolfsonmicro.com" , "Rafael J. Wysocki" , Len Brown , "linux-pm@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: , 2017-06-21 0:08 GMT+02:00 Pavel Machek : > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> Yes, that's argument against changing rtc _drivers_ for hardware that >> >> can not do better than 32bit. For generic code (such as 44/51 sysfs, >> >> 51/51 suspend test), the change still makes sense. >> >> What I had in mind when writing those patches was to remove the limitations >> coming from those functions usage, even more since they been marked has >> deprecated. >> >> I agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: benjamin.gaignard@linaro.org (Benjamin Gaignard) Date: Wed, 21 Jun 2017 11:14:34 +0200 Subject: [PATCH 00/51] rtc: stop using rtc deprecated functions In-Reply-To: <20170620220805.GA11195@amd> References: <1497951359-13334-1-git-send-email-benjamin.gaignard@linaro.org> <20170620100348.zh4ygvjjgnhxvmvl@piout.net> <20170620121011.GA13221@amd> <20170620122400.sm7qqvwyj6cuzarw@piout.net> <20170620132620.GA16881@amd> <6ED8E3B22081A4459DAC7699F3695FB7018CD96FCD@SW-EX-MBX02.diasemi.com> <20170620134458.GA10104@amd> <20170620134827.ubvzhh25klaotupv@piout.net> <20170620220805.GA11195@amd> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 2017-06-21 0:08 GMT+02:00 Pavel Machek : > Hi! > >> >> > This is it. >> >> > https://patchwork.kernel.org/patch/6219401/ >> >> >> >> Thanks. >> >> >> >> Yes, that's argument against changing rtc _drivers_ for hardware that >> >> can not do better than 32bit. For generic code (such as 44/51 sysfs, >> >> 51/51 suspend test), the change still makes sense. >> >> What I had in mind when writing those patches was to remove the limitations >> coming from those functions usage, even more since they been marked has >> deprecated. >> >> I agree that will change nothing of hardware limitation but at least >> the limit will >> not come from the framework. > >> > Yes, we agree on that but I won't cherry pick working patches from a 51 >> > patches series. > > Well, it would be actually nice for you to do the cherry > picking. That's something maintainers do, because it is hard for > contributors to guess maintainer's taste. > > Anyway, it looks like someone should go through all the RTC drivers, > and document their limitations of each driver (date in future when > hardware ceases to be useful). If Benjamin has time to do that, I > guess that removes all the objections to the series. Without the datasheet I can check in driver code what they do in read/set time functions to understand their limitations. All drivers using BCD like system or spliting day and time should be fixed. I can do a subset of my patches including those driver + the acked ones. Alexandre does that sound reasonable for you ? > Regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html