On Fri, Aug 16, 2013 at 03:08:07PM -0700, Greg Kroah-Hartman wrote:
> On Fri, Aug 16, 2013 at 11:55:31PM +0200, Thierry Reding wrote:
> > > > + list_for_each_entry(private, &device_early_list, early) {
> > > > + struct device *dev = private->device;
> > > > + int err;
> > > > +
> > > > + if (dev->bus == &platform_bus_type) {
> > >
> > > Why special case the platform bus? We are trying to move things off of
> > > the platform bus, don't make it harder to do that :)
> >
> > I heard about that, but I must have missed the thread where this was
> > discussed. Can you point me to it?
>
> I thought it was on lkml, but it might have been limited to linux-arm
> and the ksummit-discuss mailing list on one of the threads there.
> Sorry, I can't recall it at the moment.
I think I found it. It was limited to linux-arm and ksummit-discuss.
Interesting read, thanks.
> > > Not that I really like the whole idea anyway, but I doubt there's much I
> > > can do about it...
> >
> > Well, getting feedback from you and others is precisely the reason why I
> > wanted to post this early. There must be a reason why you don't like it,
> > so perhaps you can share your thoughts and we can mould this into
> > something that you'd be more comfortable with.
>
> Ideally we would have the rest of the system up and running (i.e. sysfs)
> before having to deal with devices and drivers. As it is, you are
> "special casing" a number of special devices on special platforms to
> work around architectural issues on those platforms. Stuff that ideally
> would never need to be done, except for crazy hardware designers :)
>
> So I understand that it is needed, in some special cases, but that
> doesn't mean I have to like it...
So the rest of this thread seems to be going in a slightly different
direction. If indeed we can come up with a way to limit the early code
to setup only the bare minimum and not register all kinds of data
structures for later on, then this "workaround" shouldn't really be
needed at all.
I think it would be nice to ultimately have a single driver that would
know how to do early setup that will be enough to get us to initcalls
and do the full initialization once the regular .probe() is called.
> > To be honest I don't particularly like it either. It's very hackish for
> > core code. But on the other hand there are a few device/driver ordering
> > problems that this (or something similar) would help solve. I'm
> > certainly open to discuss alternatives and perhaps there's a much
> > cleaner way to solve the problem.
>
> As this usually is needed on a case-by-case basis, I'm hoping that your
> case really does need this, right? If so, there's not much the kernel
> can do except add hooks like this to make it work properly.
Well, the most obvious cases where early initialization is needed are
interrupt controllers and clocks. Those used to be setup by platform
code and was isolated to arch/arm (I guess the same is true for other
architectures as well). That way everybody could do what they wanted.
We've moved a lot of that code out into drivers/ but a side-effect of
that was that some of it wasn't turned into proper drivers.
Perhaps the current solutions are all fine and I should just ignore that
they irritate me.
Thierry
Attachment:
pgpmrPGUjZsL4.pgp
Description: PGP signature
