[PATCH v2 4/5] mvebu: add 5.10 kernel config

[Tomasz Maciej Nowak]

W dniu 20.02.2021 o 21:39, Rui Salvaterra pisze:
> Hi, Tomasz,
> 
> On Sat, 20 Feb 2021 at 16:55, Tomasz Maciej Nowak <tmn505 at gmail.com> wrote:
>>
>> The cortexa53 and cortexa72 config refresh are missing, also some symbols could be split from this patch and added to generic config, so other targets refresh will produce smaller diffs. Comments inline.
> 
> I have no a53/a72 hardware at all (I only have a9, the Omnia), so any
> changes to those targets will be completely untested. Maybe I should
> have made this point explicit. :/

I assumed it's bump for whole target and reviewed as such, since the series name doesn't explicitly state it's for cortexa9. Anyway that's the point of KERNEL_TESTING_PATCHVER, to allow volunteers to test it and some could provide Tested-by tag (for example me) or point/submit a fix.

> 
> [sniped]
> 
>>> +# CONFIG_ARCH_MSTARV7 is not set
>> Split from this commit and move to generic config.
> 
> What do you mean? Split this specific kconfig symbol, or the whole block?

All the symbols I pointed to, move them to generic config with separate commit before mvebu kernel 5.10 config refresh.

> 
> [sniped]
> 
>>> +# CONFIG_LEDS_TURRIS_OMNIA is not set
>>
>> You are adding LEDs node to dts but the driver still is disabled, do the LEDs work without it? If not, make it built-in or package as module.
> 
> I'm not adding any features yet. First, I want to get to a point where
> the system runs exactly as it would run with 5.4. New features will
> come afterwards (in this case, as a module, of course).

So there's no point to add changes to Omnia dts (add hw buf management to Your other series, when kernel bump is merged), introduce them when You'll activate the features, in single series of patches. Also doing raw kernel bump will speed up the review/merge process.

> 
> [sniped]
> 
> Thanks,
> Rui
> 


-- 
TMN