* Re: [PATCH v2] Fix strange behavior of touchpad on Clevo NS70PU
From: Werner Sembach @ 2024-02-02 14:26 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20231205163602.16106-1-wse@tuxedocomputers.com>
gentle bump
Am 05.12.23 um 17:36 schrieb Werner Sembach:
> When closing the laptop lid with an external screen connected, the mouse
> pointer has a constant movement to the lower right corner. Opening the
> lid again stops this movement, but after that the touchpad does no longer
> register clicks.
>
> The touchpad is connected both via i2c-hid and PS/2, the predecessor of
> this device (NS70MU) has the same layout in this regard and also strange
> behaviour caused by the psmouse and the i2c-hid driver fighting over
> touchpad control. This fix is reusing the same workaround by just
> disabling the PS/2 aux port, that is only used by the touchpad, to give the
> i2c-hid driver the lone control over the touchpad.
>
> v2: Rebased on current master
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/input/serio/i8042-acpipnpio.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/serio/i8042-acpipnpio.h b/drivers/input/serio/i8042-acpipnpio.h
> index 9c39553d30fa2..b31d3285bea69 100644
> --- a/drivers/input/serio/i8042-acpipnpio.h
> +++ b/drivers/input/serio/i8042-acpipnpio.h
> @@ -1200,6 +1200,12 @@ static const struct dmi_system_id i8042_dmi_quirk_table[] __initconst = {
> SERIO_QUIRK_RESET_ALWAYS | SERIO_QUIRK_NOLOOP |
> SERIO_QUIRK_NOPNP)
> },
> + {
> + .matches = {
> + DMI_MATCH(DMI_BOARD_NAME, "NS5x_7xPU"),
> + },
> + .driver_data = (void *)(SERIO_QUIRK_NOAUX)
> + },
> {
> .matches = {
> DMI_MATCH(DMI_BOARD_NAME, "NJ50_70CU"),
^ permalink raw reply
* Re: [PATCH v2] Fix strange behavior of touchpad on Clevo NS70PU
From: Dmitry Torokhov @ 2024-02-02 18:22 UTC (permalink / raw)
To: Werner Sembach; +Cc: linux-input, linux-kernel
In-Reply-To: <20231205163602.16106-1-wse@tuxedocomputers.com>
On Tue, Dec 05, 2023 at 05:36:01PM +0100, Werner Sembach wrote:
> When closing the laptop lid with an external screen connected, the mouse
> pointer has a constant movement to the lower right corner. Opening the
> lid again stops this movement, but after that the touchpad does no longer
> register clicks.
>
> The touchpad is connected both via i2c-hid and PS/2, the predecessor of
> this device (NS70MU) has the same layout in this regard and also strange
> behaviour caused by the psmouse and the i2c-hid driver fighting over
> touchpad control. This fix is reusing the same workaround by just
> disabling the PS/2 aux port, that is only used by the touchpad, to give the
> i2c-hid driver the lone control over the touchpad.
>
> v2: Rebased on current master
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Cc: stable@vger.kernel.org
Applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH AUTOSEL 6.7 23/23] platform/x86: touchscreen_dmi: Add info for the TECLAST X16 Plus tablet
From: Sasha Levin @ 2024-02-02 18:39 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phoenix Chen, Hans de Goede, Sasha Levin, ilpo.jarvinen,
linux-input, platform-driver-x86
In-Reply-To: <20240202183926.540467-1-sashal@kernel.org>
From: Phoenix Chen <asbeltogf@gmail.com>
[ Upstream commit 1abdf288b0ef5606f76b6e191fa6df05330e3d7e ]
Add touch screen info for TECLAST X16 Plus tablet.
Signed-off-by: Phoenix Chen <asbeltogf@gmail.com>
Link: https://lore.kernel.org/r/20240126095308.5042-1-asbeltogf@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/platform/x86/touchscreen_dmi.c | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index 0c6733772698..7aee5e9ff2b8 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -944,6 +944,32 @@ static const struct ts_dmi_data teclast_tbook11_data = {
.properties = teclast_tbook11_props,
};
+static const struct property_entry teclast_x16_plus_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 8),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 14),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1916),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1264),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl3692-teclast-x16-plus.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("silead,home-button"),
+ { }
+};
+
+static const struct ts_dmi_data teclast_x16_plus_data = {
+ .embedded_fw = {
+ .name = "silead/gsl3692-teclast-x16-plus.fw",
+ .prefix = { 0xf0, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00 },
+ .length = 43560,
+ .sha256 = { 0x9d, 0xb0, 0x3d, 0xf1, 0x00, 0x3c, 0xb5, 0x25,
+ 0x62, 0x8a, 0xa0, 0x93, 0x4b, 0xe0, 0x4e, 0x75,
+ 0xd1, 0x27, 0xb1, 0x65, 0x3c, 0xba, 0xa5, 0x0f,
+ 0xcd, 0xb4, 0xbe, 0x00, 0xbb, 0xf6, 0x43, 0x29 },
+ },
+ .acpi_name = "MSSL1680:00",
+ .properties = teclast_x16_plus_props,
+};
+
static const struct property_entry teclast_x3_plus_props[] = {
PROPERTY_ENTRY_U32("touchscreen-size-x", 1980),
PROPERTY_ENTRY_U32("touchscreen-size-y", 1500),
@@ -1612,6 +1638,15 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_SKU, "E5A6_A1"),
},
},
+ {
+ /* Teclast X16 Plus */
+ .driver_data = (void *)&teclast_x16_plus_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_MATCH(DMI_PRODUCT_SKU, "D3A5_A1"),
+ },
+ },
{
/* Teclast X3 Plus */
.driver_data = (void *)&teclast_x3_plus_data,
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.6 21/21] platform/x86: touchscreen_dmi: Add info for the TECLAST X16 Plus tablet
From: Sasha Levin @ 2024-02-02 18:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phoenix Chen, Hans de Goede, Sasha Levin, ilpo.jarvinen,
linux-input, platform-driver-x86
In-Reply-To: <20240202184015.540966-1-sashal@kernel.org>
From: Phoenix Chen <asbeltogf@gmail.com>
[ Upstream commit 1abdf288b0ef5606f76b6e191fa6df05330e3d7e ]
Add touch screen info for TECLAST X16 Plus tablet.
Signed-off-by: Phoenix Chen <asbeltogf@gmail.com>
Link: https://lore.kernel.org/r/20240126095308.5042-1-asbeltogf@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/platform/x86/touchscreen_dmi.c | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index 0c6733772698..7aee5e9ff2b8 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -944,6 +944,32 @@ static const struct ts_dmi_data teclast_tbook11_data = {
.properties = teclast_tbook11_props,
};
+static const struct property_entry teclast_x16_plus_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 8),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 14),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1916),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1264),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl3692-teclast-x16-plus.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("silead,home-button"),
+ { }
+};
+
+static const struct ts_dmi_data teclast_x16_plus_data = {
+ .embedded_fw = {
+ .name = "silead/gsl3692-teclast-x16-plus.fw",
+ .prefix = { 0xf0, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00 },
+ .length = 43560,
+ .sha256 = { 0x9d, 0xb0, 0x3d, 0xf1, 0x00, 0x3c, 0xb5, 0x25,
+ 0x62, 0x8a, 0xa0, 0x93, 0x4b, 0xe0, 0x4e, 0x75,
+ 0xd1, 0x27, 0xb1, 0x65, 0x3c, 0xba, 0xa5, 0x0f,
+ 0xcd, 0xb4, 0xbe, 0x00, 0xbb, 0xf6, 0x43, 0x29 },
+ },
+ .acpi_name = "MSSL1680:00",
+ .properties = teclast_x16_plus_props,
+};
+
static const struct property_entry teclast_x3_plus_props[] = {
PROPERTY_ENTRY_U32("touchscreen-size-x", 1980),
PROPERTY_ENTRY_U32("touchscreen-size-y", 1500),
@@ -1612,6 +1638,15 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_SKU, "E5A6_A1"),
},
},
+ {
+ /* Teclast X16 Plus */
+ .driver_data = (void *)&teclast_x16_plus_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_MATCH(DMI_PRODUCT_SKU, "D3A5_A1"),
+ },
+ },
{
/* Teclast X3 Plus */
.driver_data = (void *)&teclast_x3_plus_data,
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.1 15/15] platform/x86: touchscreen_dmi: Add info for the TECLAST X16 Plus tablet
From: Sasha Levin @ 2024-02-02 18:40 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phoenix Chen, Hans de Goede, Sasha Levin, ilpo.jarvinen,
linux-input, platform-driver-x86
In-Reply-To: <20240202184057.541411-1-sashal@kernel.org>
From: Phoenix Chen <asbeltogf@gmail.com>
[ Upstream commit 1abdf288b0ef5606f76b6e191fa6df05330e3d7e ]
Add touch screen info for TECLAST X16 Plus tablet.
Signed-off-by: Phoenix Chen <asbeltogf@gmail.com>
Link: https://lore.kernel.org/r/20240126095308.5042-1-asbeltogf@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/platform/x86/touchscreen_dmi.c | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index 9a92d515abb9..50ec19188a20 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -913,6 +913,32 @@ static const struct ts_dmi_data teclast_tbook11_data = {
.properties = teclast_tbook11_props,
};
+static const struct property_entry teclast_x16_plus_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 8),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 14),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1916),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1264),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl3692-teclast-x16-plus.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("silead,home-button"),
+ { }
+};
+
+static const struct ts_dmi_data teclast_x16_plus_data = {
+ .embedded_fw = {
+ .name = "silead/gsl3692-teclast-x16-plus.fw",
+ .prefix = { 0xf0, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00 },
+ .length = 43560,
+ .sha256 = { 0x9d, 0xb0, 0x3d, 0xf1, 0x00, 0x3c, 0xb5, 0x25,
+ 0x62, 0x8a, 0xa0, 0x93, 0x4b, 0xe0, 0x4e, 0x75,
+ 0xd1, 0x27, 0xb1, 0x65, 0x3c, 0xba, 0xa5, 0x0f,
+ 0xcd, 0xb4, 0xbe, 0x00, 0xbb, 0xf6, 0x43, 0x29 },
+ },
+ .acpi_name = "MSSL1680:00",
+ .properties = teclast_x16_plus_props,
+};
+
static const struct property_entry teclast_x3_plus_props[] = {
PROPERTY_ENTRY_U32("touchscreen-size-x", 1980),
PROPERTY_ENTRY_U32("touchscreen-size-y", 1500),
@@ -1567,6 +1593,15 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_SKU, "E5A6_A1"),
},
},
+ {
+ /* Teclast X16 Plus */
+ .driver_data = (void *)&teclast_x16_plus_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_MATCH(DMI_PRODUCT_SKU, "D3A5_A1"),
+ },
+ },
{
/* Teclast X3 Plus */
.driver_data = (void *)&teclast_x3_plus_data,
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 5.15 11/11] platform/x86: touchscreen_dmi: Add info for the TECLAST X16 Plus tablet
From: Sasha Levin @ 2024-02-02 18:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phoenix Chen, Hans de Goede, Sasha Levin, ilpo.jarvinen,
linux-input, platform-driver-x86
In-Reply-To: <20240202184130.541736-1-sashal@kernel.org>
From: Phoenix Chen <asbeltogf@gmail.com>
[ Upstream commit 1abdf288b0ef5606f76b6e191fa6df05330e3d7e ]
Add touch screen info for TECLAST X16 Plus tablet.
Signed-off-by: Phoenix Chen <asbeltogf@gmail.com>
Link: https://lore.kernel.org/r/20240126095308.5042-1-asbeltogf@gmail.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/platform/x86/touchscreen_dmi.c | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/platform/x86/touchscreen_dmi.c b/drivers/platform/x86/touchscreen_dmi.c
index f129e29b295d..397283893f39 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -916,6 +916,32 @@ static const struct ts_dmi_data teclast_tbook11_data = {
.properties = teclast_tbook11_props,
};
+static const struct property_entry teclast_x16_plus_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 8),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 14),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1916),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 1264),
+ PROPERTY_ENTRY_BOOL("touchscreen-inverted-y"),
+ PROPERTY_ENTRY_STRING("firmware-name", "gsl3692-teclast-x16-plus.fw"),
+ PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("silead,home-button"),
+ { }
+};
+
+static const struct ts_dmi_data teclast_x16_plus_data = {
+ .embedded_fw = {
+ .name = "silead/gsl3692-teclast-x16-plus.fw",
+ .prefix = { 0xf0, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00 },
+ .length = 43560,
+ .sha256 = { 0x9d, 0xb0, 0x3d, 0xf1, 0x00, 0x3c, 0xb5, 0x25,
+ 0x62, 0x8a, 0xa0, 0x93, 0x4b, 0xe0, 0x4e, 0x75,
+ 0xd1, 0x27, 0xb1, 0x65, 0x3c, 0xba, 0xa5, 0x0f,
+ 0xcd, 0xb4, 0xbe, 0x00, 0xbb, 0xf6, 0x43, 0x29 },
+ },
+ .acpi_name = "MSSL1680:00",
+ .properties = teclast_x16_plus_props,
+};
+
static const struct property_entry teclast_x3_plus_props[] = {
PROPERTY_ENTRY_U32("touchscreen-size-x", 1980),
PROPERTY_ENTRY_U32("touchscreen-size-y", 1500),
@@ -1552,6 +1578,15 @@ const struct dmi_system_id touchscreen_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_SKU, "E5A6_A1"),
},
},
+ {
+ /* Teclast X16 Plus */
+ .driver_data = (void *)&teclast_x16_plus_data,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TECLAST"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Default string"),
+ DMI_MATCH(DMI_PRODUCT_SKU, "D3A5_A1"),
+ },
+ },
{
/* Teclast X3 Plus */
.driver_data = (void *)&teclast_x3_plus_data,
--
2.43.0
^ permalink raw reply related
* [git pull] Input updates for v6.8-rc2
From: Dmitry Torokhov @ 2024-02-02 19:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.8-rc2
to receive updates for the input subsystem. You will get:
- a fix for the fix to deal with newer laptops which get confused by the
"GET ID" command when probing for PS/2 keyboards
- a couple of tweaks to i8042 to handle Clevo NS70PU and Lifebook U728
laptops
- a change to bcm5974 to validate that the device has appropriate
endpoints
- an addition of new product ID to xpad driver to recognize Lenovo
Legion Go controllers
- a quirk to Goodix controller to deal with extra GPIO described in ACPI
tables on some devices.
Changelog:
---------
Brenton Simpson (1):
Input: xpad - add Lenovo Legion Go controllers
Hans de Goede (3):
Input: goodix - accept ACPI resources with gpio_count == 3 && gpio_int_idx == 0
Input: atkbd - skip ATKBD_CMD_SETLEDS when skipping ATKBD_CMD_GETID
Input: atkbd - do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID
Javier Carrasco (1):
Input: bcm5974 - check endpoint type before starting traffic
Szilard Fabian (1):
Input: i8042 - add Fujitsu Lifebook U728 to i8042 quirk table
Werner Sembach (1):
Input: i8042 - fix strange behavior of touchpad on Clevo NS70PU
Diffstat:
--------
drivers/input/joystick/xpad.c | 2 ++
drivers/input/keyboard/atkbd.c | 14 +++++++++-----
drivers/input/mouse/bcm5974.c | 20 ++++++++++++++++++++
drivers/input/serio/i8042-acpipnpio.h | 14 ++++++++++++++
drivers/input/touchscreen/goodix.c | 3 ++-
5 files changed, 47 insertions(+), 6 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v7 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: kernel test robot @ 2024-02-02 20:58 UTC (permalink / raw)
To: Kamel Bouhara, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Henrik Rydberg, linux-input, linux-kernel,
devicetree, Marco Felsch, Jeff LaBundy
Cc: oe-kbuild-all, catalin.popescu, mark.satterthwaite,
Thomas Petazzoni, Gregory Clement, bsp-development.geo,
Kamel Bouhara
In-Reply-To: <20240131141158.3350344-4-kamel.bouhara@bootlin.com>
Hi Kamel,
kernel test robot noticed the following build warnings:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus robh/for-next krzk-dt/for-next linus/master v6.8-rc2 next-20240202]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Kamel-Bouhara/dt-bindings-vendor-prefixes-Add-TouchNetix-AS/20240131-221925
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link: https://lore.kernel.org/r/20240131141158.3350344-4-kamel.bouhara%40bootlin.com
patch subject: [PATCH v7 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
config: s390-randconfig-r131-20240201 (https://download.01.org/0day-ci/archive/20240203/202402030433.2vfAa4qt-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project fdac7d0b6f74f919d319b31a0680c77f66732586)
reproduce: (https://download.01.org/0day-ci/archive/20240203/202402030433.2vfAa4qt-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202402030433.2vfAa4qt-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
>> drivers/input/touchscreen/touchnetix_axiom.c:181:18: sparse: sparse: incorrect type in assignment (different base types) @@ expected restricted __le32 [usertype] preamble @@ got unsigned int @@
drivers/input/touchscreen/touchnetix_axiom.c:181:18: sparse: expected restricted __le32 [usertype] preamble
drivers/input/touchscreen/touchnetix_axiom.c:181:18: sparse: got unsigned int
>> drivers/input/touchscreen/touchnetix_axiom.c:183:40: sparse: sparse: incorrect type in argument 2 (different base types) @@ expected unsigned int reg @@ got restricted __le32 [usertype] preamble @@
drivers/input/touchscreen/touchnetix_axiom.c:183:40: sparse: expected unsigned int reg
drivers/input/touchscreen/touchnetix_axiom.c:183:40: sparse: got restricted __le32 [usertype] preamble
vim +181 drivers/input/touchscreen/touchnetix_axiom.c
171
172 static int axiom_read(struct axiom_data *ts, u8 usage, u8 page, void *buf, u16 len)
173 {
174 struct axiom_cmd_header cmd_header;
175 __le32 preamble;
176 int ret;
177
178 cmd_header.target_address = cpu_to_le16(axiom_usage_to_target_address(ts, usage, page, 0));
179 cmd_header.length = cpu_to_le16(len | AXIOM_CMD_HEADER_READ_MASK);
180
> 181 preamble = get_unaligned_le32((u8 *)&cmd_header);
182
> 183 ret = regmap_write(ts->regmap, preamble, 0);
184 if (ret) {
185 dev_err(ts->dev, "failed to write preamble, error %d\n", ret);
186 return ret;
187 }
188
189 ret = regmap_raw_read(ts->regmap, 0, buf, len);
190 if (ret) {
191 dev_err(ts->dev, "failed to read target address %04x, error %d\n",
192 cmd_header.target_address, ret);
193 return ret;
194 }
195
196 /* Wait device's DMA operations */
197 usleep_range(AXIOM_DMA_OPS_DELAY_USEC, AXIOM_DMA_OPS_DELAY_USEC + 50);
198
199 return 0;
200 }
201
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [git pull] Input updates for v6.8-rc2
From: pr-tracker-bot @ 2024-02-02 21:00 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <Zb1HxLM3Vs9p4MiG@google.com>
The pull request you sent on Fri, 2 Feb 2024 11:51:32 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git tags/input-for-v6.8-rc2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/eab5c86d2413dd92fe94a735673141e8ee873f7a
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/3] Annotate kfuncs in .BTF_ids section
From: Manu Bretelle @ 2024-02-02 23:09 UTC (permalink / raw)
To: Daniel Xu
Cc: linux-trace-kernel, coreteam, bpf, linux-input, cgroups, netdev,
linux-stm32, linux-kselftest, linux-doc, fsverity, linux-kernel,
linux-arm-kernel, netfilter-devel, alexei.starovoitov, olsajiri,
quentin, alan.maguire, memxor, vmalik
In-Reply-To: <cover.1706491398.git.dxu@dxuuu.xyz>
On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote:
> === Description ===
>
> This is a bpf-treewide change that annotates all kfuncs as such inside
> .BTF_ids. This annotation eventually allows us to automatically generate
> kfunc prototypes from bpftool.
>
> We store this metadata inside a yet-unused flags field inside struct
> btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
>
> More details about the full chain of events are available in commit 3's
> description.
>
> The accompanying pahole and bpftool changes can be viewed
> here on these "frozen" branches [0][1].
>
> [0]: https://github.com/danobi/pahole/tree/kfunc_btf-v3-mailed
> [1]: https://github.com/danobi/linux/tree/kfunc_bpftool-mailed
I hit a similar issue to [0] on master
943b043aeecc ("selftests/bpf: Fix bench runner SIGSEGV")
when cross-compiling on x86_64 (LE) to s390x (BE).
I do have CONFIG_DEBUG_INFO_BTF enable and the issue would not trigger if
I disabled CONFIG_DEBUG_INFO_BTF (and with the fix mentioned in [0]).
What seems to happen is that `tools/resolve_btfids` is ran in the context of the
host endianess and if I printk before the WARN_ON:
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index ef380e546952..a9ed7a1a4936 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -8128,6 +8128,7 @@ int register_btf_kfunc_id_set(enum bpf_prog_type prog_type,
* WARN() for initcall registrations that do not check errors.
*/
if (!(kset->set->flags & BTF_SET8_KFUNCS)) {
+ printk("Flag 0x%08X, expected 0x%08X\n", kset->set->flags, BTF_SET8_KFUNCS);
WARN_ON(!kset->owner);
return -EINVAL;
}
the boot logs would show:
Flag 0x01000000, expected 0x00000001
The issue did not happen prior to
6f3189f38a3e ("bpf: treewide: Annotate BPF kfuncs in BTF")
has only 0 was written before.
It seems [1] will be addressing cross-compilation, but it did not fix it as is
by just applying on top of master, so probably some of the changes will also need
to be ported to `tools/include/linux/btf_ids.h`?
A hacky workaround to cross-compilation I have is to apply:
diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
index 4b8079f294f6..b706e7ab066f 100644
--- a/tools/bpf/resolve_btfids/Makefile
+++ b/tools/bpf/resolve_btfids/Makefile
@@ -22,10 +22,10 @@ HOST_OVERRIDES := AR="$(HOSTAR)" CC="$(HOSTCC)" LD="$(HOSTLD)" ARCH="$(HOSTARCH)
CROSS_COMPILE="" EXTRA_CFLAGS="$(HOSTCFLAGS)"
RM ?= rm
-HOSTCC ?= gcc
-HOSTLD ?= ld
-HOSTAR ?= ar
-CROSS_COMPILE =
+HOSTCC = $(CC)
+HOSTLD = $(LD)
+HOSTAR = $(AR)
+#CROSS_COMPILE =
OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
@@ -56,16 +56,16 @@ $(OUTPUT) $(OUTPUT)/libsubcmd $(LIBBPF_OUT):
$(SUBCMDOBJ): fixdep FORCE | $(OUTPUT)/libsubcmd
$(Q)$(MAKE) -C $(SUBCMD_SRC) OUTPUT=$(SUBCMD_OUT) \
- DESTDIR=$(SUBCMD_DESTDIR) $(HOST_OVERRIDES) prefix= subdir= \
+ DESTDIR=$(SUBCMD_DESTDIR) prefix= subdir= \
$(abspath $@) install_headers
$(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile) | $(LIBBPF_OUT)
$(Q)$(MAKE) $(submake_extras) -C $(LIBBPF_SRC) OUTPUT=$(LIBBPF_OUT) \
- DESTDIR=$(LIBBPF_DESTDIR) $(HOST_OVERRIDES) prefix= subdir= \
+ DESTDIR=$(LIBBPF_DESTDIR) prefix= subdir= \
$(abspath $@) install_headers
-LIBELF_FLAGS := $(shell $(HOSTPKG_CONFIG) libelf --cflags 2>/dev/null)
-LIBELF_LIBS := $(shell $(HOSTPKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf)
+LIBELF_FLAGS := $(shell $(PKG_CONFIG) libelf --cflags 2>/dev/null)
+LIBELF_LIBS := $(shell $(PKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf)
HOSTCFLAGS_resolve_btfids += -g \
-I$(srctree)/tools/include \
@@ -84,7 +84,7 @@ $(BINARY_IN): fixdep FORCE prepare | $(OUTPUT)
$(BINARY): $(BPFOBJ) $(SUBCMDOBJ) $(BINARY_IN)
$(call msg,LINK,$@)
- $(Q)$(HOSTCC) $(BINARY_IN) $(KBUILD_HOSTLDFLAGS) -o $@ $(BPFOBJ) $(SUBCMDOBJ) $(LIBS)
+ $(Q)$(CC) $(BINARY_IN) $(KBUILD_HOSTLDFLAGS) -o $@ $(BPFOBJ) $(SUBCMDOBJ) $(LIBS)
clean_objects := $(wildcard $(OUTPUT)/*.o \
$(OUTPUT)/.*.o.cmd \
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index a38a3001527c..5cd193c04448 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -171,7 +171,7 @@ INCLUDE_DIR := $(SCRATCH_DIR)/include
BPFOBJ := $(BUILD_DIR)/libbpf/libbpf.a
ifneq ($(CROSS_COMPILE),)
HOST_BUILD_DIR := $(BUILD_DIR)/host
-HOST_SCRATCH_DIR := $(OUTPUT)/host-tools
+HOST_SCRATCH_DIR := $(SCRATCH_DIR)
HOST_INCLUDE_DIR := $(HOST_SCRATCH_DIR)/include
else
HOST_BUILD_DIR := $(BUILD_DIR)
This causes `resolve_btfids` to be compiled in the target endianess and gets
magically run provided that the hosts has `qemu-s390x-static` and a functional
binfmt_misc [2] on the host, but having this using host architecture per [1]
is likely better.
Here are steps to reproduce the issue on Ubuntu 23.10 and assuming
danobi/vmtest [3] is installed:
XPLATFORM="s390x"
XARCH="s390"
# Set up repo for s390x
cat <<EOF >> /etc/apt/sources.list.d/s390x.list
deb [arch=s390x] http://ports.ubuntu.com/ubuntu-ports mantic main restricted
deb [arch=s390x] http://ports.ubuntu.com/ubuntu-ports mantic-updates main restricted
EOF
sudo dpkg --add-architecture s390x
apt install qemu-system-s390x qemu-user-static g{cc,++}-"${XARCH}-linux-gnu" {libelf-dev,libssl-dev,pkgconf}:s390x
KBUILD_OUTPUT_DIR="/tmp/kbuild-${XPLATFORM}"
mkdir "${KBUILD_OUTPUT_DIR}"
cat tools/testing/selftests/bpf/config{,.vm,.${XPLATFORM}} > ${KBUILD_OUTPUT_DIR}/.config
make ARCH="${XARCH}" CROSS_COMPILE="${XPLATFORM}-linux-gnu-" O="${KBUILD_OUTPUT_DIR}" -j$((4 * $(nproc))) olddefconfig
make ARCH="${XARCH}" CROSS_COMPILE="${XPLATFORM}-linux-gnu-" O="${KBUILD_OUTPUT_DIR}" -j$((4 * $(nproc))) all
# No need for a s390x ubuntu 23.10 rootfs, we only care about booting the kernel
vmtest -k "${KBUILD_OUTPUT_DIR}/arch/s390/boot/bzImage" -a s390x "uname -m" | cat
For the chroot route, see [4].
[0] https://lore.kernel.org/linux-kernel/20240201155339.2b5936be@canb.auug.org.au/T/
[1] https://lore.kernel.org/bpf/cover.1706717857.git.vmalik@redhat.com/
[2] https://en.wikipedia.org/wiki/Binfmt_misc
[3] https://github.com/danobi/vmtest
[4] https://chantra.github.io/bpfcitools/bpf-cross-compile.html
Manu
>
> === Changelog ===
>
> Changes from v3:
> * Rebase to bpf-next and add missing annotation on new kfunc
>
> Changes from v2:
> * Only WARN() for vmlinux kfuncs
>
> Changes from v1:
> * Move WARN_ON() up a call level
> * Also return error when kfunc set is not properly tagged
> * Use BTF_KFUNCS_START/END instead of flags
> * Rename BTF_SET8_KFUNC to BTF_SET8_KFUNCS
>
> Daniel Xu (3):
> bpf: btf: Support flags for BTF_SET8 sets
> bpf: btf: Add BTF_KFUNCS_START/END macro pair
> bpf: treewide: Annotate BPF kfuncs in BTF
>
> Documentation/bpf/kfuncs.rst | 8 +++----
> drivers/hid/bpf/hid_bpf_dispatch.c | 8 +++----
> fs/verity/measure.c | 4 ++--
> include/linux/btf_ids.h | 21 +++++++++++++++----
> kernel/bpf/btf.c | 8 +++++++
> kernel/bpf/cpumask.c | 4 ++--
> kernel/bpf/helpers.c | 8 +++----
> kernel/bpf/map_iter.c | 4 ++--
> kernel/cgroup/rstat.c | 4 ++--
> kernel/trace/bpf_trace.c | 8 +++----
> net/bpf/test_run.c | 8 +++----
> net/core/filter.c | 20 +++++++++---------
> net/core/xdp.c | 4 ++--
> net/ipv4/bpf_tcp_ca.c | 4 ++--
> net/ipv4/fou_bpf.c | 4 ++--
> net/ipv4/tcp_bbr.c | 4 ++--
> net/ipv4/tcp_cubic.c | 4 ++--
> net/ipv4/tcp_dctcp.c | 4 ++--
> net/netfilter/nf_conntrack_bpf.c | 4 ++--
> net/netfilter/nf_nat_bpf.c | 4 ++--
> net/xfrm/xfrm_interface_bpf.c | 4 ++--
> net/xfrm/xfrm_state_bpf.c | 4 ++--
> .../selftests/bpf/bpf_testmod/bpf_testmod.c | 8 +++----
> 23 files changed, 87 insertions(+), 66 deletions(-)
>
> --
> 2.42.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/3] Annotate kfuncs in .BTF_ids section
From: Daniel Xu @ 2024-02-03 1:34 UTC (permalink / raw)
To: Manu Bretelle
Cc: linux-trace-kernel, coreteam, bpf, linux-input, cgroups, netdev,
linux-stm32, linux-kselftest, linux-doc, fsverity, linux-kernel,
linux-arm-kernel, netfilter-devel, alexei.starovoitov, olsajiri,
quentin, alan.maguire, memxor, vmalik
In-Reply-To: <Zb12EZt0BAKOPBk/@surya>
Hi Manu,
On Fri, Feb 02, 2024 at 03:09:05PM -0800, Manu Bretelle wrote:
> On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote:
> > === Description ===
> >
> > This is a bpf-treewide change that annotates all kfuncs as such inside
> > .BTF_ids. This annotation eventually allows us to automatically generate
> > kfunc prototypes from bpftool.
> >
> > We store this metadata inside a yet-unused flags field inside struct
> > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> >
> > More details about the full chain of events are available in commit 3's
> > description.
> >
> > The accompanying pahole and bpftool changes can be viewed
> > here on these "frozen" branches [0][1].
> >
> > [0]: https://github.com/danobi/pahole/tree/kfunc_btf-v3-mailed
> > [1]: https://github.com/danobi/linux/tree/kfunc_bpftool-mailed
>
>
> I hit a similar issue to [0] on master
> 943b043aeecc ("selftests/bpf: Fix bench runner SIGSEGV")
> when cross-compiling on x86_64 (LE) to s390x (BE).
> I do have CONFIG_DEBUG_INFO_BTF enable and the issue would not trigger if
> I disabled CONFIG_DEBUG_INFO_BTF (and with the fix mentioned in [0]).
>
> What seems to happen is that `tools/resolve_btfids` is ran in the context of the
> host endianess and if I printk before the WARN_ON:
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index ef380e546952..a9ed7a1a4936 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -8128,6 +8128,7 @@ int register_btf_kfunc_id_set(enum bpf_prog_type prog_type,
> * WARN() for initcall registrations that do not check errors.
> */
> if (!(kset->set->flags & BTF_SET8_KFUNCS)) {
> + printk("Flag 0x%08X, expected 0x%08X\n", kset->set->flags, BTF_SET8_KFUNCS);
> WARN_ON(!kset->owner);
> return -EINVAL;
> }
>
> the boot logs would show:
> Flag 0x01000000, expected 0x00000001
>
> The issue did not happen prior to
> 6f3189f38a3e ("bpf: treewide: Annotate BPF kfuncs in BTF")
> has only 0 was written before.
>
> It seems [1] will be addressing cross-compilation, but it did not fix it as is
> by just applying on top of master, so probably some of the changes will also need
> to be ported to `tools/include/linux/btf_ids.h`?
>
> A hacky workaround to cross-compilation I have is to apply:
>
> diff --git a/tools/bpf/resolve_btfids/Makefile b/tools/bpf/resolve_btfids/Makefile
> index 4b8079f294f6..b706e7ab066f 100644
> --- a/tools/bpf/resolve_btfids/Makefile
> +++ b/tools/bpf/resolve_btfids/Makefile
> @@ -22,10 +22,10 @@ HOST_OVERRIDES := AR="$(HOSTAR)" CC="$(HOSTCC)" LD="$(HOSTLD)" ARCH="$(HOSTARCH)
> CROSS_COMPILE="" EXTRA_CFLAGS="$(HOSTCFLAGS)"
> RM ?= rm
> -HOSTCC ?= gcc
> -HOSTLD ?= ld
> -HOSTAR ?= ar
> -CROSS_COMPILE =
> +HOSTCC = $(CC)
> +HOSTLD = $(LD)
> +HOSTAR = $(AR)
> +#CROSS_COMPILE =
> OUTPUT ?= $(srctree)/tools/bpf/resolve_btfids/
> @@ -56,16 +56,16 @@ $(OUTPUT) $(OUTPUT)/libsubcmd $(LIBBPF_OUT):
> $(SUBCMDOBJ): fixdep FORCE | $(OUTPUT)/libsubcmd
> $(Q)$(MAKE) -C $(SUBCMD_SRC) OUTPUT=$(SUBCMD_OUT) \
> - DESTDIR=$(SUBCMD_DESTDIR) $(HOST_OVERRIDES) prefix= subdir= \
> + DESTDIR=$(SUBCMD_DESTDIR) prefix= subdir= \
> $(abspath $@) install_headers
> $(BPFOBJ): $(wildcard $(LIBBPF_SRC)/*.[ch] $(LIBBPF_SRC)/Makefile) | $(LIBBPF_OUT)
> $(Q)$(MAKE) $(submake_extras) -C $(LIBBPF_SRC) OUTPUT=$(LIBBPF_OUT) \
> - DESTDIR=$(LIBBPF_DESTDIR) $(HOST_OVERRIDES) prefix= subdir= \
> + DESTDIR=$(LIBBPF_DESTDIR) prefix= subdir= \
> $(abspath $@) install_headers
> -LIBELF_FLAGS := $(shell $(HOSTPKG_CONFIG) libelf --cflags 2>/dev/null)
> -LIBELF_LIBS := $(shell $(HOSTPKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf)
> +LIBELF_FLAGS := $(shell $(PKG_CONFIG) libelf --cflags 2>/dev/null)
> +LIBELF_LIBS := $(shell $(PKG_CONFIG) libelf --libs 2>/dev/null || echo -lelf)
> HOSTCFLAGS_resolve_btfids += -g \
> -I$(srctree)/tools/include \
> @@ -84,7 +84,7 @@ $(BINARY_IN): fixdep FORCE prepare | $(OUTPUT)
> $(BINARY): $(BPFOBJ) $(SUBCMDOBJ) $(BINARY_IN)
> $(call msg,LINK,$@)
> - $(Q)$(HOSTCC) $(BINARY_IN) $(KBUILD_HOSTLDFLAGS) -o $@ $(BPFOBJ) $(SUBCMDOBJ) $(LIBS)
> + $(Q)$(CC) $(BINARY_IN) $(KBUILD_HOSTLDFLAGS) -o $@ $(BPFOBJ) $(SUBCMDOBJ) $(LIBS)
> clean_objects := $(wildcard $(OUTPUT)/*.o \
> $(OUTPUT)/.*.o.cmd \
> diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
> index a38a3001527c..5cd193c04448 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -171,7 +171,7 @@ INCLUDE_DIR := $(SCRATCH_DIR)/include
> BPFOBJ := $(BUILD_DIR)/libbpf/libbpf.a
> ifneq ($(CROSS_COMPILE),)
> HOST_BUILD_DIR := $(BUILD_DIR)/host
> -HOST_SCRATCH_DIR := $(OUTPUT)/host-tools
> +HOST_SCRATCH_DIR := $(SCRATCH_DIR)
> HOST_INCLUDE_DIR := $(HOST_SCRATCH_DIR)/include
> else
> HOST_BUILD_DIR := $(BUILD_DIR)
>
> This causes `resolve_btfids` to be compiled in the target endianess and gets
> magically run provided that the hosts has `qemu-s390x-static` and a functional
> binfmt_misc [2] on the host, but having this using host architecture per [1]
> is likely better.
This is kinda surprising to me. I don't recall seeing any code inside
resolve_btfids that touches the set8 flags field -- only the ids in the
flexible array member. Would be interested to see what the value of the
set8 flags field is before resolve_btfids is run.
I'm a bit busy until Sunday afternoon but I'll try to take a look around
then. Might be a good opportunity to play with poke [0].
Thanks,
Daniel
[0]: http://www.jemarch.net/poke
^ permalink raw reply
* Requesting 3 patches for Apple Magic Keyboard 2021 to be merged to LTS kernels
From: Aseda Aboagye @ 2024-02-03 2:45 UTC (permalink / raw)
To: stable; +Cc: jikos, benjamin.tissoires, linux-input
Dear stable kernel maintainers,
I am writing to request that 3 related patches be merged to various LTS kernels. I'm not sure if it would have
been preferable for me to send 3 separate emails, so please forgive me if I chose wrongly. (This is my first foray
into interacting with the kernel community) :)
The patches are as follows:
1. 0cd3be51733f (HID: apple: Add support for the 2021 Magic Keyboard, 2021-10-08)
2. 346338ef00d3 (HID: apple: Swap the Fn and Left Control keys on Apple keyboards, 2020-05-15)
3. 531cb56972f2 (HID: apple: Add 2021 magic keyboard FN key mapping, 2021-11-08)
These patches have all been merged to mainline, but I believe when they were submitted, backporting may not have been considered. The Apple Magic Keyboard 2021 (Model # A2450) seems to be a popular keyboard, and without these
patches, for users on certain LTS kernels that use this keyboard, the function keys do not behave as expected. e.g. Pressing the brightness down or brightness up key didn't work, and bizarrely pressing the globe/Fn key alone caused the brightness to decrease. None of the top row keys worked as expected.
I checked to see where the patches were missing and figured that it would be good to have those patches in those
kernels.
I would ask that patches 1 & 3 be merged to v4.19, v5.4, v5.10, and v5.15.
I would ask that patch 2 be merged to: v5.4 and v4.19.
For patch 3 to apply cleanly, it needed patch 2 to be present in the tree.
Thanks,
--
Aseda Aboagye
^ permalink raw reply
* Re: Requesting 3 patches for Apple Magic Keyboard 2021 to be merged to LTS kernels
From: Greg KH @ 2024-02-03 3:34 UTC (permalink / raw)
To: Aseda Aboagye; +Cc: stable, jikos, benjamin.tissoires, linux-input
In-Reply-To: <3b82d3d8-c0c3-49e1-ae68-966f02fe5429@chromium.org>
On Fri, Feb 02, 2024 at 08:45:40PM -0600, Aseda Aboagye wrote:
> Dear stable kernel maintainers,
>
> I am writing to request that 3 related patches be merged to various LTS kernels. I'm not sure if it would have
> been preferable for me to send 3 separate emails, so please forgive me if I chose wrongly. (This is my first foray
> into interacting with the kernel community) :)
>
> The patches are as follows:
>
> 1. 0cd3be51733f (HID: apple: Add support for the 2021 Magic Keyboard, 2021-10-08)
> 2. 346338ef00d3 (HID: apple: Swap the Fn and Left Control keys on Apple keyboards, 2020-05-15)
> 3. 531cb56972f2 (HID: apple: Add 2021 magic keyboard FN key mapping, 2021-11-08)
>
> These patches have all been merged to mainline, but I believe when they were submitted, backporting may not have been considered. The Apple Magic Keyboard 2021 (Model # A2450) seems to be a popular keyboard, and without these
> patches, for users on certain LTS kernels that use this keyboard, the function keys do not behave as expected. e.g. Pressing the brightness down or brightness up key didn't work, and bizarrely pressing the globe/Fn key alone caused the brightness to decrease. None of the top row keys worked as expected.
>
> I checked to see where the patches were missing and figured that it would be good to have those patches in those
> kernels.
>
> I would ask that patches 1 & 3 be merged to v4.19, v5.4, v5.10, and v5.15.
> I would ask that patch 2 be merged to: v5.4 and v4.19.
>
> For patch 3 to apply cleanly, it needed patch 2 to be present in the tree.
I've done so now, but really, adding support for a keyboard that wasn't
even out when the kernel was released is odd, why not just use a newer
kernel version? That's generally a good idea for all consumer devices,
use the latest stable kernel please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/3] Annotate kfuncs in .BTF_ids section
From: Jiri Olsa @ 2024-02-03 14:40 UTC (permalink / raw)
To: Manu Bretelle, vmalik
Cc: Daniel Xu, linux-trace-kernel, coreteam, bpf, linux-input,
cgroups, netdev, linux-stm32, linux-kselftest, linux-doc,
fsverity, linux-kernel, linux-arm-kernel, netfilter-devel,
alexei.starovoitov, olsajiri, quentin, alan.maguire, memxor
In-Reply-To: <Zb12EZt0BAKOPBk/@surya>
On Fri, Feb 02, 2024 at 03:09:05PM -0800, Manu Bretelle wrote:
> On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote:
> > === Description ===
> >
> > This is a bpf-treewide change that annotates all kfuncs as such inside
> > .BTF_ids. This annotation eventually allows us to automatically generate
> > kfunc prototypes from bpftool.
> >
> > We store this metadata inside a yet-unused flags field inside struct
> > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> >
> > More details about the full chain of events are available in commit 3's
> > description.
> >
> > The accompanying pahole and bpftool changes can be viewed
> > here on these "frozen" branches [0][1].
> >
> > [0]: https://github.com/danobi/pahole/tree/kfunc_btf-v3-mailed
> > [1]: https://github.com/danobi/linux/tree/kfunc_bpftool-mailed
>
>
> I hit a similar issue to [0] on master
> 943b043aeecc ("selftests/bpf: Fix bench runner SIGSEGV")
> when cross-compiling on x86_64 (LE) to s390x (BE).
> I do have CONFIG_DEBUG_INFO_BTF enable and the issue would not trigger if
> I disabled CONFIG_DEBUG_INFO_BTF (and with the fix mentioned in [0]).
>
> What seems to happen is that `tools/resolve_btfids` is ran in the context of the
> host endianess and if I printk before the WARN_ON:
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index ef380e546952..a9ed7a1a4936 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -8128,6 +8128,7 @@ int register_btf_kfunc_id_set(enum bpf_prog_type prog_type,
> * WARN() for initcall registrations that do not check errors.
> */
> if (!(kset->set->flags & BTF_SET8_KFUNCS)) {
> + printk("Flag 0x%08X, expected 0x%08X\n", kset->set->flags, BTF_SET8_KFUNCS);
> WARN_ON(!kset->owner);
> return -EINVAL;
> }
>
> the boot logs would show:
> Flag 0x01000000, expected 0x00000001
>
> The issue did not happen prior to
> 6f3189f38a3e ("bpf: treewide: Annotate BPF kfuncs in BTF")
> has only 0 was written before.
>
> It seems [1] will be addressing cross-compilation, but it did not fix it as is
> by just applying on top of master, so probably some of the changes will also need
> to be ported to `tools/include/linux/btf_ids.h`?
the fix in [1] is fixing flags in set8's pairs, but not the global flags
it looks like Viktor's fix should now also swap that as well? like in the
change below on top of Viktor's changes (untested)
jirka
---
diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
index d01603ef6283..c44d57fec390 100644
--- a/tools/bpf/resolve_btfids/main.c
+++ b/tools/bpf/resolve_btfids/main.c
@@ -706,6 +706,8 @@ static int sets_patch(struct object *obj)
* correctly translate everything.
*/
if (need_bswap) {
+ set8->flags = bswap_32(set8->flags);
+
for (i = 0; i < cnt; i++) {
set8->pairs[i].flags =
bswap_32(set8->pairs[i].flags);
^ permalink raw reply related
* + XPS 13 9343
From: Antoine @ 2024-02-03 16:16 UTC (permalink / raw)
To: hdegoede
Cc: Dell.Client.Kernel, linux-input, linux-kernel, linux-pm, pmenzel,
regressions, 1061521
In-Reply-To: <f27b491c-2f1c-4e68-804c-24eeaa8d10de@redhat.com>
On 1/20/24 21:26, Hans de Goede wrote:
> Can you try adding "i8042.dumbkbd=1" to your kernel commandline?
>
> The next question is if the keyboard will still actually
> work after suspend/resume with "i8042.dumbkbd=1". If it
> stays in the list, but no longer works
Hi, thanks a lot for taking into account our hardware,
just a supplementary feedback:
In my case (Dell XPS 13 9343/i5-5200U):
- Dell Inc. XPS 13 9343/0TM99H, BIOS A19 12/24/2018
- Linux version 6.6.13-1 (2024-01-20)
commandline with `i8042.dumbkbd=1` fixes the issue,
with capslock functional but without led
+ as a side note, hibernate doesn't trigger any issue
(before getting informed of and testing `i8042.dumbkbd=1`)
I had attached logs before/after suspend against 6.6.11 and 6.6.13 :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061521#30
I remain at your disposal for any further infos/testing
best regards,
Antoine
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/3] Annotate kfuncs in .BTF_ids section
From: Manu Bretelle @ 2024-02-03 18:45 UTC (permalink / raw)
To: Jiri Olsa
Cc: vmalik, Daniel Xu, linux-trace-kernel, coreteam, bpf, linux-input,
cgroups, netdev, linux-stm32, linux-kselftest, linux-doc,
fsverity, linux-kernel, linux-arm-kernel, netfilter-devel,
alexei.starovoitov, quentin, alan.maguire, memxor
In-Reply-To: <Zb5QWCw3Tg26_MDa@krava>
On Sat, Feb 03, 2024 at 03:40:24PM +0100, Jiri Olsa wrote:
> On Fri, Feb 02, 2024 at 03:09:05PM -0800, Manu Bretelle wrote:
> > On Sun, Jan 28, 2024 at 06:24:05PM -0700, Daniel Xu wrote:
> > > === Description ===
> > >
> > > This is a bpf-treewide change that annotates all kfuncs as such inside
> > > .BTF_ids. This annotation eventually allows us to automatically generate
> > > kfunc prototypes from bpftool.
> > >
> > > We store this metadata inside a yet-unused flags field inside struct
> > > btf_id_set8 (thanks Kumar!). pahole will be taught where to look.
> > >
> > > More details about the full chain of events are available in commit 3's
> > > description.
> > >
> > > The accompanying pahole and bpftool changes can be viewed
> > > here on these "frozen" branches [0][1].
> > >
> > > [0]: https://github.com/danobi/pahole/tree/kfunc_btf-v3-mailed
> > > [1]: https://github.com/danobi/linux/tree/kfunc_bpftool-mailed
> >
> >
> > I hit a similar issue to [0] on master
> > 943b043aeecc ("selftests/bpf: Fix bench runner SIGSEGV")
> > when cross-compiling on x86_64 (LE) to s390x (BE).
> > I do have CONFIG_DEBUG_INFO_BTF enable and the issue would not trigger if
> > I disabled CONFIG_DEBUG_INFO_BTF (and with the fix mentioned in [0]).
> >
> > What seems to happen is that `tools/resolve_btfids` is ran in the context of the
> > host endianess and if I printk before the WARN_ON:
> > diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> > index ef380e546952..a9ed7a1a4936 100644
> > --- a/kernel/bpf/btf.c
> > +++ b/kernel/bpf/btf.c
> > @@ -8128,6 +8128,7 @@ int register_btf_kfunc_id_set(enum bpf_prog_type prog_type,
> > * WARN() for initcall registrations that do not check errors.
> > */
> > if (!(kset->set->flags & BTF_SET8_KFUNCS)) {
> > + printk("Flag 0x%08X, expected 0x%08X\n", kset->set->flags, BTF_SET8_KFUNCS);
> > WARN_ON(!kset->owner);
> > return -EINVAL;
> > }
> >
> > the boot logs would show:
> > Flag 0x01000000, expected 0x00000001
> >
> > The issue did not happen prior to
> > 6f3189f38a3e ("bpf: treewide: Annotate BPF kfuncs in BTF")
> > has only 0 was written before.
> >
> > It seems [1] will be addressing cross-compilation, but it did not fix it as is
> > by just applying on top of master, so probably some of the changes will also need
> > to be ported to `tools/include/linux/btf_ids.h`?
>
> the fix in [1] is fixing flags in set8's pairs, but not the global flags
>
> it looks like Viktor's fix should now also swap that as well? like in the
> change below on top of Viktor's changes (untested)
>
> jirka
>
>
> ---
> diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/main.c
> index d01603ef6283..c44d57fec390 100644
> --- a/tools/bpf/resolve_btfids/main.c
> +++ b/tools/bpf/resolve_btfids/main.c
> @@ -706,6 +706,8 @@ static int sets_patch(struct object *obj)
> * correctly translate everything.
> */
> if (need_bswap) {
> + set8->flags = bswap_32(set8->flags);
> +
> for (i = 0; i < cnt; i++) {
> set8->pairs[i].flags =
> bswap_32(set8->pairs[i].flags);
>
That should work. Here are a few tests I ran:
$ md5sum /tmp/kbuild-s390x/vmlinux.*
eb658e51e089f3c5b2c8909a29dc9997 /tmp/kbuild-s390x/vmlinux.a
# plain vmlinux before running resolv_btfids (all 0s)
ea907cd46a1a73b8276b5f2a82af00ca /tmp/kbuild-s390x/vmlinux.before_resolv
# x86_64 resolv_btfids on master without Viktor's patch
980a40c3a3ff563d1c2d1ebdd5071a23 /tmp/kbuild-s390x/vmlinux.resolv_native
# x86_64 resolv_btfids on master with Viktor's patch
b986d19e242719ebea41c578235da662 /tmp/kbuild-s390x/vmlinux.resolv_native_patch_viktor
# x86_64 resolv_btfids on master with Viktor's patch and your suggested patch
4edd8752ff01129945bd442689b1927b /tmp/kbuild-s390x/vmlinux.resolv_native_patch_viktor_patched
# s390x resolv_btfids run with qemu-s390x-static
4edd8752ff01129945bd442689b1927b /tmp/kbuild-s390x/vmlinux.resolv_s390x
and some hexdiff of those binaries:
# difference between master's native build and s390x build.... has byte swapping for set8 and others
diff -ruN <(xxd /tmp/kbuild-s390x/vmlinux.resolv_s390x) <(xxd /tmp/kbuild-s390x/vmlinux.resolv_native) > diff_s390x_native.diff
https://gist.github.com/chantra/c3d58637a08a6f7340953dc155bb18cc
# difference betwee Viktor's version and s390x build.... squinting my eyes I only see the global set8 is missing
diff -ruN <(xxd /tmp/kbuild-s390x/vmlinux.resolv_s390x) <(xxd /tmp/kbuild-s390x/vmlinux.resolv_native_patch_viktor) > diff_s390x_native_viktor.diff
https://gist.github.com/chantra/61cfff02b456ae72d3c0161ce1897097
Have a good weekend all!
Manu
^ permalink raw reply
* [dtor-input:for-linus] BUILD SUCCESS 4255447ad34c5c3785fcdcf76cfa0271d6e5ed39
From: kernel test robot @ 2024-02-03 19:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
branch HEAD: 4255447ad34c5c3785fcdcf76cfa0271d6e5ed39 Input: i8042 - add Fujitsu Lifebook U728 to i8042 quirk table
elapsed time: 1448m
configs tested: 212
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc nsimosci_defconfig gcc
arc nsimosci_hs_defconfig gcc
arc randconfig-001-20240203 gcc
arc randconfig-002-20240203 gcc
arc tb10x_defconfig gcc
arc vdk_hs38_smp_defconfig gcc
arm allmodconfig gcc
arm allnoconfig clang
arm allyesconfig gcc
arm aspeed_g5_defconfig gcc
arm bcm2835_defconfig clang
arm defconfig clang
arm netwinder_defconfig gcc
arm randconfig-001-20240203 clang
arm randconfig-002-20240203 clang
arm randconfig-003-20240203 gcc
arm randconfig-004-20240203 clang
arm s5pv210_defconfig gcc
arm shmobile_defconfig gcc
arm socfpga_defconfig gcc
arm u8500_defconfig gcc
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20240203 clang
arm64 randconfig-002-20240203 clang
arm64 randconfig-003-20240203 gcc
arm64 randconfig-004-20240203 gcc
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20240203 gcc
csky randconfig-002-20240203 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20240203 clang
hexagon randconfig-002-20240203 clang
i386 alldefconfig gcc
i386 allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240203 clang
i386 buildonly-randconfig-002-20240203 gcc
i386 buildonly-randconfig-003-20240203 clang
i386 buildonly-randconfig-004-20240203 clang
i386 buildonly-randconfig-005-20240203 clang
i386 buildonly-randconfig-006-20240203 gcc
i386 defconfig clang
i386 randconfig-001-20240203 clang
i386 randconfig-002-20240203 gcc
i386 randconfig-003-20240203 clang
i386 randconfig-004-20240203 gcc
i386 randconfig-005-20240203 clang
i386 randconfig-006-20240203 gcc
i386 randconfig-011-20240203 clang
i386 randconfig-012-20240203 gcc
i386 randconfig-013-20240203 gcc
i386 randconfig-014-20240203 gcc
i386 randconfig-015-20240203 gcc
i386 randconfig-016-20240203 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch allyesconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20240203 gcc
loongarch randconfig-002-20240203 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k apollo_defconfig gcc
m68k bvme6000_defconfig gcc
m68k defconfig gcc
m68k m5275evb_defconfig gcc
m68k m5475evb_defconfig gcc
m68k multi_defconfig gcc
m68k mvme147_defconfig gcc
m68k stmark2_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
microblaze mmu_defconfig gcc
mips allmodconfig gcc
mips allnoconfig gcc
mips allyesconfig gcc
mips gpr_defconfig clang
mips maltasmvp_eva_defconfig gcc
nios2 alldefconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20240203 gcc
nios2 randconfig-002-20240203 gcc
openrisc allmodconfig gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20240203 gcc
parisc randconfig-002-20240203 gcc
parisc64 alldefconfig gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc bamboo_defconfig clang
powerpc kmeter1_defconfig gcc
powerpc mvme5100_defconfig gcc
powerpc ps3_defconfig gcc
powerpc randconfig-001-20240203 clang
powerpc randconfig-002-20240203 clang
powerpc randconfig-003-20240203 clang
powerpc sam440ep_defconfig gcc
powerpc64 randconfig-001-20240203 clang
powerpc64 randconfig-002-20240203 gcc
powerpc64 randconfig-003-20240203 clang
riscv allmodconfig clang
riscv allnoconfig gcc
riscv allyesconfig clang
riscv defconfig clang
riscv randconfig-001-20240203 clang
riscv randconfig-002-20240203 clang
riscv rv32_defconfig clang
s390 allmodconfig clang
s390 allnoconfig clang
s390 allyesconfig gcc
s390 debug_defconfig gcc
s390 defconfig clang
s390 randconfig-001-20240203 gcc
s390 randconfig-002-20240203 clang
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh dreamcast_defconfig gcc
sh ecovec24-romimage_defconfig gcc
sh landisk_defconfig gcc
sh lboxre2_defconfig gcc
sh polaris_defconfig gcc
sh randconfig-001-20240203 gcc
sh randconfig-002-20240203 gcc
sh rsk7201_defconfig gcc
sh rsk7203_defconfig gcc
sh se7780_defconfig gcc
sh sh7763rdp_defconfig gcc
sh sh7785lcr_defconfig gcc
sh titan_defconfig gcc
sparc allmodconfig gcc
sparc allnoconfig gcc
sparc allyesconfig gcc
sparc defconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20240203 gcc
sparc64 randconfig-002-20240203 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig gcc
um defconfig clang
um randconfig-001-20240203 clang
um randconfig-002-20240203 clang
um x86_64_defconfig clang
x86_64 allnoconfig clang
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20240203 gcc
x86_64 buildonly-randconfig-002-20240203 gcc
x86_64 buildonly-randconfig-003-20240203 gcc
x86_64 buildonly-randconfig-004-20240203 gcc
x86_64 buildonly-randconfig-005-20240203 gcc
x86_64 buildonly-randconfig-006-20240203 gcc
x86_64 defconfig gcc
x86_64 randconfig-001-20240203 gcc
x86_64 randconfig-002-20240203 gcc
x86_64 randconfig-003-20240203 clang
x86_64 randconfig-004-20240203 gcc
x86_64 randconfig-005-20240203 gcc
x86_64 randconfig-006-20240203 gcc
x86_64 randconfig-011-20240203 gcc
x86_64 randconfig-012-20240203 gcc
x86_64 randconfig-013-20240203 clang
x86_64 randconfig-014-20240203 clang
x86_64 randconfig-015-20240203 clang
x86_64 randconfig-016-20240203 clang
x86_64 randconfig-071-20240203 clang
x86_64 randconfig-072-20240203 gcc
x86_64 randconfig-073-20240203 clang
x86_64 randconfig-074-20240203 clang
x86_64 randconfig-075-20240203 clang
x86_64 randconfig-076-20240203 clang
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa allnoconfig gcc
xtensa allyesconfig gcc
xtensa nommu_kc705_defconfig gcc
xtensa randconfig-001-20240203 gcc
xtensa randconfig-002-20240203 gcc
xtensa smp_lx200_defconfig gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] Input: bma150: remove I2C_CLASS_HWMON from drivers w/o detect and address_list
From: Wolfram Sang @ 2024-02-03 20:39 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Dmitry Torokhov, open list:HID CORE LAYER,
linux-i2c@vger.kernel.org
In-Reply-To: <011ac933-2a45-4a63-895d-d45bfcb8576e@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
On Sat, Jan 27, 2024 at 04:18:57PM +0100, Heiner Kallweit wrote:
> Class-based I2C probing requires detect() and address_list to be
> set in the I2C client driver, see checks in i2c_detect().
> It's misleading to declare I2C_CLASS_HWMON support if this
> precondition isn't met.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: + XPS 13 9343
From: Hans de Goede @ 2024-02-04 7:24 UTC (permalink / raw)
To: Antoine
Cc: Dell.Client.Kernel, linux-input, linux-kernel, linux-pm, pmenzel,
regressions, 1061521
In-Reply-To: <bc166c19-8da3-cd42-b749-e35eaebe7822@r2rien.net>
Hi Antoine,
On 2/3/24 17:16, Antoine wrote:
> On 1/20/24 21:26, Hans de Goede wrote:
>> Can you try adding "i8042.dumbkbd=1" to your kernel commandline?
>>
>> The next question is if the keyboard will still actually
>> work after suspend/resume with "i8042.dumbkbd=1". If it
>> stays in the list, but no longer works
>
> Hi, thanks a lot for taking into account our hardware,
> just a supplementary feedback:
>
> In my case (Dell XPS 13 9343/i5-5200U):
> - Dell Inc. XPS 13 9343/0TM99H, BIOS A19 12/24/2018
> - Linux version 6.6.13-1 (2024-01-20)
>
> commandline with `i8042.dumbkbd=1` fixes the issue,
> with capslock functional but without led
> + as a side note, hibernate doesn't trigger any issue
>
> (before getting informed of and testing `i8042.dumbkbd=1`)
> I had attached logs before/after suspend against 6.6.11 and 6.6.13 :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061521#30
>
> I remain at your disposal for any further infos/testing
The issue of the kbd on some Dell XPS models no longer
working after a suspend/resume cycle should be fixed by
these 2 patches which are on their way to Linus' tree:
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=683cd8259a9b883a51973511f860976db2550a6e
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=9cf6e24c9fbf17e52de9fff07f12be7565ea6d61
Regards,
Hans
^ permalink raw reply
* [PATCH] iio: hid-sensor-als: Return 0 for HID_USAGE_SENSOR_TIME_TIMESTAMP
From: Srinivas Pandruvada @ 2024-02-04 12:56 UTC (permalink / raw)
To: jikos, jic23, lars, Basavaraj.Natikar
Cc: linux-input, linux-iio, linux-kernel, Srinivas Pandruvada
When als_capture_sample() is called with usage ID
HID_USAGE_SENSOR_TIME_TIMESTAMP, return 0. The HID sensor core ignores
the return value for capture_sample() callback, so return value doesn't
make difference. But correct the return value to return success instead
of -EINVAL.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
As part of review comments for series "Add support of color temperature
and chromaticity". This is separate from the series as this is
unrelated.
drivers/iio/light/hid-sensor-als.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 5cd27f04b45e..b6c4bef2a7bb 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -226,6 +226,7 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
als_state->timestamp = hid_sensor_convert_timestamp(&als_state->common_attributes,
*(s64 *)raw_data);
+ ret = 0;
break;
default:
break;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/4] Add support of color temperature and chromaticity
From: Srinivas Pandruvada @ 2024-02-04 13:03 UTC (permalink / raw)
To: jikos, jic23, lars, Basavaraj.Natikar
Cc: linux-input, linux-iio, linux-kernel, Srinivas Pandruvada
The original series submitted to 6.7 (before revert) is modified to
solve regression issues on several platforms. There are two changes
introduced before adding support for new features to allow dynamic
addition of channels.
v4:
Addressed comments from Jonathan and Basavaraj
v3:
Addressed comments for v2, details in each patch.
v2:
New change to add channels dynamically
Modified color temperature and chromaticity to skip in case
of failures
Basavaraj Natikar (2):
iio: hid-sensor-als: Add light color temperature support
iio: hid-sensor-als: Add light chromaticity support
Srinivas Pandruvada (2):
iio: hid-sensor-als: Assign channels dynamically
iio: hid-sensor-als: Remove hardcoding of values for enums
drivers/iio/light/hid-sensor-als.c | 123 ++++++++++++++++++++++++-----
include/linux/hid-sensor-ids.h | 4 +
2 files changed, 109 insertions(+), 18 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v4 1/4] iio: hid-sensor-als: Assign channels dynamically
From: Srinivas Pandruvada @ 2024-02-04 13:03 UTC (permalink / raw)
To: jikos, jic23, lars, Basavaraj.Natikar
Cc: linux-input, linux-iio, linux-kernel, Srinivas Pandruvada
In-Reply-To: <20240204130332.2635760-1-srinivas.pandruvada@linux.intel.com>
Instead of assuming that every channel defined statically by
als_channels[] is present, assign dynamically based on presence of the
respective usage id in the descriptor. This will allow to register ALS
with limited channel support. Append the timestamp as the last channel.
Update available_scan_mask to specify all channels which are present.
There is no intentional function changes done.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
v4:
Addressed comments from Jonthan:
- Use available_scan_masks
- timestamp location is fixed and left gaps in sample data for absent channels
- Use CHANNEL_SCAN_INDEX_MAX as limit to check presence of usage ids, otherwise
it will miss newer channels added in subsequent patches.
v3:
Addressed comments from Jonthan:
- Remove channel allocation and move to iio_priv()
- Parse all usage IDs in a single loop and continue
for failure. This way the temperature and chromaticity
will not need any special processing to parse usage ids.
- Don't leave empty channel indexes
v2:
New change
drivers/iio/light/hid-sensor-als.c | 52 +++++++++++++++++++++---------
1 file changed, 36 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index b6c4bef2a7bb..d3b892c0e307 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -25,6 +25,7 @@ struct als_state {
struct hid_sensor_hub_callbacks callbacks;
struct hid_sensor_common common_attributes;
struct hid_sensor_hub_attribute_info als[CHANNEL_SCAN_INDEX_MAX];
+ struct iio_chan_spec channels[CHANNEL_SCAN_INDEX_MAX + 1];
struct {
u32 illum[CHANNEL_SCAN_INDEX_MAX];
u64 timestamp __aligned(8);
@@ -33,9 +34,16 @@ struct als_state {
int scale_post_decml;
int scale_precision;
int value_offset;
+ int num_channels;
s64 timestamp;
};
+/* The order of usage ids must match scan index starting from CHANNEL_SCAN_INDEX_INTENSITY */
+static const u32 als_usage_ids[] = {
+ HID_USAGE_SENSOR_LIGHT_ILLUM,
+ HID_USAGE_SENSOR_LIGHT_ILLUM,
+};
+
static const u32 als_sensitivity_addresses[] = {
HID_USAGE_SENSOR_DATA_LIGHT,
HID_USAGE_SENSOR_LIGHT_ILLUM,
@@ -68,6 +76,8 @@ static const struct iio_chan_spec als_channels[] = {
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
+static unsigned long als_scan_mask[] = {0, 0};
+
/* Adjust channel real bits based on report descriptor */
static void als_adjust_channel_bit_mask(struct iio_chan_spec *channels,
int channel, int size)
@@ -238,27 +248,38 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
/* Parse report which is specific to an usage id*/
static int als_parse_report(struct platform_device *pdev,
struct hid_sensor_hub_device *hsdev,
- struct iio_chan_spec *channels,
unsigned usage_id,
struct als_state *st)
{
- int ret;
+ struct iio_chan_spec *channels;
+ int ret, index = 0;
int i;
- for (i = 0; i <= CHANNEL_SCAN_INDEX_ILLUM; ++i) {
+ channels = st->channels;
+
+ for (i = 0; i < CHANNEL_SCAN_INDEX_MAX; ++i) {
ret = sensor_hub_input_get_attribute_info(hsdev,
HID_INPUT_REPORT,
usage_id,
- HID_USAGE_SENSOR_LIGHT_ILLUM,
+ als_usage_ids[i],
&st->als[i]);
if (ret < 0)
- return ret;
- als_adjust_channel_bit_mask(channels, i, st->als[i].size);
+ continue;
+
+ channels[index] = als_channels[i];
+ als_scan_mask[0] |= BIT(i);
+ als_adjust_channel_bit_mask(channels, index, st->als[i].size);
+ ++index;
dev_dbg(&pdev->dev, "als %x:%x\n", st->als[i].index,
st->als[i].report_id);
}
+ st->num_channels = index;
+ /* Return success even if one usage id is present */
+ if (index)
+ ret = 0;
+
st->scale_precision = hid_sensor_format_scale(usage_id,
&st->als[CHANNEL_SCAN_INDEX_INTENSITY],
&st->scale_pre_decml, &st->scale_post_decml);
@@ -294,15 +315,7 @@ static int hid_als_probe(struct platform_device *pdev)
return ret;
}
- indio_dev->channels = devm_kmemdup(&pdev->dev, als_channels,
- sizeof(als_channels), GFP_KERNEL);
- if (!indio_dev->channels) {
- dev_err(&pdev->dev, "failed to duplicate channels\n");
- return -ENOMEM;
- }
-
ret = als_parse_report(pdev, hsdev,
- (struct iio_chan_spec *)indio_dev->channels,
hsdev->usage,
als_state);
if (ret) {
@@ -310,8 +323,15 @@ static int hid_als_probe(struct platform_device *pdev)
return ret;
}
- indio_dev->num_channels =
- ARRAY_SIZE(als_channels);
+ /* Add timestamp channel */
+ als_state->channels[als_state->num_channels] = als_channels[CHANNEL_SCAN_INDEX_TIMESTAMP];
+
+ /* +1 for adding timestamp channel */
+ indio_dev->num_channels = als_state->num_channels + 1;
+
+ indio_dev->channels = als_state->channels;
+ indio_dev->available_scan_masks = als_scan_mask;
+
indio_dev->info = &als_info;
indio_dev->name = name;
indio_dev->modes = INDIO_DIRECT_MODE;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/4] iio: hid-sensor-als: Remove hardcoding of values for enums
From: Srinivas Pandruvada @ 2024-02-04 13:03 UTC (permalink / raw)
To: jikos, jic23, lars, Basavaraj.Natikar
Cc: linux-input, linux-iio, linux-kernel, Srinivas Pandruvada
In-Reply-To: <20240204130332.2635760-1-srinivas.pandruvada@linux.intel.com>
Remove hardcoding of values for enum CHANNEL_SCAN_INDEX_INTENSITY and
CHANNEL_SCAN_INDEX_ILLUM.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
v4:
NO change
v3:
New patch. Added as the next patch removed the hardcoding of enum values
when submitted. To remove unrelated changes, created a patch to just
remove hardcoding of values.
drivers/iio/light/hid-sensor-als.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index d3b892c0e307..521af52b3f3b 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -14,8 +14,8 @@
#include "../common/hid-sensors/hid-sensor-trigger.h"
enum {
- CHANNEL_SCAN_INDEX_INTENSITY = 0,
- CHANNEL_SCAN_INDEX_ILLUM = 1,
+ CHANNEL_SCAN_INDEX_INTENSITY,
+ CHANNEL_SCAN_INDEX_ILLUM,
CHANNEL_SCAN_INDEX_MAX
};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/4] iio: hid-sensor-als: Add light color temperature support
From: Srinivas Pandruvada @ 2024-02-04 13:03 UTC (permalink / raw)
To: jikos, jic23, lars, Basavaraj.Natikar
Cc: linux-input, linux-iio, linux-kernel, Srinivas Pandruvada
In-Reply-To: <20240204130332.2635760-1-srinivas.pandruvada@linux.intel.com>
From: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
On some platforms, ambient color sensors also support light color
temperature. Add support of light color temperature.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
v4:
- Index is fixed for each channel instead of packing for absent channels
v3:
Simplilified as no special processing is required in als_parse_report()
v2:
Original patch from Basavaraj Natikar <Basavaraj.Natikar@amd.com> is
modified to prevent failure when the new usage id is not found in the
descriptor.
drivers/iio/light/hid-sensor-als.c | 21 +++++++++++++++++++++
include/linux/hid-sensor-ids.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 521af52b3f3b..0e9a25c51676 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -16,6 +16,7 @@
enum {
CHANNEL_SCAN_INDEX_INTENSITY,
CHANNEL_SCAN_INDEX_ILLUM,
+ CHANNEL_SCAN_INDEX_COLOR_TEMP,
CHANNEL_SCAN_INDEX_MAX
};
@@ -42,6 +43,7 @@ struct als_state {
static const u32 als_usage_ids[] = {
HID_USAGE_SENSOR_LIGHT_ILLUM,
HID_USAGE_SENSOR_LIGHT_ILLUM,
+ HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE,
};
static const u32 als_sensitivity_addresses[] = {
@@ -73,6 +75,16 @@ static const struct iio_chan_spec als_channels[] = {
BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
.scan_index = CHANNEL_SCAN_INDEX_ILLUM,
},
+ {
+ .type = IIO_COLORTEMP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
+ .scan_index = CHANNEL_SCAN_INDEX_COLOR_TEMP,
+ },
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
@@ -113,6 +125,11 @@ static int als_read_raw(struct iio_dev *indio_dev,
min = als_state->als[chan->scan_index].logical_minimum;
address = HID_USAGE_SENSOR_LIGHT_ILLUM;
break;
+ case CHANNEL_SCAN_INDEX_COLOR_TEMP:
+ report_id = als_state->als[chan->scan_index].report_id;
+ min = als_state->als[chan->scan_index].logical_minimum;
+ address = HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE;
+ break;
default:
report_id = -1;
break;
@@ -233,6 +250,10 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
als_state->scan.illum[CHANNEL_SCAN_INDEX_ILLUM] = sample_data;
ret = 0;
break;
+ case HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE:
+ als_state->scan.illum[CHANNEL_SCAN_INDEX_COLOR_TEMP] = sample_data;
+ ret = 0;
+ break;
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
als_state->timestamp = hid_sensor_convert_timestamp(&als_state->common_attributes,
*(s64 *)raw_data);
diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
index 13b1e65fbdcc..8af4fb3e0254 100644
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@ -21,6 +21,7 @@
#define HID_USAGE_SENSOR_ALS 0x200041
#define HID_USAGE_SENSOR_DATA_LIGHT 0x2004d0
#define HID_USAGE_SENSOR_LIGHT_ILLUM 0x2004d1
+#define HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE 0x2004d2
/* PROX (200011) */
#define HID_USAGE_SENSOR_PROX 0x200011
--
2.43.0
^ permalink raw reply related
* [PATCH v4 4/4] iio: hid-sensor-als: Add light chromaticity support
From: Srinivas Pandruvada @ 2024-02-04 13:03 UTC (permalink / raw)
To: jikos, jic23, lars, Basavaraj.Natikar
Cc: linux-input, linux-iio, linux-kernel, Srinivas Pandruvada
In-Reply-To: <20240204130332.2635760-1-srinivas.pandruvada@linux.intel.com>
From: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
On some platforms, ambient color sensors also support the x and y light
colors, which represent the coordinates on the CIE 1931 chromaticity
diagram. Add light chromaticity x and y.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
v4:
- Index is fixed for each channel instead of packing for absent channels
v3:
Simplilified as no special processing is required in als_parse_report()
v2:
Original patch from Basavaraj Natikar <Basavaraj.Natikar@amd.com> is
modified to prevent failure when the new usage id is not found in the
descriptor.
drivers/iio/light/hid-sensor-als.c | 46 ++++++++++++++++++++++++++++++
include/linux/hid-sensor-ids.h | 3 ++
2 files changed, 49 insertions(+)
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 0e9a25c51676..3c8f707c18cf 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -17,6 +17,8 @@ enum {
CHANNEL_SCAN_INDEX_INTENSITY,
CHANNEL_SCAN_INDEX_ILLUM,
CHANNEL_SCAN_INDEX_COLOR_TEMP,
+ CHANNEL_SCAN_INDEX_CHROMATICITY_X,
+ CHANNEL_SCAN_INDEX_CHROMATICITY_Y,
CHANNEL_SCAN_INDEX_MAX
};
@@ -44,6 +46,8 @@ static const u32 als_usage_ids[] = {
HID_USAGE_SENSOR_LIGHT_ILLUM,
HID_USAGE_SENSOR_LIGHT_ILLUM,
HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE,
+ HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X,
+ HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y,
};
static const u32 als_sensitivity_addresses[] = {
@@ -85,6 +89,30 @@ static const struct iio_chan_spec als_channels[] = {
BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
.scan_index = CHANNEL_SCAN_INDEX_COLOR_TEMP,
},
+ {
+ .type = IIO_CHROMATICITY,
+ .modified = 1,
+ .channel2 = IIO_MOD_X,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
+ .scan_index = CHANNEL_SCAN_INDEX_CHROMATICITY_X,
+ },
+ {
+ .type = IIO_CHROMATICITY,
+ .modified = 1,
+ .channel2 = IIO_MOD_Y,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_OFFSET) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS) |
+ BIT(IIO_CHAN_INFO_HYSTERESIS_RELATIVE),
+ .scan_index = CHANNEL_SCAN_INDEX_CHROMATICITY_Y,
+ },
IIO_CHAN_SOFT_TIMESTAMP(CHANNEL_SCAN_INDEX_TIMESTAMP)
};
@@ -130,6 +158,16 @@ static int als_read_raw(struct iio_dev *indio_dev,
min = als_state->als[chan->scan_index].logical_minimum;
address = HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE;
break;
+ case CHANNEL_SCAN_INDEX_CHROMATICITY_X:
+ report_id = als_state->als[chan->scan_index].report_id;
+ min = als_state->als[chan->scan_index].logical_minimum;
+ address = HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X;
+ break;
+ case CHANNEL_SCAN_INDEX_CHROMATICITY_Y:
+ report_id = als_state->als[chan->scan_index].report_id;
+ min = als_state->als[chan->scan_index].logical_minimum;
+ address = HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y;
+ break;
default:
report_id = -1;
break;
@@ -254,6 +292,14 @@ static int als_capture_sample(struct hid_sensor_hub_device *hsdev,
als_state->scan.illum[CHANNEL_SCAN_INDEX_COLOR_TEMP] = sample_data;
ret = 0;
break;
+ case HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X:
+ als_state->scan.illum[CHANNEL_SCAN_INDEX_CHROMATICITY_X] = sample_data;
+ ret = 0;
+ break;
+ case HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y:
+ als_state->scan.illum[CHANNEL_SCAN_INDEX_CHROMATICITY_Y] = sample_data;
+ ret = 0;
+ break;
case HID_USAGE_SENSOR_TIME_TIMESTAMP:
als_state->timestamp = hid_sensor_convert_timestamp(&als_state->common_attributes,
*(s64 *)raw_data);
diff --git a/include/linux/hid-sensor-ids.h b/include/linux/hid-sensor-ids.h
index 8af4fb3e0254..6730ee900ee1 100644
--- a/include/linux/hid-sensor-ids.h
+++ b/include/linux/hid-sensor-ids.h
@@ -22,6 +22,9 @@
#define HID_USAGE_SENSOR_DATA_LIGHT 0x2004d0
#define HID_USAGE_SENSOR_LIGHT_ILLUM 0x2004d1
#define HID_USAGE_SENSOR_LIGHT_COLOR_TEMPERATURE 0x2004d2
+#define HID_USAGE_SENSOR_LIGHT_CHROMATICITY 0x2004d3
+#define HID_USAGE_SENSOR_LIGHT_CHROMATICITY_X 0x2004d4
+#define HID_USAGE_SENSOR_LIGHT_CHROMATICITY_Y 0x2004d5
/* PROX (200011) */
#define HID_USAGE_SENSOR_PROX 0x200011
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox