<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net, branch v4.1</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v4.1</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.1'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2015-06-11T23:04:02Z</updated>
<entry>
<title>net: igb: fix the start time for periodic output signals</title>
<updated>2015-06-11T23:04:02Z</updated>
<author>
<name>Richard Cochran</name>
<email>richardcochran@gmail.com</email>
</author>
<published>2015-06-11T12:51:30Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=58c98be137830d34b79024cc5dc95ef54fcd7ffe'/>
<id>urn:sha1:58c98be137830d34b79024cc5dc95ef54fcd7ffe</id>
<content type='text'>
When programming the start of a periodic output, the code wrongly places
the seconds value into the "low" register and the nanoseconds into the
"high" register.  Even though this is backwards, it slipped through my
testing, because the re-arming code in the interrupt service routine is
correct, and the signal does appear starting with the second edge.

This patch fixes the issue by programming the registers correctly.

Signed-off-by: Richard Cochran &lt;richardcochran@gmail.com&gt;
Reviewed-by: Jacob Keller &lt;jacob.e.keller@intel.com&gt;
Acked-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>enic: fix memory leak in rq_clean</title>
<updated>2015-06-11T06:42:39Z</updated>
<author>
<name>Govindarajulu Varadarajan</name>
<email>_govind@gmx.com</email>
</author>
<published>2015-06-11T06:22:56Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8b13b4e0bc884ba7dc8ee4de3ee915b7d30e7f78'/>
<id>urn:sha1:8b13b4e0bc884ba7dc8ee4de3ee915b7d30e7f78</id>
<content type='text'>
When incoming packet qualifies for rx_copybreak, we copy the data to newly
allocated skb. We do not free/unmap the original buffer. At this point driver
assumes this buffer is unallocated. When enic_rq_alloc_buf() is called for
buffer allocation, it checks if buf-&gt;os_buf is NULL. If its not NULL that means
buffer can be re-used.

When vnic_rq_clean() is called for freeing all rq buffers, and if the
rx_copybreak reused buffer falls outside the used desc, we do not free the
buffer. The following trace is observer when dma-debug is enabled.

Fix is to walk through complete ring and clean if buffer is present.

[   40.555386] ------------[ cut here ]------------
[   40.555396] WARNING: CPU: 0 PID: 491 at lib/dma-debug.c:971 dma_debug_device_change+0x188/0x1f0()
[   40.555400] pci 0000:06:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=4]
               One of leaked entries details: [device address=0x00000000ff4cc040] [size=9018 bytes] [mapped with DMA_FROM_DEVICE] [mapped as single]
