easiest way to deactivate a driver at boot time?
(Q asked by a colleague, a wee bit vague on details so i'm hoping i'm describing it correctly, seems like it should be easy to solve.) short form of question: what is the standard way of, at boot time, passing the kernel information to specify that a built-in driver should *not* be started? longer form of question: target system has two "slots", each of which contains a distinct embedded system running linux. both of those systems run the same kernel, *except* that, in slot 0, kernel should start and run a particular driver whereas, in slot 1, the kernel should *not* start that particular driver, whereupon apps on that system will fall back and do things differently. (apparently, the apps will use the simple existence of the driver's /dev/driver special device file to identify which approach to take.) as i understand it, then, whether or not that driver should start is based simply on being able to identify the slot the board is in, and this is something that is allegedly available to u-boot, which will then pass the appropriate info on the kernel command line, telling the kernel whether or not to start that driver. so far, so good. question is, what is the "appropriate" info to pass to the kernel to identify whether or not to start a (built-in) driver? my initial reaction was, define a simple module parameter, say "run", which is tested immediately upon driver startup, and if it's "0", just exit; otherwise, run normally. and then u-boot would add to the boot line: ... drivername.run=0 ... am i overthinking this? i'm used to module parameters being used to pass info to drivers and modules to *customize* their behaviour, not to simply say whether to run or not. is this a reasonable way to do this? is there a better/standard way? and is there a simple example of that in the current kernel source? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
On Thu, Dec 15, 2016 at 04:56:18AM -0500, Robert P. J. Day wrote:
(Q asked by a colleague, a wee bit vague on details so i'm hoping i'm describing it correctly, seems like it should be easy to solve.)
short form of question: what is the standard way of, at boot time, passing the kernel information to specify that a built-in driver should *not* be started?
Depends on the subsystem and driver, the only "standard way" is to just not build the driver into the kernel in the first place and use modules and load the module from userspace as-needed. Or, use the device tree that is passed to the kernel by the bootloader to define the hardware and if the hardware isn't defined, then no driver will get bound to it. good luck! greg k-h
On Thu, Dec 15, 2016 at 03:49:01AM -0800, Greg KH wrote:
On Thu, Dec 15, 2016 at 04:56:18AM -0500, Robert P. J. Day wrote:
(Q asked by a colleague, a wee bit vague on details so i'm hoping i'm describing it correctly, seems like it should be easy to solve.)
short form of question: what is the standard way of, at boot time, passing the kernel information to specify that a built-in driver should *not* be started?
Depends on the subsystem and driver, the only "standard way" is to just not build the driver into the kernel in the first place and use modules and load the module from userspace as-needed.
Or, use the device tree that is passed to the kernel by the bootloader to define the hardware and if the hardware isn't defined, then no driver will get bound to it.
What about "fixing up" the device tree in U-Boot with functions from common/fdt_support.(c|h) Maybe you could use fdt_del_node_and_alias to delete that drivers device tree node if it is not needed? Regards, Clemens
Or maybe using [status = "disabled"] at the device tree. Do you control the compilation of these device-trees, kernel, drivers and apps? 2016-12-15 10:20 GMT-02:00 Clemens Gruber <clemens.gruber@pqgruber.com>:
On Thu, Dec 15, 2016 at 03:49:01AM -0800, Greg KH wrote:
On Thu, Dec 15, 2016 at 04:56:18AM -0500, Robert P. J. Day wrote:
(Q asked by a colleague, a wee bit vague on details so i'm hoping i'm describing it correctly, seems like it should be easy to solve.)
short form of question: what is the standard way of, at boot time, passing the kernel information to specify that a built-in driver should *not* be started?
Depends on the subsystem and driver, the only "standard way" is to just not build the driver into the kernel in the first place and use modules and load the module from userspace as-needed.
Or, use the device tree that is passed to the kernel by the bootloader to define the hardware and if the hardware isn't defined, then no driver will get bound to it.
What about "fixing up" the device tree in U-Boot with functions from common/fdt_support.(c|h)
Maybe you could use fdt_del_node_and_alias to delete that drivers device tree node if it is not needed?
Regards, Clemens
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- "Do or do not. There is no try" Yoda Master
On Thu, 15 Dec 2016, Daniel. wrote:
Or maybe using [status = "disabled"] at the device tree. Do you control the compilation of these device-trees, kernel, drivers and apps?
this sounds like the simplest approach -- u-boot can check things out and, if necessary, use the FDT utilities to disable the portion of the tree related to that driver. am i understanding this correctly? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
I've never tried his brand new u-boot features, but yes, I guess is possible to use ftd set to set status to "diabled" based on some logic. Search for "5.9.7.5. fdt set - set node properties" at http://www.denx.de/wiki/view/DULG/UBootCmdFDT 2016-12-15 10:55 GMT-02:00 Robert P. J. Day <rpjday@crashcourse.ca>:
On Thu, 15 Dec 2016, Daniel. wrote:
Or maybe using [status = "disabled"] at the device tree. Do you control the compilation of these device-trees, kernel, drivers and apps?
this sounds like the simplest approach -- u-boot can check things out and, if necessary, use the FDT utilities to disable the portion of the tree related to that driver. am i understanding this correctly?
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
-- "Do or do not. There is no try" Yoda Master
participants (4)
-
Clemens Gruber -
Daniel. -
Greg KH -
Robert P. J. Day