Re: [PATCH 2/3] ARM: sunxi: Add an ahci-platform compatible AHCIdriver for the Allwinner SUNXi series of SoCs

From: Hans de Goede
Date: Fri Dec 06 2013 - 06:06:38 EST


Hi,

On 12/06/2013 10:12 AM, Oliver Schinagl wrote:

On 06-12-13 10:01, Thomas Petazzoni wrote:
Dear Tejun Heo,

On Wed, 4 Dec 2013 08:23:12 -0500, Tejun Heo wrote:

But again, point me (for dummies ;) in the right direction and I'll
work on it with some help.
Richard and Shawn recently worked on ahci_imx. Can you guys please
talk with each other and figure out what can be done to share as much
as possible among these new platform-specific drivers? I'd really
like to see the common things factored out as much as possible with
only the actual hardware differences described for each device.
Also, please Cc me on such discussions. I have a pending AHCI platform
driver for another ARM SoC family. It is very similar to ahci_platform,
but needs to do a few more things that are SoC specific (map an
additional register area, and do some SoC-specific stuff with them).

For the moment, we're left with two approaches:

* Do what Oliver did, where the ahci_<foo> driver will do its own
SoC-specific stuff, and then will register an additional
platform_device to trigger the ->probe() of the generic
ahci_platform driver. I must say I don't really like this solution,
since it involves having two platform_device registered for the same
piece of hardware (one platform_device to trigger the ->probe of
ahci_<foo>, and another one to trigger the ->probe of ahci_platform).

* Duplicate in ahci_<foo> the (relatively small) amount of code that
is present in ahci_platform.

From my point of view, ahci_platform should be turned into a small
"library", that provides an API for ahci_<foo> drivers to 1/ do their
own custom stuff and 2/ do the common ahci_platform stuff.

This way we avoid the registration of two platform_device for the same
piece of hardware, and we avoid the duplication of code.

Want me to propose a RFC for this idea?
I've started to do what sdhci does with their pltfrm driver, assuming that's the right approach. Since i'm only dabbling and not always 100% sure what should or shouldn't be done, it may take a little while, but looks promising from my end ;)

So is the sdhci-pltfrm approach the correct one? We still have ahci_* drivers, but ahci_platform.c won't be a driver in the sense that it is now anymore.

Sounds good to me. May I suggest simply adding a new ahci_pltfrm driver for
this and leaving the existing ahci_platform alone? Of course in the end
we want the old ahci_platform to go away, but it is probably best to
introduce the new one in parallel and then port things over 1 by 1
by people who can actually test the port :)

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/