Missing isa_ symbols

Missing isa_ symbols

[Christoph Hellwig]

I've recently switched CONFIG_ISA on to compile-test various scsi
drivers and get lots of warnings like:

WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_bus_to_virt
WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_page_to_bus
WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_virt_to_bus
WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol udelay

from looking at other architectures it looks like architectures
supporting CONFIG_ISA are supposed to supply them.  Any idea how to
implement this properly for ppc?  (and no, I can't test it, by mac
doesn't actually have an isa bus)

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Missing isa_ symbols

[Benjamin Herrenschmidt]

On Wed, 2004-02-04 at 08:03, Christoph Hellwig wrote:
> I've recently switched CONFIG_ISA on to compile-test various scsi
> drivers and get lots of warnings like:
>
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_bus_to_virt
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_page_to_bus
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_virt_to_bus
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol udelay

udelay is a different story, the driver probably lacks an include

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Missing isa_ symbols

[Tom Rini]

On Tue, Feb 03, 2004 at 10:03:21PM +0100, Christoph Hellwig wrote:

> I've recently switched CONFIG_ISA on to compile-test various scsi
> drivers and get lots of warnings like:
>
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_bus_to_virt
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_page_to_bus
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_virt_to_bus
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol udelay
>
> from looking at other architectures it looks like architectures
> supporting CONFIG_ISA are supposed to supply them.  Any idea how to
> implement this properly for ppc?  (and no, I can't test it, by mac
> doesn't actually have an isa bus)

On PPC32, CONFIG_ISA is kinda hack'ish.  I know it will / must work on
PRePs, and it _may_ but I'm not certain of some CHRP machines as well.
So you can probably look at the i386 versions of the functions (save for
udelay as Ben mentioned) and do something like:
if (_machine == _MACH_prep) {
 ... do i386 version ...
} else
 return -EINVAL; // whatever

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Missing isa_ symbols

[Olaf Hering]

 On Tue, Feb 03, Christoph Hellwig wrote:

>
> I've recently switched CONFIG_ISA on to compile-test various scsi
> drivers and get lots of warnings like:
>
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_bus_to_virt
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_page_to_bus
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol isa_virt_to_bus
> WARNING: /lib/modules/2.6.2-rc3/kernel/drivers/scsi/wd7000.ko needs unknown symbol udelay

Who is using that kind of hardware on ppc32?

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Missing isa_ symbols

[Christoph Hellwig]

On Tue, Feb 03, 2004 at 04:17:28PM -0700, Tom Rini wrote:
> On PPC32, CONFIG_ISA is kinda hack'ish.  I know it will / must work on
> PRePs, and it _may_ but I'm not certain of some CHRP machines as well.
> So you can probably look at the i386 versions of the functions (save for
> udelay as Ben mentioned) and do something like:
> if (_machine == _MACH_prep) {
>  ... do i386 version ...
> } else
>  return -EINVAL; // whatever

Well, there's no really sane error return for any of those, but as these
routines are clearly for isa drivers only I'd just implement the prep
versions.

Does this patch look okay?

--- 1.16/include/asm-ppc/io.h	Wed Feb  4 06:31:18 2004
+++ edited/include/asm-ppc/io.h	Fri Feb 13 07:30:39 2004
@@ -199,6 +199,26 @@
 #define memcpy_toio(a,b,c)	memcpy((void *)(a),(b),(c))

 /*
+ * ISA space is 'always mapped' on a typical prep system, no need to
+ * explicitly ioremap() it. The fact that the ISA IO space is mapped
+ * to PAGE_OFFSET is pure coincidence - it does not mean ISA values
+ * are physical addresses. The following constant pointer can be
+ * used as the IO-area pointer (it can be iounmapped as well, so the
+ * analogy with PCI is quite large):
+ */
+#define __ISA_IO_base ((char *)(PAGE_OFFSET))
+
+#define isa_readb(a) readb(__ISA_IO_base + (a))
+#define isa_readw(a) readw(__ISA_IO_base + (a))
+#define isa_readl(a) readl(__ISA_IO_base + (a))
+#define isa_writeb(b,a) writeb(b,__ISA_IO_base + (a))
+#define isa_writew(w,a) writew(w,__ISA_IO_base + (a))
+#define isa_writel(l,a) writel(l,__ISA_IO_base + (a))
+#define isa_memset_io(a,b,c)		memset_io(__ISA_IO_base + (a),(b),(c))
+#define isa_memcpy_fromio(a,b,c)	memcpy_fromio((a),__ISA_IO_base + (b),(c))
+#define isa_memcpy_toio(a,b,c)		memcpy_toio(__ISA_IO_base + (a),(b),(c))
+
+/*
  * Map in an area of physical address space, for accessing
  * I/O devices etc.
  */
@@ -265,6 +285,13 @@
 	return (void*) mm_ptov (address);
 #endif
 }
+
+/*
+ * ISA I/O bus memory addresses are 1:1 with the physical address.
+ */
+#define isa_virt_to_bus virt_to_phys
+#define isa_page_to_bus page_to_phys
+#define isa_bus_to_virt phys_to_virt

 /*
  * Change "struct page" to physical address.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Missing isa_ symbols

[Geert Uytterhoeven]

On Sat, 14 Feb 2004, Christoph Hellwig wrote:
> On Tue, Feb 03, 2004 at 04:17:28PM -0700, Tom Rini wrote:
> > On PPC32, CONFIG_ISA is kinda hack'ish.  I know it will / must work on
> > PRePs, and it _may_ but I'm not certain of some CHRP machines as well.
> > So you can probably look at the i386 versions of the functions (save for
> > udelay as Ben mentioned) and do something like:
> > if (_machine == _MACH_prep) {
> >  ... do i386 version ...
> > } else
> >  return -EINVAL; // whatever
>
> Well, there's no really sane error return for any of those, but as these
> routines are clearly for isa drivers only I'd just implement the prep
> versions.
>
> Does this patch look okay?
>
> --- 1.16/include/asm-ppc/io.h	Wed Feb  4 06:31:18 2004
> +++ edited/include/asm-ppc/io.h	Fri Feb 13 07:30:39 2004
> @@ -199,6 +199,26 @@
>  #define memcpy_toio(a,b,c)	memcpy((void *)(a),(b),(c))
>
>  /*
> + * ISA space is 'always mapped' on a typical prep system, no need to
> + * explicitly ioremap() it. The fact that the ISA IO space is mapped
> + * to PAGE_OFFSET is pure coincidence - it does not mean ISA values
> + * are physical addresses. The following constant pointer can be
> + * used as the IO-area pointer (it can be iounmapped as well, so the
> + * analogy with PCI is quite large):
> + */
> +#define __ISA_IO_base ((char *)(PAGE_OFFSET))

This is not true, I think.

I don't remember whether there's a global ISA memory base variable on PPC yet
(I think there is on MIPS)...

> +
> +#define isa_readb(a) readb(__ISA_IO_base + (a))
> +#define isa_readw(a) readw(__ISA_IO_base + (a))
> +#define isa_readl(a) readl(__ISA_IO_base + (a))
> +#define isa_writeb(b,a) writeb(b,__ISA_IO_base + (a))
> +#define isa_writew(w,a) writew(w,__ISA_IO_base + (a))
> +#define isa_writel(l,a) writel(l,__ISA_IO_base + (a))
> +#define isa_memset_io(a,b,c)		memset_io(__ISA_IO_base + (a),(b),(c))
> +#define isa_memcpy_fromio(a,b,c)	memcpy_fromio((a),__ISA_IO_base + (b),(c))
> +#define isa_memcpy_toio(a,b,c)		memcpy_toio(__ISA_IO_base + (a),(b),(c))
> +
> +/*
>   * Map in an area of physical address space, for accessing
>   * I/O devices etc.
>   */
> @@ -265,6 +285,13 @@
>  	return (void*) mm_ptov (address);
>  #endif
>  }
> +
> +/*
> + * ISA I/O bus memory addresses are 1:1 with the physical address.
> + */
> +#define isa_virt_to_bus virt_to_phys
> +#define isa_page_to_bus page_to_phys
> +#define isa_bus_to_virt phys_to_virt

Same for this.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Missing isa_ symbols

[Benjamin Herrenschmidt]

> > +#define __ISA_IO_base ((char *)(PAGE_OFFSET))
>
> This is not true, I think.

Don't we have an isa_io_base and isa_mem_base ? let's just use
these and return 0xffffffff if not there... (assume base = 0 as
non-existing is safe, we'll never ioremap these at 0 physical)

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Missing isa_ symbols

[Benjamin Herrenschmidt]

On Sun, 2004-02-15 at 23:24, Benjamin Herrenschmidt wrote:
> > > +#define __ISA_IO_base ((char *)(PAGE_OFFSET))
> >
> > This is not true, I think.
>
> Don't we have an isa_io_base and isa_mem_base ? let's just use
> these and return 0xffffffff if not there... (assume base = 0 as
> non-existing is safe, we'll never ioremap these at 0 physical)

I mean at 0 virtual of course ... time to go to bed

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/