This is a note to let you know that I've just added the patch titled
iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Nate Watterson <nwatters(a)codeaurora.org>
Date: Fri, 7 Apr 2017 01:36:20 -0400
Subject: iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range
From: Nate Watterson <nwatters(a)codeaurora.org>
[ Upstream commit 5016bdb796b3726eec043ca0ce3be981f712c756 ]
Normally, calling alloc_iova() using an iova_domain with insufficient
pfns remaining between start_pfn and dma_limit will fail and return a
NULL pointer. Unexpectedly, if such a "full" iova_domain contains an
iova with pfn_lo == 0, the alloc_iova() call will instead succeed and
return an iova containing invalid pfns.
This is caused by an underflow bug in __alloc_and_insert_iova_range()
that occurs after walking the "full" iova tree when the search ends
at the iova with pfn_lo == 0 and limit_pfn is then adjusted to be just
below that (-1). This (now huge) limit_pfn gives the impression that a
vast amount of space is available between it and start_pfn and thus
a new iova is allocated with the invalid pfn_hi value, 0xFFF.... .
To rememdy this, a check is introduced to ensure that adjustments to
limit_pfn will not underflow.
This issue has been observed in the wild, and is easily reproduced with
the following sample code.
struct iova_domain *iovad = kzalloc(sizeof(*iovad), GFP_KERNEL);
struct iova *rsvd_iova, *good_iova, *bad_iova;
unsigned long limit_pfn = 3;
unsigned long start_pfn = 1;
unsigned long va_size = 2;
init_iova_domain(iovad, SZ_4K, start_pfn, limit_pfn);
rsvd_iova = reserve_iova(iovad, 0, 0);
good_iova = alloc_iova(iovad, va_size, limit_pfn, true);
bad_iova = alloc_iova(iovad, va_size, limit_pfn, true);
Prior to the patch, this yielded:
*rsvd_iova == {0, 0} /* Expected */
*good_iova == {2, 3} /* Expected */
*bad_iova == {-2, -1} /* Oh no... */
After the patch, bad_iova is NULL as expected since inadequate
space remains between limit_pfn and start_pfn after allocating
good_iova.
Signed-off-by: Nate Watterson <nwatters(a)codeaurora.org>
Signed-off-by: Joerg Roedel <jroedel(a)suse.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iommu/iova.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -126,7 +126,7 @@ static int __alloc_and_insert_iova_range
break; /* found a free slot */
}
adjust_limit_pfn:
- limit_pfn = curr_iova->pfn_lo - 1;
+ limit_pfn = curr_iova->pfn_lo ? (curr_iova->pfn_lo - 1) : 0;
move_left:
prev = curr;
curr = rb_prev(curr);
Patches currently in stable-queue which might be from nwatters(a)codeaurora.org are
queue-4.4/iommu-iova-fix-underflow-bug-in-__alloc_and_insert_iova_range.patch
This is a note to let you know that I've just added the patch titled
Input: tsc2007 - check for presence and power down tsc2007 during probe
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-tsc2007-check-for-presence-and-power-down-tsc2007-during-probe.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:11 CET 2018
From: "H. Nikolaus Schaller" <hns(a)goldelico.com>
Date: Fri, 17 Feb 2017 12:51:19 -0800
Subject: Input: tsc2007 - check for presence and power down tsc2007 during probe
From: "H. Nikolaus Schaller" <hns(a)goldelico.com>
[ Upstream commit 934df23171e7c5b71d937104d4957891c39748ff ]
1. check if chip is really present and don't succeed if it isn't.
2. if it succeeds, power down the chip until accessed
Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/touchscreen/tsc2007.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -455,6 +455,14 @@ static int tsc2007_probe(struct i2c_clie
tsc2007_stop(ts);
+ /* power down the chip (TSC2007_SETUP does not ACK on I2C) */
+ err = tsc2007_xfer(ts, PWRDOWN);
+ if (err < 0) {
+ dev_err(&client->dev,
+ "Failed to setup chip: %d\n", err);
+ return err; /* usually, chip does not respond */
+ }
+
err = input_register_device(input_dev);
if (err) {
dev_err(&client->dev,
Patches currently in stable-queue which might be from hns(a)goldelico.com are
queue-4.4/input-tsc2007-check-for-presence-and-power-down-tsc2007-during-probe.patch
This is a note to let you know that I've just added the patch titled
ima: relax requiring a file signature for new files with zero length
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Date: Wed, 8 Nov 2017 07:38:28 -0500
Subject: ima: relax requiring a file signature for new files with zero length
From: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
[ Upstream commit b7e27bc1d42e8e0cc58b602b529c25cd0071b336 ]
Custom policies can require file signatures based on LSM labels. These
files are normally created and only afterwards labeled, requiring them
to be signed.
Instead of requiring file signatures based on LSM labels, entire
filesystems could require file signatures. In this case, we need the
ability of writing new files without requiring file signatures.
The definition of a "new" file was originally defined as any file with
a length of zero. Subsequent patches redefined a "new" file to be based
on the FILE_CREATE open flag. By combining the open flag with a file
size of zero, this patch relaxes the file signature requirement.
Fixes: 1ac202e978e1 ima: accept previously set IMA_NEW_FILE
Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
security/integrity/ima/ima_appraise.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -206,7 +206,8 @@ int ima_appraise_measurement(int func, s
if (opened & FILE_CREATED)
iint->flags |= IMA_NEW_FILE;
if ((iint->flags & IMA_NEW_FILE) &&
- !(iint->flags & IMA_DIGSIG_REQUIRED))
+ (!(iint->flags & IMA_DIGSIG_REQUIRED) ||
+ (inode->i_size == 0)))
status = INTEGRITY_PASS;
goto out;
}
Patches currently in stable-queue which might be from zohar(a)linux.vnet.ibm.com are
queue-4.4/ima-relax-requiring-a-file-signature-for-new-files-with-zero-length.patch
This is a note to let you know that I've just added the patch titled
Input: qt1070 - add OF device ID table
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
input-qt1070-add-of-device-id-table.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
Date: Thu, 23 Mar 2017 13:33:12 -0700
Subject: Input: qt1070 - add OF device ID table
From: Javier Martinez Canillas <javier(a)osg.samsung.com>
[ Upstream commit cf5cd9d4480a87da78768718cac194a71079b5cb ]
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
The compatible strings don't have a vendor prefix because that's how it's
used currently, and changing this will be a Device Tree ABI break.
Signed-off-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/input/keyboard/qt1070.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/input/keyboard/qt1070.c
+++ b/drivers/input/keyboard/qt1070.c
@@ -274,9 +274,18 @@ static const struct i2c_device_id qt1070
};
MODULE_DEVICE_TABLE(i2c, qt1070_id);
+#ifdef CONFIG_OF
+static const struct of_device_id qt1070_of_match[] = {
+ { .compatible = "qt1070", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, qt1070_of_match);
+#endif
+
static struct i2c_driver qt1070_driver = {
.driver = {
.name = "qt1070",
+ .of_match_table = of_match_ptr(qt1070_of_match),
.pm = &qt1070_pm_ops,
},
.id_table = qt1070_id,
Patches currently in stable-queue which might be from javier(a)osg.samsung.com are
queue-4.4/input-qt1070-add-of-device-id-table.patch
This is a note to let you know that I've just added the patch titled
i40e: fix ethtool to get EEPROM data from X722 interface
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-fix-ethtool-to-get-eeprom-data-from-x722-interface.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Lihong Yang <lihong.yang(a)intel.com>
Date: Mon, 30 Jan 2017 12:29:32 -0800
Subject: i40e: fix ethtool to get EEPROM data from X722 interface
From: Lihong Yang <lihong.yang(a)intel.com>
[ Upstream commit c271dd6c391b535226cf1a81aaad9f33cb5899d3 ]
Currently ethtool -e will error out with a X722 interface
as its EEPROM has a scope limit at offset 0x5B9FFF.
This patch fixes the issue by setting the EEPROM length to
the scope limit to avoid NVM read failure beyond that.
Change-ID: I0b7d4dd6c7f2a57cace438af5dffa0f44c229372
Signed-off-by: Lihong Yang <lihong.yang(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1073,6 +1073,11 @@ static int i40e_get_eeprom_len(struct ne
struct i40e_hw *hw = &np->vsi->back->hw;
u32 val;
+#define X722_EEPROM_SCOPE_LIMIT 0x5B9FFF
+ if (hw->mac.type == I40E_MAC_X722) {
+ val = X722_EEPROM_SCOPE_LIMIT + 1;
+ return val;
+ }
val = (rd32(hw, I40E_GLPCI_LBARCTRL)
& I40E_GLPCI_LBARCTRL_FL_SIZE_MASK)
>> I40E_GLPCI_LBARCTRL_FL_SIZE_SHIFT;
Patches currently in stable-queue which might be from lihong.yang(a)intel.com are
queue-4.4/i40e-fix-ethtool-to-get-eeprom-data-from-x722-interface.patch
This is a note to let you know that I've just added the patch titled
HID: reject input outside logical range only if null state is set
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: "Valtteri Heikkilä" <rnd(a)nic.fi>
Date: Tue, 14 Feb 2017 23:14:32 +0000
Subject: HID: reject input outside logical range only if null state is set
From: "Valtteri Heikkilä" <rnd(a)nic.fi>
[ Upstream commit 3f3752705dbd50b66b66ad7b4d54fe33d2f746ed ]
This patch fixes an issue in drivers/hid/hid-input.c where USB HID
control null state flag is not checked upon rejecting inputs outside
logical minimum-maximum range. The check should be made according to USB
HID specification 1.11, section 6.2.2.5, p.31. The fix will resolve
issues with some game controllers, such as:
https://bugzilla.kernel.org/show_bug.cgi?id=68621
[tk(a)the-tk.com: shortened and fixed spelling in commit message]
Signed-off-by: Valtteri Heikkilä <rnd(a)nic.fi>
Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com>
Acked-By: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-input.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1135,6 +1135,7 @@ void hidinput_hid_event(struct hid_devic
* don't specify logical min and max.
*/
if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
+ (field->flags & HID_MAIN_ITEM_NULL_STATE) &&
(field->logical_minimum < field->logical_maximum) &&
(value < field->logical_minimum ||
value > field->logical_maximum)) {
Patches currently in stable-queue which might be from rnd(a)nic.fi are
queue-4.4/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
This is a note to let you know that I've just added the patch titled
i40e: Acquire NVM lock before reads on all devices
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40e-acquire-nvm-lock-before-reads-on-all-devices.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Aaron Salter <aaron.k.salter(a)intel.com>
Date: Fri, 2 Dec 2016 12:33:02 -0800
Subject: i40e: Acquire NVM lock before reads on all devices
From: Aaron Salter <aaron.k.salter(a)intel.com>
[ Upstream commit 96a39aed25e6559b160786117df124084feb9080 ]
Acquire NVM lock before reads on all devices. Previously, locks were
only used for X722 and later. Fixes an issue where simultaneous X710
NVM accesses were interfering with each other.
Change-ID: If570bb7acf958cef58725ec2a2011cead6f80638
Signed-off-by: Aaron Salter <aaron.k.salter(a)intel.com>
Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/intel/i40e/i40e_nvm.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_nvm.c
@@ -292,14 +292,14 @@ i40e_status i40e_read_nvm_word(struct i4
{
enum i40e_status_code ret_code = 0;
- if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) {
- ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
- if (!ret_code) {
+ ret_code = i40e_acquire_nvm(hw, I40E_RESOURCE_READ);
+ if (!ret_code) {
+ if (hw->flags & I40E_HW_FLAG_AQ_SRCTL_ACCESS_ENABLE) {
ret_code = i40e_read_nvm_word_aq(hw, offset, data);
- i40e_release_nvm(hw);
+ } else {
+ ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
}
- } else {
- ret_code = i40e_read_nvm_word_srctl(hw, offset, data);
+ i40e_release_nvm(hw);
}
return ret_code;
}
Patches currently in stable-queue which might be from aaron.k.salter(a)intel.com are
queue-4.4/i40e-acquire-nvm-lock-before-reads-on-all-devices.patch
This is a note to let you know that I've just added the patch titled
HID: clamp input to logical range if no null state
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-clamp-input-to-logical-range-if-no-null-state.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Tomasz Kramkowski <tk(a)the-tk.com>
Date: Tue, 14 Mar 2017 13:29:13 +0000
Subject: HID: clamp input to logical range if no null state
From: Tomasz Kramkowski <tk(a)the-tk.com>
[ Upstream commit c3883fe06488a483658ba5d849b70e49bee15e7c ]
This patch fixes an issue in drivers/hid/hid-input.c where values
outside of the logical range are not clamped when "null state" bit of
the input control is not set.
This was discussed on the lists [1] and this change stems from the fact
due to the ambiguity of the HID specification it might be appropriate to
follow Microsoft's own interpretation of the specification. As noted in
Microsoft's documentation [2] in the section titled "Required HID usages
for digitizers" it is noted that values reported outside the logical
range "will be considered as invalid data and the value will be changed
to the nearest boundary value (logical min/max)."
This patch fixes an issue where the (1292:4745) Innomedia INNEX
GENESIS/ATARI reports out of range values for its X and Y axis of the
DPad which, due to the null state bit being unset, are forwarded to
userspace as is. Now these values will get clamped to the logical range
before being forwarded to userspace. This device was also used to test
this patch.
This patch expands on commit 3f3752705dbd ("HID: reject input outside
logical range only if null state is set").
[1]: http://lkml.kernel.org/r/20170307131036.GA853@gaia.local
[2]: https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)…
Signed-off-by: Tomasz Kramkowski <tk(a)the-tk.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-input.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1128,19 +1128,26 @@ void hidinput_hid_event(struct hid_devic
/*
* Ignore out-of-range values as per HID specification,
- * section 5.10 and 6.2.25.
+ * section 5.10 and 6.2.25, when NULL state bit is present.
+ * When it's not, clamp the value to match Microsoft's input
+ * driver as mentioned in "Required HID usages for digitizers":
+ * https://msdn.microsoft.com/en-us/library/windows/hardware/dn672278(v=vs.85)…
*
* The logical_minimum < logical_maximum check is done so that we
* don't unintentionally discard values sent by devices which
* don't specify logical min and max.
*/
if ((field->flags & HID_MAIN_ITEM_VARIABLE) &&
- (field->flags & HID_MAIN_ITEM_NULL_STATE) &&
- (field->logical_minimum < field->logical_maximum) &&
- (value < field->logical_minimum ||
- value > field->logical_maximum)) {
- dbg_hid("Ignoring out-of-range value %x\n", value);
- return;
+ (field->logical_minimum < field->logical_maximum)) {
+ if (field->flags & HID_MAIN_ITEM_NULL_STATE &&
+ (value < field->logical_minimum ||
+ value > field->logical_maximum)) {
+ dbg_hid("Ignoring out-of-range value %x\n", value);
+ return;
+ }
+ value = clamp(value,
+ field->logical_minimum,
+ field->logical_maximum);
}
/*
Patches currently in stable-queue which might be from tk(a)the-tk.com are
queue-4.4/hid-clamp-input-to-logical-range-if-no-null-state.patch
queue-4.4/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
This is a note to let you know that I've just added the patch titled
HID: elo: clear BTN_LEFT mapping
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-elo-clear-btn_left-mapping.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Jiri Kosina <jkosina(a)suse.cz>
Date: Wed, 22 Nov 2017 11:19:51 +0100
Subject: HID: elo: clear BTN_LEFT mapping
From: Jiri Kosina <jkosina(a)suse.cz>
[ Upstream commit 9abd04af951e5734c9d5cfee9b49790844b734cf ]
ELO devices have one Button usage in GenDesk field, which makes hid-input map
it to BTN_LEFT; that confuses userspace, which then considers the device to be
a mouse/touchpad instead of touchscreen.
Fix that by unmapping BTN_LEFT and keeping only BTN_TOUCH in place.
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/hid-elo.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/hid/hid-elo.c
+++ b/drivers/hid/hid-elo.c
@@ -42,6 +42,12 @@ static int elo_input_configured(struct h
{
struct input_dev *input = hidinput->input;
+ /*
+ * ELO devices have one Button usage in GenDesk field, which makes
+ * hid-input map it to BTN_LEFT; that confuses userspace, which then
+ * considers the device to be a mouse/touchpad instead of touchscreen.
+ */
+ clear_bit(BTN_LEFT, input->keybit);
set_bit(BTN_TOUCH, input->keybit);
set_bit(ABS_PRESSURE, input->absbit);
input_set_abs_params(input, ABS_PRESSURE, 0, 256, 0, 0);
Patches currently in stable-queue which might be from jkosina(a)suse.cz are
queue-4.4/hid-elo-clear-btn_left-mapping.patch
queue-4.4/hid-clamp-input-to-logical-range-if-no-null-state.patch
queue-4.4/hid-reject-input-outside-logical-range-only-if-null-state-is-set.patch
This is a note to let you know that I've just added the patch titled
f2fs: relax node version check for victim data in gc
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
f2fs-relax-node-version-check-for-victim-data-in-gc.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Mar 19 09:58:12 CET 2018
From: Jaegeuk Kim <jaegeuk(a)kernel.org>
Date: Tue, 21 Mar 2017 10:59:50 -0400
Subject: f2fs: relax node version check for victim data in gc
From: Jaegeuk Kim <jaegeuk(a)kernel.org>
[ Upstream commit c13ff37e359bb3eacf4e1760dcea8d9760aa7459 ]
- has_not_enough_free_secs
node_secs: 0 dent_secs: 0 freed:0 free_segments:103 reserved:104
- f2fs_gc
- get_victim_by_default
alloc_mode 0, gc_mode 1, max_search 2672, offset 4654, ofs_unit 1
- do_garbage_collect
start_segno 3976, end_segno 3977 type 0
- is_alive
nid 22797, blkaddr 2131882, ofs_in_node 0, version 0x8/0x0
- gc_data_segment 766, segno 3976, block 512/426 not alive
So, this patch fixes subtle corrupted case where node version does not match
to summary version which results in infinite loop by gc.
Reported-by: Yunlei He <heyunlei(a)huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/f2fs/gc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -522,8 +522,10 @@ static bool is_alive(struct f2fs_sb_info
get_node_info(sbi, nid, dni);
if (sum->version != dni->version) {
- f2fs_put_page(node_page, 1);
- return false;
+ f2fs_msg(sbi->sb, KERN_WARNING,
+ "%s: valid data with mismatched node version.",
+ __func__);
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
}
*nofs = ofs_of_node(node_page);
Patches currently in stable-queue which might be from jaegeuk(a)kernel.org are
queue-4.4/f2fs-relax-node-version-check-for-victim-data-in-gc.patch