Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753714Ab3JDQso (ORCPT ); Fri, 4 Oct 2013 12:48:44 -0400 Received: from mail-qa0-f48.google.com ([209.85.216.48]:61109 "EHLO mail-qa0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751667Ab3JDQsm (ORCPT ); Fri, 4 Oct 2013 12:48:42 -0400 MIME-Version: 1.0 X-Originating-IP: [2620:0:1000:1b02:6e3b:e5ff:fe16:f1aa] In-Reply-To: <20131004132209.GB23923@kroah.com> References: <20131004114128.GL12758@n2100.arm.linux.org.uk> <20131004132209.GB23923@kroah.com> Date: Fri, 4 Oct 2013 09:48:41 -0700 Message-ID: Subject: Re: Use of drivers/platform and matching include? From: Olof Johansson To: Greg Kroah-Hartman Cc: Russell King - ARM Linux , Kumar Gala , Linux Kernel list , "linux-arm-kernel@lists.infradead.org" , linux-arm-msm@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1538 Lines: 36 On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman wrote: > On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote: >> >> So, no, there will be no new drivers under arch/arm. They must be in the >> drivers subtree somewhere. > > I have no objection with this, and encourage it. Ok, so these are some of the requirements as far as I see it: * No per-vendor driver dumping ground under drivers/* (i.e. no drivers/platform//) * No weirdly constructed single-driver directories directly under drivers/* (we already have a few and should look at moving those) because nothing else fits * We need some sort of convention on dependencies. Several of these are more libraries than drivers, i.e. we'll have cross-calls for things like queue management, resource allocation, etc. So having a single location to hold most of these makes sense instead of everything cross-depending on everything else. Based on the above, how about we create something like drivers/resourcemgr to hold these? I think at least parts of the mvebu-mbus driver that ended up under drivers/bus might be a fit to move there. The APM queue allocator would likely be a fit, and maybe some of the qualcomm stuff. Kumar, what are your thoughts on that? Greg? -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/