From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C3D1C8F5E; Fri, 11 Oct 2024 13:47:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728654435; cv=none; b=hCKIjZCcYluOykxGy/byU1cxI5gotFHAUDaOsdZkGn0WNR/UQG//9pbQx1I3HhU+8CO+nO+PPPZbJ9cwsz/+YxQTHFBm8cmyCBh6Bm9HpdWdyLYqcI/FLBm6f+ATZYMKQZlvP3+Nmy4ZFKlFmIvnpaUBY1EbNAGBNQ86/RzAtt4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1728654435; c=relaxed/simple; bh=4hWK7owCdQ8AZEtitrIBPKLbtijxQ0BNhtAY2CySHqo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l6k+YgeaLWmMQqmMPl/RVBYat/hNUw0gK2/wAjagAh9lIp+2c8dP0qkO9cP8OxlU4wz3AJE0b8pNapKoClZe/zV8/j6S+KhWtBq5xX5jCvJ5Mer4v/OHB+unisjsdN90TIJkyDr/RUCowHz/YdI9DBln7VzccoscwoipBmRM/Ms= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 B45E2497; Fri, 11 Oct 2024 06:47:42 -0700 (PDT) Received: from pluto (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 82FF23F5A1; Fri, 11 Oct 2024 06:47:10 -0700 (PDT) Date: Fri, 11 Oct 2024 14:47:07 +0100 From: Cristian Marussi To: Florian Fainelli Cc: linux-arm-kernel@lists.infreadead.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sudeep Holla , Cristian Marussi , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , "open list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE" , "moderated list:SYSTEM CONTROL & POWER/MANAGEMENT INTERFACE" , justin.chen@broadcom.com, opendmb@gmail.com, kapil.hali@broadcom.com, bcm-kernel-feedback-list@broadcom.com, Arnd Bergmann Subject: Re: [PATCH v2] firmware: arm_scmi: Give SMC transport precedence over mailbox Message-ID: References: <20241007235413.507860-1-florian.fainelli@broadcom.com> Precedence: bulk X-Mailing-List: arm-scmi@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: <20241007235413.507860-1-florian.fainelli@broadcom.com> On Mon, Oct 07, 2024 at 04:54:13PM -0700, Florian Fainelli wrote: > Broadcom STB platforms have for historical reasons included both > "arm,scmi-smc" and "arm,scmi" in their SCMI Device Tree node compatible > string, in that order. > > After the commit cited in the Fixes tag and with a kernel configuration > that enables both the SMC and the Mailbox transports, we would probe > the mailbox transport, but fail to complete since we would not have a > mailbox driver available. With each SCMI transport being a platform > driver with its own set of compatible strings to match, rather than an > unique platform driver entry point, we no longer match from most > specific to least specific. There is also no simple way for the mailbox > driver to return -ENODEV and let another platform driver attempt > probing. This leads to a platform with no SCMI provider, therefore all > drivers depending upon SCMI resources are put on deferred probe forever. > > By keeping the SMC transport objects linked first, we can let the > platform driver match the compatible string and probe successfully with > no adverse effects on platforms using the mailbox transport. > > Fixes: b53515fa177c ("firmware: arm_scmi: Make MBOX transport a standalone driver") > Signed-off-by: Florian Fainelli I was hoping to find some way to avoid this workaround.... ...but I failed :P ... so LGTM. Reviewed-by: Cristian Marussi Thanks, Cristian