This patch resets the link, if link is up - whenever users enable or disable EEE
Signed-off-by: NAkeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_set_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use the wrapper functions for getting and setting the driver data using
platform_device instead of using deva_set_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch removes the no_csum_insertion private parameter that is not used anymore
and, also,  the "likely" annotation from the condition that is not in a critical path.
Signed-off-by: NGiuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Acked-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NPavel Emelyanov <xemul@parallels.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NPavel Emelyanov <xemul@parallels.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NPavel Emelyanov <xemul@parallels.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NPavel Emelyanov <xemul@parallels.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Some variables could have their scope reduced.
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NEugenia Emantayev <eugenia@mellanox.com>
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix some coding style issues in this function.
Signed-off-by: NAmir Vadai <amirv@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NShahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

o Enable diagnostic test via ethtool and QConvergeConsole
  application when Multiple Tx queues are enabled on 82xx
  series adapters.
Signed-off-by: NHimanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NHimanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NHimanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Patch allow to use different mode settings for SPI (MODE3 for example)
and limit maximal speed according to IC datasheet.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

Flags is not used by boards, so remove this field from the driver
platform_data.
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

This patch replaces power callbacks to the regulator API. To improve
the readability of the code, helper for the regulator enable/disable
was added.
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: NAlexander Shiyan <shc_work@mail.ru>
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>

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: NSean Cross <xobs@kosagi.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NMatus Ujhelyi <ujhelyi.m@gmail.com>
Acked-by: NMugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NMugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Acked-by: NMugunthan V N <mugunthanvnm@ti.com>
Acked-by: NLad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Acked-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLibo Chen <libo.chen@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>