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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 6 Dec 2013 10:18:56 +0100
From:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
To:	Oliver Schinagl <oliver@...inagl.nl>
Cc:	Tejun Heo <tj@...nel.org>,
	Olliver Schinagl <oliver+list@...inagl.nl>,
	grant.likely@...aro.org,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, dev@...ux-sunxi.org,
	maxime.ripard@...e-electrons.com, ijc@...lion.org.uk,
	hdegoede@...hat.com, Richard Zhu <r65037@...escale.com>,
	Shawn Guo <shawn.guo@...aro.org>
Subject: Re: [PATCH 2/3] ARM: sunxi: Add an ahci-platform compatible AHCI
 driver for the Allwinner SUNXi series of SoCs

Dear Oliver Schinagl,

On Fri, 06 Dec 2013 10:12:34 +0100, Oliver Schinagl wrote:

> >  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 ;)

Yes, the approach of shdci_pltfrm is exactly the one I was proposing
here, so it definitely looks like the right direction to me (though my
opinion is not authoritative at all in this area, obviously).

> 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.

Yes, seems good. We will still need ahci_<foo> for the various SoC
families, because depending on the SoC, you have different things to do
(take various clocks, or do other SoC-specific configuration). As an
example, the main thing I have to do on the SoC I'm working with is
configuring some memory windows that allow the SATA controller to do
DMA to the DRAM. This configuration is inherently completely specific
to this SoC family, and it wouldn't make sense to have that in an
ahci_platform driver shared by all platforms.

Oliver, can you Cc me on your future patches about this topic, so that
I can test them in the context of the SoC I'm working on?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/