On Mon, Sep 23, 2019 at 12:42 PM Leonard Crestez <leonard.crestez@xxxxxxx> wrote: > > On 17.09.2019 23:20, Rob Herring wrote: > > On Fri, Aug 23, 2019 at 05:36:56PM +0300, Leonard Crestez wrote: > >> The interconnect-node-id property is parsed by the imx interconnect > >> driver to find nodes on which frequencies can be adjusted. > >> > >> Add #interconnect-cells so that device drivers can request paths from > >> bus nodes instead of requiring a separate "virtual" node to represent > >> the interconnect itself. > >> > >> Signed-off-by: Leonard Crestez <leonard.crestez@xxxxxxx> > >> --- > >> Documentation/devicetree/bindings/devfreq/imx-ddrc.yaml | 5 +++++ > >> Documentation/devicetree/bindings/devfreq/imx.yaml | 5 +++++ > >> 2 files changed, 10 insertions(+) > > > > Please combine this with the other series for devfreq support. > > I understand that having two series which add to the same bindings file > is odd but the devfreq and interconnect parts are independent to a very > large degree and devfreq can be useful on it's own. To start with, I'm suspicious of any 'devfreq' binding because that's a Linux thing. I somewhat expect that the interconnect binding should replace the devfreq binding, but I haven't been able to investigate. > The only reason devfreq bindings are updated is to avoid adding a > "virtual" node for interconnect. Since DT is a big source of confusion > here can you read https://patchwork.kernel.org/cover/11111865/#22883457 > and maybe offer some advice? Design something that matches the structure of the h/w not how Linux drivers happen to be structured. I can't tell what that is without any context around adding a couple of properties. Nor do I have the time to dig into each SoC vendor's bus structure if it's even documented publicly. I also don't follow why you need 'interconnect-node-id' and if you do, it should be a common property. Rob
