[PATCH v8 0/4] edac: Add APM X-Gene SoC memory controller EDAC driver

Loc Ho lho at apm.com
Mon May 11 15:29:10 PDT 2015


>> On Wed, May 6, 2015 at 11:29 AM, Borislav Petkov <bp at alien8.de> wrote:
>> > On Wed, May 06, 2015 at 11:12:20AM -0700, Loc Ho wrote:
>> >> 1. Whether to have an single driver for APM EDAC or multiple instance
>> >> of 4 different drivers. With single driver, it does not scale in the
>> >> future when we add/remove memory controllers and CPU domains. This is
>> >
>> > Why doesn't it scale? Please explain this to me more verbosely.
>> Let me explain a bit more. We have four memory controller today.
>> Therefore, I would like to have 4 DTS node and the same driver probe
>> function called 4 times. If there is only one driver for the entire
>> APM EDAC, I would have to merge all the resource registers into an
>> single DTS node and its probe function called one time. In this one
>> driver design, what would I do in future chip or variant of the chip
>> in which it remove or add an addition memory controller? I would have
>> to change the driver as well as the DTS node. In the four instance
>> probe design, all I need is to add an additional DTS node.
> There are lots of possible representations in DT that would solve this.
> First of all, a device node can be turned into a platform_device but
> does not have to, so you you could have one DT node for the common
> parts (the pcp), and then subnodes underneath it, and have the driver
> attach to the main device but parse the subnodes manually to see
> what registers are there. There is no magic involved here, and this
> would address the concerns that Boris and I have.
> Another option would be to have multiple drivers: have one driver
> that handles the common parts here, and make that export a shared
> interface to which the other drivers can register, then create
> five drivers that each do one thing. In my opinion that would work
> just as well, and be a nice abstraction, but I suspect that Boris
> would prefer doing it the other way.

Thanks all for the comment. I will follow the design as with
gpio-dwapb driver. This would take care of Borislav concern as
mentioned by Arnd.


More information about the linux-arm-kernel mailing list