[   40.555402] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw joydev mousedev gf128mul hid_generic glue_helper mgag200 usbhid ttm hid drm_kms_helper drm ablk_helper syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core iTCO_wdt cryptd mac_hid evdev pcspkr sb_edac edac_core tpm_tis iTCO_vendor_support ipmi_si wmi tpm ipmi_msghandler shpchp lpc_ich processor acpi_power_meter hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache sd_mod ehci_pci ehci_hcd megaraid_sas usbcore scsi_mod usb_common enic(-) crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2
[   40.555467] CPU: 0 PID: 491 Comm: rmmod Not tainted 4.1.0-rc7-ARCH-01305-gf59b71f #118
[   40.555469] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014
[   40.555471]  0000000000000000 00000000e2f8a5b7 ffff880275f8bc48 ffffffff8158d6f0
[   40.555474]  0000000000000000 ffff880275f8bca0 ffff880275f8bc88 ffffffff8107b04a
[   40.555477]  ffff8802734e0000 0000000000000004 ffff8804763fb3c0 ffff88027600b650
[   40.555480] Call Trace:
[   40.555488]  [&lt;ffffffff8158d6f0&gt;] dump_stack+0x4f/0x7b
[   40.555492]  [&lt;ffffffff8107b04a&gt;] warn_slowpath_common+0x8a/0xc0
[   40.555494]  [&lt;ffffffff8107b0d5&gt;] warn_slowpath_fmt+0x55/0x70
[   40.555498]  [&lt;ffffffff812fa408&gt;] dma_debug_device_change+0x188/0x1f0
[   40.555503]  [&lt;ffffffff8109aaef&gt;] notifier_call_chain+0x4f/0x80
[   40.555506]  [&lt;ffffffff8109aecb&gt;] __blocking_notifier_call_chain+0x4b/0x70
[   40.555510]  [&lt;ffffffff8109af06&gt;] blocking_notifier_call_chain+0x16/0x20
[   40.555514]  [&lt;ffffffff813f8066&gt;] __device_release_driver+0xf6/0x120
[   40.555518]  [&lt;ffffffff813f8b08&gt;] driver_detach+0xc8/0xd0
[   40.555523]  [&lt;ffffffff813f7c59&gt;] bus_remove_driver+0x59/0xe0
[   40.555527]  [&lt;ffffffff813f93a0&gt;] driver_unregister+0x30/0x70
[   40.555534]  [&lt;ffffffff8131532d&gt;] pci_unregister_driver+0x2d/0xa0
[   40.555542]  [&lt;ffffffffa0200ec2&gt;] enic_cleanup_module+0x10/0x14e [enic]
[   40.555547]  [&lt;ffffffff8110158f&gt;] SyS_delete_module+0x1cf/0x280
[   40.555551]  [&lt;ffffffff811e284e&gt;] ? ____fput+0xe/0x10
[   40.555554]  [&lt;ffffffff810980ec&gt;] ? task_work_run+0xbc/0xf0
[   40.555558]  [&lt;ffffffff815930ee&gt;] system_call_fastpath+0x12/0x71
[   40.555561] ---[ end trace 4988cadc77c2b236 ]---
[   40.555562] Mapped at:
[   40.555563]  [&lt;ffffffff812fa865&gt;] debug_dma_map_page+0x95/0x150
[   40.555566]  [&lt;ffffffffa01f4a88&gt;] enic_rq_alloc_buf+0x1b8/0x360 [enic]
[   40.555570]  [&lt;ffffffffa01f7658&gt;] enic_open+0xf8/0x820 [enic]
[   40.555574]  [&lt;ffffffff8148d50e&gt;] __dev_open+0xce/0x150
[   40.555579]  [&lt;ffffffff8148d851&gt;] __dev_change_flags+0xa1/0x170

Signed-off-by: Govindarajulu Varadarajan &lt;_govind@gmx.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>enic: check return value for stat dump</title>
<updated>2015-06-11T06:42:39Z</updated>
<author>
<name>Govindarajulu Varadarajan</name>
<email>_govind@gmx.com</email>
</author>
<published>2015-06-11T06:22:55Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=19b596bda1c5400808635fde0d521c1f89a6c1a3'/>
<id>urn:sha1:19b596bda1c5400808635fde0d521c1f89a6c1a3</id>
<content type='text'>
We do not check the return value of enic_dev_stats_dump(). If allocation
fails, we will hit NULL pointer reference.

Return only if memory allocation fails. For other failures, we return the
previously recorded values.

Signed-off-by: Govindarajulu Varadarajan &lt;_govind@gmx.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>enic: unlock napi busy poll before unmasking intr</title>
<updated>2015-06-11T06:42:39Z</updated>
<author>
<name>Govindarajulu Varadarajan</name>
<email>_govind@gmx.com</email>
</author>
<published>2015-06-11T06:22:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6286e8285078ab02b215bba1d42a05ecfd864515'/>
<id>urn:sha1:6286e8285078ab02b215bba1d42a05ecfd864515</id>
<content type='text'>
There is a small window between vnic_intr_unmask() and enic_poll_unlock_napi().
In this window if an irq occurs and napi is scheduled on different cpu, it tries
to acquire enic_poll_lock_napi() and hits the following WARN_ON message.

Fix is to unlock napi_poll before unmasking the interrupt.

