kernel/linux.git/drivers/net/ethernet/microchip, branch v4.11.5

net: microchip: encx24j600: use new api ethtool_{get|set}_link_ksettings

2017-02-13T03:32:17+00:00

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. As I don't have the hardware, I'd be very pleased if someone may test this patch. Signed-off-by: Philippe Reynes Signed-off-by: David S. Miller

net: microchip: enc28j60: use new api ethtool_{get|set}_link_ksettings

2017-02-13T03:32:17+00:00

encx24j600: Fix some checkstyle warnings

2016-12-16T18:31:47+00:00

Signed-off-by: Jeroen De Wachter Signed-off-by: David S. Miller

encx24j600: bugfix - always move ERXTAIL to next packet in encx24j600_rx_packets

2016-12-16T18:31:47+00:00

Before, encx24j600_rx_packets did not update encx24j600_priv's next_packet member when an error occurred during packet handling (either because the packet's RSV header indicates an error or because the encx24j600_receive_packet method can't allocate an sk_buff). If the next_packet member is not updated, the ERXTAIL register will be set to the same value it had before, which means the bad packet remains in the component's memory and its RSV header will be read again when a new packet arrives. If the RSV header indicates a bad packet or if sk_buff allocation continues to fail, new packets will be stored in the component's memory until that memory is full, after which packets will be dropped. The SETPKTDEC command is always executed though, so the encx24j600 hardware has an incorrect count of the packets in its memory. To prevent this, the next_packet member should always be updated, allowing the packet to be skipped (either because it's bad, as indicated in its RSV header, or because allocating an sk_buff failed). In the allocation failure case, this does mean dropping a valid packet, but dropping the oldest packet to keep as much memory as possible available for new packets seems preferable to keeping old (but valid) packets around while dropping new ones. Signed-off-by: Jeroen De Wachter Signed-off-by: David S. Miller

net: deprecate eth_change_mtu, remove usage

2016-10-13T13:36:57+00:00

With centralized MTU checking, there's nothing productive done by eth_change_mtu that isn't already done in dev_set_mtu, so mark it as deprecated and remove all usage of it in the kernel. All callers have been audited for calls to alloc_etherdev* or ether_setup directly, which means they all have a valid dev->min_mtu and dev->max_mtu. Now eth_change_mtu prints out a netdev_warn about being deprecated, for the benefit of out-of-tree drivers that might be utilizing it. Of note, dvb_net.c actually had dev->mtu = 4096, while using eth_change_mtu, meaning that if you ever tried changing it's mtu, you couldn't set it above 1500 anymore. It's now getting dev->max_mtu also set to 4096 to remedy that. v2: fix up lantiq_etop, missed breakage due to drive not compiling on x86 CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson Signed-off-by: David S. Miller

kthread: kthread worker API cleanup

2016-10-11T22:06:33+00:00

A good practice is to prefix the names of functions by the name of the subsystem. The kthread worker API is a mix of classic kthreads and workqueues. Each worker has a dedicated kthread. It runs a generic function that process queued works. It is implemented as part of the kthread subsystem. This patch renames the existing kthread worker API to use the corresponding name from the workqueues API prefixed by kthread_: __init_kthread_worker() -> __kthread_init_worker() init_kthread_worker() -> kthread_init_worker() init_kthread_work() -> kthread_init_work() insert_kthread_work() -> kthread_insert_work() queue_kthread_work() -> kthread_queue_work() flush_kthread_work() -> kthread_flush_work() flush_kthread_worker() -> kthread_flush_worker() Note that the names of DEFINE_KTHREAD_WORK*() macros stay as they are. It is common that the "DEFINE_" prefix has precedence over the subsystem names. Note that INIT() macros and init() functions use different naming scheme. There is no good solution. There are several reasons for this solution: + "init" in the function names stands for the verb "initialize" aka "initialize worker". While "INIT" in the macro names stands for the noun "INITIALIZER" aka "worker initializer". + INIT() macros are used only in DEFINE() macros + init() functions are used close to the other kthread() functions. It looks much better if all the functions use the same scheme. + There will be also kthread_destroy_worker() that will be used close to kthread_cancel_work(). It is related to the init() function. Again it looks better if all functions use the same naming scheme. + there are several precedents for such init() function names, e.g. amd_iommu_init_device(), free_area_init_node(), jump_label_init_type(), regmap_init_mmio_clk(), + It is not an argument but it was inconsistent even before. [arnd@arndb.de: fix linux-next merge conflict] Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.com Suggested-by: Andrew Morton Signed-off-by: Petr Mladek Cc: Oleg Nesterov Cc: Tejun Heo Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Steven Rostedt Cc: "Paul E. McKenney" Cc: Josh Triplett Cc: Thomas Gleixner Cc: Jiri Kosina Cc: Borislav Petkov Cc: Michal Hocko Cc: Vlastimil Babka Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

