linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Sinan Kaya <okaya@codeaurora.org>,
	linux-pci@vger.kernel.org, timur@codeaurora.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH 09/30] drm/i915: deprecate pci_get_bus_and_slot()
Date: Thu, 23 Nov 2017 09:42:39 +0200	[thread overview]
Message-ID: <1511422959.4641.5.camel@linux.intel.com> (raw)
In-Reply-To: <4541eaef-745a-e78f-e61d-1c7c207b551e@codeaurora.org>

On Wed, 2017-11-22 at 11:28 -0500, Sinan Kaya wrote:
> On 11/22/2017 2:52 AM, Joonas Lahtinen wrote:
> > Dropping the extra mailing lists and Dave, this is a rather trivial thing.
> > 
> > On Wed, 2017-11-22 at 00:30 -0500, Sinan Kaya wrote:
> > > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > > where a PCI device is present. This restricts the device drivers to be
> > > reused for other domain numbers.
> > > 
> > > Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't
> > > extract the domain number. Other places, use the actual domain number from
> > > the device.
> > > 
> > > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> > 
> > <SNIP>
> > 
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -419,7 +419,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
> > >  
> > >  static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
> > >  {
> > > -	dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> > > +	uint16_t devfn = PCI_DEVFN(0, 0)
> > 
> > The would have to be "unsigned int" according to the function
> > signature.
> 
> Even though the return value is unsigned int, PCI_DEVFN cannot be bigger
> than 16 bits. 
> 
> http://elixir.free-electrons.com/linux/v4.14.1/source/include/uapi/linux/pci.h#L31
> 
> /*
>  * The PCI interface treats multi-function devices as independent
>  * devices.  The slot/function address of each device is encoded
>  * in a single byte as follows:
>  *
>  *	7:3 = slot
>  *	2:0 = function
>  */
> 
> It is common practice to use u16 for keeping devfn information in the
> kernel.

A quick run of 'git grep "PCI_DEVFN" | egrep "(uint|u)(16|32)"' vs.
'git grep "PCI_DEVFN" | grep "unsigned"' didn't indicate that. And
following the function signature would be the thing to do, unless there
is some compelling reason not to.

But it's not really relevant as a variable is not needed.

> > > +
> > > +	dev_priv->bridge_dev = pci_get_domain_bus_and_slot(0, 0, devfn);
> > 
> > But the most straightforward change is to simply convert to:
> > 
> > 	dev_priv->bridge_dev = pci_get_domain_bus_and_slot(0, 0,
> > 							   PCI_DEVFN(0, 0));
> > 
> > Can you please resend like that.
> 
> I did this at the beginning and but, I hit a checkpatch problem with
> more than 80 characters. That's why, I moved the devfn value assignment
> to a different line.

It is not longer than 80 characters when you break line before the
PCI_DEVFN like I proposed. Or you can break it after the "=", too,
either way works fine.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

  parent reply	other threads:[~2017-11-23  7:42 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-22  5:30 [PATCH 00/30] PCI: deprecate pci_get_bus_and_slot() Sinan Kaya
2017-11-22  5:30 ` [PATCH 01/30] alpha/PCI: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 02/30] powerpc/PCI: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 03/30] x86/PCI: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 04/30] ata: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 05/30] agp: nvidia: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 06/30] edd: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 07/30] ibft: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 08/30] drm/gma500: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 09/30] drm/i915: " Sinan Kaya
2017-11-22  7:52   ` Joonas Lahtinen
2017-11-22 16:28     ` Sinan Kaya
2017-11-22 19:50       ` Jani Nikula
2017-11-22 19:58         ` Timur Tabi
2017-11-23  7:14           ` Jani Nikula
2017-11-23  7:42       ` Joonas Lahtinen [this message]
2017-11-23 18:37         ` Sinan Kaya
2017-11-27  8:56           ` Joonas Lahtinen
2017-11-27 14:05             ` Sinan Kaya
2017-11-22  5:30 ` [PATCH 10/30] drm/nouveau: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 11/30] hwmon: (coretemp) " Sinan Kaya
2017-11-22 15:07   ` [11/30] " Guenter Roeck
2017-11-22  5:30 ` [PATCH 12/30] Drivers: ide: " Sinan Kaya
2017-11-22  7:53   ` Greg KH
2017-11-22 16:24     ` Sinan Kaya
2017-11-22  5:30 ` [PATCH 13/30] iommu/amd: " Sinan Kaya
2017-11-22  5:30 ` [PATCH 14/30] powerpc/powermac: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 15/30] bnx2x: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 16/30] pch_gbe: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 17/30] PCI: cpqhp: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 18/30] PCI: ibmphp: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 19/30] PCI/quirks: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 20/30] PCI/syscall: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 21/30] xen: " Sinan Kaya
2017-11-22 12:53   ` Juergen Gross
2017-11-22  5:31 ` [PATCH 22/30] openprom: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 23/30] [media] atomisp: " Sinan Kaya
2017-11-22 12:20   ` Alan Cox
2017-11-22 14:05     ` Sinan Kaya
2017-11-22 14:06       ` Sinan Kaya
2017-11-22  5:31 ` [PATCH 24/30] staging: rts5208: " Sinan Kaya
2017-11-22  7:54   ` Greg Kroah-Hartman
2017-11-22  5:31 ` [PATCH 25/30] backlight: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 26/30] video: fbdev: intelfb: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 27/30] video: fbdev: nvidia: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 28/30] video: fbdev: riva: " Sinan Kaya
2017-11-22  5:31 ` [PATCH 29/30] i7300_idle: " Sinan Kaya
2017-11-22  7:53   ` Greg Kroah-Hartman
2017-11-22 16:15     ` Sinan Kaya
2017-11-22 16:45       ` Greg Kroah-Hartman
2017-11-22 16:50         ` Sinan Kaya
2017-11-22 16:58           ` Greg Kroah-Hartman
2017-11-22  5:31 ` [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function Sinan Kaya
2017-11-22  5:45   ` Timur Tabi
2017-11-22  5:55     ` Sinan Kaya
2017-11-22  6:08       ` Timur Tabi
2017-11-22  7:51         ` Greg KH
2017-11-22 14:42           ` Timur Tabi
2017-11-22 14:49             ` Greg KH
2017-11-22 15:18               ` Sinan Kaya

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=1511422959.4641.5.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=okaya@codeaurora.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=timur@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 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).