[Skiboot] [PATCH v12 07/10] skiboot: Find the IMC DTB

[Michael Neuling]

> > > +void imc_catalog_preload(void)
> > > +{
> > > > +	uint32_t pvr = mfspr(SPR_PVR);
> > > > +	int ret = OPAL_SUCCESS;
> > > 
> > > +	imc_catalog_size = MAX_UNCOMPRESSED_IMC_DTB_SIZE;
> > 
> > Should we sanity check MAX_UNCOMPRESSED_IMC_DTB_SIZE vs the FFS partition
> > size.
> 
> Just trying to understand how this check will help. 

I'm concerned that if they pnor size gets bigger, you'll overflow this buffer. 
Hence the check.

> Infact going forward
> if they reduce the pnor partition side we will break right? Is that the
> indent to have the check?

I would have thought the making the pnor partition smaller would be fine.

> > > +enum {
> > > > > +	IMC_COUNTER_PER_THREAD		= 0x1,
> > > > > +	IMC_COUNTER_PER_SUB_CORE	= 0x2,
> > > > > +	IMC_COUNTER_PER_CORE		= 0x4,
> > > > > +	IMC_COUNTER_PER_QUAD		= 0x8,
> > > 
> > > +	IMC_COUNTER_PER_CHIP		= 0x10,
> > 
> > Only CHIP is used in this patch set.
> > 
> > Why are we creating this opal API if only CHIP is ever used?  Can we delete
> > the
> > rest of these?
> 
>  From the OPAL patchset yes we only use the "CHIP",
> but in the kernel side we use the "CORE" and "THREAD"
> properties. That said, I can make this to map the
> current OPAL counter type and remove the rest?

>From our chat offline yesterday, these sound more like details of the in memory
structure written by the microcode than OPAL APIs.  If so, they should be
removed from the opal-api.h

Mikey