lkml.org 
[lkml]   [2011]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/11] spi-dw: expose platform data stucture.
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
>



\
 
 \ /
  Last update: 2011-06-23 07:19    [W:0.791 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site