From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f47.google.com (mail-dl1-f47.google.com [74.125.82.47]) (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 46E6F31AF07 for ; Tue, 28 Apr 2026 20:21:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777407667; cv=none; b=BpCPUNfi9Xb21fuDW6bO2dOPiHFZdSQay8/Tx1Gcz1sRa7gxWatrtbXuCyugF6271VQI6riD5hSy+F5pZWx2cDGL/rKGGDY+qQFRKOKnt5fW25UocYVqKQGjq/UcAMqbid4VfVL+xiO5dyBrqWSbLaIBsDI5tBVcmfWX0Zo9KhE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777407667; c=relaxed/simple; bh=b3y0XwETp/+cTkGRrG43RAGkVJDpjROsO7uB28sz0+k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IW4gH2bwpEc4XNPRl5RrJiLR+u31nNzEPgdNEfoMykaLZDgHwDTbbYmuCDMykzGE+js7SFU77yafdR91GViuTmoxh/4lCE7IVbpHYRkfMtl54VYF1rJeDqT6x0QN5cMTaalUrJ6nPZR/MFabCN6BvWrgY7jkWCU2kApOtAN9/ss= 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=Qk/a/gpH; arc=none smtp.client-ip=74.125.82.47 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="Qk/a/gpH" Received: by mail-dl1-f47.google.com with SMTP id a92af1059eb24-12c45281a06so16339110c88.1 for ; Tue, 28 Apr 2026 13:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1777407663; x=1778012463; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=wAYKdy6rZGHPp+6vTJbxhAN2mtySYtF/dy0uwVb4Go4=; b=Qk/a/gpHCT0jyi5R99OTiHzfbiqefiQgbfbvncmGW/v8RZYEpHTyzAmlJdoZOF9RXx ApO2HfxAoSXrA/y0FwW+q7Aex1MlSu287gmjdLKOcamUmrm9pnpwSPets4bP8W0/Hw49 1m1lu1Ab1ISF0Je3WzJGHKMLKAXFy0Er17E34= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777407663; x=1778012463; h=in-reply-to: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=wAYKdy6rZGHPp+6vTJbxhAN2mtySYtF/dy0uwVb4Go4=; b=lz7gwReBEk4b6FOzMAJ1dpJRud85GmFnOgxPwd9nkpEdkNxEXL6GFJ7VtansL+PzHO lpYDYaBJCuvYVeAa1wTqPKYv3g76tU/4SdUdW1ALLYjC/sfk0vnvhpPfOjul5DUXmNOr V/XiNeASIWMHL9QjMnFuUOxOM+6SPKltUEQUHyZpbU1C4EQTK2APt/G2k8n6fStjyIaP gN5XooyNOS+dY1GgsEYSDpwfxBGZgPaiBe5PPaMdCOdQhRxhQS2TnuxNWAhZmPsbPNjn 0PlQ1lmlmn2cSo4G2tUEwomh7IgeyQNgryhRFk2k/arEpER4s48XBGggr50t4tVc4t+W MQlg== X-Forwarded-Encrypted: i=1; AFNElJ+xO53OsBttQQkg0wJBogz6HCnbTKYoLJ65I943U7v0wH7QZa1e4ck8OEWJMqwP/gTtgsf27KWSeM5gHII=@vger.kernel.org X-Gm-Message-State: AOJu0YwBbQ7VUCCJdG9kWDPihMBd7fG5MeDZ+vbOhgzXrTWL4mr5cEpF CVpWyvQrqITXGKLSuD9tEnOKbTh3gY68yoF34+dFkDvMVNEpxJYMG+bA833WQ5Gmgg== X-Gm-Gg: AeBDiesU0bG++uhIgZOi3uV9oFj808B/jJLrA0YWYkjmE1KIracRKnIYrMw9dIeRAcp ODOi40T9tZt4iflj7fB/ckVU/3B5qB8mDeES6+LWzoWqVBxdhHyoi7Q6dvLN5hCq0h1Wc5vtw4X arxXFzPfGDvB3MwvVimTnEEKGO/ae60Ys9HWhfzXKjI72u4Stg3Gx7L6zddiNKXrPcYKUmymwA/ S6w1CPYvSv1p8fzWe1ZGjskT9rEyJBygXdbOqHc0nC8pz3mFNrnBv3NfF9W1Z7tPkmxBE45WyfJ 3t5TAw7vJ7tznr/m57T6Su9JqlqIF9H4uiSFDgsm1lpyXCS4eWltOcoTbpJlsg1hvcLHK9fCh+1 tHEU47HpP13ExkJkPHZLtl/XBiXP3KP0VQIqNTA8OryOxDpxJYPa4syNuAGYfKKu2aPvaSkqpHw s5C+NA3hTHqbMxpgVhmE/KwIVRKh8tc8otkJT9vLwzhLZu7FoWODCahTEHs7peXeywYFTTK2DzS gDCN9PEwAs= X-Received: by 2002:a05:7022:6607:b0:128:d967:4678 with SMTP id a92af1059eb24-12ddd99c410mr1729142c88.23.1777407663085; Tue, 28 Apr 2026 13:21:03 -0700 (PDT) Received: from localhost ([2a00:79e0:2e7c:8:4ff5:9607:c7e5:48f3]) by smtp.gmail.com with UTF8SMTPSA id a92af1059eb24-12ddd933044sm2821511c88.5.2026.04.28.13.21.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2026 13:21:02 -0700 (PDT) Date: Tue, 28 Apr 2026 13:21:00 -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: <20241209092809.GA3246424@google.com> <20260421193038.GA1502234-robh@kernel.org> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260421193038.GA1502234-robh@kernel.org> Hi Rob, Thanks for your thoughts. I delayed a bit since I wasn't really sure what the right conclusion was and wanted to give it some thought. On Tue, Apr 21, 2026 at 02:30:38PM -0500, Rob Herring wrote: > On Mon, Apr 20, 2026 at 03:54:42PM -0700, Brian Norris wrote: > > 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. > > The problem with #1 is a) new platforms can then repeat the same mistake > and b) we'll forget what platforms needed some work-around and whether > we still need to maintain such a work-around. Well, I might not forget, > but the next DT maintainer (applications welcome!) even won't know. For > example, I have know clue if we still need to carry some of the > work-arounds embedded into the interrupt parsing code. That all > predates me. The only way I find out is breaking them (I'll never > understand why people still run PowerMacs from the 1990s). Ack to most of this. I'll note that it's possible to write unit tests for this, if we go for the in-kernel route though, so hopefully that'd give maintainers a bit more visibility. > Calling the fixup code a layer is an exageration. It's on my kernel.org > tree in the dt/fixup-infrastruct branch. And look, guess what issue it > was that it has a fixup for. OK! I spoke in ignorance then. I really haven't explored the device tree construction / unflattening logic, so it was new to me. If it really comes to patching the kernel itself, I'll consider pulling in your patch. On first glance, it looks good, and not that complex even to an outsider like me. > > (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.) > > Shrug. I thought the ABI was a concern here. It's ultimately up to the > maintainers and users of a given platform whether or not they care about > the ABI. I'm usually on the receiving end of people complaining about ABI. It seems like we bend over backwards in a lot of places (drivers, driver frameworks) to maintain some idea of DTB ABI, while in practice, the ABI is almost never a strict concern for anything I've dealt with -- 98% of the DTB is generated from in-kernel DTS sources that match the kernel. ($subject case is actually the closest we get to DTB ABI concerns, because it involves the small part of the DTB that is generated by a program that is independent from the kernel tree. But even there, it's possible to fix the issue in the kernel-provided source.) So it seems to me like maybe it's best to just ignore the ABI concern, patch the DTS and call it a day. I've done that here: https://lore.kernel.org/all/20260428200712.2660635-1-briannorris@chromium.org/ [PATCH 0/7] dts: Add /firmware/#{address,size}-cells to Chromium-based DTs If someone finds reason we should still go back to fix the kernel itself, I can resurrect the fixup logic in addition. Thanks, Brian