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: <bb2702c4-848a-4e0e-6381-66af079a7c13@intel.com>
Date:	Fri, 10 Jun 2016 15:00:17 +0300
From:	Crestez Dan Leonard <leonard.crestez@...el.com>
To:	Wolfram Sang <wsa@...-dreams.de>
Cc:	linux-acpi@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>, linux-i2c@...r.kernel.org,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	linux-kernel@...r.kernel.org,
	Irina Tirdea <irina.tirdea@...el.com>,
	Octavian Purdila <octavian.purdila@...el.com>,
	Daniel Baluta <daniel.baluta@...el.com>
Subject: Re: [RFC v2 2/2] i2c: Pass i2c_device_id to probe func when using DT
 ids through ACPI

On 06/10/2016 10:04 AM, Wolfram Sang wrote:
> On Thu, Jun 09, 2016 at 04:06:03PM +0300, Crestez Dan Leonard wrote:
>> When devices are instatiated through devicetree the i2c_client->name is
>> set to the compatible string with company name stripped out. This is
>> then matched to the i2c_device_id table to pass the device_id to the
>> probe function. This id parameter is used by some device drivers to
>> differentiate between model numbers.
>>
>> When using ACPI this id parameter is NULL and the driver usually needs
>> to do ACPI-specific differentiation.
>>
>> This patch attempts to find a valid i2c_device_id when using ACPI with
>> DT-like compatible strings.
> 
> Note that this DT behaviour is about to be dropped to match I2C with
> the "generic" behaviour".
> 
> https://lkml.org/lkml/2016/5/4/534

Looking at that series it seems that the intention is to eventually
remove the i2c_device_id argument from probe completely? That would
cause a lot of code churn. It would also require every driver that needs
to differentiate between models to pretty much duplicate the matching
logic performed by the core.

This does seem better than receiving an i2c_device_id parameter argument
which may or may not be NULL. Still, in order to support multiple models
using ACPI DT ids every driver would have to attempt some sort of
acpi_of_match_device, right?

Have you considered adding .probe_of(dev, of_device_id) and
.probe_acpi(dev, acpi_device_id) instead, with arguments which are
always guaranteed to be non-NULL? The main advantage would be that
drivers don't need to do their own matching and all rules are only
present ever in the core. Then ACPI with DT ids could be made to "just
work" without per-driver support.

-- 
Regards,
Leonard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