linux-kernel - RE: [PATCH v2] crypto: aspeed: fix format unexpected build warning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <TY2PR06MB3213D3EB56E9B01521D86FC180419@TY2PR06MB3213.apcprd06.prod.outlook.com>
Date:   Wed, 7 Sep 2022 03:09:32 +0000
From:   Neal Liu <neal_liu@...eedtech.com>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Herbert Xu <herbert@...dor.apana.org.au>
CC:     "David S . Miller" <davem@...emloft.net>,
        Joel Stanley <joel@....id.au>,
        Andrew Jeffery <andrew@...id.au>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        BMC-SW <BMC-SW@...eedtech.com>, kernel test robot <lkp@...el.com>
Subject: RE: [PATCH v2] crypto: aspeed: fix format unexpected build warning

> On 9/6/22 19:13, Herbert Xu wrote:
> > On Mon, Sep 05, 2022 at 01:24:49PM +0800, Neal Liu wrote:
> >>
> >> @@ -324,7 +324,7 @@ static int aspeed_hace_ahash_trigger(struct
> aspeed_hace_dev *hace_dev,
> >>  	struct ahash_request *req = hash_engine->req;
> >>  	struct aspeed_sham_reqctx *rctx = ahash_request_ctx(req);
> >>
> >> -	AHASH_DBG(hace_dev, "src_dma:0x%x, digest_dma:0x%x,
> length:0x%x\n",
> >> +	AHASH_DBG(hace_dev, "src_dma:%zu, digest_dma:%zu, length:%zu\n",
> >>  		  hash_engine->src_dma, hash_engine->digest_dma,
> >>  		  hash_engine->src_length);
> >
> > Shouldn't we use %pad instead of %zu for dma_addr_t (you'll also need
> > to pass in a dma_addr_t pointer instead of the value)?
> 
> That sounds correct.
> I only looked at the size_t parts...

True. I'll revise it and send next patch, thanks.