enc28j60: Fix race condition in enc28j60 driver

2016-07-02T18:48:14+00:00

The interrupt worker code for the enc28j60 relies only on the TXIF flag to determinate if the packet transmission was completed. However the datasheet specifies in section 12.1.3 that TXERIF will clear the TXRTS after a transmit abort. Also in section 12.1.4 that TXIF will be set when TXRTS transitions from '1' to '0'. Therefore the TXIF flag is enabled during transmission errors. This causes a race condition, since the worker code will invoke enc28j60_tx_clear() -> netif_wake_queue(), potentially invoking the ndo_start_xmit function to send a new packet. The enc28j60_send_packet function uses a workqueue that invokes enc28j60_hw_tx(). In between this function is called, the worker from the interrupt handler will enter the path for error handler because of the TXERIF flag, causing to invoke enc28j60_tx_clear() again and releasing the packet scheduled for transmission, causing a kernel crash with due a NULL pointer. These crashes due a NULL pointer were observed under stress conditions of the device. A BUG_ON() sequence was used to validate the issue was fixed, and has been running without problems for 2 years now. Signed-off-by: Diego Dompe Acked-by: Sergio Valverde Signed-off-by: David S. Miller

treewide: replace dev->trans_start update with helper

2016-05-04T18:16:49+00:00

Replace all trans_start updates with netif_trans_update helper. change was done via spatch: struct net_device *d; @@ - d->trans_start = jiffies + netif_trans_update(d) Compile tested only. Cc: user-mode-linux-devel@lists.sourceforge.net Cc: linux-xtensa@linux-xtensa.org Cc: linux1394-devel@lists.sourceforge.net Cc: linux-rdma@vger.kernel.org Cc: netdev@vger.kernel.org Cc: MPT-FusionLinux.pdl@broadcom.com Cc: linux-scsi@vger.kernel.org Cc: linux-can@vger.kernel.org Cc: linux-parisc@vger.kernel.org Cc: linux-omap@vger.kernel.org Cc: linux-hams@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: linux-wireless@vger.kernel.org Cc: linux-s390@vger.kernel.org Cc: devel@driverdev.osuosl.org Cc: b.a.t.m.a.n@lists.open-mesh.org Cc: linux-bluetooth@vger.kernel.org Signed-off-by: Florian Westphal Acked-by: Felipe Balbi Acked-by: Mugunthan V N Acked-by: Antonio Quartulli Signed-off-by: David S. Miller

drivers: replace dev->trans_start accesses with dev_trans_start

2016-05-04T18:16:47+00:00

a trans_start struct member exists twice: - in struct net_device (legacy) - in struct netdev_queue Instead of open-coding dev->trans_start usage to obtain the current trans_start value, use dev_trans_start() instead. This is not exactly the same, as dev_trans_start also considers the trans_start values of the netdev queues owned by the device and provides the most recent one. For legacy devices this doesn't matter as dev_trans_start can cope with netdev trans_start values of 0 (they are ignored). This is a prerequisite to eventual removal of dev->trans_start. Cc: linux-rdma@vger.kernel.org Signed-off-by: Florian Westphal Signed-off-by: David S. Miller

net: ethernet: enc28j60: add device tree support

2016-04-29T20:23:02+00:00

The following patch adds the required match table for device tree support (and while at, fix the indent). It's also possible to specify the MAC address in the DT blob. Also add the corresponding binding documentation file. Signed-off-by: Michael Heimpold Signed-off-by: David S. Miller