a nicer function
to retrieve the spi device name, e.g. spi_dev_name(). That way, the
internal implementation can change in the future without having to
update all drivers.
Grant, what do you think?
--
Jean Delvare
On Sun, 16 Sep 2012 09:19:34 -0700, Guenter Roeck wrote:
On Sun, Sep 16, 2012 at 03:09:01PM +0200, Jean Delvare wrote:
On Tue, 11 Sep 2012 13:52:50 -0700, Guenter Roeck wrote:
That's a very nice cleanup, but it makes me wonder...
Wouldn't it make sense to create the name attribute of spi
or not there's
@@ -260,6 +268,7 @@ struct i2c_board_info {
struct dev_archdata *archdata;
struct device_node *of_node;
int irq;
+ int irq_gpio;
};
/**
--
Jean Delvare
Hi Jonathan,
On Fri, 02 Sep 2011 10:19:24 +0100, Jonathan Cameron wrote:
On 09/02/11 07:56, Jean Delvare wrote:
Stephen,
Can you please fix your e-mail client / system / whatever so that your
patch series are no longer sent duplicated?
On Thu, 1 Sep 2011 16:04:27 -0600, Stephen
code
but actual drivers. It does include i2c and spi, which stick out by
being a lot larger than most others.
Opinions? Move or don't move?
No opinion, I just don't care.
--
Jean Delvare
--
Simplify data backup
/i2c is in a totally different place?
While I am surprised, I am not necessarily objecting. But it seems that
you should better define what your actual plan is, before asking us if
we agree with it.
--
Jean Delvare
Hi Wolfram,
On Tue, 27 Jan 2009 10:53:26 +0100, Wolfram Sang wrote:
On Tue, Jan 27, 2009 at 09:04:42AM +0100, Jean Delvare wrote:
Now that thhis is in mainline ... I suggest two more changes:
- at24 (i2c eeprom) doesn't need to be EXPERIMENTAL
- we still need interfaces
it. Are there any objections to this change?
Thanks,
--
Jean Delvare
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
here is that we really want to group
the drivers according to their functionality and not technical
implementation details.
--
Jean Delvare
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R
sounds quite different from our hwmon drivers. Our hwmon
drivers read all the sensor values at once and cache the readings for a
couple seconds, so you can't get an instant reading at any time, and
they also don't support interrupts in general.
--
Jean Delvare
10 matches
Mail list logo
