| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20110520065820.GC21285@ponder.secretlab.ca> Date: Fri, 20 May 2011 00:58:20 -0600 From: Grant Likely <grant.likely@...retlab.ca> To: Barry Song <21cnbao@...il.com> Cc: Linus Walleij <linus.walleij@...aro.org>, Linus Walleij <linus.walleij@...ricsson.com>, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, Lee Jones <lee.jones@...aro.org>, Jonas Aaberg <jonas.aberg@...ricsson.com> Subject: Re: [PATCH 02/10] mach-u300: rewrite gpio driver, move to drivers/gpio On Thu, May 19, 2011 at 10:05:25PM +0800, Barry Song wrote: > 2011/5/19 Linus Walleij <linus.walleij@...aro.org>: > > On Thu, May 19, 2011 at 2:35 PM, Barry Song <21cnbao@...il.com> wrote: > >> 2011/5/19 Linus Walleij <linus.walleij@...aro.org>: > >>> On Thu, May 19, 2011 at 1:38 PM, Barry Song <21cnbao@...il.com> wrote: > >>>> > >>>> looks like the driver can't be a real module, is the module_exit > >>>> suitable? it looks strange module_exit plays together with > >>>> arch_initcall. > >>> > >>> It's a rather common design pattern in the kernel for early > >>> platform drivers. Either the dependencies are resolved by the > >>> different initlevels or they are resolved in probe order with > >>> loadable modules. Module load will call all initlevels in order. > >>> > >>> It is not elegant but it is common. > >> > >> Linus, thanks for your reply. module_exit and related functions are > >> really useless codes. but people have done that before, then we have > >> no way except following. > >> u300_gpio_exit never gets chance to run and when we disassemble > >> vmlinux, u300_gpio_exit() function should be not in the final binary > >> at all, just a symbol name is left. > > > > I know. I can make the Kconfig options tristate if it makes you feel > > better... > what i feel headache is that it is really difficult and unpredicted > for an internal gpio driver to be removable in lots of read products > because gpio is probably the last bottom module other drivers need. > even it can be called in arch/arm/plat(mach). > > i am not sure whether i am thinking right. gpio and pinmux are more > things of bottom level APIs like dma/clock tree but not like device > drivers. but i really think you have sent a great pinmux core > framework. > No, gpio controllers are just another set of devices, albeit really low level devices that lots of other things depend on. The Linux model does and should support loading/unloading of GPIO drivers providing there is nothing using them. So, yes, in a lot of cases unloading them is simply not possible because board support code depends on them at some point in early boot, but that doesn't mean that they should be treated differently than any other drivers. Oh, and just to be clear, there are also use cases where really low level code has to go and poke GPIO devices directly before any of the driver model subsystems are up and running. That is a different use-case and it is not what I'm talking about here. g. > we once thought we could have a plat-common above all > plat-xxx/mach-xxx, and let the plat-common provide the cores of dma, > clk, gpio, pinmux(pinmux core from you), for example, all common API > and abstract level codes like gpio_request can be there, and SoCs just > implement some hardware-related callbacks required by plat-common in > themselves plat-xxx . > > > > > Linus Walleij > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists