[PATCH V2 - RESEND] SPI: BCM2835: allow arbitrary GPIO to act as SPI-chip_select

Mark Brown 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 
> explicitly?

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...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20150325/89d23764/attachment.sig>

More information about the linux-rpi-kernel mailing list