From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 63C1C2E762E for ; Wed, 3 Dec 2025 10:11:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764756712; cv=none; b=m3Toj9UrP522t4jrNfnwoguMQddlych5etTIyPO71buls8mKfL1/JNDbdiAQo9Mbyf+HwSHUv+uUE1SnZBsx2ks0ZFMR0vL+QXdb/hpdvmD51/OtITAeggEC48hgqj8Z94T1SV/olROwS33mw6GjNDm+jbWLnxGVFYSoYrWpEeI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764756712; c=relaxed/simple; bh=yy2j4Gr2kBYId3840eqEXHigGss3DzYkeqaEM7aYlHA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pex50wnX+DHpgJyC2QXacX7hEsYWsDLa51URpjHc0tLpSrjEvTdKMjJe49fURNSEK6FnMGCFFCmkbNrex2myydgbYUN/zIniH4IpLt5xdZmyq+BspcPhCWjdF/4sTQBO/M+50e4xRWoIVXgkk2VUwMcCAYjIcMVnQ8kESgFrYSA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CGQ3qm8f; arc=none smtp.client-ip=209.85.167.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CGQ3qm8f" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-59581e32163so6627608e87.1 for ; Wed, 03 Dec 2025 02:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764756707; x=1765361507; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7hkzMjIodS1pI1goTlzUE28NNMhc2FNCH6n3nOuMBQE=; b=CGQ3qm8f+FnQjwU2B6pdhx/AwemgYV6WVz3Dj7xUo4cV3I4MJgz1nWnTG6r2YQPOjf fP8b+31wR1gNKe6nGF9q9e+RncRGjSWqm3UGUrUsUmPAxzh+gkAJ7quVLcI9rMrMg7vB Uq0TC/2dS4oGg0gFqFJdmhF5vXYCsU+okjdR6We64fb16qwZPbwsgj6AxYG9IZAgrwah tARdWVM8K9aVO6PuvFeMcAZk9zmPV6pfQJxh1anrbDS95rvuNVWG8Lrc27VSlQ9/IY0L 55DMxgyxALBxlRdganrQNQwaut8ICacgWsjCQgecIbz6bI07RlBRM+UX0VQC2wwTLQW+ owHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764756707; x=1765361507; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7hkzMjIodS1pI1goTlzUE28NNMhc2FNCH6n3nOuMBQE=; b=OA8xrrh7Nz1sEIuW10U0+WR+MgdzmGO7Zfc+T0KQnZ3/jQZEAQk3AmD4Lu3S9SUjhj DxSyuj4tZQWTNxA/k8B3XczIMzOMoWfCQpqZonX4M5l3hGIrP3VxXtl60KQQeVyinKat +7L6zClowly9Rm6G9DY8cS40HBjPVbFQ/uUfnnouS94fhaxqPhxuxygOX1UQHyG/f6sU WBkh+cHKi84xu2zQJBX3BNGe6el+MMrMcxudD3PI5BuZeD7DH2dBnRpNgWhHy/QReBcr 0xJaaDGjXCy8B2xBIoU9TcM99VQknqdgWrDJDwC4xQp/4fDeJAOEGR8k+4PJ/vCNIfWA 45Bw== X-Forwarded-Encrypted: i=1; AJvYcCV9X93svcDQEfkAzZ5l0gpUx/BaxkRozWpsmyQ6dTunk0UqfrQ7pcX15CEJbe5lEvVRwUii4Zx5IZM=@vger.kernel.org X-Gm-Message-State: AOJu0YzJXAJKGjDYdlD23rP556Qgn0WS/BIIyb+KIofDZqpNx1WPT4Bk TBLoBFGTL+qpoh90xGaWTnua88aCOzDBB9MSZxkixLtOP+7DGb64Xi/h X-Gm-Gg: ASbGncuR8AhNdexMaWhD+DNVv8q+aVMaBEWp1K6T9rpNJvykOuSUWwb7nI83ERYdYAH U7RHgxHH47iPUoVZwYSVDe3QiUwLGPQu5Wc13ttfLiTlPh/1Yvtvtbk1y1IO1Y5ChTTdNZJWJGx 3cdakK6XEj7cf/sJKegNlb8zoeoFDlb+7emdpJsShYOi+4Gl9A915lf8T/tIY9X6uLUQqeXm6c5 p8wuPwtzWq4UXuR5O8W16BfsjJ8L4ElNjczNkWOC6ChEwUGk3cqC1IoSdSbWykwx8QDMlo0jUEN 5DDM2jZXy7IIAZnPGPw6bBoILDl4nse74cNgz4PYw25/u2rNjoAxoTwhqg7wfjWxWMSZGZMm5PO cmI8mbxNg/mfPxYr3DkE3PirYwqWN1eDI9Zw9k3BGNT5TfoHD5c83DFNABjqphqSKHSCwmLz48b 7OLrrhM+9S4ea6Vg== X-Google-Smtp-Source: AGHT+IGClRjrRzHtx62krt4asIMCvQHnP6xr/r5CpGOAwQrXHtwf7m7w8S9UGWZzoda9nXqVUQIx4Q== X-Received: by 2002:a05:6512:12c4:b0:595:7d86:f654 with SMTP id 2adb3069b0e04-597d3fb539emr853943e87.26.1764756707102; Wed, 03 Dec 2025 02:11:47 -0800 (PST) Received: from [10.38.18.76] ([213.255.186.37]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-596bf8a7b2asm5560144e87.12.2025.12.03.02.11.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Dec 2025 02:11:46 -0800 (PST) Message-ID: Date: Wed, 3 Dec 2025 12:11:45 +0200 Precedence: bulk X-Mailing-List: linux-clk@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 01/29] Revert "treewide: Fix probing of devices in DT overlays" To: Herve Codina , Rob Herring Cc: 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 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> <088af3ff-bd04-4bc9-b304-85f6ed555f2a@gmail.com> <20251202175836.747593c0@bootlin.com> Content-Language: en-US From: Kalle Niemi In-Reply-To: <20251202175836.747593c0@bootlin.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/2/25 18:58, Herve Codina wrote: > Hi Kalle, Matti, > > On Tue, 2 Dec 2025 13:21:16 +0200 > Kalle Niemi wrote: > >> On 12/2/25 11:26, Herve Codina wrote: >>> Hi Kalle, >>> >>> On Fri, 28 Nov 2025 10:34:57 +0200 >>> Kalle Niemi wrote: >>> >>> ... >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Test system testing drivers for ROHM ICs bisected this commit to cause >>>>>>>>>> BD71847 drivers probe to not be called. >>>>>>>>> This driver (and overlay support) is in linux-next or something 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 actual >>>>>> 'glue-code' doing the overlay is part of the downstream test >>>>>> infrastructure. So yes, this is not a bug in upstream kernel - this >>>>>> falls in the category of an upstream change causing downstream things to >>>>>> break. So, feel free to say: "Go fix your code" :) >>>>>> >>>>>> Now that this is sorted, if someone is still interested in helping us to >>>>>> get our upstream drivers tested - the downstream piece is just taking >>>>>> the compiled device-tree overlay at runtime (via bin-attribute file), >>>>>> and applying it using the of_overlay_fdt_apply(). The approach is >>>>>> working for our testing purposes when the device is added to I2C/SPI >>>>>> node which is already enabled. However, in case where we have the 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 works? >>>>> 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, can you >>> send your overlay (dtso) used in your working and non working cases? >>> >>> Best regards, >>> Hervé >> >> Hello Hervé, >> >> I have attached the overlay source file: bd71847_overlay.dts > > Thanks a lot for your overlay. > > I did an update of the reverted patches and I didn't detect any regression > with the update applied on my use case but I don't have the needed code to > perform tests similar to your use case. Indeed, you apply the overlay using > an out of tree code. > > May I ask you to perform a test of this update on your side? > > First you can use the last linux-next kernel where reverted patches are present. > The next-20251127 tag is a good candidate. Indeed both patches are present: > - 76841259ac092 ("of: dynamic: Fix overlayed devices not probing because of fw_devlink") > - 7d67ddc5f0148 ("Revert "treewide: Fix probing of devices in DT overlays"") > > Of course, be sure to have the issue using this kernel with your overlays. > > Then can you add the following modification on your faulty kernel: > ---- 8< ---- > diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c > index 1528d8ad9f26..aea7bb26d9c4 100644 > --- a/drivers/of/overlay.c > +++ b/drivers/of/overlay.c > @@ -190,6 +190,20 @@ static void overlay_fw_devlink_refresh(struct overlay_changeset *ovcs) > for (int i = 0; i < ovcs->count; i++) { > struct device_node *np = ovcs->fragments[i].target; > > + /* > + * The device related to target node itself could have been > + * removed and re-added. This happens when the 'status' property > + * in the target node has been changed by the overlay. > + * > + * In that case the parent node needs to be fixed. > + * > + * Before fixing the target node itself, fix its parent. To keep > + * things simple, fix the parent in any case. If nothing needs > + * to be fixed, fw_devlink_refresh_fwnode() acts as a no-op. > + */ > + if (np->parent) > + fw_devlink_refresh_fwnode(of_fwnode_handle(np->parent)); > + > fw_devlink_refresh_fwnode(of_fwnode_handle(np)); > } > } > ---- 8< ---- > > My hope is that this modification will fix your issue. > If so, I will add it in my next iteration. > > If you cannot perform the test on your side, can you provide me the out of > tree code you use to apply the overlay? > > Best regards, > Hervé Hello Hervé, I tried this patch on next-20251127 by manually adding the added lines to /drivers/of/overlay.c, and it did not solve the issue. I will continue to test this. BR Kalle