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 <[email protected]>
---
Cc: Heinrich Schuchardt <[email protected]>
Cc: Jerome Forissier <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: [email protected]
---
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/[email protected]/
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.
