Re: ti_scm_syscon driver
Oskar Holmlund via freebsd-arm <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.arm |
|---|---|
| Message-ID | <[email protected]> |
Den måndag 7 september 2020 02:30:57 CEST, Thomas Skibo <[email protected]> skrev: Hello. I am testing some code I have developed to provide the Zynq boards with a real clock driver and update the other device drivers to use the clock infrastructure. It is also supposed to allow us to use "upstream" gnu dts files. But, I ran into a problem booting a GENERIC kernel on my Zybo. The ti_scm_syscon driver, which has the "syscon" compatibility string, grabs the zynq-slcr node before my driver. The compatibility property for the node in the GNU dts file is; compatible = "xlnx,zynq-slcr", "syscon", "simple-mfd"; I fixed the problem by having my probe routine return DEVICE_PROBE_SPECIFIC. But, the DEVICE_PROBE(9) man page seems to say I shouldn't do this. Also, I see a lot of device nodes in other boards that have "syscon" along with their more specific driver name. Aren't they going to run into problems too if the ti_scm_syscon driver matches them? Should the ti_scm_syscon driver use a lower priority return value in its probe routine? --Thomas Skibo _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]" Hi Thomas, I'm sorry I've caused you trouble with ti_scm_syscon.c catchall for syscon. I will try to point out the situation from TI dts. (head) sys/gnu/dts/arm/am33xx-l4.dtsi from line 270 the control module are defined and 286 the syscon part. The Control module are described here https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/omap/ctrl.txt the syscon part is not directly documented for TI its just there in the example. (of course this exist https://www.kernel.org/doc/Documentation/devicetree/bindings/mfd/syscon.txt ) I'm glad for any suggestions to solve the issue to not interfere with other drivers. I can test your proposal to lower the priority. Or get TI to change syscon to something more specific in the DTS? Maybe its better if i hardcode ti_scm.c to add the syscon child and remove the probe part from ti_scm_syscon.c? Other suggestions? -- Bästa Hälsningar Oskar Holmlund Tel 070-3220292 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "[email protected]"