This driver has been in the tree since 2009 with no real movement to get
it out. Now it is starting to cause build issues and other problems for
people who want to fix coding style problems, but can not actually build
it.
As nothing is happening here, just delete the module entirely.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Cc: David Daney <ddaney@caviumnetworks.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: YueHaibing <yuehaibing@huawei.com>
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Wambui Karuga <wambui.karugax@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Florian Westphal <fw@strlen.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Branden Bonaby <brandonbonaby94@gmail.com>
Cc: "Petr Štetiar" <ynezz@true.cz>
Cc: Sandro Volery <sandro@volery.com>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Giovanni Gherdovich <bobdc9664@seznam.cz>
Cc: Valery Ivanov <ivalery111@gmail.com>
Link: https://lore.kernel.org/r/20191210091509.3546251-1-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The code doesn't compile due to incompatible pointer errors such as
drivers/staging/octeon/ethernet-tx.c:649:50: error:
passing argument 1 of 'cvmx_wqe_get_grp' from incompatible pointer type
This is due to mixing, for example, cvmx_wqe_t with 'struct cvmx_wqe'.
Unfortunately, one can not just revert the primary offending commit, as doing so
results in secondary errors. This is made worse by the fact that the "removed"
typedefs still exist and are used widely outside the staging directory,
making the entire set of "remove typedef" changes pointless and wrong.
Reflect reality and mark the driver as BROKEN.
Fixes: ef1fe6b736 ("staging: octeon: remove typedef declaration for cvmx_wqe")
Fixes: 73aef0c9d2 ("staging: octeon: remove typedef declaration for cvmx_helper_link_info")
Cc: Wambui Karuga <wambui.karugax@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20191202141836.9363-1-linux@roeck-us.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
While do COMPILE_TEST build without CONFIG_NETDEVICES,
we get Kconfig warning:
WARNING: unmet direct dependencies detected for PHYLIB
Depends on [n]: NETDEVICES [=n]
Selected by [y]:
- OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC && NETDEVICES [=n] || COMPILE_TEST [=y])
Reported-by: Hulk Robot <hulkci@huawei.com>
Reported-by: Mark Brown <broonie@kernel.org>
Fixes: 171a9bae68 ("staging/octeon: Allow test build on !MIPS")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add compile test support by moving all includes of files under
asm/octeon into octeon-ethernet.h, and if we're not on MIPS,
stub out all the calls into the octeon support code in octeon-stubs.h
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are a few remaining drivers/staging/*/Kconfig files that do not
have SPDX identifiers in them. Add the correct GPL-2.0 identifier to
them to make scanning tools happy.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The octeon-ethernet driver shares an mdio bus with the octeon-mgmt
driver. Here we convert the octeon-ethernet driver to use the PHY
Abstraction Layer.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The octeon-ethernet driver supports the sgmii, rgmii, spi, and xaui
ports present on the Cavium OCTEON family of SOCs. These SOCs are
multi-core mips64 processors with existing support over in arch/mips.
The driver files can be categorized into three basic groups:
1) Register definitions, these are named cvmx-*-defs.h
2) Main driver code, these have names that don't start cvmx-.
3) Interface specific functions and other utility code, names starting
with cvmx-
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
