These four patches are fallout from test builds on ARM. I have a
few more of them in my backlog but have not yet confirmed them
to still be valid.
The first three patches are about incomplete dependencies on
old drivers. One could backport them to the beginning of time
in theory, but there is little value since nobody would run into
these problems.
The final patch is one I had submitted before together with the
respective pcmcia patch but forgot to follow up on that. It's
still a valid but relatively theoretical bug, because the previous
behavior of the driver was just as broken as what we have in
mainline.
Please apply,
Arnd
Arnd Bergmann (4):
net: cs89x0: always build platform code if !HAS_IOPORT_MAP
net: wan: add missing virt_to_bus dependencies
net: lance,ni64: don't build for ARM
net: am2150: fix nmclan_cs.c shared interrupt handling
drivers/net/ethernet/amd/Kconfig | 4 ++--
drivers/net/ethernet/amd/nmclan_cs.c | 2 ++
drivers/net/ethernet/cirrus/Kconfig | 3 ++-
drivers/net/wan/Kconfig | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
--
2.1.0.rc2
The cs89x0 driver can either be built as an ISA driver or a platform
driver, the choice is controlled by the CS89x0_PLATFORM Kconfig
symbol. Building the ISA driver on a system that does not have
a way to map I/O ports fails with this error:
drivers/built-in.o: In function `cs89x0_ioport_probe.constprop.1':
:(.init.text+0x4794): undefined reference to `ioport_map'
:(.init.text+0x4830): undefined reference to `ioport_unmap'
This changes the Kconfig logic to take that option away and
always force building the platform variant of this driver if
CONFIG_HAS_IOPORT_MAP is not set. This is the only correct
choice in this case, and it avoids the build error.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/cirrus/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
The cosa driver is rather outdated and does not get built on most
platforms because it requires the ISA_DMA_API symbol. However
there are some ARM platforms that have ISA_DMA_API but no virt_to_bus,
and they get this build error when enabling the ltpc driver.
drivers/net/wan/cosa.c: In function 'tx_interrupt':
drivers/net/wan/cosa.c:1768:3: error: implicit declaration of function 'virt_to_bus'
unsigned long addr = virt_to_bus(cosa->txbuf);
^
The same problem exists for the Hostess SV-11 and Sealevel Systems 4021
drivers.
This adds another dependency in Kconfig to avoid that configuration.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wan/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
@@ -25,7 +25,7 @@ if WAN# There is no way to detect a comtrol sv11 - force it modular for now.configHOSTESS_SV11tristate"Comtrol Hostess SV-11 support"-depends onISA&&m&&ISA_DMA_API&&INET&&HDLC+depends onISA&&m&&ISA_DMA_API&&INET&&HDLC&&VIRT_TO_BUShelpDriverforComtrolHostessSV-11networkcardwhichoperatesonlowspeedsynchronousseriallinksatupto
@@ -37,7 +37,7 @@ config HOSTESS_SV11# The COSA/SRP driver has not been tested as non-modular yet.configCOSAtristate"COSA/SRP sync serial boards support"-depends onISA&&m&&ISA_DMA_API&&HDLC+depends onISA&&m&&ISA_DMA_API&&HDLC&&VIRT_TO_BUS---help---DriverforCOSAandSRPsynchronousserialboards.
@@ -87,7 +87,7 @@ config LANMEDIA# There is no way to detect a Sealevel board. Force it modularconfigSEALEVEL_4021tristate"Sealevel Systems 4021 support"-depends onISA&&m&&ISA_DMA_API&&INET&&HDLC+depends onISA&&m&&ISA_DMA_API&&INET&&HDLC&&VIRT_TO_BUShelpThisisadriverfortheSealevelSystemsACB56serialI/Oadapter.
The ni65 and lance ethernet drivers manually program the ISA DMA
controller that is only available on x86 PCs and a few compatible
systems. Trying to build it on ARM results in this error:
ni65.c: In function 'ni65_probe1':
ni65.c:496:62: error: 'DMA1_STAT_REG' undeclared (first use in this function)
((inb(DMA1_STAT_REG) >> 4) & 0x0f)
^
ni65.c:496:62: note: each undeclared identifier is reported only once for each function it appears in
ni65.c:497:63: error: 'DMA2_STAT_REG' undeclared (first use in this function)
| (inb(DMA2_STAT_REG) & 0xf0);
The DMA1_STAT_REG and DMA2_STAT_REG registers are only defined for
alpha, mips, parisc, powerpc and x86, although it is not clear
which subarchitectures actually have them at the correct location.
This patch for now just disables it for ARM, to avoid randconfig
build errors. We could also decide to limit it to the set of
architectures on which it does compile, but that might look more
deliberate than guessing based on where the drivers build.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/amd/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
A recent patch tried to work around a valid warning for the use of a
deprecated interface by blindly changing from the old
pcmcia_request_exclusive_irq() interface to pcmcia_request_irq().
This driver has an interrupt handler that is not currently aware
of shared interrupts, but can be easily converted to be.
At the moment, the driver reads the interrupt status register
repeatedly until it contains only zeroes in the interesting bits,
and handles each bit individually.
This patch adds the missing part of returning IRQ_NONE in case none
of the bits are set to start with, so we can move on to the next
interrupt source.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 5f5316fcd08ef7 ("am2150: Update nmclan_cs.c to use update PCMCIA API")
---
drivers/net/ethernet/amd/nmclan_cs.c | 2 ++
1 file changed, 2 insertions(+)
From: Jan Kasprzak <hidden> Date: 2015-01-28 16:19:10
Arnd Bergmann wrote:
: The cosa driver is rather outdated and does not get built on most
: platforms because it requires the ISA_DMA_API symbol. However
: there are some ARM platforms that have ISA_DMA_API but no virt_to_bus,
: and they get this build error when enabling the ltpc driver.
:
: drivers/net/wan/cosa.c: In function 'tx_interrupt':
: drivers/net/wan/cosa.c:1768:3: error: implicit declaration of function 'virt_to_bus'
: unsigned long addr = virt_to_bus(cosa->txbuf);
: ^
:
: The same problem exists for the Hostess SV-11 and Sealevel Systems 4021
: drivers.
Hello,
as for COSA, it is OK. Although I would like to know whether there still is
at least one COSA card in use somewhere :-)
Acked-By: Jan "Yenya" Kasprzak <redacted>
Thanks,
-Yenya
:
: This adds another dependency in Kconfig to avoid that configuration.
:
: Signed-off-by: Arnd Bergmann [off-list ref]
: ---
: drivers/net/wan/Kconfig | 6 +++---
: 1 file changed, 3 insertions(+), 3 deletions(-)
:
: diff --git a/drivers/net/wan/Kconfig b/drivers/net/wan/Kconfig
: index 94e234975c61..a2fdd15f285a 100644
: --- a/drivers/net/wan/Kconfig
: +++ b/drivers/net/wan/Kconfig
: @@ -25,7 +25,7 @@ if WAN
: # There is no way to detect a comtrol sv11 - force it modular for now.
: config HOSTESS_SV11
: tristate "Comtrol Hostess SV-11 support"
: - depends on ISA && m && ISA_DMA_API && INET && HDLC
: + depends on ISA && m && ISA_DMA_API && INET && HDLC && VIRT_TO_BUS
: help
: Driver for Comtrol Hostess SV-11 network card which
: operates on low speed synchronous serial links at up to
: @@ -37,7 +37,7 @@ config HOSTESS_SV11
: # The COSA/SRP driver has not been tested as non-modular yet.
: config COSA
: tristate "COSA/SRP sync serial boards support"
: - depends on ISA && m && ISA_DMA_API && HDLC
: + depends on ISA && m && ISA_DMA_API && HDLC && VIRT_TO_BUS
: ---help---
: Driver for COSA and SRP synchronous serial boards.
:
: @@ -87,7 +87,7 @@ config LANMEDIA
: # There is no way to detect a Sealevel board. Force it modular
: config SEALEVEL_4021
: tristate "Sealevel Systems 4021 support"
: - depends on ISA && m && ISA_DMA_API && INET && HDLC
: + depends on ISA && m && ISA_DMA_API && INET && HDLC && VIRT_TO_BUS
: help
: This is a driver for the Sealevel Systems ACB 56 serial I/O adapter.
:
: --
: 2.1.0.rc2
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| New GPG 4096R/A45477D5 -- see http://www.fi.muni.cz/~kas/pgp-rollover.txt |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
||| "New and improved" is only really improved if it also takes backwards |||
||| compatibility into account, rather than saying "now everybody must do |||
||| things the new and improved - and different - way" --Linus Torvalds |||
These four patches are fallout from test builds on ARM. I have a
few more of them in my backlog but have not yet confirmed them
to still be valid.
The first three patches are about incomplete dependencies on
old drivers. One could backport them to the beginning of time
in theory, but there is little value since nobody would run into
these problems.
The final patch is one I had submitted before together with the
respective pcmcia patch but forgot to follow up on that. It's
still a valid but relatively theoretical bug, because the previous
behavior of the driver was just as broken as what we have in
mainline.