| Message ID | 1531924476-23261-1-git-send-email-phil.edworthy@renesas.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
Hi Phil, On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy <phil.edworthy@renesas.com> wrote: > To avoid all SoC peripheral drivers deferring their probes, both clock and > pinctrl drivers should already be probed. Since the pinctrl driver requires > a clock to access the registers, the clock driver should be probed before > the pinctrl driver. > > Therefore, move the clock driver from subsys_initcall to core_initcall. > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> Thanks for your patch! The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right? > --- a/drivers/clk/renesas/r9a06g032-clocks.c > +++ b/drivers/clk/renesas/r9a06g032-clocks.c > @@ -877,17 +877,18 @@ static const struct of_device_id r9a06g032_match[] = { > { } > }; > > -static struct platform_driver r9a06g032_clock_driver = { > +static struct platform_driver r9a06g032_clock_driver __refdata = { > .driver = { > .name = "renesas,r9a06g032-sysctrl", > .of_match_table = r9a06g032_match, > }, > + .probe = r9a06g032_clocks_probe, > }; > > static int __init r9a06g032_clocks_init(void) > { > - return platform_driver_probe(&r9a06g032_clock_driver, > - r9a06g032_clocks_probe); > + platform_driver_register(&r9a06g032_clock_driver); > + return 0; > } Why are all of the above changes needed? Shouldn't the platform_driver_probe() keep on working? If it does not, it means the clock driver has some other dependency, and cannot be bound immediately. This is potentially a dangerous situation, as r9a06g032_clocks_probe() is __init, but can still be called at any time later. Hence using platform_driver_probe() is the safe thing to do, possibly with a different reshuffling of the clock and pinctrl initcall priorities. > -subsys_initcall(r9a06g032_clocks_init); > +core_initcall(r9a06g032_clocks_init); Gr{oetje,eeting}s, Geert
Hi Geert, On 20 July 2018 12:21, Geert Uytterhoeven wrote: > On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy wrote: > > To avoid all SoC peripheral drivers deferring their probes, both clock > > and pinctrl drivers should already be probed. Since the pinctrl driver > > requires a clock to access the registers, the clock driver should be > > probed before the pinctrl driver. > > > > Therefore, move the clock driver from subsys_initcall to core_initcall. > > > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> > > Thanks for your patch! Thanks for your review! > The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right? No, the pinctrl driver uses subsys_initcall, but postcore_initcall or arch_initcall may be better to make it clear about the dependencies. > > --- a/drivers/clk/renesas/r9a06g032-clocks.c > > +++ b/drivers/clk/renesas/r9a06g032-clocks.c > > @@ -877,17 +877,18 @@ static const struct of_device_id > r9a06g032_match[] = { > > { } > > }; > > > > -static struct platform_driver r9a06g032_clock_driver = { > > +static struct platform_driver r9a06g032_clock_driver __refdata = { > > .driver = { > > .name = "renesas,r9a06g032-sysctrl", > > .of_match_table = r9a06g032_match, > > }, > > + .probe = r9a06g032_clocks_probe, > > }; > > > > static int __init r9a06g032_clocks_init(void) { > > - return platform_driver_probe(&r9a06g032_clock_driver, > > - r9a06g032_clocks_probe); > > + platform_driver_register(&r9a06g032_clock_driver); > > + return 0; That should be: + return platform_driver_register(&r9a06g032_clock_driver); > > } > > Why are all of the above changes needed? > Shouldn't the platform_driver_probe() keep on working? > If it does not, it means the clock driver has some other dependency, and > cannot be bound immediately. This is potentially a dangerous situation, as > r9a06g032_clocks_probe() is __init, but can still be called at any time later. > Hence using platform_driver_probe() is the safe thing to do, possibly with a > different reshuffling of the clock and pinctrl initcall priorities. No, you cannot call platform_driver_probe() from core_initcall. All drivers that are in core_initcall call platform_driver_register(). Thanks Phil > > -subsys_initcall(r9a06g032_clocks_init); > > +core_initcall(r9a06g032_clocks_init); > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux- > m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
Hi Phil, On Fri, Jul 20, 2018 at 2:06 PM Phil Edworthy <phil.edworthy@renesas.com> wrote: > On 20 July 2018 12:21, Geert Uytterhoeven wrote: > > On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy wrote: > > > To avoid all SoC peripheral drivers deferring their probes, both clock > > > and pinctrl drivers should already be probed. Since the pinctrl driver > > > requires a clock to access the registers, the clock driver should be > > > probed before the pinctrl driver. > > > > > > Therefore, move the clock driver from subsys_initcall to core_initcall. > > > > > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> > > > > Thanks for your patch! > Thanks for your review! > > > The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right? > No, the pinctrl driver uses subsys_initcall, but postcore_initcall or > arch_initcall may be better to make it clear about the dependencies. if the pinctrl driver uses subsys_initcall(), ... > > > --- a/drivers/clk/renesas/r9a06g032-clocks.c > > > +++ b/drivers/clk/renesas/r9a06g032-clocks.c > > > @@ -877,17 +877,18 @@ static const struct of_device_id > > r9a06g032_match[] = { > > > { } > > > }; > > > > > > -static struct platform_driver r9a06g032_clock_driver = { > > > +static struct platform_driver r9a06g032_clock_driver __refdata = { > > > .driver = { > > > .name = "renesas,r9a06g032-sysctrl", > > > .of_match_table = r9a06g032_match, > > > }, > > > + .probe = r9a06g032_clocks_probe, > > > }; > > > > > > static int __init r9a06g032_clocks_init(void) { > > > - return platform_driver_probe(&r9a06g032_clock_driver, > > > - r9a06g032_clocks_probe); > > > + platform_driver_register(&r9a06g032_clock_driver); > > > + return 0; > That should be: > + return platform_driver_register(&r9a06g032_clock_driver); > > > > } > > > > Why are all of the above changes needed? > > Shouldn't the platform_driver_probe() keep on working? > > If it does not, it means the clock driver has some other dependency, and > > cannot be bound immediately. This is potentially a dangerous situation, as > > r9a06g032_clocks_probe() is __init, but can still be called at any time later. > > Hence using platform_driver_probe() is the safe thing to do, possibly with a > > different reshuffling of the clock and pinctrl initcall priorities. > No, you cannot call platform_driver_probe() from core_initcall. > All drivers that are in core_initcall call platform_driver_register(). Hence they cannot have their probe function __init. > > Thanks > Phil > > > > -subsys_initcall(r9a06g032_clocks_init); > > > +core_initcall(r9a06g032_clocks_init); ... using postcore_initcall() or arch_initcall() here, should work with platform_driver_probe()? Gr{oetje,eeting}s, Geert
SGkgR2VlcnQsDQoNCk9uIDIwIEp1bHkgMjAxOCAxMzoxMiwgR2VlcnQgVXl0dGVyaG9ldmVuIHdy b3RlOg0KPiBPbiBGcmksIEp1bCAyMCwgMjAxOCBhdCAyOjA2IFBNIFBoaWwgRWR3b3J0aHkgIHdy b3RlOg0KPiA+IE9uIDIwIEp1bHkgMjAxOCAxMjoyMSwgR2VlcnQgVXl0dGVyaG9ldmVuIHdyb3Rl Og0KPiA+ID4gT24gV2VkLCBKdWwgMTgsIDIwMTggYXQgNDozNCBQTSBQaGlsIEVkd29ydGh5IHdy b3RlOg0KPiA+ID4gPiBUbyBhdm9pZCBhbGwgU29DIHBlcmlwaGVyYWwgZHJpdmVycyBkZWZlcnJp bmcgdGhlaXIgcHJvYmVzLCBib3RoDQo+ID4gPiA+IGNsb2NrIGFuZCBwaW5jdHJsIGRyaXZlcnMg c2hvdWxkIGFscmVhZHkgYmUgcHJvYmVkLiBTaW5jZSB0aGUNCj4gPiA+ID4gcGluY3RybCBkcml2 ZXIgcmVxdWlyZXMgYSBjbG9jayB0byBhY2Nlc3MgdGhlIHJlZ2lzdGVycywgdGhlIGNsb2NrDQo+ ID4gPiA+IGRyaXZlciBzaG91bGQgYmUgcHJvYmVkIGJlZm9yZSB0aGUgcGluY3RybCBkcml2ZXIu DQo+ID4gPiA+DQo+ID4gPiA+IFRoZXJlZm9yZSwgbW92ZSB0aGUgY2xvY2sgZHJpdmVyIGZyb20g c3Vic3lzX2luaXRjYWxsIHRvIGNvcmVfaW5pdGNhbGwuDQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25l ZC1vZmYtYnk6IFBoaWwgRWR3b3J0aHkgPHBoaWwuZWR3b3J0aHlAcmVuZXNhcy5jb20+DQo+ID4g Pg0KPiA+ID4gVGhhbmtzIGZvciB5b3VyIHBhdGNoIQ0KPiA+IFRoYW5rcyBmb3IgeW91ciByZXZp ZXchDQo+ID4NCj4gPiA+IFRoZSAobm90IHlldCB1cHN0cmVhbWVkKSBwaW5jdHJsIGRyaXZlciB1 c2VzIHBvc3Rjb3JlX2luaXRjYWxsKCksIHJpZ2h0Pw0KPiA+IE5vLCB0aGUgcGluY3RybCBkcml2 ZXIgdXNlcyBzdWJzeXNfaW5pdGNhbGwsIGJ1dCBwb3N0Y29yZV9pbml0Y2FsbCBvcg0KPiA+IGFy Y2hfaW5pdGNhbGwgbWF5IGJlIGJldHRlciB0byBtYWtlIGl0IGNsZWFyIGFib3V0IHRoZSBkZXBl bmRlbmNpZXMuDQo+IA0KPiBpZiB0aGUgcGluY3RybCBkcml2ZXIgdXNlcyBzdWJzeXNfaW5pdGNh bGwoKSwgLi4uDQo+IA0KPiA+ID4gPiAtLS0gYS9kcml2ZXJzL2Nsay9yZW5lc2FzL3I5YTA2ZzAz Mi1jbG9ja3MuYw0KPiA+ID4gPiArKysgYi9kcml2ZXJzL2Nsay9yZW5lc2FzL3I5YTA2ZzAzMi1j bG9ja3MuYw0KPiA+ID4gPiBAQCAtODc3LDE3ICs4NzcsMTggQEAgc3RhdGljIGNvbnN0IHN0cnVj dCBvZl9kZXZpY2VfaWQNCj4gPiA+IHI5YTA2ZzAzMl9tYXRjaFtdID0gew0KPiA+ID4gPiAgICAg ICAgIHsgfQ0KPiA+ID4gPiAgfTsNCj4gPiA+ID4NCj4gPiA+ID4gLXN0YXRpYyBzdHJ1Y3QgcGxh dGZvcm1fZHJpdmVyIHI5YTA2ZzAzMl9jbG9ja19kcml2ZXIgPSB7DQo+ID4gPiA+ICtzdGF0aWMg c3RydWN0IHBsYXRmb3JtX2RyaXZlciByOWEwNmcwMzJfY2xvY2tfZHJpdmVyIF9fcmVmZGF0YSA9 DQo+ID4gPiA+ICt7DQo+ID4gPiA+ICAgICAgICAgLmRyaXZlciAgICAgICAgID0gew0KPiA+ID4g PiAgICAgICAgICAgICAgICAgLm5hbWUgICA9ICJyZW5lc2FzLHI5YTA2ZzAzMi1zeXNjdHJsIiwN Cj4gPiA+ID4gICAgICAgICAgICAgICAgIC5vZl9tYXRjaF90YWJsZSA9IHI5YTA2ZzAzMl9tYXRj aCwNCj4gPiA+ID4gICAgICAgICB9LA0KPiA+ID4gPiArICAgICAgIC5wcm9iZSA9IHI5YTA2ZzAz Ml9jbG9ja3NfcHJvYmUsDQo+ID4gPiA+ICB9Ow0KPiA+ID4gPg0KPiA+ID4gPiAgc3RhdGljIGlu dCBfX2luaXQgcjlhMDZnMDMyX2Nsb2Nrc19pbml0KHZvaWQpICB7DQo+ID4gPiA+IC0gICAgICAg cmV0dXJuIHBsYXRmb3JtX2RyaXZlcl9wcm9iZSgmcjlhMDZnMDMyX2Nsb2NrX2RyaXZlciwNCj4g PiA+ID4gLSAgICAgICAgICAgICAgICAgICAgICAgcjlhMDZnMDMyX2Nsb2Nrc19wcm9iZSk7DQo+ ID4gPiA+ICsgICAgICAgcGxhdGZvcm1fZHJpdmVyX3JlZ2lzdGVyKCZyOWEwNmcwMzJfY2xvY2tf ZHJpdmVyKTsNCj4gPiA+ID4gKyAgICAgICByZXR1cm4gMDsNCj4gPiBUaGF0IHNob3VsZCBiZToN Cj4gPiArICAgICAgIHJldHVybiBwbGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoJnI5YTA2ZzAzMl9j bG9ja19kcml2ZXIpOw0KPiA+DQo+ID4gPiA+ICB9DQo+ID4gPg0KPiA+ID4gV2h5IGFyZSBhbGwg b2YgdGhlIGFib3ZlIGNoYW5nZXMgbmVlZGVkPw0KPiA+ID4gU2hvdWxkbid0IHRoZSBwbGF0Zm9y bV9kcml2ZXJfcHJvYmUoKSBrZWVwIG9uIHdvcmtpbmc/DQo+ID4gPiBJZiBpdCBkb2VzIG5vdCwg aXQgbWVhbnMgdGhlIGNsb2NrIGRyaXZlciBoYXMgc29tZSBvdGhlciBkZXBlbmRlbmN5LA0KPiA+ ID4gYW5kIGNhbm5vdCBiZSBib3VuZCBpbW1lZGlhdGVseS4gIFRoaXMgaXMgcG90ZW50aWFsbHkg YSBkYW5nZXJvdXMNCj4gPiA+IHNpdHVhdGlvbiwgYXMNCj4gPiA+IHI5YTA2ZzAzMl9jbG9ja3Nf cHJvYmUoKSBpcyBfX2luaXQsIGJ1dCBjYW4gc3RpbGwgYmUgY2FsbGVkIGF0IGFueSB0aW1lIGxh dGVyLg0KPiA+ID4gSGVuY2UgdXNpbmcgcGxhdGZvcm1fZHJpdmVyX3Byb2JlKCkgaXMgdGhlIHNh ZmUgdGhpbmcgdG8gZG8sDQo+ID4gPiBwb3NzaWJseSB3aXRoIGEgZGlmZmVyZW50IHJlc2h1ZmZs aW5nIG9mIHRoZSBjbG9jayBhbmQgcGluY3RybCBpbml0Y2FsbA0KPiBwcmlvcml0aWVzLg0KPiA+ IE5vLCB5b3UgY2Fubm90IGNhbGwgcGxhdGZvcm1fZHJpdmVyX3Byb2JlKCkgZnJvbSBjb3JlX2lu aXRjYWxsLg0KPiA+IEFsbCBkcml2ZXJzIHRoYXQgYXJlIGluIGNvcmVfaW5pdGNhbGwgY2FsbCBw bGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoKS4NCj4gDQo+IEhlbmNlIHRoZXkgY2Fubm90IGhhdmUg dGhlaXIgcHJvYmUgZnVuY3Rpb24gX19pbml0Lg0KPiANCj4gPg0KPiA+IFRoYW5rcw0KPiA+IFBo aWwNCj4gPg0KPiA+ID4gPiAtc3Vic3lzX2luaXRjYWxsKHI5YTA2ZzAzMl9jbG9ja3NfaW5pdCk7 DQo+ID4gPiA+ICtjb3JlX2luaXRjYWxsKHI5YTA2ZzAzMl9jbG9ja3NfaW5pdCk7DQo+IA0KPiAu Li4gdXNpbmcgcG9zdGNvcmVfaW5pdGNhbGwoKSBvciBhcmNoX2luaXRjYWxsKCkgaGVyZSwgc2hv dWxkIHdvcmsgd2l0aA0KPiBwbGF0Zm9ybV9kcml2ZXJfcHJvYmUoKT8NCk5vcGUsIHlvdSBoYXZl IHRvIHVzZSBwbGF0Zm9ybV9kcml2ZXJfcmVnaXN0ZXIoKSBmb3IgRFQgYmFzZWQgZHJpdmVycy4N CnN1YnN5c19pbml0Y2FsbCBpcyB0aGUgZWFybGllc3QgeW91IGNhbiB1c2UgcGxhdGZvcm1fZHJp dmVyX3Byb2JlKCkuDQoNClRoYW5rcw0KUGhpbA0KDQo+IEdye29ldGplLGVldGluZ31zLA0KPiAN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgR2VlcnQNCj4gDQo+IC0tDQo+IEdlZXJ0IFV5dHRl cmhvZXZlbiAtLSBUaGVyZSdzIGxvdHMgb2YgTGludXggYmV5b25kIGlhMzIgLS0gZ2VlcnRAbGlu dXgtDQo+IG02OGsub3JnDQo+IA0KPiBJbiBwZXJzb25hbCBjb252ZXJzYXRpb25zIHdpdGggdGVj aG5pY2FsIHBlb3BsZSwgSSBjYWxsIG15c2VsZiBhIGhhY2tlci4gQnV0DQo+IHdoZW4gSSdtIHRh bGtpbmcgdG8gam91cm5hbGlzdHMgSSBqdXN0IHNheSAicHJvZ3JhbW1lciIgb3Igc29tZXRoaW5n IGxpa2UgdGhhdC4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBMaW51cyBU b3J2YWxkcw0K -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Phil, On Fri, Jul 20, 2018 at 2:26 PM Phil Edworthy <phil.edworthy@renesas.com> wrote: > On 20 July 2018 13:12, Geert Uytterhoeven wrote: > > On Fri, Jul 20, 2018 at 2:06 PM Phil Edworthy wrote: > > > On 20 July 2018 12:21, Geert Uytterhoeven wrote: > > > > On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy wrote: > > > > > To avoid all SoC peripheral drivers deferring their probes, both > > > > > clock and pinctrl drivers should already be probed. Since the > > > > > pinctrl driver requires a clock to access the registers, the clock > > > > > driver should be probed before the pinctrl driver. > > > > > > > > > > Therefore, move the clock driver from subsys_initcall to core_initcall. > > > > > > > > > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> > > > > > > > > Thanks for your patch! > > > Thanks for your review! > > > > > > > The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right? > > > No, the pinctrl driver uses subsys_initcall, but postcore_initcall or > > > arch_initcall may be better to make it clear about the dependencies. > > > > if the pinctrl driver uses subsys_initcall(), ... > > > > > -subsys_initcall(r9a06g032_clocks_init); > > > > > +core_initcall(r9a06g032_clocks_init); > > > > ... using postcore_initcall() or arch_initcall() here, should work with > > platform_driver_probe()? > Nope, you have to use platform_driver_register() for DT based drivers. > subsys_initcall is the earliest you can use platform_driver_probe(). So drivers/misc/atmel_tclib.c and drivers/pinctrl/pinctrl-coh901.c, which use arch_initcall(), cannot work? If that is really true, you can still use subsys_initcall() in the clock driver, and subsys_initcall_sync() in the pinctrl driver. Gr{oetje,eeting}s, Geert
Hi Geert, On 20 July 2018 13:41, Geert Uytterhoeven wrote: > On Fri, Jul 20, 2018 at 2:26 PM Phil Edworthy wrote: > > On 20 July 2018 13:12, Geert Uytterhoeven wrote: > > > On Fri, Jul 20, 2018 at 2:06 PM Phil Edworthy wrote: > > > > On 20 July 2018 12:21, Geert Uytterhoeven wrote: > > > > > On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy wrote: > > > > > > To avoid all SoC peripheral drivers deferring their probes, > > > > > > both clock and pinctrl drivers should already be probed. Since > > > > > > the pinctrl driver requires a clock to access the registers, > > > > > > the clock driver should be probed before the pinctrl driver. > > > > > > > > > > > > Therefore, move the clock driver from subsys_initcall to > core_initcall. > > > > > > > > > > > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> > > > > > > > > > > Thanks for your patch! > > > > Thanks for your review! > > > > > > > > > The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right? > > > > No, the pinctrl driver uses subsys_initcall, but postcore_initcall > > > > or arch_initcall may be better to make it clear about the dependencies. > > > > > > if the pinctrl driver uses subsys_initcall(), ... > > > > > > > -subsys_initcall(r9a06g032_clocks_init); > > > > > > +core_initcall(r9a06g032_clocks_init); > > > > > > ... using postcore_initcall() or arch_initcall() here, should work > > > with platform_driver_probe()? > > Nope, you have to use platform_driver_register() for DT based drivers. > > subsys_initcall is the earliest you can use platform_driver_probe(). > > So drivers/misc/atmel_tclib.c and drivers/pinctrl/pinctrl-coh901.c, which use > arch_initcall(), cannot work? How those drivers work I do not know. However, I tried with the rzn1 clock driver and it does not work. > If that is really true, you can still use subsys_initcall() in the clock driver, and > subsys_initcall_sync() in the pinctrl driver. True, I'm not sure how people decide which initcall to use and whether the _sync variants of the initcalls have a special meaning or intention. As far as I know they were introduced for threaded probes, so are we supposed to use them for driver dependencies like this? Do you know why the rza1 pinctrl driver is running from core_initcall()? Thanks Phil
Hi Phil, CC Jacopo On Fri, Jul 20, 2018 at 3:57 PM Phil Edworthy <phil.edworthy@renesas.com> wrote: > On 20 July 2018 13:41, Geert Uytterhoeven wrote: > > On Fri, Jul 20, 2018 at 2:26 PM Phil Edworthy wrote: > > > On 20 July 2018 13:12, Geert Uytterhoeven wrote: > > > > On Fri, Jul 20, 2018 at 2:06 PM Phil Edworthy wrote: > > > > > On 20 July 2018 12:21, Geert Uytterhoeven wrote: > > > > > > On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy wrote: > > > > > > > To avoid all SoC peripheral drivers deferring their probes, > > > > > > > both clock and pinctrl drivers should already be probed. Since > > > > > > > the pinctrl driver requires a clock to access the registers, > > > > > > > the clock driver should be probed before the pinctrl driver. > > > > > > > > > > > > > > Therefore, move the clock driver from subsys_initcall to > > core_initcall. > > > > > > > > > > > > > > Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> > > > > > > > > > > > > Thanks for your patch! > > > > > Thanks for your review! > > > > > > > > > > > The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right? > > > > > No, the pinctrl driver uses subsys_initcall, but postcore_initcall > > > > > or arch_initcall may be better to make it clear about the dependencies. > > > > > > > > if the pinctrl driver uses subsys_initcall(), ... > > > > > > > > > -subsys_initcall(r9a06g032_clocks_init); > > > > > > > +core_initcall(r9a06g032_clocks_init); > > > > > > > > ... using postcore_initcall() or arch_initcall() here, should work > > > > with platform_driver_probe()? > > > Nope, you have to use platform_driver_register() for DT based drivers. > > > subsys_initcall is the earliest you can use platform_driver_probe(). > > > > So drivers/misc/atmel_tclib.c and drivers/pinctrl/pinctrl-coh901.c, which use > > arch_initcall(), cannot work? > How those drivers work I do not know. However, I tried with the rzn1 clock > driver and it does not work. > > > If that is really true, you can still use subsys_initcall() in the clock driver, and > > subsys_initcall_sync() in the pinctrl driver. > True, I'm not sure how people decide which initcall to use and whether the > _sync variants of the initcalls have a special meaning or intention. As far as > I know they were introduced for threaded probes, so are we supposed to > use them for driver dependencies like this? > > Do you know why the rza1 pinctrl driver is running from core_initcall()? Probably because it can? Note that drivers/clk/renesas/clk-rz.c uses CLK_OF_DECLARE(). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/clk/renesas/r9a06g032-clocks.c b/drivers/clk/renesas/r9a06g032-clocks.c index a0b6ecd..b03d616 100644 --- a/drivers/clk/renesas/r9a06g032-clocks.c +++ b/drivers/clk/renesas/r9a06g032-clocks.c @@ -877,17 +877,18 @@ static const struct of_device_id r9a06g032_match[] = { { } }; -static struct platform_driver r9a06g032_clock_driver = { +static struct platform_driver r9a06g032_clock_driver __refdata = { .driver = { .name = "renesas,r9a06g032-sysctrl", .of_match_table = r9a06g032_match, }, + .probe = r9a06g032_clocks_probe, }; static int __init r9a06g032_clocks_init(void) { - return platform_driver_probe(&r9a06g032_clock_driver, - r9a06g032_clocks_probe); + platform_driver_register(&r9a06g032_clock_driver); + return 0; } -subsys_initcall(r9a06g032_clocks_init); +core_initcall(r9a06g032_clocks_init);
To avoid all SoC peripheral drivers deferring their probes, both clock and pinctrl drivers should already be probed. Since the pinctrl driver requires a clock to access the registers, the clock driver should be probed before the pinctrl driver. Therefore, move the clock driver from subsys_initcall to core_initcall. Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com> --- drivers/clk/renesas/r9a06g032-clocks.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)