From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=aj.id.au (client-ip=66.111.4.25; helo=out1-smtp.messagingengine.com; envelope-from=andrew@aj.id.au; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=aj.id.au Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=aj.id.au header.i=@aj.id.au header.b="VfYV17mr"; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.b="LDy+p2iY"; dkim-atps=neutral Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 41KZqp4M66zF1QL for ; Tue, 3 Jul 2018 17:04:38 +1000 (AEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B5F0B218B4; Tue, 3 Jul 2018 03:04:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 03 Jul 2018 03:04:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h=cc :date:from:message-id:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=eb55P6e+P9E44e7hvt2CocvScxT2pp5aaSC7xlOo5 vs=; b=VfYV17mrv4YTWDaF/vx75pveuL053QeNWOxn8SwLjdgwuwU/70ioIv7xq BoDtf0YsbjOeowzkVk1ApOMmp9A+4Lal4dxZ0AvqEdgSANkBEYKKgWF1YkWYn9Hy qKPJ2Gp8mb37IakyWEy1fzHEEh4QMptVpIikplfcLVxXKLF1zQ2zkQR7C5pyXzUb JuRc0OItyfDRqMdtoXhl4rh/8z3oZAmKZsoai7VDLdN1RTwGkuCNGMNy2Pp8j0do tu6q9LkNYxquKOES6unZcaNIGzd6bMIzBqRlul3GhCCbKrNK1RL0bPFf7nUY5xDF QQkhJ9ms4evu8Nwxop16PwugO9N5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:date:from:message-id:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=eb55P6e+P9E44e7hv t2CocvScxT2pp5aaSC7xlOo5vs=; b=LDy+p2iYyyq3AOgbR0y2RcZe7mx18/iSr AdoPXpR63hj7kI51gNn8K8GTkQVATfDZjA1FQY5Kk02Ha6eqnvhXzKx7VJWdZ92C Fdr+UMLChbd9lgn9NWpOWvQgfh7E2OIDVTpPxku0p40WobiaLVBb4czZim+/AtJi Dssr7dFId4aFPxD6idTk6vQkDN+DYKaY+4NmVXQNK2KXyeuJaDyZWqVjd3J9pNdy ip1OpqTxdosahj56eKr7FS+3gjd3eEcUDuO+DNewrHnXaqp2Eldqav52cTjgQNKe wMmK1S1Ixmg31jUB8jOuBoNCTYe+cSZ012a/Oa/KWWpS1U3+ZJBIA== X-ME-Proxy:

X-ME-Sender: Received: from dave.bha-au.ibmmobiledemo.com (unknown [202.81.18.28]) by mail.messagingengine.com (Postfix) with ESMTPA id A672F1032F; Tue, 3 Jul 2018 03:04:29 -0400 (EDT) From: Andrew Jeffery To: linux-kernel@vger.kernel.org Cc: Andrew Jeffery , robh+dt@kernel.org, mark.rutland@arm.com, joel@jms.id.au, gregkh@linuxfoundation.org, Eugene.Cho@dell.com, a.amelkin@yadro.com, stewart@linux.ibm.com, benh@kernel.crashing.org, openbmc@lists.ozlabs.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 0/4] sysfs interface to miscellaneous BMC controls and fields Date: Tue, 3 Jul 2018 17:04:09 +1000 Message-Id: <20180703070413.28756-1-andrew@aj.id.au> X-Mailer: git-send-email 2.17.1 X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 07:04:42 -0000 X-List-Received-Date: Tue, 03 Jul 2018 07:04:42 -0000 *Dons firefighting gear* Hello, This series introduces a bmc-misc-ctrl driver for exposing hardware interfaces provided by the BMC (Baseboard Management Controller) for scratch register communication between the host and the BMC, and other miscellaneous switches controlling BMC hardware features that can be exposed to the host. Previously Ben Herrenschmidt sent mail wanting to get some consensus on a good way forward: https://lkml.org/lkml/2018/4/10/222 To summarise Ben's points: We have found that the controls we need to expose do not fit well into existing driver models for several reasons: 1. Not exposing the fields to userspace would instead mean encoding policy affecting the host system into the BMC kernel (typically scratch registers) 2. Some controls are so unique as to defy integration into other drivers 3. Exposing specific, well-constrained fields feels less evil than falling back to devmem. This series is one implementation of what we had in mind. My motivation is with respect to ASPEED BMC hardware but Dell have also indicated they would also make use of something similar for Nuvoton BMCs. To those ends, the implementation of bmc-misc-ctrl introduced here: 1. Uses devicetree to describe the miscellaneous fields and switches 2. Exposes the fields in sysfs via value/mask/set/clear attributes 3. Adds a 'bmc' class for the fields to aid discovery in userspace Now, the intent is bmc-misc-ctrl is used as a last resort. If features can sanely be exposed in more appropriate drivers, then that should (obviously) be done instead. I'm sending this out as an RFC as I'm sure people will have feedback. I hope it will be more constructive than 'NAK'. Thanks, Andrew Andrew Jeffery (4): dts: misc: Add bindings documentation for bmc-misc-ctrl Documentation: ABI: Add sysfs-class-bmc documentation to testing misc: Add bmc-misc-ctrl dts: aspeed-g5: Add bmc-misc-ctrl nodes to devicetree Documentation/ABI/testing/sysfs-class-bmc | 62 +++ .../bindings/misc/bmc-misc-ctrl.txt | 252 ++++++++++++ MAINTAINERS | 7 + arch/arm/boot/dts/aspeed-g5.dtsi | 192 +++++++++ drivers/misc/Kconfig | 8 + drivers/misc/Makefile | 1 + drivers/misc/bmc-misc-ctrl.c | 363 ++++++++++++++++++ 7 files changed, 885 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-bmc create mode 100644 Documentation/devicetree/bindings/misc/bmc-misc-ctrl.txt create mode 100644 drivers/misc/bmc-misc-ctrl.c -- 2.17.1