re simply was no other way, and I took it for given that this is seen
by everybody involved as an absolute exception, due to the nature of the
issue and of the massive changes that were needed.
Thanks,
--
Jiri Kosina
SUSE Labs
m major distro kernels
(based on that very -stable release), as that's apparently what people
are hitting in the real world with that particular kernel
?
Thanks,
--
Jiri Kosina
SUSE Labs
m major distro kernels
(based on that very -stable release), as that's apparently what people
are hitting in the real world with that particular kernel
?
Thanks,
--
Jiri Kosina
SUSE Labs
ure that for almost every fix there is a person on a planet
that'd rate it "critical". We can't really use this as an argument for
inclusion of code into -stable, as that'd mean that -stable and Linus'
tree would have to be basically the same.
--
Jiri Kosina
SUSE Labs
ure that for almost every fix there is a person on a planet
that'd rate it "critical". We can't really use this as an argument for
inclusion of code into -stable, as that'd mean that -stable and Linus'
tree would have to be basically the same.
--
Jiri Kosina
SUSE Labs
f regressions.
So this whole debate is about finding a compromise.
My gut feeling always was that the statement in
Documentation/process/stable-kernel-rules.rst
is very reasonable, but making the process way more "aggresive" when
backporting patches is breaking much of its o
f regressions.
So this whole debate is about finding a compromise.
My gut feeling always was that the statement in
Documentation/process/stable-kernel-rules.rst
is very reasonable, but making the process way more "aggresive" when
backporting patches is breaking much of its o
ch -stable tree consumer
anyway).
This is a POV of me as an distro kernel maintainer, but mileage of others
definitely can / will vary of course.
Thanks,
--
Jiri Kosina
SUSE Labs
ch -stable tree consumer
anyway).
This is a POV of me as an distro kernel maintainer, but mileage of others
definitely can / will vary of course.
Thanks,
--
Jiri Kosina
SUSE Labs
into the git commit
changelog, therefore should instead contain something like "This adds a
news driver for HW XX, that needs a specialized driver bacuse and
things to specifically point out in implementation are ".
Could you please provide that, so that I can commit it?
Thanks.
--
Jiri Kosina
SUSE Labs
into the git commit
changelog, therefore should instead contain something like "This adds a
news driver for HW XX, that needs a specialized driver bacuse and
things to specifically point out in implementation are ".
Could you please provide that, so that I can commit it?
Thanks.
--
Jiri Kosina
SUSE Labs
ut figuring out the
'closer bigger fitting type' for hexadecimal literals, which might be more
tricky.
Thanks,
--
Jiri Kosina
SUSE Labs
ut figuring out the
'closer bigger fitting type' for hexadecimal literals, which might be more
tricky.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 27 Mar 2018, Jiri Kosina wrote:
> > These patches are untested. Especially, patch 1 slightly changes the
> > behavior
> > of 't4_read_write_register()'.
> > This looks logical to me, but please, review it carefully.
> >
> > Christophe JAILLET (4):
&g
On Tue, 27 Mar 2018, Jiri Kosina wrote:
> > These patches are untested. Especially, patch 1 slightly changes the
> > behavior
> > of 't4_read_write_register()'.
> > This looks logical to me, but please, review it carefully.
> >
> > Christophe JAILLET (4):
&g
re-sending report description command after resume.
> Add device ID as a quirk.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Aaron Ma <aaron...@canonical.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
re-sending report description command after resume.
> Add device ID as a quirk.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Aaron Ma
Applied, thanks.
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina <jkos...@suse.cz>
Commits 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time") and
a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time") lost the
type information for __VMALLOC_BASE_L4, __VMALLOC_BASE_L5,
__VMEMMAP_BASE_L4 and _
From: Jiri Kosina
Commits 9b46a051e4 ("x86/mm: Initialize vmemmap_base at boot-time") and
a7412546d8 ("x86/mm: Adjust vmalloc base and size at boot-time") lost the
type information for __VMALLOC_BASE_L4, __VMALLOC_BASE_L5,
__VMEMMAP_BASE_L4 and __VMEMMAP_BASE_L5 constants.
On Tue, 10 Apr 2018, Josh Poimboeuf wrote:
> I think CONFIG_LOCKDEP is always a good idea.
FWIW CONFIG_LOCKDEP mostly enables the infrastructure, but
CONFIG_PROVE_LOCKING is what turns most of the cleverness on.
--
Jiri Kosina
SUSE Labs
On Tue, 10 Apr 2018, Josh Poimboeuf wrote:
> I think CONFIG_LOCKDEP is always a good idea.
FWIW CONFIG_LOCKDEP mostly enables the infrastructure, but
CONFIG_PROVE_LOCKING is what turns most of the cleverness on.
--
Jiri Kosina
SUSE Labs
>exist`.
> Most functions check 'dev->exist' before doing its work, but
> `hidraw_get_report()` was missing that check.
>
> Signed-off-by: Rodrigo Rivas Costa <rodrigorivasco...@gmail.com>
Applied, thank you.
--
Jiri Kosina
SUSE Labs
>exist`.
> Most functions check 'dev->exist' before doing its work, but
> `hidraw_get_report()` was missing that check.
>
> Signed-off-by: Rodrigo Rivas Costa
Applied, thank you.
--
Jiri Kosina
SUSE Labs
On Tue, 3 Apr 2018, Aaron Ma wrote:
> Hi Jiri:
>
> This patch is pending for long time.
>
> Could you merge this single patch to upstream?
I don't this I am seeing it in my inbox. Could you please resend? Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 3 Apr 2018, Aaron Ma wrote:
> Hi Jiri:
>
> This patch is pending for long time.
>
> Could you merge this single patch to upstream?
I don't this I am seeing it in my inbox. Could you please resend? Thanks,
--
Jiri Kosina
SUSE Labs
> Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Torokhov <dmitry.torok...@gmail.com>
Applied for 4.17, thanks.
--
Jiri Kosina
SUSE Labs
> Fixes: 581c4484769e ("HID: input: map digitizer battery usage")
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095
> Cc: sta...@vger.kernel.org
> Signed-off-by: Dmitry Torokhov
Applied for 4.17, thanks.
--
Jiri Kosina
SUSE Labs
/thermal/tmon/sysfs.c| 12 +++-
tools/thermal/tmon/tmon.c | 1 -
40 files changed, 60 insertions(+), 61 deletions(-)
--
Jiri Kosina
SUSE Labs
/thermal/tmon/sysfs.c| 12 +++-
tools/thermal/tmon/tmon.c | 1 -
40 files changed, 60 insertions(+), 61 deletions(-)
--
Jiri Kosina
SUSE Labs
Sliepen (1):
HID: corsair: Add support for the GLAIVE RGB gaming mouse
Haridhar Kalvala (1):
HID: google: Enable PM Full On mode when adjusting backlight
Jiri Kosina (1):
HID: wacom: wacom_wac_collection() is local to wacom_wac.c
Todd Kelner (1):
HID: sony: Add touchp
Sliepen (1):
HID: corsair: Add support for the GLAIVE RGB gaming mouse
Haridhar Kalvala (1):
HID: google: Enable PM Full On mode when adjusting backlight
Jiri Kosina (1):
HID: wacom: wacom_wac_collection() is local to wacom_wac.c
Todd Kelner (1):
HID: sony: Add touchp
PE=Device
>
> rdesc file is attached
>
> Thx for the effort!
Can I add your Tested-by: while applying the commit?
Thanks,
--
Jiri Kosina
SUSE Labs
PE=Device
>
> rdesc file is attached
>
> Thx for the effort!
Can I add your Tested-by: while applying the commit?
Thanks,
--
Jiri Kosina
SUSE Labs
romium.org>
> Signed-off-by: Nicolas Boichat <drink...@chromium.org>
Applied to for-4.17/google-hammer. Thanks,
--
Jiri Kosina
SUSE Labs
ardware output report and
> hardware raw request won't fail to set brightness, and set
> device back to NORMAL mode once this call returns.
>
> Signed-off-by: Haridhar Kalvala
> Reviewed-by: Dmitry Torokhov
> Signed-off-by: Nicolas Boichat
Applied to for-4.17/google-hammer. Thanks,
--
Jiri Kosina
SUSE Labs
m>
> Signed-off-by: Nicolas Boichat <drink...@chromium.org>
Applied to for-4.17/google-hammer.
Thanks,
--
Jiri Kosina
SUSE Labs
or-4.17/google-hammer.
Thanks,
--
Jiri Kosina
SUSE Labs
ter()'
> HID: alps: Fix some style in 't4_read_write_register()'
>
> drivers/hid/hid-alps.c | 27 ++-
> 1 file changed, 22 insertions(+), 5 deletions(-)
Masaki-san,
do you have any comments to Christophe's patchset please?
Thanks,
--
Jiri Kosina
SUSE Labs
ter()'
> HID: alps: Fix some style in 't4_read_write_register()'
>
> drivers/hid/hid-alps.c | 27 ++-
> 1 file changed, 22 insertions(+), 5 deletions(-)
Masaki-san,
do you have any comments to Christophe's patchset please?
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 27 Mar 2018, Stephen Rothwell wrote:
> Jiri, you could drop (or revert) the commit in your tree.
Dropped. Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 27 Mar 2018, Stephen Rothwell wrote:
> Jiri, you could drop (or revert) the commit in your tree.
Dropped. Thanks,
--
Jiri Kosina
SUSE Labs
nups I realized while trying to merge hid-multitouch
> into hid-core, so that other drivers could reuse the hid-mt logic (but it's
> not that easy I must confess).
I've split this into two logical sets, and applied. Thanks!
--
Jiri Kosina
SUSE Labs
nups I realized while trying to merge hid-multitouch
> into hid-core, so that other drivers could reuse the hid-mt logic (but it's
> not that easy I must confess).
I've split this into two logical sets, and applied. Thanks!
--
Jiri Kosina
SUSE Labs
go through the slow path and
pessimistically assume that audit is enabled and has reasonable ruleset
loaded", I have my own (different) opinion of what is too ugly.
Thanks,
--
Jiri Kosina
SUSE Labs
go through the slow path and
pessimistically assume that audit is enabled and has reasonable ruleset
loaded", I have my own (different) opinion of what is too ugly.
Thanks,
--
Jiri Kosina
SUSE Labs
ay due to scheduling.
Paul, what do you think?
Thanks,
--
Jiri Kosina
SUSE Labs
ay due to scheduling.
Paul, what do you think?
Thanks,
--
Jiri Kosina
SUSE Labs
On Fri, 2 Mar 2018, Aishwarya Pant wrote:
> Add sysfs documentation for N-Trig touchscreens under Documentation/ABI.
> Descriptions have been collected from code comments.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
On Fri, 2 Mar 2018, Aishwarya Pant wrote:
> Add sysfs documentation for N-Trig touchscreens under Documentation/ABI.
> Descriptions have been collected from code comments.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
BI
breakage, but those will not be picked up by stable I guess, and you
probably don't care either.
--
Jiri Kosina
SUSE Labs
BI
breakage, but those will not be picked up by stable I guess, and you
probably don't care either.
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina <jkos...@suse.cz>
There is no point going through all the audit slow path syscall entry/exit
in case the audit daemon is running, but hasn't populated the audit filter
with any rules whatsoever.
Only set TIF_AUDIT_SYSCALL in case the number of populated audit rules i
From: Jiri Kosina
There is no point going through all the audit slow path syscall entry/exit
in case the audit daemon is running, but hasn't populated the audit filter
with any rules whatsoever.
Only set TIF_AUDIT_SYSCALL in case the number of populated audit rules is
non-zero.
Originally
ur mailbox. I still think
> it's valuable.
> IIRC it should still apply on your tree, but if not, I can quickly
> update the patch.
Ah, thanks for a friendly ping! This really slipped in between cracks.
Applied now.
--
Jiri Kosina
SUSE Labs
luable.
> IIRC it should still apply on your tree, but if not, I can quickly
> update the patch.
Ah, thanks for a friendly ping! This really slipped in between cracks.
Applied now.
--
Jiri Kosina
SUSE Labs
id-multitouch variant of it as well) to
for-4.17/upstream.
--
Jiri Kosina
SUSE Labs
t of it as well) to
for-4.17/upstream.
--
Jiri Kosina
SUSE Labs
On Fri, 2 Mar 2018, Aishwarya Pant wrote:
> Descriptions have been collected from git commit logs.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
On Fri, 2 Mar 2018, Aishwarya Pant wrote:
> Descriptions have been collected from git commit logs.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
I have applied both patches to for-4.17/elecom.
Thanks,
--
Jiri Kosina
SUSE Labs
I have applied both patches to for-4.17/elecom.
Thanks,
--
Jiri Kosina
SUSE Labs
eam-fixes.
--
Jiri Kosina
SUSE Labs
eam-fixes.
--
Jiri Kosina
SUSE Labs
ing 127 bytes from a string of length 127
> [-Wstringop-truncation]
>
> The compiler require that the input param 'len' of strncpy() should be
> greater than the length of the src string, so that '\0' is copied as
> well. We can just use strlcpy() to avoid this warning.
Applied to for-4.17/upstream.
--
Jiri Kosina
SUSE Labs
gth 127
> [-Wstringop-truncation]
>
> The compiler require that the input param 'len' of strncpy() should be
> greater than the length of the src string, so that '\0' is copied as
> well. We can just use strlcpy() to avoid this warning.
Applied to for-4.17/upstream.
--
Jiri Kosina
SUSE Labs
_64)
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Applied to for-4.17/upstream.
--
Jiri Kosina
SUSE Labs
y: Colin Ian King
Applied to for-4.17/upstream.
--
Jiri Kosina
SUSE Labs
On Sat, 3 Feb 2018, Aaron Ma wrote:
> Could anyone review and apply these 2 patch?
I have applied all 3 patches to for-4.16/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
On Sat, 3 Feb 2018, Aaron Ma wrote:
> Could anyone review and apply these 2 patch?
I have applied all 3 patches to for-4.16/upstream-fixes. Thanks,
--
Jiri Kosina
SUSE Labs
On Sat, 10 Feb 2018, Guus Sliepen wrote:
> This mouse sold by Corsair as the GLAIVE RGB gaming mouse has the same
> problem with its HID reports as the Scimitar PRO RGB, so reuse the
> same fix for the GLAIVE RGB.
Applied to for-4.16/upstream-fixes.
--
Jiri Kosina
SUSE Labs
On Sat, 10 Feb 2018, Guus Sliepen wrote:
> This mouse sold by Corsair as the GLAIVE RGB gaming mouse has the same
> problem with its HID reports as the Scimitar PRO RGB, so reuse the
> same fix for the GLAIVE RGB.
Applied to for-4.16/upstream-fixes.
--
Jiri Kosina
SUSE Labs
+
> drivers/hid/hid-quirks.c | 3 +
> 5 files changed, 434 insertions(+)
> create mode 100644 drivers/hid/hid-elan.c
Applied to for-4.17/hid-elan. Thanks,
--
Jiri Kosina
SUSE Labs
id-quirks.c | 3 +
> 5 files changed, 434 insertions(+)
> create mode 100644 drivers/hid/hid-elan.c
Applied to for-4.17/hid-elan. Thanks,
--
Jiri Kosina
SUSE Labs
HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE)
events
HID: wacom: Add support for One by Wacom (CTL-472 / CTL-672)
Jiri Kosina (1):
HID: elo: clear BTN_LEFT mapping
Niels Skou Olsen (2):
HID: Ignore Jabra HID interface based on firmware version
HID: Add
HID: wacom: Fix reporting of touch toggle (WACOM_HID_WD_MUTE_DEVICE)
events
HID: wacom: Add support for One by Wacom (CTL-472 / CTL-672)
Jiri Kosina (1):
HID: elo: clear BTN_LEFT mapping
Niels Skou Olsen (2):
HID: Ignore Jabra HID interface based on firmware version
HID: Add
---
13 files changed, 227 insertions(+), 187 deletions(-)
--
Jiri Kosina
SUSE Labs
---
13 files changed, 227 insertions(+), 187 deletions(-)
--
Jiri Kosina
SUSE Labs
On Fri, 26 Jan 2018, Jiri Kosina wrote:
> > diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
> > index 34f053a150a9..091f53fe31cc 100644
> > --- a/include/linux/thread_info.h
> > +++ b/include/linux/thread_info.h
> > @@ -43,7 +43,9 @@ en
On Fri, 26 Jan 2018, Jiri Kosina wrote:
> > diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
> > index 34f053a150a9..091f53fe31cc 100644
> > --- a/include/linux/thread_info.h
> > +++ b/include/linux/thread_info.h
> > @@ -43,7 +43,9 @@ en
from reused stack. */
> memset(s->addr, 0, THREAD_SIZE);
> #endif
Is there any good reason not to do it symmetricaly also for non-vmapped
stacks? (by passing __GFP_ZERO to alloc_pages_node())?
Thanks,
--
Jiri Kosina
SUSE Labs
from reused stack. */
> memset(s->addr, 0, THREAD_SIZE);
> #endif
Is there any good reason not to do it symmetricaly also for non-vmapped
stacks? (by passing __GFP_ZERO to alloc_pages_node())?
Thanks,
--
Jiri Kosina
SUSE Labs
this
relevant to ABI?
Thanks,
--
Jiri Kosina
SUSE Labs
this
relevant to ABI?
Thanks,
--
Jiri Kosina
SUSE Labs
reak loading of externally-built modules just
because they might contain indirect calls.
Warning in such situations / tainting the kernel / reporting "might be
vulnerable" in sysfs should be the proper way to go.
retpolines are not kernel ABI (towards modules) breaker, so let's not
pretend it is.
Thanks,
--
Jiri Kosina
SUSE Labs
reak loading of externally-built modules just
because they might contain indirect calls.
Warning in such situations / tainting the kernel / reporting "might be
vulnerable" in sysfs should be the proper way to go.
retpolines are not kernel ABI (towards modules) breaker, so let's not
pretend it is.
Thanks,
--
Jiri Kosina
SUSE Labs
ch and every one
fail to load.
Thanks,
--
Jiri Kosina
SUSE Labs
ch and every one
fail to load.
Thanks,
--
Jiri Kosina
SUSE Labs
Linus' tree
> > instead of that?
>
> Greg prefered using modversions
Ah. OK, Greg: I'll eat my hat (I've heard that's very popular these times)
if there is a major enterprise distro that doesn't revert this patch
immediately.
--
Jiri Kosina
SUSE Labs
Linus' tree
> > instead of that?
>
> Greg prefered using modversions
Ah. OK, Greg: I'll eat my hat (I've heard that's very popular these times)
if there is a major enterprise distro that doesn't revert this patch
immediately.
--
Jiri Kosina
SUSE Labs
out, Andi. I've been just now writing more or
less the same thing; ditching that and will reuse your patch instead.
Why was the more aggresive version (6cfb521ac0d5b) merged into Linus' tree
instead of that?
Thanks,
--
Jiri Kosina
SUSE Labs
out, Andi. I've been just now writing more or
less the same thing; ditching that and will reuse your patch instead.
Why was the more aggresive version (6cfb521ac0d5b) merged into Linus' tree
instead of that?
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 23 Jan 2018, Jiri Kosina wrote:
> So that vermagic patch doesn't really help anything in real world (FWIW
> I've just dropped it from SLE kernel). "Potentially insecure" doesn't mean
> it shouldn't be loaded if the user wishes so. Only "functionally
> inco
On Tue, 23 Jan 2018, Jiri Kosina wrote:
> So that vermagic patch doesn't really help anything in real world (FWIW
> I've just dropped it from SLE kernel). "Potentially insecure" doesn't mean
> it shouldn't be loaded if the user wishes so. Only "functionally
> inco
oesn't mean
it shouldn't be loaded if the user wishes so. Only "functionally
incorrect" (which is the kernel ABI compatibility check) should be the
show stopper.
--
Jiri Kosina
SUSE Labs
oesn't mean
it shouldn't be loaded if the user wishes so. Only "functionally
incorrect" (which is the kernel ABI compatibility check) should be the
show stopper.
--
Jiri Kosina
SUSE Labs
On Wed, 20 Dec 2017, Srinivas Pandruvada wrote:
> Added PCI ID for Cannon Lake and Coffee Lake laptop/desktop skews.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruv...@linux.intel.com>
Applied to for-4.16/hid-quirks-cleanup/ish. Thanks,
--
Jiri Kosina
SUSE Labs
On Wed, 20 Dec 2017, Srinivas Pandruvada wrote:
> Added PCI ID for Cannon Lake and Coffee Lake laptop/desktop skews.
>
> Signed-off-by: Srinivas Pandruvada
Applied to for-4.16/hid-quirks-cleanup/ish. Thanks,
--
Jiri Kosina
SUSE Labs
ot; comment for
> a more abridged yet hopefully just as informative generic version.
>
> Signed-off-by: Tomasz Kramkowski <t...@the-tk.com>
> ---
> v2 changes:
> * pass rsize directly to mouse_button_fixup
> * add support for wireless EX-G variant
> v1: https://marc.info/?i=20171204205550.2621-1...@the-tk.com
Applied, thanks.
--
Jiri Kosina
SUSE Labs
ot; comment for
> a more abridged yet hopefully just as informative generic version.
>
> Signed-off-by: Tomasz Kramkowski
> ---
> v2 changes:
> * pass rsize directly to mouse_button_fixup
> * add support for wireless EX-G variant
> v1: https://marc.info/?i=20171204205550.2621-1...@the-tk.com
Applied, thanks.
--
Jiri Kosina
SUSE Labs
On Fri, 17 Nov 2017, Andrew Duggan wrote:
> The Fujitsu R726 Pad has an optional USB keyboard dock which contains
> a Synaptics touchpad. The dock identifies itself as a
> Primax Rezel Tablet Keyboard.
>
> Signed-off-by: Andrew Duggan <adug...@synaptics.com>
Applied, tha
901 - 1000 of 6650 matches
Mail list logo
