linux-kernel - Re: [PATCH v2] hwmon: (tmp401) Add of_match

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]

Date:   Mon, 2 May 2022 06:57:50 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Camel Guo <camel.guo@...s.com>, Jean Delvare <jdelvare@...e.com>
Cc:     linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel@...s.com
Subject: Re: [PATCH v2] hwmon: (tmp401) Add of_match_table

On 5/2/22 02:19, Camel Guo wrote:
> When tmp401 is built as kernel module, it won't be automatically loaded
> even through there is a device node in the devicetree. e.g:
>      i2c {
>        #address-cells = <1>;
>        #size-cells = <0>;
> 
>        sensor@4c {
>          compatible = "ti,tmp401";
>          reg = <0x4c>;
>        };
>      };
> In order to make sure it is loaded automatically, this commit adds
> of_match_table for tmp401.
> 

As mentioned before, historically i2c devices would instantiate based
on the i2c match table. You are claiming that this is no longer the case.
The above is no evidence; that would require a log output on an affected
system showing that the sensors are not or no longer longer instantiated.

I am not absolutely opposed to adding the nodes, but the explanation
needs to match reality. If you can not provide evidence from an actual
boot log, I'll have to implement a tmp401 device model in qemu and test
myself. That will take a while.

Guenter