mbox series

[0/3] Add "num-prio-bits" property for Cortex-M devices

Message ID 20231216182740.3305724-1-sam@rfc1149.net
Headers show
Series Add "num-prio-bits" property for Cortex-M devices | expand

Message

Samuel Tardieu Dec. 16, 2023, 6:27 p.m. UTC
This patch series builds on a discussion initiated by Anton Kochkov on this
list in 2022. It allows setting the appropriate number of priority bits for
Cortex-M devices. For example, FreeRTOS checks at startup that the right
number of priority bits is available in order to guarantee its runtime
structures safety. They added a configuration option specially for QEMU
to disable this check because QEMU always use 2 bits for Cortex-M0/M0+/M1
and 8 bits for other devices.

While this change allows the number of priority bits to be properly
configured, it keeps the same default as before in order to preserve
backward compatibility.

Based-on: <20220813112559.1974427-1-anton.kochkov@proton.me>
([PATCH] hw/arm/nvic: implement "num-prio-bits" property)

Samuel Tardieu (3):
  hw/intc/armv7m_nvic: add "num-prio-bits" property
  hw/arm/armv7m: alias the NVIC "num-prio-bits" property
  hw/arm/socs: configure priority bits for existing SOCs

 hw/arm/armv7m.c        |  2 ++
 hw/arm/stellaris.c     |  2 ++
 hw/arm/stm32f100_soc.c |  1 +
 hw/arm/stm32f205_soc.c |  1 +
 hw/arm/stm32f405_soc.c |  1 +
 hw/intc/armv7m_nvic.c  | 23 ++++++++++++++++++++++-
 6 files changed, 29 insertions(+), 1 deletion(-)

Comments

Samuel Tardieu Dec. 17, 2023, 7:35 a.m. UTC | #1
> Samuel Tardieu (3):
>   hw/intc/armv7m_nvic: add "num-prio-bits" property
>   hw/arm/armv7m: alias the NVIC "num-prio-bits" property
>   hw/arm/socs: configure priority bits for existing SOCs

Any idea to why patchew fails to apply thoses patches? The mbox at 
<https://patchew.org/QEMU/20231216182740.3305724-1-sam@rfc1149.net/> 
applies cleanly on master AFAICS.

  Sam
Peter Maydell Dec. 19, 2023, 4:05 p.m. UTC | #2
On Sun, 17 Dec 2023 at 07:37, Samuel Tardieu <sam@rfc1149.net> wrote:
>
>
> > Samuel Tardieu (3):
> >   hw/intc/armv7m_nvic: add "num-prio-bits" property
> >   hw/arm/armv7m: alias the NVIC "num-prio-bits" property
> >   hw/arm/socs: configure priority bits for existing SOCs
>
> Any idea to why patchew fails to apply thoses patches? The mbox at
> <https://patchew.org/QEMU/20231216182740.3305724-1-sam@rfc1149.net/>
> applies cleanly on master AFAICS.

This is because you put a Based-on: tag in the cover letter.
Based-on: means "please apply this other patch first before this
series, because there is a dependency" (we use it for things
like "this patchset has to sit on top of some other cleanup
patchset I sent last week and which hasn't got into git yet").
So patchew applied Anton's original patch from 2022, and then tried
to apply your three patches on top of that, which caused a conflict.

Anyway, I just wanted to say that this patchset is on my
todo list to review but I'm not going to be able to get to
it before I break for Christmas, so I'll get back to it
in January. Thanks for the contribution!

-- PMM
Samuel Tardieu Dec. 19, 2023, 7:13 p.m. UTC | #3
Peter Maydell <peter.maydell@linaro.org> writes:

>> Any idea to why patchew fails to apply thoses patches? The mbox 
>> at
>> <https://patchew.org/QEMU/20231216182740.3305724-1-sam@rfc1149.net/>
>> applies cleanly on master AFAICS.
>
> This is because you put a Based-on: tag in the cover letter.
> Based-on: means "please apply this other patch first before this
> series, because there is a dependency" (we use it for things
> like "this patchset has to sit on top of some other cleanup
> patchset I sent last week and which hasn't got into git yet").
> So patchew applied Anton's original patch from 2022, and then 
> tried
> to apply your three patches on top of that, which caused a 
> conflict.

Thanks for the explanation. I thought "Based-on:" was just a 
polite way of attributing credit to past discussions. I'll keep 
that in mind. Do you want me to resubmit it as a v2 without the 
"Based-on:" tag so that patchew gets it right?

> Anyway, I just wanted to say that this patchset is on my
> todo list to review but I'm not going to be able to get to
> it before I break for Christmas, so I'll get back to it
> in January. Thanks for the contribution!

Noted!

Best.

  Sam
Peter Maydell Dec. 19, 2023, 8:46 p.m. UTC | #4
On Tue, 19 Dec 2023 at 19:15, Samuel Tardieu <sam@rfc1149.net> wrote:
>
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> >> Any idea to why patchew fails to apply thoses patches? The mbox
> >> at
> >> <https://patchew.org/QEMU/20231216182740.3305724-1-sam@rfc1149.net/>
> >> applies cleanly on master AFAICS.
> >
> > This is because you put a Based-on: tag in the cover letter.
> > Based-on: means "please apply this other patch first before this
> > series, because there is a dependency" (we use it for things
> > like "this patchset has to sit on top of some other cleanup
> > patchset I sent last week and which hasn't got into git yet").
> > So patchew applied Anton's original patch from 2022, and then
> > tried
> > to apply your three patches on top of that, which caused a
> > conflict.
>
> Thanks for the explanation. I thought "Based-on:" was just a
> polite way of attributing credit to past discussions. I'll keep
> that in mind. Do you want me to resubmit it as a v2 without the
> "Based-on:" tag so that patchew gets it right?

No, you don't need to do that. I can review it, and if it's
OK I can apply it to my target-arm tree, based on what we
have now.

thanks
-- PMM