On Mon, Nov 2, 2009 at 6:14 AM, Wolfram Sang <w.s...@pengutronix.de> wrote: >> Also, I'm resistant to changing the probe layout on this driver at >> this time. With the work being done to generalize the OF support >> code, there is a strong possibility that of_platform will be >> deprecated in favor of going back to using the platform bus directly >> (just like how OF support works for i2c, spi, etc). I'd rather not >> refactor the driver until I'm certain of the direction that things are >> going to go. > > And this was possibly the best answer I could get \o/ Sounds really promising, > is there somewhere a discussion about how OF-generalization could happen?
It has been discussed on-and-off on the mailing list and on IRC. There are 2 major problems that need to be solved before it can be done: 1. Figure out how to do OF-style driver probing with the platform bus. I could use the same heuristic as used by i2c & spi, but that approach isn't very scalable, and doesn't handle backwards compatibility very well. 2. Figure out the best way to extract platform data from the device tree without having a huge impact on the device drivers. The adapter code still driver specific, so it needs to be part of the device driver itself, but I want to establish a pattern which does not require major surgery to platform drivers in order to add OF support. >> - return mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64, >> + rc = mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64, >> irq_of_parse_and_map(op->node, 0), id); >> + if (!rc) > > A matter of taste, maybe: I'd prefer > > if (rc == 0) > > as (!ptr) is often used for catching errors with pointers, but here it is the > 'all went OK'-path. Okay, I'll change this. Thanks for the feedback. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
