[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38c7f603-9170-f5a3-6a47-d6959f3c3137@prevas.dk>
Date: Tue, 8 Dec 2020 22:17:06 +0100
From: Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To: Christophe Leroy <christophe.leroy@...roup.eu>,
Li Yang <leoyang.li@....com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>
Cc: Vladimir Oltean <vladimir.oltean@....com>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, Zhao Qiang <qiang.zhao@....com>
Subject: Re: [PATCH 14/20] ethernet: ucc_geth: don't statically allocate eight
ucc_geth_info
On 08/12/2020 16.13, Christophe Leroy wrote:
>
>
> Le 05/12/2020 à 20:17, Rasmus Villemoes a écrit :
>> @@ -3714,25 +3712,23 @@ static int ucc_geth_probe(struct
>> platform_device* ofdev)
>> if ((ucc_num < 0) || (ucc_num > 7))
>> return -ENODEV;
>> - ug_info = &ugeth_info[ucc_num];
>> - if (ug_info == NULL) {
>> - if (netif_msg_probe(&debug))
>> - pr_err("[%d] Missing additional data!\n", ucc_num);
>> - return -ENODEV;
>> - }
>> + ug_info = kmalloc(sizeof(*ug_info), GFP_KERNEL);
>
> Could we use dev_kmalloc() instead, to avoid the freeing on the wait out
> and the err_free_info: path ?
Perhaps, but I don't think mixing ordinary kmalloc() with devm_ versions
in the same driver is a good idea - IIRC there are at least some rules
to obey if one does that, but I don't remember and can't find what they are.
Rasmus
Powered by blists - more mailing lists