Probe in Linux DevFreq Driver Not Being Called

Question

I am trying to set up a devfreq driver for a peripheral on Linux. My init method for the driver looks as follows:

  static struct platform_driver zynq_csortfreq_driver = {
    .probe  = zynq_csortfreq_probe,
    .driver = {
        .name   = "ZYNQ_CSORT_DEVFREQ",
        .owner  = THIS_MODULE,
    },
  };

static int __init zynq_csortfreq_init(void)
{
    return platform_driver_register(&zynq_csortfreq_driver);
}
late_initcall(zynq_csortfreq_init);

However, the probe function (zynq_csortfreq_probe) in my driver never seems to get called. I've read that in order for the probe call to work correctly, the .name value of the driver must match the name of the device - where can I find the name of the device?

Answer 1

In order for the probe function to be called, you must add a device from a machine file or via the device tree. This is typically done with platform_device_register() or platform_add_devices() in machine files. Alternatively, of_platform_populate() is used for the device tree model, but code does not use this directly. The platform device documentation has information for your Linux kernel version. It seems that your Linux uses the device tree model. The documentation in the cpufree devicetree will have some helpful information on activating your driver for this board with device trees.

The dtsi file needs something like,

 soc {
     zyncfreq@addr {
          compatible="xxxx"
          /* Other platform data */

Which will define the device for your machine. I would suggest that first you modify your machine files init_machine entry and use platform_device_register() to associate your driver with a device. Then you can later attempt to get the device tree mechanism working if you wish.

If you can view this closed question, my answer might be helpful if the Linux device-model documentation is not completely clear. However, I think for your case the Linux docs are sufficient.

Answer 2

SOLVED:

Problem is in the makefile system. A "dummy" object file must be created and the two "real" files must be combined into the "dummy" object file.

So, new makefile:

#
# Makefile for the mcp3202 driver.
#

obj-$(CONFIG_MCP3202) := mcp3202.o
mcp3202-objs := mcp3202_core.o mcp3202_pru.o

The original "mcp3202.c" was renamed to "mcp3202_core.c". The listed "mcp3202.o" does not need a corresponding .c file since it is created "out of thin air" by the make system by combining mcp3202_core.o and mcp3202_pru.o.

Not very elegant but explains why there's a lot of "_core.c" files strung through out the KERNEL build system. Sounds like an value-added opportunity for a Kernel guru to work on...