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] [day] [month] [year] [list]
Message-ID: <a25e62a8-0610-b015-001f-dec9b1600b3b@roeck-us.net>
Date:   Fri, 7 Aug 2020 07:15:35 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Stephen Kitt <steve@....org>
Cc:     Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hwmon/pmbus: use simple i2c probe function

On 8/6/20 11:23 PM, Stephen Kitt wrote:
> On Thu, 6 Aug 2020 14:48:58 -0700, Guenter Roeck <linux@...ck-us.net> wrote:
>> On 8/6/20 1:12 PM, Stephen Kitt wrote:
>>> On Thu, 6 Aug 2020 12:15:55 -0700, Guenter Roeck <linux@...ck-us.net>
>>> wrote:  
>>>> On 8/6/20 9:16 AM, Stephen Kitt wrote:  
> [...]
>>>> Also, I am not convinced that replacements such as
>>>>
>>>> -	{ "ipsps1", 0 },
>>>> +	{ .name = "ipsps1" },
>>>>
>>>> are an improvement. I would suggest to leave that alone for
>>>> consistency (and to make it easier to add more devices to the
>>>> various drivers if that happens in the future).  
>>>
>>> From reading through all the drivers using id_table, it seems to me that
>>> we could do away with driver_data altogether and move all that to
>>> driver-local structures, in many cases covering more than just an id. By
>>> only initialising the elements of the structure that are really needed, I
>>> was hoping to (a) make it more obvious that driver_data isn’t used, and
>>> (b) allow removing it without touching all the code again.
>>>   
>>
>> I don't see it as an improvement to replace a common data structure with
>> per-driver data structures. That sounds too much like "let's re-invent
>> the wheel over and over again". If that is where things are going, I'd
>> rather have it implemented everywhere else first. I am ok with the other
>> changes, but not with this.
> 
> I agree, and I wasn’t intending on encouraging re-inventing the wheel in each
> driver. Let’s focus on probe_new for now...
> 
> What did you mean by “to make it easier to add more devices to the various
> drivers if that happens in the future”? There are already many drivers with
> multiple devices but no driver_data, dropping the explicit driver_data
> initialisation doesn’t necessarily make it harder to add devices, does it?
> 
There is an existing mechanism to identify devices based on the device ID,
should that be necessary. I am not inclined to let people invent a
separate per-driver mechanism unless the kernel community decides that
this is the way to go.

Thanks,
Guenter



Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