Martin Habets says:

====================
Move Siena into a separate subdirectory

The Siena NICs (SFN5000 and SFN6000 series) went EOL in November 2021.
Most of these adapters have been remove from our test labs, and testing
has been reduced to a minimum.

This patch series creates a separate kernel module for the Siena architecture,
analogous to what was done for Falcon some years ago.
This reduces our maintenance for the sfc.ko module, and allows us to
enhance the EF10 and EF100 drivers without the risk of breaking Siena NICs.

After this series further enhancements are needed to differentiate the
new kernel module from sfc.ko, and the Siena code can be removed from sfc.ko.
Thes will be posted as a small follow-up series.
The Siena module is not built by default, but can be enabled
using Kconfig option SFC_SIENA. This will create module sfc-siena.ko.

	Patches

Patches 1-3 establish the code base for the Siena driver.
Patches 4-10 ensure the allyesconfig build succeeds.
Patch 11 adds the basic Siena module.

I do not expect patch 1 through 3 to be reviewed, they are FYI only.
No checkpatch issues were resolved as part of these, but they
were fixed in the subsequent patches.

	Testing

Various build tests were done such as allyesconfig, W=1 and sparse.
The new sfc-siena.ko and sfc.ko modules were tested on a machine with both
these NICs in them, and several tests were run on both drivers.
====================

Link: https://lore.kernel.org/r/165211018297.5289.9658523545298485394.stgit@palantir17.mph.netSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Make the (un)load message more specific to differentiate it from
the sfc.ko messages.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The implementation of each is quite short. This means sriov.c is
not needed any more.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

For siena use efx_siena_ as the function prefix.
efx_nic_update_stats_atomic is only used in efx_common.c, so move
it there.
efx_nic_copy_stats is not used in Siena, so it is removed.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

For siena use efx_siena_ as the function prefix.
Several functions are not used in Siena, so they are removed.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

For siena use efx_siena_ as the function prefix.
This patch covers selftest.h, ptp.h, net_driver.h and ethtool_common.h.
efx_ethtool_fill_self_tests() can become static.
Some functions in ptp.c can also become static.
Rename loopback_mode in net_driver.h.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

For siena use efx_siena_ as the function prefix.
Several functions are not used in Siena, so they are removed.

Use a Siena specific variable name for module parameter
efx_separate_tx_channels.
Move efx_fini_tx_queue() to avoid a forward declaration of
efx_dequeue_buffer().
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

When building with allyesconfig there are many identical
symbol names.
For siena use efx_siena_ as the function and variable prefix
to avoid build errors.

efx_mtd_remove_partition can become static as it is no longer called
from other files.
efx_ticks_to_usecs and efx_xmit_done_single are not used in Siena, so
they are removed.
Several functions are only used inside efx_channels.c for Siena so
they can become static.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Functionality not supported or needed on Siena includes:
- Anything for EF100
- EF10 specifics such as register access, PIO and TSO offload.
Also only bind to Siena NICs.

Remove EF10 specifics from nic.h.
The functions that start with efx_farch_ will be removed from sfc.ko
with a subsequent patch.
Add the efx_ prefix to siena_prepare_flush() to make it consistent
with the other APIs.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

These are the files starting with m through w.
No changes are done, those will be done with subsequent commits.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

These are the files starting with b through i.
No changes are done, those will be done with subsequent commits.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Files are only moved, no changes are made.
Signed-off-by: NMartin Habets <habetsm.xilinx@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Kernel test robot reported an issue after a recent patch about an
unused variable when CONFIG_IPV6 is disabled. Move the variable
declaration to be inside the #ifdef, and do a bit more cleanup. There
is no need to use a temporary ipv6 bool value, it is just checked once,
remove the extra variable and just do the check directly.

Fixes: 9d5447ed ("nfp: flower: fixup ipv6/ipv4 route lookup for neigh events")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NLouis Peens <louis.peens@corigine.com>
Signed-off-by: NSimon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20220510074845.41457-1-simon.horman@corigine.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Pointer dev is being assigned a value that is never used, the assignment
and the variable are redundant and can be removed. Also replace null check
with the preferred !ptr idiom.

Cleans up clang scan warning:
net/x25/x25_proc.c:94:26: warning: Although the value stored to 'dev' is
used in the enclosing expression, the value is never actually read
from 'dev' [deadcode.DeadStores]
Signed-off-by: NColin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20220508214500.60446-1-colin.i.king@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

Wells Lu says:

====================
This is a patch series for Ethernet driver of Sunplus SP7021 SoC.

Sunplus SP7021 is an ARM Cortex A7 (4 cores) based SoC. It integrates
many peripherals (ex: UART, I2C, SPI, SDIO, eMMC, USB, SD card and
etc.) into a single chip. It is designed for industrial control
applications.

Refer to:
https://sunplus.atlassian.net/wiki/spaces/doc/overview
https://tibbo.com/store/plus1.html
====================

Link: https://lore.kernel.org/r/1652004800-3212-1-git-send-email-wellslutw@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

Add driver for Sunplus SP7021 SoC.
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWells Lu <wellslutw@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

Add bindings documentation for Sunplus SP7021 SoC.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NWells Lu <wellslutw@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

Gerhard Engleder says:

====================
ptp: Support hardware clocks with additional free running cycle counter

ptp vclocks require a clock with free running time for the timecounter.
Currently only a physical clock forced to free running is supported.
If vclocks are used, then the physical clock cannot be synchronized
anymore. The synchronized time is not available in hardware in this
case. As a result, timed transmission with TAPRIO hardware support
is not possible anymore.

If hardware would support a free running time additionally to the
physical clock, then the physical clock does not need to be forced to
free running. Thus, the physical clocks can still be synchronized while
vclocks are in use.

The physical clock could be used to synchronize the time domain of the
TSN network and trigger TAPRIO. In parallel vclocks can be used to
synchronize other time domains.

One year ago I thought for two time domains within a TSN network also
two physical clocks are required. This would lead to new kernel
interfaces for asking for the second clock, ... . But actually for a
time triggered system like TSN there can be only one time domain that
controls the system itself. All other time domains belong to other
layers, but not to the time triggered system itself. So other time
domains can be based on a free running counter if similar mechanisms
like 2 step synchroisation are used.

Synchronisation was tested with two time domains between two directly
connected hosts. Each host run two ptp4l instances, the first used the
physical clock and the second used the virtual clock. I used my FPGA
based network controller as network device. ptp4l was used in
combination with the virtual clock support patches from Miroslav
Lichvar.

v4:
- if_index of 0 is invalid (Jonathan Lemon)
- set if_index to 0 in the SOF_TIMESTAMPING_RAW_HARDWARE block (Jonathan
  Lemon)
- add helper function for netdev_get_tstamp() call (Jonathan Lemon)
- update SKBTX_ANY_TSTAMP (Paolo Abeni)
- use separate bits for new tx_flags (Richard Cochran)

v3:
- optimize ptp_convert_timestamp (Richard Cochran)
- call dev_get_by_napi_id() only if needed (Richard Cochran)
- use non-negated logical test (Richard Cochran)
- add comment for skipped output (Richard Cochran)
- add comment for SKBTX_HW_TSTAMP_USE_CYCLES masking (Richard Cochran)

v2:
- rename ptp_clock cycles to has_cycles (Richard Cochran)
- call it free running cycle counter (Richard Cochran)
- update struct skb_shared_hwtstamps kdoc (Richard Cochran)
- optimize timestamp address/cookie processing path (Richard Cochran,
  Vinicius Costa Gomes)

v1:
- complete rework based on suggestions (Richard Cochran)
====================

Link: https://lore.kernel.org/r/20220506200142.3329-1-gerhard@engleder-embedded.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

The TSN endpoint Ethernet MAC supports a free running counter
additionally to its clock. This free running counter can be read and
hardware timestamps are supported. As the name implies, this counter
cannot be set and its frequency cannot be adjusted.

Add free running cycle counter support based on this free running
counter to physical clock. This also requires hardware time stamps
based on that free running counter.
Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
Acked-by: NJonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

ptp_convert_timestamp() is called in the RX path of network messages.
The current implementation takes ~5000ns on 1.2GHz A53. This is too much
for the hot path of packet processing.

Introduce hash table for fast vclock lookup in ptp_convert_timestamp().
The execution time of ptp_convert_timestamp() is reduced to ~700ns on
1.2GHz A53.
Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

If a physical clock supports a free running cycle counter, then
timestamps shall be based on this time too. For TX it is known in
advance before the transmission if a timestamp based on the free running
cycle counter is needed. For RX it is impossible to know which timestamp
is needed before the packet is received and assigned to a socket.

Support late timestamp determination by a network device. Therefore, an
address/cookie is stored within the new netdev_data field of struct
skb_shared_hwtstamps. This address/cookie is provided to a new network
device function called ndo_get_tstamp(), which returns a timestamp based
on the normal/adjustable time or based on the free running cycle
counter. If function is not supported, then timestamp handling is not
changed.

This mechanism is intended for RX, but TX use is also possible.
Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
Acked-by: NJonathan Lemon <jonathan.lemon@gmail.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

ptp_convert_timestamp() converts only the timestamp hwtstamp, which is
a field of the argument with the type struct skb_shared_hwtstamps *. So
a pointer to the hwtstamp field of this structure is sufficient.

Rework ptp_convert_timestamp() to use an argument of type ktime_t *.
This allows to add additional timestamp manipulation stages before the
call of ptp_convert_timestamp().
Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

The free running cycle counter of physical clocks called cycles shall be
used for hardware timestamps to enable synchronisation.

Introduce new flag SKBTX_HW_TSTAMP_USE_CYCLES, which signals driver to
provide a TX timestamp based on cycles if cycles are supported.
Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

ptp vclocks require a free running time for their timecounter.
Currently only a physical clock forced to free running is supported.
If vclocks are used, then the physical clock cannot be synchronized
anymore. The synchronized time is not available in hardware in this
case. As a result, timed transmission with TAPRIO hardware support
is not possible anymore.

If hardware would support a free running time additionally to the
physical clock, then the physical clock does not need to be forced to
free running. Thus, the physical clocks can still be synchronized
while vclocks are in use.

The physical clock could be used to synchronize the time domain of the
TSN network and trigger TAPRIO. In parallel vclocks can be used to
synchronize other time domains.

Introduce support for a free running cycle counter called cycles to
physical clocks. Rework ptp vclocks to use this free running cycle
counter. Default implementation is based on time of physical clock.
Thus, behavior of ptp vclocks based on physical clocks without free
running cycle counter is identical to previous behavior.
Signed-off-by: NGerhard Engleder <gerhard@engleder-embedded.com>
Acked-by: NRichard Cochran <richardcochran@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

Since commit 4e30e98c ("dpaa2-mac: return -EPROBE_DEFER from dpaa2_mac_open in case the fwnode is not set")
@parent can't be NULL after the if. It's either the address
of the ->fwnode of @dpmacs or @fwnode in case of ACPI.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20220506200029.852310-1-kuba@kernel.orgSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

Simon Horman says:

====================
nfp: support Corigine PCIE vendor ID

Historically the nfp driver has supported NFP chips with Netronome's
PCIE vendor ID. This patch extends the driver to also support NFP
chips, which at this point are assumed to be otherwise identical from
a software perspective, that have Corigine's PCIE vendor ID (0x1da8).

This patchset begins by cleaning up strings to make them:
* Vendor neutral for the NFP chip
* Relate to Corigine for the driver itself

It then adds support to the driver for the Corigine's PCIE vendor ID
====================

Link: https://lore.kernel.org/r/20220508173816.476357-1-simon.horman@corigine.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Historically the nfp driver has supported NFP chips with Netronome's
PCIE vendor ID. This patch extends the driver to also support NFP
chips, which at this point are assumed to be otherwise identical from
a software perspective, that have Corigine's PCIE vendor ID (0x1da8).

Also, Rename the macro definitions PCI_DEVICE_ID_NERTONEOME_NFPXXXX
to PCI_DEVICE_ID_NFPXXXX, as they are now used in conjunction with two
PCIE vendor IDs.
Signed-off-by: NYu Xiao <yu.xiao@corigine.com>
Signed-off-by: NYinjun Zhang <yinjun.zhang@corigine.com>
Signed-off-by: NSimon Horman <simon.horman@corigine.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Historically the nfp driver has supported NFP chips with Netronome's
PCIE vendor ID. In preparation for extending the to also support NFP
chips that have Corigine's PCIE vendor ID (0x1da8) make printk statements
relating to the chip vendor neutral.

An alternate approach is to set the string based on the PCI vendor ID.
In our judgement this proved to cumbersome so we have taken this simpler
approach.

Update strings relating to the driver to use Corigine, who have taken
over maintenance of the driver.
Signed-off-by: NYu Xiao <yu.xiao@corigine.com>
Signed-off-by: NYinjun Zhang <yinjun.zhang@corigine.com>
Signed-off-by: NSimon Horman <simon.horman@corigine.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Tony Nguyen says:

====================
100GbE Intel Wired LAN Driver Updates 2022-05-06

Marcin Szycik says:

This patchset adds support for systemd defined naming scheme for port
representors, as well as re-enables displaying PCI bus-info in ethtool.

bus-info information has previously been removed from ethtool for port
representors, as a workaround for a bug in lshw tool, where the tool would
sometimes display wrong descriptions for port representors/PF. Now the bug
has been fixed in lshw tool [1].

Removing the workaround can be considered a regression (user might be
running an older, unpatched version of lshw) (see [2] for discussion).
However, calling SET_NETDEV_DEV also produces the same effect as removing
the workaround, i.e. lshw is able to access PCI bus-info (this time not
via ethtool, but in some other way) and the bug can occur.

Adding SET_NETDEV_DEV is important, as it greatly improves netdev naming -
- port representors are named based on PF name. Currently port representors
are named "ethX", which might be confusing, especially when spawning VFs on
multiple PFs. Furthermore, it's currently harder to determine to which PF
does a particular port representor belong, as bus-info is not shown in
ethtool.

Consider the following three cases:

Case 1: current code - driver workaround in place, no SET_NETDEV_DEV,
lshw with or without fix. Port representors are not displayed because they
don't have bus-info (the workaround), PFs are labelled correctly:

$ sudo ./lshw -c net -businfo
Bus info          Device      Class          Description
========================================================
pci@0000:02:00.0  ens6f0      network        Ethernet Controller E810-XXV for SFP <-- PF
pci@0000:02:00.1  ens6f1      network        Ethernet Controller E810-XXV for SFP
pci@0000:02:01.0  ens6f0v0    network        Ethernet Adaptive Virtual Function <-- VF
pci@0000:02:01.1  ens6f0v1    network        Ethernet Adaptive Virtual Function
...

Case 2: driver workaround in place, SET_NETDEV_DEV, no lshw fix. Port
representors have predictable names. lshw is able to get bus-info because
of SET_NETDEV_DEV and netdevs CAN be mislabelled:

$ sudo ./lshw -c net -businfo
Bus info          Device           Class          Description
=============================================================
pci@0000:02:00.0  ens6f0npf0vf60   network        Ethernet Controller E810-XXV for SFP <-- mislabeled port representor
pci@0000:02:00.1  ens6f1           network        Ethernet Controller E810-XXV for SFP
pci@0000:02:01.0  ens6f0v0         network        Ethernet Adaptive Virtual Function
pci@0000:02:01.1  ens6f0v1         network        Ethernet Adaptive Virtual Function
...
pci@0000:02:00.0  ens6f0npf0vf26   network        Ethernet interface
pci@0000:02:00.0  ens6f0           network        Ethernet interface <-- mislabeled PF
pci@0000:02:00.0  ens6f0npf0vf81   network        Ethernet interface
...
$ sudo ethtool -i ens6f0npf0vf60
driver: ice
...
bus-info:
...

Output of lshw would be the same with workaround removed; it does not
change the fact that lshw labels netdevs incorrectly, while at the same
time it prevents ethtool from displaying potentially useful data
(bus-info).

Case 3: workaround removed, SET_NETDEV_DEV, lshw fix:

$ sudo ./lshw -c net -businfo
Bus info          Device           Class          Description
=============================================================
pci@0000:02:00.0  ens6f0npf0vf73   network        Ethernet Controller E810-XXV for SFP
pci@0000:02:00.1  ens6f1           network        Ethernet Controller E810-XXV for SFP
pci@0000:02:01.0  ens6f0v0         network        Ethernet Adaptive Virtual Function
pci@0000:02:01.1  ens6f0v1         network        Ethernet Adaptive Virtual Function
...
pci@0000:02:00.0  ens6f0npf0vf5    network        Ethernet Controller E810-XXV for SFP
pci@0000:02:00.0  ens6f0           network        Ethernet Controller E810-XXV for SFP
pci@0000:02:00.0  ens6f0npf0vf60   network        Ethernet Controller E810-XXV for SFP
...
$ sudo ethtool -i ens6f0npf0vf73
driver: ice
...
bus-info: 0000:02:00.0
...

In this case poort representors have predictable names, netdevs are not
mislabelled in lshw, and bus-info is shown in ethtool.

[1] https://ezix.org/src/pkg/lshw/commit/9bf4e4c9c1
[2] https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20220321144731.3935-1-marcin.szycik@linux.intel.com

* '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
  Revert "ice: Hide bus-info in ethtool for PRs in switchdev mode"
  ice: link representors to PCI device
====================

Link: https://lore.kernel.org/r/20220506180052.5256-1-anthony.l.nguyen@intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Eliminate the follow smatch warning:

net/rose/rose_route.c:1136 rose_node_show() warn: inconsistent
indenting.
Reported-by: NAbaci Robot <abaci@linux.alibaba.com>
Signed-off-by: NJiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220507034207.18651-1-jiapeng.chong@linux.alibaba.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Guangbin Huang says:

====================
net: hns3: updates for -next

This series includes some updates for the HNS3 ethernet driver.

Change logs:
V1 -> V2:
 - Fix some sparse warnings of patch 3# and 4#.
 - Add patch #6 to fix sparse warnings of incorrect type of argument.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The argument rss_ind_tbl_size is type u16 in function definition of
hclge_comm_get_rss_indir_tbl(), but it is set to type __le16 in function
declaration by mistake, so fix it.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds a new mailbox opcode to query map relation between
vf ring and vector.
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch uses __le16/__32 to define mailbox data structures. Then byte
order conversion are added for mailbox messages from VF to PF.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, hns3 mailbox processing between PF and VF missed to convert
message byte order and use data type u16 instead of __le16 for mailbox
data process. These processes may cause problems between different
architectures.

So this patch uses __le16/__le32 data type to define mailbox data
structures. To be compatible with old hns3 driver, these structures use
one-byte alignment. Then byte order conversions are added to mailbox
messages from PF to VF.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Vector0 is used for common interrupt control events and is
irrelevant to performance. Currently, the driver sets the
default affinity of vector0 to NUMA nodes, which is unnecessary.
Therefore, the default setting is removed, and the driver does
not set the affinity for vector0.
Signed-off-by: NYufeng Mo <moyufeng@huawei.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When set tx-buf-size as 0 by ethtool, hns3_init_tx_spare_buffer()
will return directly and priv->ring->tx_spare->len is uninitialized,
then print function access priv->ring->tx_spare->len will cause
this issue.

When set tx-buf-size as 0 by ethtool, the print function will
print 0 directly and not access priv->ring->tx_spare->len.

Fixes: 2373b35c ("net: hns3: add log for setting tx spare buf size")
Signed-off-by: NHao Chen <chenhao288@hisilicon.com>
Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Yuiko Oshino says:

====================
net: phy: add LAN8742 phy support

add LAN8742 phy support
update LAN88xx phy ID and phy ID mask so that it can coexist with LAN8742

The current phy IDs on the available hardware.
    LAN8742 0x0007C130, 0x0007C131
    LAN88xx 0x0007C132

v3->v4:
- fixed the one tab missing issue in the smsc.c.

v2->v3:
-added comments about the 0xfffffff2 mask that is for the differentiation and the future revisions.

v1->v2:
-removed "REVIEW REQUEST3" from the PATCH 1/2.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The current phy IDs on the available hardware.
        LAN8742 0x0007C130, 0x0007C131
Signed-off-by: NYuiko Oshino <yuiko.oshino@microchip.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

update LAN88xx phy ID and phy ID mask because the existing code conflicts with the LAN8742 phy.

The current phy IDs on the available hardware.
        LAN8742 0x0007C130, 0x0007C131
        LAN88xx 0x0007C132
Signed-off-by: NYuiko Oshino <yuiko.oshino@microchip.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>