RE: [PATCH] RFC: AMBA bus discardable probe() function

RE: [PATCH] RFC: AMBA bus discardable probe() function

[Linus WALLEIJ]

[Russell]

> which gives a total of 5188 bytes for all the above probe functions.
> However, in order to free this, we're adding 184 bytes of code and
> literal pool to achieve this:
> (...) 
> The overall kernel size is 3877020 bytes, which means we're potentially
> allowing for 0.13% of the kernel to be freed at run time - which may
> equate to one or at most two additional pages.

We have the PL022 as well, and the PL08x is being added but it will
likely stay in that ballpark figure.

But overall that does not seem to be worth it, so let's drop it
for the time being. CC:ing the linux-embedded folks that
often worry about footprint size to see if someone oppose. Also
CC Viresh who works on a platform for e.g. set-top boxes using
these PrimeCells which I think may be memory-constrained.

Yours,
Linus Walleij

RE: [PATCH] RFC: AMBA bus discardable probe() function

[Linus WALLEIJ]

[Greg]
> [Me]
> > +	spin_lock(&amba_bustype.p->klist_drivers.k_lock);
> 
> Ick, nope, you can't do this, sorry.  That's a "private" structure for
> a reason.

Yeah I get it, but in the platform bus case what's that traversal of 
the klists actually for? I didn't get it, and was guessing that it
was considering the case where devices spawn new devices.

> So what's the real driving force here, just saving a few hundred bytes
> after booting?  Or something else?

A few thousand actually according to Russells measurements.
And no I don't think it's worth it unless someone else challenge this...

Yours,
Linus Walleij

Re: [PATCH] RFC: AMBA bus discardable probe() function

[Dmitry Torokhov]

On Wednesday, August 04, 2010 11:26:00 pm Linus WALLEIJ wrote:
> [Greg]
> 
> > [Me]
> > 
> > > +	spin_lock(&amba_bustype.p->klist_drivers.k_lock);
> > 
> > Ick, nope, you can't do this, sorry.  That's a "private" structure for
> > a reason.
> 
> Yeah I get it, but in the platform bus case what's that traversal of
> the klists actually for? I didn't get it, and was guessing that it
> was considering the case where devices spawn new devices.

It is to check if the driver actually bound to any devices and fail driver
registration if it did not - then, in case of modular build, entire driver
module might get unloaded from memory as well.

-- 
Dmitry