linux-stable.git/drivers/net/fddi, branch linux-5.10.y Linux kernel stable tree net: defxx: Fix missing err handling in dfx_init() 2023-01-14T09:15:42+00:00 Yongqiang Liu liuyongqiang13@huawei.com 2022-12-07T07:20:45+00:00 8ed99944572b118770253c81493a620673a0f96b [ Upstream commit ae18dcdff0f8d7e84cd3fd9f496518b5e72d185d ] When eisa_driver_register() or tc_register_driver() failed, the modprobe defxx would fail with some err log as follows: Error: Driver 'defxx' is already registered, aborting... Fix this issue by adding err hanling in dfx_init(). Fixes: e89a2cfb7d7b5 ("[TC] defxx: TURBOchannel support") Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit ae18dcdff0f8d7e84cd3fd9f496518b5e72d185d ]

When eisa_driver_register() or tc_register_driver() failed,
the modprobe defxx would fail with some err log as follows:

 Error: Driver 'defxx' is already registered, aborting...

Fix this issue by adding err hanling in dfx_init().

Fixes: e89a2cfb7d7b5 ("[TC] defxx: TURBOchannel support")
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: fddi: fix UAF in fza_probe 2021-07-25T12:36:20+00:00 Pavel Skripkin paskripkin@gmail.com 2021-07-13T10:58:53+00:00 f33605908a9b6063525e9f68e62d739948c5fccf commit deb7178eb940e2c5caca1b1db084a69b2e59b4c9 upstream. fp is netdev private data and it cannot be used after free_netdev() call. Using fp after free_netdev() can cause UAF bug. Fix it by moving free_netdev() after error message. Fixes: 61414f5ec983 ("FDDI: defza: Add support for DEC FDDIcontroller 700 TURBOchannel adapter") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit deb7178eb940e2c5caca1b1db084a69b2e59b4c9 upstream.

fp is netdev private data and it cannot be
used after free_netdev() call. Using fp after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() after error message.

Fixes: 61414f5ec983 ("FDDI: defza: Add support for DEC FDDIcontroller 700
TURBOchannel adapter")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
FDDI: defxx: Make MMIO the configuration default except for EISA 2021-05-14T07:50:00+00:00 Maciej W. Rozycki macro@orcam.me.uk 2021-03-10T12:03:14+00:00 3b999f3eac04593ee64e2e7d5815ed952debdecd commit 193ced4a79599352d63cb8c9e2f0c6043106eb6a upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. The default kernel configuration choice for the defxx driver is the use of I/O ports rather than MMIO for PCI and EISA systems. It may have made sense as a conservative backwards compatible choice back when MMIO operation support was added to the driver as a part of TURBOchannel bus support. However nowadays this configuration choice makes the driver unusable with systems that do not implement I/O transactions for PCIe. Make DEFXX_MMIO the configuration default then, except where configured for EISA. This exception is because an EISA adapter can have its MMIO decoding disabled with ECU (EISA Configuration Utility) and therefore not available with the resource allocation infrastructure we implement, while port I/O is always readily available as it uses slot-specific addressing, directly mapped to the slot an option card has been placed in and handled with our EISA bus support core. Conversely a kernel that supports modern systems which may not have I/O transactions implemented for PCIe will usually not be expected to handle legacy EISA systems. The change of the default will make it easier for people, including but not limited to distribution packagers, to make a working choice for the driver. Update the option description accordingly and while at it replace the potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports" according to our nomenclature used elsewhere. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support") Cc: stable@vger.kernel.org # v2.6.21+ Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 193ced4a79599352d63cb8c9e2f0c6043106eb6a upstream.

Recent versions of the PCI Express specification have deprecated support
for I/O transactions and actually some PCIe host bridges, such as Power
Systems Host Bridge 4 (PHB4), do not implement them.

The default kernel configuration choice for the defxx driver is the use
of I/O ports rather than MMIO for PCI and EISA systems.  It may have
made sense as a conservative backwards compatible choice back when MMIO
operation support was added to the driver as a part of TURBOchannel bus
support.  However nowadays this configuration choice makes the driver
unusable with systems that do not implement I/O transactions for PCIe.

Make DEFXX_MMIO the configuration default then, except where configured
for EISA.  This exception is because an EISA adapter can have its MMIO
decoding disabled with ECU (EISA Configuration Utility) and therefore
not available with the resource allocation infrastructure we implement,
while port I/O is always readily available as it uses slot-specific
addressing, directly mapped to the slot an option card has been placed
in and handled with our EISA bus support core.  Conversely a kernel that
supports modern systems which may not have I/O transactions implemented
for PCIe will usually not be expected to handle legacy EISA systems.

The change of the default will make it easier for people, including but
not limited to distribution packagers, to make a working choice for the
driver.

Update the option description accordingly and while at it replace the
potentially ambiguous PIO acronym with IOP for "port I/O" vs "I/O ports"
according to our nomenclature used elsewhere.

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Fixes: e89a2cfb7d7b ("[TC] defxx: TURBOchannel support")
Cc: stable@vger.kernel.org # v2.6.21+
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR 2021-05-14T07:49:57+00:00 Maciej W. Rozycki macro@orcam.me.uk 2021-03-10T12:03:09+00:00 a22fc2eb03c4e9217ed6fd2a80fa216ac343f807 commit f626ca682912fab55dff15469ce893ae16b65c7e upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned: # lspci -s 0031:02:04.0 -v 0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] I/O ports at <unassigned> [disabled] Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Kernel driver in use: defxx Kernel modules: defxx # Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: # cat /proc/ioports 00000000-ffffffffffffffff : 0031:02:04.0 # Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state: 0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it. Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O. Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location with the last two lines now swapped for easier handling in the driver. There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway. While at it factor out the error message calls into helpers and fix an argument order bug with the `pr_err' call now in `dfx_register_res_err'. Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f626ca682912fab55dff15469ce893ae16b65c7e upstream.

Recent versions of the PCI Express specification have deprecated support
for I/O transactions and actually some PCIe host bridges, such as Power
Systems Host Bridge 4 (PHB4), do not implement them.

For those systems the PCI BARs that request a mapping in the I/O space
have the length recorded in the corresponding PCI resource set to zero,
which makes it unassigned:

# lspci -s 0031:02:04.0 -v
0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02)
	Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA)
	Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8
	Memory at 620c080020000 (32-bit, non-prefetchable) [size=128]
	I/O ports at <unassigned> [disabled]
	Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
	Kernel driver in use: defxx
	Kernel modules: defxx

#

