linux-kernel - Re: [PATCH] Add Silicom Platform Driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f400750d-e53c-65f8-210f-aa127d8f6beb@roeck-us.net>
Date:   Fri, 28 Jul 2023 10:52:59 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Huibin Shi <henrys@...icom-usa.com>,
        Henry Shi <henryshi2018@...il.com>,
        "hbshi69@...mail.com" <hbshi69@...mail.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "hdegoede@...hat.com" <hdegoede@...hat.com>,
        "markgross@...nel.org" <markgross@...nel.org>,
        "jdelvare@...e.com" <jdelvare@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>
Cc:     "hb_shi2003@...oo.com" <hb_shi2003@...oo.com>,
        Wen Wang <wenw@...icom-usa.com>
Subject: Re: [PATCH] Add Silicom Platform Driver

On 7/28/23 09:47, Christophe JAILLET wrote:
> Le 28/07/2023 à 14:59, Huibin Shi a écrit :
>> Christophe,
>>
>> Thanks for the comments. See my comments below.
>>
>> Updated patch will be sent out later after review comments from other reviewers are addressed.
>>
>> Henry
>> -----Original Message-----
>> From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
>> Sent: Tuesday, July 25, 2023 5:03 PM
>> To: Henry Shi <henryshi2018@...il.com>; hbshi69@...mail.com; tglx@...utronix.de; mingo@...hat.com; bp@...en8.de; dave.hansen@...ux.intel.com; x86@...nel.org; hpa@...or.com; hdegoede@...hat.com; markgross@...nel.org; jdelvare@...e.com; linux@...ck-us.net; linux-kernel@...r.kernel.org; platform-driver-x86@...r.kernel.org; linux-hwmon@...r.kernel.org
>> Cc: hb_shi2003@...oo.com; Huibin Shi <henrys@...icom-usa.com>; Wen Wang <wenw@...icom-usa.com>
>> Subject: Re: [PATCH] Add Silicom Platform Driver
>>
>> Caution: This is an external email. Please take care when clicking links or opening attachments.
>>
>>
>> Le 18/07/2023 à 18:01, Henry Shi a écrit :
>>> The Silicom platform (silicom-platform) Linux driver for Swisscom
>>> Business Box (Swisscom BB) as well as Cordoba family products is a
>>> software solution designed to facilitate the efficient management and
>>> control of devices through the integration of various Linux
>>> frameworks. This platform driver provides seamless support for device
>>> management via the Linux LED framework, GPIO framework, Hardware
>>> Monitoring (HWMON), and device attributes. The Silicom platform
>>> driver's compatibility with these Linux frameworks allows applications
>>> to access and control Cordoba family devices using existing software
>>> that is compatible with these frameworks. This compatibility
>>> simplifies the development process, reduces dependencies on
>>> proprietary solutions, and promotes interoperability with other
>>> Linux-based systems and software.
>>>
>>> Signed-off-by: Henry Shi <henryshi2018@...il.com>
>>> ---
>>
>> [...]
>>
>>> +static int __init silicom_mc_leds_register(struct device *dev,
>>> +                                        const struct led_classdev_mc
>>> +*mc_leds) {
>>> +     struct led_classdev_mc *led;
>>> +     int i, err;
>>> +
>>> +     for (i = 0; mc_leds[i].led_cdev.name; i++) {
>>> +             /* allocate and copy data from the init constansts */
>>> +             led = devm_kzalloc(dev, sizeof(struct led_classdev_mc),
>>> + GFP_KERNEL);
>>
>> sizeof(*led) is shorter.
>> Mostly a matter of taste.
>>
>> Maybe even devm_kmemdup()?
>>
>> Henry: thanks. Devm_kmemdup() API requires additional argument that is not necessary of this driver. I prefer devm_kzalloc for now.
> 
> CJ: The only additionnal parameter I can think of are the one of memcpy() ...
> 
>>
>>> +             if (IS_ERR_OR_NULL(led)) {
>>
>> if (!led)
>> is enough.
>>
>> Henry: OK, changed
>>
>>> +                     dev_err(dev, "Failed to alloc
>>> + led_classdev_mc[%d]: %ld\n", i, PTR_ERR(led));
>>
>> This kind of message is useless and should be removed (checkpatch should warn about it)
>>
>> Henry: OK, removed.
>>
>>> +                     return -ENOMEM;
>>> +             }
>>> +             memcpy(led, &mc_leds[i], sizeof(*led));
> 
> ... here.
> 
> devm_kzalloc() + this memcpy() could be done with only devm_kmemdup().
> 
> This is mostly a matter of taste.
> 

I don't think that using (or not using) available API functions should
be a matter of taste, or the next step might be to re-implement memcpy().

Guenter