On Thu, Oct 09, 2014 at 08:16:18AM -0500, Dinh Nguyen wrote: > Hi Philipp, > > On 10/9/14, 4:03 AM, Philipp Zabel wrote: > > Am Mittwoch, den 08.10.2014, 21:44 -0500 schrieb > > dinguyen@xxxxxxxxxxxxxxxxxxxxx: > >> From: Dinh Nguyen <dinguyen@xxxxxxxxxxxxxxxxxxxxx> > >> > >> There are certain drivers that are required to get loaded very early using > >> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver. > >> This driver has to get loaded early because it needs to enable FPGA components > >> that are connected to the bridge. > >> > >> This FPGA bridge driver will using the reset controller API to toggle it's > >> reset bits, thus, it needs the reset driver to be loaded as early as possible > >> in order for it to get used properly. > > > > Without knowing the details, this sounds like the wrong approach. Can't > > the bridge driver return -EPROBE_DEFER until the reset controller is > > available? > > > > The bridge driver is also using arch_initcall, as it also needs to get > loaded early for FPGA IPs to work, and so later driver loading will work > for the FPGA IPs. > For the bridge driver the same is true. I guess that there *might* be IP cores where you need to be very early, but that shouldn't be the normal case. If the driver can't get loaded properly, the right thing would be to fix the driver. I have developed a bridge driver, too (which only needs the devicetree binding docu for a v1) and I have a driver+IP core that is directly connected to the bridge. I don't need any messing around with the initcalls to work properly. -EPROBE_DEFER works just fine. What I do need however is loading the FPGA very early of course, if it is not done in the bootloader. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
