From: "Zhu, Lejun" <lejun.zhu@linux.intel.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: broonie@kernel.org, sameo@linux.intel.com,
linux-kernel@vger.kernel.org, jacob.jun.pan@linux.intel.com,
bin.yang@intel.com
Subject: Re: [PATCH v4 1/3] mfd: intel_soc_pmic: Core driver
Date: Fri, 30 May 2014 17:03:56 +0800 [thread overview]
Message-ID: <5388497C.3000106@linux.intel.com> (raw)
In-Reply-To: <20140530080848.GB2619@lee--X1>
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
next prev parent reply other threads:[~2014-05-30 9:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-29 7:19 [PATCH v4 0/3] mfd: Intel SoC Power Management IC Zhu, Lejun
2014-05-29 7:19 ` [PATCH v4 1/3] mfd: intel_soc_pmic: Core driver Zhu, Lejun
2014-05-29 11:40 ` Lee Jones
2014-05-30 4:58 ` Zhu, Lejun
2014-05-30 8:08 ` Lee Jones
2014-05-30 9:03 ` Zhu, Lejun [this message]
2014-05-30 9:28 ` Lee Jones
2014-05-31 2:27 ` Zhu, Lejun
2014-05-29 7:19 ` [PATCH v4 2/3] mfd: intel_soc_pmic: Crystal Cove support Zhu, Lejun
2014-05-29 11:49 ` Lee Jones
2014-05-30 5:01 ` Zhu, Lejun
2014-05-29 7:19 ` [PATCH v4 3/3] mfd: intel_soc_pmic: Build files Zhu, Lejun
2014-05-29 11:43 ` Lee Jones
2014-05-30 5:00 ` Zhu, Lejun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5388497C.3000106@linux.intel.com \
--to=lejun.zhu@linux.intel.com \
--cc=bin.yang@intel.com \
--cc=broonie@kernel.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox