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
| ||
|
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/
Powered by blists - more mailing lists