On Sun, Sep 15, 2013 at 7:43 AM, Grant Likely <grant.likely@xxxxxxxxxx> wrote: > On Fri, 13 Sep 2013 08:49:06 -0700, Olof Johansson <olof@xxxxxxxxx> wrote: >> On Fri, Sep 13, 2013 at 7:00 AM, Rob Herring <robherring2@xxxxxxxxx> wrote: >> > On Thu, Sep 12, 2013 at 8:31 PM, Emilio López <emilio@xxxxxxxxxxxxx> wrote: [snip] >> > Better, but this is still wrong. DT describes the hardware. There is >> > no such h/w as a simple-memory-controller. The fact that you have a >> > simple-memory-ctrlr kernel driver is a kernel >> > feature/artifact/limitation. Describe the h/w with a meaningful >> > compatible string and put that string in the simple memory controller >> > driver match table. If someday we have a real driver for said memory >> > controller, then it is only a kernel change to use a different driver. >> >> >> We discussed this over IRC last night -- I still think it makes more >> sense to make the clock driver for sunxi aware of this and just add a >> reference to the clock at init time. >> >> This is never going to differ from board to board (today the clock >> name is the same on all sunxi platforms -- pll5_ddr. And the need will >> likewise be there for all platforms at this time. >> >> If and when it changes in the future, we can reevaluate. But this >> doesn't have to be driven by device tree at this time, it seems to >> just make things overly complicated and contrived. > > I agree. Creating a new platform driver + device tree binding just to > claim a clock that must not be disables does not look like the right > approach to me either. Maybe a driver is overkill, but fully describing the h/w would be a good thing. Only defining the h/w that Linux currently uses is not a good practice (although admittedly hard to avoid). Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
