No support of platform device instance id?

[Grant Likely]

On Sat, Mar 19, 2011 at 8:39 PM, Shawn Guo <shawn.guo at freescale.com> wrote:
> On Thu, Mar 17, 2011 at 11:08:19AM -0600, Grant Likely wrote:
>> On Thu, Mar 17, 2011 at 12:31:15PM +0800, Shawn Guo wrote:
>> > On Wed, Mar 16, 2011 at 05:05:00PM -0600, Grant Likely wrote:
>> > >
>> > [...]
>> > > I'd like to have feedback on the new code to make sure that the model
>> > > is sane.  There are some fiddly code it there which is used to match
>> > > platform_device registrations to nodes in the device tree.  I *think*
>> > > it makes sense, but I'd like to hear other opinions.
>> > >
>> > Binding platform_device with of_node via resources matching seems a
>> > little fiddly, but your implementation looks solid to me.  I made a
>> > quick scan on all the platform_device registration under
>> > arch/arm/plat-mxc/devices, nothing would be broken, only except
>> > platform-gpio_keys which is not an on-chip device.
>>
>> Right; and doing it this way doesn't make sense for anything that is
>> board/system specific because if the board is using the DT, then it is
>> simpler and more reliable to avoid the matching heuristic entirely.
>>
>> > Looking at the code, I'm wondering how the binding of resource type
>> > IORESOURCE_DMA looks like.  I'm seeing some platform_device is using
>> > this flag to tell dma channel fixed for the device.  I'm not sure if
>> > it can be fit in property 'dma-ranges'.  And I only see IORESOURCE_MEM
>> > and IORESOURCE_IRQ being used in the matching model.
>>
>> The matching is simply a heuristic that makes a best guess about how
>> how device nodes line up with platform_device registrations.  Right
>> now the heuristic is to look at the register ranges and irqs described
>> in the node and make sure that each of them are listed in the
>> platform_device.  If the platform_device has additional resources,
>> then it simply ignores them.  That seems to be sufficient for accurate
>> matching, but I won't know for sure until people start using it.
>>
>> If there are situations where the heuristic does not work, then I'd
>> like to know what they are so that the algorithm can be fixed, or in
>> the absolute worst case implement workaround logic.
>>
>> One option I'm considering which would improve the accuracy of the
>> heuristic is to add a 'char *of_compatible' field to struct
>> platform_device.  Then platform_devices could optionally be tagged
>> with the compatible value that must be present in order to be matched
>> with a node.
>>
>> I definitely want feedback on the matching heuristic!
>>
> Tested on babbage with serial, fec and esdhc drivers, and I did see
> it solves problems of clkdev dev_id matching and pdev->id use.  And
> it even helped to discover one problem with .end definition of fec
> resource IORESOURCE_MEM.  I will send mainline a patch for that soon.

Awesome, thanks!

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.