On Mon, Sep 25, 2023 at 04:21:17PM +0200, Michal Simek wrote: > > > On 9/25/23 16:19, Tom Rini wrote: > > On Mon, Sep 25, 2023 at 04:10:38PM +0200, Michal Simek wrote: > > > Hi Simon, > > > > > > On 9/25/23 16:01, Simon Glass wrote: > > > > Hi Michal, > > > > > > > > On Mon, 25 Sept 2023 at 07:38, Michal Simek <michal.si...@amd.com> > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 9/25/23 15:10, Simon Glass wrote: > > > > > > Hi Michal, > > > > > > > > > > > > On Mon, 25 Sept 2023 at 00:06, Michal Simek <michal.si...@amd.com> > > > > > > wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > > > > On 9/23/23 20:13, Simon Glass wrote: > > > > > > > > Current alignment which is using 16 bytes is not correct in > > > > > > > > connection to > > > > > > > > trace_clocks description and it's length. > > > > > > > > That's why use start_addr variable and record proper size based > > > > > > > > on used > > > > > > > > entries. > > > > > > > > > > > > > > > > Fixes: be16fc81b2ed ("trace: Update proftool to use new binary > > > > > > > > format"). > > > > > > > > Signed-off-by: Michal Simek <michal.si...@amd.com> > > > > > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > > > > > > --- > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > - s/start_addr/start_ofs/g' > > > > > > > > > > > > > > > > tools/proftool.c | 31 +++++++++++++++++++++++++++++-- > > > > > > > > 1 file changed, 29 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > Applied to u-boot-dm, thanks! > > > > > > > > > > > > > > FYI: I have merged it to my tree and already sent pull request to > > > > > > > Tom. > > > > > > > Without it I couldn't pass CI loop to get all reviewed features > > > > > > > in. > > > > > > > > > > > > > > https://lore.kernel.org/all/ab72c480-e9f8-416e-adf5-726f7d40c...@amd.com/ > > > > > > > > > > > > Ah OK, well that's fine. It was in my patchwork queue still, which > > > > > > suggests that the patches were not set to 'applied'? > > > > > > > > > > I am not using patchwork. But I expect my reply to cover letter was > > > > > recorded there. > > > > > > > > Probably. If you reply to each patch, it shows up in the patch, but > > > > the cover letter is hidden somewhere else. > > > > > > I have never started to like patchwork. I installed that client long time > > > ago, I also have account for quite a long time. > > > > > > > If you are not using patchwork, how come you are a custodian? Is > > > > someone else dealing with patchwork for you? > > > > > > Not really. I am just keep track on it via emails. > > > > > > DT folks did wire CI loop on every patch which they get. I am not aware > > > about any feature like this which would bring me something. That's why I > > > am > > > considering patchwork as unneeded layer. And I also don't think that I > > > have > > > read anywhere that all custodians should be using patchwork. > > > > Right, patchwork isn't required, but can be helpful. Part of how > > patchwork is maintained for everyone (in U-Boot) is that I have a script > > that will update the status of patches to accepted and add the githash, > > based on the "patchwork hash" of a given commit. There's a number of > > automated tooling things that other projects use which could be helpful > > here, but due to lack of time/resources, we haven't tried them here. > > Can you share that script? I am happy to run it and pretty much close my list. > I am using b4 for applying patches that's why all message-ids are listed in > the history which will uniquely identify that patches.
If you like, yes, you can run the following. Note that when I run it myself between tags, it will still re-update things. This requires having patchwork cloned from git as well and is a slight modification of both tools/patchwork-update-commits and tools/post-receive.hook: #!/bin/bash # Patchwork - automated patch tracking system # Copyright (C) 2010 martin f. krafft <madd...@madduck.net> # # SPDX-License-Identifier: GPL-2.0-or-later # Git post-receive hook to update Patchwork patches after Git pushes set -u PW_DIR=/home/trini/work/u-boot/patchwork/patchwork #TODO: the state map should really live in the repo's git-config STATE_MAP=".git/refs/heads/master:Accepted" # ignore all commits already present in these refs # e.g., # EXCLUDE="refs/heads/upstream refs/heads/other-project" EXCLUDE="" do_exit=0 trap "do_exit=1" INT get_patchwork_hash() { local hash hash=$(git diff "$1~..$1" | python3 $PW_DIR/hasher.py) echo "$hash" test -n "$hash" } get_patchwork_hash_harder() { local hash hash=$(git diff "$1~..$1" | sed -e 's/^ $//g' | python3 $PW_DIR/hasher.py) echo "$hash" test -n "$hash" } get_patch_id() { local id id=$(curl -s "http://patchwork.ozlabs.org/api/patches/?project=uboot&hash=$1" | \ jq '.[-1] | .id') echo "$id" } set_patch_state() { pwclient update -s "$2" -c "$3" "$1" 2>&1 } update_patches() { local cnt; cnt=0 for rev in $(git rev-parse --not ${EXCLUDE} | git rev-list --stdin --no-merges --reverse "${1}".."${2}"); do if [ "$do_exit" = 1 ]; then echo "I: exiting..." >&2 break fi hash=$(get_patchwork_hash "$rev") if [ -z "$hash" ]; then echo "E: failed to hash rev $rev." >&2 continue fi id=$(get_patch_id "$hash") if [ "$id" = "null" ]; then hash=$(get_patchwork_hash_harder "$rev") id=$(get_patch_id "$hash") fi if [ "$id" = "null" ]; then echo "E: failed to find patch for rev $rev." >&2 continue fi reason="$(set_patch_state "$id" "$3" "$rev")" if [ -n "$reason" ]; then echo "E: failed to update patch #$id${reason:+: $reason}." >&2 continue fi echo "I: patch #$id updated using rev $rev." >&2 cnt=$((cnt + 1)) done echo "I: $cnt patch(es) updated to state $3." >&2 } oldrev=$1 newrev=$2 refname=".git/refs/heads/master" found=0 for i in $STATE_MAP; do key="${i%:*}" if [ "$key" = "$refname" ]; then update_patches "$oldrev" "$newrev" ${i#*:} found=1 break fi done if [ $found -eq 0 ]; then echo "E: STATE_MAP has no mapping for branch $refname" >&2 fi -- Tom
signature.asc
Description: PGP signature