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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <8a51d0af-e018-40d4-8aa6-8c42caa5cccf@email.android.com>
Date:	Wed, 22 Jun 2011 23:06:15 -0600
From:	"glikely@...retlab.ca" <grant.likely@...retlab.ca>
To:	Dirk Brandewie <dirk.brandewie@...il.com>
CC:	linux-kernel@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net
Subject: Re: [PATCH 01/11] spi-dw: expose platform data stucture.



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.

g.

>
>--Dirk

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
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/