On 16/6/2023 2:51 pm, Sebastian Huber wrote:
> On 16.06.23 03:49, Chris Johns wrote:
>>> diff --git a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> index 96b77907a6..bc211e37b6 100644
>>> --- a/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> +++ b/bsps/shared/grlib/drvmgr/ambapp_bus_grlib.c
>>> @@ -41,7 +41,7 @@
>>> #include <grlib/genirq.h>
>>> #include <bsp.h>
>>> -#include <bsp/irq.h>
>>> +#include <bsp/irq-generic.h>
>>> #include <grlib/grlib_impl.h>
>>> @@ -227,7 +227,7 @@ static int ambapp_grlib_int_clear
>>> struct drvmgr_dev *dev,
>>> int irq)
>>> {
>>> - BSP_shared_interrupt_clear(irq);
>>> + (void) rtems_interrupt_clear(irq);
>>> return DRVMGR_OK;
>> Why ignore the return code of the clear and assume the result is OK?
>>
>> This pattern is repeated in other places.
>
> This is how it is. I didn't want to introduce functional or API changes with
> this patch set.
I do not see the API change.
If the code here is looking through the interface provided to the implementation
so it knows no error will be returned then it is functionally equivalent to what
exists if the error is checked. Nothing changes. The problem with the change is
using the interface implies the error is being checked and a change in the
implementation to return an error would not be handled here. Leaving a latent
issue like that does not seem right?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
