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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 290FBC433F5 for ; Fri, 30 Sep 2022 12:06:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230321AbiI3MGn (ORCPT ); Fri, 30 Sep 2022 08:06:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231408AbiI3MGh (ORCPT ); Fri, 30 Sep 2022 08:06:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE6B8137445; Fri, 30 Sep 2022 05:06:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5B59562312; Fri, 30 Sep 2022 12:06:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F1F7C43470; Fri, 30 Sep 2022 12:06:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1664539592; bh=S0mIJgFJM3dB0uXkyvoEXDo0PcaqtEvOtb8hBS/fxbY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=heTjtm23rTZZUFi4PzjAN4DjWv/LUcSl0Yx3aXcuL+YSVPcRR7i/k72s5IUjC2MNV d8et357QAxsU5Hjn26cXoms6XPU26b/l8qxlrge1FBciyMHeZjHG4UHRzW7QRoJ11S M2T881APkkOAXWsSjLR2wNJwRhJSbmTolvBZQPWc= Date: Fri, 30 Sep 2022 14:06:30 +0200 From: Greg Kroah-Hartman To: Elliot Berman Cc: Bjorn Andersson , Murali Nalajala , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Andy Gross , Dmitry Baryshkov , Jassi Brar , linux-arm-kernel@lists.infradead.org, Mark Rutland , Lorenzo Pieralisi , Sudeep Holla , Marc Zyngier , Rob Herring , Krzysztof Kozlowski , Jonathan Corbet , Will Deacon , Catalin Marinas , Arnd Bergmann , devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 10/14] gunyah: sysfs: Add node to describe supported features Message-ID: References: <20220928195633.2348848-1-quic_eberman@quicinc.com> <20220928195633.2348848-11-quic_eberman@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220928195633.2348848-11-quic_eberman@quicinc.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 28, 2022 at 12:56:29PM -0700, Elliot Berman wrote: > Add a sysfs node to list the features that the Gunyah hypervisor and > Linux supports. For now, Linux support cspace (capability IDs) and > message queues, so only report those.. > > Signed-off-by: Elliot Berman > --- > Documentation/ABI/testing/sysfs-hypervisor-gunyah | 15 +++++++++++++++ > drivers/virt/gunyah/sysfs.c | 15 +++++++++++++++ > 2 files changed, 30 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-hypervisor-gunyah b/Documentation/ABI/testing/sysfs-hypervisor-gunyah > index 7d74e74e9edd..6d0cde30355a 100644 > --- a/Documentation/ABI/testing/sysfs-hypervisor-gunyah > +++ b/Documentation/ABI/testing/sysfs-hypervisor-gunyah > @@ -1,3 +1,18 @@ > +What: /sys/hypervisor/gunyah/features > +Date: October 2022 > +KernelVersion: 6.1 > +Contact: linux-arm-msm@vger.kernel.org > +Description: If running under Gunyah: > + Space separated list of features supported by Linux and Gunyah: > + "cspace": Gunyah devices > + "doorbell": Sending/receiving virtual interrupts via Gunyah doorbells > + "message-queue": Sending/receiving messages via Gunyah message queues > + "vic": Interrupt lending > + "vpm": Virtual platform management > + "vcpu": Virtual CPU management > + "memextent": Memory lending/management > + "trace": Gunyah hypervisor tracing Please no. Why do you really need this type of list? What hypervisor will NOT have them all present already? Who will use this file and what will it be used for? sysfs files should just be 1 value and not need to be parsed. Yes, we have lists of features at times, but really, you need a very very good reason why this is the only way this information can be exposed and who is going to use it in order to be able to have this accepted. thanks, greg k-h