On Tuesday 03 May 2016 11:11:56 Rob Herring wrote: > > + > > +Child nodes: > > +Every SLIMbus controller node can contain zero or more child nodes > > +representing slave devices on the bus. Every SLIMbus slave device is > > +uniquely determined by the enumeration address containing 4 fields: > > +Manufacturer ID, Product code, Device index, and Instance value for > > +the device. > > +If child node is not present and it is instantiated after device > > +discovery (slave device reporting itself present), > > +its name will be in this format: "217:60:1:0" > > + > > +However, the device may need additional non-standard way to power it > > +up so that it can start functioning. In that case, child node will > > +need to be present as slave of the slimbus-controller device. > > +The compatible property will be necessary so that corresponding > > +driver can probe and execute the required procedure to make it > > +functional. > > + > > +Required property for SLIMbus child node if it is present: > > +- reg - enumeration address fields of the device > > + > > +- compatible - name of SLIMbus child node using practice typically > > + followed by discoverable buses: > > + "<manufacturer>,<product-model>", "slim" > > Im most cases for compatible strings on discoverable buses, the VID and > PID (and perhaps more) are used to form the compatible string. See USB > binding for a recent example. This will save you from having to make up > strings for every device. Actually it seems like the current binding puts the same manufacturer ID and product ID pair into both address and compatible string. Is that correct? I would have expected the address to have only index and instance fields and the compatible string match whatever we can detect by looking at that device. This has probably been discussed 5 years ago when the patches were first posted, but I don't remember the outcome. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
