[Skiboot] [PATCH RFC 07/12] opal-prd: use get_ipoll_mask() callback

[Daniel M Crowell]

I can't think of a way this can fail.

--
Dan Crowell
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com



From:   Jeremy Kerr <jk at ozlabs.org>
To:     Vasant Hegde <hegdevasant at linux.vnet.ibm.com>, 
skiboot at lists.ozlabs.org
Cc:     Dan Crowell <dcrowell at us.ibm.com>
Date:   05/25/2017 06:34 PM
Subject:        Re: [Skiboot] [PATCH RFC 07/12] opal-prd: use 
get_ipoll_mask() callback



Hi Vasant,

>> @@ -1515,6 +1516,13 @@ static int run_attn_loop(struct opal_prd_ctx 
*ctx)
>>          }
>>      }
>>
>> +    if (hservice_runtime->get_ipoll_events) {
>> +        pr_debug("HBRT: calling get_ipoll_events");
>> +        opal_prd_ipoll = call_get_ipoll_events();
> 
> So if get_ipoll_events fails then we endup passing same value. But
> looking into interface definition, I don't see a way to validate the
> output. May be validate for negative values?

This function can't fail (there isn't a return value to indicate an
error), and it returns an unsigned value. Besides, we can't check for
negative, as valid values currently have the top-bit set anyway...

That's okay though, as the HBRT implementation will just likely just be
a simple return <value>.

Dan: if that's not the case (and you do need a facility to indicate an
error), then we could define 0xff..ff as an error condition. However, we
would have no option but to exit from the daemon anyway, so you could
get the same behaviour by calling callbacks->assert()..

Cheers,


Jeremy





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20170525/6c440acf/attachment.html>