[RFC] Driver configuration using Device Tree

[Grant Likely]

On Tue, 09 Jul 2013 14:10:58 -0600, Eric Holmberg <eholmber at codeaurora.org> wrote:
> I am trying to determine if Device Tree is an appropriate use for 
> configuring drivers and would like to request comments.  We currently 
> use Device Tree in our Shared Memory Driver (SMD) that manages up to 64 
> ports (where a port consists of an RX FIFO and a TX FIFO) between any 
> two processors and a pair of interrupts for each processor.  The shared 
> memory address and interrupt configuration is stored in Device Tree and 
> since this is hardware, this is considered an acceptable use.  However, 
> we also have two separate modules that use SMD and export devices to 
> userspace through either the TTY framework (SMD TTY) or through a 
> character device (SMD PKT).  For these drivers, the configuration has 
> less to do with hardware and more about which port to connect to in the 
> SMD driver and how to expose the port to userspace through a device 
> node.  This code is used in Linux-based phones.
> 
> The DT configuration looks like this:
>          qcom,smdtty {
>                  compatible = "qcom,smdtty";
> 
>                  qcom,smdtty-ds {
>                          qcom,smdtty-port-name = "DS";
>                          qcom,smdtty-edge = <0>;
>                          qcom,smdtty-dev-idx = <0>;
>                  };
>                  . . .
>                 /* on the order of 10 more port config items */
>        };
> 
> 
> Question
> --------
> Is there a concern that DT should only be used for hardware 
> configuration and that this "driver configuration" is not an acceptable 
> use?  If it is not acceptable, should I go back to using platform 
> devices (seems like a step backwards) or some other method such as 
> exporting a control channel to userspace that can be configured using an 
> IOCTL?

It still is a reasonable leap to say that the DT contains the known-sane
configuration settings that are needed by the platform. It may not be
/strictly/ a hardware description, but it is a description of the usage
model of the platform.

I would however say that you only want that configuration to appear once
in the system. If, say, the linux host sets up and configures the SMD
regions, then I would like to see the remote systems dynamically
receiving the configuration from the linux host instead of having a
separate configuration file.

g.