Re: Re[2]: [PATCH v2 1/3] mfd: syscon: Removed support for unloading
On Tuesday 12 February 2013, Alexander Shiyan wrote: > > On Monday 11 February 2013, Alexander Shiyan wrote: > > > The driver can be used in various subsystems and therefore should not > > > be unloaded when it is defined in the kernel configuration, so remove > > > support for unloading it. > > > > > > Signed-off-by: Alexander Shiyan > > > > Can you describe a scenario where that would happen? Normally the > > module should stay pinned as long as any other module refers > > to its exported symbols. > > Probably I wrote a bad description. > The driver registered by "postcore_initcall". Therefore, if we unregister the > driver, we have no way to register it back. Fixme please. Ah, the driver is actually "bool" in Kconfig rather than "tristate", so it is not possible to build it as a module. Makes sense then, and if we ever want to turn this into a module, we can still revert your patch. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re[2]: [PATCH v2 1/3] mfd: syscon: Removed support for unloading
On Tuesday 12 February 2013, Alexander Shiyan wrote: On Monday 11 February 2013, Alexander Shiyan wrote: The driver can be used in various subsystems and therefore should not be unloaded when it is defined in the kernel configuration, so remove support for unloading it. Signed-off-by: Alexander Shiyan shc_w...@mail.ru Can you describe a scenario where that would happen? Normally the module should stay pinned as long as any other module refers to its exported symbols. Probably I wrote a bad description. The driver registered by postcore_initcall. Therefore, if we unregister the driver, we have no way to register it back. Fixme please. Ah, the driver is actually bool in Kconfig rather than tristate, so it is not possible to build it as a module. Makes sense then, and if we ever want to turn this into a module, we can still revert your patch. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re[2]: [PATCH v2 1/3] mfd: syscon: Removed support for unloading
Hello.
> On Monday 11 February 2013, Alexander Shiyan wrote:
> > The driver can be used in various subsystems and therefore should not
> > be unloaded when it is defined in the kernel configuration, so remove
> > support for unloading it.
> >
> > Signed-off-by: Alexander Shiyan
>
> Can you describe a scenario where that would happen? Normally the
> module should stay pinned as long as any other module refers
> to its exported symbols.
Probably I wrote a bad description.
The driver registered by "postcore_initcall". Therefore, if we unregister the
driver, we have no way to register it back. Fixme please.
---
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re[2]: [PATCH v2 1/3] mfd: syscon: Removed support for unloading
Hello.
On Monday 11 February 2013, Alexander Shiyan wrote:
The driver can be used in various subsystems and therefore should not
be unloaded when it is defined in the kernel configuration, so remove
support for unloading it.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
Can you describe a scenario where that would happen? Normally the
module should stay pinned as long as any other module refers
to its exported symbols.
Probably I wrote a bad description.
The driver registered by postcore_initcall. Therefore, if we unregister the
driver, we have no way to register it back. Fixme please.
---
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
