* [PATCH] x86/vmware: Add TDX hypercall support
From: Alexey Makhalov @ 2023-12-08 2:32 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, namit, timothym, akaher,
jsipek, dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms
In-Reply-To: <64074f04-fd72-488b-831a-ad744bbcd950@broadcom.com>
From: Alexey Makhalov <amakhalov@vmware.com>
VMware hypercalls use I/O port, VMCALL or VMMCALL instructions.
Add __tdx_hypercall path to support TDX guests.
No change in high bandwidth hypercalls, as only low bandwidth
ones are supported for TDX guests.
Co-developed-by: Tim Merrifield <timothym@vmware.com>
Signed-off-by: Tim Merrifield <timothym@vmware.com>
Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Reviewed-by: Nadav Amit <namit@vmware.com>
---
arch/x86/include/asm/vmware.h | 83 +++++++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/vmware.c | 22 ++++++++++
2 files changed, 105 insertions(+)
diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 719e41260ece..04c698b905ab 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -34,12 +34,65 @@
#define VMWARE_CMD_GETHZ 45
#define VMWARE_CMD_GETVCPU_INFO 68
#define VMWARE_CMD_STEALCLOCK 91
+/*
+ * Hypercall command mask:
+ * bits[6:0] command, range [0, 127]
+ * bits[19:16] sub-command, range [0, 15]
+ */
+#define VMWARE_CMD_MASK 0xf007fULL
#define CPUID_VMWARE_FEATURES_ECX_VMMCALL BIT(0)
#define CPUID_VMWARE_FEATURES_ECX_VMCALL BIT(1)
extern u8 vmware_hypercall_mode;
+#define VMWARE_TDX_VENDOR_LEAF 0x1af7e4909ULL
+#define VMWARE_TDX_HCALL_FUNC 1
+
+extern unsigned long vmware_tdx_hypercall(struct tdx_module_args *args);
+
+/*
+ * TDCALL[TDG.VP.VMCALL] uses rax (arg0) and rcx (arg2), while the use of
+ * rbp (arg6) is discouraged by the TDX specification. Therefore, we
+ * remap those registers to r12, r13 and r14, respectively.
+ */
+static inline
+unsigned long vmware_tdx_hypercall_args(unsigned long cmd, unsigned long in1,
+ unsigned long in3, unsigned long in4,
+ unsigned long in5, unsigned long in6,
+ uint32_t *out1, uint32_t *out2,
+ uint32_t *out3, uint32_t *out4,
+ uint32_t *out5, uint32_t *out6)
+{
+ unsigned long ret;
+
+ struct tdx_module_args args = {
+ .r13 = cmd,
+ .rbx = in1,
+ .rdx = in3,
+ .rsi = in4,
+ .rdi = in5,
+ .r14 = in6,
+ };
+
+ ret = vmware_tdx_hypercall(&args);
+
+ if (out1)
+ *out1 = args.rbx;
+ if (out2)
+ *out2 = args.r13;
+ if (out3)
+ *out3 = args.rdx;
+ if (out4)
+ *out4 = args.rsi;
+ if (out5)
+ *out5 = args.rdi;
+ if (out6)
+ *out6 = args.r14;
+
+ return ret;
+}
+
/*
* 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.
@@ -67,6 +120,11 @@ unsigned long vmware_hypercall1(unsigned long cmd, unsigned long in1)
{
unsigned long out0;
+ if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+ return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0, 0,
+ NULL, NULL, NULL,
+ NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -85,6 +143,11 @@ unsigned long vmware_hypercall3(unsigned long cmd, unsigned long in1,
{
unsigned long out0;
+ if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+ return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0, 0,
+ out1, out2, NULL,
+ NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=b" (*out1), "=c" (*out2)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -104,6 +167,11 @@ unsigned long vmware_hypercall4(unsigned long cmd, unsigned long in1,
{
unsigned long out0;
+ if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+ return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0, 0,
+ out1, out2, out3,
+ NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -123,6 +191,11 @@ unsigned long vmware_hypercall5(unsigned long cmd, unsigned long in1,
{
unsigned long out0;
+ if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+ return vmware_tdx_hypercall_args(cmd, in1, in3, in4, in5, 0,
+ NULL, out2, NULL,
+ NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=c" (*out2)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -145,6 +218,11 @@ unsigned long vmware_hypercall6(unsigned long cmd, unsigned long in1,
{
unsigned long out0;
+ if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+ return vmware_tdx_hypercall_args(cmd, in1, in3, 0, 0, 0,
+ NULL, out2, out3,
+ out4, out5, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=c" (*out2), "=d" (*out3), "=S" (*out4),
"=D" (*out5)
@@ -166,6 +244,11 @@ unsigned long vmware_hypercall7(unsigned long cmd, unsigned long in1,
{
unsigned long out0;
+ if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+ return vmware_tdx_hypercall_args(cmd, in1, in3, in4, in5, 0,
+ out1, out2, out3,
+ NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c
index 3aa1adaed18f..bcf1d0fb3e89 100644
--- a/arch/x86/kernel/cpu/vmware.c
+++ b/arch/x86/kernel/cpu/vmware.c
@@ -428,6 +428,28 @@ static bool __init vmware_legacy_x2apic_available(void)
(eax & BIT(VCPU_LEGACY_X2APIC));
}
+#ifdef CONFIG_INTEL_TDX_GUEST
+unsigned long vmware_tdx_hypercall(struct tdx_module_args *args)
+{
+ if (!hypervisor_is_type(X86_HYPER_VMWARE))
+ return 0;
+
+ if (args->r13 & ~VMWARE_CMD_MASK) {
+ pr_warn("Out of range command %llx\n", args->r13);
+ return 0;
+ }
+
+ args->r10 = VMWARE_TDX_VENDOR_LEAF;
+ args->r11 = VMWARE_TDX_HCALL_FUNC;
+ args->r12 = VMWARE_HYPERVISOR_MAGIC;
+
+ __tdx_hypercall(args);
+
+ return args->r12;
+}
+EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
+#endif
+
#ifdef CONFIG_AMD_MEM_ENCRYPT
static void vmware_sev_es_hcall_prepare(struct ghcb *ghcb,
struct pt_regs *regs)
--
2.39.0
^ permalink raw reply related
* Re: [PATCH] x86/vmware: Add TDX hypercall support
From: Alexey Makhalov @ 2023-12-08 2:27 UTC (permalink / raw)
To: Dave Hansen, linux-kernel, virtualization, hpa, dave.hansen, bp,
mingo, tglx, dave.hansen
Cc: x86, netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, namit, timothym, akaher,
jsipek, dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms
In-Reply-To: <53592a3a-3d96-4aa1-8357-ec595f59c5f3@intel.com>
On 12/7/23 9:12 AM, Dave Hansen wrote:
> On 12/5/23 23:15, Alexey Makhalov wrote:
>> +#ifdef CONFIG_INTEL_TDX_GUEST
>> +/* Export tdx hypercall and allow it only for VMware guests. */
>> +void vmware_tdx_hypercall_args(struct tdx_module_args *args)
>> +{
>> + if (hypervisor_is_type(X86_HYPER_VMWARE))
>> + __tdx_hypercall(args);
>> +}
>> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall_args);
>> +#endif
>
> I think this is still too generic. This still allows anything setting
> X86_HYPER_VMWARE to make any TDX hypercall.
>
> I'd *much* rather you export something like vmware_tdx_hypercall() or
> even the high-level calls like hypervisor_ppn_reset_all(). The higher
> level and more specialized the interface, the less likely it is to be
> abused.
Dave, I understood your point. Please take a look on the next version of
the patch.
I export vmware_tdx_hypercall(), while vmware_tdx_hypercall_args() is a
static inline wrapper on top.
Most of the vmware hypercall logic plus sanity checks are now in
exported function. While only input and output argument handling remains
in the wrapper to allow compiler optimization for hypercalls with few
argument. Exporting vmware_tdx_hypercall1, vmware_tdx_hypercall3, and so
on is not an option either.
Regards,
--Alexey
^ permalink raw reply
* RE: [PATCH 4/4] platform: chrome: cros_ec_ishtp: use helper functions for connection
From: Xu, Even @ 2023-12-08 0:38 UTC (permalink / raw)
To: Jiri Kosina, Tzung-Bi Shih
Cc: srinivas.pandruvada@linux.intel.com, bleung@chromium.org,
groeck@chromium.org, linux-input@vger.kernel.org,
chrome-platform@lists.linux.dev
In-Reply-To: <nycvar.YFH.7.76.2312061133470.29220@cbobk.fhfr.pm>
Thanks Jiri!
Best Regards,
Even Xu
-----Original Message-----
From: Jiri Kosina <jkosina@suse.com>
Sent: Wednesday, December 6, 2023 6:34 PM
To: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: Xu, Even <even.xu@intel.com>; srinivas.pandruvada@linux.intel.com; bleung@chromium.org; groeck@chromium.org; linux-input@vger.kernel.org; chrome-platform@lists.linux.dev
Subject: Re: [PATCH 4/4] platform: chrome: cros_ec_ishtp: use helper functions for connection
On Wed, 6 Dec 2023, Tzung-Bi Shih wrote:
> On Tue, Dec 05, 2023 at 09:50:33AM +0800, Even Xu wrote:
> > Use helper functions ishtp_cl_establish_connection() and
> > ishtp_cl_destroy_connection() to establish and destroy connection
> > respectively. These functions are used during initialization, reset
> > and deinitialization flows.
> >
> > No functional changes are expected.
> >
> > Signed-off-by: Even Xu <even.xu@intel.com>
> > Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
>
> Acked-by: Tzung-Bi Shih <tzungbi@kernel.org>
Thanks.
> One minor suggestion: we usually use "platform/chrome:" instead of
> "platform: chrome:" for the title prefix.
I have changed that, and am taking it together with the rest of the series through hid.git#for-6.8/intel-ish.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/2] Input: i8042: Avoid probing if no keyboard and mouse are set in quirks
From: Mario Limonciello @ 2023-12-07 20:39 UTC (permalink / raw)
To: Rahul Rameshbabu; +Cc: dmitry.torokhov, linux-input, linux-kernel
In-Reply-To: <87il5bgfmp.fsf@nvidia.com>
On 12/6/2023 15:55, Rahul Rameshbabu wrote:
> On Wed, 06 Dec, 2023 15:21:39 -0600 Mario Limonciello <mario.limonciello@amd.com> wrote:
>> Some laptops have an i8042 controller in the SOC, nothing mentioned in
>> ACPI PNP and nothing connected to the controller. Add the ability to
>> skip probing in this case.
>>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>
> Thanks. I think this is a good choice for handling the issue you
> presented with the Framework 16.
>
> Reviewed-by: Rahul Rameshbabu <rrameshbabu@nvidia.com>
Thanks!
Dmitry,
Are you OK with this? The other direction I considered was to add a DMI
BIOS year check and "only continue to probe" non PNP devices on systems
older than 2023.
That could let you cut and run without needing to continue to add quirks
like this but it could be riskier.
^ permalink raw reply
* Re: [PATCH] x86/vmware: Add TDX hypercall support
From: Dave Hansen @ 2023-12-07 17:12 UTC (permalink / raw)
To: Alexey Makhalov, linux-kernel, virtualization, hpa, dave.hansen,
bp, mingo, tglx, dave.hansen
Cc: x86, netdev, richardcochran, linux-input, dmitry.torokhov, zackr,
linux-graphics-maintainer, pv-drivers, namit, timothym, akaher,
jsipek, dri-devel, daniel, airlied, tzimmermann, mripard,
maarten.lankhorst, horms
In-Reply-To: <20231206071527.59171-1-alexey.makhalov@broadcom.com>
On 12/5/23 23:15, Alexey Makhalov wrote:
> +#ifdef CONFIG_INTEL_TDX_GUEST
> +/* Export tdx hypercall and allow it only for VMware guests. */
> +void vmware_tdx_hypercall_args(struct tdx_module_args *args)
> +{
> + if (hypervisor_is_type(X86_HYPER_VMWARE))
> + __tdx_hypercall(args);
> +}
> +EXPORT_SYMBOL_GPL(vmware_tdx_hypercall_args);
> +#endif
I think this is still too generic. This still allows anything setting
X86_HYPER_VMWARE to make any TDX hypercall.
I'd *much* rather you export something like vmware_tdx_hypercall() or
even the high-level calls like hypervisor_ppn_reset_all(). The higher
level and more specialized the interface, the less likely it is to be
abused.
^ permalink raw reply
* RE: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Biju Das @ 2023-12-07 17:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <114c9baf-66d1-4055-a47c-916642b6dedd@linaro.org>
Hi Krzysztof Kozlowski,
Thanks for the feedback.
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Thursday, December 7, 2023 8:44 AM
> Subject: Re: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062
> to json-schema
>
> On 06/12/2023 16:57, Biju Das wrote:
> > Convert the da9062 PMIC device tree binding documentation to json-
> schema.
> >
> > Update the example to match reality.
> >
> > While at it, update description with link to product information.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > v3->v4:
> > * Split the thermal binding patch separate.
> > * Updated the description.
> > v2->v3:
> > * Fixed bot errors related to MAINTAINERS entry, invalid doc
> > references and thermal examples by merging patch#4.
> > v2:
> > * New patch
> > ---
> > .../bindings/input/dlg,da9062-onkey.yaml | 3 +-
> > .../devicetree/bindings/mfd/da9062.txt | 124 ------------
> > .../devicetree/bindings/mfd/dlg,da9063.yaml | 186 +++++++++++++++++-
> > .../bindings/thermal/dlg,da9062-thermal.yaml | 2 +-
> > 4 files changed, 183 insertions(+), 132 deletions(-) delete mode
> > 100644 Documentation/devicetree/bindings/mfd/da9062.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
> > b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
> > index 4cff91f4bd34..18b6a3f02c07 100644
> > --- a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
> > +++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
> > @@ -11,8 +11,7 @@ maintainers:
> >
> > description: |
> > This module is part of the DA9061/DA9062/DA9063. For more details
> > about entire
> > - DA9062 and DA9061 chips see
> > Documentation/devicetree/bindings/mfd/da9062.txt
> > - For DA9063 see
> > Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> > + DA906{1,2,3} chips see
> > + Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> >
> > This module provides the KEY_POWER event.
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt
> > b/Documentation/devicetree/bindings/mfd/da9062.txt
> > deleted file mode 100644
> > index c8a7f119ac84..000000000000
> > --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> > +++ /dev/null
> > @@ -1,124 +0,0 @@
> > -* Dialog DA9062 Power Management Integrated Circuit (PMIC)
> > -
> > -Product information for the DA9062 and DA9061 devices can be found
> here:
> > --
&sdata=yWQlq55fIMgsfBxaNXCj4zwBiK14xZcd6l3NYKVnAWM%3D&re
> > served=0
> > -
> > -The DA9062 PMIC consists of:
> > -
> > -Device Supply Names Description
> > ------- ------------ -----------
> > -da9062-regulator : : LDOs & BUCKs
> > -da9062-rtc : : Real-Time Clock
> > -da9062-onkey : : On Key
> > -da9062-watchdog : : Watchdog Timer
> > -da9062-thermal : : Thermal
> > -da9062-gpio : : GPIOs
> > -
> > -The DA9061 PMIC consists of:
> > -
> > -Device Supply Names Description
> > ------- ------------ -----------
> > -da9062-regulator : : LDOs & BUCKs
> > -da9062-onkey : : On Key
> > -da9062-watchdog : : Watchdog Timer
> > -da9062-thermal : : Thermal
> > -
> > -======
> > -
> > -Required properties:
> > -
> > -- compatible : Should be
> > - "dlg,da9062" for DA9062
> > - "dlg,da9061" for DA9061
> > -- reg : Specifies the I2C slave address (this defaults to 0x58 but it
> > can be
> > - modified to match the chip's OTP settings).
> > -
> > -Optional properties:
> > -
> > -- gpio-controller : Marks the device as a gpio controller.
> > -- #gpio-cells : Should be two. The first cell is the pin number and
> the
> > - second cell is used to specify the gpio polarity.
> > -
> > -See Documentation/devicetree/bindings/gpio/gpio.txt for further
> > information on -GPIO bindings.
> > -
> > -- interrupts : IRQ line information.
> > -- interrupt-controller
> > -
> > -See
> > Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> for -further information on IRQ bindings.
> > -
> > -Sub-nodes:
> > -
> > -- regulators : This node defines the settings for the LDOs and BUCKs.
> > - The DA9062 regulators are bound using their names listed below:
> > -
> > - buck1 : BUCK_1
> > - buck2 : BUCK_2
> > - buck3 : BUCK_3
> > - buck4 : BUCK_4
> > - ldo1 : LDO_1
> > - ldo2 : LDO_2
> > - ldo3 : LDO_3
> > - ldo4 : LDO_4
> > -
> > - The DA9061 regulators are bound using their names listed below:
> > -
> > - buck1 : BUCK_1
> > - buck2 : BUCK_2
> > - buck3 : BUCK_3
> > - ldo1 : LDO_1
> > - ldo2 : LDO_2
> > - ldo3 : LDO_3
> > - ldo4 : LDO_4
> > -
> > - The component follows the standard regulator framework and the
> > bindings
> > - details of individual regulator device can be found in:
> > - Documentation/devicetree/bindings/regulator/regulator.txt
> > -
> > - regulator-initial-mode may be specified for buck regulators using
> > mode values
> > - from include/dt-bindings/regulator/dlg,da9063-regulator.h.
> > -
> > -- rtc : This node defines settings required for the Real-Time Clock
> > associated
> > - with the DA9062. There are currently no entries in this binding,
> > however
> > - compatible = "dlg,da9062-rtc" should be added if a node is created.
> > -
> > -- onkey : See ../input/dlg,da9062-onkey.yaml
> > -
> > -- watchdog: See ../watchdog/dlg,da9062-watchdog.yaml
> > -
> > -- thermal : See ../thermal/dlg,da9062-thermal.yaml
> > -
> > -Example:
> > -
> > - pmic0: da9062@58 {
> > - compatible = "dlg,da9062";
> > - reg = <0x58>;
> > - interrupt-parent = <&gpio6>;
> > - interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> > - interrupt-controller;
> > -
> > - rtc {
> > - compatible = "dlg,da9062-rtc";
> > - };
> > -
> > - regulators {
> > - DA9062_BUCK1: buck1 {
> > - regulator-name = "BUCK1";
> > - regulator-min-microvolt = <300000>;
> > - regulator-max-microvolt = <1570000>;
> > - regulator-min-microamp = <500000>;
> > - regulator-max-microamp = <2000000>;
> > - regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
> > - regulator-boot-on;
> > - };
> > - DA9062_LDO1: ldo1 {
> > - regulator-name = "LDO_1";
> > - regulator-min-microvolt = <900000>;
> > - regulator-max-microvolt = <3600000>;
> > - regulator-boot-on;
> > - };
> > - };
> > - };
> > -
> > diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> > b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> > index 676b4f2566ae..54bb23dbc73f 100644
> > --- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> > @@ -4,7 +4,7 @@
> > $id:
> >
> > -title: Dialog DA9063/DA9063L Power Management Integrated Circuit
> > (PMIC)
> > +title: Dialog DA906{3L,3,2,1} Power Management Integrated Circuit
> > +(PMIC)
> >
> > maintainers:
> > - Steve Twiss <stwiss.opensource@diasemi.com> @@ -17,10 +17,17 @@
> > description: |
> > moment where all voltage monitors are disabled. Next, as da9063 only
> supports
> > UV *and* OV monitoring, both must be set to the same severity and
> value
> > (0: disable, 1: enable).
> > + Product information for the DA906{3L,3,2,1} devices can be found
> here:
> > + -
> >
> > properties:
> > compatible:
> > enum:
> > + - dlg,da9061
> > + - dlg,da9062
> > - dlg,da9063
> > - dlg,da9063l
> >
> > @@ -35,6 +42,19 @@ properties:
> > "#interrupt-cells":
> > const: 2
> >
> > + gpio:
>
> Old binding did not have such node and nothing in commit msg explained
> changes from pure conversion.
OK will update the commit message. Check patch complained about undocumented compatible.
>
> > + type: object
> > + $ref: /schemas/gpio/gpio.yaml#
>
> ?!? Why? First: It's always selected. Second, so you have two gpio
> controllers? And original binding had 0? Why this is not explained at all?
> Open the binding and look at its properties.
I have referred[1] and [2] to add gpio controller property.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-phytec-phycore-som.dtsi?h=next-20231207#n95
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/mfd/da9062.txt?h=next-20231207#n38
>
>
> > + unevaluatedProperties: false
> > + properties:
> > + compatible:
> > + const: dlg,da9062-gpio
> > +
> > + gpio-controller: true
>
> And here is the second gpio-controller...
So you mean it is redundant as $ref: /schemas/gpio/gpio.yaml
has already defined gpio-controller for this object??
>
> > +
> > + "#gpio-cells":
> > + const: 2
> > +
> > onkey:
> > $ref: /schemas/input/dlg,da9062-onkey.yaml
> >
> > @@ -42,7 +62,7 @@ properties:
> > type: object
> > additionalProperties: false
> > patternProperties:
> > - "^(ldo([1-9]|1[01])|bcore([1-2]|s-
> merged)|b(pro|mem|io|peri)|bmem-bio-merged)$":
> > + "^(ldo([1-9]|1[01])|bcore([1-2]|s-
> merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck[1-4])$":
> > $ref: /schemas/regulator/regulator.yaml
> > unevaluatedProperties: false
> >
> > @@ -52,7 +72,12 @@ properties:
> > unevaluatedProperties: false
> > properties:
> > compatible:
> > - const: dlg,da9063-rtc
> > + enum:
> > + - dlg,da9063-rtc
> > + - dlg,da9062-rtc
> > +
> > + thermal:
> > + $ref: /schemas/thermal/dlg,da9062-thermal.yaml
> >
> > watchdog:
> > $ref: /schemas/watchdog/dlg,da9062-watchdog.yaml
> > @@ -60,8 +85,65 @@ properties:
> > required:
> > - compatible
> > - reg
> > - - interrupts
> > - - interrupt-controller
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - dlg,da9063
> > + - dlg,da9063l
> > + then:
> > + properties:
> > + thermal: false
> > + gpio: false
> > + gpio-controller: false
> > + "#gpio-cells": false
> > + regulators:
> > + patternProperties:
> > + "^buck[1-4]$": false
> > + required:
> > + - interrupts
> > + - interrupt-controller
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - dlg,da9062
> > + then:
> > + properties:
> > + regulators:
> > + patternProperties:
> > + "^(ldo([5-9]|10|11)|bcore([1-2]|s-
> merged)|b(pro|mem|io|peri)|bmem-bio-merged)$": false
> > + required:
> > + - gpio
> > + - onkey
> > + - rtc
> > + - thermal
> > + - watchdog
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - dlg,da9061
> > + then:
> > + properties:
> > + gpio: false
> > + gpio-controller: false
> > + "#gpio-cells": false
> > + regulators:
> > + patternProperties:
> > + "^(ldo([5-9]|10|11)|bcore([1-2]|s-
> merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck4)$": false
> > + rtc: false
> > + required:
> > + - onkey
> > + - thermal
> > + - watchdog
> >
> > additionalProperties: false
> >
> > @@ -118,4 +200,98 @@ examples:
> > };
> > };
> > };
> > +
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/regulator/dlg,da9063-regulator.h>
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + pmic@58 {
> > + compatible = "dlg,da9062";
> > + reg = <0x58>;
> > + #interrupt-cells = <2>;
> > + interrupt-parent = <&gpio1>;
> > + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> > + interrupt-controller;
> > +
> > + gpio {
> > + compatible = "dlg,da9062-gpio";
> > + status = "disabled";
>
> Why?
> Where are gpio-controller and cells? For this node and for parent? Why
> this example is incomplete?
I have used a real example [1] here.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-phytec-phycore-som.dtsi?h=next-20231207#n95
Currently I don't see any driver is using this compatible other than MFD.
Cheers,
Biju
>
> > + };
> > +
> > + onkey {
> > + compatible = "dlg,da9062-onkey";
> > + };
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add poweroff-in-suspend property
From: Krzysztof Kozlowski @ 2023-12-07 16:59 UTC (permalink / raw)
To: Stefan Eichenberger, nick, dmitry.torokhov, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linus.walleij
Cc: linux-input, devicetree, linux-arm-kernel, linux-kernel,
Stefan Eichenberger
In-Reply-To: <20231207111300.80581-2-eichest@gmail.com>
On 07/12/2023 12:12, Stefan Eichenberger wrote:
> diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> index c40799355ed7..047a5101341c 100644
> --- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
> @@ -87,6 +87,12 @@ properties:
> - 2 # ATMEL_MXT_WAKEUP_GPIO
> default: 0
>
> + atmel,poweroff-in-suspend:
> + description: |
> + When this property is set, all supplies are turned off when the system is
> + going to suspend.
You described the desired Linux feature or behavior, not the actual
hardware. The bindings are about the latter, so instead you need to
rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 5/8] dt-bindings: input: Convert da906{1,2,3} onkey to json-schema
From: Biju Das @ 2023-12-07 16:42 UTC (permalink / raw)
To: Krzysztof Kozlowski, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Support Opensource, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, Geert Uytterhoeven,
Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <39094951-6ecb-4948-8be5-7ab13dd5269b@linaro.org>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Thursday, December 7, 2023 8:37 AM
> Subject: Re: [PATCH v4 5/8] dt-bindings: input: Convert da906{1,2,3} onkey
> to json-schema
>
> On 06/12/2023 16:57, Biju Das wrote:
> > Convert the da906{1,2,3} onkey device tree binding documentation to
> > json-schema.
> >
> > Update MAINTAINERS entries, description and onkey property by
> > referring to dlg,da9062-onkey binding file.
> >
>
> ...
>
> > +---
> > +$id:
> > +
> > +title: Dialog DA9061/62/63 OnKey Module
> > +
> > +maintainers:
> > + - Biju Das <biju.das.jz@bp.renesas.com>
> > +
> > +description: |
> > + This module is part of the DA9061/DA9062/DA9063. For more details
> > +about entire
> > + DA9062 and DA9061 chips see
> > +Documentation/devicetree/bindings/mfd/da9062.txt
> > + For DA9063 see
> > +Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> > +
> > + This module provides the KEY_POWER event.
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - items:
>
> Drop items
Agreed.
Cheers,
Biju
>
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best
> regards, Krzysztof
^ permalink raw reply
* Re: Fwd: Logitech G915 Wireless Keyboard acts weird on 6.6.0
From: Mavroudis Chatzilazaridis @ 2023-12-07 15:04 UTC (permalink / raw)
To: Jiri Kosina, Linux regressions mailing list
Cc: Bagas Sanjaya, Linux Kernel Mailing List, Linux Input Devices,
Filipe Laíns, Bastien Nocera, LinuxCat, Marcelo,
Takashi Iwai, Hans de Goede, Linus Torvalds, Benjamin Tissoires
In-Reply-To: <nycvar.YFH.7.76.2311211458030.29220@cbobk.fhfr.pm>
On 2023-11-21 16:00, Jiri Kosina wrote:> A comment from Mavroudis just
appeared in
>
> https://bugzilla.kernel.org/show_bug.cgi?id=218172
>
> pointing out that indeed the report descriptor of the device he is working
> on is different than the ones from the reporter.
>
> Until this mess gets figured out, I am now pretty sure revert is the way
> to go for 6.7.
>
> --
> Jiri Kosina
> SUSE Labs
>
Greetings everyone,
I have recently made a new patch [0] aimed at addressing the issues that
have been identified.
I would appreciate it if you could test it and provide any feedback on it.
[0] https://bugzilla.kernel.org/show_bug.cgi?id=218172#c14
^ permalink raw reply
* Re: [PATCH] selftests/hid: fix failing tablet button tests
From: Benjamin Tissoires @ 2023-12-07 13:55 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Shuah Khan, Peter Hutterer,
Benjamin Tissoires
Cc: Jiri Kosina, linux-input, linux-kselftest, linux-kernel
In-Reply-To: <20231207-b4-wip-selftests-v1-1-c4e13fe04a70@kernel.org>
On Thu, 07 Dec 2023 13:22:39 +0100, Benjamin Tissoires wrote:
> An overlook from commit 74452d6329be ("selftests/hid: tablets: add
> variants of states with buttons"), where I don't use the Enum...
>
>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-6.8/selftests), thanks!
[1/1] selftests/hid: fix failing tablet button tests
https://git.kernel.org/hid/hid/c/da2c1b861065
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] HID: intel-ish-hid: ipc: Rework EHL OOB wakeup
From: Jiri Kosina @ 2023-12-07 13:53 UTC (permalink / raw)
To: srinivas pandruvada
Cc: Kai-Heng Feng, benjamin.tissoires, linux-pm, linux-pci,
Jian Hui Lee, Even Xu, linux-input, linux-kernel
In-Reply-To: <6776742e5aba8f9f10c661a7876eb252f4ac7745.camel@linux.intel.com>
On Thu, 7 Dec 2023, srinivas pandruvada wrote:
> On Wed, 2023-11-08 at 14:19 +0200, Kai-Heng Feng wrote:
> > Since PCI core and ACPI core already handles PCI PME wake and GPE
> > wake
> > when the device has wakeup capability, use device_init_wakeup() to
> > let
> > them do the wakeup setting work.
> >
> > Also add a shutdown callback which uses pci_prepare_to_sleep() to let
> > PCI and ACPI set OOB wakeup for S5.
> >
> > Cc: Jian Hui Lee <jianhui.lee@canonical.com>
> > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Thanks, applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: intel-ish-hid: ipc: Rework EHL OOB wakeup
From: srinivas pandruvada @ 2023-12-07 13:49 UTC (permalink / raw)
To: Kai-Heng Feng, jikos, benjamin.tissoires
Cc: linux-pm, linux-pci, Jian Hui Lee, Even Xu, linux-input,
linux-kernel
In-Reply-To: <20231108121940.288005-1-kai.heng.feng@canonical.com>
On Wed, 2023-11-08 at 14:19 +0200, Kai-Heng Feng wrote:
> Since PCI core and ACPI core already handles PCI PME wake and GPE
> wake
> when the device has wakeup capability, use device_init_wakeup() to
> let
> them do the wakeup setting work.
>
> Also add a shutdown callback which uses pci_prepare_to_sleep() to let
> PCI and ACPI set OOB wakeup for S5.
>
> Cc: Jian Hui Lee <jianhui.lee@canonical.com>
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> v2:
> Rebase on ("HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE
> bit")
>
> drivers/hid/intel-ish-hid/ipc/pci-ish.c | 67 ++++++-----------------
> --
> 1 file changed, 15 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> index 710fda5f19e1..65e7eeb2fa64 100644
> --- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> +++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
> @@ -119,50 +119,6 @@ static inline bool ish_should_leave_d0i3(struct
> pci_dev *pdev)
> return !pm_resume_via_firmware() || pdev->device ==
> CHV_DEVICE_ID;
> }
>
> -static int enable_gpe(struct device *dev)
> -{
> -#ifdef CONFIG_ACPI
> - acpi_status acpi_sts;
> - struct acpi_device *adev;
> - struct acpi_device_wakeup *wakeup;
> -
> - adev = ACPI_COMPANION(dev);
> - if (!adev) {
> - dev_err(dev, "get acpi handle failed\n");
> - return -ENODEV;
> - }
> - wakeup = &adev->wakeup;
> -
> - /*
> - * Call acpi_disable_gpe(), so that reference count
> - * gpe_event_info->runtime_count doesn't overflow.
> - * When gpe_event_info->runtime_count = 0, the call
> - * to acpi_disable_gpe() simply return.
> - */
> - acpi_disable_gpe(wakeup->gpe_device, wakeup->gpe_number);
> -
> - acpi_sts = acpi_enable_gpe(wakeup->gpe_device, wakeup-
> >gpe_number);
> - if (ACPI_FAILURE(acpi_sts)) {
> - dev_err(dev, "enable ose_gpe failed\n");
> - return -EIO;
> - }
> -
> - return 0;
> -#else
> - return -ENODEV;
> -#endif
> -}
> -
> -static void enable_pme_wake(struct pci_dev *pdev)
> -{
> - if ((pci_pme_capable(pdev, PCI_D0) ||
> - pci_pme_capable(pdev, PCI_D3hot) ||
> - pci_pme_capable(pdev, PCI_D3cold)) && !enable_gpe(&pdev-
> >dev)) {
> - pci_pme_active(pdev, true);
> - dev_dbg(&pdev->dev, "ish ipc driver pme wake
> enabled\n");
> - }
> -}
> -
> /**
> * ish_probe() - PCI driver probe callback
> * @pdev: pci device
> @@ -233,7 +189,7 @@ static int ish_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
>
> /* Enable PME for EHL */
> if (pdev->device == EHL_Ax_DEVICE_ID)
> - enable_pme_wake(pdev);
> + device_init_wakeup(dev, true);
>
> ret = ish_init(ishtp);
> if (ret)
> @@ -256,6 +212,19 @@ static void ish_remove(struct pci_dev *pdev)
> ish_device_disable(ishtp_dev);
> }
>
> +
> +/**
> + * ish_shutdown() - PCI driver shutdown callback
> + * @pdev: pci device
> + *
> + * This function sets up wakeup for S5
> + */
> +static void ish_shutdown(struct pci_dev *pdev)
> +{
> + if (pdev->device == EHL_Ax_DEVICE_ID)
> + pci_prepare_to_sleep(pdev);
> +}
> +
> static struct device __maybe_unused *ish_resume_device;
>
> /* 50ms to get resume response */
> @@ -378,13 +347,6 @@ static int __maybe_unused ish_resume(struct
> device *device)
> struct pci_dev *pdev = to_pci_dev(device);
> struct ishtp_device *dev = pci_get_drvdata(pdev);
>
> - /* add this to finish power flow for EHL */
> - if (dev->pdev->device == EHL_Ax_DEVICE_ID) {
> - pci_set_power_state(pdev, PCI_D0);
> - enable_pme_wake(pdev);
> - dev_dbg(dev->devc, "set power state to D0 for
> ehl\n");
> - }
> -
> ish_resume_device = device;
> dev->resume_flag = 1;
>
> @@ -400,6 +362,7 @@ static struct pci_driver ish_driver = {
> .id_table = ish_pci_tbl,
> .probe = ish_probe,
> .remove = ish_remove,
> + .shutdown = ish_shutdown,
> .driver.pm = &ish_pm_ops,
> };
>
^ permalink raw reply
* Re: [PATCH v2] HID: intel-ish-hid: ipc: Rework EHL OOB wakeup
From: srinivas pandruvada @ 2023-12-07 13:48 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: jikos, benjamin.tissoires, linux-pm, linux-pci, Jian Hui Lee,
Even Xu, linux-input, linux-kernel
In-Reply-To: <CAAd53p7do2rrB=qbpWKbNCWB_qfZ2YZPtB_55VcfGjDYXgLfzA@mail.gmail.com>
On Thu, 2023-12-07 at 10:44 +0800, Kai-Heng Feng wrote:
> On Tue, Dec 5, 2023 at 1:50 AM srinivas pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> >
> > Hi Kai,
> >
> > Sorry for he delay in getting back on this. I have a question
> > below:
> >
> > On Wed, 2023-11-08 at 14:19 +0200, Kai-Heng Feng wrote:
> > > Since PCI core and ACPI core already handles PCI PME wake and GPE
> > > wake
> > > when the device has wakeup capability, use device_init_wakeup()
> > > to
> > > let
> > > them do the wakeup setting work.
> > >
> > > Also add a shutdown callback which uses pci_prepare_to_sleep() to
> > > let
> > > PCI and ACPI set OOB wakeup for S5.
> > >
> > > Cc: Jian Hui Lee <jianhui.lee@canonical.com>
> > > Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> > > ---
> > > v2:
> > > Rebase on ("HID: intel-ish-hid: ipc: Disable and reenable ACPI
> > > GPE
> > > bit")
> > >
> > > drivers/hid/intel-ish-hid/ipc/pci-ish.c | 67 ++++++-------------
> > > ----
> > > --
> > >
...
...
> > > + device_init_wakeup(dev, true);
> >
> > For apple to apple comparison, which path will call
> > https://elixir.bootlin.com/linux/latest/C/ident/__pci_enable_wake
> > which will call pci_pme_active()?
>
> Here's the flow:
> device_shutdown()
> pci_device_shutdown()
> ish_shutdown()
> pci_prepare_to_sleep()
> __pci_enable_wake()
> pci_pme_active()
> __pci_pme_active()
Thanks. I will send my ACK to the original patch.
Thanks,
Srinivas
>
> Kai-Heng
>
> >
> > Thanks,
> > Srinivas
> >
> > >
> > > ret = ish_init(ishtp);
> > > if (ret)
> > > @@ -256,6 +212,19 @@ static void ish_remove(struct pci_dev *pdev)
> > > ish_device_disable(ishtp_dev);
> > > }
> > >
> > > +
> > > +/**
> > > + * ish_shutdown() - PCI driver shutdown callback
> > > + * @pdev: pci device
> > > + *
> > > + * This function sets up wakeup for S5
> > > + */
> > > +static void ish_shutdown(struct pci_dev *pdev)
> > > +{
> > > + if (pdev->device == EHL_Ax_DEVICE_ID)
> > > + pci_prepare_to_sleep(pdev);
> > > +}
> > > +
> > > static struct device __maybe_unused *ish_resume_device;
> > >
> > > /* 50ms to get resume response */
> > > @@ -378,13 +347,6 @@ static int __maybe_unused ish_resume(struct
> > > device *device)
> > > struct pci_dev *pdev = to_pci_dev(device);
> > > struct ishtp_device *dev = pci_get_drvdata(pdev);
> > >
> > > - /* add this to finish power flow for EHL */
> > > - if (dev->pdev->device == EHL_Ax_DEVICE_ID) {
> > > - pci_set_power_state(pdev, PCI_D0);
> > > - enable_pme_wake(pdev);
> > > - dev_dbg(dev->devc, "set power state to D0 for
> > > ehl\n");
> > > - }
> > > -
> > > ish_resume_device = device;
> > > dev->resume_flag = 1;
> > >
> > > @@ -400,6 +362,7 @@ static struct pci_driver ish_driver = {
> > > .id_table = ish_pci_tbl,
> > > .probe = ish_probe,
> > > .remove = ish_remove,
> > > + .shutdown = ish_shutdown,
> > > .driver.pm = &ish_pm_ops,
> > > };
> > >
> >
^ permalink raw reply
* Re: [PATCH] selftests/hid: fix failing tablet button tests
From: Jiri Kosina @ 2023-12-07 12:44 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Benjamin Tissoires, Shuah Khan, Peter Hutterer, linux-input,
linux-kselftest, linux-kernel
In-Reply-To: <20231207-b4-wip-selftests-v1-1-c4e13fe04a70@kernel.org>
On Thu, 7 Dec 2023, Benjamin Tissoires wrote:
> An overlook from commit 74452d6329be ("selftests/hid: tablets: add
> variants of states with buttons"), where I don't use the Enum...
>
> Fixes: 74452d6329be ("selftests/hid: tablets: add variants of states with buttons")
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Jiri Kosina <jkosina@suse.com>
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] selftests/hid: fix failing tablet button tests
From: Benjamin Tissoires @ 2023-12-07 12:22 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Shuah Khan, Peter Hutterer
Cc: Jiri Kosina, Benjamin Tissoires, linux-input, linux-kselftest,
linux-kernel
An overlook from commit 74452d6329be ("selftests/hid: tablets: add
variants of states with buttons"), where I don't use the Enum...
Fixes: 74452d6329be ("selftests/hid: tablets: add variants of states with buttons")
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
---
Not sure what happened, but I mustn't have run the tests before
sending the series, and they fail blatently.
I'm deeply sorry for that, I thought these failures were fixed.
Cheers,
Benjamin
---
tools/testing/selftests/hid/tests/test_tablet.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/hid/tests/test_tablet.py b/tools/testing/selftests/hid/tests/test_tablet.py
index dc8b0fe9e7f3..903f19f7cbe9 100644
--- a/tools/testing/selftests/hid/tests/test_tablet.py
+++ b/tools/testing/selftests/hid/tests/test_tablet.py
@@ -115,7 +115,7 @@ class PenState(Enum):
# we take only the highest button in account
for b in [libevdev.EV_KEY.BTN_STYLUS, libevdev.EV_KEY.BTN_STYLUS2]:
if bool(evdev.value[b]):
- button = b
+ button = BtnPressed(b)
# the kernel tends to insert an EV_SYN once removing the tool, so
# the button will be released after
@@ -155,7 +155,7 @@ class PenState(Enum):
if button_found:
raise ValueError(f"duplicated BTN_STYLUS* in {events}")
button_found = True
- button = ev.code if ev.value else None
+ button = BtnPressed(ev.code) if ev.value else None
# the kernel tends to insert an EV_SYN once removing the tool, so
# the button will be released after
---
base-commit: f556aa957df8cb3e98af0f54bf1fa65f59ae47a3
change-id: 20231207-b4-wip-selftests-c1565d4d4578
Best regards,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply related
* [PATCH v1 2/2] Input: atmel_mxt_ts - support poweroff in suspend
From: Stefan Eichenberger @ 2023-12-07 11:13 UTC (permalink / raw)
To: nick, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, linus.walleij
Cc: linux-input, devicetree, linux-arm-kernel, linux-kernel,
Stefan Eichenberger
In-Reply-To: <20231207111300.80581-1-eichest@gmail.com>
From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Add a new device tree property to indicate that the device should be
powered off in suspend mode. We have a shared regulator that powers the
display, a USB hub and some other peripherals. The maxtouch doesn't
normally disable the regulator in suspend mode, so our extra peripherals
stay powered on. This is not desirable as it consumes more power. With
this patch we add the option to disable the regulator in suspend mode
for the maxtouch and accept the longer initialisation time.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 72 ++++++++++++++++++------
1 file changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 20094b9899f0..7caa0d317d30 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -317,6 +317,7 @@ struct mxt_data {
struct gpio_desc *reset_gpio;
struct gpio_desc *wake_gpio;
bool use_retrigen_workaround;
+ bool poweroff_in_suspend;
/* Cached parameters from object table */
u16 T5_address;
@@ -2799,15 +2800,18 @@ static int mxt_configure_objects(struct mxt_data *data,
dev_warn(dev, "Error %d updating config\n", error);
}
- if (data->multitouch) {
- error = mxt_initialize_input_device(data);
- if (error)
- return error;
- } else {
- dev_warn(dev, "No touch object detected\n");
- }
+ /* If input device is not already registered */
+ if (!data->input_dev) {
+ if (data->multitouch) {
+ error = mxt_initialize_input_device(data);
+ if (error)
+ return error;
+ } else {
+ dev_warn(dev, "No touch object detected\n");
+ }
- mxt_debug_init(data);
+ mxt_debug_init(data);
+ }
return 0;
}
@@ -3328,6 +3332,8 @@ static int mxt_probe(struct i2c_client *client)
msleep(MXT_RESET_INVALID_CHG);
}
+ data->poweroff_in_suspend = device_property_read_bool(&client->dev,
+ "atmel,poweroff-in-suspend");
/*
* Controllers like mXT1386 have a dedicated WAKE line that could be
* connected to a GPIO or to I2C SCL pin, or permanently asserted low.
@@ -3390,12 +3396,21 @@ static int mxt_suspend(struct device *dev)
if (!input_dev)
return 0;
- mutex_lock(&input_dev->mutex);
+ if (!device_may_wakeup(dev) && data->poweroff_in_suspend) {
+ if (data->reset_gpio)
+ gpiod_set_value(data->reset_gpio, 1);
- if (input_device_enabled(input_dev))
- mxt_stop(data);
+ regulator_bulk_disable(ARRAY_SIZE(data->regulators),
+ data->regulators);
+ data->T44_address = 0;
+ } else {
+ mutex_lock(&input_dev->mutex);
+
+ if (input_device_enabled(input_dev))
+ mxt_stop(data);
- mutex_unlock(&input_dev->mutex);
+ mutex_unlock(&input_dev->mutex);
+ }
disable_irq(data->irq);
@@ -3411,14 +3426,37 @@ static int mxt_resume(struct device *dev)
if (!input_dev)
return 0;
- enable_irq(data->irq);
+ if (!device_may_wakeup(dev) && data->poweroff_in_suspend) {
+ int ret;
- mutex_lock(&input_dev->mutex);
+ ret = regulator_bulk_enable(ARRAY_SIZE(data->regulators),
+ data->regulators);
+ if (ret) {
+ dev_err(dev, "failed to enable regulators: %d\n",
+ ret);
+ return ret;
+ }
+ msleep(MXT_BACKUP_TIME);
- if (input_device_enabled(input_dev))
- mxt_start(data);
+ if (data->reset_gpio) {
+ /* Wait a while and then de-assert the RESET GPIO line */
+ msleep(MXT_RESET_GPIO_TIME);
+ gpiod_set_value(data->reset_gpio, 0);
+ msleep(MXT_RESET_INVALID_CHG);
+ }
- mutex_unlock(&input_dev->mutex);
+ /* This also enables the irq again */
+ mxt_initialize(data);
+ } else {
+ enable_irq(data->irq);
+
+ mutex_lock(&input_dev->mutex);
+
+ if (input_device_enabled(input_dev))
+ mxt_start(data);
+
+ mutex_unlock(&input_dev->mutex);
+ }
return 0;
}
--
2.40.1
^ permalink raw reply related
* [PATCH v1 1/2] dt-bindings: input: atmel,maxtouch: add poweroff-in-suspend property
From: Stefan Eichenberger @ 2023-12-07 11:12 UTC (permalink / raw)
To: nick, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, linus.walleij
Cc: linux-input, devicetree, linux-arm-kernel, linux-kernel,
Stefan Eichenberger
In-Reply-To: <20231207111300.80581-1-eichest@gmail.com>
From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Add a new property to indicate that the device should be powered off in
suspend mode.
Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
---
Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index c40799355ed7..047a5101341c 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -87,6 +87,12 @@ properties:
- 2 # ATMEL_MXT_WAKEUP_GPIO
default: 0
+ atmel,poweroff-in-suspend:
+ description: |
+ When this property is set, all supplies are turned off when the system is
+ going to suspend.
+ type: boolean
+
wakeup-source:
type: boolean
--
2.40.1
^ permalink raw reply related
* [PATCH v1 0/2] Add a property to turn off the max touch controller in suspend mode
From: Stefan Eichenberger @ 2023-12-07 11:12 UTC (permalink / raw)
To: nick, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt, conor+dt,
nicolas.ferre, alexandre.belloni, claudiu.beznea, linus.walleij
Cc: linux-input, devicetree, linux-arm-kernel, linux-kernel,
Stefan Eichenberger
From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Our hardware has a shared regulator that powers various peripherals such
as the display, touch, USB hub, etc. Since the Maxtouch controller
doesn't currently allow it to be turned off, this regulator has to stay
on in suspend mode. This increases the overall power consumption. In
order to turn off the controller when the system goes into suspend mode,
this series adds a device tree property to the maxtouch driver that
allows the controller to be turned off completely and ensurs that it can
resume from the power off state.
Stefan Eichenberger (2):
dt-bindings: input: atmel,maxtouch: add power-off-in-suspend property
Input: atmel_mxt_ts - support power off in suspend
.../bindings/input/atmel,maxtouch.yaml | 6 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 72 ++++++++++++++-----
2 files changed, 61 insertions(+), 17 deletions(-)
--
2.40.1
^ permalink raw reply
* RE: [PATCH v4 0/8] Convert DA906{1,2} bindings to json-schema
From: Biju Das @ 2023-12-07 9:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <22597bf1-b623-4c5d-b230-c2054c4c13b5@linaro.org>
Hi Krzysztof Kozlowski,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Thursday, December 7, 2023 9:16 AM
> Subject: Re: [PATCH v4 0/8] Convert DA906{1,2} bindings to json-schema
>
> On 07/12/2023 10:01, Biju Das wrote:
> > Hi Krzysztof Kozlowski, Lee Jones,
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >> Sent: Thursday, December 7, 2023 8:38 AM
> >> Subject: Re: [PATCH v4 0/8] Convert DA906{1,2} bindings to
> >> json-schema
> >>
> >> On 06/12/2023 16:57, Biju Das wrote:
> >>> Convert the below bindings to json-schema
> >>> 1) DA906{1,2} mfd bindings
> >>> 2) DA906{1,2,3} onkey bindings
> >>> 3) DA906{1,2,3} thermal bindings
> >>>
> >>> Also add fallback for DA9061 watchdog device and document
> >>> DA9063 watchdog device.
> >>
> >> Please explain here dependencies and make clear merging strategy. The
> >> patches cannot be taken independently.
> >
> > Rob mentioned it needs to be taken through MFD tree. See [1]
> >
>
> This I know, but you must explain it here - not in my reply, but in the
> cover letter. No one will remember what was agreed days ago, not
> mentioning that not everyone could read Rob's message. So how anyone
> reading your cover letter could know it?
Agreed, Will mention it in cover letter.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v4 0/8] Convert DA906{1,2} bindings to json-schema
From: Krzysztof Kozlowski @ 2023-12-07 9:16 UTC (permalink / raw)
To: Biju Das, Lee Jones, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB11269663E4EE04920195D708D868BA@TYCPR01MB11269.jpnprd01.prod.outlook.com>
On 07/12/2023 10:01, Biju Das wrote:
> Hi Krzysztof Kozlowski, Lee Jones,
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> Sent: Thursday, December 7, 2023 8:38 AM
>> Subject: Re: [PATCH v4 0/8] Convert DA906{1,2} bindings to json-schema
>>
>> On 06/12/2023 16:57, Biju Das wrote:
>>> Convert the below bindings to json-schema
>>> 1) DA906{1,2} mfd bindings
>>> 2) DA906{1,2,3} onkey bindings
>>> 3) DA906{1,2,3} thermal bindings
>>>
>>> Also add fallback for DA9061 watchdog device and document
>>> DA9063 watchdog device.
>>
>> Please explain here dependencies and make clear merging strategy. The
>> patches cannot be taken independently.
>
> Rob mentioned it needs to be taken through MFD tree. See [1]
>
This I know, but you must explain it here - not in my reply, but in the
cover letter. No one will remember what was agreed days ago, not
mentioning that not everyone could read Rob's message. So how anyone
reading your cover letter could know it?
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v4 0/8] Convert DA906{1,2} bindings to json-schema
From: Biju Das @ 2023-12-07 9:01 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input@vger.kernel.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven, Prabhakar Mahadev Lad, biju.das.au,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <874165ae-c7a2-4f04-825a-aa9d6f4d4cb3@linaro.org>
Hi Krzysztof Kozlowski, Lee Jones,
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Thursday, December 7, 2023 8:38 AM
> Subject: Re: [PATCH v4 0/8] Convert DA906{1,2} bindings to json-schema
>
> On 06/12/2023 16:57, Biju Das wrote:
> > Convert the below bindings to json-schema
> > 1) DA906{1,2} mfd bindings
> > 2) DA906{1,2,3} onkey bindings
> > 3) DA906{1,2,3} thermal bindings
> >
> > Also add fallback for DA9061 watchdog device and document
> > DA9063 watchdog device.
>
> Please explain here dependencies and make clear merging strategy. The
> patches cannot be taken independently.
Rob mentioned it needs to be taken through MFD tree. See [1]
[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20231202192536.266885-9-biju.das.jz@bp.renesas.com/#25620636
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH v2 00/15] selftests/hid: tablets fixes
From: Benjamin Tissoires @ 2023-12-07 8:56 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, Shuah Khan, Peter Hutterer, linux-input,
linux-kselftest, linux-kernel
In-Reply-To: <170193920703.229356.5910722658341910962.b4-ty@kernel.org>
On Thu, Dec 7, 2023 at 9:53 AM Benjamin Tissoires <bentiss@kernel.org> wrote:
>
> On Wed, 06 Dec 2023 11:45:51 +0100, Benjamin Tissoires wrote:
> > the main trigger of this series was the XP-Pen issue[0].
> > Basically, the tablets tests were good-ish but couldn't
> > handle that tablet both in terms of emulation or in terms
> > of detection of issues.
> >
> > So rework the tablets test a bit to be able to include the
> > XP-Pen patch later, once I have a kernel fix for it (right
> > now I only have a HID-BPF fix, meaning that the test will
> > fail if I include them).
> >
> > [...]
>
> Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-5.8/selftests), thanks!
of course, it's for-6.8/selftests, not 5.8 :)
Cheers,
Benjamin
>
> [01/15] selftests/hid: vmtest.sh: update vm2c and container
> https://git.kernel.org/hid/hid/c/887f8094b335
> [02/15] selftests/hid: vmtest.sh: allow finer control on the build steps
> https://git.kernel.org/hid/hid/c/46bc0277c250
> [03/15] selftests/hid: base: allow for multiple skip_if_uhdev
> https://git.kernel.org/hid/hid/c/110292a77f7c
> [04/15] selftests/hid: tablets: remove unused class
> https://git.kernel.org/hid/hid/c/b5edacf79c8e
> [05/15] selftests/hid: tablets: move the transitions to PenState
> https://git.kernel.org/hid/hid/c/d52f52069fed
> [06/15] selftests/hid: tablets: move move_to function to PenDigitizer
> https://git.kernel.org/hid/hid/c/881ccc36b426
> [07/15] selftests/hid: tablets: do not set invert when the eraser is used
> https://git.kernel.org/hid/hid/c/d8d7aa2266a7
> [08/15] selftests/hid: tablets: set initial data for tilt/twist
> https://git.kernel.org/hid/hid/c/e08e493ff961
> [09/15] selftests/hid: tablets: define the elements of PenState
> https://git.kernel.org/hid/hid/c/83912f83fabc
> [10/15] selftests/hid: tablets: add variants of states with buttons
> https://git.kernel.org/hid/hid/c/74452d6329be
> [11/15] selftests/hid: tablets: convert the primary button tests
> https://git.kernel.org/hid/hid/c/1f01537ef17e
> [12/15] selftests/hid: tablets: add a secondary barrel switch test
> https://git.kernel.org/hid/hid/c/76df1f72fb25
> [13/15] selftests/hid: tablets: be stricter for some transitions
> https://git.kernel.org/hid/hid/c/ab9b82909e9b
> [14/15] selftests/hid: fix mypy complains
> https://git.kernel.org/hid/hid/c/ed5bc56cedca
> [15/15] selftests/hid: fix ruff linter complains
> https://git.kernel.org/hid/hid/c/f556aa957df8
>
> Cheers,
> --
> Benjamin Tissoires <bentiss@kernel.org>
>
^ permalink raw reply
* Re: [PATCH v2 00/15] selftests/hid: tablets fixes
From: Benjamin Tissoires @ 2023-12-07 8:53 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Shuah Khan, Peter Hutterer,
Benjamin Tissoires
Cc: linux-input, linux-kselftest, linux-kernel
In-Reply-To: <20231206-wip-selftests-v2-0-c0350c2f5986@kernel.org>
On Wed, 06 Dec 2023 11:45:51 +0100, Benjamin Tissoires wrote:
> the main trigger of this series was the XP-Pen issue[0].
> Basically, the tablets tests were good-ish but couldn't
> handle that tablet both in terms of emulation or in terms
> of detection of issues.
>
> So rework the tablets test a bit to be able to include the
> XP-Pen patch later, once I have a kernel fix for it (right
> now I only have a HID-BPF fix, meaning that the test will
> fail if I include them).
>
> [...]
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git (for-5.8/selftests), thanks!
[01/15] selftests/hid: vmtest.sh: update vm2c and container
https://git.kernel.org/hid/hid/c/887f8094b335
[02/15] selftests/hid: vmtest.sh: allow finer control on the build steps
https://git.kernel.org/hid/hid/c/46bc0277c250
[03/15] selftests/hid: base: allow for multiple skip_if_uhdev
https://git.kernel.org/hid/hid/c/110292a77f7c
[04/15] selftests/hid: tablets: remove unused class
https://git.kernel.org/hid/hid/c/b5edacf79c8e
[05/15] selftests/hid: tablets: move the transitions to PenState
https://git.kernel.org/hid/hid/c/d52f52069fed
[06/15] selftests/hid: tablets: move move_to function to PenDigitizer
https://git.kernel.org/hid/hid/c/881ccc36b426
[07/15] selftests/hid: tablets: do not set invert when the eraser is used
https://git.kernel.org/hid/hid/c/d8d7aa2266a7
[08/15] selftests/hid: tablets: set initial data for tilt/twist
https://git.kernel.org/hid/hid/c/e08e493ff961
[09/15] selftests/hid: tablets: define the elements of PenState
https://git.kernel.org/hid/hid/c/83912f83fabc
[10/15] selftests/hid: tablets: add variants of states with buttons
https://git.kernel.org/hid/hid/c/74452d6329be
[11/15] selftests/hid: tablets: convert the primary button tests
https://git.kernel.org/hid/hid/c/1f01537ef17e
[12/15] selftests/hid: tablets: add a secondary barrel switch test
https://git.kernel.org/hid/hid/c/76df1f72fb25
[13/15] selftests/hid: tablets: be stricter for some transitions
https://git.kernel.org/hid/hid/c/ab9b82909e9b
[14/15] selftests/hid: fix mypy complains
https://git.kernel.org/hid/hid/c/ed5bc56cedca
[15/15] selftests/hid: fix ruff linter complains
https://git.kernel.org/hid/hid/c/f556aa957df8
Cheers,
--
Benjamin Tissoires <bentiss@kernel.org>
^ permalink raw reply
* Re: RMI4: The RMI4 specification not found
From: Kamil Duljas @ 2023-12-07 8:52 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, Andrew Duggan, Christopher Heiny,
marge.yang
In-Reply-To: <CAFR=A7mFbMH9xt=FnzQzeZUtYv0AAMK=9DfPaBNcttpFj1z7Jg@mail.gmail.com>
It nice to update this document. I found a problem with out-of-bounds
memory during probe device. I need new manual to create issue.
Kamil
śr., 22 lis 2023 o 21:46 Kamil Duljas <kamil.duljas@gmail.com> napisał(a):
>
> Hi,
> I would like to become familiar with RMI4 driver in the recent linux
> kernel but I couldn't find a reference manual to RMI4 specification.
> On the net I found an old version without the f12 feature.
> Follow path: drivers/input/rmi4/rmi_driver.c contains link
> http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
> returns 404
>
> --
> Pozdrawiam,
> Kamil Duljas
--
Pozdrawiam,
Kamil Duljas
^ permalink raw reply
* Re: [PATCH v4 8/8] dt-bindings: mfd: dlg,da9063: Convert da9062 to json-schema
From: Krzysztof Kozlowski @ 2023-12-07 8:43 UTC (permalink / raw)
To: Biju Das, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones
Cc: Support Opensource, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Steve Twiss, linux-input, devicetree, linux-pm,
Geert Uytterhoeven, Prabhakar Mahadev Lad, Biju Das,
linux-renesas-soc
In-Reply-To: <20231206155740.5278-9-biju.das.jz@bp.renesas.com>
On 06/12/2023 16:57, Biju Das wrote:
> Convert the da9062 PMIC device tree binding documentation to json-schema.
>
> Update the example to match reality.
>
> While at it, update description with link to product information.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> v3->v4:
> * Split the thermal binding patch separate.
> * Updated the description.
> v2->v3:
> * Fixed bot errors related to MAINTAINERS entry, invalid doc
> references and thermal examples by merging patch#4.
> v2:
> * New patch
> ---
> .../bindings/input/dlg,da9062-onkey.yaml | 3 +-
> .../devicetree/bindings/mfd/da9062.txt | 124 ------------
> .../devicetree/bindings/mfd/dlg,da9063.yaml | 186 +++++++++++++++++-
> .../bindings/thermal/dlg,da9062-thermal.yaml | 2 +-
> 4 files changed, 183 insertions(+), 132 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mfd/da9062.txt
>
> diff --git a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
> index 4cff91f4bd34..18b6a3f02c07 100644
> --- a/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
> +++ b/Documentation/devicetree/bindings/input/dlg,da9062-onkey.yaml
> @@ -11,8 +11,7 @@ maintainers:
>
> description: |
> This module is part of the DA9061/DA9062/DA9063. For more details about entire
> - DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
> - For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> + DA906{1,2,3} chips see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
>
> This module provides the KEY_POWER event.
>
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt b/Documentation/devicetree/bindings/mfd/da9062.txt
> deleted file mode 100644
> index c8a7f119ac84..000000000000
> --- a/Documentation/devicetree/bindings/mfd/da9062.txt
> +++ /dev/null
> @@ -1,124 +0,0 @@
> -* Dialog DA9062 Power Management Integrated Circuit (PMIC)
> -
> -Product information for the DA9062 and DA9061 devices can be found here:
> -- https://www.dialog-semiconductor.com/products/da9062
> -- https://www.dialog-semiconductor.com/products/da9061
> -
> -The DA9062 PMIC consists of:
> -
> -Device Supply Names Description
> ------- ------------ -----------
> -da9062-regulator : : LDOs & BUCKs
> -da9062-rtc : : Real-Time Clock
> -da9062-onkey : : On Key
> -da9062-watchdog : : Watchdog Timer
> -da9062-thermal : : Thermal
> -da9062-gpio : : GPIOs
> -
> -The DA9061 PMIC consists of:
> -
> -Device Supply Names Description
> ------- ------------ -----------
> -da9062-regulator : : LDOs & BUCKs
> -da9062-onkey : : On Key
> -da9062-watchdog : : Watchdog Timer
> -da9062-thermal : : Thermal
> -
> -======
> -
> -Required properties:
> -
> -- compatible : Should be
> - "dlg,da9062" for DA9062
> - "dlg,da9061" for DA9061
> -- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
> - modified to match the chip's OTP settings).
> -
> -Optional properties:
> -
> -- gpio-controller : Marks the device as a gpio controller.
> -- #gpio-cells : Should be two. The first cell is the pin number and the
> - second cell is used to specify the gpio polarity.
> -
> -See Documentation/devicetree/bindings/gpio/gpio.txt for further information on
> -GPIO bindings.
> -
> -- interrupts : IRQ line information.
> -- interrupt-controller
> -
> -See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
> -further information on IRQ bindings.
> -
> -Sub-nodes:
> -
> -- regulators : This node defines the settings for the LDOs and BUCKs.
> - The DA9062 regulators are bound using their names listed below:
> -
> - buck1 : BUCK_1
> - buck2 : BUCK_2
> - buck3 : BUCK_3
> - buck4 : BUCK_4
> - ldo1 : LDO_1
> - ldo2 : LDO_2
> - ldo3 : LDO_3
> - ldo4 : LDO_4
> -
> - The DA9061 regulators are bound using their names listed below:
> -
> - buck1 : BUCK_1
> - buck2 : BUCK_2
> - buck3 : BUCK_3
> - ldo1 : LDO_1
> - ldo2 : LDO_2
> - ldo3 : LDO_3
> - ldo4 : LDO_4
> -
> - The component follows the standard regulator framework and the bindings
> - details of individual regulator device can be found in:
> - Documentation/devicetree/bindings/regulator/regulator.txt
> -
> - regulator-initial-mode may be specified for buck regulators using mode values
> - from include/dt-bindings/regulator/dlg,da9063-regulator.h.
> -
> -- rtc : This node defines settings required for the Real-Time Clock associated
> - with the DA9062. There are currently no entries in this binding, however
> - compatible = "dlg,da9062-rtc" should be added if a node is created.
> -
> -- onkey : See ../input/dlg,da9062-onkey.yaml
> -
> -- watchdog: See ../watchdog/dlg,da9062-watchdog.yaml
> -
> -- thermal : See ../thermal/dlg,da9062-thermal.yaml
> -
> -Example:
> -
> - pmic0: da9062@58 {
> - compatible = "dlg,da9062";
> - reg = <0x58>;
> - interrupt-parent = <&gpio6>;
> - interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> - interrupt-controller;
> -
> - rtc {
> - compatible = "dlg,da9062-rtc";
> - };
> -
> - regulators {
> - DA9062_BUCK1: buck1 {
> - regulator-name = "BUCK1";
> - regulator-min-microvolt = <300000>;
> - regulator-max-microvolt = <1570000>;
> - regulator-min-microamp = <500000>;
> - regulator-max-microamp = <2000000>;
> - regulator-initial-mode = <DA9063_BUCK_MODE_SYNC>;
> - regulator-boot-on;
> - };
> - DA9062_LDO1: ldo1 {
> - regulator-name = "LDO_1";
> - regulator-min-microvolt = <900000>;
> - regulator-max-microvolt = <3600000>;
> - regulator-boot-on;
> - };
> - };
> - };
> -
> diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> index 676b4f2566ae..54bb23dbc73f 100644
> --- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> +++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
> @@ -4,7 +4,7 @@
> $id: http://devicetree.org/schemas/mfd/dlg,da9063.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC)
> +title: Dialog DA906{3L,3,2,1} Power Management Integrated Circuit (PMIC)
>
> maintainers:
> - Steve Twiss <stwiss.opensource@diasemi.com>
> @@ -17,10 +17,17 @@ description: |
> moment where all voltage monitors are disabled. Next, as da9063 only supports
> UV *and* OV monitoring, both must be set to the same severity and value
> (0: disable, 1: enable).
> + Product information for the DA906{3L,3,2,1} devices can be found here:
> + - https://www.dialog-semiconductor.com/products/da9063l
> + - https://www.dialog-semiconductor.com/products/da9063
> + - https://www.dialog-semiconductor.com/products/da9062
> + - https://www.dialog-semiconductor.com/products/da9061
>
> properties:
> compatible:
> enum:
> + - dlg,da9061
> + - dlg,da9062
> - dlg,da9063
> - dlg,da9063l
>
> @@ -35,6 +42,19 @@ properties:
> "#interrupt-cells":
> const: 2
>
> + gpio:
Old binding did not have such node and nothing in commit msg explained
changes from pure conversion.
> + type: object
> + $ref: /schemas/gpio/gpio.yaml#
?!? Why? First: It's always selected. Second, so you have two gpio
controllers? And original binding had 0? Why this is not explained at
all? Open the binding and look at its properties.
> + unevaluatedProperties: false
> + properties:
> + compatible:
> + const: dlg,da9062-gpio
> +
> + gpio-controller: true
And here is the second gpio-controller...
> +
> + "#gpio-cells":
> + const: 2
> +
> onkey:
> $ref: /schemas/input/dlg,da9062-onkey.yaml
>
> @@ -42,7 +62,7 @@ properties:
> type: object
> additionalProperties: false
> patternProperties:
> - "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$":
> + "^(ldo([1-9]|1[01])|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck[1-4])$":
> $ref: /schemas/regulator/regulator.yaml
> unevaluatedProperties: false
>
> @@ -52,7 +72,12 @@ properties:
> unevaluatedProperties: false
> properties:
> compatible:
> - const: dlg,da9063-rtc
> + enum:
> + - dlg,da9063-rtc
> + - dlg,da9062-rtc
> +
> + thermal:
> + $ref: /schemas/thermal/dlg,da9062-thermal.yaml
>
> watchdog:
> $ref: /schemas/watchdog/dlg,da9062-watchdog.yaml
> @@ -60,8 +85,65 @@ properties:
> required:
> - compatible
> - reg
> - - interrupts
> - - interrupt-controller
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - dlg,da9063
> + - dlg,da9063l
> + then:
> + properties:
> + thermal: false
> + gpio: false
> + gpio-controller: false
> + "#gpio-cells": false
> + regulators:
> + patternProperties:
> + "^buck[1-4]$": false
> + required:
> + - interrupts
> + - interrupt-controller
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - dlg,da9062
> + then:
> + properties:
> + regulators:
> + patternProperties:
> + "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged)$": false
> + required:
> + - gpio
> + - onkey
> + - rtc
> + - thermal
> + - watchdog
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - dlg,da9061
> + then:
> + properties:
> + gpio: false
> + gpio-controller: false
> + "#gpio-cells": false
> + regulators:
> + patternProperties:
> + "^(ldo([5-9]|10|11)|bcore([1-2]|s-merged)|b(pro|mem|io|peri)|bmem-bio-merged|buck4)$": false
> + rtc: false
> + required:
> + - onkey
> + - thermal
> + - watchdog
>
> additionalProperties: false
>
> @@ -118,4 +200,98 @@ examples:
> };
> };
> };
> +
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/regulator/dlg,da9063-regulator.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pmic@58 {
> + compatible = "dlg,da9062";
> + reg = <0x58>;
> + #interrupt-cells = <2>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> +
> + gpio {
> + compatible = "dlg,da9062-gpio";
> + status = "disabled";
Why?
Where are gpio-controller and cells? For this node and for parent? Why
this example is incomplete?
> + };
> +
> + onkey {
> + compatible = "dlg,da9062-onkey";
> + };
Best regards,
Krzysztof
^ 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