> From: Jan Beulich
> Sent: Monday, April 11, 2022 5:40 PM
>
> There's no good reason to use these when we already have a pci_sbdf_t
> type object available. This extends to the use of PCI_BUS() in
> pci_ecam_map_bus() as well.
>
> No change to generated code (with gcc11 at least, and I have to
On 13.04.2022 16:13, Bertrand Marquis wrote:
>> On 13 Apr 2022, at 14:58, Roger Pau Monné wrote:
>> On Wed, Apr 13, 2022 at 01:48:14PM +, Bertrand Marquis wrote:
On 11 Apr 2022, at 10:40, Jan Beulich wrote:
There's no good reason to use these when we already have a pci_sbdf_t
>
Hi,
> On 13 Apr 2022, at 14:58, Roger Pau Monné wrote:
>
> On Wed, Apr 13, 2022 at 01:48:14PM +, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 11 Apr 2022, at 10:40, Jan Beulich wrote:
>>>
>>> There's no good reason to use these when we already have a pci_sbdf_t
>>> type object available.
On Wed, Apr 13, 2022 at 01:48:14PM +, Bertrand Marquis wrote:
> Hi Jan,
>
> > On 11 Apr 2022, at 10:40, Jan Beulich wrote:
> >
> > There's no good reason to use these when we already have a pci_sbdf_t
> > type object available. This extends to the use of PCI_BUS() in
> > pci_ecam_map_bus() a
On 13.04.2022 15:48, Bertrand Marquis wrote:
>> On 11 Apr 2022, at 10:40, Jan Beulich wrote:
>> --- a/xen/arch/arm/pci/ecam.c
>> +++ b/xen/arch/arm/pci/ecam.c
>> @@ -28,8 +28,7 @@ void __iomem *pci_ecam_map_bus(struct pc
>> container_of(bridge->ops, const struct pci_ecam_ops, pci_ops);
>>
Hi Jan,
> On 11 Apr 2022, at 10:40, Jan Beulich wrote:
>
> There's no good reason to use these when we already have a pci_sbdf_t
> type object available. This extends to the use of PCI_BUS() in
> pci_ecam_map_bus() as well.
>
> No change to generated code (with gcc11 at least, and I have to adm
On Mon, Apr 11, 2022 at 11:40:24AM +0200, Jan Beulich wrote:
> There's no good reason to use these when we already have a pci_sbdf_t
> type object available. This extends to the use of PCI_BUS() in
> pci_ecam_map_bus() as well.
>
> No change to generated code (with gcc11 at least, and I have to ad
