Re: [PATCH 1/2] ARM: dts: Add binding for Broadcom MSPI driver.

[Florian Fainelli]

On 12/05/15 10:38, Jonathan Richardson wrote:
> 
> Signed-off-by: Jonathan Richardson <jonathar@xxxxxxxxxxxx>
> ---
>  .../devicetree/bindings/spi/brcm,mspi-spi.txt      |   39 ++++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
> 
> diff --git a/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
> new file mode 100644
> index 0000000..e86a7a0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/brcm,mspi-spi.txt
> @@ -0,0 +1,39 @@
> +Broadcom MSPI controller
> +
> +The Broadcom MSPI controller is a SPI controller found on various chips such
> +as Cygnus.
> +
> +Required properties:
> +- compatible: Must be "brcm,mspi-v0".
> +
> +- reg:  The first register is the physical base address of the MSPI controller.
> +  The second register is the address of the MSPI interrupt control registers. It
> +  is only required for chips that have a separate register set for extended
> +  interrupt control. This is required for Cygnus.

In which case we would want to mandate the use of a "reg-names"
property, because there could be other kinds of controllers, such as the
one found on BCM7xxx where we have the 3 "reg" units, the first one is
the MSPI controller register range, while the two others are used for
the Boot SPI portion of the controller to accelerate flash reads, so
completely unrelated here.

Right now, using your driver on this Device Tree/configuration makes
bcm_mspi request the second register range and mistakenly assuming this
is the extended interrupt control register.

You could argue that the BSPI portion should be a separate node, but
even so, better be safe than sorry.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/