[PATCH V2 - RESEND] SPI: BCM2835: allow arbitrary GPIO to act as SPI-chip_select
broonie at kernel.org
Wed Mar 25 14:02:15 PDT 2015
On Wed, Mar 25, 2015 at 08:43:36PM +0100, Martin Sperl wrote:
> > On 25.03.2015, at 19:50, Mark Brown <broonie at kernel.org> wrote:
> > This sounds like you're trying to work aroud the core rather than work
> > with the core - enhance the core so that it can express what you need.
> Working in a single driver makes things more local without having
> a "moving" target with lots of other patches. If done right most of it
> then can get moved to the core - if needed...
That's fine for your out of tree stuff but not for mainline.
> >> Also there is another point here, that Stephen pointed out:
> >> Would not a switch from the use of the "native-cs" to "gpio-only" mean
> >> a required change in Device-tree? And isn't DT assumed to be a stabe API?
> > Can you be more specific about what change you think might be required?
> > Currently the driver doesn't support GPIOs as chip selects at all so
> > anything enabling them is going to be new.
> Well, if we say we "need" gpio_cs to be set in DT of the master, then
> that might be assumed an API change that might break some custom
> device-trees - I was mostly referring to that.
> So how would that situation be with the requirement to use the GPIO_CS
I'm sorry but I still don't understand what you're saying here.
Assigning a value to a variable in the kernel has no obvious impact on
the DT, and anything that adds a DT binding to the driver that doesn't
exist already is obviously a change.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: Digital signature
More information about the linux-rpi-kernel