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

Martin Sperl kernel at martin.sperl.org
Wed Jul 29 23:45:20 PDT 2015

> On 30.07.2015, at 07:36, Stefan Wahren <info at lategoodbye.de> wrote:
> Hi Martin,
> Am 29.07.2015 um 23:16 schrieb Martin Sperl:
>>> On 29.07.2015, at 18:37, Stefan Wahren <info at lategoodbye.de> wrote:
>>> Hi Martin,
>>>> Am 28.07.2015 um 12:48 schrieb Martin Sperl:
>>>>> On 28.07.2015 08:18, Martin Sperl wrote:
>>>>> Hi Stephen!
>>>>> But the bigger question you have not answered is: “where should such an
>>>>> auxiliar driver go in the kernel tree?” i.e. which directory?
>>>> One thing: could the "module" be a regulator?
>>> IMHO that won't be acceptable.
>> Why would it not be acceptable?
> first of all, sorry i didn't follow this thread in every detail. My intention was to give you some ideas. I'm a not maintainer.
> IMU a regulator is a hardware part who controls voltage or current.
> Does it apply in your case?
> Any question: would a user expect this function in the regulator framework?

I am just trying to find a solution that will get accepted with the minimum
number of reposts/rewrites to avoid frustration, but nobody has an answer
which api we really should use.

The problem is that we have DT and we have code and as we only want HW
being represented in the device tree we need something “sensible”.

What about adding “bcrm,bcm2835-aux-enable” to drivers/mfd/syscon.c

That way we:
* have a clean dt that only represents hardware
* reuse existing code with minimal modifications
* minimal effort

That would be a minimal patch to enable this, so we can ask if that is
acceptable and if it is not then we can still think of something else,
which would be mostly replicating the bit-management portion of syscon.

Sometimes I wish there was a way to “extend” compatibility of a driver
by just adding something to the device-tree (say compatibility) or define 
it in the platform config c-files without having to touch the actual
drivers to add that compatibility string...


More information about the linux-rpi-kernel mailing list