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]
Date:   Thu, 25 Jun 2020 16:21:39 +0300
From:   Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To:     Ricardo Ribalda <ribalda@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
        Wolfram Sang <wsa@...nel.org>
Subject: Re: [PATCH v2] i2c: designware: platdrv: Set class based on dmi

On 6/24/20 2:25 PM, Ricardo Ribalda wrote:
> Current AMD's zen-based APUs use this core for some of its i2c-buses.
> 
> With this patch we re-enable autodetection of hwmon-alike devices, so
> lm-sensors will be able to work automatically.
> 
> It does not affect the boot-time of embedded devices, as the class is
> set based on the dmi information.
> 
> Signed-off-by: Ricardo Ribalda <ribalda@...nel.org>
> ---
> v2:
> Changes by Andy Shevchenko <andriy.shevchenko@...ux.intel.com>:
>   - CodeStyle
> Changes by kernel test robot <lkp@...el.com>
>   - Include dmi header to fix build error on arc
>   - check if dmi_get_system_info returned NULL
>   drivers/i2c/busses/i2c-designware-platdrv.c | 16 +++++++++++++++-
>   1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
> index c2efaaaac252..5892fdba9c25 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -12,6 +12,7 @@
>   #include <linux/clk-provider.h>
>   #include <linux/clk.h>
>   #include <linux/delay.h>
> +#include <linux/dmi.h>
>   #include <linux/err.h>
>   #include <linux/errno.h>
>   #include <linux/i2c.h>
> @@ -173,6 +174,19 @@ static void dw_i2c_plat_pm_cleanup(struct dw_i2c_dev *dev)
>   		pm_runtime_put_noidle(dev->dev);
>   }
>   
> +static bool dw_i2c_hwmon_bus(void)
> +{
> +	const char *product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
> +
> +	if (!product_name)
> +		return false;
> +
> +	if (strstr(product_name, "QT5222"))
> +		return true;
> +
> +	return false;
> +}
> +

I'm not too familiar with the DMI stuff but is the more usual way to 
have struct dmi_system_id table and match it with dmi_check_system()? 
Perhaps scales better than individual dmi_get_system_info() and string 
comparison calls.

Andy and I were pondering offline is there any info in ACPI table that 
tells which bus have these sensors or can it be hardcoded with the DMI 
match so that there is no need probe all buses for these sensors on that 
product. But that can be another optimization patch I guess.

-- 
Jarkko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