From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f48.google.com (mail-dl1-f48.google.com [74.125.82.48]) (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 7028237FF5F for ; Mon, 20 Apr 2026 22:54:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776725687; cv=none; b=FEZZPyHOaKR3Vi5HJd7pzKOZLWvGJFtYoJT9fBu6KEx5WM52R41brenz3dkaz3Dm5vTfqXTRwHyh8NIcqbYgB2ggqmy6NvuF+pCB6CQ8LJ4UR+OxryK2od83M3FeyTIXCmfmSgYZKlQ18+dUDzOjTZXhUgQ0h7TLsneCBAViKAw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776725687; c=relaxed/simple; bh=LzWzhzcf1C6ni0bQispFtpLu+s0ydO/LCFQvYMYUdBU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=APC99uLYlhux9ak+AR/9xaO3XX1+fE5/+Z+UW5YeSLutsdrF5HTR02VIXZyXWcdOXwOnq1U3RwRlopdYEOzKcqF/IbrKYbrZPmu4VWUuA9JNOZJmgHAxzqOzEirbE4MdU8DkNq8aMC/tzBGBhOvyPWISmp9fp6rmVCvm76WyGJo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=KKT/1TwP; arc=none smtp.client-ip=74.125.82.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="KKT/1TwP" Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-12c1a170a50so4279821c88.0 for ; Mon, 20 Apr 2026 15:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1776725686; x=1777330486; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=CUnGStOPn+XWhs8XrMu/ZlBc/4VQOcQ2/iqWR+erKXE=; b=KKT/1TwPv+OYfYs2LkSF/223HrfBSL31TI/+xXwr7nK28UmZoTen1OjV+B+mSePEiN 05dOg/CjYCWh792j0iS7CywdUQcFjiYLBIHnrWUprSYizpcxk1yNDuCbTEQXcriFxMaR 8kdT87EvjnZJyfPcrbMdOJ0mL5ZAVq+/w3pVc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776725686; x=1777330486; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CUnGStOPn+XWhs8XrMu/ZlBc/4VQOcQ2/iqWR+erKXE=; b=GFZaBoDA5litgjhMh8t5BSvEdY7n6Hp9Del4EcwOAHo2J3WkDlI2KqBctN0u4LWzHR S9zyeEQybv2kglqrDWxmwmMCIeTOSMr3Z44h8yl3eHiUKpGQSoIFJFZKRBkHLL1palg7 JYxc86arIJF9AHrnQU8j6xKBS4ZoD0oj7d6yLHxHAyYiyox+KTA+aU6+AI/xwmLjK3c2 ArN6ho0dNPhJhMEIo0kXa8idCUNHLSFf9662vMU57DEDLdMzg5vbFuWW49s2HH2kbrBq vzooCHTkY4yAFi5Ob329kd8BmsoF2qCfhy9oj8o4TV+dnjrsKthBGpQOJj2hjaJyxz93 6McA== X-Forwarded-Encrypted: i=1; AFNElJ9xdWkOPxS3IZwZVJXKA8LNZQrTWyDUP38v3V+klHWjbU9i8UCrdpLwWlUpdVYfOht1c03eGIcVfal726A=@vger.kernel.org X-Gm-Message-State: AOJu0YxsVqb7lZf1Rs6tseLkFyGCqZ/ruikIAeEglPeYxL5JJ02G2v0z Ytc4RDf8r3hYfAUrfEk0OMskoHb3eC+g3jUnkUokIu+n4bowOytPJLZCMf0X6feSQQ== X-Gm-Gg: AeBDiev4SHzWCi3vLCbFbJ7dZCswDzZpjn2kcotHRqb9nw7vfzTejJwJpBd08L/hoNj xt5uaaqyq4nnkb2vb4XoCAy35HsHV6Nk7WQ03P33dkskSkIev69GCsp96qIDWYtJDn1z3zOdg40 VJ+9D6zJQru/JdwXD/IDjwwrVNbfEStXM3MWRz48He8wO/IFWCdtf1TFf8o9wC+o5Fmsv8OP+j2 DnDpY/89RUiZm996TcOzN90ZVELhz8XlVrOJNA2ZzYljxSxvA2musG6lJDcMujN7HtdS20pccOR S/DRS401hTFs86iBo6fXD3sjvl31at4IF86qCH9eEkbJna21A6X/Ze0lSn8cZw9/vsQSxYrNqpD XF3orTx8ZqP6SUfb8sfqDt4lljTc7MYKqkiJtrx2LgR5JbhWUK6SmxeOFQfoSME2PZWfvYQNb6k 2LrVXoIM9ecgKC7lfHK42Nq9Xz61gevRcKvBJBezArhNd2b8kaEoU0lWgWkz/fEhwWRmMTSPvi X-Received: by 2002:a05:7022:f9e:b0:128:ccb7:7fa3 with SMTP id a92af1059eb24-12c73fa8fa3mr7564950c88.34.1776725685322; Mon, 20 Apr 2026 15:54:45 -0700 (PDT) Received: from localhost ([2a00:79e0:2e7c:8:b635:62cc:359d:682d]) by smtp.gmail.com with UTF8SMTPSA id a92af1059eb24-12da8b8fbc4sm3231421c88.4.2026.04.20.15.54.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Apr 2026 15:54:44 -0700 (PDT) Date: Mon, 20 Apr 2026 15:54:42 -0700 From: Brian Norris To: Rob Herring Cc: Chen-Yu Tsai , Sasha Levin , Krzysztof Kozlowski , AngeloGioacchino Del Regno , Linus Torvalds , Krzysztof Kozlowski , Conor Dooley , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Matthias Brugger , Doug Anderson , Julius Werner , chrome-platform@lists.linux.dev Subject: Re: [regression] of: mis-parsing Depthcharge's /firmware Message-ID: References: <19ba4910-f909-41b4-ba62-c904bc37d41d@linaro.org> <20241209092809.GA3246424@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Apr 20, 2026 at 05:19:06PM -0500, Rob Herring wrote: > On Mon, Apr 20, 2026 at 3:57 PM Brian Norris wrote: > > On Mon, Apr 20, 2026 at 07:57:40AM -0500, Rob Herring wrote: > > > On Fri, Apr 17, 2026 at 4:26 PM Brian Norris wrote: > > > > Can we patch of_bus_default_match() to accept an empty 'ranges' [1]? Or > > > > should I go patch every Chromium-device DTS file I can find? So far, I > > > > think I can get that done in 17 files in the upstream tree... > > > > > > Both. > > > > To be clear, my options were: > > > > 1. fix up kernel parsing to accept these /firmware/coreboot node > > structures (with empty ranges / no #{address,size}-cells) > > 2. add #{address,size}-cells into the kernel-included dts(i) files (this > > will merge safely with the DTB modifications patched in by old > > bootloaders). > > > > I wouldn't call #2 "kernel fixup the DT", personally. I'd call it "fix > > up the DT source that happens to be provided by the kernel." This > > assumes no one is using device trees that are exclusively maintained > > outside the kernel. (I believe that's generally true, except for > > OpenWrt. And even there, it's still acceptable to patch the DT source, > > and I've already done so.) > > > > > Though I'd rather the kernel fixup the DT rather than relax the > > > parsing code for everyone. Then we know what platforms need this and > > > don't let new ones in. > > > > I'm not sure how to parse this. This paragraph sounds like a 3rd option: > > Well, not in the sense of pick one of 3 options. It's another option > in how to fix the kernel. Ah, got it. So it's an alternative to #1. > I think we should fix any .dts files we can > in addition to fixing the kernel. OK. I have patches for both, and I'll see about sending them out in the next day or two. > > 3. "kernel fixup the DT" -- sound like you want the kernel to identify > > these specific /firmware/coreboot structures, and activtly > > modify/patch the FDT at runtime > > > > Is that an accurate interpretation? If so, that sounds rather novel, and > > nothing like "both" (#1 + #2 above). It's certainly possible, but seems > > like a large lift for this particular incompatibility. > > Yes. It's not novel though. The powerpc code is littered with such > things. Some of them due to the commit in question here. Look at > commits from me in arch/powerpc. > > I started some common infrastructure to apply fixups, but the case in > particular that needed it ended up not needing it. So it's something I > have on a branch somewhere. Also it worked on the unflattened tree as > not all things need to be fixed up early. You say it's not novel, but then you say the only existing code is either: 1) completely different, and only applicable to powerpc or 2) only on your local tree. That sounds novel to me :) Anyway, I'm more inclined to lean on my #1 and/or #2 than to write a whole new fixup layer. But maybe #1 can be replaced in the future if we come to really want/need a generic fixup layer in the future. (Frankly, if we do #2, #1 and #3 will probably both be redundant and unnecessary. I don't know of any case here where we're relying on strict DTB ABI compatibility with no opportunity to update some of the DTS sources.) Brian