Regardless the driver goes ahead and requests it (here observed with a
Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry:

# cat /proc/ioports
00000000-ffffffffffffffff : 0031:02:04.0
#

Furthermore, the system gets confused as the driver actually continues
and pokes at those locations, causing a flood of messages being output
to the system console by the underlying system firmware, like:

defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
defxx 0031:02:04.0: enabling device (0140 -> 0142)
LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000
IPMI: dropping non severe PEL event
LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
IPMI: dropping non severe PEL event
LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014
IPMI: dropping non severe PEL event

and so on and so on (possibly intermixed actually, as there's no locking
between the kernel and the firmware in console port access with this
particular system, but cleaned up above for clarity), and once some 10k
of such pairs of the latter two messages have been produced an interace
eventually shows up in a useless state:

0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00

This was not expected to happen as resource handling was added to the
driver a while ago, because it was not known at that time that a PCI
system would be possible that cannot assign port I/O resources, and
oddly enough `request_region' does not fail, which would have caught it.

Correct the problem then by checking for the length of zero for the CSR
resource and bail out gracefully refusing to register an interface if
that turns out to be the case, producing messages like:

defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
0031:02:04.0: Cannot use I/O, no address set, aborting
0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y"

Keep the original check for the EISA MMIO resource as implemented,
because in that case the length is hardwired to 0x400 as a consequence
of how the compare/mask address decoding works in the ESIC chip and it
is only the base address that is set to zero if MMIO has been disabled
for the adapter in EISA configuration, which in turn could be a valid
bus address in a legacy-free system implementing PCI, especially for
port I/O.

Where the EISA MMIO resource has been disabled for the adapter in EISA
configuration this arrangement keeps producing messages like:

eisa 00:05: EISA: slot 5: DEC3002 detected
defxx: v1.11 2014/07/01  Lawrence V. Stefani and others
00:05: Cannot use MMIO, no address set, aborting
00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n"
00:05: Or run ECU and set adapter's MMIO location

with the last two lines now swapped for easier handling in the driver.

There is no need to check for and catch the case of a port I/O resource
not having been assigned for EISA as the adapter uses the slot-specific
I/O space, which gets assigned by how EISA has been specified and maps
directly to the particular slot an option card has been placed in.  And
the EISA variant of the adapter has additional registers that are only
accessible via the port I/O space anyway.

While at it factor out the error message calls into helpers and fix an
argument order bug with the `pr_err' call now in `dfx_register_res_err'.

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management")
Cc: stable@vger.kernel.org # v3.19+
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fddi/skfp: Avoid the use of one-element array 2020-09-29T20:27:43+00:00 Gustavo A. R. Silva gustavoars@kernel.org 2020-09-29T13:27:51+00:00 2c956a5ad4de7376ee792e888809edf2b2b39b86 One-element arrays are being deprecated[1]. Replace the one-element array with a simple object of type u_char: 'u_char rm_pad1'[2], once it seems this is just a placeholder for padding. [1] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays [2] https://github.com/KSPP/linux/issues/86 Built-tested-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/lkml/5f72c23f.%2FkPBWcZBu+W6HKH4%25lkp@intel.com/ Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
One-element arrays are being deprecated[1]. Replace the one-element array
with a simple object of type u_char: 'u_char rm_pad1'[2], once it seems
this is just a placeholder for padding.

[1] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
[2] https://github.com/KSPP/linux/issues/86

Built-tested-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/lkml/5f72c23f.%2FkPBWcZBu+W6HKH4%25lkp@intel.com/
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
treewide: Use fallthrough pseudo-keyword 2020-08-23T22:36:59+00:00 Gustavo A. R. Silva gustavoars@kernel.org 2020-08-23T22:36:59+00:00 df561f6688fef775baa341a0f5d960becd248b11 Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> 
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
net: fddi: skfp: cfm: Remove seemingly unused variable 'ID_sccs' 2020-08-15T03:42:25+00:00 Lee Jones lee.jones@linaro.org 2020-08-14T11:39:32+00:00 81dbf2191f60ccf90f65171d6593c420ee05507f This variable is present in many source files and has not been used anywhere (at least internally) since it was introduced. Fixes the following W=1 kernel build warning(s): drivers/net/fddi/skfp/cfm.c: In function ‘cfm’: drivers/net/fddi/skfp/cfm.c:211:6: warning: variable ‘oldstate’ set but not used [-Wunused-but-set-variable] drivers/net/fddi/skfp/cfm.c:40:19: warning: ‘ID_sccs’ defined but not used [-Wunused-const-variable=] Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
This variable is present in many source files and has not been used
anywhere (at least internally) since it was introduced.

Fixes the following W=1 kernel build warning(s):

 drivers/net/fddi/skfp/cfm.c: In function ‘cfm’:
 drivers/net/fddi/skfp/cfm.c:211:6: warning: variable ‘oldstate’ set but not used [-Wunused-but-set-variable]
 drivers/net/fddi/skfp/cfm.c:40:19: warning: ‘ID_sccs’ defined but not used [-Wunused-const-variable=]

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: fddi: skfp: cfm: Remove set but unused variable 'oldstate' 2020-08-15T03:42:25+00:00 Lee Jones lee.jones@linaro.org 2020-08-14T11:39:31+00:00 d1ad06ba7e47a2cb5522d7e81aed1a76abdef41c While we're at it, remove some code which has never been invoked. Keep the comment though, as it seems potentially half useful. Fixes the following W=1 kernel build warning(s): drivers/net/fddi/skfp/cfm.c: In function ‘cfm’: drivers/net/fddi/skfp/cfm.c:211:6: warning: variable ‘oldstate’ set but not used [-Wunused-but-set-variable] Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
While we're at it, remove some code which has never been invoked.

Keep the comment though, as it seems potentially half useful.

Fixes the following W=1 kernel build warning(s):

 drivers/net/fddi/skfp/cfm.c: In function ‘cfm’:
 drivers/net/fddi/skfp/cfm.c:211:6: warning: variable ‘oldstate’ set but not used [-Wunused-but-set-variable]

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: fddi: skfp: smt: Remove seemingly unused variable 'ID_sccs' 2020-08-15T03:42:25+00:00 Lee Jones lee.jones@linaro.org 2020-08-14T11:39:30+00:00 7b1af34f024e72c458a330d028ed4e9ad0d981c3 This variable is present in many source files and has not been used anywhere (at least internally) since it was introduced. Fixes the following W=1 kernel build warning(s): drivers/net/fddi/skfp/smt.c:24:19: warning: ‘ID_sccs’ defined but not used [-Wunused-const-variable=] Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
This variable is present in many source files and has not been used
anywhere (at least internally) since it was introduced.

Fixes the following W=1 kernel build warning(s):

 drivers/net/fddi/skfp/smt.c:24:19: warning: ‘ID_sccs’ defined but not used [-Wunused-const-variable=]

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: fddi: skfp: smt: Place definition of 'smt_pdef' under same stipulations as its use 2020-08-15T03:42:25+00:00 Lee Jones lee.jones@linaro.org 2020-08-14T11:39:24+00:00 327afdd7c0d13695e8fcbaa0995d451b34c3107b The variable 'smt_pdef' is only used if LITTLE_ENDIAN is set, so only define it if this is the case. Fixes the following W=1 kernel build warning(s): drivers/net/fddi/skfp/smt.c:1572:3: warning: ‘smt_pdef’ defined but not used [-Wunused-const-variable=] Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
The variable 'smt_pdef' is only used if LITTLE_ENDIAN is set, so only
define it if this is the case.

Fixes the following W=1 kernel build warning(s):

 drivers/net/fddi/skfp/smt.c:1572:3: warning: ‘smt_pdef’ defined but not used [-Wunused-const-variable=]

Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>