[Skiboot] [PATCH 3/6] hw/npu2: Common NPU2 init routine between NVLink and OpenCAPI

Andrew Donnellan andrew.donnellan at au1.ibm.com
Tue Aug 21 17:01:36 AEST 2018


On 21/08/18 16:34, Alistair Popple wrote:
> Couple of minor comments below, but nothing major.
> 
> Reviewed-By: Alistair Popple <alistair at popple.id.au>

Thanks :)

>> +	dt_for_each_compatible(dt_root, np, "ibm,power9-npu") {
>> +	        npu = setup_npu(np);
>> +		if (npu) {
> 
> Not sure if you're just being defensive but setup_npu() can never return
> npu == NULL (it asserts instead) so the check is somewhat superfluous.

I think at some point it was able to return NULL and then I shuffled 
things around a bit...

>> diff --git a/include/npu2.h b/include/npu2.h
>> index 10742031ec0f..9fdc438bb4c1 100644
>> --- a/include/npu2.h
>> +++ b/include/npu2.h
>> @@ -147,6 +147,7 @@ struct npu2 {
>>   	uint32_t	chip_id;
>>   	uint64_t	xscom_base;
>>   	void		*regs;
>> +	void		*ocapi_global_mmio_base;
> 
> This is only one value so at this point it doesn't matter but if we start adding
> more values to struct npu2 that are exclusive to NPU2 xor OCAPI it would be nice
> to have these in different structs so it's obvious which ones are
> initialised/used in each case.

I've gone back and forth on this... in principle I agree but C doesn't 
make nested struct namespacing look particularly elegant and I keep 
screwing up . vs -> when I do that... but yes, if we need to add more 
fields then maybe it's worth doing that.


-- 
Andrew Donnellan              OzLabs, ADL Canberra
andrew.donnellan at au1.ibm.com  IBM Australia Limited



More information about the Skiboot mailing list