linux-kernel - Re: [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019 board revision

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: <fa145f84-4249-44da-57dc-10cfe25dbde3@enpas.org>
Date:   Tue, 13 Aug 2019 11:49:05 +0200
From:   Max Staudt <max@...as.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Linux I2C <linux-i2c@...r.kernel.org>, linux-hwmon@...r.kernel.org,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Jean Delvare <jdelvare@...e.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Linux/m68k <linux-m68k@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Subject: Re: [PATCH v2 2/4] i2c/busses/i2c-icy: Add LTC2990 present on 2019
 board revision

On 08/13/2019 09:03 AM, Geert Uytterhoeven wrote:
> Hi Max,
> 
> On Tue, Aug 13, 2019 at 1:53 AM Max Staudt <max@...as.org> wrote:
>> Since the 2019 a1k.org community re-print of these PCBs sports an
>> LTC2990 hwmon chip as an example use case, let this driver autoprobe
>> for that as well. If it is present, modprobing ltc2990 is sufficient.
>>
>> Signed-off-by: Max Staudt <max@...as.org>
> 
> Thanks for your patch!
> 
>> --- a/drivers/i2c/busses/i2c-icy.c
>> +++ b/drivers/i2c/busses/i2c-icy.c
>> @@ -160,6 +180,8 @@ static void icy_remove(struct zorro_dev *z)
>>  {
>>         struct icy_i2c *i2c = dev_get_drvdata(&z->dev);
>>
>> +       i2c_unregister_device(i2c->client_ltc2990);
> 
> Is this needed?
> In my understanding, i2c_del_adapter() below takes care of that.
It seems to do that in i2c_del_adapter():

  device_for_each_child(&adap->dev, NULL, __unregister_dummy);


However, I'm not sure I'm supposed to do that. I went by Documentation/i2c/instantiating-devices, which in "Method 2" says:

  The driver which instantiated the I2C device is responsible for destroying
  it on cleanup. This is done by calling i2c_unregister_device() on the
  pointer that was earlier returned by i2c_new_device() or
  i2c_new_probed_device().


So, what is preferred and why?


Thanks!

Max