[anybus,v3,5/6] dt-bindings: anybuss-host: document devicetree binding

From: Sven Van Asbroeck <svendev@arcx.com>

This patch adds devicetree binding documentation for the
Arcx Anybus-S host.

Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
---
 .../bindings/bus/arcx,anybuss-host.txt        | 36 +++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/arcx,anybuss-host.txt

On Sun, Nov 4, 2018 at 4:55 PM <thesven73@gmail.com> wrote:


> ---
>  .../bindings/bus/arcx,anybuss-host.txt        | 36 +++++++++++++++++++
>  1 file changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/bus/arcx,anybuss-host.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/arcx,anybuss-host.txt b/Documentation/devicetree/bindings/bus/arcx,anybuss-host.txt
> new file mode 100644
> index 000000000000..5c28e4e09bb2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/arcx,anybuss-host.txt
> @@ -0,0 +1,36 @@
> +* Arcx Anybus-S host
> +
> +This host communicates with the SoC over a parallel bus. It is
> +expected that its Device Tree node is specified as the child of a node
> +corresponding to the parallel bus used for communication.
> +
> +Required properties:
> +
> +  - compatible : The following string:
> +        "arcx,anybuss-host"
> +
> +  - reg : bus memory area where the Anybus-S host dpram is located.
> +
> +  - interrupts : interrupt connected to the Anybus-S host interrupt line.
> +       Generic interrupt client node bindings are described in
> +               interrupt-controller/interrupts.txt
> +
> +  - resets : the reset line associated with the Anybus-S host.
> +
> +Example of usage:
> +
> +This example places the Anybus-S host on top of the i.MX WEIM parallel bus, see:
> +Documentation/devicetree/bindings/bus/imx-weim.txt

To allow describing connected devices, I think we need a #address-cells
and #size-cells property here, with fixed values. If a device is attached by
a single 32-bit integer, then

 #address-cells = <1>;
 #size-cells = <0>;

should be enough, otherwise you might need additional address cells.
Actually listing the device(s) can be optional, but we do need the
adress in order
to let the bus code associate a device_node pointer with the child
device structure to let a driver read the properties.

       Arnd

Hi Arnd, thank you for the review and the feedback !

>
> To allow describing connected devices, I think we need a #address-cells
> and #size-cells property here, with fixed values.

I'm not sure I understand. Connected devices aren't described in the
devicetree. The anybus specification defines an id register, which is
then used to load the client driver automatically, in the manner of
pci/usb.

In case I have misinterpreted your feedback, could you clarify a bit?
Thanks,
Sven

E.g. here's the definition of an anybus client driver, a profinet card:

static struct anybuss_client_driver profinet_driver = {
    .probe = profinet_probe,
    .remove = profinet_remove,
    .driver = {
        .name   = "hms-profinet",
        .owner = THIS_MODULE,
    },
    .fieldbus_type = 0x0089,
};

static int __init profinet_init(void)
{
    return anybuss_client_driver_register(&profinet_driver);
}
module_init(profinet_init);

On Thu, Nov 8, 2018 at 3:21 PM Sven Van Asbroeck <thesven73@gmail.com> wrote:
>
> Hi Arnd, thank you for the review and the feedback !
>
> >
> > To allow describing connected devices, I think we need a #address-cells
> > and #size-cells property here, with fixed values.
>
> I'm not sure I understand. Connected devices aren't described in the
> devicetree. The anybus specification defines an id register, which is
> then used to load the client driver automatically, in the manner of
> pci/usb.
>
> In case I have misinterpreted your feedback, could you clarify a bit?

This is related to my reply on another patch of this series. I think it's
likely that you need to be able to describe anybus devices in DT
for additional properties in some cases, even if the common case
doesn't need it.

We do the same thing on PCI and USB, where normally everything
is probed through hardware access, but a device driver can look
at dev->of_node to see if that contains any further properties.

       Arnd

On Thu, Nov 8, 2018 at 9:27 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> We do the same thing on PCI and USB, where normally everything
> is probed through hardware access, but a device driver can look
> at dev->of_node to see if that contains any further properties.
>

This is very interesting. Spent some time trying to find an example of this
for pci/usb, but drew a blank. Could you point me to an example?

One of our products has pcie ethernet, but we have to patch it so it can
grab its mac address from the bootloader. You are saying that there is
a standard way to accomplish this?