On Wed, Mar 25, 2015 at 08:43:36PM +0100, Martin Sperl wrote: > > On 25.03.2015, at 19:50, Mark Brown <broonie@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: Digital signature
