linux-kernel - Re: [PATCH 01/11] spi-dw: expose platform data stucture.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4E02CC1B.2070403@gmail.com>
Date:	Wed, 22 Jun 2011 22:16:11 -0700
From:	Dirk Brandewie <dirk.brandewie@...il.com>
To:	"glikely@...retlab.ca" <grant.likely@...retlab.ca>
CC:	linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net
Subject: Re: [PATCH 01/11] spi-dw: expose platform data stucture.

On 06/22/2011 10:06 PM, glikely@...retlab.ca wrote:
>
>
> Dirk Brandewie<dirk.brandewie@...il.com>  wrote:
>
>> On 06/22/2011 09:03 PM, glikely@...retlab.ca wrote:
>>>
>>>
>>> Dirk Brandewie<dirk.brandewie@...il.com>   wrote:
>>>
>>>> On 06/22/2011 08:47 PM, Grant Likely wrote:
>>>>> On Wed, Jun 22, 2011 at 8:00 PM,<dirk.brandewie@...il.com>    wrote:
>>>>>> From: Dirk Brandewie<dirk.brandewie@...il.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
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/