Devicetree
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Jinseob Kim <kimjinseob88@gmail.com>
Cc: "Jonathan Cameron" <jic23@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"David Lechner" <dlechner@baylibre.com>,
	"Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v5 1/6] dt-bindings: iio: add Open Sensor Fusion device
Date: Tue, 16 Jun 2026 16:53:46 +0100	[thread overview]
Message-ID: <20260616-enigmatic-remarry-4f1a4d06e637@spud> (raw)
In-Reply-To: <20260616072242.3942-2-kimjinseob88@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6337 bytes --]

On Tue, Jun 16, 2026 at 04:22:37PM +0900, Jinseob Kim wrote:
> Add the generic Open Sensor Fusion device binding for a serdev-attached
> IIO sensor aggregation hub, and document the opensensorfusion vendor
> prefix.
> 
> The opensensorfusion,osf compatible describes the generic Open Sensor
> Fusion host interface. OSF GREEN is not the Linux compatible identity.
> Likewise, OSF0 is the current wire magic and a wire-format detail, not
> the Linux driver identity.
> 
> The fixed OSF frame header carries protocol_major and protocol_minor at
> fixed offsets. This driver currently supports protocol_major 0.
> protocol_minor changes are intended to remain backward-compatible within
> that fixed header layout. Incompatible wire-format changes require a new
> protocol_major. If a future device cannot expose compatible version
> discovery through the fixed header layout, it will need a different
> compatible.
> 
> Require vcc-supply so the driver can enable device power before starting
> communication.
> 
> Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> ---
>  .../bindings/iio/opensensorfusion,osf.yaml    | 59 +++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
>  MAINTAINERS                                   | 13 ++++
>  3 files changed, 74 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> 
> diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> new file mode 100644
> index 000000000..012a07fd6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Open Sensor Fusion Sensor Aggregation Hub
> +
> +maintainers:
> +  - Jinseob Kim <kimjinseob88@gmail.com>
> +
> +description: |
> +  Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
> +  protocol data stream over its host interface and may report capabilities and

s/may report/reports/ because mandatory reporting, even if nothing is
actually there, is a requirement for having a compatible describing the
"bus".

> +  samples for multiple sensor classes. The Linux driver discovers the actual

s/The Linux driver discovers the actual sensor channels/The actual sensor channels are discovered"
Because although maybe only linux will use this it should not be
specific.

> +  sensor channels from OSF capability reports instead of describing those
> +  sensors in Device Tree.
> +
> +  Open Sensor Fusion is not a generic industry standard. Public project

I would drop this first sentence to be honest.

> +  documentation is available at:
> +
> +    https://github.com/opensensorfusion
> +
> +  The compatible describes the generic Open Sensor Fusion host interface. It
> +  is not an OSF GREEN board identity, and it does not encode the OSF0 wire
> +  magic. OSF0, protocol_major, and protocol_minor are wire-protocol details
> +  exchanged in OSF frames.

I think I move this to the first paragraph and would say something like

| This binding documents the generic Open Sensor Fusion host interface.
| 
| Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
| protocol data stream over its host interface and reports capabilities and
| samples for multiple sensor classes. The actual sensor channels are discovered
| at runtime from OSF capability reports instead of describing them in Device
| Tree.
|
| The protocol version is discovered at runtime.

Does that sound about right?

> +
> +allOf:
> +  - $ref: /schemas/serial/serial-peripheral-props.yaml#
> +
> +properties:
> +  compatible:
> +    const: opensensorfusion,osf
> +
> +  vcc-supply:
> +    description:
> +      Regulator supplying power to the Open Sensor Fusion device.
> +
> +required:
> +  - compatible
> +  - vcc-supply
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    vcc_sensor: regulator-0 {
> +        compatible = "regulator-fixed";
> +        regulator-name = "sensor-vcc";
> +    };

Drop this node, the tooling fakes one when running the checks. Only keep
nodes that actually form your device here. Same way you don't need to
actually fill out the serial port.
pw-bot: changes-requested

> +
> +    serial {
> +        sensor {
> +            compatible = "opensensorfusion,osf";
> +            vcc-supply = <&vcc_sensor>;
> +        };
> +    };
> +...
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 28784d66a..88172d4a4 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1237,6 +1237,8 @@ patternProperties:
>      description: OpenPandora GmbH
>    "^openrisc,.*":
>      description: OpenRISC.io
> +  "^opensensorfusion,.*":
> +    description: Open Sensor Fusion
>    "^openwrt,.*":
>      description: OpenWrt
>    "^option,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c2c6d7927..2ddefc42d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20011,6 +20011,19 @@ F:	Documentation/devicetree/
>  F:	arch/*/boot/dts/
>  F:	include/dt-bindings/
>  

> +OPEN SENSOR FUSION IIO DRIVER
> +M:	Jinseob Kim <kimjinseob88@gmail.com>
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
> +F:	Documentation/iio/open-sensor-fusion.rst
> +F:	drivers/iio/opensensorfusion/Kconfig
> +F:	drivers/iio/opensensorfusion/Makefile
> +F:	drivers/iio/opensensorfusion/osf_core.*
> +F:	drivers/iio/opensensorfusion/osf_iio.*
> +F:	drivers/iio/opensensorfusion/osf_protocol.*
> +F:	drivers/iio/opensensorfusion/osf_serdev.c
> +F:	drivers/iio/opensensorfusion/osf_stream.*

At this stage, only add the binding. The rest should be added when the
files are.

Cheers,
Conor.

> +
>  OPENCOMPUTE PTP CLOCK DRIVER
>  M:	Vadim Fedorenko <vadim.fedorenko@linux.dev>
>  L:	netdev@vger.kernel.org
> -- 
> 2.43.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2026-06-16 15:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  7:22 [PATCH RFC v5 0/6] iio: add Open Sensor Fusion IIO driver Jinseob Kim
2026-06-16  7:22 ` [PATCH RFC v5 1/6] dt-bindings: iio: add Open Sensor Fusion device Jinseob Kim
2026-06-16  7:31   ` sashiko-bot
2026-06-16 15:53   ` Conor Dooley [this message]
2026-06-16  7:22 ` [PATCH RFC v5 2/6] Documentation: iio: add Open Sensor Fusion driver overview Jinseob Kim
2026-06-16  7:22 ` [PATCH RFC v5 3/6] iio: osf: add protocol decoding Jinseob Kim
2026-06-16 11:09   ` Andy Shevchenko
2026-06-16  7:22 ` [PATCH RFC v5 4/6] iio: osf: add stream parser Jinseob Kim
2026-06-16  7:38   ` sashiko-bot
2026-06-16 11:16   ` Andy Shevchenko
2026-06-16  7:22 ` [PATCH RFC v5 5/6] iio: osf: add UART transport Jinseob Kim
2026-06-16  7:37   ` sashiko-bot
2026-06-16 11:27   ` Andy Shevchenko
2026-06-16  7:22 ` [PATCH RFC v5 6/6] iio: osf: register IIO devices from capabilities Jinseob Kim
2026-06-16  7:38   ` sashiko-bot
2026-06-16 11:32   ` Andy Shevchenko

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=20260616-enigmatic-remarry-4f1a4d06e637@spud \
    --to=conor@kernel.org \
    --cc=andy@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=kimjinseob88@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=skhan@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox