public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Cc: greg@kroah.com, s.hauer@pengutronix.de,
	linux-arm-kernel@lists.arm.linux.org.uk,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/3] platform_device: add init() exit() callbacks
Date: Tue, 24 Feb 2009 19:29:42 +0100	[thread overview]
Message-ID: <20090224182942.GA12372@pengutronix.de> (raw)
In-Reply-To: <20090224155731.28880.77132.stgit@Programuotojas>

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/  |

      reply	other threads:[~2009-02-24 18:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-24 15:57 [RFC PATCH 1/3] platform_device: add init() exit() callbacks Paulius Zaleckas
2009-02-24 18:29 ` Uwe Kleine-König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090224182942.GA12372@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=greg@kroah.com \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulius.zaleckas@teltonika.lt \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox