Re: [PATCH 08/10] vpci/arm: Allow updating BAR's header for non-ECAM bridges

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>]

On 11/12/20 11:56 AM, Roger Pau Monné wrote:
> On Mon, Nov 09, 2020 at 02:50:29PM +0200, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> Non-ECAM host bridges in hwdom go directly to PCI config space,
>> not through vpci (they use their specific method for accessing PCI
>> configuration, e.g. dedicated registers etc.). Thus hwdom's vpci BARs are
>> never updated via vPCI MMIO handlers, so implement a dedicated method
>> for a PCI host bridge, so it has a chance to update the initial state of
>> the device BARs.
>>
>> Note, we rely on the fact that control/hardware domain will not update
>> physical BAR locations for the given devices.
> This is quite ugly.
It is
>
> I'm looking at the commit that implements the hook for R-Car and I'm
> having trouble seeing how that's different from the way we would
> normally read the BAR addresses.

Ok, please see my comment on patch [06/10]. In short:

when a PCI device is *added* we call init_bars and at that time BARs

are not assigned on ARM yet. But, if we move init_bars to the point

when a device *assigned* then it will work? And this code will go away

>
> I think this should likely be paired with the actual implementation of
> a hook, or else it's hard to tell whether it really needed or not.
Yes, if we move to device assign then it won't be needed: have to check that
>
> Thanks, Roger.

Thank you,

Oleksandr