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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
