Hi, Here's some of my thoughts on how a connector format for the DT could be done. Sorry it's taken longer than I hoped - I've been pretty swamped in my day job. This is pretty early thoughts, but gives an outline of the approach I prefer. So.. start with an example of a board DT including a widget socket, which contains pins for an MMIO bus, an i2c bus and 2 interrupt lines. /dts-v1/; / { compatible = "foo,oldboard"; ranges; soc@... { ranges; mmio: mmio-bus@... { #address-cells = <2>; #size-cells = <2>; ranges; }; i2c: i2c@... { }; intc: intc@... { #interrupt-cells = <2>; }; }; connectors { widget1 { compatible = "foo,widget-socket"; w1_irqs: irqs { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; interrupt-map-mask = <0xffffffff>; interrupt-map = < 0 &intc 7 0 1 &intc 8 0 >; }; aliases = { i2c = &i2c; intc = &w1_irqs; mmio = &mmio; }; }; }; }; Note that the symbols are local to the connector, and explicitly listed, rather than including all labels in the tree. This is to enforce (or at the very least encourage) plugins to only access those parts of the base tree. Note also the use of an interrupt nexus node contained within the connector to control which irqs the socketed device can use. I think this needs some work to properly handle unit addresses, but hope that's enough to give the rough idea. So, what does the thing that goes in the socket look like? I'm thinking some new dts syntax like this: /dts-v1/; /plugin/ foo,widget-socket { compatible = "foo,whirligig-widget"; }; &i2c { whirligig-controller@... { ... interrupt-parent = <&widget-irqs>; interrupts = <0>; }; }; Use of the /plugin/ keyword is rather different from existing practice, so we may want a new one instead. The idea is that this would be compiled to something like: /dts-v1/; / { socket-type = "foo,widget-socket"; compatible = "foo,whirligig-widget"; fragment@0 { target-alias = "i2c"; __overlay__ { whirligig-controller@... { ... interrupt-parent = <0xffffffff>; interrupts = <0>; }; }; }; __phandle_fixups__ { /* These are (path, property, offset) tuples) */ widget-irqs = "/fragment@0/__overlay__/whirligig-controller@...", "interrupt-parent", <0>; }; }; Suppose then there's a new version of the board. This extends the widget socket in a backwards compatible way, but there are now two interchangeable sockets, and they're wired up to different irqs and i2c lines on the baseboard: /dts-v1/; / { compatible = "foo,newboard"; ranges; soc@... { ranges; mmio: mmio-bus@... { #address-cells = <2>; #size-cells = <2>; ranges; }; i2c0: i2c@... { }; i2c1: i2c@... { }; intc: intc@... { }; }; connectors { widget1 { compatible = "foo,widget-socket-v2", "foo,widget-socket"; w1_irqs: irqs { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; interrupt-map-mask = <0xffffffff>; interrupt-map = < 0 &intc 17 0 1 &intc 8 0 >; }; aliases = { i2c = &i2c0; intc = &w1_irqs; mmio = &mmio; }; }; widget2 { compatible = "foo,widget-socket-v2", "foo,widget-socket"; w2_irqs: irqs { interrupt-controller; #address-cells = <0>; #interrupt-cells = <1>; interrupt-map-mask = <0xffffffff>; interrupt-map = < 0 &intc 9 0 1 &intc 10 0 >; }; aliases = { i2c = &i2c1; widget-irqs = &w2_irqs; mmio = &mmio; }; }; }; }; A socketed device could also have it's own connectors - the contrived example below has a little 256 byte mmio space (maybe some sort of LPC thingy?): /dts-v1/; /plugin/ foo,widget-socket-v2 { compatible = "foo,superduper-widget}; connectors { compatible = "foo,super-socket"; aliases { superbus = &superbus; }; }; }; &mmio { superbus: super-bridge@100000000 { #address-cells = <1>; #size-cells = <1>; ranges = <0x0 0xabcd0000 0x12345600 0x100>; }; }; &i2c { super-controller@... { ... }; duper-controller@... { }; }; Thoughts? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson