Date: Thu, 10 Aug 2017 00:33:25 +0200 From: =?UTF-8?Q?Manuel_St=c3=bchn?= <freebsdnewbie@freenet.de> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: devicetree vs. MODULE_DEPEND Message-ID: <4bde70fb-04e4-7d1d-ad5b-3a8f80d6993e@freenet.de> In-Reply-To: <1502315961.50720.75.camel@freebsd.org> References: <20170809205919.GA62042@freebsd-t420.fritz.box> <1502315961.50720.75.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 09 Aug 2017 15:59:21 -0600, Ian Lepore wrote > On Wed, 2017-08-09 at 22:59 +0200, Manuel Stühn wrote: >> Hi list, >> >> is it correct, that the sequence in the devicetree-blob defines the >> probing sequence without considering the MODULE_DEPEND-macro? >> >> I stumbled over an unexpected behavior during the ti_pruss-driver >> development. Because the ti-pruss is gone in the default devicetree, >> I >> activate it via the overlay-framework and put it to the address >> "/ocp/pruss@4a300000". The devicetree-blob contains the entry and >> the >> driver gets probed, but it fails to enable its clock. >> This is quite obvious as according to dmesg the am335x_prcm0 is >> probed >> _after_ the ti_pruss0 device. So I tried to handle this by adding an >> explicit dependency to ti_prcm into the ti_pruss driver like: >> MODULE_DEPEND(ti_pruss, ti_prcm, 1, 1, 1); >> >> It compiles cleanly, unfortunately this changes nothing. Only placing >> it >> in the devicetree after the prcm-node or loading it as a module >> after >> the OS booted up makes the device probe correctly. >> >> Any ideas? > > MODULE_DEPEND only affects the kernel linker. It ensures that other > modules you depend on automatically get loaded along with your module. > > Try the attached patch to ensure that the clocks driver is loaded > earlier than drivers that might rely on it. > The patch works for me, thanks for your help!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4bde70fb-04e4-7d1d-ad5b-3a8f80d6993e>