From: Mark Brown <broonie@kernel.org>
To: "Zhu, Lejun" <lejun.zhu@linux.intel.com>
Cc: lee.jones@linaro.org, sameo@linux.intel.com,
linux-kernel@vger.kernel.org, jacob.jun.pan@linux.intel.com,
bin.yang@intel.com
Subject: Re: [PATCH RESEND v2 1/4] mfd: intel_soc_pmic: Core driver
Date: Fri, 23 May 2014 18:49:25 +0100 [thread overview]
Message-ID: <20140523174925.GH22111@sirena.org.uk> (raw)
In-Reply-To: <1400805629-10322-2-git-send-email-lejun.zhu@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3603 bytes --]
On Fri, May 23, 2014 at 08:40:26AM +0800, Zhu, Lejun wrote:
> +struct device *intel_soc_pmic_dev(void)
> +{
> + return pmic->dev;
> +}
> +EXPORT_SYMBOL(intel_soc_pmic_dev);
Why do you need to take a global reference to this?
> +/*
> + * Read from a PMIC register
> + */
> +int intel_soc_pmic_readb(int reg)
> +{
> + int ret;
> + unsigned int val;
> +
> + mutex_lock(&pmic_lock);
> +
> + if (!pmic) {
> + ret = -EIO;
> + } else {
> + ret = regmap_read(pmic->regmap, reg, &val);
> + if (!ret)
> + ret = val;
> + }
> +
> + mutex_unlock(&pmic_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(intel_soc_pmic_readb);
This is wrapping the EXPORT_SYMBOL_GPL() regmap API with an
EXPORT_SYMBOL() API. Don't do that, if you really do need these
wrappers make them EXPORT_SYMBOL_GPL().
There should also be no need to add extra locking around regmap calls,
the regmap API has locking as standard.
It's also not clear why this API exists at all, surely all the
interaction with the device happens from the core or function drivers
for the device which ought to be able to get a direct reference to the
regmap anyway and only be instantiated when one is present.
> +/*
> + * Set platform_data of the child devices. Needs to be called before
> + * the MFD device is added.
> + */
> +int intel_soc_pmic_set_pdata(const char *name, void *data, int len)
> +{
> + struct cell_dev_pdata *pdata;
> +
> + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + pr_err("intel_pmic: can't set pdata!\n");
> + return -ENOMEM;
> + }
> +
> + pdata->name = name;
> + pdata->data = data;
> + pdata->len = len;
> +
> + list_add_tail(&pdata->list, &pdata_list);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(intel_soc_pmic_set_pdata);
What is going on here, why aren't the normal ways of getting data to the
devices (such as reading the platform data of the parent device) OK?
> +static void __pmic_regmap_flush(void)
> +{
> + if (cache_write_pending)
> + WARN_ON(regmap_write(pmic->regmap, cache_offset,
> + cache_write_val));
> +static int pmic_regmap_load_from_hw(struct intel_pmic_regmap *map)
> +{
> + int ret;
This all appears to be an open coded cache layer - there is already
cache support in regmap, just reuse that.
> +static irqreturn_t pmic_irq_isr(int irq, void *data)
> +{
> + return IRQ_WAKE_THREAD;
> +}
Just register the IRQ as IRQF_ONESHOT and only provide the threaded
handler.
> +static irqreturn_t pmic_irq_thread(int irq, void *data)
> +{
> + int i;
> +
> + mutex_lock(&pmic->irq_lock);
> +
> + for (i = 0; i < pmic->irq_num; i++) {
> + if (test_bit(PMIC_IRQ_MASK_BIT(i), &PMIC_IRQ_MASK(pmic, i)))
> + continue;
> +
> + if (pmic_regmap_read(&pmic->irq_regmap[i].status)) {
> + pmic_regmap_write(&pmic->irq_regmap[i].ack, 1);
> + handle_nested_irq(pmic->irq_base + i);
> + }
> + }
This looks like you should be using regmap-irq, or at least like there's
some small additions needed to make it usable.
> + if (gpio_is_valid(pmic->pmic_int_gpio)) {
> + ret = gpio_request_one(pmic->pmic_int_gpio,
> + GPIOF_DIR_IN, "PMIC Interupt");
> + if (ret) {
> + dev_err(pmic->dev, "Request PMIC_INT gpio error\n");
> + goto out_free_desc;
> + }
> +
> + pmic->irq = gpio_to_irq(pmic->pmic_int_gpio);
> + }
There should be no need to do this, simply requesting the interrupt
should be sufficient to ensure the pin is in the correct mode. If this
isn't the case the interrupt controller driver probably needs an update,
there's some support for helping with this in the GPIO framework IIRC.
You're also not using managed (devm) allocations for anything here.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-05-23 17:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 0:40 [PATCH RESEND v2 0/4] mfd: Intel SoC Power Management IC Zhu, Lejun
2014-05-23 0:40 ` [PATCH RESEND v2 1/4] mfd: intel_soc_pmic: Core driver Zhu, Lejun
2014-05-23 17:49 ` Mark Brown [this message]
2014-05-26 6:01 ` Zhu, Lejun
2014-05-26 14:51 ` Mark Brown
2014-05-27 0:48 ` Zhu, Lejun
2014-05-27 11:20 ` Mark Brown
2014-05-28 0:55 ` Zhu, Lejun
2014-05-28 11:19 ` Mark Brown
2014-05-23 0:40 ` [PATCH RESEND v2 2/4] mfd: intel_soc_pmic: I2C interface Zhu, Lejun
2014-05-23 17:53 ` Mark Brown
2014-05-26 6:03 ` Zhu, Lejun
2014-05-23 0:40 ` [PATCH RESEND v2 3/4] mfd: intel_soc_pmic: Crystal Cove support Zhu, Lejun
2014-05-23 0:40 ` [PATCH RESEND v2 4/4] mfd: intel_soc_pmic: Build files Zhu, Lejun
2014-05-23 10:08 ` [PATCH RESEND v2 0/4] mfd: Intel SoC Power Management IC Lee Jones
2014-05-25 23:41 ` 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=20140523174925.GH22111@sirena.org.uk \
--to=broonie@kernel.org \
--cc=bin.yang@intel.com \
--cc=jacob.jun.pan@linux.intel.com \
--cc=lee.jones@linaro.org \
--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
all inboxes | Powered by JetHome®