Am 30.11.2017 um 08:24 schrieb kernel@xxxxxxxxxxxxxxxx: > I understand, but the question still is: how to > present the information in a valid way. > > To use gpio propperly it would require that the driver > implements a “sub-driver” pinctrl with all the extra > (boilerplate) code overhead. > > Also this would mean mixing different types of > logical drivers into a single source - I doubt that > would be easy to get accepted... > > Here again a summary of all the GPIOs that the mcp2517fd has: > * TXCAN: dedicated GPIO with single function, > individually conigurable as push/pull or open drain > * INT: main interrupt line - configurable as push/pull or > individually conigurable as push/pull or open drain > * GPIO0: general GPIO with in/out option, but 2 special “cases”: > tx-irq and TX-disable > group configurable as push/pull or open drain > * GPIO1: general GPIO with in/out potion, but 1 special “cases”: > rx-irq > group configurable as push/pull or open drain > * CLKO/SOF: clock output at (1/10th, 1/5th, 1/2, 1 of the > core frequency) or start of frame output > possibly group configurable as push/pull or open drain > (not explicitly specified in datasheet) > > How would you try to present that HW-configuration in the > device tree instead? > How would it impact the driver design? > Hi, I'm afraid I don't know what is best practice but you may want to look at the max310x driver which declares it's GPIOs and GPIO based interrupts in the regular driver. drivers/tty/serial/max310x.c Documentation/devicetree/bindings/serial/maxim,max310x.txt Look for "#ifdef CONFIG_GPIOLIB". My first try would be a single dt node like the max310x uses in the dt example. Imho it is better to make things useful before making them complicated. Regards, Patrick
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
