[PATCH V2 00/13] IOT2050-related enhancements

[Jan Kiszka]

On 26.10.22 23:02, Marek Vasut wrote:
> On 10/26/22 17:55, Jan Kiszka wrote:
>> On 26.10.22 16:03, Marek Vasut wrote:
>>> On 10/26/22 15:54, Tom Rini wrote:
>>>> On Wed, Oct 26, 2022 at 09:28:09AM +0200, Jan Kiszka wrote:
>>>>> On 05.10.22 10:33, Jan Kiszka wrote:
>>>>>> (Almost) flushing our upstream queue for the IOT2050 device, this
>>>>>> mostly
>>>>>> brings board-specific changes such as:
>>>>>>
>>>>>>    - updated build process and firmware layout for PG1 vs. PG2
>>>>>> devices
>>>>>>    - more watchdog preparations
>>>>>>    - preparations for verified boot on IOT2050 Advanced devices
>>>>>>
>>>>>> There are also some generic extensions in this series which are
>>>>>> dependencies for the above:
>>>>>>
>>>>>>    - env: Complete generic support for writable list
>>>>>>    - env: Couple networking-related variable flags to CONFIG_NET
>>>>>> (repost)
>>>>>>    - tools: Add script for converting public key into device tree
>>>>>> include
>>>>>>
>>>>>> Changes in v2:
>>>>>>    - rebased over latest master
>>>>>>    - reworked patch 1 to be less invasive to the code
>>>>>>    - added "iot2050: use the named gpio to control the user-button"
>>>>>>
>>>>>> Still in our backlog is support for a new variant that comes with M.2
>>>>>> slots. But that requires some more rework first.
>>>>>
>>>>> Any remaining questions/remarks for this series? Asking also as we
>>>>> would
>>>>> like to move forward with upstreaming that M.2 support which
>>>>> depends on
>>>>> this one here.
>>>>
>>>> Marek, I believe you had concerns about the environment side of v1
>>>> here,
>>>> is v2 more to your liking? Thanks!
>>>
>>> Nothing changed in V2 in that aspect as far as I can tell.
>>
>> Well... patch 1 changes significantly and is much less invasive - as we
>> discussed around v1. Can you please update your comments then? I'm lost
>> now what else you would like to see changed.
> 
> IIRC my comment was that env prio ordering is board specific and so it
> should be in board/ , wasn't it ?

Please re-read the old discussion to its end. It ended with how to make
the approach less invasive.

The whole patch is about making it no longer board specific - because it
isn't for the variable protection scenario under secure boot. As I
pointed out in that thread, we have multiple downstream boards using
exactly this very same pattern already.

Thanks,
Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux