[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D1CB21235@AcuExch.aculab.com>
Date: Fri, 17 Apr 2015 15:14:18 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Christophe Leroy' <christophe.leroy@....fr>,
Kim Phillips <kim.phillips@...escale.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
David S Miller <davem@...emloft.net>
CC: "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
Subject: RE: [PATCH v3 03/17] crypto: talitos - talitos_ptr renamed ptr for
more lisibility
From: Christophe Leroy
> Linux CodyingStyle recommends to use short variables for local
> variables. ptr is just good enough for those 3 lines functions.
> It helps keep single lines shorter than 80 characters.
...
> -static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t dma_addr)
> +static void to_talitos_ptr(struct talitos_ptr *ptr, dma_addr_t dma_addr)
> {
> - talitos_ptr->ptr = cpu_to_be32(lower_32_bits(dma_addr));
> - talitos_ptr->eptr = upper_32_bits(dma_addr);
> + ptr->ptr = cpu_to_be32(lower_32_bits(dma_addr));
> + ptr->eptr = upper_32_bits(dma_addr);
> }
...
Maybe, but 'ptr' isn't a good choice.
David
Powered by blists - more mailing lists