linux-kernel - Re: [PATCH v4 1/3] mfd: intel_soc

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: <53893E20.1060404@linux.intel.com>
Date:	Sat, 31 May 2014 10:27:44 +0800
From:	"Zhu, Lejun" <lejun.zhu@...ux.intel.com>
To:	Lee Jones <lee.jones@...aro.org>
CC:	broonie@...nel.org, sameo@...ux.intel.com,
	linux-kernel@...r.kernel.org, jacob.jun.pan@...ux.intel.com,
	bin.yang@...el.com
Subject: Re: [PATCH v4 1/3] mfd: intel_soc_pmic: Core driver



On 2014/5/30 17:28, Lee Jones wrote:
>>>>>> +static const struct i2c_device_id intel_soc_pmic_i2c_id[] = {
>>>>>> +	{"INT33FD:00", (kernel_ulong_t)&intel_soc_pmic_config_crc},
>>>>>> +	{ }
>>>>>> +};
>>>>>> +MODULE_DEVICE_TABLE(i2c, intel_soc_pmic_i2c_id);
>>>>>> +
>>>>>> +static struct acpi_device_id intel_soc_pmic_acpi_match[] = {
>>>>>> +	{"INT33FD", (kernel_ulong_t)&intel_soc_pmic_config_crc},
>>>>>> +	{ },
>>>>>> +};
>>>>>> +MODULE_DEVICE_TABLE(acpi, intel_soc_pmic_acpi_match);
>>>>>
>>>>> Does ACPI have a match function to extact it's .driver_data attribute?
>>>>>
>>>>> If so, are you using it here? If not, why not?
>>>>>
>>>>
>>>> The ACPI table is used in i2c_device_match(), and the i2c table is used
>>>> in i2c_device_probe(), so the id in the i2c table is actually fed to
>>>> intel_soc_pmic_probe(). But I only found out now that having the i2c
>>>> table alone is enough, because i2c_device_match will fallback to the i2c
>>>> table if there's no ACPI table. So to keep it simple, I'll remove the
>>>> ACPI table completely.
>>>
>>> Actually, can you do it the other way round?  Minimise the i2c table
>>> and populate the ACPI one.  I'm just about to work on a separate
>>> patch-set which deprecates the use of the i2c table on DT and/or ACPI
>>> only registered devices.
>>
>> Current i2c_device_probe will only feed driver_data from i2c_device_id
>> table to intel_soc_pmic_probe(), because it uses i2c_match_id(). So if I
>> remove "&intel_soc_pmic_config_crc" from the i2c table, I will get NULL
>> from id->driver_data until your new patch fixes it.
> 
> Right, which is why I asked if ACPI has a match function - I just
> looked and it does.  So what you need to do is supply a very simple
> i2c_device_id struct (just until my patch lands, then there'll be no
> reason to supply one at all) and use  acpi_match_device() instead of
> using id->driver_data.
> 

Oh I see. You mean calling acpi_match_device() in my own probe(). I'll
change my code to do that in next version.

Best Regards
Lejun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/