Re: [PATCH v4 1/3] mfd: intel_soc_pmic: Core driver

[Zhu, Lejun]

On 2014/5/30 16:08, Lee Jones wrote:
>>>> +static int intel_soc_pmic_find_gpio_irq(struct device *dev)
>>>> +{
>>>> +	struct gpio_desc *desc;
>>>> +	int irq;
>>>> +
>>>> +	desc = devm_gpiod_get_index(dev, KBUILD_MODNAME, 0);
>>>
>>> What does "KBUILD_MODNAME" translate to?
>>
>> It translates into "intel_soc_pmic".
> 
> Can you just put that instead?

Sure. I'll fix it.

(...)

>>>> +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.

So for the driver to work for the i2c code both today and in the future,
I think it's best to keep the driver_data populated in both tables. What
do you think?

Best Regards
Lejun

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