[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.

Without such warnings people will never update their code and fix 
the errors in PPC64 builds.

And yes, some of the drivers affected are maintained.

This also ctches accidential additions of users for these functions like 
a usage of bus_to_virt() in the infiniband code that was added in 
2.6.17-rc1 (already removed).

This patch increases the number of warnings shown during builds, but it 
seems worth including it at least in -mm for making people aware of this 
issue.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 27 Apr 2006
- 19 Apr 2006
- 6 Jan 2006
- 13 Dec 2005
- 23 Nov 2005
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Mon, Jun 26, 2006 at 05:10:12PM +0200, Adrian Bunk wrote:
 > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
 > on i386.
 > 
 > Without such warnings people will never update their code and fix 
 > the errors in PPC64 builds.

.. and deprecating pm_send_all, cli, sti, restore_flags, check_region yadayada
has really been a great success at motivating people to fix those up too.

How about we fix up some of the existing noise before we add more?
A build log of a fedora kernel I had handy shows 165 deprecated warnings
that have been there forever.  Your proposal will add over 500 warnings
in drivers/ alone.

		Dave

-- 
http://www.codemonkey.org.uk

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Arjan van de Ven]

On Mon, 2006-06-26 at 11:38 -0400, Dave Jones wrote:
> On Mon, Jun 26, 2006 at 05:10:12PM +0200, Adrian Bunk wrote:
>  > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
>  > on i386.
>  > 
>  > Without such warnings people will never update their code and fix 
>  > the errors in PPC64 builds.
> 
> .. and deprecating pm_send_all, cli, sti, restore_flags, check_region yadayada
> has really been a great success at motivating people to fix those up too.

cli/sti should just be removed, or at least have those drivers marked
BROKEN... nobody is apparently using them anyway...


Maybe depreciation needs to go together with a "will mark users broken
in X days, and will remove entirely in X+Y days".. and then stick to
it. 

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Mon, Jun 26, 2006 at 05:46:55PM +0200, Arjan van de Ven wrote:
 > On Mon, 2006-06-26 at 11:38 -0400, Dave Jones wrote:
 > > On Mon, Jun 26, 2006 at 05:10:12PM +0200, Adrian Bunk wrote:
 > >  > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
 > >  > on i386.
 > >  > 
 > >  > Without such warnings people will never update their code and fix 
 > >  > the errors in PPC64 builds.
 > > 
 > > .. and deprecating pm_send_all, cli, sti, restore_flags, check_region yadayada
 > > has really been a great success at motivating people to fix those up too.
 > 
 > cli/sti should just be removed, or at least have those drivers marked
 > BROKEN... nobody is apparently using them anyway...

Just ISDN really.

		Dave

-- 
http://www.codemonkey.org.uk

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Jan Engelhardt]

> > cli/sti should just be removed, or at least have those drivers marked
> > BROKEN... nobody is apparently using them anyway...
>
>Just ISDN really.
>
And ISDN is widespread in Germany (besides 56k and DSL(PPPOE)).


Jan Engelhardt
-- 

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Arjan van de Ven]

On Tue, 2006-06-27 at 16:27 +0200, Jan Engelhardt wrote:
> > > cli/sti should just be removed, or at least have those drivers marked
> > > BROKEN... nobody is apparently using them anyway...
> >
> >Just ISDN really.
> >
> And ISDN is widespread in Germany (besides 56k and DSL(PPPOE)).
> 

so it really should be fixed ;-)

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Alan Cox]

Ar Maw, 2006-06-27 am 16:27 +0200, ysgrifennodd Jan Engelhardt:
> > > cli/sti should just be removed, or at least have those drivers marked
> > > BROKEN... nobody is apparently using them anyway...
> >
> >Just ISDN really.
> >
> And ISDN is widespread in Germany (besides 56k and DSL(PPPOE)).

Then there should be lots of Germans eager to fix it when it gets dealt
with.

Alan

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Jan Engelhardt]

>> > > cli/sti should just be removed, or at least have those drivers marked
>> > > BROKEN... nobody is apparently using them anyway...
>> >
>> >Just ISDN really.
>> >
>> And ISDN is widespread in Germany (besides 56k and DSL(PPPOE)).
>
>Then there should be lots of Germans eager to fix it when it gets dealt
>with.
>

/* Heh, heh */

So what do I need to replace cli/sti with?

Oh btw:
(linux-2.6.17)
21:05 shanghai:../drivers/isdn > grep cli'()'  -lr .
./hardware/avm/t1isa.c
./hysdn/boardergo.c
./hysdn/hysdn_proclog.c
./hysdn/hysdn_sched.c
./isdnloop/isdnloop.c

There does not really seem to be a lot of places (yes, isdnloop is full of 
it) to change. Especially HISAX has no cli/stis anymore as it seems, 
which, among AVM stuff, is commonly in use. I am running this one:
  00:0a.0 Network controller: Tiger Jet Network Inc. Tiger3XX Modem/ISDN 
  interface (PCI, CONFIG_HISAX_NETJET)
previously I had a Teledat 100 (ISA, CONFIG_HISAX_SEDLBAUER) but had to 
replace that when I got a new motherboard with no ISA slots.


Have a nice day,
Jan Engelhardt
-- 

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Arjan van de Ven]

On Tue, 2006-06-27 at 21:09 +0200, Jan Engelhardt wrote:
> >> > > cli/sti should just be removed, or at least have those drivers marked
> >> > > BROKEN... nobody is apparently using them anyway...
> >> >
> >> >Just ISDN really.
> >> >
> >> And ISDN is widespread in Germany (besides 56k and DSL(PPPOE)).
> >
> >Then there should be lots of Germans eager to fix it when it gets dealt
> >with.
> >
> 
> /* Heh, heh */
> 
> So what do I need to replace cli/sti with?

proper spinlocks ;)

cli/sti assumed to disable interrupts on all processors, and so when an
old driver uses cli/sti it's sort of a lock against any interrupt
handler (yes this is locking code not data!). In general you need to
find out what data the author wanted to protect, and just create proper
locking for that data.  

yes this is not a mechanical transformation.. if it was it would have
been done already :)

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Mon, Jun 26, 2006 at 11:38:35AM -0400, Dave Jones wrote:
> On Mon, Jun 26, 2006 at 05:10:12PM +0200, Adrian Bunk wrote:
>  > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
>  > on i386.
>  > 
>  > Without such warnings people will never update their code and fix 
>  > the errors in PPC64 builds.
> 
> .. and deprecating pm_send_all, cli, sti, restore_flags, check_region yadayada
> has really been a great success at motivating people to fix those up too.

It has been a success, look at the numbers:

2.6.0     : 36 options depending on BROKEN_ON_SMP
2.6.17-mm2: 17 options depending on BROKEN_ON_SMP

2.6.7-mm7 : 20 drivers with warnings due to check_region
2.6.17-mm2:  3 drivers with warnings due to check_region

It's not that everything was fixed immediately, but there is definitely 
some progress.

> How about we fix up some of the existing noise before we add more?
> A build log of a fedora kernel I had handy shows 165 deprecated warnings
> that have been there forever.  Your proposal will add over 500 warnings
> in drivers/ alone.

There are few drivers generating many warnings, e.g. stallion+istallion 
alone give 138 __deprecated warnings only for cli/sti/restore_flags 
usage. Most of the code doesn't have any problems.

And my main motivation for getting virt_to_bus/bus_to_virt removed is 
the following:

If the virt_to_bus/bus_to_virt are fixed, Andrew might finally accept my 
patch to add -Werror-implicit-function-declaration to the CFLAGS (which 
he only rejected since it turned link errors into compile errors in his 
ppc64 builds). 

And -Werror-implicit-function-declaration is important since it will 
turn some nasty to debug runtime stack corruptions into compile errors.

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Mon, Jun 26, 2006 at 06:14:11PM +0200, Adrian Bunk wrote:

 > If the virt_to_bus/bus_to_virt are fixed, Andrew might finally accept my 
 > patch to add -Werror-implicit-function-declaration to the CFLAGS (which 
 > he only rejected since it turned link errors into compile errors in his 
 > ppc64 builds). 

Indeed. That was so useful in fact that I added the same to the Fedora
kernel quite some time back.  Having a build fail in the first few minutes
is much preferable to having it fail after 15 minutes.

I've not encountered any breakage due to that for some time though.
Though perhaps Andrew had config options enabled that we disabled in
our builds.

		Dave

-- 
http://www.codemonkey.org.uk

PATCH: stallion clean up: Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Alan Cox]

> There are few drivers generating many warnings, e.g. stallion+istallion 
> alone give 138 __deprecated warnings only for cli/sti/restore_flags 
> usage. Most of the code doesn't have any problems.

Stallion locking is easy to fix as far as I can tell. I've left the
wake/sleep stuff for a janitor project

Signed-off-by: Alan Cox <alan@redhat.com>

There are two locking sets involved. One locks the board mappings and the
other is the tty open/close locking. The low level code was clearly designed
to be ported to OS's with spin locks already so pretty much comes out in the
wash

--- linux.vanilla-2.6.17/drivers/char/stallion.c	2006-06-19 17:29:45.000000000 +0100
+++ linux-2.6.17/drivers/char/stallion.c	2006-06-26 21:18:04.015037064 +0100
@@ -141,15 +141,6 @@
 static struct tty_driver	*stl_serial;
 
 /*
- *	We will need to allocate a temporary write buffer for chars that
- *	come direct from user space. The problem is that a copy from user
- *	space might cause a page fault (typically on a system that is
- *	swapping!). All ports will share one buffer - since if the system
- *	is already swapping a shared buffer won't make things any worse.
- */
-static char			*stl_tmpwritebuf;
-
-/*
  *	Define a local default termios struct. All ports will be created
  *	with this termios initially. Basically all it defines is a raw port
  *	at 9600, 8 data bits, 1 stop bit.
@@ -363,6 +354,14 @@
 };
 
 /*
+ *	Lock ordering is that you may not take stallion_lock holding
+ *	brd_lock.
+ */
+ 
+static spinlock_t brd_lock; 		/* Guard the board mapping */
+static spinlock_t stallion_lock;	/* Guard the tty driver */
+
+/*
  *	Set up enable and disable macros for the ECH boards. They require
  *	the secondary io address space to be activated and deactivated.
  *	This way all ECH boards can share their secondary io region.
@@ -725,17 +724,7 @@
 
 static int __init stallion_module_init(void)
 {
-	unsigned long	flags;
-
-#ifdef DEBUG
-	printk("init_module()\n");
-#endif
-
-	save_flags(flags);
-	cli();
 	stl_init();
-	restore_flags(flags);
-
 	return 0;
 }
 
@@ -746,7 +735,6 @@
 	stlbrd_t	*brdp;
 	stlpanel_t	*panelp;
 	stlport_t	*portp;
-	unsigned long	flags;
 	int		i, j, k;
 
 #ifdef DEBUG
@@ -756,9 +744,6 @@
 	printk(KERN_INFO "Unloading %s: version %s\n", stl_drvtitle,
 		stl_drvversion);
 
-	save_flags(flags);
-	cli();
-
 /*
  *	Free up all allocated resources used by the ports. This includes
  *	memory and interrupts. As part of this process we will also do
@@ -770,7 +755,6 @@
 	if (i) {
 		printk("STALLION: failed to un-register tty driver, "
 			"errno=%d\n", -i);
-		restore_flags(flags);
 		return;
 	}
 	for (i = 0; i < 4; i++) {
@@ -783,8 +767,6 @@
 			"errno=%d\n", -i);
 	class_destroy(stallion_class);
 
-	kfree(stl_tmpwritebuf);
-
 	for (i = 0; (i < stl_nrbrds); i++) {
 		if ((brdp = stl_brds[i]) == (stlbrd_t *) NULL)
 			continue;
@@ -814,8 +796,6 @@
 		kfree(brdp);
 		stl_brds[i] = (stlbrd_t *) NULL;
 	}
-
-	restore_flags(flags);
 }
 
 module_init(stallion_module_init);
@@ -948,7 +928,7 @@
 
 	brdp = kzalloc(sizeof(stlbrd_t), GFP_KERNEL);
 	if (!brdp) {
-		printk("STALLION: failed to allocate memory (size=%d)\n",
+		printk("STALLION: failed to allocate memory (size=%Zd)\n",
 			sizeof(stlbrd_t));
 		return NULL;
 	}
@@ -1066,16 +1046,17 @@
 	rc = 0;
 	doclocal = 0;
 
+	spin_lock_irqsave(&stallion_lock, flags);
+
 	if (portp->tty->termios->c_cflag & CLOCAL)
 		doclocal++;
 
-	save_flags(flags);
-	cli();
 	portp->openwaitcnt++;
 	if (! tty_hung_up_p(filp))
 		portp->refcount--;
 
 	for (;;) {
+		/* Takes brd_lock internally */
 		stl_setsignals(portp, 1, 1);
 		if (tty_hung_up_p(filp) ||
 		    ((portp->flags & ASYNC_INITIALIZED) == 0)) {
@@ -1093,13 +1074,14 @@
 			rc = -ERESTARTSYS;
 			break;
 		}
+		/* FIXME */
 		interruptible_sleep_on(&portp->open_wait);
 	}
 
 	if (! tty_hung_up_p(filp))
 		portp->refcount++;
 	portp->openwaitcnt--;
-	restore_flags(flags);
+	spin_unlock_irqrestore(&stallion_lock, flags);
 
 	return rc;
 }
@@ -1119,16 +1101,15 @@
 	if (portp == (stlport_t *) NULL)
 		return;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&stallion_lock, flags);
 	if (tty_hung_up_p(filp)) {
-		restore_flags(flags);
+		spin_unlock_irqrestore(&stallion_lock, flags);
 		return;
 	}
 	if ((tty->count == 1) && (portp->refcount != 1))
 		portp->refcount = 1;
 	if (portp->refcount-- > 1) {
-		restore_flags(flags);
+		spin_unlock_irqrestore(&stallion_lock, flags);
 		return;
 	}
 
@@ -1142,11 +1123,18 @@
  *	(The sc26198 has no "end-of-data" interrupt only empty FIFO)
  */
 	tty->closing = 1;
+	
+	spin_unlock_irqrestore(&stallion_lock, flags);
+	
 	if (portp->closing_wait != ASYNC_CLOSING_WAIT_NONE)
 		tty_wait_until_sent(tty, portp->closing_wait);
 	stl_waituntilsent(tty, (HZ / 2));
 
+
+	spin_lock_irqsave(&stallion_lock, flags);
 	portp->flags &= ~ASYNC_INITIALIZED;
+	spin_unlock_irqrestore(&stallion_lock, flags);
+	
 	stl_disableintrs(portp);
 	if (tty->termios->c_cflag & HUPCL)
 		stl_setsignals(portp, 0, 0);
@@ -1173,7 +1161,6 @@
 
 	portp->flags &= ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING);
 	wake_up_interruptible(&portp->close_wait);
-	restore_flags(flags);
 }
 
 /*****************************************************************************/
@@ -1195,9 +1182,6 @@
 		(int) tty, (int) buf, count);
 #endif
 
-	if ((tty == (struct tty_struct *) NULL) ||
-	    (stl_tmpwritebuf == (char *) NULL))
-		return 0;
 	portp = tty->driver_data;
 	if (portp == (stlport_t *) NULL)
 		return 0;
@@ -1302,11 +1286,6 @@
 	if (portp->tx.buf == (char *) NULL)
 		return;
 
-#if 0
-	if (tty->stopped || tty->hw_stopped ||
-	    (portp->tx.head == portp->tx.tail))
-		return;
-#endif
 	stl_startrxtx(portp, -1, 1);
 }
 
@@ -1977,12 +1956,14 @@
 	unsigned int	iobase;
 	int		handled = 0;
 
+	spin_lock(&brd_lock);
 	panelp = brdp->panels[0];
 	iobase = panelp->iobase;
 	while (inb(brdp->iostatus) & EIO_INTRPEND) {
 		handled = 1;
 		(* panelp->isr)(panelp, iobase);
 	}
+	spin_unlock(&brd_lock);
 	return handled;
 }
 
@@ -2168,7 +2149,7 @@
 		portp = kzalloc(sizeof(stlport_t), GFP_KERNEL);
 		if (!portp) {
 			printk("STALLION: failed to allocate memory "
-				"(size=%d)\n", sizeof(stlport_t));
+				"(size=%Zd)\n", sizeof(stlport_t));
 			break;
 		}
 
@@ -2304,7 +2285,7 @@
 	panelp = kzalloc(sizeof(stlpanel_t), GFP_KERNEL);
 	if (!panelp) {
 		printk(KERN_WARNING "STALLION: failed to allocate memory "
-			"(size=%d)\n", sizeof(stlpanel_t));
+			"(size=%Zd)\n", sizeof(stlpanel_t));
 		return -ENOMEM;
 	}
 
@@ -2478,7 +2459,7 @@
 		panelp = kzalloc(sizeof(stlpanel_t), GFP_KERNEL);
 		if (!panelp) {
 			printk("STALLION: failed to allocate memory "
-				"(size=%d)\n", sizeof(stlpanel_t));
+				"(size=%Zd)\n", sizeof(stlpanel_t));
 			break;
 		}
 		panelp->magic = STL_PANELMAGIC;
@@ -2879,8 +2860,7 @@
 	portp->stats.lflags = 0;
 	portp->stats.rxbuffered = 0;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&stallion_lock, flags);
 	if (portp->tty != (struct tty_struct *) NULL) {
 		if (portp->tty->driver_data == portp) {
 			portp->stats.ttystate = portp->tty->flags;
@@ -2894,7 +2874,7 @@
 			}
 		}
 	}
-	restore_flags(flags);
+	spin_unlock_irqrestore(&stallion_lock, flags);
 
 	head = portp->tx.head;
 	tail = portp->tx.tail;
@@ -3056,14 +3036,6 @@
 		return -1;
 
 /*
- *	Allocate a temporary write buffer.
- */
-	stl_tmpwritebuf = kmalloc(STL_TXBUFSIZE, GFP_KERNEL);
-	if (!stl_tmpwritebuf)
-		printk("STALLION: failed to allocate memory (size=%d)\n",
-			STL_TXBUFSIZE);
-
-/*
  *	Set up a character driver for per board stuff. This is mainly used
  *	to do stats ioctls on the ports.
  */
@@ -3147,11 +3119,13 @@
 	unsigned int	gfrcr;
 	int		chipmask, i, j;
 	int		nrchips, uartaddr, ioaddr;
