All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: adharmap@codeaurora.org
Cc: davidb@codeaurora.org, "David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Bryan Huntsman <bryanh@codeaurora.org>,
	Daniel Walker <dwalker@fifo99.com>,
	David Collins <collinsd@codeaurora.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Joe Perches <joe@perches.com>,
	Russell King <linux@arm.linux.org.uk>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Stepan Moskovchenko <stepanm@codeaurora.org>,
	Linus Walleij <linux.walleij@sterricsson.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [Qualcomm PM8921 MFD 2/6] mfd: pm8xxx: Add irq support
Date: Wed, 2 Mar 2011 22:46:16 +0000	[thread overview]
Message-ID: <20110302224616.GB32325@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1299104001-5240-3-git-send-email-adharmap@codeaurora.org>

On Wed, Mar 02, 2011 at 02:13:17PM -0800, adharmap@codeaurora.org wrote:
> 
> Change-Id: Ibb23878cd382af9a750d62ab49482f5dc72e3714
> Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>

Remove the change IDs from upstream submissions.  The kernel doesn't use
gerritt.

>  struct pm8921 {
> -	struct device *dev;
> +	struct device			*dev;
> +	struct device			*irq_dev;

Is it really useful to register a struct device purely for the interrupt
controller?  I'd have expected this to be core functionality of the
device.  The fact that you need to store the device at all is a bit odd
too as you're using the MFD API.

>  static struct pm8xxx_drvdata pm8921_drvdata = {
> -	.pmic_readb	= pm8921_readb,
> -	.pmic_writeb	= pm8921_writeb,
> -	.pmic_read_buf	= pm8921_read_buf,
> -	.pmic_write_buf = pm8921_write_buf,
> +	.pmic_readb		= pm8921_readb,
> +	.pmic_writeb		= pm8921_writeb,
> +	.pmic_read_buf		= pm8921_read_buf,
> +	.pmic_write_buf		= pm8921_write_buf,
> +	.pmic_read_irq_stat	= pm8921_read_irq_stat,
> +};

It'd seem better to indent things as per the final driver in the first
patch - this reindentation creates a lot of noise in the diff.

>  		goto err_read_rev;
>  	}
> -	pr_info("PMIC revision:   %02X\n", val);
> +	pr_info("PMIC revision 1: %02X\n", val);
> +	rev = val;
>  

Again, do this in the first patch.

