* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
IB/mlx4: Fix MTT leakage in resize CQ
IB/ehca: Fix problem with generated flush work completions
IB/ehca: Change misleading error message on memory hotplug
mlx4_core: Save/restore default port IB capability mask
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
powerpc: Fix system calls on Cell entered with XER.SO=1
powerpc/cell: Fix GDB watchpoints, again
powerpc/mpic: Don't reset affinity for secondary MPIC on boot
powerpc/cell/axon-msi: Retry on missing interrupt
powerpc: Fix boot freeze on machine with empty memory node
powerpc: Fix IRQ assignment for some PCIe devices
powerpc/spufs: Fix spinning in spufs_ps_fault on signal
powerpc/mpc832x_rdb: fix swapped ethernet ids
powerpc: Use generic PHY driver for Marvell 88E1111 PHY on GE Fanuc SBC610
powerpc/85xx: L2 cache size wrong in 8572DS dts
powerpc/virtex: Update defconfigs
powerpc/52xx: update defconfigs
xsysace: Fix driver to use resource_size_t instead of unsigned long
powerpc/virtex: fix various format/casting printk mismatches
powerpc/mpc5200: fix bestcomm Kconfig dependencies
powerpc/44x: Fix 460EX/460GT machine check handling
powerpc/40x: Limit allocable DRAM during early mapping
... by giving the instances' names magic suffix recognized by modpost ;-/
Their ->probe() is __devinit
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
a) ->probe() can be __devinit; no need to put it into .text
b) calling __init stuff from it, OTOH, is wrong
c) ->remove() is __devexit fodder
Acked-by: rmk+kernel@arm.linux.org.uk
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ibmtr_resume() is calling ibmtr_probe(), which is devinit. Whether
that's the right thing to do there is a separate question, but
since it's PCMCIA and thus will never compile without HOTPLUG...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ixgbe_init_interrupt_scheme() is called from ixgbe_resume(). Build that
with CONFIG_PM and without CONFIG_HOTPLUG and you've got a problem.
Several helpers called by it also are misannotated __devinit.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
pppol2tp_sock_to_session() do sock_hold() if the session to release is
not NULL.
Signed-off-by: Frédéric Moulins <frederic.moulins@alsatis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 7ff93f8b ("mlx4_core: Multiple port type support") introduced
support for different port types. As part of that support, SET_PORT
is invoked to set the port type during driver startup. However, as a
side-effect, for IB ports the invocation of this command also sets the
port's capability mask to zero (losing the default value set by FW).
To fix this, get the default ib port capabilities (via a MAD_IFC Port
Info query) during driver startup, and save them for use in the
mlx4_SET_PORT command when setting the port-type to Infiniband.
This patch fixes problems with subnet manager (SM) failover such as
<https://bugs.openfabrics.org/show_bug.cgi?id=1183>, which occurred
because the IsTrapSupported bit in the capability mask was zeroed.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
PAUSE frames are only relevant for the real device, broadcasting them
to all macvlan devices can cause a significant load increase.
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
hp-plus uses 8390p.c, so it should use eip_poll(), not ei_poll().
drivers/built-in.o: In function `hpp_probe1':
hp-plus.c:(.init.text+0x9cbd): undefined reference to `ei_poll'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Ath5k driver has too many interrupts per second at idle
http://bugzilla.kernel.org/show_bug.cgi?id=11749
Signed-off-by: Martin Xu <martin.xu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
http://bugzilla.kernel.org/show_bug.cgi?id=12076
Remove any write access to groups and others, only keep write permission
to its owner, usually only root user.
Reported-by: Jérôme Poulin <jeromepoulin@gmail.com>
Signed-off-by: Cheng Renquan <crquan@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We should only tell the hardware its capable of DMA'ing
to us only what we asked dev_alloc_skb(). Prior to this
it is possible a large RX'd frame could have corrupted
DMA data but for us but we were saved only because we
were previously also pci_map_single()'ing the same large
value. The issue prior to this though was we were unmapping
a smaller amount which the prior DMA patch fixed.
Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This should fix the SW-IOMMU bounce buffer starvation
seen ok kernel.org bugzilla 11811:
http://bugzilla.kernel.org/show_bug.cgi?id=11811
Users on MacBook Pro 3.1/MacBook v2 would see something like:
DMA: Out of SW-IOMMU space for 4224 bytes at device 0000:0b:00.0
Unfortunately its only easy to trigger on MacBook Pro 3.1/MacBook v2
so far so its difficult to debug (even with swiotlb=force).
We were pci_unmap_single()'ing less bytes than what we called
for with pci_map_single() and as such we were starving
the swiotlb from its 64MB amount of bounce buffers. We remain
consistent and now always use sc->rxbufsize for RX. While at
it we update the beacon DMA maps as well to only use the data
portion of the skb, previous to this we were pci_map_single()'ing
more data for beaconing than what we tell the hardware it can use,
therefore pushing more iotlb abuse.
Still not sure why this is so easily triggerable on
MacBook Pro 3.1, it may be the hardware configuration
tends to use more memory > 3GB mark for DMA.
Signed-off-by: Maciej Zenczykowski <zenczykowski@gmail.com>
Signed-off-by: Bennyam Malavazi <Bennyam.Malavazi@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For the RX DMA fix for iwlwifi ("iwlagn: fix RX skb alignment") Luis
pointed out:
> aligned_dma_addr can obviously be > real_dma_addr at this point, what
> guarantees we can use it on our own whim?
I asked around, and he's right, there may be platforms that do not allow
passing such such an address to the DMA API functions. This patch
changes it by using the proper dma_sync_single_range_for_cpu API
invented for this purpose.
Cc: Luis R. Rodriguez <mcgrof@gmail.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
PHY is mostly compatible with the existing VSC8244 PHY. The init sequence
is different and the interrupt mask lacks some bits present in the VSC8244.
Rather than making a copy of the existing VSC234x config_intr function and
change one constant, I modify it to select the interrupt mask based on
which driver is calling it. This lets it be used by both drivers.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
remove redundant argument comments in files of drivers/net/*
Signed-off-by: Qinghuang Feng <qhfeng.kernel@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix hp-plus driver link errors.
Builds as loadable module and kernel image driver.
All drivers that use 8390.o or 8390p.o that will build on
i386 with MCA/PCI/EISA/ISA were built successfully both
=m and =y.
drivers/built-in.o: In function `hpp_open':
hp-plus.c:(.text+0xac06c): undefined reference to `eip_interrupt'
hp-plus.c:(.text+0xac0d7): undefined reference to `eip_open'
drivers/built-in.o: In function `hpp_close':
hp-plus.c:(.text+0xac1bb): undefined reference to `eip_close'
drivers/built-in.o: In function `hpp_probe1':
hp-plus.c:(.init.text+0xa98a): undefined reference to `NS8390p_init'
drivers/built-in.o: In function `hp_plus_probe':
(.init.text+0xa9fe): undefined reference to `__alloc_eip_netdev'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hi,
after noticing that my Netgear FA411 (PCMCIA-NIC) [1] stopped working with
the release of the 2.6.25 kernel (sidux-version), I checked the
respective driver sources and noticed that the pcnet_cs driver bailed
out with "use axnet_cs instead" for the Netgear FA411, but axnet_cs
doesn't claim this ID.
I compiled a kernel with the PCMCIA-ID for the netgear card moved to
axnet_cs from pcnet_cs which worked. I then contacted sidux-kernel
maintainer Stefan Lippers-Hollmann who turned the info into this patch
and integrated it into the kernel:
<http://svn.berlios.de/svnroot/repos/fullstory/linux-sidux-2.6/trunk/debian/patches/features/2.6.27.4_PCMCIA_move-PCMCIA-ID-for-Netgear-FA411-from-pcnet_cs-to-axnet_cs.patch>
This works for me and AFAIK there were no reports of any breakage for
other devices on sidux-support.
This looks like a trivial patch, but since I have very limited
experience with kernel modifications I might be woefully wrong there.
But if there are no side effects of this patch, is it possible to get it
into the official kernel?
I can provide more detailed information on the affected hardware if
necessary.
-cord
[1]
Socket 1 Device 0: [axnet_cs] (bus ID: 1.0)
Configuration: state: on
Product Name: NETGEAR FA411 Fast Ethernet
Identification: manf_id: 0x0149 card_id: 0x0411
function: 6 (network)
prod_id(1): "NETGEAR" (0x9aa79dc3)
prod_id(2): "FA411" (0x40fad875)
prod_id(3): "Fast Ethernet" (0xb4be14e3)
prod_id(4): --- (---)
From: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Date: Sat, 1 Nov 2008 23:53:04 +0000
Subject: PCMCIA: move PCMCIA ID for Netgear FA411 from pcnet_cs to axnet_cs:
Since kernel 2.6.25, commit 61da96be07
(pcnet_cs: if AX88190-based card, printk "use axnet_cs instead" message.),
pcnet_cs bails out with "use axnet_cs instead" for the Netgear FA411, but
axnet_cs doesn't claim this ID.
Socket 1 Device 0: [axnet_cs] (bus ID: 1.0)
Configuration: state: on
Product Name: NETGEAR FA411 Fast Ethernet
Identification: manf_id: 0x0149 card_id: 0x0411
function: 6 (network)
prod_id(1): "NETGEAR" (0x9aa79dc3)
prod_id(2): "FA411" (0x40fad875)
prod_id(3): "Fast Ethernet" (0xb4be14e3)
prod_id(4): --- (---)
Cc: stable <stable@kernel.org> [2.6.25, 2.6.26, 2.6.27]
Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: Cord Walter <qord@cwalter.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the case when the phy_ids is mostly Fs and in some case 0x0
due to broken hardware.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add AX_MEDIUM_ENCK also when speed = 10/100Mbps. This allows my belkin
f5d5055 to work with my 100Mbps switch and with an old 10Mbps ISA card.
Without this patch, the card is recognized and the interface is brought
up fine, but no packets actually flow through the interface.
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
Acked-by: David Hollis <dhollis@davehollis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When mv643xx_eth allocates skbuffs, it adds
'dma_get_cache_alignment() - 1' to the length it needs, so that it can
align the skb's ->data pointer to a cache boundary. When checking
whether a transmitted skbuff can be reused as a receive buffer, these
bytes needs to be included into the minimum bound for the recycle check.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Update to change of mii_bus interface and fix some warning.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
rxfd->frag_info is a __le64, IPG_RFI_FRAGLEN is a cpu-endian
constant and wants to be outside of the le64_to_cpu. Fixed
in multiple places.
Also an occurrence where le64_to_cpu was used instead of cpu_to_le64
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A previous patch, 51e2a3846e, made
genphy_config_aneg() not restart aneg by calling genphy_restart_aneg() if
the advertisement hadn't changed.
But, genphy_restart_aneg() doesn't just restart aneg, it may also *enable*
aneg or un-isolate the PHY from the MII (those functions are controlled by
the same register). The code to avoid calling genphy_restart_aneg() didn't
consider this.
So, modify genphy_config_aneg() to also check if the PHY needs to have aneg
enabled or be un-isolated before deciding not to restart aneg.
This caused a problem with certain Davicom PHYs, as that driver isolates
the PHY (why?) before calling genphy_config_aneg() and expects the PHY to
be un-isolated by that function.
Signed-off-by: Trent Piepho <tpiepho@freescale.com>
Reported-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is the minimal patch to fix endian mismatches. These are
probably bugs on big-endian arches, noops on little endian.
jme_rxsum_ok could be improved to directly take a __le16 and
change all of the masks/sets to be in little-endian, but
has not been done here to keep the patch small.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
CC [M] drivers/net/ixgbe/ixgbe_main.o
drivers/net/ixgbe/ixgbe_main.c: In function `ixgbe_intr':
drivers/net/ixgbe/ixgbe_main.c:1290: sorry, unimplemented: inlining failed in call to 'ixgbe_irq_enable': function body not available
drivers/net/ixgbe/ixgbe_main.c:1312: sorry, unimplemented: called from here
make[4]: *** [drivers/net/ixgbe/ixgbe_main.o] Error 1
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
So I dug deeper into the DMA problems I had with iwlagn and a kind soul
helped me in that he said something about pci-e alignment and mentioned
the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
something the device would fail with, but when I looked into the
function for a minute anyway I stumbled over this little gem:
BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));
Clearly, that is a totally bogus check, one would hope the compiler
removes it entirely. (Think about it)
After fixing it, I obviously ran into it, nothing guarantees the
alignment the way you want it, because of the way skbs and their
headroom are allocated. I won't explain that here nor double-check that
I'm right, that goes beyond what most of the CC'ed people care about.
So then I came up with the patch below, and so far my system has
survived minutes with 64K pages, when it would previously fail in
seconds. And I haven't seen a single instance of the TX bug either. But
when you see the patch it'll be pretty obvious to you why.
This should fix the following reported kernel bugs:
http://bugzilla.kernel.org/show_bug.cgi?id=11596http://bugzilla.kernel.org/show_bug.cgi?id=11393http://bugzilla.kernel.org/show_bug.cgi?id=11983
I haven't checked if there are any elsewhere, but I suppose RHBZ will
have a few instances too...
I'd like to ask anyone who is CC'ed (those are people I know ran into
the bug) to try this patch.
I am convinced that this patch is correct in spirit, but I haven't
understood why, for example, there are so many unmap calls. I'm not
entirely convinced that this is the only bug leading to the TX reply
errors.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Before ieee80211_notify_mac() was added, it was presented with the
use case of using it to tell mac80211 that the association may
have been lost because the firmware crashed/reset.
Since then, it has also been used by iwlwifi to (slightly) speed
up re-association after resume, a workaround around the fact that
mac80211 has no suspend/resume handling yet. It is also not used
by any other drivers, so clearly it cannot be necessary for "good
enough" suspend/resume.
Unfortunately, the callback suffers from a severe problem: It only
works for station mode. If suspend/resume happens while in IBSS or
any other mode (but station), then the callback is pointless.
Recently, it has created a number of locking issues, first because
it required rtnl locking rather than RCU due to calling sleeping
functions within the critical section, and now because it's called
by iwlwifi from the mac80211 workqueue that may not use the rtnl
because it is flushed under rtnl.
(cf. http://bugzilla.kernel.org/show_bug.cgi?id=12046)
I think, therefore, that we should take a step back, remove it
entirely for now and add the small feature it provided properly.
For suspend and resume we will need to introduce new hooks, and for
the case where the firmware was reset the driver will probably
simply just pretend it has done a suspend/resume cycle to get
mac80211 to reprogram the hardware completely, not just try to
connect to the current AP again in station mode. When doing so, we
will need to take into account locking issues and possibly defer
to schedule_work from within mac80211 for the resume operation,
while the suspend operation must be done directly.
Proper suspend/resume should also not necessarily try to reconnect
to the current AP, the time spent in suspend may have been short
enough to not be disconnected from the AP, mac80211 will detect
that the AP went out of range quickly if it did, and if the
association is lost then the AP will disassoc as soon as a data
frame is sent. We might also take into account WWOL then, and
have mac80211 program the hardware into such a mode where it is
available and requested.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
skb->tail can't be meant here because it's not the same across 32/64 bit
compilations. This means there's no way the current driver can work on
64-bit architectures.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org [2.6.27]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (27 commits)
rtnetlink: propagate error from dev_change_flags in do_setlink()
isdn: remove extra byteswap in isdn_net_ciscohdlck_slarp_send_reply
Phonet: refuse to send bigger than MTU packets
e1000e: fix IPMI traffic
e1000e: fix warn_on reload after phy_id error
phy: fix phy address bug
e100: fix dma error in direction for mapping
igb: use dev_printk instead of printk
qla3xxx: Cleanup: Fix link print statements.
igb: Use device_set_wakeup_enable
e1000: Use device_set_wakeup_enable
e1000e: Use device_set_wakeup_enable
via-velocity: enable perfect filtering for multicast packets
phy: Add support for Marvell 88E1118 PHY
mlx4_en: Pause parameters per port
phylib: fix premature freeing of struct mii_bus
atl1: Do not enumerate options unsupported by chip
atl1e: fix broken multicast by removing unnecessary crc inversion
gianfar: Fix DMA unmap invocations
net/ucc_geth: Fix oops in uec_get_ethtool_stats()
...
Some users reported that they have machines with BMCs enabled that cannot
receive IPMI traffic after e1000e is loaded.
http://marc.info/?l=e1000-devel&m=121909039127414&w=2http://marc.info/?l=e1000-devel&m=121365543823387&w=2
This fixes the issue if they load with the new parameter = 0 by disabling
crc stripping, but leaves the performance feature on for most users.
Based on work done by Hong Zhang.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the driver fails to initialize the first time due to the failure in the
phy_id check the kernel triggers a warn_on on the second try to load the
driver because the driver did not free the msi/x resources in the first
load because of the previous failure in phy_id check.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
PHYID returns 0xffff and not 0xffffffff when not found and in some
case(at91sam9263) 0x0. Maybe this patch could be useful.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The e100 driver triggers BUG_ON(buf->direction != dir)
by doing pci_map_single(..., PCI_DMA_BIDIRECTIONAL)
and pci_dma_sync_single_for_device(..., PCI_DMA_TODEVICE).
Changing the DMA direction, especially with dmabounce will result
in unexpected behaviour.
Reported-by: Anders Grafstrom <grfstrm@users.sourceforge.net>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use dev_printk() instead of printk() to give a little more context
and use consistent format.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Removed debug print statements and improved conditionals around informational statements.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
igb_set_wol(). Accordingly, use device_can_wakeup() for checking
if wake-up is supported by the device.
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
e1000_set_wol(). Accordingly, use device_can_wakeup() for checking
if wake-up is supported by the device.
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since dev->power.should_wakeup bit is used by the PCI core to
decide whether the device should wake up the system from sleep
states, set/unset this bit whenever WOL is enabled/disabled using
e1000_set_wol(). Accordingly, use device_can_wakeup() for checking
if wake-up is supported by the device.
Signed-off-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
![](/avatar/43508f7a1ec957af441e34aa327a4088?size=56 "\\"Rafael J. Wysocki\"){kind=small}
