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? 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. I still could leave those 2 functions in the spi driver for now and when someone wants to implement the uart1, then they would need to pull that out into a separate driver. As for interrupt-handler: it was a simple idea that would work fine for the bcm2835aux case to avoid configuring things for the uart, but then you do not want the uart1 to get configured as 'compatible=“ns16650”;’ inside the device-tree, so this is not acceptable anyway (unless there were some way to define “additional” compatibility for a driver without modifying the driver itself). This means we will need to implement a minimal driver for uart1 that wraps ns16650. But as all the drivers (spi-bcm2835aux as well as ns16650) can use FIRQ_SHARED (and do not need to read/write the shared aux_irg registers) the need for a interrupt controller is not there. -- 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
