Re: [PATCH] spi: pxa2xx_spi introduce chip select gpio to simplify the common cases

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

On Tuesday 09 September 2008, Jonathan Cameron wrote:
> 
> >  - It's probably worth removing support for the SSFRM
> >    mechanism and requiring gpio_cs or (at least as a
> >    transitional scheme) the cs_control() thing.
>
> I disagree strongly with this.
> 
> By all means issue a warning that cs_change will be
> effectively 1 in all cases. However, with many real setups
> this is absolutely fine. Leave getting this right to a
> combination of the board config writers and some good
> documentation!

My logic is as follows:

  (a) it's superfluous given that the pin used for
      SSFRM can be managed as a GPIO;
  (b) it's less capable than managing it as a GPIO,
      examples being lack of SPI_CS_HIGH support
      and broken cs_change;
  (c) given (b) and what you noted, it's error prone;
  (d) given (a-c) it's confusing

In short, removing this mechanism would improve quality
and maintainability.  Needing *more* documentation for
core functionality is a red flag.

Notice I'm not saying it can't (or doesn't) work, within
its constraints (b).  I'm just saying that if it's removed,
the driver will be better and won't lose *ANY* functionality.

- Dave


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/