: is there some subtle C-issue that is evaded here by setting
head->next to NULL prior to copying over it?
(I know this piece of code only got copied around in this patch and this is
therefor not something that this patch actually introduced.)
> +
> + func(rq);
> + }
> +}
Thanks,
Paul Bolle
rror;
|^~~~
make[4]: *** [scripts/Makefile.build:283: sound/soc/sof/intel/hda-codec.o]
Error 1
make[3]: *** [scripts/Makefile.build:500: sound/soc/sof/intel] Error 2
make[2]: *** [scripts/Makefile.build:500: sound/soc/sof] Error 2
make[1]: *** [scripts/Makefile.build:500: sound/soc] Error 2
make: *** [Makefile:1778: sound] Error 2
There's indeed no error label in v5.9.5. (There is one in v5.10-rc2, I just
checked.) Is no-one else running into this?
Thanks,
Paul Bolle
The following commit has been merged into the locking/core branch of tip:
Commit-ID: d89d5f855f84ccf3f7e648813b4bb95c780bd7cd
Gitweb:
https://git.kernel.org/tip/d89d5f855f84ccf3f7e648813b4bb95c780bd7cd
Author:Paul Bolle
AuthorDate:Thu, 01 Oct 2020 22:20:28 +02:00
n_ia32_syscall() just checking CONFIG_IA32_EMULATION
should do too.
(Way outside my limited expertise, but anyway: is does look odd to see a call
to in_ia32_syscall() in drivers/. All other calls are in arch/x86/. Isn't this
a bit too x86 specific for an arch independent driver?)
Thanks,
Paul Bolle
Andy Shevchenko schreef op wo 07-10-2020 om 14:58 [+0300]:
> Does [1] fix the issue?
>
> [1]:
> https://lore.kernel.org/linux-gpio/20201005131044.87276-1-andriy.shevche...@linux.intel.com/
Yes, it fixes the build error.
Thanks,
Paul Bolle
cases when host - guest - guest app either from:
> 1. x86_64 - x86_64 - i386;
> 2. x86_64 - i386 - i386.
I ran into this build error too.
Perhaps the UML maintainers have an idea what to do here. The commit that
triggers this error is 5ad284ab3a01 ("gpiolib: Fix line event handling in
syscall compatible mode").
Thanks,
Paul Bolle
The sha1sum of include/linux/atomic-arch-fallback.h isn't checked by
check-atomics.sh. It's not clear why it's skipped so let's check it too.
Signed-off-by: Paul Bolle
---
It seems it never has been checked. So this does cast some doubt about
the usefulness of these tests. Bu
of these warnings in about six
days, while the session before that (v5.2.y) showed none.
Just like in Norbert's case, wifi appears to work fine.
Paul Bolle
Greg KH schreef op ma 26-08-2019 om 06:34 [+0200]:
> It's on that key already, have you refreshed your version of it?
I have now. sas...@kernel.org (and another identity) is now on that key.
Thanks,
Paul Bolle
ould use one of gpg2's many options
to add an
aka "Sasha Levin "
line to that key. (I assume "--recv-key" then would have found your key.)
Or would that be a sin against kernel.org policy, state-of-the-art
cryptographic practices, or whatever?
Thanks,
Paul Bolle
Hi Phong,
Phong Tran schreef op za 27-07-2019 om 08:56 [+0700]:
> On 7/26/19 9:22 PM, Paul Bolle wrote:
> > Phong Tran schreef op vr 26-07-2019 om 20:35 [+0700]:
> > > diff --git a/drivers/isdn/gigaset/usb-gigaset.c
> > > b/drivers/isdn/gigaset/usb-gigaset
F: include/uapi/linux/gfs2_ondisk.h
-GIGASET ISDN DRIVERS
-M: Paul Bolle
-L: gigaset307x-com...@lists.sourceforge.net
-W: http://gigaset307x.sourceforge.net/
-S: Odd Fixes
-F: drivers/staging/isdn/gigaset/
-
GNSS SUBSYSTEM
M: Johan Hovold
T: git git://git.kernel.org
I should check. (The subject of that thread
contains "[5.2 REGRESSION]", but I'd say "[5.3-rc1 REGRESSION]" would more
accurate, but whatever.)
Thanks,
Paul Bolle
t: No such process
[ OK ] Stopped Journal Service.
And without systemd-journald I couldn't get userspace up and running.
A bit of tinkering showed that "vdso32=0" on the kernel command line allows me
to get a usable userspace.
Any idea where I should look next to pinpoint this?
Thanks,
Paul Bolle
;endpoint[1].desc;
> +if (!endpoint) {
> + dev_err(cs->dev, "Endpoint not available\n");
> + retval = -ENODEV;
> + goto error;
> + }
>
> ucs->busy = 0;
>
Please note that I'm very close to getting cut off from the ISDN network, so
the chances of being able to testi this on a live system are getting small.
Thanks,
Paul Bolle
Hi Jose,
James Bottomley schreef op do 18-07-2019 om 06:29 [+0900]:
> On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote:
> > I've just reached a day of uptime with your revert. (The proper
> > uptime is just a fraction of a day, this being a laptop.) Anyhow, no
> &g
Paul Bolle schreef op di 09-04-2019 om 21:11 [+0200]:
> Does it still apply?
It does, cleanly. Output is (for v5.1-rc4):
./usr/include/asm-generic/fcntl.h:119: leaks CONFIG_64BIT to userspace where it
is not valid
./usr/include/asm-generic/mman-common.h:22: le
a local branch for over five years, but
never dared to push it upstream.
Does it still apply?
Thanks,
Paul Bolle
-- >8 ---
>From 0f73c8ee776c197e3029c4eed21af0f121a8f9d3 Mon Sep 17 00:00:00 2001
From: Paul Bolle
Date: Tue, 4 Feb 2014 22:22:48 +0100
Subject: [PATCH] headers_check: enab
-Wimplicit-fallthrough=3
>
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Paul Bolle
Thanks,
Paul Bolle
keeping the ISDN
subsystem in the tree after September 1, 2019, and if so, in what form. I'm in
no position to properly answer that question.
Paul Bolle
? You didn't touch the procinfo method in the other ISDN
drivers, as far as I can see.
(If it was intentional, gigaset_procinfo() can of course be removed.)
> - iif->ctr.proc_fops = &gigaset_proc_fops;
> + iif->ctr.proc_show = gigaset_proc_show,
> INIT_LIST_HEAD(&iif->appls);
> skb_queue_head_init(&iif->sendqueue);
> atomic_set(&iif->sendqlen, 0);
Thanks,
Paul Bolle
that's done you're free to send cleanup patches for this whenever
you feel like doing so.
Thanks,
Paul Bolle
/* Is the help text empty or all whitespace? */
> + if ($2[strspn($2, " \f\n\r\t\v")] == '\0')
> + zconfprint("warning: '%s' defined with blank help text",
> +current_entry->sym->name ?: "");
> +
Does this go to stderr?
Another fix would be to ignore empty help texts and not render them at all. Is
that possible?
Thanks,
Paul Bolle
ch is actually part of the LINUXINCLUDE variable, but split off
to make things confusing.)
Why do you need to include linux/kconfig.h here?
> #include
> #include
Thanks,
Paul Bolle
happy. I don't mind, and I could keep on doing
that for years. But still, I'd love to hear someone say: yes, I still care
about mainline ISDN.
Does that person still exists?
Thanks,
Paul Bolle
awkward place where my ISDN setup lives. I'll spare you the
details. But that silliness again shows, I'd say, that the gigaset code mainly
exists to see if there's still a pulse in mainline ISDN. Is that enough to
bother? Or should mainline ISDN go the way of, say, IRDA?
But I digress. An alternative patch would be much appreciated.
Thanks,
Paul Bolle
y hardcoded to 1 for all three drivers (including
bas_gigaset). So driver->cs itself is invalid here.
And since the patch uses
struct cardstate *cs = urb->context;
in a few places my guess is that it's really the patch that triggers this.
Thanks,
Paul Bolle
On Thu, 2017-10-19 at 23:03 +0200, Paul Bolle wrote:
> On Mon, 2017-10-16 at 17:29 -0700, Kees Cook wrote:
> > In preparation for unconditionally passing the struct timer_list pointer to
> > all timer callbacks, switch to using the new timer_setup() and from_timer()
> > to p
On Mon, 2017-10-16 at 17:29 -0700, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
Acked-by: Paul Bolle
For the record: t
On Mon, 2017-10-16 at 17:29 -0700, Kees Cook wrote:
> This replaces a kmalloc followed by a bunch of per-field zeroing with a
> single kzalloc call, reducing the lines of code.
Acked-by: Paul Bolle
Thanks,
Paul Bolle
o use random pointers in these timer
callbacks is removed.)
Thanks,
Paul Bolle
ce to look at
them properly!): I'd prefer it if that was done separately in a preceding
patch. Would that bother you?
Thanks,
Paul Bolle
gt; snakes. But I just wanted to point out the lack of consistency here.
A major benefit is that
#if IS_ENABLED(CONFIG_HYPERV)
is shorter than
#if defined(CONFIG_HYPERV) || defined(CONFIG_HYPERV_MODULE)
and less prone to typos.
Paul Bolle
gned-off-by: Joe Perches
> ---
> drivers/isdn/gigaset/interface.c| 2 +-
Gigaset hunk looks good to me:
Acked-by: Paul Bolle
> drivers/isdn/hardware/mISDN/avmfritz.c | 17 +
> drivers/isdn/hardware/mISDN/hfcmulti.c | 8
> drivers/isdn/hardware/mISD
owing stack of stuff that I should
actually submit:
Acked-by: Paul Bolle
Thanks,
Paul Bolle
On Tue, 2017-01-03 at 23:25 +0100, Arnd Bergmann wrote:
> As far as I'm concerned, we are totally fine as long as there exists a
> longterm supported kernel that has i4l in drivers/staging.
Or in drivers/isdn, right?
Paul Bolle
cleanups?
How often did a bunch of drivers re-enter the tree after being sent to
staging?
Paul Bolle
On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
> I don't have a problem with C programming
I'm sorry, but you do need to learn C, at a basic level, first.
Paul Bolle
pe for target 'net/wireless/reg.o' failed
make: *** [net/wireless/reg.o] Error 2
Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
Paul Bolle
include/asm/ got removed in v1.1.45. Two decades later it's about time
to stop worrying whether patches still touch it.
Signed-off-by: Paul Bolle
---
Lightly tested.
scripts/checkpatch.pl | 5 -
1 file changed, 5 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpat
uot; ]; then
echo "#define __KSYM_module_layout 1" >> "$new_ksyms_file"
fi
> I'm trying to determine the best way to fix it. Stay tuned.
Will do. I'm curious to see what a proper fix might look like.
Thanks,
Paul Bolle
On Thu, 2016-12-01 at 10:01 +0100, Paul Bolle wrote:
> Perhaps this is all documented somewhere. But even then it would be nice if
> the build would fail right at the start. Ie, the build probably should fail if
> one does "make bzImage" while having a .config with
> CONF
NUSED_KSYMS=y
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
Because it seems in that case the subsequent "make modules" will then end in
this flood of ERRORs.
Paul Bolle
On Wed, 2016-11-30 at 22:42 +0100, Paul Bolle wrote:
> My current theory is that setting MODVERSIONS, somehow, hides the ERROR spew.
> Because that could explain your bisect. Linus' commit turns of MODVERSIONS the
> hard way. And, naturally, this theory fails if your .con
xplain your bisect. Linus' commit turns of MODVERSIONS the
hard way. And, naturally, this theory fails if your .configs never had
MODVERSIONS set in the first place.
I'm testing all this right now, but you probably command more powerful
machines and could beat me in testing this theory.
Thanks,
Paul Bolle
O build
> successfully, so I'm a wee bit baffled as to what's actually going on
> here.
Likewise (ie, both the modules splat going away if doing a single make and
being baffled, but more that a wee bit).
Paul Bolle
y we call pkg-config in scripts/kconfig/Makefile. Or in
scripts/kconfig/lxdialog/check-lxdialog.sh. Not sure, I didn't yet dive deeper
into this.
Hope this helps,
Paul Bolle
Commit-ID: 9190e21780dfeff524a67c6e7b806c8a9d496086
Gitweb: http://git.kernel.org/tip/9190e21780dfeff524a67c6e7b806c8a9d496086
Author: Paul Bolle
AuthorDate: Fri, 25 Nov 2016 13:41:47 +0100
Committer: Ingo Molnar
CommitDate: Mon, 28 Nov 2016 07:49:17 +0100
x86/build: Remove three
Commit-ID: 06cbbac0f57d947656a12c30a0a69d4cf0ac6dea
Gitweb: http://git.kernel.org/tip/06cbbac0f57d947656a12c30a0a69d4cf0ac6dea
Author: Paul Bolle
AuthorDate: Fri, 25 Nov 2016 13:38:34 +0100
Committer: Ingo Molnar
CommitDate: Mon, 28 Nov 2016 07:49:17 +0100
x86/build: Don'
less.
Signed-off-by: Paul Bolle
---
arch/x86/include/asm/Kbuild | 4
1 file changed, 4 deletions(-)
diff --git a/arch/x86/include/asm/Kbuild b/arch/x86/include/asm/Kbuild
index 2cfed174e3c9..2b892e2313a9 100644
--- a/arch/x86/include/asm/Kbuild
+++ b/arch/x86/include/asm/Kbuild
@@ -6,10
: Paul Bolle
---
arch/x86/realmode/rm/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
index 25012abc3409..4463fa72db94 100644
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@ -69,7 +69,7
) twice.
Signed-off-by: Paul Bolle
---
Build tested only!
arch/mips/boot/compressed/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/boot/compressed/Makefile
b/arch/mips/boot/compressed/Makefile
index 011b14512c05..41564a4db6f7 100644
--- a/arch/mips/boot
pointless. So stop appending to these flags.
Signed-off-by: Paul Bolle
---
Build tested only!
arch/cris/boot/compressed/Makefile | 3 ---
arch/cris/boot/rescue/Makefile | 3 ---
2 files changed, 6 deletions(-)
diff --git a/arch/cris/boot/compressed/Makefile
b/arch/cris/boot/compressed
el.org/msg1262410.html
> https://marc.info/?l=linux-kernel&m=147780880425626
> Stat: n/a
> Note: nothing happened yet; BTW: Should build regressions be on this list at
> all?
Fixed by commit 818f38c5b7c4 ("MIPS: Fix build of compressed image"). So this
is actually fixed since v4.9-rc4, but I only looked into this again today.
Thanks,
Paul Bolle
incorrect. The example that comes to mind is
depends on SH
that I have spotted a few times in the past years. But this treewide pass will
incur some runtime cost and might not be easy to implement cleanly. Perhaps
we're better of with using your script for that.
Thanks,
Paul Bolle
Please play with it. Unless you spot some issues I really should be properly
resubmitting it.
Thanks,
Paul Bolle
>8 >8 >8 >8 ---
From: Paul Bolle
Subject: [PATCH] kconfig: warn if an unknown symbol is selected
A select of an unknown symbol is basically treated as a
c License as published by the Free
> + * Software Foundation, version 2.
> +MODULE_LICENSE("GPL");
Nit: according to the comments in include/linux/module.h the "ident" that
matches the license described at the top of this file is "GPL v2".
Paul Bolle
On Mon, 2016-11-07 at 14:38 +0100, Heiko Carstens wrote:
> On Mon, Nov 07, 2016 at 02:13:06PM +0100, Paul Bolle wrote:
> > --- /dev/null
> > +++ b/arch/s390/include/asm/facilities.h
> > @@ -0,0 +1,43 @@
> > +#ifndef __ASM_FACILITIES_H
> > +#define __AS
Hi Mashiro,
On Tue, 2016-11-08 at 10:50 +0900, Masahiro Yamada wrote:
> 2016-11-07 21:52 GMT+09:00 Paul Bolle :
> > So it seems the odd $(LINUXINCLUDE) variable in that Makefile could be
> > replaced with something like:
> > -include $(srctree)/include/generated/autoc
attempt to use asm/facilities.h instead of
generated/facilities.h. That allows to drop arch/s390/tools/ entirely. I don't
actually have an s390 machine at hand to test this, but this does build and
the preprocessed code this generates looks sane.
(Yes, asm/facilities.h might need another le
ities.c is actually
interested in is autoconf.h. (autoconf.h will be included via in kconfig.h.)
So it seems the odd $(LINUXINCLUDE) variable in that Makefile could be
replaced with something like:
-include $(srctree)/include/generated/autoconf.h
Paul Bolle
Commit-ID: 0acba3f91823a5e53a54af5dc31fc774b0e64e99
Gitweb: http://git.kernel.org/tip/0acba3f91823a5e53a54af5dc31fc774b0e64e99
Author: Paul Bolle
AuthorDate: Thu, 3 Nov 2016 10:47:48 +0100
Committer: Ingo Molnar
CommitDate: Mon, 7 Nov 2016 07:30:01 +0100
x86/boot/build: Remove always
Apparently Matt left Intel. Let's forward this to a recently used
address.
On Thu, 2016-11-03 at 10:47 +0100, Paul Bolle wrote:
> Commmit b6eea87fc685 ("x86, boot: Explicitly include autoconf.h for
> hostprogs") correctly noted
> [...] that because $(USERINCLUDE) isn
he reference to that make variable.
Signed-off-by: Paul Bolle
---
arch/x86/boot/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index 12ea8f8384f4..0d810fb15eac 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefil
Kernel source files need not include explicitly
because the top Makefile forces to include it with:
-include $(srctree)/include/linux/kconfig.h
Remove another reduntdant include, that managed to sneak by commit
97139d4a6f26 ("treewide: remove redundant #include ").
Signed-off-by:
On Thu, 2016-11-03 at 02:16 -0700, Joe Perches wrote:
> Yes, it's been reported and should be fixed in -mm.
> The fix should show up in -next in a little bit.
Great.
> For now, try:
> $ sed -i -e 's/\xA0/ /g' scripts/get_maintainer.pl
Thanks,
Paul Bolle
character \xA0; marked by <-- HERE after <-- HERE near column
1 at ./scripts/get_maintainer.pl line 277.
Git blame shows:
git blame -L 277,+1 ./scripts/get_maintainer.pl
b67071653d3fc (Joe Perches 2016-10-28 13:22:01 +1100 277)
$sections = 1;
(A0 seems to be the no break space. That character was inserted more
often further down the patch.)
Anybody else seeing this?
Paul Bolle
is
because it started out as a mistyped reference to LINUXINCLUDE.) So this
reference has always been an empty string. Let's remove it before it
spreads any further.
Signed-off-by: Paul Bolle
---
arch/s390/boot/compressed/Makefile| 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
drive
The build system stopped generating ikconfig.h in v2.6.8. Remove an entry
for it in dontdiff. There's also a reference to it in a small comment.
Remove that comment too, as it is of little help in any case.
Signed-off-by: Paul Bolle
---
Documentation/dontdiff | 1 -
kernel/Makefile
work. Should Intel fix its mail setup, or should lkml.kernel.org learn
to escape "%"?)
Thanks,
Paul Bolle
goal to
be able to use the same kernel image as a host and a guest. At least, I
think that is one of its goals.
And as probably everybody capable of hacking on lguest (ie, other
people than me) came up with doubts similar to yours, these two issues
never got fixed.
Thanks,
Paul Bolle
I didn't understand much of the possible solutions that where suggested
three years ago.
I'm certain I still ran into this issue with the microcode loader in
the beginning of this year, so that was probably with a v4.4 based
guest.
Paul Bolle
13 for fault at 0x162: Invalid argument
A similar obscure gotcha (I think it is "unhandled trap 13") can be
avoided by launching the guest with the dis_ucode_ldr kernel option.
Hope this helps,
Paul Bolle
es should be proper English. But commit header lines
should not end with a period. The vast majority doesn't. Yes, I've just
checked.
How many newspaper headlines end with a period?
Thanks,
Paul Bolle
o break that hard dependency from those drivers without preventing their
> usage altogether.
By the way: would you have pointers to threads that discussed attempts
to achieve this using currently available Kconfig options?
Thanks,
Paul Bolle
On Thu, 2016-10-27 at 23:10 -0400, Nicolas Pitre wrote:
> On Fri, 28 Oct 2016, Paul Bolle wrote:
> > And in your example BAR is bool, right? Does the above get more
> > complicated if BAR would be tristate?
>
> If BAR=m then implying BAZ from FOO=y will force BAZ to y o
On Thu, 2016-10-27 at 23:10 -0400, Nicolas Pitre wrote:
> On Fri, 28 Oct 2016, Paul Bolle wrote:
> > What happens when a tristate symbol is implied by a symbol set to 'y'
> > and by a symbol set to 'm'?
>
> That's respectively the third and second r
On Thu, 2016-10-27 at 23:10 -0400, Nicolas Pitre wrote:
> On Fri, 28 Oct 2016, Paul Bolle wrote:
> > You probably got "["if" ]" for free by copying what's there for
> > select. But this series doesn't use it, so perhaps it would be better
> >
For ARMv7 SoCs
config PINCTRL_MT2701
3) Would you like me to submit a proper (but lightly tested) patch or
do you prefer to fix this yourself?
Thanks,
Paul Bolle
> b) Match dependency semantics:
> b1) Swap all "select FOO" to "depends on FOO" or,
> b2) Swap all "depends on FOO" to "select FOO"
> + c) Consider the use of "imply" instead of "select"
If memory serves me right this text was added after a long discussion
with Luis Rodriguez. Luis might want to have a look at any
Haven't looked at the code yet, sorry. I'm still trying to see whether
I can wrap my mind around this. It looks like just setting a default on
another symbol, but there could be a twist I missed.
Paul Bolle
As far as I can see this series doesn't add a user of "suggest". So I
see no reason to add it.
NAK.
Paul Bolle
On Wed, 2016-10-26 at 19:41 -0400, Nicolas Pitre wrote:
> On Thu, 27 Oct 2016, Paul Bolle wrote:
> > If you'll have to send another update don't bother including Yann. Yann
> > hasn't be heard of in years. MAINTAINERS doesn't reflect reality for
> > kcon
selected") has a special meaning in kconfig land. I guess you meant
something neutral like "set" here. Is that correct?
By the way: "also" makes this sentence hard to parse.
Paul Bolle
including Yann. Yann
hasn't be heard of in years. MAINTAINERS doesn't reflect reality for
kconfig.
Paul Bolle
d(__KERNEL__)
(In that case you're probably better of defining these macros outside
of uapi.)
I've only lightly tested those two alternatives, so please double
check.
Paul Bolle
Commit-ID: bb12d6740f6de393927362f23f833a79d85df384
Gitweb: http://git.kernel.org/tip/bb12d6740f6de393927362f23f833a79d85df384
Author: Paul Bolle
AuthorDate: Tue, 25 Oct 2016 22:56:05 +0200
Committer: Ingo Molnar
CommitDate: Wed, 26 Oct 2016 08:41:06 +0200
x86/decoder: Use stderr if
Commit-ID: bdcc18b548b8f1fab23c097724c6f32daac03185
Gitweb: http://git.kernel.org/tip/bdcc18b548b8f1fab23c097724c6f32daac03185
Author: Paul Bolle
AuthorDate: Tue, 25 Oct 2016 22:56:04 +0200
Committer: Ingo Molnar
CommitDate: Wed, 26 Oct 2016 08:41:06 +0200
x86/decoder: Use stdout if
e typo).
Patch 2/2 does the reverse for the "insn sanity test": it sends a message to
stderr if that test fails.
One thing puzzles me about these two tests: I must have run them hundreds of
times but I've never seen them fail. Have other people ran into failures?
Paul Bolle (2):
x
If the instruction sanity test fails, it prints a "Failure" message to
stdout. Make this program behave like the rest of the build and print
that message to stderr.
Signed-off-by: Paul Bolle
---
arch/x86/tools/insn_sanity.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
di
r for errors
or warnings. We're told about a successful run here, so the instruction
decoder test should use stdout.
Let's fix the typo too, while we're at it.
Signed-off-by: Paul Bolle
---
The joke about the guidelines is shamelessly copied from commit 55a6e622e66a
("arch/x86/tool
[Detailed post, but please give it a quick scan.]
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> > start.
>
> That would be betw
The abbreviation for Cryptographic Coprocessor is "CCP".
Signed-off-by: Paul Bolle
---
include/linux/ccp.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/ccp.h b/include/linux/ccp.h
index a7653339fedb..c71dd8fa5764 100644
--- a/include/linux/c
[Added Nicolas.]
On Thu, 2016-10-20 at 21:06 +0900, Masahiro Yamada wrote:
> 2016-10-20 19:04 GMT+09:00 Paul Bolle :
> > On Sun, 2016-10-16 at 20:07 +0900, Masahiro Yamada wrote:
> > There are about a dozen instances of IS_ENABLED() that target something
> > other than a kc
_is_defined(arg1_or_junk) __take_second_arg(arg1_or_junk 1, 0)
__is_defined() is now meant to be used generally, and not just on
kconfig macros. Can it be moved into another header?
Paul Bolle
t; isn't in there. Don't worry, it's not lost, it will get handled
> eventually...
Great. I'll be patient from now on. Sorry for the noise.
Paul Bolle
know.
Did I botch my attempt at a backport of "lightnvm: ensure that
nvm_dev_ops can be used without CONFIG_NVM" to v4.4.y (see
https://lkml.kernel.org/r/<1476477349-28155-1-git-send-email-pebolle@ti
scali.nl> ) sufficiently for it to be dropped?
Thanks,
Paul Bolle
On Fri, 2016-10-14 at 22:35 +0200, Paul Bolle wrote:
> From: Jens Axboe
>
> From: Jens Axboe
Bother. Resend?
Paul Bolle
e.
Signed-off-by: Jens Axboe
[pebolle: backport to v4.4]
Signed-off-by: Paul Bolle
---
Jens, there's a missing include of in v4.4.y, which is
making me rather nervous. Please double check my backport.
include/linux/lightnvm.h | 121 +--
1 f
On Fri, 2016-10-14 at 15:47 +0200, Greg KH wrote:
> Makes sense to me, can you forward on a patch that applies cleanly and
> I'll queue it up for the next round (after this one.)
Hope to do that later today. If it turns out I've messed things up Jens
can still speak up.
Thanks,
Paul Bolle
rd is enough for you, then feel free to
queue it up.
> Also, stable questions/issues should be cc:ed to sta...@vger.kernel.org.
Sorry about that. I've received one too many of your formletters, so
now I try to avoid sta...@vger.kernel.org as much as I can.
Thanks,
Paul Bolle
1 - 100 of 2074 matches
Mail list logo
