* Re: [PATCH v7 12/17] ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
From: Jacob Keller @ 2016-11-08 23:54 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-13-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Use the recently introduced refname_atom_parser_internal() within
> remote_ref_atom_parser(), this provides a common base for all the ref
> printing atoms, allowing %(upstream) and %(push) to also use the
> ':strip' option.
>
> The atoms '%(push)' and '%(upstream)' will retain the ':track' and
> ':trackshort' atom modifiers to themselves as they have no meaning in
> context to the '%(refname)' and '%(symref)' atoms.
>
> Update the documentation and tests to reflect the same.
>
Nice. Good to have all this become common.
> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
> ---
> Documentation/git-for-each-ref.txt | 27 ++++++++++++++-------------
> ref-filter.c | 26 +++++++++++++++-----------
> t/t6300-for-each-ref.sh | 2 ++
> 3 files changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index a669a32..600b703 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -114,21 +114,22 @@ objectname::
>
> upstream::
> The name of a local ref which can be considered ``upstream''
> - from the displayed ref. Respects `:short` in the same way as
> - `refname` above. Additionally respects `:track` to show
> - "[ahead N, behind M]" and `:trackshort` to show the terse
> - version: ">" (ahead), "<" (behind), "<>" (ahead and behind),
> - or "=" (in sync). `:track` also prints "[gone]" whenever
> - unknown upstream ref is encountered. Append `:track,nobracket`
> - to show tracking information without brackets (i.e "ahead N,
> - behind M"). Has no effect if the ref does not have tracking
> - information associated with it.
> + from the displayed ref. Respects `:short` and `:strip` in the
> + same way as `refname` above. Additionally respects `:track`
> + to show "[ahead N, behind M]" and `:trackshort` to show the
> + terse version: ">" (ahead), "<" (behind), "<>" (ahead and
> + behind), or "=" (in sync). `:track` also prints "[gone]"
> + whenever unknown upstream ref is encountered. Append
> + `:track,nobracket` to show tracking information without
> + brackets (i.e "ahead N, behind M"). Has no effect if the ref
> + does not have tracking information associated with it.
>
> push::
> - The name of a local ref which represents the `@{push}` location
> - for the displayed ref. Respects `:short`, `:track`, and
> - `:trackshort` options as `upstream` does. Produces an empty
> - string if no `@{push}` ref is configured.
> + The name of a local ref which represents the `@{push}`
> + location for the displayed ref. Respects `:short`, `:strip`,
> + `:track`, and `:trackshort` options as `upstream`
> + does. Produces an empty string if no `@{push}` ref is
> + configured.
>
> HEAD::
> '*' if HEAD matches current ref (the checked out branch), ' '
> diff --git a/ref-filter.c b/ref-filter.c
> index f1d27b5..7d3d3a6 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -52,7 +52,8 @@ static struct used_atom {
> char color[COLOR_MAXLEN];
> struct align align;
> struct {
> - enum { RR_NORMAL, RR_SHORTEN, RR_TRACK, RR_TRACKSHORT } option;
> + enum { RR_REF, RR_TRACK, RR_TRACKSHORT } option;
> + struct refname_atom refname;
> unsigned int nobracket: 1;
> } remote_ref;
> struct {
> @@ -102,7 +103,9 @@ static void remote_ref_atom_parser(struct used_atom *atom, const char *arg)
> int i;
>
> if (!arg) {
> - atom->u.remote_ref.option = RR_NORMAL;
> + atom->u.remote_ref.option = RR_REF;
> + refname_atom_parser_internal(&atom->u.remote_ref.refname,
> + arg, atom->name);
> return;
> }
>
> @@ -112,16 +115,17 @@ static void remote_ref_atom_parser(struct used_atom *atom, const char *arg)
> for (i = 0; i < params.nr; i++) {
> const char *s = params.items[i].string;
>
> - if (!strcmp(s, "short"))
> - atom->u.remote_ref.option = RR_SHORTEN;
> - else if (!strcmp(s, "track"))
> + if (!strcmp(s, "track"))
> atom->u.remote_ref.option = RR_TRACK;
> else if (!strcmp(s, "trackshort"))
> atom->u.remote_ref.option = RR_TRACKSHORT;
> else if (!strcmp(s, "nobracket"))
> atom->u.remote_ref.nobracket = 1;
> - else
> - die(_("unrecognized format: %%(%s)"), atom->name);
> + else {
> + atom->u.remote_ref.option = RR_REF;
> + refname_atom_parser_internal(&atom->u.remote_ref.refname,
> + arg, atom->name);
> + }
> }
>
> string_list_clear(¶ms, 0);
> @@ -1100,8 +1104,8 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname,
> struct branch *branch, const char **s)
> {
> int num_ours, num_theirs;
> - if (atom->u.remote_ref.option == RR_SHORTEN)
> - *s = shorten_unambiguous_ref(refname, warn_ambiguous_refs);
> + if (atom->u.remote_ref.option == RR_REF)
> + *s = show_ref(&atom->u.remote_ref.refname, refname);
> else if (atom->u.remote_ref.option == RR_TRACK) {
> if (stat_tracking_info(branch, &num_ours,
> &num_theirs, NULL)) {
> @@ -1133,8 +1137,8 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname,
> *s = ">";
> else
> *s = "<>";
> - } else /* RR_NORMAL */
> - *s = refname;
> + } else
> + die("BUG: unhandled RR_* enum");
> }
>
> char *get_head_description(void)
> diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
> index 3d28234..7ca0a12 100755
> --- a/t/t6300-for-each-ref.sh
> +++ b/t/t6300-for-each-ref.sh
> @@ -55,8 +55,10 @@ test_atom head refname:strip=1 heads/master
> test_atom head refname:strip=2 master
> test_atom head upstream refs/remotes/origin/master
> test_atom head upstream:short origin/master
> +test_atom head upstream:strip=2 origin/master
> test_atom head push refs/remotes/myfork/master
> test_atom head push:short myfork/master
> +test_atom head push:strip=1 remotes/myfork/master
> test_atom head objecttype commit
> test_atom head objectsize 171
> test_atom head objectname $(git rev-parse refs/heads/master)
> --
> 2.10.2
>
^ permalink raw reply
* Re: [Qemu-devel] Sphinx for QEMU docs? (and a doc-comment format question)
From: Paolo Bonzini @ 2016-11-08 23:56 UTC (permalink / raw)
To: Stefan Hajnoczi, Peter Maydell; +Cc: QEMU Developers, Stefan Hajnoczi
In-Reply-To: <20161107133045.GM5036@stefanha-x1.localdomain>
On 07/11/2016 14:30, Stefan Hajnoczi wrote:
> On Sat, Nov 05, 2016 at 06:42:23PM +0000, Peter Maydell wrote:
>> In particular I think we could:
>> * set up a framework for our in-tree docs/ which gives us a
>> place to put new docs (both for-users and for-developers) --
>> I think having someplace to put things will reduce the barrier
>> to people writing useful new docs
>> * gradually convert the existing docs to rst
>> * use the sphinx extension features to pull in the doc-comments
>> we have been fairly consistently writing over the last few years
>> (for instance a converted version of docs/memory.txt could pull
>> in doc comments from memory.h; or we can just write simple
>> wrapper files like a "Bitmap operations" document that
>> displays the doc comments from bitops.h)
>
> You are suggesting Sphinx for two different purposes:
>
> 1. Formatting docs/ in HTML, PDF, etc.
>
> 2. API documentation from doc comments.
>
> It's a good idea for #1 since we can then publish automated builds of
> the docs. They will be easy to view and link to in a web browser.
>
> I'm not a fan of #2. QEMU is not a C library that people develop
> against and our APIs are not stable. There is no incentive for pretty
> doc comments. It might be cool to set it up once but things will
> deterioate again quickly because we don't actually need external API
> docs.
I don't think pretty doc comments matter, but accurate doc comments do.
If we cannot have accurate doc comments, we might not have them at all,
but this is actually not the case. There are some areas where we
actually go to great(er) lengths to have up-to-date documentation and
up-to-date doc comments, and it's a pity to only provide half of the
information in an easily consumable format.
It doesn't really have to be perfect, but it's a nice thing to have.
I'm not entirely sure that it's interesting to format bitops.h's doc
comments, but for memory.h or aio.h I'm pretty sure it's worth it.
Paolo
^ permalink raw reply
* [Bug 98513] [REGRESSION][4.9-rc3 w/ drm-next-4.10-wip][AMDGPU][CIK] Unable to suspend, hangs on hibernation
From: bugzilla-daemon @ 2016-11-08 23:57 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-98513-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 3112 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98513
--- Comment #2 from Shawn Starr <shawn.starr@rogers.com> ---
Bisected results confirmed:
[spstarr@segfault linux]$ git bisect bad
86f8c599b09c916f9aad30563271440dbd79213a is the first bad commit
commit 86f8c599b09c916f9aad30563271440dbd79213a
Author: Rex Zhu <Rex.Zhu@amd.com>
Date: Mon Oct 3 20:46:36 2016 +0800
drm/amdgpu: when suspend, set boot state instand of disable dpm.
fix pm-hibernate bug, when suspend/resume, dpm start failed.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
:040000 040000 5537c5937b203abdb5c48c5a0dc8dc5f6a3d00f2
7f048011c861d8c35b922fd94f089cd07d670f60 M drivers
[spstarr@segfault linux]$ git bisect log
git bisect start
# good: [1001354ca34179f3db924eb66672442a173147dc] Linux 4.9-rc1
git bisect good 1001354ca34179f3db924eb66672442a173147dc
# bad: [2f5945e707b5dffbf12444ad8bea079626ad30ec] drm/amdgpu: add the interface
of waiting multiple fences (v4)
git bisect bad 2f5945e707b5dffbf12444ad8bea079626ad30ec
# good: [61d0a04d6f5b2122f88aacbc4b1716e571961660] Merge tag
'topic/drm-misc-2016-10-24' of git://anongit.freedesktop.org/drm-intel into
drm-next
git bisect good 61d0a04d6f5b2122f88aacbc4b1716e571961660
# good: [e4ab73a13291fc844c9e24d5c347bd95818544d2] drm/i915: Respect
alternate_ddc_pin for all DDI ports
git bisect good e4ab73a13291fc844c9e24d5c347bd95818544d2
# bad: [415282b15e15c2d7fb18e29c5b554cc7f4ff5c52] drm/amdgpu: disable dpm
before turn off clock when vce idle.
git bisect bad 415282b15e15c2d7fb18e29c5b554cc7f4ff5c52
# good: [392f0c775c80de0eae4c07227cc220015df70abc] drm/amdgpu/gfx8: cache rb
config values
git bisect good 392f0c775c80de0eae4c07227cc220015df70abc
# good: [472259f02657ef99cba2a64832ccadad8e3baabe] drm/amd/amdgpu: re-factor
debugfs wave reader
git bisect good 472259f02657ef99cba2a64832ccadad8e3baabe
# good: [f1e68a7cf582b41d6da1dd15b9f0bfb9057c1164] drm/amdgpu/atom: remove a
bunch of unused functions
git bisect good f1e68a7cf582b41d6da1dd15b9f0bfb9057c1164
# good: [585ffd65441a4aea7e762d17f7a248d07cd1c9ac] drm/ttm: fix coding style in
ttm_bo_driver.h
git bisect good 585ffd65441a4aea7e762d17f7a248d07cd1c9ac
# good: [8ed8147abc7cf1f689245deb316aabfe2f657ade] drm/amdgpu: use failed label
to handle context init failure
git bisect good 8ed8147abc7cf1f689245deb316aabfe2f657ade
# bad: [3f767e3d076dd2a24a614917c8f0b05d8d82b90b] drm/amdgpu: just not load smc
firmware if smu is already running
git bisect bad 3f767e3d076dd2a24a614917c8f0b05d8d82b90b
# bad: [86f8c599b09c916f9aad30563271440dbd79213a] drm/amdgpu: when suspend, set
boot state instand of disable dpm.
git bisect bad 86f8c599b09c916f9aad30563271440dbd79213a
# first bad commit: [86f8c599b09c916f9aad30563271440dbd79213a] drm/amdgpu: when
suspend, set boot state instand of disable dpm.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 4279 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [REGRESSION][drm-next-4.10-wip] commit 86f8c599b09c916f9aad30563271440dbd79213a breaks hibernation on AMDGPU CIK
From: Shawn Starr @ 2016-11-08 23:58 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Hello,
I've bisected kernel and have found the regression that deadlocks GPU on hibernation.
Bug https://bugs.freedesktop.org/show_bug.cgi?id=98513
[spstarr@segfault linux]$ git bisect bad
86f8c599b09c916f9aad30563271440dbd79213a is the first bad commit
commit 86f8c599b09c916f9aad30563271440dbd79213a
Author: Rex Zhu <Rex.Zhu@amd.com>
Date: Mon Oct 3 20:46:36 2016 +0800
drm/amdgpu: when suspend, set boot state instand of disable dpm.
fix pm-hibernate bug, when suspend/resume, dpm start failed.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
:040000 040000 5537c5937b203abdb5c48c5a0dc8dc5f6a3d00f2 7f048011c861d8c35b922fd94f089cd07d670f60 M drivers
[spstarr@segfault linux]$ git bisect log
git bisect start
# good: [1001354ca34179f3db924eb66672442a173147dc] Linux 4.9-rc1
git bisect good 1001354ca34179f3db924eb66672442a173147dc
# bad: [2f5945e707b5dffbf12444ad8bea079626ad30ec] drm/amdgpu: add the interface of waiting multiple fences (v4)
git bisect bad 2f5945e707b5dffbf12444ad8bea079626ad30ec
# good: [61d0a04d6f5b2122f88aacbc4b1716e571961660] Merge tag 'topic/drm-misc-2016-10-24' of git://anongit.freedesktop.org/drm-intel into drm-next
git bisect good 61d0a04d6f5b2122f88aacbc4b1716e571961660
# good: [e4ab73a13291fc844c9e24d5c347bd95818544d2] drm/i915: Respect alternate_ddc_pin for all DDI ports
git bisect good e4ab73a13291fc844c9e24d5c347bd95818544d2
# bad: [415282b15e15c2d7fb18e29c5b554cc7f4ff5c52] drm/amdgpu: disable dpm before turn off clock when vce idle.
git bisect bad 415282b15e15c2d7fb18e29c5b554cc7f4ff5c52
# good: [392f0c775c80de0eae4c07227cc220015df70abc] drm/amdgpu/gfx8: cache rb config values
git bisect good 392f0c775c80de0eae4c07227cc220015df70abc
# good: [472259f02657ef99cba2a64832ccadad8e3baabe] drm/amd/amdgpu: re-factor debugfs wave reader
git bisect good 472259f02657ef99cba2a64832ccadad8e3baabe
# good: [f1e68a7cf582b41d6da1dd15b9f0bfb9057c1164] drm/amdgpu/atom: remove a bunch of unused functions
git bisect good f1e68a7cf582b41d6da1dd15b9f0bfb9057c1164
# good: [585ffd65441a4aea7e762d17f7a248d07cd1c9ac] drm/ttm: fix coding style in ttm_bo_driver.h
git bisect good 585ffd65441a4aea7e762d17f7a248d07cd1c9ac
# good: [8ed8147abc7cf1f689245deb316aabfe2f657ade] drm/amdgpu: use failed label to handle context init failure
git bisect good 8ed8147abc7cf1f689245deb316aabfe2f657ade
# bad: [3f767e3d076dd2a24a614917c8f0b05d8d82b90b] drm/amdgpu: just not load smc firmware if smu is already running
git bisect bad 3f767e3d076dd2a24a614917c8f0b05d8d82b90b
# bad: [86f8c599b09c916f9aad30563271440dbd79213a] drm/amdgpu: when suspend, set boot state instand of disable dpm.
git bisect bad 86f8c599b09c916f9aad30563271440dbd79213a
# first bad commit: [86f8c599b09c916f9aad30563271440dbd79213a] drm/amdgpu: when suspend, set boot state instand of disable dpm.
Thanks,
Shawn
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v7 13/17] ref-filter: add `:dir` and `:base` options for ref printing atoms
From: Jacob Keller @ 2016-11-08 23:58 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-14-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Add the options `:dir` and `:base` to all ref printing ('%(refname)',
> '%(symref)', '%(push)' and '%(upstream)') atoms. The `:dir` option gives
> the directory (the part after $GIT_DIR/) of the ref without the
> refname. The `:base` option gives the base directory of the given
> ref (i.e. the directory following $GIT_DIR/refs/).
>
Nice, this seems useful.
> Add tests and documentation for the same.
>
> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com>
> ---
> Documentation/git-for-each-ref.txt | 34 +++++++++++++++++++---------------
> ref-filter.c | 29 +++++++++++++++++++++++++----
> t/t6300-for-each-ref.sh | 24 ++++++++++++++++++++++++
> 3 files changed, 68 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index 600b703..f4ad297 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -96,7 +96,9 @@ refname::
> slash-separated path components from the front of the refname
> (e.g., `%(refname:strip=2)` turns `refs/tags/foo` into `foo`.
> `<N>` must be a positive integer. If a displayed ref has fewer
> - components than `<N>`, the command aborts with an error.
> + components than `<N>`, the command aborts with an error. For the base
> + directory of the ref (i.e. foo in refs/foo/bar/boz) append
> + `:base`. For the entire directory path append `:dir`.
>
> objecttype::
> The type of the object (`blob`, `tree`, `commit`, `tag`).
> @@ -114,22 +116,23 @@ objectname::
>
> upstream::
> The name of a local ref which can be considered ``upstream''
> - from the displayed ref. Respects `:short` and `:strip` in the
> - same way as `refname` above. Additionally respects `:track`
> - to show "[ahead N, behind M]" and `:trackshort` to show the
> - terse version: ">" (ahead), "<" (behind), "<>" (ahead and
> - behind), or "=" (in sync). `:track` also prints "[gone]"
> - whenever unknown upstream ref is encountered. Append
> - `:track,nobracket` to show tracking information without
> - brackets (i.e "ahead N, behind M"). Has no effect if the ref
> - does not have tracking information associated with it.
> + from the displayed ref. Respects `:short`, `:strip`, `:base`
> + and `:dir` in the same way as `refname` above. Additionally
> + respects `:track` to show "[ahead N, behind M]" and
> + `:trackshort` to show the terse version: ">" (ahead), "<"
> + (behind), "<>" (ahead and behind), or "=" (in sync). `:track`
> + also prints "[gone]" whenever unknown upstream ref is
> + encountered. Append `:track,nobracket` to show tracking
> + information without brackets (i.e "ahead N, behind M"). Has
> + no effect if the ref does not have tracking information
> + associated with it.
>
> push::
> The name of a local ref which represents the `@{push}`
> location for the displayed ref. Respects `:short`, `:strip`,
> - `:track`, and `:trackshort` options as `upstream`
> - does. Produces an empty string if no `@{push}` ref is
> - configured.
> + `:track`, `:trackshort`, `:base` and `:dir` options as
> + `upstream` does. Produces an empty string if no `@{push}` ref
> + is configured.
>
At this point would it make more sense to document the extra values
here in one block separately? For example, the upstream atom is
getting pretty complex with all those options. Additionally, some of
the options can be combined, like nobracket, but others cannot be
comined so It may be worth documenting how and when those combinations
work?
> HEAD::
> '*' if HEAD matches current ref (the checked out branch), ' '
> @@ -169,8 +172,9 @@ if::
>
> symref::
> The ref which the given symbolic ref refers to. If not a
> - symbolic ref, nothing is printed. Respects the `:short` and
> - `:strip` options in the same way as `refname` above.
> + symbolic ref, nothing is printed. Respects the `:short`,
> + `:strip`, `:base` and `:dir` options in the same way as
> + `refname` above.
>
> In addition to the above, for commit and tag objects, the header
> field names (`tree`, `parent`, `object`, `type`, and `tag`) can
> diff --git a/ref-filter.c b/ref-filter.c
> index 7d3d3a6..b47b900 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -31,7 +31,7 @@ struct if_then_else {
> };
>
> struct refname_atom {
> - enum { R_NORMAL, R_SHORT, R_STRIP } option;
> + enum { R_BASE, R_DIR, R_NORMAL, R_SHORT, R_STRIP } option;
> unsigned int strip;
> };
>
> @@ -93,7 +93,11 @@ static void refname_atom_parser_internal(struct refname_atom *atom,
> atom->option = R_STRIP;
> if (strtoul_ui(arg, 10, &atom->strip) || atom->strip <= 0)
> die(_("positive value expected refname:strip=%s"), arg);
> - } else
> + } else if (!strcmp(arg, "dir"))
> + atom->option = R_DIR;
> + else if (!strcmp(arg, "base"))
> + atom->option = R_BASE;
> + else
> die(_("unrecognized %%(%s) argument: %s"), name, arg);
> }
>
> @@ -252,7 +256,6 @@ static void if_atom_parser(struct used_atom *atom, const char *arg)
> die(_("unrecognized %%(if) argument: %s"), arg);
> }
>
> -
> static struct {
> const char *name;
> cmp_type cmp_type;
> @@ -1096,7 +1099,25 @@ static const char *show_ref(struct refname_atom *atom, const char *refname)
> return shorten_unambiguous_ref(refname, warn_ambiguous_refs);
> else if (atom->option == R_STRIP)
> return strip_ref_components(refname, atom->strip);
> - else
> + else if (atom->option == R_BASE) {
> + const char *sp, *ep;
> +
> + if (skip_prefix(refname, "refs/", &sp)) {
> + ep = strchr(sp, '/');
> + if (!ep)
> + return "";
> + return xstrndup(sp, ep - sp);
> + }
> + return "";
> + } else if (atom->option == R_DIR) {
> + const char *sp, *ep;
> +
> + sp = refname;
> + ep = strrchr(sp, '/');
> + if (!ep)
> + return "";
> + return xstrndup(sp, ep - sp);
> + } else
> return refname;
> }
>
> diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
> index 7ca0a12..8ff6568 100755
> --- a/t/t6300-for-each-ref.sh
> +++ b/t/t6300-for-each-ref.sh
> @@ -53,12 +53,18 @@ test_atom head refname refs/heads/master
> test_atom head refname:short master
> test_atom head refname:strip=1 heads/master
> test_atom head refname:strip=2 master
> +test_atom head refname:dir refs/heads
> +test_atom head refname:base heads
> test_atom head upstream refs/remotes/origin/master
> test_atom head upstream:short origin/master
> test_atom head upstream:strip=2 origin/master
> +test_atom head upstream:dir refs/remotes/origin
> +test_atom head upstream:base remotes
> test_atom head push refs/remotes/myfork/master
> test_atom head push:short myfork/master
> test_atom head push:strip=1 remotes/myfork/master
> +test_atom head push:dir refs/remotes/myfork
> +test_atom head push:base remotes
> test_atom head objecttype commit
> test_atom head objectsize 171
> test_atom head objectname $(git rev-parse refs/heads/master)
> @@ -600,4 +606,22 @@ test_expect_success 'Verify usage of %(symref:strip) atom' '
> test_cmp expected actual
> '
>
> +cat >expected <<EOF
> +refs/heads
> +EOF
> +
> +test_expect_success 'Verify usage of %(symref:dir) atom' '
> + git for-each-ref --format="%(symref:dir)" refs/heads/sym > actual &&
> + test_cmp expected actual
> +'
> +
> +cat >expected <<EOF
> +heads
> +EOF
> +
> +test_expect_success 'Verify usage of %(symref:base) atom' '
> + git for-each-ref --format="%(symref:base)" refs/heads/sym > actual &&
> + test_cmp expected actual
> +'
> +
> test_done
> --
> 2.10.2
>
^ permalink raw reply
* [Bug 98513] [REGRESSION][drm-next-4.10-wip][AMDGPU][CIK] Unable to suspend, hangs on hibernation bad commit 86f8c599b09c916f9aad30563271440dbd79213a
From: bugzilla-daemon @ 2016-11-08 23:58 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-98513-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 754 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98513
Shawn Starr <shawn.starr@rogers.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[REGRESSION][4.9-rc3 w/ |[REGRESSION][drm-next-4.10-
|drm-next-4.10-wip][AMDGPU][ |wip][AMDGPU][CIK] Unable to
|CIK] Unable to suspend, |suspend, hangs on
|hangs on hibernation |hibernation bad commit
| |86f8c599b09c916f9aad3056327
| |1440dbd79213a
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1371 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] checkpatch: fix uninitialized var when run with --no-tree
From: Brian Norris @ 2016-11-09 0:00 UTC (permalink / raw)
To: Andrew Morton
Cc: Andy Whitcroft, Joe Perches, linux-kernel, Linus Torvalds,
SF Markus Elfring, Jerome Forissier
In-Reply-To: <20161108151040.4283451c39240dd32bdd61dc@linux-foundation.org>
On Tue, Nov 08, 2016 at 03:10:40PM -0800, Andrew Morton wrote:
> I already have the below. Good enough?
Sure, good enough. Though it does have the same tiny awkwardness as my
v1.
> From: Jerome Forissier <jerome.forissier@linaro.org>
> Subject: checkpatch: don't try to get maintained status when --no-tree is given
>
> Fixes the following warning:
> Use of uninitialized value $root in concatenation (.) or string at /path/to/checkpatch.pl line 764.
>
> Link: http://lkml.kernel.org/r/1476719709-16668-1-git-send-email-jerome.forissier@linaro.org
> Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
> Acked-by: Joe Perches <joe@perches.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> scripts/checkpatch.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -puN scripts/checkpatch.pl~checkpatch-dont-try-to-get-maintained-status-when-no-tree-is-given scripts/checkpatch.pl
> --- a/scripts/checkpatch.pl~checkpatch-dont-try-to-get-maintained-status-when-no-tree-is-given
> +++ a/scripts/checkpatch.pl
> @@ -761,7 +761,7 @@ sub seed_camelcase_file {
> sub is_maintained_obsolete {
> my ($filename) = @_;
>
> - return 0 if (!(-e "$root/scripts/get_maintainer.pl"));
> + return 0 if (!$tree || !(-e "$root/scripts/get_maintainer.pl"));
>
> my $status = `perl $root/scripts/get_maintainer.pl --status --nom --nol --nogit --nogit-fallback -f $filename 2>&1`;
>
> _
>
FWIW:
Reviewed-by: Brian Norris <computersforpeace@gmail.com>
^ permalink raw reply
* Re: [PATCH v7 14/17] ref-filter: allow porcelain to translate messages in the output
From: Jacob Keller @ 2016-11-09 0:00 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-15-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Introduce setup_ref_filter_porcelain_msg() so that the messages used in
> the atom %(upstream:track) can be translated if needed. This is needed
> as we port branch.c to use ref-filter's printing API's.
>
So any user that wants these translated calls
setup_ref_filter_porcelain_msg but this will impact all callers from
that point on. Ok, I think that's ok? Otherwise they get default
without translation.
> Written-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
> Mentored-by: Christian Couder <christian.couder@gmail.com>
> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
> ref-filter.c | 28 ++++++++++++++++++++++++----
> ref-filter.h | 2 ++
> 2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index b47b900..944671a 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -15,6 +15,26 @@
> #include "version.h"
> #include "wt-status.h"
>
> +static struct ref_msg {
> + const char *gone;
> + const char *ahead;
> + const char *behind;
> + const char *ahead_behind;
> +} msgs = {
> + "gone",
> + "ahead %d",
> + "behind %d",
> + "ahead %d, behind %d"
> +};
> +
> +void setup_ref_filter_porcelain_msg(void)
> +{
> + msgs.gone = _("gone");
> + msgs.ahead = _("ahead %d");
> + msgs.behind = _("behind %d");
> + msgs.ahead_behind = _("ahead %d, behind %d");
> +}
> +
> typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
>
> struct align {
> @@ -1130,15 +1150,15 @@ static void fill_remote_ref_details(struct used_atom *atom, const char *refname,
> else if (atom->u.remote_ref.option == RR_TRACK) {
> if (stat_tracking_info(branch, &num_ours,
> &num_theirs, NULL)) {
> - *s = xstrdup("gone");
> + *s = xstrdup(msgs.gone);
> } else if (!num_ours && !num_theirs)
> *s = "";
> else if (!num_ours)
> - *s = xstrfmt("behind %d", num_theirs);
> + *s = xstrfmt(msgs.behind, num_theirs);
> else if (!num_theirs)
> - *s = xstrfmt("ahead %d", num_ours);
> + *s = xstrfmt(msgs.ahead, num_ours);
> else
> - *s = xstrfmt("ahead %d, behind %d",
> + *s = xstrfmt(msgs.ahead_behind,
> num_ours, num_theirs);
> if (!atom->u.remote_ref.nobracket && *s[0]) {
> const char *to_free = *s;
> diff --git a/ref-filter.h b/ref-filter.h
> index 0014b92..da17145 100644
> --- a/ref-filter.h
> +++ b/ref-filter.h
> @@ -111,5 +111,7 @@ struct ref_sorting *ref_default_sorting(void);
> int parse_opt_merge_filter(const struct option *opt, const char *arg, int unset);
> /* Get the current HEAD's description */
> char *get_head_description(void);
> +/* Set up translated strings in the output. */
> +void setup_ref_filter_porcelain_msg(void);
>
> #endif /* REF_FILTER_H */
> --
> 2.10.2
>
^ permalink raw reply
* Re: [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
From: Arun Easi @ 2016-11-09 0:00 UTC (permalink / raw)
To: Martin K. Petersen
Cc: kbuild test robot, Manish Rangankar, kbuild-all, James Bottomley,
lduncan, cleech, linux-scsi, netdev, QLogic-Storage-Upstream,
Yuval Mintz
In-Reply-To: <yq137j1r0q3.fsf@sermon.lab.mkp.net>
Martin,
On Tue, 8 Nov 2016, 3:49pm -0000, Martin K. Petersen wrote:
> >>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
>
> Arun,
>
> Arun> qedi is the new iSCSI driver, which we are trying to submit, for
> Arun> our 41000 series CNA. This patch series were broken up into
> Arun> logical blocks for review purpose, but were not made to compile
> Arun> individually. It is our impression that this is acceptable for
> Arun> SCSI and all the initial "qedi" patches will be squashed and
> Arun> committed as a single commit. Please let us know if we are
> Arun> mistaken, and if so, we will post another series with this taken
> Arun> care of.
>
> It's fine to post the patches split up to ease the review process. But
> whatever we commit must obviously be bisectable.
>
If it is alright with you, we would like to have all of our initial
patches for the driver (qedi) squashed as a single commit to the tree. We
will ensure that this single combined commit compiles clean.
Regards,
-Arun
^ permalink raw reply
* Re: [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
From: Arun Easi @ 2016-11-09 0:00 UTC (permalink / raw)
To: Martin K. Petersen
Cc: kbuild test robot, Manish Rangankar, kbuild-all, James Bottomley,
lduncan, cleech, linux-scsi, netdev, QLogic-Storage-Upstream,
Yuval Mintz
In-Reply-To: <yq137j1r0q3.fsf@sermon.lab.mkp.net>
Martin,
On Tue, 8 Nov 2016, 3:49pm -0000, Martin K. Petersen wrote:
> >>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
>
> Arun,
>
> Arun> qedi is the new iSCSI driver, which we are trying to submit, for
> Arun> our 41000 series CNA. This patch series were broken up into
> Arun> logical blocks for review purpose, but were not made to compile
> Arun> individually. It is our impression that this is acceptable for
> Arun> SCSI and all the initial "qedi" patches will be squashed and
> Arun> committed as a single commit. Please let us know if we are
> Arun> mistaken, and if so, we will post another series with this taken
> Arun> care of.
>
> It's fine to post the patches split up to ease the review process. But
> whatever we commit must obviously be bisectable.
>
If it is alright with you, we would like to have all of our initial
patches for the driver (qedi) squashed as a single commit to the tree. We
will ensure that this single combined commit compiles clean.
Regards,
-Arun
^ permalink raw reply
* Re: [PATCH v15 1/4] clk: mediatek: Add MT2701 clock support
From: Stephen Boyd @ 2016-11-09 0:01 UTC (permalink / raw)
To: Erin Lo
Cc: Matthias Brugger, Mike Turquette, Rob Herring, Arnd Bergmann,
Sascha Hauer, Daniel Kurtz, Philipp Zabel, devicetree,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-clk,
srv_heupstream, ms.chen, robert.chou, Shunli Wang, James Liao
In-Reply-To: <1478245388-1412-2-git-send-email-erin.lo@mediatek.com>
On 11/04, Erin Lo wrote:
> From: Shunli Wang <shunli.wang@mediatek.com>
>
> Add MT2701 clock support, include topckgen, apmixedsys,
> infracfg, pericfg and subsystem clocks.
>
> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> Tested-by: John Crispin <blogic@openwrt.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v15 1/4] clk: mediatek: Add MT2701 clock support
From: Stephen Boyd @ 2016-11-09 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478245388-1412-2-git-send-email-erin.lo@mediatek.com>
On 11/04, Erin Lo wrote:
> From: Shunli Wang <shunli.wang@mediatek.com>
>
> Add MT2701 clock support, include topckgen, apmixedsys,
> infracfg, pericfg and subsystem clocks.
>
> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> Tested-by: John Crispin <blogic@openwrt.org>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v15 2/4] reset: mediatek: Add MT2701 reset driver
From: Stephen Boyd @ 2016-11-09 0:01 UTC (permalink / raw)
To: Erin Lo
Cc: Matthias Brugger, Mike Turquette, Rob Herring, Arnd Bergmann,
Sascha Hauer, Daniel Kurtz, Philipp Zabel, devicetree,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-clk,
srv_heupstream, ms.chen, robert.chou, Shunli Wang, James Liao
In-Reply-To: <1478245388-1412-3-git-send-email-erin.lo@mediatek.com>
On 11/04, Erin Lo wrote:
> From: Shunli Wang <shunli.wang@mediatek.com>
>
> In infrasys and perifsys, there are many reset
> control bits for kinds of modules. These bits are
> used as actual reset controllers to be registered
> into kernel's generic reset controller framework.
>
> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> Tested-by: John Crispin <blogic@openwrt.org>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v15 2/4] reset: mediatek: Add MT2701 reset driver
From: Stephen Boyd @ 2016-11-09 0:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478245388-1412-3-git-send-email-erin.lo@mediatek.com>
On 11/04, Erin Lo wrote:
> From: Shunli Wang <shunli.wang@mediatek.com>
>
> In infrasys and perifsys, there are many reset
> control bits for kinds of modules. These bits are
> used as actual reset controllers to be registered
> into kernel's generic reset controller framework.
>
> Signed-off-by: Shunli Wang <shunli.wang@mediatek.com>
> Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
> Signed-off-by: Erin Lo <erin.lo@mediatek.com>
> Tested-by: John Crispin <blogic@openwrt.org>
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v7 15/17] branch, tag: use porcelain output
From: Jacob Keller @ 2016-11-09 0:01 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-16-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> From: Karthik Nayak <karthik.188@gmail.com>
>
> Call ref-filter's setup_ref_filter_porcelain_msg() to enable
> translated messages for the %(upstream:tack) atom. Although branch.c
> doesn't currently use ref-filter's printing API's, this will ensure
> that when it does in the future patches, we do not need to worry about
> translation.
>
Makes sense.
Thanks,
Jake
> Written-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
> Mentored-by: Christian Couder <christian.couder@gmail.com>
> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
> Signed-off-by: Karthik Nayak <karthik.188@gmail.com>
> ---
> builtin/branch.c | 2 ++
> builtin/tag.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index be9773a..dead2b8 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -656,6 +656,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
> OPT_END(),
> };
>
> + setup_ref_filter_porcelain_msg();
> +
> memset(&filter, 0, sizeof(filter));
> filter.kind = FILTER_REFS_BRANCHES;
> filter.abbrev = -1;
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 50e4ae5..a00e9a7 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -373,6 +373,8 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
> OPT_END()
> };
>
> + setup_ref_filter_porcelain_msg();
> +
> git_config(git_tag_config, sorting_tail);
>
> memset(&opt, 0, sizeof(opt));
> --
> 2.10.2
>
^ permalink raw reply
* Re: [ANNOUNCE] xfs: for-next branch updated to 84716639acc3
From: Darrick J. Wong @ 2016-11-09 0:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-xfs, linux-fsdevel, jack, tytso, ross.zwisler
In-Reply-To: <20161108231639.GC28922@dastard>
On Wed, Nov 09, 2016 at 10:16:39AM +1100, Dave Chinner wrote:
> Hi folks,
>
> The for-next branch of the xfs kernel repository at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
>
> has just been updated.
>
> This update includes the DAX iomap PMD fault infrastructure, a bunch
> of libxfs cleanups that sync the kernel code with changes that
> have been made in the userspace libxfs and a few bug fixes thrown in
> there for good measure.
/me notices the commit message for 132f2ac5055a96 ("xfs: check minimum block
size for CRC filesystems") says that you cleaned up the XFS_MIN_CRC_BLOCKSIZE
check, but the patch appears identical to the one that I sent. I think all
you changed was removing the unlikely()...?
(<shrug> I doubt it's a big deal either way really...)
--D
>
> Jan, Ted and Ross:
>
> I have pushed the DAX changes into a stable topic branch named
> "dax-4.10-iomap-pmd". Any fixes to this code will be appended to
> this branch - the commits are now stable so that it can be pulled
> into other trees for further development of DAX features for this
> cycle.
>
> The dax-4.10-iomap-pmd branch will also reach linux-next via the
> merge into the for-next branch. However, keep in mind that the
> for-next in the XFS tree is not a stable branch - it may get
> rebased from time to time as stable topic branches have commits
> appended - so treat the for-next branch like you treat linux-next.
>
> -Dave.
>
> The new head of the for-next branch is commit:
>
> 84716639acc3 Merge branch 'xfs-4.10-misc-fixes-1' into for-next
>
> New Commits:
>
> Brian Foster (2):
> [399372349a7f] xfs: don't skip cow forks w/ delalloc blocks in cowblocks scan
> [04197b341f23] xfs: don't BUG() on mixed direct and mapped I/O
>
> Darrick J. Wong (8):
> [755c7bf5ddca] libxfs: convert ushort to unsigned short
> [420fbeb4bff4] libxfs: synchronize dinode_verify with userspace
> [68c098582b20] libxfs: fix whitespace problems
> [ae90b994b40f] libxfs: fix xfs_attr_shortform_bytesfit declaration
> [523b2e76e3ec] libxfs: clean up _dir2_data_freescan
> [5e52365ac863] xfs: move dir_ino_validate declaration per xfsprogs
> [4fd29ec47212] xfs: check return value of _trans_reserve_quota_nblks
> [132f2ac5055a] xfs: check minimum block size for CRC filesystems
>
> Dave Chinner (3):
> [e823656675ac] Merge branch 'dax-4.10-iomap-pmd' into for-next
> [baa5baeb87de] Merge branch 'xfs-4.10-libxfs-cleanups' into for-next
> [84716639acc3] Merge branch 'xfs-4.10-misc-fixes-1' into for-next
>
> Eric Sandeen (3):
> [e6fc6fcf4447] xfs: don't call xfs_sb_quota_from_disk twice
> [4dfce57db635] xfs: fix up xfs_swap_extent_forks inline extent handling
> [5d829300bee0] xfs: provide helper for counting extents from if_bytes
>
> Ross Zwisler (16):
> [547edce3ba23] ext4: tell DAX the size of allocation holes
> [fa0d3fce7cef] dax: remove buffer_size_valid()
> [03e0990fc88f] ext2: remove support for DAX PMD faults
> [ce95ab0fa669] dax: make 'wait_table' global variable static
> [aada54f98004] dax: remove the last BUG_ON() from fs/dax.c
> [e3ad61c64abc] dax: consistent variable naming for DAX entries
> [63e95b5c4f16] dax: coordinate locking for offsets in PMD range
> [b9fde0462e34] dax: remove dax_pmd_fault()
> [11c59c92f44d] dax: correct dax iomap code namespace
> [333ccc978e1e] dax: add dax_iomap_sector() helper function
> [1550290b0801] dax: dax_iomap_fault() needs to call iomap_end()
> [fa28f7296a7c] dax: move RADIX_DAX_* defines to dax.h
> [422476c4641e] dax: move put_(un)locked_mapping_entry() in dax.c
> [642261ac995e] dax: add struct iomap based DAX PMD support
> [862f1b9d6718] xfs: use struct iomap based DAX PMD fault path
> [190b5caad750] dax: remove "depends on BROKEN" from FS_DAX_PMD
>
>
> Code Diffstat:
>
> fs/Kconfig | 1 -
> fs/dax.c | 826 ++++++++++++++++++++++++-------------------
> fs/ext2/file.c | 35 +-
> fs/ext4/inode.c | 3 +
> fs/xfs/libxfs/xfs_attr_leaf.h | 2 +-
> fs/xfs/libxfs/xfs_bmap.c | 54 +--
> fs/xfs/libxfs/xfs_dir2.h | 5 +
> fs/xfs/libxfs/xfs_dir2_data.c | 24 +-
> fs/xfs/libxfs/xfs_dir2_priv.h | 1 -
> fs/xfs/libxfs/xfs_ialloc.c | 5 +-
> fs/xfs/libxfs/xfs_inode_buf.c | 6 +-
> fs/xfs/libxfs/xfs_inode_buf.h | 4 +-
> fs/xfs/libxfs/xfs_inode_fork.c | 31 +-
> fs/xfs/libxfs/xfs_inode_fork.h | 1 +
> fs/xfs/libxfs/xfs_log_format.h | 4 +-
> fs/xfs/libxfs/xfs_log_recover.h | 2 +-
> fs/xfs/libxfs/xfs_rtbitmap.c | 1 -
> fs/xfs/libxfs/xfs_sb.c | 14 +-
> fs/xfs/libxfs/xfs_types.h | 3 +
> fs/xfs/xfs_aops.c | 48 +--
> fs/xfs/xfs_aops.h | 3 -
> fs/xfs/xfs_bmap_util.c | 33 +-
> fs/xfs/xfs_file.c | 10 +-
> fs/xfs/xfs_icache.c | 7 +-
> fs/xfs/xfs_inode_item.c | 4 +-
> fs/xfs/xfs_ioctl.c | 6 +-
> fs/xfs/xfs_log_recover.c | 4 +-
> fs/xfs/xfs_qm.c | 2 +-
> fs/xfs/xfs_reflink.c | 38 +-
> fs/xfs/xfs_reflink.h | 2 -
> include/linux/dax.h | 58 ++-
> mm/filemap.c | 5 +-
> 32 files changed, 683 insertions(+), 559 deletions(-)
> --
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups
From: Alexei Starovoitov @ 2016-11-09 0:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: John Stultz, Mickaël Salaün, Daniel Mack,
David S. Miller, kafai, fw, Harald Hoyer, Network Development,
Sargun Dhillon, Pablo Neira Ayuso, lkml, Tejun Heo, Li Zefan,
Jonathan Corbet, open list:CONTROL GROUP (CGROUP),
Android Kernel Team, Rom Lemarchand, Colin Cross, Dmitry Shmidt,
Todd Kjos
In-Reply-To: <CALCETrU5fCWoe0RXfKWuN7Zt9vLvoyHFcZnVqeqiKBpSKrMrxA@mail.gmail.com>
On Tue, Nov 08, 2016 at 03:51:40PM -0800, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 3:28 PM, John Stultz <john.stultz@linaro.org> wrote:
> > This patch adds logic to allows a process to migrate other tasks
> > between cgroups if they have CAP_SYS_RESOURCE.
> >
> > In Android (where this feature originated), the ActivityManager tracks
> > various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM,
> > etc), and then as applications change states, the SchedPolicy logic
> > will migrate the application tasks between different cgroups used
> > to control the different application states (for example, there is a
> > background cpuset cgroup which can limit background tasks to stay
> > on one low-power cpu, and the bg_non_interactive cpuctrl cgroup can
> > then further limit those background tasks to a small percentage of
> > that one cpu's cpu time).
> >
> > However, for security reasons, Android doesn't want to make the
> > system_server (the process that runs the ActivityManager and
> > SchedPolicy logic), run as root. So in the Android common.git
> > kernel, they have some logic to allow cgroups to loosen their
> > permissions so CAP_SYS_NICE tasks can migrate other tasks between
> > cgroups.
> >
> > I feel the approach taken there overloads CAP_SYS_NICE a bit much
> > for non-android environments.
> >
> > So this patch, as suggested by Michael Kerrisk, simply adds a
> > check for CAP_SYS_RESOURCE.
> >
> > I've tested this with AOSP master, and this seems to work well
> > as Zygote and system_server already use CAP_SYS_RESOURCE. I've
> > also submitted patches against the android-4.4 kernel to change
> > it to use CAP_SYS_RESOURCE, and the Android developers just merged
> > it.
> >
>
> I hate to say it, but I think I may see a problem. Current
> developments are afoot to make cgroups do more than resource control.
> For example, there's Landlock and there's Daniel's ingress/egress
> filter thing. Current cgroup controllers can mostly just DoS their
> controlled processes. These new controllers (or controller-like
> things) can exfiltrate data and change semantics.
>
> Does anyone have a security model in mind for these controllers and
> the cgroups that they're attached to? I'm reasonably confident that
> CAP_SYS_RESOURCE is not the answer...
and specifically the answer is... ?
Also would be great if you start with specifying the question first
and the problem you're trying to solve.
^ permalink raw reply
* Re: [PATCH] drivers: tca8418: Change the interrupt type
From: Dmitry Torokhov @ 2016-11-09 0:04 UTC (permalink / raw)
To: Maxime Ripard; +Cc: linux-input, linux-kernel
In-Reply-To: <20161107144024.15291-1-maxime.ripard@free-electrons.com>
On Mon, Nov 07, 2016 at 03:40:24PM +0100, Maxime Ripard wrote:
> The TCA8418 interrupt has a level trigger, not a edge one.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Hmm, maybe we could rely on OF data for trigger type?
> ---
> drivers/input/keyboard/tca8418_keypad.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/tca8418_keypad.c b/drivers/input/keyboard/tca8418_keypad.c
> index 9002298698fc..b88b3696a2e1 100644
> --- a/drivers/input/keyboard/tca8418_keypad.c
> +++ b/drivers/input/keyboard/tca8418_keypad.c
> @@ -360,7 +360,7 @@ static int tca8418_keypad_probe(struct i2c_client *client,
> irq = gpio_to_irq(irq);
>
> error = devm_request_threaded_irq(dev, irq, NULL, tca8418_irq_handler,
> - IRQF_TRIGGER_FALLING |
> + IRQF_TRIGGER_LOW |
> IRQF_SHARED |
> IRQF_ONESHOT,
> client->name, keypad_data);
> --
> 2.10.1
>
--
Dmitry
^ permalink raw reply
* Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups
From: Alexei Starovoitov @ 2016-11-09 0:03 UTC (permalink / raw)
To: Andy Lutomirski
Cc: John Stultz, Mickaël Salaün, Daniel Mack,
David S. Miller, kafai, fw, Harald Hoyer, Network Development,
Sargun Dhillon, Pablo Neira Ayuso, lkml, Tejun Heo, Li Zefan,
Jonathan Corbet, open list:CONTROL GROUP (CGROUP),
Android Kernel Team, Rom Lemarchand, Colin Cross, Dmitry Shmidt,
Todd Kjos, Christian Poetzsch, Amit Pundir, Dmitry Torokhov,
Kees Cook, Serge E . Hallyn, Linux API
In-Reply-To: <CALCETrU5fCWoe0RXfKWuN7Zt9vLvoyHFcZnVqeqiKBpSKrMrxA@mail.gmail.com>
On Tue, Nov 08, 2016 at 03:51:40PM -0800, Andy Lutomirski wrote:
> On Tue, Nov 8, 2016 at 3:28 PM, John Stultz <john.stultz@linaro.org> wrote:
> > This patch adds logic to allows a process to migrate other tasks
> > between cgroups if they have CAP_SYS_RESOURCE.
> >
> > In Android (where this feature originated), the ActivityManager tracks
> > various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM,
> > etc), and then as applications change states, the SchedPolicy logic
> > will migrate the application tasks between different cgroups used
> > to control the different application states (for example, there is a
> > background cpuset cgroup which can limit background tasks to stay
> > on one low-power cpu, and the bg_non_interactive cpuctrl cgroup can
> > then further limit those background tasks to a small percentage of
> > that one cpu's cpu time).
> >
> > However, for security reasons, Android doesn't want to make the
> > system_server (the process that runs the ActivityManager and
> > SchedPolicy logic), run as root. So in the Android common.git
> > kernel, they have some logic to allow cgroups to loosen their
> > permissions so CAP_SYS_NICE tasks can migrate other tasks between
> > cgroups.
> >
> > I feel the approach taken there overloads CAP_SYS_NICE a bit much
> > for non-android environments.
> >
> > So this patch, as suggested by Michael Kerrisk, simply adds a
> > check for CAP_SYS_RESOURCE.
> >
> > I've tested this with AOSP master, and this seems to work well
> > as Zygote and system_server already use CAP_SYS_RESOURCE. I've
> > also submitted patches against the android-4.4 kernel to change
> > it to use CAP_SYS_RESOURCE, and the Android developers just merged
> > it.
> >
>
> I hate to say it, but I think I may see a problem. Current
> developments are afoot to make cgroups do more than resource control.
> For example, there's Landlock and there's Daniel's ingress/egress
> filter thing. Current cgroup controllers can mostly just DoS their
> controlled processes. These new controllers (or controller-like
> things) can exfiltrate data and change semantics.
>
> Does anyone have a security model in mind for these controllers and
> the cgroups that they're attached to? I'm reasonably confident that
> CAP_SYS_RESOURCE is not the answer...
and specifically the answer is... ?
Also would be great if you start with specifying the question first
and the problem you're trying to solve.
^ permalink raw reply
* Re: [PATCH 0/2] Add new resets for pcie-rockchip
From: Heiko Stuebner @ 2016-11-09 0:05 UTC (permalink / raw)
To: Shawn Lin, Bjorn Helgaas
Cc: Rob Herring, devicetree, linux-rockchip, Brian Norris, linux-pci
In-Reply-To: <1477017836-19317-1-git-send-email-shawn.lin@rock-chips.com>
Hi Björn,
Am Freitag, 21. Oktober 2016, 10:43:54 CET schrieb Shawn Lin:
> Hi Bjorn and Heiko,
>
> Sorry for updating pcie-rockchip so frequently under this development
> cycle. This patch is going to fix a urgent issue of missing control for
> pm_rst, aclk_rst and pclk_rst. These three resets was controlled by rom code
> but now the driver will take over it in order to solve some weird issues
> found by MP test. Thanks to that it is still under MP test internally, so
> the backward compatibility of dtb won't be a big deal.
could you take a look at these patches and maybe think about including them
still for 4.9?
Thanks
Heiko
^ permalink raw reply
* Re: status of spdk
From: Yehuda Sadeh-Weinraub @ 2016-11-09 0:06 UTC (permalink / raw)
To: Sage Weil; +Cc: Wang, Haomai, ceph-devel
In-Reply-To: <alpine.DEB.2.11.1611082334390.32512@piezo.us.to>
On Tue, Nov 8, 2016 at 3:40 PM, Sage Weil <sweil@redhat.com> wrote:
> On Tue, 8 Nov 2016, Yehuda Sadeh-Weinraub wrote:
>> I just started looking at spdk, and have a few comments and questions.
>>
>> First, it's not clear to me how we should handle build. At the moment
>> the spdk code resides as a submodule in the ceph tree, but it depends
>> on dpdk, which currently needs to be downloaded separately. We can add
>> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
>> said, getting it to build was a bit tricky and I think it might be
>> broken with cmake. In order to get it working I resorted to building a
>> system library and use that.
>
> Note that this PR is about to merge
>
> https://github.com/ceph/ceph/pull/10748
>
> which adds the DPDK submodule, so hopefully this issue will go away when
> that merged or with a follow-on cleanup.
>
>> The way to currently configure an osd to use bluestore with spdk is by
>> creating a symbolic link that replaces the bluestore 'block' device to
>> point to a file that has a name that is prefixed with 'spdk:'.
>> Originally I assumed that the suffix would be the nvme device id, but
>> it seems that it's not really needed, however, the file itself needs
>> to contain the device id (see
>> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
>> minor fixes).
>
> Open a PR for those?
Sure
>
>> As I understand it, in order to support multiple osds on the same NVMe
>> device we have a few options. We can leverage NVMe namespaces, but
>> that's not supported on all devices. We can configure bluestore to
>> only use part of the device (device sharding? not sure if it supports
>> it). I think it's best if we could keep bluestore out of the loop
>> there and have the NVMe driver abstract multiple partitions of the
>> NVMe device. The idea is to be able to define multiple partitions on
>> the device (e.g., each partition will be defined by the offset, size,
>> and namespace), and have the osd set to use a specific partition.
>> We'll probably need a special tool to manage it, and potentially keep
>> the partition table information on the device itself. The tool could
>> also manage the creation of the block link. We should probably rethink
>> how the link is structure and what it points at.
>
> I agree that bluestore shouldn't get involved.
>
> Is the NVMe namespaces meant to support multiple processes sharing the
> same hardware device?
More of a partitioning solution, but yes (as far as I undestand).
>
> Also, if you do that, is it possible to give one of the namespaces to the
> kernel? That might solve the bootstrapping problem we currently have
Theoretically, but not right now (or ever?). See here:
https://lists.01.org/pipermail/spdk/2016-July/000073.html
> where we have nowhere to put the $osd_data filesystem with the device
> metadata. (This is admittedly not necessarily a blocking issue. Putting
> those dirs on / wouldn't be the end of the world; it just means cards
> can't be easily moved between boxes.)
>
Maybe we can use bluestore for these too ;) that been said, there
might be some kind of a loopback solution that could work, but not
sure if it won't create major bottlenecks that we'd want to avoid.
Yehuda
^ permalink raw reply
* RE: [PATCH v2 2/2] Staging: fsl-mc: include: mc: Kernel type 's32' preferred over 'int32_t'
From: Stuart Yoder @ 2016-11-08 23:52 UTC (permalink / raw)
To: Shiva Kerdel
Cc: gregkh@linuxfoundation.org, German.Rivera@freescale.com,
German Rivera, treding@nvidia.com, Nipun Gupta,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
Laurentiu Tudor
In-Reply-To: <20161108154214.16243-2-shiva@exdev.nl>
> -----Original Message-----
> From: Shiva Kerdel [mailto:shiva@exdev.nl]
> Sent: Tuesday, November 08, 2016 9:42 AM
> To: Stuart Yoder <stuart.yoder@nxp.com>
> Cc: gregkh@linuxfoundation.org; German.Rivera@freescale.com; German Rivera <german.rivera@nxp.com>;
> treding@nvidia.com; itai.katz@nxp.com; Nipun Gupta <nipun.gupta@nxp.com>; linux-kernel@vger.kernel.org;
> devel@driverdev.osuosl.org; Shiva Kerdel <shiva@exdev.nl>
> Subject: [PATCH v2 2/2] Staging: fsl-mc: include: mc: Kernel type 's32' preferred over 'int32_t'
>
> Follow the kernel type preferrences of using 's32' over 'int32_t'.
>
> Signed-off-by: Shiva Kerdel <shiva@exdev.nl>
> ---
> drivers/staging/fsl-mc/include/mc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fsl-mc/include/mc.h b/drivers/staging/fsl-mc/include/mc.h
> index a781a36..1c46c0c 100644
> --- a/drivers/staging/fsl-mc/include/mc.h
> +++ b/drivers/staging/fsl-mc/include/mc.h
> @@ -81,7 +81,7 @@ enum fsl_mc_pool_type {
> */
> struct fsl_mc_resource {
> enum fsl_mc_pool_type type;
> - int32_t id;
> + s32 id;
> void *data;
> struct fsl_mc_resource_pool *parent_pool;
> struct list_head node;
Acked-by: Stuart Yoder <stuart.yoder@nxp.com>
^ permalink raw reply
* RE: ACPI module-level code (MLC) not working?
From: Zheng, Lv @ 2016-11-09 0:07 UTC (permalink / raw)
To: Peter Wu
Cc: Rick Kerkhof, Bartosz Skrzypczak, Moore, Robert,
linux-acpi@vger.kernel.org
In-Reply-To: <20161108175650.GB21992@al>
Hi,
> From: Peter Wu [mailto:peter@lekensteyn.nl]
> Subject: Re: ACPI module-level code (MLC) not working?
>
> On Tue, Nov 08, 2016 at 05:35:07PM +0000, Zheng, Lv wrote:
> > Hi,
> >
> > > From: Peter Wu [mailto:peter@lekensteyn.nl]
> > > Subject: ACPI module-level code (MLC) not working?
> > >
> > > Hi Lv,
> > >
> > > According to some tests, setting acpi_gbl_parse_table_as_term_list to
> > > TRUE does is not effective. The code within the If-block is still not
> > > executed early enough or something else is wrong.
> > >
> > > Previously Rick had an issue with an Acer Aspire V7-582PG where the dGPU
> > > could not be powered off and I demonstrated an isolated test case in
> > > http://www.spinics.net/lists/linux-acpi/msg70069.html
> > >
> > > In Bartosz's case, the dGPU cannot be powered on (also using nouveau),
> > > preventing suspend from working. Situation is as follows (tested with
> > > Linux 3.16, 4.8.4, 4.9-rc2, 4.9-rc4):
> > >
> > > His Lenovo IdeaPad Z510 laptop (BIOS date 2014) enables power resources
> > > and related _PR3 objects under the conditional If(_OSI("Windows 2013")).
> > > Both with and without acpi_gbl_parse_table_as_term_list set to TRUE, the
> > > module-level code is not loaded properly. Via a SSDT override, it was
> > > confirmed that removing the If conditional results in the expected
> > > behavior.
> > >
> > > Various details are given in https://github.com/Bumblebee-Project/bbswitch/issues/142
> > > including lots of dmesg logs (see posts at the bottom).
> > > With above MLC flag set (v4.9-rc4): https://pastebin.com/raw/vCEPGezX
> > > With SSDT override (v4.9-rc2): https://pastebin.com/raw/3Fsf2VPU
> >
> > I checked the post.
> > It seems the current working way is: disabling _OSI(Windows 2013) which disables power resources.
>
> That is how Lenovo probably intended to use it (only add Power Resources
> when Windows 8 is detected).
>
> > I have several questions related to this issue:
> > 1. The following messages are prompt up when "acpi_gbl_parse_table_as_term_list = TRUE":
> > [ 2.519113] ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure, AE_NOT_FOUND
> (20160831/psargs-359)
> > [ 2.519121] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG1.PEGP.DD02._BCL] (Node
> ffff8802568d3cf8), AE_NOT_FOUND (20160831/psparse-543)
> > How was this triggered?
>
> This comes from acpi_video.c, ssdt4.dsl contains a \_SB.PCI0.GFX0.DD02
> device with an _ADR method, but no _BCL one. It is not a regression
> though, let's ignore this for now.
>
> > 2. I noticed the following statement:
> > So, for some reason Lenovo has decided to give all tables the same name.
> > The ACPI table override functionality matches possible candidates by signature, OEM ID and OEM
> Revision ID which are all the same.
> > As a result, the wrong SSDT is overridden.
> > Could you provide the detail of the tables from the platform?
> > What is the reason of doing such kind of craps in BIOS?
>
> I have no idea why Lenovo would do such a silly thing, but that is why
> we had to patch tables.c with:
>
> if (existing_table->checksum != 0xAF) {
> acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
> pr_info("Skipping next table\n");
> goto next_table;
> }
>
> This is of course an unacceptable hard-coded value, but it was needed in
> as a quick hack. For a longterm solution, maybe we can name the table
> files specially such that additional match conditions can be given. This
> is a different issue though.
>
> What would you like to know about the platform? The acpidump is
> available at
> https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4773050/+files/LENOVO-20287.tar.gz
>
> ssdt5.dsl is the file of interest, grep for "Windows 2013".
The table headers are:
DefinitionBlock ("dsdt.aml", "DSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
DefinitionBlock ("ssdt1.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
DefinitionBlock ("ssdt2.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
DefinitionBlock ("ssdt3.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
DefinitionBlock ("ssdt4.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
DefinitionBlock ("ssdt5.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
They will be deemed as different versions of the same table from linux ACPI's point of view.
Whether override will be done or not depends on Linux version.
In recent Linux, ssdt1.aml will be used (no override), while in old Linux, ssdt5.aml will be used (override).
Let me ask further.
1. Should OSPM load only ssdt5.aml or load only ssdt1.aml, or load ssdt1.aml,ssdt2.aml,ssdt3.aml,ssdt4.aml,ssdt5.aml?
2. Can you confirm Windows behavior here via amli?
Anyway, this is a special case that violates spec and seems to be aiming to trigger regressions against changed logic brought by me.
No matter whether the change is reasonable.
Linux only need a quirk for this platform.
Thanks
Lv
>
> Kind regards,
> Peter
>
> > Thanks and best regards
> > Lv
> >
> > >
> > > If you would like a new bugzilla entry or have some patches to test, you
> > > know where to find us :)
> > > --
> > > Kind regards,
> > > Peter Wu
> > > https://lekensteyn.nl
^ permalink raw reply
* Re: [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
From: Martin K. Petersen @ 2016-11-09 0:07 UTC (permalink / raw)
To: Arun Easi
Cc: Martin K. Petersen, kbuild test robot, Manish Rangankar,
kbuild-all, James Bottomley, lduncan, cleech, linux-scsi, netdev,
QLogic-Storage-Upstream, Yuval Mintz
In-Reply-To: <alpine.LRH.2.00.1611081555110.28058@mvluser05.qlc.com>
>>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
>> It's fine to post the patches split up to ease the review
>> process. But whatever we commit must obviously be bisectable.
Arun> If it is alright with you, we would like to have all of our
Arun> initial patches for the driver (qedi) squashed as a single commit
Arun> to the tree. We will ensure that this single combined commit
Arun> compiles clean.
That's fine with me.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)
From: Arnd Bergmann @ 2016-11-09 0:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Kernel Build Reports Mailman List, Olof's autobuilder, stable,
Greg KH, Eric W. Biederman
In-Reply-To: <CAOesGMjH1jGum3E08F2h5dH2dyq_ekwZ_4M7piAdsxDFvhXu8g@mail.gmail.com>
On Tuesday, November 8, 2016 3:26:52 PM CET Olof Johansson wrote:
> On Tue, Nov 8, 2016 at 2:17 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> >>> Here are the build results from automated periodic testing.
> >>>
> >>> The tree being built was stable-rc, found at:
> >>>
> >>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> >>>
> >>> Topmost commit:
> >>>
> >>> f821e08 Linux 4.4.31-rc1
> >>>
> >>> Build logs (stderr only) can be found at the following link (experimental):
> >>>
> >>> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
> >>
> >> These seem to be largely caused by building with gcc-6. It's probably
> >> a good idea to keep supporting that configuration though and
> >> backport the fixes. Here are the upstream commit IDs I've found.
> >
> > That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
> >
> > It's not entirely reasonable to expect older releases to build with
> > new toolchains without warnings, and I'm not sure if it makes sense to
> > bring back those fixes to -stable (unless they fix real bugs, of
> > course).
>
> A lot less noise with older gcc:
>
> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-44-gc5be865/
Out of the ones I mentioned earlier, that leaves
aaaab56dba9a ("of: silence warnings due to max() usage")
badbda53e505 ("mm/cma: silence warnings due to max() usage")
but adds a couple of others:
| arch/powerpc/relocs_check.sh: line 46: ccache /usr/local/cross-4.9.2/bin/powerpc64-linux-objdump: No such file or directory
| arch/arm64/Makefile:25: LSE atomics not supported by binutils
These seem to be caused by an older binutils release in your cross-4.9.2 build
| In file included from /work/build/batch/drivers/isdn/hardware/eicon/message.c:30:0:
| /work/build/batch/drivers/isdn/hardware/eicon/message.c: In function 'mixer_notify_update':
| /work/build/batch/drivers/isdn/hardware/eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds]
| *(__le16 *)addr = cpu_to_le16(v);
This looks like a false-positive bug caused by 4.9 that is no longer
present in newer compilers.
I assume this is the line
PUT_WORD(&(((CAPI_MSG *) msg)->info.facility_req.structs[1]), LI_REQ_SILENT_UPDATE);
Arnd
^ 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.