From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Heiner Kallweit <hkallweit1@gmail.com>,
nic_swsd@realtek.com, "David S . Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH v4 2/2] r8169: switch to device-managed functions in probe (part 2)
Date: Thu, 01 Mar 2018 22:15:26 +0200 [thread overview]
Message-ID: <1519935326.10722.370.camel@linux.intel.com> (raw)
In-Reply-To: <b3cfbfd4-2cf3-d9aa-96ef-b7502ec15dce@gmail.com>
On Thu, 2018-03-01 at 20:54 +0100, Heiner Kallweit wrote:
> Am 01.03.2018 um 12:27 schrieb Andy Shevchenko:
> > - rc = pci_request_regions(pdev, MODULENAME);
> > + rc = pcim_iomap_regions(pdev, BIT(region), MODULENAME);
> > if (rc < 0) {
> > - netif_err(tp, probe, dev, "could not request
> > regions\n");
> > + netif_err(tp, probe, dev, "cannot remap MMIO,
> > aborting\n");
> > return rc;
> > }
> >
> >
> > + tp->mmio_addr = pcim_iomap_table(pdev)[region];
> >
>
> pcim_iomap_table() can return NULL in case of an error.
No.
> Shouldn't we catch this?
No.
Yeah, I'm a bit tired to explain everyone that pcim_iomap_table() will
never fail if previous pcim_iomap_regions() not failed.
> Typical benefit of switching to device-managed functions is that we
> don't
> have to clean up in the probe() error path and in remove(). With the
> change here we don't have any such benefit and we just exchange two
> calls
> against two other calls w/o functional change (AFAICS).
> Which benefit do you see justifying this patch?
-67% statistics is a good sign, no?
> However I don't know the PCI API's good enough to be able to judge
> whether
> one set of calls is preferable.
More than above, it's about consistency. While you switch to devm_, for
PCI driver it's naturally to go for pcim_.
Esp. taking into account that pcim_enable_device() _is_ already there.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2018-03-01 20:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 11:27 [PATCH v4 1/2] r8169: Dereference MMIO address immediately before use Andy Shevchenko
2018-03-01 11:27 ` [PATCH v4 2/2] r8169: switch to device-managed functions in probe (part 2) Andy Shevchenko
2018-03-01 19:54 ` Heiner Kallweit
2018-03-01 20:15 ` Andy Shevchenko [this message]
2018-03-01 20:36 ` Heiner Kallweit
2018-03-02 13:38 ` Andy Shevchenko
2018-03-04 23:15 ` David Miller
2018-03-01 20:01 ` [PATCH v4 1/2] r8169: Dereference MMIO address immediately before use Heiner Kallweit
2018-03-01 20:21 ` Andy Shevchenko
2018-03-04 23:15 ` David Miller
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=1519935326.10722.370.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.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 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.