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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 93F3DC30658 for ; Tue, 25 Jun 2024 08:49:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Content-Transfer-Encoding:Content-Type:In-Reply-To:From:References:To:Subject :MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=n+OiqRQm4VVWpy0vnpohjTVwjXgHNRf30NEahZXCK2Q=; b=uPzpcXdsDivpYg OUTxYaIYjSX+gZWfqDbez2hrRx+F1qHxc2U1yxXnlaCVXPtJ8+A+4aPgBv1yRwzfpiqS13rHsGFCU vrWMknMdeKxiF0fiDHPJIX1BfSuox+3QRjFd36rWkj83mOkXXMGMBXk0T/+q5z7TClKLjwRpJo75G p4wgFh4CPefTRtZ5AyDEnitTbbrsvJn8TYiwLhbgq+0CKsUJ3Fi05Cy77BUTu9NRUAHeQGASTJfVS ZLBIcmgbwmpI8oDHd50UOj5wWNFvHwkYH9kdCd/1dUPxcOaByOVVh5X4O9nsrh8+7i9E4gm/jL5Hm KaADhvARziEUMA1srbjA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sM1ri-00000002Ak5-09nC; Tue, 25 Jun 2024 08:49:26 +0000 Received: from madrid.collaboradmins.com ([46.235.227.194]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sM1rb-00000002AjP-0lxb; Tue, 25 Jun 2024 08:49:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1719305357; bh=jaMfjUSzmTt56GaotikfsNUu0t1/tVz87p+MxzGBY50=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=osA68c029o1snvbg8uaGgx3SdEFXZleM3P6TejYL0GGc3zJZKZkZfMPNAFfXy+wrW DWf0YvSMU4qykWszIjEO1IZikI7SiLEJtXiViRfRjODGfgjW9L4eNMun33GdbzGMz+ Bm6SC4WLna+GEYg3c1QJzcrN5rGcN1JXDX2BVqbE3+VZpfPW76b1mK/fc9AE+Eoypq bHyKLWXE3eQKc1iIi6hLfwCgpk5ujjtcnz9NhiohTf6URXPoRQTNcBSnkwIMcaIB/V gT8eI2NLmEJ06t938s9m2xzYBPYka6FmBy1QaNZn/r8QU2AzTmCifELK3CnKIPMbcG u5vFcIg0uHF3A== Received: from [100.113.186.2] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madrid.collaboradmins.com (Postfix) with ESMTPSA id BB306378045F; Tue, 25 Jun 2024 08:49:16 +0000 (UTC) Message-ID: <4647181b-e5a0-4f6e-9aba-1bcde763d678@collabora.com> Date: Tue, 25 Jun 2024 10:49:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm64: dts: mt7622: fix switch probe on bananapi-r64 To: =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= , Linux regressions mailing list , Paolo Abeni References: <20240516204847.171029-1-linux@fw-web.de> <43aacd9d-b851-4100-8ccc-878ac6ae10f8@leemhuis.info> <698cf562-1ca9-4aa3-be7e-a1474b612c5b@leemhuis.info> <0cba095c-3d55-416a-a7ad-b359129731cf@arinc9.com> <714da201-654b-4183-8e5e-8ff0b64fe621@leemhuis.info> <2cac4cf68304e81abffbd9ff0387ee100323c2b7.camel@redhat.com> <1807a142-1534-4fa4-ad4b-d1c03af014c2@arinc9.com> <58d8ddea-71cc-427a-94cc-a95f6bce61d2@collabora.com> <16e9c06e-9908-455d-a387-614fefe5bcf8@arinc9.com> <5e87d31c-b059-4f9a-93f7-dc87465ed14a@collabora.com> <4416ef22-78cc-4ce5-b61d-69ff0903811e@arinc9.com> <750a60a6-4585-4bd2-97be-cf944e51fbdb@leemhuis.info> <7a2ea06b-ae4e-4374-82c2-4de4184e06c3@arinc9.com> <40035548-c76b-4b0d-915f-c513eaadbc5d@leemhuis.info> From: AngeloGioacchino Del Regno Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240625_014919_418506_CFB56906 X-CRM114-Status: GOOD ( 32.56 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Conor Dooley , linux-kernel@vger.kernel.org, Daniel Golle , linux-mediatek@lists.infradead.org, Matthias Brugger , Krzysztof Kozlowski , Frank Wunderlich , Rob Herring , linux-arm-kernel@lists.infradead.org Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Il 25/06/24 10:17, Arınç ÜNAL ha scritto: > On 25/06/2024 09.57, Linux regression tracking (Thorsten Leemhuis) wrote: >> On 25.06.24 08:17, Arınç ÜNAL wrote: >>> On 25/06/2024 08.56, Linux regression tracking (Thorsten Leemhuis) wrote: >>>> On 17.06.24 13:08, Arınç ÜNAL wrote: >>>>> On 17/06/2024 11:33, Linux regression tracking (Thorsten Leemhuis) >>>>> wrote: >>>>> [...] >>>>> I've submitted a patch series that fixes the regression. Angelo argued >>>>> against the way the regression is fixed. I've very clearly argued >>>>> back why >>>>> I find Angelo's approach wrong. There's been no response back. I don't >>>>> understand why reverting the patch is the likely outcome >>>> >>>> Long story short: because that how things like that are handled in the >>>> Linux kernel project, as Linus wants it like that. See some of the >>>> quotes from https://docs.kernel.org/process/handling-regressions.html >>>> for details. >>>> >>>>> whilst the >>>>> standing argument points towards applying the said patch series. If a >>>>> revert happens before this discussion with Angelo finalises, this >>>>> will set >>>>> a precedent that will tell maintainers that they can have their way >>>>> by just >>>>> not replying to the ongoing discussions. >>>>> >>>>> That said, the decision of resolving the regression by either >>>>> reverting the >>>>> patch or applying the patch series shall not depend on whether or not >>>>> Angelo is pleased but rather there're no counter-arguments left on the >>>>> points brought, meaning the decision shall be made depending on the >>>>> argument that stands. >>>>> >>>>> Therefore, I suggest that unless Angelo responds back with a >>>>> counter-argument in the window of a week or two, as you've described, my >>>>> patch series shall be applied. >>>> >>>> It looks more and more like we are stuck here (or was there progress and >>>> I just missed it?) while the 6.10 final is slowly getting closer. Hence: >>> >>> There hasn't been progress at all. I believe I have clearly described the >>> way out of this issue. >>> >>>> AngeloGioacchino, should we ask the net maintainers to revert >>>> 868ff5f4944aa9 ("net: dsa: mt7530-mdio: read PHY address of switch from >>>> device tree") for now to resolve this regression? Reminder, there is >>>> nothing wrong with that commit per se afaik, it just exposes a problem >>>> that needs to be fixed first before it can be reapplied. >>> >>> Are you suggesting the patch shall be reverted first, then the DT patch >>> applied, then the reverted patch applied back? >> >> Yeah. >> Sorry, I've lost your reply in the long stack of emails that I get every day. I'm not suggesting to revert the patch, but to fix it such that it does not break devices using old devicetrees, as it was the case before. Even though, in a way, when you update the kernel, you do also update the devicetrees with it just because it's almost effortless to do so, doing that is not mandatory. ...and that's why the driver, which was - in a way - faulty before, getting the switch to work even though the devicetree node was wrong, must still be compatible. I do want to apply the devicetree fix, but I also do *not* want to see *driver* changes that go against the backward compatibility rule of devicetree when this is not strictly necessary (when it is - it's okay to make an exception)... ...and this is not one of the cases in which it's strictly necessary. >>> If only one of the first two >>> steps were done, it would fix the regression so I don't understand why go >>> through this tedious process when we can quite simply apply the DT patch to >>> resolve the regression. >> >> Which DT patch do you mean here? Your series or the one from Frank at >> the start of the thread (the one you seems to be unhappy about iirc, but >> I might be wrong there)? > > My series, as arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts needs to be > addressed too to resolve the regression. > >> >> Anyway, to answer the statement: because the maintainers that would have >> to accept the DT patch to resolve the problem apparently are not happy >> with it -- and nobody seems to be working on providing patches that make >> them happy which are also acceptable at this point of the devel cycle; >> so as it looks like currently to prevent the regression from entering >> 6.10 reverting the net change is the only option left. > > I've already made my case regarding the situation with the DT patch. I > can't provide new patches because Angelo did not acknowledge my points yet. > I maintain the net driver and I too won't be happy with a revert on the > driver. > And again, I wouldn't be happy to see a revert either; just fix it so that the old devicetree still works with the driver code. Regards, Angelo