Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2714283pxb; Thu, 3 Feb 2022 12:33:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJynJK7kx7Nl9OQn1mu/rTRAHll0jXYeNsG2gIH8hud8zxrV3aFP4ok7cfnLyak++4xHxMdc X-Received: by 2002:a63:84c6:: with SMTP id k189mr29699402pgd.79.1643920428923; Thu, 03 Feb 2022 12:33:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643920428; cv=none; d=google.com; s=arc-20160816; b=bpbqLjB/RTNGNzVHM6lR05RSLH3t/GWXvjtcq4clZfq3gI8foCQbhXkt8Y5h27i4H6 /UUOPaDOF98l9eqG0N032DgKnLbBzrIHb4WovyQUO3TQ2DbFBkwMy9+yEzOeqt7xBiVG qNURQYwf9RaRxurLxdn+nhfsOzITOi2hPNdvpXtPEuv+NHpE7a59lhy54Htq5paBl11H MvDNPp77QW+SJYHNIneyj4ra8j4DtdN7dj3VbXQ2UfzO9XJsjPPXNkBzE0EjPMX4/dKk nRcGqTZ/ubIRHkBTUSb1m1Zg2qVMjmu46on1LY/W7bFvCKljKp0zRF57AqSDbIWUg5x6 oNgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=tWgyAh1qnHnqqfliJ9ctCqM/gHOYAbSqSRKRZngmcg4=; b=nzUv33U9y8vQQ9K3cGNTBks9f/BtBHII9rqMSOmUMmezfgk/9INY7Y4r/jJcm9A1FW kDB/UJbeCYEDgWpwTAol7vj3xgTC7zKUqEvMmg/4BfXHVXCeDWJmK5rxkidP3xPgnaHE 1Ll3hg9E0qn8VuVIVdnz8PtAICPkzmc/nw+htfrztWxsD8nxGbbsaFVz8b34qxoDMMoj 4395j/EW4qw1sMMxPZ/Wtx3MuIYbrYG1tFtZ5DdkV4qUw6H8y5YeZNSaJzY8H+GFd47W iczUYVOkT6nV0vODzx+ySI6xGYcvJQMkuKPPqydRB6pWvn20T+/LdDltw4o6y95212PH PvZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=DIEN2TWS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mi17si9783464pjb.99.2022.02.03.12.33.37; Thu, 03 Feb 2022 12:33:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=DIEN2TWS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242681AbiBBITS (ORCPT + 99 others); Wed, 2 Feb 2022 03:19:18 -0500 Received: from mga12.intel.com ([192.55.52.136]:54667 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231628AbiBBITR (ORCPT ); Wed, 2 Feb 2022 03:19:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643789957; x=1675325957; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=8FUTnB+neOfsiAnGwSfgWEkpPzljgOQLUdu2mTTAd70=; b=DIEN2TWSRhKH4fLn9vBpa8L8kKMkx0ferOO6+OJJnFAMj6dZPgjWG7HE 9bLsAa3vhF5pwaj6cUedRmxnJ4+8A3/6FAt7zw3Dg/aPvUqfJbhDrQcli WWYNQyhdSrzdDqyjdlqW//EYXTbKQ0xwybzDFvlXQgsInjX1FX/kNFckY xebsjPiT55lnRbExuYSZ41rKJi93j/Ops3ewByHRJZxa9AphR4UfUPLRg 9nUTTF1TCkDhwRtwhAlPq2istDHgBio1LZb8umR8O1OKyQBOVSlka3GEW CGZDgzEPjd4+H1iHshYRYHIbvKEy0hA3NURLF1uAhjpk/+M05s9As58qd A==; X-IronPort-AV: E=McAfee;i="6200,9189,10245"; a="227838065" X-IronPort-AV: E=Sophos;i="5.88,336,1635231600"; d="scan'208";a="227838065" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Feb 2022 00:19:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,336,1635231600"; d="scan'208";a="676365354" Received: from kuha.fi.intel.com ([10.237.72.185]) by fmsmga001.fm.intel.com with SMTP; 02 Feb 2022 00:19:14 -0800 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Wed, 02 Feb 2022 10:19:13 +0200 Date: Wed, 2 Feb 2022 10:19:13 +0200 From: Heikki Krogerus To: Won Chung Cc: "Rafael J . Wysocki" , Len Brown , Benson Leung , Prashant Malani , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] ACPI: device_sysfs: Add sysfs support for _PLD Message-ID: References: <20220201015518.3118404-1-wonchung@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220201015518.3118404-1-wonchung@google.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Won, On Tue, Feb 01, 2022 at 01:55:18AM +0000, Won Chung wrote: > When ACPI table includes _PLD fields for a device, create a new > directory (pld) in sysfs to share _PLD fields. I think you need to explain what needs this information in user space. > Signed-off-by: Won Chung > --- > Documentation/ABI/testing/sysfs-bus-acpi | 107 +++++++++++++++++++++++ > drivers/acpi/device_sysfs.c | 55 ++++++++++++ > include/acpi/acpi_bus.h | 1 + > 3 files changed, 163 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-bus-acpi b/Documentation/ABI/testing/sysfs-bus-acpi > index 58abacf59b2a..b8b71c8f3cfd 100644 > --- a/Documentation/ABI/testing/sysfs-bus-acpi > +++ b/Documentation/ABI/testing/sysfs-bus-acpi > @@ -96,3 +96,110 @@ Description: > hardware, if the _HRV control method is present. It is mostly > useful for non-PCI devices because lspci can list the hardware > version for PCI devices. > + > +What: /sys/bus/acpi/devices/.../pld/ > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + This directory contains the output of the device object's _PLD > + control method, if present. This information provides details > + on physical location of a device. > + > +What: /sys/bus/acpi/devices/.../pld/revision > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + The current revision is 0x2. > + > +What: /sys/bus/acpi/devices/.../pld/group_token > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Unique numerical value identifying a group. > + > +What: /sys/bus/acpi/devices/.../pld/group_position > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Identifies this device connection point’s position in the group. > + > +What: /sys/bus/acpi/devices/.../pld/user_visible > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Set if the device connection point can be seen by the user > + without disassembly. > + > +What: /sys/bus/acpi/devices/.../pld/dock > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Set if the device connection point resides in a docking station > + or port replicator. > + > +What: /sys/bus/acpi/devices/.../pld/bay > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Set if describing a device in a bay or if device connection > + point is a bay. > + > +What: /sys/bus/acpi/devices/.../pld/lid > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Set if this device connection point resides on the lid of > + laptop system. > + > +What: /sys/bus/acpi/devices/.../pld/panel > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Describes which panel surface of the system’s housing the > + device connection point resides on: > + 0 - Top > + 1 - Bottom > + 2 - Left > + 3 - Right > + 4 - Front > + 5 - Back > + 6 - Unknown (Vertical Position and Horizontal Position will be > + ignored) > + > +What: /sys/bus/acpi/devices/.../pld/vertical_position > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + 0 - Upper > + 1 - Center > + 2 - Lower > + > +What: /sys/bus/acpi/devices/.../pld/horizontal_position > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + ACPI specification does not define horizontal position field. > + Can be used as either > + 0 - Left > + 1 - Center > + 2 - Right > + or > + 0 - Leftmost > + and higher numbers going toward the right. > + > +What: /sys/bus/acpi/devices/.../pld/shape > +Date: Feb, 2022 > +Contact: Won Chung > +Description: > + Describes the shape of the device connection point. > + 0 - Round > + 1 - Oval > + 2 - Square > + 3 - Vertical Rectangle > + 4 - Horizontal Rectangle > + 5 - Vertical Trapezoid > + 6 - Horizontal Trapezoid > + 7 - Unknown - Shape rendered as a Rectangle with dotted lines > + 8 - Chamfered > + 15:9 - Reserved > + > diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c > index d5d6403ba07b..610be93635a0 100644 > --- a/drivers/acpi/device_sysfs.c > +++ b/drivers/acpi/device_sysfs.c > @@ -509,6 +509,49 @@ static ssize_t status_show(struct device *dev, struct device_attribute *attr, > } > static DEVICE_ATTR_RO(status); > > +#define DEV_ATTR_PLD_PROP(prop) \ > + static ssize_t prop##_show(struct device *dev, struct device_attribute *attr, \ > + char *buf) \ > +{ \ > + struct acpi_device *acpi_dev = to_acpi_device(dev); \ > + if (acpi_dev->pld == NULL) \ > + return -EIO; \ > + return sprintf(buf, "%u\n", acpi_dev->pld->prop); \ > +}; \ Ah, you are storing the _PLD below. Before there were concerns about the memory that the cached _PLD information would consume. Another way of doing this would be to just always evaluate the _PLD here. Rafael needs to comment on this. My personal opinion is that let's just store the thing. > +static DEVICE_ATTR_RO(prop) > + > +DEV_ATTR_PLD_PROP(revision); > +DEV_ATTR_PLD_PROP(group_token); > +DEV_ATTR_PLD_PROP(group_position); > +DEV_ATTR_PLD_PROP(user_visible); > +DEV_ATTR_PLD_PROP(dock); > +DEV_ATTR_PLD_PROP(bay); > +DEV_ATTR_PLD_PROP(lid); > +DEV_ATTR_PLD_PROP(panel); > +DEV_ATTR_PLD_PROP(vertical_position); > +DEV_ATTR_PLD_PROP(horizontal_position); > +DEV_ATTR_PLD_PROP(shape); > + > +static struct attribute *dev_attr_pld[] = { > + &dev_attr_revision.attr, > + &dev_attr_group_token.attr, > + &dev_attr_group_position.attr, > + &dev_attr_user_visible.attr, > + &dev_attr_dock.attr, > + &dev_attr_bay.attr, > + &dev_attr_lid.attr, > + &dev_attr_panel.attr, > + &dev_attr_vertical_position.attr, > + &dev_attr_horizontal_position.attr, > + &dev_attr_shape.attr, > + NULL, > +}; > + > +static struct attribute_group dev_attr_pld_group = { > + .name = "pld", > + .attrs = dev_attr_pld, > +}; > + > /** > * acpi_device_setup_files - Create sysfs attributes of an ACPI device. > * @dev: ACPI device object. > @@ -595,6 +638,16 @@ int acpi_device_setup_files(struct acpi_device *dev) > &dev_attr_real_power_state); > } > > + if (acpi_has_method(dev->handle, "_PLD")) { > + status = acpi_get_physical_device_location(dev->handle, > + &dev->pld); > + if (ACPI_FAILURE(status)) > + goto end; > + result = device_add_group(&dev->dev, &dev_attr_pld_group); > + if (result) > + goto end; > + } You probable want to store the pld in acpi_store_pld_crc(). Perhaps also rename that function to just acpi_store_pld() at the same time. Here you just want to create the sysfs group. > acpi_expose_nondev_subnodes(&dev->dev.kobj, &dev->data); > > end: > @@ -645,4 +698,6 @@ void acpi_device_remove_files(struct acpi_device *dev) > device_remove_file(&dev->dev, &dev_attr_status); > if (dev->handle) > device_remove_file(&dev->dev, &dev_attr_path); > + if (acpi_has_method(dev->handle, "_PLD")) > + device_remove_group(&dev->dev, &dev_attr_pld_group); > } > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h > index ca88c4706f2b..929e726a666b 100644 > --- a/include/acpi/acpi_bus.h > +++ b/include/acpi/acpi_bus.h > @@ -381,6 +381,7 @@ struct acpi_device { > struct acpi_hotplug_context *hp; > struct acpi_driver *driver; > const struct acpi_gpio_mapping *driver_gpios; > + struct acpi_pld_info *pld; > void *driver_data; > struct device dev; > unsigned int physical_node_count; > -- thanks, -- heikki