linux-kernel - Re: [RFC PATCH 1/2] mmc_spi: export probe and remove functions

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: <20080601121841.0392b01c@mjolnir.drzeus.cx>
Date:	Sun, 1 Jun 2008 12:18:41 +0200
From:	Pierre Ossman <drzeus-mmc@...eus.cx>
To:	avorontsov@...mvista.com
Cc:	David Brownell <dbrownell@...rs.sourceforge.net>,
	Grant Likely <grant.likely@...retlab.ca>,
	Gary Jennejohn <garyj@...x.de>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] mmc_spi: export probe and remove functions

On Mon, 26 May 2008 17:10:09 +0400
Anton Vorontsov <avorontsov@...mvista.com> wrote:

> 
> Btw, this isn't actually drivers encapsulating. This is about making
> mmc_spi export some "library" function which could be used by other
> bindings.
> 
> Think of usb_add_hcd() used by various drivers' bindings for e.g.
> drivers/usb/host/ehci-*.c. Though usb_add_hcd() is more generic
> than just "EHCI" bindings, but only because there is nothing to
> share between them. (for MMC over SPI bindings all we want to do is fill
> the platform data).
> 

There's a big difference. usb_add_hcd() is designed specifically to be
called by other, real probe functions. mmc_spi_probe() _is_ a probe
function. Also exporting it as a library function is very confusing.

> 
> Maybe something like this? I don't like it so much, but given that
> you don't like to export functions from mmc_spi, we'll have to place
> some calls into the driver itself. :-/ And there is no easy way to do
> generic callbacks, since that way we'll have implement "mmc_spi
> callbacks subsystem". :-)

That's not a callback, but an explicit call to another module.


All of this work looks a bit like trying to wedge a square piece into a
round hole. It looks to me that the kernel needs a bit of restructuring
to handle it. You can't really export every probe function of every
platform device so that you can add OF hooks to it.

>From what I can tell, the OF stuff behaves very much like the PNP
system on PCs. The information relayed is a bit more versatile though.
Perhaps what is needed is a more advanced "platform" bus that is
modeled after the PNP bus, but with the extra ability of handling the
stuff currently crammed into the platform structures. mmc_spi would
then be extended to be driver for the "platform" bus and we could have
generic calls like platform_get_pin(dev, "ro");.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  rdesktop, core developer          http://www.rdesktop.org
--
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/