From: Lee Jones <lee.jones@linaro.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-kernel@vger.kernel.org,
Samuel Ortiz <sameo@linux.intel.com>,
Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Subject: Re: [PATCH v1 4/5] mfd: lpc_sch: Add support for Intel Quark X1000
Date: Mon, 1 Sep 2014 12:31:58 +0100 [thread overview]
Message-ID: <20140901113158.GN7374@lee--X1> (raw)
In-Reply-To: <1409567306.30155.51.camel@linux.intel.com>
On Mon, 01 Sep 2014, Andy Shevchenko wrote:
> On Mon, 2014-09-01 at 10:22 +0100, Lee Jones wrote:
> > On Fri, 22 Aug 2014, Andy Shevchenko wrote:
> >
> > > Intel Quark X1000 SoC supports IRQ based GPIO. This patch will
> > > enable MFD support for Quark X1000 and provide IRQ resources
> > > to Quark X1000 GPIO device driver.
> > >
> > > Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
> > > Tested-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> See my answers below.
>
> > > ---
> > > drivers/mfd/lpc_sch.c | 41 +++++++++++++++++++++++++++++++++++------
> > > 1 file changed, 35 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
> > > index c4eb359..6145a4c 100644
> > > --- a/drivers/mfd/lpc_sch.c
> > > +++ b/drivers/mfd/lpc_sch.c
> > > @@ -37,6 +37,9 @@
> > > #define GPIO_IO_SIZE 64
> > > #define GPIO_IO_SIZE_CENTERTON 128
> > >
> > > +/* Intel Quark X1000 GPIO IRQ Number */
> > > +#define GPIO_IRQ_QUARK_X1000 9
> > > +
> > > #define WDTBASE 0x84
> > > #define WDT_IO_SIZE 64
> > >
> > > @@ -44,28 +47,37 @@ enum sch_chipsets {
> > > LPC_SCH = 0, /* Intel Poulsbo SCH */
> > > LPC_ITC, /* Intel Tunnel Creek */
> > > LPC_CENTERTON, /* Intel Centerton */
> > > + LPC_QUARK_X1000, /* Intel Quark X1000 */
> > > };
> > >
> > > struct lpc_sch_info {
> > > unsigned int io_size_smbus;
> > > unsigned int io_size_gpio;
> > > unsigned int io_size_wdt;
> > > + int irq_gpio;
> > > };
> > >
> > > static struct lpc_sch_info sch_chipset_info[] = {
> > > [LPC_SCH] = {
> > > .io_size_smbus = SMBUS_IO_SIZE,
> > > .io_size_gpio = GPIO_IO_SIZE,
> > > + .irq_gpio = -1,
> > > },
> > > [LPC_ITC] = {
> > > .io_size_smbus = SMBUS_IO_SIZE,
> > > .io_size_gpio = GPIO_IO_SIZE,
> > > .io_size_wdt = WDT_IO_SIZE,
> > > + .irq_gpio = -1,
> > > },
> > > [LPC_CENTERTON] = {
> > > .io_size_smbus = SMBUS_IO_SIZE,
> > > .io_size_gpio = GPIO_IO_SIZE_CENTERTON,
> > > .io_size_wdt = WDT_IO_SIZE,
> > > + .irq_gpio = -1,
> > > + },
> > > + [LPC_QUARK_X1000] = {
> > > + .io_size_gpio = GPIO_IO_SIZE,
> > > + .irq_gpio = GPIO_IRQ_QUARK_X1000,
> > > },
> > > };
> > >
> > > @@ -73,6 +85,7 @@ static const struct pci_device_id lpc_sch_ids[] = {
> > > { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC), LPC_SCH },
> > > { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC), LPC_ITC },
> > > { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_CENTERTON_ILB), LPC_CENTERTON },
> > > + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB), LPC_QUARK_X1000 },
> > > { 0, }
> > > };
> > > MODULE_DEVICE_TABLE(pci, lpc_sch_ids);
> > > @@ -106,14 +119,26 @@ static int lpc_sch_get_io(struct pci_dev *pdev, int where, const char *name,
> > > return 0;
> > > }
> > >
> > > +static int lpc_sch_get_irq(struct resource *res, int irq)
> > > +{
> > > + if (irq < 0)
> > > + return -EINVAL;
> > > +
> > > + res->start = irq;
> > > + res->end = irq;
> > > + res->flags = IORESOURCE_IRQ;
> > > +
> > > + return 0;
> > > +}
> >
> > Why does this need to be a separate function?
> >
> > I fear that the code will become unnecessarily fragmented, just for the
> > sake of it.
>
> I could do this as a condition branch.
You could, but you don't.
> > > static int lpc_sch_populate_cell(struct pci_dev *pdev, int where,
> > > - const char *name, int size, int id,
> > > - struct mfd_cell *cell)
> > > + const char *name, int size, int irq,
> > > + int id, struct mfd_cell *cell)
> > > {
> > > struct resource *res;
> > > int ret;
> > >
> > > - res = devm_kzalloc(&pdev->dev, sizeof(*res), GFP_KERNEL);
> > > + res = devm_kcalloc(&pdev->dev, 2, sizeof(*res), GFP_KERNEL);
> > > if (!res)
> > > return -ENOMEM;
> > >
> > > @@ -129,6 +154,10 @@ static int lpc_sch_populate_cell(struct pci_dev *pdev, int where,
> > > cell->ignore_resource_conflicts = true;
> > > cell->id = id;
> > >
> > > + ret = lpc_sch_get_irq(++res, irq);
> > > + if (!ret)
> > > + cell->num_resources++;
> >
> > Once again, you're masking errors. If it's not an error, don't return
> > one. If it is, filter it back and fail the bind.
>
> I have to know if there is such resource or not. Taking into account you
> prefer to see lpc_sch_get_irq embedded in here I just can do as a
> condition branch and there will be no more question I hope.
This is true.
> > > return 0;
> > > }
> > >
> > > @@ -141,19 +170,19 @@ static int lpc_sch_probe(struct pci_dev *dev,
> > > int ret;
> > >
> > > ret = lpc_sch_populate_cell(dev, SMBASE, "isch_smbus",
> > > - info->io_size_smbus,
> > > + info->io_size_smbus, -1,
> > > id->device, &lpc_sch_cells[cells]);
> > > if (!ret)
> > > cells++;
> > >
> > > ret = lpc_sch_populate_cell(dev, GPIOBASE, "sch_gpio",
> > > - info->io_size_gpio,
> > > + info->io_size_gpio, info->irq_gpio,
> > > id->device, &lpc_sch_cells[cells]);
> > > if (!ret)
> > > cells++;
> > >
> > > ret = lpc_sch_populate_cell(dev, WDTBASE, "ie6xx_wdt",
> > > - info->io_size_wdt,
> > > + info->io_size_wdt, -1,
> > > id->device, &lpc_sch_cells[cells]);
> > > if (!ret)
> > > cells++;
>
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2014-09-01 11:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-22 10:58 [PATCH v1 0/5] mfd: lpc_sch: Intel Quark support Andy Shevchenko
2014-08-22 10:58 ` [PATCH v1 1/5] mfd: lpc_sch: reduce duplicate code Andy Shevchenko
2014-09-01 9:13 ` Lee Jones
2014-09-01 10:21 ` Andy Shevchenko
2014-09-01 11:38 ` Lee Jones
2014-09-01 11:48 ` Andy Shevchenko
2014-09-01 13:46 ` Lee Jones
2014-09-01 14:00 ` Andy Shevchenko
2014-08-22 10:58 ` [PATCH v1 2/5] mfd: lpc_sch: better code manageability with chipset info struct Andy Shevchenko
2014-09-01 9:16 ` Lee Jones
2014-09-01 10:25 ` Andy Shevchenko
2014-09-02 0:17 ` Chang, Rebecca Swee Fun
2014-09-02 7:25 ` Lee Jones
2014-08-22 10:58 ` [PATCH v1 3/5] pci_ids: add support for Intel Quark ILB Andy Shevchenko
2014-08-29 14:27 ` Bjorn Helgaas
2014-09-01 9:14 ` Andy Shevchenko
2014-09-02 0:14 ` Chang, Rebecca Swee Fun
2014-08-22 10:58 ` [PATCH v1 4/5] mfd: lpc_sch: Add support for Intel Quark X1000 Andy Shevchenko
2014-09-01 9:22 ` Lee Jones
2014-09-01 10:28 ` Andy Shevchenko
2014-09-01 11:31 ` Lee Jones [this message]
2014-08-22 10:58 ` [PATCH v1 5/5] mfd: lpc_sch: remove FSF address Andy Shevchenko
2014-08-29 14:26 ` Bjorn Helgaas
2014-08-29 9:57 ` [PATCH v1 0/5] mfd: lpc_sch: Intel Quark support Andy Shevchenko
2014-08-29 11:00 ` Lee Jones
2014-09-01 11:40 ` Andy Shevchenko
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=20140901113158.GN7374@lee--X1 \
--to=lee.jones@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rebecca.swee.fun.chang@intel.com \
--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;
as well as URLs for NNTP newsgroup(s).