bgmac uses bcm47xx_nvram.h which is only available when BCM47XX was
selected. Earlier BCMA_HOST_SOC depended on BCM47XX so this was not
build on any other archs, but that changed. We should modify this
driver to get access to the nvram or the variables through platform
data.

This fixes a build problem in linux-next reported by Stephen Rothwell:

drivers/net/ethernet/broadcom/bgmac.c:19:27: fatal error: bcm47xx_nvram.h: No such file or directory
 #include <bcm47xx_nvram.h>
                           ^
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

bgmac is using functions from phylib, add the dependency.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

All drivers that select MII also need to select NET_CORE because MII
depends on it.  This is a bit ridiculous because NET_CORE is just a
menu option that doesn't enable any code by itself.

There is also no need for it to be a visible option, since its users
all select it.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

BCMA is a Broadcom specific bus with devices AKA cores. All recent BCMA
based SoCs have gigabit ethernet provided by the GBit MAC core. This
patch adds driver for such a cores registering itself as a netdev. It
has been tested on a BCM4706 and BCM4718 chipsets.

In the kernel tree there is already b44 driver which has some common
things with bgmac, however there are many differences that has led to
the decision or writing a new driver:
1) GBit MAC cores appear on BCMA bus (not SSB as in case of b44)
2) There is 64bit DMA engine which differs from 32bit one
3) There is no CAM (Content Addressable Memory) in GBit MAC
4) We have 4 TX queues on GBit MAC devices (instead of 1)
5) Many registers have different addresses/values
6) RX header flags are also different

The driver in it's state is functional how, however there is of course
place for improvements:
1) Supporting more net_device_ops
2) SUpporting more ethtool_ops
3) Unaligned addressing in DMA
4) Writing separated PHY driver
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In this patch the SR-IOV code is segregated from the main bulk of
the bnx2x code. The CONFIG_BNX2X_SRIOV define is added to Broadcom's
Kconfig, and allows the elision of the building of all the SR-IOV
support code in the driver.
The define is dependant on the kernel CONFIG_PCI_IOV configuration
define.
Signed-off-by: NAriel Elior <ariele@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds code to write the reference clock. If a chip reset is
performed, the hwclock is reinitialized with the adjusted kernel time
Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is the seldom used corner case where HWMON=m at the same
time as TIGON3=y (typically randconfigs) which will cause a link
fail like:

drivers/built-in.o: In function `tg3_close':
tg3.c:(.text+0x16bd86): undefined reference to `hwmon_device_unregister'
drivers/built-in.o: In function `tg3_hwmon_open':
tg3.c:(.text+0x16fc4b): undefined reference to `hwmon_device_register'
make[1]: *** [vmlinux] Error 1

Fix it as suggested by DaveM[1] by having the Kconfig logic simply
select HWMON when TIGON3 is selected.  This gets rid of all the
extra IS_ENABLED ifdeffery in tg3.c as a side benefit.

[1] http://marc.info/?l=linux-netdev&m=134250573718151&w=2

Cc: Michael Chan <mchan@broadcom.com>
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reported-by: NAnisse Astier <anisse@astier.eu>
Suggested-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

MII Kconfig option is apart of the core networking drivers and
by default NET_CORE is enabled so drivers selecting MII will
have MII enabled as well.  It was found using the randconfig
option during testing, MII would be selected but NET_CORE
could be disabled.  This caused a dependency error.

Resolved the dependency by selecting NET_CORE when MII is
selected.
Reported-by: NEmil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Based on finds for Stephen Rothwell, where current defconfig's
enable a ethernet driver and it is not compiled due to the newly
added NET_VENDOR_* component of Kconfig.

This patch enables all the "new" Kconfig options so that current
defconfig's will continue to compile the expected drivers.  In
addition, by enabling all the new Kconfig options does not add
any un-expected options.

CC: Stephen Rothwll <sfc@canb.auug.org.au>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Moves the drivers for Broadcom devices into
drivers/net/ethernet/broadcom/ and the necessary Kconfig and Makefile
changes.

CC: Eilon Greenstein <eilong@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
CC: Matt Carlson <mcarlson@broadcom.com>
CC: Gary Zambrano <zambrano@broadcom.com>
CC: "Maciej W. Rozycki" <macro@linux-mips.org>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>