When link was down, the bit of DM in ECMR was always set.
So, we could not use half-duplex mode on the controller.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the rx ring is completely empty, then the device may never fire an rx
interrupt. Unfortunately, the rx interrupt is what triggers populating the
rx ring with fresh buffers, so this will cause networking to lock up.

This patch replenishes the skb in recv descriptor as soon as it is
peeled off while processing rx completions. If the skb/buffer
allocation fails, existing one is recycled and the packet in hand is
dropped. This way none of the RX desc is ever left empty, thus avoiding
starvation
Signed-off-by: NScott J. Goldman <scottjg@vmware.com>
Signed-off-by: NShreyas N Bhatewara <sbhatewara@vmware.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MAC address was set using the signed char sockaddr->sa_addr
field and thus the address could be corrupted through sign extension.
Signed-off-by: NKristoffer Glembo <kristoffer@gaisler.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This silences dma-debug warnings:

https://lkml.org/lkml/2011/6/30/341

------------[ cut here ]------------
WARNING: at /home/jimc/projects/lx/linux-2.6/lib/dma-debug.c:820
check_unmap+0x1fe/0x56a()
natsemi 0000:00:06.0: DMA-API: device driver frees DMA memory with
different size [device address=0x0000000006ef0040] [map size=1538
bytes] [unmap size=1522 bytes]
Modules linked in: pc8736x_gpio pc87360 hwmon_vid scx200_gpio nsc_gpio
scx200_hrt scx200_acb i2c_core arc4 rtl8180 mac80211 eeprom_93cx6
cfg80211 pcspkr rfkill scx200 ide_gd_mod ide_pci_generic ohci_hcd
usbcore sc1200 ide_core
Pid: 870, comm: collector Not tainted 3.0.0-rc5-sk-00080-gca56a95e #1
Call Trace:
 [<c011a556>] warn_slowpath_common+0x4a/0x5f
 [<c02565cb>] ? check_unmap+0x1fe/0x56a
 [<c011a5cf>] warn_slowpath_fmt+0x26/0x2a
 [<c02565cb>] check_unmap+0x1fe/0x56a
 [<c0256aaa>] debug_dma_unmap_page+0x53/0x5b
 [<c029d6cd>] pci_unmap_single+0x4d/0x57
 [<c029ea0a>] natsemi_poll+0x343/0x5ca
 [<c0116f41>] ? try_to_wake_up+0xea/0xfc
 [<c0122416>] ? spin_unlock_irq.clone.28+0x18/0x23
 [<c02d4667>] net_rx_action+0x3f/0xe5
 [<c011e35e>] __do_softirq+0x5b/0xd1
 [<c011e303>] ? local_bh_enable+0xa/0xa
 <IRQ>  [<c011e54b>] ? irq_exit+0x34/0x75
 [<c01034b9>] ? do_IRQ+0x66/0x79
 [<c034e869>] ? common_interrupt+0x29/0x30
 [<c0115ed0>] ? finish_task_switch.clone.118+0x31/0x72
 [<c034cb92>] ? schedule+0x3b2/0x3f1
 [<c012f4b0>] ? hrtimer_start_range_ns+0x10/0x12
 [<c012f4ce>] ? hrtimer_start_expires+0x1c/0x24
 [<c034d5aa>] ? schedule_hrtimeout_range_clock+0x8e/0xb4
 [<c012ed27>] ? update_rmtp+0x68/0x68
 [<c034d5da>] ? schedule_hrtimeout_range+0xa/0xc
 [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
 [<c017b051>] ? do_select+0x488/0x4cd
 [<c0115ee2>] ? finish_task_switch.clone.118+0x43/0x72
 [<c01157ad>] ? need_resched+0x14/0x1e
 [<c017a99e>] ? poll_freewait+0x74/0x74
 [<c01157ad>] ? need_resched+0x14/0x1e
 [<c034cbc1>] ? schedule+0x3e1/0x3f1
 [<c011e55e>] ? irq_exit+0x47/0x75
 [<c01157ad>] ? need_resched+0x14/0x1e
 [<c034cf8a>] ? preempt_schedule_irq+0x44/0x4a
 [<c034dd1e>] ? need_resched+0x17/0x19
 [<c024bc12>] ? put_dec_full+0x7b/0xaa
 [<c0240060>] ? blkdev_ioctl+0x434/0x618
 [<c024bc70>] ? put_dec+0x2f/0x6d
 [<c024c6a5>] ? number.clone.1+0x10b/0x1d0
 [<c034cf8a>] ? preempt_schedule_irq+0x44/0x4a
 [<c034dd1e>] ? need_resched+0x17/0x19
 [<c024d046>] ? vsnprintf+0x225/0x264
 [<c024cea0>] ? vsnprintf+0x7f/0x264
 [<c018346f>] ? seq_printf+0x22/0x40
 [<c01a2fcc>] ? do_task_stat+0x582/0x5a3
 [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
 [<c017b1b5>] ? core_sys_select+0x11f/0x1a3
 [<c017a913>] ? poll_schedule_timeout+0x27/0x3e
 [<c01a34a1>] ? proc_tgid_stat+0xd/0xf
 [<c012357c>] ? recalc_sigpending+0x32/0x35
 [<c0123b9c>] ? __set_task_blocked+0x64/0x6a
 [<c011dfb0>] ? timespec_add_safe+0x24/0x48
 [<c0123449>] ? spin_unlock_irq.clone.16+0x18/0x23
 [<c017b3a1>] ? sys_pselect6+0xe5/0x13e
 [<c034dd65>] ? syscall_call+0x7/0xb
 [<c0340000>] ? rpc_clntdir_depopulate+0x26/0x30
---[ end trace 180dcac41a50938b ]---
Reported-by: NJim Cromie <jim.cromie@gmail.com>
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Tested-by: NJim Cromie <jim.cromie@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Offload setting of vlan device requires
vlan_features to be initialized.
Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

request_threaded irq will call kzalloc that can sleep. Initializing the flags variable outside of spin_lock_irqsave/restore in bnad_mbox_irq_alloc will avoid call traces like below.

Jun 27 08:15:24 home-t710 kernel: [11735.634550] Brocade 10G Ethernet driver
Jun 27 08:15:24 home-t710 kernel: [11735.634590] bnad_pci_probe : (0xffff880427f3d000, 0xffffffffa020f3e0) PCI Func : (2)
Jun 27 08:15:24 home-t710 kernel: [11735.637677] bna 0000:82:00.2: PCI INT A -> GSI 66 (level, low) -> IRQ 66
Jun 27 08:15:24 home-t710 kernel: [11735.638290] bar0 mapped to ffffc90014980000, len 262144
Jun 27 08:15:24 home-t710 kernel: [11735.638732] BUG: sleeping function called from invalid context at mm/slub.c:847
Jun 27 08:15:24 home-t710 kernel: [11735.638736] in_atomic(): 0, irqs_disabled(): 1, pid: 11243, name: insmod
Jun 27 08:15:24 home-t710 kernel: [11735.638740] Pid: 11243, comm: insmod Not tainted 3.0.0-rc4+ #6
Jun 27 08:15:24 home-t710 kernel: [11735.638743] Call Trace:
Jun 27 08:15:24 home-t710 kernel: [11735.638755]  [<ffffffff81046427>] __might_sleep+0xeb/0xf0
Jun 27 08:15:24 home-t710 kernel: [11735.638766]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638773]  [<ffffffff8111201c>] kmem_cache_alloc_trace+0x43/0xd8
Jun 27 08:15:24 home-t710 kernel: [11735.638782]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638787]  [<ffffffff810ab791>] request_threaded_irq+0xa1/0x113
Jun 27 08:15:24 home-t710 kernel: [11735.638798]  [<ffffffffa020f0c0>] bnad_pci_probe+0x612/0x8e5 [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638807]  [<ffffffffa01fe469>] ? netif_wake_queue+0x3d/0x3d [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638816]  [<ffffffff81482ef4>] ? _raw_spin_unlock_irqrestore+0x17/0x19
Jun 27 08:15:24 home-t710 kernel: [11735.638822]  [<ffffffff8124d17a>] local_pci_probe+0x44/0x75
Jun 27 08:15:24 home-t710 kernel: [11735.638826]  [<ffffffff8124dc06>] pci_device_probe+0xd0/0xff
Jun 27 08:15:24 home-t710 kernel: [11735.638832]  [<ffffffff812ef8ab>] driver_probe_device+0x131/0x213
Jun 27 08:15:24 home-t710 kernel: [11735.638836]  [<ffffffff812ef9e7>] __driver_attach+0x5a/0x7e
Jun 27 08:15:24 home-t710 kernel: [11735.638840]  [<ffffffff812ef98d>] ? driver_probe_device+0x213/0x213
Jun 27 08:15:24 home-t710 kernel: [11735.638844]  [<ffffffff812ee933>] bus_for_each_dev+0x53/0x89
Jun 27 08:15:24 home-t710 kernel: [11735.638848]  [<ffffffff812ef48a>] driver_attach+0x1e/0x20
Jun 27 08:15:24 home-t710 kernel: [11735.638852]  [<ffffffff812ef0ae>] bus_add_driver+0xd1/0x224
Jun 27 08:15:24 home-t710 kernel: [11735.638858]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
Jun 27 08:15:24 home-t710 kernel: [11735.638862]  [<ffffffff812efe57>] driver_register+0x98/0x105
Jun 27 08:15:24 home-t710 kernel: [11735.638866]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
Jun 27 08:15:24 home-t710 kernel: [11735.638871]  [<ffffffff8124e4c9>] __pci_register_driver+0x56/0xc1
Jun 27 08:15:24 home-t710 kernel: [11735.638875]  [<ffffffffa01b8000>] ? 0xffffffffa01b7fff
Jun 27 08:15:24 home-t710 kernel: [11735.638884]  [<ffffffffa01b8040>] bnad_module_init+0x40/0x60 [bna]
Jun 27 08:15:24 home-t710 kernel: [11735.638892]  [<ffffffff81002099>] do_one_initcall+0x7f/0x136
Jun 27 08:15:24 home-t710 kernel: [11735.638899]  [<ffffffff8108608b>] sys_init_module+0x88/0x1d0
Jun 27 08:15:24 home-t710 kernel: [11735.638906]  [<ffffffff81489682>] system_call_fastpath+0x16/0x1b
Jun 27 08:15:24 home-t710 kernel: [11735.639642] bnad_pci_probe : (0xffff880427f3e000, 0xffffffffa020f3e0) PCI Func : (3)
Jun 27 08:15:24 home-t710 kernel: [11735.639665] bna 0000:82:00.3: PCI INT A -> GSI 66 (level, low) -> IRQ 66
Jun 27 08:15:24 home-t710 kernel: [11735.639735] bar0 mapped to ffffc90014400000, len 262144
Signed-off-by: NShyam Iyer <shyam_iyer@dell.com>
Acked-by: NRasesh Mody <rmody@brocade.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Precedence of the printk should be at higher level so chip fatal
errors are always reported.
Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When we are in a recover process from a chip fatal error,
	driver should skip over execution of mailbox commands during
	resetting chip.
Signed-off-by: NJitendra Kalsaria <jitendra.kalsaria@qlogic.com>
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Lockdep found a locking inconsistency in the mkiss_close function:

> kernel: [ INFO: inconsistent lock state ]
> kernel: 2.6.39.1 #3
> kernel: ---------------------------------
> kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
> kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
> kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
> kernel: {IN-SOFTIRQ-R} state was registered at:

The message hints that disc_data_lock is aquired with softirqs disabled,
but does not itself disable softirqs, which can in rare circumstances
lead to a deadlock. 
The same problem is present in the 6pack driver, this patch fixes both
by using write_lock_bh instead of write_lock.
Reported-by: NBernard F6BVP <f6bvp@free.fr>
Tested-by: NBernard F6BVP <f6bvp@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: Ralf Baechle<ralf@linux-mips.org>
Cc: stable@kernel.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

We would free the proper number of curves, but in the wrong
slots, due to a missing level of indirection through
the pdgain_idx table.

It's simpler just to try to free all four slots, so do that.

Cc: stable@kernel.org
Signed-off-by: NBob Copeland <me@bobcopeland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.

Cc: stable@kernel.org
Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This module and a bunch of dependancies are getting loaded on several
of laptops I have (probably picking up the mobile broadband device),
that have nothing to do with zaurus. Matching by class without
any vendor/device pair isn't the right thing to do here, as it
will prevent any other driver from correctly binding to it.
(Or in the absense of a driver, will just waste time & memory by
 unnecessarily loading modules)
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The two options "CAN bit-timing calculation" and
"Platform CAN drivers with Netlink support" have a "default Y". In order to
activate them by default, change to "default y".
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Acked-by: NWolfgang Grandegger <wg@grandegger.com>
Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function rionet_remove initializes local variable 'ndev' to NULL
and do nothing changes before the call to unregister_netdev(ndev),
this could cause a NULL pointer dereference.
Reported-by: NJesper Juhl <jj@chaosbits.net>
Signed-off-by: NYinglin Luan <synmyth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They are 64K and result in order-4 allocations, even with SLUB.

Therefore, just like we always have for the deflate buffers, use
vmalloc.
Reported-by: NMartin Jackson <mjackson220.list@gmail.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

"iwlagn: map command buffers BIDI" uses the DMA_* enumerations for DMA
directions, even though the pci_* DMA API is still in use.  That patch
was undoubtedly developed on top of "iwlagn: don't use the PCI wrappers
for DMA operation", which is due in the next release.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently (3.0-rc2), modinfo iwlagn shows:
    firmware:       iwlwifi-5150-IWL5150_UCODE_API_MAX.ucode
    firmware:       iwlwifi-5000-IWL5000_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6000g2b-IWL6000G2_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6000g2a-IWL6000G2_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6050-IWL6050_UCODE_API_MAX.ucode
    firmware:       iwlwifi-6000-IWL6000_UCODE_API_MAX.ucode
    firmware:       iwlwifi-100-IWL100_UCODE_API_MAX.ucode
    firmware:       iwlwifi-1000-IWL1000_UCODE_API_MAX.ucode
    firmware:       iwlwifi-105-IWL105_UCODE_API_MAX.ucode
    firmware:       iwlwifi-2030-IWL2030_UCODE_API_MAX.ucode
    firmware:       iwlwifi-2000-IWL2000_UCODE_API_MAX.ucode

