RE: [PATCH 1/1] dt-bindings: spi: Add separate binding for dh,dhcom-board

[Christoph Niedermaier <cniedermaier@dh-electronics.com>]

From: Conor Dooley <conor@kernel.org>
Sent: Monday, October 19, 2026 8:23 PM
> On Sun, Oct 18, 2026 at 11:38:09PM +0200, Marek Vasut wrote:
> > On 10/18/26 9:37 PM, Conor Dooley wrote:
> > > On Sat, Oct 17, 2026 at 12:01:55AM +0200, Marek Vasut wrote:
> > > > On 10/16/26 10:57 PM, Frank.Li@oss.nxp.com wrote:
> > > > > From: Frank Li <Frank.Li@nxp.com>
> > > > > 
> > > > > The dh,dhcom-board SPI device uses spi-cpha and spi-cpol properties,
> > > > > which are not permitted by the trivial-devices schema. Move it to a
> > > > > dedicated binding file that references spi-peripheral-props.yaml and
> > > > > explicitly allows those SPI mode properties.
> > > > > 
> > > > > Fixes below CHECK_DTBS warnings:
> > > > >     arch/arm/boot/dts/nxp/imx/imx6ull-dhcor-maveo-box.dtb: spidev@0 (dh,dhcom-board): 'spi-cpha', 'spi-cpol' do not match any of the regexes: '^pinctrl-[0-9]+$'
> > > > >           from schema $id: http://devicetree.org/schemas/trivial-devices.yaml
> > > > 
> > > > How come this did not trigger until now ?
> > > > 
> > > > > Assisted-by: LLM
> > > > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > > > ---
> > > > >    .../bindings/spi/dh,dhcom-board.yaml          | 46 +++++++++++++++++++
> > > > >    .../devicetree/bindings/trivial-devices.yaml  |  2 -
> > > > >    2 files changed, 46 insertions(+), 2 deletions(-)
> > > > >    create mode 100644 Documentation/devicetree/bindings/spi/dh,dhcom-board.yaml
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/spi/dh,dhcom-board.yaml b/Documentation/devicetree/bindings/spi/dh,dhcom-board.yaml
> > > > > new file mode 100644
> > > > > index 0000000000000..ed213cbe9b04c
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/spi/dh,dhcom-board.yaml
> > > > > @@ -0,0 +1,46 @@
> > > > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > > > > +%YAML 1.2
> > > > > +---
> > > > > +$id: http://devicetree.org/schemas/spi/dh,dhcom-board.yaml#
> > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > +
> > > > > +title: DH electronics GmbH on-board CPLD trivial SPI device
> > > > 
> > > > This does not look quite right, since compatible this is used only on:
> > > > 
> > > > arch/arm/boot/dts/imx6ull-dhcor-maveo-box.dts
> > > > 
> > > >         model = "DH electronics i.MX6ULL DHCOR on maveo box";
> > > >         compatible = "marantec,imx6ull-dhcor-maveo-box",
> > > > "dh,imx6ull-dhcor-som",
> > > > 
> > > > So the whole
> > > > 
> > > >         spidev@0 {
> > > >                 compatible = "dh,dhcom-board";
> > > >                 reg = <0>;
> > > >                 spi-cpha;
> > > >                 spi-cpol;
> > > >                 spi-max-frequency = <54000000>;
> > > >         };
> > > > 
> > > > Should probably use a different compatible.
> > > > 
> > > > Christoph, what device is this on this board ?

There is no device connected to these pins, only an extension connector.
The "dh,dhcom-board" device was used only to test the hardware and was
unfortunately forgotten to be removed. In the production version, no
device is connected to this interface. It should actually be removed.
Should I create a patch for this?

> > > > (and this change should only be applied with RB from Christoph, I do not
> > > > have the hardware so I cannot tell what it really is)
> > > > 
> > > > > +maintainers:
> > > > > +  - Marek Vasut <marex@denx.de>
> > > > 
> > > > @nabladev.com
> > > > 
> > > > > +  - Frank Li <Frank.Li@nxp.com>
> > > > > +
> > > > > +allOf:
> > > > > +  - $ref: spi-peripheral-props.yaml
> > > > > +
> > > > > +properties:
> > > > > +  compatible:
> > > > > +    const: dh,dhcom-board
> > > > > +
> > > > > +  reg:
> > > > > +    maxItems: 1
> > > > > +
> > > > > +  spi-cpha: true
> > > > > +
> > > > > +  spi-cpol: true
> > > > 
> > > > Wouldn't it make more sense to allow those properties for trivial SPI
> > > > devices in general ?
> > > 
> > > If the device requires them (which it probably does?), then standalone
> > > makes sense to actually set that requirement.
> > 
> > All right.
> > 
> > But in any case, the compatible string should likely be fixed here, this
> > does not seem right. The dh,dhcom-board was describing some CPLD/FPGA on one
> > of the evalboards.
> 
> Ye I don't disagree there. "dhcom-board" seems not nearly specific
> enough about what the device is.

There isn't actually a user for this device, see above. It's only used downstream
at DH electronics for a connection to a PSoC chip. But even for this purpose, it's
not being used correctly. What should we do now?

Regards
Christoph