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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 25 Jul 2023 23:02:37 +0200
From:   Christophe JAILLET <christophe.jaillet@...adoo.fr>
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, henrys@...icom-usa.com, wenw@...icom-usa.com
Subject: Re: [PATCH] Add Silicom Platform Driver

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()?

> +		if (IS_ERR_OR_NULL(led)) {

if (!led)
is enough.

> +			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)

> +			return -ENOMEM;
> +		}
> +		memcpy(led, &mc_leds[i], sizeof(*led));
> +
> +		led->subled_info = devm_kzalloc(dev, led->num_colors * sizeof(struct mc_subled),
> +						GFP_KERNEL);

Maybe even devm_kmemdup()?

> +		if (IS_ERR_OR_NULL(led->subled_info)) {

if (!led->subled_info)
is enough.

> +			dev_err(dev, "Failed to alloc subled_info[%d]: %ld\n",
> +				i, PTR_ERR(led->subled_info));

This kind of message is useless and should be removed (checkpatch should 
warn about it)

> +			return -ENOMEM;
> +		}
> +		memcpy(led->subled_info, mc_leds[i].subled_info,
> +			led->num_colors * sizeof(struct mc_subled));
> +
> +		err = devm_led_classdev_multicolor_register(dev, led);
> +		if (err) {
> +			dev_err(dev, "Failed to register[%d]: %d\n", i, err);
> +			return err;
> +		}
> +	}
> +
> +	return 0;
> +}

[...]