On 12/19/2011 06:22 PM, ext Felipe Balbi wrote:
On Mon, Dec 19, 2011 at 05:45:30PM +0200, Vladimir Zapolskiy wrote:
This change is indended to prevent a situation, when a user finds unworking
musb controller on his board. Due to a restriction of determined order of
musb-{omap2430,da8xx,blackfin,tusb,am35x,ux500,davinci} and musb-hdrc
loading, there is no option to have a working musb controller, if the
correspondent module with a particular controller support is loaded after musb
core.
Then fix that. Don't force EVERYBODY to have a built-in MUSB just
because MUSB driver still has bugs. Find out the root cause of this
module loading order issue, and fix it.
Ok.
Note, that all of the touched drivers have subsys_initcall() initialization,
which basically doesn't have any special load order meaning, if a driver is
compiled as module.
Yes and that's because they should all be module_init() instead. We have
to stop this hackery of forcing certain loading by sticking *_initcall()
on drivers and making everything built-in. This is utterly wrong and we
need another way to force dependency between modules. If MUSB needs an
I2C transceiver to be loaded before it, you need to find a better way to
tell that to the kernel (or to userland).
What is your raw idea of making proper order of module loading?
This patch is just a hack trying to force the driver into a working
condition without actually fixing the problem. MUSB still has many
issues and that's known, but masking the issue with Kconfig tricks will
not fly.
Fix the real problem, which is: the glue layer has a separate address
space and should not depend on the musb pointer at all. So that's what
needs to be done. That will prevent that NULL pointer you tried to fix
on previous patch. Now the loading order, you should let udev load
modules for you. If it's not loading modules automatically, then there's
a missing MODULE_ALIAS() for example.
Good, I'll take a look at that. However I presume that if you want to
have half-working modules for a while, at least in temporarily it might
be fruitful to prevent some oopses in them, does it sound wild?
Signed-off-by: Vladimir Zapolskiy<vladimir.zapolskiy@xxxxxxxxx>
Cc: Felipe Balbi<balbi@xxxxxx>
It took so long to make this stupid driver work as a module because of
all the issues the original mentor delivery had I AM NOT TAKING THIS
PATCH!! EVER!
Do not send it again in any way whatsoever.
I have a feeling that deliberately set RFC in the header is sufficient
excuse not to take that patch, so thanks for comments.
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
