Messages in this thread | | | Date | Wed, 22 Jun 2011 22:16:11 -0700 | From | Dirk Brandewie <> | Subject | Re: [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 >
| |