This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How do I call .probe from an application program?

I'm using a custom board derived from the DM6467T EVM.

I find many drivers with a structure containing a .probe value, initialized to point to a drivername_probe() function (and a .name value set to "drivername").

From an application program, how do I call one of these probe functions?  I'm guessing it might be through ioctl(), but I'm only guessing.

Thanks very much,

Helmut

  • In short, you don't.

    The core functionality implemented as a part of the Linux driver model calls the probe function of a registered driver when a device with the same name is registered or vice-versa.

    If the probe function is not getting called you should check if there is a problem with the device and/or driver registration (name mismatch or anything else).

    Regards,

    Vaibhav

  • Vaibhav,

    Thanks for this info.  I suspected as much.

    With this question, one of my multiple real objectives is for my application in user space to trigger an action in my customized ADV7171 video chip driver.  I thought I might be able to add another [function pointer] definition below the .probe definition, and somehow have my application cause the function to run.  Or else I might hijack an existing function.  I realize the .probe calling behavior is only half my difficulty, being the receiving end.  I still have difficulty making the call from user space.

    Perhaps you might really help me by suggesting the correct way, or at least feasible way, to accomplish this.  

    To rephrase, imagine I have something called MyAction.  I've already modified the ADV7171's driver (ADV7170) once, and will modify it further to carry out MyAction.  Then, I need the application program to tell the driver when to do MyAction.  Specifically, MyAction is to reconfigure chip-internal color bars on or off.  When configuring the color bars on, MyAction within the driver must also turn on the CLK_OUT2 from the DM6467T (ref thread http://e2e.ti.com/support/embedded/f/354/p/102238/363361.aspx#363361)

    Another objective is a slightly different MyAction within some other kernel space code.  board-dm646x-evm.c accesses the CPLD on the DM6467T EVM, as well as my custom board derived from the same.  I have already necessarily customized board-dm646x-evm.c, for things such as removing ATA and other things that correspond to hardware not present on my board.  board-dm646x-evm.c accesses control bits in Reg0 and Reg1 of the CPLD.  I need to overload meaning into recently freed up (unused) bits.  MyAction will allow the application to cause CPLD register changes, thus controlling my board.  Specifically, the CPLD has the ability to shut down the Internet PHY, which uses lots of power.  All I have to do is set a newly defined bit in Reg0 (I2C address 0x3a).  I plan to do this under application control, so my application needs to invoke MyAction within board-dm646x-evm.c.  (ref thread http://e2e.ti.com/support/embedded/f/354/p/103153/362808.aspx#362808)

    Thanks again,

    Helmut

  • There are a few options for triggering something from user space.

    1. You could extend the ioctl handler (if the driver has that) to add the functionality that you want.

    2. Add sysfs entries which end up triggering your function in the kernel.

    3. Add procfs entries which again end up triggering your function in the kernel.

    4. If its for debugging purposes only, add debugfs entries.

    You can check up on the merits and demerits of each of these and pick the most logical one. One of the above should definitely help you achieve your objective.

    Regards,

    Vaibhav

     

  • Vaibhav,

    Your advice above sounds great, and reinforces what I've been learning along the way here.

    Please jump over to this other thread, where the subjects are now merging.  The link below should place you correctly, chronologically, right at the response posted by Norman Wong on 04-05-2011 12:42 PM": http://e2e.ti.com/support/embedded/f/354/p/103153/363629.aspx#363629

    Thanks again,

    Helmut

  • RESOLVED.

    Note I didn't so much want to call probe, as to call probe into board-dm6467x-evm.c.  And I didn't so much want to do that as simply get into board-dm6466x-evm.c from user space in order to cause a read/write of CPLD registers.

    With that said, here's my solution:

    "This is how to read/write CPLD registers on DM6467T" http://e2e.ti.com/support/embedded/f/354/p/104258/366748.aspx#366748