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=-12.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PULL_REQUEST,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 BE535C433E0 for ; Tue, 7 Jul 2020 08:05: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 868C2206C3 for ; Tue, 7 Jul 2020 08:05:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="qT3RTVmi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 868C2206C3 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=mc5inP1leZFTEBcKxT1a52hyj6mI5tnvs1FEYpSVgdw=; b=qT3RTVmi7XuxSXpOpmm8UGL7n SpDbZcRfx35NvJteuhYvUUsAAgrwHMv3qivCGlfQTUAcZMyttHTH/V6XgdHHMtygeKQIy1rwczTmP l7yCIVZRPYIjjsA2Yc9TrfDvxc9Nda5Ir/l5dzrz6YsZXS3iCMhdnkdB62xYYwc7mLV6kRH9/Z2N3 UKVf4xzAEHzD+LLU4fxmC1KOHax4UyQS1CdwLw1sGrg1A8zFG2kqCYuSzU5iKO49jFRHAI2Td5zfi Tl2Jb/DTweCT051Al0fWXjvITFxNdZdVMD5lpyBwCi9wQirNEozJqlEg2gN4OWj3CU9MeMiyPNzji YFssFdlag==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsiaW-0007Lw-3O; Tue, 07 Jul 2020 08:04:24 +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 1jsiaT-0007LI-NY for linux-arm-kernel@lists.infradead.org; Tue, 07 Jul 2020 08:04:22 +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 D3B7431B; Tue, 7 Jul 2020 01:04:15 -0700 (PDT) Received: from bogus (unknown [10.37.8.63]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C33653F68F; Tue, 7 Jul 2020 01:04:13 -0700 (PDT) Date: Tue, 7 Jul 2020 09:04:10 +0100 From: Sudeep Holla To: Arnd Bergmann Subject: Re: [GIT PULL] firmware: arm_scmi: updates for v5.9 Message-ID: <20200707080410.GC10953@bogus> References: <20200706165336.40800-1-sudeep.holla@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20200707_040422_070974_58EA1D0D X-CRM114-Status: GOOD ( 28.05 ) 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: , List-Id: Cc: Kevin Hilman , SoC Team , ARM SoC Team , Cristian Marussi , Sudeep Holla , Olof Johansson , ALKML 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 Hi Arnd, On Mon, Jul 06, 2020 at 09:23:46PM +0200, Arnd Bergmann wrote: > On Mon, Jul 6, 2020 at 6:53 PM Sudeep Holla wrote: > > > > The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: > > > > Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-5.9 > > > > for you to fetch changes up to 585dfab3fb80e67b3a54790b3d5ef2991feb3950: > > > > firmware: arm_scmi: Add base notifications support (2020-07-01 17:07:26 +0100) > > > > ---------------------------------------------------------------- > > ARM SCMI/SCPI updates for v5.9 > > > > The main addition for this time is the support for platform notifications. > > SCMI protocol specification allows the platform to signal events to the > > interested agents via notification messages. We are adding support for > > the dispatch and delivery of such notifications to the interested users > > inside the kernel. > > > > Other than that, there are minor changes like checking and using the > > fast_switch capability quering the firmware instead of doing it > > unconditionally(using polling mode transfer), cosmetic trace update and > > use of HAVE_ARM_SMCCC_DISCOVERY instead of ARM_PSCI_FW. > > I haven't pulled this yet, as I noticed one data structure definition that > seems very odd: > > struct scmi_event_header { > u64 timestamp; > u8 evt_id; > size_t payld_sz; > u8 payld[]; > } __packed; > > This is an odd mix of fixed-length fields (u64) and variable length > fields (size_t is different on 32-bit machines), out of which at least > one is misaligned because of the __packed attribute. > Agreed, my mistake. I did mention to get rid of __packed in earlier version and completely missed to observe in later versions. > There are others that are just slightly odd: > > struct scmi_reset_issued_report { > u64 timestamp; > u32 agent_id; > u32 domain_id; > u32 reset_state; > /* four bytes padding */ > }; > > struct scmi_perf_level_report { > u64 timestamp; > u32 agent_id; > u32 domain_id; > u32 performance_level; > /* four bytes padding */ > }; > > struct scmi_base_error_report { > u64 timestamp; > u32 agent_id; > bool fatal; > /* 1 byte padding */ > u16 cmd_count; > u64 reports[0]; > }; > > as this includes four implied padding bytes at the end. I could not figure > out exactly what the guarantees for interface stability on either of > them are, but if these get passed between the kernel and some other > code (firmware or user space), or might be in the future, then I'd suggest > redefining them in a way that avoids those oddities. > These structures are not shared across kernel and userspace/firmware. It is entirely constructed by kernel for other users within kernel. Cristian, correct me if I am wrong ? Or add more info/clarity if it helps the discussion here. > Once this has been clarified, please just add any further patches > (if needed) on top of the existing branch and send a new pull request. > Thanks -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel