All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Brandewie <dirk.brandewie@gmail.com>
To: "glikely@secretlab.ca" <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org, spi-devel-general@lists.sourceforge.net
Subject: Re: [PATCH 01/11] spi-dw: expose platform data stucture.
Date: Wed, 22 Jun 2011 22:16:11 -0700	[thread overview]
Message-ID: <4E02CC1B.2070403@gmail.com> (raw)
In-Reply-To: <8a51d0af-e018-40d4-8aa6-8c42caa5cccf@email.android.com>

On 06/22/2011 10:06 PM, glikely@secretlab.ca wrote:
>
>
> Dirk Brandewie<dirk.brandewie@gmail.com>  wrote:
>
>> On 06/22/2011 09:03 PM, glikely@secretlab.ca wrote:
>>>
>>>
>>> Dirk Brandewie<dirk.brandewie@gmail.com>   wrote:
>>>
>>>> On 06/22/2011 08:47 PM, Grant Likely wrote:
>>>>> On Wed, Jun 22, 2011 at 8:00 PM,<dirk.brandewie@gmail.com>    wrote:
>>>>>> From: Dirk Brandewie<dirk.brandewie@gmail.com>
>>>>>>
>>>>>> Expose the platform data structure for use by client drivers. ATM
>>>>>> there are not any in-tree drivers using the driver (that I can
>>>>>> find). This patch exposes the platform data needed for client
>>>> drivers.
>>>>>
>>>>> ?  Why would client drivers want to muck with this configuration?
>> I
>>>>> can understand the dw_spi driver being able to have per-spi_device
>>>>> configuration, but spi_drivers absolutely should not have
>> visibility
>>>>> into bus-specific details.  Am I misunderstanding something.
>>>>>
>>>>
>>>> Most of these config options don't need to be client configurable
>> IMHO
>>>> but they
>>>> are being used ATM by drivers that aren't upstream and the current
>>>> controller
>>>> driver uses them.  This patch is to give a smooth transition
>>>> (bisectable) to my
>>>> change that reworks the core message and transfer handling code.
>>>>
>>>> This allows me to provide patches to the developers of the out of
>> tree
>>>> drivers
>>>> that should be coming in RSN and exposes the interface they are
>> using
>>>> now.
>>>
>>> My question still stands. Are you expecting spi_driver code to
>> manipulate this data?
>>>
>>>
>>
>> The current drivers behaviour is driven by this data provided by the
>> client.
>> This makes the current client drivers work since some have not picked
>> picked up
>> your change moving dw_spi.h out of include/linux/spi (right answer
>> IMHO) and
>> provides the interface they are using now.
>
> So the situation is that certain out-of-tree spi_drivers are reaching into internal details of a specific spi bus driver?
>If so, then that is wrong and bad, and certainly will not be merged. Especially when there are no in tree users and neither
>does this series add any.

OK

Since the current driver used pxa2xx_spi.c as a template I was following the 
example provided by include/linux/spi/pxa2xx_spi.h.  I have no problem dropping 
this patch until I finish the rest of the rework planned. Was trying to limit 
the amount of heartburn others on the list had with my changes.

--Dirk
>
> g.
>
>>
>> --Dirk
>


  reply	other threads:[~2011-06-23  5:16 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-23  2:00 [PATCH 00/11] RFC spi-dw updates dirk.brandewie
2011-06-23  2:00 ` [PATCH 01/11] spi-dw: expose platform data stucture dirk.brandewie
2011-06-23  3:47   ` Grant Likely
2011-06-23  4:00     ` Dirk Brandewie
2011-06-23  4:03       ` glikely@secretlab.ca
2011-06-23  4:37         ` Dirk Brandewie
2011-06-23  5:06           ` glikely@secretlab.ca
2011-06-23  5:16             ` Dirk Brandewie [this message]
2011-06-23  2:00 ` [PATCH 02/11] spi-dw: update function naming convention to match file naming dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  2:00 ` [PATCH 03/11] spi-dw: change MRST prefix to generic prefix dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  2:00 ` [PATCH 04/11] spi-dw: remove unused definition dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  2:00 ` [PATCH 05/11] spi-dw: split spi_dw_enable_chip() into spi_dw_enable()/spi_dw_disable() dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  2:00 ` [PATCH 06/11] spi-dw: Force error on out of range chip select dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  3:51   ` Grant Likely
2011-06-23  4:13     ` Dirk Brandewie
2011-06-23  2:00 ` [PATCH 07/11] spi-dw: Set number of available chip selects correctly dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  3:53   ` Grant Likely
2011-06-23  2:00 ` [PATCH 08/11] spi-dw: Ensure fifo lenght is set dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  2:41   ` Feng Tang
2011-06-23  2:41     ` Feng Tang
2011-06-23  3:01     ` Dirk Brandewie
2011-06-23  3:01       ` Dirk Brandewie
2011-06-23  3:21       ` Feng Tang
2011-06-23  3:21         ` Feng Tang
2011-06-23  3:55   ` Grant Likely
2011-06-23  4:20     ` Dirk Brandewie
2011-06-23  2:00 ` [PATCH 09/11] spi-dw: Fix condition in spi_dw_{writer/reader} dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  2:45   ` Feng Tang
2011-06-23  2:45     ` Feng Tang
2011-06-23  3:09     ` Dirk Brandewie
2011-06-23  3:09       ` Dirk Brandewie
2011-06-23  3:25       ` Feng Tang
2011-06-23  3:25         ` Feng Tang
2011-06-23  3:30         ` Dirk Brandewie
2011-06-23  3:30           ` Dirk Brandewie
2011-06-23  5:09           ` Feng Tang
2011-06-23  5:09             ` Feng Tang
2011-06-23  2:00 ` [PATCH 10/11] spi-dw: Move checking of max_speed_hz value to be a prerequisite in spi_dw_setup dirk.brandewie
2011-06-23  2:00 ` [PATCH 11/11] spi-dw: remove noop else clause dirk.brandewie
2011-06-23  2:00   ` dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w
2011-06-23  2:47   ` Feng Tang
2011-06-23  2:47     ` Feng Tang
2011-06-23  3:13     ` Dirk Brandewie
2011-06-23  3:13       ` Dirk Brandewie
2011-06-23  2:39 ` [PATCH 00/11] RFC spi-dw updates Feng Tang
2011-06-23  2:39   ` Feng Tang

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=4E02CC1B.2070403@gmail.com \
    --to=dirk.brandewie@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /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.