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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTik7BnJKWCsm2L3-GJPTaaiXFNSgaA@mail.gmail.com>
Date:	Thu, 19 May 2011 14:25:47 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Barry Song <21cnbao@...il.com>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	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 1:38 PM, Barry Song <21cnbao@...il.com> wrote:

>> -arch_initcall(u300_gpio_init);
>> -module_exit(u300_gpio_exit);
>>
> 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.

> guess symbol u300_gpio_exit will finally lose in the last vmlinux
> since it is in exit section and built-in kernel.

Yes. And if you one day, to do some testing, compile and load it
as module and unload it, it is handy.

I have other drivers where I simply don't have an exit function
but this one I have actually used.

> another problem i see is after moving gpio/pinmux to drivers as
> platform device, codes in arch/arm/plat(mach) can't  call gpio/pinmux
> api before the related platform devices registerred. that will
> required these platform devices enter system earlier.

This is exactly the reason why the u300 gpio driver needs to
be initialized in an arch_initcall().

Yours,
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