Re: easiest way to deactivate a driver at boot time?

[Robert P. J. Day]

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



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: easiest way to deactivate a driver at boot time?

[Daniel.]

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 :
> 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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: easiest way to deactivate a driver at boot time?

[Hayward, Shaun]

> On Dec 15, 2016, at 7:23 AM, Hayward, Shaun  wrote:
> 
> 
>> On Dec 15, 2016, at 4:59 AM, Robert P. J. Day  wrote:
>> 
>> question is, what is the "appropriate" info to pass to the 
>> 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
> 
> I just (last week) tackled a similar issue. In our case, we used u-boot to 
> detect board type and then load a different device file. This caused our 
> optional device to only be present on the appropriate board (we use udev). We 
> also then used the device tree "model" name from user space to key additional 
> customizations (/sys/firmware/devicetree/base/model, if memory serves me 
> right).
> 
> In this setup, the driver is always in the kernel (we run the same image for 
> both boards), but a device is only registered on boards with the matching 
> device in their device tree.
> 
> Shaun
(Forgot to cc list...)
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Re: easiest way to deactivate a driver at boot time?

[Clemens Gruber]

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

Re: easiest way to deactivate a driver at boot time?

[Greg KH]

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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

easiest way to deactivate a driver at boot time?

[Robert P. J. Day]

  (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



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies