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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 594BDC433E0 for ; Fri, 7 Aug 2020 01:42:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4455020855 for ; Fri, 7 Aug 2020 01:42:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Rb1Aia/5" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726058AbgHGBmn (ORCPT ); Thu, 6 Aug 2020 21:42:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726013AbgHGBmn (ORCPT ); Thu, 6 Aug 2020 21:42:43 -0400 Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 073C3C061575 for ; Thu, 6 Aug 2020 18:42:42 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id r11so136783pfl.11 for ; Thu, 06 Aug 2020 18:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=cAPX6D2qzJW+cM4TwCNFgYllwmjivb9JxeuNDMu8OqY=; b=Rb1Aia/5mpYUMxN9hLfbwKYrYIYeobqIFx7wpP7JvLpUfD1tC0oCip6VQfp5bQT799 FF4++SLrByMlkoblaNVMVj8ujTPzej6dSye2kyYbmUbPAMQciDE8DIMVCFi4QrMXLGn1 9mmghCPOjBC6AAwJgIeEJfLpHMo/FGQfLxgBAOMXnNlLKPq3Ou3gbd7FqihG2o9NIwKP yUYAUOyMVBk3flcgqrhsDhHKey1dKx5Pa4kIxtieOqaTiyq6IoCH9F4jq0WIYPwooMw1 yvVTs98FXs3BnMt7vjDL+e1eCi4oSniROVL5yCD6K0erbM9xd+63A1SIAtLV5RxFlw+U do2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cAPX6D2qzJW+cM4TwCNFgYllwmjivb9JxeuNDMu8OqY=; b=DtpbxkSYFvhNTA0qPcgg7qBopbCGbYTiKcE02+yvxi/4i2RQ+MsP4Ww90STOpdqcvl dpIjZB+odQYGLegTf4pJccmLGI88+uxo4/muIXNq1C13kfNHVyRL7YN3Q6EWPgkALCMp li2zJynVhhi8481yHw/7USbkIkVxRzMQpgfT8qlTP88hCA8kb1pUrJ37uA6MVDSC+NSk wX+rM2jgeAB0kXFWWCy5c7HbsWd7h9UEYxOCynqDTgV88RXiKQVuqzLTcs4Bk0h9j/wp RHgj4hbbbyC81axZ4Pvi2ubKek6IJpu3w0zOyo2XyOgIIHyNIZaF+bZBR74hymbdPrGk Co3w== X-Gm-Message-State: AOAM533UrJoV3HCUqBjLx1jPj2L5aG+nD+op1TOHbuP//+hqflAIOqRI IsNFHHtSMo8du8lJgkiU6Yyulg== X-Google-Smtp-Source: ABdhPJzj4zgIDD/7qY6szboPvWpWjPCrmFgpaapdZ8cQMmuJnqsLKWM/UU/+vw2kRylnHv/CMYglwQ== X-Received: by 2002:a63:6542:: with SMTP id z63mr10058026pgb.317.1596764561531; Thu, 06 Aug 2020 18:42:41 -0700 (PDT) Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id h12sm10507294pfr.143.2020.08.06.18.42.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2020 18:42:40 -0700 (PDT) Date: Thu, 6 Aug 2020 18:39:03 -0700 From: Bjorn Andersson To: John Stultz Cc: Steev Klimaszewski , Saravana Kannan , Thomas Gleixner , Jason Cooper , Marc Zyngier , Matthias Brugger , Andy Gross , Android Kernel Team , lkml , linux-arm-kernel , "moderated list:ARM/Mediatek SoC support" , linux-arm-msm , Hanks Chen , CC Hwang , Loda Chou Subject: Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros Message-ID: <20200807013903.GG20825@builder.lan> References: <20200718000637.3632841-1-saravanak@google.com> <20200718000637.3632841-3-saravanak@google.com> <78ad0914-6173-f753-9eba-b7cbfbb51fd6@kali.org> <20200807004001.GF20825@builder.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > wrote: > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski wrote: > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz wrote: > > > > >>> > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > >>> patch series out, as I had success with a much older version of > > > > >>> Saravana's macro magic. > > > > >>> > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > >>> building the driver in. > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > >> at the code delta. > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > to get debug output on the C630. > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > allow me to boot again. > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > a module or built-in. > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > more grace time to load. > > > > With the risk of me reading more into this than what you're saying, > > please don't upstream anything that depend this parameter to be > > increased. > > > > Compiling any of these drivers as module should not require the user to > > pass additional kernel command line parameters in order to get their > > device to boot. > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > avoid it. But the reality is that it is already required (at least in > configurations heavily using modules) to give more time for modules > loaded to resolve missing dependencies after init begins (due to > changes in the driver core to fail loading after init so that optional > dt links aren't eternally looked for). This was seen when trying to > enable the qualcom clk drivers to modules. > So to clarify what you're saying, any system that boots successfully with the default options is a sign of pure luck - regardless of being builtin or modules. And there you have my exact argument against the deferred timeout magic going on in the driver core. But as you know people insist that it's more important to be able to boot some defunct system from NFS than a properly configured one reliably. > It doesn't seem necessary in this case, but I suggested it here as > I've got it enabled by default in my AOSP builds so that the > module-heavy configs for GKI boot properly (even if Saravana's > fw_devlink work is disabled). > With all due respect, that's your downstream kernel, the upstream kernel should not rely on luck, out-of-tree patches or kernel parameters. Regards, Bjorn 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E3C82C433E0 for ; Fri, 7 Aug 2020 01:43:04 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BE27620855 for ; Fri, 7 Aug 2020 01:43:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="dqYds1JF"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Rb1Aia/5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE27620855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JE5iNpDkrkax6tNtuB0KrXpFIXBlv3pQ2xz6o9GQuRA=; b=dqYds1JFMtIFDNmWz25uEIaEa 8bJ0rIZU9pOY0pJAhuu1KWx2xTHaRN4IY1QIE3P95ecLWhiKHt37094iwEzGwpdDNw8Z0J/VLYnjz LxFM/EyDV8PZphRbVM4V5Sv4sWS/FQtREqoaqKn/9zMV9WBLAkhL7YTe2Vr7In1oX57AFH4WN5V0S Gamm3tI2RBTTz49qffSX1Y+Ok8EncHLEoffKLtuDPOGJfv+th3k6iOH+Ymz4VRv6nrjM8ZI48h5hb /WcesAOtubWLPyhA6aKXt5hVsE8Vwjk/WD1iNq46cdBl9Vdw9GWQDDmZIWH1tzZOTEG44Swk7t2o2 aL3QR4NLA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3rPF-00059p-36; Fri, 07 Aug 2020 01:42:49 +0000 Received: from mail-pg1-x543.google.com ([2607:f8b0:4864:20::543]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3rPB-00058y-4k for linux-mediatek@lists.infradead.org; Fri, 07 Aug 2020 01:42:46 +0000 Received: by mail-pg1-x543.google.com with SMTP id m34so100388pgl.11 for ; Thu, 06 Aug 2020 18:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=cAPX6D2qzJW+cM4TwCNFgYllwmjivb9JxeuNDMu8OqY=; b=Rb1Aia/5mpYUMxN9hLfbwKYrYIYeobqIFx7wpP7JvLpUfD1tC0oCip6VQfp5bQT799 FF4++SLrByMlkoblaNVMVj8ujTPzej6dSye2kyYbmUbPAMQciDE8DIMVCFi4QrMXLGn1 9mmghCPOjBC6AAwJgIeEJfLpHMo/FGQfLxgBAOMXnNlLKPq3Ou3gbd7FqihG2o9NIwKP yUYAUOyMVBk3flcgqrhsDhHKey1dKx5Pa4kIxtieOqaTiyq6IoCH9F4jq0WIYPwooMw1 yvVTs98FXs3BnMt7vjDL+e1eCi4oSniROVL5yCD6K0erbM9xd+63A1SIAtLV5RxFlw+U do2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cAPX6D2qzJW+cM4TwCNFgYllwmjivb9JxeuNDMu8OqY=; b=lhdfNfZZ5cfrflAzk/ZfIUTSAbea4vYAtmHHo4nCla2Fo2Ruuu66ebZ2I003VCpFyG CIbFRQtUt2Aa19b1hAD2FEDtmSMkdcSG2IiZJ9Pv+YXWQNQL9Du0ya1LUwo6nsk1ts7g XVkQ/U2yYbtKlr1ABd+gR0Nhc7tdBPEBYpmEqSHHCTAT8Wcoezc2DP5UxxqIGgm1jOKR 72XN6pQObzAlln5k1JrSQzIWp0cf0YkSblKnNSnbSN8oK7a0n6sE0E8dUcLoOaCS+HXx CmuI84zJLMQ7j7a8FqrtbYoBcedfKphU0m+Bx65KhLYobmc6+s4xehpzCRe4d/Hzf9SI jknA== X-Gm-Message-State: AOAM533LTpef310SZ0hFlwyf3uxXnLuBALVniNJJgBaXghLWHArPQpC/ xc4gaZb6nU/SCr5eUA5Y+/xyrw== X-Google-Smtp-Source: ABdhPJzj4zgIDD/7qY6szboPvWpWjPCrmFgpaapdZ8cQMmuJnqsLKWM/UU/+vw2kRylnHv/CMYglwQ== X-Received: by 2002:a63:6542:: with SMTP id z63mr10058026pgb.317.1596764561531; Thu, 06 Aug 2020 18:42:41 -0700 (PDT) Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id h12sm10507294pfr.143.2020.08.06.18.42.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2020 18:42:40 -0700 (PDT) Date: Thu, 6 Aug 2020 18:39:03 -0700 From: Bjorn Andersson To: John Stultz Subject: Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros Message-ID: <20200807013903.GG20825@builder.lan> References: <20200718000637.3632841-1-saravanak@google.com> <20200718000637.3632841-3-saravanak@google.com> <78ad0914-6173-f753-9eba-b7cbfbb51fd6@kali.org> <20200807004001.GF20825@builder.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200806_214245_302526_B8D49D86 X-CRM114-Status: GOOD ( 33.48 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: CC Hwang , Jason Cooper , Saravana Kannan , Marc Zyngier , Hanks Chen , Loda Chou , lkml , Steev Klimaszewski , Andy Gross , "moderated list:ARM/Mediatek SoC support" , linux-arm-msm , Matthias Brugger , Thomas Gleixner , Android Kernel Team , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > wrote: > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski wrote: > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz wrote: > > > > >>> > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > >>> patch series out, as I had success with a much older version of > > > > >>> Saravana's macro magic. > > > > >>> > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > >>> building the driver in. > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > >> at the code delta. > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > to get debug output on the C630. > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > allow me to boot again. > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > a module or built-in. > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > more grace time to load. > > > > With the risk of me reading more into this than what you're saying, > > please don't upstream anything that depend this parameter to be > > increased. > > > > Compiling any of these drivers as module should not require the user to > > pass additional kernel command line parameters in order to get their > > device to boot. > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > avoid it. But the reality is that it is already required (at least in > configurations heavily using modules) to give more time for modules > loaded to resolve missing dependencies after init begins (due to > changes in the driver core to fail loading after init so that optional > dt links aren't eternally looked for). This was seen when trying to > enable the qualcom clk drivers to modules. > So to clarify what you're saying, any system that boots successfully with the default options is a sign of pure luck - regardless of being builtin or modules. And there you have my exact argument against the deferred timeout magic going on in the driver core. But as you know people insist that it's more important to be able to boot some defunct system from NFS than a properly configured one reliably. > It doesn't seem necessary in this case, but I suggested it here as > I've got it enabled by default in my AOSP builds so that the > module-heavy configs for GKI boot properly (even if Saravana's > fw_devlink work is disabled). > With all due respect, that's your downstream kernel, the upstream kernel should not rely on luck, out-of-tree patches or kernel parameters. Regards, Bjorn _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D7A72C433E0 for ; Fri, 7 Aug 2020 01:44:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B417820855 for ; Fri, 7 Aug 2020 01:44:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IgaIYa6M"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Rb1Aia/5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B417820855 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Kkzjj2tTel2oYB2frOcoAnAb3CC5hdv9Q06g/W4Evh4=; b=IgaIYa6Mu/grvALHgNuI9rGEg qnD0jtKLf39SQAulfJSdWtfnSmcYQbMItVmdI4sS6PjLPb1+seh6zCJWeOU4scazql+7Ovvpa0REt NmgwOArEv5HXcyGdh3YRUsiAM/sSlh9vrZeFV8iGFn/NxL6AO+Joe+I52WHwrAtvJrVsp+LU0r399 CICh84jHNxXfNpUa2RiPe8tVlV17k9qqCVoN/tVo1ng5flasF6KLWxUEY6NySnXOt1pxVe9Z9cZiH K+1KmElKeCrlKbzr4UfByVDa7m5d0Ml/Ec/MOMoXz/TdKOJP7633cHN45MouwCuenlIF5uzXsyo0t fZpnsGK0g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3rPD-00059e-RG; Fri, 07 Aug 2020 01:42:47 +0000 Received: from mail-pf1-x441.google.com ([2607:f8b0:4864:20::441]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k3rPB-00058z-3l for linux-arm-kernel@lists.infradead.org; Fri, 07 Aug 2020 01:42:46 +0000 Received: by mail-pf1-x441.google.com with SMTP id m8so153127pfh.3 for ; Thu, 06 Aug 2020 18:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=cAPX6D2qzJW+cM4TwCNFgYllwmjivb9JxeuNDMu8OqY=; b=Rb1Aia/5mpYUMxN9hLfbwKYrYIYeobqIFx7wpP7JvLpUfD1tC0oCip6VQfp5bQT799 FF4++SLrByMlkoblaNVMVj8ujTPzej6dSye2kyYbmUbPAMQciDE8DIMVCFi4QrMXLGn1 9mmghCPOjBC6AAwJgIeEJfLpHMo/FGQfLxgBAOMXnNlLKPq3Ou3gbd7FqihG2o9NIwKP yUYAUOyMVBk3flcgqrhsDhHKey1dKx5Pa4kIxtieOqaTiyq6IoCH9F4jq0WIYPwooMw1 yvVTs98FXs3BnMt7vjDL+e1eCi4oSniROVL5yCD6K0erbM9xd+63A1SIAtLV5RxFlw+U do2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cAPX6D2qzJW+cM4TwCNFgYllwmjivb9JxeuNDMu8OqY=; b=fQKu2GXEUMsmYRB5PEJUn3GYkbvOD85oqZQ+ptYcoHuHlHYlQj0bL0XmjBMQLj6wOo RsCA5Li2iVxhvNcpLEtZNhLI9eKTSZqHkY2g61NMNHI0ZspoZwQAqWDNjQnWrwWNam2u sGZ0JJ45QZLwVp1geK4ZD6BkgGdh+qlud5ToqxH9sEIQzPHFlOkgS5CQx/nvh133P+J8 VD46J77aJUku9fg5MM5CAW3Tqagybll4o5IB2e25tfL+lf9XjI9Ygm/2jTd0F6tV9gTU 0nilNInvBfLxoqEPBxpI2KLNEQiyj1KUyQ9FeU1JtjElAiQeOVh/NvDK6+KT/hsCdyRN 6VUw== X-Gm-Message-State: AOAM533oOLpnD3pvmQG8kzxUwAvlkA2JURfBI+ddijZiiE9P4JYBnSpM mf81d0yIQ0k//q0M3Z4TdNV1GQ== X-Google-Smtp-Source: ABdhPJzj4zgIDD/7qY6szboPvWpWjPCrmFgpaapdZ8cQMmuJnqsLKWM/UU/+vw2kRylnHv/CMYglwQ== X-Received: by 2002:a63:6542:: with SMTP id z63mr10058026pgb.317.1596764561531; Thu, 06 Aug 2020 18:42:41 -0700 (PDT) Received: from builder.lan (104-188-17-28.lightspeed.sndgca.sbcglobal.net. [104.188.17.28]) by smtp.gmail.com with ESMTPSA id h12sm10507294pfr.143.2020.08.06.18.42.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2020 18:42:40 -0700 (PDT) Date: Thu, 6 Aug 2020 18:39:03 -0700 From: Bjorn Andersson To: John Stultz Subject: Re: [PATCH v3 2/4] irqchip/qcom-pdc: Switch to using IRQCHIP_PLATFORM_DRIVER helper macros Message-ID: <20200807013903.GG20825@builder.lan> References: <20200718000637.3632841-1-saravanak@google.com> <20200718000637.3632841-3-saravanak@google.com> <78ad0914-6173-f753-9eba-b7cbfbb51fd6@kali.org> <20200807004001.GF20825@builder.lan> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200806_214245_297786_4C60ABC2 X-CRM114-Status: GOOD ( 34.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: CC Hwang , Jason Cooper , Saravana Kannan , Marc Zyngier , Hanks Chen , Loda Chou , lkml , Steev Klimaszewski , Andy Gross , "moderated list:ARM/Mediatek SoC support" , linux-arm-msm , Matthias Brugger , Thomas Gleixner , Android Kernel Team , linux-arm-kernel 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 Thu 06 Aug 18:22 PDT 2020, John Stultz wrote: > On Thu, Aug 6, 2020 at 5:43 PM Bjorn Andersson > wrote: > > On Wed 05 Aug 14:57 PDT 2020, John Stultz wrote: > > > On Wed, Aug 5, 2020 at 2:47 PM Steev Klimaszewski wrote: > > > > On 8/5/20 4:16 PM, Steev Klimaszewski wrote: > > > > > On 8/5/20 3:19 PM, Saravana Kannan wrote: > > > > >> On Wed, Aug 5, 2020 at 12:44 AM John Stultz wrote: > > > > >>> > > > > >>> So this is where I bashfully admit I didn't get a chance to try this > > > > >>> patch series out, as I had success with a much older version of > > > > >>> Saravana's macro magic. > > > > >>> > > > > >>> But unfortunately, now that this has landed in mainline, I'm seeing > > > > >>> boot regressions on db845c. :( This is in the non-modular case, > > > > >>> building the driver in. > > > > >> Does that mean the modular version is working? Or you haven't tried > > > > >> that yet? I'll wait for your reply before I try to fix it. I don't > > > > >> have the hardware, but it should be easy to guess this issue looking > > > > >> at the code delta. > > > > > For what it's worth, I saw this too on the Lenovo C630 (started on -next > > > > > around 20200727, but I didn't track it down as, well, there's less way > > > > > to get debug output on the C630. > > > > > > > > > > In my testing, module or built-in doesn't matter, but reverting does > > > > > allow me to boot again. > > > > > > > > > Actually - I spoke too soon - QCOM_PDC built-in with the commit reverted > > > > boots, however, module (on the c630 at least) doesn't boot whether it's > > > > a module or built-in. > > > > > > You may need to set deferred_probe_timeout=30 to give things a bit > > > more grace time to load. > > > > With the risk of me reading more into this than what you're saying, > > please don't upstream anything that depend this parameter to be > > increased. > > > > Compiling any of these drivers as module should not require the user to > > pass additional kernel command line parameters in order to get their > > device to boot. > > So, ideally I agree, and Saravana's fw_devlink work should allow us to > avoid it. But the reality is that it is already required (at least in > configurations heavily using modules) to give more time for modules > loaded to resolve missing dependencies after init begins (due to > changes in the driver core to fail loading after init so that optional > dt links aren't eternally looked for). This was seen when trying to > enable the qualcom clk drivers to modules. > So to clarify what you're saying, any system that boots successfully with the default options is a sign of pure luck - regardless of being builtin or modules. And there you have my exact argument against the deferred timeout magic going on in the driver core. But as you know people insist that it's more important to be able to boot some defunct system from NFS than a properly configured one reliably. > It doesn't seem necessary in this case, but I suggested it here as > I've got it enabled by default in my AOSP builds so that the > module-heavy configs for GKI boot properly (even if Saravana's > fw_devlink work is disabled). > With all due respect, that's your downstream kernel, the upstream kernel should not rely on luck, out-of-tree patches or kernel parameters. Regards, Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel