> On 30.07.2015, at 07:36, Stefan Wahren <info@xxxxxxxxxxxxxx> wrote: > > Hi Martin, > > Am 29.07.2015 um 23:16 schrieb Martin Sperl: >> >> >>> On 29.07.2015, at 18:37, Stefan Wahren <info@xxxxxxxxxxxxxx> 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 compatibility? 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... Martin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
