[PATCH v4 2/3] ARM: mach-shmobile: r8a7779: add SATA support

[Magnus Damm]

Hi Simon

On Fri, Mar 1, 2013 at 4:23 PM, Simon Horman <horms at verge.net.au> wrote:
> On Thu, Feb 28, 2013 at 05:41:48PM -0800, Olof Johansson wrote:
>> On Wed, Feb 27, 2013 at 11:39:14PM +0300, Sergei Shtylyov wrote:
>> > From: Vladimir Barinov <vladimir.barinov at cogentembedded.com>
>> >
>> > Add SATA clock for r8a7779 SoC (for both device tree and usual cases).
>> > Register SATA controller as a "late" platform device on r8a7779 SoC.
>>
>> Hi,
>>
>> If you have the a binding in the device tree (which you do through patch 1/3),
>> then there's no reason to have a platform device for it.
>
> Hi Olof,
>
> the DT exists but currently the marzen board brings up all
> of its devices using platform devices. Which if nothing else is
> internally consistent.
>
> I suppose it would be possible to add a call to
> r8a7779_add_standard_devices_dt() and have the board bring
> up this device using DT and the rest using platform drivers
> (until the drivers are migrated to DT).
>
> Would that be your preferred option?
>
> Magnus, how do you feel about this idea?

I fail to see the upside I'm afraid.

I believe the best way forward is for us to keep on following the same
style as we have done so far. So for drivers they should begin by
interfacing as regular platform devices drivers and then add DT
support incrementally. This allows us to try out things in a non-ABI
kind of way and it also allows us to add support for various hardware
feature that do not yet support DT like in the case of DMA Engine.
With platform devices we can also use the driver with the SH
architecture.

You can of course do some mixed DT and platform device support on a
board-level, but I don't really see what would be good about it.
Actually, I believe that will just make things overly complicated
without giving us the possibility to try out certain experimental
features with platform-device-only interface.

Of course Simon, if you prefer to follow your proposal above then go
ahead. However, please consider the case when this code will be back
ported to LTSI-3.4.

Thanks,

/ magnus