+	unsigned long   flags;
 
 #ifdef DEBUG
 	printk("stl_panelinit(brdp=%x,panelp=%x)\n", (int) brdp, (int) panelp);
 #endif
 
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(panelp->brdnr, panelp->pagenr);
 
 /*
@@ -3189,6 +3163,7 @@
 	}
 
 	BRDDISABLE(panelp->brdnr);
+	spin_unlock_irqrestore(&brd_lock, flags);
 	return chipmask;
 }
 
@@ -3200,6 +3175,7 @@
 
 static void stl_cd1400portinit(stlbrd_t *brdp, stlpanel_t *panelp, stlport_t *portp)
 {
+	unsigned long flags;
 #ifdef DEBUG
 	printk("stl_cd1400portinit(brdp=%x,panelp=%x,portp=%x)\n",
 		(int) brdp, (int) panelp, (int) portp);
@@ -3209,6 +3185,7 @@
 	    (portp == (stlport_t *) NULL))
 		return;
 
+	spin_lock_irqsave(&brd_lock, flags);
 	portp->ioaddr = panelp->iobase + (((brdp->brdtype == BRD_ECHPCI) ||
 		(portp->portnr < 8)) ? 0 : EREG_BANKSIZE);
 	portp->uartaddr = (portp->portnr & 0x04) << 5;
@@ -3219,6 +3196,7 @@
 	stl_cd1400setreg(portp, LIVR, (portp->portnr << 3));
 	portp->hwid = stl_cd1400getreg(portp, GFRCR);
 	BRDDISABLE(portp->brdnr);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3428,8 +3406,7 @@
 		tiosp->c_cc[VSTART], tiosp->c_cc[VSTOP]);
 #endif
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x3));
 	srer = stl_cd1400getreg(portp, SRER);
@@ -3466,7 +3443,7 @@
 		portp->sigs &= ~TIOCM_CD;
 	stl_cd1400setreg(portp, SRER, ((srer & ~sreroff) | sreron));
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3492,8 +3469,7 @@
 	if (rts > 0)
 		msvr2 = MSVR2_RTS;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	if (rts >= 0)
@@ -3501,7 +3477,7 @@
 	if (dtr >= 0)
 		stl_cd1400setreg(portp, MSVR1, msvr1);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3520,14 +3496,13 @@
 	printk("stl_cd1400getsignals(portp=%x)\n", (int) portp);
 #endif
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	msvr1 = stl_cd1400getreg(portp, MSVR1);
 	msvr2 = stl_cd1400getreg(portp, MSVR2);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 
 	sigs = 0;
 	sigs |= (msvr1 & MSVR1_DCD) ? TIOCM_CD : 0;
@@ -3569,15 +3544,14 @@
 	else if (rx > 0)
 		ccr |= CCR_RXENABLE;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	stl_cd1400ccrwait(portp);
 	stl_cd1400setreg(portp, CCR, ccr);
 	stl_cd1400ccrwait(portp);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3609,8 +3583,7 @@
 	else if (rx > 0)
 		sreron |= SRER_RXDATA;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	stl_cd1400setreg(portp, SRER,
@@ -3618,7 +3591,7 @@
 	BRDDISABLE(portp->brdnr);
 	if (tx > 0)
 		set_bit(ASYI_TXBUSY, &portp->istate);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3634,13 +3607,12 @@
 #ifdef DEBUG
 	printk("stl_cd1400disableintrs(portp=%x)\n", (int) portp);
 #endif
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	stl_cd1400setreg(portp, SRER, 0);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3653,8 +3625,7 @@
 	printk("stl_cd1400sendbreak(portp=%x,len=%d)\n", (int) portp, len);
 #endif
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	stl_cd1400setreg(portp, SRER,
@@ -3664,7 +3635,7 @@
 	portp->brklen = len;
 	if (len == 1)
 		portp->stats.txbreaks++;
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3688,8 +3659,7 @@
 	if (tty == (struct tty_struct *) NULL)
 		return;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 
@@ -3729,7 +3699,7 @@
 	}
 
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3753,8 +3723,7 @@
 	if (tty == (struct tty_struct *) NULL)
 		return;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	if (state) {
@@ -3769,7 +3738,7 @@
 		stl_cd1400ccrwait(portp);
 	}
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3785,8 +3754,7 @@
 	if (portp == (stlport_t *) NULL)
 		return;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_cd1400setreg(portp, CAR, (portp->portnr & 0x03));
 	stl_cd1400ccrwait(portp);
@@ -3794,7 +3762,7 @@
 	stl_cd1400ccrwait(portp);
 	portp->tx.tail = portp->tx.head;
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -3833,6 +3801,7 @@
 		(int) panelp, iobase);
 #endif
 
+	spin_lock(&brd_lock);
 	outb(SVRR, iobase);
 	svrtype = inb(iobase + EREG_DATA);
 	if (panelp->nrports > 4) {
@@ -3846,6 +3815,8 @@
 		stl_cd1400txisr(panelp, iobase);
 	else if (svrtype & SVRR_MDM)
 		stl_cd1400mdmisr(panelp, iobase);
+		
+	spin_unlock(&brd_lock);
 }
 
 /*****************************************************************************/
@@ -4433,8 +4404,7 @@
 		tiosp->c_cc[VSTART], tiosp->c_cc[VSTOP]);
 #endif
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_sc26198setreg(portp, IMR, 0);
 	stl_sc26198updatereg(portp, MR0, mr0);
@@ -4461,7 +4431,7 @@
 	portp->imr = (portp->imr & ~imroff) | imron;
 	stl_sc26198setreg(portp, IMR, portp->imr);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4491,13 +4461,12 @@
 	else if (rts > 0)
 		iopioron |= IPR_RTS;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_sc26198setreg(portp, IOPIOR,
 		((stl_sc26198getreg(portp, IOPIOR) & ~iopioroff) | iopioron));
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4516,12 +4485,11 @@
 	printk("stl_sc26198getsignals(portp=%x)\n", (int) portp);
 #endif
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	ipr = stl_sc26198getreg(portp, IPR);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 
 	sigs = 0;
 	sigs |= (ipr & IPR_DCD) ? 0 : TIOCM_CD;
@@ -4558,13 +4526,12 @@
 	else if (rx > 0)
 		ccr |= CR_RXENABLE;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_sc26198setreg(portp, SCCR, ccr);
 	BRDDISABLE(portp->brdnr);
 	portp->crenable = ccr;
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4593,15 +4560,14 @@
 	else if (rx > 0)
 		imr |= IR_RXRDY | IR_RXBREAK | IR_RXWATCHDOG;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_sc26198setreg(portp, IMR, imr);
 	BRDDISABLE(portp->brdnr);
 	portp->imr = imr;
 	if (tx > 0)
 		set_bit(ASYI_TXBUSY, &portp->istate);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4618,13 +4584,12 @@
 	printk("stl_sc26198disableintrs(portp=%x)\n", (int) portp);
 #endif
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	portp->imr = 0;
 	stl_sc26198setreg(portp, IMR, 0);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4637,8 +4602,7 @@
 	printk("stl_sc26198sendbreak(portp=%x,len=%d)\n", (int) portp, len);
 #endif
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	if (len == 1) {
 		stl_sc26198setreg(portp, SCCR, CR_TXSTARTBREAK);
@@ -4647,7 +4611,7 @@
 		stl_sc26198setreg(portp, SCCR, CR_TXSTOPBREAK);
 	}
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4672,8 +4636,7 @@
 	if (tty == (struct tty_struct *) NULL)
 		return;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 
 	if (state) {
@@ -4719,7 +4682,7 @@
 	}
 
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4744,8 +4707,7 @@
 	if (tty == (struct tty_struct *) NULL)
 		return;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	if (state) {
 		mr0 = stl_sc26198getreg(portp, MR0);
@@ -4765,7 +4727,7 @@
 		stl_sc26198setreg(portp, MR0, mr0);
 	}
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4781,14 +4743,13 @@
 	if (portp == (stlport_t *) NULL)
 		return;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	stl_sc26198setreg(portp, SCCR, CR_TXRESET);
 	stl_sc26198setreg(portp, SCCR, portp->crenable);
 	BRDDISABLE(portp->brdnr);
 	portp->tx.tail = portp->tx.head;
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 }
 
 /*****************************************************************************/
@@ -4815,12 +4776,11 @@
 	if (test_bit(ASYI_TXBUSY, &portp->istate))
 		return 1;
 
-	save_flags(flags);
-	cli();
+	spin_lock_irqsave(&brd_lock, flags);
 	BRDENABLE(portp->brdnr, portp->pagenr);
 	sr = stl_sc26198getreg(portp, SR);
 	BRDDISABLE(portp->brdnr);
-	restore_flags(flags);
+	spin_unlock_irqrestore(&brd_lock, flags);
 
 	return (sr & SR_TXEMPTY) ? 0 : 1;
 }
@@ -4877,6 +4837,8 @@
 {
 	stlport_t	*portp;
 	unsigned int	iack;
+	
+	spin_lock(&brd_lock);
 
 /* 
  *	Work around bug in sc26198 chip... Cannot have A6 address
@@ -4893,6 +4855,8 @@
 		stl_sc26198txisr(portp);
 	else
 		stl_sc26198otherisr(portp, iack);
+		
+	spin_unlock(&brd_lock);
 }
 
 /*****************************************************************************/

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Alan Cox]

