[Skiboot] [PATCH] opal-gard: Add support for new PVR POWER9P.
Oliver O'Halloran
oohall at gmail.com
Tue Feb 11 10:46:20 AEDT 2020
On Tue, Feb 11, 2020 at 3:38 AM Vasant Hegde
<hegdevasant at linux.vnet.ibm.com> wrote:
>
> On 2/10/20 8:25 PM, Oliver O'Halloran wrote:
> > On Mon, Feb 10, 2020 at 10:32 PM Stewart Smith <stewart at flamingspork.com> wrote:
> >>
> >>
> >>> On 7 Feb 2020, at 07:12, Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com> wrote:
> >>>
> >>> Enable a new PVR for gard tool to work on another p9 variant. Makes op-test
> >>> as well happy.
> >>>
> >>> Signed-off-by: Mahesh Salgaonkar <mahesh at linux.vnet.ibm.com>
> >>> ---
> >>> external/gard/gard.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/external/gard/gard.c b/external/gard/gard.c
> >>> index 5e58fede9..8877f1c84 100644
> >>> --- a/external/gard/gard.c
> >>> +++ b/external/gard/gard.c
> >>> @@ -153,6 +153,7 @@ static void guess_chip_gen(void)
> >>> return;
> >>>
> >>> case 0x004e: /* nimbus */
> >>> + case 0x004f: /* Axone */
> >>> set_chip_gen(p9_chip_units);
> >>> return;
> >>
> >> Makes me wonder why we don’t have something in the device tree and key off it.
> >
> > Patches welcome,
> >
> > Keep in mind that opal-gard can be used on the BMC, where we have no
> > access to the host DT, or on an x86 where there's no way to choose a
> > sensible default.
>
>
>
> Quick search shows we have definitions in multiple places.
>
>
> external/xscom-utils/sram.c:#define PVR_TYPE_P9 0x004e
> external/gard/gard.c: case 0x004e: /* nimbus */
> hdata/test/hdata_to_dt.c:#define PVR_TYPE_P9 0x004e
> hdata/test/hdata_to_dt.c:#define PVR_P9 0x004e0200
> hw/test/phys-map-test.c: 0x004e0200, /* PVR_P9 */
> include/processor.h:#define PVR_TYPE_P9 0x004e
>
>
>
> Why not use definitions from processor.h instead of DT?
I'll assume you mean "instead of hardcoding" and at a guess it's not
safe to #include processor.h from the tools in external/
>
> -Vasant
>
More information about the Skiboot
mailing list