* [PATCH] spi: add a bits_per_word to struct spi_board_info
@ 2010-09-01 6:24 Feng Tang
[not found] ` <1283322289-2545-1-git-send-email-feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Feng Tang @ 2010-09-01 6:24 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f; +Cc: David Brownell
Currently a spi device's bits_per_word can only be inited
inside protocol driver's probe func, this patch will enable
platform code to specify this info when registering the
spi_board_info
Signed-off-by: Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
---
drivers/spi/spi.c | 1 +
include/linux/spi/spi.h | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index a9e5c79..a8690e7 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -350,6 +350,7 @@ struct spi_device *spi_new_device(struct spi_master *master,
proxy->chip_select = chip->chip_select;
proxy->max_speed_hz = chip->max_speed_hz;
proxy->mode = chip->mode;
+ proxy->bits_per_word = chip->bits_per_word;
proxy->irq = chip->irq;
strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
proxy->dev.platform_data = (void *) chip->platform_data;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 92e52a1..f36d0d5 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -698,6 +698,8 @@ static inline ssize_t spi_w8r16(struct spi_device *spi, u8 cmd)
* @mode: Initializes spi_device.mode; based on the chip datasheet, board
* wiring (some devices support both 3WIRE and standard modes), and
* possibly presence of an inverter in the chipselect path.
+ * @bits_per_word: Initializes spi_device.bits_per_word, usually it will
+ * be from 8 to 32 bits
*
* When adding new SPI devices to the device tree, these structures serve
* as a partial device template. They hold information which can't always
@@ -742,6 +744,7 @@ struct spi_board_info {
* where the default of SPI_CS_HIGH = 0 is wrong.
*/
u8 mode;
+ u8 bits_per_word;
/* ... may need additional spi_device chip config data here.
* avoid stuff protocol drivers can set; but include stuff
--
1.7.0.4
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
[not found] ` <1283322289-2545-1-git-send-email-feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2010-09-01 15:10 ` Grant Likely
[not found] ` <220308.75070.qm@web180310.mail.gq1.yahoo.com>
0 siblings, 1 reply; 11+ messages in thread
From: Grant Likely @ 2010-09-01 15:10 UTC (permalink / raw)
To: Feng Tang
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, David Brownell
On Wed, Sep 01, 2010 at 02:24:49PM +0800, Feng Tang wrote:
> Currently a spi device's bits_per_word can only be inited
> inside protocol driver's probe func, this patch will enable
> platform code to specify this info when registering the
> spi_board_info
What is the use case that you would want to do this. Knowing what the bits_per_word should be is the responsibility of the spi device driver. What is the use-case where the driver wouldn't know what bits_per_word should be?
g.
>
> Signed-off-by: Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> Cc: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> ---
> drivers/spi/spi.c | 1 +
> include/linux/spi/spi.h | 3 +++
> 2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index a9e5c79..a8690e7 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -350,6 +350,7 @@ struct spi_device *spi_new_device(struct spi_master *master,
> proxy->chip_select = chip->chip_select;
> proxy->max_speed_hz = chip->max_speed_hz;
> proxy->mode = chip->mode;
> + proxy->bits_per_word = chip->bits_per_word;
> proxy->irq = chip->irq;
> strlcpy(proxy->modalias, chip->modalias, sizeof(proxy->modalias));
> proxy->dev.platform_data = (void *) chip->platform_data;
> diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
> index 92e52a1..f36d0d5 100644
> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -698,6 +698,8 @@ static inline ssize_t spi_w8r16(struct spi_device *spi, u8 cmd)
> * @mode: Initializes spi_device.mode; based on the chip datasheet, board
> * wiring (some devices support both 3WIRE and standard modes), and
> * possibly presence of an inverter in the chipselect path.
> + * @bits_per_word: Initializes spi_device.bits_per_word, usually it will
> + * be from 8 to 32 bits
> *
> * When adding new SPI devices to the device tree, these structures serve
> * as a partial device template. They hold information which can't always
> @@ -742,6 +744,7 @@ struct spi_board_info {
> * where the default of SPI_CS_HIGH = 0 is wrong.
> */
> u8 mode;
> + u8 bits_per_word;
>
> /* ... may need additional spi_device chip config data here.
> * avoid stuff protocol drivers can set; but include stuff
> --
> 1.7.0.4
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
[not found] ` <220308.75070.qm-4JhmkcZgSkk/JfqJOfUXs/u2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
@ 2010-09-02 2:01 ` Feng Tang
2010-09-02 5:23 ` David Brownell
0 siblings, 1 reply; 11+ messages in thread
From: Feng Tang @ 2010-09-02 2:01 UTC (permalink / raw)
To: David Brownell
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, David Brownell
On Wed, 1 Sep 2010 23:46:18 +0800
David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:
> Re $SUBJECT ... consider it a quirk of how
> SPI devices get setup that this field isn't
> one of the ones the platform code can set up.
>
> I've thought about fixing this before,
> and decided against it:
>
>
> > What is the use case that you would want to do
> > this. Knowing what the bits_per_word should
> > be is the responsibility of the spi device
> > driver. What is the > use-case where the
> > driver wouldn't know what bits_per_word
> > should be?
>
> What's the case where platform code could
> know "better" than the driver?
Grant also asked me the same question. Yes, driver itself
know the bits_per_word info best in most case, but there is
some device (Option GTM501L spi modem) which supports multiple
bits_per_mode option, and here platform code is the good place
to set it.
One of my intension of this patch is to save some extra spi_setup.
For many spi protocol drivers in kernel, spi_setup() will be
called twice for them, first time is inside spi_new_device(it calls
spi_add_device), the second time will be inside driver's probe
func, after setting bits_per_word info. So if we can set it before
registering board info, then the second spi_setup can be removed for
many drivers.
Thanks,
Feng
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
2010-09-02 2:01 ` Feng Tang
@ 2010-09-02 5:23 ` David Brownell
[not found] ` <930634.1250.qm-4JhmkcZgSkk/JfqJOfUXs/u2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: David Brownell @ 2010-09-02 5:23 UTC (permalink / raw)
To: Feng Tang; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
--- On Wed, 9/1/10, Feng Tang <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
> >
> > What's the case where platform code could
> > know "better" than the driver?
>
> Grant also asked me the same question.
I saw him ask a different question (which
I quoted) ...
Yes, driver itself
> know the bits_per_word info best in most case, but there
> is
> some device (Option GTM501L spi modem) which supports
> multiple
> bits_per_mode option, and here platform code
is the good place to set it.
Not unless it knows which mode the driver uses...
a kind of layering violation.
>
> So if we can set it before
> registering board info, then the second spi_setup can be
> removed for many drivers.
that doesn't seem to me like it'd be a startup
cost that's easily observed; hard for me to
worry about it, but I can see what you mean.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
[not found] ` <930634.1250.qm-4JhmkcZgSkk/JfqJOfUXs/u2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
@ 2010-09-02 6:13 ` Feng Tang
2010-09-08 20:21 ` Grant Likely
0 siblings, 1 reply; 11+ messages in thread
From: Feng Tang @ 2010-09-02 6:13 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi David,
> > Grant also asked me the same question.
>
>
> I saw him ask a different question (which
> I quoted) ...
My mistake, I tried to answer Grant's and your questions in one email to
keep the discussion in one thread.
>
>
> Yes, driver itself
> > know the bits_per_word info best in most case, but there
> > is
> > some device (Option GTM501L spi modem) which supports
> > multiple
> > bits_per_mode option, and here platform code
> is the good place to set it.
>
>
> Not unless it knows which mode the driver uses...
> a kind of layering violation.
spi_board_info has a member of "mode", so for my platform, I prefer to
set all these infos in platform code, while protocol driver can
check if the preset infos like speed_hz/mode/bits_per_word are supported.
I thought platform code have to know the detail of the spi device
when setting spi_board_info for it.
Also the following code quoted from spi_setup() indicates it supports
setting mode for spi_board_info
------------------------------------------------------------------------
bad_bits = spi->mode & ~spi->master->mode_bits;
if (bad_bits) {
dev_dbg(&spi->dev, "setup: unsupported mode bits %x\n",
bad_bits);
return -EINVAL;
}
Thanks,
Feng
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
2010-09-02 6:13 ` Feng Tang
@ 2010-09-08 20:21 ` Grant Likely
[not found] ` <20100908202159.GG7065-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Grant Likely @ 2010-09-08 20:21 UTC (permalink / raw)
To: Feng Tang
Cc: David Brownell, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Thu, Sep 02, 2010 at 02:13:48PM +0800, Feng Tang wrote:
> Hi David,
>
>
> > > Grant also asked me the same question.
> >
> >
> > I saw him ask a different question (which
> > I quoted) ...
>
> My mistake, I tried to answer Grant's and your questions in one email to
> keep the discussion in one thread.
>
> >
> >
> > Yes, driver itself
> > > know the bits_per_word info best in most case, but there
> > > is
> > > some device (Option GTM501L spi modem) which supports
> > > multiple
> > > bits_per_mode option, and here platform code
> > is the good place to set it.
> >
> >
> > Not unless it knows which mode the driver uses...
> > a kind of layering violation.
>
> spi_board_info has a member of "mode", so for my platform, I prefer to
> set all these infos in platform code, while protocol driver can
> check if the preset infos like speed_hz/mode/bits_per_word are supported.
The real problem is that spi_drivers are normally allowed to change
bits_per_word as needed. If the spi_driver gets unbound and
rebound, then the original platform-set value for bits_per_word is
lost and the behaviour changes. If you really want to give the driver
hints about the best setting for bits_per_word or similar, then you
should probably use a driver-specific pdata structure.
g.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
[not found] ` <20100908202159.GG7065-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
@ 2010-09-09 3:14 ` Feng Tang
2010-09-09 3:18 ` Grant Likely
0 siblings, 1 reply; 11+ messages in thread
From: Feng Tang @ 2010-09-09 3:14 UTC (permalink / raw)
To: Grant Likely
Cc: David Brownell, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi Grant,
On Thu, 9 Sep 2010 04:21:59 +0800
Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> > >
> > > Yes, driver itself
> > > > know the bits_per_word info best in most case, but there
> > > > is
> > > > some device (Option GTM501L spi modem) which supports
> > > > multiple
> > > > bits_per_mode option, and here platform code
> > > is the good place to set it.
> > >
> > >
> > > Not unless it knows which mode the driver uses...
> > > a kind of layering violation.
> >
> > spi_board_info has a member of "mode", so for my platform, I prefer
> > to set all these infos in platform code, while protocol driver can
> > check if the preset infos like speed_hz/mode/bits_per_word are
> > supported.
>
> The real problem is that spi_drivers are normally allowed to change
> bits_per_word as needed.
For drivers who don't accept bits_per_word comes from platform code, it
could just ignores it and set the value it wants.
> If the spi_driver gets unbound and
> rebound, then the original platform-set value for bits_per_word is
> lost and the behaviour changes.
Um, if you are talking about driver load/unload, then the bits_per_word
info won't get lost as it is set to spi_device from spi_board_info when
spi_new_device get called.
> If you really want to give the driver
> hints about the best setting for bits_per_word or similar, then you
> should probably use a driver-specific pdata structure.
Good point, really a solution to the GTM501L modem driver. But still,
adding the bits_per_word to spi_board_info will be more generic when
more devices which support multiple bits models show up.
Thanks,
Feng
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
2010-09-09 3:14 ` Feng Tang
@ 2010-09-09 3:18 ` Grant Likely
[not found] ` <20100909031827.GA10389-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: Grant Likely @ 2010-09-09 3:18 UTC (permalink / raw)
To: Feng Tang
Cc: David Brownell, spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Thu, Sep 09, 2010 at 11:14:45AM +0800, Feng Tang wrote:
> Hi Grant,
>
> On Thu, 9 Sep 2010 04:21:59 +0800
> Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>
> > > >
> > > > Yes, driver itself
> > > > > know the bits_per_word info best in most case, but there
> > > > > is
> > > > > some device (Option GTM501L spi modem) which supports
> > > > > multiple
> > > > > bits_per_mode option, and here platform code
> > > > is the good place to set it.
> > > >
> > > >
> > > > Not unless it knows which mode the driver uses...
> > > > a kind of layering violation.
> > >
> > > spi_board_info has a member of "mode", so for my platform, I prefer
> > > to set all these infos in platform code, while protocol driver can
> > > check if the preset infos like speed_hz/mode/bits_per_word are
> > > supported.
> >
> > The real problem is that spi_drivers are normally allowed to change
> > bits_per_word as needed.
>
> For drivers who don't accept bits_per_word comes from platform code, it
> could just ignores it and set the value it wants.
>
> > If the spi_driver gets unbound and
> > rebound, then the original platform-set value for bits_per_word is
> > lost and the behaviour changes.
>
> Um, if you are talking about driver load/unload, then the bits_per_word
> info won't get lost as it is set to spi_device from spi_board_info when
> spi_new_device get called.
No, I'm talking about a specific device's spi_driver being unloaded
and reloaded. spi_new_device would only be called if the spi bus
driver was reloaded, triggering a call to spi_register_master().
> > If you really want to give the driver
> > hints about the best setting for bits_per_word or similar, then you
> > should probably use a driver-specific pdata structure.
>
> Good point, really a solution to the GTM501L modem driver. But still,
> adding the bits_per_word to spi_board_info will be more generic when
> more devices which support multiple bits models show up.
As described above, anything that a driver can legally modify cannot
be "preset" by the platform code because the initial preset values
will get lost. A different mechanism must be used so that initial
conditions remain unchanged between successive binding of a driver.
g.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
[not found] ` <20100909031827.GA10389-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
@ 2010-09-09 3:48 ` David Brownell
[not found] ` <570796.22556.qm-g47maUHHHF8P4eY3Ra60wvu2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 11+ messages in thread
From: David Brownell @ 2010-09-09 3:48 UTC (permalink / raw)
To: Feng Tang, Grant Likely
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
You know, in retrospect, I shouldn't have put
most of those SPI device setup params into the
board setup data.
There's one which MUST be there: polarity of
the chip select line. The rest seem like they
could (and arguably should) all be handled by
driver-specific params. (Possible exception:
clock rate, which sometimes matters even when
chips are not selected).
At any rate, adding MORE driver-specific params
(like bits-per-word) to board setup data seems
like the wrong direction to go...
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
[not found] ` <570796.22556.qm-g47maUHHHF8P4eY3Ra60wvu2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
@ 2010-09-09 4:36 ` Grant Likely
2010-09-09 6:06 ` Feng Tang
1 sibling, 0 replies; 11+ messages in thread
From: Grant Likely @ 2010-09-09 4:36 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Wed, Sep 8, 2010 at 9:48 PM, David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:
> You know, in retrospect, I shouldn't have put
> most of those SPI device setup params into the
> board setup data.
Out of curiosity, what was the reasoning behind registering the spi
board info separately instead of passing it explicitly via the spi bus
driver's platform_data? (I ask only because I'm unfamiliar with the
history).
> There's one which MUST be there: polarity of
> the chip select line. The rest seem like they
> could (and arguably should) all be handled by
> driver-specific params. (Possible exception:
> clock rate, which sometimes matters even when
> chips are not selected).
Of course, CS polarity and clock rate are more representative of the
interconnection than of the device. Regardless though, it should be
done in such a way that a properly behaved spi_driver cannot change
the initial .probe() conditions.
> At any rate, adding MORE driver-specific params
> (like bits-per-word) to board setup data seems
> like the wrong direction to go...
indeed!
g.
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] spi: add a bits_per_word to struct spi_board_info
[not found] ` <570796.22556.qm-g47maUHHHF8P4eY3Ra60wvu2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
2010-09-09 4:36 ` Grant Likely
@ 2010-09-09 6:06 ` Feng Tang
1 sibling, 0 replies; 11+ messages in thread
From: Feng Tang @ 2010-09-09 6:06 UTC (permalink / raw)
To: David Brownell; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
On Thu, 9 Sep 2010 11:48:22 +0800
David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org> wrote:
> You know, in retrospect, I shouldn't have put
> most of those SPI device setup params into the
> board setup data.
>
> There's one which MUST be there: polarity of
> the chip select line. The rest seem like they
> could (and arguably should) all be handled by
> driver-specific params. (Possible exception:
> clock rate, which sometimes matters even when
> chips are not selected).
>
> At any rate, adding MORE driver-specific params
> (like bits-per-word) to board setup data seems
> like the wrong direction to go..
Agree. Thank you two for helping me get an overall picture of
configuring these parameters.
-Feng
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-09-09 6:06 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-01 6:24 [PATCH] spi: add a bits_per_word to struct spi_board_info Feng Tang
[not found] ` <1283322289-2545-1-git-send-email-feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2010-09-01 15:10 ` Grant Likely
[not found] ` <220308.75070.qm@web180310.mail.gq1.yahoo.com>
[not found] ` <220308.75070.qm-4JhmkcZgSkk/JfqJOfUXs/u2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
2010-09-02 2:01 ` Feng Tang
2010-09-02 5:23 ` David Brownell
[not found] ` <930634.1250.qm-4JhmkcZgSkk/JfqJOfUXs/u2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
2010-09-02 6:13 ` Feng Tang
2010-09-08 20:21 ` Grant Likely
[not found] ` <20100908202159.GG7065-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2010-09-09 3:14 ` Feng Tang
2010-09-09 3:18 ` Grant Likely
[not found] ` <20100909031827.GA10389-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2010-09-09 3:48 ` David Brownell
[not found] ` <570796.22556.qm-g47maUHHHF8P4eY3Ra60wvu2YVrzzGjVVpNB7YpNyf8@public.gmane.org>
2010-09-09 4:36 ` Grant Likely
2010-09-09 6:06 ` Feng Tang
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.