* Re: [PATCH 1/1] HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT related user initiated OOB write
From: Lee Jones @ 2026-03-19 8:45 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Filipe Laíns, linux-input, linux-kernel
In-Reply-To: <o5n60785-0900-7869-sn47-7977p8so17nq@xreary.bet>
On Tue, 17 Mar 2026, Jiri Kosina wrote:
> On Tue, 17 Mar 2026, Lee Jones wrote:
>
> > > > diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> > > > index 44b716697510..885b986c7a12 100644
> > > > --- a/drivers/hid/hid-logitech-dj.c
> > > > +++ b/drivers/hid/hid-logitech-dj.c
> > > > @@ -1282,6 +1282,12 @@ static int logi_dj_recv_send_report(struct dj_receiver_dev *djrcv_dev,
> > > > return -ENODEV;
> > > > }
> > > >
> > > > + if (report->maxfield < 1 || report->field[0]->report_count != DJREPORT_SHORT_LENGTH - 1) {
> > >
> > > This is all static information. So this should be checked in the
> > > .probe(), once the device has been parsed, not for every single call of
> > > logi_dj_recv_send_report().
> >
> > Doesn't report_count come from the device?
>
> The point is -- maxfield and report_count can't change once parsed unless
> the report descriptor would be re-read and re-parsed (which doesn't happen
> in runtime, only during probe).
>
> So checking during probe/parse time just once should be sufficient,
> instead of checking it upon every received report.
Okay, thanks for the explanation. I'll give it a shot.
--
Lee Jones [李琼斯]
^ permalink raw reply
* [ardb:x86-pie-v4-wip] [x86] fa65278b9b: kunit.VCAP_API_DebugFS_Testsuite.vcap_api_show_admin_raw_test.fail
From: kernel test robot @ 2026-03-19 8:00 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: oe-lkp, lkp, linux-kernel, linux-arch, linux-input, oliver.sang
Hello,
we don't have enough knowledge how this change caused below kunit test failed,
but the results in our tests are quite persistent.
=========================================================================================
tbox_group/testcase/rootfs/kconfig/compiler/group:
lkp-hsw-d03/kunit/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-kunit/gcc-14/group-03
96f4aca8b6e7fd65 fa65278b9bdce81fddb3ec54017
---------------- ---------------------------
fail:runs %reproduction fail:runs
| | |
:30 100% 30:30 kunit.VCAP_API_DebugFS_Testsuite.vcap_api_show_admin_raw_test.fail
btw, the configs have below diff which seems reasonable to us.
--- /pkg/linux/x86_64-rhel-9.4-kunit/gcc-14/96f4aca8b6e7fd654c7fd3ce990e3326345c8f3b/.config 2026-03-18 11:03:48.295524180 +0800
+++ /pkg/linux/x86_64-rhel-9.4-kunit/gcc-14/fa65278b9bdce81fddb3ec54017ccc384fd42dca/.config 2026-03-18 11:04:47.609268479 +0800
@@ -530,6 +530,7 @@ CONFIG_ARCH_SUPPORTS_CRASH_HOTPLUG=y
CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
+CONFIG_RELOCATABLE_PIE=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x200000
below is full report FYI.
kernel test robot noticed "kunit.VCAP_API_DebugFS_Testsuite.vcap_api_show_admin_raw_test.fail" on:
commit: fa65278b9bdce81fddb3ec54017ccc384fd42dca ("x86: Use PIE codegen for the relocatable 64-bit kernel")
https://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git x86-pie-v4-wip
in testcase: kunit
version:
with following parameters:
group: group-03
config: x86_64-rhel-9.4-kunit
compiler: gcc-14
test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (Haswell) with 16G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
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 <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202603191529.cfc2cbbe-lkp@intel.com
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260319/202603191529.cfc2cbbe-lkp@intel.com
kern :err : [ 109.892567] [ T3126] # vcap_api_show_admin_raw_test: EXPECTATION FAILED at drivers/net/ethernet/microchip/vcap/vcap_api_debugfs_kunit.c:377
Expected test_expected == test_pr_buffer[0], but
test_expected == " addr: 786, X6 rule, keysets: VCAP_KFS_MAC_ETYPE
"
test_pr_buffer[0] == ""
kern :info : [ 109.898412] [ T1] not ok 2 vcap_api_show_admin_raw_test
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Krzysztof Kozlowski @ 2026-03-19 7:23 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Luca Leonardo Scorcia, linux-mediatek, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Julien Massot, Gary Bisson, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAGXv+5EqUhJ62fjE0R9nLcu6tsfXan8ZEYe7hvkofKnFM7W8NQ@mail.gmail.com>
On 19/03/2026 05:53, Chen-Yu Tsai wrote:
>>> I understood this is that electrical constraints are a matter of the
>>> actual board layout, so if adjustments are needed they have to be in
>>> the board dts. But you also specify "If fixed", so maybe there's an
>>> exception to this rule when the constraint is "absolute" and boards
>>> can't actually set a different value?
>>
>> Now I am confused. You wrote - LDOs with fixed 1.8V output - so board
>> cannot set it to 2.0V for example. They are affixed. This regulator
>> CANNOT physically produce anything else.
>
> As you said, it cannot physically produce anything else. IMO it doesn't
> even need voltage constraints as it is already implied by the model and
> regulator output, in which case I would actually recommend rejecting
> min/max voltage being added to this node.
But the text is not helping and not doing much good here. So either this
should be schema or nothing. I agree though that having here no
constraints in final DTS is valid.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: touchscreen: trivial-touch: Move allOf: after required:
From: Dmitry Torokhov @ 2026-03-19 5:12 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Conor Dooley, Frank Li, Job Noorman,
Krzysztof Kozlowski, Rob Herring, linux-input, linux-renesas-soc
In-Reply-To: <20260312224925.186077-1-marek.vasut+renesas@mailbox.org>
On Thu, Mar 12, 2026 at 11:49:01PM +0100, Marek Vasut wrote:
> Majority of schemas place allOf: after required: . Documentation
> Documentation/devicetree/bindings/writing-schema.rst also hints at
> this ordering. Trivially update this schema. No functional change.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: touchscreen: Convert TS-4800 to DT schema
From: Dmitry Torokhov @ 2026-03-19 5:05 UTC (permalink / raw)
To: Eduard Bostina
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Brown, linux-input,
devicetree, linux-kernel
In-Reply-To: <20260316181038.9771-1-egbostina@gmail.com>
On Mon, Mar 16, 2026 at 08:10:37PM +0200, Eduard Bostina wrote:
> Convert the TS-4800 touchscreen bindings to DT schema.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: Chen-Yu Tsai @ 2026-03-19 5:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Louis-Alexis Eyraud, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-8-l.scorcia@gmail.com>
On Wed, Mar 18, 2026 at 2:46 AM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> From: Fabien Parent <parent.f@gmail.com>
>
> The MT6392 is a regulator found on boards based on the MediaTek
> MT8167, MT8516, and probably other SoCs. It is a so called PMIC and
> connects as a slave to a SoC using SPI, wrapped inside PWRAP.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Co-developed-by: Val Packett <val@packett.cool>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/mt6392-regulator.c | 487 +++++++++++++++++++++
> include/linux/regulator/mt6392-regulator.h | 40 ++
> 4 files changed, 537 insertions(+)
> create mode 100644 drivers/regulator/mt6392-regulator.c
> create mode 100644 include/linux/regulator/mt6392-regulator.h
>
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index d2335276cce5..66876d730807 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -991,6 +991,15 @@ config REGULATOR_MT6380
> This driver supports the control of different power rails of device
> through regulator interface.
>
> +config REGULATOR_MT6392
> + tristate "MediaTek MT6392 PMIC"
> + depends on MFD_MT6397
> + help
> + Say y here to select this option to enable the power regulator of
> + MediaTek MT6392 PMIC.
> + This driver supports the control of different power rails of device
> + through regulator interface.
> +
> config REGULATOR_MT6397
> tristate "MediaTek MT6397 PMIC"
> depends on MFD_MT6397
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 1beba1493241..db5145cfcf36 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -117,6 +117,7 @@ obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
> obj-$(CONFIG_REGULATOR_MT6363) += mt6363-regulator.o
> obj-$(CONFIG_REGULATOR_MT6370) += mt6370-regulator.o
> obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
> +obj-$(CONFIG_REGULATOR_MT6392) += mt6392-regulator.o
> obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
> obj-$(CONFIG_REGULATOR_MTK_DVFSRC) += mtk-dvfsrc-regulator.o
> obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
> diff --git a/drivers/regulator/mt6392-regulator.c b/drivers/regulator/mt6392-regulator.c
> new file mode 100644
> index 000000000000..50cc0019f48a
> --- /dev/null
> +++ b/drivers/regulator/mt6392-regulator.c
> @@ -0,0 +1,487 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Copyright (c) 2020 MediaTek Inc.
> +// Copyright (c) 2020 BayLibre, SAS.
> +// Author: Chen Zhong <chen.zhong@mediatek.com>
> +// Author: Fabien Parent <fparent@baylibre.com>
> +//
> +// Based on mt6397-regulator.c
> +
> +#include <linux/module.h>
> +#include <linux/linear_range.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/mt6397/core.h>
> +#include <linux/mfd/mt6392/registers.h>
> +#include <linux/regulator/driver.h>
> +#include <linux/regulator/machine.h>
> +#include <linux/regulator/mt6392-regulator.h>
> +#include <linux/regulator/of_regulator.h>
> +#include <dt-bindings/regulator/mediatek,mt6392-regulator.h>
> +
> +/*
> + * MT6392 regulators' information
> + *
> + * @desc: standard fields of regulator description.
> + * @qi: Mask for query enable signal status of regulators
> + * @vselon_reg: Register sections for hardware control mode of bucks
> + * @vselctrl_reg: Register for controlling the buck control mode.
> + * @vselctrl_mask: Mask for query buck's voltage control mode.
> + */
> +struct mt6392_regulator_info {
> + struct regulator_desc desc;
> + u32 qi;
> + u32 vselon_reg;
> + u32 vselctrl_reg;
> + u32 vselctrl_mask;
> + u32 modeset_reg;
> + u32 modeset_mask;
> +};
> +
> +#define MT6392_BUCK(match, vreg, min, max, step, volt_ranges, enreg, \
> + vosel, vosel_mask, voselon, vosel_ctrl, \
> + _modeset_reg, _modeset_mask, rampdelay) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_range_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = ((max) - (min)) / (step) + 1, \
> + .linear_ranges = volt_ranges, \
> + .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
> + .vsel_reg = vosel, \
> + .vsel_mask = vosel_mask, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(0), \
> + .ramp_delay = rampdelay, \
Please add the supply names.
> + }, \
> + .qi = BIT(13), \
> + .vselon_reg = voselon, \
> + .vselctrl_reg = vosel_ctrl, \
> + .vselctrl_mask = BIT(1), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel, \
> + vosel_mask, _modeset_reg, _modeset_mask, entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_table_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = ARRAY_SIZE(ldo_volt_table), \
> + .volt_table = ldo_volt_table, \
> + .vsel_reg = vosel, \
> + .vsel_mask = vosel_mask, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + }, \
> + .qi = BIT(15), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_LDO_LINEAR(match, vreg, min, max, step, volt_ranges, \
> + enreg, enbit, vosel, vosel_mask, _modeset_reg, \
> + _modeset_mask, entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_ldo_range_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = ((max) - (min)) / (step) + 1, \
> + .linear_ranges = volt_ranges, \
> + .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
> + .vsel_reg = vosel, \
> + .vsel_mask = vosel_mask, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + }, \
> + .qi = BIT(15), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_REG_FIXED(match, vreg, enreg, enbit, volt, \
> + _modeset_reg, _modeset_mask, entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_fixed_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = 1, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + .min_uV = volt, \
> + }, \
> + .qi = BIT(15), \
> + .modeset_reg = _modeset_reg, \
> + .modeset_mask = _modeset_mask, \
> +}
> +
> +#define MT6392_REG_FIXED_NO_MODE(match, vreg, enreg, enbit, volt, \
> + entime) \
> +[MT6392_ID_##vreg] = { \
> + .desc = { \
> + .name = #vreg, \
> + .of_match = of_match_ptr(match), \
> + .ops = &mt6392_volt_fixed_no_mode_ops, \
> + .type = REGULATOR_VOLTAGE, \
> + .id = MT6392_ID_##vreg, \
> + .owner = THIS_MODULE, \
> + .n_voltages = 1, \
> + .enable_reg = enreg, \
> + .enable_mask = BIT(enbit), \
> + .enable_time = entime, \
> + .min_uV = volt, \
> + }, \
> + .qi = BIT(15), \
> +}
> +
> +static const struct linear_range buck_volt_range1[] = {
> + REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250),
> +};
> +
> +static const struct linear_range buck_volt_range2[] = {
> + REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500),
> +};
> +
> +static const u32 ldo_volt_table1[] = {
> + 1800000, 1900000, 2000000, 2200000,
> +};
> +
> +static const struct linear_range ldo_volt_range2[] = {
> + REGULATOR_LINEAR_RANGE(3300000, 0, 3, 100000),
> +};
> +
> +static const u32 ldo_volt_table3[] = {
> + 1800000, 3300000,
> +};
> +
> +static const u32 ldo_volt_table4[] = {
> + 3000000, 3300000,
> +};
> +
> +static const u32 ldo_volt_table5[] = {
> + 1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000,
> +};
> +
> +static const u32 ldo_volt_table6[] = {
> + 1240000, 1390000,
> +};
> +
> +static const u32 ldo_volt_table7[] = {
> + 1200000, 1300000, 1500000, 1800000,
> +};
> +
> +static const u32 ldo_volt_table8[] = {
> + 1800000, 2000000,
> +};
If this PMIC is anything like the MT6358, then it has 0.01V fine
tuning for most if not all the LDOs. It is sometimes needed as
a rail may have a 0.04V boost that would otherwise be invisible
to the system. And then if you have something like 3.04V set in
the DT constraints, you end up with something the regulator driver
doesn't support, but the hardware does.
Please see how it's done in the MT6358 driver. I spent a lot of
time on that driver to make it actually support the full range
of voltages, and describing the supplies.
ChenYu
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Chen-Yu Tsai @ 2026-03-19 4:56 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260317184507.523060-4-l.scorcia@gmail.com>
On Wed, Mar 18, 2026 at 2:46 AM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 318 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++
> 2 files changed, 342 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..fa4aad2dcbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,318 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 Regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + All voltage regulators provided by the PMIC are described as sub-nodes of
> + this node.
> +
> +properties:
> + compatible:
> + items:
> + - const: mediatek,mt6392-regulator
Please add the various supply rails. This allows you to properly describe
regulator dependencies and have a complete power supply tree.
They can be found in the datasheet.
ChenYu
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Chen-Yu Tsai @ 2026-03-19 4:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Luca Leonardo Scorcia, linux-mediatek, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Julien Massot, Gary Bisson, Louis-Alexis Eyraud,
Val Packett, Fabien Parent, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <ad0d1ea1-4c5d-4cfc-af0d-8d843e7e0e9e@kernel.org>
On Thu, Mar 19, 2026 at 6:14 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 18/03/2026 22:25, Luca Leonardo Scorcia wrote:
> >>
> >> Drop compatible. Regulator nodes do not have compatibles.
> >
> > Thanks for this comment. It took me a while to understand what you
> > meant as most of the MediaTek PMIC regulator drivers still require the
> > compatible node to probe, including MT6397 that was the template for
> > this patch. I compared the driver to MT6359 that does not use it and I
> > am now working on the driver to not rely on it.
> >
> >> With this, you can also drop example as it won't be used.
> >
> > Just to be sure - do you mean remove the compatible attribute from the
> > example, or the whole example section?
>
> The entire example because without the compatible it will be no-op.
>
> >
> >>> +
> >>> +patternProperties:
> >>> + "^(buck_)?v(core|proc|sys)$":
> >>
> >> Nope, underscores are not allowed. Use only hyphens.
> >
> > Got it. I will actually completely remove the (buck_|ldo_) prefix
> > altogether as suggested in another comment.
> >
> >>> + "^(ldo_)?v(adc18|camio|cn18|io18)$":
> >>> + description: LDOs with fixed 1.8V output
> >>
> >> If fixed, then encode it in the schema - min/max microvolt.
> >
> > If possible I'd like some clarification here. According to Chen-Yu
> > Tsai comment [1], dtsi shouldn't contain voltage constraints. The way
>
> That's odd, because long time in the past I heard that DTS must
> absolutely set min/max constraints, because these are real hardware
> (board) constraints for each regulator, unlike the generic and broad
> ones from the driver.
>
> IOW, driver has what datasheet tells. DTS has what actually should be used.
>
> Also, I did not actually require to make min/max required, just they
> have to be specific/constrained.
>
> > I understood this is that electrical constraints are a matter of the
> > actual board layout, so if adjustments are needed they have to be in
> > the board dts. But you also specify "If fixed", so maybe there's an
> > exception to this rule when the constraint is "absolute" and boards
> > can't actually set a different value?
>
> Now I am confused. You wrote - LDOs with fixed 1.8V output - so board
> cannot set it to 2.0V for example. They are affixed. This regulator
> CANNOT physically produce anything else.
As you said, it cannot physically produce anything else. IMO it doesn't
even need voltage constraints as it is already implied by the model and
regulator output, in which case I would actually recommend rejecting
min/max voltage being added to this node.
ChenYu
^ permalink raw reply
* [dtor-input:next] BUILD SUCCESS b8303880b641fa12db4e752b19f1b5160f0fa965
From: kernel test robot @ 2026-03-19 4:21 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
branch HEAD: b8303880b641fa12db4e752b19f1b5160f0fa965 Input: atlas - convert ACPI driver to a platform one
elapsed time: 733m
configs tested: 163
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260319 gcc-11.5.0
arc randconfig-002-20260319 gcc-11.5.0
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm randconfig-001-20260319 gcc-11.5.0
arm randconfig-002-20260319 gcc-11.5.0
arm randconfig-003-20260319 gcc-11.5.0
arm randconfig-004-20260319 gcc-11.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260319 gcc-15.2.0
arm64 randconfig-002-20260319 gcc-15.2.0
arm64 randconfig-003-20260319 gcc-15.2.0
arm64 randconfig-004-20260319 gcc-15.2.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260319 gcc-15.2.0
csky randconfig-002-20260319 gcc-15.2.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260319 gcc-11.5.0
hexagon randconfig-002-20260319 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260319 gcc-14
i386 buildonly-randconfig-002-20260319 gcc-14
i386 buildonly-randconfig-003-20260319 gcc-14
i386 buildonly-randconfig-004-20260319 gcc-14
i386 buildonly-randconfig-005-20260319 gcc-14
i386 buildonly-randconfig-006-20260319 gcc-14
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260319 gcc-14
i386 randconfig-002-20260319 gcc-14
i386 randconfig-003-20260319 gcc-14
i386 randconfig-004-20260319 gcc-14
i386 randconfig-005-20260319 gcc-14
i386 randconfig-006-20260319 gcc-14
i386 randconfig-007-20260319 gcc-14
i386 randconfig-011-20260319 clang-20
i386 randconfig-012-20260319 clang-20
i386 randconfig-013-20260319 clang-20
i386 randconfig-014-20260319 clang-20
i386 randconfig-015-20260319 clang-20
i386 randconfig-016-20260319 clang-20
i386 randconfig-017-20260319 clang-20
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260319 gcc-11.5.0
loongarch randconfig-002-20260319 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
m68k mac_defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260319 gcc-11.5.0
nios2 randconfig-002-20260319 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260319 clang-19
parisc randconfig-002-20260319 clang-19
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc chrp32_defconfig clang-19
powerpc randconfig-001-20260319 clang-19
powerpc randconfig-002-20260319 clang-19
powerpc64 randconfig-001-20260319 clang-19
powerpc64 randconfig-002-20260319 clang-19
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260319 gcc-8.5.0
sparc randconfig-002-20260319 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260319 gcc-8.5.0
sparc64 randconfig-002-20260319 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260319 gcc-8.5.0
um randconfig-002-20260319 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260319 clang-20
x86_64 buildonly-randconfig-002-20260319 clang-20
x86_64 buildonly-randconfig-003-20260319 clang-20
x86_64 buildonly-randconfig-004-20260319 clang-20
x86_64 buildonly-randconfig-005-20260319 clang-20
x86_64 buildonly-randconfig-006-20260319 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260319 gcc-14
x86_64 randconfig-002-20260319 gcc-14
x86_64 randconfig-003-20260319 gcc-14
x86_64 randconfig-004-20260319 gcc-14
x86_64 randconfig-005-20260319 gcc-14
x86_64 randconfig-006-20260319 gcc-14
x86_64 randconfig-011-20260319 gcc-13
x86_64 randconfig-012-20260319 gcc-13
x86_64 randconfig-013-20260319 gcc-13
x86_64 randconfig-014-20260319 gcc-13
x86_64 randconfig-015-20260319 gcc-13
x86_64 randconfig-016-20260319 gcc-13
x86_64 randconfig-071-20260319 clang-20
x86_64 randconfig-072-20260319 clang-20
x86_64 randconfig-073-20260319 clang-20
x86_64 randconfig-074-20260319 clang-20
x86_64 randconfig-075-20260319 clang-20
x86_64 randconfig-076-20260319 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260319 gcc-8.5.0
xtensa randconfig-002-20260319 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Krzysztof Kozlowski @ 2026-03-18 22:14 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <CAORyz2Laoo4EiLcHZ-ygLiFGW_h8qV7QxqNsMbueM=nov5zH0A@mail.gmail.com>
On 18/03/2026 22:25, Luca Leonardo Scorcia wrote:
>>
>> Drop compatible. Regulator nodes do not have compatibles.
>
> Thanks for this comment. It took me a while to understand what you
> meant as most of the MediaTek PMIC regulator drivers still require the
> compatible node to probe, including MT6397 that was the template for
> this patch. I compared the driver to MT6359 that does not use it and I
> am now working on the driver to not rely on it.
>
>> With this, you can also drop example as it won't be used.
>
> Just to be sure - do you mean remove the compatible attribute from the
> example, or the whole example section?
The entire example because without the compatible it will be no-op.
>
>>> +
>>> +patternProperties:
>>> + "^(buck_)?v(core|proc|sys)$":
>>
>> Nope, underscores are not allowed. Use only hyphens.
>
> Got it. I will actually completely remove the (buck_|ldo_) prefix
> altogether as suggested in another comment.
>
>>> + "^(ldo_)?v(adc18|camio|cn18|io18)$":
>>> + description: LDOs with fixed 1.8V output
>>
>> If fixed, then encode it in the schema - min/max microvolt.
>
> If possible I'd like some clarification here. According to Chen-Yu
> Tsai comment [1], dtsi shouldn't contain voltage constraints. The way
That's odd, because long time in the past I heard that DTS must
absolutely set min/max constraints, because these are real hardware
(board) constraints for each regulator, unlike the generic and broad
ones from the driver.
IOW, driver has what datasheet tells. DTS has what actually should be used.
Also, I did not actually require to make min/max required, just they
have to be specific/constrained.
> I understood this is that electrical constraints are a matter of the
> actual board layout, so if adjustments are needed they have to be in
> the board dts. But you also specify "If fixed", so maybe there's an
> exception to this rule when the constraint is "absolute" and boards
> can't actually set a different value?
Now I am confused. You wrote - LDOs with fixed 1.8V output - so board
cannot set it to 2.0V for example. They are affixed. This regulator
CANNOT physically produce anything else.
At least this is the meaning of the text you wrote.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: Luca Leonardo Scorcia @ 2026-03-18 21:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260318-nickel-serval-of-tolerance-621bad@quoll>
Il giorno mer 18 mar 2026 alle ore 08:43 Krzysztof Kozlowski
<krzk@kernel.org> ha scritto:
> Please use subject prefixes matching the subsystem. You can get them for
> example with 'git log --oneline -- DIRECTORY_OR_FILE' on the directory
> your patch is touching. For bindings, the preferred subjects are
> explained here:
> https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters
>
> You already received this feedback from Mark.
I am sorry I missed these. I will revise all of them in the next version.
> > +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
[...]
> > +properties:
> > + compatible:
> > + items:
> > + - const: mediatek,mt6392-regulator
>
> Drop compatible. Regulator nodes do not have compatibles.
Thanks for this comment. It took me a while to understand what you
meant as most of the MediaTek PMIC regulator drivers still require the
compatible node to probe, including MT6397 that was the template for
this patch. I compared the driver to MT6359 that does not use it and I
am now working on the driver to not rely on it.
> With this, you can also drop example as it won't be used.
Just to be sure - do you mean remove the compatible attribute from the
example, or the whole example section?
> > +
> > +patternProperties:
> > + "^(buck_)?v(core|proc|sys)$":
>
> Nope, underscores are not allowed. Use only hyphens.
Got it. I will actually completely remove the (buck_|ldo_) prefix
altogether as suggested in another comment.
> > + "^(ldo_)?v(adc18|camio|cn18|io18)$":
> > + description: LDOs with fixed 1.8V output
>
> If fixed, then encode it in the schema - min/max microvolt.
If possible I'd like some clarification here. According to Chen-Yu
Tsai comment [1], dtsi shouldn't contain voltage constraints. The way
I understood this is that electrical constraints are a matter of the
actual board layout, so if adjustments are needed they have to be in
the board dts. But you also specify "If fixed", so maybe there's an
exception to this rule when the constraint is "absolute" and boards
can't actually set a different value?
[1] https://lore.kernel.org/linux-mediatek/28102417-4a2a-4e29-afbd-d0f2aa76074b@collabora.com/T/#mb1473bb5515f3e5a1bb3ff20c717b387c42373ef
Thank you for your help!
--
Luca Leonardo Scorcia
l.scorcia@gmail.com
^ permalink raw reply
* [PATCH] HID: pulsar: add driver for Pulsar gaming mice
From: Nikolas Koesling @ 2026-03-18 20:55 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, linux-kernel
Add a HID driver for Pulsar wireless gaming mice (X2 V2, X2H, X2A,
Xlite V3). The driver exposes battery level, voltage, and charging
status through the power supply framework. It supports wired, 1kHz,
and 4kHz wireless dongle connections.
The protocol used by this driver is based on findings from
python-pulsar-mouse-tool by Andrew Rabert (MIT License):
https://github.com/andrewrabert/python-pulsar-mouse-tool
Signed-off-by: Nikolas Koesling <nikolas@koesling.info>
---
MAINTAINERS | 6 +
drivers/hid/Kconfig | 10 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-ids.h | 5 +
drivers/hid/hid-pulsar.c | 669 +++++++++++++++++++++++++++++++++++++++
5 files changed, 691 insertions(+)
create mode 100644 drivers/hid/hid-pulsar.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d7241695df96..62e1549ca9fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11339,6 +11339,12 @@ L: linux-input@vger.kernel.org
S: Supported
F: drivers/hid/hid-playstation.c
+HID PULSAR DRIVER
+M: Nikolas Koesling <nikolas@koesling.info>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: drivers/hid/hid-pulsar.c
+
HID SENSOR HUB DRIVERS
M: Jiri Kosina <jikos@kernel.org>
M: Jonathan Cameron <jic23@kernel.org>
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index c1d9f7c6a5f2..503287973886 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -1280,6 +1280,16 @@ config HID_UNIVERSAL_PIDFF
Supports Moza Racing, Cammus, VRS, FFBeast and more.
+config HID_PULSAR
+ tristate "Pulsar gaming mouse support"
+ depends on USB_HID
+ select POWER_SUPPLY
+ help
+ Support for Pulsar gaming mice (X2 V2, X2H, X2A, Xlite V3)
+ connected via 1kHz/4kHz USB dongle or wired.
+ Provides battery level, voltage, and charging status
+ monitoring via the power supply framework.
+
config HID_WACOM
tristate "Wacom Intuos/Graphire tablet support (USB)"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index e01838239ae6..67ad39b47df1 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -112,6 +112,7 @@ hid-picolcd-$(CONFIG_DEBUG_FS) += hid-picolcd_debugfs.o
obj-$(CONFIG_HID_PLANTRONICS) += hid-plantronics.o
obj-$(CONFIG_HID_PLAYSTATION) += hid-playstation.o
obj-$(CONFIG_HID_PRIMAX) += hid-primax.o
+obj-$(CONFIG_HID_PULSAR) += hid-pulsar.o
obj-$(CONFIG_HID_PXRC) += hid-pxrc.o
obj-$(CONFIG_HID_RAPOO) += hid-rapoo.o
obj-$(CONFIG_HID_RAZER) += hid-razer.o
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index afcee13bad61..18d461247aed 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -1169,6 +1169,11 @@
#define USB_VENDOR_ID_PRODIGE 0x05af
#define USB_DEVICE_ID_PRODIGE_CORDLESS 0x3062
+#define USB_VENDOR_ID_PULSAR 0x3554
+#define USB_DEVICE_ID_PULSAR_WIRED 0xf507
+#define USB_DEVICE_ID_PULSAR_1KHZ 0xf508
+#define USB_DEVICE_ID_PULSAR_4KHZ 0xf509
+
#define I2C_VENDOR_ID_QTEC 0x6243
#define USB_VENDOR_ID_QUANTA 0x0408
diff --git a/drivers/hid/hid-pulsar.c b/drivers/hid/hid-pulsar.c
new file mode 100644
index 000000000000..2720b9f18b08
--- /dev/null
+++ b/drivers/hid/hid-pulsar.c
@@ -0,0 +1,669 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * HID driver for pulsar mice
+ *
+ * Supported pulsar devices:
+ * - X2 V2
+ * - X2H
+ * - X2A
+ * - Xlite V3
+ *
+ * Copyright (c) 2026 Nikolas Koesling
+ */
+
+#include <linux/hid.h>
+#include <linux/usb.h>
+#include <linux/power_supply.h>
+#include "hid-ids.h"
+
+/* ----- driver settings ----- */
+#define CMD_TIMEOUT_MSEC 100
+#define MAX_BATTERY_AGE_NS 60000000000ULL /* 60s */
+#define MAX_UNAVAIL_AGE_NS 5000000000ULL /* 5s */
+#define INIT_RETRIES 1
+#define INIT_DELAY_MSEC 1000
+
+/* ----- constants ----- */
+#define USB_INTERFACE 1
+#define USB_PAYLOAD_LEN 17
+#define CMD_HID_REPORT_ID 0x08
+#define CHECKSUM_MAGIC 0x55
+#define DEV_INFO_LEN 4
+#define CON_1K 0x00
+#define CON_4K 0x01
+#define CON_WIRED 0x02
+
+/* ----- device commands ----- */
+enum pulsar_cmd {
+ CMD_NONE = 0,
+ CMD_INFO = 0x01,
+ CMD_STATUS = 0x03,
+ CMD_POWER = 0x04,
+ CMD_EVENT = 0x0a, /* recv only */
+};
+
+#define EVENT_PWR 0x40 /* power status change */
+#define EVENT_PWR_CHK 0xf9
+
+/* ----- structs ----- */
+struct pulsar_battery {
+ struct power_supply *ps;
+ struct power_supply_desc desc;
+ char name[48];
+ char model[32];
+ u8 level; /* percent */
+ u16 voltage; /* millivolts */
+ bool conn;
+ bool available;
+ u64 last_read;
+ u64 last_status;
+};
+
+struct pulsar_data {
+ struct hid_device *hdev;
+
+ spinlock_t raw_event_lock; /* protects response_buf, pending_event */
+ struct mutex lock_cmd; /* serializes device command execution */
+ struct rw_semaphore lock_bat; /* protects battery state */
+
+ struct completion response_ready;
+ u8 response_buf[USB_PAYLOAD_LEN];
+ u8 pending_event;
+ struct work_struct power_uevent_work;
+ struct delayed_work init_work;
+ unsigned int init_retries;
+ atomic_t device_verified;
+ atomic_t stopping;
+
+ struct pulsar_battery battery;
+};
+
+static u8 calc_checksum(const u8 *data, size_t len)
+{
+ u8 sum = 0;
+
+ for (size_t i = 0; i < len - 1; i++)
+ sum += data[i];
+
+ return (u8)CHECKSUM_MAGIC - sum;
+}
+
+static int send_cmd(struct hid_device *hdev, const u8 *buf, size_t len)
+{
+ int ret;
+ u8 *dmabuf;
+
+ hid_dbg(hdev, "send command: %*ph\n", (int)len, buf);
+
+ dmabuf = kmemdup(buf, len, GFP_KERNEL);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ /* device listens only to control transfers */
+ ret = hid_hw_raw_request(hdev, dmabuf[0], dmabuf, len,
+ HID_OUTPUT_REPORT, HID_REQ_SET_REPORT);
+
+ kfree(dmabuf);
+
+ if (ret < 0)
+ return ret;
+ if (ret != len)
+ return -EIO;
+
+ return 0;
+}
+
+static int exec_cmd(struct pulsar_data *drvdata, const u8 *payload,
+ u8 *response, unsigned int timeout_msec)
+{
+ struct hid_device *hdev = drvdata->hdev;
+ unsigned long flags;
+ int ret;
+ unsigned long timeout;
+ u8 checksum;
+
+ if (atomic_read(&drvdata->stopping))
+ return -ENODEV;
+
+ mutex_lock(&drvdata->lock_cmd);
+
+ if (atomic_read(&drvdata->stopping)) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ reinit_completion(&drvdata->response_ready);
+ drvdata->pending_event = payload[1];
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+
+ ret = send_cmd(hdev, payload, USB_PAYLOAD_LEN);
+
+ if (ret < 0) {
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ drvdata->pending_event = CMD_NONE;
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+ hid_err(hdev, "failed to send command 0x%02x: %d\n",
+ payload[1], ret);
+ goto out;
+ }
+
+ timeout = wait_for_completion_timeout(&drvdata->response_ready,
+ msecs_to_jiffies(timeout_msec));
+
+ if (timeout == 0) {
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ drvdata->pending_event = CMD_NONE;
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ spin_lock_irqsave(&drvdata->raw_event_lock, flags);
+ memcpy(response, drvdata->response_buf, USB_PAYLOAD_LEN);
+ spin_unlock_irqrestore(&drvdata->raw_event_lock, flags);
+
+ /* validate checksum */
+ checksum = calc_checksum(response, USB_PAYLOAD_LEN);
+
+ if (response[USB_PAYLOAD_LEN - 1] != checksum) {
+ hid_err(hdev,
+ "invalid checksum in response: 0x%02x (expected 0x%02x)\n",
+ response[USB_PAYLOAD_LEN - 1], checksum);
+ ret = -EIO;
+ goto out;
+ }
+
+ ret = 0;
+out:
+ mutex_unlock(&drvdata->lock_cmd);
+ return ret;
+}
+
+static inline void finalize_payload(u8 *payload, u8 cmd)
+{
+ payload[0] = CMD_HID_REPORT_ID;
+ payload[1] = cmd;
+ payload[USB_PAYLOAD_LEN - 1] = calc_checksum(payload, USB_PAYLOAD_LEN);
+}
+
+static int read_status(struct pulsar_data *drvdata)
+{
+ int ret;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+
+ finalize_payload(payload, CMD_STATUS);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0)
+ return ret;
+ if (response[6] > 0x01)
+ return -EIO;
+
+ return (int)response[6]; /* 1: available, 0: not available */
+}
+
+static int read_device_info(struct pulsar_data *drvdata, u8 *data)
+{
+ int ret;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+
+ payload[5] = DEV_INFO_LEN * 2;
+ get_random_bytes(payload + 6, DEV_INFO_LEN);
+ finalize_payload(payload, CMD_INFO);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0)
+ return ret;
+
+ if (data)
+ memcpy(data, response + 6 + DEV_INFO_LEN, DEV_INFO_LEN);
+
+ response[8 + DEV_INFO_LEN] = 0;
+ response[9 + DEV_INFO_LEN] = 0;
+
+ /*
+ * Verify challenge-response. Response layout from offset 6:
+ * [0..3] encoded response [4..7] device info (ID + conn type)
+ *
+ * resp[i] = challenge[i] * (i+1) + challenge[(i+1) % 4] + device_id[i]
+ *
+ * bytes 6..7 are zeroed for verification.
+ */
+ for (int i = 0; i < DEV_INFO_LEN; i++) {
+ u8 expect = response[6 + DEV_INFO_LEN + i];
+ u8 actual = response[6 + i] - (i + 1) * payload[6 + i] -
+ payload[6 + (i + 1) % DEV_INFO_LEN];
+
+ if (expect != actual) {
+ hid_warn(drvdata->hdev,
+ "device info[%d] mismatch: %02x != %02x\n",
+ i, expect, actual);
+ return -EIO;
+ }
+ }
+
+ return 0;
+}
+
+static int read_power(struct pulsar_data *drvdata)
+{
+ u64 now;
+ bool need_status, need_power;
+ int ret = 0;
+ u8 payload[USB_PAYLOAD_LEN] = { 0 };
+ u8 response[USB_PAYLOAD_LEN];
+ struct pulsar_battery *battery = &drvdata->battery;
+
+ now = ktime_get_ns();
+
+ down_write(&drvdata->lock_bat);
+
+ need_status = (now - battery->last_status >= MAX_UNAVAIL_AGE_NS);
+ need_power = battery->available &&
+ (now - battery->last_read >= MAX_BATTERY_AGE_NS);
+
+ if (!need_status && !need_power)
+ goto unlock;
+
+ if (need_status) {
+ ret = read_status(drvdata);
+ if (ret < 0) {
+ hid_err(drvdata->hdev,
+ "%s: failed to read status: %d\n",
+ __func__, ret);
+ goto unlock;
+ }
+
+ battery->last_status = now;
+
+ if (!ret) {
+ battery->available = false;
+ goto unlock;
+ }
+
+ /* device just became available, force power read */
+ if (!battery->available)
+ need_power = true;
+ }
+
+ if (!need_power)
+ goto unlock;
+
+ finalize_payload(payload, CMD_POWER);
+
+ ret = exec_cmd(drvdata, payload, response, CMD_TIMEOUT_MSEC);
+ if (ret < 0) {
+ hid_err(drvdata->hdev, "%s: failed to read power: %d\n",
+ __func__, ret);
+ goto unlock;
+ }
+
+ if (response[6] > 100 || response[7] > 0x01) {
+ ret = -EIO;
+ goto unlock;
+ }
+
+ battery->available = true;
+ battery->level = response[6];
+ battery->conn = response[7] == 1;
+ battery->voltage = (response[8] << 8) | response[9];
+ battery->last_read = now;
+
+ hid_dbg(drvdata->hdev, "%s: level=%d, conn=%d, voltage=%d\n",
+ __func__, battery->level, battery->conn, battery->voltage);
+
+unlock:
+ up_write(&drvdata->lock_bat);
+ return ret;
+}
+
+static int battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct pulsar_data *drvdata;
+ int ret;
+
+ drvdata = power_supply_get_drvdata(psy);
+
+ ret = read_power(drvdata);
+ if (ret)
+ return ret;
+
+ down_read(&drvdata->lock_bat);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ if (!drvdata->battery.available)
+ val->intval = POWER_SUPPLY_STATUS_UNKNOWN;
+ else if (drvdata->battery.conn && drvdata->battery.level < 100)
+ val->intval = POWER_SUPPLY_STATUS_CHARGING;
+ else if (drvdata->battery.conn && drvdata->battery.level >= 100)
+ val->intval = POWER_SUPPLY_STATUS_FULL;
+ else
+ val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val->intval = drvdata->battery.level;
+ break;
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ val->intval = drvdata->battery.voltage * 1000;
+ break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = drvdata->battery.available;
+ break;
+ case POWER_SUPPLY_PROP_MANUFACTURER:
+ val->strval = "pulsar";
+ break;
+ case POWER_SUPPLY_PROP_SCOPE:
+ val->intval = POWER_SUPPLY_SCOPE_DEVICE;
+ break;
+ case POWER_SUPPLY_PROP_MODEL_NAME:
+ val->strval = drvdata->battery.model;
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ up_read(&drvdata->lock_bat);
+ return ret;
+}
+
+static void power_uevent_work_handler(struct work_struct *work)
+{
+ struct pulsar_data *drvdata;
+ int ret;
+
+ drvdata = container_of(work, struct pulsar_data, power_uevent_work);
+
+ if (atomic_read(&drvdata->stopping))
+ return;
+
+ down_write(&drvdata->lock_bat);
+ drvdata->battery.last_read = 0;
+ drvdata->battery.last_status = 0;
+ up_write(&drvdata->lock_bat);
+
+ ret = read_power(drvdata);
+ if (ret < 0) {
+ hid_err(drvdata->hdev, "%s: failed to read power: %d\n",
+ __func__, ret);
+ return;
+ }
+
+ power_supply_changed(drvdata->battery.ps);
+}
+
+static int pulsar_raw_event(struct hid_device *hdev,
+ struct hid_report *report, u8 *data, int size)
+{
+ struct pulsar_data *drvdata;
+
+ drvdata = hid_get_drvdata(hdev);
+ if (!drvdata)
+ return 0;
+
+ hid_dbg(hdev, "received raw event: %*ph\n", size, data);
+
+ if (size != USB_PAYLOAD_LEN || data[0] != CMD_HID_REPORT_ID)
+ return 0;
+
+ if (data[1] != CMD_EVENT) {
+ spin_lock(&drvdata->raw_event_lock);
+ if (drvdata->pending_event != data[1]) {
+ spin_unlock(&drvdata->raw_event_lock);
+ return 0;
+ }
+ memcpy(drvdata->response_buf, data, size);
+ drvdata->pending_event = CMD_NONE;
+ complete(&drvdata->response_ready);
+ spin_unlock(&drvdata->raw_event_lock);
+ return 1;
+ }
+
+ if (!atomic_read(&drvdata->device_verified))
+ return 0;
+
+ if (data[6] == EVENT_PWR && data[USB_PAYLOAD_LEN - 1] == EVENT_PWR_CHK) {
+ schedule_work(&drvdata->power_uevent_work);
+ hid_dbg(hdev, "received power event\n");
+ return 1;
+ }
+
+ return 0;
+}
+
+static const enum power_supply_property pulsar_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS, POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW, POWER_SUPPLY_PROP_ONLINE,
+ POWER_SUPPLY_PROP_MODEL_NAME, POWER_SUPPLY_PROP_SCOPE,
+ POWER_SUPPLY_PROP_MANUFACTURER, POWER_SUPPLY_PROP_PRESENT
+};
+
+static void init_power_supply_desc(struct pulsar_data *drvdata)
+{
+ drvdata->battery.desc.name = drvdata->battery.name;
+ drvdata->battery.desc.type = POWER_SUPPLY_TYPE_BATTERY;
+ drvdata->battery.desc.properties = pulsar_battery_props;
+ drvdata->battery.desc.num_properties = ARRAY_SIZE(pulsar_battery_props);
+ drvdata->battery.desc.get_property = battery_get_property;
+}
+
+static void pulsar_init_work(struct work_struct *work)
+{
+ struct pulsar_data *drvdata;
+ struct hid_device *hdev;
+ struct power_supply_config psy_cfg;
+ int ret;
+ u8 data[DEV_INFO_LEN];
+ const char *con_type = "unknown";
+ u16 model_id;
+
+ drvdata = container_of(work, struct pulsar_data, init_work.work);
+ hdev = drvdata->hdev;
+
+ ret = read_device_info(drvdata, data);
+ if (ret == -ETIMEDOUT) {
+ if (drvdata->init_retries--) {
+ hid_dbg(hdev,
+ "device info read timed out, retrying (%u left)\n",
+ drvdata->init_retries);
+ schedule_delayed_work(&drvdata->init_work,
+ msecs_to_jiffies
+ (INIT_DELAY_MSEC));
+ return;
+ }
+ hid_err(hdev, "device info read timed out, giving up\n");
+ return;
+ }
+ if (ret < 0) {
+ hid_err(hdev, "failed to read device info: %d\n", ret);
+ return;
+ }
+
+ hid_dbg(hdev, "device info: %*ph\n", DEV_INFO_LEN, data);
+ model_id = data[0] << 8 | data[1];
+
+ switch (data[2]) {
+ case CON_1K:
+ con_type = "1kHz";
+ break;
+ case CON_4K:
+ con_type = "4kHz";
+ break;
+ case CON_WIRED:
+ con_type = "wired";
+ break;
+ }
+
+ switch (model_id) {
+ case 0x060a:
+ case 0x060b:
+ case 0x0612:
+ case 0x0613:
+ case 0x0614:
+ case 0x0615:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2 V2 (%s)", con_type);
+ break;
+ case 0x060c:
+ case 0x060d:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2H (%s)", con_type);
+ break;
+ case 0x0607:
+ case 0x060e:
+ case 0x060f:
+ case 0x0610:
+ case 0x0611:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar Xlite V3 (%s)", con_type);
+ break;
+ case 0x0608:
+ case 0x0609:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar X2A (%s)", con_type);
+ break;
+ default:
+ snprintf(drvdata->battery.model, sizeof(drvdata->battery.model),
+ "Pulsar unknown (%s)", con_type);
+ }
+
+ init_power_supply_desc(drvdata);
+
+ psy_cfg = (struct power_supply_config) {.drv_data = drvdata };
+ drvdata->battery.ps =
+ devm_power_supply_register(&hdev->dev, &drvdata->battery.desc,
+ &psy_cfg);
+ if (IS_ERR(drvdata->battery.ps)) {
+ hid_err(hdev, "failed to register battery: %ld\n",
+ PTR_ERR(drvdata->battery.ps));
+ drvdata->battery.ps = NULL;
+ return;
+ }
+
+ atomic_set(&drvdata->device_verified, 1);
+ hid_info(hdev, "device verified, battery registered\n");
+}
+
+static int pulsar_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ int ret;
+ struct usb_interface *intf;
+ struct usb_device *usbdev;
+ struct pulsar_data *drvdata;
+ struct hid_report *report_in;
+ struct hid_report *report_out;
+
+ if (!hid_is_usb(hdev))
+ return -ENODEV;
+
+ ret = hid_parse(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "hid_parse failed: %d\n", ret);
+ return ret;
+ }
+
+ intf = to_usb_interface(hdev->dev.parent);
+ report_in =
+ hdev->report_enum[HID_INPUT_REPORT].report_id_hash[CMD_HID_REPORT_ID];
+ report_out =
+ hdev->report_enum[HID_OUTPUT_REPORT].report_id_hash[CMD_HID_REPORT_ID];
+
+ if (!report_in || !report_out ||
+ hid_report_len(report_in) != USB_PAYLOAD_LEN ||
+ hid_report_len(report_out) != USB_PAYLOAD_LEN ||
+ intf->cur_altsetting->desc.bInterfaceNumber != USB_INTERFACE)
+ return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+
+ drvdata = devm_kzalloc(&hdev->dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+
+ drvdata->hdev = hdev;
+
+ mutex_init(&drvdata->lock_cmd);
+ init_rwsem(&drvdata->lock_bat);
+
+ usbdev = interface_to_usbdev(intf);
+
+ spin_lock_init(&drvdata->raw_event_lock);
+ hid_set_drvdata(hdev, drvdata);
+ init_completion(&drvdata->response_ready);
+ INIT_WORK(&drvdata->power_uevent_work, power_uevent_work_handler);
+ INIT_DELAYED_WORK(&drvdata->init_work, pulsar_init_work);
+ drvdata->init_retries = INIT_RETRIES;
+
+ snprintf(drvdata->battery.name, sizeof(drvdata->battery.name),
+ "pulsar_%s_battery", usbdev->devpath);
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret < 0) {
+ hid_err(hdev, "hw start failed\n");
+ return ret;
+ }
+
+ ret = hid_hw_open(hdev);
+ if (ret < 0) {
+ hid_err(hdev, "hw open failed\n");
+ goto err_open;
+ }
+
+ schedule_delayed_work(&drvdata->init_work, 0);
+
+ return 0;
+
+err_open:
+ cancel_work_sync(&drvdata->power_uevent_work);
+ hid_hw_stop(hdev);
+ return ret;
+}
+
+static void pulsar_remove(struct hid_device *hdev)
+{
+ struct pulsar_data *drvdata;
+
+ drvdata = hid_get_drvdata(hdev);
+ if (!drvdata) {
+ hid_hw_stop(hdev);
+ return;
+ }
+
+ atomic_set(&drvdata->stopping, 1);
+ cancel_delayed_work_sync(&drvdata->init_work);
+ cancel_work_sync(&drvdata->power_uevent_work);
+
+ /* wait for active device i/o (exec_cmd) */
+ mutex_lock(&drvdata->lock_cmd);
+ hid_hw_close(hdev);
+ mutex_unlock(&drvdata->lock_cmd);
+
+ hid_hw_stop(hdev);
+ mutex_destroy(&drvdata->lock_cmd);
+}
+
+static const struct hid_device_id pulsar_table[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_WIRED) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_1KHZ) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_PULSAR, USB_DEVICE_ID_PULSAR_4KHZ) },
+ { }
+};
+
+static struct hid_driver pulsar_driver = {
+ .name = "pulsar",
+ .id_table = pulsar_table,
+ .probe = pulsar_probe,
+ .remove = pulsar_remove,
+ .raw_event = pulsar_raw_event,
+};
+
+module_hid_driver(pulsar_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("HID driver for pulsar mice");
+MODULE_AUTHOR("Nikolas Koesling");
+MODULE_DEVICE_TABLE(hid, pulsar_table);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] Remove unused headers in x86/tools, scripts, pps, input
From: Nicolas Schier @ 2026-03-18 19:56 UTC (permalink / raw)
To: Oli
Cc: Thomas Gleixner, Ingo Molnar, Steven Rostedt, Mathieu Desnoyers,
Masami Hiramatsu, Rodolfo Giometti, Henrik Rydberg,
Dmitry Torokhov, Nathan Chancellor, linux-kernel,
linux-trace-kernel, linux-kbuild, linux-input, x86
In-Reply-To: <CAOW84UxjnSDKSjsaaS9=DBquCk3SDfb74=OmkHTLUyq5qriYsA@mail.gmail.com>
Hi Oli,
thanks for your contribution. Some comments below:
On Tue, Mar 10, 2026 at 10:01:41PM -0500, Oli wrote:
> From c78a0572f5ec2b927f9b723af687e6ef913561a4 Mon Sep 17 00:00:00 2001
> From: Eddie Hudgins <Oochiolio@gmail.com>
> Date: Tue, 10 Mar 2026 21:53:07 -0500
> Subject: [PATCH] Signed-off-by: Eddie Hudgins <Oochiolio@gmail.com>
> arch/x86/tools: Removed headers in relocs_32.c scripts/basic: Removed
> headers
> in fixdep.c drivers/pps: Removed headers in pps.c drivers/input: Removed
> headers in input-mt.c
Usually, patch mails do not contain mail headers within their body; the
only possible exception is 'From:' if the sender is not the patch
author. These additional headers prevent the usual patch application
(e.g. 'git am <mail').
>
> These changes compile for x86, x86_64, and powerpc (Those were the only
> ones fairly tested) under defconfig. This aims to clean up code and
> simplify the files for developers. This will also contribute to start of
> decluttering the environment.
A commit subject should start with a subsystem identifier. A commit
message should tell about the what and why of the patch, followed by a
'Signed-of-by'. E.g.:
kbuild: fixdep: Remove unused includes
Remove unused #include statements for clean up.
Signed-off-by: Your Name <your.e.mail@addre.ss>
(More complex changes require more details commit message).
Please check Documentation/process/submitting-patches.rst.
[...]
> diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
> index cdd5da7e009b..feb9e7d8984d 100644
> --- a/scripts/basic/fixdep.c
> +++ b/scripts/basic/fixdep.c
> @@ -89,7 +89,6 @@
> * but I don't think the added complexity is worth it)
> */
>
> -#include <sys/types.h>
> #include <sys/stat.h>
> #include <unistd.h>
> #include <fcntl.h>
> --
> 2.43.0
The change in scripts/basic/fixdep.c looks good to me. Do you want to
prepare a new kbuild-only patch and want me to take it for kbuild?
Kind regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: AngeloGioacchino Del Regno @ 2026-03-18 17:22 UTC (permalink / raw)
To: wens
Cc: Luca Leonardo Scorcia, linux-mediatek, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <CAGb2v64+oofwTiJTXDYCuzUEpk=zioi16i8a7iMimc_eZ1RPUQ@mail.gmail.com>
Il 18/03/26 14:54, Chen-Yu Tsai ha scritto:
> On Wed, Mar 18, 2026 at 8:39 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@collabora.com> wrote:
>>
>> Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
>>> From: Val Packett <val@packett.cool>
>>>
>>> Add the dts to be included by all boards using the MT6392 PMIC.
>>>
>>> Signed-off-by: Val Packett <val@packett.cool>
>>> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
>>> ---
>>> arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
>>> 1 file changed, 141 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
>>> new file mode 100644
>>> index 000000000000..fbf6f671524c
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
>>> @@ -0,0 +1,141 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Copyright (c) 2019 MediaTek Inc.
>>> + * Copyright (c) 2024 Val Packett <val@packett.cool>
>>> + */
>>> +
>>> +#include <dt-bindings/input/input.h>
>>> +
>>> +&pwrap {
>>> + pmic: pmic {
>>> + compatible = "mediatek,mt6392", "mediatek,mt6323";
>>> + interrupt-controller;
>>> + #interrupt-cells = <2>;
>>> +
>>> + keys {
>>> + compatible = "mediatek,mt6392-keys";
>>> +
>>> + key-power {
>>> + linux,keycodes = <KEY_POWER>;
>>> + wakeup-source;
>>> + };
>>> +
>>> + key-home {
>>> + linux,keycodes = <KEY_HOME>;
>>> + wakeup-source;
>>> + };
>>> + };
>>> +
>>> + pio6392: pinctrl {
>>> + compatible = "mediatek,mt6392-pinctrl";
>>> +
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> + };
>>> +
>>> + rtc {
>>> + compatible = "mediatek,mt6392-rtc",
>>> + "mediatek,mt6323-rtc";
>>> + };
>>> +
>>> + regulators {
>>> + compatible = "mediatek,mt6392-regulator";
>>> +
>>> + mt6392_vproc_reg: buck_vproc {
>>
>> s/buck//g
>>
>> Also, no min/max voltages?!
>
> We really shouldn't set min/max voltages in the PMIC dtsi file.
>
> The min/max voltages are supposed to be the intersection of the
> consumers acceptable operating ranges. The min/max of the regulator
> itself is already implied by the model / compatible.
>
Your point is fair, but it's also true that some of the regulators are not
really meant to ever output anything different than what they are supposed
to, though, with slight variations being possible... I guess the best option
here is to leave declaring voltages to board DTs instead, which is sensible
in the end.
Okay, agreed. Let's go with no voltages.
Reminder for myself: there's a bunch of PMIC devicetrees to cleanup in here...
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] Input: sentelic: fix comment typo
From: Joseph Salisbury @ 2026-03-18 16:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <abo7FVLq3qUzxkee@google.com>
On 3/18/26 1:43 AM, Dmitry Torokhov wrote:
> Hi Joseph,
>
> On Mon, Mar 16, 2026 at 07:48:31PM -0400, Joseph Salisbury wrote:
>>
>> On 3/16/26 2:12 PM, Joseph Salisbury wrote:
>>> The file contains a spelling error in a source comment (formating).
>>>
>>> Typos in comments reduce readability and make text searches less reliable
>>> for developers and maintainers.
>>>
>>> Replace 'formating' with 'formatting' in the affected comment. This is a
>>> comment-only cleanup and does not change behavior.
>>>
>>> Fixes: fc69f4a6af49 ("Input: add new driver for Sentelic Finger Sensing Pad")
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Joseph Salisbury <joseph.salisbury@oracle.com>
>>> ---
>>> drivers/input/mouse/sentelic.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/input/mouse/sentelic.h b/drivers/input/mouse/sentelic.h
>>> index 02cac0e7ad63..9ba3631e3d0f 100644
>>> --- a/drivers/input/mouse/sentelic.h
>>> +++ b/drivers/input/mouse/sentelic.h
>>> @@ -60,7 +60,7 @@
>>> #define FSP_REG_SN1 (0x41)
>>> #define FSP_REG_SN2 (0x42)
>>> -/* Finger-sensing Pad packet formating related definitions */
>>> +/* Finger-sensing Pad packet formatting related definitions */
>>> /* absolute packet type */
>>> #define FSP_PKT_TYPE_NORMAL (0x00)
>> I inadvertently added Fixes: and Cc: stable tags. If possible, please
>> remove them as they are not appropriate for fixes to misspellings in code
>> comments. If it's not possible to remove them, I can send a v2.
>>
> Sorry I did not receive the original patch but even with the typo fixed
> this comment needs more work to improve readability.
>
> Thanks.
>
Thanks for the feedback, Dmitry!
Would you like just improved readability for that line, or would you
like me to add some additional info on the definitions?
How about something like this:
-/* Finger-sensing Pad packet formating related definitions */
+/* Finger Sensing Pad packet format definitions.
+ * Define packet types and bit fields used to decode device reports.
+ */
If that looks good, I'll send a v2.
^ permalink raw reply
* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: Chen-Yu Tsai @ 2026-03-18 13:54 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: Luca Leonardo Scorcia, linux-mediatek, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Gary Bisson,
Julien Massot, Louis-Alexis Eyraud, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <c1a425ba-a4ca-49ea-9660-5de74bede124@collabora.com>
On Wed, Mar 18, 2026 at 8:39 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> > From: Val Packett <val@packett.cool>
> >
> > Add the dts to be included by all boards using the MT6392 PMIC.
> >
> > Signed-off-by: Val Packett <val@packett.cool>
> > Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> > ---
> > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
> > 1 file changed, 141 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > new file mode 100644
> > index 000000000000..fbf6f671524c
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> > @@ -0,0 +1,141 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019 MediaTek Inc.
> > + * Copyright (c) 2024 Val Packett <val@packett.cool>
> > + */
> > +
> > +#include <dt-bindings/input/input.h>
> > +
> > +&pwrap {
> > + pmic: pmic {
> > + compatible = "mediatek,mt6392", "mediatek,mt6323";
> > + interrupt-controller;
> > + #interrupt-cells = <2>;
> > +
> > + keys {
> > + compatible = "mediatek,mt6392-keys";
> > +
> > + key-power {
> > + linux,keycodes = <KEY_POWER>;
> > + wakeup-source;
> > + };
> > +
> > + key-home {
> > + linux,keycodes = <KEY_HOME>;
> > + wakeup-source;
> > + };
> > + };
> > +
> > + pio6392: pinctrl {
> > + compatible = "mediatek,mt6392-pinctrl";
> > +
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + };
> > +
> > + rtc {
> > + compatible = "mediatek,mt6392-rtc",
> > + "mediatek,mt6323-rtc";
> > + };
> > +
> > + regulators {
> > + compatible = "mediatek,mt6392-regulator";
> > +
> > + mt6392_vproc_reg: buck_vproc {
>
> s/buck//g
>
> Also, no min/max voltages?!
We really shouldn't set min/max voltages in the PMIC dtsi file.
The min/max voltages are supposed to be the intersection of the
consumers acceptable operating ranges. The min/max of the regulator
itself is already implied by the model / compatible.
ChenYu
^ permalink raw reply
* Re: [PATCH v5] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
From: Bjorn Andersson @ 2026-03-18 13:50 UTC (permalink / raw)
To: Kamil Gołda, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Yedaya Katsman
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260208-touchscreen-patches-v5-1-5821dff9c9a2@gmail.com>
On Sun, 08 Feb 2026 23:24:23 +0200, Yedaya Katsman wrote:
> Add device tree node for the Focaltech FT3518 touchscreen on
> Xiaomi Mi A3 (laurel-sprout).
>
> Enable qupv3_id_0 and i2c2 bus that the touchscreen is on.
>
> Downstream references:
> Link: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/laurel-r-oss/arch/arm64/boot/dts/qcom/trinket-pinctrl.dtsi
> Link: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/laurel-r-oss/arch/arm64/boot/dts/qcom/laurel_sprout-qrd.dtsi
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: Add Focaltech FT3518 touchscreen
commit: ea062e42832274cc8fb0587ea8852e1558cef0e1
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 7/9] regulator: mt6392: Add support for MT6392 regulator
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Fabien Parent, Val Packett, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Gary Bisson, Louis-Alexis Eyraud,
Julien Massot, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-8-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Fabien Parent <parent.f@gmail.com>
>
> The MT6392 is a regulator found on boards based on the MediaTek
> MT8167, MT8516, and probably other SoCs. It is a so called PMIC and
> connects as a slave to a SoC using SPI, wrapped inside PWRAP.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Co-developed-by: Val Packett <val@packett.cool>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/mt6392-regulator.c | 487 +++++++++++++++++++++
> include/linux/regulator/mt6392-regulator.h | 40 ++
> 4 files changed, 537 insertions(+)
> create mode 100644 drivers/regulator/mt6392-regulator.c
> create mode 100644 include/linux/regulator/mt6392-regulator.h
>
..snip..
> +
> +/* The array is indexed by id(MT6392_ID_XXX) */
> +static struct mt6392_regulator_info mt6392_regulators[] = {
> + MT6392_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250,
s/buck_//g
s/ldo_//g
after which
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v3 3/9] dt-bindings: regulator: Document MediaTek MT6392 PMIC Regulators
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Julien Massot,
Gary Bisson, Louis-Alexis Eyraud, Val Packett, Fabien Parent,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-4-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 318 ++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++
> 2 files changed, 342 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..fa4aad2dcbe8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,318 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 Regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + All voltage regulators provided by the PMIC are described as sub-nodes of
> + this node.
> +
> +properties:
> + compatible:
> + items:
> + - const: mediatek,mt6392-regulator
> +
> +patternProperties:
> + "^(buck_)?v(core|proc|sys)$":
> + description: Buck regulators
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + BUCK regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(adc18|camio|cn18|io18)$":
There was a discussion a bit of time ago and we decided to drop the "ldo_" and
"buck_" prefix from the regulators.
Can you please drop those?
Cheers,
Angelo
> + description: LDOs with fixed 1.8V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(xo22)$":
> + description: LDOs with fixed 2.2V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(m25)$":
> + description: LDOs with fixed 2.5V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(aud28|io28)$":
> + description: LDOs with fixed 2.8V output w/ mode
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(cama)$":
> + description: LDOs with fixed 2.8V output w/o mode
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> + "^(ldo_)?vusb$":
> + description: LDOs with fixed 3.3V output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes:
> + description: |
> + LDO regulators can set regulator-initial-mode and regulator-allowed-modes to
> + values specified in dt-bindings/regulator/mediatek,mt6392-regulator.h
> + items:
> + enum: [0, 1]
> + unevaluatedProperties: false
> +
> + "^(ldo_)?v(aud22|camaf|camd|cn35|efuse|emc3v3|gp1|gp2|m|mc|mch)$":
> + description: LDOs with variable output
> + type: object
> + $ref: regulator.yaml#
> + properties:
> + regulator-allowed-modes: false
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + mt6392_regulators: regulators {
> + compatible = "mediatek,mt6392-regulator";
> +
> + mt6392_vproc_reg: buck_vproc {
> + regulator-name = "vproc";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <12500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vsys_reg: buck_vsys {
> + regulator-name = "vsys";
> + regulator-min-microvolt = <1400000>;
> + regulator-max-microvolt = <2987500>;
> + regulator-ramp-delay = <25000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcore_reg: buck_vcore {
> + regulator-name = "vcore";
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <12500>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vxo22_reg: ldo_vxo22 {
> + regulator-name = "vxo22";
> + regulator-min-microvolt = <2200000>;
> + regulator-max-microvolt = <2200000>;
> + regulator-enable-ramp-delay = <110>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vaud22_reg: ldo_vaud22 {
> + regulator-name = "vaud22";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2200000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcama_reg: ldo_vcama {
> + regulator-name = "vcama";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vaud28_reg: ldo_vaud28 {
> + regulator-name = "vaud28";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vadc18_reg: ldo_vadc18 {
> + regulator-name = "vadc18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcn35_reg: ldo_vcn35 {
> + regulator-name = "vcn35";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3600000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vio28_reg: ldo_vio28 {
> + regulator-name = "vio28";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vusb_reg: ldo_vusb {
> + regulator-name = "vusb";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vmc_reg: ldo_vmc {
> + regulator-name = "vmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-boot-on;
> + };
> +
> + mt6392_vmch_reg: ldo_vmch {
> + regulator-name = "vmch";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-boot-on;
> + };
> +
> + mt6392_vemc3v3_reg: ldo_vemc3v3 {
> + regulator-name = "vemc3v3";
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-boot-on;
> + };
> +
> + mt6392_vgp1_reg: ldo_vgp1 {
> + regulator-name = "vgp1";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vgp2_reg: ldo_vgp2 {
> + regulator-name = "vgp2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vcn18_reg: ldo_vcn18 {
> + regulator-name = "vcn18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vcamaf_reg: ldo_vcamaf {
> + regulator-name = "vcamaf";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vm_reg: ldo_vm {
> + regulator-name = "vm";
> + regulator-min-microvolt = <1240000>;
> + regulator-max-microvolt = <1390000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vio18_reg: ldo_vio18 {
> + regulator-name = "vio18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + mt6392_vcamd_reg: ldo_vcamd {
> + regulator-name = "vcamd";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vcamio_reg: ldo_vcamio {
> + regulator-name = "vcamio";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vm25_reg: ldo_vm25 {
> + regulator-name = "vm25";
> + regulator-min-microvolt = <2500000>;
> + regulator-max-microvolt = <2500000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> +
> + mt6392_vefuse_reg: ldo_vefuse {
> + regulator-name = "vefuse";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <2000000>;
> + regulator-enable-ramp-delay = <264>;
> + };
> + };
> diff --git a/include/dt-bindings/regulator/mediatek,mt6392-regulator.h b/include/dt-bindings/regulator/mediatek,mt6392-regulator.h
> new file mode 100644
> index 000000000000..8bd1a13faad8
> --- /dev/null
> +++ b/include/dt-bindings/regulator/mediatek,mt6392-regulator.h
> @@ -0,0 +1,24 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_REGULATOR_MEDIATEK_MT6392_H_
> +#define _DT_BINDINGS_REGULATOR_MEDIATEK_MT6392_H_
> +
> +/*
> + * Buck mode constants which may be used in devicetree properties (eg.
> + * regulator-initial-mode, regulator-allowed-modes).
> + * See the manufacturer's datasheet for more information on these modes.
> + */
> +
> +#define MT6392_BUCK_MODE_AUTO 0
> +#define MT6392_BUCK_MODE_FORCE_PWM 1
> +
> +/*
> + * LDO mode constants which may be used in devicetree properties (eg.
> + * regulator-initial-mode, regulator-allowed-modes).
> + * See the manufacturer's datasheet for more information on these modes.
> + */
> +
> +#define MT6392_LDO_MODE_NORMAL 0
> +#define MT6392_LDO_MODE_LP 1
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v3 9/9] arm64: dts: mt6392: add mt6392 PMIC dtsi
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Val Packett, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, Linus Walleij, Liam Girdwood, Mark Brown,
Gary Bisson, Julien Massot, Louis-Alexis Eyraud, Fabien Parent,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-10-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Val Packett <val@packett.cool>
>
> Add the dts to be included by all boards using the MT6392 PMIC.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> arch/arm64/boot/dts/mediatek/mt6392.dtsi | 141 +++++++++++++++++++++++
> 1 file changed, 141 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6392.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt6392.dtsi b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> new file mode 100644
> index 000000000000..fbf6f671524c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6392.dtsi
> @@ -0,0 +1,141 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Copyright (c) 2024 Val Packett <val@packett.cool>
> + */
> +
> +#include <dt-bindings/input/input.h>
> +
> +&pwrap {
> + pmic: pmic {
> + compatible = "mediatek,mt6392", "mediatek,mt6323";
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + keys {
> + compatible = "mediatek,mt6392-keys";
> +
> + key-power {
> + linux,keycodes = <KEY_POWER>;
> + wakeup-source;
> + };
> +
> + key-home {
> + linux,keycodes = <KEY_HOME>;
> + wakeup-source;
> + };
> + };
> +
> + pio6392: pinctrl {
> + compatible = "mediatek,mt6392-pinctrl";
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +
> + rtc {
> + compatible = "mediatek,mt6392-rtc",
> + "mediatek,mt6323-rtc";
> + };
> +
> + regulators {
> + compatible = "mediatek,mt6392-regulator";
> +
> + mt6392_vproc_reg: buck_vproc {
s/buck//g
Also, no min/max voltages?!
> + regulator-name = "vproc";
> + };
> +
> + mt6392_vsys_reg: buck_vsys {
> + regulator-name = "vsys";
> + };
> +
> + mt6392_vcore_reg: buck_vcore {
> + regulator-name = "vcore";
> + };
> +
> + mt6392_vxo22_reg: ldo_vxo22 {
s/ldo//g
Also, same comment here, no min/max voltages?!
Most of those are easy too, because the regulator name actually tells you
the voltage it is supposed to output ;-)
Cheers,
Angelo
> + regulator-name = "vxo22";
> + };
> +
> + mt6392_vaud22_reg: ldo_vaud22 {
> + regulator-name = "vaud22";
> + };
> +
> + mt6392_vcama_reg: ldo_vcama {
> + regulator-name = "vcama";
> + };
> +
> + mt6392_vaud28_reg: ldo_vaud28 {
> + regulator-name = "vaud28";
> + };
> +
> + mt6392_vadc18_reg: ldo_vadc18 {
> + regulator-name = "vadc18";
> + };
> +
> + mt6392_vcn35_reg: ldo_vcn35 {
> + regulator-name = "vcn35";
> + };
> +
> + mt6392_vio28_reg: ldo_vio28 {
> + regulator-name = "vio28";
> + };
> +
> + mt6392_vusb_reg: ldo_vusb {
> + regulator-name = "vusb";
> + };
> +
> + mt6392_vmc_reg: ldo_vmc {
> + regulator-name = "vmc";
> + };
> +
> + mt6392_vmch_reg: ldo_vmch {
> + regulator-name = "vmch";
> + };
> +
> + mt6392_vemc3v3_reg: ldo_vemc3v3 {
> + regulator-name = "vemc3v3";
> + };
> +
> + mt6392_vgp1_reg: ldo_vgp1 {
> + regulator-name = "vgp1";
> + };
> +
> + mt6392_vgp2_reg: ldo_vgp2 {
> + regulator-name = "vgp2";
> + };
> +
> + mt6392_vcn18_reg: ldo_vcn18 {
> + regulator-name = "vcn18";
> + };
> +
> + mt6392_vcamaf_reg: ldo_vcamaf {
> + regulator-name = "vcamaf";
> + };
> +
> + mt6392_vm_reg: ldo_vm {
> + regulator-name = "vm";
> + };
> +
> + mt6392_vio18_reg: ldo_vio18 {
> + regulator-name = "vio18";
> + };
> +
> + mt6392_vcamd_reg: ldo_vcamd {
> + regulator-name = "vcamd";
> + };
> +
> + mt6392_vcamio_reg: ldo_vcamio {
> + regulator-name = "vcamio";
> + };
> +
> + mt6392_vm25_reg: ldo_vm25 {
> + regulator-name = "vm25";
> + };
> +
> + mt6392_vefuse_reg: ldo_vefuse {
> + regulator-name = "vefuse";
> + };
> + };
> + };
> +};
^ permalink raw reply
* Re: [PATCH v3 1/9] dt-bindings: mfd: mt6397: Add bindings for MT6392 PMIC
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Fabien Parent, Val Packett, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Gary Bisson, Louis-Alexis Eyraud,
Julien Massot, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-2-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the currently supported bindings for the MT6392 PMIC.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../devicetree/bindings/mfd/mediatek,mt6397.yaml | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> index 6a89b479d10f..22b09e148d7c 100644
> --- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
> @@ -40,6 +40,10 @@ properties:
> - mediatek,mt6358
> - mediatek,mt6359
> - mediatek,mt6397
> + - items:
> + - enum:
> + - mediatek,mt6392
> + - const: mediatek,mt6323
> - items:
> - enum:
> - mediatek,mt6366
> @@ -68,6 +72,10 @@ properties:
> - mediatek,mt6331-rtc
> - mediatek,mt6358-rtc
> - mediatek,mt6397-rtc
> + - items:
> + - enum:
> + - mediatek,mt6392-rtc
> + - const: mediatek,mt6323-rtc
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -92,6 +100,7 @@ properties:
> - mediatek,mt6328-regulator
> - mediatek,mt6358-regulator
> - mediatek,mt6359-regulator
> + - mediatek,mt6392-regulator
> - mediatek,mt6397-regulator
> - items:
> - enum:
^ permalink raw reply
* Re: [PATCH v3 2/9] dt-bindings: input: mtk-pmic-keys: add MT6392 binding definition
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Fabien Parent, Val Packett, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Louis-Alexis Eyraud, Gary Bisson,
Julien Massot, Chen Zhong, linux-input, devicetree, linux-kernel,
linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-3-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Fabien Parent <parent.f@gmail.com>
>
> Add the binding documentation of the mtk-pmic-keys for the MT6392 PMICs.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v3 4/9] dt-bindings: pinctrl: mt65xx: Document MT6392 pinctrl
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
Linus Walleij, Liam Girdwood, Mark Brown, Julien Massot,
Val Packett, Gary Bisson, Louis-Alexis Eyraud, Fabien Parent,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-5-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> Add a compatible for the pinctrl device of the MT6392 PMIC, a variant
> of the already supported MT6397.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../pinctrl/mediatek,mt65xx-pinctrl.yaml | 1 +
> include/dt-bindings/pinctrl/mt6392-pinfunc.h | 39 +++++++++++++++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 include/dt-bindings/pinctrl/mt6392-pinfunc.h
Please rename the header to mediatek,mt6392-pinfunc.h
after which:
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> index aa71398cf522..1468c6f87cfa 100644
> --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> @@ -17,6 +17,7 @@ properties:
> enum:
> - mediatek,mt2701-pinctrl
> - mediatek,mt2712-pinctrl
> + - mediatek,mt6392-pinctrl
> - mediatek,mt6397-pinctrl
> - mediatek,mt7623-pinctrl
> - mediatek,mt8127-pinctrl
> diff --git a/include/dt-bindings/pinctrl/mt6392-pinfunc.h b/include/dt-bindings/pinctrl/mt6392-pinfunc.h
> new file mode 100644
> index 000000000000..c65278c8103d
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/mt6392-pinfunc.h
> @@ -0,0 +1,39 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +#ifndef __DTS_MT6392_PINFUNC_H
> +#define __DTS_MT6392_PINFUNC_H
> +
> +#include <dt-bindings/pinctrl/mt65xx.h>
> +
> +#define MT6392_PIN_0_INT__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
> +#define MT6392_PIN_0_INT__FUNC_INT (MTK_PIN_NO(0) | 1)
> +#define MT6392_PIN_0_INT__FUNC_TEST_CK2 (MTK_PIN_NO(0) | 5)
> +#define MT6392_PIN_0_INT__FUNC_TEST_IN1 (MTK_PIN_NO(0) | 6)
> +#define MT6392_PIN_0_INT__FUNC_TEST_OUT1 (MTK_PIN_NO(0) | 7)
> +
> +#define MT6392_PIN_1_SRCLKEN__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
> +#define MT6392_PIN_1_SRCLKEN__FUNC_SRCLKEN (MTK_PIN_NO(1) | 1)
> +#define MT6392_PIN_1_SRCLKEN__FUNC_TEST_CK0 (MTK_PIN_NO(1) | 5)
> +#define MT6392_PIN_1_SRCLKEN__FUNC_TEST_IN2 (MTK_PIN_NO(1) | 6)
> +#define MT6392_PIN_1_SRCLKEN__FUNC_TEST_OUT2 (MTK_PIN_NO(1) | 7)
> +
> +#define MT6392_PIN_2_RTC_32K1V8__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
> +#define MT6392_PIN_2_RTC_32K1V8__FUNC_RTC_32K1V8 (MTK_PIN_NO(2) | 1)
> +#define MT6392_PIN_2_RTC_32K1V8__FUNC_TEST_CK1 (MTK_PIN_NO(2) | 5)
> +#define MT6392_PIN_2_RTC_32K1V8__FUNC_TEST_IN3 (MTK_PIN_NO(2) | 6)
> +#define MT6392_PIN_2_RTC_32K1V8__FUNC_TEST_OUT3 (MTK_PIN_NO(2) | 7)
> +
> +#define MT6392_PIN_3_SPI_CLK__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
> +#define MT6392_PIN_3_SPI_CLK__FUNC_SPI_CLK (MTK_PIN_NO(3) | 1)
> +
> +#define MT6392_PIN_4_SPI_CSN__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
> +#define MT6392_PIN_4_SPI_CSN__FUNC_SPI_CSN (MTK_PIN_NO(4) | 1)
> +
> +#define MT6392_PIN_5_SPI_MOSI__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
> +#define MT6392_PIN_5_SPI_MOSI__FUNC_SPI_MOSI (MTK_PIN_NO(5) | 1)
> +
> +#define MT6392_PIN_6_SPI_MISO__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
> +#define MT6392_PIN_6_SPI_MISO__FUNC_SPI_MISO (MTK_PIN_NO(6) | 1)
> +#define MT6392_PIN_6_SPI_MISO__FUNC_TEST_IN4 (MTK_PIN_NO(6) | 6)
> +#define MT6392_PIN_6_SPI_MISO__FUNC_TEST_OUT4 (MTK_PIN_NO(6) | 7)
> +
> +#endif /* __DTS_MT6392_PINFUNC_H */
--
AngeloGioacchino Del Regno
Senior Software Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales, no. 5513718
^ permalink raw reply
* Re: [PATCH v3 5/9] mfd: mt6397: Add support for MT6392 pmic
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Fabien Parent, Val Packett, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Lee Jones, Matthias Brugger, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-6-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Fabien Parent <parent.f@gmail.com>
>
> Update the MT6397 MFD driver to support the MT6392 PMIC.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v3 6/9] input: keyboard: mtk-pmic-keys: add MT6392 support
From: AngeloGioacchino Del Regno @ 2026-03-18 12:39 UTC (permalink / raw)
To: Luca Leonardo Scorcia, linux-mediatek
Cc: Val Packett, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, Linus Walleij, Liam Girdwood, Mark Brown,
Gary Bisson, Julien Massot, Louis-Alexis Eyraud, Fabien Parent,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260317184507.523060-7-l.scorcia@gmail.com>
Il 17/03/26 19:43, Luca Leonardo Scorcia ha scritto:
> From: Val Packett <val@packett.cool>
>
> Add support for the MT6392 PMIC to the keys driver.
>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ 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