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=-14.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 D6EB0C4361B for ; Fri, 11 Dec 2020 19:39:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9ACBE23D97 for ; Fri, 11 Dec 2020 19:39:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388254AbgLKSE0 (ORCPT ); Fri, 11 Dec 2020 13:04:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:40410 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388652AbgLKSD6 (ORCPT ); Fri, 11 Dec 2020 13:03:58 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 305DF23D3C; Fri, 11 Dec 2020 18:03:17 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1knml9-000Wtq-4f; Fri, 11 Dec 2020 18:03:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 11 Dec 2020 18:03:15 +0000 From: Marc Zyngier To: Saravana Kannan Cc: Robin Murphy , Qian Cai , "Rafael J. Wysocki" , "Rafael J. Wysocki" , Len Brown , Greg Kroah-Hartman , Ard Biesheuvel , Rob Herring , Frank Rowand , Thomas Gleixner , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Grygorii Strashko , Stephen Rothwell , linux-efi , LKML , ACPI Devel Maling List , Tomi Valkeinen , Laurent Pinchart , Android Kernel Team , Linux Next Mailing List , linux-arm-kernel Subject: Re: [PATCH v2 16/17] driver core: Refactor fw_devlink feature In-Reply-To: References: <20201121020232.908850-1-saravanak@google.com> <20201121020232.908850-17-saravanak@google.com> <02e7047071f0b54b046ac472adeeb3fafabc643c.camel@redhat.com> <788ee1c7-0ea2-33ec-658e-50707f7515a6@arm.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <813b3fbd80ad4dfee7ff8517d4829a1f@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: saravanak@google.com, robin.murphy@arm.com, qcai@redhat.com, rjw@rjwysocki.net, rafael@kernel.org, lenb@kernel.org, gregkh@linuxfoundation.org, ardb@kernel.org, robh+dt@kernel.org, frowand.list@gmail.com, tglx@linutronix.de, devicetree@vger.kernel.org, grygorii.strashko@ti.com, sfr@canb.auug.org.au, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com, kernel-team@android.com, linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 2020-12-11 17:51, Saravana Kannan wrote: > On Fri, Dec 11, 2020 at 8:34 AM Robin Murphy > wrote: >> >> On 2020-12-11 14:11, Qian Cai wrote: >> > On Fri, 2020-11-20 at 18:02 -0800, Saravana Kannan wrote: >> >> The current implementation of fw_devlink is very inefficient because it >> >> tries to get away without creating fwnode links in the name of saving >> >> memory usage. Past attempts to optimize runtime at the cost of memory >> >> usage were blocked with request for data showing that the optimization >> >> made significant improvement for real world scenarios. >> >> >> >> We have those scenarios now. There have been several reports of boot >> >> time increase in the order of seconds in this thread [1]. Several OEMs >> >> and SoC manufacturers have also privately reported significant >> >> (350-400ms) increase in boot time due to all the parsing done by >> >> fw_devlink. >> >> >> >> So this patch uses all the setup done by the previous patches in this >> >> series to refactor fw_devlink to be more efficient. Most of the code has >> >> been moved out of firmware specific (DT mostly) code into driver core. >> >> >> >> This brings the following benefits: >> >> - Instead of parsing the device tree multiple times during bootup, >> >> fw_devlink parses each fwnode node/property only once and creates >> >> fwnode links. The rest of the fw_devlink code then just looks at these >> >> fwnode links to do rest of the work. >> >> >> >> - Makes it much easier to debug probe issue due to fw_devlink in the >> >> future. fw_devlink=on blocks the probing of devices if they depend on >> >> a device that hasn't been added yet. With this refactor, it'll be very >> >> easy to tell what that device is because we now have a reference to >> >> the fwnode of the device. >> >> >> >> - Much easier to add fw_devlink support to ACPI and other firmware >> >> types. A refactor to move the common bits from DT specific code to >> >> driver core was in my TODO list as a prerequisite to adding ACPI >> >> support to fw_devlink. This series gets that done. >> >> >> >> [1] - https://lore.kernel.org/linux-omap/ea02f57e-871d-cd16-4418-c1da4bbc4696@ti.com/ >> >> Signed-off-by: Saravana Kannan >> >> Tested-by: Laurent Pinchart >> >> Tested-by: Grygorii Strashko >> > >> > Reverting this commit and its dependency: >> > >> > 2d09e6eb4a6f driver core: Delete pointless parameter in fwnode_operations.add_links >> > >> > from today's linux-next fixed a boot crash on an arm64 Thunder X2 server. >> >> Since the call stack implicates the platform-device-wrangling we do in >> IORT code I took a quick look; AFAICS my guess would be it's blowing >> up >> trying to walk a zeroed list head since "driver core: Add >> fwnode_init()" >> missed acpi_alloc_fwnode_static(). > > Thanks Robin. I'm pretty sure this is the reason. I thought I fixed > all ACPI cases, but clearly I missed this one. I'll send out a patch > for this today. If you think there are any other places I missed > please let me know. I'll try some git grep foo to see if I missed any > other instances of fwnode ops being set. Yup, that fixed it here (QDF2400). Thanks, M. diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 39263c6b52e1..2630c2e953f7 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -55,7 +55,7 @@ static inline struct fwnode_handle *acpi_alloc_fwnode_static(void) if (!fwnode) return NULL; - fwnode->ops = &acpi_static_fwnode_ops; + fwnode_init(fwnode, &acpi_static_fwnode_ops); return fwnode; } -- Jazz is not dead. It just smells funny... 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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 150E6C4361B for ; Fri, 11 Dec 2020 18:04:39 +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 BBF5A23D3C for ; Fri, 11 Dec 2020 18:04:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BBF5A23D3C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aiI+pRxBnHUoeD1u6M4brR1f51xEZNcMw7AcQqoWdw8=; b=JxWccag/nwqk2UU/Ks5o5/Qaf cLhLEk63lCGiVvZRkdCEBtXWyckLHfQclbg848jqk7RVm2YiWNJMorqa4su/IfGduJ5DQCxZ6hlEr Izcgro1WLDmfegI2Iad493qTz8ne9FgDaLOhIdPaezp8YjlWN3BnHYnngByqKkjwH+a2nYIQjgX7m 3EFUQpSBTHN7EUitQvAIt1XiapKiqzDcS/QHRU+sOvCVTJQSv40vVWRk4aPX5brPHzj+9x8uSfuuk vNjTmtwPRJdgAwEDjwZY5N2DDgQi4YCjNdxLOpiWEj9lHsQDKQWW9dDYik1O6Pqcg0oQZwJSlipP6 FkRtUyNSQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1knmlF-0001cX-Ng; Fri, 11 Dec 2020 18:03:21 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1knmlD-0001by-4N for linux-arm-kernel@lists.infradead.org; Fri, 11 Dec 2020 18:03:20 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 305DF23D3C; Fri, 11 Dec 2020 18:03:17 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1knml9-000Wtq-4f; Fri, 11 Dec 2020 18:03:15 +0000 MIME-Version: 1.0 Date: Fri, 11 Dec 2020 18:03:15 +0000 From: Marc Zyngier To: Saravana Kannan Subject: Re: [PATCH v2 16/17] driver core: Refactor fw_devlink feature In-Reply-To: References: <20201121020232.908850-1-saravanak@google.com> <20201121020232.908850-17-saravanak@google.com> <02e7047071f0b54b046ac472adeeb3fafabc643c.camel@redhat.com> <788ee1c7-0ea2-33ec-658e-50707f7515a6@arm.com> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <813b3fbd80ad4dfee7ff8517d4829a1f@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: saravanak@google.com, robin.murphy@arm.com, qcai@redhat.com, rjw@rjwysocki.net, rafael@kernel.org, lenb@kernel.org, gregkh@linuxfoundation.org, ardb@kernel.org, robh+dt@kernel.org, frowand.list@gmail.com, tglx@linutronix.de, devicetree@vger.kernel.org, grygorii.strashko@ti.com, sfr@canb.auug.org.au, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com, kernel-team@android.com, linux-next@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201211_130319_351680_439EDE43 X-CRM114-Status: GOOD ( 31.10 ) 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: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-efi , Grygorii Strashko , Frank Rowand , "Rafael J. Wysocki" , Qian Cai , Greg Kroah-Hartman , Tomi Valkeinen , "Rafael J. Wysocki" , LKML , ACPI Devel Maling List , Linux Next Mailing List , Rob Herring , Laurent Pinchart , Android Kernel Team , Stephen Rothwell , Thomas Gleixner , Robin Murphy , Ard Biesheuvel , linux-arm-kernel , Len Brown Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-12-11 17:51, Saravana Kannan wrote: > On Fri, Dec 11, 2020 at 8:34 AM Robin Murphy > wrote: >> >> On 2020-12-11 14:11, Qian Cai wrote: >> > On Fri, 2020-11-20 at 18:02 -0800, Saravana Kannan wrote: >> >> The current implementation of fw_devlink is very inefficient because it >> >> tries to get away without creating fwnode links in the name of saving >> >> memory usage. Past attempts to optimize runtime at the cost of memory >> >> usage were blocked with request for data showing that the optimization >> >> made significant improvement for real world scenarios. >> >> >> >> We have those scenarios now. There have been several reports of boot >> >> time increase in the order of seconds in this thread [1]. Several OEMs >> >> and SoC manufacturers have also privately reported significant >> >> (350-400ms) increase in boot time due to all the parsing done by >> >> fw_devlink. >> >> >> >> So this patch uses all the setup done by the previous patches in this >> >> series to refactor fw_devlink to be more efficient. Most of the code has >> >> been moved out of firmware specific (DT mostly) code into driver core. >> >> >> >> This brings the following benefits: >> >> - Instead of parsing the device tree multiple times during bootup, >> >> fw_devlink parses each fwnode node/property only once and creates >> >> fwnode links. The rest of the fw_devlink code then just looks at these >> >> fwnode links to do rest of the work. >> >> >> >> - Makes it much easier to debug probe issue due to fw_devlink in the >> >> future. fw_devlink=on blocks the probing of devices if they depend on >> >> a device that hasn't been added yet. With this refactor, it'll be very >> >> easy to tell what that device is because we now have a reference to >> >> the fwnode of the device. >> >> >> >> - Much easier to add fw_devlink support to ACPI and other firmware >> >> types. A refactor to move the common bits from DT specific code to >> >> driver core was in my TODO list as a prerequisite to adding ACPI >> >> support to fw_devlink. This series gets that done. >> >> >> >> [1] - https://lore.kernel.org/linux-omap/ea02f57e-871d-cd16-4418-c1da4bbc4696@ti.com/ >> >> Signed-off-by: Saravana Kannan >> >> Tested-by: Laurent Pinchart >> >> Tested-by: Grygorii Strashko >> > >> > Reverting this commit and its dependency: >> > >> > 2d09e6eb4a6f driver core: Delete pointless parameter in fwnode_operations.add_links >> > >> > from today's linux-next fixed a boot crash on an arm64 Thunder X2 server. >> >> Since the call stack implicates the platform-device-wrangling we do in >> IORT code I took a quick look; AFAICS my guess would be it's blowing >> up >> trying to walk a zeroed list head since "driver core: Add >> fwnode_init()" >> missed acpi_alloc_fwnode_static(). > > Thanks Robin. I'm pretty sure this is the reason. I thought I fixed > all ACPI cases, but clearly I missed this one. I'll send out a patch > for this today. If you think there are any other places I missed > please let me know. I'll try some git grep foo to see if I missed any > other instances of fwnode ops being set. Yup, that fixed it here (QDF2400). Thanks, M. diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 39263c6b52e1..2630c2e953f7 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -55,7 +55,7 @@ static inline struct fwnode_handle *acpi_alloc_fwnode_static(void) if (!fwnode) return NULL; - fwnode->ops = &acpi_static_fwnode_ops; + fwnode_init(fwnode, &acpi_static_fwnode_ops); return fwnode; } -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel