Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <dcd78309d7bbbdad511e10a63eb0e73f01934e8b.camel@hadess.net>
Subject: Re: [PATCH v2 resend 2/2] iio: documentation: Document
 accelerometer label use
From:   Bastien Nocera <hadess@hadess.net>
To:     Hans de Goede <hdegoede@redhat.com>,
        Marcel Holtmann <marcel@holtmann.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     linux-bluetooth@vger.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Mark Pearson <mpearson@lenovo.com>
Date:   Fri, 16 Apr 2021 12:56:26 +0200
In-Reply-To: <20210405203933.17282-3-hdegoede@redhat.com>
References: <20210405203933.17282-1-hdegoede@redhat.com>
         <20210405203933.17282-3-hdegoede@redhat.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.0 (3.40.0-1.fc34) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

On Mon, 2021-04-05 at 22:39 +0200, Hans de Goede wrote:
> Some 2-in-1 laptops / convertibles with 360° (yoga-style) hinges,
> have 2 accelerometers, 1 in their base and 1 in their display.
> 
> In many cases the kernel can detect the location of each
> accelerometer
> based on e.g. information from the ACPI tables.
> 
> It is important for userspace to know the location of the 2
> accelerometers.
> Rather then adding a new sysfs-attribute for this we can relay this
> information to userspace by using standardized label strings for
> this.
> This mirrors how this is done for proximity sensors.
> 
> This commit documents 2 new standardized label strings for this
> purpose:
> "accel-base"
> "accel-display"

If we have a combined proximity and accelerometer sensor (which
wouldn't be unheard off with sensor hubs being used), how are multiple
labels, say "proximity-wifi" and "accel-base" documented?

I think that it might be worth using a separate sysfs attribute for
this, say "location" which would have "display" or "base" as a value,
and which iio-sensor-proxy could already consume.

This would also make it easier to funnel values from DeviceTree or ACPI
to udev and/or a single sysfs kernel attribute one-to-one.

Cheers

> 
> Note the "base" and "display" suffixes were chosen to match the
> values
> used for the systemd/udev hwdb.d/60-sensor.hwdb file's ACCEL_LOCATION
> property.
> 
> 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 | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 7379e40d862d..b7529bca83f5 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -72,6 +72,13 @@ Description:
>                 calculated by firmware from other sensor readings,
> rather then
>                 being a raw sensor reading.
>  
> +               For accelerometers used in 2-in-1s with 360° (yoga-
> style) hinges,
> +               which have an accelerometer in both their base and
> their display,
> +               the following standardized labels are used:
> +
> +               * "accel-base"
> +               * "accel-display"
> +
>  What:          /sys/bus/iio/devices/iio:deviceX/current_timestamp_cl
> ock
>  KernelVersion: 4.5
>  Contact:       linux-iio@vger.kernel.org