linux-kernel - Re: [RFC PATCH 1/3] platform_device: add init() exit() callbacks

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] [day] [month] [year] [list]

Date:	Tue, 24 Feb 2009 19:29:42 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Paulius Zaleckas <paulius.zaleckas@...tonika.lt>
Cc:	greg@...ah.com, s.hauer@...gutronix.de,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/3] platform_device: add init() exit() callbacks

Hello,

On Tue, Feb 24, 2009 at 05:57:31PM +0200, Paulius Zaleckas wrote:
> Some(many?) platform drivers needs board specific callbacks
> to initialize/deinitialize(request/release) GPIO pins,
> generic bus initialization, board specific configuration
> and etc.
Up to now I used clk_enable + clk_disable for this purpose in my code.
Isn't that a nice alternative?  One pro of it is that you don't need to
extend struct platform_device.

> Currently this is done by passing pointers to such functions
> through platform_data. It is common for such drivers to have
> init()/exit() functions declared in platform_data structure.
> 
> Using platform_data for this purpose has some drawbacks:
> 1. You have to write checks for platform_data and functions
>    pointers existance and ensure correct error path in every
>    platform driver.
I don't consider this a real drawback.  Kernel code is full of these
idioms.

> 2. Since part of the code is in driver and another in board
>    specific code, usually you have to push this code through
>    different maintainers. This also adds some not necessary work
>    to ensure that adding changes to the board code, while changes
>    to the driver are still pending, will not break this board
>    compilation.
I don't get this rationale.  Do you mean "As now all platform drivers
have init() and exit() you don't need to break compilation when
introducing them to the driver and the platform code."  This counts
hardly as an argument.

> 3. In my case, I am adding support for new ARM CPU, this needs
>    to be done for some already existing drivers like serial 8250,
>    mtd physmap and etc. this becomes pain in the ...
As far as I can see the 8250 driver doesn't currently support callbacks.
What exactly do you mean here?

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
--
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/