which is obviously wrong, the user should not see the *_UCODE_API_MAX
macros but the actual ucode API versions here.

The problem are the
    #define *_MODULE_FIRMWARE(api) *_FW_PRE #api ".ucode"
which do not expand api correctly (because this is a macro itself).

Fixed by using __stringify() from linux/stringify.h.

Further information about macro stringification can be found here:
    http://gcc.gnu.org/onlinedocs/cpp/Stringification.htmlSigned-off-by: NEvgeni Golov <sargentd@die-welt.net>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Evidently, the device sometimes wants to write back
to command buffers, even if I see no reason why it
should. Allow it to do that.
Tested-by: NAndy Lutomirski <luto@mit.edu>
Tested-by: NKyle McMartin <kyle@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

When we stop the device while a command is in
flight that uses multiple TBs, we can leak the
DMA buffers for the second and higher TBs. Fix
this by using iwlagn_unmap_tfd() as we do when
we normally recover the entry.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Fixed call to skb_record_rx_queue where we were passing the queue index
relative to the adapter when it should have been relative to the net_device.
Signed-off-by: NJohn (Jay) Hernandez <jay@chelsio.com>
Signed-off-by: NDivy Le Ray <divy@chelsio.com>
Reported-by: NShawn Bohrer <sbohrer@rgmadvisors.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When an interface changes type to a P2P type,
iwlagn will erroneously set vif->type to the
P2P type and not the reduced/split type. Fix
this by keeping "newtype" in another variable
for the assignment to vif->type.

