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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS 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 A6E34C433B4 for ; Wed, 14 Apr 2021 00:32:15 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 1A367613BA for ; Wed, 14 Apr 2021 00:32:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A367613BA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=aj.id.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4FKk252my6z30NP for ; Wed, 14 Apr 2021 10:32:13 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=aj.id.au header.i=@aj.id.au header.a=rsa-sha256 header.s=fm2 header.b=HbYw7hON; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=rHiavBpy; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=aj.id.au (client-ip=66.111.4.224; helo=new2-smtp.messagingengine.com; envelope-from=andrew@aj.id.au; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=aj.id.au header.i=@aj.id.au header.a=rsa-sha256 header.s=fm2 header.b=HbYw7hON; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=rHiavBpy; dkim-atps=neutral Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4FKk1W0Zh7z2yyK; Wed, 14 Apr 2021 10:31:42 +1000 (AEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 8F9AB580666; Tue, 13 Apr 2021 20:31:37 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute3.internal (MEProxy); Tue, 13 Apr 2021 20:31:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=knUE4eA4OJPF+HeLNfyGSHUwlIZ5VVc yXxGwT1wC3mg=; b=HbYw7hONcS2tHP0GCTKx/rYFKmy6+Sd8TH68re77bRFrgzx QfAEqd7AD81GTnpwPRTHX98f7jeTYe0eIJrVMD7TH3Ec6Gt15D3MejL0meVGrwHS J5NfluxWOHookNX0PJoE6SkGMYt5rPCJ/gQX5daohJXLfcwOVgJ3S0XrgMD3BpJR J/KSQK33bz/jrNS1sUH+Beav2jyJ94ajcCVDblqlzdIgjt5uaeDAduPXTJcqavWu 5ZWrRj3Jg1z1hCoanX2OMsAcGREhn+umQZF6L017nZowqg/gq/E70GTZD2uGK+rL 3R5nU9r7z+YX5ukYQt3oI/7NiZrlPuGorVs42ug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=knUE4e A4OJPF+HeLNfyGSHUwlIZ5VVcyXxGwT1wC3mg=; b=rHiavBpyRcIE+PMbzfzvJx Cr0oPNN4/2GPWA08i2c3zxaa0bCXP6OpOt0z9DxTj3u7rX9bODvYxWjKt9AMh9oq at3vN/9FuHI/5WPEOKa0OsHxcVXceSH7iIFcKTVpRmz/ojIULPbaVKHczk2sWa1D 24AjCtbKYoNJcRg2+JeTL2jRymF/6ytOVskQ7FqMAHT2q+YTtwiO5zxOGe4ohDAm uvED+R76YyBdT354ty/u8x0Ab/7YTrQqQyWx/hw6XS2C2LDLtBex30XxQe0GjcCM IhpOXK3epVnXqDeCFLLPJo4IKrr655YhdgYQdW1/byEQ7Fs5Z8LbDtYpNa99jNNw == X-ME-Sender:

X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeltddgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetnhgu rhgvficulfgvfhhfvghrhidfuceorghnughrvgifsegrjhdrihgurdgruheqnecuggftrf grthhtvghrnhepudevjeegleejteffgfdvudetgfdvjedujeefgfekheeitedtgedvtdei keevjeeinecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgvfiesrghjrdhiugdrrghu X-ME-Proxy:

Received: by mailuser.nyi.internal (Postfix, from userid 501) id D411AA0048E; Tue, 13 Apr 2021 20:31:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: <37e75b07-a5c6-422f-84b3-54f2bea0b917@www.fastmail.com> In-Reply-To: References: <20210319062752.145730-1-andrew@aj.id.au> <20210319062752.145730-16-andrew@aj.id.au>

Date: Wed, 14 Apr 2021 10:00:20 +0930 From: "Andrew Jeffery" To: "Arnd Bergmann" Subject: =?UTF-8?Q?Re:_[PATCH_v2_16/21]_ipmi:_kcs=5Fbmc:_Add_a_"raw"_character_de?= =?UTF-8?Q?vice_interface?= Content-Type: text/plain X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , DTML , "Chia-Wei, Wang" , Ryan Chen , Tomer Maimon , Corey Minyard , Avi Fishman , Patrick Venture , OpenBMC Maillist , Dmitry Torokhov , Linux Kernel Mailing List , Tali Perry , "open list:GPIO SUBSYSTEM" , Rob Herring , openipmi-developer@lists.sourceforge.net, Lee Jones , Linus Walleij , linux-aspeed , Benjamin Fair Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Tue, 13 Apr 2021, at 17:52, Arnd Bergmann wrote: > On Tue, Apr 13, 2021 at 1:45 AM Andrew Jeffery wrote: > > On Mon, 12 Apr 2021, at 18:18, Arnd Bergmann wrote: > > > On Mon, Apr 12, 2021 at 3:33 AM Andrew Jeffery wrote: > > > > On Fri, 9 Apr 2021, at 17:25, Arnd Bergmann wrote: > > > > > On Fri, Mar 19, 2021 at 7:31 AM Andrew Jeffery wrote: > > > > > > > > > > > > The existing IPMI chardev encodes IPMI behaviours as the name suggests. > > > > > > However, KCS devices are useful beyond IPMI (or keyboards), as they > > > > > > provide a means to generate IRQs and exchange arbitrary data between a > > > > > > BMC and its host system. > > > > > > > > > > I only noticed the series after Joel asked about the DT changes on the arm > > > > > side. One question though: > > > > > > > > > > How does this related to the drivers/input/serio/ framework that also talks > > > > > to the keyboard controller for things that are not keyboards? > > > > > > > > I've taken a brief look and I feel they're somewhat closely related. > > > > > > > > It's plausible that we could wrangle the code so the Aspeed and Nuvoton > > > > KCS drivers move under drivers/input/serio. If you squint, the i8042 > > > > serio device driver has similarities with what the Aspeed and Nuvoton > > > > device drivers are providing to the KCS IPMI stack. > > > > > > After looking some more into it, I finally understood that the two are > > > rather complementary. While the drivers/char/ipmi/kcs_bmc.c > > > is the other (bmc) end of drivers/char/ipmi/ipmi_kcs_sm.c, it seems > > > that the proposed kcs_bmc_cdev_raw.c interface would be > > > what corresponds to the other side of > > > drivers/input/serio/i8042.c+userio.c. > > > > Right. I guess the question is should we be splitting kernel subsystems > > along host/bmc lines? Doesn't feel intuitive, it's all Linux, but maybe > > we can consolidate in the future if it makes sense? > > We actually have a number of subsystems with somewhat overlapping > functionality. I brought up serio, because it has an abstraction for multiple > things that communicate over the keyboard controller and I thought > the problem you were trying to solve was also related to the keyboard > controller. > It is also one of multiple abstractions that allow you to connect a device > to a uart (along with serdev and tty_ldisc, probably at least one more that > you can nest above or below these). > > Consolidating the kcs_bmc.c interface into something that already > exists would obviously be best, but it's not clear which of these that > should be, that depends on the fundamental properties of the hardware > interface. > > > > Then again, these are also on > > > separate ports (0x60 for the keyboard controller, 0xca2 for the BMC > > > KCS), so they would never actually talk to one another. > > > > Well, sort of I guess. On Power systems we don't use the keyboard > > controller for IPMI or keyboards, so we're just kinda exploiting the > > hardware for our own purposes. > > Can you describe in an abstract form what the hardware interface > can do here and what you want from it? I wonder if it could be > part of a higher-level interface such as drivers/mailbox/ instead. It gives us interrupts each way between the host and BMC when we send some (small amount of) data/metadata. Mailbox is possibly a fit for this? We're (ab)using the keyboard controllers to implement a vendor MCTP binding over LPC[1] and also a simple protocol for the (Power) host to trigger BMC debug data capture in the event of issues with other (more complex) in-band communication stacks. The MCTP binding is what requires access to STR. It's feasible that we could implement the debug capture protocol with the serio_raw interface now that I think about it (as it only makes use of data and not status). What's unclear to me right now is what impact that has on the Aspeed/Nuvoton KCS drivers we have in the IPMI subsystem. If we can do something sensible to service both serio and IPMI with the one driver implementation then I can put together a PoC for the debug data stuff using serio_raw. Regarding the MCTP binding, Jeremy Kerr is working in an in-kernel, socket-based implementation of MCTP. Eventually this will allow us to bury the KCS details in the MCTP subsystem, which removes some of the motivation for the raw interface here. Andrew [1] https://github.com/openbmc/libmctp/blob/master/docs/bindings/vendor-ibm-astlpc.md