* Re: [PATCH 0/2] HID: bpf: allow bpf to rebind a driver to hid-mutltiouch
From: Jiri Kosina @ 2025-09-12 15:12 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Peter Hutterer, linux-input, linux-kernel
In-Reply-To: <20250821-bpf-rescan-v1-0-08f9e2bc01bb@kernel.org>
On Thu, 21 Aug 2025, Benjamin Tissoires wrote:
> This happened while Peter was trying to fix a Viewsonic device: the HID
> device sending multiotuch data through a proprietary collection was
> handled by hid-generic, and we don't have any way of attaching it to
> hid-multitouch because the pre-scanning wasn't able to see the Contact
> ID HID usage.
>
> After a little of back and forth, it turns out that the best solution is
> to re-scan the device when a report descriptor is changed from the BPF
> point of view.
>
> Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> ---
> Benjamin Tissoires (2):
> HID: core: factor out hid_set_group()
> HID: bpf: rescan the device for the group after a load/unload
>
> drivers/hid/hid-core.c | 44 ++++++++++++++++++++++++++++++++++++--------
> 1 file changed, 36 insertions(+), 8 deletions(-)
Now in hid.git#for-6.18/core. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH] HID: steelseries: Fix STEELSERIES_SRWS1 handling in steelseries_remove() (was [linux-next:master 1042/7110] drivers/hid/hid-steelseries.c:599:1: warning: unused label 'srws1_remove')
From: Jiri Kosina @ 2025-09-12 14:31 UTC (permalink / raw)
To: kernel test robot
Cc: Jeongjun Park, llvm, oe-kbuild-all, Benjamin Tissoires,
linux-kernel, linux-input
In-Reply-To: <202509090334.76D4qGtW-lkp@intel.com>
On Tue, 9 Sep 2025, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> head: 3e8e5822146bc396d2a7e5fbb7be13271665522a
> commit: a84eeacbf9325fd7f604b80f246aaba157730cd5 [1042/7110] HID: steelseries: refactor probe() and remove()
> config: um-randconfig-002-20250908 (https://download.01.org/0day-ci/archive/20250909/202509090334.76D4qGtW-lkp@intel.com/config)
> compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 7fb1dc08d2f025aad5777bb779dfac1197e9ef87)
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250909/202509090334.76D4qGtW-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202509090334.76D4qGtW-lkp@intel.com/
>
> All warnings (new ones prefixed by >>):
>
> In file included from drivers/hid/hid-steelseries.c:13:
> In file included from include/linux/hid.h:29:
> In file included from include/linux/hid_bpf.h:6:
> In file included from include/linux/bpf.h:31:
> In file included from include/linux/memcontrol.h:13:
> In file included from include/linux/cgroup.h:27:
> In file included from include/linux/kernel_stat.h:8:
> In file included from include/linux/interrupt.h:11:
> In file included from include/linux/hardirq.h:11:
> In file included from arch/um/include/asm/hardirq.h:5:
> In file included from include/asm-generic/hardirq.h:17:
> In file included from include/linux/irq.h:20:
> In file included from include/linux/io.h:12:
> In file included from arch/um/include/asm/io.h:24:
> include/asm-generic/io.h:1175:55: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
> 1175 | return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port;
> | ~~~~~~~~~~ ^
> >> drivers/hid/hid-steelseries.c:599:1: warning: unused label 'srws1_remove' [-Wunused-label]
> 599 | srws1_remove:
> | ^~~~~~~~~~~~~
> 2 warnings generated.
[ adding CCs ]
From: Jiri Kosina <jkosina@suse.com>
Subject: [PATCH] HID: steelseries: Fix STEELSERIES_SRWS1 handling in steelseries_remove()
srws1_remove label can be only reached only if LEDS subsystem is enabled.
To avoid putting horryfing ifdef second time around the label, just
perform the cleanup and exit immediately directly.
Fixes: a84eeacbf9325 ("HID: steelseries: refactor probe() and remove()")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202509090334.76D4qGtW-lkp@intel.com/
Signed-off-by: Jiri Kosina <jkosina@suse.com>
---
drivers/hid/hid-steelseries.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/hid/hid-steelseries.c b/drivers/hid/hid-steelseries.c
index 8af98d67959e..f98435631aa1 100644
--- a/drivers/hid/hid-steelseries.c
+++ b/drivers/hid/hid-steelseries.c
@@ -582,7 +582,7 @@ static void steelseries_remove(struct hid_device *hdev)
if (hdev->product == USB_DEVICE_ID_STEELSERIES_SRWS1) {
#if IS_BUILTIN(CONFIG_LEDS_CLASS) || \
(IS_MODULE(CONFIG_LEDS_CLASS) && IS_MODULE(CONFIG_HID_STEELSERIES))
- goto srws1_remove;
+ hid_hw_stop(hdev);
#endif
return;
}
@@ -596,7 +596,6 @@ static void steelseries_remove(struct hid_device *hdev)
cancel_delayed_work_sync(&sd->battery_work);
hid_hw_close(hdev);
-srws1_remove:
hid_hw_stop(hdev);
}
--
Jiri Kosina
SUSE Labs
^ permalink raw reply related
* Re: [PATCH] HID: lenovo: Use KEY_PERFORMANCE instead of ACPI's platform_profile
From: Jiri Kosina @ 2025-09-12 14:23 UTC (permalink / raw)
To: Janne Grunau
Cc: Benjamin Tissoires, Vishnu Sankar, linux-input, regressions,
linux-kernel, stable
In-Reply-To: <20250901-hid-lenovo-drop-platform_profile-v1-1-e2e9c68483ab@jannau.net>
On Mon, 1 Sep 2025, Janne Grunau wrote:
> Commit 84c9d2a968c82 ("HID: lenovo: Support for ThinkPad-X12-TAB-1/2 Kbd
> Fn keys") added a dependency on ACPI's platform_profile. This should not
> be done for generic USB devices as this prevents using the devices on
> non ACPI devices like Apple silicon Macs and other non-ACPI arm64
> systems. An attempt to allow using platform_profile on non-ACPI systems
> was rejected in [1] and instead platform_profile was made to fail during
> init in commit dd133162c9cf ("ACPI: platform_profile: Avoid initializing
> on non-ACPI platforms").
> So remove the broken dependency and instead let's user space handle this
> keycode by sending the new KEY_PERFORMANCE. Stable backport depends on
> commit 89c5214639294 ("Input: add keycode for performance mode key").
>
> [1]: https://lore.kernel.org/linux-acpi/CAJZ5v0icRdTSToaKbdf=MdRin4NyB2MstUVaQo8VR6-n7DkVMQ@mail.gmail.com/
>
> Cc: regressions@lists.linux.dev
> Cc: stable@vger.kernel.org
> Fixes: 84c9d2a968c82 ("HID: lenovo: Support for ThinkPad-X12-TAB-1/2 Kbd Fn keys")
> Signed-off-by: Janne Grunau <j@jannau.net>
> ---
> #regzbot introduced: 84c9d2a968c82
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: LOFREE: Fix back/forward buttons for
From: Jiri Kosina @ 2025-09-12 14:21 UTC (permalink / raw)
To: stepeos; +Cc: linux-input, linux-kernel
In-Reply-To: <20250831095348.93453-1-onegearmode@gmail.com>
On Sun, 31 Aug 2025, stepeos wrote:
> From: Steve Oswald <stevepeter.oswald@gmail.com>
Changelog and signoff need to go here, otherwise I can't apply the patch.
> ---
> drivers/hid/hid-ids.h | 3 ++
> drivers/hid/hid-lofree.c | 96 ++++++++++++++++++++++++++++++++++++++++
You are adding a new driver, but neither Makefile nor Kconfig entry for
it, which is suspicious at least :)
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Adding Kernel xpad support for Flydigi Apex 5
From: Jiri Kosina @ 2025-09-12 14:14 UTC (permalink / raw)
To: brandon; +Cc: vi, linux-input
In-Reply-To: <75r4880n-on78-7010-2q64-so6pp5qsos82@xreary.bet>
On Fri, 12 Sep 2025, Jiri Kosina wrote:
> On Fri, 29 Aug 2025, brandon wrote:
>
> > Hello,
> >
> > This adds support for the Flydigi Apex 5 controller to the xpad kernel module. This has been tested as part of: https://github.com/paroj/xpad/pull/328
> >
> > This patch is very small and simple, it simply white lists the controller so it can be used. The trigger and stick mappings are none standard, but SDL has the correct mappings already shipped so it's not a problem in Steam or games I've tried.
> >
> > Here is the patch:
> >
> > --- linux/drivers/input/joystick/xpad.c.orig 2025-08-29 18:20:56.157442704 +0100
> > +++ linux/drivers/input/joystick/xpad.c 2025-08-29 18:19:29.539174760 +0100
> > @@ -422,6 +422,7 @@ static const struct xpad_device {
> > { 0x3537, 0x1010, "GameSir G7 SE", 0, XTYPE_XBOXONE },
> > { 0x366c, 0x0005, "ByoWave Proteus Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE, FLAG_DELAY_INIT },
> > { 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX },
> > + { 0x37d7, 0x2501, "Flydigi Apex 5", 0, XTYPE_XBOX },
> > { 0x413d, 0x2104, "Black Shark Green Ghost Gamepad", 0, XTYPE_XBOX360 },
> > { 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
> > { 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
> > @@ -578,6 +579,7 @@ static const struct usb_device_id xpad_t
> > XPAD_XBOX360_VENDOR(0x3537), /* GameSir Controllers */
> > XPAD_XBOXONE_VENDOR(0x3537), /* GameSir Controllers */
> > XPAD_XBOXONE_VENDOR(0x366c), /* ByoWave controllers */
> > + XPAD_XBOXONE_VENDOR(0x37d7), /* Flydigi Controllers */
> > XPAD_XBOX360_VENDOR(0x413d), /* Black Shark Green Ghost Controller */
> > { }
> > };
>
> Thanks for the patch.
>
> It's however whitespace-damaged, and also is missing a signoff. Could you
> please fix that and resubmit, so that I could merge it?
(sorry, it's not me who should be merging it, but Dmitry Torokhov as an
input maintainer -- please CC him as well on the next iteration)
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Adding Kernel xpad support for Flydigi Apex 5
From: Jiri Kosina @ 2025-09-12 14:14 UTC (permalink / raw)
To: brandon; +Cc: vi, linux-input
In-Reply-To: <198f7064b23.1194b1b9d477339.120973386817363979@emergence.ltd>
On Fri, 29 Aug 2025, brandon wrote:
> Hello,
>
> This adds support for the Flydigi Apex 5 controller to the xpad kernel module. This has been tested as part of: https://github.com/paroj/xpad/pull/328
>
> This patch is very small and simple, it simply white lists the controller so it can be used. The trigger and stick mappings are none standard, but SDL has the correct mappings already shipped so it's not a problem in Steam or games I've tried.
>
> Here is the patch:
>
> --- linux/drivers/input/joystick/xpad.c.orig 2025-08-29 18:20:56.157442704 +0100
> +++ linux/drivers/input/joystick/xpad.c 2025-08-29 18:19:29.539174760 +0100
> @@ -422,6 +422,7 @@ static const struct xpad_device {
> { 0x3537, 0x1010, "GameSir G7 SE", 0, XTYPE_XBOXONE },
> { 0x366c, 0x0005, "ByoWave Proteus Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE, FLAG_DELAY_INIT },
> { 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX },
> + { 0x37d7, 0x2501, "Flydigi Apex 5", 0, XTYPE_XBOX },
> { 0x413d, 0x2104, "Black Shark Green Ghost Gamepad", 0, XTYPE_XBOX360 },
> { 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
> { 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
> @@ -578,6 +579,7 @@ static const struct usb_device_id xpad_t
> XPAD_XBOX360_VENDOR(0x3537), /* GameSir Controllers */
> XPAD_XBOXONE_VENDOR(0x3537), /* GameSir Controllers */
> XPAD_XBOXONE_VENDOR(0x366c), /* ByoWave controllers */
> + XPAD_XBOXONE_VENDOR(0x37d7), /* Flydigi Controllers */
> XPAD_XBOX360_VENDOR(0x413d), /* Black Shark Green Ghost Controller */
> { }
> };
Thanks for the patch.
It's however whitespace-damaged, and also is missing a signoff. Could you
please fix that and resubmit, so that I could merge it?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/2] hid: intel-thc-hid: intel-quicki2c: Add WCL Device IDs
From: Jiri Kosina @ 2025-09-12 14:13 UTC (permalink / raw)
To: Xinpeng Sun; +Cc: bentiss, srinivas.pandruvada, linux-input, linux-kernel
In-Reply-To: <20250828021000.3299377-1-xinpeng.sun@intel.com>
Both patches now applied to hid.git#for-6.17/upstream-fixes, thanks.
(next time, please follow the HID subsystem shortlog convention with
capitalized 'HID:' prefix, thanks).
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: net: Convert Marvell 8897/8997 bindings to DT schema
From: Rob Herring @ 2025-09-12 14:06 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
sean.wang, simona, support.opensource, tiffany.lin, tzimmermann,
yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-bluetooth, linux-gpio, linux-input, linux-kernel,
linux-media, linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-4-ariel.dalessandro@collabora.com>
On Thu, Sep 11, 2025 at 12:09:52PM -0300, Ariel D'Alessandro wrote:
> Convert the existing text-based DT bindings for Marvell 8897/8997
> (sd8897/sd8997) bluetooth devices controller to a DT schema.
>
> While here:
>
> * bindings for "usb1286,204e" (USB interface) are dropped from the DT
> schema definition as these are currently documented in file [0].
> * DT binding users are updated to use bluetooth generic name
> recommendation.
>
> [0] Documentation/devicetree/bindings/net/btusb.txt
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> ---
> .../net/bluetooth/marvell,sd8897-bt.yaml | 79 ++++++++++++++++++
> .../devicetree/bindings/net/btusb.txt | 2 +-
> .../bindings/net/marvell-bt-8xxx.txt | 83 -------------------
> .../dts/rockchip/rk3288-veyron-fievel.dts | 2 +-
> .../boot/dts/rockchip/rk3288-veyron-jaq.dts | 2 +-
> arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
.dts files should be separate patches. Please send the bindings patches
separately per subsystem so subsystem maintainers can apply them. All
the Mediatek dts changes can be 1 series.
The schema looks good.
Rob
^ permalink raw reply
* Re: [PATCH v2 01/12] dt-bindings: media: Convert MediaTek mt8173-mdp bindings to DT schema
From: Krzysztof Kozlowski @ 2025-09-12 13:25 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, angelogioacchino.delregno, broonie, chunkuang.hu,
conor+dt, davem, dmitry.torokhov, edumazet, flora.fu, heiko,
houlong.wei, jeesw, kernel, krzk+dt, kuba, lgirdwood,
linus.walleij, louisalexis.eyraud, luiz.dentz, maarten.lankhorst,
marcel, matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel,
pabeni, robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-bluetooth, linux-gpio, linux-input, linux-kernel,
linux-media, linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <CAGXv+5GovP7NuG042AwfmtC-sPJMGuFAm6iZ0iqNZgU0VE+qmQ@mail.gmail.com>
On 12/09/2025 10:27, Chen-Yu Tsai wrote:
>>> +properties:
>>> + compatible:
>>> + oneOf:
>>> + - enum:
>>> + - mediatek,mt8173-mdp-rdma
>>> + - mediatek,mt8173-mdp-rsz
>>> + - mediatek,mt8173-mdp-wdma
>>> + - mediatek,mt8173-mdp-wrot
>>
>> Why there is no mediatek,mt8173-mdp here? What does this compatible
>> represent?
>>
>>> + - items:
>>> + - const: mediatek,mt8173-mdp-rdma
>>
>> Still suspicious. Device cannot be simulatanously: compatible and not
>> compatible. This is not a well known cat that has superposition of two
>> states, whenenver you look the other way.
>>
>> Maybe the old binding was incorrect, maybe the in-tree DTS is incorrect.
>> Whichever the reason, this must be investigated and documented, because
>> by standard rules this is wrong. Each wrong code needs very clear
>> explanations (and "someone did it" is not a good enough explanation).
>
> My guess is that "mediatek,mt8173-mdp" is meant to serve as a single
> entry point for the implementation to bind the driver to. The MDP is
I am speaking about hardware. What piece of hardware it implements and
why sometimes it is RDMA MDP and sometimes it is not RDMA MDP, but only MDP.
> a Data Pipeline and there could be multiple instances of the same
> IP block, as seen in the original example.
>
> The datasheet I have doesn't cover the "RDMA" block specifically, so
> I can't say whether there is an actual difference between the two RDMA
> blocks.
>
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [regression] 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") causes issue with ID 4c4a:4155 Jieli Technology USB Composite Device
From: zhangheng @ 2025-09-12 12:49 UTC (permalink / raw)
To: Salvatore Bonaccorso, Jiri Kosina, Staffan Melin
Cc: Benjamin Tissoires, linux-input, linux-kernel, regressions,
stable, 1114557
In-Reply-To: <aL2gYJaXoB6p_oyM@eldamar.lan>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
I am currently working on resolving this issue by limiting the original
patch
based on the information in the device descriptor to avoid affecting
your device,
You can try this patch and look forward to your reply.
在 2025/9/7 23:10, Salvatore Bonaccorso 写道:
> Hi Zhang, hi Jiri,
>
> In Debian Staffan Melin reported that after an update containing the
> commit 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY"),
> the input device with same idVendor and idProduct, the Jieli
> Technology USB Composite Device, does not get recognized anymore.
>
> The full Debian report is at: https://bugs.debian.org/1114557
>
> The issue is not specific to the 6.12.y series and confirmed in 6.16.3
> as well.
>
> Staffan Melin did bisect the kernels between 6.12.38 (which was still
> working) and 6.1.41 (which was not), confirming by bisection that the
> offending commit is
>
> 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY")
>
> #regzbot introduced: 1a8953f4f774
> #regzbot monitor: https://bugs.debian.org/1114557
>
> So it looks that the quirk applied is unfortunately affecting
> negatively as well Staffan Melin case.
>
> Can you have a look?
>
> Regards,
> Salvatore
[-- Attachment #2: 0001-HID-quirks-Add-device-descriptor-for-4c4a-4155.patch --]
[-- Type: text/plain, Size: 2175 bytes --]
From 9fb4fd3873e5693647e517c7960383c4523cd093 Mon Sep 17 00:00:00 2001
From: Zhang Heng <zhangheng@kylinos.cn>
Date: Fri, 12 Sep 2025 20:38:18 +0800
Subject: [PATCH] HID: quirks: Add device descriptor for 4c4a:4155
Two USB devices use the same ID. To avoid affecting functionality,
device descriptors are added to distinguish between them
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
---
drivers/hid/hid-quirks.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index ffd034566e2e..d39a8e53ea36 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -913,6 +913,17 @@ static const struct hid_device_id hid_ignore_list[] = {
#endif
{ HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_QUANTA, USB_DEVICE_ID_QUANTA_HP_5MP_CAMERA_5473) },
+ { }
+};
+/*
+ * hid_ignore_mic - Microphone devices do not require HID core processing
+ *
+ * Now there are two USB devices using the same ID, one is the microphone and the other
+ * is the touch screen. The touch screen requires hid core processing, but the
+ * microphone does not. The two have different bcdIDs, which will be used to
+ * distinguish them in the future
+ */
+static const struct hid_device_id hid_ignore_mic[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SMARTLINKTECHNOLOGY, USB_DEVICE_ID_SMARTLINKTECHNOLOGY_4155) },
{ }
};
@@ -1068,6 +1079,9 @@ bool hid_ignore(struct hid_device *hdev)
hdev->quirks & HID_QUIRK_IGNORE_MOUSE)
return true;
+ if(hid_match_id(hdev, hid_ignore_mic) && (hdev->version > 1.1))
+ return true;
+
return !!hid_match_id(hdev, hid_ignore_list);
}
EXPORT_SYMBOL_GPL(hid_ignore);
@@ -1266,7 +1280,8 @@ static unsigned long hid_gets_squirk(const struct hid_device *hdev)
const struct hid_device_id *bl_entry;
unsigned long quirks = hdev->initial_quirks;
- if (hid_match_id(hdev, hid_ignore_list))
+ if (hid_match_id(hdev, hid_ignore_list) ||
+ (hid_match_id(hdev, hid_ignore_mic) && (hdev->version > 1.1)))
quirks |= HID_QUIRK_IGNORE;
if (hid_match_id(hdev, hid_mouse_ignore_list))
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v14 00/10] Add support for MAX7360
From: Mathieu Dubois-Briand @ 2025-09-12 12:07 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kamel Bouhara,
Linus Walleij, Bartosz Golaszewski, Dmitry Torokhov,
Uwe Kleine-König, Michael Walle, Mark Brown,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
devicetree, linux-kernel, linux-gpio, linux-input, linux-pwm,
andriy.shevchenko, Grégory Clement, Thomas Petazzoni,
Krzysztof Kozlowski, Andy Shevchenko, Bartosz Golaszewski
In-Reply-To: <20250902152306.GV2163762@google.com>
On Tue Sep 2, 2025 at 5:23 PM CEST, Lee Jones wrote:
> On Sun, 24 Aug 2025, Mathieu Dubois-Briand wrote:
>
>> This series implements a set of drivers allowing to support the Maxim
>> Integrated MAX7360 device.
>>
>> The MAX7360 is an I2C key-switch and led controller, with following
>> functionalities:
>> - Keypad controller for a key matrix of up to 8 rows and 8 columns.
>> - Rotary encoder support, for a single rotary encoder.
>> - Up to 8 PWM outputs.
>> - Up to 8 GPIOs with support for interrupts and 6 GPOs.
>
> MFD looks okay now, let me know when you have all Acks and I'll merge the set.
Hi Lee,
The PWM driver just got Acked, so I believe we are good to go.
Please tell me if there is anything else I need to do.
Thanks,
Mathieu
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v14 04/10] pwm: max7360: Add MAX7360 PWM support
From: Mathieu Dubois-Briand @ 2025-09-12 12:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kamel Bouhara, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Michael Walle, Mark Brown, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, devicetree, linux-kernel,
linux-gpio, linux-input, linux-pwm, andriy.shevchenko,
Grégory Clement, Thomas Petazzoni, Andy Shevchenko
In-Reply-To: <7jytyub4v7tn6vbwh4drusaagnskl2dsfg2xr6eqp4leqpfq3y@a7g3de5echs4>
On Fri Sep 12, 2025 at 10:57 AM CEST, Uwe Kleine-König wrote:
> On Sun, Aug 24, 2025 at 01:57:23PM +0200, Mathieu Dubois-Briand wrote:
>> +static int max7360_pwm_round_waveform_tohw(struct pwm_chip *chip,
>> + struct pwm_device *pwm,
>> + const struct pwm_waveform *wf,
>> + void *_wfhw)
>> +{
>> + struct max7360_pwm_waveform *wfhw = _wfhw;
>> + u64 duty_steps;
>> +
>> + /*
>> + * Ignore user provided values for period_length_ns and duty_offset_ns:
>> + * we only support fixed period of MAX7360_PWM_PERIOD_NS and offset of 0.
>> + * Values from 0 to 254 as duty_steps will provide duty cycles of 0/256
>> + * to 254/256, while value 255 will provide a duty cycle of 100%.
>> + */
>> + if (wf->duty_length_ns >= MAX7360_PWM_PERIOD_NS) {
>> + duty_steps = MAX7360_PWM_MAX;
>> + } else {
>> + duty_steps = (u32)wf->duty_length_ns * MAX7360_PWM_STEPS / MAX7360_PWM_PERIOD_NS;
>> + if (duty_steps == MAX7360_PWM_MAX)
>> + duty_steps = MAX7360_PWM_MAX - 1;
>> + }
>> +
>> + wfhw->duty_steps = min(MAX7360_PWM_MAX, duty_steps);
>
> duty_steps is never bigger than MAX7360_PWM_MAX, isn't it? Then this can
> be simplified to just
>
> wfhw->duty_steps = duty_steps;
>
Ok, I reviewed this section and I do agree with you. I will prepare a
new patch to fix this line and will send it separately.
> Otherwise looks fine to me.
>
> To get this series forward, it's OK for me to apply the series as is via
> Lee's MFD tree and cope for this minor optimisation later. So:
>
> Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
>
> Best regards
> Uwe
Thanks,
Mathieu
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v1 2/2] Drivers: hv: Make CONFIG_HYPERV bool
From: Greg KH @ 2025-09-12 11:43 UTC (permalink / raw)
To: Mukesh R
Cc: dri-devel, linux-kernel, linux-input, linux-hyperv, netdev,
linux-pci, linux-scsi, linux-fbdev, linux-arch, virtualization,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, jikos,
bentiss, kys, haiyangz, wei.liu, decui, dmitry.torokhov,
andrew+netdev, davem, edumazet, kuba, pabeni, bhelgaas,
James.Bottomley, martin.petersen, deller, arnd, sgarzare, horms
In-Reply-To: <d7d7b23f-eaea-2dbc-9c9d-4bee082f6fe7@linux.microsoft.com>
On Mon, Sep 08, 2025 at 02:01:34PM -0700, Mukesh R wrote:
> On 9/6/25 04:36, Greg KH wrote:
> > On Fri, Sep 05, 2025 at 06:09:52PM -0700, Mukesh Rathor wrote:
> >> With CONFIG_HYPERV and CONFIG_HYPERV_VMBUS separated, change CONFIG_HYPERV
> >> to bool from tristate. CONFIG_HYPERV now becomes the core Hyper-V
> >> hypervisor support, such as hypercalls, clocks/timers, Confidential
> >> Computing setup, PCI passthru, etc. that doesn't involve VMBus or VMBus
> >> devices.
> >
> > But why are you making it so that this can not be a module anymore? You
> > are now forcing ALL Linux distro users to always have this code in their
> > system, despite not ever using the feature. That feels like a waste to
> > me.
> >
> > What is preventing this from staying as a module? Why must you always
> > have this code loaded at all times for everyone?
>
> This is currently not a module. I assume it was at the beginning. In
> drivers/Makefile today:
>
> obj-$(subst m,y,$(CONFIG_HYPERV)) += hv/
>
>
> More context: CONFIG_HYPERV doesn't really reflect one module. It is
> both for kernel built in code and building of stuff in drivers/hv.
>
> drivers/hv then builds 4 modules:
>
> obj-$(CONFIG_HYPERV) += hv_vmbus.o
> obj-$(CONFIG_HYPERV_UTILS) += hv_utils.o
> obj-$(CONFIG_HYPERV_BALLOON) += hv_balloon.o
> obj-$(CONFIG_MSHV_ROOT) += mshv_root.o
>
> Notice vmbus is using CONFIG_HYPERV because there is no
> CONFIG_HYPERV_VMBUS. We are trying to fix that here.
This series does not apply to my tree:
checking file drivers/gpu/drm/Kconfig
checking file drivers/hid/Kconfig
checking file drivers/hv/Kconfig
Hunk #2 FAILED at 82.
1 out of 2 hunks FAILED
checking file drivers/hv/Makefile
checking file drivers/input/serio/Kconfig
checking file drivers/net/hyperv/Kconfig
checking file drivers/pci/Kconfig
checking file drivers/scsi/Kconfig
checking file drivers/uio/Kconfig
checking file drivers/video/fbdev/Kconfig
checking file include/asm-generic/mshyperv.h
Hunk #1 succeeded at 162 with fuzz 2 (offset -3 lines).
Hunk #2 succeeded at 198 (offset -3 lines).
Hunk #3 succeeded at 215 (offset -3 lines).
checking file net/vmw_vsock/Kconfig
What was it made against?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v14 04/10] pwm: max7360: Add MAX7360 PWM support
From: Uwe Kleine-König @ 2025-09-12 8:57 UTC (permalink / raw)
To: Mathieu Dubois-Briand
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kamel Bouhara, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Michael Walle, Mark Brown, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, devicetree, linux-kernel,
linux-gpio, linux-input, linux-pwm, andriy.shevchenko,
Grégory Clement, Thomas Petazzoni, Andy Shevchenko
In-Reply-To: <20250824-mdb-max7360-support-v14-4-435cfda2b1ea@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
On Sun, Aug 24, 2025 at 01:57:23PM +0200, Mathieu Dubois-Briand wrote:
> +static int max7360_pwm_round_waveform_tohw(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + const struct pwm_waveform *wf,
> + void *_wfhw)
> +{
> + struct max7360_pwm_waveform *wfhw = _wfhw;
> + u64 duty_steps;
> +
> + /*
> + * Ignore user provided values for period_length_ns and duty_offset_ns:
> + * we only support fixed period of MAX7360_PWM_PERIOD_NS and offset of 0.
> + * Values from 0 to 254 as duty_steps will provide duty cycles of 0/256
> + * to 254/256, while value 255 will provide a duty cycle of 100%.
> + */
> + if (wf->duty_length_ns >= MAX7360_PWM_PERIOD_NS) {
> + duty_steps = MAX7360_PWM_MAX;
> + } else {
> + duty_steps = (u32)wf->duty_length_ns * MAX7360_PWM_STEPS / MAX7360_PWM_PERIOD_NS;
> + if (duty_steps == MAX7360_PWM_MAX)
> + duty_steps = MAX7360_PWM_MAX - 1;
> + }
> +
> + wfhw->duty_steps = min(MAX7360_PWM_MAX, duty_steps);
duty_steps is never bigger than MAX7360_PWM_MAX, isn't it? Then this can
be simplified to just
wfhw->duty_steps = duty_steps;
Otherwise looks fine to me.
To get this series forward, it's OK for me to apply the series as is via
Lee's MFD tree and cope for this minor optimisation later. So:
Acked-by: Uwe Kleine-König <ukleinek@kernel.org>
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 01/12] dt-bindings: media: Convert MediaTek mt8173-mdp bindings to DT schema
From: AngeloGioacchino Del Regno @ 2025-09-12 8:49 UTC (permalink / raw)
To: Chen-Yu Tsai, Krzysztof Kozlowski
Cc: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-bluetooth, linux-gpio, linux-input, linux-kernel,
linux-media, linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <CAGXv+5GovP7NuG042AwfmtC-sPJMGuFAm6iZ0iqNZgU0VE+qmQ@mail.gmail.com>
Il 12/09/25 10:27, Chen-Yu Tsai ha scritto:
> On Fri, Sep 12, 2025 at 2:06 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Thu, Sep 11, 2025 at 12:09:50PM -0300, Ariel D'Alessandro wrote:
>>> Convert the existing text-based DT bindings for MediaTek MT8173 Media Data
>>> Path to a DT schema.
>>>
>>> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>>> ---
>>> .../bindings/media/mediatek,mt8173-mdp.yaml | 169 ++++++++++++++++++
>>> .../bindings/media/mediatek-mdp.txt | 95 ----------
>>> 2 files changed, 169 insertions(+), 95 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>>> delete mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>>> new file mode 100644
>>> index 0000000000000..8ca33a733c478
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
>>> @@ -0,0 +1,169 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/media/mediatek,mt8173-mdp.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: MediaTek MT8173 Media Data Path
>>> +
>>> +maintainers:
>>> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
>>> +
>>> +description:
>>> + Media Data Path is used for scaling and color space conversion.
>>> +
>>> +properties:
>>> + compatible:
>>> + oneOf:
>>> + - enum:
>>> + - mediatek,mt8173-mdp-rdma
>>> + - mediatek,mt8173-mdp-rsz
>>> + - mediatek,mt8173-mdp-wdma
>>> + - mediatek,mt8173-mdp-wrot
>>
>> Why there is no mediatek,mt8173-mdp here? What does this compatible
>> represent?
>>
>>> + - items:
>>> + - const: mediatek,mt8173-mdp-rdma
>>
>> Still suspicious. Device cannot be simulatanously: compatible and not
>> compatible. This is not a well known cat that has superposition of two
>> states, whenenver you look the other way.
>>
>> Maybe the old binding was incorrect, maybe the in-tree DTS is incorrect.
>> Whichever the reason, this must be investigated and documented, because
>> by standard rules this is wrong. Each wrong code needs very clear
>> explanations (and "someone did it" is not a good enough explanation).
>
> My guess is that "mediatek,mt8173-mdp" is meant to serve as a single
> entry point for the implementation to bind the driver to. The MDP is
> a Data Pipeline and there could be multiple instances of the same
> IP block, as seen in the original example.
>
Yeah your guess is right.
Cheers,
Angelo
> The datasheet I have doesn't cover the "RDMA" block specifically, so
> I can't say whether there is an actual difference between the two RDMA
> blocks.
>
>
> ChenYu
>
>>> + - const: mediatek,mt8173-mdp
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + clocks:
>>> + minItems: 1
>>> + maxItems: 2
>>> +
>>> + power-domains:
>>> + maxItems: 1
>>> +
>>> + iommus:
>>> + maxItems: 1
>>> +
>>> + mediatek,vpu:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description:
>>> + phandle to Mediatek Video Processor Unit for HW Codec encode/decode and
>>> + image processing.
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - clocks
>>> + - power-domains
>>> +
>>> +allOf:
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: mediatek,mt8173-mdp-rdma
>>> + then:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: Main clock
>>> + - description: Mutex clock
>>> + else:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: Main clock
>>> +
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - mediatek,mt8173-mdp-rdma
>>> + - mediatek,mt8173-mdp-wdma
>>> + - mediatek,mt8173-mdp-wrot
>>> + then:
>>> + required:
>>> + - iommus
>>> +
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: mediatek,mt8173-mdp
>>> + then:
>>> + required:
>>> + - mediatek,vpu
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/clock/mt8173-clk.h>
>>> + #include <dt-bindings/memory/mt8173-larb-port.h>
>>> + #include <dt-bindings/power/mt8173-power.h>
>>> +
>>> + soc {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> +
>>> + mdp_rdma0: rdma@14001000 {
>>> + compatible = "mediatek,mt8173-mdp-rdma",
>>> + "mediatek,mt8173-mdp";
>>> + reg = <0 0x14001000 0 0x1000>;
>>> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
>>> + <&mmsys CLK_MM_MUTEX_32K>;
>>> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
>>> + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
>>> + mediatek,vpu = <&vpu>;
>>> + };
>>> +
>>> + mdp_rdma1: rdma@14002000 {
>>> + compatible = "mediatek,mt8173-mdp-rdma";
>>> + reg = <0 0x14002000 0 0x1000>;
>>> + clocks = <&mmsys CLK_MM_MDP_RDMA1>,
>>> + <&mmsys CLK_MM_MUTEX_32K>;
>>> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
>>> + iommus = <&iommu M4U_PORT_MDP_RDMA1>;
>>> + };
>>
>> My previous comment applies.
>>
>> Keep one or two examples.
>>
>> Best regards,
>> Krzysztof
>>
^ permalink raw reply
* Re: [PATCH v2 01/12] dt-bindings: media: Convert MediaTek mt8173-mdp bindings to DT schema
From: Chen-Yu Tsai @ 2025-09-12 8:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, angelogioacchino.delregno, broonie, chunkuang.hu,
conor+dt, davem, dmitry.torokhov, edumazet, flora.fu, heiko,
houlong.wei, jeesw, kernel, krzk+dt, kuba, lgirdwood,
linus.walleij, louisalexis.eyraud, luiz.dentz, maarten.lankhorst,
marcel, matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel,
pabeni, robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-bluetooth, linux-gpio, linux-input, linux-kernel,
linux-media, linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250912-alluring-turaco-of-conversion-dca193@kuoka>
On Fri, Sep 12, 2025 at 2:06 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Thu, Sep 11, 2025 at 12:09:50PM -0300, Ariel D'Alessandro wrote:
> > Convert the existing text-based DT bindings for MediaTek MT8173 Media Data
> > Path to a DT schema.
> >
> > Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> > ---
> > .../bindings/media/mediatek,mt8173-mdp.yaml | 169 ++++++++++++++++++
> > .../bindings/media/mediatek-mdp.txt | 95 ----------
> > 2 files changed, 169 insertions(+), 95 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
> > delete mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
> > new file mode 100644
> > index 0000000000000..8ca33a733c478
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
> > @@ -0,0 +1,169 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/mediatek,mt8173-mdp.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: MediaTek MT8173 Media Data Path
> > +
> > +maintainers:
> > + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> > +
> > +description:
> > + Media Data Path is used for scaling and color space conversion.
> > +
> > +properties:
> > + compatible:
> > + oneOf:
> > + - enum:
> > + - mediatek,mt8173-mdp-rdma
> > + - mediatek,mt8173-mdp-rsz
> > + - mediatek,mt8173-mdp-wdma
> > + - mediatek,mt8173-mdp-wrot
>
> Why there is no mediatek,mt8173-mdp here? What does this compatible
> represent?
>
> > + - items:
> > + - const: mediatek,mt8173-mdp-rdma
>
> Still suspicious. Device cannot be simulatanously: compatible and not
> compatible. This is not a well known cat that has superposition of two
> states, whenenver you look the other way.
>
> Maybe the old binding was incorrect, maybe the in-tree DTS is incorrect.
> Whichever the reason, this must be investigated and documented, because
> by standard rules this is wrong. Each wrong code needs very clear
> explanations (and "someone did it" is not a good enough explanation).
My guess is that "mediatek,mt8173-mdp" is meant to serve as a single
entry point for the implementation to bind the driver to. The MDP is
a Data Pipeline and there could be multiple instances of the same
IP block, as seen in the original example.
The datasheet I have doesn't cover the "RDMA" block specifically, so
I can't say whether there is an actual difference between the two RDMA
blocks.
ChenYu
> > + - const: mediatek,mt8173-mdp
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + minItems: 1
> > + maxItems: 2
> > +
> > + power-domains:
> > + maxItems: 1
> > +
> > + iommus:
> > + maxItems: 1
> > +
> > + mediatek,vpu:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + phandle to Mediatek Video Processor Unit for HW Codec encode/decode and
> > + image processing.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - power-domains
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: mediatek,mt8173-mdp-rdma
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: Main clock
> > + - description: Mutex clock
> > + else:
> > + properties:
> > + clocks:
> > + items:
> > + - description: Main clock
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - mediatek,mt8173-mdp-rdma
> > + - mediatek,mt8173-mdp-wdma
> > + - mediatek,mt8173-mdp-wrot
> > + then:
> > + required:
> > + - iommus
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: mediatek,mt8173-mdp
> > + then:
> > + required:
> > + - mediatek,vpu
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/mt8173-clk.h>
> > + #include <dt-bindings/memory/mt8173-larb-port.h>
> > + #include <dt-bindings/power/mt8173-power.h>
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + mdp_rdma0: rdma@14001000 {
> > + compatible = "mediatek,mt8173-mdp-rdma",
> > + "mediatek,mt8173-mdp";
> > + reg = <0 0x14001000 0 0x1000>;
> > + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > + <&mmsys CLK_MM_MUTEX_32K>;
> > + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> > + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> > + mediatek,vpu = <&vpu>;
> > + };
> > +
> > + mdp_rdma1: rdma@14002000 {
> > + compatible = "mediatek,mt8173-mdp-rdma";
> > + reg = <0 0x14002000 0 0x1000>;
> > + clocks = <&mmsys CLK_MM_MDP_RDMA1>,
> > + <&mmsys CLK_MM_MUTEX_32K>;
> > + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> > + iommus = <&iommu M4U_PORT_MDP_RDMA1>;
> > + };
>
> My previous comment applies.
>
> Keep one or two examples.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 12/12] dt-bindings: input: Convert MELFAS MIP4 Touchscreen to DT schema
From: AngeloGioacchino Del Regno @ 2025-09-12 8:13 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-13-ariel.dalessandro@collabora.com>
Il 11/09/25 17:10, Ariel D'Alessandro ha scritto:
> Convert the existing text-based DT bindings for MELFAS MIP4 Touchscreen
> controller to a DT schema.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 08/12] dt-bindings: pinctrl: mt65xx: Allow gpio-line-names
From: AngeloGioacchino Del Regno @ 2025-09-12 8:12 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-9-ariel.dalessandro@collabora.com>
Il 11/09/25 17:09, Ariel D'Alessandro ha scritto:
> Current, the DT bindings for MediaTek's MT65xx Pin controller is missing
> the gpio-line-names property, add it to the associated schema.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> index b9680b896f12f..aa71398cf522f 100644
> --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml
> @@ -43,6 +43,8 @@ properties:
> the amount of cells must be specified as 2. See the below mentioned gpio
> binding representation for description of particular cells.
>
> + gpio-line-names: true
> +
> mediatek,pctl-regmap:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
^ permalink raw reply
* Re: [PATCH v2 11/12] dt-bindings: soc: mediatek: pwrap: Add power-domains property
From: AngeloGioacchino Del Regno @ 2025-09-12 8:11 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-12-ariel.dalessandro@collabora.com>
Il 11/09/25 17:10, Ariel D'Alessandro ha scritto:
> Currently, the DT bindings for Mediatek PMIC Wrapper is missing the
> power-domains property, which is used in the MT8173 E1 evaluation board as
> it needs USB power domain.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../bindings/soc/mediatek/mediatek,pwrap.yaml | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
> index 4737e5f45d541..54c0cd64d3094 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
> +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,pwrap.yaml
> @@ -98,6 +98,9 @@ properties:
> - const: pwrap
> - const: pwrap-bridge
>
> + power-domains:
> + maxItems: 1
> +
> pmic:
> type: object
>
> @@ -126,6 +129,18 @@ allOf:
> clock-names:
> minItems: 4
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: mediatek,mt8173-pwrap
> + then:
> + properties:
> + power-domains: true
> + else:
> + properties:
> + power-domains: false
> +
> additionalProperties: false
>
> examples:
^ permalink raw reply
* Re: [PATCH v2 10/12] arm64: dts: mediatek: mt8173-elm: Drop unused bank supply
From: AngeloGioacchino Del Regno @ 2025-09-12 8:11 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-11-ariel.dalessandro@collabora.com>
Il 11/09/25 17:09, Ariel D'Alessandro ha scritto:
> The mediatek,mt8173-thermal device tree binding schema doesn't allow
> regulator supplies like the ones defined in mt8173-elm.dtsi. Drop these as
> the associated driver doesn't implement them either.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 09/12] dt-bindings: regulator: Convert Dialog DA9211 Regulators to DT schema
From: AngeloGioacchino Del Regno @ 2025-09-12 8:11 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-10-ariel.dalessandro@collabora.com>
Il 11/09/25 17:09, Ariel D'Alessandro ha scritto:
> Convert the existing text-based DT bindings for Dialog Semiconductor DA9211
> Voltage Regulators family to a DT schema. Examples are simplified, as these
> are all equal.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> ---
> .../devicetree/bindings/regulator/da9211.txt | 205 ------------------
> .../bindings/regulator/dlg,da9211.yaml | 104 +++++++++
> 2 files changed, 104 insertions(+), 205 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/regulator/da9211.txt
> create mode 100644 Documentation/devicetree/bindings/regulator/dlg,da9211.yaml
>
..snip..
> diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9211.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9211.yaml
> new file mode 100644
> index 0000000000000..9d5e25bc3872c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/dlg,da9211.yaml
> @@ -0,0 +1,104 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/dlg,da9211.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title:
> + Dialog Semiconductor DA9211/DA9212/DA9213/DA9223/DA9214/DA9224/DA9215/DA9225
> + Voltage Regulator
Dialog Semiconductor DA9211-9215, DA9223-9225 Voltage Regulators
Better? :-)
> +
> +maintainers:
> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> +
> +properties:
> + compatible:
> + enum:
> + - dlg,da9211
> + - dlg,da9212
> + - dlg,da9213
> + - dlg,da9214
> + - dlg,da9215
> + - dlg,da9223
> + - dlg,da9224
> + - dlg,da9225
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + regulators:
> + type: object
> + additionalProperties: false
> + description:
> + List of regulators provided by the device
> +
> + patternProperties:
> + "^BUCK([AB])$":
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> + description: |
Please drop the vertical bar | from all descriptions
after which,
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> + Properties for a single BUCK regulator
> +
> + properties:
> + regulator-initial-mode:
> + items:
> + enum: [ 1, 2, 3 ]
> + description: |
> + Defined in include/dt-bindings/regulator/dlg,da9211-regulator.h
> +
> + regulator-allowed-modes:
> + items:
> + enum: [ 1, 2, 3 ]
> + description: |
> + Defined in include/dt-bindings/regulator/dlg,da9211-regulator.h
> +
> + enable-gpios:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - regulators
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/regulator/dlg,da9211-regulator.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + regulator@68 {
> + compatible = "dlg,da9212";
> + reg = <0x68>;
> + interrupts = <3 27>;
> +
> + regulators {
> + BUCKA {
> + regulator-name = "VBUCKA";
> + regulator-min-microvolt = < 300000>;
> + regulator-max-microvolt = <1570000>;
> + regulator-min-microamp = <2000000>;
> + regulator-max-microamp = <5000000>;
> + enable-gpios = <&gpio 27 0>;
> + };
> + BUCKB {
> + regulator-name = "VBUCKB";
> + regulator-min-microvolt = < 300000>;
> + regulator-max-microvolt = <1570000>;
> + regulator-min-microamp = <2000000>;
> + regulator-max-microamp = <5000000>;
> + enable-gpios = <&gpio 17 0>;
> + };
> + };
> + };
> + };
> +
> +...
^ permalink raw reply
* Re: [PATCH v2 07/12] arm64: dts: mediatek: mt8173: Fix mt8173-pinctrl node names
From: AngeloGioacchino Del Regno @ 2025-09-12 8:11 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-8-ariel.dalessandro@collabora.com>
Il 11/09/25 17:09, Ariel D'Alessandro ha scritto:
> According to the mediatek,mt8173-pinctrl device tree binding schema, the
> pinctrl node names should match pattern 'pins$'. Fix this.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 01/12] dt-bindings: media: Convert MediaTek mt8173-mdp bindings to DT schema
From: AngeloGioacchino Del Regno @ 2025-09-12 8:11 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-2-ariel.dalessandro@collabora.com>
Il 11/09/25 17:09, Ariel D'Alessandro ha scritto:
> Convert the existing text-based DT bindings for MediaTek MT8173 Media Data
> Path to a DT schema.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../bindings/media/mediatek,mt8173-mdp.yaml | 169 ++++++++++++++++++
> .../bindings/media/mediatek-mdp.txt | 95 ----------
> 2 files changed, 169 insertions(+), 95 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
> delete mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
> new file mode 100644
> index 0000000000000..8ca33a733c478
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-mdp.yaml
> @@ -0,0 +1,169 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/mediatek,mt8173-mdp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT8173 Media Data Path
> +
> +maintainers:
> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> +
> +description:
> + Media Data Path is used for scaling and color space conversion.
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - mediatek,mt8173-mdp-rdma
> + - mediatek,mt8173-mdp-rsz
> + - mediatek,mt8173-mdp-wdma
> + - mediatek,mt8173-mdp-wrot
> + - items:
> + - const: mediatek,mt8173-mdp-rdma
> + - const: mediatek,mt8173-mdp
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + minItems: 1
> + maxItems: 2
> +
> + power-domains:
> + maxItems: 1
> +
> + iommus:
> + maxItems: 1
> +
> + mediatek,vpu:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + phandle to Mediatek Video Processor Unit for HW Codec encode/decode and
> + image processing.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - power-domains
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: mediatek,mt8173-mdp-rdma
> + then:
> + properties:
> + clocks:
> + items:
> + - description: Main clock
> + - description: Mutex clock
> + else:
> + properties:
> + clocks:
> + items:
> + - description: Main clock
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - mediatek,mt8173-mdp-rdma
> + - mediatek,mt8173-mdp-wdma
> + - mediatek,mt8173-mdp-wrot
> + then:
> + required:
> + - iommus
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: mediatek,mt8173-mdp
> + then:
> + required:
> + - mediatek,vpu
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8173-clk.h>
> + #include <dt-bindings/memory/mt8173-larb-port.h>
> + #include <dt-bindings/power/mt8173-power.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + mdp_rdma0: rdma@14001000 {
> + compatible = "mediatek,mt8173-mdp-rdma",
> + "mediatek,mt8173-mdp";
> + reg = <0 0x14001000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> + <&mmsys CLK_MM_MUTEX_32K>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> + mediatek,vpu = <&vpu>;
> + };
> +
> + mdp_rdma1: rdma@14002000 {
> + compatible = "mediatek,mt8173-mdp-rdma";
> + reg = <0 0x14002000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RDMA1>,
> + <&mmsys CLK_MM_MUTEX_32K>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + iommus = <&iommu M4U_PORT_MDP_RDMA1>;
> + };
> +
> + mdp_rsz0: rsz@14003000 {
> + compatible = "mediatek,mt8173-mdp-rsz";
> + reg = <0 0x14003000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RSZ0>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + };
> +
> + mdp_rsz1: rsz@14004000 {
> + compatible = "mediatek,mt8173-mdp-rsz";
> + reg = <0 0x14004000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RSZ1>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + };
> +
> + mdp_rsz2: rsz@14005000 {
> + compatible = "mediatek,mt8173-mdp-rsz";
> + reg = <0 0x14005000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_RSZ2>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + };
> +
> + mdp_wdma0: wdma@14006000 {
> + compatible = "mediatek,mt8173-mdp-wdma";
> + reg = <0 0x14006000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_WDMA>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + iommus = <&iommu M4U_PORT_MDP_WDMA>;
> + };
> +
> + mdp_wrot0: wrot@14007000 {
> + compatible = "mediatek,mt8173-mdp-wrot";
> + reg = <0 0x14007000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_WROT0>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + iommus = <&iommu M4U_PORT_MDP_WROT0>;
> + };
> +
> + mdp_wrot1: wrot@14008000 {
> + compatible = "mediatek,mt8173-mdp-wrot";
> + reg = <0 0x14008000 0 0x1000>;
> + clocks = <&mmsys CLK_MM_MDP_WROT1>;
> + power-domains = <&spm MT8173_POWER_DOMAIN_MM>;
> + iommus = <&iommu M4U_PORT_MDP_WROT1>;
> + };
> + };
> +
> +...
^ permalink raw reply
* Re: [PATCH v2 02/12] dt-bindings: media: Convert MediaTek mt8173-vpu bindings to DT schema
From: AngeloGioacchino Del Regno @ 2025-09-12 8:11 UTC (permalink / raw)
To: Ariel D'Alessandro, airlied, amergnat, andrew+netdev,
andrew-ct.chen, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
robh, sean.wang, simona, support.opensource, tiffany.lin,
tzimmermann, yunfei.dong
Cc: devicetree, dri-devel, linux-arm-kernel, linux-bluetooth,
linux-gpio, linux-input, linux-kernel, linux-media,
linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <20250911151001.108744-3-ariel.dalessandro@collabora.com>
Il 11/09/25 17:09, Ariel D'Alessandro ha scritto:
> Convert the existing text-based DT bindings for Mediatek MT8173 Video
> Processor Unit to a DT schema.
>
> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../bindings/media/mediatek,mt8173-vpu.yaml | 74 +++++++++++++++++++
> .../bindings/media/mediatek-vpu.txt | 31 --------
> 2 files changed, 74 insertions(+), 31 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
> delete mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
> new file mode 100644
> index 0000000000000..8a47761f1e6b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8173-vpu.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/mediatek,mt8173-vpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek MT8173 Video Processor Unit
> +
> +maintainers:
> + - Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> +
> +description:
> + Video Processor Unit is a HW video controller. It controls HW Codec including
> + H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color
> + convert).
> +
> +properties:
> + compatible:
> + const: mediatek,mt8173-vpu
> +
> + reg:
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: tcm
> + - const: cfg_reg
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + items:
> + - const: main
> +
> + memory-region:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - clocks
> + - clock-names
> + - memory-region
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/mt8173-clk.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + vpu: vpu@10020000 {
> + compatible = "mediatek,mt8173-vpu";
> + reg = <0 0x10020000 0 0x30000>,
> + <0 0x10050000 0 0x100>;
> + reg-names = "tcm", "cfg_reg";
> + interrupts = <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&topckgen CLK_TOP_SCP_SEL>;
> + clock-names = "main";
> + memory-region = <&vpu_dma_reserved>;
> + };
> + };
> +
> +...
^ permalink raw reply
* Re: [PATCH v14 04/10] pwm: max7360: Add MAX7360 PWM support
From: Mathieu Dubois-Briand @ 2025-09-12 6:23 UTC (permalink / raw)
To: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kamel Bouhara, Linus Walleij, Bartosz Golaszewski,
Dmitry Torokhov, Uwe Kleine-König, Michael Walle, Mark Brown,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich
Cc: devicetree, linux-kernel, linux-gpio, linux-input, linux-pwm,
andriy.shevchenko, Grégory Clement, Thomas Petazzoni,
Andy Shevchenko
In-Reply-To: <20250824-mdb-max7360-support-v14-4-435cfda2b1ea@bootlin.com>
On Sun Aug 24, 2025 at 1:57 PM CEST, Mathieu Dubois-Briand wrote:
> From: Kamel Bouhara <kamel.bouhara@bootlin.com>
>
> Add driver for Maxim Integrated MAX7360 PWM controller, supporting up to
> 8 independent PWM outputs.
>
> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
> Co-developed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/pwm/Kconfig | 10 +++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-max7360.c | 209 ++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 220 insertions(+)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index f00ce973dddf..f2b1ce47de7f 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -432,6 +432,16 @@ config PWM_LPSS_PLATFORM
> To compile this driver as a module, choose M here: the module
> will be called pwm-lpss-platform.
>
> +config PWM_MAX7360
> + tristate "MAX7360 PWMs"
> + depends on MFD_MAX7360
> + help
> + PWM driver for Maxim Integrated MAX7360 multifunction device, with
> + support for up to 8 PWM outputs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-max7360.
> +
> config PWM_MC33XS2410
> tristate "MC33XS2410 PWM support"
> depends on OF
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index ff4f47e5fb7a..dfa8b4966ee1 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_LPC32XX) += pwm-lpc32xx.o
> obj-$(CONFIG_PWM_LPSS) += pwm-lpss.o
> obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
> obj-$(CONFIG_PWM_LPSS_PLATFORM) += pwm-lpss-platform.o
> +obj-$(CONFIG_PWM_MAX7360) += pwm-max7360.o
> obj-$(CONFIG_PWM_MC33XS2410) += pwm-mc33xs2410.o
> obj-$(CONFIG_PWM_MEDIATEK) += pwm-mediatek.o
> obj-$(CONFIG_PWM_MESON) += pwm-meson.o
> diff --git a/drivers/pwm/pwm-max7360.c b/drivers/pwm/pwm-max7360.c
> new file mode 100644
> index 000000000000..ebf93a7aee5b
> --- /dev/null
> +++ b/drivers/pwm/pwm-max7360.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2025 Bootlin
> + *
> + * Author: Kamel BOUHARA <kamel.bouhara@bootlin.com>
> + * Author: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
> + *
> + * PWM functionality of the MAX7360 multi-function device.
> + * https://www.analog.com/media/en/technical-documentation/data-sheets/MAX7360.pdf
> + *
> + * Limitations:
> + * - Only supports normal polarity.
> + * - The period is fixed to 2 ms.
> + * - Only the duty cycle can be changed, new values are applied at the beginning
> + * of the next cycle.
> + * - When disabled, the output is put in Hi-Z immediately.
> + */
> +#include <linux/bits.h>
> +#include <linux/dev_printk.h>
> +#include <linux/err.h>
> +#include <linux/math64.h>
> +#include <linux/mfd/max7360.h>
> +#include <linux/minmax.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pwm.h>
> +#include <linux/regmap.h>
> +#include <linux/time.h>
> +#include <linux/types.h>
> +
> +#define MAX7360_NUM_PWMS 8
> +#define MAX7360_PWM_MAX 255
> +#define MAX7360_PWM_STEPS 256
> +#define MAX7360_PWM_PERIOD_NS (2 * NSEC_PER_MSEC)
> +
> +struct max7360_pwm_waveform {
> + u8 duty_steps;
> + bool enabled;
> +};
> +
> +static int max7360_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> +{
> + struct regmap *regmap = pwmchip_get_drvdata(chip);
> +
> + /*
> + * Make sure we use the individual PWM configuration register and not
> + * the global one.
> + * We never need to use the global one, so there is no need to revert
> + * that in the .free() callback.
> + */
> + return regmap_write_bits(regmap, MAX7360_REG_PWMCFG(pwm->hwpwm),
> + MAX7360_PORT_CFG_COMMON_PWM, 0);
> +}
> +
> +static int max7360_pwm_round_waveform_tohw(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + const struct pwm_waveform *wf,
> + void *_wfhw)
> +{
> + struct max7360_pwm_waveform *wfhw = _wfhw;
> + u64 duty_steps;
> +
> + /*
> + * Ignore user provided values for period_length_ns and duty_offset_ns:
> + * we only support fixed period of MAX7360_PWM_PERIOD_NS and offset of 0.
> + * Values from 0 to 254 as duty_steps will provide duty cycles of 0/256
> + * to 254/256, while value 255 will provide a duty cycle of 100%.
> + */
> + if (wf->duty_length_ns >= MAX7360_PWM_PERIOD_NS) {
> + duty_steps = MAX7360_PWM_MAX;
> + } else {
> + duty_steps = (u32)wf->duty_length_ns * MAX7360_PWM_STEPS / MAX7360_PWM_PERIOD_NS;
> + if (duty_steps == MAX7360_PWM_MAX)
> + duty_steps = MAX7360_PWM_MAX - 1;
> + }
> +
> + wfhw->duty_steps = min(MAX7360_PWM_MAX, duty_steps);
> + wfhw->enabled = !!wf->period_length_ns;
> +
> + if (wf->period_length_ns && wf->period_length_ns < MAX7360_PWM_PERIOD_NS)
> + return 1;
> + else
> + return 0;
> +}
> +
> +static int max7360_pwm_round_waveform_fromhw(struct pwm_chip *chip, struct pwm_device *pwm,
> + const void *_wfhw, struct pwm_waveform *wf)
> +{
> + const struct max7360_pwm_waveform *wfhw = _wfhw;
> +
> + wf->period_length_ns = wfhw->enabled ? MAX7360_PWM_PERIOD_NS : 0;
> + wf->duty_offset_ns = 0;
> +
> + if (wfhw->enabled) {
> + if (wfhw->duty_steps == MAX7360_PWM_MAX)
> + wf->duty_length_ns = MAX7360_PWM_PERIOD_NS;
> + else
> + wf->duty_length_ns = DIV_ROUND_UP(wfhw->duty_steps * MAX7360_PWM_PERIOD_NS,
> + MAX7360_PWM_STEPS);
> + } else {
> + wf->duty_length_ns = 0;
> + }
> +
> + return 0;
> +}
> +
> +static int max7360_pwm_write_waveform(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + const void *_wfhw)
> +{
> + struct regmap *regmap = pwmchip_get_drvdata(chip);
> + const struct max7360_pwm_waveform *wfhw = _wfhw;
> + unsigned int val;
> + int ret;
> +
> + if (wfhw->enabled) {
> + ret = regmap_write(regmap, MAX7360_REG_PWM(pwm->hwpwm), wfhw->duty_steps);
> + if (ret)
> + return ret;
> + }
> +
> + val = wfhw->enabled ? BIT(pwm->hwpwm) : 0;
> + return regmap_write_bits(regmap, MAX7360_REG_GPIOCTRL, BIT(pwm->hwpwm), val);
> +}
> +
> +static int max7360_pwm_read_waveform(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + void *_wfhw)
> +{
> + struct regmap *regmap = pwmchip_get_drvdata(chip);
> + struct max7360_pwm_waveform *wfhw = _wfhw;
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(regmap, MAX7360_REG_GPIOCTRL, &val);
> + if (ret)
> + return ret;
> +
> + if (val & BIT(pwm->hwpwm)) {
> + wfhw->enabled = true;
> + ret = regmap_read(regmap, MAX7360_REG_PWM(pwm->hwpwm), &val);
> + if (ret)
> + return ret;
> +
> + wfhw->duty_steps = val;
> + } else {
> + wfhw->enabled = false;
> + wfhw->duty_steps = 0;
> + }
> +
> + return 0;
> +}
> +
> +static const struct pwm_ops max7360_pwm_ops = {
> + .request = max7360_pwm_request,
> + .round_waveform_tohw = max7360_pwm_round_waveform_tohw,
> + .round_waveform_fromhw = max7360_pwm_round_waveform_fromhw,
> + .read_waveform = max7360_pwm_read_waveform,
> + .write_waveform = max7360_pwm_write_waveform,
> +};
> +
> +static int max7360_pwm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct pwm_chip *chip;
> + struct regmap *regmap;
> + int ret;
> +
> + regmap = dev_get_regmap(dev->parent, NULL);
> + if (!regmap)
> + return dev_err_probe(dev, -ENODEV, "Could not get parent regmap\n");
> +
> + /*
> + * This MFD sub-device does not have any associated device tree node:
> + * properties are stored in the device node of the parent (MFD) device
> + * and this same node is used in phandles of client devices.
> + * Reuse this device tree node here, as otherwise the PWM subsystem
> + * would be confused by this topology.
> + */
> + device_set_of_node_from_dev(dev, dev->parent);
> +
> + chip = devm_pwmchip_alloc(dev, MAX7360_NUM_PWMS, 0);
> + if (IS_ERR(chip))
> + return PTR_ERR(chip);
> + chip->ops = &max7360_pwm_ops;
> +
> + pwmchip_set_drvdata(chip, regmap);
> +
> + ret = devm_pwmchip_add(dev, chip);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to add PWM chip\n");
> +
> + return 0;
> +}
> +
> +static struct platform_driver max7360_pwm_driver = {
> + .driver = {
> + .name = "max7360-pwm",
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> + },
> + .probe = max7360_pwm_probe,
> +};
> +module_platform_driver(max7360_pwm_driver);
> +
> +MODULE_DESCRIPTION("MAX7360 PWM driver");
> +MODULE_AUTHOR("Kamel BOUHARA <kamel.bouhara@bootlin.com>");
> +MODULE_AUTHOR("Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>");
> +MODULE_LICENSE("GPL");
Hi Uwe,
Any thought about this new version? I believe I fixed all the points we
have been discussing previously.
Thanks,
Mathieu
--
Mathieu Dubois-Briand, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.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