Re: linux-next: build failure after merge of the final tree (net-next tree related)

[Just bring this to the attention of the PowerPC folks ...]

On Thu, 20 Sep 2012 16:45:58 -0400 (EDT) David Miller [off-list ref] wrote:

From: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Thu, 20 Sep 2012 12:10:14 +0300

quoted

On Thu, Sep 20, 2012 at 05:36:22PM +1000, Stephen Rothwell wrote:

quoted

Hi all,

After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/net/ethernet/i825xx/znet.c: In function 'hardware_init':
drivers/net/ethernet/i825xx/znet.c:868:2: error: implicit declaration of function 'isa_virt_to_bus' [-Werror=implicit-function-declaration]

Caused by commit 1d3ff76759b7 ("i825xx: znet: fix compiler warnings when
building a 64-bit kernel").  Is there some Kconfig dependency missing (CONFIG_ISA)?

If we make it dependent on CONFIG_ISA then the driver cannot be built with
64-bit kernel. Then again is there someone running 64-bit kernel on Zenith
Z-note notebook? From the pictures it looks like very ancient "laptop".

An alternative is to make it depend on X86 like this:

I think the powerpc port is at fault here.

Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

quoted

I think the powerpc port is at fault here.

Part of being able to advertise ISA_DMA_API is providing isa_virt_to_bus().

Hrm, that's ancient gunk, I'll have to dig. We potentially can support
ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
isa_virt_to_bus is a non-starter.

But then, do we really care ? IE. Is there single device that actually
requires ISA_DMA_API and that is expected to work on any currently
supported powerpc hw ? :-)

We don't even support PReP anymore, so that leaves us with what ?

Anybody has an objection to turning ISA_DMA_API off ?

Cheers,
Ben.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 21 Sep 2012 08:22:44 +1000

Hrm, that's ancient gunk, I'll have to dig. We potentially can support
ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
isa_virt_to_bus is a non-starter.

But then, do we really care ? IE. Is there single device that actually
requires ISA_DMA_API and that is expected to work on any currently
supported powerpc hw ? :-)

We don't even support PReP anymore, so that leaves us with what ?

ISA_DMA_API implies a fixed window of addresses which are <= 32-bits
on the bus, which is a hardware requirement of these devices.

isa_virt_to_bus() goes to that physical address, and the expection is
that you use GFP_DMA and thus the physical addresses fit inside of
an unsigned int.

isa_virt_to_bus() basically amounts to a virt-->phys plus a cast.

Anybody has an objection to turning ISA_DMA_API off ?

Then you can remove all of the DMA api stuff in powerpc's asm/dma.h
but some of it looks like it might be in use.

On Thu, 2012-09-20 at 18:53 -0400, David Miller wrote:

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Fri, 21 Sep 2012 08:22:44 +1000

quoted

Hrm, that's ancient gunk, I'll have to dig. We potentially can support
ISA devices DMA'ing from an ISA bridge... but via the iommu, which means
isa_virt_to_bus is a non-starter.

But then, do we really care ? IE. Is there single device that actually
requires ISA_DMA_API and that is expected to work on any currently
supported powerpc hw ? :-)

We don't even support PReP anymore, so that leaves us with what ?

ISA_DMA_API implies a fixed window of addresses which are <= 32-bits
on the bus, which is a hardware requirement of these devices.

isa_virt_to_bus() goes to that physical address, and the expection is
that you use GFP_DMA and thus the physical addresses fit inside of
an unsigned int.

Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all
of memory is ZONE_DMA). It's always been like that afaik.

We could support ISA device limited addressability using the iommu but
that would involve a map/unmap type API (which I remember we did support
in the old days by passing NULL to pci_map_*, but we dropped that along
the way).

isa_virt_to_bus() basically amounts to a virt-->phys plus a cast.

quoted

Anybody has an objection to turning ISA_DMA_API off ?

Then you can remove all of the DMA api stuff in powerpc's asm/dma.h
but some of it looks like it might be in use.

I will dig a bit. I think there might be some users of the ISA DMA
engine for legacy floppies and parport on some early pSeries and CHRP
machines (including Pegasos).

Cheers,
Ben.

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 22 Sep 2012 07:46:40 +1000

Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all
of memory is ZONE_DMA). It's always been like that afaik.

We could support ISA device limited addressability using the iommu but
that would involve a map/unmap type API (which I remember we did support
in the old days by passing NULL to pci_map_*, but we dropped that along
the way).

I think I'm going to just end up restricting this driver to X86
as was originally suggested.

There seems to be no real consistent Kconfig protection for users
of isa_virt_to_bus() and friends.

We know that ISA_DMA_API doesn't do it, and ISA doesn't do it either
as powerpc also allows that to bet set for CHRP and friends.

Thanks.

On Sat, 2012-09-22 at 16:00 -0400, David Miller wrote:

I think I'm going to just end up restricting this driver to X86
as was originally suggested.

Probably the easiest fix indeed.

There seems to be no real consistent Kconfig protection for users
of isa_virt_to_bus() and friends.

We know that ISA_DMA_API doesn't do it, and ISA doesn't do it either
as powerpc also allows that to bet set for CHRP and friends.

It's a old mess :-( And not an easy one to untangle...

Cheers,
Ben.