archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely-s3s/>
To: jassi brar <>
Cc: Ken Mills <>,
	spi mailing list
Subject: Re: [PATCH] Add support for slave controllers plus sysfs entries for power management
Date: Tue, 16 Feb 2010 15:01:20 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Feb 14, 2010 at 6:37 PM, jassi brar <> wrote:
> On Mon, Feb 15, 2010 at 8:20 AM, Linus Walleij
> <> wrote:
>> 2010/1/19 Grant Likely <grant.likely-s3s/>:
>>>  The current model is that each spi_device is registered with an
>>> spi_master.  Many device drivers operate on the assumption that the
>>> ->master pointer is valid.  With this patch, it appears that
>>> spi_devices can be registered either against an spi_master or an
>>> spi_slave; thus invalidating the assumption drivers are already
>>> operating under.  That alone makes me nervous.
>> IIRC in my last review of this patch I proposed that drivers be
>> either master, slave or both. With the current approach that would
>> mean putting  #ifdefs over the ->master as well and making master
>> support optional. (You can even #ifdef out these parts of the struct
>> to be absolutely sure.)
> I don't think adding SPI_SLAVE support is just a matter of providing
> additional callbacks and structures, as is pointed out in this thread....
> We'd better see if the implementation covers at least some aspects of
> being a SPI slave,
> otherwise it seems more like a 'workaround' than support.

I agree.  I need to see a real usage model before I merge anything.
As it stands right now, spi_master looks like an entirely different
thing from an spi_slave, even if both happen to use spi_messages
(although spi_message only seems to handle a small number of the
possible spi slave use cases.  For example, it doesn't address at all
a command and response within the same SPI transfer).  I don't at all
like the idea of allowing the current spi_device to be registered on
either an spi_master or an spi_slave.

I may let a driver through that happens to turn on an SPI slave mode
in the hardware, but if you're doing that, be aware that it may be an
abuse of the spi_master model, and you'll get little sympathy when
breakage happens.

I haven't seen anything spi_slave related yet that I'll merge in the
common spi code.


SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW

      parent reply	other threads:[~2010-02-16 22:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 21:06 [PATCH] Add support for slave controllers plus sysfs entries for power management Ken Mills
2010-01-19 15:59 ` Grant Likely
     [not found]   ` <>
2010-02-14 23:20     ` Linus Walleij
     [not found]       ` <>
2010-02-15  1:37         ` jassi brar
     [not found]           ` <>
2010-02-16 19:33             ` Linus Walleij
     [not found]               ` <>
2010-02-16 20:48                 ` Ned Forrester
     [not found]                   ` <4B7B048C.8080205-/>
2010-02-17  3:19                     ` Grant Likely
2010-02-16 22:07                 ` Grant Likely
2010-02-17  1:43                 ` jassi brar
2010-02-16 22:01             ` Grant Likely [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \
    --to=grant.likely-s3s/ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).