Re: [PATCH v1 1/2] efuse: IMG Pistachio eFuse Controller

[James Hogan <james.hogan-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

On 18/11/14 00:26, Andrew Bresticker wrote:
> Hi Naidu,
> 
> On Mon, Nov 17, 2014 at 4:12 PM, Naidu Tellapati
> <Naidu.Tellapati-1AXoQHu6uovQT0dZR+AlfA@public.gmane.org> wrote:
>> Hi Andrew,
>>
>> (We will respond to James Hogan's remaining review comments in a separate email)
>>
>>>>
>>>> +obj-$(CONFIG_SOC_IMG)           += pistachio/
>>
>>> What is CONFIG_SOC_IMG? It sounds very generic.
>>
>> May I have your suggestions on the above.
>>
>> (Assuming we create drivers/soc/img/ instead of drivers/soc/pistachio/)

What would "belong" in there?
Basically anything that doesn't belong in some particular subsystem?

> I don't have much visibility into ImgTec SoCs other than Pistachio,
> but I think introducing a SOC_IMG Kconfig symbol is a good idea as it
> gives drivers for various pieces of IP present on ImgTec SoCs
> (watchdog, I2C, DMA, etc.) a more specific dependency than say MIPS or
> METAG.  Maybe James has a suggestion for how to deal with this?

I have very limited experience with IMG based SoCs other than Chorus2
and TZ1090, but I'm not convinced an SOC_IMG adds any value tbh if it is
simply a way to group drivers. Both SOC_IMG and METAG || MIPS would end
up being fuzzy/inexact convenience dependencies to reduce clutter on
other platforms, so perhaps it would be best kept simple, flexible and
easily understandable. I don't feel strongly about it either way though.

I suspect certain IP blocks may potentially get licensed separately and
require exceptions (PDP springs to mind?), so it probably is technically
a per-IP block thing. James Hartley might have a better idea about that.

Cheers
James


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]