On 8/3/2011 6:43 PM, Grant Likely wrote:
On Wed, Aug 3, 2011 at 4:04 PM, Cousson, Benoit<b-cousson@xxxxxx> wrote:
Hi Grant,
Going further with the usage of OF_DEV_AUXDATA_ID, I realized that this is is not doing what I was expecting. My expectation might be silly, but in order to make platform_match to work without DT matching mechanism, you need to have the driver name in the pdev->name field:
/* fall-back to driver name match */
return (strcmp(pdev->name, drv->name) == 0);
Except that the of_device_add function is doing that:
pdev->name = dev_name(&ofdev->dev);
pdev->id = -1;
Yes, I know. It is written that way on purpose so that it doesn't get
used to avoid adding a match table to the device driver because
auxdata is a stop-gap solution. It is *not* intended to be used long
term (with one exception for passing platform callbacks when there is
no other solution).
Outch... You guys are doing your best to make our life harder :-)
auxdata passes platform_data and overrides the device name when there
is no way easy way to make the driver work without it. It handles the
the current implementation of clocks and regulators which aren't yet
populated from the device tree. It will go away when clock&
regulator bindings are implemented.
By implementing it the way it is, it ensures that no drivers
inadvertently depends on auxdata, and will thus break when the auxdata
entries are removed. Manjunath mentioned that there is a patch that
allows the id to be set, but it still doesn't set the driver name in a
way that will allow existing drivers to bind using the old method, and
that is by design.
I understand what you are asking for, but the DT matching mechanism is
absolutely required. Adding it to drivers is certainly not any more
onerous that maintaining a bunch of auxdata tables for boards.
Fair enough.
Bottom line is that DT is a all inclusive pack, you cannot skip one part
even if it is not necessarily needed right now :-(
I understand very well the final goal, I was just trying to spread the
huge effort that DT migration will require to focus first on the stuff
located in mach-omap, meaning all the board and devices init part.
I was hoping to let the drivers for the moment until the first phase is
done. Since auxdata was already there to help the migration, I was just
expecting it to be even more helpful.
Besides, part of the point of the move to DT is to eliminate device
and device data tables at the board file level, which is another
reason why auxdata is a temporary solution.
Again, I got that point, it was not our intent to use that as a final
solution.
Let's start hacking the OMAP drivers then...
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
