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 EBF84CFB44F for ; Mon, 7 Oct 2024 17:09:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:References:Cc:To:Subject:From: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=1Xsz1cKkpJKzKS5NgU8P9HM5AvWEcAQxgUYBZ/hb0Eo=; b=yni3mHaYk0oS3iRbzMwUC+qNaI x5gluedOiuNanYy/w64dBwLw8cl+x0eFbSwdIjkGKiyVTZQOotuUFdjJo4+d4HJNTIn4d9AnTRZxS 2tcFEr44uMVN6u5wcoo9VrRE4wG2kC5Mo4IMG1uw6jTFz0G8iJZIdbnS0UBMyzG9a91xIVmHxt6mp vDyUG6WRzvH9DJEyAQReVGtdYabCbf4dqSX0VkH7eCKS+F9h2BdtrILhQjMSUoOLchov0PdCzACwi DXSciCLWQ9lkkTs9aNARf8om3ZgN+6J4WGnjwskjKBCEs/nRaa9GsKthP4ZDGk2einzmuzds49LXg RSYwwBMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sxrEw-00000003HvJ-24nD; Mon, 07 Oct 2024 17:09:46 +0000 Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sxrD4-00000003HZb-17MU for linux-arm-kernel@lists.infradead.org; Mon, 07 Oct 2024 17:07:51 +0000 Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-2e0894f1b14so3463139a91.1 for ; Mon, 07 Oct 2024 10:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1728320869; x=1728925669; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=1Xsz1cKkpJKzKS5NgU8P9HM5AvWEcAQxgUYBZ/hb0Eo=; b=e1Lq02SDt7UBsnhwY0enJiC/8IAGrVuMPOhVLlj8fPCVALSzXZOXrKnsrt92b1YTZ1 uluKKCMbvTI26TyW13/gq9RBPZR8XaF+r/wW7csb32g9o+NlmLRZmH1NDr8F1Zw2oh3x w9wnl1azwiA1BQ7jIzW8Q73On7OWil4Rgl7Dw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728320869; x=1728925669; h=content-transfer-encoding:in-reply-to:autocrypt:content-language :references:cc:to:subject:from:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1Xsz1cKkpJKzKS5NgU8P9HM5AvWEcAQxgUYBZ/hb0Eo=; b=SbWJQEZmlzAMHWz+DDxHVZtFgIWUl8NmAFFOJdeMT/R+EPuvnpP5IAbGQn25akVI3U PrMFnOOOpqr/uV6YQLiK7hexWzBF8G2AcpZPH7iEpm8zqLe/v76rzBbH8rxHNQz7z/Q/ jmAOUrnNiTPE4FEw+jVgg18HBZEhzs61ALkFpMcZG7kU26IfCTim2FFpt9a+ULs2YCWK GcuRZhnnlAh7eAIEjtLf1h0YkyPrERwojAltz5PNnYUlyR6hYipf6eFBN1JkugJhXIiV b+1GR4IfGuQnfaGXwtdVT1sWvtykauul+HwSsN1XimiVXnpjBgsHV8QurqEyw0m0kJt6 kPpw== X-Forwarded-Encrypted: i=1; AJvYcCVoB0CIjxLYGrd3pUXTeOqnswBxCT6nksx/XKApfetARMsEOyhOPQ5lPUlJJj+l464avtxVHJSfKc1cuemNmOHt@lists.infradead.org X-Gm-Message-State: AOJu0Yx33iqiG47HFgHqzv8arHMzKR3WHLxnZVYMrJx/+hhg589vN2w1 X0aYTNCzUyaLlgS7lDtYbCTHp109ffhAixy1z1UYxGBy33VKZcd/XeV1Ni7t5w== X-Google-Smtp-Source: AGHT+IGafgSzyj7H334JaowYq/bSl0luswUi03Ck5xtcg5AC+8GL0Qp4QvzU6hyPq89Q2aXo/BBkdg== X-Received: by 2002:a17:90a:ce87:b0:2c9:649c:5e08 with SMTP id 98e67ed59e1d1-2e1e6226d7bmr13956400a91.15.1728320869018; Mon, 07 Oct 2024 10:07:49 -0700 (PDT) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2e1e85d96bfsm7420819a91.27.2024.10.07.10.07.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Oct 2024 10:07:48 -0700 (PDT) Message-ID: Date: Mon, 7 Oct 2024 10:07:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Florian Fainelli Subject: Re: [PATCH] firmware: arm_scmi: Give SMC transport precedence over mailbox To: Cristian Marussi Cc: linux-arm-kernel@lists.infread.org, Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sudeep Holla , "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 References: <20241006043317.3867421-1-florian.fainelli@broadcom.com> Content-Language: en-US Autocrypt: addr=florian.fainelli@broadcom.com; keydata= xsBNBFPAG8ABCAC3EO02urEwipgbUNJ1r6oI2Vr/+uE389lSEShN2PmL3MVnzhViSAtrYxeT M0Txqn1tOWoIc4QUl6Ggqf5KP6FoRkCrgMMTnUAINsINYXK+3OLe7HjP10h2jDRX4Ajs4Ghs JrZOBru6rH0YrgAhr6O5gG7NE1jhly+EsOa2MpwOiXO4DE/YKZGuVe6Bh87WqmILs9KvnNrQ PcycQnYKTVpqE95d4M824M5cuRB6D1GrYovCsjA9uxo22kPdOoQRAu5gBBn3AdtALFyQj9DQ KQuc39/i/Kt6XLZ/RsBc6qLs+p+JnEuPJngTSfWvzGjpx0nkwCMi4yBb+xk7Hki4kEslABEB AAHNMEZsb3JpYW4gRmFpbmVsbGkgPGZsb3JpYW4uZmFpbmVsbGlAYnJvYWRjb20uY29tPsLB IQQQAQgAywUCZWl41AUJI+Jo+hcKAAG/SMv+fS3xUQWa0NryPuoRGjsA3SAUAAAAAAAWAAFr ZXktdXNhZ2UtbWFza0BwZ3AuY29tjDAUgAAAAAAgAAdwcmVmZXJyZWQtZW1haWwtZW5jb2Rp bmdAcGdwLmNvbXBncG1pbWUICwkIBwMCAQoFF4AAAAAZGGxkYXA6Ly9rZXlzLmJyb2FkY29t Lm5ldAUbAwAAAAMWAgEFHgEAAAAEFQgJChYhBNXZKpfnkVze1+R8aIExtcQpvGagAAoJEIEx tcQpvGagWPEH/2l0DNr9QkTwJUxOoP9wgHfmVhqc0ZlDsBFv91I3BbhGKI5UATbipKNqG13Z TsBrJHcrnCqnTRS+8n9/myOF0ng2A4YT0EJnayzHugXm+hrkO5O9UEPJ8a+0553VqyoFhHqA zjxj8fUu1px5cbb4R9G4UAySqyeLLeqnYLCKb4+GklGSBGsLMYvLmIDNYlkhMdnnzsSUAS61 WJYW6jjnzMwuKJ0ZHv7xZvSHyhIsFRiYiEs44kiYjbUUMcXor/uLEuTIazGrE3MahuGdjpT2 IOjoMiTsbMc0yfhHp6G/2E769oDXMVxCCbMVpA+LUtVIQEA+8Zr6mX0Yk4nDS7OiBlvOwE0E U8AbwQEIAKxr71oqe+0+MYCc7WafWEcpQHFUwvYLcdBoOnmJPxDwDRpvU5LhqSPvk/yJdh9k 4xUDQu3rm1qIW2I9Puk5n/Jz/lZsqGw8T13DKyu8eMcvaA/irm9lX9El27DPHy/0qsxmxVmU pu9y9S+BmaMb2CM9IuyxMWEl9ruWFS2jAWh/R8CrdnL6+zLk60R7XGzmSJqF09vYNlJ6Bdbs MWDXkYWWP5Ub1ZJGNJQ4qT7g8IN0qXxzLQsmz6tbgLMEHYBGx80bBF8AkdThd6SLhreCN7Uh IR/5NXGqotAZao2xlDpJLuOMQtoH9WVNuuxQQZHVd8if+yp6yRJ5DAmIUt5CCPcAEQEAAcLB gQQYAQIBKwUCU8AbwgUbDAAAAMBdIAQZAQgABgUCU8AbwQAKCRCTYAaomC8PVQ0VCACWk3n+ obFABEp5Rg6Qvspi9kWXcwCcfZV41OIYWhXMoc57ssjCand5noZi8bKg0bxw4qsg+9cNgZ3P N/DFWcNKcAT3Z2/4fTnJqdJS//YcEhlr8uGs+ZWFcqAPbteFCM4dGDRruo69IrHfyyQGx16s CcFlrN8vD066RKevFepb/ml7eYEdN5SRALyEdQMKeCSf3mectdoECEqdF/MWpfWIYQ1hEfdm C2Kztm+h3Nkt9ZQLqc3wsPJZmbD9T0c9Rphfypgw/SfTf2/CHoYVkKqwUIzI59itl5Lze+R5 wDByhWHx2Ud2R7SudmT9XK1e0x7W7a5z11Q6vrzuED5nQvkhAAoJEIExtcQpvGagugcIAJd5 EYe6KM6Y6RvI6TvHp+QgbU5dxvjqSiSvam0Ms3QrLidCtantcGT2Wz/2PlbZqkoJxMQc40rb fXa4xQSvJYj0GWpadrDJUvUu3LEsunDCxdWrmbmwGRKqZraV2oG7YEddmDqOe0Xm/NxeSobc MIlnaE6V0U8f5zNHB7Y46yJjjYT/Ds1TJo3pvwevDWPvv6rdBeV07D9s43frUS6xYd1uFxHC 7dZYWJjZmyUf5evr1W1gCgwLXG0PEi9n3qmz1lelQ8lSocmvxBKtMbX/OKhAfuP/iIwnTsww 95A2SaPiQZA51NywV8OFgsN0ITl2PlZ4Tp9hHERDe6nQCsNI/Us= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241007_100750_343870_C5E72E45 X-CRM114-Status: GOOD ( 21.55 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Cristian, On October 7, 2024 4:52:33 AM PDT, Cristian Marussi wrote: >On Sat, Oct 05, 2024 at 09:33:17PM -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. > >Hi Florian, > >did not know this.. It stems from us starting with a mailbox driver that did the SMC call, and later transitioning to the "smc" transport proper. Our boot loader provides the Device Tree blob to the kernel and we maintain backward/forward compatibility as much as possible. > >> >> After the commit cited in the Fixes tag and with a kernel >> configuration that enables both the SCMI and the Mailbox transports, we >> would probe the mailbox transport, but fail to complete since we would >> not have a mailbox driver available. >> >Not sure to have understood this... > >...you mean you DO have the SMC/Mailbox SCMI transport drivers compiled >into the Kconfig AND you have BOTH the SMC AND Mailbox compatibles in >DT, BUT your platform does NOT physically have a mbox/shmem transport >and as a consequence, when MBOX probes (at first), you see an error from >the core like: > > "arm-scmi: unable to communicate with SCMI" > >since it gets no reply from the SCMI server (being not connnected via >mbox) and it bails out .... am I right ? In an unmodified kernel where both the "mailbox" and "smc" transports are enabled, we get the "mailbox" driver to probe first since it matched the "arm,scmi" part of the compatible string and it is linked first into the kernel. Down the road though we will fail the initialization with: [ 1.135363] arm-scmi arm-scmi.1.auto: Using scmi_mailbox_transport [ 1.141901] arm-scmi arm-scmi.1.auto: SCMI max-rx-timeout: 30ms [ 1.148113] arm-scmi arm-scmi.1.auto: failed to setup channel for protocol:0x10 [ 1.155828] arm-scmi arm-scmi.1.auto: error -EINVAL: failed to setup channels [ 1.163379] arm-scmi arm-scmi.1.auto: probe with driver arm-scmi failed with error -22 Because the platform device is now bound, and there is no mechanism to return -ENODEV, we won't try another transport driver that would attempt to match the other compatibility strings. That makes sense because in general you specify the Device Tree precisely, and you also have a tailored kernel configuration. Right now this is only an issue using arm's multi_v7_defconfig and arm64's defconfig both of which that we intend to keep on using for CI purposes. > >If this is the case, without this patch, after this error and the mbox probe >failing, the SMC transport, instead, DO probe successfully at the end, right ? With my patch we probe the "smc" transport first and foremost and we successfully initialize it, therefore we do not even try the "mailbox" transport at all, which is intended. > >IOW, what is the impact without this patch, an error and a delay in the >probe sequence till it gets to the SMC transport probe 9as second >attempt) or worse ? (trying to understand here...) There is no recovery without the patch, we are not giving up the arm_scmi platform device because there is no mechanism to return -ENODEV and allow any of the subsequent transport drivers enabled to attempt to take over the platform device and probe it again. Thanks! -- Florian