| Message ID | 1482213825-30448-9-git-send-email-oohall@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On 20/12/16 17:03, Oliver O'Halloran wrote: > Define a driver specific flush opal call in preperation for removing preparation > the con_ops->flush() operation. > > Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Except for uncertainty below: Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> > --- > core/console.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/core/console.c b/core/console.c > index be5aa6211ce4..b053e491e351 100644 > --- a/core/console.c > +++ b/core/console.c > @@ -373,6 +373,12 @@ static int64_t dummy_console_read(int64_t term_number, int64_t *length, > } > opal_call(OPAL_CONSOLE_READ, dummy_console_read, 3); > > +static int64_t dummy_console_flush(int64_t term_number __unused) > +{ > + return OPAL_UNSUPPORTED; > +} > +opal_call(OPAL_CONSOLE_FLUSH, dummy_console_flush, 1); The other OPAL_CONSOLE_FLUSH call hasn't been removed yet, is having competing opal_call()s a defined thing?
On Tue, Dec 20, 2016 at 6:33 PM, Andrew Donnellan <andrew.donnellan@au1.ibm.com> wrote: > On 20/12/16 17:03, Oliver O'Halloran wrote: >> >> Define a driver specific flush opal call in preperation for removing > > > preparation > >> the con_ops->flush() operation. >> >> Signed-off-by: Oliver O'Halloran <oohall@gmail.com> > > > Except for uncertainty below: > > Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> > >> --- >> core/console.c | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/core/console.c b/core/console.c >> index be5aa6211ce4..b053e491e351 100644 >> --- a/core/console.c >> +++ b/core/console.c >> @@ -373,6 +373,12 @@ static int64_t dummy_console_read(int64_t >> term_number, int64_t *length, >> } >> opal_call(OPAL_CONSOLE_READ, dummy_console_read, 3); >> >> +static int64_t dummy_console_flush(int64_t term_number __unused) >> +{ >> + return OPAL_UNSUPPORTED; >> +} >> +opal_call(OPAL_CONSOLE_FLUSH, dummy_console_flush, 1); > > > The other OPAL_CONSOLE_FLUSH call hasn't been removed yet, is having > competing opal_call()s a defined thing? No, there is always a single OPAL call handler. opal_register() overwrites the existing handler at runtime. > > -- > Andrew Donnellan OzLabs, ADL Canberra > andrew.donnellan@au1.ibm.com IBM Australia Limited >
On 20/12/16 18:40, Oliver O'Halloran wrote: >> The other OPAL_CONSOLE_FLUSH call hasn't been removed yet, is having >> competing opal_call()s a defined thing? > > No, there is always a single OPAL call handler. opal_register() > overwrites the existing handler at runtime. I'm referring to: ajd@ajd:~/code/skiboot$ gg "opal_call(OPAL_CONSOLE_FLUSH" core/console.c:opal_call(OPAL_CONSOLE_FLUSH, opal_console_flush, 1); core/console.c:opal_call(OPAL_CONSOLE_FLUSH, dummy_console_flush, 1); I realise opal_register() overwrites the handler at runtime, but what exactly happens with multiple opal_call()s? This is of course moot as we fix it a few patches later.
On Tue, Dec 20, 2016 at 6:46 PM, Andrew Donnellan <andrew.donnellan@au1.ibm.com> wrote: > On 20/12/16 18:40, Oliver O'Halloran wrote: >>> >>> The other OPAL_CONSOLE_FLUSH call hasn't been removed yet, is having >>> competing opal_call()s a defined thing? >> >> >> No, there is always a single OPAL call handler. opal_register() >> overwrites the existing handler at runtime. > > > I'm referring to: > > ajd@ajd:~/code/skiboot$ gg "opal_call(OPAL_CONSOLE_FLUSH" > core/console.c:opal_call(OPAL_CONSOLE_FLUSH, opal_console_flush, 1); > core/console.c:opal_call(OPAL_CONSOLE_FLUSH, dummy_console_flush, 1); > > I realise opal_register() overwrites the handler at runtime, but what > exactly happens with multiple opal_call()s? > > This is of course moot as we fix it a few patches later. Ah right. The macro itself spins up a struct which is inserted in a special ELF section. When linking skiboot.elf it folds these sections into an array that skiboot walks when filling out the OPAL call table at boot. Whatever comes second in the table will be installed as the handler, but the ordering in the table will depend on how the linker feels. > > > -- > Andrew Donnellan OzLabs, ADL Canberra > andrew.donnellan@au1.ibm.com IBM Australia Limited >
diff --git a/core/console.c b/core/console.c index be5aa6211ce4..b053e491e351 100644 --- a/core/console.c +++ b/core/console.c @@ -373,6 +373,12 @@ static int64_t dummy_console_read(int64_t term_number, int64_t *length, } opal_call(OPAL_CONSOLE_READ, dummy_console_read, 3); +static int64_t dummy_console_flush(int64_t term_number __unused) +{ + return OPAL_UNSUPPORTED; +} +opal_call(OPAL_CONSOLE_FLUSH, dummy_console_flush, 1); + static void dummy_console_poll(void *data __unused) { bool has_data = false;
Define a driver specific flush opal call in preperation for removing the con_ops->flush() operation. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> --- core/console.c | 6 ++++++ 1 file changed, 6 insertions(+)