Cc: stable@kernel.org [2.6.38+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Since we don't have HUGE command any more, there is no point in adding 1
to the num of slots in the command queue. Doing so is buggy and might corrupt
memory.

Bug introduced by 4ce7cc2b
iwlagn: support multiple TBs per command

Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>

Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>

"status" should be an int here for the error handling to work.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

-Support for big endian.
-Do not use USB buffers at the stack.
-Safer/more efficient code for local constants.
Signed-off-by: NMarius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In commit 3ac5e26a entitled
"rtlwifi: rtl8192c-common: Change common firmware routines for addition
of rtl8192se and rtl8192de", the firmware loading code was moved.
Unfortunately, some necessary code was dropped for rtl8192cu.

The dmesg output shows the following:

rtl8192c: Loading firmware file rtlwifi/rtl8192cufw.bin
rtl8192c_common:_rtl92c_fw_free_to_go():<0-0> Polling FW ready fail!! REG_MCUFWDL:0x00000006 .
rtl8192c_common:rtl92c_download_fw():<0-0> Firmware is not ready to run!

In addition, the interface will authenticate and associate, but cannot
transfer data.

This is reported as Kernel Bug #38012.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When NETCONSOLE_DYNAMIC=y and CONFIGFS_FS=m, there are build errors
in netconsole:

drivers/built-in.o: In function `drop_netconsole_target':
netconsole.c:(.text+0x1a100f): undefined reference to `config_item_put'
drivers/built-in.o: In function `make_netconsole_target':
netconsole.c:(.text+0x1a10b9): undefined reference to `config_item_init_type_name'
drivers/built-in.o: In function `write_msg':
netconsole.c:(.text+0x1a11a4): undefined reference to `config_item_get'
netconsole.c:(.text+0x1a1211): undefined reference to `config_item_put'
drivers/built-in.o: In function `netconsole_netdev_event':
netconsole.c:(.text+0x1a12cc): undefined reference to `config_item_put'
netconsole.c:(.text+0x1a12ec): undefined reference to `config_item_get'
netconsole.c:(.text+0x1a1366): undefined reference to `config_item_put'
drivers/built-in.o: In function `init_netconsole':
netconsole.c:(.init.text+0x953a): undefined reference to `config_group_init'
netconsole.c:(.init.text+0x9560): undefined reference to `configfs_register_subsystem'
drivers/built-in.o: In function `dynamic_netconsole_exit':
netconsole.c:(.exit.text+0x809): undefined reference to `configfs_unregister_subsystem'

so fix the NETCONSOLE_DYNAMIC depends clause to prevent this.
Based on email suggestion from Ben Hutchings.  Thanks.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=37992Reported-by: NDavid Hill <hilld@binarystorm.net>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Because the socket buffer is freed in the completion interrupt, it is not
safe to access it after submitting it to the hardware.

Cc: stable@kernel.org
Cc: Sachin Sanap <ssanap@marvell.com>
Cc: Zhangfei Gao <zgao6@marvell.com>
Cc: Philip Rakity <prakity@marvell.com>
Signed-off-by: NRichard Cochran <richard.cochran@omicron.at>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As soon as skb is given to hardware, TX completion can free skb under
us.
Therefore, we should update dev stats before kicking the device.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
CC: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are two devices with PCI ID 0x10ec:0x8192, namely RTL8192E and
RTL8192SE. The method of distinguishing them is by the revision ID
at offset 0x8 of the PCI configuration space. If the value is 0x10,
then the device uses rtl8192se for a driver.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

As soon as skb is given to hardware and spinlock released, TX completion
can free skb under us. Therefore, we should update netdev stats before
spinlock release.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Otherwise we will not see the name of the slave dev in error
message:

[  388.469446] (null):  doesn't support polling, aborting.
Signed-off-by: NWANG Cong <amwang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>

The fst_open() function, after a successful try_module_get() may return
an error code if hdlc_open() returns it.  However, it does not put the
module on this error path.

This patch adds the necessary module_put() call.

Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: NPavel Shved <shved@ispras.ru>
Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>

The RIPTR and TIPTR  (receive/transmit internal temporary data pointer),
used by microcode as a temporary buffer for data, must be 32-byte aligned
according to the RM for MPC8247.

Tested on mgcoge.
Signed-off-by: NClive Stubbings <clive.stubbings@xentech.co.uk>
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com>
cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
cc: Vitaly Bordug <vbordug@ru.mvista.com>
cc: netdev@vger.kernel.org
Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>

The size of the desc array is not the size of the desc structure, so
when we try to free up things, we leak some parts.
Reported-by: NRegis Dargent <rdargent@edevice.com>
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>

Commit 8d8fc29d changed the behavior of slave
devices in regards to netpoll.  Specifically it created a mutually exclusive
relationship between being a slave and a netpoll-capable device.  This creates
problems for KVM because guests relied on needing netconsole active on a slave
device to a bridge.  Ideally libvirtd could just attach netconsole to the bridge
device instead, but thats currently infeasible, because while the bridge device
supports netpoll, it requires that all slave interface also support it, but the
tun/tap driver currently does not.  The most direct solution is to teach tun/tap
to support netpoll, which is implemented by the patch below.

I've not tested this yet, but its pretty straightforward.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Reported-by: NRik van Riel <riel@redhat.com>
CC: Rik van Riel <riel@redhat.com>
CC: Maxim Krasnyansky <maxk@qualcomm.com>
CC: Cong Wang <amwang@redhat.com>
CC: "David S. Miller" <davem@davemloft.net>
Reviewed-by: NRik van Riel <riel@redhat.com>
Tested-by: NRik van Riel <riel@redhat.com>
Reviewed-by: NWANG Cong <amwang@redhat.com>
Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>

The dp83640 PHY provides time stamp and other information via special
PHY status frames. Previously, the driver decoded the frames and then
let the network stack drop them. This works fine when the PTP messages
come over UDP.

However, when receiving PTP messages via L2 packets, this creates a
problem. The status frames use the official PTP destination MAC address,
and so they are delivered to user space along with the "real" frames,
causing confusion for applications.

This commit fixes the issue by simply dropping the PHY status frames
in the driver.
Signed-off-by: NRichard Cochran <richard.cochran@omicron.at>
Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>

If two eternal time stamp events occur at nearly the same time, the
phyter will add an extra word into the status frame. This commit fixes
the parsing code to recognize and skip over the extra word.
Signed-off-by: NRichard Cochran <richard.cochran@omicron.at>
Signed-off-by: NDavid S. Miller <davem@conan.davemloft.net>