* Re: [PATCH 2/2] arm64: dts: qcom: pm6150: Add vibrator
From: Dmitry Baryshkov @ 2024-06-07 7:17 UTC (permalink / raw)
To: Jens Reidel
Cc: dmitry.torokhov, robh, krzk+dt, conor+dt, andersson,
konrad.dybcio, linux-arm-msm, linux-input, devicetree,
linux-kernel
In-Reply-To: <20240606181027.98537-3-adrian@travitia.xyz>
On Thu, Jun 06, 2024 at 08:10:27PM +0200, Jens Reidel wrote:
> Add a node for the vibrator module found inside the PM6150.
>
> Signed-off-by: Jens Reidel <adrian@travitia.xyz>
> ---
> arch/arm64/boot/dts/qcom/pm6150.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] Input: elan_i2c - do not leave interrupt disabled on suspend failure
From: Dmitry Torokhov @ 2024-06-07 6:02 UTC (permalink / raw)
To: linux-input; +Cc: jingle.wu, josh.chen, Phoenix Huang, linux-kernel
Make sure interrupts are not left disabled when we fail to suspend the
touch controller.
Fixes: 6696777c6506 ("Input: add driver for Elan I2C/SMbus touchpad")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
drivers/input/mouse/elan_i2c_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index c2aec5c360b3..ce96513b34f6 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1356,6 +1356,8 @@ static int elan_suspend(struct device *dev)
}
err:
+ if (ret)
+ enable_irq(client->irq);
mutex_unlock(&data->sysfs_mutex);
return ret;
}
--
2.45.2.505.gda0bf45e8d-goog
--
Dmitry
^ permalink raw reply related
* Re: [PATCH] HID: add missing MODULE_DESCRIPTION() macros
From: Jeff Johnson @ 2024-06-07 5:12 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, kernel-janitors
In-Reply-To: <20240606-md-drivers-hid-v1-1-d6a5120b94cb@quicinc.com>
On 6/6/2024 10:09 PM, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-holtek-mouse.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ite.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kensington.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-keytouch.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kye.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lcpower.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lenovo.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-winwing.o
>
> Add the missing invocations of the MODULE_DESCRIPTION() macro.
>
> Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
> ---
> drivers/hid/hid-holtek-mouse.c | 1 +
> drivers/hid/hid-ite.c | 1 +
> drivers/hid/hid-kensington.c | 1 +
> drivers/hid/hid-keytouch.c | 1 +
> drivers/hid/hid-kye.c | 1 +
> drivers/hid/hid-lcpower.c | 1 +
> drivers/hid/hid-lenovo.c | 1 +
> drivers/hid/hid-winwing.c | 1 +
> 8 files changed, 8 insertions(+)
please ignore this patch -- this is a duplicate
^ permalink raw reply
* [PATCH] HID: add missing MODULE_DESCRIPTION() macros
From: Jeff Johnson @ 2024-06-07 5:09 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: linux-input, linux-kernel, kernel-janitors, Jeff Johnson
make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-holtek-mouse.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-ite.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kensington.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-keytouch.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-kye.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lcpower.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-lenovo.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-winwing.o
Add the missing invocations of the MODULE_DESCRIPTION() macro.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
---
drivers/hid/hid-holtek-mouse.c | 1 +
drivers/hid/hid-ite.c | 1 +
drivers/hid/hid-kensington.c | 1 +
drivers/hid/hid-keytouch.c | 1 +
drivers/hid/hid-kye.c | 1 +
drivers/hid/hid-lcpower.c | 1 +
drivers/hid/hid-lenovo.c | 1 +
drivers/hid/hid-winwing.c | 1 +
8 files changed, 8 insertions(+)
diff --git a/drivers/hid/hid-holtek-mouse.c b/drivers/hid/hid-holtek-mouse.c
index 7c907939bfae..343730c28e2d 100644
--- a/drivers/hid/hid-holtek-mouse.c
+++ b/drivers/hid/hid-holtek-mouse.c
@@ -110,4 +110,5 @@ static struct hid_driver holtek_mouse_driver = {
};
module_hid_driver(holtek_mouse_driver);
+MODULE_DESCRIPTION("HID driver for Holtek gaming mice");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-ite.c b/drivers/hid/hid-ite.c
index 75ebfcf31889..6a7281bc27c9 100644
--- a/drivers/hid/hid-ite.c
+++ b/drivers/hid/hid-ite.c
@@ -141,4 +141,5 @@ static struct hid_driver ite_driver = {
module_hid_driver(ite_driver);
MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
+MODULE_DESCRIPTION("HID driver for some ITE \"special\" devices");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-kensington.c b/drivers/hid/hid-kensington.c
index b31f7f431a3f..99e79b42047c 100644
--- a/drivers/hid/hid-kensington.c
+++ b/drivers/hid/hid-kensington.c
@@ -46,4 +46,5 @@ static struct hid_driver ks_driver = {
};
module_hid_driver(ks_driver);
+MODULE_DESCRIPTION("HID driver for Kensigton Slimblade Trackball");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-keytouch.c b/drivers/hid/hid-keytouch.c
index 73bf8642dfe3..a972943baaea 100644
--- a/drivers/hid/hid-keytouch.c
+++ b/drivers/hid/hid-keytouch.c
@@ -48,5 +48,6 @@ static struct hid_driver keytouch_driver = {
};
module_hid_driver(keytouch_driver);
+MODULE_DESCRIPTION("HID driver for Keytouch devices not fully compliant with HID standard");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jiri Kosina");
diff --git a/drivers/hid/hid-kye.c b/drivers/hid/hid-kye.c
index 70ceb9437332..ca2ba3da2458 100644
--- a/drivers/hid/hid-kye.c
+++ b/drivers/hid/hid-kye.c
@@ -671,4 +671,5 @@ static struct hid_driver kye_driver = {
};
module_hid_driver(kye_driver);
+MODULE_DESCRIPTION("HID driver for Kye/Genius devices not fully compliant with HID standard");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-lcpower.c b/drivers/hid/hid-lcpower.c
index 8acd3ee5ada5..58953d11ded7 100644
--- a/drivers/hid/hid-lcpower.c
+++ b/drivers/hid/hid-lcpower.c
@@ -53,4 +53,5 @@ static struct hid_driver ts_driver = {
};
module_hid_driver(ts_driver);
+MODULE_DESCRIPTION("HID driver for LC Power Model RC1000MCE");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
index e6b2ae68b8fb..e5e72aa5260a 100644
--- a/drivers/hid/hid-lenovo.c
+++ b/drivers/hid/hid-lenovo.c
@@ -1442,4 +1442,5 @@ static struct hid_driver lenovo_driver = {
};
module_hid_driver(lenovo_driver);
+MODULE_DESCRIPTION("HID driver for IBM/Lenovo");
MODULE_LICENSE("GPL");
diff --git a/drivers/hid/hid-winwing.c b/drivers/hid/hid-winwing.c
index 0e224d1a6466..10a5d87ccb96 100644
--- a/drivers/hid/hid-winwing.c
+++ b/drivers/hid/hid-winwing.c
@@ -223,4 +223,5 @@ static struct hid_driver winwing_driver = {
};
module_hid_driver(winwing_driver);
+MODULE_DESCRIPTION("HID driver for WinWing Orion 2 throttle");
MODULE_LICENSE("GPL");
---
base-commit: 19ca0d8a433ff37018f9429f7e7739e9f3d3d2b4
change-id: 20240606-md-drivers-hid-42e9f9c85cd9
^ permalink raw reply related
* [PATCH v2 1/1] hid-asus: use hid for brightness control on keyboard
From: Luke D. Jones @ 2024-06-07 4:05 UTC (permalink / raw)
To: jikos; +Cc: bentiss, linux-input, linux-kernel, Luke D. Jones
In-Reply-To: <20240607040532.1074379-1-luke@ljones.dev>
On almost all ASUS ROG series laptops the MCU used for the USB keyboard
also has a HID packet used for setting the brightness. This is usually
the same as the WMI method. But in some laptops the WMI method either
is missing or doesn't work, so we should default to the HID control.
Signed-off-by: Luke D. Jones <luke@ljones.dev>
---
drivers/hid/hid-asus.c | 7 ++++
drivers/platform/x86/asus-wmi.c | 3 +-
include/linux/platform_data/x86/asus-wmi.h | 45 ++++++++++++++++++++++
3 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
index 02de2bf4f790..0ed3708ef7e2 100644
--- a/drivers/hid/hid-asus.c
+++ b/drivers/hid/hid-asus.c
@@ -492,12 +492,19 @@ static void asus_kbd_backlight_work(struct work_struct *work)
*/
static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
{
+ struct asus_drvdata *drvdata = hid_get_drvdata(hdev);
u32 value;
int ret;
if (!IS_ENABLED(CONFIG_ASUS_WMI))
return false;
+ if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD &&
+ dmi_check_system(asus_use_hid_led_dmi_ids)) {
+ hid_info(hdev, "using HID for asus::kbd_backlight\n");
+ return false;
+ }
+
ret = asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS,
ASUS_WMI_DEVID_KBD_BACKLIGHT, 0, &value);
hid_dbg(hdev, "WMI backlight check: rc %d value %x", ret, value);
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 3f9b6285c9a6..799d928c7d3d 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1681,7 +1681,8 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
goto error;
}
- if (!kbd_led_read(asus, &led_val, NULL)) {
+ if (!kbd_led_read(asus, &led_val, NULL) && !dmi_check_system(asus_use_hid_led_dmi_ids)) {
+ pr_info("using asus-wmi for asus::kbd_backlight\n");
asus->kbd_led_wk = led_val;
asus->kbd_led.name = "asus::kbd_backlight";
asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index 3eb5cd6773ad..6ba0015e4386 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -4,6 +4,7 @@
#include <linux/errno.h>
#include <linux/types.h>
+#include <linux/dmi.h>
/* WMI Methods */
#define ASUS_WMI_METHODID_SPEC 0x43455053 /* BIOS SPECification */
@@ -160,4 +161,48 @@ static inline int asus_wmi_evaluate_method(u32 method_id, u32 arg0, u32 arg1,
}
#endif
+/* To be used by both hid-asus and asus-wmi to determine which controls kbd_brightness */
+#if IS_ENABLED(CONFIG_ASUS_WMI)
+bool asus_use_hid_led(void);
+#else
+static inline bool asus_use_hid_led(void)
+{
+ return true;
+}
+#endif
+
+static const struct dmi_system_id asus_use_hid_led_dmi_ids[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "ROG Zephyrus"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "ROG Strix"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_PRODUCT_FAMILY, "ROG Flow"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GA403"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "GU605"),
+ },
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "RC71L"),
+ },
+ },
+ NULL,
+};
+
#endif /* __PLATFORM_DATA_X86_ASUS_WMI_H */
--
2.45.1
^ permalink raw reply related
* [PATCH v2 0/1] hid-asus: use hid for keyboard brightness control
From: Luke D. Jones @ 2024-06-07 4:05 UTC (permalink / raw)
To: jikos; +Cc: bentiss, linux-input, linux-kernel, Luke D. Jones
Refactored V1 of patch to remove the report_id changing as it isn't required.
Changelog:
- V2
- Split patch in two (use hid, and change report_id)
- Drop the report_id changing as not required
- Use dmi_check_system() for DMI matching
History:
- https://lore.kernel.org/linux-input/20240528013959.14661-1-luke@ljones.dev/T/#u
Luke D. Jones (1):
hid-asus: use hid for brightness control on keyboard
drivers/hid/hid-asus.c | 7 ++++
drivers/platform/x86/asus-wmi.c | 3 +-
include/linux/platform_data/x86/asus-wmi.h | 45 ++++++++++++++++++++++
3 files changed, 54 insertions(+), 1 deletion(-)
--
2.45.1
^ permalink raw reply
* [PATCH v11 1/8] x86/vmware: Introduce VMware hypercall API
From: Alexey Makhalov @ 2024-06-06 23:23 UTC (permalink / raw)
To: linux-kernel, virtualization, bp, hpa, dave.hansen, mingo, tglx
Cc: x86, netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, timothym, akaher,
dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms, kirill.shutemov, Alexey Makhalov
In-Reply-To: <3d6ec46c-53c2-4a13-90ff-eb419863c1d5@broadcom.com>
Introduce vmware_hypercall family of functions. It is a common
implementation to be used by the VMware guest code and virtual
device drivers in architecture independent manner.
The API consists of vmware_hypercallX and vmware_hypercall_hb_{out,in}
set of functions by analogy with KVM hypercall API. Architecture
specific implementation is hidden inside.
It will simplify future enhancements in VMware hypercalls such
as SEV-ES and TDX related changes without needs to modify a
caller in device drivers code.
Current implementation extends an idea from commit bac7b4e84323
("x86/vmware: Update platform detection code for VMCALL/VMMCALL
hypercalls") to have a slow, but safe path vmware_hypercall_slow()
earlier during the boot when alternatives are not yet applied.
The code inherits VMWARE_CMD logic from the commit mentioned above.
Move common macros from vmware.c to vmware.h.
Signed-off-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
---
arch/x86/include/asm/vmware.h | 279 ++++++++++++++++++++++++++++++++--
arch/x86/kernel/cpu/vmware.c | 58 ++++++-
2 files changed, 315 insertions(+), 22 deletions(-)
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index ac9fc51e2b18..724c8b9b4b8d 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -7,26 +7,277 @@
#include <linux/stringify.h>
/*
- * The hypercall definitions differ in the low word of the %edx argument
- * in the following way: the old port base interface uses the port
- * number to distinguish between high- and low bandwidth versions.
+ * VMware hypercall ABI.
+ *
+ * - Low bandwidth (LB) hypercalls (I/O port based, vmcall and vmmcall)
+ * have up to 6 input and 6 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg2 - Hypercall command
+ * arg3 bits [15:0] - Port number, LB and direction flags
+ *
+ * - High bandwidth (HB) hypercalls are I/O port based only. They have
+ * up to 7 input and 7 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5), %ebp (arg6).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg1 - Hypercall command
+ * arg3 bits [15:0] - Port number, HB and direction flags
+ *
+ * For compatibility purposes, x86_64 systems use only lower 32 bits
+ * for input and output arguments.
+ *
+ * The hypercall definitions differ in the low word of the %edx (arg3)
+ * in the following way: the old I/O port based interface uses the port
+ * number to distinguish between high- and low bandwidth versions, and
+ * uses IN/OUT instructions to define transfer direction.
*
* The new vmcall interface instead uses a set of flags to select
* bandwidth mode and transfer direction. The flags should be loaded
- * into %dx by any user and are automatically replaced by the port
- * number if the VMWARE_HYPERVISOR_PORT method is used.
- *
- * In short, new driver code should strictly use the new definition of
- * %dx content.
+ * into arg3 by any user and are automatically replaced by the port
+ * number if the I/O port method is used.
+ */
+
+#define VMWARE_HYPERVISOR_HB BIT(0)
+#define VMWARE_HYPERVISOR_OUT BIT(1)
+
+#define VMWARE_HYPERVISOR_PORT 0x5658
+#define VMWARE_HYPERVISOR_PORT_HB (VMWARE_HYPERVISOR_PORT | \
+ VMWARE_HYPERVISOR_HB)
+
+#define VMWARE_HYPERVISOR_MAGIC 0x564d5868U
+
+#define VMWARE_CMD_GETVERSION 10
+#define VMWARE_CMD_GETHZ 45
+#define VMWARE_CMD_GETVCPU_INFO 68
+#define VMWARE_CMD_STEALCLOCK 91
+
+#define CPUID_VMWARE_FEATURES_ECX_VMMCALL BIT(0)
+#define CPUID_VMWARE_FEATURES_ECX_VMCALL BIT(1)
+
+extern unsigned long vmware_hypercall_slow(unsigned long cmd,
+ unsigned long in1, unsigned long in3,
+ unsigned long in4, unsigned long in5,
+ u32 *out1, u32 *out2, u32 *out3,
+ u32 *out4, u32 *out5);
+
+/*
+ * The low bandwidth call. The low word of %edx is presumed to have OUT bit
+ * set. The high word of %edx may contain input data from the caller.
*/
+#define VMWARE_HYPERCALL \
+ ALTERNATIVE_2("movw %[port], %%dx\n\t" \
+ "inl (%%dx), %%eax", \
+ "vmcall", X86_FEATURE_VMCALL, \
+ "vmmcall", X86_FEATURE_VMW_VMMCALL)
+
+static inline
+unsigned long vmware_hypercall1(unsigned long cmd, unsigned long in1)
+{
+ unsigned long out0;
+
+ if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
+ return vmware_hypercall_slow(cmd, in1, 0, 0, 0,
+ NULL, NULL, NULL, NULL, NULL);
+
+ asm_inline volatile (VMWARE_HYPERCALL
+ : "=a" (out0)
+ : [port] "i" (VMWARE_HYPERVISOR_PORT),
+ "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (0)
+ : "cc", "memory");
+ return out0;
+}
+
+static inline
+unsigned long vmware_hypercall3(unsigned long cmd, unsigned long in1,
+ u32 *out1, u32 *out2)
+{
+ unsigned long out0;
+
+ if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
+ return vmware_hypercall_slow(cmd, in1, 0, 0, 0,
+ out1, out2, NULL, NULL, NULL);
+
+ asm_inline volatile (VMWARE_HYPERCALL
+ : "=a" (out0), "=b" (*out1), "=c" (*out2)
+ : [port] "i" (VMWARE_HYPERVISOR_PORT),
+ "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (0)
+ : "cc", "memory");
+ return out0;
+}
+
+static inline
+unsigned long vmware_hypercall4(unsigned long cmd, unsigned long in1,
+ u32 *out1, u32 *out2, u32 *out3)
+{
+ unsigned long out0;
+
+ if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
+ return vmware_hypercall_slow(cmd, in1, 0, 0, 0,
+ out1, out2, out3, NULL, NULL);
+
+ asm_inline volatile (VMWARE_HYPERCALL
+ : "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
+ : [port] "i" (VMWARE_HYPERVISOR_PORT),
+ "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (0)
+ : "cc", "memory");
+ return out0;
+}
+
+static inline
+unsigned long vmware_hypercall5(unsigned long cmd, unsigned long in1,
+ unsigned long in3, unsigned long in4,
+ unsigned long in5, u32 *out2)
+{
+ unsigned long out0;
+
+ if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
+ return vmware_hypercall_slow(cmd, in1, in3, in4, in5,
+ NULL, out2, NULL, NULL, NULL);
+
+ asm_inline volatile (VMWARE_HYPERCALL
+ : "=a" (out0), "=c" (*out2)
+ : [port] "i" (VMWARE_HYPERVISOR_PORT),
+ "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
+ return out0;
+}
+
+static inline
+unsigned long vmware_hypercall6(unsigned long cmd, unsigned long in1,
+ unsigned long in3, u32 *out2,
+ u32 *out3, u32 *out4, u32 *out5)
+{
+ unsigned long out0;
+
+ if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
+ return vmware_hypercall_slow(cmd, in1, in3, 0, 0,
+ NULL, out2, out3, out4, out5);
+
+ asm_inline volatile (VMWARE_HYPERCALL
+ : "=a" (out0), "=c" (*out2), "=d" (*out3), "=S" (*out4),
+ "=D" (*out5)
+ : [port] "i" (VMWARE_HYPERVISOR_PORT),
+ "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3)
+ : "cc", "memory");
+ return out0;
+}
+
+static inline
+unsigned long vmware_hypercall7(unsigned long cmd, unsigned long in1,
+ unsigned long in3, unsigned long in4,
+ unsigned long in5, u32 *out1,
+ u32 *out2, u32 *out3)
+{
+ unsigned long out0;
+
+ if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
+ return vmware_hypercall_slow(cmd, in1, in3, in4, in5,
+ out1, out2, out3, NULL, NULL);
+
+ asm_inline volatile (VMWARE_HYPERCALL
+ : "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
+ : [port] "i" (VMWARE_HYPERVISOR_PORT),
+ "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
+ return out0;
+}
+
+#ifdef CONFIG_X86_64
+#define VMW_BP_CONSTRAINT "r"
+#else
+#define VMW_BP_CONSTRAINT "m"
+#endif
+
+/*
+ * High bandwidth calls are not supported on encrypted memory guests.
+ * The caller should check cc_platform_has(CC_ATTR_MEM_ENCRYPT) and use
+ * low bandwidth hypercall if memory encryption is set.
+ * This assumption simplifies HB hypercall implementation to just I/O port
+ * based approach without alternative patching.
+ */
+static inline
+unsigned long vmware_hypercall_hb_out(unsigned long cmd, unsigned long in2,
+ unsigned long in3, unsigned long in4,
+ unsigned long in5, unsigned long in6,
+ u32 *out1)
+{
+ unsigned long out0;
+
+ asm_inline volatile (
+ UNWIND_HINT_SAVE
+ "push %%" _ASM_BP "\n\t"
+ UNWIND_HINT_UNDEFINED
+ "mov %[in6], %%" _ASM_BP "\n\t"
+ "rep outsb\n\t"
+ "pop %%" _ASM_BP "\n\t"
+ UNWIND_HINT_RESTORE
+ : "=a" (out0), "=b" (*out1)
+ : "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (cmd),
+ "c" (in2),
+ "d" (in3 | VMWARE_HYPERVISOR_PORT_HB),
+ "S" (in4),
+ "D" (in5),
+ [in6] VMW_BP_CONSTRAINT (in6)
+ : "cc", "memory");
+ return out0;
+}
-/* Old port-based version */
-#define VMWARE_HYPERVISOR_PORT 0x5658
-#define VMWARE_HYPERVISOR_PORT_HB 0x5659
+static inline
+unsigned long vmware_hypercall_hb_in(unsigned long cmd, unsigned long in2,
+ unsigned long in3, unsigned long in4,
+ unsigned long in5, unsigned long in6,
+ u32 *out1)
+{
+ unsigned long out0;
-/* Current vmcall / vmmcall version */
-#define VMWARE_HYPERVISOR_HB BIT(0)
-#define VMWARE_HYPERVISOR_OUT BIT(1)
+ asm_inline volatile (
+ UNWIND_HINT_SAVE
+ "push %%" _ASM_BP "\n\t"
+ UNWIND_HINT_UNDEFINED
+ "mov %[in6], %%" _ASM_BP "\n\t"
+ "rep insb\n\t"
+ "pop %%" _ASM_BP "\n\t"
+ UNWIND_HINT_RESTORE
+ : "=a" (out0), "=b" (*out1)
+ : "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (cmd),
+ "c" (in2),
+ "d" (in3 | VMWARE_HYPERVISOR_PORT_HB),
+ "S" (in4),
+ "D" (in5),
+ [in6] VMW_BP_CONSTRAINT (in6)
+ : "cc", "memory");
+ return out0;
+}
+#undef VMW_BP_CONSTRAINT
+#undef VMWARE_HYPERCALL
/* The low bandwidth call. The low word of edx is presumed clear. */
#define VMWARE_HYPERCALL \
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 11f83d07925e..533ac2d1de88 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -41,17 +41,9 @@
#define CPUID_VMWARE_INFO_LEAF 0x40000000
#define CPUID_VMWARE_FEATURES_LEAF 0x40000010
-#define CPUID_VMWARE_FEATURES_ECX_VMMCALL BIT(0)
-#define CPUID_VMWARE_FEATURES_ECX_VMCALL BIT(1)
-#define VMWARE_HYPERVISOR_MAGIC 0x564D5868
-
-#define VMWARE_CMD_GETVERSION 10
-#define VMWARE_CMD_GETHZ 45
-#define VMWARE_CMD_GETVCPU_INFO 68
#define VMWARE_CMD_LEGACY_X2APIC 3
#define VMWARE_CMD_VCPU_RESERVED 31
-#define VMWARE_CMD_STEALCLOCK 91
#define STEALCLOCK_NOT_AVAILABLE (-1)
#define STEALCLOCK_DISABLED 0
@@ -110,6 +102,56 @@ struct vmware_steal_time {
static unsigned long vmware_tsc_khz __ro_after_init;
static u8 vmware_hypercall_mode __ro_after_init;
+unsigned long vmware_hypercall_slow(unsigned long cmd,
+ unsigned long in1, unsigned long in3,
+ unsigned long in4, unsigned long in5,
+ u32 *out1, u32 *out2, u32 *out3,
+ u32 *out4, u32 *out5)
+{
+ unsigned long out0;
+
+ switch (vmware_hypercall_mode) {
+ case CPUID_VMWARE_FEATURES_ECX_VMCALL:
+ asm_inline volatile ("vmcall"
+ : "=a" (out0), "=b" (*out1), "=c" (*out2),
+ "=d" (*out3), "=S" (*out4), "=D" (*out5)
+ : "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
+ break;
+ case CPUID_VMWARE_FEATURES_ECX_VMMCALL:
+ asm_inline volatile ("vmmcall"
+ : "=a" (out0), "=b" (*out1), "=c" (*out2),
+ "=d" (*out3), "=S" (*out4), "=D" (*out5)
+ : "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
+ break;
+ default:
+ asm_inline volatile ("movw %[port], %%dx; inl (%%dx), %%eax"
+ : "=a" (out0), "=b" (*out1), "=c" (*out2),
+ "=d" (*out3), "=S" (*out4), "=D" (*out5)
+ : [port] "i" (VMWARE_HYPERVISOR_PORT),
+ "a" (VMWARE_HYPERVISOR_MAGIC),
+ "b" (in1),
+ "c" (cmd),
+ "d" (in3),
+ "S" (in4),
+ "D" (in5)
+ : "cc", "memory");
+ break;
+ }
+ return out0;
+}
+
static inline int __vmware_platform(void)
{
uint32_t eax, ebx, ecx, edx;
--
2.39.0
^ permalink raw reply related
* Re: [PATCH v10 1/8] x86/vmware: Introduce VMware hypercall API
From: Alexey Makhalov @ 2024-06-06 23:18 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-kernel, virtualization, hpa, dave.hansen, mingo, tglx, x86,
netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, timothym, akaher,
dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms, kirill.shutemov
In-Reply-To: <20240603175844.GKZl4EVGUxp2aQZnYJ@fat_crate.local>
On 6/3/24 10:58 AM, Borislav Petkov wrote:
> On Wed, May 29, 2024 at 05:44:32PM -0700, Alexey Makhalov wrote:
>> While most of the vmware_hypercall callers are executed after alternative
>> patching applied, there are small amount of hypercalls running before that.
>> Only for them we have the logic of analyzing vmware_hypercall_mode as a
>> default alternative code. And there are 2 constraints:
>> 1. vmcall/vmmcall are not supported by old ESXi/Workstation/Fusion. We have
>> to use in/out instructions. After the end of support of old hypervisors the
>> alternative can be simplified as follow:
>> ALTERNATIVE("vmcall", "vmmcall", X86_FEATURE_VMW_VMMCALL);
>> 2. SEV-ES enabled VMs should use _only_ vmcall/vmmcall as in/out
>> instructions cause faults.
>>
>> Another approach that we discussed internally was to use
>> ALTERNATIVE_2("movw %[port], %%dx; "inl (%%dx), %%eax", "vmcall",
>> X86_FEATURE_VMW_VMCALL, "vmmcall", X86_FEATURE_VMW_VMMCALL) for
>> vmware_hypercallX family of functions, _and_ to have a separate API
>> vmware_sev_hypercallX, with the silly dance without an alternative inside,
>> to be used only by early boot code, before alternative application. But,
>> it's error prone when things come to boot time related code movements or
>> rearrangements as it puts additional requirement for SEV-ES
>> understanding/testing for VMware guests.
>
> Right, so since we're exporting that alternatives_patched thing already,
> you might also try to do:
>
> if (unlikely(!alternatives_patched))
> return slow_hypercall_X_in_c();
>
> asm_inline volatile(VMWARE_HYPERCALL...
>
> where that slow_hypercall_X_in_c()* set of APIs does the checks in C.
>
> And the VMWARE_HYPERCALL thing is a lot simpler then.
>
> All in all, you'll have a lot less unreadable asm to pay attention to
> and those APIs should be all easy and readable.
>
Thanks for the idea.
I improved the condition to eliminate slow path for modules such as
vmmouse, vmwgfx.
if (unlikely(!alternatives_patched) && !__is_defined(MODULE))
return vmware_hypercall_slow(...);
It also drops the need for exporting vmware_hypercall_mode or
vmware_hypercall_slow symbols.
Will post just Patch0001 for review here before sending v11 out.
^ permalink raw reply
* Re: [PATCH v13 3/3] Input: Add TouchNetix axiom i2c touchscreen driver
From: Dmitry Torokhov @ 2024-06-06 21:32 UTC (permalink / raw)
To: Kamel BOUHARA
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg,
linux-input, linux-kernel, devicetree, Marco Felsch, Jeff LaBundy,
catalin.popescu, mark.satterthwaite, Thomas Petazzoni,
Gregory Clement, bsp-development.geo
In-Reply-To: <7ca4a22f903313128de5c0f65a49b319@bootlin.com>
On Wed, Jun 05, 2024 at 03:48:20PM +0200, Kamel BOUHARA wrote:
> [...]
>
> > > > +
> > > > + error = devm_request_threaded_irq(dev, client->irq, NULL,
> > > > + axiom_irq, IRQF_ONESHOT, dev_name(dev), ts);
> > > > + if (error) {
> > > > + dev_info(dev, "Request irq failed, falling back to polling mode");
> > >
> > > I do not think you should fall back to polling mode if you fail to get
> > > interrupt. If it was not specified (client->irq) then I can see that
> > > we
> > > might want to fall back, but if the system configured for using
> > > interrupt and you can not get it you should bail out.
> > >
> >
> > Yes, clear, the polling mode can be decorrelated to the irq not provided
> > case.
>
> Just to make sure I understood, is this what you propose ?
>
> if (client->irq) {
> error = devm_request_threaded_irq(...)
> if (error) {
> dev_warn(dev, "failed to request IRQ\n");
> client->irq = 0;
> }
> }
>
> if(!client->irq) {
> // setup polling stuff
> ...
> }
No, if you fail to acquire interrupt that was described in ACPI/DT it
should be treated as an error, like this:
if (client->irq) {
error = devm_request_threaded_irq(...)
if (error)
return dev_err_probe(...);
} else {
.. set up polling ..
}
This also makes sure that if interrupt controller is not ready and
requests probe deferral we will not end up with device in polling mode.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: wacom_i2c - Clean up the query device fields
From: Dmitry Torokhov @ 2024-06-06 21:25 UTC (permalink / raw)
To: Alistair Francis; +Cc: linux-input, linux-kernel, alistair23
In-Reply-To: <ZmIozAu-R1nbRYHF@google.com>
On Thu, Jun 06, 2024 at 02:23:24PM -0700, Dmitry Torokhov wrote:
> Hi Alistair,
>
> On Thu, Nov 18, 2021 at 10:35:45PM +1000, Alistair Francis wrote:
> > Improve the query device fields to be more verbose.
> >
> > Signed-off-by: Alistair Francis <alistair@alistair23.me>
>
> Could you please list what has changed since v1?
Ugh, sorry, I did not realize that this is an older patch that I already
applied...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: wacom_i2c - Clean up the query device fields
From: Dmitry Torokhov @ 2024-06-06 21:23 UTC (permalink / raw)
To: Alistair Francis; +Cc: linux-input, linux-kernel, alistair23
In-Reply-To: <20211118123545.102872-1-alistair@alistair23.me>
Hi Alistair,
On Thu, Nov 18, 2021 at 10:35:45PM +1000, Alistair Francis wrote:
> Improve the query device fields to be more verbose.
>
> Signed-off-by: Alistair Francis <alistair@alistair23.me>
Could you please list what has changed since v1?
> ---
> drivers/input/touchscreen/wacom_i2c.c | 45 ++++++++++++++++-----------
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/input/touchscreen/wacom_i2c.c b/drivers/input/touchscreen/wacom_i2c.c
> index fe4ea6204a4e..50d159919bd1 100644
> --- a/drivers/input/touchscreen/wacom_i2c.c
> +++ b/drivers/input/touchscreen/wacom_i2c.c
> @@ -23,13 +23,20 @@
> #define WACOM_BARREL_SWITCH_2 BIT(4)
> #define WACOM_IN_PROXIMITY BIT(5)
>
> -/* Registers */
> -#define WACOM_CMD_QUERY0 0x04
> -#define WACOM_CMD_QUERY1 0x00
> -#define WACOM_CMD_QUERY2 0x33
> -#define WACOM_CMD_QUERY3 0x02
> -#define WACOM_CMD_THROW0 0x05
> -#define WACOM_CMD_THROW1 0x00
> +// Registers
I am partial to C-style comments, let's keep them.
> +#define WACOM_COMMAND_LSB 0x04
> +#define WACOM_COMMAND_MSB 0x00
> +
> +#define WACOM_DATA_LSB 0x05
> +#define WACOM_DATA_MSB 0x00
> +
> +// Report types
> +#define REPORT_FEATURE 0x30
> +
> +// Requests / operations
> +#define OPCODE_GET_REPORT 0x02
> +
> +#define WACOM_QUERY_REPORT 3
> #define WACOM_QUERY_SIZE 19
>
> struct wacom_features {
> @@ -51,22 +58,24 @@ static int wacom_query_device(struct i2c_client *client,
> struct wacom_features *features)
> {
> int ret;
> - u8 cmd1[] = { WACOM_CMD_QUERY0, WACOM_CMD_QUERY1,
> - WACOM_CMD_QUERY2, WACOM_CMD_QUERY3 };
> - u8 cmd2[] = { WACOM_CMD_THROW0, WACOM_CMD_THROW1 };
> u8 data[WACOM_QUERY_SIZE];
> +
> + u8 get_query_data_cmd[] = {
> + WACOM_COMMAND_LSB,
> + WACOM_COMMAND_MSB,
> + REPORT_FEATURE | WACOM_QUERY_REPORT,
> + OPCODE_GET_REPORT,
> + WACOM_DATA_LSB,
> + WACOM_DATA_MSB,
> + };
> +
> struct i2c_msg msgs[] = {
> + // Request reading of feature ReportID: 3 (Pen Query Data)
> {
> .addr = client->addr,
> .flags = 0,
> - .len = sizeof(cmd1),
> - .buf = cmd1,
> - },
> - {
> - .addr = client->addr,
> - .flags = 0,
> - .len = sizeof(cmd2),
> - .buf = cmd2,
> + .len = sizeof(get_query_data_cmd),
> + .buf = get_query_data_cmd,
This combines writes into one message. Is this safe and works for all
devices? At the very least this needs to be mentioned in the patch
description.
> },
> {
> .addr = client->addr,
> --
> 2.31.1
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: wacom_w8001: Correct device name generation
From: Dmitry Torokhov @ 2024-06-06 21:09 UTC (permalink / raw)
To: Gerecke, Jason
Cc: linux-input, Ping Cheng, Aaron Armstrong Skomra, Joshua Dickens,
Jason Gerecke
In-Reply-To: <20240605164656.61623-1-jason.gerecke@wacom.com>
On Wed, Jun 05, 2024 at 09:46:56AM -0700, Gerecke, Jason wrote:
> From: Jason Gerecke <jason.gerecke@wacom.com>
>
> Fixes: 6c7cc1a29d1e ("Input: wacom_w8001 - simplify device name generation")
> Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 0/2] asus wmi and hid: use HID LED for brightness
From: Luke Jones @ 2024-06-06 21:02 UTC (permalink / raw)
To: Hans de Goede, Benjamin Tissoires
Cc: Jiri Kosina, Ilpo Järvinen, corentin.chary,
platform-driver-x86, linux-kernel, linux-input
In-Reply-To: <fc03506c-210f-4d79-9a99-8bc9b0587d25@redhat.com>
On Thu, 6 Jun 2024, at 9:53 PM, Hans de Goede wrote:
> Hi Benjamin,
>
> On 6/6/24 10:49 AM, Benjamin Tissoires wrote:
> > On May 29 2024, Hans de Goede wrote:
> >> Hi all,
> >>
> >> On 5/29/24 3:28 AM, Luke D. Jones wrote:
> >>> Changelog:
> >>> - v1
> >>> - Split the patch in two
> >>> - Move function body to asus-wmi and export
> >>> - Use array of names and for loops
> >>>
> >>> History:
> >>> - https://lore.kernel.org/linux-input/20240528013959.14661-1-luke@ljones.dev/T/#u
> >>>
> >>> Luke D. Jones (2):
> >>> hid-asus: use hid for brightness control on keyboard
> >>> hid-asus: change the report_id used for HID LED control
> >>>
> >>> drivers/hid/hid-asus.c | 32 +++++++++++++++++++-
> >>> drivers/platform/x86/asus-wmi.c | 35 +++++++++++++++++++++-
> >>> include/linux/platform_data/x86/asus-wmi.h | 10 +++++++
> >>> 3 files changed, 75 insertions(+), 2 deletions(-)
> >>
> >> Jiri, Benjamin since the first patch now also touches pdx86 files
> >> we need to coordinate merging this.
> >>
> >> There also is a long list of patches pending for
> >> drivers/platform/x86/asus-wmi.c
> >>
> >> So I would prefer to take this series (both patches) upstream through
> >> the pdx86 tree to avoid conflicts.
> >>
> >> May we have an ack from one of you for merging this through pdx86/for-next ?
> >
> > Sure:
> > Acked-by: Benjamin Tissoires <bentiss@kernel.org>
>
> Thank you for the ack.
>
> > But I haven't seen the v2. Are you sure you want to take this series as
> > it is?
>
> No I plan to wait for v2, I just thought it would be good to have
> an ack to merge this through the pdx86 tree beforehand.
My apologies for the delay, I have v2 prepped, but I'm waiting on feedback from a few folks regarding the 2024 G16 and G14, plus the TUF laptops - these are possibly affected by the patch. Shouldn't be more than a day or two now.
Regards,
Luke.
^ permalink raw reply
* Re: [PATCH v11 1/4] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Andy Shevchenko @ 2024-06-06 19:49 UTC (permalink / raw)
To: Danny Kaehn
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires, Jiri Kosina,
devicetree, linux-input, Dmitry Torokhov, Bartosz Golaszewski,
Ethan Twardy
In-Reply-To: <20240606162438.GA77976@LNDCL34533.neenah.na.plexus.com>
On Thu, Jun 06, 2024 at 11:24:38AM -0500, Danny Kaehn wrote:
> On Thu, Jun 06, 2024 at 09:18:59AM -0600, Rob Herring wrote:
> > On Wed, Jun 05, 2024 at 06:12:44PM -0500, Danny Kaehn wrote:
...
> > > + i2c:
> > > + description: The SMBus/I2C controller node for the CP2112
> > > + $ref: /schemas/i2c/i2c-controller.yaml#
> > > + unevaluatedProperties: false
> > > +
> > > + properties:
> > > + sda-gpios:
> > > + maxItems: 1
> > > +
> > > + scl-gpios:
> > > + maxItems: 1
> >
> > These are because I2C can be on any of the pins? It's a bit odd if they
> > aren't used as gpios. Probably should be pinmux, but that's overkill for
> > 2 pins.
> >
>
> I'm beginning to realize now that this may be a bit non-standard, but it
> did solve a stuck bus issue under some conditions.
>
> The CP2112's I2C controller is self-contained and can only be on the
> specific pins it is attached to (no pinmux, etc..).
>
> In this case, these properties are ment to specify additional gpio pins
> which are connected to the SCL and SDA lines (this then also assumes those
> are configured to be open drain / inputs to not interfere with the bus
> during normal operation). This was inspired by what is done ini2c-imx.yaml,
> but I realize this is a bit different due to using external pins rather
> than pinmuxing to the GPIOs.
>
> How I used this was to actually connect some of the CP2112's own GPIO pins
> to the SDA and SCL lines to be able to use those pins to recover the
> bus. This was able to solve a stuck bus under some real-world cases with
> the v2 of the CP2112 containing an errata which caused this
> semi-frequently.
Aren't they just for I²C recovery?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v11 0/4] Firmware Support for USB-HID Devices and CP2112
From: Andy Shevchenko @ 2024-06-06 19:47 UTC (permalink / raw)
To: Danny Kaehn
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires, Jiri Kosina,
devicetree, linux-input, Dmitry Torokhov, Bartosz Golaszewski,
Ethan Twardy
In-Reply-To: <20240606155453.GA54873@LNDCL34533.neenah.na.plexus.com>
On Thu, Jun 06, 2024 at 10:54:53AM -0500, Danny Kaehn wrote:
> On Thu, Jun 06, 2024 at 02:42:42AM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 05, 2024 at 06:12:43PM -0500, Danny Kaehn wrote:
...
> > > Changes in v11:
> > > - Eliminate 'gpio' subnode for DT and ACPI for the CP2112 per comment
> > > from Rob H.
> >
> > Hmm... I don't know much about DT, but how is this supposed to work in ACPI?
> > I mean if we want to refer to the GPIO in GpioIo() or GpioInt() resources,
> > what should we put there as ACPI path?
>
> What I tested was essentially taking what Benjamin had done in [1], just
> removing the "GPIO" device and combining it with the parent device (the
> CP2112 itself). So for the example below, I believe the path would be
> "\_SB_.PCI0.SE9_.RHUB.CP2_". If I get the chance (and can figure out how
> to do it using ACPI) I'll try to add a "gpio-keys" or something to the
> system using this path and make sure that works.
This is counter intuitive and doesn't follow other (ACPI) devices with GPIO.
So whatever you do for DT I don't care much, but let's not remove subnode
for ACPI case.
...
> Full example within context:
Thank you!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH V2 5/5] Add support for Awinic sar sensor.
From: kernel test robot @ 2024-06-06 18:32 UTC (permalink / raw)
To: wangshuaijie, dmitry.torokhov, robh, krzk+dt, conor+dt, jeff,
linux-input, devicetree, linux-kernel
Cc: oe-kbuild-all, wangshuaijie, liweilei, kangjiajun
In-Reply-To: <20240605091143.163789-6-wangshuaijie@awinic.com>
Hi,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 32f88d65f01bf6f45476d7edbe675e44fb9e1d58]
url: https://github.com/intel-lab-lkp/linux/commits/wangshuaijie-awinic-com/dt-bindings-input-Add-YAML-to-Awinic-sar-sensor/20240605-172023
base: 32f88d65f01bf6f45476d7edbe675e44fb9e1d58
patch link: https://lore.kernel.org/r/20240605091143.163789-6-wangshuaijie%40awinic.com
patch subject: [PATCH V2 5/5] Add support for Awinic sar sensor.
config: x86_64-randconfig-102-20240607 (https://download.01.org/0day-ci/archive/20240607/202406070207.ncwHTWh4-lkp@intel.com/config)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
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/202406070207.ncwHTWh4-lkp@intel.com/
cocci warnings: (new ones prefixed by >>)
>> drivers/input/misc/aw_sar/aw_sar.c:2006:3-8: No need to set .owner here. The core will do it.
vim +2006 drivers/input/misc/aw_sar/aw_sar.c
2002
2003 static struct i2c_driver aw_sar_i2c_driver = {
2004 .driver = {
2005 .name = AW_SAR_I2C_NAME,
> 2006 .owner = THIS_MODULE,
2007 .of_match_table = aw_sar_dt_match,
2008 .pm = &aw_sar_pm_ops,
2009 },
2010 .probe = aw_sar_i2c_probe,
2011 .remove = aw_sar_i2c_remove,
2012 .shutdown = aw_sar_i2c_shutdown,
2013 .id_table = aw_sar_i2c_id,
2014 };
2015
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH 1/2] dt-bindings: input: qcom,pm8xxx-vib: Document PM6150 compatible
From: Jens Reidel @ 2024-06-06 18:10 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzk+dt, conor+dt, andersson,
konrad.dybcio
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel, Jens Reidel
In-Reply-To: <20240606181027.98537-1-adrian@travitia.xyz>
The PM6150 vibrator module is compatible with the PMI632 vibrator
module, document the PM6150 vibrator compatible as fallback for the
PMI632 vibrator.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
---
Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
index 2025d6a5423e..76a286ec5959 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
@@ -19,6 +19,7 @@ properties:
- qcom,pmi632-vib
- items:
- enum:
+ - qcom,pm6150-vib
- qcom,pm7250b-vib
- qcom,pm7325b-vib
- qcom,pm7550ba-vib
--
2.45.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: pm6150: Add vibrator
From: Jens Reidel @ 2024-06-06 18:10 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzk+dt, conor+dt, andersson,
konrad.dybcio
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel, Jens Reidel
In-Reply-To: <20240606181027.98537-1-adrian@travitia.xyz>
Add a node for the vibrator module found inside the PM6150.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
---
arch/arm64/boot/dts/qcom/pm6150.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pm6150.dtsi b/arch/arm64/boot/dts/qcom/pm6150.dtsi
index 6de6ed562d97..d48cf92bda78 100644
--- a/arch/arm64/boot/dts/qcom/pm6150.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm6150.dtsi
@@ -166,5 +166,11 @@ pm6150_lsid1: pmic@1 {
reg = <0x1 SPMI_USID>;
#address-cells = <1>;
#size-cells = <0>;
+
+ pm6150_vib: vibrator@5300 {
+ compatible = "qcom,pm6150-vib", "qcom,pmi632-vib";
+ reg = <0x5300>;
+ status = "disabled";
+ };
};
};
--
2.45.1
^ permalink raw reply related
* [PATCH 0/2] Add vibrator support for PM6150 PMIC
From: Jens Reidel @ 2024-06-06 18:10 UTC (permalink / raw)
To: dmitry.torokhov, robh, krzk+dt, conor+dt, andersson,
konrad.dybcio
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel, Jens Reidel
This series adds vibrator support for PM6150. Was tested on SM7150
(xiaomi-davinci).
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Jens Reidel (2):
dt-bindings: input: qcom,pm8xxx-vib: Document PM6150 compatible
arm64: dts: qcom: pm6150: Add vibrator
.../devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 1 +
arch/arm64/boot/dts/qcom/pm6150.dtsi | 6 ++++++
2 files changed, 7 insertions(+)
--
2.45.1
^ permalink raw reply
* [PATCH 0/3 v4] Add cros-ec-keyboard v3.0
From: Daisuke Nojiri @ 2024-06-06 17:40 UTC (permalink / raw)
Cc: dmitry.torokhov, robh, krzk+dt, conor+dt, bleung, groeck,
linux-input, devicetree, chrome-platform, linux-kernel, pmalani,
swboyd, hverkuil-cisco, rekanorman, abhishekpandit, pholla,
chingkang, lma, Daisuke Nojiri
In-Reply-To: <20240604005354.2294468-1-dnojiri@chromium.org>
This patch series adds a support for cros-ec-keyboard v3.0, which uses a
reorganized and larger keyboard matrix thus also requires a protocol update.
---
Changes in v4:
- Change subject line: ARM:... to dt-bindings:...
- Add description about keyboard matrix v3.0.
- Add cover letter.
---
Changes in v3:
- Remove CROS_KBD_V30 in Kconfig and macros conditionally set in
cros-ec-keyboard.dtsi.
---
Changes in v2:
- Separate cros_ec_commands.h from cros_ec_proto.{c.h}.
- Remove Change-Id, TEST=, BUG= lines.
Daisuke Nojiri (3):
platform/chrome: Add struct ec_response_get_next_event_v3
platform/chrome: cros_ec_proto: Upgrade get_next_event to v3
dt-bindings: cros-ec-keyboard: Add keyboard matrix v3.0
drivers/platform/chrome/cros_ec_proto.c | 27 +++--
include/dt-bindings/input/cros-ec-keyboard.h | 104 ++++++++++++++++++
.../linux/platform_data/cros_ec_commands.h | 34 ++++++
include/linux/platform_data/cros_ec_proto.h | 2 +-
4 files changed, 157 insertions(+), 10 deletions(-)
--
2.45.2.505.gda0bf45e8d-goog
^ permalink raw reply
* [PATCH 3/3 v4] dt-bindings: cros-ec-keyboard: Add keyboard matrix v3.0
From: Daisuke Nojiri @ 2024-06-06 17:34 UTC (permalink / raw)
Cc: Daisuke Nojiri, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Benson Leung, Guenter Roeck, linux-input,
devicetree, chrome-platform, linux-kernel
In-Reply-To: <20240606173509.243739-1-dnojiri@chromium.org>
Add support for keyboard matrix version 3.0, which reduces keyboard
ghosting.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
---
include/dt-bindings/input/cros-ec-keyboard.h | 104 +++++++++++++++++++
1 file changed, 104 insertions(+)
diff --git a/include/dt-bindings/input/cros-ec-keyboard.h b/include/dt-bindings/input/cros-ec-keyboard.h
index f0ae03634a96..afc12f6aa642 100644
--- a/include/dt-bindings/input/cros-ec-keyboard.h
+++ b/include/dt-bindings/input/cros-ec-keyboard.h
@@ -100,4 +100,108 @@
MATRIX_KEY(0x07, 0x0b, KEY_UP) \
MATRIX_KEY(0x07, 0x0c, KEY_LEFT)
+/* No numpad */
+#define CROS_TOP_ROW_KEYMAP_V30 \
+ MATRIX_KEY(0x00, 0x01, KEY_F11) /* T11 */ \
+ MATRIX_KEY(0x00, 0x02, KEY_F1) /* T1 */ \
+ MATRIX_KEY(0x00, 0x04, KEY_F10) /* T10 */ \
+ MATRIX_KEY(0x00, 0x0b, KEY_F14) /* T14 */ \
+ MATRIX_KEY(0x00, 0x0c, KEY_F15) /* T15 */ \
+ MATRIX_KEY(0x01, 0x02, KEY_F4) /* T4 */ \
+ MATRIX_KEY(0x01, 0x04, KEY_F7) /* T7 */ \
+ MATRIX_KEY(0x01, 0x05, KEY_F12) /* T12 */ \
+ MATRIX_KEY(0x01, 0x09, KEY_F9) /* T9 */ \
+ MATRIX_KEY(0x02, 0x02, KEY_F3) /* T3 */ \
+ MATRIX_KEY(0x02, 0x04, KEY_F6) /* T6 */ \
+ MATRIX_KEY(0x02, 0x0b, KEY_F8) /* T8 */ \
+ MATRIX_KEY(0x03, 0x02, KEY_F2) /* T2 */ \
+ MATRIX_KEY(0x03, 0x05, KEY_F13) /* T13 */ \
+ MATRIX_KEY(0x04, 0x04, KEY_F5) /* T5 */
+
+#define CROS_MAIN_KEYMAP_V30 /* Keycode */ \
+ MATRIX_KEY(0x00, 0x03, KEY_B) /* 50 */ \
+ MATRIX_KEY(0x00, 0x05, KEY_N) /* 51 */ \
+ MATRIX_KEY(0x00, 0x06, KEY_RO) /* 56 (JIS) */ \
+ MATRIX_KEY(0x00, 0x08, KEY_EQUAL) /* 13 */ \
+ MATRIX_KEY(0x00, 0x09, KEY_HOME) /* 80 (Numpad) */ \
+ MATRIX_KEY(0x00, 0x0a, KEY_RIGHTALT) /* 62 */ \
+ MATRIX_KEY(0x00, 0x10, KEY_FN) /* 127 */ \
+ \
+ MATRIX_KEY(0x01, 0x01, KEY_ESC) /* 110 */ \
+ MATRIX_KEY(0x01, 0x03, KEY_G) /* 35 */ \
+ MATRIX_KEY(0x01, 0x06, KEY_H) /* 36 */ \
+ MATRIX_KEY(0x01, 0x08, KEY_APOSTROPHE) /* 41 */ \
+ MATRIX_KEY(0x01, 0x0b, KEY_BACKSPACE) /* 15 */ \
+ MATRIX_KEY(0x01, 0x0c, KEY_HENKAN) /* 65 (JIS) */ \
+ MATRIX_KEY(0x01, 0x0e, KEY_LEFTCTRL) /* 58 */ \
+ \
+ MATRIX_KEY(0x02, 0x01, KEY_TAB) /* 16 */ \
+ MATRIX_KEY(0x02, 0x03, KEY_T) /* 21 */ \
+ MATRIX_KEY(0x02, 0x05, KEY_RIGHTBRACE) /* 28 */ \
+ MATRIX_KEY(0x02, 0x06, KEY_Y) /* 22 */ \
+ MATRIX_KEY(0x02, 0x08, KEY_LEFTBRACE) /* 27 */ \
+ MATRIX_KEY(0x02, 0x09, KEY_DELETE) /* 76 (Numpad) */ \
+ MATRIX_KEY(0x02, 0x0c, KEY_PAGEUP) /* 85 (Numpad) */ \
+ MATRIX_KEY(0x02, 0x011, KEY_YEN) /* 14 (JIS) */ \
+ \
+ MATRIX_KEY(0x03, 0x00, KEY_LEFTMETA) /* Launcher */ \
+ MATRIX_KEY(0x03, 0x01, KEY_GRAVE) /* 1 */ \
+ MATRIX_KEY(0x03, 0x03, KEY_5) /* 6 */ \
+ MATRIX_KEY(0x03, 0x04, KEY_S) /* 32 */ \
+ MATRIX_KEY(0x03, 0x06, KEY_MINUS) /* 12 */ \
+ MATRIX_KEY(0x03, 0x08, KEY_6) /* 7 */ \
+ MATRIX_KEY(0x03, 0x09, KEY_SLEEP) /* Lock */ \
+ MATRIX_KEY(0x03, 0x0b, KEY_BACKSLASH) /* 29 */ \
+ MATRIX_KEY(0x03, 0x0c, KEY_MUHENKAN) /* 63 (JIS) */ \
+ MATRIX_KEY(0x03, 0x0e, KEY_RIGHTCTRL) /* 64 */ \
+ \
+ MATRIX_KEY(0x04, 0x01, KEY_A) /* 31 */ \
+ MATRIX_KEY(0x04, 0x02, KEY_D) /* 33 */ \
+ MATRIX_KEY(0x04, 0x03, KEY_F) /* 34 */ \
+ MATRIX_KEY(0x04, 0x05, KEY_K) /* 38 */ \
+ MATRIX_KEY(0x04, 0x06, KEY_J) /* 37 */ \
+ MATRIX_KEY(0x04, 0x08, KEY_SEMICOLON) /* 40 */ \
+ MATRIX_KEY(0x04, 0x09, KEY_L) /* 39 */ \
+ MATRIX_KEY(0x04, 0x0b, KEY_ENTER) /* 43 */ \
+ MATRIX_KEY(0x04, 0x0c, KEY_END) /* 81 (Numpad) */ \
+ \
+ MATRIX_KEY(0x05, 0x01, KEY_1) /* 2 */ \
+ MATRIX_KEY(0x05, 0x02, KEY_COMMA) /* 53 */ \
+ MATRIX_KEY(0x05, 0x03, KEY_DOT) /* 54 */ \
+ MATRIX_KEY(0x05, 0x04, KEY_SLASH) /* 55 */ \
+ MATRIX_KEY(0x05, 0x05, KEY_C) /* 48 */ \
+ MATRIX_KEY(0x05, 0x06, KEY_SPACE) /* 61 */ \
+ MATRIX_KEY(0x05, 0x07, KEY_LEFTSHIFT) /* 44 */ \
+ MATRIX_KEY(0x05, 0x08, KEY_X) /* 47 */ \
+ MATRIX_KEY(0x05, 0x09, KEY_V) /* 49 */ \
+ MATRIX_KEY(0x05, 0x0b, KEY_M) /* 52 */ \
+ MATRIX_KEY(0x05, 0x0c, KEY_PAGEDOWN) /* 86 (Numpad) */ \
+ \
+ MATRIX_KEY(0x06, 0x01, KEY_Z) /* 46 */ \
+ MATRIX_KEY(0x06, 0x02, KEY_3) /* 4 */ \
+ MATRIX_KEY(0x06, 0x03, KEY_4) /* 5 */ \
+ MATRIX_KEY(0x06, 0x04, KEY_2) /* 3 */ \
+ MATRIX_KEY(0x06, 0x05, KEY_8) /* 9 */ \
+ MATRIX_KEY(0x06, 0x06, KEY_0) /* 11 */ \
+ MATRIX_KEY(0x06, 0x08, KEY_7) /* 8 */ \
+ MATRIX_KEY(0x06, 0x09, KEY_9) /* 10 */ \
+ MATRIX_KEY(0x06, 0x0b, KEY_DOWN) /* 84 */ \
+ MATRIX_KEY(0x06, 0x0c, KEY_RIGHT) /* 89 */ \
+ MATRIX_KEY(0x06, 0x0d, KEY_LEFTALT) /* 60 */ \
+ MATRIX_KEY(0x06, 0x0f, KEY_ASSISTANT) /* 128 */ \
+ MATRIX_KEY(0x06, 0x11, KEY_BACKSLASH) /* 42 (JIS, ISO) */ \
+ \
+ MATRIX_KEY(0x07, 0x01, KEY_U) /* 23 */ \
+ MATRIX_KEY(0x07, 0x02, KEY_I) /* 24 */ \
+ MATRIX_KEY(0x07, 0x03, KEY_O) /* 25 */ \
+ MATRIX_KEY(0x07, 0x04, KEY_P) /* 26 */ \
+ MATRIX_KEY(0x07, 0x05, KEY_Q) /* 17 */ \
+ MATRIX_KEY(0x07, 0x06, KEY_W) /* 18 */ \
+ MATRIX_KEY(0x07, 0x07, KEY_RIGHTSHIFT) /* 57 */ \
+ MATRIX_KEY(0x07, 0x08, KEY_E) /* 19 */ \
+ MATRIX_KEY(0x07, 0x09, KEY_R) /* 20 */ \
+ MATRIX_KEY(0x07, 0x0b, KEY_UP) /* 83 */ \
+ MATRIX_KEY(0x07, 0x0c, KEY_LEFT) /* 79 */ \
+ MATRIX_KEY(0x07, 0x11, KEY_102ND) /* 45 (ISO) */
+
#endif /* _CROS_EC_KEYBOARD_H */
--
2.45.2.505.gda0bf45e8d-goog
^ permalink raw reply related
* Re: [PATCH v11 1/4] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Danny Kaehn @ 2024-06-06 16:24 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Benjamin Tissoires, Andy Shevchenko,
Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy
In-Reply-To: <20240606151859.GA3605325-robh@kernel.org>
I appreciate you taking a look (even in spite of the dt_binding_check
failure).
On Thu, Jun 06, 2024 at 09:18:59AM -0600, Rob Herring wrote:
> On Wed, Jun 05, 2024 at 06:12:44PM -0500, Danny Kaehn wrote:
> > This is a USB HID device which includes an I2C controller and 8 GPIO pins.
> >
> > The binding allows describing the chip's gpio and i2c controller in DT
> > using the subnodes named "gpio" and "i2c", respectively. This is
>
> There's no more gpio subnode.
>
Will fix.
> > intended to be used in configurations where the CP2112 is permanently
> > connected in hardware.
> >
> > Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
> > ---
> > .../devicetree/bindings/i2c/silabs,cp2112.yaml | 105 +++++++++++++++++++++
> > 1 file changed, 105 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
> > new file mode 100644
> > index 000000000000..0108f2e43c8c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
> > @@ -0,0 +1,105 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/i2c/silabs,cp2112.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: CP2112 HID USB to SMBus/I2C Bridge
> > +
> > +maintainers:
> > + - Danny Kaehn <danny.kaehn@plexus.com>
> > +
> > +description:
> > + The CP2112 is a USB HID device which includes an integrated I2C controller
> > + and 8 GPIO pins. Its GPIO pins can each be configured as inputs, open-drain
> > + outputs, or push-pull outputs.
> > +
> > +properties:
> > + compatible:
> > + const: usb10c4,ea90
> > +
> > + reg:
> > + maxItems: 1
> > + description: The USB port number on the host controller
>
> Or hub ports. Just drop 'on the host controller'.
>
Will fix.
> > +
> > + i2c:
> > + description: The SMBus/I2C controller node for the CP2112
> > + $ref: /schemas/i2c/i2c-controller.yaml#
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + sda-gpios:
> > + maxItems: 1
> > +
> > + scl-gpios:
> > + maxItems: 1
>
> These are because I2C can be on any of the pins? It's a bit odd if they
> aren't used as gpios. Probably should be pinmux, but that's overkill for
> 2 pins.
>
I'm beginning to realize now that this may be a bit non-standard, but it
did solve a stuck bus issue under some conditions.
The CP2112's I2C controller is self-contained and can only be on the
specific pins it is attached to (no pinmux, etc..).
In this case, these properties are ment to specify additional gpio pins
which are connected to the SCL and SDA lines (this then also assumes those
are configured to be open drain / inputs to not interfere with the bus
during normal operation). This was inspired by what is done ini2c-imx.yaml,
but I realize this is a bit different due to using external pins rather
than pinmuxing to the GPIOs.
How I used this was to actually connect some of the CP2112's own GPIO pins
to the SDA and SCL lines to be able to use those pins to recover the
bus. This was able to solve a stuck bus under some real-world cases with
the v2 of the CP2112 containing an errata which caused this
semi-frequently.
> > +
> > + clock-frequency:
> > + minimum: 10000
> > + default: 100000
> > + maximum: 400000
> > +
> > + interrupt-controller: true
> > + "#interrupt-cells":
> > + const: 2
>
> Where does the
Unsure what you intended to ask here -- but the interrupt comes from the
GPIO chip. It is unfortunately not a hardware interrupt, but is
accomplished through polling.
> > +
> > + gpio-controller: true
> > + "#gpio-cells":
> > + const: 2
> > +
> > + gpio-line-names:
> > + minItems: 1
> > + maxItems: 8
> > +
> > +patternProperties:
> > + "-hog(-[0-9]+)?$":
> > + type: object
> > +
> > + required:
> > + - gpio-hog
> > +
> > +required:
> > + - compatible
> > + - reg
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + usb {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + cp2112: device@1 {
> > + compatible = "usb10c4,ea90";
> > + reg = <1>;
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + sda-gpios = <&cp2112 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > + scl-gpios = <&cp2112 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> > +
> > + temp@48 {
> > + compatible = "national,lm75";
> > + reg = <0x48>;
> > + };
> > + };
> > +
> > + gpio-controller;
> > + interrupt-controller;
> > + #gpio-cells = <2>;
> > + gpio-line-names = "CP2112_SDA", "CP2112_SCL", "TEST2",
> > + "TEST3","TEST4", "TEST5", "TEST6";
> > +
> > + fan-rst-hog {
> > + gpio-hog;
> > + gpios = <7 GPIO_ACTIVE_HIGH>;
> > + output-high;
> > + line-name = "FAN_RST";
> > + };
> > + };
> > + };
> >
> > --
> > 2.25.1
> >
Thanks,
Danny Kaehn
^ permalink raw reply
* Re: [PATCH v11 0/4] Firmware Support for USB-HID Devices and CP2112
From: Danny Kaehn @ 2024-06-06 15:54 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rob Herring, Krzysztof Kozlowski, Benjamin Tissoires, Jiri Kosina,
devicetree, linux-input, Dmitry Torokhov, Bartosz Golaszewski,
Ethan Twardy
In-Reply-To: <ZmD38oynzhjH2628@smile.fi.intel.com>
On Thu, Jun 06, 2024 at 02:42:42AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 05, 2024 at 06:12:43PM -0500, Danny Kaehn wrote:
> > This patchset allows USB-HID devices to have Firmware bindings through sharing
> > the USB fwnode with the HID driver, and adds such a binding and driver
> > implementation for the CP2112 USB to SMBus Bridge (which necessitated the
> > USB-HID change). This change allows a CP2112 permanently attached in hardware to
> > be described in DT and ACPI and interoperate with other drivers.
>
> ...
>
> > Changes in v11:
> > - Eliminate 'gpio' subnode for DT and ACPI for the CP2112 per comment
> > from Rob H.
>
> Hmm... I don't know much about DT, but how is this supposed to work in ACPI?
> I mean if we want to refer to the GPIO in GpioIo() or GpioInt() resources,
> what should we put there as ACPI path?
What I tested was essentially taking what Benjamin had done in [1], just
removing the "GPIO" device and combining it with the parent device (the
CP2112 itself). So for the example below, I believe the path would be
"\_SB_.PCI0.SE9_.RHUB.CP2_". If I get the chance (and can figure out how
to do it using ACPI) I'll try to add a "gpio-keys" or something to the
system using this path and make sure that works.
[1]: https://patchwork.kernel.org/project/linux-input/patch/20230227140758.1575-4-kaehndan@gmail.com/#25242036
Thanks,
Danny Kaehn
---
Full example within context:
Device (SE9)
{
Name (_ADR, 0x001D0001) // _ADR: Address
Device (RHUB)
{
Name (_ADR, Zero)
Device (CP2) // the USB-hid & CP2112 shared node
{
Name (_ADR, One)
Name (_STA, 0x0F)
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "gpio-hog", 1 },
Package () { "gpios", Package () { 4, 0 } },
Package () { "output-high", 1 },
Package () { "line-name", "gpio4-pullup" },
},
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "gpio-line-names", Package () {
"",
"",
"irq-rmi4",
"",
"power", // set to 1 with gpio-hog above
"",
"",
"",
""}},
}
})
Device (I2C0)
{
Name (_ADR, Zero)
Name (_STA, 0x0F)
}
}
}
}
>
> > - Edit hid-cp2112.c to match for ACPI index and fall back to matching by
> > name (instead of the other way around)
> > - Separate CP2112 I2C bus speed configuration into a separate patch
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v11 1/4] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Danny Kaehn @ 2024-06-06 15:12 UTC (permalink / raw)
To: robh@kernel.org, krzk+dt@kernel.org,
andriy.shevchenko@linux.intel.com, krzk@kernel.org,
bentiss@kernel.org
Cc: jikos@kernel.org, linux-input@vger.kernel.org,
bartosz.golaszewski@linaro.org, devicetree@vger.kernel.org,
dmitry.torokhov@gmail.com, Ethan Twardy
In-Reply-To: <e183c4ab-e48e-4c9f-be31-13b16ad466b6@kernel.org>
On Thu, 2024-06-06 at 08:28 +0200, Krzysztof Kozlowski wrote:
> PLEXUS SECURITY WARNING
> You have not previously corresponded with this sender.
> On 06/06/2024 01:12, Danny Kaehn wrote:
> > This is a USB HID device which includes an I2C controller and 8
> GPIO pins.
> >
> > The binding allows describing the chip's gpio and i2c controller in
> DT
> > using the subnodes named "gpio" and "i2c", respectively. This is
> > intended to be used in configurations where the CP2112 is
> permanently
> > connected in hardware.
> >
> > Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
> > ---
> > .../devicetree/bindings/i2c/silabs,cp2112.yaml | 105
> +++++++++++++++++++++
> > 1 file changed, 105 insertions(+)
>
> So this is v11 but was never tested?
My apologies -- initially `DT_SCHEMA_FILES=silabs,cp2112.yaml make
dt_binding_check` was completing without any output (and I assumed
success), but after a clean, I get make errors, either relating to "no
rule to make ... *.example.dtb", or yamllint usage errors. Have tried
updating dtschema and/or reinstalling, and also started from scratch on
a different system with the same issues. I will get this working and
run this before submitting additional revisions, apologies again!
(and I will of course fix the issue reported by the bot)
>
> Changelog does not help me understanding what happened with this
> binding...
I'll keep in mind better specifying changes to the binding in the
changelog!
Since v6, where Rob added his review tag [1], the only changes were
eliminating the gpio subnode and combining it with the parent, and
updating my email address.
Since v4, where you had added your review tag [2], I addressed Rob's
comments in [3], including:
- Removing the ngpios property
- Constraining the hog pattern more to a single naming scheme
- Removing unneeded properties from the hog which are provided by the
parent schema
- Adding an example of the hog to test the schema
Additionally, I added sda-gpios and scl-gpios to the i2c node as well
as usage of it in the example dts. This is intended to be used for bus
recovery GPIOs (not yet included in the kernel drivers)
[1]:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230217184904.1290-2-kaehndan@gmail.com/
[2]:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230206135016.6737-2-kaehndan@gmail.com/
[3]:
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230205145450.3396-2-kaehndan@gmail.com/#3051932
Thanks,
Danny Kaehn
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v11 1/4] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
From: Rob Herring @ 2024-06-06 15:18 UTC (permalink / raw)
To: Danny Kaehn
Cc: Krzysztof Kozlowski, Benjamin Tissoires, Andy Shevchenko,
Jiri Kosina, devicetree, linux-input, Dmitry Torokhov,
Bartosz Golaszewski, Ethan Twardy
In-Reply-To: <20240605-cp2112-dt-v11-1-d55f0f945a62@plexus.com>
On Wed, Jun 05, 2024 at 06:12:44PM -0500, Danny Kaehn wrote:
> This is a USB HID device which includes an I2C controller and 8 GPIO pins.
>
> The binding allows describing the chip's gpio and i2c controller in DT
> using the subnodes named "gpio" and "i2c", respectively. This is
There's no more gpio subnode.
> intended to be used in configurations where the CP2112 is permanently
> connected in hardware.
>
> Signed-off-by: Danny Kaehn <danny.kaehn@plexus.com>
> ---
> .../devicetree/bindings/i2c/silabs,cp2112.yaml | 105 +++++++++++++++++++++
> 1 file changed, 105 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
> new file mode 100644
> index 000000000000..0108f2e43c8c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/silabs,cp2112.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i2c/silabs,cp2112.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: CP2112 HID USB to SMBus/I2C Bridge
> +
> +maintainers:
> + - Danny Kaehn <danny.kaehn@plexus.com>
> +
> +description:
> + The CP2112 is a USB HID device which includes an integrated I2C controller
> + and 8 GPIO pins. Its GPIO pins can each be configured as inputs, open-drain
> + outputs, or push-pull outputs.
> +
> +properties:
> + compatible:
> + const: usb10c4,ea90
> +
> + reg:
> + maxItems: 1
> + description: The USB port number on the host controller
Or hub ports. Just drop 'on the host controller'.
> +
> + i2c:
> + description: The SMBus/I2C controller node for the CP2112
> + $ref: /schemas/i2c/i2c-controller.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + sda-gpios:
> + maxItems: 1
> +
> + scl-gpios:
> + maxItems: 1
These are because I2C can be on any of the pins? It's a bit odd if they
aren't used as gpios. Probably should be pinmux, but that's overkill for
2 pins.
> +
> + clock-frequency:
> + minimum: 10000
> + default: 100000
> + maximum: 400000
> +
> + interrupt-controller: true
> + "#interrupt-cells":
> + const: 2
Where does the
> +
> + gpio-controller: true
> + "#gpio-cells":
> + const: 2
> +
> + gpio-line-names:
> + minItems: 1
> + maxItems: 8
> +
> +patternProperties:
> + "-hog(-[0-9]+)?$":
> + type: object
> +
> + required:
> + - gpio-hog
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + usb {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cp2112: device@1 {
> + compatible = "usb10c4,ea90";
> + reg = <1>;
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + sda-gpios = <&cp2112 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> + scl-gpios = <&cp2112 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
> +
> + temp@48 {
> + compatible = "national,lm75";
> + reg = <0x48>;
> + };
> + };
> +
> + gpio-controller;
> + interrupt-controller;
> + #gpio-cells = <2>;
> + gpio-line-names = "CP2112_SDA", "CP2112_SCL", "TEST2",
> + "TEST3","TEST4", "TEST5", "TEST6";
> +
> + fan-rst-hog {
> + gpio-hog;
> + gpios = <7 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "FAN_RST";
> + };
> + };
> + };
>
> --
> 2.25.1
>
^ permalink raw reply
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