Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15 |
|
#
f99e6d7c |
| 27-Feb-2023 |
Rafał Miłecki <rafal@milecki.pl> |
bgmac: fix *initial* chip reset to support BCM5358
While bringing hardware up we should perform a full reset including the switch bit (BGMAC_BCMA_IOCTL_SW_RESET aka SICF_SWRST). It's what specificat
bgmac: fix *initial* chip reset to support BCM5358
While bringing hardware up we should perform a full reset including the switch bit (BGMAC_BCMA_IOCTL_SW_RESET aka SICF_SWRST). It's what specification says and what reference driver does.
This seems to be critical for the BCM5358. Without this hardware doesn't get initialized properly and doesn't seem to transmit or receive any packets.
Originally bgmac was calling bgmac_chip_reset() before setting "has_robosw" property which resulted in expected behaviour. That has changed as a side effect of adding platform device support which regressed BCM5358 support.
Fixes: f6a95a24957a ("net: ethernet: bgmac: Add platform device support") Cc: Jon Mason <jdmason@kudzu.us> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230227091156.19509-1-zajec5@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
show more ...
|
Revision tags: v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37 |
|
#
592df366 |
| 28-Apr-2022 |
Jakub Kicinski <kuba@kernel.org> |
net: bgmac: remove a copy of the NAPI_POLL_WEIGHT define
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder.
Reviewed-by: Florian Fainelli
net: bgmac: remove a copy of the NAPI_POLL_WEIGHT define
Defining local versions of NAPI_POLL_WEIGHT with the same values in the drivers just makes refactoring harder.
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
28e303da |
| 07-Jan-2021 |
Rafał Miłecki <rafal@milecki.pl> |
net: broadcom: share header defining UniMAC registers
UniMAC is integrated into multiple Broadcom's Ethernet controllers so use a shared header file for it and avoid some code duplication.
Signed-o
net: broadcom: share header defining UniMAC registers
UniMAC is integrated into multiple Broadcom's Ethernet controllers so use a shared header file for it and avoid some code duplication.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Doug Berger <opendmb@gmail.com> Link: https://lore.kernel.org/r/20210107180051.1542-2-zajec5@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
12cf8e75 |
| 07-Jan-2021 |
Rafał Miłecki <rafal@milecki.pl> |
bgmac: add bgmac_umac_*() helpers for accessing UniMAC registers
UniMAC is a hardware block commonly used in Broadcom Ethernet controllers that should get its own header file. Not every controller h
bgmac: add bgmac_umac_*() helpers for accessing UniMAC registers
UniMAC is a hardware block commonly used in Broadcom Ethernet controllers that should get its own header file. Not every controller has it mapped at the 0x800 offset so add bgmac access helpers. They will allow using shared register defines.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20210107180051.1542-1-zajec5@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6 |
|
#
8c7da639 |
| 27-Mar-2020 |
Murali Krishna Policharla <murali.policharla@broadcom.com> |
bgmac: configure MTU and add support for frames beyond 8192 byte size
Change DMA descriptor length to handle jumbo frames beyond 8192 bytes. Also update jumbo frame max size to include FCS, the DMA
bgmac: configure MTU and add support for frames beyond 8192 byte size
Change DMA descriptor length to handle jumbo frames beyond 8192 bytes. Also update jumbo frame max size to include FCS, the DMA packet length received includes FCS.
Signed-off-by: Murali Krishna Policharla <murali.policharla@broadcom.com> Reviewed-by: Arun Parameswaran <arun.parameswaran@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16 |
|
#
16a1c064 |
| 01-Apr-2018 |
Florian Fainelli <f.fainelli@gmail.com> |
net: bgmac: Correctly annotate register space
All the members: base, idm_base and nicpm_base should be annotated with __iomem since they are pointers to register space. This fixes a bunch of sparse
net: bgmac: Correctly annotate register space
All the members: base, idm_base and nicpm_base should be annotated with __iomem since they are pointers to register space. This fixes a bunch of sparse reported warnings.
Fixes: f6a95a24957a ("net: ethernet: bgmac: Add platform device support") Fixes: dd5c5d037f5e ("net: ethernet: bgmac: add NS2 support") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.15, v4.13.16, v4.14 |
|
#
b2441318 |
| 01-Nov-2017 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine
License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license identifiers to apply.
- when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary:
SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became the concluded license(s).
- when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.
In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related.
Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v4.13.5, v4.13 |
|
#
a163bdb0 |
| 13-Jul-2017 |
Abhishek Shah <abhishek.shah@broadcom.com> |
net: ethernet: bgmac: Make IDM register space optional
IDM operations are usually one time ops and should be done in firmware itself. Driver is not supposed to touch IDM registers.
However, for som
net: ethernet: bgmac: Make IDM register space optional
IDM operations are usually one time ops and should be done in firmware itself. Driver is not supposed to touch IDM registers.
However, for some SoCs', driver is performing IDM read/writes. So this patch masks IDM operations in case firmware is taking care of IDM operations.
Signed-off-by: Abhishek Shah <abhishek.shah@broadcom.com> Reviewed-by: Oza Oza <oza.oza@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2 |
|
#
f3537b34 |
| 28-Feb-2017 |
Joey Zhong <zhongx@broadcom.com> |
net: ethernet: bgmac: driver power manangement
Implement suspend/resume callbacks in the bgmac driver. This makes sure that we de-initialize and re-initialize the hardware correctly before entering
net: ethernet: bgmac: driver power manangement
Implement suspend/resume callbacks in the bgmac driver. This makes sure that we de-initialize and re-initialize the hardware correctly before entering suspend and when resuming.
Signed-off-by: Joey Zhong <zhongx@broadcom.com> Signed-off-by: Jon Mason <jon.mason@broadcom.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
02083c3a |
| 28-Feb-2017 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: use #defines for MAX size
The maximum frame size is really just the standard ethernet frame size and FCS. So use those existing defines to make the code a little more beautifu
net: ethernet: bgmac: use #defines for MAX size
The maximum frame size is really just the standard ethernet frame size and FCS. So use those existing defines to make the code a little more beautiful.
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
16206524 |
| 02-Mar-2017 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: init sequence bug
Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately ma
net: ethernet: bgmac: init sequence bug
Fix a bug in the 'bgmac' driver init sequence that blind writes for init sequence where it should preserve most bits other than the ones it is deliberately manipulating.
The code now checks to see if the adapter needs to be brought out of reset (where as before it was doing an IDM write to bring it out of reset regardless of whether it was in reset or not). Also, removed unnecessary usleeps (as there is already a read present to flush the IDM writes).
Signed-off-by: Zac Schroff <zschroff@broadcom.com> Signed-off-by: Jon Mason <jon.mason@broadcom.com> Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support") Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.10.1, v4.10 |
|
#
6850f8b5 |
| 16-Feb-2017 |
Tobias Klauser <tklauser@distanz.ch> |
net: bgmac: store MAC address directly in netdev->dev_addr
After commit 34a5102c3235 ("net: bgmac: allocate struct bgmac just once & don't copy it") the mac_addr member of struct bgmac is no longer
net: bgmac: store MAC address directly in netdev->dev_addr
After commit 34a5102c3235 ("net: bgmac: allocate struct bgmac just once & don't copy it") the mac_addr member of struct bgmac is no longer necessary to pass the MAC address to bgmac_enet_probe(). Instead it can directly be stored in netdev->dev_addr.
Also use eth_hw_addr_random() instead of eth_random_addr() in case a random MAC is nedded. This will make sure netdev->addr_assign_type will be properly set.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Acked-by: Jon Mason <jon.mason@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
aa8863e5 |
| 31-Jan-2017 |
Rafał Miłecki <rafal@milecki.pl> |
net: bgmac: drop struct bcma_mdio we don't need anymore
Adding struct bcma_mdio was a workaround for bcma code not having access to the struct bgmac used in the core code. Now we don't duplicate thi
net: bgmac: drop struct bcma_mdio we don't need anymore
Adding struct bcma_mdio was a workaround for bcma code not having access to the struct bgmac used in the core code. Now we don't duplicate this struct we can just use it internally in bcma code.
This simplifies code & allows access to all bgmac driver details from all places in bcma code.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
34a5102c |
| 31-Jan-2017 |
Rafał Miłecki <rafal@milecki.pl> |
net: bgmac: allocate struct bgmac just once & don't copy it
So far were were allocating struct bgmac in 3 places: platform code, bcma code and shared bgmac_enet_probe function. The reason for this w
net: bgmac: allocate struct bgmac just once & don't copy it
So far were were allocating struct bgmac in 3 places: platform code, bcma code and shared bgmac_enet_probe function. The reason for this was bgmac_enet_probe: 1) Requiring early-filled struct bgmac 2) Calling alloc_etherdev on its own in order to use netdev_priv later
This solution got few drawbacks: 1) Was duplicating allocating code 2) Required copying early-filled struct 3) Resulted in platform/bcma code having access only to unused struct
Solve this situation by simply extracting some probe code into the new bgmac_alloc function.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31 |
|
#
dd5c5d03 |
| 04-Nov-2016 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: add NS2 support
Add support for the variant of amac hardware present in the Broadcom Northstar2 based SoCs. Northstar2 requires an additional register to be configured with th
net: ethernet: bgmac: add NS2 support
Add support for the variant of amac hardware present in the Broadcom Northstar2 based SoCs. Northstar2 requires an additional register to be configured with the port speed/duplexity (NICPM). This can be added to the link callback to hide it from the instances that do not use this. Also, clearing of the pending interrupts on init is required due to observed issues on some platforms.
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
1676aba5 |
| 04-Nov-2016 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: device tree phy enablement
Change the bgmac driver to allow for phy's defined by the device tree
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Acked-by: Rafał Miłecki <raf
net: ethernet: bgmac: device tree phy enablement
Change the bgmac driver to allow for phy's defined by the device tree
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Acked-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1 |
|
#
1cb94db3 |
| 17-Aug-2016 |
Rafał Miłecki <rafal@milecki.pl> |
net: bgmac: support Ethernet core on BCM53573 SoCs
BCM53573 is a new series of Broadcom's SoCs. It's based on ARM and can be found in two packages (versions): BCM53573 and BCM47189. It shares some c
net: bgmac: support Ethernet core on BCM53573 SoCs
BCM53573 is a new series of Broadcom's SoCs. It's based on ARM and can be found in two packages (versions): BCM53573 and BCM47189. It shares some code with the Northstar family, but also requires some new quirks.
First of all there can be up to 2 Ethernet cores on this SoC. If that is the case, they are connected to two different switch ports allowing some more complex/optimized setups. It seems the second unit doesn't come fully configured and requires some IRQ quirk.
Other than that only the first core is connected to the PHY. For the second one we have to register fixed PHY (similarly to the Northstar), otherwise generic PHY driver would get some invalid info.
This has been successfully tested on Tenda AC9 (BCM47189B0).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4 |
|
#
f6a95a24 |
| 07-Jul-2016 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: Add platform device support
The bcma portion of the driver has been split off into a bcma specific driver. This has been mirrored for the platform driver. The last references
net: ethernet: bgmac: Add platform device support
The bcma portion of the driver has been split off into a bcma specific driver. This has been mirrored for the platform driver. The last references to the bcma core struct have been changed into a generic function call. These function calls are wrappers to either the original bcma code or new platform functions that access the same areas via MMIO. This necessitated adding function pointers for both platform and bcma to hide which backend is being used from the generic bgmac code.
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
db791eb2 |
| 07-Jul-2016 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: convert to feature flags
The bgmac driver is using the bcma provides device ID and revision, as well as the SoC ID and package, to determine which features are necessary to ena
net: ethernet: bgmac: convert to feature flags
The bgmac driver is using the bcma provides device ID and revision, as well as the SoC ID and package, to determine which features are necessary to enable, reset, etc in the driver. In anticipation of removing the bcma requirement for this driver, these must be changed to not reference that struct. In place of that, each "feature" has been given a flag, and the flags are enabled for their respective device and SoC.
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
55954f3b |
| 07-Jul-2016 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file
Move the BCMA MDIO phy into a separate file, as it is very tightly coupled with the BCMA bus. This will help with the upcoming BCM
net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file
Move the BCMA MDIO phy into a separate file, as it is very tightly coupled with the BCMA bus. This will help with the upcoming BCMA removal from the bgmac driver. Optimally, this should be moved into phy drivers, but it is too tightly coupled with the bgmac driver to effectively move it without more changes to the driver.
Note: the phy_reset was intentionally removed, as the mdio phy subsystem automatically resets the phy if a reset function pointer is present. In addition to the moving of the driver, this reset function is added.
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
a0b68486 |
| 07-Jul-2016 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: add dma_dev pointer
The dma buffer allocation, etc references a dma_dev device pointer from the bcma core. In anticipation of removing the bcma requirement for this driver, th
net: ethernet: bgmac: add dma_dev pointer
The dma buffer allocation, etc references a dma_dev device pointer from the bcma core. In anticipation of removing the bcma requirement for this driver, these must be changed to not reference that struct. Add a dma_dev device pointer to the bgmac stuct and reference that instead.
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d00a8281 |
| 07-Jul-2016 |
Jon Mason <jon.mason@broadcom.com> |
net: ethernet: bgmac: change bgmac_* prints to dev_* prints
The bgmac_* print wrappers call dev_* prints with the dev pointer from the bcma core. In anticipation of removing the bcma requirement fo
net: ethernet: bgmac: change bgmac_* prints to dev_* prints
The bgmac_* print wrappers call dev_* prints with the dev pointer from the bcma core. In anticipation of removing the bcma requirement for this driver, these must be changed to not reference that struct. So, simply change all of the bgmac_* prints to their dev_* counterparts. In some cases netdev_* prints are more appropriate, so change those as well.
Signed-off-by: Jon Mason <jon.mason@broadcom.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.6.3, v4.4.14 |
|
#
b21fcb25 |
| 19-Jun-2016 |
Philippe Reynes <tremyfr@gmail.com> |
net: ethernet: bgmac: use phydev from struct net_device
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phy
net: ethernet: bgmac: use phydev from struct net_device
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v4.6.2, v4.4.13 |
|
#
f6613d4f |
| 07-Jun-2016 |
Florian Fainelli <f.fainelli@gmail.com> |
bgmac: Add support for ethtool statistics
Read the statistics from the BGMAC's builtin MAC and return them to user-space using the standard ethtool helpers.
Signed-off-by: Florian Fainelli <f.faine
bgmac: Add support for ethtool statistics
Read the statistics from the BGMAC's builtin MAC and return them to user-space using the standard ethtool helpers.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8 |
|
#
c02bc350 |
| 12-Apr-2016 |
Felix Fietkau <nbd@openwrt.org> |
bgmac: fix MAC soft-reset bit for corerev > 4
Only core revisions older than 4 use BGMAC_CMDCFG_SR_REV0. This mainly fixes support for BCM4708A0KF SoCs with Ethernet core rev 5 (it means only some d
bgmac: fix MAC soft-reset bit for corerev > 4
Only core revisions older than 4 use BGMAC_CMDCFG_SR_REV0. This mainly fixes support for BCM4708A0KF SoCs with Ethernet core rev 5 (it means only some devices as most of BCM4708A0KF-s got core rev 4). This was tested for regressions on BCM47094 which doesn't seem to care which bit gets used.
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|