The functionality is to be replaced by an improved implementation,
so first clean up.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Acked-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
bitarray.c consists mostly of functionality that is already available as part
of the standard kernel API. batman-adv could use architecture optimized code
and reduce the binary size by switching to the standard functions.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
In packet.h the numeric constant 6 is used instead of the more portable ETH_ALEN
define. This patch substitute any hardcoded value with such define.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Acked-by: Sven Eckelmann <sven@narfation.org>
Both drivers need to depend upon HAS_IOMEM, otherwise we
get a build failure on platforms like S390.
All the driver specific config options need to depend upon
the drivers themselves.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Everything has been set up in the PCI probe function.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>
No net_device.irq removal yet. The driver probe, remove and failure
paths need some care beforehand.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>
- pci_resource_start() can be removed from sis900_get_mac_addr() because
the IO range is maped and stored into the device private struct early
in the device probe function.
- the driver contains a few direct accesses to low IO ports that forbid
to re(#)define the usual out{l, w, b} macros.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Daniele Venzano <venza@brownhat.org>
The bulk of the patch comes from the __iomem changes.
- the phy read and write operations were carrying the chip id deep
down the call chain. Let's waste a pointer and contain the flying
spaghetti monster.
- phy_{read, write}_1bit only need to access the DCR9 register. The loss
of generality here should not hurt.
- removed a leftover printk of the EISA era. This is a pure PCI device.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
The eeprom registers always use the same PCI bar whereas the general
registers may either use the same mapping as the eeprom registers or
a different one. It is thus possible to simplify parse_eeprom().
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
The device private data pointer can not be NULL in smsc9420_open().
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Steve Glendinning <steve.glendinning@smsc.com>
- unbalanced pci_disable_device
- PCI ressources were not released
- mismatching pci_alloc_.../kfree pairs are replaced by DMA alloc helpers.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Ack-by: Grant Grundler <grundler@parisc-linux.org>
Some settings are duplicated between ethtool link management and module
options. The latter is trimmed. The half duplex, speed and autonegotiation
defaults are kept unchanged.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Ion Badulescu <ionut@badula.org>
It's useless to check mem_start on a newly allocated device as well.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Ion Badulescu <ionut@badula.org>
I have a new optimized x86 "strncpy_from_user()" that will use these
same helper functions for all the same reasons the name lookup code uses
them. This is preparation for that.
This moves them into an architecture-specific header file. It's
architecture-specific for two reasons:
- some of the functions are likely to want architecture-specific
implementations. Even if the current code happens to be "generic" in
the sense that it should work on any little-endian machine, it's
likely that the "multiply by a big constant and shift" implementation
is less than optimal for an architecture that has a guaranteed fast
bit count instruction, for example.
- I expect that if architectures like sparc want to start playing
around with this, we'll need to abstract out a few more details (in
particular the actual unaligned accesses). So we're likely to have
more architecture-specific stuff if non-x86 architectures start using
this.
(and if it turns out that non-x86 architectures don't start using
this, then having it in an architecture-specific header is still the
right thing to do, of course)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
