Re: [PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2

[Stephen Warren <swarren@xxxxxxxxxxxxx>]

On 07/28/2015 12:18 AM, Martin Sperl wrote:
> Hi Stephen!
> 
>> On 28.07.2015, at 04:51, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>>
>>
>>> If this is not acceptable, then where should such a driver go in the
>>> kernel tree?
>>>
>>> It would essentially implement the following:
>>> bcm2835aux_enable(dev, device-id);
>>> bcm2835aux_disable(dev, device-id);
>>>
>>> Which would just set/clean the bits in the register while holding a lock.
>>
>> That sounds reasonable. I'd also expect a function that the client
>> drivers could call during probe() to look up the device (and implement
>> deferred probe) and another to release the reference during the client's
>> remove().
>
> But the bigger question you have not answered is: “where should such an
> auxiliar driver go in the kernel tree?” i.e. which directory?

drivers/soc seems made for this.

> I really do not want to implement it and then get told: “that should not
> go here” - been thru too many iterations already…
>
> Also I am not sure I understood the “defer” thingy.
> I thought of actually implementing only 2 functions to use during probe
> and removal:
> * bcm2835aux_enable(dev)
> * bcm2835aux_disable(dev)
> 
> Both would pick up the “bcrm,aux” property from the device tree (as per 
> “bcrm,aux = <&bcm2835aux 4>”) and set the enable register accordingly
> holding a lock.

That'd probably be fine. The important thing is to get the DT right
since that's an ABI. The implementation can be refactored/rewritten at
will later provided the right info is in the DT.

If you go this route, deferred probe isn't relevant.

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html