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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 A68B3C07E95 for ; Mon, 19 Jul 2021 23:39:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8BC826113C for ; Mon, 19 Jul 2021 23:39:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242021AbhGSW6K (ORCPT ); Mon, 19 Jul 2021 18:58:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359706AbhGSVW1 (ORCPT ); Mon, 19 Jul 2021 17:22:27 -0400 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E358C05BD16 for ; Mon, 19 Jul 2021 14:54:25 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id t186so30002428ybf.2 for ; Mon, 19 Jul 2021 14:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mgewm5mjx+FRnoLmab+NYqOB950vpM/jLC7o5sa2XM8=; b=l0R7mPgHhU+9/Prsowfdj7Q2tQ1PxSoUyzKyHKVvNc724HS7Q2DlFv99s3OP2TG/Zq lwEOjLRSF21f2rIl6xbmlp+HtCrfmG/rtgg50IMgNNhdd7MvHme0UH+zssIKkD4DysIV 9n03+QQKXy8uuwmkJD8Mr+uOSE/yA0i2iVtHLv/9GUxl+FSGRkhTePgD8pYCukp4Dyz7 nqQ6P12jnkTl+CUhabJGja6HSNCHhD9KeRBFuzhgnM8w1DbZ2CXLE0Q7Ci39eg+sf+vv GsJnL5QEKafmdGXCglA+rJ9522ssx6xe5cbdRqM+wnuZ2Iz4xFxlQvezVkADeXN2P62Z xTTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mgewm5mjx+FRnoLmab+NYqOB950vpM/jLC7o5sa2XM8=; b=Mwa3YLHeVB/WSAOEOSh7b3Uq3ASjPMMo4aCdt/4IiuX4o19tKpgQvjKf+2YUmC0mpC U3bWx76igmVhGWpCWog8PgN+yoxLmW+/taMAPxRHmtYve1XqS2NQcvFupnure/g6Pvls qMaQiZ7MpznccOH/uv/t6hPhHhFrZETxvgwG4Wy4HIUjegWIh9edZDciJ8IuM4vEkjhW G3d4RlCiz5yrQkEB2lRNCx/IzdTFLOQ0EuuBB/Su/GQGkjceMryqov2oJLDmlTlLE5ya Gv08RF6Ucr12mFyASnoN5mXq1xmQ1HipGAhUAEjInoBPgl7vwno0UYD4nhlOYGsTE4Gj yTCQ== X-Gm-Message-State: AOAM533jHCcC37DX33e4NZDZNQBqXR2WFwoFtUmrO/W6lIsihFuN16+q K9BuI/w9Tp3mmyl5ElYuq0ITlnMB6UJygh7qHK9V9w== X-Google-Smtp-Source: ABdhPJzzk8LrlzrvE22blW8gQTFo/PFlSTmtqN8jtyX4Dwh9d+eIRQ31WAGLf0IV9Ru2kTwRL7h6I1jaXreQrxJjSnI= X-Received: by 2002:a25:8b91:: with SMTP id j17mr33097786ybl.228.1626731663924; Mon, 19 Jul 2021 14:54:23 -0700 (PDT) MIME-Version: 1.0 References: <20210707045320.529186-1-john.stultz@linaro.org> In-Reply-To: From: Saravana Kannan Date: Mon, 19 Jul 2021 14:53:47 -0700 Message-ID: Subject: Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module To: Bjorn Andersson Cc: John Stultz , lkml , Catalin Marinas , Will Deacon , Andy Gross , Joerg Roedel , Thomas Gleixner , Marc Zyngier , Linus Walleij , Vinod Koul , Kalle Valo , Maulik Shah , Todd Kjos , Greg Kroah-Hartman , linux-arm-msm , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , "open list:GPIO SUBSYSTEM" , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Mon, Jul 19, 2021 at 12:36 PM Bjorn Andersson wrote: > > On Mon 19 Jul 14:00 CDT 2021, John Stultz wrote: > > > On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson > > wrote: > > > On Tue 06 Jul 23:53 CDT 2021, John Stultz wrote: > > > > Allow the qcom_scm driver to be loadable as a permenent module. > > > > > > > > This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to > > > > ensure that drivers that call into the qcom_scm driver are > > > > also built as modules. While not ideal in some cases its the > > > > only safe way I can find to avoid build errors without having > > > > those drivers select QCOM_SCM and have to force it on (as > > > > QCOM_SCM=n can be valid for those drivers). > > > > > > > > Reviving this now that Saravana's fw_devlink defaults to on, > > > > which should avoid loading troubles seen before. > > > > > > > > > > Are you (in this last paragraph) saying that all those who have been > > > burnt by fw_devlink during the last months and therefor run with it > > > disabled will have a less fun experience once this is merged? > > > Bjorn, I jump in and help with any reports of issues with fw_devlink if I'm cc'ed. Please feel free to add me and I'll help fix any issues you have with fw_devlink=on. > > > > I guess potentially. So way back when this was originally submitted, > > some folks had trouble booting if it was set as a module due to it > > loading due to the deferred_probe_timeout expiring. > > My attempts to change the default timeout value to be larger ran into > > trouble, but Saravana's fw_devlink does manage to resolve things > > properly for this case. > > > > Unfortunately I see really weird things coming out of that, e.g. display > on my db845c is waiting for the USB hub on PCIe to load its firmware, > which typically times out after 60 seconds. > > I've stared at it quite a bit and I don't understand how they are > related. Can you please add me to any email thread with the details? I'd be happy to help. First step is to make sure all the devices probe as with fw_devlink=permissive. After that if you are still seeing issues, it's generally timing issues in the driver. But if the actual timing issue is identified (by you or whoever knows the driver seeing the issue), then I can help with fixes or suggestions for fixes. > > But if folks are having issues w/ fw_devlink, and have it disabled, > > and set QCOM_SCM=m they could still trip over the issue with the > > timeout firing before it is loaded (especially if they are loading > > modules from late mounted storage rather than ramdisk). > > > > I guess we'll have to force QCOM_SCM=y in the defconfig and hope people > don't make it =m. > > > > (I'm picking this up, but I don't fancy the idea that some people are > > > turning the boot process into a lottery) > > > > Me neither, and I definitely think the deferred_probe_timeout logic is > > way too fragile, which is why I'm eager for fw_devlink as it's a much > > less racy approach to handling module loading dependencies. > > Right, deferred_probe_timeout is the main issue here. Without it we > might get some weird probe deferral runs, but either some driver is > missing or it settles eventually. > > With deferred_probe_timeout it's rather common for me to see things > end up probe out of order (even more now with fw_devlink finding cyclic > dependencies) and deferred_probe_timeout just breaking things. Again, please CC me on these threads and I'd be happy to help. > > > So if you > > want to hold on this, while any remaining fw_devlink issues get > > sorted, that's fine. But I'd also not cast too much ire at > > fw_devlink, as the global probe timeout approach for handling optional > > links isn't great, and we need a better solution. > > > > There's no end to the possible and valid ways you can setup your > defconfig and run into the probe deferral issues, so I see no point in > holding this one back any longer. I just hope that one day it will be > possible to boot the upstream kernel in a reliable fashion. Might not be believable, but I'm hoping fw_devlink helps you meet this goal :) -Saravana