[RFC] devices without FDT node
Hello Simon,
in U-Boot we can define drivers via U_BOOT_DRVINFO and U_BOOT_DRIVER.
My current use case is SBI system reset extension. A driver would not reasonably depend on the device-tree because if the RISC-V cpu is in S-mode we know that there must be an SBI implementation. If the extension is available, has to be determined in the probe() function of the driver.
My current solution is to use U_BOOT_DRIVER and to call device_bind_driver(gd->dm_root,...) in board_init(). But that results in code duplication in the board files.
What do think about adding the usual driver functions to struct driver_info:
int (*bind)(struct udevice *dev); int (*probe)(struct udevice *dev); int (*remove)(struct udevice *dev); int (*unbind)(struct udevice *dev);
Alternatively one could add a flag DM_FLAG_AUTO_PROBE to the struct driver flags field which would lead to probing irrespective of the device-tree.
I would prefer the latter solution.
Best regards
Heinrich
Hi Heinrich,
On Thu, 4 Mar 2021 at 08:01, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Hello Simon,
in U-Boot we can define drivers via U_BOOT_DRVINFO and U_BOOT_DRIVER.
My current use case is SBI system reset extension. A driver would not reasonably depend on the device-tree because if the RISC-V cpu is in S-mode we know that there must be an SBI implementation. If the extension is available, has to be determined in the probe() function of the driver.
My current solution is to use U_BOOT_DRIVER and to call device_bind_driver(gd->dm_root,...) in board_init(). But that results in code duplication in the board files.
What do think about adding the usual driver functions to struct driver_info:
int (*bind)(struct udevice *dev); int (*probe)(struct udevice *dev); int (*remove)(struct udevice *dev); int (*unbind)(struct udevice *dev);Alternatively one could add a flag DM_FLAG_AUTO_PROBE to the struct driver flags field which would lead to probing irrespective of the device-tree.
I would prefer the latter solution.
Surely this should be in the devicetree. Why would it not be?
Regards, Simon
Am 4. März 2021 20:26:49 MEZ schrieb Simon Glass sjg@chromium.org:
Hi Heinrich,
On Thu, 4 Mar 2021 at 08:01, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Hello Simon,
in U-Boot we can define drivers via U_BOOT_DRVINFO and U_BOOT_DRIVER.
My current use case is SBI system reset extension. A driver would not reasonably depend on the device-tree because if the RISC-V cpu is in S-mode we know that there must be an SBI implementation. If the extension is available, has to be determined in the probe() function
of
the driver.
My current solution is to use U_BOOT_DRIVER and to call device_bind_driver(gd->dm_root,...) in board_init(). But that results
in
code duplication in the board files.
What do think about adding the usual driver functions to struct
driver_info:
int (*bind)(struct udevice *dev); int (*probe)(struct udevice *dev); int (*remove)(struct udevice *dev); int (*unbind)(struct udevice *dev);Alternatively one could add a flag DM_FLAG_AUTO_PROBE to the struct driver flags field which would lead to probing irrespective of the device-tree.
I would prefer the latter solution.
Surely this should be in the devicetree. Why would it not be?
Here is the background to my question:
http://lists.infradead.org/pipermail/opensbi/2021-March/000691.html
The OpenSBI maintainers did not see any need for a device tree node for calling the system reset extension.
Best regards
Heinrich
Regards, Simon
Hi Heinrich,
On Thu, 4 Mar 2021 at 13:10, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 4. März 2021 20:26:49 MEZ schrieb Simon Glass sjg@chromium.org:
Hi Heinrich,
On Thu, 4 Mar 2021 at 08:01, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Hello Simon,
in U-Boot we can define drivers via U_BOOT_DRVINFO and U_BOOT_DRIVER.
My current use case is SBI system reset extension. A driver would not reasonably depend on the device-tree because if the RISC-V cpu is in S-mode we know that there must be an SBI implementation. If the extension is available, has to be determined in the probe() function
of
the driver.
My current solution is to use U_BOOT_DRIVER and to call device_bind_driver(gd->dm_root,...) in board_init(). But that results
in
code duplication in the board files.
What do think about adding the usual driver functions to struct
driver_info:
int (*bind)(struct udevice *dev); int (*probe)(struct udevice *dev); int (*remove)(struct udevice *dev); int (*unbind)(struct udevice *dev);Alternatively one could add a flag DM_FLAG_AUTO_PROBE to the struct driver flags field which would lead to probing irrespective of the device-tree.
I would prefer the latter solution.
Surely this should be in the devicetree. Why would it not be?
Here is the background to my question:
http://lists.infradead.org/pipermail/opensbi/2021-March/000691.html
The OpenSBI maintainers did not see any need for a device tree node for calling the system reset extension.
I'm sorry to hear that, but we should have a node for each device in the system. In principle there is never a need for a devicetree node. We can always just write code to manually bind and configure devices. When everyone took this attitude it led eventually to the mandate in Linux to...not do that.
We have enough ad-hoc device_bind() calls already due to Linux's hybrid approach. It adds to code size, clouds visibility of devices, complicates sandbox testing, does not work with of-platdata-inst and creates this sort of email thread...
IMO it is really just creating a problem where none should exist.
Regards, Simon
participants (2)
-
Heinrich Schuchardt -
Simon Glass