[  781.121746] ------------[ cut here ]------------
[  781.121789] WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/cisco/enic/vnic_rq.h:228 enic_poll_msix_rq+0x36a/0x3c0 [enic]()
[  781.121834] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel mgag200 ttm drm_kms_helper joydev aes_x86_64 lrw drm gf128mul mousedev glue_helper sb_edac ablk_helper iTCO_wdt iTCO_vendor_support evdev ipmi_si syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core edac_core lpc_ich mac_hid cryptd pcspkr ipmi_msghandler shpchp tpm_tis acpi_power_meter tpm wmi processor hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache hid_generic usbhid hid ehci_pci ehci_hcd sd_mod megaraid_sas usbcore scsi_mod usb_common enic crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2
[  781.122176] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc6-ARCH-00040-gc46a024-dirty #106
[  781.122210] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014
[  781.122252]  0000000000000000 bddbbc9d655ec96e ffff880277e43da8 ffffffff81583fe8
[  781.122286]  0000000000000000 0000000000000000 ffff880277e43de8 ffffffff8107acfa
[  781.122319]  ffff880272c01000 ffff880273f18000 ffff880273f1a100 0000000000000000
[  781.122352] Call Trace:
[  781.122364]  &lt;IRQ&gt;  [&lt;ffffffff81583fe8&gt;] dump_stack+0x4f/0x7b
[  781.122399]  [&lt;ffffffff8107acfa&gt;] warn_slowpath_common+0x8a/0xc0
[  781.122425]  [&lt;ffffffff8107ae2a&gt;] warn_slowpath_null+0x1a/0x20
[  781.122455]  [&lt;ffffffffa01fa9ca&gt;] enic_poll_msix_rq+0x36a/0x3c0 [enic]
[  781.122487]  [&lt;ffffffff8148525a&gt;] net_rx_action+0x22a/0x370
[  781.122512]  [&lt;ffffffff8107ed3d&gt;] __do_softirq+0xed/0x2d0
[  781.122537]  [&lt;ffffffff8107f06e&gt;] irq_exit+0x7e/0xa0
[  781.122560]  [&lt;ffffffff8158c424&gt;] do_IRQ+0x64/0x100
[  781.122582]  [&lt;ffffffff8158a42e&gt;] common_interrupt+0x6e/0x6e
[  781.122605]  &lt;EOI&gt;  [&lt;ffffffff810bd331&gt;] ? cpu_startup_entry+0x121/0x480
[  781.122638]  [&lt;ffffffff810bd2fc&gt;] ? cpu_startup_entry+0xec/0x480
[  781.122667]  [&lt;ffffffff810f2ed3&gt;] ? clockevents_register_device+0x113/0x1f0
[  781.122698]  [&lt;ffffffff81050ab6&gt;] start_secondary+0x196/0x1e0
[  781.122723] ---[ end trace cec2e9dd3af7b9db ]---

Signed-off-by: Govindarajulu Varadarajan &lt;_govind@gmx.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: bcmgenet: power on MII block for all MII modes</title>
<updated>2015-06-08T19:13:53Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2015-06-08T17:47:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=afe3f907d20f39c0eaf81f2baec247ba672f34a9'/>
<id>urn:sha1:afe3f907d20f39c0eaf81f2baec247ba672f34a9</id>
<content type='text'>
The RGMII block is currently only powered on when using RGMII or
RGMII_NO_ID, which is not correct when using the GENET interface in MII
or Reverse MII modes. We always need to power on the RGMII interface for
this block to properly work, regardless of the MII mode in which we
operate.

Fixes: aa09677cba423 ("net: bcmgenet: add MDIO routines")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>b44: call netif_napi_del()</title>
<updated>2015-06-08T02:45:34Z</updated>
<author>
<name>Hauke Mehrtens</name>
<email>hauke@hauke-m.de</email>
</author>
<published>2015-06-07T12:11:48Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1489bdeeae1a47171926e255956c9fc251db13a0'/>
<id>urn:sha1:1489bdeeae1a47171926e255956c9fc251db13a0</id>
<content type='text'>
When the driver gets unregistered a call to netif_napi_del() was
missing, this all was also missing in the error paths of
b44_init_one().

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>be2net: Replace dma/pci_alloc_coherent() calls with dma_zalloc_coherent()</title>
<updated>2015-06-07T22:35:11Z</updated>
<author>
<name>Sriharsha Basavapatna</name>
<email>sriharsha.basavapatna@avagotech.com</email>
</author>
<published>2015-06-05T10:03:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e51000db4c880165eab06ec0990605f24e75203f'/>
<id>urn:sha1:e51000db4c880165eab06ec0990605f24e75203f</id>
<content type='text'>
There are several places in the driver (all in control paths) where
coherent dma memory is being allocated using either dma_alloc_coherent()
or the deprecated pci_alloc_consistent(). All these calls should be
changed to use dma_zalloc_coherent() to avoid uninitialized fields in
data structures backed by this memory.

