Re: Device Drivers Which Include mkdir("/dev")

On Fri, Feb 19, 2021, 5:32 PM Chris Johns wrote: > On 20/2/21 7:56 am, Joel Sherrill wrote: > > On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom > > wrote: > > > > I think the suggestion is to provide a catch-all rather than try to > add new > > faults for every poss

Re: Device Drivers Which Include mkdir("/dev")

On 20/2/21 7:56 am, Joel Sherrill wrote: > On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom > wrote: > > I think the suggestion is to provide a catch-all rather than try to add > new > faults for every possible condition. This mkdir is a pretty esoteric fault > t

Re: Device Drivers Which Include mkdir("/dev")

On Fri, Feb 19, 2021 at 2:51 PM Gedare Bloom wrote: > I think the suggestion is to provide a catch-all rather than try to add > new faults for every possible condition. This mkdir is a pretty esoteric > fault that is unlikely to happen in properly developed code. > Then why shouldn't this just b

Re: Device Drivers Which Include mkdir("/dev")

I think the suggestion is to provide a catch-all rather than try to add new faults for every possible condition. This mkdir is a pretty esoteric fault that is unlikely to happen in properly developed code. On Fri, Feb 19, 2021, 11:03 AM Joel Sherrill wrote: > > > On Fri, Feb 19, 2021 at 9:48 AM

Re: Device Drivers Which Include mkdir("/dev")

On Fri, Feb 19, 2021 at 9:48 AM Gedare Bloom wrote: > On Thu, Feb 18, 2021 at 11:32 PM Sebastian Huber > wrote: > > > > On 18/02/2021 21:08, Gedare Bloom wrote: > > > > >> Grrr.. I've looked again at the code and it is all Gaisler code doing > something > > >> like mkdir("/dev/leonXXX"). It real

RE: [PATCH v1 1/2] score: Enforce stack_end alignment

I'll make sure to address the proper use of RTEMS_ALIGN_* in the updated patch if it is still necessary, thanks! Kinsey -Original Message- From: Gedare Bloom Sent: Friday, February 19, 2021 10:55 To: Kinsey Moore Cc: devel@rtems.org Subject: Re: [PATCH v1 1/2] score: Enforce stack_end

RE: [PATCH v1 1/2] score: Enforce stack_end alignment

On 2021/02/19 01:08, Sebastian Huber wrote: > On 19/02/2021 07:12, Sebastian Huber wrote: >> I think the bug is in _TLS_Get_allocation_size(). It assumes >> CPU_HEAP_ALIGNMENT >= CPU_STACK_ALIGNMENT. It should probably use the >> maximum of these two values. The only usage of CPU_HEAP_ALIGNMENT in

Re: [PATCH v2 4/4] rtems: Avoid potential recursion in ASR handling

