Re: [Xen-devel] [PATCH v2 08/10] arm: add a small kconfig for Renesas RCar H3

[Artem Mygaiev <artem_mygaiev@xxxxxxxx>]

Hi Stefano

On 23.05.18 00:00, Stefano Stabellini wrote:
> On Tue, 22 May 2018, Julien Grall wrote:
> > It might be easier to maintain if we provide a per platform config option (e.g
> > CONFIG_RCAR3) that will select driver for that specific board.
> >
> > The user is then free to select other components (e.g scheduler...). So you
> > don't impose memaccess disabled, NULL scheduler...
> >
> > (Thank you Andrii for the suggestion!)
> This is a good idea, it would be great to have CONFIG_RCAR3, but it does
> not take away the need for this kconfig. CONFIG_RCAR3 and rcar3.config
> are orthogonal, let me explain.
>
> Let's say that we have a CONFIG_RCAR3 that selects everything needed for
> the Rcar3, such as:
>
> NR_CPUS, SCIF
>
> and deselects:
>
> ACPI, GICV3, the other UARTs, ARM_SMMU.
>
> We still need a reference kconfig with other not platform specific
> options, for instance:
>
> SCHED_NULL
>
> For two reasons:
> 1) we need a reference kconfig for certifications, it has to include the
>     choice of schedulers, debug options, etc, which are not Rcar3 specific
> 2) as per previous discussions, we need a set of pre-canned kconfigs to
>     establish what we security support
>
> rcar3.config is meant to address these two points. CONFIG_RCAR3 would
> not take away the need for rcar3.config, but it would make rcar3.config
> shorter and easier to maintain.
>
> CONFIG_RCAR3 was not on my roadmap but I'll see what I can do. Maybe it
> is best if I do the work for QEMU only (both CONFIG_QEMU and
> qemu.config) and leave the Renesas work (both CONFIG_RCAR3 and
> rcar3.config) to EPAM. I cannot test it anyway.
We will check v3 patchset on R-Car H3

 -- Artem

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel