[Skiboot] [RFC PATCH] powerpc/powernv: report error messages from opal
oohall at gmail.com
Fri Jul 7 10:45:39 AEST 2017
On Thu, Jul 6, 2017 at 8:20 PM, Michael Ellerman <mpe at ellerman.id.au> wrote:
> Stewart Smith <stewart at linux.vnet.ibm.com> writes:
>> Oliver O'Halloran <oohall at gmail.com> writes:
>>> diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h
>>> index 0e2e57bcab50..cb9c0e6afb33 100644
>>> --- a/arch/powerpc/include/asm/opal-api.h
>>> +++ b/arch/powerpc/include/asm/opal-api.h
>>> @@ -167,7 +167,8 @@
>>> #define OPAL_INT_EOI 124
>>> #define OPAL_INT_SET_MFRR 125
>>> #define OPAL_PCI_TCE_KILL 126
>>> -#define OPAL_LAST 126
>>> +#define OPAL_SCRAPE_LOG 128
>> (another thought, along with the skiboot thoughts), I don't like the
>> SCRAPE_LOG name so much, as it's more of a "hey linux, here's some log
>> messages from firmware, possibly before you were
>> involved"... OPAL_FETCH_LOG ?
> I'm not a huge fan of an interrupt followed by an opal call just to
> fetch a single line of log.
> Can't we do something more like the existing msglog code, where we have
> a ring buffer and then the interrupt just becomes "hey Linux you should
> look at your ring buffer".
eh... personally I don't see the overhead of the OPAL call as being
important. OPAL errors are infrequent and there's no need to make
fetching OPAL errors fast.
I think we have a bit of a recurring problem where we make random
Skiboot implementation details into part of the OPAL ABI. There is
*no* reason the kernel should care about the skiboot log format so I'd
rather we just kept the details of parsing it inside of Skiboot. I'm
open to suggestions of how to improve the interface, but I think we
should keep it.
More information about the Skiboot