netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Fri, 02 Mar 2018 15:38:47 +0200	[thread overview]
Message-ID: <1519997927.10722.379.camel@linux.intel.com> (raw)
In-Reply-To: <66b55c14-a124-f6cb-0b02-7aa7afd2e434@gmail.com>

On Thu, 2018-03-01 at 21:36 +0100, Heiner Kallweit wrote:
> Am 01.03.2018 um 21:15 schrieb Andy Shevchenko:
> > 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.
> > 
> 
> Ahh, missed this because I didn't dig that deep into these functions.
> Would be nice if pcim_iomap_regions() returned iomap directly
> (or an ERRPTR). Then the additional call to pcim_iomap_table()
> wouldn't be needed.

You can't do that, since you may ask to map several regions at once.
And moreover, some of them can be optional (then you indeed need to
check the return value of pcim_iomap_table() helper).

> 
> 
> > > 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

  reply	other threads:[~2018-03-02 13:38 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
2018-03-01 20:36       ` Heiner Kallweit
2018-03-02 13:38         ` Andy Shevchenko [this message]
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=1519997927.10722.379.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 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).