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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 40958C433B4 for ; Mon, 12 Apr 2021 23:46:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1A07360FDB for ; Mon, 12 Apr 2021 23:46:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237695AbhDLXqh (ORCPT ); Mon, 12 Apr 2021 19:46:37 -0400 Received: from new2-smtp.messagingengine.com ([66.111.4.224]:56881 "EHLO new2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237290AbhDLXqg (ORCPT ); Mon, 12 Apr 2021 19:46:36 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 62113580449; Mon, 12 Apr 2021 19:46:17 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute3.internal (MEProxy); Mon, 12 Apr 2021 19:46:17 -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=fmEbaEZe+KED5JiPxN0DVWg/HvQWdbc FjVOEUztK2NI=; b=Vx/AVcRxxdiZfCzmg6HH9s7fTRcRO2A7YIjLyLaYe8qYr0r BS6egDBjdLmYM34p470HJr5LqP5KoInLDDwqdcamk5MRSrxO7dAhMPAMUDC0dhjh vJPcgIwiLG8KOJ3uKA0GTGu1jcMQaOMSnd2WrYuTHIQZVsAWFGqkwBRXNlti55x/ 6ugOqakXKGxkr0fFLfkKWrDXxcxOVi08DvlZS08DU0g+kMkvrqeAYCT7meuT5hdW cOoZaNo0ceLqWTSGPHWkpxqHpGYT21VoEfaKHBFdWelkIXGtvA0GWL6pRx9n2reQ 6kULJBJilakY/lES25nZKfX1V5Pxebr9HcJga0Q== 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=fmEbaE Ze+KED5JiPxN0DVWg/HvQWdbcFjVOEUztK2NI=; b=RCRlZHDVBmLjCH2Y7LqZJ+ LPMZ6zfYSA6N9BRlHWDS80Td69J2sFZ47v0FrYjGX9CByF1tu62RmXm7qpQJoCd9 lyFdYNdzNHNXMTeMxpri2aLsG94InMhJ8JdMtTYuYL8jgwgeI3B/KHx/1h7FXxwW GFXGj/30mGVdydc6aQu8SVDfHYocr+6I1EzEpM+MqorxoGRXWXNhvEDsz/DFvSXa rYE3E5TnGUmIZZ4eTJZgl8j6ujkfUb41tPfnYSTWk7WZo5HbgTE0bvvQIlBDdV1N ceo9eazaMv36UwCVQ0aDxCcUePl6VUptDzGA6jyNVzZzVveA5t4xIBSb2wGGWApw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekkedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdetnhgu rhgvficulfgvfhhfvghrhidfuceorghnughrvgifsegrjhdrihgurdgruheqnecuggftrf grthhtvghrnhepuddttdekueeggedvtddtueekiedutdfguedutdefieeuteefieelteet vddthfeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnughrvgifsegrjhdrihgurdgruh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 38211A00492; Mon, 12 Apr 2021 19:46:16 -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: In-Reply-To: References: <20210319062752.145730-1-andrew@aj.id.au> <20210319062752.145730-16-andrew@aj.id.au> Date: Tue, 13 Apr 2021 09:15:55 +0930 From: "Andrew Jeffery" To: "Arnd Bergmann" Cc: "Dmitry Torokhov" , openipmi-developer@lists.sourceforge.net, "OpenBMC Maillist" , "Corey Minyard" , "Joel Stanley" , "Ryan Chen" , DTML , "Tomer Maimon" , linux-aspeed , "open list:GPIO SUBSYSTEM" , "Avi Fishman" , "Patrick Venture" , "Linus Walleij" , "Linux Kernel Mailing List" , "Tali Perry" , "Rob Herring" , "Lee Jones" , "Chia-Wei, Wang" , "Linux ARM" , "Benjamin Fair" 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 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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? > 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. > > > Both the KCS IPMI and raw chardev I've implemented in this patch need > > both read and write access to the status register (STR). serio could > > potentially expose its value through serio_interrupt() using the > > SERIO_OOB_DATA flag, but I haven't put any thought into it beyond this > > sentence. We'd need some extra support for writing STR via the serio > > API. I'm not sure that fits into the abstraction (unless we make > > serio_write() take a flags argument?). > > > > In that vein, the serio_raw interface is close to the functionality > > that the raw chardev provides in this patch, though again serio_raw > > lacks userspace access to STR. Flags are ignored in the ->interrupt() > > callback so all values received via ->interrupt() are exposed as data. > > The result is there's no way to take care of SERIO_OOB_DATA in the > > read() path. Given that, I think we'd have to expose an ioctl() to > > access the STR value after taking care of SERIO_OOB_DATA in > > ->interrupt(). > > > > I'm not sure where that lands us. > > Based on what I looked up, I think you can just forget about my original > question. We have two separate interfaces that use an Intel 8042-style > protocol, but they don't really interact. Right, this is still true given Power doesn't care for keyboards or IPMI via the keyboard controllers; the two still don't interact. Andrew