[PATCH 1/3] soc: Introduce drivers/soc place-holder for SOC specific drivers

[Greg Kroah-Hartman]

On Mon, Mar 03, 2014 at 10:13:57AM -0600, Kumar Gala wrote:
> 
> On Mar 2, 2014, at 2:48 PM, Olof Johansson <olof at lixom.net> wrote:
> 
> > On Sun, Mar 02, 2014 at 05:12:06PM +0000, One Thousand Gnomes wrote:
> >> On Fri, 28 Feb 2014 18:18:38 -0500
> >> Santosh Shilimkar <santosh.shilimkar at ti.com> wrote:
> >> 
> >>> Based on earlier thread "https://lkml.org/lkml/2013/10/7/662" and
> >>> further discussion at Kernel Summit'2013, it was agreed to create
> >>> 'driver/soc' for drivers which are quite SOC specific.
> >>> 
> >>> Lets take the discussion forward with this patch.
> >> 
> >> So what happens if you put something in say soc/banana and 3 months later
> >> the same IP block shows up in two other devices both of which have their
> >> own soc/ directory already ?
> > 
> > This isn't so much about IP blocks as about all the other glue logic and
> > management functions that vendors so far seem to implement in their own ways.
> > 
> > I don't remember the name we agreed on, I don't think it was drivers/soc --
> > partly because naming it that brings up the kinds of questions you have.
> > Paul took it upon himself to start sorting this out (and merge through us on
> > arm-soc), so he hopefully remembers better than me. :)
> 
> I think it was drivers/soc for the case that Paul was going to look at.  I’d expect we’d go with drivers/soc/<VENDOR> to reduce churn between newer SoC families from a company sharing something with an older one, etc.
> 
> > 
> >> What happens when the same blocks shows up on both a SoC and
> >> later externally ?
> >> 
> >> Where does a soc specifc gpio driver go ?
> > 
> > drivers/gpio, of course. This isn't changing that.
> > 
> >> It seems to me we've got a lot of confusion here because drivers/ is
> >> split by type, and we've also got arch/* machine specific drivers and
> >> we've got drivers/platform which is intended as far as I can see for
> >> everything you'd put in drivers/soc except for that which goes in arch/*
> >> anyway.
> >> 
> >> If QMSS is arm specific why isn't it in arch/arm, if it's not why isn't
> >> it in drivers/platform ?
> > 
> > drivers/platform are for specific vendor platforms. I.e. various laptop
> > vendors, a few server vendors, etc. Code for a whole silicon vendor's driver
> > does not belong there.
> >> 
> >> Just trying to understand the point of drivers/soc. 
> > 
> > Shortcutting most of the discussion by focusing on this question. ;)
> > 
> > We've been struggling to find a home for some of the code that we want to keep
> > in the kernel tree, and we sat down to talk with (among others) Greg at KS to
> > try to figure out how to move forward.
> 
> We talked about drivers/lib and drivers/soc back at KS.  Greg was
> going to start of drivers/lib and Paul was going to look at
> drivers/soc.

Yes, drivers/lib/ is still on my TODO list, unfortunatly way down it...
I'll get to it "soon" with some variation of "soon" :(

greg "my inbox is full" k-h