Messages in this thread | | | Subject | Re: [PATCH v2 4/7] cpufreq: add driver for Raspbery Pi | From | Nicolas Saenz Julienne <> | Date | Thu, 06 Jun 2019 19:22:16 +0200 |
| |
Hi Stephen, Thanks for the review.
On Thu, 2019-06-06 at 10:09 -0700, Stephen Boyd wrote: > Quoting Nicolas Saenz Julienne (2019-06-06 07:22:56) > > diff --git a/drivers/cpufreq/raspberrypi-cpufreq.c > > b/drivers/cpufreq/raspberrypi-cpufreq.c > > new file mode 100644 > > index 000000000000..99b59d5a50aa > > --- /dev/null > > +++ b/drivers/cpufreq/raspberrypi-cpufreq.c > [...] > > + > > +/* > > + * Since the driver depends on clk-raspberrypi, which may return > > EPROBE_DEFER, > > + * all the activity is performed in the probe, which may be defered as > > well. > > + */ > > +static struct platform_driver raspberrypi_cpufreq_driver = { > > + .driver = { > > + .name = "raspberrypi-cpufreq", > > + }, > > + .probe = raspberrypi_cpufreq_probe, > > + .remove = raspberrypi_cpufreq_remove, > > +}; > > +module_platform_driver(raspberrypi_cpufreq_driver); > > How does this driver probe? Do you have a node in DT named > raspberrypi-cpufreq that matches and probes this? I would think this > would follow the drivers/cpufreq/cpufreq-dt-platdev.c design where it's > an initcall that probes the board compatible string. > > Or, if it depends on clk-raspberrypi probing, maybe it could create the > platform device in that drivers probe function.
Well you just reviewed that patch :)
> > + > > +MODULE_AUTHOR("Nicolas Saenz Julienne <nsaenzjulienne@suse.de"); > > +MODULE_DESCRIPTION("Raspberry Pi cpufreq driver"); > > +MODULE_LICENSE("GPL"); > > +MODULE_ALIAS("platform:raspberrypi-cpufreq"); > > I don't think the module alias is needed anymore.
That's surprising. I remember the driver not being loaded by udev without it.
Regards, Nicolas
[unhandled content-type:application/pgp-signature] | |