Re: [PATCH RFC v3 0/1] Implement STM32L4x5 EXTI

[Alistair Francis <alistair23@gmail.com>]

On Tue, Dec 5, 2023 at 5:20 AM ~inesvarhol <inesvarhol@git.sr.ht> wrote:
>
> This patch allows to emulate the STM32L4x5 EXTI device.
> It implements register access and software interruptions.
>
> This is RFC because we're new at contributing to QEMU.

Thanks for the patches!

As a general guide, RFCs are for things that you don't think should be
merged. So for example maybe you have half finished something, but you
want to get some feedback, you can send an RFC.

You don't have to send an RFC just because you are unsure if you have
done something correctly. A patch is fine. Although there is no harm
in sending an RFC, usually you get less eye balls on it because
everyone is busy.

> We had some difficulties writing qtests and the result might be bizarre.
>
> We have some questions about the next steps for our stm32l4x5 project :
>
> Should we send a non-RFC patch after this peripheral implementation is
> reviewed,
> or should we wait for more peripherals to be implemented?

Yes!

The easiest way to develop upstream is to send your patches as early
as you can. Obviously you want to test them and make sure they work.
But you don't have to wait for every single thing to be finished. If
you have implemented support in a peripheral you can send those
patches upstream.

Again, as long everything works and is tested it's ready to go. Don't
wait for a year of development before trying to upstream, as that is
harder for you and for reviewers. Get feedback early and often :)

> We have syscfg and uart implementations ongoing.
>
> Also, should the version numbers restart from 1 when sending a non-RFC
> tag ?

Yes, it will reset to "PATCH", and then "PATCH v2" and so on

Alistair

>
> Sincerely,
> Inès Varhol
>
>
> Changes from v2 to v3:
> - adding more tests writing/reading in exti registers
> - adding tests checking that interrupt work by reading NVIC registers
> - correcting exti_write in SWIER (so it sets an irq only when a bit goes
> from '0' to '1')
> - correcting exti_set_irq (so it never writes in PR when the relevant
> bit in IMR is '0')
>
> Changes from v1 to v2:
> - use arrays to deduplicate code and logic
> - move internal constant EXTI_NUM_GPIO_EVENT_IN_LINES from the header
> to the .c file
> - Improve copyright headers
> - replace static const with #define
> - use the DEFINE_TYPES macro
> - fill the impl and valid field of the exti's MemoryRegionOps
> - fix invalid test caused by a last minute change
>
> Based-on: <170049810484.22920.612074576971878323-0@git.sr.ht>
> ([RFC v3 2/2] hw/arm: Add minimal support for the B-L475E-IOT01A board)
>
> Inès Varhol (1):
>   Implement STM32L4x5 EXTI
>
>  hw/arm/Kconfig                    |   1 +
>  hw/arm/stm32l4x5_soc.c            |  65 +++-
>  hw/misc/Kconfig                   |   3 +
>  hw/misc/meson.build               |   1 +
>  hw/misc/stm32l4x5_exti.c          | 306 +++++++++++++++++++
>  hw/misc/trace-events              |   5 +
>  include/hw/arm/stm32l4x5_soc.h    |   3 +
>  include/hw/misc/stm32l4x5_exti.h  |  58 ++++
>  tests/qtest/meson.build           |   5 +
>  tests/qtest/stm32l4x5_exti-test.c | 485 ++++++++++++++++++++++++++++++
>  10 files changed, 930 insertions(+), 2 deletions(-)
>  create mode 100644 hw/misc/stm32l4x5_exti.c
>  create mode 100644 include/hw/misc/stm32l4x5_exti.h
>  create mode 100644 tests/qtest/stm32l4x5_exti-test.c
>
> --
> 2.38.5
>