> +static int
> +pm8xxx_read_block(const struct pm_irq_chip *chip, u8 bp, u8 *ip)
> +{
> +	int	rc;
> +
> +	rc = pm8xxx_writeb(chip->dev->parent,
> +				SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
> +	if (rc) {
> +		pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
> +		goto bail_out;
> +	}
> +
> +	rc = pm8xxx_readb(chip->dev->parent,
> +			SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
> +	if (rc)
> +		pr_err("Failed Reading Status rc=%d\n", rc);
> +bail_out:
> +	return rc;
> +}

The namespacing here is odd, this looks like it should be a generic API
not a block specific one.

> +	/* Check IRQ bits */
> +	for (k = 0; k < 8; k++) {
> +		if (bits & (1 << k)) {
> +			pmirq = block * 8 + k;
> +			irq = pmirq + chip->irq_base;
> +			/* Check spurious interrupts */
> +			if (((1 << k) & chip->irqs_allowed[block])) {
> +				/* Found one */
> +				chip->irqs_to_handle[*handled] = irq;
> +				(*handled)++;
> +			} else { /* Clear and mask wrong one */
> +				config = PM_IRQF_W_C_M |
> +					(k << PM_IRQF_BITS_SHIFT);
> +
> +				pm8xxx_config_irq(chip,
> +						  block, config);
> +
> +				if (pm8xxx_can_print())
> +					pr_err("Spurious IRQ: %d "
> +					       "[block, bit]="
> +					       "[%d, %d]\n",
> +					       irq, block, k);
> +			}

The generic IRQ code should be able to take care of spurious interrupts
for you?  It's a bit surprising that there's all this logic - I'd expect
an IRQ chip to just defer logic about which interrupts are valid and so
on to the generic IRQ code.

>  #include <linux/device.h>
> +#include <linux/mfd/pm8xxx/irq.h>
> +
> +#define NR_PM8921_IRQS 256

Traditionally this'd be namespaced like this:

+#define PM8921_NR_IRQS 256

WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [Qualcomm PM8921 MFD 2/6] mfd: pm8xxx: Add irq support
Date: Wed, 2 Mar 2011 22:46:16 +0000	[thread overview]
Message-ID: <20110302224616.GB32325@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1299104001-5240-3-git-send-email-adharmap@codeaurora.org>

On Wed, Mar 02, 2011 at 02:13:17PM -0800, adharmap at codeaurora.org wrote:
> 
> Change-Id: Ibb23878cd382af9a750d62ab49482f5dc72e3714
> Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>

Remove the change IDs from upstream submissions.  The kernel doesn't use
gerritt.

>  struct pm8921 {
> -	struct device *dev;
> +	struct device			*dev;
> +	struct device			*irq_dev;

Is it really useful to register a struct device purely for the interrupt
controller?  I'd have expected this to be core functionality of the
device.  The fact that you need to store the device at all is a bit odd
too as you're using the MFD API.

>  static struct pm8xxx_drvdata pm8921_drvdata = {
> -	.pmic_readb	= pm8921_readb,
> -	.pmic_writeb	= pm8921_writeb,
> -	.pmic_read_buf	= pm8921_read_buf,
> -	.pmic_write_buf = pm8921_write_buf,
> +	.pmic_readb		= pm8921_readb,
> +	.pmic_writeb		= pm8921_writeb,
> +	.pmic_read_buf		= pm8921_read_buf,
> +	.pmic_write_buf		= pm8921_write_buf,
> +	.pmic_read_irq_stat	= pm8921_read_irq_stat,
> +};

It'd seem better to indent things as per the final driver in the first
patch - this reindentation creates a lot of noise in the diff.

>  		goto err_read_rev;
>  	}
> -	pr_info("PMIC revision:   %02X\n", val);
> +	pr_info("PMIC revision 1: %02X\n", val);
> +	rev = val;
>  

Again, do this in the first patch.

> +static int
> +pm8xxx_read_block(const struct pm_irq_chip *chip, u8 bp, u8 *ip)
> +{
> +	int	rc;
> +
> +	rc = pm8xxx_writeb(chip->dev->parent,
> +				SSBI_REG_ADDR_IRQ_BLK_SEL, bp);
> +	if (rc) {
> +		pr_err("Failed Selecting Block %d rc=%d\n", bp, rc);
> +		goto bail_out;
> +	}
> +
> +	rc = pm8xxx_readb(chip->dev->parent,
> +			SSBI_REG_ADDR_IRQ_IT_STATUS, ip);
> +	if (rc)
> +		pr_err("Failed Reading Status rc=%d\n", rc);
> +bail_out:
> +	return rc;
> +}

The namespacing here is odd, this looks like it should be a generic API
not a block specific one.

> +	/* Check IRQ bits */
> +	for (k = 0; k < 8; k++) {
> +		if (bits & (1 << k)) {
> +			pmirq = block * 8 + k;
> +			irq = pmirq + chip->irq_base;
> +			/* Check spurious interrupts */
> +			if (((1 << k) & chip->irqs_allowed[block])) {
> +				/* Found one */
> +				chip->irqs_to_handle[*handled] = irq;
> +				(*handled)++;
> +			} else { /* Clear and mask wrong one */
> +				config = PM_IRQF_W_C_M |
> +					(k << PM_IRQF_BITS_SHIFT);
> +
> +				pm8xxx_config_irq(chip,
> +						  block, config);
> +
> +				if (pm8xxx_can_print())
> +					pr_err("Spurious IRQ: %d "
> +					       "[block, bit]="
> +					       "[%d, %d]\n",
> +					       irq, block, k);
> +			}

The generic IRQ code should be able to take care of spurious interrupts
for you?  It's a bit surprising that there's all this logic - I'd expect
an IRQ chip to just defer logic about which interrupts are valid and so
on to the generic IRQ code.

>  #include <linux/device.h>
> +#include <linux/mfd/pm8xxx/irq.h>
> +
> +#define NR_PM8921_IRQS 256

Traditionally this'd be namespaced like this:

+#define PM8921_NR_IRQS 256

  reply	other threads:[~2011-03-02 22:46 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-02 22:13 [Qualcomm PM8921 MFD 0/6] *** SUBJECT HERE *** adharmap
2011-03-02 22:13 ` adharmap at codeaurora.org
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 1/6] mfd: pm8921: Add PMIC 8921 core driver adharmap
2011-03-02 22:13   ` adharmap at codeaurora.org
2011-03-02 22:28   ` Mark Brown
2011-03-02 22:28     ` Mark Brown
2011-03-03  3:38     ` Abhijeet Dharmapurikar
2011-03-03  3:38       ` Abhijeet Dharmapurikar
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 2/6] mfd: pm8xxx: Add irq support adharmap
2011-03-02 22:13   ` adharmap at codeaurora.org
2011-03-02 22:46   ` Mark Brown [this message]
2011-03-02 22:46     ` Mark Brown
2011-03-03  4:38     ` Abhijeet Dharmapurikar
2011-03-03  4:38       ` Abhijeet Dharmapurikar
2011-03-03 15:22       ` Mark Brown
2011-03-03 15:22         ` Mark Brown
2011-03-03 22:55         ` Abhijeet Dharmapurikar
2011-03-03 22:55           ` Abhijeet Dharmapurikar
2011-03-04 11:12           ` Mark Brown
2011-03-04 11:12             ` Mark Brown
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 3/6] gpio: pm8xxx-gpio: Add pm8xxx gpio driver adharmap
2011-03-02 22:13   ` adharmap at codeaurora.org
2011-07-08 15:44   ` Greg KH
2011-07-08 15:44     ` Greg KH
2011-07-08 17:23     ` Abhijeet Dharmapurikar
2011-07-08 17:23       ` Abhijeet Dharmapurikar
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 4/6] mfd: pm8xxx-mpp: Add pm8xxx MPP driver adharmap
2011-03-02 22:13   ` adharmap at codeaurora.org
2011-07-08 14:57   ` Greg KH
2011-07-08 14:57     ` Greg KH
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 5/6] MAINTAINERS: Add pmic8921, pmic8xxx subdevices maintainers adharmap
2011-03-02 22:13   ` adharmap at codeaurora.org
2011-03-02 22:50   ` Joe Perches
2011-03-02 22:50     ` Joe Perches
2011-03-03  4:41     ` Abhijeet Dharmapurikar
2011-03-03  4:41       ` Abhijeet Dharmapurikar
2011-03-02 22:13 ` [Qualcomm PM8921 MFD 6/6] msm: board-8960: Add support for pm8921 adharmap
2011-03-02 22:13   ` adharmap at codeaurora.org

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=20110302224616.GB32325@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=adharmap@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=bryanh@codeaurora.org \
    --cc=collinsd@codeaurora.org \
    --cc=davem@davemloft.net \
    --cc=davidb@codeaurora.org \
    --cc=dwalker@fifo99.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@suse.de \
    --cc=joe@perches.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux.walleij@sterricsson.com \
    --cc=linux@arm.linux.org.uk \
    --cc=sameo@linux.intel.com \
    --cc=stepanm@codeaurora.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.