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=-5.3 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,USER_AGENT_SANE_1 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 0019BC43461 for ; Tue, 8 Sep 2020 12:11:45 +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 55E80206B8 for ; Tue, 8 Sep 2020 12:11:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mXF81INs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 55E80206B8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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=bQUQUDBi6Pn4WH+CsutITbdWcmKSeEc647RF2PAqWik=; b=mXF81INseAlmtHkRZbi78BBl9 YT/T0PARPOb0WVhIUnwHWsh+Sll0QxB/wzAogTPSOUTtaTWIeRZ3ZjRfOPIi5bvnjhB6EpaiFpDCb 4V4Ierq1EBA6d25yPFV7Z+7AbxB1MlUbKxHs/qQabhTFfMQhhACiGsZS5ilatnFmUUtCS61gPnMnb SwX3O7WYPqqRT1Apzpq3Rk4ooANBH2v66jdDmCEunhQvQvyNlnOaAitbVeJE+hh38UZcO2sTMg2Cs k6cbXpy/dRZsZqs7t8GO3NUoRPok1WLpus9sbIyOC1Jz30/96VvNTL+A6pi6ybPZcy3dXrc1UtZry rwXSYkHmQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFcS7-0000xO-27; Tue, 08 Sep 2020 12:10:23 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kFcS5-0000wp-2C for linux-arm-kernel@lists.infradead.org; Tue, 08 Sep 2020 12:10:21 +0000 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 5C5F431B; Tue, 8 Sep 2020 05:10:19 -0700 (PDT) Received: from bogus (unknown [10.57.10.112]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 17B453F73C; Tue, 8 Sep 2020 05:10:17 -0700 (PDT) Date: Tue, 8 Sep 2020 13:10:12 +0100 From: Sudeep Holla To: Cristian Marussi Subject: Re: [PATCH v2 0/4] firmware: arm_scmi: Enable building SCMI as module Message-ID: <20200908121012.GA11523@bogus> References: <20200907195046.56615-1-sudeep.holla@arm.com> <20200908090844.GA30729@e119603-lin.cambridge.arm.com> <20200908111105.GA16927@bogus> <20200908115305.GA6904@e119603-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200908115305.GA6904@e119603-lin.cambridge.arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200908_081021_167410_BA4B7CBB X-CRM114-Status: GOOD ( 27.32 ) 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: Mikhail Golubev , Peter Hilber , Igor Skalkin , linux-arm-kernel@lists.infradead.org, Anton Yakovlev 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 Tue, Sep 08, 2020 at 12:53:05PM +0100, Cristian Marussi wrote: > On Tue, Sep 08, 2020 at 12:11:14PM +0100, Sudeep Holla wrote: > > On Tue, Sep 08, 2020 at 10:08:44AM +0100, Cristian Marussi wrote: > > > Hi Sudeep > > > > > > On Mon, Sep 07, 2020 at 08:50:42PM +0100, Sudeep Holla wrote: > > > > Hi, > > > > > > > > Though it was initially developed as module, so some reason(I can't > > > > recollect why apart from some structuring arounf the way bus and > > > > protocols were initialised), it was merged as a built-in only driver. > > > > > > > > Now, there is a need to build this as modules. This is mainly needed > > > > by virtio transport. This also aligns well with GKI modularisation > > > > efforts. > > > > > > > > Regards, > > > > Sudeep > > > > > > > > > > I re-tested this v2 (also regarding some interactions with notifications) and > > > works generally fine for me, both builtin or modularized, BUT I've seen an > > > issue on core module load/unload/load. > > > Basically doing this: > > > > > > (debian-arm64)root@debarm64:~# insmod ./scmi-module.ko > > > (debian-arm64)root@debarm64:~# insmod ./scmi-cpufreq.ko > > > > > > (debian-arm64)root@debarm64:~# rmmod ./scmi-cpufreq.ko > > > (debian-arm64)root@debarm64:~# rmmod ./scmi-module.ko > > > (debian-arm64)root@debarm64:~# lsmod > > > Module Size Used by > > > (debian-arm64)root@debarm64:~# insmod ./scmi-module.ko > > > > > > I've got this: > > > > > > > > > [ 146.982413] mhu 2b1f0000.mhu: Channel in use > > > [ 146.982433] arm-scmi firmware:scmi: failed to request SCMI Tx mailbox > > > [ 146.982472] arm-scmi: probe of firmware:scmi failed with error -16 > > > > > > and SCMI is broken then after reloading. > > > > > > Now this is an issue I've seen already in my ongoing WIP on full SCMI Protocols > > > modularization for custom protocols, and it is related to the fact the the > > > underlying transport init is bound to the SCMI device creation and not the > > > protocol initialization, and we are not destroying and re-creating such > > > devices properly. (things that I'm going to address in that WIP) > > > > > > Given that the solution to this is not so simple as of now, and given that > > > unloading of the core as a whole module does not make so much sense anyway > > > (while it will be needed for single custom protocols modules), couldn't we > > > just make scmi-module a permanent by droppping module_exit() ? > > > > Now I remember why I had bus_exit before unregistering the driver. I think > > that should fix the issue. Let me know. > > > > Yes that works for me, both as builtin or as a module now. > With that fix, can I take this as: Tested-by: Cristian Marussi -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel