linux-kernel - Re: [PATCH] mcp3021: rework for DT support of reference-voltage

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: <20161019012442.GA30552@roeck-us.net>
Date:   Tue, 18 Oct 2016 18:24:42 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Clemens Gruber <clemens.gruber@...ruber.com>
Cc:     linux-hwmon@...r.kernel.org, Jean Delvare <jdelvare@...e.com>,
        devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mcp3021: rework for DT support of reference-voltage

On Wed, Oct 19, 2016 at 12:44:44AM +0200, Clemens Gruber wrote:
> Support setting the reference voltage in the device tree.
> Rework of driver structure, put chip specific data in a separate
> structure and assign it depending on device id from platform data or
> DT match.
> Extend the device documentation and add new documentation for the
> devicetree bindings.
> Also change S_IRUGO to the better readable 0444, which fixes a
> checkpatch warning.
> 
> Signed-off-by: Clemens Gruber <clemens.gruber@...ruber.com>
> ---
>  .../devicetree/bindings/hwmon/mcp3021.txt          |  21 +++

This needs to be a separate patch.

...

> +static int mcp3021_probe(struct i2c_client *client,
> +	const struct i2c_device_id *id);
> +static int mcp3021_remove(struct i2c_client *client);
>  

We are trying hard to get rid of functions declarations like this.
Adding it means that the code is rearranged for no good reason.
Please limit the changes to nececessary changes, and please refrain
from rearranging it and from introducing your personal style.

> -enum chips {
> +enum {

Another indication that you are making changes for no good reason.
You may not like named enums, others do. That doesn't mean you can
change the code to your liking. Please don't do that.

Guenter