From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Rohit Vaswani <rvaswani@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>,
linux-arm-msm@vger.kernel.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Kumar Gala <galak@codeaurora.org>
Subject: Re: Use of drivers/platform and matching include?
Date: Mon, 7 Oct 2013 19:19:41 -0700 [thread overview]
Message-ID: <20131008021941.GA9427@kroah.com> (raw)
In-Reply-To: <52535151.2000508@codeaurora.org>
On Mon, Oct 07, 2013 at 05:26:57PM -0700, Rohit Vaswani wrote:
> On 10/5/2013 10:13 AM, Greg Kroah-Hartman wrote:
> > On Fri, Oct 04, 2013 at 09:48:41AM -0700, Olof Johansson wrote:
> >> On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> 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/<soc vendor>/)
> > Yes.
>
> We agree that there is no need for a dump *all* drivers under
> arm/mach-foo in drivers/platform/foo/. The msm bus driver would be added
> under drivers/bus/. But, we still have some drivers which are quite SoC
> specific and not in the general category of the sub-directories present
> under drivers.
> As Kumar mentioned earlier -
>
> An example driver would be the means we utilize to communicate memory
> regions between various HW blocks on the SoC. So a video/media core
> driver might need access to a header/functions from the memory region
> driver.
>
> Would drivers/misc/qcom-* or drivers/misc/qcom/* be a reasonable place
> to add them ? and the headers could go into include/linux/qcom-*.h
That seems reasonable, but I'd have to see the code to verify this.
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
To: linux-arm-kernel@lists.infradead.org
Subject: Use of drivers/platform and matching include?
Date: Mon, 7 Oct 2013 19:19:41 -0700 [thread overview]
Message-ID: <20131008021941.GA9427@kroah.com> (raw)
In-Reply-To: <52535151.2000508@codeaurora.org>
On Mon, Oct 07, 2013 at 05:26:57PM -0700, Rohit Vaswani wrote:
> On 10/5/2013 10:13 AM, Greg Kroah-Hartman wrote:
> > On Fri, Oct 04, 2013 at 09:48:41AM -0700, Olof Johansson wrote:
> >> On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> 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/<soc vendor>/)
> > Yes.
>
> We agree that there is no need for a dump *all* drivers under
> arm/mach-foo in drivers/platform/foo/. The msm bus driver would be added
> under drivers/bus/. But, we still have some drivers which are quite SoC
> specific and not in the general category of the sub-directories present
> under drivers.
> As Kumar mentioned earlier -
>
> An example driver would be the means we utilize to communicate memory
> regions between various HW blocks on the SoC. So a video/media core
> driver might need access to a header/functions from the memory region
> driver.
>
> Would drivers/misc/qcom-* or drivers/misc/qcom/* be a reasonable place
> to add them ? and the headers could go into include/linux/qcom-*.h
That seems reasonable, but I'd have to see the code to verify this.
greg k-h
next prev parent reply other threads:[~2013-10-08 2:19 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-03 14:45 Use of drivers/platform and matching include? Kumar Gala
2013-10-03 14:45 ` Kumar Gala
2013-10-03 15:27 ` Greg Kroah-Hartman
2013-10-03 15:27 ` Greg Kroah-Hartman
2013-10-03 16:21 ` Kumar Gala
2013-10-03 16:21 ` Kumar Gala
2013-10-03 16:25 ` Greg Kroah-Hartman
2013-10-03 16:25 ` Greg Kroah-Hartman
2013-10-03 16:38 ` Kumar Gala
2013-10-03 16:38 ` Kumar Gala
2013-10-03 16:46 ` Olof Johansson
2013-10-03 16:46 ` Olof Johansson
2013-10-03 17:09 ` Greg Kroah-Hartman
2013-10-03 17:09 ` Greg Kroah-Hartman
2013-10-03 17:54 ` Olof Johansson
2013-10-03 17:54 ` Olof Johansson
2013-10-04 11:18 ` Catalin Marinas
2013-10-04 11:18 ` Catalin Marinas
2013-10-04 11:50 ` Russell King - ARM Linux
2013-10-04 11:50 ` Russell King - ARM Linux
2013-10-04 11:43 ` Russell King - ARM Linux
2013-10-04 11:43 ` Russell King - ARM Linux
2013-10-04 12:03 ` Catalin Marinas
2013-10-04 12:03 ` Catalin Marinas
2013-10-04 11:41 ` Russell King - ARM Linux
2013-10-04 11:41 ` Russell King - ARM Linux
2013-10-04 13:22 ` Greg Kroah-Hartman
2013-10-04 13:22 ` Greg Kroah-Hartman
2013-10-04 16:48 ` Olof Johansson
2013-10-04 16:48 ` Olof Johansson
2013-10-04 19:29 ` Santosh Shilimkar
2013-10-04 19:29 ` Santosh Shilimkar
2013-10-04 19:29 ` Santosh Shilimkar
2013-10-05 17:13 ` Greg Kroah-Hartman
2013-10-05 17:13 ` Greg Kroah-Hartman
2013-10-08 0:26 ` Rohit Vaswani
2013-10-08 0:26 ` Rohit Vaswani
2013-10-08 2:19 ` Greg Kroah-Hartman [this message]
2013-10-08 2:19 ` Greg Kroah-Hartman
2013-10-07 6:48 ` Andi Shyti
2013-10-07 6:48 ` Andi Shyti
2013-10-08 17:57 ` Rohit Vaswani
2013-10-08 17:57 ` Rohit Vaswani
2013-10-09 6:04 ` Andi Shyti
2013-10-09 6:04 ` Andi Shyti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131008021941.GA9427@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=galak@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=olof@lixom.net \
--cc=rvaswani@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.