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 6E374C636CC for ; Mon, 13 Feb 2023 12:11:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc: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=gkQDThxx9uBEIuqjkmmaCU15HOolgrWyntTe6QFItRo=; b=oLsyOFfgaqufOH GxDWp/2c4je7XDE9Zis9USB6tbMmL/3xqhKdqOv1//+u9Xs/sy25QGqqLEsCgFnH80N/G98K6VaX+ SN62BrdGIr/6TzNL6lUtrjpERYM/FQ23H8WULKUp88ocMO29SU2fy86kZ29wJl/W7ybigtlvinU96 vFeObocTql9tCyfraNYp+P9P8t8IZSpwYyyvj5V83dGMgnwtZ2QhPkzCXyfh5/JemUeM1jTGSA/J1 guHvXilcZfb/SrUi4vkW3cwfx+6ZGWS2M0FjQuWalwt/JpwbdKegh0UmpMyoKLKoHcEWLANGI6z+i uC+RHKg/wGL/ufj/CIvg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pRXfL-00EZrN-ON; Mon, 13 Feb 2023 12:10:39 +0000 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pRXfH-00EZkC-08 for linux-arm-kernel@lists.infradead.org; Mon, 13 Feb 2023 12:10:36 +0000 Received: by mail-wm1-x32e.google.com with SMTP id j29-20020a05600c1c1d00b003dc52fed235so8846130wms.1 for ; Mon, 13 Feb 2023 04:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=9MaV0V+7vWugnBV1ToolFUuuNSy4tV5osQNFJ4N+ljw=; b=PSq69g92d9LKqQNBdzaFMIQ7WRDNvGmXjHLTpbtOKyT2QNfe95h38EVbbFa2G7UcLy zDV/EnTJamYgnLq5t2KbZbVASQKaOmVvWl7MKSQaZ4NgWBpCpDh1unROKzC/rXmx84mx /lM82PfGy7AvlhpdvQpFZIg2rLTuo0MLHwI6aI08XH94aIKVl6maSc0h4F+bsxoAeyE/ NdQ4W8G0uUvEgEWOFdqxXDT+4RzkO4PAlleJ/PD0fsj3fQ6bRnCx4GiYBbU2poycHkyc mSzLgbc/xrj83O52tTAIYVsvS/p+Eb5fUubGXsy+2igGi/Uz1SAoiZgTU8NVeEBFuRrC 7LqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9MaV0V+7vWugnBV1ToolFUuuNSy4tV5osQNFJ4N+ljw=; b=l0gyE7EB3fOPUB0OxntgE+oldDWzj6dQCgL32SDzXIscVdlNTw9zvqHvl0LQgYhWhv we/Kbbpqpech/gHRaButEhKWyBI08/CDuLjPOMm0X/Z8mPkXcgUPyVN/yuIvsvrps3dW g1G4hi9TsTSv/7a6A6j7OzER1fjoRGF8bRn3DQaptDF9KKXRL9wpoFmQP4Y9DHv465Kh L3IUpF3hDHMCZAkZMgEFimiqtOs7LqH5usKyn5+KP7X+npwO9I5duFeKDlbBjsubNqrG ohuF54U1iPQ1/I3pUsEw8xbW3wc0lnTAwmhovgHf6HLqrkjKfhXGpWYNwc4ri+tIx/O0 BGFw== X-Gm-Message-State: AO0yUKVmm1wphH7C63yKkw0C6XxbZ3AKQN8yYXUttW34nBrrpuKJnTXi /xUOu4AqeDWAr+UxRYgXXkNJtDM8hZxK1YO7 X-Google-Smtp-Source: AK7set8bQ8INp/EJISlse7CDCP/1ExXeTUzaodeinMKBFLAToTqtqUVeMmw/ZfxSvpikfwKgdgrKsg== X-Received: by 2002:a05:600c:a295:b0:3dd:1bcc:eb17 with SMTP id hu21-20020a05600ca29500b003dd1bcceb17mr18735513wmb.28.1676290224741; Mon, 13 Feb 2023 04:10:24 -0800 (PST) Received: from [192.168.1.109] ([178.197.216.144]) by smtp.gmail.com with ESMTPSA id c15-20020adffb4f000000b002c5441dae62sm9119007wrs.17.2023.02.13.04.10.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Feb 2023 04:10:24 -0800 (PST) Message-ID: Date: Mon, 13 Feb 2023 13:10:23 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 02/17] dt-bindings: arm: apple: apple,pmgr: Add t8112-pmgr compatible Content-Language: en-US To: Janne Grunau Cc: Hector Martin , Sven Peter , Alyssa Rosenzweig , Rob Herring , Krzysztof Kozlowski , Mark Kettenis , asahi@lists.linux.dev, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230202-asahi-t8112-dt-v1-0-cb5442d1c229@jannau.net> <20230202-asahi-t8112-dt-v1-2-cb5442d1c229@jannau.net> <5ebf96d9-689a-f915-29b8-31af891fc63f@linaro.org> <20230213115741.GA17933@jannau.net> From: Krzysztof Kozlowski In-Reply-To: <20230213115741.GA17933@jannau.net> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230213_041035_218232_6EDC01E9 X-CRM114-Status: GOOD ( 22.23 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 13/02/2023 12:57, Janne Grunau wrote: > On 2023-02-13 12:10:36 +0100, Krzysztof Kozlowski wrote: >> On 12/02/2023 16:41, Janne Grunau wrote: >>> The block on Apple M2 SoCs is compatible with the existing driver so >>> just add its per-SoC compatible. >>> >>> Signed-off-by: Janne Grunau >>> >>> --- >>> This trivial dt-bindings update should be merged through the asahi-soc >>> tree to ensure validation of the Apple M2 (t8112) devicetrees in this >>> series. >> >> No, the bindings go via subsystem. Just because you want to validate >> something is not really a reason - you can validate on next. Don't >> create special rules for Asahi... or rather - why Asahi is special than >> everyone else? > > We did that 2 or 3 times in the past without commnts that it is not > desired so I wasn't aware that this would be special handling. > > Merging binding and devicetree updates together looks to me like the > most sensible option since dtbs validation is the only testable > dependecy of dt binding updates. But it is not the recommended practice. Bindings were always going with drivers and this was said by Rob multiple times. For sure if there is no driver update at all or subsystem maintainer is not responsive, bindings were picked up by SoC folks, but it's rather fallback, not the main path. > Keeping them together ensures the dtbs validate without delaying > devicetree changes by one kernel release after the dt-bindings change > was merged. dtbs will validate on next and in next release the same way if bindings go via subsystem. I don't see the benefit nor any difference for validation. What type of delay? Why would you ever need it? > I suppose it works out most of the time if the merge request is sent > only if it validates in next. That still depends on the merge order in > the merge window but -rc1 should be fine. There is no requirement of dtbs_check for bisectability. Bindings are separate (also exported to other users), thus it is expected to have here async. > > I'll consider devicetree validation as eventually valid from now on and > not care too much about it. Everything will validate once reaches next as well... Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel