Re: [PATCH v2 08/16] ppc/pnv: user created pnv-phb for powernv9

[Daniel Henrique Barboza]

On 6/7/22 03:44, Cédric Le Goater wrote:
> > > > Also, the comment seems wrong to me. The qom parenting doesn't matter when building the device tree. 
> >
> > it does. See pnv_dt_xscom()
>
> And this is the root cause of many headaches for user-created devices.
> Could it be done differently ?

Just tried to do a related change based on the review you gave in patch 07:

----
But it would assert if child is not of the correct type. The routine
above is called from a object_child_foreach() which loops on all
children.

I think it could be improved by using directly &chip*->phbs[i].

C.
-----

This doesn't work out of the gate because, for user creatable devices, we
are not setting the phbs back into the chip->phbs[] array. In fact we're
not even incrementing chip->num_phbs. We were getting away with all of it
because we are parenting the PHBs to the chip during realize.

Considering that, and also how pnv_dt_xscom() works, I´d rather stick with
most of the the QOM usage we already have. Otherwise we would need, for example,
to change xscom_dt_child to go through each device we want in the DT. And
there's no clear benefit aside from using less QOM, but that can be amended
by adding more documentation here and there.

I can make an exception for powernv8 and 
pnv_ics_get_child()/pnv_ics_resend_child(),
where we're cycling through all child elements every time. For those cases it's 
worth
to access the phbs directly via chip->phbs[], and for user creatable phb3s I'll 
add
the created phb in the array.

I also believe that I can do more to make the current handling of default 
phb3/phb4
closer to what user creatable devices does. This will ease the work to be done
by this series and will also make the design easier to understand. I might also 
do
some changes that Mark pointed out in the phb3/4 root ports as well. This 
series can
then be more about the PnvPHB proxy.


Thanks,


Daniel




> Thanks,
>
> C.