Hi Grant,
Thanks for the explanation.
On Sat, Mar 12, 2011 at 02:46:20AM -0700, Grant Likely wrote:
On Sat, Mar 12, 2011 at 03:00:57PM +0800, Shawn Guo wrote:
Hello all,
I'm looking at function of_device_alloc in drivers/of/platform.c, and surprisingly found that the platform device instance id is being hard-coded as -1 when calling platform_device_alloc. Does this mean that there is no support of pdev id in DT?
Correct, when generating devices from the DT, the core code has no way of knowing what the 'preferred' number of the device should be. It
If we have this number in DT, the core code gets the way.
expects that when the driver's .probe() hook is called, the driver is smart enough to enumerate the automatically.
Considering that many drivers on ARM platform are replying on pdev->id, we will have to make every single of such drivers become smart.
If yes, can anyone please help me understand why we do not have something in DT node to reflect this id and get it supported? Or this is something on TODO list?
Ideally, you shouldn't be relying on .id at all. Fix your device drivers to enumerate correctly, and use explicit phandle references when specifying connections between devices.
Again, many existing ARM drivers will need to get fixed.
That said, I do understand the issue with needing to reference a specific device by name; like for specifying the console device. In those cases, the correct way to figure out what number a device is supposed to have is to add a property to the /aliases node (see ePAPR
To me, specifying the id in DT, and letting core code get it from DT and pass it to platform_device_alloc seems more natural and straight-forward than creating /aliases node and then parsing it in every single driver that need to figure out the device number.
The most important thing is that the ARM drivers relying on pdev->id will need no changes on this point, if we have pdev->id supported in DT core code.
I can live with the approach you tell, but I doubt that ARM community people will have the same question, when we post the driver changes for DT support.
for a description of /aliases). However, even in this case the driver should be looking at the device tree data, and not depend on the value in pdev->id.
If we have pdev->id specified in DT and retrieved it by core code, the driver is actually looking at the data from DT.