All of lore.kernel.org
 help / color / mirror / Atom feed
From: Won Chung <wonchung@google.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Benson Leung <bleung@chromium.org>,
	Prashant Malani <pmalani@chromium.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6] ACPI: device_sysfs: Add sysfs support for _PLD
Date: Mon, 14 Feb 2022 12:30:17 -0800	[thread overview]
Message-ID: <CAOvb9yjpruiHxkZyZ8BOT0Hi_iV7xMOnBCr59BZX3eah_Zcy_w@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0gD4zs3uBAYv6M4_1gNpkZ-g9XKOywJnf5007e6GwoGVA@mail.gmail.com>

On Mon, Feb 14, 2022 at 11:12 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Fri, Feb 11, 2022 at 3:30 AM Won Chung <wonchung@google.com> wrote:
> >
> > When ACPI table includes _PLD fields for a device, create a new
> > directory (pld) in sysfs to share _PLD fields.
>
> This version of the patch loos better to me, but I'm not sure if it
> goes into the right direction overall.
>
> > Currently without PLD information, when there are multiple of same
> > devices, it is hard to distinguish which device corresponds to which
> > physical device in 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.
>
> So I think that this is your primary use case and I'm wondering if
> this is the best way to address it.
>
> Namely, by exposing _PLD information under the ACPI device object,
> you'll make user space wanting to use that information depend on this
> interface, but the problem is not ACPI-specific (inevitably, it will
> appear on systems using DT, sooner or later) and making the user space
> interface related to it depend on ACPI doesn't look like a perfect
> choice.
>
> IOW, why don't you create a proper ABI for this in the Type C
> subsystem and expose the information needed by user space in a generic
> way that can be based on the _PLD information on systems with ACPI?

Hi Rafael,

Thank you for the review.

I was thinking that _PLD info is specific to ACPI since it is part of
the ACPI table. Could you explain a little bit more on why you think
exposing _PLD fields is not an ACPI-specific problem?

I gave an example of how _PLD fields can be used for specifying Type C
connectors, but it is not Type C specific. For Chrome OS, we plan to
initially add PLD to not only Type C connectors but also USB port
devices (including Type C and Type A). Also, PLD can be used in the
future for describing other types of ports too like HDMI. (Benson and
Prashant, please correct or add if I am wrong or missing some
information) Maybe my commit message was not detailed enough..

I am also curious what Heikki thinks about this. Heikki, can you take
a look and share your thoughts?

Thank you,
Won

  reply	other threads:[~2022-02-14 20:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11  2:30 [PATCH v6] ACPI: device_sysfs: Add sysfs support for _PLD Won Chung
2022-02-14 19:11 ` Rafael J. Wysocki
2022-02-14 20:30   ` Won Chung [this message]
2022-02-14 22:58     ` Won Chung
2022-02-15 10:14       ` Heikki Krogerus
2022-02-15 13:54         ` Rafael J. Wysocki
2022-02-16 11:34           ` Heikki Krogerus
2022-02-16 16:39             ` Rafael J. Wysocki
2022-02-18  1:15               ` Won Chung
2022-02-18 17:24                 ` Rafael J. Wysocki
2022-02-18 19:48                   ` Won Chung
2022-02-28 19:12                     ` Won Chung
2022-02-15 14:04       ` Rafael J. Wysocki
2022-02-15 14:08         ` Rafael J. Wysocki
2022-02-16 17:33         ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOvb9yjpruiHxkZyZ8BOT0Hi_iV7xMOnBCr59BZX3eah_Zcy_w@mail.gmail.com \
    --to=wonchung@google.com \
    --cc=bleung@chromium.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmalani@chromium.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.