On 18/11/14 00:26, Andrew Bresticker wrote: > Hi Naidu, > > On Mon, Nov 17, 2014 at 4:12 PM, Naidu Tellapati > <Naidu.Tellapati@xxxxxxxxxx> 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:
signature.asc
Description: OpenPGP digital signature
