All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-input@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	linux-iio@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Mark Pearson <mpearson@lenovo.com>,
	Bastien Nocera <hadess@hadess.net>
Subject: Re: [PATCH 1/2] iio: documentation: Document proximity sensor label use
Date: Fri, 12 Feb 2021 18:46:17 +0000	[thread overview]
Message-ID: <20210212184617.5bad8172@archlinux> (raw)
In-Reply-To: <20210207123720.8357-1-hdegoede@redhat.com>

On Sun,  7 Feb 2021 13:37:19 +0100
Hans de Goede <hdegoede@redhat.com> wrote:

> Add an entry to Documentation/ABI/testing/sysfs-bus-iio for
> the new device and channel label sysfs-attribute support.
> 
> And document the standardized labels which may be used with proximity
> sensors to hint userspace about the intended use of the sensor.
> 
> Using labels to differentiate between the multiple proximity sensors
> which a modern laptop/tablet may have was discussed in this thread:
> https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/
> 
> As mentioned the "proximity-wifi*" labels are already being used in
> this manner on some chromebooks, see e.g.:
> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
> arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi
> 
> And the "proximity-palmrest" and "proximity-lap" labels are intended
> to be used with the lap and palmrest sensors found in recent Lenovo
> ThinkPad models.
> 
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Mark Pearson <mpearson@lenovo.com>
> Cc: Bastien Nocera <hadess@hadess.net>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 41 +++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
> index 35289d47d6cb..f2f090f8bd2f 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -33,6 +33,47 @@ Description:
>  		Description of the physical chip / device for device X.
>  		Typically a part number.
>  
> +What:		/sys/bus/iio/devices/iio:deviceX/label
> +What:		/sys/bus/iio/devices/iio:deviceX/in_*_label
> +What:		/sys/bus/iio/devices/iio:deviceX/out_*_label

I was a bit in two minds about this from an organizational point of view.
1) Whether to separate the general label where position tends to make sense
   from the channel labels.  May be something we want to do in future but we can probably
   let that go for now.
2) Whether to allow such broad wild cards for the channels.
   Whilst in theory any channel can have a label we normally only document ABI
   that actually exists (mostly to know what we might break if we change anything :)
   Still I can't see any way we can change this without breakage so in this
   one case let's let the broad wild card go in.

This comes unstuck on the fact it overlaps with existing more specific Docs.

So can you pull the channel part out of here for v2.
/sys/bus/iio/devices/iio:deviceX/in_voltageY_label
/sys/bus/iio/devices/iio:deviceX/in_anglY_label

The reason to keep these separate is that they will often contain a bit more
info about specific driver ABI (because of the issues with duplicating
ABI documentation in multiple files) so I'd rather we didn't end up with this
one item having many pages of info.

Jonathan



Jonathan
> +KernelVersion:	5.8
> +Contact:	linux-iio@vger.kernel.org
> +Description:
> +		Optional symbolic label for a device or a channel.
> +		This is useful for userspace to be able to better identify an
> +		individual device or channel.
> +
> +		The contents of the label are free-form, but there are some
> +		standardized uses:
> +
> +		For proximity sensors which give the proximity (of a person) to
> +		a certain wlan or wwan antenna the following standardized labels
> +		are used:
> +
> +		* "proximity-wifi"
> +		* "proximity-lte"
> +		* "proximity-wifi-lte"
> +		* "proximity-wifi-left"
> +		* "proximity-wifi-right"
> +
> +		These are used to indicate to userspace that these proximity
> +		sensors may be used to tune transmit power to ensure that
> +		Specific Absorption Rate (SAR) limits are honored.
> +		The "-left" and "-right" labels are for devices with multiple
> +		antennas.
> +
> +		In some laptops/tablets the standardized proximity sensor labels
> +		instead	indicate proximity to a specific part of the device:
> +
> +		* "proximity-palmrest" indicates proximity to the keyboard's palmrest
> +		* "proximity-palmrest-left" indicates proximity to the left part of the palmrest
> +		* "proximity-palmrest-right" indicates proximity to the right part of the palmrest
> +		* "proximity-lap" indicates the device is being used on someone's lap
> +
> +		Note "proximity-lap" is special in that its value may be
> +		calculated by firmware from other sensor readings, rather then
> +		being a raw sensor reading.
> +
>  What:		/sys/bus/iio/devices/iio:deviceX/current_timestamp_clock
>  KernelVersion:	4.5
>  Contact:	linux-iio@vger.kernel.org


  parent reply	other threads:[~2021-02-12 18:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-07 12:37 [PATCH 1/2] iio: documentation: Document proximity sensor label use Hans de Goede
2021-02-07 12:37 ` [PATCH 2/2] iio: documentation: Document accelerometer " Hans de Goede
2021-02-08 13:40 ` [PATCH 1/2] iio: documentation: Document proximity sensor " Bastien Nocera
2021-02-08 13:50   ` Hans de Goede
2021-02-08 14:16     ` Bastien Nocera
2021-02-08 14:17       ` Hans de Goede
2021-02-12 18:46 ` Jonathan Cameron [this message]
2021-02-12 18:58   ` Hans de Goede
2021-02-15 12:39     ` Jonathan Cameron
2021-02-15 12:55       ` Hans de Goede
2021-02-15 14:12         ` Jonathan Cameron

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=20210212184617.5bad8172@archlinux \
    --to=jic23@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hadess@hadess.net \
    --cc=hdegoede@redhat.com \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=mpearson@lenovo.com \
    --cc=pmeerw@pmeerw.net \
    /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.