All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	<linux-kernel@vger.kernel.org>, <linux-pci@vger.kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	<lokeshvutla@ti.com>
Subject: Re: [PATCH 1/3] PCI: Add support in pci_walk_bus() to invoke callback matching RID
Date: Mon, 27 Sep 2021 20:26:59 +0530	[thread overview]
Message-ID: <589e1bf2-3955-5249-7c0e-04c9c7b07e3f@ti.com> (raw)
In-Reply-To: <87r1dat6v9.wl-maz@kernel.org>

Hi Marc,

On 27/09/21 8:15 pm, Marc Zyngier wrote:
> On Wed, 22 Sep 2021 02:26:09 +0100,
> Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>
>>>>>> -void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
>>>>>> -		  void *userdata)
>>>>>> +void __pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
>>>>>> +		    void *userdata, u32 rid, u32 mask)
>>>>>>  {
>>>>>>  	struct pci_dev *dev;
>>>>>>  	struct pci_bus *bus;
>>>>>> @@ -399,13 +401,16 @@ void pci_walk_bus(struct pci_bus *top, int (*cb)(struct pci_dev *, void *),
>>>>>>  		} else
>>>>>>  			next = dev->bus_list.next;
>>>>>>  
>>>>>> +		if (mask != 0xffff && ((pci_dev_id(dev) & mask) != rid))
>>>>>
>>>>> Why the check for the mask? I also wonder whether the mask should apply
>>>>> to the rid as well:
>>>>
>>>> If the mask is set for all 16bits, then there is not going to be two PCIe
>>>> devices which gets the same ITS device ID right? So no need for calculating
>>>> total number of vectors?
>>>
>>> Are we really arguing about the cost of a compare+branch vs some
>>> readability? Or is there an actual correctness issue here?
>>
>> It is for correctness. So existing pci_walk_bus() doesn't invoke cb based on
>> rid. So when we convert to __pci_walk_bus(), existing callers of pci_walk_bus()
>> might not invoke cb for some devices without the check.
>>>
>>>>>
>>>>> 		if ((pci_dev_id(dev) & mask) != (rid & mask))
>>>
>>> Because I think the above expression is a lot more readable (and
>>> likely more correct) than what you are suggesting.
>>
>> That would result in existing pci_walk_bus() behave differently from what was
>> before this patch no?
>>
>> I'm having something like this below
>> 	+#define pci_walk_bus(top, cb, userdata) \
>> 	+	 __pci_walk_bus((top), (cb), (userdata), 0x0, 0xffff)
>>
>> So if we add only "if ((pci_dev_id(dev) & mask) != (rid & mask))",
>> the callback will not be invoked for any devices (other than one
>> with rid = 0)
> 
> But that *is* the bug, isn't it? If you want to parse all the devices,
> a mask of 0 is what you need. The mask defines the bits that you want
> to match against the RID you passed as a parameter. If you don't want
> to check any bit, don't pass any!

Indeed! Thanks for explaining.

Regards,
Kishon

  reply	other threads:[~2021-09-27 14:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20  6:41 [PATCH 0/3] PCI/gic-v3-its: Add support for same ITS device ID for multiple PCIe devices Kishon Vijay Abraham I
2021-09-20  6:41 ` [PATCH 1/3] PCI: Add support in pci_walk_bus() to invoke callback matching RID Kishon Vijay Abraham I
2021-09-20  8:56   ` Marc Zyngier
2021-09-20 14:28     ` Kishon Vijay Abraham I
2021-09-20 18:01       ` Marc Zyngier
2021-09-22  1:26         ` Kishon Vijay Abraham I
2021-09-27 14:45           ` Marc Zyngier
2021-09-27 14:56             ` Kishon Vijay Abraham I [this message]
2021-09-20  6:41 ` [PATCH 2/3] PCI: Export find_pci_root_bus() Kishon Vijay Abraham I
2021-09-20  8:37   ` Marc Zyngier
2021-09-20  6:41 ` [PATCH 3/3] irqchip/gic-v3-its: Include "msi-map-mask" for calculating nvecs Kishon Vijay Abraham I
2021-09-20  8:36   ` Marc Zyngier
2021-09-20  9:14 ` [PATCH 0/3] PCI/gic-v3-its: Add support for same ITS device ID for multiple PCIe devices Marc Zyngier
2021-09-20 11:22   ` Kishon Vijay Abraham I
2021-09-20 11:36     ` Marc Zyngier

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=589e1bf2-3955-5249-7c0e-04c9c7b07e3f@ti.com \
    --to=kishon@ti.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maz@kernel.org \
    --cc=tglx@linutronix.de \
    /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.