All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	David Cohen <david.a.cohen@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 3/4] gpio-langwell: use managed functions pcim_* and devm_*
Date: Wed, 22 May 2013 11:50:00 +0300	[thread overview]
Message-ID: <20130522085000.GY11878@intel.com> (raw)
In-Reply-To: <CAHp75Vdyb4ynf-XQrcaCrKSPkbzN9_PP6txpvsYnYWXdZpWrEQ@mail.gmail.com>

On Wed, May 22, 2013 at 11:36:15AM +0300, Andy Shevchenko wrote:
> On Wed, May 22, 2013 at 11:05 AM, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> > On Wed, May 22, 2013 at 10:47:38AM +0300, Andy Shevchenko wrote:
> >> This makes the error handling much more simpler than open-coding everything and
> >> in addition makes the probe function smaller an tidier.
> >>
> >> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >
> > In general this change looks good. Getting rid of 61 lines is certainly an
> > improvement!
> >
> > David, are you able to check that this still works on your hardware? (I'm
> > pretty sure that Andy has tested this already on Medfield)
> 
> I also wonder if it still okay on other platforms where this IP block
> is embedded.
> 
> > I have few minor comments, though. See below.
> 
> Thank you for the review. See my answers below.
> 
> >> ---
> >>  drivers/gpio/gpio-langwell.c | 82 ++++++++++++--------------------------------
> >>  1 file changed, 21 insertions(+), 61 deletions(-)
> >>
> >> diff --git a/drivers/gpio/gpio-langwell.c b/drivers/gpio/gpio-langwell.c
> >> index 8203084..8672282 100644
> >> --- a/drivers/gpio/gpio-langwell.c
> >> +++ b/drivers/gpio/gpio-langwell.c
> >> @@ -320,56 +320,35 @@ static const struct dev_pm_ops lnw_gpio_pm_ops = {
> >>  static int lnw_gpio_probe(struct pci_dev *pdev,
> >>                         const struct pci_device_id *id)
> >>  {
> >> -     void __iomem *base;
> >> -     resource_size_t start, len;
> >>       struct lnw_gpio *lnw;
> >>       u32 gpio_base;
> >>       u32 irq_base;
> >>       int retval;
> >>       int ngpio = id->driver_data;
> >>
> >> -     retval = pci_enable_device(pdev);
> >> +     retval = pcim_enable_device(pdev);
> >>       if (retval)
> >>               return retval;
> >>
> >> -     retval = pci_request_regions(pdev, "langwell_gpio");
> >> +     retval = pcim_iomap_regions(pdev, 1 << 0 | 1 << 1, pci_name(pdev));
> >
> > I wonder if "langwell_gpio" is still a better name compared to
> > pci_name(pdev)?
> 
> This is used as an internal name for certain resource.
> 
> It could be seen in case of using printk("%pR") for example. But even
> in that case I prefer to see the actual device as well to which
> the resource belongs to.
> 
> My general opinion is better to use pci_name(pdev) in the pci drivers instead
> of hardcoded pseudo-unique strings.

Fair enough :)

> >>       if (retval) {
> >> -             dev_err(&pdev->dev, "error requesting resources\n");
> >> -             goto err_pci_req_region;
> >> -     }
> >> -     /* get the gpio_base from bar1 */
> >> -     start = pci_resource_start(pdev, 1);
> >> -     len = pci_resource_len(pdev, 1);
> >> -     base = ioremap_nocache(start, len);
> >> -     if (!base) {
> >> -             dev_err(&pdev->dev, "error mapping bar1\n");
> >> -             retval = -EFAULT;
> >> -             goto err_ioremap;
> >> +             dev_err(&pdev->dev, "I/O memory mapping error\n");
> >> +             return retval;
> >>       }
> >>
> >> -     irq_base = readl(base);
> >> -     gpio_base = readl(sizeof(u32) + base);
> >> +     irq_base = readl(pcim_iomap_table(pdev)[1]);
> >> +     gpio_base = readl(sizeof(u32) + pcim_iomap_table(pdev)[1]);
> >
> > Using pcim_iomap_table(pdev)[] is a bit confusing, at least for me. Can you
> > add a variable where you store that pointer and use that instead?
> 
> [Hmm... It returns pointer to an array of pointers.
> Okay,  I will relive base variable for this as we discussed privately.

Cool, thanks!

  reply	other threads:[~2013-05-22  8:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-22  7:47 [PATCH v2 0/4] gpio-langwell: bugfix and amendments Andy Shevchenko
2013-05-22  7:47 ` [PATCH v2 1/4] gpio-langwell: initialize lock before usage Andy Shevchenko
2013-05-22  7:58   ` Mika Westerberg
2013-05-22  7:47 ` [PATCH v2 2/4] gpio-langwell: do not use direct access to iomapped memory Andy Shevchenko
2013-05-22  7:58   ` Mika Westerberg
2013-05-22  7:47 ` [PATCH v2 3/4] gpio-langwell: use managed functions pcim_* and devm_* Andy Shevchenko
2013-05-22  8:05   ` Mika Westerberg
2013-05-22  8:36     ` Andy Shevchenko
2013-05-22  8:50       ` Mika Westerberg [this message]
2013-05-22  7:47 ` [PATCH v2 4/4] gpio-langwell: amend error messages Andy Shevchenko
2013-05-22  8:06   ` Mika Westerberg

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=20130522085000.GY11878@intel.com \
    --to=mika.westerberg@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=david.a.cohen@intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.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.