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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CE88C433B4 for ; Tue, 27 Apr 2021 16:39:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DE091613ED for ; Tue, 27 Apr 2021 16:39:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237727AbhD0QkY (ORCPT ); Tue, 27 Apr 2021 12:40:24 -0400 Received: from foss.arm.com ([217.140.110.172]:54874 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237685AbhD0QkT (ORCPT ); Tue, 27 Apr 2021 12:40:19 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 92E80D6E; Tue, 27 Apr 2021 09:39:35 -0700 (PDT) Received: from bogus (unknown [10.57.61.96]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8DE463F73B; Tue, 27 Apr 2021 09:39:33 -0700 (PDT) Date: Tue, 27 Apr 2021 17:39:13 +0100 From: Sudeep Holla To: Florian Fainelli Cc: Cristian Marussi , Jim Quinlan , Sudeep Holla , Saravana Kannan , Greg Kroah-Hartman , "Rafael J. Wysocki" , Al Cooper , Michael Walle , Jon Hunter , Marek Szyprowski , Geert Uytterhoeven , Guenter Roeck , Android Kernel Team , LKML Subject: Re: [PATCH v1 3/3] Revert "Revert "driver core: Set fw_devlink=on by default"" Message-ID: <20210427163913.svx2w2mxo4w3is32@bogus> References: <20210302211133.2244281-1-saravanak@google.com> <20210302211133.2244281-4-saravanak@google.com> <60989b90-7f8a-5306-e7d7-c5461bc9ac68@gmail.com> <23ab7a11-330c-4d3d-00c1-984c5248464e@gmail.com> <20210427074807.GI43717@e120937-lin> <20210427141116.GJ43717@e120937-lin> <20210427151042.j7hku7pxqz56uyt6@bogus> <0887ce92-e9d8-47ec-0077-4c1f2fd46f87@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0887ce92-e9d8-47ec-0077-4c1f2fd46f87@gmail.com> User-Agent: NeoMutt/20171215 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 27, 2021 at 09:24:55AM -0700, Florian Fainelli wrote: [...] > This is a self inflicted problem that we have in that the bootloader > provides a Device Tree to the kernel which is massaged in different ways > and intends to stay backwards compatible as much as possible. And indeed > after removing the 'mboxes' property gets us going with fw_devlink=on. > I assume the bootloader checks the presence of SMC support and modifies the DT node accordingly. Can't it remove the mbox properties as it make no sense with SMC compatible ? However ... > > > > 2. IIUC, the fw_devlink might use information from DT to establish the > > dependency and having mailbox information in this context may be > > considered wrong as there is no dependency if it is using SMC. > > Right, unfortunately, short of having some special casing for SCMI and > checking that if we have both an "arm,smc-id" and "mboxes" phandle we > should prefer the former, there is not probably much that can be done > here. Do we want to do that? I *think* we could do that in the SCMI drivers, but: 1. I am not sure if that helps fw_devlinks if they are deriving the info purely based on DT 2. I am also afraid that someone might come up with exactly opposite requirement that let us prefer mailbox over SMC as they would use SMC only if h/w lacks proper mailbox support. I fear that we will get into rabbit hole trying to do something like that. -- Regards, Sudeep