- 21 Aug, 2013 40 commits
-
-
Libo Chen authored
Unnecessary dev_set_drvdata() is removed, because the driver core clears the driver data to NULL after device_release or on probe failure. Signed-off-by:
Libo Chen <libo.chen@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Libo Chen authored
Unnecessary dev_set_drvdata() is removed, because the driver core clears the driver data to NULL after device_release or on probe failure. Signed-off-by:
-
Libo Chen authored
Unnecessary dev_set_drvdata() is removed, because the driver core clears the driver data to NULL after device_release or on probe failure. Signed-off-by:
-
Libo Chen authored
Unnecessary dev_set_drvdata() is removed, because the driver core clears the driver data to NULL after device_release or on probe failure. Signed-off-by:
-
Libo Chen authored
Unnecessary dev_set_drvdata() is removed, because the driver core clears the driver data to NULL after device_release or on probe failure. Signed-off-by:
-
David S. Miller authored
Pavel Emelyanov says: ==================== tun: Some bits required for tun's checkpoint-restore (v2) After taking a closer look on tun checkpoint-restore I've found several issues with the tun's API that make it impossible to dump and restore the state of tun device and attached tun-files. The proposed API changes are all about extending the existing ioctl-based stuff. Patches fit today's net-next. This v2 has David's comments about patch #1 fixed. All the rest is the same. ==================== Signed-off-by: -
Pavel Emelyanov authored
The only thing we may have from tun device is the fprog, whic contains the number of filter elements and a pointer to (user-space) memory where the elements are. The program itself may not be available if the device is persistent and detached. Signed-off-by:
Pavel Emelyanov <xemul@parallels.com> Signed-off-by:
-
Pavel Emelyanov authored
There's a small problem with sk-filters on tun devices. Consider an application doing this sequence of steps: fd = open("/dev/net/tun"); ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" }); ioctl(fd, TUNATTACHFILTER, &my_filter); ioctl(fd, TUNSETPERSIST, 1); close(fd); At that point the tun0 will remain in the system and will keep in mind that there should be a socket filter at address '&my_filter'. If after that we do fd = open("/dev/net/tun"); ioctl(fd, TUNSETIFF, { .ifr_name = "tun0" }); we most likely receive the -EFAULT error, since tun_attach() would try to connect the filter back. But (!) if we provide a filter at address &my_filter, then tun0 will be created and the "new" filter would be attached, but application may not know about that. This may create certain problems to anyone using tun-s, but it's critical problem for c/r -- if we meet a persistent tun device with a filter in mind, we will not be able to attach to it to dump its state (flags, owner, address, vnethdr size, etc.). The proposal is to allow to attach to tun device (with TUNSETIFF) w/o attaching the filter to the tun-file's socket. After this attach app may e.g clean the device by dropping the filter, it doesn't want to have one, or (in case of c/r) get information about the device with tun ioctls. Signed-off-by: -
Pavel Emelyanov authored
Multiqueue tun devices allow to attach and detach from its queues while keeping the interface itself set on file. Knowing this is critical for the checkpoint part of criu project. Signed-off-by:
-
Pavel Emelyanov authored
Tun devices cannot be created with ifidex user wants, but it's required by checkpoint-restore project. Long time ago such ability was implemented for rtnl_ops-based interface for creating links (9c7dafbf net: Allow to create links with given ifindex), but the only API for creating and managing tuntap devices is ioctl-based and is evolving with adding new ones (cde8b15f tuntap: add ioctl to attach or detach a file form tuntap device). Following that trend, here's how a new ioctl that sets the ifindex for device, that _will_ be created by TUNSETIFF ioctl looks like. So those who want a tuntap device with the ifindex N, should open the tun device, call ioctl(fd, TUNSETIFINDEX, &N), then call TUNSETIFF. If the index N is busy, then the register_netdev will find this out and the ioctl would be failed with -EBUSY. If setifindex is not called, then it will be generated as before. Signed-off-by:
-
Amir Vadai authored
Some variables could have their scope reduced. Signed-off-by:
Amir Vadai <amirv@mellanox.com> Signed-off-by:
-
Amir Vadai authored
Result of skb_frag_dma_map() and dma_map_single() wasn't checked. Added a check and proper handling in case of failure. Moved the mapping to the beginning of mlx4_en_xmit(), before updating the ring data structure to make error handling easier. Signed-off-by:
-
Amir Vadai authored
When hardware gets into error state, must notify user about it. When QP in error state no traffic will be tx'ed from the attached tx_ring. Driver should know how to recover from this unexpected state. I will send later on the recovery flow, but having the print shouldn't be delayed. Signed-off-by:
-
Eugenia Emantayev authored
Fix a bug when FC and PFC are enabled/disabled at the same time. According to ConnectX-3 Programmer Manual these two features are mutial exclusive. So make sure when enabling PFC to turn off global FC and vise versa. Otherwise it hurts the performance. Signed-off-by:
Eugenia Emantayev <eugenia@mellanox.com> Signed-off-by:
-
Amir Vadai authored
Fix some coding style issues in this function. Signed-off-by:
-
Himanshu Madhani authored
Signed-off-by:
Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by:
-
Shahed Shaikh authored
Each function driver instance uses the MAC address of the lowest function belonging to that physical port as a unique port identifier. This port identifier is read and cached in driver during probe and provided to user space through ndo_get_phys_port_id() Signed-off-by:
Shahed Shaikh <shahed.shaikh@qlogic.com> Signed-off-by:
-
Himanshu Madhani authored
o Enable diagnostic test via ethtool and QConvergeConsole application when Multiple Tx queues are enabled on 82xx series adapters. Signed-off-by:
-
Himanshu Madhani authored
o using ethtool {set|get}_channel option, user can change number of Tx queues for 82xx Series adapter. o updated ethtool -S <ethX> option to display stats from each Tx queue. Signed-off-by: -
Himanshu Madhani authored
o 82xx firmware allows support for multiple Tx queues. This patch will enable multi Tx queue support for 82xx series adapter. Max number of Tx queues supported will be 8. Signed-off-by:
-
Sean Cross authored
Some boards require custom PHY configuration, for example due to trace length differences. Add the ability to configure these registers in order to get the PHY to function on boards that need it. Because PHYs are auto-detected based on MDIO device IDs, allow PHY configuration to be specified in the parent Ethernet device node if no PHY device node is present. Signed-off-by:
Sean Cross <xobs@kosagi.com> Signed-off-by:
-
Daniel Borkmann authored
Instead of hard-coding length values, use a define to make it clear where those lengths come from. Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Daniel Borkmann authored
For the functions mld_gq_start_timer(), mld_ifc_start_timer(), and mld_dad_start_timer(), rather use unsigned long than int as we operate only on unsigned values anyway. This seems more appropriate as there is no good reason to do type conversions to int, that could lead to future errors. Signed-off-by:
-
Daniel Borkmann authored
Use proper API functions to calculate jiffies from milliseconds and not the crude method of dividing HZ by a value. This ensures more accurate values even in the case of strange HZ values. While at it, also simplify code in the mlh2 case by using max(). Signed-off-by:
-
Matus Ujhelyi authored
Some phy's can be configured to enable wake on lan (e.g. at803x or marvell 88E1318S). There is no way how to enable wol on CPSW with such connected phys. This patch adds this support. It is provided by calling the phy's related code. Tested on board with at8030x connected phy. Wol interrupt line is connected to GPIO0 on am335x. Signed-off-by:
Matus Ujhelyi <ujhelyi.m@gmail.com> Acked-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
-
Mugunthan V N authored
CPSW driver no longer supports platform register as all the SoCs which has CPSW are supporting DT only booting, so moving cpsw.h header file from platform include to drivers/net/ethernet/ti Signed-off-by:
-
Nicolas Dichtel authored
When an Xin6 tunnel is set up, we check other netdevices to inherit the link- local address. If none is available, the interface will not have any link-local address. RFC4862 expects that each interface has a link local address. Now than this kind of tunnels supports x-netns, it's easy to fall in this case (by creating the tunnel in a netns where ethernet interfaces stand and then moving it to a other netns where no ethernet interface is available). RFC4291, Appendix A suggests two methods: the first is the one currently implemented, the second is to generate a unique identifier, so that we can always generate the link-local address. Let's use eth_random_addr() to generate this interface indentifier. I remove completly the previous method, hence for the whole life of the interface, the link-local address remains the same (previously, it depends on which ethernet interfaces were up when the tunnel interface was set up). Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
David S. Miller authored
This reverts commit df8372ca. These changes are buggy and make unintended semantic changes to ip6_tnl_add_linklocal(). Signed-off-by:
-
Julia Lawall authored
Use devm_ioremap_resource instead of devm_request_and_ioremap. This was done using the semantic patch scripts/coccinelle/api/devm_ioremap_resource.cocci The relevant call to platform_get_resource was manually moved down to the call to devm_ioremap_resource. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Libo Chen authored
Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev, so we can directly pass a struct platform_device. Signed-off-by:Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Libo Chen authored
Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &of_dev->dev, so we can directly pass a struct platform_device. Signed-off-by:Michal Simek <monstr@monstr.eu> Signed-off-by:
-
Libo Chen authored
Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &of->dev, so we can directly pass a struct platform_device. Signed-off-by: -
Libo Chen authored
Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &of->dev, so we can directly pass a struct platform_device. Signed-off-by: -
Libo Chen authored
Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &of->dev, so we can directly pass a struct platform_device. Signed-off-by: -
Libo Chen authored
Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &ofdev->dev, so we can directly pass a struct platform_device. Signed-off-by: -
Libo Chen authored
Use the wrapper functions for getting and setting the driver data using platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev, so we can directly pass a struct platform_device. Signed-off-by: -
Sergei Shtylyov authored
Now that the 'register_type' field of the 'sh_eth' driver's platform data is not used by the driver anymore, it's time to remove it and its initializers from the SH platform code. Also move *enum* declaring values for this field from <linux/sh_eth.h> to the local driver's header file as they're only needed by the driver itself now... Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Sergei Shtylyov authored
The register layout is a SoC characteristic, so it's wrong that it's stored in the otherwise board specific platform data. Add 'register_type' field to 'struct sh_eth_cpu_data', initialize it properly for each SoC, and read it from this structure instead of the platfrom data from now on... Signed-off-by:
-
Sergei Shtylyov authored
The Ether platform data is behind the declaration of 'struct sh_eth_plat_data' as it's lacking the initializers for the 'register_type' and 'phy_interface' fields -- it means they'll be implicitly and wrongly set to SH_ETH_REG_GIGABIT and PHY_INTERFACE_MODE_NA. Initialize the fields explicitly and fix off-by-one error in the Ether memory resource end, while at it... Signed-off-by:
-
Sergei Shtylyov authored
The 'sh_eth' driver's probe will crash as the platform code is hopelessly behind the platform data -- it passes PHY ID instead of 'struct sh_eth_plat_data *'. Strangely, both commit d88a3ea6 (SH7619 add ethernet controler support) that added the platform code and commit 71557a37 ([netdrvr] sh_eth: Add SH7619 support) were done in about the same time, yet the latter one added 'struct sh_eth_plat_data' and the platform code didn't ever get updated... Add the proper platform data and fix off-by-one memory resource end error, while at it... Signed-off-by:
-
