On Sun, Oct 8, 2017 at 4:03 PM, Chris Packham <chris.pack...@alliedtelesis.co.nz> wrote: > Hi Rob, Greg, > > On 04/10/17 10:38, Rob Herring wrote: >> On Fri, Sep 22, 2017 at 03:48:13AM +1200, Chris Packham wrote: >>> Document the device tree bindings for the uio-prv-genirq driver. Provide >>> some examples on how it can be used. >>> >>> Signed-off-by: Chris Packham <chris.pack...@alliedtelesis.co.nz> >>> --- >>> .../bindings/uio/linux,uio-pdrv-genirq.txt | 28 >>> ++++++++++++++++++++++ >>> 1 file changed, 28 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/uio/linux,uio-pdrv-genirq.txt >> >> NAK. >> >> I'm sure this has come up before but if you want to map a device to a >> uio driver, then add its compatible string to the driver. Bindings >> describe h/w devices. > > Fair enough. > > The problem for me is that the uio-pdrv-genirq is so generic it could > apply to pretty much any hardware device. The driver has dt-awareness > but it currently doesn't have any built-in compatible string (it is set > via a module param). > > My use-case is a microcontoller with a userspace driver all I need out > of the kernel is i2c access and interrupts. Any suggestions as to how to > move forward with this.
Define the binding for the uC regardless of how the driver is implemented. Then add its compatible to the uio-pdev driver. That's how we've dealt with spi-dev for example. Rob
