[PATCH 01/38] move asic3_remove to .devexit.text
Uwe Kleine-König
it using __devexit.
Signed-off-by: Uwe Kleine-König <u.klein...@pengutronix.de>
Acked-by: Sam Ravnborg <s...@ravnborg.org>
Cc: Samuel Ortiz <sa...@linux.intel.com>
Cc: Philipp Zabel <philip...@gmail.com>
Cc: Yinghai Lu <yhlu....@gmail.com>
Cc: Russell King <rmk+k...@arm.linux.org.uk>
Cc: linux-...@vger.kernel.org
---
drivers/mfd/asic3.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
index 63a2a66..e22128c 100644
--- a/drivers/mfd/asic3.c
+++ b/drivers/mfd/asic3.c
@@ -908,7 +908,7 @@ static int __init asic3_probe(struct platform_device *pdev)
return ret;
}
-static int asic3_remove(struct platform_device *pdev)
+static int __devexit asic3_remove(struct platform_device *pdev)
{
int ret;
struct asic3 *asic = platform_get_drvdata(pdev);
--
1.6.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Uwe Kleine-König
it using __devexit.
Signed-off-by: Uwe Kleine-König <u.klein...@pengutronix.de>
Acked-by: Sam Ravnborg <s...@ravnborg.org>
Cc: James E.J. Bottomley <James.B...@suse.de>
Cc: Yang Hongyang <yan...@cn.fujitsu.com>
Cc: James Bottomley <James.B...@HansenPartnership.com>
Cc: Andrew Morton <ak...@linux-foundation.org>
Cc: Alan Cox <al...@linux.intel.com>
Cc: linux...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Alan Cox <al...@redhat.com>
---
drivers/scsi/atp870u.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/atp870u.c b/drivers/scsi/atp870u.c
index b137e56..1059167 100644
--- a/drivers/scsi/atp870u.c
+++ b/drivers/scsi/atp870u.c
@@ -3143,7 +3143,7 @@ static int atp870u_biosparam(struct scsi_device *disk, struct block_device *dev,
return 0;
}
-static void atp870u_remove (struct pci_dev *pdev)
+static void __devexit atp870u_remove (struct pci_dev *pdev)
{
struct atp_unit *devext = pci_get_drvdata(pdev);
struct Scsi_Host *pshost = devext->host;
Uwe Kleine-König
define it using __devexit.
Signed-off-by: Uwe Kleine-König <u.klein...@pengutronix.de>
Cc: Ming Lei <tom.l...@gmail.com>
Cc: Henrique de Moraes Holschuh <h...@hmh.eng.br>
Cc: Greg Kroah-Hartman <gre...@suse.de>
Cc: David Brownell <dbro...@users.sourceforge.net>
Cc: linux-...@vger.kernel.org
Cc: David Woodhouse <dw...@infradead.org>
Cc: linu...@lists.infradead.org
---
drivers/mtd/nand/excite_nandflash.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/nand/excite_nandflash.c b/drivers/mtd/nand/excite_nandflash.c
index 72446fb..af6a6a5 100644
--- a/drivers/mtd/nand/excite_nandflash.c
+++ b/drivers/mtd/nand/excite_nandflash.c
@@ -128,7 +128,7 @@ static int excite_nand_devready(struct mtd_info *mtd)
* The binding to the mtd and all allocated
* resources are released.
*/
-static int __exit excite_nand_remove(struct platform_device *dev)
+static int __devexit excite_nand_remove(struct platform_device *dev)
{
struct excite_nand_drvdata * const this = platform_get_drvdata(dev);
James Bottomley
> The function atp870u_remove is used only wrapped by __devexit_p so define
> it using __devexit.
But there's really no point to this. HOTPLUG is always defined on SCSI
systems that have these drivers, which means that _devinit/exit are
nops. That makes the change purely cosmetic and not worth churning two
dozen drivers for.
Even for the EMBEDDED cases that should care about this, the maintainers
have indicated that the memory savings simply aren't worth the hassle of
tracking the sectional updates.
James
Samuel Ortiz
On Tue, Nov 24, 2009 at 10:06:56PM +0100, Uwe Kleine-K�nig wrote:
> The function asic3_remove is used only wrapped by __devexit_p so define
> it using __devexit.
This one was already applied to my for-next branch.
Cheers,
Samuel.
> Signed-off-by: Uwe Kleine-K�nig <u.klein...@pengutronix.de>
> Acked-by: Sam Ravnborg <s...@ravnborg.org>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> Cc: Philipp Zabel <philip...@gmail.com>
> Cc: Yinghai Lu <yhlu....@gmail.com>
> Cc: Russell King <rmk+k...@arm.linux.org.uk>
> Cc: linux-...@vger.kernel.org
> ---
> drivers/mfd/asic3.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
> index 63a2a66..e22128c 100644
> --- a/drivers/mfd/asic3.c
> +++ b/drivers/mfd/asic3.c
> @@ -908,7 +908,7 @@ static int __init asic3_probe(struct platform_device *pdev)
> return ret;
> }
>
> -static int asic3_remove(struct platform_device *pdev)
> +static int __devexit asic3_remove(struct platform_device *pdev)
> {
> int ret;
> struct asic3 *asic = platform_get_drvdata(pdev);
> --
> 1.6.5.2
>
--
Intel Open Source Technology Centre
http://oss.intel.com/
Uwe Kleine-König
> On Tue, 2009-11-24 at 22:06 +0100, Uwe Kleine-K�nig wrote:
> > The function atp870u_remove is used only wrapped by __devexit_p so define
> > it using __devexit.
>
> But there's really no point to this. HOTPLUG is always defined on SCSI
> systems that have these drivers, which means that _devinit/exit are
> nops. That makes the change purely cosmetic and not worth churning two
> dozen drivers for.
>
> Even for the EMBEDDED cases that should care about this, the maintainers
> have indicated that the memory savings simply aren't worth the hassle of
> tracking the sectional updates.
do is something like
find drivers/scsi -type f -print0 | xargs perl -p -i -e 's/\b__(dev)?exit(_p)?\b//'
Then my scripts will drop the scsi related patches.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K�nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Bartlomiej Zolnierkiewicz
> On Tue, 2009-11-24 at 22:06 +0100, Uwe Kleine-König wrote:
> > The function atp870u_remove is used only wrapped by __devexit_p so define
> > it using __devexit.
>
> But there's really no point to this. HOTPLUG is always defined on SCSI
> systems that have these drivers, which means that _devinit/exit are
> nops. That makes the change purely cosmetic and not worth churning two
> dozen drivers for.
Looking at things from a bit different angle:
These tags still have some value as a documentation and help
in maintaining some level of the coherency between different
parts of a kernel (which is a Good Thing).
--
Bartlomiej Zolnierkiewicz