[PATCH v2 1/3] test: env: Add test for environment storage in SPI NOR

[Marek Vasut]

On 12/31/25 5:11 PM, Tom Rini wrote:
> On Wed, Dec 31, 2025 at 05:07:31PM +0100, Marek Vasut wrote:
>> On 12/24/25 12:32 AM, Tom Rini wrote:
>>> On Tue, Dec 23, 2025 at 07:55:45PM +0100, Marek Vasut wrote:
>>>> On 12/23/25 6:32 PM, Heinrich Schuchardt wrote:
>>>>> On 12/23/25 15:31, Marek Vasut wrote:
>>>>>> Add test for environment stored in SPI NOR. The test works in a very
>>>>>> similar way to the current test for environment stored in ext4 FS,
>>>>>> except it generates spi.bin file backing the SPI NOR.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas at mailbox.org>
>>>>>> ---
>>>>>> Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>>>>> Cc: Jerome Forissier <jerome.forissier at linaro.org>
>>>>>> Cc: Simon Glass <sjg at chromium.org>
>>>>>> Cc: Tom Rini <trini at konsulko.com>
>>>>>> Cc: u-boot at lists.denx.de
>>>>>> ---
>>>>>> V2: No change
>>>>>> ---
>>>>>>     test/py/tests/test_env.py | 99 +++++++++++++++++++++++++++++++++++++++
>>>>>>     1 file changed, 99 insertions(+)
>>>>>>
>>>>>> diff --git a/test/py/tests/test_env.py b/test/py/tests/test_env.py
>>>>>> index 383e26c03b0..48e31f19b3c 100644
>>>>>> --- a/test/py/tests/test_env.py
>>>>>> +++ b/test/py/tests/test_env.py
>>>>>> @@ -457,6 +457,26 @@ def mk_env_ext4(state_test_env):
>>>>>>         utils.run_and_log(c, ['cp',  '-f', persistent, fs_img])
>>>>>>         return fs_img
>>>>>> +def mk_env_spi_flash(state_test_env):
>>>>>
>>>>> Thank you for adding the test.
>>>>>
>>>>> Unfortunately pylint doesn't like your code. Please have a look.
>>>>
>>>> Is this something we run in CI ? If so, CI builds did pass.
>>>>
>>>> If not, how do I trigger this ?
>>>
>>> We only run pylint_err not pylint in CI. The "make pylint" target has
>>> been unused for so long that the baseline itself is out of date. I don't
>>> object to trying to improve our python code to match standard practices
>>> better, but this isn't the place to start adding complaints.
>>>
>>> All that said, a newline before a new function is just a normal good
>>> practice and so at least the quoted here example should be fixed, just
>>> like if it was in C :)
>> There is a newline before the function, the code is incorrectly quoted in
>> this discussion, see e.g. patchwork for the actual content of this patch:
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20251223143130.16266-1-marek.vasut+renesas@mailbox.org/
>>
>> So, what exactly should be fixed in this patch ?
> 
> Thanks for explaining. The only problem I have now is you didn't give a
> cover letter explaining the feature and so I need to come up with
> something when merging the series as a merge commit. I can do that, it's
> just easier when I don't have to.
2/3 basically describes why this series is needed, and implements the 
actual functionality. I can send a V3 with no changes and cover letter 
if still needed.