Reported-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Tested-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Sriharsha Basavapatna &lt;sriharsha.basavapatna@avagotech.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>amd-xgbe: Use disable_irq_nosync from within timer function</title>
<updated>2015-06-07T07:21:12Z</updated>
<author>
<name>Lendacky, Thomas</name>
<email>Thomas.Lendacky@amd.com</email>
</author>
<published>2015-06-05T21:02:26Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=078b29d7e92e4254b6de16097d0369dde17efe21'/>
<id>urn:sha1:078b29d7e92e4254b6de16097d0369dde17efe21</id>
<content type='text'>
Since the Tx timer function runs in softirq context the driver needs
to call disable_irq_nosync instead of a disable_irq.

Reported-by: Josh Stone &lt;jistone@redhat.com&gt;
Signed-off-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>i40e: Make sure to be in VEB mode if SRIOV is enabled at probe</title>
<updated>2015-06-05T03:14:23Z</updated>
<author>
<name>Anjali Singhai Jain</name>
<email>anjali.singhai@intel.com</email>
</author>
<published>2015-05-27T16:06:14Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=fa11cb3d16a9b9b296a2b811a49faf1356240348'/>
<id>urn:sha1:fa11cb3d16a9b9b296a2b811a49faf1356240348</id>
<content type='text'>
If SRIOV is enabled we need to be in VEB mode not VEPA mode at probe.
This fixes an NPAR bug when SRIOV is enabled in the BIOS.

Change-ID: Ibf006abafd9a0ca3698ec24848cd771cf345cbbc
Signed-off-by: Anjali Singhai Jain &lt;anjali.singhai@intel.com&gt;
Tested-by: Jim Young &lt;james.m.young@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
<entry>
<title>i40e: start up in VEPA mode by default</title>
<updated>2015-06-05T03:10:30Z</updated>
<author>
<name>Anjali Singhai Jain</name>
<email>anjali.singhai@intel.com</email>
</author>
<published>2015-05-08T22:35:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=fc60861e9b00388fd11d7995a60bf0b1e61dba93'/>
<id>urn:sha1:fc60861e9b00388fd11d7995a60bf0b1e61dba93</id>
<content type='text'>
The patch fixes a bug in the default configuration which
prevented a software bridge loaded on the PF interface from
working correctly because broadcast packets are incorrectly
looped back.

Fix the general case, by loading the driver in VEPA mode Until a
VF or VMDq VSI is added. This way loopback on the Main VSI is
turned off until needed and can resolve the issue of unnecessary
reflection for users that do not have VF or VMDq VSIs setup.

The driver must now coordinate the loopback setting for the Flow
Director (FDIR) VSI to make sure it is in sync with the current
VEB or VEPA mode setting.

The user can still switch bridge modes from the bridge commands and
choose to be in VEPA mode with VF VSIs. Because of hardware
requirements, the call to switch to VEB mode when no VF/VMDqs are
present will be rejected.

NOTE: This patch uses BIT_ULL as that is preferred going forward,
a followup patch in the lower priority queue to net-next will fix
up the remaining 1 &lt;&lt; usages.

Change-ID: Ib121ddb18fe4b3c4f52e9deda6fcbeb9105683d1
Signed-off-by: Anjali Singhai Jain &lt;anjali.singhai@intel.com&gt;
Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Tested-by: Jim Young &lt;james.m.young@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
</entry>
</feed>
