I acn undertand your complaint in the context of an OF driver
(which we don't have yet) but "mmio-ide" just means nothing to the
current driver, and it doesn't convery enough info on the
programming interface for the conceivable OF driver, it also does
need to know at least "reg-stride" (and maybe "reg-size" in case
only 16/32-bit accesses can be used). Well, if such driver will be
written, I/O mapping support will probably be dropped from it, so
indeed, calling it mmio-ide.c would make sense. But that can be
added when this driver is done, and for now
I don't think the details of what Linux code currently exists should drive the device tree binding. That the current patches use platform_device glue code is an implementation detail (and one I'd rather see go away, in favor of a driver that supports both platform_device and of_device).
I'd really prefer the board name to appear in the "compatible" prop
(to which "mmio-ide" can be appended)...
Sure, that's always good... it was the "instead" that I objected to.
Hmmm. So what is finally suggested devicetree node for this beast - can somebody refine?
I am a little bit confused about decided device_type