* [PATCH v2 5/8] merge-ort: split out a separate display_update_messages() function
From: Elijah Newren via GitGitGadget @ 2022-01-05 17:27 UTC (permalink / raw)
To: git
Cc: Christian Couder, Taylor Blau, Johannes Altmanninger,
Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1114.v2.git.git.1641403655.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
No functional changes included in this patch; it's just a preparatory
step in anticipation of wanting to handle the printed messages
differently in `git merge-tree --real`.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
merge-ort.c | 71 ++++++++++++++++++++++++++++-------------------------
merge-ort.h | 8 ++++++
2 files changed, 46 insertions(+), 33 deletions(-)
diff --git a/merge-ort.c b/merge-ort.c
index 0342f104836..3cdef173cd7 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -4197,6 +4197,42 @@ static int record_conflicted_index_entries(struct merge_options *opt)
return errs;
}
+void merge_display_update_messages(struct merge_options *opt,
+ struct merge_result *result)
+{
+ struct merge_options_internal *opti = result->priv;
+ struct hashmap_iter iter;
+ struct strmap_entry *e;
+ struct string_list olist = STRING_LIST_INIT_NODUP;
+ int i;
+
+ trace2_region_enter("merge", "display messages", opt->repo);
+
+ /* Hack to pre-allocate olist to the desired size */
+ ALLOC_GROW(olist.items, strmap_get_size(&opti->output),
+ olist.alloc);
+
+ /* Put every entry from output into olist, then sort */
+ strmap_for_each_entry(&opti->output, &iter, e) {
+ string_list_append(&olist, e->key)->util = e->value;
+ }
+ string_list_sort(&olist);
+
+ /* Iterate over the items, printing them */
+ for (i = 0; i < olist.nr; ++i) {
+ struct strbuf *sb = olist.items[i].util;
+
+ printf("%s", sb->buf);
+ }
+ string_list_clear(&olist, 0);
+
+ /* Also include needed rename limit adjustment now */
+ diff_warn_rename_limit("merge.renamelimit",
+ opti->renames.needed_limit, 0);
+
+ trace2_region_leave("merge", "display messages", opt->repo);
+}
+
void merge_switch_to_result(struct merge_options *opt,
struct tree *head,
struct merge_result *result,
@@ -4235,39 +4271,8 @@ void merge_switch_to_result(struct merge_options *opt,
trace2_region_leave("merge", "write_auto_merge", opt->repo);
}
- if (display_update_msgs) {
- struct merge_options_internal *opti = result->priv;
- struct hashmap_iter iter;
- struct strmap_entry *e;
- struct string_list olist = STRING_LIST_INIT_NODUP;
- int i;
-
- trace2_region_enter("merge", "display messages", opt->repo);
-
- /* Hack to pre-allocate olist to the desired size */
- ALLOC_GROW(olist.items, strmap_get_size(&opti->output),
- olist.alloc);
-
- /* Put every entry from output into olist, then sort */
- strmap_for_each_entry(&opti->output, &iter, e) {
- string_list_append(&olist, e->key)->util = e->value;
- }
- string_list_sort(&olist);
-
- /* Iterate over the items, printing them */
- for (i = 0; i < olist.nr; ++i) {
- struct strbuf *sb = olist.items[i].util;
-
- printf("%s", sb->buf);
- }
- string_list_clear(&olist, 0);
-
- /* Also include needed rename limit adjustment now */
- diff_warn_rename_limit("merge.renamelimit",
- opti->renames.needed_limit, 0);
-
- trace2_region_leave("merge", "display messages", opt->repo);
- }
+ if (display_update_msgs)
+ merge_display_update_messages(opt, result);
merge_finalize(opt, result);
}
diff --git a/merge-ort.h b/merge-ort.h
index c011864ffeb..1b93555a60b 100644
--- a/merge-ort.h
+++ b/merge-ort.h
@@ -70,6 +70,14 @@ void merge_switch_to_result(struct merge_options *opt,
int update_worktree_and_index,
int display_update_msgs);
+/*
+ * Display messages about conflicts and which files were 3-way merged.
+ * Automatically called by merge_switch_to_result() with stream == stdout,
+ * so only call this when bypassing merge_switch_to_result().
+ */
+void merge_display_update_messages(struct merge_options *opt,
+ struct merge_result *result);
+
/* Do needed cleanup when not calling merge_switch_to_result() */
void merge_finalize(struct merge_options *opt,
struct merge_result *result);
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 4/8] merge-tree: implement real merges
From: Elijah Newren via GitGitGadget @ 2022-01-05 17:27 UTC (permalink / raw)
To: git
Cc: Christian Couder, Taylor Blau, Johannes Altmanninger,
Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1114.v2.git.git.1641403655.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
This adds the ability to perform real merges rather than just trivial
merges (meaning handling three way content merges, recursive ancestor
consolidation, renames, proper directory/file conflict handling, and so
forth). However, unlike `git merge`, the working tree and index are
left alone and no branch is updated.
The only output is:
- the toplevel resulting tree printed on stdout
- exit status of 0 (clean) or 1 (conflicts present)
This output is mean to be used by some higher level script, perhaps in a
sequence of steps like this:
NEWTREE=$(git merge-tree --real $BRANCH1 $BRANCH2)
test $? -eq 0 || die "There were conflicts..."
NEWCOMMIT=$(git commit-tree $NEWTREE -p $BRANCH1 -p $BRANCH2)
git update-ref $BRANCH1 $NEWCOMMIT
Note that higher level scripts may also want to access the
conflict/warning messages normally output during a merge, or have quick
access to a list of files with conflicts. That is not available in this
preliminary implementation, but subsequent commits will add that
ability.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
Documentation/git-merge-tree.txt | 28 +++++++----
builtin/merge-tree.c | 55 +++++++++++++++++++++-
t/t4301-merge-tree-real.sh | 81 ++++++++++++++++++++++++++++++++
3 files changed, 153 insertions(+), 11 deletions(-)
create mode 100755 t/t4301-merge-tree-real.sh
diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt
index 58731c19422..5823938937f 100644
--- a/Documentation/git-merge-tree.txt
+++ b/Documentation/git-merge-tree.txt
@@ -3,26 +3,34 @@ git-merge-tree(1)
NAME
----
-git-merge-tree - Show three-way merge without touching index
+git-merge-tree - Perform merge without touching index or working tree
SYNOPSIS
--------
[verse]
+'git merge-tree' --real <branch1> <branch2>
'git merge-tree' <base-tree> <branch1> <branch2>
DESCRIPTION
-----------
-Reads three tree-ish, and output trivial merge results and
-conflicting stages to the standard output. This is similar to
-what three-way 'git read-tree -m' does, but instead of storing the
-results in the index, the command outputs the entries to the
-standard output.
+Performs a merge, but does not make any new commits and does not read
+from or write to either the working tree or index.
-This is meant to be used by higher level scripts to compute
-merge results outside of the index, and stuff the results back into the
-index. For this reason, the output from the command omits
-entries that match the <branch1> tree.
+The first form will merge the two branches, doing a full recursive
+merge with rename detection. If the merge is clean, the exit status
+will be `0`, and if the merge has conflicts, the exit status will be
+`1`. The output will consist solely of the resulting toplevel tree
+(which may have files including conflict markers).
+
+The second form is meant for backward compatibility and will only do a
+trival merge. It reads three tree-ish, and outputs trivial merge
+results and conflicting stages to the standard output in a semi-diff
+format. Since this was designed for higher level scripts to consume
+and merge the results back into the index, it omits entries that match
+<branch1>. The result of this second form is is similar to what
+three-way 'git read-tree -m' does, but instead of storing the results
+in the index, the command outputs the entries to the standard output.
GIT
---
diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index e1d2832c809..ac50f3d108b 100644
--- a/builtin/merge-tree.c
+++ b/builtin/merge-tree.c
@@ -2,6 +2,9 @@
#include "builtin.h"
#include "tree-walk.h"
#include "xdiff-interface.h"
+#include "help.h"
+#include "commit-reach.h"
+#include "merge-ort.h"
#include "object-store.h"
#include "parse-options.h"
#include "repository.h"
@@ -392,7 +395,57 @@ struct merge_tree_options {
static int real_merge(struct merge_tree_options *o,
const char *branch1, const char *branch2)
{
- die(_("real merges are not yet implemented"));
+ struct commit *parent1, *parent2;
+ struct commit_list *common;
+ struct commit_list *merge_bases = NULL;
+ struct commit_list *j;
+ struct merge_options opt;
+ struct merge_result result = { 0 };
+
+ parent1 = get_merge_parent(branch1);
+ if (!parent1)
+ help_unknown_ref(branch1, "merge",
+ _("not something we can merge"));
+
+ parent2 = get_merge_parent(branch2);
+ if (!parent2)
+ help_unknown_ref(branch2, "merge",
+ _("not something we can merge"));
+
+ init_merge_options(&opt, the_repository);
+ /*
+ * TODO: Support subtree and other -X options?
+ if (use_strategies_nr == 1 &&
+ !strcmp(use_strategies[0]->name, "subtree"))
+ opt.subtree_shift = "";
+ for (x = 0; x < xopts_nr; x++)
+ if (parse_merge_opt(&opt, xopts[x]))
+ die(_("Unknown strategy option: -X%s"), xopts[x]);
+ */
+
+ opt.show_rename_progress = 0;
+
+ opt.branch1 = merge_remote_util(parent1)->name; /* or just branch1? */
+ opt.branch2 = merge_remote_util(parent2)->name; /* or just branch2? */
+
+ /*
+ * Get the merge bases, in reverse order; see comment above
+ * merge_incore_recursive in merge-ort.h
+ */
+ common = get_merge_bases(parent1, parent2);
+ for (j = common; j; j = j->next)
+ commit_list_insert(j->item, &merge_bases);
+
+ /*
+ * TODO: notify if merging unrelated histories?
+ if (!common)
+ fprintf(stderr, _("merging unrelated histories"));
+ */
+
+ merge_incore_recursive(&opt, merge_bases, parent1, parent2, &result);
+ printf("%s\n", oid_to_hex(&result.tree->object.oid));
+ merge_switch_to_result(&opt, NULL, &result, 0, 0);
+ return result.clean ? 0 : 1;
}
int cmd_merge_tree(int argc, const char **argv, const char *prefix)
diff --git a/t/t4301-merge-tree-real.sh b/t/t4301-merge-tree-real.sh
new file mode 100755
index 00000000000..f7aa310f8c1
--- /dev/null
+++ b/t/t4301-merge-tree-real.sh
@@ -0,0 +1,81 @@
+#!/bin/sh
+
+test_description='git merge-tree --real'
+
+. ./test-lib.sh
+
+# This test is ort-specific
+GIT_TEST_MERGE_ALGORITHM=ort
+export GIT_TEST_MERGE_ALGORITHM
+
+test_expect_success setup '
+ test_write_lines 1 2 3 4 5 >numbers &&
+ echo hello >greeting &&
+ echo foo >whatever &&
+ git add numbers greeting whatever &&
+ git commit -m initial &&
+
+ git branch side1 &&
+ git branch side2 &&
+
+ git checkout side1 &&
+ test_write_lines 1 2 3 4 5 6 >numbers &&
+ echo hi >greeting &&
+ echo bar >whatever &&
+ git add numbers greeting whatever &&
+ git commit -m modify-stuff &&
+
+ git checkout side2 &&
+ test_write_lines 0 1 2 3 4 5 >numbers &&
+ echo yo >greeting &&
+ git rm whatever &&
+ mkdir whatever &&
+ >whatever/empty &&
+ git add numbers greeting whatever/empty &&
+ git commit -m other-modifications
+'
+
+test_expect_success 'Content merge and a few conflicts' '
+ git checkout side1^0 &&
+ test_must_fail git merge side2 &&
+ cp .git/AUTO_MERGE EXPECT &&
+ E_TREE=$(cat EXPECT) &&
+
+ git reset --hard &&
+ test_must_fail git merge-tree --real side1 side2 >RESULT &&
+ R_TREE=$(cat RESULT) &&
+
+ # Due to differences of e.g. "HEAD" vs "side1", the results will not
+ # exactly match. Dig into individual files.
+
+ # Numbers should have three-way merged cleanly
+ test_write_lines 0 1 2 3 4 5 6 >expect &&
+ git show ${R_TREE}:numbers >actual &&
+ test_cmp expect actual &&
+
+ # whatever and whatever~<branch> should have same HASHES
+ git rev-parse ${E_TREE}:whatever ${E_TREE}:whatever~HEAD >expect &&
+ git rev-parse ${R_TREE}:whatever ${R_TREE}:whatever~side1 >actual &&
+ test_cmp expect actual &&
+
+ # greeting should have a merge conflict
+ git show ${E_TREE}:greeting >tmp &&
+ cat tmp | sed -e s/HEAD/side1/ >expect &&
+ git show ${R_TREE}:greeting >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'Barf on misspelled option' '
+ # Mis-spell with single "s" instead of double "s"
+ test_expect_code 129 git merge-tree --real --mesages FOOBAR side1 side2 2>expect &&
+
+ grep "error: unknown option.*mesages" expect
+'
+
+test_expect_success 'Barf on too many arguments' '
+ test_expect_code 129 git merge-tree --real side1 side2 side3 2>expect &&
+
+ grep "^usage: git merge-tree" expect
+'
+
+test_done
--
gitgitgadget
^ permalink raw reply related
* Please pull u-boot-marvell/master
From: Stefan Roese @ 2022-01-05 17:27 UTC (permalink / raw)
To: Tom Rini, U-Boot Mailing List
Hi Tom,
please pull this last minute kwbimage related fix:
----------------------------------------------------------------
- kwbimage: Fix checksum calculation for v1 images (Pierre)
----------------------------------------------------------------
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=143&view=results
Thanks,
Stefan
The following changes since commit b3f84a939f514a266a5a3aa97cbe2787c2d73d89:
Merge tag 'video-20211228' of
https://source.denx.de/u-boot/custodians/u-boot-video (2021-12-28
11:19:26 -0500)
are available in the Git repository at:
git@source.denx.de:u-boot/custodians/u-boot-marvell.git
for you to fetch changes up to 9203c73895ab410f7a57f56ec26201253a1f008b:
tools: kwbimage: Fix checksum calculation for v1 images (2022-01-05
16:31:58 +0100)
----------------------------------------------------------------
Pierre Bourdon (1):
tools: kwbimage: Fix checksum calculation for v1 images
tools/kwbimage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* [Intel-wired-lan] [PATCH] ice: Use bitmap_free() to free bitmap
From: G, GurucharanX @ 2022-01-05 17:27 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <d139eb69eb12c9793a2a3b65e94f74d4cee2a39c.1640529439.git.christophe.jaillet@wanadoo.fr>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Christophe JAILLET
> Sent: Sunday, December 26, 2021 8:09 PM
> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem at davemloft.net; kuba at kernel.org
> Cc: netdev at vger.kernel.org; kernel-janitors at vger.kernel.org; Christophe
> JAILLET <christophe.jaillet@wanadoo.fr>; intel-wired-lan at lists.osuosl.org;
> linux-kernel at vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] ice: Use bitmap_free() to free bitmap
>
> kfree() and bitmap_free() are the same. But using the latter is more consistent
> when freeing memory allocated with bitmap_zalloc().
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* [PATCH v2 6/8] merge-ort: allow update messages to be written to different file stream
From: Elijah Newren via GitGitGadget @ 2022-01-05 17:27 UTC (permalink / raw)
To: git
Cc: Christian Couder, Taylor Blau, Johannes Altmanninger,
Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1114.v2.git.git.1641403655.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
This modifies the new display_update_messages() function to allow
printing to somewhere other than stdout.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
merge-ort.c | 7 ++++---
merge-ort.h | 3 ++-
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/merge-ort.c b/merge-ort.c
index 3cdef173cd7..86eebf39166 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -4198,7 +4198,8 @@ static int record_conflicted_index_entries(struct merge_options *opt)
}
void merge_display_update_messages(struct merge_options *opt,
- struct merge_result *result)
+ struct merge_result *result,
+ FILE *stream)
{
struct merge_options_internal *opti = result->priv;
struct hashmap_iter iter;
@@ -4222,7 +4223,7 @@ void merge_display_update_messages(struct merge_options *opt,
for (i = 0; i < olist.nr; ++i) {
struct strbuf *sb = olist.items[i].util;
- printf("%s", sb->buf);
+ fprintf(stream, "%s", sb->buf);
}
string_list_clear(&olist, 0);
@@ -4272,7 +4273,7 @@ void merge_switch_to_result(struct merge_options *opt,
}
if (display_update_msgs)
- merge_display_update_messages(opt, result);
+ merge_display_update_messages(opt, result, stdout);
merge_finalize(opt, result);
}
diff --git a/merge-ort.h b/merge-ort.h
index 1b93555a60b..55819a57da8 100644
--- a/merge-ort.h
+++ b/merge-ort.h
@@ -76,7 +76,8 @@ void merge_switch_to_result(struct merge_options *opt,
* so only call this when bypassing merge_switch_to_result().
*/
void merge_display_update_messages(struct merge_options *opt,
- struct merge_result *result);
+ struct merge_result *result,
+ FILE *stream);
/* Do needed cleanup when not calling merge_switch_to_result() */
void merge_finalize(struct merge_options *opt,
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 7/8] merge-tree: support saving merge messages to a separate file
From: Elijah Newren via GitGitGadget @ 2022-01-05 17:27 UTC (permalink / raw)
To: git
Cc: Christian Couder, Taylor Blau, Johannes Altmanninger,
Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1114.v2.git.git.1641403655.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
When running `git merge-tree --real`, we previously would only return an
exit status reflecting the cleanness of a merge, and print out the
toplevel tree of the resulting merge. Merges also have informational
messages, ("Auto-merging <PATH>", "CONFLICT (content): ...", "CONFLICT
(file/directory)", etc.) In fact, when non-content conflicts occur
(such as file/directory, modify/delete, add/add with differing modes,
rename/rename (1to2), etc.), these informational messages are often the
only notification since these conflicts are not representable in the
contents of the file.
Add a --messages option which names a file so that callers can request
these messages be recorded somewhere.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
Documentation/git-merge-tree.txt | 6 ++++--
builtin/merge-tree.c | 18 ++++++++++++++++--
t/t4301-merge-tree-real.sh | 18 ++++++++++++++++++
3 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt
index 5823938937f..4d5857b390b 100644
--- a/Documentation/git-merge-tree.txt
+++ b/Documentation/git-merge-tree.txt
@@ -9,7 +9,7 @@ git-merge-tree - Perform merge without touching index or working tree
SYNOPSIS
--------
[verse]
-'git merge-tree' --real <branch1> <branch2>
+'git merge-tree' --real [--messages=<file>] <branch1> <branch2>
'git merge-tree' <base-tree> <branch1> <branch2>
DESCRIPTION
@@ -21,7 +21,9 @@ The first form will merge the two branches, doing a full recursive
merge with rename detection. If the merge is clean, the exit status
will be `0`, and if the merge has conflicts, the exit status will be
`1`. The output will consist solely of the resulting toplevel tree
-(which may have files including conflict markers).
+(which may have files including conflict markers). With `--messages`,
+it will write any informational messages (such as "Auto-merging
+<path>" and conflict notices) to the given file.
The second form is meant for backward compatibility and will only do a
trival merge. It reads three tree-ish, and outputs trivial merge
diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index ac50f3d108b..46b746b6b7c 100644
--- a/builtin/merge-tree.c
+++ b/builtin/merge-tree.c
@@ -390,6 +390,7 @@ static int trivial_merge(const char *base,
struct merge_tree_options {
int real;
+ char *messages_file;
};
static int real_merge(struct merge_tree_options *o,
@@ -443,8 +444,15 @@ static int real_merge(struct merge_tree_options *o,
*/
merge_incore_recursive(&opt, merge_bases, parent1, parent2, &result);
+
+ if (o->messages_file) {
+ FILE *fp = xfopen(o->messages_file, "w");
+ merge_display_update_messages(&opt, &result, fp);
+ fclose(fp);
+ }
printf("%s\n", oid_to_hex(&result.tree->object.oid));
- merge_switch_to_result(&opt, NULL, &result, 0, 0);
+
+ merge_finalize(&opt, &result);
return result.clean ? 0 : 1;
}
@@ -452,15 +460,18 @@ int cmd_merge_tree(int argc, const char **argv, const char *prefix)
{
struct merge_tree_options o = { 0 };
int expected_remaining_argc;
+ int original_argc;
const char * const merge_tree_usage[] = {
- N_("git merge-tree --real <branch1> <branch2>"),
+ N_("git merge-tree --real [<options>] <branch1> <branch2>"),
N_("git merge-tree <base-tree> <branch1> <branch2>"),
NULL
};
struct option mt_options[] = {
OPT_BOOL(0, "real", &o.real,
N_("do a real merge instead of a trivial merge")),
+ OPT_STRING(0, "messages", &o.messages_file, N_("file"),
+ N_("filename to write informational/conflict messages to")),
OPT_END()
};
@@ -469,8 +480,11 @@ int cmd_merge_tree(int argc, const char **argv, const char *prefix)
usage_with_options(merge_tree_usage, mt_options);
/* Parse arguments */
+ original_argc = argc;
argc = parse_options(argc, argv, prefix, mt_options,
merge_tree_usage, 0);
+ if (!o.real && original_argc < argc)
+ die(_("--real must be specified if any other options are"));
expected_remaining_argc = (o.real ? 2 : 3);
if (argc != expected_remaining_argc)
usage_with_options(merge_tree_usage, mt_options);
diff --git a/t/t4301-merge-tree-real.sh b/t/t4301-merge-tree-real.sh
index f7aa310f8c1..5f3f27f504d 100755
--- a/t/t4301-merge-tree-real.sh
+++ b/t/t4301-merge-tree-real.sh
@@ -78,4 +78,22 @@ test_expect_success 'Barf on too many arguments' '
grep "^usage: git merge-tree" expect
'
+test_expect_success '--messages gives us the conflict notices and such' '
+ test_must_fail git merge-tree --real --messages=MSG_FILE side1 side2 &&
+
+ # Expected results:
+ # "greeting" should merge with conflicts
+ # "numbers" should merge cleanly
+ # "whatever" has *both* a modify/delete and a file/directory conflict
+ cat <<-EOF >expect &&
+ Auto-merging greeting
+ CONFLICT (content): Merge conflict in greeting
+ Auto-merging numbers
+ CONFLICT (file/directory): directory in the way of whatever from side1; moving it to whatever~side1 instead.
+ CONFLICT (modify/delete): whatever~side1 deleted in side2 and modified in side1. Version side1 of whatever~side1 left in tree.
+ EOF
+
+ test_cmp expect MSG_FILE
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related
* [PATCH v2 8/8] merge-tree: provide an easy way to access which files have conflicts
From: Elijah Newren via GitGitGadget @ 2022-01-05 17:27 UTC (permalink / raw)
To: git
Cc: Christian Couder, Taylor Blau, Johannes Altmanninger,
Elijah Newren, Elijah Newren, Elijah Newren
In-Reply-To: <pull.1114.v2.git.git.1641403655.gitgitgadget@gmail.com>
From: Elijah Newren <newren@gmail.com>
Callers of `git merge-tree --real` might want an easy way to determine
which files conflicted. While they could potentially use the --messages
option and parse the resulting messages written to that file, those
messages are not meant to be machine readable. Provide a simpler
mechanism of having the user specify --unmerged-list=$FILENAME, and then
write a NUL-separated list of unmerged filenames to the specified file.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
Documentation/git-merge-tree.txt | 6 ++++--
builtin/merge-tree.c | 16 ++++++++++++++++
merge-ort.c | 13 +++++++++++++
merge-ort.h | 3 +++
t/t4301-merge-tree-real.sh | 9 +++++++++
5 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge-tree.txt b/Documentation/git-merge-tree.txt
index 4d5857b390b..542cea1a1a8 100644
--- a/Documentation/git-merge-tree.txt
+++ b/Documentation/git-merge-tree.txt
@@ -9,7 +9,7 @@ git-merge-tree - Perform merge without touching index or working tree
SYNOPSIS
--------
[verse]
-'git merge-tree' --real [--messages=<file>] <branch1> <branch2>
+'git merge-tree' --real [--messages=<file>] [--conflicted-list=<file>] <branch1> <branch2>
'git merge-tree' <base-tree> <branch1> <branch2>
DESCRIPTION
@@ -23,7 +23,9 @@ will be `0`, and if the merge has conflicts, the exit status will be
`1`. The output will consist solely of the resulting toplevel tree
(which may have files including conflict markers). With `--messages`,
it will write any informational messages (such as "Auto-merging
-<path>" and conflict notices) to the given file.
+<path>" and conflict notices) to the given file. With
+`--conflicted-list`, it will write a list of unmerged files, one per
+line, to the given file.
The second form is meant for backward compatibility and will only do a
trival merge. It reads three tree-ish, and outputs trivial merge
diff --git a/builtin/merge-tree.c b/builtin/merge-tree.c
index 46b746b6b7c..4ae34da98b1 100644
--- a/builtin/merge-tree.c
+++ b/builtin/merge-tree.c
@@ -391,6 +391,7 @@ static int trivial_merge(const char *base,
struct merge_tree_options {
int real;
char *messages_file;
+ char *conflicted_file;
};
static int real_merge(struct merge_tree_options *o,
@@ -450,6 +451,19 @@ static int real_merge(struct merge_tree_options *o,
merge_display_update_messages(&opt, &result, fp);
fclose(fp);
}
+ if (o->conflicted_file) {
+ struct string_list conflicted_files = STRING_LIST_INIT_NODUP;
+ FILE *fp = xfopen(o->conflicted_file, "w");
+ int i;
+
+ merge_get_conflicted_files(&result, &conflicted_files);
+ for (i = 0; i < conflicted_files.nr; i++) {
+ fprintf(fp, "%s", conflicted_files.items[i].string);
+ fputc('\0', fp);
+ }
+ fclose(fp);
+ string_list_clear(&conflicted_files, 0);
+ }
printf("%s\n", oid_to_hex(&result.tree->object.oid));
merge_finalize(&opt, &result);
@@ -472,6 +486,8 @@ int cmd_merge_tree(int argc, const char **argv, const char *prefix)
N_("do a real merge instead of a trivial merge")),
OPT_STRING(0, "messages", &o.messages_file, N_("file"),
N_("filename to write informational/conflict messages to")),
+ OPT_STRING(0, "conflicted-list", &o.conflicted_file, N_("file"),
+ N_("filename to write list of unmerged files")),
OPT_END()
};
diff --git a/merge-ort.c b/merge-ort.c
index 86eebf39166..3d6dd1b234c 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -4234,6 +4234,19 @@ void merge_display_update_messages(struct merge_options *opt,
trace2_region_leave("merge", "display messages", opt->repo);
}
+void merge_get_conflicted_files(struct merge_result *result,
+ struct string_list *conflicted_files)
+{
+ struct hashmap_iter iter;
+ struct strmap_entry *e;
+ struct merge_options_internal *opti = result->priv;
+
+ strmap_for_each_entry(&opti->conflicted, &iter, e) {
+ string_list_append(conflicted_files, e->key);
+ }
+ string_list_sort(conflicted_files);
+}
+
void merge_switch_to_result(struct merge_options *opt,
struct tree *head,
struct merge_result *result,
diff --git a/merge-ort.h b/merge-ort.h
index 55819a57da8..165cef6616f 100644
--- a/merge-ort.h
+++ b/merge-ort.h
@@ -79,6 +79,9 @@ void merge_display_update_messages(struct merge_options *opt,
struct merge_result *result,
FILE *stream);
+void merge_get_conflicted_files(struct merge_result *result,
+ struct string_list *conflicted_files);
+
/* Do needed cleanup when not calling merge_switch_to_result() */
void merge_finalize(struct merge_options *opt,
struct merge_result *result);
diff --git a/t/t4301-merge-tree-real.sh b/t/t4301-merge-tree-real.sh
index 5f3f27f504d..ec7bd8efd06 100755
--- a/t/t4301-merge-tree-real.sh
+++ b/t/t4301-merge-tree-real.sh
@@ -96,4 +96,13 @@ test_expect_success '--messages gives us the conflict notices and such' '
test_cmp expect MSG_FILE
'
+test_expect_success '--messages gives us the conflict notices and such' '
+ test_must_fail git merge-tree --real --conflicted-list=UNMERGED side1 side2 &&
+
+ cat UNMERGED | tr "\0" "\n" >actual &&
+ test_write_lines greeting whatever~side1 >expect &&
+
+ test_cmp expect actual
+'
+
test_done
--
gitgitgadget
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH] ice: Use bitmap_free() to free bitmap
From: G, GurucharanX @ 2022-01-05 17:27 UTC (permalink / raw)
To: Christophe JAILLET, Brandeburg, Jesse, Nguyen, Anthony L,
davem@davemloft.net, kuba@kernel.org
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org
In-Reply-To: <d139eb69eb12c9793a2a3b65e94f74d4cee2a39c.1640529439.git.christophe.jaillet@wanadoo.fr>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Christophe JAILLET
> Sent: Sunday, December 26, 2021 8:09 PM
> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net; kuba@kernel.org
> Cc: netdev@vger.kernel.org; kernel-janitors@vger.kernel.org; Christophe
> JAILLET <christophe.jaillet@wanadoo.fr>; intel-wired-lan@lists.osuosl.org;
> linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] ice: Use bitmap_free() to free bitmap
>
> kfree() and bitmap_free() are the same. But using the latter is more consistent
> when freeing memory allocated with bitmap_zalloc().
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/intel/ice/ice_ptp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* [Intel-wired-lan] [PATCH] ice: Optimize a few bitmap operations
From: G, GurucharanX @ 2022-01-05 17:28 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <b0cf67c12895e40b403a435192d47b0ac1a00def.1640250120.git.christophe.jaillet@wanadoo.fr>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Christophe JAILLET
> Sent: Thursday, December 23, 2021 2:34 PM
> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem at davemloft.net; kuba at kernel.org
> Cc: netdev at vger.kernel.org; kernel-janitors at vger.kernel.org; Christophe
> JAILLET <christophe.jaillet@wanadoo.fr>; intel-wired-lan at lists.osuosl.org;
> linux-kernel at vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] ice: Optimize a few bitmap operations
>
> When a bitmap is local to a function, it is safe to use the non-atomic
> __[set|clear]_bit(). No concurrent accesses can occur.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/intel/ice/ice_flex_pipe.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] ice: Optimize a few bitmap operations
From: G, GurucharanX @ 2022-01-05 17:28 UTC (permalink / raw)
To: Christophe JAILLET, Brandeburg, Jesse, Nguyen, Anthony L,
davem@davemloft.net, kuba@kernel.org
Cc: netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org
In-Reply-To: <b0cf67c12895e40b403a435192d47b0ac1a00def.1640250120.git.christophe.jaillet@wanadoo.fr>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Christophe JAILLET
> Sent: Thursday, December 23, 2021 2:34 PM
> To: Brandeburg, Jesse <jesse.brandeburg@intel.com>; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; davem@davemloft.net; kuba@kernel.org
> Cc: netdev@vger.kernel.org; kernel-janitors@vger.kernel.org; Christophe
> JAILLET <christophe.jaillet@wanadoo.fr>; intel-wired-lan@lists.osuosl.org;
> linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] ice: Optimize a few bitmap operations
>
> When a bitmap is local to a function, it is safe to use the non-atomic
> __[set|clear]_bit(). No concurrent accesses can occur.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> drivers/net/ethernet/intel/ice/ice_flex_pipe.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
^ permalink raw reply
* [PATCH 0/4] HID: hid-uclogic-params: Fix NULL pointer dereferences
From: José Expósito @ 2022-01-05 17:29 UTC (permalink / raw)
To: jikos
Cc: benjamin.tissoires, linux-input, linux-kernel, spbnick,
José Expósito
Hi everyone,
This series fixes 4 possible NULL pointer dereference errors
present in hid-uclogic-params.c found by Coverity.
Even though the fixes are small and very similar I made them
in 4 patches to include the Coverity ID on each of them and
make Coverity happy.
I didn't find any code calling the functions with invalid
params, but since the check is there, it's better to make sure
that it's doing its job.
Thanks,
José Expósito
José Expósito (4):
HID: hid-uclogic-params: Invalid parameter check in
uclogic_params_init
HID: hid-uclogic-params: Invalid parameter check in
uclogic_params_get_str_desc
HID: hid-uclogic-params: Invalid parameter check in
uclogic_params_huion_init
HID: hid-uclogic-params: Invalid parameter check in
uclogic_params_frame_init_v1_buttonpad
drivers/hid/hid-uclogic-params.c | 31 ++++++++++++++++++++++---------
1 file changed, 22 insertions(+), 9 deletions(-)
--
2.25.1
^ permalink raw reply
* [PATCH 1/4] HID: hid-uclogic-params: Invalid parameter check in uclogic_params_init
From: José Expósito @ 2022-01-05 17:29 UTC (permalink / raw)
To: jikos
Cc: benjamin.tissoires, linux-input, linux-kernel, spbnick,
José Expósito
In-Reply-To: <20220105172915.131091-1-jose.exposito89@gmail.com>
The function performs a check on its input parameters, however, the
hdev parameter is used before the check.
Initialize the stack variables after checking the input parameters to
avoid a possible NULL pointer dereference.
Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443831 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
---
drivers/hid/hid-uclogic-params.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
index adff1bd68d9f..3c10b858cf74 100644
--- a/drivers/hid/hid-uclogic-params.c
+++ b/drivers/hid/hid-uclogic-params.c
@@ -834,10 +834,10 @@ int uclogic_params_init(struct uclogic_params *params,
struct hid_device *hdev)
{
int rc;
- struct usb_device *udev = hid_to_usb_dev(hdev);
- __u8 bNumInterfaces = udev->config->desc.bNumInterfaces;
- struct usb_interface *iface = to_usb_interface(hdev->dev.parent);
- __u8 bInterfaceNumber = iface->cur_altsetting->desc.bInterfaceNumber;
+ struct usb_device *udev;
+ __u8 bNumInterfaces;
+ struct usb_interface *iface;
+ __u8 bInterfaceNumber;
bool found;
/* The resulting parameters (noop) */
struct uclogic_params p = {0, };
@@ -848,6 +848,11 @@ int uclogic_params_init(struct uclogic_params *params,
goto cleanup;
}
+ udev = hid_to_usb_dev(hdev);
+ bNumInterfaces = udev->config->desc.bNumInterfaces;
+ iface = to_usb_interface(hdev->dev.parent);
+ bInterfaceNumber = iface->cur_altsetting->desc.bInterfaceNumber;
+
/*
* Set replacement report descriptor if the original matches the
* specified size. Otherwise keep interface unchanged.
--
2.25.1
^ permalink raw reply related
* [PATCH 2/4] HID: hid-uclogic-params: Invalid parameter check in uclogic_params_get_str_desc
From: José Expósito @ 2022-01-05 17:29 UTC (permalink / raw)
To: jikos
Cc: benjamin.tissoires, linux-input, linux-kernel, spbnick,
José Expósito
In-Reply-To: <20220105172915.131091-1-jose.exposito89@gmail.com>
The function performs a check on the hdev input parameters, however, it
is used before the check.
Initialize the udev variable after the sanity check to avoid a
possible NULL pointer dereference.
Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443827 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
---
drivers/hid/hid-uclogic-params.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
index 3c10b858cf74..3a83e2c39b4f 100644
--- a/drivers/hid/hid-uclogic-params.c
+++ b/drivers/hid/hid-uclogic-params.c
@@ -66,7 +66,7 @@ static int uclogic_params_get_str_desc(__u8 **pbuf, struct hid_device *hdev,
__u8 idx, size_t len)
{
int rc;
- struct usb_device *udev = hid_to_usb_dev(hdev);
+ struct usb_device *udev;
__u8 *buf = NULL;
/* Check arguments */
@@ -75,6 +75,8 @@ static int uclogic_params_get_str_desc(__u8 **pbuf, struct hid_device *hdev,
goto cleanup;
}
+ udev = hid_to_usb_dev(hdev);
+
buf = kmalloc(len, GFP_KERNEL);
if (buf == NULL) {
rc = -ENOMEM;
--
2.25.1
^ permalink raw reply related
* [PATCH 3/4] HID: hid-uclogic-params: Invalid parameter check in uclogic_params_huion_init
From: José Expósito @ 2022-01-05 17:29 UTC (permalink / raw)
To: jikos
Cc: benjamin.tissoires, linux-input, linux-kernel, spbnick,
José Expósito
In-Reply-To: <20220105172915.131091-1-jose.exposito89@gmail.com>
The function performs a check on its input parameters, however, the
hdev parameter is used before the check.
Initialize the stack variables after checking the input parameters to
avoid a possible NULL pointer dereference.
Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443804 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
---
drivers/hid/hid-uclogic-params.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
index 3a83e2c39b4f..4136837e4d15 100644
--- a/drivers/hid/hid-uclogic-params.c
+++ b/drivers/hid/hid-uclogic-params.c
@@ -709,9 +709,9 @@ static int uclogic_params_huion_init(struct uclogic_params *params,
struct hid_device *hdev)
{
int rc;
- struct usb_device *udev = hid_to_usb_dev(hdev);
- struct usb_interface *iface = to_usb_interface(hdev->dev.parent);
- __u8 bInterfaceNumber = iface->cur_altsetting->desc.bInterfaceNumber;
+ struct usb_device *udev;
+ struct usb_interface *iface;
+ __u8 bInterfaceNumber;
bool found;
/* The resulting parameters (noop) */
struct uclogic_params p = {0, };
@@ -725,6 +725,10 @@ static int uclogic_params_huion_init(struct uclogic_params *params,
goto cleanup;
}
+ udev = hid_to_usb_dev(hdev);
+ iface = to_usb_interface(hdev->dev.parent);
+ bInterfaceNumber = iface->cur_altsetting->desc.bInterfaceNumber;
+
/* If it's not a pen interface */
if (bInterfaceNumber != 0) {
/* TODO: Consider marking the interface invalid */
--
2.25.1
^ permalink raw reply related
* [PATCH 4/4] HID: hid-uclogic-params: Invalid parameter check in uclogic_params_frame_init_v1_buttonpad
From: José Expósito @ 2022-01-05 17:29 UTC (permalink / raw)
To: jikos
Cc: benjamin.tissoires, linux-input, linux-kernel, spbnick,
José Expósito
In-Reply-To: <20220105172915.131091-1-jose.exposito89@gmail.com>
The function performs a check on the hdev input parameters, however, it
is used before the check.
Initialize the udev variable after the sanity check to avoid a
possible NULL pointer dereference.
Fixes: 9614219e9310e ("HID: uclogic: Extract tablet parameter discovery into a module")
Addresses-Coverity-ID: 1443763 ("Null pointer dereference")
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
---
drivers/hid/hid-uclogic-params.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-uclogic-params.c b/drivers/hid/hid-uclogic-params.c
index 4136837e4d15..3e70f969fb84 100644
--- a/drivers/hid/hid-uclogic-params.c
+++ b/drivers/hid/hid-uclogic-params.c
@@ -452,7 +452,7 @@ static int uclogic_params_frame_init_v1_buttonpad(
{
int rc;
bool found = false;
- struct usb_device *usb_dev = hid_to_usb_dev(hdev);
+ struct usb_device *usb_dev;
char *str_buf = NULL;
const size_t str_len = 16;
@@ -462,6 +462,8 @@ static int uclogic_params_frame_init_v1_buttonpad(
goto cleanup;
}
+ usb_dev = hid_to_usb_dev(hdev);
+
/*
* Enable generic button mode
*/
--
2.25.1
^ permalink raw reply related
* Re: [RFC PATCH 2/2] merge-ort: add t/t4310-merge-tree-ort.sh
From: Elijah Newren @ 2022-01-05 17:29 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano, Christian Couder,
Ævar Arnfjörð Bjarmason, Taylor Blau,
Johannes Schindelin
In-Reply-To: <20220105163324.73369-3-chriscool@tuxfamily.org>
On Wed, Jan 5, 2022 at 8:33 AM Christian Couder
<christian.couder@gmail.com> wrote:
>
> This adds a few tests for the new merge-tree-ort command. They have
> been copy-pasted from t4300-merge-tree.sh, and then the expected
> output has been adjusted.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> t/t4310-merge-tree-ort.sh | 162 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 162 insertions(+)
> create mode 100755 t/t4310-merge-tree-ort.sh
>
> diff --git a/t/t4310-merge-tree-ort.sh b/t/t4310-merge-tree-ort.sh
> new file mode 100755
> index 0000000000..9a54508e82
> --- /dev/null
> +++ b/t/t4310-merge-tree-ort.sh
> @@ -0,0 +1,162 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2010 Will Palmer
> +# Copyright (c) 2021 Christian Couder
> +#
> +
> +test_description='git merge-tree-ort'
> +
> +TEST_PASSES_SANITIZE_LEAK=true
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> + test_commit "initial" "initial-file" "initial"
> +'
> +
> +test_expect_success 'file add A, !B' '
> + git reset --hard initial &&
> + test_commit "add-a-not-b" "ONE" "AAA" &&
> + git merge-tree-ort initial initial add-a-not-b >actual &&
> + cat >expected <<EXPECTED &&
> +result tree: ee38e20a5c0e1698539ac99d55616079a04fce26
So the tests only work on sha1? My tests in
https://lore.kernel.org/git/pull.1114.git.git.1640927044.gitgitgadget@gmail.com/
are sha256 compatible.
> +clean: 1
> +diff with branch1:
> +:000000 100644 0000000 43d5a8e A ONE
> +
> +diff --git a/ONE b/ONE
> +new file mode 100644
> +index 0000000..43d5a8e
> +--- /dev/null
> ++++ b/ONE
> +@@ -0,0 +1 @@
> ++AAA
Oh, this isn't just a --raw diff, but both a raw and full diff? I
missed that reading over the previous patch. This seems potentially
*extremely* expensive for big repos; dramatically more so than the
merge portion of the operation. (Any files modified on just one side
can be trivially merged without looking at the contents. In fact,
directories only modified on one side can usually be trivially merged
without looking at the contents. But merges are going to modify lots
of files relative to either of the two sides and especially relative
to the merge base, and doing a full diff is going to have to crack
open every one of those files -- multiple times since you do it
against the base as well -- to show this output). I don't think this
is what you want.
> +diff with branch2:
> +diff with base:
> +:000000 100644 0000000 43d5a8e A ONE
> +
> +diff --git a/ONE b/ONE
> +new file mode 100644
> +index 0000000..43d5a8e
> +--- /dev/null
> ++++ b/ONE
> +@@ -0,0 +1 @@
> ++AAA
> +EXPECTED
> +
> + test_cmp expected actual
> +'
> +
> +test_expect_success 'file add !A, B' '
> + git reset --hard initial &&
> + test_commit "add-not-a-b" "ONE" "AAA" &&
> + git merge-tree-ort initial add-not-a-b initial >actual &&
> + cat >expected <<EXPECTED &&
> +result tree: ee38e20a5c0e1698539ac99d55616079a04fce26
> +clean: 1
> +diff with branch1:
> +diff with branch2:
> +:000000 100644 0000000 43d5a8e A ONE
> +
> +diff --git a/ONE b/ONE
> +new file mode 100644
> +index 0000000..43d5a8e
> +--- /dev/null
> ++++ b/ONE
> +@@ -0,0 +1 @@
> ++AAA
> +diff with base:
> +:000000 100644 0000000 43d5a8e A ONE
> +
> +diff --git a/ONE b/ONE
> +new file mode 100644
> +index 0000000..43d5a8e
> +--- /dev/null
> ++++ b/ONE
> +@@ -0,0 +1 @@
> ++AAA
> +EXPECTED
> +
> + test_cmp expected actual
> +'
> +
> +test_expect_success 'file add A, B (same)' '
> + git reset --hard initial &&
> + test_commit "add-a-b-same-A" "ONE" "AAA" &&
> + git reset --hard initial &&
> + test_commit "add-a-b-same-B" "ONE" "AAA" &&
> + git merge-tree-ort initial add-a-b-same-A add-a-b-same-B >actual &&
> + cat >expected <<EXPECTED &&
> +result tree: ee38e20a5c0e1698539ac99d55616079a04fce26
> +clean: 1
> +diff with branch1:
> +diff with branch2:
> +diff with base:
> +:000000 100644 0000000 43d5a8e A ONE
> +
> +diff --git a/ONE b/ONE
> +new file mode 100644
> +index 0000000..43d5a8e
> +--- /dev/null
> ++++ b/ONE
> +@@ -0,0 +1 @@
> ++AAA
> +EXPECTED
> +
> + test_cmp expected actual
> +'
> +
> +test_expect_success 'file add A, B (different)' '
> + git reset --hard initial &&
> + test_commit "add-a-b-diff-A" "ONE" "AAA" &&
> + git reset --hard initial &&
> + test_commit "add-a-b-diff-B" "ONE" "BBB" &&
> + git merge-tree-ort initial add-a-b-diff-A add-a-b-diff-B >actual &&
> + cat >expected <<EXPECTED &&
> +result tree: 3aa938e8cc8be73c81cbaf629ea55a16e7c39319
> +clean: 0
> +diff with branch1:
> +:100644 100644 43d5a8e 1e462bc M ONE
> +
> +diff --git a/ONE b/ONE
> +index 43d5a8e..1e462bc 100644
> +--- a/ONE
> ++++ b/ONE
> +@@ -1 +1,5 @@
> ++<<<<<<< add-a-b-diff-A
> + AAA
> ++=======
> ++BBB
> ++>>>>>>> add-a-b-diff-B
> +diff with branch2:
> +:100644 100644 ba62923 1e462bc M ONE
> +
> +diff --git a/ONE b/ONE
> +index ba62923..1e462bc 100644
> +--- a/ONE
> ++++ b/ONE
> +@@ -1 +1,5 @@
> ++<<<<<<< add-a-b-diff-A
> ++AAA
> ++=======
> + BBB
> ++>>>>>>> add-a-b-diff-B
> +diff with base:
> +:000000 100644 0000000 1e462bc A ONE
> +
> +diff --git a/ONE b/ONE
> +new file mode 100644
> +index 0000000..1e462bc
> +--- /dev/null
> ++++ b/ONE
> +@@ -0,0 +1,5 @@
> ++<<<<<<< add-a-b-diff-A
> ++AAA
> ++=======
> ++BBB
> ++>>>>>>> add-a-b-diff-B
> +EXPECTED
> +
> + test_cmp expected actual
> +'
> +
> +test_done
> --
I've focused a bit on the things that I didn't care as much for, but
the usage of the merge-ort API was solid and there are pieces here
that look quite simliar to what I'd expect...and in fact, to what I
also implemented. Perhaps there are multiple things I also overlooked
in my implementation of this idea; would be great to get your comments
on that, over at [1].
And, as a heads up, as noted at [2], I'm also working on the
server-side cherry-pick/rebase.
[1] https://lore.kernel.org/git/pull.1114.v2.git.git.1641403655.gitgitgadget@gmail.com/
[2] https://lore.kernel.org/git/CABPp-BHpK8hPsiuHoYsf5D_rjcGLSW-_faL3ODoh56pG_2Luwg@mail.gmail.com/
^ permalink raw reply
* Git bug report git remote get-url
From: Nanekrangsan, Sucheela (NYC-GIS) @ 2022-01-05 17:22 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Frank, Carson (OMA-GIS)
Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.
What did you do before the bug happened? (Steps to reproduce your issue)
1. I put [remote] entries in /etc/gitconfig
2. `git config --get remote.xxx.url` returns the correct URL. I can `git pull` from this remote.
3. `git remote get-url xxx` returns "error: No such remote 'xxx'"
4. After `git remote add xxx`, I can get the URL from `git remote get-url`.
What did you expect to happen? (Expected behavior)
I expected `git-remote get-url` to give me the URL I added in /etc/gitconfig.
What happened instead? (Actual behavior)
`git remote get-url` did not recognize the report I added in /etc/gitconfig.
What's different between what you expected and what actually happened?
I expected the URL from /etc/gitconfig from `git remote get-url` but got error.
Anything else you want to add:
These give me the correct results
`git config --get remote.xxx.url`
`git ls-remote --get-url xxx`
Please review the rest of the bug report below.
You can delete any lines you don't wish to share.
[System Info]
git version:
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 3.10.0-1160.49.1.el7.x86_64 #1 SMP Tue Nov 30 15:51:32 UTC 2021 x86_64
compiler info: gnuc: 4.8
libc info: glibc: 2.17
$SHELL (typically, interactive shell): /bin/bash
This message contains information which may be confidential and privileged. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message. Thank you very much.
^ permalink raw reply
* Re: [Intel-gfx] [RFC 7/7] drm/i915/guc: Print the GuC error capture output register list.
From: Teres Alexis, Alan Previn @ 2022-01-05 17:30 UTC (permalink / raw)
To: Brost, Matthew, tvrtko.ursulin@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
In-Reply-To: <8257f42f-7bbd-c033-28f1-f43f21cc81af@linux.intel.com>
On Tue, 2022-01-04 at 13:56 +0000, Tvrtko Ursulin wrote:
>
> > The flow of events are as below:
> >
> > 1. guc sends notification that an error capture was done and ready to take.
> > - at this point we copy the guc error captured dump into an interim store
> > (larger buffer that can hold multiple captures).
> > 2. guc sends notification that a context was reset (after the prior)
> > - this triggers a call to i915_gpu_coredump with the corresponding engine-mask
> > from the context that was reset
> > - i915_gpu_coredump proceeds to gather entire gpu state including driver state,
> > global gpu state, engine state, context vmas and also engine registers. For the
> > engine registers now call into the guc_capture code which merely needs to verify
> > that GuC had already done a step 1 and we have data ready to be parsed.
>
> What about the time between the actual reset and receiving the context
> reset notification? Latter will contain intel_context->guc_id - can that
> be re-assigned or "retired" in between the two and so cause problems for
> matching the correct (or any) vmas?
>
Not it cannot because its only after the context reset notification that i915 starts
taking action against that cotnext - and even that happens after the i915_gpu_codedump (engine-mask-of-context) happens.
That's what i've observed in the code flow.
> Regards,
>
> Tvrtko
^ permalink raw reply
* Re: [OE-core] [PATCH 2/2] package.bbclass: don't skip kernel and kernel modules
From: Bruce Ashfield @ 2022-01-05 17:30 UTC (permalink / raw)
To: Richard Purdie
Cc: Saul Wold, Patches and discussions about the oe-core layer,
Joshua Watt, Bruce Ashfield
In-Reply-To: <f55b92395da477d06df9b545ac6fc7ac47d0df41.camel@linuxfoundation.org>
On Wed, Jan 5, 2022 at 12:07 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2022-01-04 at 14:07 -0800, Saul Wold wrote:
> >
> > On 12/22/21 01:09, Richard Purdie wrote:
> > > On Tue, 2021-12-21 at 11:08 -0800, Saul Wold wrote:
> > > > Stop ignoring or skipping the kernel and kernel modules code in the
> > > > split debug and striping functions, this will allow create_spdx to
> > > > process the kernel and modules.
> > > >
> > > > Signed-off-by: Saul Wold <saul.wold@windriver.com>
> > > > ---
> > > > meta/classes/package.bbclass | 8 ++------
> > > > 1 file changed, 2 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> > > > index 84eafbd529..4b7fe4f1e1 100644
> > > > --- a/meta/classes/package.bbclass
> > > > +++ b/meta/classes/package.bbclass
> > > > @@ -390,10 +390,6 @@ def splitdebuginfo(file, dvar, debugdir, debuglibdir, debugappend, debugsrcdir,
> > > > dvar = d.getVar('PKGD')
> > > > objcopy = d.getVar("OBJCOPY")
> > > >
> > > > - # We ignore kernel modules, we don't generate debug info files.
> > > > - if file.find("/lib/modules/") != -1 and file.endswith(".ko"):
> > > > - return (file, sources)
> > > > -
> > > > newmode = None
> > > > if not os.access(file, os.W_OK) or os.access(file, os.R_OK):
> > > > origmode = os.stat(file)[stat.ST_MODE]
> > > > @@ -1147,7 +1143,7 @@ python split_and_strip_files () {
> > > >
> > > > if file.endswith(".ko") and file.find("/lib/modules/") != -1:
> > > > kernmods.append(file)
> > > > - continue
> > > > +
> > > > if oe.package.is_static_lib(file):
> > > > staticlibs.append(file)
> > > > continue
> > > > @@ -1165,7 +1161,7 @@ python split_and_strip_files () {
> > > > continue
> > > > # Check its an executable
> > > > if (s[stat.ST_MODE] & stat.S_IXUSR) or (s[stat.ST_MODE] & stat.S_IXGRP) or (s[stat.ST_MODE] & stat.S_IXOTH) \
> > > > - or ((file.startswith(libdir) or file.startswith(baselibdir)) and (".so" in f or ".node" in f)):
> > > > + or ((file.startswith(libdir) or file.startswith(baselibdir)) and (".so" in f or ".node" in f)) or (f.startswith('vmlinux') or ".ko" in f):
> > > >
> > > > if cpath.islink(file):
> > > > checkelflinks[file] = ltarget
> > >
> > > edgerouter:
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/4513
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/111/builds/2507/steps/11/logs/stdio
> > >
> > So I have been digging into this and it seems that an option was added a
> > decade ago or so to strip the kernel/vmlinux when it's too big, this was
> > done for at least the routerstationpro according to bug #3515 [0], and
> > persists with the edgerouter, although I am not sure if it would still
> > actually be required as the edgerouter also uses the
> > KERNEL_ALT_IMAGETYPE to create a smaller binary kernel image.
> >
> > The change I proposed causes the all kernels to be stripped all the time
> > as part of the split_and_strip_files(). As I see it there few different
> > options:
> >
> > 1) Set KERNEL_IMAGE_EXTRA_STRIP_SECTIONS = "" in create_spdx.bbclass
> > - This solves the problem with create_spdx.bbclass is in use, but not
> > the general case
>
> I don't think I like this as it is a side effect that isn't obvious or expected.
>
> >
> > 2) Remove the KERNEL_IMAGE_EXTRA_STRIP_SECTIONS from edgerouter.conf
> > - Will solve the edgerouter case but may not solve other usages
> > unknown to me.
> > - Does anyone know of other machines/layers usage of this variable?
> >
> > 3) deprecate the kernel.bbclass:do_strip function in favor of using the
> > split_and_strip_files() of package.bbclass
>
> I know Bruce has said he doesn't like this, however stepping back, these issues
> were from a time our stripping code was young and evolving. If we can
> standardise and have it all work together well in one set of functions, I think
> that is worth looking at. I'd prefer the kernel wasn't a special case if it no
> longer needs to be.
>
> That said, I don't remember the details of why we did this.
There's a middle ground of debug being possible, and some sections
removed to keep the footprint a bit lower. There were also some
unwinders, etc, that didn't work when everything was stripped and
split into debug. The stripping was too aggressive, and removed some
sections that were required.
While I can't exactly point to the use cases for it now, with the 5K
options in the kernel, they haven't all been removed, and I'd be very
hesitant to remove the capability completely.
Bruce
>
>
> >
> > 4) Change error to warning in packaging.bbclass for the kernel only
> > - This would explain that a kernel image (vmlinux) is already
> > stripped and extended package data would not be available for for SPDX
> > creation.
> >
> > RP, Bruce, Joshua: Thoughts?
>
> If we can simplify and stop the kernel being a special case for this code (or
> handle kernels generically) that would be worth a bit of effort IMO...
>
> Cheers,
>
> Richard
>
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#160211): https://lists.openembedded.org/g/openembedded-core/message/160211
> Mute This Topic: https://lists.openembedded.org/mt/87884056/1050810
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
^ permalink raw reply
* [PATCH] common: handle ceph's new mount syntax
From: Jeff Layton @ 2022-01-05 17:30 UTC (permalink / raw)
To: fstests; +Cc: guan
Cephfs is introducing a new mount device syntax. Fix the fstests
infrastructure to handle the new syntax correctly.
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
common/config | 2 +-
common/rc | 34 ++++++++++++++++++++++++++++++++--
2 files changed, 33 insertions(+), 3 deletions(-)
diff --git a/common/config b/common/config
index e0a5c5df58ff..be97436b0857 100644
--- a/common/config
+++ b/common/config
@@ -533,7 +533,7 @@ _check_device()
fi
case "$FSTYP" in
- 9p|tmpfs|virtiofs)
+ 9p|tmpfs|virtiofs|ceph)
# 9p and virtiofs mount tags are just plain strings, so anything is allowed
# tmpfs doesn't use mount source, ignore
;;
diff --git a/common/rc b/common/rc
index 7973ceb5fdf8..4fa0b818d840 100644
--- a/common/rc
+++ b/common/rc
@@ -1592,7 +1592,7 @@ _require_scratch_nocheck()
_notrun "this test requires a valid \$SCRATCH_MNT"
fi
;;
- nfs*|ceph)
+ nfs*)
echo $SCRATCH_DEV | grep -q ":/" > /dev/null 2>&1
if [ -z "$SCRATCH_DEV" -o "$?" != "0" ]; then
_notrun "this test requires a valid \$SCRATCH_DEV"
@@ -1601,6 +1601,21 @@ _require_scratch_nocheck()
_notrun "this test requires a valid \$SCRATCH_MNT"
fi
;;
+ ceph)
+ if [ -z "$SCRATCH_DEV" ]; then
+ _notrun "this test requires a valid \$SCRATCH_DEV"
+ fi
+ echo $SCRATCH_DEV | grep -q "=/" > /dev/null 2>&1
+ if [ "$?" != "0" ]; then
+ echo $SCRATCH_DEV | grep -q ":/" > /dev/null 2>&1
+ if [ "$?" != "0" ]; then
+ _notrun "this test requires a valid \$SCRATCH_DEV"
+ fi
+ fi
+ if [ ! -d "$SCRATCH_MNT" ]; then
+ _notrun "this test requires a valid \$SCRATCH_MNT"
+ fi
+ ;;
pvfs2)
echo $SCRATCH_DEV | grep -q "://" > /dev/null 2>&1
if [ -z "$SCRATCH_DEV" -o "$?" != "0" ]; then
@@ -1770,7 +1785,7 @@ _require_test()
_notrun "this test requires a valid \$TEST_DIR"
fi
;;
- nfs*|ceph)
+ nfs*)
echo $TEST_DEV | grep -q ":/" > /dev/null 2>&1
if [ -z "$TEST_DEV" -o "$?" != "0" ]; then
_notrun "this test requires a valid \$TEST_DEV"
@@ -1779,6 +1794,21 @@ _require_test()
_notrun "this test requires a valid \$TEST_DIR"
fi
;;
+ ceph)
+ if [ -z "$TEST_DEV" ]; then
+ _notrun "this test requires a valid \$TEST_DEV"
+ fi
+ echo $TEST_DEV | grep -q "=/" > /dev/null 2>&1
+ if [ "$?" != "0" ]; then
+ echo $TEST_DEV | grep -q ":/" > /dev/null 2>&1
+ if [ "$?" != "0" ]; then
+ _notrun "this test requires a valid \$TEST_DEV"
+ fi
+ fi
+ if [ ! -d "$TEST_DIR" ]; then
+ _notrun "this test requires a valid \$TEST_DIR"
+ fi
+ ;;
cifs)
echo $TEST_DEV | grep -q "//" > /dev/null 2>&1
if [ -z "$TEST_DEV" -o "$?" != "0" ]; then
--
2.33.1
^ permalink raw reply related
* Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address
From: Andrew Lunn @ 2022-01-05 17:30 UTC (permalink / raw)
To: Aaron Ma
Cc: kuba, henning.schild, linux-usb, netdev, linux-kernel, davem,
hayeswang, tiwai
In-Reply-To: <20220105151427.8373-1-aaron.ma@canonical.com>
On Wed, Jan 05, 2022 at 11:14:25PM +0800, Aaron Ma wrote:
> When plugin multiple r8152 ethernet dongles to Lenovo Docks
> or USB hub, MAC passthrough address from BIOS should be
> checked if it had been used to avoid using on other dongles.
>
> Currently builtin r8152 on Dock still can't be identified.
> First detected r8152 will use the MAC passthrough address.
I do have to wonder why you are doing this in the kernel, and not
using a udev rule? This seems to be policy, and policy does not belong
in the kernel.
Andrew
^ permalink raw reply
* [PATCH] pinctrl: sunxi: Fix H616 I2S3 pin data
From: Andre Przywara @ 2022-01-05 17:29 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Linus Walleij
Cc: Jernej Skrabec, SASANO Takayoshi, linux-gpio, linux-arm-kernel,
linux-sunxi
Two bugs have sneaked in the H616 pinctrl data:
- PH9 uses the mux value of 0x3 twice (one should be 0x5 instead)
- PH8 and PH9 use the "i2s3" function name twice in each pin
For the double pin name we use the same trick we pulled for i2s0: append
the pin function to the group name to designate the special function.
Fixes: 25adc29407fb ("pinctrl: sunxi: Add support for the Allwinner H616 pin controller")
Reported-by: SASANO Takayoshi <uaa@mx5.nisiq.net>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
index ce1917e230f4..152b71226a80 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
@@ -363,16 +363,16 @@ static const struct sunxi_desc_pin h616_pins[] = {
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
- SUNXI_FUNCTION(0x3, "i2s3"), /* DO0 */
+ SUNXI_FUNCTION(0x3, "i2s3_dout0"), /* DO0 */
SUNXI_FUNCTION(0x4, "spi1"), /* MISO */
- SUNXI_FUNCTION(0x5, "i2s3"), /* DI1 */
+ SUNXI_FUNCTION(0x5, "i2s3_din1"), /* DI1 */
SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 8)), /* PH_EINT8 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x3, "i2s3"), /* DI0 */
+ SUNXI_FUNCTION(0x3, "i2s3_din0"), /* DI0 */
SUNXI_FUNCTION(0x4, "spi1"), /* CS1 */
- SUNXI_FUNCTION(0x3, "i2s3"), /* DO1 */
+ SUNXI_FUNCTION(0x5, "i2s3_dout1"), /* DO1 */
SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 9)), /* PH_EINT9 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
SUNXI_FUNCTION(0x0, "gpio_in"),
--
2.17.6
^ permalink raw reply related
* [PATCH] pinctrl: sunxi: Fix H616 I2S3 pin data
From: Andre Przywara @ 2022-01-05 17:29 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Linus Walleij
Cc: Jernej Skrabec, SASANO Takayoshi, linux-gpio, linux-arm-kernel,
linux-sunxi
Two bugs have sneaked in the H616 pinctrl data:
- PH9 uses the mux value of 0x3 twice (one should be 0x5 instead)
- PH8 and PH9 use the "i2s3" function name twice in each pin
For the double pin name we use the same trick we pulled for i2s0: append
the pin function to the group name to designate the special function.
Fixes: 25adc29407fb ("pinctrl: sunxi: Add support for the Allwinner H616 pin controller")
Reported-by: SASANO Takayoshi <uaa@mx5.nisiq.net>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
index ce1917e230f4..152b71226a80 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
@@ -363,16 +363,16 @@ static const struct sunxi_desc_pin h616_pins[] = {
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
- SUNXI_FUNCTION(0x3, "i2s3"), /* DO0 */
+ SUNXI_FUNCTION(0x3, "i2s3_dout0"), /* DO0 */
SUNXI_FUNCTION(0x4, "spi1"), /* MISO */
- SUNXI_FUNCTION(0x5, "i2s3"), /* DI1 */
+ SUNXI_FUNCTION(0x5, "i2s3_din1"), /* DI1 */
SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 8)), /* PH_EINT8 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 9),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x3, "i2s3"), /* DI0 */
+ SUNXI_FUNCTION(0x3, "i2s3_din0"), /* DI0 */
SUNXI_FUNCTION(0x4, "spi1"), /* CS1 */
- SUNXI_FUNCTION(0x3, "i2s3"), /* DO1 */
+ SUNXI_FUNCTION(0x5, "i2s3_dout1"), /* DO1 */
SUNXI_FUNCTION_IRQ_BANK(0x6, 6, 9)), /* PH_EINT9 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(H, 10),
SUNXI_FUNCTION(0x0, "gpio_in"),
--
2.17.6
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] drivers: perf: marvell_cn10k: fix an IS_ERR() vs NULL check
From: Will Deacon @ 2022-01-05 17:31 UTC (permalink / raw)
To: Dan Carpenter, Bhaskara Budiredla
Cc: catalin.marinas, kernel-team, Will Deacon, kernel-janitors,
linux-arm-kernel, Mark Rutland, linux-kernel
In-Reply-To: <20211217145907.GA16611@kili>
On Fri, 17 Dec 2021 17:59:08 +0300, Dan Carpenter wrote:
> The devm_ioremap() function does not return error pointers. It returns
> NULL.
>
>
Applied to will (for-next/perf), thanks!
[1/1] drivers: perf: marvell_cn10k: fix an IS_ERR() vs NULL check
https://git.kernel.org/will/c/2da56881a7f8
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [RFC PATCH 0/2] Introduce new merge-tree-ort command
From: Elijah Newren @ 2022-01-05 17:32 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano, Christian Couder,
Ævar Arnfjörð Bjarmason, Taylor Blau,
Johannes Schindelin
In-Reply-To: <CABPp-BFh7UnQtPM=tO8rfp5bPK4-7esouv5KCx1sUSESwEA=Rw@mail.gmail.com>
On Wed, Jan 5, 2022 at 8:53 AM Elijah Newren <newren@gmail.com> wrote:
>
> On Wed, Jan 5, 2022 at 8:33 AM Christian Couder
> <christian.couder@gmail.com> wrote:
> >
> > During the 2nd Virtual Git Contributors’ Summit last October, and even
> > before, the subject of performing server side merges and rebases came
> > up, as platforms like GitHub and GitLab would like to support many
> > features and data formats that libgit2 doesn't support, like for
> > example SHA256 hashes and partial clone.
> >
...
> > The first patch in the series adds the new command without any test
> > and documentation.
> >
> > The second patch in the series adds a few tests that let us see how
> > the command's output looks like in different very simple cases.
> >
> > Of course if this approach is considered valuable, I plan to add some
> > documentation, more tests and very likely a number of options before
> > submitting the next iteration.
>
> Was there something you didn't like about
> https://lore.kernel.org/git/pull.1114.git.git.1640927044.gitgitgadget@gmail.com/?
Since I already had some fixes queued up for that series based on
feedback from Johannes Altmanninger and Fabian Stelzer, I decided to
submit those so you wouldn't have to stumble over the same problems.
So see https://lore.kernel.org/git/pull.1114.v2.git.git.1641403655.gitgitgadget@gmail.com/
instead (which also now has a pointer to this series in the cover
letter).
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.