Ar Llu, 2006-06-26 am 17:10 +0200, ysgrifennodd Adrian Bunk:
> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> on i386.
> 
> Without such warnings people will never update their code and fix 
> the errors in PPC64 builds.

Most of the uses of virt_to_bus/bus_to_virt are hardware that isn't even
available on obscure platforms like PPC64. Would still be good to get
these in and nailed.

Undefined '.bus_to_virt', '.virt_to_bus' causes compile error on Powerpc 64-bit

[Judith Lebzelter]

Hello:

For the automated cross-compile builds at OSDL, powerpc 64-bit 
'allmodconfig' is failing.  The warnings/errors below appear in 
the 'modpost' stage of kernel compiles for 2.6.18 and -mm2 kernels.

Thanks;
Judith Lebzelter
OSDL

-----------

  Building modules, stage 2.
  MODPOST 1658 modules
WARNING: Can't handle masks in drivers/ata/ahci:FFFF05
WARNING: ".virt_to_bus" [sound/oss/sscape.ko] undefined!
WARNING: ".virt_to_bus" [sound/oss/sound.ko] undefined!
WARNING: ".bus_to_virt" [sound/oss/cs46xx.ko] undefined!
WARNING: ".virt_to_bus" [sound/oss/cs46xx.ko] undefined!
WARNING: ".bus_to_virt" [drivers/scsi/tmscsim.ko] undefined!
WARNING: ".bus_to_virt" [drivers/scsi/BusLogic.ko] undefined!
WARNING: ".virt_to_bus" [drivers/net/wan/lmc/lmc.ko] undefined!
WARNING: ".virt_to_bus" [drivers/message/i2o/i2o_config.ko] undefined!
WARNING: ".bus_to_virt" [drivers/block/cpqarray.ko] undefined!
WARNING: ".bus_to_virt" [drivers/atm/zatm.ko] undefined!
WARNING: ".virt_to_bus" [drivers/atm/zatm.ko] undefined!
WARNING: ".bus_to_virt" [drivers/atm/horizon.ko] undefined!
WARNING: ".virt_to_bus" [drivers/atm/firestream.ko] undefined!
WARNING: ".bus_to_virt" [drivers/atm/firestream.ko] undefined!
WARNING: ".bus_to_virt" [drivers/atm/ambassador.ko] undefined!
WARNING: ".virt_to_bus" [drivers/atm/ambassador.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Re: Undefined '.bus_to_virt', '.virt_to_bus' causes compile error on Powerpc 64-bit

[Adrian Bunk]

On Mon, Oct 02, 2006 at 02:49:54PM -0700, Judith Lebzelter wrote:

> Hello:

Hi Judith,

> For the automated cross-compile builds at OSDL, powerpc 64-bit 
> 'allmodconfig' is failing.  The warnings/errors below appear in 
> the 'modpost' stage of kernel compiles for 2.6.18 and -mm2 kernels.

known for ages - the drivers need fixing.

You might want to convince Andrew accepting my patch to make 
virt_to_bus/bus_to_virt give compile warnings on i386 for making
people more aware of this problem...

> Thanks;
> Judith Lebzelter
> OSDL
> 
> -----------
> 
>   Building modules, stage 2.
>   MODPOST 1658 modules
> WARNING: Can't handle masks in drivers/ata/ahci:FFFF05
> WARNING: ".virt_to_bus" [sound/oss/sscape.ko] undefined!
> WARNING: ".virt_to_bus" [sound/oss/sound.ko] undefined!
> WARNING: ".bus_to_virt" [sound/oss/cs46xx.ko] undefined!
> WARNING: ".virt_to_bus" [sound/oss/cs46xx.ko] undefined!
> WARNING: ".bus_to_virt" [drivers/scsi/tmscsim.ko] undefined!
> WARNING: ".bus_to_virt" [drivers/scsi/BusLogic.ko] undefined!
> WARNING: ".virt_to_bus" [drivers/net/wan/lmc/lmc.ko] undefined!
> WARNING: ".virt_to_bus" [drivers/message/i2o/i2o_config.ko] undefined!
> WARNING: ".bus_to_virt" [drivers/block/cpqarray.ko] undefined!
> WARNING: ".bus_to_virt" [drivers/atm/zatm.ko] undefined!
> WARNING: ".virt_to_bus" [drivers/atm/zatm.ko] undefined!
> WARNING: ".bus_to_virt" [drivers/atm/horizon.ko] undefined!
> WARNING: ".virt_to_bus" [drivers/atm/firestream.ko] undefined!
> WARNING: ".bus_to_virt" [drivers/atm/firestream.ko] undefined!
> WARNING: ".bus_to_virt" [drivers/atm/ambassador.ko] undefined!
> WARNING: ".virt_to_bus" [drivers/atm/ambassador.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Tue, Oct 03, 2006 at 01:44:28AM +0200, Adrian Bunk wrote:
> On Mon, Oct 02, 2006 at 02:49:54PM -0700, Judith Lebzelter wrote:
> 
> > Hello:
> 
> Hi Judith,
> 
> > For the automated cross-compile builds at OSDL, powerpc 64-bit 
> > 'allmodconfig' is failing.  The warnings/errors below appear in 
> > the 'modpost' stage of kernel compiles for 2.6.18 and -mm2 kernels.
> 
> known for ages - the drivers need fixing.
> 
> You might want to convince Andrew accepting my patch to make 
> virt_to_bus/bus_to_virt give compile warnings on i386 for making
> people more aware of this problem...
>...

In case anyone is interested, the patch is below.

cu
Adrian


<--  snip  -->


virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.

Without such warnings people will never update their code and fix 
the errors in PPC64 builds.

And yes, some of the drivers affected are maintained.

This also catches accidential additions of users for these functions 
like a usage of bus_to_virt() in the infiniband code that was added in 
2.6.17-rc1 (already removed).

This patch increases the number of warnings shown during builds, but it 
seems worth including it at least in -mm for making people aware of this 
issue.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 7 Jul 2006
- 26 Jun 2006
- 27 Apr 2006
- 19 Apr 2006
- 6 Jan 2006
- 13 Dec 2005
- 23 Nov 2005
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Nicholas Miell]

On Tue, 2006-10-03 at 03:22 +0200, Adrian Bunk wrote:
> On Tue, Oct 03, 2006 at 01:44:28AM +0200, Adrian Bunk wrote:
> > On Mon, Oct 02, 2006 at 02:49:54PM -0700, Judith Lebzelter wrote:
> > 
> > > Hello:
> > 
> > Hi Judith,
> > 
> > > For the automated cross-compile builds at OSDL, powerpc 64-bit 
> > > 'allmodconfig' is failing.  The warnings/errors below appear in 
> > > the 'modpost' stage of kernel compiles for 2.6.18 and -mm2 kernels.
> > 
> > known for ages - the drivers need fixing.
> > 
> > You might want to convince Andrew accepting my patch to make 
> > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > people more aware of this problem...
> >...
> 
> In case anyone is interested, the patch is below.
> 
> cu
> Adrian
> 

Won't this also cause warnings for valid arch-specific usage (i.e. in
linux/arch/{i386,x86_64})?

-- 
Nicholas Miell <nmiell@comcast.net>

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Mon, Oct 02, 2006 at 06:48:11PM -0700, Nicholas Miell wrote:
> On Tue, 2006-10-03 at 03:22 +0200, Adrian Bunk wrote:
> > On Tue, Oct 03, 2006 at 01:44:28AM +0200, Adrian Bunk wrote:
> > > On Mon, Oct 02, 2006 at 02:49:54PM -0700, Judith Lebzelter wrote:
> > > 
> > > > Hello:
> > > 
> > > Hi Judith,
> > > 
> > > > For the automated cross-compile builds at OSDL, powerpc 64-bit 
> > > > 'allmodconfig' is failing.  The warnings/errors below appear in 
> > > > the 'modpost' stage of kernel compiles for 2.6.18 and -mm2 kernels.
> > > 
> > > known for ages - the drivers need fixing.
> > > 
> > > You might want to convince Andrew accepting my patch to make 
> > > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > > people more aware of this problem...
> > >...
> > 
> > In case anyone is interested, the patch is below.
> > 
> > cu
> > Adrian
> > 
> 
> Won't this also cause warnings for valid arch-specific usage (i.e. in
> linux/arch/{i386,x86_64})?

They aren't used under linux/arch/i386/ and my patch doesn't change x86_64.

> Nicholas Miell <nmiell@comcast.net>

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Nicholas Miell]

On Tue, 2006-10-03 at 03:58 +0200, Adrian Bunk wrote:
> On Mon, Oct 02, 2006 at 06:48:11PM -0700, Nicholas Miell wrote:
> > On Tue, 2006-10-03 at 03:22 +0200, Adrian Bunk wrote:
> > > On Tue, Oct 03, 2006 at 01:44:28AM +0200, Adrian Bunk wrote:
> > > > On Mon, Oct 02, 2006 at 02:49:54PM -0700, Judith Lebzelter wrote:
> > > > 
> > > > > Hello:
> > > > 
> > > > Hi Judith,
> > > > 
> > > > > For the automated cross-compile builds at OSDL, powerpc 64-bit 
> > > > > 'allmodconfig' is failing.  The warnings/errors below appear in 
> > > > > the 'modpost' stage of kernel compiles for 2.6.18 and -mm2 kernels.
> > > > 
> > > > known for ages - the drivers need fixing.
> > > > 
> > > > You might want to convince Andrew accepting my patch to make 
> > > > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > > > people more aware of this problem...
> > > >...
> > > 
> > > In case anyone is interested, the patch is below.
> > > 
> > > cu
> > > Adrian
> > > 
> > 
> > Won't this also cause warnings for valid arch-specific usage (i.e. in
> > linux/arch/{i386,x86_64})?
> 
> They aren't used under linux/arch/i386/ and my patch doesn't change x86_64.