On Fri, Feb 19, 2021 at 2:42 AM Sebastian Huber wrote: > > On 19/02/2021 10:40, Sebastian Huber wrote: > > > + if ( > > +normal_asr_is_enabled && > > + !previous_asr_is_enabled && > > + asr->signals_pending != 0 > > + ) { > > +_Thread_Append_post_switch_action( executing, actio

Re: [PATCH v2 2/4] rtems: New errors for rtems_signal_catch()

On Fri, Feb 19, 2021 at 2:40 AM Sebastian Huber wrote: > > Ensure that no invalid modes are set during ASR processing. > > Update #4244. > --- > cpukit/include/rtems/rtems/modesimpl.h | 48 ++ > cpukit/rtems/src/signalcatch.c | 15 > cpukit/rtems/src/taskm

Re: [PATCH 05/13] posix: Remove superfluous check

On Fri, Feb 19, 2021 at 9:46 AM Joel Sherrill wrote: > > > > On Fri, Feb 19, 2021, 10:31 AM Gedare Bloom wrote: >> >> On Thu, Feb 18, 2021 at 11:56 PM Sebastian Huber >> wrote: >> > >> > On 18/02/2021 20:25, Joel Sherrill wrote: >> > >> > > > - /* >> > > > - * api may be NULL in case

Re: [PATCH rtems-docs] user/bsps: Mention fixed console baud rate for zynq

On Fri, Feb 19, 2021 at 1:21 AM Jan Sommer wrote: > > --- > user/bsps/arm/xilinx-zynq.rst | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/arm/xilinx-zynq.rst > index 365c336..dcc0649 100644 > --- a/user/bsps/arm/xilinx-zynq.rst >

Re: [PATCH v1 1/2] score: Enforce stack_end alignment

On Thu, Feb 18, 2021 at 11:59 AM Kinsey Moore wrote: > > The size of the reserved TLS space is not guaranteed to adhere to stack > alignment requirements which can cause stack_end to become misaligned. > This enforces the alignment of stack_end. > --- > cpukit/score/src/threadinitialize.c | 4 +++

Re: [PATCH 11/13] rtems: New errors for rtems_signal_catch()

On Fri, Feb 19, 2021 at 12:00 AM Sebastian Huber wrote: > > On 18/02/2021 20:29, Joel Sherrill wrote: > > > > > > > On Thu, Feb 18, 2021 at 11:32 AM Gedare Bloom > > wrote: > > > > On Wed, Feb 17, 2021 at 12:30 PM Sebastian Huber > > >

Re: [PATCH 12/13] rtems: Add _Modes_Set_timeslice()

On Thu, Feb 18, 2021 at 11:59 PM Sebastian Huber wrote: > > On 18/02/2021 18:37, Gedare Bloom wrote: > > >> +RTEMS_INLINE_ROUTINE void _Modes_Set_timeslice( > > I don't really like the name. It implies we want to set timeslicing true. > > > > _Modes_Update_timeslice() may be better? > > > > I just

Re: [PATCH 05/13] posix: Remove superfluous check

On Fri, Feb 19, 2021, 10:31 AM Gedare Bloom wrote: > On Thu, Feb 18, 2021 at 11:56 PM Sebastian Huber > wrote: > > > > On 18/02/2021 20:25, Joel Sherrill wrote: > > > > > > - /* > > > > - * api may be NULL in case of a thread close in progress > > > > - */ > > > > - if ( !a

Re: [PATCH 13/13] rtems: Avoid potential recursion in ASR handling

On Fri, Feb 19, 2021 at 9:35 AM Gedare Bloom wrote: > > On Thu, Feb 18, 2021 at 11:59 PM Sebastian Huber > wrote: > > > > On 18/02/2021 18:49, Gedare Bloom wrote: > > > > >> + executing->cpu_time_budget = normal_cpu_time_budget ; > > >> + executing->budget_algorithm = normal_budget_algorithm ;

Re: [PATCH 13/13] rtems: Avoid potential recursion in ASR handling

On Thu, Feb 18, 2021 at 11:59 PM Sebastian Huber wrote: > > On 18/02/2021 18:49, Gedare Bloom wrote: > > >> + executing->cpu_time_budget = normal_cpu_time_budget ; > >> + executing->budget_algorithm = normal_budget_algorithm ; > >> + prev_is_preemptible = executing->is_preemptible; > > 'prev' i

Re: [PATCH 05/13] posix: Remove superfluous check

On Thu, Feb 18, 2021 at 11:56 PM Sebastian Huber wrote: > > On 18/02/2021 20:25, Joel Sherrill wrote: > > > > - /* > > > - * api may be NULL in case of a thread close in progress > > > - */ > > > - if ( !api ) > > > -return; > > > - > > I believe you, but shou

Re: Device Drivers Which Include mkdir("/dev")

On Thu, Feb 18, 2021 at 11:32 PM Sebastian Huber wrote: > > On 18/02/2021 21:08, Gedare Bloom wrote: > > >> Grrr.. I've looked again at the code and it is all Gaisler code doing > >> something > >> like mkdir("/dev/leonXXX"). It really could fail. This should be a fatal > >> error > >> and would

[PATCH v4 1/3] bsps/xilinx_zynq: Add SPI driver for cadence-spi

--- bsps/include/dev/spi/cadence-spi-regs.h | 84 + bsps/include/dev/spi/cadence-spi.h | 48 +++ bsps/shared/dev/spi/cadence-spi.c | 437 3 files changed, 569 insertions(+) create mode 100644 bsps/include/dev/spi/cadence-spi-regs.h create mode 100644 bsp

[PATCH v4 0/3] Add cadence-SPI driver

v4: - Use copyright information without UTF-8 characters v3: - Fix wrong changes to spec/build/bsps/arm/xilinx-zynq/obj.yml v2: - Moved source file to bsps/shared/dev/spi - Moved include files to bsps/include/dev/spi - Enabled build in aarch64 BSPs v1: This patchset implements a driver for the

[PATCH v4 3/3] bsps/xilinx_zynq: Add SPI driver to autotools build

--- bsps/headers.am| 5 + c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am | 3 +++ c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am | 3 +++ 3 files changed, 11 insertions(+) diff --git a/bsps/headers.am b/bsps/headers.am index 1b82382db8..37ce6d6c73 100644 --- a/

[PATCH v4 2/3] bsps/xilinx_zynq: Add SPI driver to waf

--- spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml | 2 ++ spec/build/bsps/arm/xilinx-zynq/grp.yml| 2 ++ .../bsps/arm/xilinx-zynqmp/bspxilinxzynqmp.yml | 2 ++ spec/build/bsps/objdevspizynq.yml | 18 ++ 4 files changed, 24 insertions(+) create mode 100644

Re: [PATCH v2 4/4] rtems: Avoid potential recursion in ASR handling

On 19/02/2021 10:40, Sebastian Huber wrote: + if ( +normal_asr_is_enabled && + !previous_asr_is_enabled && + asr->signals_pending != 0 + ) { +_Thread_Append_post_switch_action( executing, action ); + } I will fix the alignment before I check it in. -- embedded brains GmbH

[PATCH v2 0/4] Avoid potential recursion in ASR handling

This patch set fixes a potential issue with a recursion in the ASR handling. The main issue is that _Signal_Action_handler() used rtems_task_mode() to save, set, and restore the task mode during ASR processing. This is effectively a recursive call to thread dispatching which may result in the nex

[PATCH v2 1/4] rtems: Remove _Modes_Set_interrupt_level()

This call just obfuscated the call to _ISR_Set_level(). Update #4244. --- cpukit/include/rtems/rtems/modesimpl.h | 14 -- cpukit/rtems/src/taskmode.c| 3 ++- 2 files changed, 2 insertions(+), 15 deletions(-) diff --git a/cpukit/include/rtems/rtems/modesimpl.h b/cpukit/i

[PATCH v2 3/4] rtems: Add _Modes_Apply_timeslice_to_thread()

Update #4244. --- cpukit/include/rtems/rtems/modesimpl.h | 21 + cpukit/rtems/src/taskmode.c| 8 +--- 2 files changed, 22 insertions(+), 7 deletions(-) diff --git a/cpukit/include/rtems/rtems/modesimpl.h b/cpukit/include/rtems/rtems/modesimpl.h index fe7f5e57

[PATCH v2 2/4] rtems: New errors for rtems_signal_catch()

Ensure that no invalid modes are set during ASR processing. Update #4244. --- cpukit/include/rtems/rtems/modesimpl.h | 48 ++ cpukit/rtems/src/signalcatch.c | 15 cpukit/rtems/src/taskmode.c| 14 +++- 3 files changed, 67 insertions(+), 10 d

[PATCH v2 4/4] rtems: Avoid potential recursion in ASR handling

Do the mode changes necessary for the ASR processing directly under protection of the thread state lock to avoid the recursive calls to thread dispatching done in rtems_task_mode(). Update #4244. --- cpukit/rtems/src/signalsend.c | 98 --- 1 file changed, 91 insert

[PATCH rtems-docs] user/bsps: Mention fixed console baud rate for zynq

--- user/bsps/arm/xilinx-zynq.rst | 14 ++ 1 file changed, 14 insertions(+) diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/arm/xilinx-zynq.rst index 365c336..dcc0649 100644 --- a/user/bsps/arm/xilinx-zynq.rst +++ b/user/bsps/arm/xilinx-zynq.rst @@ -37,6 +37,20 @@ to return the