From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 872B0C433EF for ; Fri, 12 Nov 2021 11:54:52 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D1B2660EBD for ; Fri, 12 Nov 2021 11:54:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D1B2660EBD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4HrH7t2db7z3bP4 for ; Fri, 12 Nov 2021 22:54:50 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.crashing.org (client-ip=63.228.1.57; helo=gate.crashing.org; envelope-from=segher@kernel.crashing.org; receiver=) Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by lists.ozlabs.org (Postfix) with ESMTP id 4HrH7N32k5z2xCc for ; Fri, 12 Nov 2021 22:54:23 +1100 (AEDT) Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 1ACBnjBf016776; Fri, 12 Nov 2021 05:49:45 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 1ACBnfPp016770; Fri, 12 Nov 2021 05:49:41 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 12 Nov 2021 05:49:41 -0600 From: Segher Boessenkool To: Olof Johansson Subject: Re: [PASEMI] Nemo board doesn't recognize any ATA disks with the pci-v5.16 updates Message-ID: <20211112114941.GK614@gate.crashing.org> References: <78308692-02e6-9544-4035-3171a8e1e6d4@xenosoft.de> <20211110184106.GA1251058@bhelgaas> <87sfw3969l.wl-maz@kernel.org> <8cc64c3b-b0c0-fb41-9836-2e5e6a4459d1@xenosoft.de> <87r1bn88rt.wl-maz@kernel.org> <87pmr7803l.wl-maz@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , Rob Herring , Lorenzo Pieralisi , mad skateman , Arnd Bergmann , kw@linux.com, Marc Zyngier , damien.lemoal@opensource.wdc.com, Christian Zigotzky , Darren Stevens , Bjorn Helgaas , Alyssa Rosenzweig , "R.T.Dickinson" , "linux-pci@vger.kernel.org" , "bhelgaas@google.com >> Bjorn Helgaas" , Matthew Leaman , linuxppc-dev , robert@swiecki.net, Christian Zigotzky Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, Nov 11, 2021 at 02:21:46PM -0800, Olof Johansson wrote: > On Thu, Nov 11, 2021 at 2:20 AM Marc Zyngier wrote: > > Am I right in understanding that the upstream kernel does not support > > the machine out of the box, and that you actually have to apply out of > > tree patches to make it work? That these patches have to do with the > > IRQ routing? > > To my knowledge that has never been needed -- that the base platform > support is all there. > > This is an old platform, and just like with the power macs, the > devicetree is indeed supplied from firmware, and as such not easily > patchable like with ARM platforms. > > Last time this was an issue (to my memory) was when they enabled > automatic little endian switching in the boot path, that caused some > issues with a (bad) phandle pointer that had gone undiscovered for 10+ > years. > > > If so, I wonder why upstream should revert a patch to work on a system > > that isn't supported upstream the first place. I will still try and > > come up with a solution for you. But asking for the revert of a patch > > on these grounds is not, IMHO, acceptable. Also, please provide these > > patches on the list so that I can help you to some extend (and I mean > > *on the list*, not on a random forum that collects my information). > > Early fixups of DT is the way to go here, if needed -- we do it on > some other platforms. That can happen in-kernel, and keep the new > functionality. For that we'd need to figure out what's actually wrong > with the DT as such right now. Yup. The scheme we have now (copy all info from OF, and then take over everything at once) is not ideal at all, but treating OF systems just like "bare" systems has advantages as well, including making it easier to fix up the device tree if it has problems. This is much superior to changing all consumers (drivers etc.) to deal with the broken device trees, so we should do it much more often :-) Segher