Sorry, for some reason I thought isa_bus_to_virt and isa_virt_to_bus
were defined in terms of virt_to_bus/bus_to_virt instead of
virt_to_phys/phys_to_virt.


-- 
Nicholas Miell <nmiell@comcast.net>

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Benjamin Herrenschmidt]

> Won't this also cause warnings for valid arch-specific usage (i.e. in
> linux/arch/{i386,x86_64})?

I wouldn't cause that usage valid :)

Ben.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Alan Cox]

Ar Maw, 2006-10-03 am 14:37 +1000, ysgrifennodd Benjamin Herrenschmidt:
> > Won't this also cause warnings for valid arch-specific usage (i.e. in
> > linux/arch/{i386,x86_64})?
> 
> I wouldn't cause that usage valid :)

Actually a lot of the older legitimate users (DRM/AGP) have been cleaned
up so it might be worth doing now after all.

Ok I take back the NAK having looked deeper. We appear to have made
sufficient progress along the way.

Acked-by: Alan Cox <alan@redhat.com>

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Benjamin Herrenschmidt]

> > You might want to convince Andrew accepting my patch to make 
> > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > people more aware of this problem...
> >...

Andrew, is there any reason not to take that patch ?

> <--  snip  -->
> 
> 
> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> on i386.
> 
> Without such warnings people will never update their code and fix 
> the errors in PPC64 builds.
> 
> And yes, some of the drivers affected are maintained.
> 
> This also catches accidential additions of users for these functions 
> like a usage of bus_to_virt() in the infiniband code that was added in 
> 2.6.17-rc1 (already removed).
> 
> This patch increases the number of warnings shown during builds, but it 
> seems worth including it at least in -mm for making people aware of this 
> issue.
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> ---
> 
> This patch was already sent on:
> - 7 Jul 2006
> - 26 Jun 2006
> - 27 Apr 2006
> - 19 Apr 2006
> - 6 Jan 2006
> - 13 Dec 2005
> - 23 Nov 2005
> - 18 Nov 2005
> - 12 Nov 2005
> 
> --- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
> +++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
> @@ -144,8 +144,14 @@
>   *
>   * Allow them on x86 for legacy drivers, though.
>   */
> -#define virt_to_bus virt_to_phys
> -#define bus_to_virt phys_to_virt
> +static inline unsigned long __deprecated virt_to_bus(volatile void * address)
> +{
> +	return __pa(address);
> +}
> +static inline void * __deprecated bus_to_virt(unsigned long address)
> +{
> +	return __va(address);
> +}
>  
>  /*
>   * readX/writeX() are used to access memory mapped devices. On some
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

On Tue, 03 Oct 2006 14:37:25 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> > > You might want to convince Andrew accepting my patch to make 
> > > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > > people more aware of this problem...
> > >...
> 
> Andrew, is there any reason not to take that patch ?

It generates lots of warnings from drivers which nobody does any work on.

Net result: lots of new warnings, no fixed bugs.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Benjamin Herrenschmidt]

On Mon, 2006-10-02 at 21:44 -0700, Andrew Morton wrote:
> On Tue, 03 Oct 2006 14:37:25 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > > > You might want to convince Andrew accepting my patch to make 
> > > > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > > > people more aware of this problem...
> > > >...
> > 
> > Andrew, is there any reason not to take that patch ?
> 
> It generates lots of warnings from drivers which nobody does any work on.
> 
> Net result: lots of new warnings, no fixed bugs.

Are you sure the warnings won't cause somebody like Al to go through
them all and fix them ?

At least they should be marked either CONFIG_BROKEN or X86 only (or
whatever arch they are supposed to be used on).

Ben.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

On Tue, 03 Oct 2006 14:49:39 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Mon, 2006-10-02 at 21:44 -0700, Andrew Morton wrote:
> > On Tue, 03 Oct 2006 14:37:25 +1000
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > > > > You might want to convince Andrew accepting my patch to make 
> > > > > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > > > > people more aware of this problem...
> > > > >...
> > > 
> > > Andrew, is there any reason not to take that patch ?
> > 
> > It generates lots of warnings from drivers which nobody does any work on.
> > 
> > Net result: lots of new warnings, no fixed bugs.
> 
> Are you sure the warnings won't cause somebody like Al to go through
> them all and fix them ?

The drivers simply don't link on some architectures, due to missing
virt_to_bus/bus_to_virt.    They aren't hard to find.

> At least they should be marked either CONFIG_BROKEN or X86 only (or
> whatever arch they are supposed to be used on).
> 

Something like that would make sense.  I guess a new config option.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Mon, Oct 02, 2006 at 09:55:27PM -0700, Andrew Morton wrote:
> On Tue, 03 Oct 2006 14:49:39 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Mon, 2006-10-02 at 21:44 -0700, Andrew Morton wrote:
> > > On Tue, 03 Oct 2006 14:37:25 +1000
> > > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > 
> > > > > > You might want to convince Andrew accepting my patch to make 
> > > > > > virt_to_bus/bus_to_virt give compile warnings on i386 for making
> > > > > > people more aware of this problem...
> > > > > >...
> > > > 
> > > > Andrew, is there any reason not to take that patch ?
> > > 
> > > It generates lots of warnings from drivers which nobody does any work on.
> > > 
> > > Net result: lots of new warnings, no fixed bugs.
> > 
> > Are you sure the warnings won't cause somebody like Al to go through
> > them all and fix them ?
> 
> The drivers simply don't link on some architectures, due to missing
> virt_to_bus/bus_to_virt.    They aren't hard to find.
>...

As my patch description says, there had even been one bus_to_virt() 
accidentally added in 2.6.17-rc1.

Shouldn't people become aware of it as early and as often as possible?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Stefan Richter]

Benjamin Herrenschmidt wrote:
> On Mon, 2006-10-02 at 21:44 -0700, Andrew Morton wrote:
>> Net result: lots of new warnings, no fixed bugs.
> 
> Are you sure the warnings won't cause somebody like Al to go through
> them all and fix them ?

If you mean by "fix" to actually convert to generic DMA mapping, then
this task may turn out to require in-depth knowledge of the driver and
its field of application in some or many of these cases.
-- 
Stefan Richter
-=====-=-==- =-=- ---==
http://arcgraph.de/sr/

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Alan Cox]

Ar Maw, 2006-10-03 am 03:22 +0200, ysgrifennodd Adrian Bunk:
> This patch was already sent on:
> - 7 Jul 2006
> - 26 Jun 2006
> - 27 Apr 2006
> - 19 Apr 2006
> - 6 Jan 2006
> - 13 Dec 2005
> - 23 Nov 2005
> - 18 Nov 2005
> - 12 Nov 2005

This patch was already NAKed on
...

These functions are used internally in the x86 core code correctly and
validly. It's just as easy to find the offenders with grep or building a
PPC tree.

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.

Without such warnings people will never update their code and fix 
the errors in PPC64 builds.

And yes, some of the drivers affected are maintained.

This also catches accidential additions of users for these functions 
like a usage of bus_to_virt() in the infiniband code that was added in 
2.6.17-rc1 (already removed).

This patch increases the number of warnings shown during builds, but it 
seems worth including it at least in -mm for making people aware of this 
issue.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 26 Jun 2006
- 27 Apr 2006
- 19 Apr 2006
- 6 Jan 2006
- 13 Dec 2005
- 23 Nov 2005
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.

Without such warnings people will never update their code and fix 
the errors in PPC64 builds.

And yes, some of the drivers affected are maintained.

As an example, the only usage of bus_to_virt() in the infiniband code 
was added in 2.6.17-rc1 (sic). 

This patch increases the number of warnings shown during builds, but it 
seems worth including it at least in -mm for making people aware of this 
issue.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 19 Apr 2006
- 6 Jan 2006
- 13 Dec 2005
- 23 Nov 2005
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Olson]

On Tue, 18 Apr 2006, Roland Dreier wrote:

|     Adrian> As an example, the only usage of bus_to_virt() in the
|     Adrian> infiniband code was added in 2.6.17-rc1 (sic).
| 
| Ugh, the pathscale guys snuck that one past me in the ipath merge.
| I'll see what I can do about it...

Already fixed in our current code, with patches headed off to you
(Roland) very soon now...

Dave Olson
olson@pathscale.com
olson@unixfolk.com
http://www.unixfolk.com/dave

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.

Without such warnings people will never update their code and fix 
Andrew's all*config PPC64 builds.

And yes, some of the drivers affected are maintained.

As an example, the only usage of bus_to_virt() in the infiniband code 
was added in 2.6.17-rc1 (sic). 

This patch increases the number of warnings shown during builds, but it 
seems worth including it at least in -mm for making people aware of this 
issue.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 6 Jan 2006
- 13 Dec 2005
- 23 Nov 2005
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Roland Dreier]

    Adrian> As an example, the only usage of bus_to_virt() in the
    Adrian> infiniband code was added in 2.6.17-rc1 (sic).

Ugh, the pathscale guys snuck that one past me in the ipath merge.
I'll see what I can do about it...

 - R.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Wed, Apr 19, 2006 at 08:13:55AM +0300, Muli Ben-Yehuda wrote:
> On Wed, Apr 19, 2006 at 12:07:15AM +0200, Adrian Bunk wrote:
> > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> > on i386.
> 
> You should probably update Documentation/ while you're at it.

Which file under Documentation/ are you referring to?

> Also, IIRC Xen uses virt_to_phys to return guest physical addresses
> and virt_to_bus to return machine physical addresses, so the
> difference is useful at least in some scenarios.

Solving this should be easy.

And this still doesn't make it right for architecture independent 
drivers to use virt_to_bus/bus_to_virt.

> Cheers,
> Muli

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[linux-os (Dick Johnson)]

On Wed, 19 Apr 2006, Adrian Bunk wrote:

> On Wed, Apr 19, 2006 at 08:13:55AM +0300, Muli Ben-Yehuda wrote:
>> On Wed, Apr 19, 2006 at 12:07:15AM +0200, Adrian Bunk wrote:
>>> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated
>>> on i386.
>>
>> You should probably update Documentation/ while you're at it.
>
> Which file under Documentation/ are you referring to?
>
>> Also, IIRC Xen uses virt_to_phys to return guest physical addresses
>> and virt_to_bus to return machine physical addresses, so the
>> difference is useful at least in some scenarios.
>
> Solving this should be easy.
>
> And this still doesn't make it right for architecture independent
> drivers to use virt_to_bus/bus_to_virt.

Then what would you use to return the proper bus address to put
into a DMA scatter list and, conversely, how would you convert
those bus addresses into something a virtual mode CPU could
access?  These macros used to be the link that made such driver
coding architecture independent. You cannot just claim that
one can't make such conversions anymore. The CPU uses virtual
addresses and the DMA uses physical (bus) addresses. Do we
throw away DMA altogether?

>
>> Cheers,
>> Muli
>
> cu
> Adrian
>
> --
>
>       "Is there not promise of rain?" Ling Tan asked suddenly out
>        of the darkness. There had been need of rain for many days.
>       "Only a promise," Lao Er said.
>                                       Pearl S. Buck - Dragon Seed
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.53 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Arjan van de Ven]

On Wed, 2006-04-19 at 14:21 -0400, linux-os (Dick Johnson) wrote:
> On Wed, 19 Apr 2006, Adrian Bunk wrote:
> 
> > On Wed, Apr 19, 2006 at 08:13:55AM +0300, Muli Ben-Yehuda wrote:
> >> On Wed, Apr 19, 2006 at 12:07:15AM +0200, Adrian Bunk wrote:
> >>> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated
> >>> on i386.
> >>
> >> You should probably update Documentation/ while you're at it.
> >
> > Which file under Documentation/ are you referring to?
> >
> >> Also, IIRC Xen uses virt_to_phys to return guest physical addresses
> >> and virt_to_bus to return machine physical addresses, so the
> >> difference is useful at least in some scenarios.
> >
> > Solving this should be easy.
> >
> > And this still doesn't make it right for architecture independent
> > drivers to use virt_to_bus/bus_to_virt.
> 
> Then what would you use to return the proper bus address to put
> into a DMA scatter list and, conversely, how would you convert
> those bus addresses into something a virtual mode CPU could
> access?  These macros used to be the link that made such driver
> coding architecture independent. You cannot just claim that
> one can't make such conversions anymore. The CPU uses virtual
> addresses and the DMA uses physical (bus) addresses. Do we
> throw away DMA altogether?

since a long time the kernel has proper dma mapping API's for this, in
2.4 it's pci specific in 2.6 it's generic and bus agnostic.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Wed, Apr 19, 2006 at 09:49:58PM +0300, Muli Ben-Yehuda wrote:
> On Wed, Apr 19, 2006 at 08:07:24PM +0200, Adrian Bunk wrote:
> 
> > Which file under Documentation/ are you referring to?
> 
> virt_to_bus() and bus_to_virt() appear in several files, in particular
> DMA-mapping.txt and IO-mapping.txt.

DMA-mapping.txt exlicitely states it's planned with 
virt_to_bus/bus_to_virt, and IO-mapping.txt starts with:

<--  snip  -->

[ NOTE: The virt_to_bus() and bus_to_virt() functions have been
        superseded by the functionality provided by the PCI DMA
        interface (see Documentation/DMA-mapping.txt).  They continue
        to be documented below for historical purposes, but new code
        must not use them. --davidm 00/12/12 ]

<--  snip  -->

Patches to update Documentation/ are always welcome, but these two files 
already explicitely mention virt_to_bus/bus_to_virt, as deprecated, so I 
still don't see any urgent action required.

> Cheers,
> Muli

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.

Without such warnings people will never update their code and fix 
Andrew's all*config ppc64 builds.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 13 Dec 2005
- 23 Nov 2005
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
>  on i386.

This spews screenfuls of crap at me.  Crap which nobody is going to fix.

Sorry, nope.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Sat, Jan 07, 2006 at 01:51:43AM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> >  on i386.
> 
> This spews screenfuls of crap at me.  Crap which nobody is going to fix.
> 
> Sorry, nope.

This is the usual chicken and egg problem:

Without a warning noone will fix the code.

And yes, some of the drivers affected seem to be maintained (and 
49 warnings come from OSS drivers with ALSA replacements another patch 
I sent removes from the kernel).

They might not show up in your all*config builds that set SMP=y, but the 
warnings with my patch aren't worse than the one's BROKEN_ON_SMP drivers 
are spitting.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.

Without such warnings people will never update their code and fix 
Andrew's all*config ppc64 builds.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 23 Nov 2005
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 18 Nov 2005
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> on i386.
> 

Problem is, nobody's fixing these things.  There's no point in adding spam
to the kernel build unless it actually gets us some action, and I haven't
seen any evidence that it does.

Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Thu, Nov 17, 2005 at 05:50:15PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> > on i386.
> > 
> 
> Problem is, nobody's fixing these things.  There's no point in adding spam
> to the kernel build unless it actually gets us some action, and I haven't
> seen any evidence that it does.
> 
> Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.

I'm used to the fact that every single BROKEN_ON_SMP driver generates 
tons of such warnings that I don't see why these warnings should be any 
bad...

If you dislike the warnings, you could move the whole __deprecated und a 
config option.

In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
drivers that seem to have an active maintainer might get fixed.

But I'm not religious regarding this issue as long as you accept my 
-Werror-implicit-function-declaration patch...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> On Thu, Nov 17, 2005 at 05:50:15PM -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> > > on i386.
> > > 
> > 
> > Problem is, nobody's fixing these things.  There's no point in adding spam
> > to the kernel build unless it actually gets us some action, and I haven't
> > seen any evidence that it does.
> > 
> > Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.
> 
> I'm used to the fact that every single BROKEN_ON_SMP driver generates 
> tons of such warnings that I don't see why these warnings should be any 
> bad...

I frequently (daily) get patches which spit new warnings.  Sometimes
(~weekly) those warnings indicate real bugs in the patch.

I believe that the main reason for this is that the developers simply don't
notice the new warning amongst all the noise.

> If you dislike the warnings, you could move the whole __deprecated und a 
> config option.
> 
> In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
> drivers that seem to have an active maintainer might get fixed.

That would be good - but perhaps a better approach would be to send pointed
emails to the maintainer.  Or to merge lameo patches to remove
virt_to_bus() so he has to fix it for real ;)

> But I'm not religious regarding this issue as long as you accept my 
> -Werror-implicit-function-declaration patch...

Problem is, I'm the sucker who takes the brunt of that change.  It'd be
best to fix up the warnings _before_ adding the make-it-break patch.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Thu, Nov 17, 2005 at 06:20:47PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > On Thu, Nov 17, 2005 at 05:50:15PM -0800, Andrew Morton wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> > > > on i386.
> > > > 
> > > 
> > > Problem is, nobody's fixing these things.  There's no point in adding spam
> > > to the kernel build unless it actually gets us some action, and I haven't
> > > seen any evidence that it does.
> > > 
> > > Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.
> > 
> > I'm used to the fact that every single BROKEN_ON_SMP driver generates 
> > tons of such warnings that I don't see why these warnings should be any 
> > bad...
> 
> I frequently (daily) get patches which spit new warnings.  Sometimes
> (~weekly) those warnings indicate real bugs in the patch.
> 
> I believe that the main reason for this is that the developers simply don't
> notice the new warning amongst all the noise.

There are few areas in the kernel that spit that many warnings that you 
might not see new ones .

The developers not noticing the warnings might often be the same 
developers who send patches that don't compile...

> > If you dislike the warnings, you could move the whole __deprecated und a 
> > config option.
> > 
> > In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
> > drivers that seem to have an active maintainer might get fixed.
> 
> That would be good - but perhaps a better approach would be to send pointed
> emails to the maintainer.  Or to merge lameo patches to remove
> virt_to_bus() so he has to fix it for real ;)

In the case of virt_to_bus/bus_to_virt there are stil many places in the 
kernel using it, and several of them are well maintained.

IMHO the warnings are the best solution for getting a vast amount fixed, 
and then it's time to think about the rest.

> > But I'm not religious regarding this issue as long as you accept my 
> > -Werror-implicit-function-declaration patch...
> 
> Problem is, I'm the sucker who takes the brunt of that change.  It'd be
> best to fix up the warnings _before_ adding the make-it-break patch.

-Werror-implicit-function-declaration doesn't add new warnings, it turns 
a specific kind of warnings that can indicate nasty runtime errors into 
compile errors.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> > 
> > I believe that the main reason for this is that the developers simply don't
> > notice the new warning amongst all the noise.
> 
> There are few areas in the kernel that spit that many warnings that you 
> might not see new ones .
> 
> The developers not noticing the warnings might often be the same 
> developers who send patches that don't compile...

Some architectures generate a lot more warnings than x86.

> > > If you dislike the warnings, you could move the whole __deprecated und a 
> > > config option.
> > > 
> > > In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
> > > drivers that seem to have an active maintainer might get fixed.
> > 
> > That would be good - but perhaps a better approach would be to send pointed
> > emails to the maintainer.  Or to merge lameo patches to remove
> > virt_to_bus() so he has to fix it for real ;)
> 
> In the case of virt_to_bus/bus_to_virt there are stil many places in the 
> kernel using it, and several of them are well maintained.
> 
> IMHO the warnings are the best solution for getting a vast amount fixed, 
> and then it's time to think about the rest.

But the warnings don't *work*.  I'm *still* staring at stupid pm_register
and intermodule_foo warnings.  How long has that been?

> > > But I'm not religious regarding this issue as long as you accept my 
> > > -Werror-implicit-function-declaration patch...
> > 
> > Problem is, I'm the sucker who takes the brunt of that change.  It'd be
> > best to fix up the warnings _before_ adding the make-it-break patch.
> 
> -Werror-implicit-function-declaration doesn't add new warnings, it turns 
> a specific kind of warnings that can indicate nasty runtime errors into 
> compile errors.

I know, that's why the patch hurts so much.  As I say, we'd be better off
fixing up all the warnings we can before turning them into build errors.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Thu, Nov 17, 2005 at 06:55:29PM -0800, Andrew Morton wrote:

 > > IMHO the warnings are the best solution for getting a vast amount fixed, 
 > > and then it's time to think about the rest.
 > 
 > But the warnings don't *work*.  I'm *still* staring at stupid pm_register
 > and intermodule_foo warnings.  How long has that been?

Too long.  I think the mtd stuff won't ever get fixed until after that
function gets removed.

		Dave

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[David S. Miller]

From: Dave Jones <davej@redhat.com>
Date: Thu, 17 Nov 2005 22:17:51 -0500

> On Thu, Nov 17, 2005 at 06:55:29PM -0800, Andrew Morton wrote:
> 
>  > > IMHO the warnings are the best solution for getting a vast amount fixed, 
>  > > and then it's time to think about the rest.
>  > 
>  > But the warnings don't *work*.  I'm *still* staring at stupid pm_register
>  > and intermodule_foo warnings.  How long has that been?
> 
> Too long.  I think the mtd stuff won't ever get fixed until after that
> function gets removed.

That's unfortunate considering we did cure the DRM cases :-)

My only thought is that virt_to_bus() and friends are a special case
because they mean compilation failure on most non-x86 platforms.

And frankly, __deprecated serves a different purpose as far as I'm
concerned.  It let's people working on stuff outside the tree know
that "oops you shouldn't be using that interface".

The deprecated warnings are so easy to filter out, so I don't think
noise is a good argument.  I see them all the time too.

The whole DMA API we have today was added 4+ years ago specifically
to get rid of virt_to_bus() and friends.  It's been mostly successful,
but one last nudge like this deprecation marking might help get us over
the edge and finally delete the thing for good. :-)

Anyways, my 2cents.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

"David S. Miller" <davem@davemloft.net> wrote:
>
> The deprecated warnings are so easy to filter out, so I don't think
>  noise is a good argument.  I see them all the time too.

That works for you and me.  But how to train all those people who write
warny patches?

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
 > "David S. Miller" <davem@davemloft.net> wrote:
 > >
 > > The deprecated warnings are so easy to filter out, so I don't think
 > >  noise is a good argument.  I see them all the time too.
 > 
 > That works for you and me.  But how to train all those people who write
 > warny patches?

Lots of poking with pointy sticks.  And -Werror.
(Just kidding, except for the bit about the sticks).

Seriously, you've caught me out pretty quickly after I've introduced
warnings in cpufreq/agpgart, for which I'm thankful. This does put
extra pressure on you though, and you've got better things to be
doing than sending nag emails.

		Dave

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Sam Ravnborg]

On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> "David S. Miller" <davem@davemloft.net> wrote:
> >
> > The deprecated warnings are so easy to filter out, so I don't think
> >  noise is a good argument.  I see them all the time too.
> 
> That works for you and me.  But how to train all those people who write
> warny patches?

Would it work to use -Werror only on some parts of the kernel.
Thinking of teaching kbuild to recursively apply a flags to gcc.

Then we could say that kernel/ should be warning free (to a start).

	Sam

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Sat, Nov 19, 2005 at 01:34:35AM +0100, Sam Ravnborg wrote:
 > On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
 > > "David S. Miller" <davem@davemloft.net> wrote:
 > > >
 > > > The deprecated warnings are so easy to filter out, so I don't think
 > > >  noise is a good argument.  I see them all the time too.
 > > 
 > > That works for you and me.  But how to train all those people who write
 > > warny patches?
 > 
 > Would it work to use -Werror only on some parts of the kernel.
 > Thinking of teaching kbuild to recursively apply a flags to gcc.

Only if you also add a load of gcc switches to disable some
of the more pointless warnings, and also can live with released
kernels breaking each time a new gcc gets released.

It's an uphill battle, which is why I only suggested it in
a humourous context.

		Dave

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[David S. Miller]

From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 19 Nov 2005 01:34:35 +0100

> On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > "David S. Miller" <davem@davemloft.net> wrote:
> > >
> > > The deprecated warnings are so easy to filter out, so I don't think
> > >  noise is a good argument.  I see them all the time too.
> > 
> > That works for you and me.  But how to train all those people who write
> > warny patches?
> 
> Would it work to use -Werror only on some parts of the kernel.
> Thinking of teaching kbuild to recursively apply a flags to gcc.
> 
> Then we could say that kernel/ should be warning free (to a start).

Many ports already add -Werror to the CFLAGS via their
arch/${ARCH}/* makefiles.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Fri, Nov 18, 2005 at 05:19:43PM -0800, David S. Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Sat, 19 Nov 2005 01:34:35 +0100
> 
> > On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > > "David S. Miller" <davem@davemloft.net> wrote:
> > > >
> > > > The deprecated warnings are so easy to filter out, so I don't think
> > > >  noise is a good argument.  I see them all the time too.
> > > 
> > > That works for you and me.  But how to train all those people who write
> > > warny patches?
> > 
> > Would it work to use -Werror only on some parts of the kernel.
> > Thinking of teaching kbuild to recursively apply a flags to gcc.
> > 
> > Then we could say that kernel/ should be warning free (to a start).
> 
> Many ports already add -Werror to the CFLAGS via their
> arch/${ARCH}/* makefiles.

They only add it to EXTRA_CFLAGS for one specifig subdirectory.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Sat, Nov 19, 2005 at 01:34:35AM +0100, Sam Ravnborg wrote:
> On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > "David S. Miller" <davem@davemloft.net> wrote:
> > >
> > > The deprecated warnings are so easy to filter out, so I don't think
> > >  noise is a good argument.  I see them all the time too.
> > 
> > That works for you and me.  But how to train all those people who write
> > warny patches?
> 
> Would it work to use -Werror only on some parts of the kernel.
> Thinking of teaching kbuild to recursively apply a flags to gcc.
> 
> Then we could say that kernel/ should be warning free (to a start).

We can do better as we do currently, but we cannever get the kernel 100% 
warning free for all supported kernel configurations and all supported 
gcc versions.

E.g. gcc emitting some "unused variable" warnings when compiling with 
CONFIG_PCI=n is quite common, and although they could all be fixed there 
will always be some warnings with unusual kernel configurations.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Sam Ravnborg]

On Sat, Nov 19, 2005 at 09:51:20PM +0100, Adrian Bunk wrote:
> On Sat, Nov 19, 2005 at 01:34:35AM +0100, Sam Ravnborg wrote:
> > On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > > "David S. Miller" <davem@davemloft.net> wrote:
> > > >
> > > > The deprecated warnings are so easy to filter out, so I don't think
> > > >  noise is a good argument.  I see them all the time too.
> > > 
> > > That works for you and me.  But how to train all those people who write
> > > warny patches?
> > 
> > Would it work to use -Werror only on some parts of the kernel.
> > Thinking of teaching kbuild to recursively apply a flags to gcc.
> > 
> > Then we could say that kernel/ should be warning free (to a start).
> 
> We can do better as we do currently, but we cannever get the kernel 100% 
> warning free for all supported kernel configurations and all supported 
> gcc versions.
> 
> E.g. gcc emitting some "unused variable" warnings when compiling with 
> CONFIG_PCI=n is quite common, and although they could all be fixed there 
> will always be some warnings with unusual kernel configurations.

I had no issue with adding more gcc flags, but this is a very valid
argument. So I will for now not do it.
>From a kbuild perspective it could be useful in other situations
to have the possibility to add a variable that was set also and only in
sub-directories. But I will not dive into it before a better reason show
up.

	Sam

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Pavel Machek]

On Sat 19-11-05 01:34:35, Sam Ravnborg wrote:
> On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > "David S. Miller" <davem@davemloft.net> wrote:
> > >
> > > The deprecated warnings are so easy to filter out, so I don't think
> > >  noise is a good argument.  I see them all the time too.
> > 
> > That works for you and me.  But how to train all those people who write
> > warny patches?
> 
> Would it work to use -Werror only on some parts of the kernel.
> Thinking of teaching kbuild to recursively apply a flags to gcc.
> 
> Then we could say that kernel/ should be warning free (to a start).

Well, please don't do that. -Werror makes development very painful.

							Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[David S. Miller]

From: Pavel Machek <pavel@suse.cz>
Date: Sun, 20 Nov 2005 23:27:32 +0000

> Well, please don't do that. -Werror makes development very painful.

I've had all of arch/sparc64 in -Werror mode for more than a year,
and it's anything but painful.  It's prevented me from introducing
numerous bugs inadvertantly.

People miss warnings or flat out ignore them, if the build fails they
will have to fix it up instead before sending in their changes.

Yes, for a spot like kernel/ it's more difficult since it's
compilation is influenced by so many configuration and platform
specific stuff, but that's just too bad.  Getting it warning free is
still something we can and should do.

Saying it's too hard, so we shouldn't even try, is a self-fufilling
prophecy.  I definitely want to add -Werror to net/ very very soon.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Jesper Juhl]

On 11/18/05, Andrew Morton <akpm@osdl.org> wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated
> > on i386.
> >
>
> Problem is, nobody's fixing these things.  There's no point in adding spam
> to the kernel build unless it actually gets us some action, and I haven't
> seen any evidence that it does.
>
I for one was not aware that these functions were considered to be
deprecated, some log "spam" would have alerted me to that fact.

I'll take a look at fixing up some of these, just need to go dig up
some docs on what the replacements are first, so be patient...

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

[2.6 patch] add -Werror-implicit-function-declaration to CFLAGS

[Adrian Bunk]

Currently, using an undeclared function gives a compile warning, but it 
can lead to a nasty runtime error if the prototype of the function is 
different from what gcc guessed.

With -Werror-implicit-function-declaration, we are getting an immediate 
compile error instead.

There will be some compile errors in cases where compilation previously
worked because the undefined function wasn't called due to gcc dead code
elimination, but in these cases a proper fix doesnt harm.


This patch also removes some unneeded spaces between two tabs in the 
following line.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 30 Aug 2005
- 30 Jul 2005

--- linux-2.6.13-rc3-mm3-full/Makefile.old	2005-07-30 13:55:32.000000000 +0200
+++ linux-2.6.13-rc3-mm3-full/Makefile	2005-07-30 13:55:56.000000000 +0200
@@ -351,7 +351,8 @@
 CPPFLAGS        := -D__KERNEL__ $(LINUXINCLUDE)
 
 CFLAGS 		:= -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-	  	   -fno-strict-aliasing -fno-common \
+		   -Werror-implicit-function-declaration \
+		   -fno-strict-aliasing -fno-common \
 		   -ffreestanding
 AFLAGS		:= -D__ASSEMBLY__
 

Re: [2.6 patch] add -Werror-implicit-function-declaration to CFLAGS

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> Currently, using an undeclared function gives a compile warning, but it 
>  can lead to a nasty runtime error if the prototype of the function is 
>  different from what gcc guessed.
> 
>  With -Werror-implicit-function-declaration, we are getting an immediate 
>  compile error instead.
> 
>  There will be some compile errors in cases where compilation previously
>  worked because the undefined function wasn't called due to gcc dead code
>  elimination, but in these cases a proper fix doesnt harm.
> 

Sorry, I need to build allmodconfig kernels on wacky architectures (eg
ppc64) and this patch is killing me.

Re: [2.6 patch] add -Werror-implicit-function-declaration to CFLAGS

[Adrian Bunk]

On Thu, Nov 10, 2005 at 04:28:57AM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > Currently, using an undeclared function gives a compile warning, but it 
> >  can lead to a nasty runtime error if the prototype of the function is 
> >  different from what gcc guessed.
> > 
> >  With -Werror-implicit-function-declaration, we are getting an immediate 
> >  compile error instead.
> > 
> >  There will be some compile errors in cases where compilation previously
> >  worked because the undefined function wasn't called due to gcc dead code
> >  elimination, but in these cases a proper fix doesnt harm.
> > 
> 
> Sorry, I need to build allmodconfig kernels on wacky architectures (eg
> ppc64) and this patch is killing me.

Can you send me the list of compile errors so that I can work on fixing 
them?

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] add -Werror-implicit-function-declaration to CFLAGS

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> On Thu, Nov 10, 2005 at 04:28:57AM -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > Currently, using an undeclared function gives a compile warning, but it 
> > >  can lead to a nasty runtime error if the prototype of the function is 
> > >  different from what gcc guessed.
> > > 
> > >  With -Werror-implicit-function-declaration, we are getting an immediate 
> > >  compile error instead.
> > > 
> > >  There will be some compile errors in cases where compilation previously
> > >  worked because the undefined function wasn't called due to gcc dead code
> > >  elimination, but in these cases a proper fix doesnt harm.
> > > 
> > 
> > Sorry, I need to build allmodconfig kernels on wacky architectures (eg
> > ppc64) and this patch is killing me.
> 
> Can you send me the list of compile errors so that I can work on fixing 
> them?
> 

No handily, sorry.   Missing virt_to_bus() is the typical problem.

The cross-tools at http://developer.osdl.org/dev/plm/cross_compile/ are
quite simple to install.

Re: [2.6 patch] add -Werror-implicit-function-declaration to CFLAGS

[Adrian Bunk]

On Thu, Nov 10, 2005 at 06:24:43PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > On Thu, Nov 10, 2005 at 04:28:57AM -0800, Andrew Morton wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > Currently, using an undeclared function gives a compile warning, but it 
> > > >  can lead to a nasty runtime error if the prototype of the function is 
> > > >  different from what gcc guessed.
> > > > 
> > > >  With -Werror-implicit-function-declaration, we are getting an immediate 
> > > >  compile error instead.
> > > > 
> > > >  There will be some compile errors in cases where compilation previously
> > > >  worked because the undefined function wasn't called due to gcc dead code
> > > >  elimination, but in these cases a proper fix doesnt harm.
> > > > 
> > > 
> > > Sorry, I need to build allmodconfig kernels on wacky architectures (eg
> > > ppc64) and this patch is killing me.
> > 
> > Can you send me the list of compile errors so that I can work on fixing 
> > them?
> > 
> 
> No handily, sorry.   Missing virt_to_bus() is the typical problem.
>

But in this case -Werror-implicit-function-declaration doesn't create 
new compile errors, it only moves compile errors from compile time to 
link or depmod time - which is IMHO not a bad change.

If you really want to keep the status quo, you can still steal the 
following from sparc64:
  extern unsigned long virt_to_bus_not_defined_use_pci_map(volatile void *addr);
  #define virt_to_bus virt_to_bus_not_defined_use_pci_map
  extern unsigned long bus_to_virt_not_defined_use_pci_map(volatile void *addr);
  #define bus_to_virt bus_to_virt_not_defined_use_pci_map

Would a patch to mark the ISA legacy functions as __deprecated be OK?

This might give some motivation for people to convert drivers and would 
avoid new code like the recently introduced kexec to use this obsolete 
API.

> The cross-tools at http://developer.osdl.org/dev/plm/cross_compile/ are
> quite simple to install.

Thanks, I've tried it.

Other problems I found until I gave up on compiling:
- a problem in sk98lin indirectly corrected by my SkPciWriteCfgDWord() 
  patch
- drivers/net/wireless/tiacx/: missing #include <linux/vmalloc.h>'s
  (see my patch) - this seems to be a real bug

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] add -Werror-implicit-function-declaration to CFLAGS

[Adrian Bunk]

On Fri, Nov 11, 2005 at 09:18:49PM +0100, Adrian Bunk wrote:
>...
> But in this case -Werror-implicit-function-declaration doesn't create 
> new compile errors, it only moves compile errors from compile time to 
> link or depmod time - which is IMHO not a bad change.
> 
> If you really want to keep the status quo, you can still steal the 
> following from sparc64:
>   extern unsigned long virt_to_bus_not_defined_use_pci_map(volatile void *addr);
>   #define virt_to_bus virt_to_bus_not_defined_use_pci_map
>   extern unsigned long bus_to_virt_not_defined_use_pci_map(volatile void *addr);
>   #define bus_to_virt bus_to_virt_not_defined_use_pci_map
> 
> Would a patch to mark the ISA legacy functions as __deprecated be OK?
>...

Sorry, this were two separate thoughts:

Would a patch to mark both virt_to_bus/bus_to_virt and the ISA legacy 
functions (that cause similar problems) as __deprecated be OK?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some