The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: "Zhu, Lejun" <lejun.zhu@linux.intel.com>
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 09:08:48 +0100	[thread overview]
Message-ID: <20140530080848.GB2619@lee--X1> (raw)
In-Reply-To: <53880FF5.8070500@linux.intel.com>

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

> >> +	if (IS_ERR(desc)) {
> >> +		dev_dbg(dev, "Not using GPIO as interrupt.\n");
> > 
> > You can't have a debug print, then return an err - use dev_err().
> 
> Actually returning ENOENT here is just a hardware difference. On some
> boards the PMIC interrupt is from a GPIO line exposed by the CPU, on the
> rest (e.g. Asus T100TA) it's not. When -ENOENT is returned, probe() will
> simply use the IRQ provided by the I2C.
> 
> I will remove this line completely, and put a comment before the function.

That'll do, thanks.

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

> By the way, the GPIO child driver got reviewed-by from Linus Walleij,
> but can't be merged because it depends on intel_soc_pmic.h. May I
> include it in next version of the patch set and have it merged along
> with the MFD driver?

Yes, if it's okay with Linus and you aapply his Ack.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2014-05-30  8:09 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 [this message]
2014-05-30  9:03         ` Zhu, Lejun
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=20140530080848.GB2619@lee--X1 \
    --to=lee.jones@linaro.org \
    --cc=bin.yang@intel.com \
    --cc=broonie@kernel.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=lejun.zhu@linux.intel.com \
    --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