Re: [PATCH 0/3] Simplify generic interrupt controller support
On 18/6/21 5:20 pm, Sebastian Huber wrote: > This patch set simplifies the generic interrupt controller support a bit to > prepare for more complex follow up changes. This change touches a large number of BSPs in an important area. I spent some time this year fixing a 10+ year old IRQ bug related to these defines in the MVME2700 BSP that was not easy to see and did not appear to be an issue when reviewing the code and the changes to it. As a result I am wary of changes in this area without suitable testing. Could you please provide a list of the BSPs effected by this change? Can you please indicate which BSPs you have tested the change on and if the tests are on simulation or real hardware? I do not expect us to have complete coverage however I do think we need a plan that documents what we have tested, what we think is covered by other test results and what is not tested. I also think we will all need to provide test results on hardware we have. How do we stage the changes so we can perform the testing? Should we test all the changes as a set and bisect if we have an issue? It may be faster if there are no issues. What test or tests to we consider have to pass for the changes to be accepted? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] covoar/ Explanations.cc: Handle newline at end of file
On 19/6/21 7:00 am, Alex White wrote:
> ---
> tester/covoar/Explanations.cc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tester/covoar/Explanations.cc b/tester/covoar/Explanations.cc
> index 1449fb2..64cad5c 100644
> --- a/tester/covoar/Explanations.cc
> +++ b/tester/covoar/Explanations.cc
> @@ -87,6 +87,9 @@ namespace Coverage {
>// Get the explanation
>while (1) {
> explain.getline( inputBuffer, MAX_LINE_LENGTH );
> +if (explain.eof()) {
> + break;
> +}
> // fprintf( stderr, "%d - %s\n", line, inputBuffer );
> if (explain.fail()) {
>std::ostringstream what;
Maybe the std::getline example with a C++11 range base loop would be a better
solution?
https://en.cppreference.com/w/cpp/string/basic_string/getline
:)
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] covoar/ Explanations.cc: Handle newline at end of file
---
tester/covoar/Explanations.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tester/covoar/Explanations.cc b/tester/covoar/Explanations.cc
index 1449fb2..64cad5c 100644
--- a/tester/covoar/Explanations.cc
+++ b/tester/covoar/Explanations.cc
@@ -87,6 +87,9 @@ namespace Coverage {
// Get the explanation
while (1) {
explain.getline( inputBuffer, MAX_LINE_LENGTH );
+if (explain.eof()) {
+ break;
+}
// fprintf( stderr, "%d - %s\n", line, inputBuffer );
if (explain.fail()) {
std::ostringstream what;
--
2.27.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC POSIX Compliance: Can't Build RTEMS Tool Suite Anymore
On Fri, Jun 18, 2021 at 8:33 AM Matthew Joyce wrote: > Dear Mentors, > > I'm sorry to report that I've taken one step forward and three steps > back. Since last night, I'm having trouble building the RTEMS tool > suite at all. I keep getting the same error (attached). > > Steps I've taken to attempt to resolve: > 1) Tried to check out previous commits and rebuild from there. > 2) sudo yum update && upgrade > Did the native gcc or binutils update? The failure looks like an assembler issue with gcc output but weird since it is a partial line error. Did you run out of disk space? > 3) Followed the quick-start guide from scratch (clone rsb and source > into a new development directory, still fails in 2.4, Install the tool > suite). > > How I got here: I applied my initial header patch to rsb using the > blog guide and rebuilt the tool set. It built successfully, but then > failed when I ran waf. (Compiler had issues with my use of the keyword > "restrict".) I then created a new patch without "restrict", just to > see if it would compile. __restrict is what I hope you used and not just restrict. newlib uses the __restrict macro it defines to ensure it only uses the restrict keyword when it is supported by the language standard version being compiled with. > I deleted the old patch from the > tools/rtems-gcc-10-newlib-head.cfg and put the new one in. > > I'm guessing that was not correct based on my experience of the last 15 > hours! > You have to eventually deal with the RSB but as long as you are working on patches to newlib, it is simpler and much quicker to just build newlib and install it over the RSB built version. You do not need to rebuild gcc, binutils, or gdb. With the locally updated newlib, make changes to your local RTEMS to add methods and/or tests. When the newlib side is ready, submit the patch for review. When that is merged, the newlib version in the RSB will need to be bumped. After the newlib RSB hash is bumped, then things are in place to submit your RTEMS modifications. Streamlining the build/test cycle like this may save an hour an iteration. You usually can't submit a newlib change and a corresponding RTEMS change in parallel anyway. They have to be sequenced because of the dependency. > > I'm really looking forward to your feedback and advice when you can. > Thank you again! > > Sincerely, > > Matt > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Why is CPU_ISR_PASSES_FRAME_POINTER == FALSE on sparc?
On 18/06/2021 16:44, Joel Sherrill wrote:
Looks like someone forgot to change the ifdef when they added the ISR frame.
Is the macro used anywhere?
It looks like CPU_ISR_PASSES_FRAME_POINTER == TRUE is an unusual option.
I get a lot of
assignment to 'ISR_Handler_entry' {aka 'void (*)(unsigned int,
CPU_Interrupt_frame *)'} from incompatible pointer type 'rtems_isr
(*)(rtems_vector_number)'
warnings.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Why is CPU_ISR_PASSES_FRAME_POINTER == FALSE on sparc?
On Fri, Jun 18, 2021 at 9:23 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> I work currently on this ticket:
>
> https://devel.rtems.org/ticket/4458
>
> This is also related to the strange set_vector() function.
set_vector() was added long ago as a BSP wrapper for rtems_interrupt_catch()
when all that was supported is what we now call simple vectored
architectures.
There were CPUs with a simple interrupt enable/disable bit in the processor
but
the board had an interrupt source mask register. Installing the vector was
not
enough to enable the interrupt. You have to touch the board's interrupt mask
register. That's where the method came from.
I count 104 references/uses in bsp/ and one in cpukit/ so it can't go away
without
some work.
> Why do we
> have this:
>
> /**
> * Does the RTEMS invoke the user's ISR with the vector number and
> * a pointer to the saved interrupt frame (1) or just the vector
> * number (0)?
> *
> * The SPARC port does not pass an Interrupt Stack Frame pointer to
> * interrupt handlers.
> */
> #define CPU_ISR_PASSES_FRAME_POINTER FALSE
>
I'm guessing given the age of the SPARC port (started around 1994) that it
originally did not pass an ISR frame. Quite likely no port did at that
point.
When this macro was added, the SPARC port didn't define or pass a
frame pointer.
At this point, I would say it is wrong.
>
> I noticed that in bsp_spurious_initialize() we use this default handler:
>
> static rtems_isr bsp_spurious_handler(
> rtems_vector_number trap,
> CPU_Interrupt_frame *isf
> )
> {
>CPU_Exception_frame frame = {
> .trap = trap,
> .isf = isf
>};
>
> We also have in cpu_asm.S:
>
> sethi%hi(SYM(_ISR_Vector_table)), %g4
> or %g4, %lo(SYM(_ISR_Vector_table)), %g4
> and %l3, 0xFF, %g5 ! remove synchronous trap
> indicator
> sll %g5, 2, %g5! g5 = offset into table
> ld [%g4 + %g5], %g4 ! g4 = _ISR_Vector_table[ vector ]
>
>
> ! o1 = 2nd arg = address of the
> ISF
> ! WAS LOADED WHEN ISF WAS
> SAVED!!!
> mov %l3, %o0 ! o0 = 1st arg = vector number
> call %g4
>
> So, why is CPU_ISR_PASSES_FRAME_POINTER set to FALSE when the handler is
> actually called with the frame pointer and some handler actually use it?
>
Looks like someone forgot to change the ifdef when they added the ISR frame.
Is the macro used anywhere?
--joel
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Why is CPU_ISR_PASSES_FRAME_POINTER == FALSE on sparc?
Hello,
I work currently on this ticket:
https://devel.rtems.org/ticket/4458
This is also related to the strange set_vector() function. Why do we
have this:
/**
* Does the RTEMS invoke the user's ISR with the vector number and
* a pointer to the saved interrupt frame (1) or just the vector
* number (0)?
*
* The SPARC port does not pass an Interrupt Stack Frame pointer to
* interrupt handlers.
*/
#define CPU_ISR_PASSES_FRAME_POINTER FALSE
I noticed that in bsp_spurious_initialize() we use this default handler:
static rtems_isr bsp_spurious_handler(
rtems_vector_number trap,
CPU_Interrupt_frame *isf
)
{
CPU_Exception_frame frame = {
.trap = trap,
.isf = isf
};
We also have in cpu_asm.S:
sethi%hi(SYM(_ISR_Vector_table)), %g4
or %g4, %lo(SYM(_ISR_Vector_table)), %g4
and %l3, 0xFF, %g5 ! remove synchronous trap indicator
sll %g5, 2, %g5! g5 = offset into table
ld [%g4 + %g5], %g4 ! g4 = _ISR_Vector_table[ vector ]
! o1 = 2nd arg = address of the ISF
! WAS LOADED WHEN ISF WAS
SAVED!!!
mov %l3, %o0 ! o0 = 1st arg = vector number
call %g4
So, why is CPU_ISR_PASSES_FRAME_POINTER set to FALSE when the handler is
actually called with the frame pointer and some handler actually use it?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/3] bsps/irq: Remove BSP_INTERRUPT_VECTOR_MAX
On 18/06/2021 15:53, Sebastian Huber wrote:
On 18/06/2021 09:20, Sebastian Huber wrote:
diff --git a/bsps/sparc/erc32/include/bsp/irq.h
b/bsps/sparc/erc32/include/bsp/irq.h
index ad3a65fcc1..7bf6cff2ff 100644
--- a/bsps/sparc/erc32/include/bsp/irq.h
+++ b/bsps/sparc/erc32/include/bsp/irq.h
@@ -20,8 +20,7 @@
#include
-#define BSP_INTERRUPT_VECTOR_MAX_STD 15 /* Standard IRQ controller */
-#define BSP_INTERRUPT_VECTOR_MAX BSP_INTERRUPT_VECTOR_MAX_STD
+#define BSP_INTERRUPT_VECTOR_COUNT 16 /* Standard IRQ controller */
/* No extra check is needed */
#undef BSP_INTERRUPT_CUSTOM_VALID_VECTOR
diff --git a/bsps/sparc/leon2/include/bsp/irq.h
b/bsps/sparc/leon2/include/bsp/irq.h
index 287530e275..a85eefaf10 100644
--- a/bsps/sparc/leon2/include/bsp/irq.h
+++ b/bsps/sparc/leon2/include/bsp/irq.h
@@ -18,8 +18,7 @@
#ifndef LIBBSP_LEON2_IRQ_CONFIG_H
#define LIBBSP_LEON2_IRQ_CONFIG_H
-#define BSP_INTERRUPT_VECTOR_MAX_STD 15 /* Standard IRQ controller */
-#define BSP_INTERRUPT_VECTOR_MAX BSP_INTERRUPT_VECTOR_MAX_STD
+#define BSP_INTERRUPT_VECTOR_COUNT 16 /* Standard IRQ controller */
/* No extra check is needed */
#undef BSP_INTERRUPT_CUSTOM_VALID_VECTOR
diff --git a/bsps/sparc/leon3/include/bsp/irq.h
b/bsps/sparc/leon3/include/bsp/irq.h
index 77f9fc2528..980f3f5bfb 100644
--- a/bsps/sparc/leon3/include/bsp/irq.h
+++ b/bsps/sparc/leon3/include/bsp/irq.h
@@ -21,10 +21,7 @@
#include
#include
-#define BSP_INTERRUPT_VECTOR_MAX_STD 15 /* Standard IRQ controller */
-#define BSP_INTERRUPT_VECTOR_MAX_EXT 31 /* Extended IRQ controller */
-
-#define BSP_INTERRUPT_VECTOR_MAX BSP_INTERRUPT_VECTOR_MAX_EXT
+#define BSP_INTERRUPT_VECTOR_COUNT 32
/* The check is different depending on IRQ controller, runtime
detected */
#define BSP_INTERRUPT_CUSTOM_VALID_VECTOR
It seems that the SPARC processor and a "standard" interrupt controller
supports only 15 external interrupts (BSP_INTERRUPT_VECTOR_COUNT should
be 15 in this case) and some systems have an interrupt controller which
supports an extended interrupt which multiplex additional 16 interrupts
to a standard interrupt (BSP_INTERRUPT_VECTOR_COUNT should be 31 in this
case). Is this correct?
Actually, this doesn't fit with:
/* Initialize interrupts */
void BSP_shared_interrupt_init(void)
{
rtems_vector_number vector;
rtems_isr_entry previous_isr;
int i;
for (i=0; i <= BSP_INTERRUPT_VECTOR_MAX_STD; i++) {
#if defined(LEON3) && (defined(RTEMS_SMP) || defined(RTEMS_MULTIPROCESSING))
/* Don't install IRQ handler on IPI interrupt */
if (i == LEON3_mp_irq)
continue;
#endif
vector = SPARC_ASYNCHRONOUS_TRAP(i) + 0x10;
rtems_interrupt_catch(bsp_isr_handler, vector, &previous_isr);
}
/* Initalize interrupt support */
bsp_interrupt_initialize();
}
Can external interrupts end up in this trap:
SPARC_ASYNCHRONOUS_TRAP(0x10)? In start.S we have:
BAD_TRAP; ! 10 undefined
/*
* ERC32 defined traps
*/
BAD_TRAP; ! 11 masked errors
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/3] bsps/irq: Remove BSP_INTERRUPT_VECTOR_MAX
On 18/06/2021 09:20, Sebastian Huber wrote: diff --git a/bsps/sparc/erc32/include/bsp/irq.h b/bsps/sparc/erc32/include/bsp/irq.h index ad3a65fcc1..7bf6cff2ff 100644 --- a/bsps/sparc/erc32/include/bsp/irq.h +++ b/bsps/sparc/erc32/include/bsp/irq.h @@ -20,8 +20,7 @@ #include -#define BSP_INTERRUPT_VECTOR_MAX_STD 15 /* Standard IRQ controller */ -#define BSP_INTERRUPT_VECTOR_MAX BSP_INTERRUPT_VECTOR_MAX_STD +#define BSP_INTERRUPT_VECTOR_COUNT 16 /* Standard IRQ controller */ /* No extra check is needed */ #undef BSP_INTERRUPT_CUSTOM_VALID_VECTOR diff --git a/bsps/sparc/leon2/include/bsp/irq.h b/bsps/sparc/leon2/include/bsp/irq.h index 287530e275..a85eefaf10 100644 --- a/bsps/sparc/leon2/include/bsp/irq.h +++ b/bsps/sparc/leon2/include/bsp/irq.h @@ -18,8 +18,7 @@ #ifndef LIBBSP_LEON2_IRQ_CONFIG_H #define LIBBSP_LEON2_IRQ_CONFIG_H -#define BSP_INTERRUPT_VECTOR_MAX_STD 15 /* Standard IRQ controller */ -#define BSP_INTERRUPT_VECTOR_MAX BSP_INTERRUPT_VECTOR_MAX_STD +#define BSP_INTERRUPT_VECTOR_COUNT 16 /* Standard IRQ controller */ /* No extra check is needed */ #undef BSP_INTERRUPT_CUSTOM_VALID_VECTOR diff --git a/bsps/sparc/leon3/include/bsp/irq.h b/bsps/sparc/leon3/include/bsp/irq.h index 77f9fc2528..980f3f5bfb 100644 --- a/bsps/sparc/leon3/include/bsp/irq.h +++ b/bsps/sparc/leon3/include/bsp/irq.h @@ -21,10 +21,7 @@ #include #include -#define BSP_INTERRUPT_VECTOR_MAX_STD 15 /* Standard IRQ controller */ -#define BSP_INTERRUPT_VECTOR_MAX_EXT 31 /* Extended IRQ controller */ - -#define BSP_INTERRUPT_VECTOR_MAX BSP_INTERRUPT_VECTOR_MAX_EXT +#define BSP_INTERRUPT_VECTOR_COUNT 32 /* The check is different depending on IRQ controller, runtime detected */ #define BSP_INTERRUPT_CUSTOM_VALID_VECTOR It seems that the SPARC processor and a "standard" interrupt controller supports only 15 external interrupts (BSP_INTERRUPT_VECTOR_COUNT should be 15 in this case) and some systems have an interrupt controller which supports an extended interrupt which multiplex additional 16 interrupts to a standard interrupt (BSP_INTERRUPT_VECTOR_COUNT should be 31 in this case). Is this correct? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] part of implimenting a monotonic clock in rtems part of this is not the final patch.
Hello Zack,
On 18/06/2021 04:34, zack_on_the_speed_chanel wrote:
so I tested it with the but I have not made a new test file I'll do that soon. How
do I add a new test? All the tests that test the timer functionality do work.
I"m confident that all the changes I had to made to implement a monotonic clock
should be there.
Regarding a new test: Just grep for example for psxtimer01 in the
sources and add the new test simmilar to the existing one.
The most relevant files are spec/build/testsuites/psxtests/*.yml for the
waf based build system and testsuites/psxtests/Makefile.am and
.../configure.ac for the old build system.
But please check whether you need a new test program. If you basically
only copy the test routine of psxtimer01 or psxtimer02 and replace all
CLOCK_REALTIME by CLOCK_MONOTONIC then you shouldn't add a new test.
Instead create a function in the test that is called once with
CLOCK_REALTIME and once with CLOCK_MONOTONIC.
Please make sure that the test not only tests the API but also whether
the timer work as expected. A timer with CLOCK_REALTIME can be affected
by changes in the wall clock. CLOCK_MONOTONIC should not be affected. So
please make sure that your test checks whether that is really the case.
Best regards
Christian
Thanks
Zack
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Tuesday, June 15th, 2021 at 7:29 AM, Christian Mauderer
wrote:
If you add a new functionallity you should add a test that tests the
expected behaviour. You just shouldn't replace one but add a new test or
a new test case to an existing test.
Best regards
Christian
On 14/06/2021 22:18, zack_on_the_speed_chanel wrote:
also i'll revert the posix test that I changed back to normal because it was
only for testing.
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Monday, June 14th, 2021 at 8:14 PM, zack_on_the_speed_chanel
zack_on_the_speed_cha...@protonmail.ch wrote:
I've made most of the corrections to the code. I fixed up the formatting but I
still don't know if I have to add anything for the settime and delete_timer().
i assume as the monotonic clock only affects the value I think it's all I have
to do. I also can try to modify a posix test to check my theory.
Thanks
Zack
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, June 12th, 2021 at 9:31 AM, Christian Mauderer o...@c-mauderer.de
wrote:
Hello Zack,
I don't really know a lot about the timer toppic. So this is more of a
style and general suggestion review.
On 09/06/2021 20:27, zack wrote:
From: zack zack_on_the_speed_cha...@protonmail.ch
cpukit/include/rtems/posix/timer.h | 6 ++-
cpukit/posix/src/psxtimercreate.c | 5 +-
cpukit/posix/src/timergettime.c | 61 ---
testsuites/psxtests/psxtimer02/psxtimer.c | 26 +++---
4 files changed, 81 insertions(+), 17 deletions(-)
diff --git a/cpukit/include/rtems/posix/timer.h
b/cpukit/include/rtems/posix/timer.h
index bcbf07a65a..f8cf6115b2 100644
--- a/cpukit/include/rtems/posix/timer.h
+++ b/cpukit/include/rtems/posix/timer.h
@@ -21,7 +21,7 @@
#include
#include
-
I think the blank line separated rtems includes from others. So please
don't remove it.
+#include
#include
#ifdef __cplusplus
@@ -47,7 +47,9 @@ typedef struct {
struct itimerspec timer_data; /* Timing data of the timer /
uint32_t ticks; / Number of ticks of the initialization /
uint32_t overrun; / Number of expirations of the timer */
- struct timespec time; /* Time at which the timer was started */
- struct timespec time; /* Time at which the timer was started */
Not sure what changed in that line. Looks like a whitespace change.
Please avoid these.
- clockid_t clock_type;
Why a blank line?
} POSIX_Timer_Control;
/**
diff --git a/cpukit/posix/src/psxtimercreate.c
b/cpukit/posix/src/psxtimercreate.c
index a63cf1d100..e78c359bd5 100644
--- a/cpukit/posix/src/psxtimercreate.c
+++ b/cpukit/posix/src/psxtimercreate.c
@@ -40,7 +40,7 @@ int timer_create(
{
POSIX_Timer_Control *ptimer;
- if ( clock_id != CLOCK_REALTIME )
- if ( clock_id != CLOCK_REALTIME || clock_id != CLOCK_MONOTONIC )
Not sure about that one. It's allways a bit difficult whith these
constructions but I think this one is allways true and therefore will
allways return an error.
Let's assume clock_id is CLOCK_MONOTONIC. In that case (clock_id !=
CLOCK_REALTIME) is true which means that the function will return with
an error. The same works for CLOCK_RREALTIME and the second condition.
If you apply De Morgan to the term you see that
(clock_id != CLOCK_REALTIME || clock_id != CLOCK_MONOTONIC)
is the same as
!(clock_id == CLOCK_REALTIME && clock_id == CLOCK_MONOTONIC)
The two inner comparisons are exclusive. So that won't work.
What you most likely want is a
!(clock_id == CLOCK_REALTIME || clock_id == CLOCK_MONOTONIC)
or with De Morgan aga
Re: [PATCH v6 1/2] Update Strong APA Scheduler
On 16/06/2021 08:00, Richi Dubey wrote: This change allows for the migration of higher priority tasks on the arrival of a lower priority task limited by affinity constraints. Thanks, for the update. I will integrate this next week. If not, please send me a reminder. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/3] Simplify generic interrupt controller support
This patch set simplifies the generic interrupt controller support a bit to prepare for more complex follow up changes. Sebastian Huber (3): bsps/irq: Remove BSP_INTERRUPT_NO_HEAP_USAGE bsps/irq: Remove BSP_INTERRUPT_VECTOR_MIN bsps/irq: Remove BSP_INTERRUPT_VECTOR_MAX bsps/aarch64/a53/include/bsp/irq.h| 3 +- bsps/aarch64/a72/include/bsp/irq.h| 3 +- bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h | 3 +- bsps/arm/altera-cyclone-v/include/bsp/irq.h | 4 +-- bsps/arm/atsam/include/bsp/irq.h | 4 +-- bsps/arm/atsam/start/bspstart.c | 2 +- bsps/arm/beagle/include/bsp/irq.h | 3 +- bsps/arm/beagle/irq/irq.c | 2 +- bsps/arm/csb336/include/bsp/irq.h | 4 +-- bsps/arm/csb337/include/bsp/irq.h | 4 +-- bsps/arm/edb7312/include/bsp/irq.h| 4 +-- bsps/arm/fvp/include/bsp/irq.h| 4 +-- bsps/arm/gumstix/include/bsp/irq.h| 4 +-- bsps/arm/imx/include/bsp/irq.h| 3 +- bsps/arm/imxrt/include/bsp/irq.h | 3 +- bsps/arm/lm3s69xx/include/bsp/irq.h | 3 +- bsps/arm/lpc176x/include/bsp/irq.h| 4 +-- bsps/arm/lpc176x/irq/irq.c| 2 +- bsps/arm/lpc24xx/include/bsp/irq.h| 6 ++-- bsps/arm/lpc24xx/irq/irq.c| 4 +-- bsps/arm/lpc32xx/include/bsp/irq.h| 5 ++- bsps/arm/raspberrypi/include/bsp/irq.h| 5 ++- bsps/arm/realview-pbx-a9/include/bsp/irq.h| 3 +- bsps/arm/rtl22xx/include/bsp/irq.h| 4 +-- bsps/arm/shared/irq/irq-armv7m.c | 2 +- bsps/arm/shared/start/start.S | 2 +- bsps/arm/smdk2410/include/bsp/irq.h | 4 +-- bsps/arm/stm32f4/include/bsp/irq.h| 3 +- bsps/arm/stm32h7/include/bsp/irq.h| 4 +-- bsps/arm/tms570/include/bsp/irq.h | 3 +- bsps/arm/tms570/irq/irq.c | 2 +- bsps/arm/xen/include/bsp/irq.h| 3 +- bsps/arm/xilinx-zynq/include/bsp/irq.h| 3 +- bsps/arm/xilinx-zynqmp/include/bsp/irq.h | 3 +- bsps/i386/include/bsp/irq.h | 3 +- bsps/include/bsp/irq-default.h| 7 +--- bsps/include/bsp/irq-generic.h| 30 +--- bsps/lm32/include/bsp/irq.h | 7 +--- bsps/m68k/genmcf548x/include/bsp/irq.h| 4 +-- bsps/m68k/genmcf548x/irq/irq.c| 2 +- bsps/mips/csb350/include/bsp/irq.h| 3 +- bsps/mips/hurricane/include/bsp/irq.h | 3 +- bsps/mips/jmr3904/include/bsp/irq.h | 4 +-- bsps/mips/malta/include/bsp/irq.h | 4 +-- bsps/mips/rbtx4925/include/bsp/irq.h | 3 +- bsps/mips/rbtx4938/include/bsp/irq.h | 3 +- bsps/mips/shared/irq/irq.c| 2 +- bsps/or1k/generic_or1k/include/bsp/irq.h | 3 +- bsps/powerpc/gen5200/include/bsp/irq.h| 4 +-- bsps/powerpc/gen83xx/include/bsp/irq.h| 4 +-- .../motorola_powerpc/include/bsp/irq.h| 3 +- bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 5 +-- bsps/powerpc/mpc8260ads/include/bsp/irq.h | 4 +-- bsps/powerpc/psim/include/bsp/irq.h | 3 +- bsps/powerpc/qemuppc/include/bsp/irq.h| 4 +-- bsps/powerpc/qoriq/include/bsp/irq.h | 6 ++-- bsps/powerpc/qoriq/irq/irq.c | 6 ++-- bsps/powerpc/t32mppc/include/bsp/irq.h| 3 +- bsps/powerpc/tqm8xx/include/bsp/irq.h | 4 +-- bsps/powerpc/virtex/include/bsp/irq.h | 3 +- bsps/riscv/griscv/include/bsp/irq.h | 4 +-- bsps/riscv/riscv/include/bsp/irq.h| 4 +-- bsps/shared/irq/irq-generic.c | 36 +++ bsps/shared/irq/irq-info.c| 2 +- bsps/shared/irq/irq-server.c | 2 +- bsps/sparc/erc32/include/bsp/irq.h| 4 +-- bsps/sparc/leon2/include/bsp/irq.h| 4 +-- bsps/sparc/leon3/include/bsp/irq.h| 10 ++ bsps/sparc/shared/irq/irq-shared.c| 2 +- bsps/x86_64/include/bsp/irq.h | 3 +- testsuites/smptests/smpcapture02/init.c | 2 +- 71 files changed, 92 insertions(+), 223 deletions(-) -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] bsps/irq: Remove BSP_INTERRUPT_VECTOR_MIN
This define was defined to be zero for all BSP except:
* or1k/generic_or1k which has only an incomplete implementation.
* m68k/genmcf548x which is a special case. This BSP uses a custom
implementation for libbsd compatibility. This custom implementation didn't
use BSP_INTERRUPT_VECTOR_MIN.
The BSP_INTERRUPT_VECTOR_MIN == 0 condition was tested by a temporary static
assertion and building all BSPs.
Update #3269.
---
bsps/aarch64/a53/include/bsp/irq.h | 1 -
bsps/aarch64/a72/include/bsp/irq.h | 1 -
bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h | 1 -
bsps/arm/altera-cyclone-v/include/bsp/irq.h| 1 -
bsps/arm/atsam/include/bsp/irq.h | 2 --
bsps/arm/beagle/include/bsp/irq.h | 1 -
bsps/arm/beagle/irq/irq.c | 2 +-
bsps/arm/csb336/include/bsp/irq.h | 2 --
bsps/arm/csb337/include/bsp/irq.h | 2 --
bsps/arm/edb7312/include/bsp/irq.h | 2 --
bsps/arm/fvp/include/bsp/irq.h | 2 --
bsps/arm/gumstix/include/bsp/irq.h | 2 --
bsps/arm/imx/include/bsp/irq.h | 1 -
bsps/arm/imxrt/include/bsp/irq.h | 1 -
bsps/arm/lm3s69xx/include/bsp/irq.h| 1 -
bsps/arm/lpc176x/include/bsp/irq.h | 2 --
bsps/arm/lpc24xx/include/bsp/irq.h | 2 --
bsps/arm/lpc24xx/irq/irq.c | 2 +-
bsps/arm/lpc32xx/include/bsp/irq.h | 1 -
bsps/arm/raspberrypi/include/bsp/irq.h | 1 -
bsps/arm/realview-pbx-a9/include/bsp/irq.h | 1 -
bsps/arm/rtl22xx/include/bsp/irq.h | 2 --
bsps/arm/shared/irq/irq-armv7m.c | 2 +-
bsps/arm/smdk2410/include/bsp/irq.h| 2 --
bsps/arm/stm32f4/include/bsp/irq.h | 1 -
bsps/arm/stm32h7/include/bsp/irq.h | 2 --
bsps/arm/tms570/include/bsp/irq.h | 1 -
bsps/arm/xen/include/bsp/irq.h | 1 -
bsps/arm/xilinx-zynq/include/bsp/irq.h | 1 -
bsps/arm/xilinx-zynqmp/include/bsp/irq.h | 1 -
bsps/i386/include/bsp/irq.h| 1 -
bsps/include/bsp/irq-default.h | 5 -
bsps/include/bsp/irq-generic.h | 18 --
bsps/lm32/include/bsp/irq.h| 5 -
bsps/m68k/genmcf548x/include/bsp/irq.h | 2 --
bsps/mips/csb350/include/bsp/irq.h | 1 -
bsps/mips/hurricane/include/bsp/irq.h | 1 -
bsps/mips/jmr3904/include/bsp/irq.h| 2 --
bsps/mips/malta/include/bsp/irq.h | 2 --
bsps/mips/rbtx4925/include/bsp/irq.h | 1 -
bsps/mips/rbtx4938/include/bsp/irq.h | 1 -
bsps/or1k/generic_or1k/include/bsp/irq.h | 1 -
bsps/powerpc/gen5200/include/bsp/irq.h | 2 --
bsps/powerpc/gen83xx/include/bsp/irq.h | 2 --
.../powerpc/motorola_powerpc/include/bsp/irq.h | 1 -
bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 2 --
bsps/powerpc/mpc8260ads/include/bsp/irq.h | 2 --
bsps/powerpc/psim/include/bsp/irq.h| 1 -
bsps/powerpc/qemuppc/include/bsp/irq.h | 2 --
bsps/powerpc/qoriq/include/bsp/irq.h | 2 --
bsps/powerpc/qoriq/irq/irq.c | 6 +++---
bsps/powerpc/t32mppc/include/bsp/irq.h | 1 -
bsps/powerpc/tqm8xx/include/bsp/irq.h | 2 --
bsps/powerpc/virtex/include/bsp/irq.h | 1 -
bsps/riscv/griscv/include/bsp/irq.h| 2 --
bsps/riscv/riscv/include/bsp/irq.h | 2 --
bsps/shared/irq/irq-info.c | 2 +-
bsps/sparc/erc32/include/bsp/irq.h | 1 -
bsps/sparc/leon2/include/bsp/irq.h | 1 -
bsps/sparc/leon3/include/bsp/irq.h | 1 -
bsps/x86_64/include/bsp/irq.h | 1 -
testsuites/smptests/smpcapture02/init.c| 2 +-
62 files changed, 16 insertions(+), 104 deletions(-)
diff --git a/bsps/aarch64/a53/include/bsp/irq.h
b/bsps/aarch64/a53/include/bsp/irq.h
index f7a4f1ad1f..e1aebf5a22 100644
--- a/bsps/aarch64/a53/include/bsp/irq.h
+++ b/bsps/aarch64/a53/include/bsp/irq.h
@@ -48,7 +48,6 @@
extern "C" {
#endif /* __cplusplus */
-#define BSP_INTERRUPT_VECTOR_MIN 0
#define BSP_INTERRUPT_VECTOR_MAX 1023
/* Interrupts vectors */
diff --git a/bsps/aarch64/a72/include/bsp/irq.h
b/bsps/aarch64/a72/include/bsp/irq.h
index c3de523d48..71076ed82a 100644
--- a/bsps/aarch64/a72/include/bsp/irq.h
+++ b/bsps/aarch64/a72/include/bsp/irq.h
@@ -48,7 +48,6 @@
extern "C" {
#endif /* __cplusplus */
-#define BSP_INTERRUPT_VECTOR_MIN 0
#define BSP_INTERRUPT_VECTOR_MAX 1023
/* Interrupts vectors */
diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h
b/bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h
index 13ce55d5b9..f12a4536b5 100644
--- a/bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h
+++ b/bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h
@@ -48,7 +48,6 @@
extern "C" {
#endif /* __cplusplus */
-#define
[PATCH 3/3] bsps/irq: Remove BSP_INTERRUPT_VECTOR_MAX
Replace it with BSP_INTERRUPT_VECTOR_COUNT. This allows a default
implementation which supports no interrupt vector at all.
Using COUNT instead of MAX may avoid some interpretation issues, for example is
the maximum value a valid vector number or not. The change shows that
BSP_INTERRUPT_VECTOR_MAX was a bit misleading since there was an off by one
error in some BSPs.
Update #3269.
---
bsps/aarch64/a53/include/bsp/irq.h | 2 +-
bsps/aarch64/a72/include/bsp/irq.h | 2 +-
bsps/aarch64/xilinx-zynqmp/include/bsp/irq.h| 2 +-
bsps/arm/altera-cyclone-v/include/bsp/irq.h | 3 ++-
bsps/arm/atsam/include/bsp/irq.h| 2 +-
bsps/arm/atsam/start/bspstart.c | 2 +-
bsps/arm/beagle/include/bsp/irq.h | 2 +-
bsps/arm/beagle/irq/irq.c | 2 +-
bsps/arm/csb336/include/bsp/irq.h | 2 +-
bsps/arm/csb337/include/bsp/irq.h | 2 +-
bsps/arm/edb7312/include/bsp/irq.h | 2 +-
bsps/arm/fvp/include/bsp/irq.h | 2 +-
bsps/arm/gumstix/include/bsp/irq.h | 2 +-
bsps/arm/imx/include/bsp/irq.h | 2 +-
bsps/arm/imxrt/include/bsp/irq.h| 2 +-
bsps/arm/lm3s69xx/include/bsp/irq.h | 2 +-
bsps/arm/lpc176x/include/bsp/irq.h | 2 +-
bsps/arm/lpc176x/irq/irq.c | 2 +-
bsps/arm/lpc24xx/include/bsp/irq.h | 4 ++--
bsps/arm/lpc24xx/irq/irq.c | 4 ++--
bsps/arm/lpc32xx/include/bsp/irq.h | 4 ++--
bsps/arm/raspberrypi/include/bsp/irq.h | 4 ++--
bsps/arm/realview-pbx-a9/include/bsp/irq.h | 2 +-
bsps/arm/rtl22xx/include/bsp/irq.h | 2 +-
bsps/arm/shared/irq/irq-armv7m.c| 2 +-
bsps/arm/shared/start/start.S | 2 +-
bsps/arm/smdk2410/include/bsp/irq.h | 2 +-
bsps/arm/stm32f4/include/bsp/irq.h | 2 +-
bsps/arm/stm32h7/include/bsp/irq.h | 2 +-
bsps/arm/tms570/include/bsp/irq.h | 2 +-
bsps/arm/tms570/irq/irq.c | 2 +-
bsps/arm/xen/include/bsp/irq.h | 2 +-
bsps/arm/xilinx-zynq/include/bsp/irq.h | 2 +-
bsps/arm/xilinx-zynqmp/include/bsp/irq.h| 2 +-
bsps/i386/include/bsp/irq.h | 2 +-
bsps/include/bsp/irq-default.h | 2 +-
bsps/include/bsp/irq-generic.h | 16 +++-
bsps/lm32/include/bsp/irq.h | 2 +-
bsps/m68k/genmcf548x/include/bsp/irq.h | 2 +-
bsps/m68k/genmcf548x/irq/irq.c | 2 +-
bsps/mips/csb350/include/bsp/irq.h | 2 +-
bsps/mips/hurricane/include/bsp/irq.h | 2 +-
bsps/mips/jmr3904/include/bsp/irq.h | 2 +-
bsps/mips/malta/include/bsp/irq.h | 2 +-
bsps/mips/rbtx4925/include/bsp/irq.h| 2 +-
bsps/mips/rbtx4938/include/bsp/irq.h| 2 +-
bsps/mips/shared/irq/irq.c | 2 +-
bsps/or1k/generic_or1k/include/bsp/irq.h| 2 +-
bsps/powerpc/gen5200/include/bsp/irq.h | 2 +-
bsps/powerpc/gen83xx/include/bsp/irq.h | 2 +-
bsps/powerpc/motorola_powerpc/include/bsp/irq.h | 2 +-
bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 2 +-
bsps/powerpc/mpc8260ads/include/bsp/irq.h | 2 +-
bsps/powerpc/psim/include/bsp/irq.h | 2 +-
bsps/powerpc/qemuppc/include/bsp/irq.h | 2 +-
bsps/powerpc/qoriq/include/bsp/irq.h| 4 ++--
bsps/powerpc/qoriq/irq/irq.c| 6 +++---
bsps/powerpc/t32mppc/include/bsp/irq.h | 2 +-
bsps/powerpc/tqm8xx/include/bsp/irq.h | 2 +-
bsps/powerpc/virtex/include/bsp/irq.h | 2 +-
bsps/riscv/griscv/include/bsp/irq.h | 2 +-
bsps/riscv/riscv/include/bsp/irq.h | 2 +-
bsps/shared/irq/irq-generic.c | 2 +-
bsps/shared/irq/irq-info.c | 2 +-
bsps/shared/irq/irq-server.c| 2 +-
bsps/sparc/erc32/include/bsp/irq.h | 3 +--
bsps/sparc/leon2/include/bsp/irq.h | 3 +--
bsps/sparc/leon3/include/bsp/irq.h | 9 +++--
bsps/sparc/shared/irq/irq-shared.c | 2 +-
bsps/x86_64/include/bsp/irq.h | 2 +-
testsuites/smptests/smpcapture02/init.c | 2 +-
71 files changed, 87 insertions(+), 93 deletions(-)
diff --git a/bsps/aarch64/a53/include/bsp/irq.h
b/bsps/aarch64/a53/include/bsp/irq.h
index e1aebf5a22..b797408ca5 100644
--- a/bsps/aarch64/a53/include/bsp/irq.h
+++ b/bsps/aarch64/a53/include/bsp/irq.h
@@ -48,7 +48,7 @@
extern "C" {
#endif /* __cplusplus */
-#define BSP_INTERRUPT_VECTOR_MAX 1023
+#define BSP_INTERRUPT_VECTOR_COUNT 1024
/* Interrupts vectors */
#define BSP_TIMER_VIRT_PPI 27
diff --git a/bsps/aarch64/a72/include/bsp/irq.h
b/bsps/aarch64/
[PATCH 1/3] bsps/irq: Remove BSP_INTERRUPT_NO_HEAP_USAGE
Remove the support for BSP_INTERRUPT_NO_HEAP_USAGE. This was only used
by one BSP and provides no real benefit.
Update #3269.
---
bsps/include/bsp/irq-generic.h| 8 --
bsps/powerpc/mpc55xxevb/include/bsp/irq.h | 1 -
bsps/shared/irq/irq-generic.c | 34 ++-
3 files changed, 3 insertions(+), 40 deletions(-)
diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
index 4135aa518c..e888a66cea 100644
--- a/bsps/include/bsp/irq-generic.h
+++ b/bsps/include/bsp/irq-generic.h
@@ -66,10 +66,6 @@ extern "C" {
#error "if you define BSP_INTERRUPT_USE_INDEX_TABLE, you have to define
BSP_INTERRUPT_HANDLER_TABLE_SIZE etc. as well"
#endif
-#if defined(BSP_INTERRUPT_NO_HEAP_USAGE) &&
!defined(BSP_INTERRUPT_USE_INDEX_TABLE)
- #error "if you define BSP_INTERRUPT_NO_HEAP_USAGE, you have to define
BSP_INTERRUPT_USE_INDEX_TABLE etc. as well"
-#endif
-
#define BSP_INTERRUPT_VECTOR_NUMBER \
(BSP_INTERRUPT_VECTOR_MAX - BSP_INTERRUPT_VECTOR_MIN + 1)
@@ -150,10 +146,6 @@ static inline rtems_vector_number
bsp_interrupt_handler_index(
* table will be accessed via a small index table. You can define the size of
* the handler table with @ref BSP_INTERRUPT_HANDLER_TABLE_SIZE.
*
- * Normally new list entries are allocated from the heap. You may define
- * @ref BSP_INTERRUPT_NO_HEAP_USAGE, if you do not want to use the heap. For
- * this option you have to define @ref BSP_INTERRUPT_USE_INDEX_TABLE as well.
- *
* You have to provide some special routines in your BSP (follow the links for
* the details):
* - bsp_interrupt_facility_initialize()
diff --git a/bsps/powerpc/mpc55xxevb/include/bsp/irq.h
b/bsps/powerpc/mpc55xxevb/include/bsp/irq.h
index c923859dec..491c120ee8 100644
--- a/bsps/powerpc/mpc55xxevb/include/bsp/irq.h
+++ b/bsps/powerpc/mpc55xxevb/include/bsp/irq.h
@@ -483,7 +483,6 @@ rtems_status_code
mpc55xx_intc_clear_software_irq(rtems_vector_number vector);
#ifdef BSP_INTERRUPT_HANDLER_TABLE_SIZE
#define BSP_INTERRUPT_USE_INDEX_TABLE
- #define BSP_INTERRUPT_NO_HEAP_USAGE
#endif
/** @} */
diff --git a/bsps/shared/irq/irq-generic.c b/bsps/shared/irq/irq-generic.c
index 1e83a6f249..abe732a9d3 100644
--- a/bsps/shared/irq/irq-generic.c
+++ b/bsps/shared/irq/irq-generic.c
@@ -142,34 +142,6 @@ static inline bool bsp_interrupt_allocate_handler_index(
#endif
}
-static bsp_interrupt_handler_entry *bsp_interrupt_allocate_handler_entry(void)
-{
- bsp_interrupt_handler_entry *e;
-
- #ifdef BSP_INTERRUPT_NO_HEAP_USAGE
-rtems_vector_number index = 0;
-
-if (bsp_interrupt_allocate_handler_index(0, &index)) {
- e = &bsp_interrupt_handler_table [index];
-} else {
- e = NULL;
-}
- #else
-e = rtems_malloc(sizeof(*e));
- #endif
-
- return e;
-}
-
-static void bsp_interrupt_free_handler_entry(bsp_interrupt_handler_entry *e)
-{
- #ifdef BSP_INTERRUPT_NO_HEAP_USAGE
-bsp_interrupt_clear_handler_entry(e, 0);
- #else
-free(e);
- #endif
-}
-
void bsp_interrupt_initialize(void)
{
rtems_status_code sc = RTEMS_SUCCESSFUL;
@@ -318,7 +290,7 @@ static rtems_status_code bsp_interrupt_handler_install(
}
/* Allocate a new entry */
- current = bsp_interrupt_allocate_handler_entry();
+ current = rtems_malloc(sizeof(*current));
if (current == NULL) {
/* Not enough memory */
bsp_interrupt_unlock();
@@ -433,7 +405,7 @@ static rtems_status_code bsp_interrupt_handler_remove(
match->next = current->next;
bsp_interrupt_enable(level);
- bsp_interrupt_free_handler_entry(current);
+ free(current);
} else if (match == head) {
/*
* The match is the list head and has no successor.
@@ -465,7 +437,7 @@ static rtems_status_code bsp_interrupt_handler_remove(
bsp_interrupt_fence(ATOMIC_ORDER_RELEASE);
bsp_interrupt_enable(level);
- bsp_interrupt_free_handler_entry(match);
+ free(match);
}
} else {
/* No matching entry found */
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
