Message ID | 20230117172450.2938962-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1888775wrn; Tue, 17 Jan 2023 09:36:42 -0800 (PST) X-Google-Smtp-Source: AMrXdXs9cnWdwPJXKSG5LTmBC2Kw92o2VBuhcxT3FwXzZMz14tYnVUsjE3qyeyPpT54HFt5Chmt/ X-Received: by 2002:a05:6a00:856:b0:57c:2ab7:2c0b with SMTP id q22-20020a056a00085600b0057c2ab72c0bmr4641562pfk.28.1673977001994; Tue, 17 Jan 2023 09:36:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673977001; cv=none; d=google.com; s=arc-20160816; b=ZovjN+AtZ8bPBL4C3b8F4wtWsfo5uNtN7Tw5fInEIv3P+7LMiSt49d31eWBveMdvf/ i9xIMDjUzWxAT094XORdWX34ZXzVbTnh2aFdKaQgJeSzei/uuo8aUiQdjwdKA+ncEzxr 0YQd01jLtKl6Uq3fZwjDHOQPlQa+iH7a6hHCydyNHKQhLDYYI36C4m0pqbXJByL9dXKr uzU07sFRoePIwgAt5iGg1V0pBWR0UWc0QACT5Nw0wWXAtZvn2Ltkqyvtb0v4z7gpzgPt B/fBa64kWNP8yZrNw+zz6xHRQ6FjcI10yIKK7LulQbu/QO85/0UcpXwJ1RGMgoI/PcSy BHbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=AY/ju9t638N2+gkveEOvOx9QPABcahu+4u472Egc83g=; b=UC8KIdqjbVvW5+DmuvzQ1aYiWC9rP0TQH/fa/nHLxxrbwA29oqv7qkCudqMpVjFSGu 9XQmhyPKtlGxRavyGHbjLAFM1zL1WWAfqXSg4g30l+iXTOeBbUWsdyTqb236tgZTZ2iG wWcI1PJzJizwjog1B5cspR+90WfennJKDyhYIeLKE4dC4X9AnUxw/06SIvYa0hYZHk/5 22JxuqpSpkj2z4letuw0M04Yf1RG01hcP0SvM0waI9fc6FX43cB3zNQkXCB/TByTfBaq c6P1xK6TcHj7005Wz0OEF/z3k7rw8+aBdutG5ACATzpr7itoAMFWZFHcO147CENycgwc 8abQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nnCHEsqn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h16-20020a056a00231000b0056c882d3d06si35928716pfh.199.2023.01.17.09.36.29; Tue, 17 Jan 2023 09:36:41 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nnCHEsqn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232296AbjAQR0O (ORCPT <rfc822;pfffrao@gmail.com> + 99 others); Tue, 17 Jan 2023 12:26:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230147AbjAQRZe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 17 Jan 2023 12:25:34 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32B6046706; Tue, 17 Jan 2023 09:24:57 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C5BD6B8166E; Tue, 17 Jan 2023 17:24:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1BF1C433F0; Tue, 17 Jan 2023 17:24:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673976294; bh=KC6Cqdox5PMT4Fg/LqX4+EbIIxzPEvcJfLC8UsQ29qQ=; h=From:To:Cc:Subject:Date:From; b=nnCHEsqnLTKVK0s2IzoHZ1KqwB/vrMDGIYRPqOp+liW2QDONQWlvWr7QX3K1dT5q6 JDLAGl9sAdNNM/nx2X+CAdLuhTyc35r5uUsFhfqtkDgcv+S6s3PXM0nNZ6zCyfVxCF TLTF+tyJqxZKNTPtQfWghB7rjmurg/g/CreZUkRa62PFT7tA5Uk3rpr2iwSA5QwxoM tohtfWoqcio12ZeOGfb0bu6nJNtuxutut0mPGtuTjuo5VnPwkWj1pdd3vA1Ox2ELnJ m41soeFDoZZ2hEzbgZw828LjtVXb7dMpY8351sBJKKyszX3OYtXijswjE5sn55Wcl8 AGWhH3lcUYvBA== From: Arnd Bergmann <arnd@kernel.org> To: Vincent Shih <vincent.sunplus@gmail.com>, Alessandro Zummo <a.zummo@towertech.it>, Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Arnd Bergmann <arnd@arndb.de>, linux-rtc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] rtc: sunplus: fix format string for printing resource Date: Tue, 17 Jan 2023 18:24:44 +0100 Message-Id: <20230117172450.2938962-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755292108598346499?= X-GMAIL-MSGID: =?utf-8?q?1755292108598346499?= |
Series |
rtc: sunplus: fix format string for printing resource
|
|
Commit Message
Arnd Bergmann
Jan. 17, 2023, 5:24 p.m. UTC
From: Arnd Bergmann <arnd@arndb.de> On 32-bit architectures with 64-bit resource_size_t, sp_rtc_probe() causes a compiler warning: drivers/rtc/rtc-sunplus.c: In function 'sp_rtc_probe': drivers/rtc/rtc-sunplus.c:243:33: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] 243 | dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The best way to print a resource is the special %pR format string, and similarly to print a pointer we can use %p and avoid the cast. Fixes: fad6cbe9b2b4 ("rtc: Add driver for RTC in Sunplus SP7021") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/rtc/rtc-sunplus.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On 17/01/2023 18:24:44+0100, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > On 32-bit architectures with 64-bit resource_size_t, sp_rtc_probe() > causes a compiler warning: > > drivers/rtc/rtc-sunplus.c: In function 'sp_rtc_probe': > drivers/rtc/rtc-sunplus.c:243:33: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] > 243 | dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The best way to print a resource is the special %pR format string, > and similarly to print a pointer we can use %p and avoid the cast. > I got this one this morning, which one is more correct? :) https://lore.kernel.org/all/20230117054232.24023-1-rdunlap@infradead.org/ > Fixes: fad6cbe9b2b4 ("rtc: Add driver for RTC in Sunplus SP7021") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/rtc/rtc-sunplus.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/rtc/rtc-sunplus.c b/drivers/rtc/rtc-sunplus.c > index e8e2ab1103fc..4b578e4d44f6 100644 > --- a/drivers/rtc/rtc-sunplus.c > +++ b/drivers/rtc/rtc-sunplus.c > @@ -240,8 +240,8 @@ static int sp_rtc_probe(struct platform_device *plat_dev) > if (IS_ERR(sp_rtc->reg_base)) > return dev_err_probe(&plat_dev->dev, PTR_ERR(sp_rtc->reg_base), > "%s devm_ioremap_resource fail\n", RTC_REG_NAME); > - dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", > - sp_rtc->res->start, (unsigned long)sp_rtc->reg_base); > + dev_dbg(&plat_dev->dev, "res = %pR, reg_base = %p\n", > + sp_rtc->res, sp_rtc->reg_base); > > sp_rtc->irq = platform_get_irq(plat_dev, 0); > if (sp_rtc->irq < 0) > -- > 2.39.0 >
On 1/17/23 09:55, Alexandre Belloni wrote: > On 17/01/2023 18:24:44+0100, Arnd Bergmann wrote: >> From: Arnd Bergmann <arnd@arndb.de> >> >> On 32-bit architectures with 64-bit resource_size_t, sp_rtc_probe() >> causes a compiler warning: >> >> drivers/rtc/rtc-sunplus.c: In function 'sp_rtc_probe': >> drivers/rtc/rtc-sunplus.c:243:33: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] >> 243 | dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> The best way to print a resource is the special %pR format string, >> and similarly to print a pointer we can use %p and avoid the cast. >> > > I got this one this morning, which one is more correct? :) > https://lore.kernel.org/all/20230117054232.24023-1-rdunlap@infradead.org/ I prefer my handling of res->start and Arnd's no-cast handling of reg_base. IMO using "%pR" prints too much info, but that's more up to the file's author or maintainer... How's that? :) >> Fixes: fad6cbe9b2b4 ("rtc: Add driver for RTC in Sunplus SP7021") >> Signed-off-by: Arnd Bergmann <arnd@arndb.de> >> --- >> drivers/rtc/rtc-sunplus.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/rtc/rtc-sunplus.c b/drivers/rtc/rtc-sunplus.c >> index e8e2ab1103fc..4b578e4d44f6 100644 >> --- a/drivers/rtc/rtc-sunplus.c >> +++ b/drivers/rtc/rtc-sunplus.c >> @@ -240,8 +240,8 @@ static int sp_rtc_probe(struct platform_device *plat_dev) >> if (IS_ERR(sp_rtc->reg_base)) >> return dev_err_probe(&plat_dev->dev, PTR_ERR(sp_rtc->reg_base), >> "%s devm_ioremap_resource fail\n", RTC_REG_NAME); >> - dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", >> - sp_rtc->res->start, (unsigned long)sp_rtc->reg_base); >> + dev_dbg(&plat_dev->dev, "res = %pR, reg_base = %p\n", >> + sp_rtc->res, sp_rtc->reg_base); >> >> sp_rtc->irq = platform_get_irq(plat_dev, 0); >> if (sp_rtc->irq < 0) >> -- >> 2.39.0 >> >
On Tue, Jan 17, 2023, at 19:24, Randy Dunlap wrote: > On 1/17/23 09:55, Alexandre Belloni wrote: >> On 17/01/2023 18:24:44+0100, Arnd Bergmann wrote: >>> From: Arnd Bergmann <arnd@arndb.de> >>> >>> On 32-bit architectures with 64-bit resource_size_t, sp_rtc_probe() >>> causes a compiler warning: >>> >>> drivers/rtc/rtc-sunplus.c: In function 'sp_rtc_probe': >>> drivers/rtc/rtc-sunplus.c:243:33: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] >>> 243 | dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", >>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> The best way to print a resource is the special %pR format string, >>> and similarly to print a pointer we can use %p and avoid the cast. >>> >> >> I got this one this morning, which one is more correct? :) >> https://lore.kernel.org/all/20230117054232.24023-1-rdunlap@infradead.org/ Both are equally correct, it's just a preference. > I prefer my handling of res->start and Arnd's no-cast handling of reg_base. > IMO using "%pR" prints too much info, but that's more up to the file's author > or maintainer... Right, I could have equally well picked the %pap version, and just went for brevity in the source. It's only pr_debug(), so very few users are going to actually see the output. Arnd
On 1/17/23 11:36, Arnd Bergmann wrote: > On Tue, Jan 17, 2023, at 19:24, Randy Dunlap wrote: >> On 1/17/23 09:55, Alexandre Belloni wrote: >>> On 17/01/2023 18:24:44+0100, Arnd Bergmann wrote: >>>> From: Arnd Bergmann <arnd@arndb.de> >>>> >>>> On 32-bit architectures with 64-bit resource_size_t, sp_rtc_probe() >>>> causes a compiler warning: >>>> >>>> drivers/rtc/rtc-sunplus.c: In function 'sp_rtc_probe': >>>> drivers/rtc/rtc-sunplus.c:243:33: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] >>>> 243 | dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", >>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >>>> The best way to print a resource is the special %pR format string, >>>> and similarly to print a pointer we can use %p and avoid the cast. >>>> >>> >>> I got this one this morning, which one is more correct? :) >>> https://lore.kernel.org/all/20230117054232.24023-1-rdunlap@infradead.org/ > > Both are equally correct, it's just a preference. > >> I prefer my handling of res->start and Arnd's no-cast handling of reg_base. >> IMO using "%pR" prints too much info, but that's more up to the file's author >> or maintainer... > > Right, I could have equally well picked the %pap version, and just > went for brevity in the source. It's only pr_debug(), so very few > users are going to actually see the output. Alexandre, sounds like you should just go with Arnd's patch.
On Tue, 17 Jan 2023 18:24:44 +0100, Arnd Bergmann wrote: > On 32-bit architectures with 64-bit resource_size_t, sp_rtc_probe() > causes a compiler warning: > > drivers/rtc/rtc-sunplus.c: In function 'sp_rtc_probe': > drivers/rtc/rtc-sunplus.c:243:33: error: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'resource_size_t' {aka 'long long unsigned int'} [-Werror=format=] > 243 | dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > [...] Applied, thanks! [1/1] rtc: sunplus: fix format string for printing resource commit: 08279468a294d8c996a657ecc9e51bd5c084c75d
diff --git a/drivers/rtc/rtc-sunplus.c b/drivers/rtc/rtc-sunplus.c index e8e2ab1103fc..4b578e4d44f6 100644 --- a/drivers/rtc/rtc-sunplus.c +++ b/drivers/rtc/rtc-sunplus.c @@ -240,8 +240,8 @@ static int sp_rtc_probe(struct platform_device *plat_dev) if (IS_ERR(sp_rtc->reg_base)) return dev_err_probe(&plat_dev->dev, PTR_ERR(sp_rtc->reg_base), "%s devm_ioremap_resource fail\n", RTC_REG_NAME); - dev_dbg(&plat_dev->dev, "res = 0x%x, reg_base = 0x%lx\n", - sp_rtc->res->start, (unsigned long)sp_rtc->reg_base); + dev_dbg(&plat_dev->dev, "res = %pR, reg_base = %p\n", + sp_rtc->res, sp_rtc->reg_base); sp_rtc->irq = platform_get_irq(plat_dev, 0); if (sp_rtc->irq < 0)