All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: MyungJoo Ham
	<myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Anton Vorontsov <anton-9xeibp6oKSgdnm+yROfE0A@public.gmane.org>,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Bartlomiej Zolnierkiewicz
	<b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Marek Szyprowski
	<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Kyungmin Park
	<kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH 1/4] mfd: max14577: Add max14577 MFD driver core
Date: Thu, 14 Nov 2013 09:15:37 +0100	[thread overview]
Message-ID: <1384416937.5901.6.camel@AMDC1943> (raw)
In-Reply-To: <20131113131328.GF878-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>

Hi,

On Wed, 2013-11-13 at 13:13 +0000, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 08:40:54AM +0100, Krzysztof Kozlowski wrote:
> 
> > +/**
> > + * After resuming from suspend it may happen that IRQ is signalled but
> > + * IRQ GPIO is not high. Also the interrupt registers won't have any data
> > + * (all of them equal to 0x00).
> > + *
> > + * In such case retry few times reading the interrupt registers.
> > + */
> > +#define IRQ_READ_REG_RETRY_CNT		5
> 
> What is the cause here?  This smells like an unreliable workaround for
> some other behaviour.  In general this all looks very like standard
> regmap code.
> 
> > +	for (i = 0; i < MAX14577_IRQ_REGS_NUM; i++) {
> > +		u8 mask_reg = max14577_mask_reg[i];
> > +
> > +		if (mask_reg == MAX14577_REG_INVALID ||
> > +				IS_ERR_OR_NULL(max14577->regmap))
> > +			continue;
> 
> Why would this code even be running if you don't have a register map?
> 
> > +		dev_info(max14577->dev, "Got interrupts [1:0x%02x, 2:0x%02x, 3:0x%02x]\n",
> > +			irq_reg[MAX14577_IRQ_INT1], irq_reg[MAX14577_IRQ_INT2],
> > +			irq_reg[MAX14577_IRQ_INT3]);
> 
> This is far too noisy, dev_dbg() at most.
> 
> > +		gpio_val = gpio_get_value(pdata->irq_gpio);
> > +
> > +		if (gpio_get_value(pdata->irq_gpio) == 0)
> > +			dev_warn(max14577->dev, "IRQ GPIO is not high, retry reading interrupt registers\n");
> > +	} while (gpio_val == 0 && --retry > 0);
> 
> This looks very strange...
> 
> > +	max14577->irq = gpio_to_irq(pdata->irq_gpio);
> > +	ret = gpio_request(pdata->irq_gpio, "max14577_irq");
> > +	if (ret) {
> > +		dev_err(max14577->dev, "Failed requesting GPIO %d: %d\n",
> > +				pdata->irq_gpio, ret);
> > +		goto err;
> > +	}
> > +	gpio_direction_input(pdata->irq_gpio);
> > +	gpio_free(pdata->irq_gpio);
> 
> This means the GPIO handling code that was present in the handling is
> broken, it's trying to use the GPIO after it was freed.
> 
> > +	ret = request_threaded_irq(max14577->irq, NULL, max14577_irq_thread,
> > +				   IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> > +				   "max14577-irq", max14577);
> 
> Are you *positive* this is a falling triggered IRQ?  All the code to do
> with spinning reading the GPIO state during handling makes it look like
> this is in fact an active low interrupt and a lot of the code in here is
> working around trying to handle that as the wrong kind of IRQ.
> 
> > +int max14577_bulk_write(struct regmap *map, u8 reg, u8 *buf, int count)
> > +{
> > +	return regmap_bulk_write(map, reg, buf, count);
> > +}
> > +EXPORT_SYMBOL_GPL(max14577_bulk_write);
> 
> Given that these are basically all trivial wrappers around regmap they
> probably ought to be static inlines in the header.
> 
> > +static struct max14577_platform_data *max14577_i2c_parse_dt(struct device *dev)
> > +{
> 
> There's no DT binding document?
> 
> > +const struct dev_pm_ops max14577_pm = {
> > +	.suspend = max14577_suspend,
> > +	.resume = max14577_resume,
> > +};
> 
> SET_SYSTEM_SLEEP_PM_OPS().
> 
> > +static int __init max14577_i2c_init(void)
> > +{
> > +	return i2c_add_driver(&max14577_i2c_driver);
> > +}
> > +subsys_initcall(max14577_i2c_init);
> 
> Why not module_i2c_driver?

Thanks for review. I'll the fix issues and send later new version of
patch.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Mark Brown <broonie@kernel.org>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Lee Jones <lee.jones@linaro.org>,
	Anton Vorontsov <anton@enomsg.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <rob.herring@calxeda.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [PATCH 1/4] mfd: max14577: Add max14577 MFD driver core
Date: Thu, 14 Nov 2013 09:15:37 +0100	[thread overview]
Message-ID: <1384416937.5901.6.camel@AMDC1943> (raw)
In-Reply-To: <20131113131328.GF878@sirena.org.uk>

Hi,

On Wed, 2013-11-13 at 13:13 +0000, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 08:40:54AM +0100, Krzysztof Kozlowski wrote:
> 
> > +/**
> > + * After resuming from suspend it may happen that IRQ is signalled but
> > + * IRQ GPIO is not high. Also the interrupt registers won't have any data
> > + * (all of them equal to 0x00).
> > + *
> > + * In such case retry few times reading the interrupt registers.
> > + */
> > +#define IRQ_READ_REG_RETRY_CNT		5
> 
> What is the cause here?  This smells like an unreliable workaround for
> some other behaviour.  In general this all looks very like standard
> regmap code.
> 
> > +	for (i = 0; i < MAX14577_IRQ_REGS_NUM; i++) {
> > +		u8 mask_reg = max14577_mask_reg[i];
> > +
> > +		if (mask_reg == MAX14577_REG_INVALID ||
> > +				IS_ERR_OR_NULL(max14577->regmap))
> > +			continue;
> 
> Why would this code even be running if you don't have a register map?
> 
> > +		dev_info(max14577->dev, "Got interrupts [1:0x%02x, 2:0x%02x, 3:0x%02x]\n",
> > +			irq_reg[MAX14577_IRQ_INT1], irq_reg[MAX14577_IRQ_INT2],
> > +			irq_reg[MAX14577_IRQ_INT3]);
> 
> This is far too noisy, dev_dbg() at most.
> 
> > +		gpio_val = gpio_get_value(pdata->irq_gpio);
> > +
> > +		if (gpio_get_value(pdata->irq_gpio) == 0)
> > +			dev_warn(max14577->dev, "IRQ GPIO is not high, retry reading interrupt registers\n");
> > +	} while (gpio_val == 0 && --retry > 0);
> 
> This looks very strange...
> 
> > +	max14577->irq = gpio_to_irq(pdata->irq_gpio);
> > +	ret = gpio_request(pdata->irq_gpio, "max14577_irq");
> > +	if (ret) {
> > +		dev_err(max14577->dev, "Failed requesting GPIO %d: %d\n",
> > +				pdata->irq_gpio, ret);
> > +		goto err;
> > +	}
> > +	gpio_direction_input(pdata->irq_gpio);
> > +	gpio_free(pdata->irq_gpio);
> 
> This means the GPIO handling code that was present in the handling is
> broken, it's trying to use the GPIO after it was freed.
> 
> > +	ret = request_threaded_irq(max14577->irq, NULL, max14577_irq_thread,
> > +				   IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> > +				   "max14577-irq", max14577);
> 
> Are you *positive* this is a falling triggered IRQ?  All the code to do
> with spinning reading the GPIO state during handling makes it look like
> this is in fact an active low interrupt and a lot of the code in here is
> working around trying to handle that as the wrong kind of IRQ.
> 
> > +int max14577_bulk_write(struct regmap *map, u8 reg, u8 *buf, int count)
> > +{
> > +	return regmap_bulk_write(map, reg, buf, count);
> > +}
> > +EXPORT_SYMBOL_GPL(max14577_bulk_write);
> 
> Given that these are basically all trivial wrappers around regmap they
> probably ought to be static inlines in the header.
> 
> > +static struct max14577_platform_data *max14577_i2c_parse_dt(struct device *dev)
> > +{
> 
> There's no DT binding document?
> 
> > +const struct dev_pm_ops max14577_pm = {
> > +	.suspend = max14577_suspend,
> > +	.resume = max14577_resume,
> > +};
> 
> SET_SYSTEM_SLEEP_PM_OPS().
> 
> > +static int __init max14577_i2c_init(void)
> > +{
> > +	return i2c_add_driver(&max14577_i2c_driver);
> > +}
> > +subsys_initcall(max14577_i2c_init);
> 
> Why not module_i2c_driver?

Thanks for review. I'll the fix issues and send later new version of
patch.

Best regards,
Krzysztof


  parent reply	other threads:[~2013-11-14  8:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13  7:40 [PATCH 0/4] mfd: max14577: Add max14577 MFD drivers Krzysztof Kozlowski
2013-11-13  7:40 ` Krzysztof Kozlowski
2013-11-13  7:40 ` [PATCH 1/4] mfd: max14577: Add max14577 MFD driver core Krzysztof Kozlowski
     [not found]   ` <1384328457-5147-2-git-send-email-k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-11-13 11:50     ` Mark Rutland
2013-11-13 11:50       ` Mark Rutland
     [not found]       ` <20131113115018.GE21713-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-11-14  8:32         ` Krzysztof Kozlowski
2013-11-14  8:32           ` Krzysztof Kozlowski
2013-11-13 13:13   ` Mark Brown
     [not found]     ` <20131113131328.GF878-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-11-14  1:33       ` Kyungmin Park
2013-11-14  1:33         ` Kyungmin Park
     [not found]         ` <CAH9JG2U9VDnRW9JZ7j7OyRmVhSXWJ5Yp_gNqUPK=xCST7SY=xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-11-14 10:24           ` Mark Brown
2013-11-14 10:24             ` Mark Brown
     [not found]             ` <20131114102419.GE26614-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-11-14 10:53               ` Marek Szyprowski
2013-11-14 10:53                 ` Marek Szyprowski
2013-11-14 11:22                 ` Mark Brown
2013-11-14  8:15       ` Krzysztof Kozlowski [this message]
2013-11-14  8:15         ` Krzysztof Kozlowski
     [not found] ` <1384328457-5147-1-git-send-email-k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-11-13  7:40   ` [PATCH 2/4] extcon: max77693: Add extcon-max14577 driver to support MUIC device Krzysztof Kozlowski
2013-11-13  7:40     ` Krzysztof Kozlowski
2013-11-13  7:40 ` [PATCH 3/4] charger: max14577: Add charger support for Maxim 14577 Krzysztof Kozlowski
2013-11-13  7:40 ` [PATCH 4/4] regulator: max14577: Add regulator driver " Krzysztof Kozlowski
     [not found]   ` <1384328457-5147-5-git-send-email-k.kozlowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2013-11-13 13:23     ` Mark Brown
2013-11-13 13:23       ` Mark Brown
2013-11-14  9:17       ` Krzysztof Kozlowski

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=1384416937.5901.6.camel@AMDC1943 \
    --to=k.kozlowski-sze3o3uu22jbdgjk7y7tuq@public.gmane.org \
    --cc=anton-9xeibp6oKSgdnm+yROfE0A@public.gmane.org \
    --cc=b.zolnierkie-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
    --cc=sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.