> -----Original Message----- > From: Menon, Nishanth > Sent: Friday, October 22, 2010 3:56 PM > To: Premi, Sanjeev > Cc: Nayak, Rajendra; [email protected] > Subject: Re: hwmod and insertable modules > > Premi, Sanjeev had written, on 10/22/2010 05:01 AM, the following: > > >>>>> During module_init I used omap_device_build() to create the > >>>> omap_device. > >>>>> But when trying to implement the module_exit, I > couldn't find the > >>>>> corresponding 'destructor'. > >>>> omap_device_build essentially does a platform_device > >> register today > >>>> and hence its not something to be done from a > insmod'able 'driver'. > >>> [sp] How does this work for - say dspbridge - where the DSP > >> as device > >>> may not be 'registered' until it is really expected to be used? > >>> > >> arch/arm/mach-omap2/dspbridge.c? ;) > > > > Which repo? On the dspbridge branch on linux-omap, there is not such > :) it is not there as dspbridge is in staging at the moment - > I believe > there is some sort of rule of not depending on staging drivers or > something like that.. but the point I was attempting to make > is backing > Rajendra's statement -> split your driver into silicon > specific data and > silicon independent driver -> the silicon dependent data (like hwmod) > can be collected by a file located in arch/arm/mach-omap2 -> pass the
I am not really concerned for location of the file - but intent of the original query was to understand if we ever thought of antonym of omap_device_build() OR if it did come for discussion if there was an accepted disposition. > data as platform_data(with stuff like baseaddress etc..) to > the driver > and things can happily function... Would suggest posting out a > RFC patch > if you'd like better ideas from the community I guess. I was trying other way - understand if there is an existing norm/ convention that I can follow - rather than (re)invent it! Based on discussion so far, I will definitely have an RFC. > > -- > Regards, > Nishanth Menon > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
