On Wed, Feb 13, 2013 at 10:52 PM, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Wed, Feb 13, 2013 at 09:04:59PM +0000, Grant Likely wrote: >> On Sat, 9 Feb 2013 22:41:38 +0000, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: >> > On Sat, Feb 09, 2013 at 10:31:05PM +0000, Grant Likely wrote: >> > > If it is a probe function, then yes the __init annotations need to be >> > > removed or the driver needs to use platform_driver_probe(). This has >> > > been the model as long as I can remember. As long as a driver has a >> > > .probe hook, the driver core can call it at any time. Deferred probe >> > > has only exposed the issue. >> > > >> > > If you want to discard the .probe() hook, then the probe() pointer >> > > needs to be cleared from the driver structure before discarding the >> > > sections. Otherwise the driver core can still call it which is what >> > > happens in deferred probe and can happen if a device gets unbound from >> > > a driver and then re-attached. >> > >> > You're talking about something completely different on the assumption >> > that what is being talked about is the probe hook. It isn't. It's >> > a path for the console initialization which has _always_ been __init >> > marked since the dawn of time, because modules are not supposed to >> > be calling that path. >> >> Sorry, you're right. Hitting reply too quickly I guess. >> >> However, the point still stands that anything that can be called from >> a .probe() path cannot be in an __init section with the current driver >> model. A driver can even be unbound from a device and reattached at >> runtime. That would also cause problems. > > However, it reveals much bigger problems - that is, if you defer the > probe of the console, what happens when we need to open the console... > > Although you can say that, there's _much_ bigger problems here if you > delay console initialization - you'll effectively end up calling init > with no system console in place, which means you'll see no output from > init until the deferred probe sorts itself out. > > Yes, it's an unintended side effect of deferred probing, but nevertheless > one which needs to be resolved such that the console _is_ initialized > before it's required, which happens _before_ the init section is > discarded. I've replied with a suggested solution to Haojian's patch to driver core. If he can test it and post a proper patch, then I'll ack it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
