From: David Brown <davidb@codeaurora.org>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: Daniel Walker <dwalker@fifo99.com>, Dima Zavin <dima@android.com>,
Bryan Huntsman <bryanh@codeaurora.org>,
Kenneth Heitke <kheitke@codeaurora.org>,
Pavel Machek <pavel@ucw.cz>,
tsoni@codeaurora.org, linux-arm-msm@vger.kernel.org,
ARM PORT <linux-arm-kernel@lists.infradead.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] msm: add single-wire serial bus interface (SSBI) driver
Date: Tue, 22 Feb 2011 19:05:58 -0800 [thread overview]
Message-ID: <8ya8vx7jvqh.fsf@huya.qualcomm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1102222049410.22028@xanadu.home> (Nicolas Pitre's message of "Tue, 22 Feb 2011 21:37:28 -0500 (EST)")
On Tue, Feb 22 2011, Nicolas Pitre wrote:
> And if someone else comes up with a SSBI interface, then it will be much
> easier to notice the already existing driver if it is in the driver
> directory rather than somewhere else in some unrelated (from that
> person's pov) obscure directory.
Well, I'm fairly sure that nobody would be making an SSBI interface, but
point taken.
>> It seems kind of unusual to create an entirely new directory under
>> drivers to hold what will only ever be a single driver.
>
> Well, a couple examples exist already: drivers/dca, drivers/nfc,
> drivers/sn, drivers/tc, drivers/vlynq, etc. And if you expect to have
> more oddball msm drivers then you can create a drivers/msm directory,
> similar to the existing drivers/macintosh, drivers/parisc, drivers/s390,
> drivers/sh, drivers/video/omap, drivers/video/omap2, etc.
drivers/msm seems like a reasonable place. We already have other
drivers that are in appropriate places.
So what kinds of things constitute drivers versus arch-specific code?
Currently, iommu drivers seem to be sprinkled throughout arch.
We also have a shared-memory driver-type thing that is only used by
other drivers. Does that make sense to be in drivers/msm?
Ken, do you mind moving this driver into 'drivers/msm' as the first one
there?
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
WARNING: multiple messages have this Message-ID (diff)
From: davidb@codeaurora.org (David Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] msm: add single-wire serial bus interface (SSBI) driver
Date: Tue, 22 Feb 2011 19:05:58 -0800 [thread overview]
Message-ID: <8ya8vx7jvqh.fsf@huya.qualcomm.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1102222049410.22028@xanadu.home> (Nicolas Pitre's message of "Tue, 22 Feb 2011 21:37:28 -0500 (EST)")
On Tue, Feb 22 2011, Nicolas Pitre wrote:
> And if someone else comes up with a SSBI interface, then it will be much
> easier to notice the already existing driver if it is in the driver
> directory rather than somewhere else in some unrelated (from that
> person's pov) obscure directory.
Well, I'm fairly sure that nobody would be making an SSBI interface, but
point taken.
>> It seems kind of unusual to create an entirely new directory under
>> drivers to hold what will only ever be a single driver.
>
> Well, a couple examples exist already: drivers/dca, drivers/nfc,
> drivers/sn, drivers/tc, drivers/vlynq, etc. And if you expect to have
> more oddball msm drivers then you can create a drivers/msm directory,
> similar to the existing drivers/macintosh, drivers/parisc, drivers/s390,
> drivers/sh, drivers/video/omap, drivers/video/omap2, etc.
drivers/msm seems like a reasonable place. We already have other
drivers that are in appropriate places.
So what kinds of things constitute drivers versus arch-specific code?
Currently, iommu drivers seem to be sprinkled throughout arch.
We also have a shared-memory driver-type thing that is only used by
other drivers. Does that make sense to be in drivers/msm?
Ken, do you mind moving this driver into 'drivers/msm' as the first one
there?
Thanks,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2011-02-23 3:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-18 0:34 [PATCH] msm: add single-wire serial bus interface (SSBI) driver Kenneth Heitke
2011-02-18 0:34 ` Kenneth Heitke
2011-02-18 0:34 ` Kenneth Heitke
2011-02-18 0:37 ` Daniel Walker
2011-02-18 0:37 ` Daniel Walker
2011-02-18 0:51 ` Bryan Huntsman
2011-02-18 0:51 ` Bryan Huntsman
2011-02-18 18:46 ` Daniel Walker
2011-02-18 18:46 ` Daniel Walker
2011-02-22 20:47 ` Dima Zavin
2011-02-22 20:47 ` Dima Zavin
2011-02-22 20:47 ` Dima Zavin
2011-02-23 0:10 ` Daniel Walker
2011-02-23 0:10 ` Daniel Walker
2011-02-23 0:17 ` David Brown
2011-02-23 0:17 ` David Brown
2011-02-23 0:39 ` Daniel Walker
2011-02-23 0:39 ` Daniel Walker
2011-02-23 2:37 ` Nicolas Pitre
2011-02-23 2:37 ` Nicolas Pitre
2011-02-23 3:05 ` David Brown [this message]
2011-02-23 3:05 ` David Brown
2011-02-23 3:21 ` Nicolas Pitre
2011-02-23 3:21 ` Nicolas Pitre
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=8ya8vx7jvqh.fsf@huya.qualcomm.com \
--to=davidb@codeaurora.org \
--cc=bryanh@codeaurora.org \
--cc=dima@android.com \
--cc=dwalker@fifo99.com \
--cc=kheitke@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=pavel@ucw.cz \
--cc=tsoni@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.