[PATCH v2 4/4] cmd: source: Support specifying config name
Tom Rini
trini at konsulko.com
Mon Oct 31 20:37:18 CET 2022
On Mon, Oct 31, 2022 at 01:27:08PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Sun, 30 Oct 2022 at 08:40, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sat, Oct 29, 2022 at 07:44:00PM -0600, Simon Glass wrote:
> > > Hi Sean,
> > >
> > > On Fri, 21 Oct 2022 at 15:04, Sean Anderson <sean.anderson at seco.com> wrote:
> > > >
> > > > On 10/21/22 4:17 PM, Simon Glass wrote:
> > > > > On Thu, 20 Oct 2022 at 13:24, Sean Anderson <sean.anderson at seco.com> wrote:
> > > > >>
> > > > >> As discussed previously [1,2], the source command is not safe to use with
> > > > >> verified boot unless there is a key with required = "images" (which has its
> > > > >> own problems). This is because if such a key is absent, signatures are
> > > > >> verified but not required. It is assumed that configuration nodes will
> > > > >> provide the signature. Because the source command does not use
> > > > >> configurations to determine the image to source, effectively no
> > > > >> verification takes place.
> > > > >>
> > > > >> To address this, allow specifying configuration nodes. We use the same
> > > > >> syntax as the bootm command (helpfully provided for us by fit_parse_conf).
> > > > >> By default, we first try the default config and then the default image. To
> > > > >> force using a config, # must be present in the command (e.g. `source
> > > > >> $loadaddr#my-conf`). For convenience, the config may be omitted, just like
> > > > >> the address may be (e.g. `source \#`). This also works for images
> > > > >> (`source \:` behaves exactly like `source` currently does).
> > > > >>
> > > > >> [1] https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9eeded@prevas.dk/
> > > > >> [2] https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005fdd@gmail.com/
> > > > >>
> > > > >> Signed-off-by: Sean Anderson <sean.anderson at seco.com>
> > > > >> ---
> > > > >>
> > > > >> (no changes since v1)
> > > > >>
> > > > >> .../cmd_stm32prog/cmd_stm32prog.c | 2 +-
> > > > >> boot/bootmeth_script.c | 2 +-
> > > > >> cmd/source.c | 73 +++++++++++++------
> > > > >> doc/uImage.FIT/source_file_format.txt | 3 +
> > > > >> drivers/usb/gadget/f_sdp.c | 2 +-
> > > > >> include/image.h | 19 +++--
> > > > >> test/py/tests/test_source.py | 11 ++-
> > > > >> 7 files changed, 82 insertions(+), 30 deletions(-)
> > > > >
> > > > > Reviewed-by: Simon Glass <sjg at chromium.org>
> > > > >
> > > > > But please use single quotes in Python. Double quotes should only be
> > > > > used when the string includes single quotes.
> > > > >
> > > >
> > > > Do we have a style guide for python? Judging by `git grep '"' '**.py'`,
> > > > double quoting is endemic. IMO single quotes should be used for
> > > > identifiers (or things which would be enums in C), and double quotes
> > > > elsewhere. But if you want to go the other way, perhaps add something
> > > > to checkpatch.
> > >
> > > Well we use PEP8, with single quotes used for nearly everything. The
> > > exceptions are the one I mentioned, and module/function comments.
> > >
> > > Do we use checkpatch for Python?
> >
> > Is there a standard python PEP8 checking tool? We should see if
> > upstream is interested in a flag or similar to call another tool for
> > python linting.
>
> Yes this is pylint and we do already use it, but not in patman so far.
> It would be a good thing to add.
I'd start by trying to put it in checkpatch.pl and seeing if upstream is
interested, the kernel has a bunch of python tools too these days.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221031/5bfb3db7/attachment.sig>
More information about the U-Boot
mailing list