From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE03E2853F1 for ; Wed, 3 Dec 2025 10:11:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764756685; cv=none; b=cOoBPYZU19fRlfp77XlD1Cr0OQFD7zDkBGMx5ejYgEX0Da421tJ+LpWZF+EKHhNSuDAwrEfkmwMkU9M+va80CUxbUXqdPXxNsfSdDzTKhCuCMwlyOIVkx3vgoeTDo7dKFGpRpsaGzm16HvDlbTCI6+JmSQyfKkgleP3ImzMbfBk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764756685; c=relaxed/simple; bh=7ykrGGwCG5UVuu6S46Y+mkYJETdoJx86HhNwtYYoBJs=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=f/rnv3IP5AeP5grbHL2aiasni/2A/ZPBHOXc87hZkKJ4ZNrXtPQIMFmx2Fhg/OfkQQxyM9v59mW+kBs7i+NYsBKwzP295ibw+e7nVlRiXuh1kgCApuvwMnZ4ikDO6jbtoWbWylgxxrBDHTyM23UvifkzyFrs4UDwj4yElAqTKms= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.221.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-55b2f2ae1cbso4304661e0c.1 for ; Wed, 03 Dec 2025 02:11:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764756682; x=1765361482; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=08y1I8cftAKXa2ZRDPk1QAbO3eRq2UKMz/WOuMZJTrE=; b=uduvHKO+tcbfqfpql0GqoTnfBGLI+m/0/u7i/opnPMPWQuBEaZeFTnIx/Wb/c3t/wQ xQUeM4HkLk7COdC3X98ZlL5bcYmYIvaKP2sZqZpoJ+ylLPWOQ9uROYCiHWtWpeC72mnz GKSyWiaYNInLOUEnb6pGnOJ8eWWuHOad2l8jvI36ApwVzlthgdeHktKlmSuvcNq1gPM6 P+vMfpVgyrzzpi4XsJQNL/1nnT51Bg0YTl6uciawimBxlZJ9RXrW/WjYoqQ6XJAKhPfL GOnbexyiiIKcGVNOMHPyos6zBBZSE+gghqVdBe4rQ6RcEaW2KB+hPxyhhzanYRwLZ1/I FQig== X-Forwarded-Encrypted: i=1; AJvYcCV2PbJwnbKoSZMj6zZDX5rSh3OWf3p9HBgxX6ku7N2tx1SgXt/Pcig29JqNZJDEEL4JBZ6pMngMaHo=@vger.kernel.org X-Gm-Message-State: AOJu0Ywer/bwdVXtwV8phUyzNkc/C3q8If8gIchYMYSvzftgNCiyoQJ+ idy/HiVJ63vI2YArXdl59eWcR0wsOaNZia2Pjd6eL6Zs9+8Sifi3+m8XzPGkTwJe X-Gm-Gg: ASbGncv6OzWrRkwiEW67bU/GMYNTiLkqFtGFG1hkmCiSJvcwNxhsNm+T5cR2a9o8xkZ WZpLtl7hkqxpRcYc8zYMkavYxo4IXGmiSGXRQ9IxrIrmIQpHoatu06zfKRxNwIfZVtSDy3u1wgo CrTXBg72MD8rymdhvPpe7XSmRm+b73KyPCyQ4oLHFPhAOP79yncVGr8pNc1t2oZNt//Rg3QFY1l 5inEuzb3S/cJskq5W3sLGiTKPK+D9nhHX0yKlYY4liPtHQlJ3cZ/xRO38syCpW2QulLzOJO3+sR xZZxNrOlTYl1ftv+Wlebtf0+igo9Rh7JwCDOJNOmFl/iUbTNYHZYXWLn+eN2GYjmqnE6FbEgXH3 fOna5pTcNHl0XxjDgWMiTD/qiZxBN7lJg8CoKPZ/UxSVGxnQVP4KAqhHQA2P/u8xQSMkToLwJpc orEMRoSvFL7sO7MVbgHdQOmz8td0rm19xSwvUuj0akuX/L1IpOQACb X-Google-Smtp-Source: AGHT+IFvHXq1BqMYO2IC0dahRdXY9JcpHg8EE+27ECe70bIWTWrM81pY8R03oOPhTuu0W52ATcm2Lg== X-Received: by 2002:a05:6122:190b:b0:559:7394:9c3a with SMTP id 71dfb90a1353d-55e5be7fd58mr460976e0c.8.1764756682147; Wed, 03 Dec 2025 02:11:22 -0800 (PST) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com. [209.85.221.170]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-55cf4e1d580sm7569026e0c.1.2025.12.03.02.11.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Dec 2025 02:11:21 -0800 (PST) Received: by mail-vk1-f170.google.com with SMTP id 71dfb90a1353d-559f4801609so1587482e0c.0 for ; Wed, 03 Dec 2025 02:11:21 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWFFEb9IOMjHF/MHOOJK8M6ETqvFdYrsG+fAg31a3ZeqRTO4YdV23gmjehD96cy0N62h+UejHRrYm8=@vger.kernel.org X-Received: by 2002:a05:6102:579a:b0:5df:c1ac:8ad4 with SMTP id ada2fe7eead31-5e48e01012fmr426535137.0.1764756375911; Wed, 03 Dec 2025 02:06:15 -0800 (PST) Precedence: bulk X-Mailing-List: linux-clk@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251015071420.1173068-1-herve.codina@bootlin.com> <20251015071420.1173068-2-herve.codina@bootlin.com> <5cf2a12a-7c66-4622-b4a9-14896c6df005@gmail.com> <072dde7c-a53c-4525-83ac-57ea38edc0b5@gmail.com> <55076f4b-d523-4f8c-8bd4-0645b790737e@gmail.com> <20251202102619.5cd971cc@bootlin.com> <20251202182834.65d7f0a1@bootlin.com> In-Reply-To: <20251202182834.65d7f0a1@bootlin.com> From: Geert Uytterhoeven Date: Wed, 3 Dec 2025 11:06:04 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AWmQ_bm_vwtlSlkiVojLd-rzxo_k4pikXV0aLj6bs5bAdLDXgMj28SXkaqQFKI0 Message-ID: Subject: Re: [PATCH v4 01/29] Revert "treewide: Fix probing of devices in DT overlays" To: Herve Codina Cc: Kalle Niemi , Rob Herring , Matti Vaittinen , Andrew Lunn , Krzysztof Kozlowski , Conor Dooley , Greg Kroah-Hartman , "Rafael J. Wysocki" , Danilo Krummrich , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , Michael Turquette , Stephen Boyd , Andi Shyti , Wolfram Sang , Peter Rosin , Arnd Bergmann , Saravana Kannan , Bjorn Helgaas , Charles Keepax , Richard Fitzgerald , David Rhodes , Linus Walleij , Ulf Hansson , Mark Brown , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Len Brown , Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , Geert Uytterhoeven , Wolfram Sang , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org, linux-i2c@vger.kernel.org, linux-pci@vger.kernel.org, linux-sound@vger.kernel.org, patches@opensource.cirrus.com, linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org, linux-spi@vger.kernel.org, linux-acpi@vger.kernel.org, linux-cxl@vger.kernel.org, Allan Nielsen , Horatiu Vultur , Steen Hegelund , Luca Ceresoli , Thomas Petazzoni Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Herv=C3=A9, On Tue, 2 Dec 2025 at 18:29, Herve Codina wrote: > On Tue, 2 Dec 2025 17:35:35 +0100 > Geert Uytterhoeven wrote: > > On Tue, 2 Dec 2025 at 10:26, Herve Codina wr= ote: > > > On Fri, 28 Nov 2025 10:34:57 +0200 > > > Kalle Niemi wrote: > > > > >>>>>> Test system testing drivers for ROHM ICs bisected this commi= t to cause > > > > >>>>>> BD71847 drivers probe to not be called. > > > > >>>>> This driver (and overlay support) is in linux-next or somethi= ng out of > > > > >>>>> tree on top of linux-next? > > > > >>>>> > > > > >>>>> Rob > > > > >>>> Yes the driver is in mainline linux: /drivers/mfd/rohm-bd718x7= .c > > > > >>> I don't see any support to apply overlays in that driver. > > > > >> Ah. Sorry for the confusion peeps. I asked Kalle to report this = without > > > > >> proper consideration. 100% my bad. > > > > >> > > > > >> While the bd718x7 drive indeed is mainline (and tested), the act= ual > > > > >> 'glue-code' doing the overlay is part of the downstream test > > > > >> infrastructure. So yes, this is not a bug in upstream kernel - t= his > > > > >> falls in the category of an upstream change causing downstream t= hings to > > > > >> break. So, feel free to say: "Go fix your code" :) > > > > >> > > > > >> Now that this is sorted, if someone is still interested in helpi= ng us to > > > > >> get our upstream drivers tested - the downstream piece is just t= aking > > > > >> the compiled device-tree overlay at runtime (via bin-attribute f= ile), > > > > >> and applying it using the of_overlay_fdt_apply(). The approach i= s > > > > >> working for our testing purposes when the device is added to I2C= /SPI > > > > >> node which is already enabled. However, in case where we have th= e I2C > > > > >> disabled, and enable it in the same overlay where we add the new= device > > > > >> - then the new device does not get probed. > > > > >> > > > > >> I would be really grateful if someone had a pointer for us. > > > > > Seems to be fw_devlink related. I suppose if you turn it off it w= orks? > > > > > There's info about the dependencies in sysfs or maybe debugfs. I = don't > > > > > remember the details, but that should help to tell you why things > > > > > aren't probing. > > > > > > Rob reverted patches but I plan to continue my work on it. > > > On my side, I need the reverted patches but I fully understand that, = on > > > your side, you need a working system. > > > > > > In order to move forward and find a solution for my next iteration, c= an you > > > send your overlay (dtso) used in your working and non working cases? > > > > Hmm, I must have missed when Rob applied (part of) this series, as I > > do an overlay test (using the out-of-tree configfs) on top of every > > (bi-weekly) renesas-drivers release, and saw no issues during the last > > few months. > > > > So I applied this series and tested loading my SPI EEPROM overlay. > > And it indeed breaks, with the culprit being this particular patch. > > > > Interestingly, quoting from this patch: > > > > "While the commit fixed fw_devlink overlay handling for one case, it > > broke it for another case. So revert it and redo the fix in a separ= ate > > patch." > > > > Where is the separate patch that redid the fix? I assume it is "[PATCH > > v4 03/29] of: dynamic: Fix overlayed devices not probing because > > of fw_devlink"? Unfortunately that doesn't fix the issue for me. > > > > Quoting more from this patch: > > > > "Closes: https://lore.kernel.org/lkml/CAMuHMdXEnSD4rRJ-o90x4OprUacN_= rJgyo8x6=3D9F9rZ+-KzjOg@mail.gmail.com/" > > > > Strange that it claims to fix the issue reported there, as the failure > > mode I am seeing is exactly the same as documented in that report? > > > > Do you know what is wrong? The overlay I am using is referenced in > > the bug report linked above. > > The first patch "Fix probing of devices in DT overlays" didn't fix all ca= ses > and so Saravana reverted this patch and proposed "of: dynamic: Fix overla= yed > devices not probing because of fw_devlink". > > This second patch was needed to fix my use case even if more modification= were > needed to have my use case fully fixed (other patches in my series). > > Rob applied those first patches from my series and some systems were brok= en. > The breakage has been reported my Kalle and Matti and led to a revert of = culprit > patches. > > I tried to understand what was wrong. I am pretty convinced that modifica= tion > done in "of: dynamic: Fix overlayed devices not probing because of fw_dev= link" > are really better than modification available in "treewide: Fix probing o= f > devices in DT overlays". > > I proposed an update [0] and I will be glad if you can also test this upd= ate > on your side and give me your feedback. > > [0] https://lore.kernel.org/lkml/20251202175836.747593c0@bootlin.com/ Thank you! Unfortunately this does not fix the problem: I still need to do an extra overlay rm/add cycle to make the SPI EEPROM work. In addition, it triggers a bunch of new scary error messages: rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,src/src-0 rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,src/src-1 [...] rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,src/src-9 rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,ssi/ssi-0 rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,ssi/ssi-1 [...] rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,ssi/ssi-9 rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,src/src-0 rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,src/src-1 [...] rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,src/src-9 rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,ssi/ssi-0 rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,ssi/ssi-1 [...] rcar_sound ec500000.sound: Failed to create device link (0x180) with supplier soc for /soc/sound@ec500000/rcar_sound,ssi/ssi-9 Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds