Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: Christian Hohnstaedt <chohnstaedt@innominate.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>, linux-crypto@vger.kernel.org
Subject: Re: IXP4xx: Fix whitespace problems in ixp4xx_crypto.
Date: Tue, 12 Jan 2010 19:09:19 +0100	[thread overview]
Message-ID: <m33a2b19gw.fsf@intrepid.localdomain> (raw)
In-Reply-To: <20100112171159.GI3056@elara.bln.innominate.local> (Christian Hohnstaedt's message of "Tue, 12 Jan 2010 18:12:00 +0100")

Christian Hohnstaedt <chohnstaedt@innominate.com> writes:

>>  static struct npe *npe_c;
>> -static struct dma_pool *buffer_pool = NULL;
>> -static struct dma_pool *ctx_pool = NULL;
>> +static struct dma_pool *buffer_pool;
>> +static struct dma_pool *ctx_pool;
>>  
>> -static struct crypt_ctl *crypt_virt = NULL;
>> +static struct crypt_ctl *crypt_virt;
>
> This is not a whitespace-fix.

Right, that's trivial non-whitespace fix :-)

> The error-path in init_ixp_crypto() depends on them being either NULL
> or correctly allocated.
>
> Or is it guaranteed that static variables are always initially zero ?

Yes, the BSS is cleared at boot (modprobe etc). This simply makes the
on-disk image a bit smaller.

>>  static dma_addr_t crypt_phys;
>>  
>>  static int support_aes = 1;
>
> But this initialization is superflous, since it will be initialized
> before use.

I didn't touch it, but will remove the initialization if it's unneeded,
of course.

>> -	static int idx = 0;
>> +	static int idx;
>
> This static index must be initialized with 0.

It is, same as the crypt_virt and co.

>> -static void free_buf_chain(struct device *dev, struct buffer_desc *buf,u32 phys)
>> +static void free_buf_chain(struct device *dev, struct buffer_desc *buf, u32 phys)
>
> Introduces a line-length > 80.

This limit has been lifted recently :-)

>>  	int num = ARRAY_SIZE(ixp4xx_algos);
>> -	int i,err ;
>> +	int i, err ;
>
> Missed one before the ;

Right.


I will fix/change these, not today but soon. Thanks for looking.
-- 
Krzysztof Halasa

  reply	other threads:[~2010-01-12 18:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-10 15:34 [6 PATCHes] IXP4xx crypto driver fixes Krzysztof Halasa
2010-01-10 17:30 ` Krzysztof Halasa
2010-01-11  9:07   ` Christian Hohnstaedt
2010-01-10 17:32 ` IXP4xx: Fix ixp4xx_crypto sparse warnings Krzysztof Halasa
2010-01-10 17:32 ` IXP4xx: Simplify get_crypt_desc() and get_crypt_desc_emerg() in ixp4xx_crypto Krzysztof Halasa
2010-01-10 17:33 ` IXP4xx: Fix whitespace problems " Krzysztof Halasa
2010-01-12 17:12   ` Christian Hohnstaedt
2010-01-12 18:09     ` Krzysztof Halasa [this message]
2010-01-10 17:37 ` ixp4xx_crypto: Fix possible NULL ptr dereference Krzysztof Halasa
2010-01-11 10:07   ` Christian Hohnstaedt
2010-01-10 17:37 ` ixp4xx_crypto: simplyfy the code a bit Krzysztof Halasa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m33a2b19gw.fsf@intrepid.localdomain \
    --to=khc@pm.waw.pl \
    --cc=chohnstaedt@innominate.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox