Hi Masahiro,
On 10 December 2014 at 06:18, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Simon,
Sorry for my late reply.
On Fri, 5 Dec 2014 07:50:33 -0700 Simon Glass sjg@chromium.org wrote:
Sorry I didn't reply on this.
I have been thinking about this for a while. For SPI we have the same problem and I think I mentioned it in the code somewhere. For the PCI RFC I have already adjusted the platdata lifecycle a little since I think it will simplify all buses, and have added a another data pointer for a different purpose.
For the case you raise the problem as you say is that each driver is required to provide a certain structure for its children so that its uclass is happy. On the other hand the driver may want to add additional information We already have a lot of flexibility so I was waiting to see how much this would really matter (there is after all a complexity trade-off).
With PCI I've made some changes and I think I'll end up adding another pointer. At that point I will also want to change SPI and I2C.
For now, I'd like to leave this alone. It does work and avoids adding new features at this late stage.
Let's revisit when I come back to PCI.
I hope you will come back to here before it gets too late.
If we have lots of drivers converted to DM and some of them start to have various deviations, it will be difficult to merge the common parts.
First priority is to move everything to Kconfig. I sent an RFC.
Second I need to figure out the platdata size of things and the discussion above.
I am not worried about the task. So far it only affects I2C and SPI (and PCI RFC). There are only 3-4 drivers I think. It should be fine. The good news is that with this many uclasses we can be a lot more confident that the design is solid and can cover U-Boot's needs.
Regards, Simon