* Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Krzysztof Kozlowski @ 2026-04-16 12:30 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Julia Lawall, Nicolas Palix
In-Reply-To: <20260310-b4-is_err_or_null-v1-1-bd63b656022d@avm.de>
On 10/03/2026 12:48, Philipp Hahn wrote:
> Find and convert uses of IS_ERR() plus NULL check to IS_ERR_OR_NULL().
>
> There are several cases where `!ptr && WARN_ON[_ONCE](IS_ERR(ptr))` is
> used:
> - arch/x86/kernel/callthunks.c:215 WARN_ON_ONCE
> - drivers/clk/clk.c:4561 WARN_ON_ONCE
> - drivers/interconnect/core.c:793 WARN_ON
> - drivers/reset/core.c:718 WARN_ON
> The change is not 100% semantical equivalent as the warning will now
> also happen when the pointer is NULL.
>
> To: Julia Lawall <Julia.Lawall@inria.fr>
> To: Nicolas Palix <nicolas.palix@imag.fr>
> Cc: cocci@inria.fr
> Cc: linux-kernel@vger.kernel.org
>
> ---
> drivers/clocksource/mips-gic-timer.c:283 looks suspicious: ret != clk,
> but Daniel Lezcano verified it as cottect.
>
> There are some cases where the checks are part of a larger expression:
> - mm/kmemleak.c:1095
> - mm/kmemleak.c:1155
> - mm/kmemleak.c:1173
> - mm/kmemleak.c:1290
> - mm/kmemleak.c:1328
> - mm/kmemleak.c:1241
> - mm/kmemleak.c:1310
> - mm/kmemleak.c:1258
> - net/netlink/af_netlink.c:2670
> Thanks to Julia Lawall for the help to also handle them.
>
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> scripts/coccinelle/api/is_err_or_null.cocci | 125 ++++++++++++++++++++++++++++
> 1 file changed, 125 insertions(+)
>
Neither this, nor try from 2011, nor any future try should be accepted,
because it creates impression IS_ERR_OR_NULL is somehow okay. No, it is
not okay, it is a discouraged pattern leading to less readable and
maintainable code. We should not have therefore any tools suggesting
usage of IS_ERR_OR_NULL, because people will be converting poor code
into that, instead of fixing that poor code.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 55/61] interconnect: Prefer IS_ERR_OR_NULL over manual NULL check
From: Krzysztof Kozlowski @ 2026-04-16 12:24 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Georgi Djakov
In-Reply-To: <20260310-b4-is_err_or_null-v1-55-bd63b656022d@avm.de>
On 10/03/2026 12:49, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Semantich change: Previously the code only printed the warning on error,
> but not when the pointer was NULL. Now the warning is printed in both
> cases!
NAK, read the code
>
> Change found with coccinelle.
>
> To: Georgi Djakov <djakov@kernel.org>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/interconnect/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 8569b78a18517b33abeafac091978b25cbc1acc7..22e92b30f73853d5bd2e05b4f52cb5aa22556468 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -790,7 +790,7 @@ void icc_put(struct icc_path *path)
> size_t i;
> int ret;
>
> - if (!path || WARN_ON(IS_ERR(path)))
> + if (WARN_ON(IS_ERR_OR_NULL(path)))
IS_ERR_OR_NULL is simply discouraged, but beside of code preference, you
just added bug here. This is clearly not equivalent and you emit warn on
perfectly valid case!
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] fbdev: omapfb: fix reference leak on failed device registration
From: Guangshuo Li @ 2026-04-15 19:17 UTC (permalink / raw)
To: Helge Deller, Thomas Zimmermann, Kees Cook, Guangshuo Li,
Dan Carpenter, Tomi Valkeinen, linux-fbdev, linux-omap, dri-devel,
linux-kernel
Cc: stable
When platform_device_register() fails in omapfb_probe(), the embedded
struct device in omapdss_device has already been initialized by
device_initialize(), but the failure path only reports the error and
returns without dropping the device reference for the current platform
device:
omapfb_probe()
-> platform_device_register(&omapdss_device)
-> device_initialize(&omapdss_device.dev)
-> setup_pdev_dma_masks(&omapdss_device)
-> platform_device_add(&omapdss_device)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: f778a12dd3320 ("OMAP: OMAPFB: fix clk_get for RFBI")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/video/fbdev/omap/omapfb_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap/omapfb_main.c b/drivers/video/fbdev/omap/omapfb_main.c
index cafe859d6e5a..0d47a8aec5c5 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -1768,6 +1768,7 @@ static int omapfb_probe(struct platform_device *pdev)
r = platform_device_register(&omapdss_device);
if (r) {
dev_err(&pdev->dev, "can't register omapdss device\n");
+ platform_device_put(&omapdss_device);
return r;
}
--
2.43.0
^ permalink raw reply related
* [PATCH] USB: omap_udc: DMA: Don't enable burst 4 mode
From: Aaro Koskinen @ 2026-04-13 18:49 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-usb; +Cc: linux-omap, linux-kernel, Tony Lindgren
Commit 65111084c63d7 ("USB: more omap_udc updates (dma and omap1710)")
added setting for DMA burst 4 mode. But I think this should be undone for
two reasons:
- It breaks DMA on 15xx boards - transfers just silently stall.
- On newer OMAP1 boards, like Nokia 770 (omap1710), there is no measurable
performance impact when testing TCP throughput with g_ether with large
15000 byte MTU size.
It's also worth noting that when the original change was made, the
OMAP_DMA_DATA_BURST_4 handling in arch/arm/plat-omap/dma.c was broken, and
actually resulted in the same as the OMAP_DMA_DATA_BURST_DIS i.e. burst
disabled. This was fixed not until a couple kernel releases later in an
unrelated commit 1a8bfa1eb998a ("[ARM] 3142/1: OMAP 2/5: Update files
common to omap1 and omap2").
So based on this it seems there was never really a very good reason to
enable this burst mode in omap_udc, so remove it now to allow 15xx DMA
to work again (it provides 2x throughput compared to PIO mode).
Fixes: 65111084c63d7 ("USB: more omap_udc updates (dma and omap1710)")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
drivers/usb/gadget/udc/omap_udc.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/omap_udc.c b/drivers/usb/gadget/udc/omap_udc.c
index 91139ae668f4..f3ca79cece1b 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -733,8 +733,6 @@ static void dma_channel_claim(struct omap_ep *ep, unsigned channel)
if (status == 0) {
omap_writew(reg, UDC_TXDMA_CFG);
/* EMIFF or SDRC */
- omap_set_dma_src_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
omap_set_dma_src_data_pack(ep->lch, 1);
/* TIPB */
omap_set_dma_dest_params(ep->lch,
@@ -756,8 +754,6 @@ static void dma_channel_claim(struct omap_ep *ep, unsigned channel)
UDC_DATA_DMA,
0, 0);
/* EMIFF or SDRC */
- omap_set_dma_dest_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
omap_set_dma_dest_data_pack(ep->lch, 1);
}
}
--
2.39.2
^ permalink raw reply related
* Re: [PATCH 04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
From: Theodore Ts'o @ 2026-04-10 15:18 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Theodore Ts'o, Andreas Dilger
In-Reply-To: <20260310-b4-is_err_or_null-v1-4-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:48:30 +0100, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
Applied, thanks!
[04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
commit: 1d749e110277ce4103f27bd60d6181e52c0cc1e3
Best regards,
--
Theodore Ts'o <tytso@mit.edu>
^ permalink raw reply
* Re: [PATCH 00/61] treewide: Use IS_ERR_OR_NULL over manual NULL check - refactor
From: Al Viro @ 2026-04-09 18:16 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Julia Lawall, Nicolas Palix, Chris Mason,
David Sterba, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko,
Theodore Ts'o, Andreas Dilger, Steve French, Paulo Alcantara,
Ronnie Sahlberg, Shyam Prasad N, Tom Talpey, Bharath SM,
Eric Van Hensbergen, Latchesar Ionkov, Dominique Martinet,
Christian Schoenebeck, Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu,
Sandeep Dhavale, Hongbo Li, Chunhai Guo, Miklos Szeredi,
Konstantin Komarov, Andreas Gruenbacher, Kees Cook, Tony Luck,
Guilherme G. Piccoli, Jan Kara, Phillip Lougher,
Christian Brauner, Jan Kara, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Tejun Heo, David Vernet, Andrea Righi,
Changwoo Min, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Ben Segall, Mel Gorman,
Valentin Schneider, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Sylwester Nawrocki, Liam Girdwood,
Mark Brown, Jaroslav Kysela, Takashi Iwai, Max Filippov,
Paolo Bonzini, John Johansen, Paul Moore, James Morris,
Serge E. Hallyn, Andrew Morton, Alasdair Kergon, Mike Snitzer,
Mikulas Patocka, Benjamin Marzinski, David S. Miller, David Ahern,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Jamal Hadi Salim, Jiri Pirko,
Marcelo Ricardo Leitner, Xin Long, Trond Myklebust,
Anna Schumaker, Chuck Lever, Jeff Layton, NeilBrown,
Olga Kornievskaia, Dai Ngo, Jon Maloy, Johannes Berg,
Catalin Marinas, Russell King, John Crispin, Thomas Bogendoerfer,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Zhenyu Wang,
Zhi Wang, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Alex Deucher, Christian König, Sandy Huang,
Heiko Stübner, Andy Yan, Igor Russkikh, Andrew Lunn,
Pavan Chebbi, Michael Chan, Potnuri Bharat Teja, Tony Nguyen,
Przemek Kitszel, Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Vinod Koul, Linus Walleij, Ulf Hansson,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Martin K. Petersen,
Eduardo Valentin, Keerthy, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Alex Williamson, Mark Greer,
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab, Joerg Roedel,
Will Deacon, Robin Murphy, Lee Jones, Pavel Machek, Dave Penkler,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Justin Sanders, Jens Axboe, Georgi Djakov, Michael Turquette,
Stephen Boyd, Philipp Zabel, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Pali Rohár, Dmitry Torokhov
In-Reply-To: <20260310-b4-is_err_or_null-v1-0-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:48:26PM +0100, Philipp Hahn wrote:
> While doing some static code analysis I stumbled over a common pattern,
> where IS_ERR() is combined with a NULL check. For that there is
> IS_ERR_OR_NULL().
... and valid uses of IS_ERR_OR_NULL are rare as hen teeth.
Most of those are "I'm not sure how this function returns an
error, let's use that just in case".
Please, do not introduce more of that crap.
^ permalink raw reply
* [PATCH] usb: musb: omap2430: Fix use-after-free in omap2430_probe()
From: Wentao Liang @ 2026-04-09 10:11 UTC (permalink / raw)
To: b-liu, gregkh; +Cc: linux-usb, linux-omap, linux-kernel, Wentao Liang, stable
In omap2430_probe(), of_node_put(np) is called prematurely before the
last access to np, leading to a use-after-free if the node's reference
count drops to zero. Move the of_node_put() calls after the last use of
np in both the success and error paths.
Fixes: ffbe2feac59b ("usb: musb: omap2430: Fix probe regression for missing resources")
Cc: stable@vger.kernel.org
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/usb/musb/omap2430.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 48bb9bfb2204..333ab79f0ca9 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -337,7 +337,6 @@ static int omap2430_probe(struct platform_device *pdev)
} else {
device_set_of_node_from_dev(&musb->dev, &pdev->dev);
}
- of_node_put(np);
glue->dev = &pdev->dev;
glue->musb = musb;
@@ -455,6 +454,7 @@ static int omap2430_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to register musb device\n");
goto err_disable_rpm;
}
+ of_node_put(np);
return 0;
@@ -464,6 +464,7 @@ static int omap2430_probe(struct platform_device *pdev)
if (!IS_ERR(glue->control_otghs))
put_device(glue->control_otghs);
err_put_musb:
+ of_node_put(np);
platform_device_put(musb);
return ret;
--
2.34.1
^ permalink raw reply related
* 回复: Re: [PATCH] fbdev: omap2: fix inconsistent lock returns in omapfb_mmap
From: 曾红玲 @ 2026-04-09 9:33 UTC (permalink / raw)
To: linux-omap, linux-fbdev, dri-devel, Helge Deller
Cc: linux-kernel, zhongling0719, kernel test robot
[-- Attachment #1: Type: text/html, Size: 2312 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Utilize pinctrl-single for bcm7038-style chips
From: Linus Walleij @ 2026-04-09 8:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tony Lindgren, Haojian Zhuang, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
On Wed, Apr 8, 2026 at 1:56 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> This patch set allows Broadcom STB chips with the BCM7038-style
> pinmux/configuration blocks to use pinctrl-single. This does not
> preclude us from making use of a more sophisticated driver in the
> future, should we need to.
Patches applied for v7.1!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/2] Utilize pinctrl-single for bcm7038-style chips
From: Linus Walleij @ 2026-04-09 8:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tony Lindgren, Haojian Zhuang, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
On Wed, Apr 8, 2026 at 1:56 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> This patch set allows Broadcom STB chips with the BCM7038-style
> pinmux/configuration blocks to use pinctrl-single. This does not
> preclude us from making use of a more sophisticated driver in the
> future, should we need to.
OK that's one way to do it. I wonder if this approach also works for
BCMBCA given Haojian's comments on my previous patch attempts.
drivers/pinctrl/bcm/pinctrl-bcm4908.c would then be phased over
to pinctrl-single, or does the MSB/LSB register layout create a
problem? If we always write 0 into MSB I guess we could just add
some quirk...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] fbdev: omap2: fix inconsistent lock returns in omapfb_mmap
From: Helge Deller @ 2026-04-09 8:29 UTC (permalink / raw)
To: zenghongling, linux-omap, linux-fbdev, dri-devel
Cc: linux-kernel, zhongling0719, kernel test robot
In-Reply-To: <20260402093403.12173-1-zenghongling@kylinos.cn>
On 4/2/26 11:34, zenghongling wrote:
> Fix the warning about inconsistent returns for '&rg->lock' in
> omapfb_mmap() function. The warning arises because the error path
> uses 'ofbi->region' while the normal path uses 'rg'.
>
> smatch warnings:
> drivers/video/fbdev/omap2/omapfb/omapfb-main.c:1126 omapfb_mmap()
> warn: inconsistent returns '&rg->lock'.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: zenghongling <zenghongling@kylinos.cn>
> ---
> drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
PS: I replaced author/email name by "Hongling Zeng" instead of "zenghongling".
I assume that's Ok, if not please let me know.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Thomas Richard @ 2026-04-08 13:01 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <20260408124109.GB1864812-robh@kernel.org>
On 4/8/26 2:41 PM, Rob Herring wrote:
> On Wed, Apr 08, 2026 at 09:58:15AM +0200, Thomas Richard wrote:
>> Hello Krzysztof,
>>
>> On 3/31/26 10:22 AM, Krzysztof Kozlowski wrote:
>>> On Mon, Mar 30, 2026 at 03:43:59PM +0200, Thomas Richard wrote:
>>>> Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
>>>> supply and allows to unlock USB I/O cell.
>>>>
>>>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>>>> ---
>>>> Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> index 3e020d87701b..908fbb46b5cf 100644
>>>> --- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>>>> @@ -89,6 +89,7 @@ allOf:
>>>> contains:
>>>> enum:
>>>> - pbias_mmc_omap4
>>>> + - pbias_sim_omap4
>>>
>>> Names cannot be fixed, because they represent different board naming.
>>> Why growing the deprecated style?
>>
>> Okay, so I'll drop all if statements, add a regex which matches
>> regulator names and fix the regulator name in the driver.
>
> If a driver depends on the names, you can't change them.
>
I mean the new regulator I add with this series. At this time it does
not exist yet in the driver.
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH v2 08/11] dt-bindings: mfd: ti,omap-usb-host: Convert to DT schema
From: Rob Herring @ 2026-04-08 12:55 UTC (permalink / raw)
To: Thomas Richard
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Thomas Petazzoni, linux-omap,
linux-kernel, devicetree
In-Reply-To: <20260330-omap4-fix-usb-support-v2-8-1c1e11b190dc@bootlin.com>
On Mon, Mar 30, 2026 at 03:44:05PM +0200, Thomas Richard wrote:
> Convert OMAP HS USB Host binding to DT schema. The 'ti,hwmods' property is
> not mandatory anymore as it is no longer required when the omap-usb-host
> node is a child of a new interconnect target (ti,sysc).
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> .../devicetree/bindings/mfd/omap-usb-host.txt | 103 -------------
> .../devicetree/bindings/mfd/ti,omap-usb-host.yaml | 161 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 3 files changed, 162 insertions(+), 103 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> deleted file mode 100644
> index a0d8c30c2631..000000000000
> --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
> +++ /dev/null
> @@ -1,103 +0,0 @@
> -OMAP HS USB Host
> -
> -Required properties:
> -
> -- compatible: should be "ti,usbhs-host"
> -- reg: should contain one register range i.e. start and length
> -- ti,hwmods: must contain "usb_host_hs"
> -
> -Optional properties:
> -
> -- num-ports: number of USB ports. Usually this is automatically detected
> - from the IP's revision register but can be overridden by specifying
> - this property. A maximum of 3 ports are supported at the moment.
> -
> -- portN-mode: String specifying the port mode for port N, where N can be
> - from 1 to 3. If the port mode is not specified, that port is treated
> - as unused. When specified, it must be one of the following.
> - "ehci-phy",
> - "ehci-tll",
> - "ehci-hsic",
> - "ohci-phy-6pin-datse0",
> - "ohci-phy-6pin-dpdm",
> - "ohci-phy-3pin-datse0",
> - "ohci-phy-4pin-dpdm",
> - "ohci-tll-6pin-datse0",
> - "ohci-tll-6pin-dpdm",
> - "ohci-tll-3pin-datse0",
> - "ohci-tll-4pin-dpdm",
> - "ohci-tll-2pin-datse0",
> - "ohci-tll-2pin-dpdm",
> -
> -- single-ulpi-bypass: Must be present if the controller contains a single
> - ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
> -
> -- clocks: a list of phandles and clock-specifier pairs, one for each entry in
> - clock-names.
> -
> -- clock-names: should include:
> - For OMAP3
> - * "usbhost_120m_fck" - 120MHz Functional clock.
> -
> - For OMAP4+
> - * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
> - * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
> - * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
> - * "utmi_p1_gfclk" - Port 1 UTMI clock mux.
> - * "utmi_p2_gfclk" - Port 2 UTMI clock mux.
> - * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
> - * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
> - * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
> - * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
> - * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
> -
> -Required properties if child node exists:
> -
> -- #address-cells: Must be 1
> -- #size-cells: Must be 1
> -- ranges: must be present
> -
> -Properties for children:
> -
> -The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
> -See Documentation/devicetree/bindings/usb/generic-ehci.yaml and
> -Documentation/devicetree/bindings/usb/generic-ohci.yaml.
> -
> -Example for OMAP4:
> -
> -usbhshost: usbhshost@4a064000 {
> - compatible = "ti,usbhs-host";
> - reg = <0x4a064000 0x800>;
> - ti,hwmods = "usb_host_hs";
> - #address-cells = <1>;
> - #size-cells = <1>;
> - ranges;
> -
> - usbhsohci: ohci@4a064800 {
> - compatible = "ti,ohci-omap3";
> - reg = <0x4a064800 0x400>;
> - interrupt-parent = <&gic>;
> - interrupts = <0 76 0x4>;
> - };
> -
> - usbhsehci: ehci@4a064c00 {
> - compatible = "ti,ehci-omap";
> - reg = <0x4a064c00 0x400>;
> - interrupt-parent = <&gic>;
> - interrupts = <0 77 0x4>;
> - };
> -};
> -
> -&usbhshost {
> - port1-mode = "ehci-phy";
> - port2-mode = "ehci-tll";
> - port3-mode = "ehci-phy";
> -};
> -
> -&usbhsehci {
> - phys = <&hsusb1_phy 0 &hsusb3_phy>;
> -};
> diff --git a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> new file mode 100644
> index 000000000000..3b5b041f0321
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> @@ -0,0 +1,161 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/ti,omap-usb-host.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OMAP HS USB Host
> +
> +maintainers:
> + - Thomas Richard <thomas.richard@bootlin.com>
> +
> +properties:
> + compatible:
> + const: ti,usbhs-host
> +
> + reg:
> + maxItems: 1
> +
> + ti,hwmods:
> + const: usb_host_hs
> +
> + num-ports:
> + description:
> + number of USB ports. Usually this is automatically detected from the IP's
> + revision register but can be overridden by specifying this property. A
> + maximum of 3 ports are supported at the moment.
> + maximum: 3
> +
> + single-ulpi-bypass:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + Must be present if the controller contains a single ULPI bypass control
> + bit. e.g. OMAP3 silicon <= ES2.1ULPI bypass control bit.
> + e.g. OMAP3 silicon <= ES2.1.
> +
> + clocks:
> + description: clock-specifier
> +
> + clock-names:
> + oneOf:
> + - items:
> + - const: usbhost_120m_fck
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - const: usb_host_hs_utmi_p2_clk
> + - const: usb_host_hs_hsic480m_p2_clk
> + - const: usb_host_hs_hsic60m_p2_clk
> + - items:
> + - const: refclk_60m_int
> + - const: refclk_60m_ext_p1
> + - const: refclk_60m_ext_p2
> + - const: usb_host_hs_utmi_p1_clk
> + - const: usb_host_hs_hsic480m_p1_clk
> + - const: usb_host_hs_hsic60m_p1_clk
> + - const: usb_host_hs_utmi_p2_clk
> + - const: usb_host_hs_hsic480m_p2_clk
> + - const: usb_host_hs_hsic60m_p2_clk
> + - const: usb_host_hs_utmi_p3_clk
> + - const: usb_host_hs_hsic480m_p3_clk
> + - const: usb_host_hs_hsic60m_p3_clk
All but the first one can be combined to this last entry plus
'minItems: 3'.
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + ranges: true
> +
> +patternProperties:
> + "^port[0-3]-mode$":
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + String specifying the port mode for port N, where N can be from 1 to 3.
> + the port mode is not specified, that port is treated as unused. When
> + specified, it must be one of the following.
> + enum:
> + - ehci-phy
> + - ehci-tll
> + - ehci-hsic
> + - ohci-phy-6pin-datse0
> + - ohci-phy-6pin-dpdm
> + - ohci-phy-3pin-datse0
> + - ohci-phy-4pin-dpdm
> + - ohci-tll-6pin-datse0
> + - ohci-tll-6pin-dpdm
> + - ohci-tll-3pin-datse0
> + - ohci-tll-4pin-dpdm
> + - ohci-tll-2pin-datse0
> + - ohci-tll-2pin-dpdm
> +
> + "^usb@":
> + type: object
> + oneOf:
> + - $ref: /schemas/usb/generic-ohci.yaml#
> + - $ref: /schemas/usb/generic-ehci.yaml#
This causes the schemas to be applied twice and oneOf causes confusing
warnings. Instead just do this:
type: object
properties:
compatible:
contains:
enum:
- ti,ehci-omap
- ti,ohci-omap3
required:
- compatible
> +
> +required:
> + - compatible
> + - reg
> +
> +allOf:
> + - if:
> + patternProperties:
> + "^usb@": true
This will always be true. Unfortunately there's no way to do required
pattern properties in json-schema.
Is it valid to have no usb nodes? I wouldn't think so, so just make
these properties always required.
> + then:
> + required:
> + - ranges
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + bus {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + usbhshost: usbhshost@4a064000 {
> + compatible = "ti,usbhs-host";
> + reg = <0x4a064000 0x800>;
> + ti,hwmods = "usb_host_hs";
> + port1-mode = "ehci-phy";
> + port2-mode = "ehci-tll";
> + port3-mode = "ehci-phy";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + usbhsohci: usb@4a064800 {
> + compatible = "ti,ohci-omap3";
> + reg = <0x4a064800 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 76 0x4>;
> + };
> +
> + usbhsehci: usb@4a064c00 {
> + compatible = "ti,ehci-omap";
> + reg = <0x4a064c00 0x400>;
> + interrupt-parent = <&gic>;
> + interrupts = <0 77 0x4>;
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 15052c0f5377..d1dadba8ed0a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19406,6 +19406,7 @@ W: http://linux.omap.com/
> Q: http://patchwork.kernel.org/project/linux-omap/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
> F: Documentation/devicetree/bindings/arm/ti/omap.yaml
> +F: Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
> F: Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> F: arch/arm/configs/omap2plus_defconfig
> F: arch/arm/mach-omap2/
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Rob Herring @ 2026-04-08 12:41 UTC (permalink / raw)
To: Thomas Richard
Cc: Krzysztof Kozlowski, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <9d76f827-3967-4ab6-b6f0-77d1bd564278@bootlin.com>
On Wed, Apr 08, 2026 at 09:58:15AM +0200, Thomas Richard wrote:
> Hello Krzysztof,
>
> On 3/31/26 10:22 AM, Krzysztof Kozlowski wrote:
> > On Mon, Mar 30, 2026 at 03:43:59PM +0200, Thomas Richard wrote:
> >> Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
> >> supply and allows to unlock USB I/O cell.
> >>
> >> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> >> ---
> >> Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> >> index 3e020d87701b..908fbb46b5cf 100644
> >> --- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> >> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
> >> @@ -89,6 +89,7 @@ allOf:
> >> contains:
> >> enum:
> >> - pbias_mmc_omap4
> >> + - pbias_sim_omap4
> >
> > Names cannot be fixed, because they represent different board naming.
> > Why growing the deprecated style?
>
> Okay, so I'll drop all if statements, add a regex which matches
> regulator names and fix the regulator name in the driver.
If a driver depends on the names, you can't change them.
Rob
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: ti,pbias-regulator: Convert to DT schema
From: Rob Herring @ 2026-04-08 12:38 UTC (permalink / raw)
To: Thomas Richard
Cc: Krzysztof Kozlowski, Aaro Koskinen, Andreas Kemnade, Kevin Hilman,
Roger Quadros, Tony Lindgren, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <6b637950-2018-41d8-bdd2-27382a9b67d8@bootlin.com>
On Wed, Apr 08, 2026 at 09:57:20AM +0200, Thomas Richard wrote:
> Hello Krzysztof,
>
> On 3/31/26 10:21 AM, Krzysztof Kozlowski wrote:
> > On Mon, Mar 30, 2026 at 03:43:58PM +0200, Thomas Richard wrote:
> >> +$id: http://devicetree.org/schemas/regulator/ti,pbias-regulator.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: PBIAS internal regulator
> >> +
> >> +maintainers:
> >> + - Thomas Richard <thomas.richard@bootlin.com>
> >> +
> >> +description: |
> >
> > Do not need '|' unless you need to preserve formatting.
> >
> >> + PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
> >> +
> >> +properties:
> >> + compatible:
> >> + items:
> >> + - enum:
> >> + - ti,pbias-dra7
> >> + - ti,pbias-omap2
> >> + - ti,pbias-omap3
> >> + - ti,pbias-omap4
> >> + - ti,pbias-omap5
> >> + - const: ti,pbias-omap
> >> +
> >> + reg:
> >> + maxItems: 1
> >> +
> >> + syscon:
> >> + description: Phandle of the system control module
> >> + $ref: /schemas/types.yaml#/definitions/phandle
> >> +
> >> +patternProperties:
> >> + '^pbias_*':
> >
> > That wasn't in old binding and underscore is not allowed, so this needs
> > explanation. Old binding mentioned only the names.
>
> I did it to match existing devicetrees.
> I guess I should define properties like 'pbias-mmc' and 'pbias-sim',
> then update node names in devicetrees to match binding.
For this ancient stuff, I would just leave the dts files alone. Just
explain that in the commit message.
Your pattern should be '^pbias_' though.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
From: Krzysztof Kozlowski @ 2026-04-08 9:11 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-2-florian.fainelli@broadcom.com>
On Tue, Apr 07, 2026 at 04:56:10PM -0700, Florian Fainelli wrote:
> Add the "brcm,bcm7038-padconf" compatible to the pinctrl-single binding.
>
> Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> index 9135788cf62e..afe7329a1df2 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
> @@ -38,6 +38,10 @@ properties:
> - enum:
> - marvell,pxa1908-padconf
> - const: pinconf-single
> + - items:
> + - enum:
> + - brcm,bcm7038-padconf
> + - const: pinctrl-single
If there is going to be a new version, entire block should be placed
before 'ti' to have some sort of sorting by compatible.
But no need to resend just for that.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: regulator: ti,pbias-regulator: Add pbias_sim_omap4 regulator
From: Thomas Richard @ 2026-04-08 7:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <20260331-funny-impetuous-bobcat-eb56af@quoll>
Hello Krzysztof,
On 3/31/26 10:22 AM, Krzysztof Kozlowski wrote:
> On Mon, Mar 30, 2026 at 03:43:59PM +0200, Thomas Richard wrote:
>> Define pbias_sim_omap4 regulator for OMAP4. This regulators drives SIM_VDDS
>> supply and allows to unlock USB I/O cell.
>>
>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>> ---
>> Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>> index 3e020d87701b..908fbb46b5cf 100644
>> --- a/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>> +++ b/Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
>> @@ -89,6 +89,7 @@ allOf:
>> contains:
>> enum:
>> - pbias_mmc_omap4
>> + - pbias_sim_omap4
>
> Names cannot be fixed, because they represent different board naming.
> Why growing the deprecated style?
Okay, so I'll drop all if statements, add a regex which matches
regulator names and fix the regulator name in the driver.
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH v2 01/11] dt-bindings: regulator: ti,pbias-regulator: Convert to DT schema
From: Thomas Richard @ 2026-04-08 7:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Thomas Petazzoni,
linux-omap, linux-kernel, devicetree
In-Reply-To: <20260331-demonic-boisterous-spider-5ed5c6@quoll>
Hello Krzysztof,
On 3/31/26 10:21 AM, Krzysztof Kozlowski wrote:
> On Mon, Mar 30, 2026 at 03:43:58PM +0200, Thomas Richard wrote:
>> +$id: http://devicetree.org/schemas/regulator/ti,pbias-regulator.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: PBIAS internal regulator
>> +
>> +maintainers:
>> + - Thomas Richard <thomas.richard@bootlin.com>
>> +
>> +description: |
>
> Do not need '|' unless you need to preserve formatting.
>
>> + PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
>> +
>> +properties:
>> + compatible:
>> + items:
>> + - enum:
>> + - ti,pbias-dra7
>> + - ti,pbias-omap2
>> + - ti,pbias-omap3
>> + - ti,pbias-omap4
>> + - ti,pbias-omap5
>> + - const: ti,pbias-omap
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + syscon:
>> + description: Phandle of the system control module
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> +
>> +patternProperties:
>> + '^pbias_*':
>
> That wasn't in old binding and underscore is not allowed, so this needs
> explanation. Old binding mentioned only the names.
I did it to match existing devicetrees.
I guess I should define properties like 'pbias-mmc' and 'pbias-sim',
then update node names in devicetrees to match binding.
Best Regards,
Thomas
^ permalink raw reply
* [PATCH 2/2] pinctrl: single: Add bcm7038-padconf compatible matching
From: Florian Fainelli @ 2026-04-07 23:56 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
Just like the TI J7200 padconf, we lose the context and therefore need
to save it and restore it across suspend/resume states.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
drivers/pinctrl/pinctrl-single.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index d85e6c1f6321..657b42caf811 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1960,7 +1960,7 @@ static const struct pcs_soc_data pinctrl_single_am654 = {
.irq_status_mask = (1 << 30), /* WKUP_EVT */
};
-static const struct pcs_soc_data pinctrl_single_j7200 = {
+static const struct pcs_soc_data pinctrl_single_loss_off = {
.flags = PCS_CONTEXT_LOSS_OFF,
};
@@ -1972,6 +1972,7 @@ static const struct pcs_soc_data pinconf_single = {
};
static const struct of_device_id pcs_of_match[] = {
+ { .compatible = "brcm,bcm7038-padconf", .data = &pinctrl_single_loss_off },
{ .compatible = "marvell,pxa1908-padconf", .data = &pinconf_single },
{ .compatible = "ti,am437-padconf", .data = &pinctrl_single_am437x },
{ .compatible = "ti,am654-padconf", .data = &pinctrl_single_am654 },
@@ -1979,7 +1980,7 @@ static const struct of_device_id pcs_of_match[] = {
{ .compatible = "ti,omap3-padconf", .data = &pinctrl_single_omap_wkup },
{ .compatible = "ti,omap4-padconf", .data = &pinctrl_single_omap_wkup },
{ .compatible = "ti,omap5-padconf", .data = &pinctrl_single_omap_wkup },
- { .compatible = "ti,j7200-padconf", .data = &pinctrl_single_j7200 },
+ { .compatible = "ti,j7200-padconf", .data = &pinctrl_single_loss_off },
{ .compatible = "pinctrl-single", .data = &pinctrl_single },
{ .compatible = "pinconf-single", .data = &pinconf_single },
{ },
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
From: Florian Fainelli @ 2026-04-07 23:56 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
Add the "brcm,bcm7038-padconf" compatible to the pinctrl-single binding.
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
---
Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
index 9135788cf62e..afe7329a1df2 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.yaml
@@ -38,6 +38,10 @@ properties:
- enum:
- marvell,pxa1908-padconf
- const: pinconf-single
+ - items:
+ - enum:
+ - brcm,bcm7038-padconf
+ - const: pinctrl-single
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] Utilize pinctrl-single for bcm7038-style chips
From: Florian Fainelli @ 2026-04-07 23:56 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tony Lindgren, Haojian Zhuang,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
This patch set allows Broadcom STB chips with the BCM7038-style
pinmux/configuration blocks to use pinctrl-single. This does not
preclude us from making use of a more sophisticated driver in the
future, should we need to.
Florian Fainelli (2):
dt-bindings: pinctrl: pinctrl-single: Add brcm,bcm7038-padconf
pinctrl: single: Add bcm7038-padconf compatible matching
.../devicetree/bindings/pinctrl/pinctrl-single.yaml | 4 ++++
drivers/pinctrl/pinctrl-single.c | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: (subset) [PATCH v5 0/4] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Andy Shevchenko @ 2026-04-07 14:16 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Dmitry Torokhov,
Kevin Hilman, Arnd Bergmann, brgl, driver-core, linux-kernel,
linux-acpi, linux-arm-kernel, linux-omap
In-Reply-To: <DHKF135KLNW5.3LT0J6T5TE3JD@kernel.org>
On Sat, Apr 04, 2026 at 03:47:24PM +0200, Danilo Krummrich wrote:
> On Thu Apr 2, 2026 at 4:15 PM CEST, Bartosz Golaszewski wrote:
> [ Fix typo in the commit message: "s/merci/mercy/". - Danilo ]
Depends if Bart used French to sound that genuine.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Krzysztof Kozlowski @ 2026-04-07 10:46 UTC (permalink / raw)
To: Thomas Richard
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <c2026868-35ff-4b5e-a0e2-bf6b3f6b75ce@bootlin.com>
On 07/04/2026 10:34, Thomas Richard wrote:
>>
>>> + - enum:
>>> + - usb424,7500
>>> + - usb424,7505
>>
>> But you should notice that this is exactly the same as 95xx, so why it
>> cannot go there? Because of the wildcard 95xx naming? That's not a
>> reason.
>
> Yes I noticed. I did not put them in 95xx because it is not the same
> driver. Isn't that a valid reason?
Not really a valid reason. If you split driver into two, do you split
bindings? Or merge drivers? Bindings here describe the hardware, not the
driver layout.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Thomas Richard @ 2026-04-07 8:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260405-smoky-spectacular-koel-dbfcda@quoll>
Hello Krzysztof,
On 4/5/26 10:06 AM, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 09:02:23PM +0200, Thomas Richard wrote:
>> Create schema for LAN75XX compatible USB Ethernet controllers. The smsc75xx
>> driver only supports LAN7500 and LAN7505 devices.
>>
>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>> ---
>> .../devicetree/bindings/net/microchip,lan75xx.yaml | 52 ++++++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..b84022976044ffec2024cff9fc0aa5016723abed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
>
> Rather microchip,lan7500.yaml. Wildcards don't really scale when you
> have 75yy coming which does not fit into this binding.
>
>
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/microchip,lan75xx.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip LAN7500/LAN7505 USB Ethernet Controllers
>> +
>> +maintainers:
>> + - Thomas Richard <thomas.richard@bootlin.com>
>> +
>> +description:
>> + Device tree properties for LAN75XX compatible USB Ethernet controller.
>> +
>> +allOf:
>> + - $ref: ethernet-controller.yaml#
>> +
>> +properties:
>> + compatible:
>> + items:
>
> Drop items, that's enum directly.
>
>> + - enum:
>> + - usb424,7500
>> + - usb424,7505
>
> But you should notice that this is exactly the same as 95xx, so why it
> cannot go there? Because of the wildcard 95xx naming? That's not a
> reason.
Yes I noticed. I did not put them in 95xx because it is not the same
driver. Isn't that a valid reason?
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH 1/3] [v4, net-next] net: ethernet: ti-cpsw:: rename soft_reset() function
From: patchwork-bot+netdevbpf @ 2026-04-07 2:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
grygorii.strashko, ilias.apalodimas, m-karicheri2, s-vadapalli,
rogerq, vladimir.oltean, alexander.sverdlin, ioana.ciornei,
linux-omap, arnd, haokexin, daniel.zahka, linux-kernel
In-Reply-To: <20260402184726.3746487-1-arnd@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 20:46:53 +0200 you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> While looking at the glob symbols shared between the cpsw drivers,
> I noticed that soft_reset() is the only one that is missing a proper
> namespace prefix, and will pollute the kernel namespace, so rename
> it to be consistent with the other symbols.
>
> [...]
Here is the summary with links:
- [1/3,v4,net-next] net: ethernet: ti-cpsw:: rename soft_reset() function
https://git.kernel.org/netdev/net-next/c/961f3c535608
- [2/3,v4,net-next] net: ethernet: ti-cpsw: fix linking built-in code to modules
https://git.kernel.org/netdev/net-next/c/df75bd552a87
- [3/3,v4,net-next] dpaa2: avoid linking objects into multiple modules
https://git.kernel.org/netdev/net-next/c/ede3136e5655
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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