Hello Rob,
Thank you for your feedback.
I will add a bit of context regarding the secumod. The
"atmel,sama5d2-secumod"
compatible string is not used for loading a driver. It is used by atmel
securam
driver (drivers/misc/sram.c) which has access to secumod's registers via:
syscon_regmap_lookup_by_compatible("atmel,sama5d2-secumod")
So the secumod exports multiple hardware functions, eg: the securam, the
PIOBU
pins which can be used as GPIO pins.
My initial patch had the "microchip,sama5d2-piobu" compatible appended
to the
secumod's compatible e.g.:
secumod@fc040000 {
compatible = "syscon", "microchip,sama5d2-piobu";
...
Taking into consideration Linus Walleij's advice I arrived to the current
version. I thought this was a good idea because it separates the secumod
node
from the GPIO controller node. Please notice that securam node is already
separated from secumod node (it is a separate node in the device tree).
I have a few questions because I am not sure of the best approach:
1. Is it ok to have the GPIO controller as a child node?
2. I used simple-mfd because it was the only way I could think of in
order to
get the driver probed.
3. Should I add a register range? I thought that because the driver uses
syscon
it is not necessary to add the register range. Also, the register
range would
have been a subset of the secumod's register range.
