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 EE100C433F5 for ; Tue, 11 Oct 2022 10:41:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=RjvJwFNfxzUMjuF/cH1YLXPMhBGh7Y9cUIfBXesTq1k=; b=0tupYHYdnyu77Q t1PdssM9oCxWMwLs+Rw2FpmwO730GLRxu7jLFTmxHPomdbxnofknCD/EvzVUUwC83eWsj4K4tzFYJ jk2ZqqJP8hyClvb9abOyfUgNibkdglti/zelr3WhnnHMMRzaJogWxk+3AMkByM7eznWRuSBzZNkii OY0KAILVkapfDKz2mU36suN3H6qkRJG/2ZO8g7ytP3fI7bIEwSGi6UdTicxPcVa4UGO6SoDb/5kMe uyjA2QSH7IiKw/btqxbGwgx7pR6dLzIqioDtEcYPhXB4UVLaj4W1onMvdlTBrzmshpd9EEhuh6RW+ NZ2r7uKd+8kbzjfKgj5A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiCh1-0041o5-IB; Tue, 11 Oct 2022 10:40:59 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oiCgx-0041mq-JH for linux-arm-kernel@lists.infradead.org; Tue, 11 Oct 2022 10:40:57 +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 13F761042; Tue, 11 Oct 2022 03:40:57 -0700 (PDT) Received: from e120937-lin (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0B8F33F766; Tue, 11 Oct 2022 03:40:49 -0700 (PDT) Date: Tue, 11 Oct 2022 11:40:47 +0100 From: Cristian Marussi To: Shivnandan Kumar Cc: sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, quic_rgottimu@quicinc.com Subject: Re: Query regarding "firmware: arm_scmi: Free mailbox channels if probe fails" Message-ID: References: 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-20221011_034055_723744_D11FE14E X-CRM114-Status: GOOD ( 19.73 ) 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Oct 11, 2022 at 03:34:45PM +0530, Shivnandan Kumar wrote: > = > Hi Cristian, > = Hi Shivnandan, > >>Ok, just out of curiosity, once done, can you point me at your downstre= am > public sources so I can see the issue and the fix that you are applying to > your trees ? > = > https://source.codeaurora.org/quic/la/kernel/msm-5.10/tree/drivers/soc/qc= om/qcom_rimps.c?h=3DKERNEL.PLATFORM.1.0.r1-07800-kernel.0 > = > I have added lock while accessing con_priv inside irq handler and shutdown > function. > = Thanks ! > = > I have one input regarding timeout from firmware, can we enable BUG on > response=A0 time out in function do_xfer based on some debug config flag,= this > will help to debug firmware timeout issue faster. > = > We will only enable that config flag during internal testing. > = I understand a sort of 'Panic-on-timeout' would be useful to just freeze the system as it is and debug, but it seems to me pretty much invasive (and generally frowned upon) to BUG_ON timeouts, given on some SCMI platforms/transports a few timeouts can happen really not so infrequently due to transient conditions during moments of peak SCMI traffic. Even though you mention to make it conditional to Kconfig, I'm not sure this could fly, especially if you want to enable only for internal testing...I'll ping Sudeep about this to see what he thinks. As an alternative, what if I try to improve SCMI tracing/debug, let's say dumping more info in dmesg about the offending (timed-out) message instead of hanging the system as a whole ? I'd have also some still-brewing-and-not-published patches to add some SCMI stats somewhere in sysfs to be able to read current SCMI errors/timeou= ts and transport anomalies, would that be of interest ? ...maybe, we could combine some of these stats and some sort of BUG_ON/WARN_ON (if it will fly eventually..) into some kind SCMI_DEBUG mode ...any input on your needs about which kind of SCMI info you'll like to see exposed by the stack would be welcome. Last but not least, since we are talking about SCMI Server/FW testing, have you (or your team) seen this work-in-progress of mine: https://lore.kernel.org/linux-arm-kernel/20220903183042.3913053-1-cristian.= marussi@arm.com/ about a new unified userspace interface to inject/snoop SCMI messages to test/fuzz/stress the SCMI server wherever it is placed ? Any feedback on the API proprosed in the cover-letter would be highly welco= me; I'll post a new V4 next week possibly, and the changes to the existing ARM = SCMI Compliance suite (mentioned in the cover) to support this new SCMI Raw mode are in their final stage too. Thanks, Cristian _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel