Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4082544ybl; Mon, 26 Aug 2019 05:19:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqwEDZfalH7OJgpRYa2sKsX1zCBROUmCKbnUg53mEethvV/WLvT46CCSo7okrQ0YrTCwWIg1 X-Received: by 2002:a17:90a:bb01:: with SMTP id u1mr19164988pjr.92.1566821968934; Mon, 26 Aug 2019 05:19:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566821968; cv=none; d=google.com; s=arc-20160816; b=piIk6UKk5tUmSmeWJGxb/ilqSJ0BsewnZzX0gGsjqFBphPYvA8elkc6e5qNQgCRh0X ad5lchwUdQn25WTuBmYS6be0BMhqcnKPeqfwiSTLlz2r+fpQtMKlI53h01r7j5OTF6wK IIqMhVFyIQhX1ZDJy2hw4PnMY92cRevJwa1gFeSCZRByHpZuuDEUAX+xq+f5zkr8/scc mjIIXPdS943suLv9Hvtpooqu/zfS81rt/KqbzeDFwWFCbDeMPpRCjVM+0zR4IT16Va+Q wgZP3Av4Cysh+aNSmZ/USCK0WtHqR4H60jcEA3Cr9R2juJtCMLY6O0A17dzUosSlc1Cz XYRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=kEHlk+FORbySlRmLzZg8jKVvOXL8pgH/F+DBHVsYZmQ=; b=fA8vP2F+764KFZ8PnvWFZuDkV6U1XKZSOJx6Qob516AWpltajwXePQ5FM+YyXYSfTE lctLe/Z3/T/4dVt+8txepPn0DpVwWus5NiWJSFT28LyKctqEASyiIn81FbRWOOoRGBLg PKfF106v0gk67CG2enGJBICVTjREpV+icionGlnZEUgbHc4tEYR708oXYhw5bB0+2aPS bj9pqXCrYp8UoH604OHnYzi5zZQZRfl+WGoFikvCnukCYYzKJP771omN9gevcycKO200 W4NoBpTbgXCZLbzag2iXTs9SYJw3D9GvaPBPeArwxzMXAXVDfGwmdQYJXWSDjPmSZpYS I4wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b74si10055608pfb.281.2019.08.26.05.19.12; Mon, 26 Aug 2019 05:19:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730599AbfHZKGy (ORCPT + 99 others); Mon, 26 Aug 2019 06:06:54 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:47401 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729563AbfHZKGx (ORCPT ); Mon, 26 Aug 2019 06:06:53 -0400 X-Originating-IP: 86.207.98.53 Received: from localhost (aclermont-ferrand-651-1-259-53.w86-207.abo.wanadoo.fr [86.207.98.53]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 0A522E0002; Mon, 26 Aug 2019 10:06:50 +0000 (UTC) Date: Mon, 26 Aug 2019 12:06:50 +0200 From: Alexandre Belloni To: Biwen Li Cc: Nandor Han , Leo Li , Mark Brown , "a.zummo@towertech.it" , "linux-rtc@vger.kernel.org" , lkml Subject: Re: [EXT] Re: [v2] rtc: pcf85363/pcf85263: fix error that failed to run hwclock -w Message-ID: <20190826100650.GB21713@piout.net> References: <20190816024636.34738-1-biwen.li@nxp.com> <20190816080417.GB3545@piout.net> <20190816162825.GE3545@piout.net> <21f417e3-db50-5930-ddc9-eed54f5d5893@vaisala.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 26/08/2019 09:49:49+0000, Biwen Li wrote: > > > > On 8/26/19 7:29 AM, Biwen Li wrote: > > >> > > >> On 8/16/19 10:40 PM, Li Yang wrote: > > >>> On Fri, Aug 16, 2019 at 11:30 AM Alexandre Belloni > > >>> wrote: > > >>>> > > >>>> On 16/08/2019 10:50:49-0500, Li Yang wrote: > > >>>>> On Fri, Aug 16, 2019 at 3:05 AM Alexandre Belloni > > >>>>> wrote: > > >>>>>> > > >>>>>> On 16/08/2019 10:46:36+0800, Biwen Li wrote: > > >>>>>>> Issue: > > >>>>>>> - # hwclock -w > > >>>>>>> hwclock: RTC_SET_TIME: Invalid argument > > >>>>>>> > > >>>>>>> Why: > > >>>>>>> - Relative patch: > > >> https://lkml.org > > >> %2Flkml%2F2019%2F4%2F3%2F55&data=02%7C01%7Cbiwen.li%40n > > xp. > > >> > > com%7Cff8cebc3f1034ae3fa9608d725ff9e5e%7C686ea1d3bc2b4c6fa92cd99 > > >> > > c5c301635%7C0%7C0%7C637019652111923736&sdata=spY6e22YOkOF > > >> 3%2BF7crSM0M6xPmOhgULDqMZLQw%2BAmdI%3D&reserved=0 , > > this patch > > >>>>>>> will always check for unwritable registers, it will compare reg > > >>>>>>> with max_register in regmap_writeable. > > >>>>>>> > > >>>>>>> - In drivers/rtc/rtc-pcf85363.c, CTRL_STOP_EN is 0x2e, but > > >> DT_100THS > > >>>>>>> is 0, max_regiter is 0x2f, then reg will be equal to 0x30, > > >>>>>>> '0x30 < 0x2f' is false,so regmap_writeable will return false. > > >>>>>>> > > >>>>>>> - Root cause: the buf[] was written to a wrong place in the file > > >>>>>>> drivers/rtc/rtc-pcf85363.c > > >>>>>>> > > >>>>>> > > >>>>>> This is not true, the RTC wraps the register accesses properly > > >>>>>> and this > > >>>>> > > >>>>> This performance hack probably deserve some explanation in the > > >>>>> code comment. :) > > >>>>> > > >>>>>> is probably something that should be handled by regmap_writable. > > >>>>> > > >>>>> The address wrapping is specific to this RTC chip. Is it also > > >>>>> commonly used by other I2C devices? I'm not sure if > > >>>>> regmap_writable should handle the wrapping case if it is too special. > > >>>>> > > >>>> > > >>>> Most of the i2c RTCs do address wrapping which is sometimes the > > >>>> only way to properly set the time. > > >>> > > >>> Adding Mark and Nandor to the loop. > > >>> > > >>> Regards, > > >>> Leo > > >>> > > >> > > >> Hi, > > >> `regmap` provides couple of ways to validate the registers: > > >> max_register, callback function and write table. All of these are > > >> optional, so it gives you the freedom to customize it as needed. > > >> > > >> In this situation probably you could: > > >> 1. Avoid using the wrapping feature of pcf85363 (you can just > > >> provide separate calls for stop, reset and time confguration). In > > >> this way the `max_register` validation method will work fine. > > > Yes, I use this way. Path as follows: > > > Stop and reset - > set time > stop > > > > > > > Some of the concerns regarding this method was that it might not be precise > > enough. That because you need 2 I2C operations (one for stop and one for time > > configuration). Not sure about your case if this is a problem or not. > Ok, got it, thanks. To be clear, for this RTC it is fine to separate both writes. Want I want is a corrected commit message with a proper reference to 8b9f9d4dc511309918c4f6793bae7387c0c638af instead of a link to lkml.org and a proper explanation. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com