From: Jonathan Cameron <jic23@kernel.org>
To: Conor Dooley <conor@kernel.org>
Cc: Jinseob Kim <kimjinseob88@gmail.com>,
linux-iio@vger.kernel.org, David Lechner <dlechner@baylibre.com>,
Nuno Sa <nuno.sa@analog.com>, Andy Shevchenko <andy@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v3 1/6] dt-bindings: iio: add OSF GREEN sensor aggregation device
Date: Fri, 29 May 2026 18:14:51 +0100 [thread overview]
Message-ID: <20260529181451.45b5d1bb@jic23-huawei> (raw)
In-Reply-To: <20260529-recant-imperfect-ba65ef80e542@spud>
On Fri, 29 May 2026 17:31:42 +0100
Conor Dooley <conor@kernel.org> wrote:
> On Fri, May 29, 2026 at 09:10:00PM +0900, Jinseob Kim wrote:
> > Describe OSF GREEN as the first board target.
> >
> > Add vendor prefix and MAINTAINERS binding entry.
> >
> > Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
> > ---
> > .../iio/imu/opensensorfusion,osf-green.yaml | 43 +++++++++++++++++++
> > .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> > MAINTAINERS | 5 +++
> > 3 files changed, 50 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml b/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
> > new file mode 100644
> > index 000000000..626b41fb0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
>
> This is still not an IMU.
Might include one but agreed, it is more. So probably move it up a a directory
to bindings/iio as it's more of a sensorhub.
> pw-bot: changes-requested
>
> > @@ -0,0 +1,43 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/imu/opensensorfusion,osf-green.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: OSF GREEN sensor aggregation board
> > +
> > +maintainers:
> > + - Jinseob Kim <kimjinseob88@gmail.com>
> > +
> > +description: |
> > + OSF GREEN is an STM32F405-based sensor aggregation board from the Open
> > + Sensor Fusion open hardware project. It sends OSF0 capability, status, and
> > + sample frames to a host over a UART link.
> > +
> > + Open Sensor Fusion is not a generic industry standard. Public project and
> > + hardware documentation is available at:
> > +
> > + https://github.com/opensensorfusion
> > + https://github.com/opensensorfusion/opensensorfusion-hardware
> > +
> > +allOf:
> > + - $ref: /schemas/serial/serial-peripheral-props.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: opensensorfusion,osf-green
>
> I'm still not convinced by the compatible here, or at least I am not
> convinced by it without clear answers to my questions on v1 about
> discoverability and compatibility between protocol versions. If the
> software on the "osf-green" is updatable (it is, right?) the compatible
> doesn't actually represent the hardware, it represents the programming
> model of what's exposed on the serial port to the host. That means the
> compatible you use has to identify the exact protocol version
> implemented, or provide enough information that the version can be
> figured out by software.
>
> Given you talk about OSF0 communicating capability etc, it seems to me
> like OSF0 is a discoverable bus? In that case, compatibles for boards
> doesn't really matter, all software should need to know is that there is
> an OSF0 "bus" and query it for what sensors are there.
Agreed - should be very generic and rely on protocol discovery. Only
need to break that if some some silly reason the way protocol version is
discovered changes.
>
> The questions I asked on v1 were:
> - What does "v0" mean here? Is the data format not complete yet?
> - Are versions of the protocol likely to be backwards compatible?
> - Will the device identify what version of the protocol it implements?
>
> Remember, there's no rush here, and you're better off slowing down and
> taking your time responding to reviews before sending new versions, so
> that the same conversations don't take place multiple times.
>
> Cheers,
> Conor.
>
next prev parent reply other threads:[~2026-05-29 17:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-29 12:09 [PATCH RFC v3 0/6] iio: add Open Sensor Fusion OSF0 UART driver Jinseob Kim
2026-05-29 12:10 ` [PATCH RFC v3 1/6] dt-bindings: iio: add OSF GREEN sensor aggregation device Jinseob Kim
2026-05-29 12:19 ` sashiko-bot
2026-05-29 16:31 ` Conor Dooley
2026-05-29 17:14 ` Jonathan Cameron [this message]
2026-05-29 12:10 ` [PATCH RFC v3 2/6] Documentation: iio: add Open Sensor Fusion protocol v0 reference Jinseob Kim
2026-05-29 12:23 ` sashiko-bot
2026-05-29 12:10 ` [PATCH RFC v3 3/6] iio: osf: add protocol v0 decoding Jinseob Kim
2026-05-29 12:10 ` [PATCH RFC v3 4/6] iio: osf: add stream parser Jinseob Kim
2026-05-29 13:08 ` sashiko-bot
2026-05-29 12:10 ` [PATCH RFC v3 5/6] iio: osf: add UART serdev transport Jinseob Kim
2026-05-29 13:40 ` sashiko-bot
2026-05-29 12:10 ` [PATCH RFC v3 6/6] iio: osf: register IIO devices from capabilities Jinseob Kim
2026-05-29 14:36 ` sashiko-bot
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=20260529181451.45b5d1bb@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=kimjinseob88@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox