Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp4150764pxm; Tue, 1 Mar 2022 12:21:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJzC/6BGJTRt3J+MgSGHRs+rBb1g4KOitTXyAzMI0yLELKpDXAlSRQVFRB9j53qmYHnYtfm2 X-Received: by 2002:a17:907:8a0d:b0:6d6:dae9:7263 with SMTP id sc13-20020a1709078a0d00b006d6dae97263mr6069549ejc.671.1646166087042; Tue, 01 Mar 2022 12:21:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646166087; cv=none; d=google.com; s=arc-20160816; b=GfWH6MfVNFZlbjYVmCXw6pViAYtRAYpZ0VokPjqca8OtD1VgZVwwq0AUVlLfJ06+cd JqDi0Y3ZAO5vYf+Ho3KRagQhdjPwWbJUpey7Tyg8xTh/+L40evfJqq73ZEnVwuqbmUGx lD0iDBx+sysFq4mDhhVZYIsylU3sKWq6Z6by9sPBu3rRJ8gdqHL8cwjD8dneTZ04cpYM taVSzu9KUHLyyrtA++FfQlvhJWv7QkYzFSe0c1pQ36OCYFfrKshNmnSyHWq9gCiddz0X csL4fpuuRqPO9b+rb+PAlTmkDkWemk9URLRN/UWgjRn2YHm3vSmPlIYjjxGqcoCIcyLd mU+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=ANEUC+dOPk/xgud/9xMmHKavai8ylEuUZGGERffgEFQ=; b=rRGbbRmgjXJtOxVVuQz2LOl3bcSbdoPw/PGh19vWPdH5XtYGoGuc2+uAEatXtpzeHP vNiQlSnMTDD18e8BqRpllJPizJcTH1s5CCM8KsFrG/2wb9qxJundrZeArFGvEdqx58Hg zxi2aDc9kyXNeLu6CwpPjWkjOph4eI9qPk0vu4vsSqJoGa8Ld7cs138K0IB9/2C98uks ZM3kuNKx0TANlWAedm9x67Ez8KGpQn0WvE9emOQxigPh+U2Ucno/o8Gy8PZTyeIxVJNB NNJCjdqeXh1G1XU5eizdm1FnPw/Pv9f87Eqc6t67xl0o2ISN+1ecWfAx+PhsFWAAK5KV MWBw== ARC-Authentication-Results: i=1; mx.google.com; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id er17-20020a056402449100b00413baf80a4fsi4471241edb.532.2022.03.01.12.21.02; Tue, 01 Mar 2022 12:21:27 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231486AbiCATMA convert rfc822-to-8bit (ORCPT + 99 others); Tue, 1 Mar 2022 14:12:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231338AbiCATL7 (ORCPT ); Tue, 1 Mar 2022 14:11:59 -0500 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E27656582F; Tue, 1 Mar 2022 11:11:17 -0800 (PST) Received: by mail-yb1-f176.google.com with SMTP id bt13so29203229ybb.2; Tue, 01 Mar 2022 11:11:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nmWK2BW2x6xyV74EFPtWDeE7bgfe1HOlsD2rX10CEvs=; b=DvvsKonyb7fR2c7QzbCJ+8FjvBu/8nZUAADqg3dgj1/R+x5wEhlEn178U0JhkVzG1u Rn3YxJoeallf3Q/C91iIzhnqMQN47cp4tCun0pTWGwCkXbleJyxQ/oHbb+1YMh+kFfnD 7N/rz/D7NGgqH7EBIkHJiy1RE+VeXz5z9zxYs44nXix+s8hLikcGhexfUvuGe0y6i4oM s+VVkV5NA9DFrf5dRx9z5B79QWkT1GC+ewvMLS8KipIEfaiAm85prTsu6gvZWUvc9cvi LHRNgFAaOVdZlOEHW9gXzyOXckFlNb5Xvq0K+xtzETqI9CEHd4cb2kxClDIjWXEgZ/eF Tq8g== X-Gm-Message-State: AOAM530QZdzPVEGqVc54atBz32ANZX2GAU2h0sKfhQ7dOWVcpg3rhPsf QK8q9jf8TTtKrCIbzj/hn5rX7nivHCqf0sR/5Pw= X-Received: by 2002:a25:bbc1:0:b0:610:b4ce:31db with SMTP id c1-20020a25bbc1000000b00610b4ce31dbmr25343371ybk.482.1646161877152; Tue, 01 Mar 2022 11:11:17 -0800 (PST) MIME-Version: 1.0 References: <20220301022625.469446-1-wonchung@google.com> In-Reply-To: From: "Rafael J. Wysocki" Date: Tue, 1 Mar 2022 20:11:06 +0100 Message-ID: Subject: Re: [PATCH v2] usb:typec: Add sysfs support for Type C connector's physical location To: Won Chung Cc: Heikki Krogerus , Greg Kroah-Hartman , "Rafael J . Wysocki" , Benson Leung , Prashant Malani , "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 1, 2022 at 7:57 PM Won Chung wrote: > > On Tue, Mar 1, 2022 at 1:33 AM Heikki Krogerus > wrote: > > > > Hi Won, > > > > On Tue, Mar 01, 2022 at 02:26:25AM +0000, Won Chung wrote: > > > When ACPI table includes _PLD field for a Type C connector, share _PLD > > > values in its sysfs. _PLD stands for physical location of device. > > > > > > Currently without connector's location information, when there are > > > multiple Type C ports, it is hard to distinguish which connector > > > corresponds to which physical port at which location. For example, when > > > there are two Type C connectors, it is hard to find out which connector > > > corresponds to the Type C port on the left panel versus the Type C port > > > on the right panel. With location information provided, we can determine > > > which specific device at which location is doing what. > > > > > > _PLD output includes much more fields, but only generic fields are added > > > and exposed to sysfs, so that non-ACPI devices can also support it in > > > the future. The minimal generic fields needed for locating a port are > > > the following. > > > - panel > > > - vertical_position > > > - horizontal_position > > > - dock > > > - lid > > > > > > Signed-off-by: Won Chung > > > --- > > > > > > Changes in v2: > > > - Use string for location. > > > - Clarify get_pld() with naming and return type. > > > > > > Documentation/ABI/testing/sysfs-class-typec | 35 ++++++ > > > drivers/usb/typec/class.c | 113 ++++++++++++++++++++ > > > drivers/usb/typec/class.h | 3 + > > > 3 files changed, 151 insertions(+) > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-typec b/Documentation/ABI/testing/sysfs-class-typec > > > index 75088ecad202..4497a5aeb063 100644 > > > --- a/Documentation/ABI/testing/sysfs-class-typec > > > +++ b/Documentation/ABI/testing/sysfs-class-typec > > > @@ -141,6 +141,41 @@ Description: > > > - "reverse": CC2 orientation > > > - "unknown": Orientation cannot be determined. > > > > > > +What: /sys/class/typec//location/panel > > > +Date: March 2022 > > > +Contact: Won Chung > > > +Description: > > > + Describes which panel surface of the system’s housing the > > > + port resides on. > > > + > > > +What: /sys/class/typec//location/vertical_position > > > +Date: March 2022 > > > +Contact: Won Chung > > > +Description: > > > + Describes vertical position of the port on the panel surface. > > > + Valid values: upper, center, lower > > > + > > > +What: /sys/class/typec//location/horizontal_position > > > +Date: March 2022 > > > +Contact: Won Chung > > > +Description: > > > + Describes horizontal position of the port on the panel surface. > > > + Valid values: left, center, right > > > + > > > +What: /sys/class/typec//location/dock > > > +Date: March 2022 > > > +Contact: Won Chung > > > +Description: > > > + Set as "yes" if the port resides in a docking station or a port > > > + replicator, otherwise set as "no". > > > + > > > +What: /sys/class/typec//location/lid > > > +Date: March 2022 > > > +Contact: Won Chung > > > +Description: > > > + Set as "yes" if the port resides on the lid of laptop system, > > > + otherwise set as "no". > > > + > > > > I've probable lost track of the topic during my winter break, I'm > > sorry about that, but why are you proposing now that this should be > > made Type-C specific? > > This information is not Type-C specific, so it definitely does not > > belong here. > > > > Br, > > > > -- > > heikki > > Hi Heikki, > > Thank you for the comment. Sorry that my description was not clear. > This is follow up from "[PATCH v6] ACPI: device_sysfs: Add sysfs > support for _PLD" in which Rafael suggested to have generic location > in Type C connector than adding PLD specifically to ACPI device. Well, this doesn't have to be /sys/class/typec//location/ though. For example, the device location information can be exposed in a more generic way is /sys/devices/.../location/ for all devices for which it is available, somewhat in analogy to /sys/devices/.../power/.