ksz8795 and ksz9477 implementation on phy read/write hooks are
different. This patch modifies the ksz9477 implementation same as
ksz8795 by updating the ksz9477_dev_ops structure.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

This patch move the dsa hook get_tag_protocol to ksz_common file. And
the tag_protocol is returned based on the dev->chip_id.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

KSZ87xx and KSZ88xx have chip_id representation at reg location 0. And
KSZ9477 compatible switch and LAN937x switch have same chip_id detection
at location 0x01 and 0x02. To have the common switch detect
functionality for ksz switches, ksz_switch_detect function is
introduced.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

The ksz9477_switch_detect performs the detecting the chip id from the
location 0x00 and also check gigabit compatibility check & number of
ports based on the register global_options0. To prepare the common ksz
switch detect function, routine other than chip id read is moved to
ksz9477_switch_init.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

When adjusting the PTP clock, the base time of the TAS configuration
will become unreliable. We need reset the TAS configuration by using a
new base time.

For example, if the driver gets a base time 0 of Qbv configuration from
user, and current time is 20000. The driver will set the TAS base time
to be 20000. After the PTP clock adjustment, the current time becomes
10000. If the TAS base time is still 20000, it will be a future time,
and TAS entry list will stop running. Another example, if the current
time becomes to be 10000000 after PTP clock adjust, a large time offset
can cause the hardware to hang.

This patch introduces a tas_clock_adjust() function to reset the TAS
module by using a new base time after the PTP clock adjustment. This can
avoid issues above.

Due to PTP clock adjustment can occur at any time, it may conflict with
the TAS configuration. We introduce a new TAS lock to serialize the
access to the TAS registers.
Signed-off-by: NXiaoliang Yang <xiaoliang.yang_1@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Rework MDIO locking to avoid potential  circular locking:

 WARNING: possible circular locking dependency detected
 5.19.0-rc1-ar9331-00017-g3ab364c7c48c #5 Not tainted
 ------------------------------------------------------
 kworker/u2:4/68 is trying to acquire lock:
 81f3c83c (ar9331:1005:(&ar9331_mdio_regmap_config)->lock){+.+.}-{4:4}, at: regmap_write+0x50/0x8c

 but task is already holding lock:
 81f60494 (&bus->mdio_lock){+.+.}-{4:4}, at: mdiobus_read+0x40/0x78

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #1 (&bus->mdio_lock){+.+.}-{4:4}:
        lock_acquire+0x2d4/0x360
        __mutex_lock+0xf8/0x384
        mutex_lock_nested+0x2c/0x38
        mdiobus_write+0x44/0x80
        ar9331_sw_bus_write+0x50/0xe4
        _regmap_raw_write_impl+0x604/0x724
        _regmap_bus_raw_write+0x9c/0xb4
        _regmap_write+0xdc/0x1a0
        _regmap_update_bits+0xf4/0x118
        _regmap_select_page+0x108/0x138
        _regmap_raw_read+0x25c/0x288
        _regmap_bus_read+0x60/0x98
        _regmap_read+0xd4/0x1b0
        _regmap_update_bits+0xc4/0x118
        regmap_update_bits_base+0x64/0x8c
        ar9331_sw_irq_bus_sync_unlock+0x40/0x6c
        __irq_set_handler+0x7c/0xac
        ar9331_sw_irq_map+0x48/0x7c
        irq_domain_associate+0x174/0x208
        irq_create_mapping_affinity+0x1a8/0x230
        ar9331_sw_probe+0x22c/0x388
        mdio_probe+0x44/0x70
        really_probe+0x200/0x424
        __driver_probe_device+0x290/0x298
        driver_probe_device+0x54/0xe4
        __device_attach_driver+0xe4/0x130
        bus_for_each_drv+0xb4/0xd8
        __device_attach+0x104/0x1a4
        bus_probe_device+0x48/0xc4
        device_add+0x600/0x800
        mdio_device_register+0x68/0xa0
        of_mdiobus_register+0x2bc/0x3c4
        ag71xx_probe+0x6e4/0x984
        platform_probe+0x78/0xd0
        really_probe+0x200/0x424
        __driver_probe_device+0x290/0x298
        driver_probe_device+0x54/0xe4
        __driver_attach+0x17c/0x190
        bus_for_each_dev+0x8c/0xd0
        bus_add_driver+0x110/0x228
        driver_register+0xe4/0x12c
        do_one_initcall+0x104/0x2a0
        kernel_init_freeable+0x250/0x288
        kernel_init+0x34/0x130
        ret_from_kernel_thread+0x14/0x1c

 -> #0 (ar9331:1005:(&ar9331_mdio_regmap_config)->lock){+.+.}-{4:4}:
        check_noncircular+0x88/0xc0
        __lock_acquire+0x10bc/0x18bc
        lock_acquire+0x2d4/0x360
        __mutex_lock+0xf8/0x384
        mutex_lock_nested+0x2c/0x38
        regmap_write+0x50/0x8c
        ar9331_sw_mbus_read+0x74/0x1b8
        __mdiobus_read+0x90/0xec
        mdiobus_read+0x50/0x78
        get_phy_device+0xa0/0x18c
        fwnode_mdiobus_register_phy+0x120/0x1d4
        of_mdiobus_register+0x244/0x3c4
        devm_of_mdiobus_register+0xe8/0x100
        ar9331_sw_setup+0x16c/0x3a0
        dsa_register_switch+0x7dc/0xcc0
        ar9331_sw_probe+0x370/0x388
        mdio_probe+0x44/0x70
        really_probe+0x200/0x424
        __driver_probe_device+0x290/0x298
        driver_probe_device+0x54/0xe4
        __device_attach_driver+0xe4/0x130
        bus_for_each_drv+0xb4/0xd8
        __device_attach+0x104/0x1a4
        bus_probe_device+0x48/0xc4
        deferred_probe_work_func+0xf0/0x10c
        process_one_work+0x314/0x4d4
        worker_thread+0x2a4/0x354
        kthread+0x134/0x13c
        ret_from_kernel_thread+0x14/0x1c

 other info that might help us debug this:

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&bus->mdio_lock);
                                lock(ar9331:1005:(&ar9331_mdio_regmap_config)->lock);
                                lock(&bus->mdio_lock);
   lock(ar9331:1005:(&ar9331_mdio_regmap_config)->lock);

  *** DEADLOCK ***

 5 locks held by kworker/u2:4/68:
  #0: 81c04eb4 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1e4/0x4d4
  #1: 81f0de78 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1e4/0x4d4
  #2: 81f0a880 (&dev->mutex){....}-{4:4}, at: __device_attach+0x40/0x1a4
  #3: 80c8aee0 (dsa2_mutex){+.+.}-{4:4}, at: dsa_register_switch+0x5c/0xcc0
  #4: 81f60494 (&bus->mdio_lock){+.+.}-{4:4}, at: mdiobus_read+0x40/0x78

 stack backtrace:
 CPU: 0 PID: 68 Comm: kworker/u2:4 Not tainted 5.19.0-rc1-ar9331-00017-g3ab364c7c48c #5
 Workqueue: events_unbound deferred_probe_work_func
 Stack : 00000056 800d4638 81f0d64c 00000004 00000018 00000000 80a20000 80a20000
         80937590 81ef3858 81f0d760 3913578a 00000005 8045e824 81f0d600 a8db84cc
         00000000 00000000 80937590 00000a44 00000000 00000002 00000001 ffffffff
         81f0d6a4 80982d7c 0000000f 20202020 80a20000 00000001 80937590 81ef3858
         81f0d760 3913578a 00000005 00000005 00000000 03bd0000 00000000 80e00000
         ...
 Call Trace:
 [<80069db0>] show_stack+0x94/0x130
 [<8045e824>] dump_stack_lvl+0x54/0x8c
 [<800c7fac>] check_noncircular+0x88/0xc0
 [<800ca068>] __lock_acquire+0x10bc/0x18bc
 [<800cb478>] lock_acquire+0x2d4/0x360
 [<807b84c4>] __mutex_lock+0xf8/0x384
 [<807b877c>] mutex_lock_nested+0x2c/0x38
 [<804ea640>] regmap_write+0x50/0x8c
 [<80501e38>] ar9331_sw_mbus_read+0x74/0x1b8
 [<804fe9a0>] __mdiobus_read+0x90/0xec
 [<804feac4>] mdiobus_read+0x50/0x78
 [<804fcf74>] get_phy_device+0xa0/0x18c
 [<804ffeb4>] fwnode_mdiobus_register_phy+0x120/0x1d4
 [<805004f0>] of_mdiobus_register+0x244/0x3c4
 [<804f0c50>] devm_of_mdiobus_register+0xe8/0x100
 [<805017a0>] ar9331_sw_setup+0x16c/0x3a0
 [<807355c8>] dsa_register_switch+0x7dc/0xcc0
 [<80501468>] ar9331_sw_probe+0x370/0x388
 [<804ff0c0>] mdio_probe+0x44/0x70
 [<804d1848>] really_probe+0x200/0x424
 [<804d1cfc>] __driver_probe_device+0x290/0x298
 [<804d1d58>] driver_probe_device+0x54/0xe4
 [<804d2298>] __device_attach_driver+0xe4/0x130
 [<804cf048>] bus_for_each_drv+0xb4/0xd8
 [<804d200c>] __device_attach+0x104/0x1a4
 [<804d026c>] bus_probe_device+0x48/0xc4
 [<804d108c>] deferred_probe_work_func+0xf0/0x10c
 [<800a0ffc>] process_one_work+0x314/0x4d4
 [<800a17fc>] worker_thread+0x2a4/0x354
 [<800a9a54>] kthread+0x134/0x13c
 [<8006306c>] ret_from_kernel_thread+0x14/0x1c
[
Signed-off-by: NOleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20220616112550.877118-1-o.rempel@pengutronix.deSigned-off-by: NJakub Kicinski <kuba@kernel.org>

xpcs_config() has 'advertising' input that is required for C37 1000BASE-X
AN in later patch series. So, we prepare xpcs_do_config() for it.

For sja1105, xpcs_do_config() is used for xpcs configuration without
depending on advertising input, so set to NULL.
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NOng Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Realtek switches in the rtl8365mb family always have at least one port
with a so-called external interface, supporting PHY interface modes such
as RGMII or SGMII. The purpose of this patch is to improve the driver's
handling of these ports.

A new struct rtl8365mb_chip_info is introduced together with a static
array of such structs. An instance of this struct is added for each
supported switch, distinguished by its chip ID and version. Embedded in
each chip_info struct is an array of struct rtl8365mb_extint, describing
the external interfaces available. This is more specific than the old
rtl8365mb_extint_port_map, which was only valid for switches with up to
6 ports.

The struct rtl8365mb_extint also contains a bitmask of supported PHY
interface modes, which allows the driver to distinguish which ports
support RGMII. This corrects a previous mistake in the driver whereby it
was assumed that any port with an external interface supports RGMII.
This is not actually the case: for example, the RTL8367S has two
external interfaces, only the second of which supports RGMII. The first
supports only SGMII and HSGMII. This new design will make it easier to
add support for other interface modes.

Finally, rtl8365mb_phylink_get_caps() is fixed up to return supported
capabilities based on the external interface properties described above.
This addresses Vladimir's point in the linked thread that the
capabilities are not actually a function of the DSA port type: Although
most typical applications will treat the ports with internal PHY as user
ports, there is no actual hardware limitation preventing one from using
them as a CPU port. Equally, ports with external interface(s) may well
be treated as user ports, even though it is typical to use those ports
as CPU ports.

Link: https://lore.kernel.org/netdev/20220510192301.5djdt3ghoavxulhl@bang-olufsen.dk/Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Acked-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Acked-by: NLuiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The variable is just assigned the value of a macro, so it can be
removed.
Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The maximum number of ports is actually 11, according to two
observations:

1. The highest port ID used in the vendor driver is 10. Since port IDs
   are indexed from 0, and since DSA follows the same numbering system,
   this means up to 11 ports are to be presumed.

2. The registers with port mask fields always amount to a maximum port
   mask of 0x7FF, corresponding to a maximum 11 ports.

In view of this, I also deleted the comment.
Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: NLuiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

There is no real need for this variable: the line change interrupt mask
is sufficiently masked out when getting linkup_ind and linkdown_ind in
the interrupt handler.
Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The official name of this switch is RTL8367RB-VB, not RTL8367RB. There
is also an RTL8367RB-VC which is rather different. Change the name of
the CHIP_ID/_VER macros for reasons of consistency.
Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: NLuiz Angelo Daros de Luca <luizluca@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Replace last occurences of hardcoded cpu-port by cpu_dp member of
dsa_port struct.

Now the constant can be dropped.
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NFrank Wunderlich <frank-w@public-files.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Enumerate available cpu-ports instead of using hardcoded constant.
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NFrank Wunderlich <frank-w@public-files.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Rework vlan_add/vlan_del functions in preparation for dynamic cpu port.

Currently BIT(MT7530_CPU_PORT) is added to new_members, even though
mt7530_port_vlan_add() will be called on the CPU port too.

Let DSA core decide when to call port_vlan_add for the CPU port, rather
than doing it implicitly.

We can do autonomous forwarding in a certain VLAN, but not add br0 to that
VLAN and avoid flooding the CPU with those packets, if software knows it
doesn't need to process them.
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NFrank Wunderlich <frank-w@public-files.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Since commit a18e6521 ("net: phylink: handle NA interface mode in
phylink_fwnode_phy_connect()"), phylib defaults to GMII when no phy-mode
or phy-connection-type property is specified in a DSA port node of the
device tree. The same commit caused a regression in rtl8365mb whereby
phylink would fail to connect, because the driver did not advertise
support for GMII for ports with internal PHY.

It should be noted that the aforementioned regression is not because the
blamed commit was incorrect: on the contrary, the blamed commit is
correcting the previous behaviour whereby unspecified phy-mode would
cause the internal interface mode to be PHY_INTERFACE_MODE_NA. The
rtl8365mb driver only worked by accident before because it _did_
advertise support for PHY_INTERFACE_MODE_NA, despite NA being reserved
for internal use by phylink. With one mistake fixed, the other was
exposed.

Commit a5dba0f2 ("net: dsa: rtl8365mb: add GMII as user port mode")
then introduced implicit support for GMII mode on ports with internal
PHY to allow a PHY connection for device trees where the phy-mode is not
explicitly set to "internal". At this point everything was working OK
again.

Subsequently, commit 6ff60646 ("net: dsa: realtek: convert to
phylink_generic_validate()") broke this behaviour again by discarding
the usage of rtl8365mb_phy_mode_supported() - where this GMII support
was indicated - while switching to the new .phylink_get_caps API.

With the new API, rtl8365mb_phy_mode_supported() is no longer needed.
Remove it altogether and add back the GMII capability - this time to
rtl8365mb_phylink_get_caps() - so that the above default behaviour works
for ports with internal PHY again.

Fixes: 6ff60646 ("net: dsa: realtek: convert to phylink_generic_validate()")
Signed-off-by: NAlvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Link: https://lore.kernel.org/r/20220607184624.417641-1-alvin@pqrs.dkSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Phylink wants to know if the link has dropped since the last time state
was retrieved, and the BMSR gives us that. Read the BMSR and use it when
deciding the link state. Fill in the an_complete member as well for the
emulated PHY state.
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Other errors accessing the registers in mv88e6352_serdes_pcs_get_state()
print "PHY " before the register name, except for the BMSR. Make this
consistent with the other error messages.
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Commit ede359d8 ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN
is bypassed") added the ability to link if AN was bypassed, and added
filling of state->an_complete field, but set it to true if AN was
enabled in BMCR, not when AN was reported complete in BMSR.

This was done because for some reason, when I wanted to use BMSR value
to infer an_complete, I was looking at BMSR_ANEGCAPABLE bit (which was
always 1), instead of BMSR_ANEGCOMPLETE bit.

Use BMSR_ANEGCOMPLETE for filling state->an_complete.

Fixes: ede359d8 ("net: dsa: mv88e6xxx: Link in pcs_get_state() if AN is bypassed")
Signed-off-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Every iteration of for_each_available_child_of_node() decrements
the reference count of the previous node.
when breaking early from a for_each_available_child_of_node() loop,
we need to explicitly call of_node_put() on the gphy_fw_np.
Add missing of_node_put() to avoid refcount leak.

Fixes: 14fceff4 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20220605072335.11257-1-linmq006@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.

Replace kernel.h inclusion with the list of what is really being used.
Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/41d99ef8629e1db03d4f2662f5556611e0b94652.1654323308.git.christophe.jaillet@wanadoo.frSigned-off-by: NJakub Kicinski <kuba@kernel.org>

of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.

mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register().
We don't need the device node after it.

Add missing of_node_put() to avoid refcount leak.

Fixes: a3c53be5 ("net: dsa: mv88e6xxx: Support multiple MDIO busses")
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Reviewed-by: NMarek Behún <kabel@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Update the VCAP filters to support multiple tag_8021q CPU ports.

TX works using a filter for VLAN ID on the ingress of the CPU port, with
a redirect and a VLAN pop action. This can be updated trivially by
amending the ingress port mask of this rule to match on all tag_8021q
CPU ports.

RX works using a filter for ingress port on the egress of the CPU port,
with a VLAN push action. Here we need to replicate these filters for
each tag_8021q CPU port, and let them all have the same action.
This means that the OCELOT_VCAP_ES0_TAG_8021Q_RXVLAN() cookie needs to
encode a unique value for every {user port, CPU port} pair it's given.
Do this by encoding the CPU port in the upper 16 bits of the cookie, and
the user port in the lower 16 bits.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is a desire for the felix driver to gain support for multiple
tag_8021q CPU ports, but the current model prevents it.

This is because ocelot_apply_bridge_fwd_mask() only takes into
consideration whether a port is a tag_8021q CPU port, but not whose CPU
port it is.

We need a model where we can have a direct affinity between an ocelot
port and a tag_8021q CPU port. This serves as the basis for multiple CPU
ports.

Declare a "dsa_8021q_cpu" backpointer in struct ocelot_port which
encodes that affinity. Repurpose the "ocelot_set_dsa_8021q_cpu" API to
"ocelot_assign_dsa_8021q_cpu" to express the change of paradigm.

Note that this change makes the first practical use of the new
ocelot_port->index field in ocelot_port_unassign_dsa_8021q_cpu(), where
we need to remove the old tag_8021q CPU port from the reserved VLAN range.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Absorb the final details of calling ocelot_port_{,un}set_dsa_8021q_cpu(),
i.e. the need to lock &ocelot->fwd_domain_lock, into the callee, to
simplify the caller and permit easier code reuse later.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add more logic to ocelot_port_{,un}set_dsa_8021q_cpu() from the ocelot
switch lib by encapsulating the ocelot_apply_bridge_fwd_mask() call that
felix used to have.

This is necessary because the CPU port change procedure will also need
to do this, and it's good to reduce code duplication by having an entry
point in the ocelot switch lib that does all that is needed.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

PGID_CPU must be updated every time a port is configured or unconfigured
as a tag_8021q CPU port. The ocelot switch lib already has a hook for
that operation, so move the updating of PGID_CPU to those hooks.

These bits are pretty specific to DSA, so normally I would keep them out
of the common switch lib, but when tag_8021q is in use, this has
implications upon the forwarding mask determined by
ocelot_apply_bridge_fwd_mask() and called extensively by the switch lib.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

PGID_BC is configured statically by ocelot_init() to flood towards the
CPU port module, and dynamically by ocelot_port_set_bcast_flood()
towards all user ports.

When the tagging protocol changes, the intention is to turn off flooding
towards the old pipe towards the host, and to turn it on towards the new
pipe.

Due to a recent change which removed the adjustment of PGID_BC from
felix_set_host_flood(), 3 things happen.

- when we change from NPI to tag_8021q mode: in this mode, the CPU port
  module is accessed via registers, and used to read PTP packets with
  timestamps. We fail to disable broadcast flooding towards the CPU port
  module, and to enable broadcast flooding towards the physical port
  that serves as a DSA tag_8021q CPU port.

- from tag_8021q to NPI mode: in this mode, the CPU port module is
  redirected to a physical port. We fail to disable broadcast flooding
  towards the physical tag_8021q CPU port, and to enable it towards the
  CPU port module at ocelot->num_phys_ports.

- when the ports are put in promiscuous mode, we also fail to update
  PGID_BC towards the host pipe of the current protocol.

First issue means that felix_check_xtr_pkt() has to do extra work,
because it will not see only PTP packets, but also broadcasts. It needs
to dequeue these packets just to drop them.

Third issue is inconsequential, since PGID_BC is allocated from the
nonreserved multicast PGID space, and these PGIDs are conveniently
initialized to 0x7f (i.e. flood towards all ports except the CPU port
module). Broadcasts reach the NPI port via ocelot_init(), and reach the
tag_8021q CPU port via the hardware defaults.

Second issue is also inconsequential, because we fail both at disabling
and at enabling broadcast flooding on a port, so the defaults mentioned
above are preserved, and they are fine except for the performance impact.

Fixes: 7a29d220 ("net: dsa: felix: reimplement tagging protocol change with function pointers")
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Since kconfig 'select' does not follow dependency chains, if symbol KSA
selects KSB, then KSA should also depend on the same symbols that KSB
depends on, in order to prevent Kconfig warnings and possible build
errors.

Change NET_DSA_SMSC_LAN9303_I2C and NET_DSA_SMSC_LAN9303_MDIO so that
they are limited to VLAN_8021Q if the latter is enabled. This prevents
the Kconfig warning:

WARNING: unmet direct dependencies detected for NET_DSA_SMSC_LAN9303
  Depends on [m]: NETDEVICES [=y] && NET_DSA [=y] && (VLAN_8021Q [=m] || VLAN_8021Q [=m]=n)
  Selected by [y]:
  - NET_DSA_SMSC_LAN9303_I2C [=y] && NETDEVICES [=y] && NET_DSA [=y] && I2C [=y]

Fixes: 430065e2 ("net: dsa: lan9303: add VLAN IDs to master device")
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Vladimir Oltean <olteanv@gmail.com>
Cc: Juergen Borleis <jbe@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Mans Rullgard <mans@mansr.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

gswip_port_fdb_dump() reads the MAC bridge entries. The error message
should say "failed to read mac bridge entry". While here, also add the
index to the error print so humans can get to the cause of the problem
easier.
Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The first N entries in priv->vlans are reserved for managing ports which
are not part of a bridge. Use priv->hw_info->max_ports to consistently
access per-bridge entries at index 7. Starting at
priv->hw_info->cpu_port (6) is harmless in this case because
priv->vlan[6].bridge is always NULL so the comparison result is always
false (which results in this entry being skipped).
Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The name, regs_size and overrides members in struct ksz_device are
unused. Hence remove it.
And host_mask is used in only place of ksz8795.c file, which can be
replaced by dev->info->cpu_ports
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch add the support for phylink_get_caps for ksz8795 and ksz9477
series switch. It updates the struct ksz_switch_chip with the details of
the internal phys and xmii interface. Then during the get_caps based on
the bits set in the structure, corresponding phy mode is set.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mib->cnt_ptr resetting is handled in multiple places as part of
port_init_cnt(). Hence moved mib->cnt_ptr code to ksz common layer
and removed from individual product files.
Signed-off-by: NPrasanna Vengateshan <prasanna.vengateshan@microchip.com>
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ksz8795 and ksz9477 uses the same algorithm for copying the ethtool
strings. Hence moved to ksz_common to remove the redundant code.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ksz8795 and ksz9477 init function initializes the memory to dev->ports,
mib counters and assigns the ds real number of ports. Since both the
routines are same, moved the allocation of port memory to
ksz_switch_register after init.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The ksz88xx family has one set of mib_names. The ksz87xx, ksz9477,
LAN937x based switches has one set of mib_names. In order to remove
redundant declaration, moved the struct mib_names to ksz_chip_data
structure.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch perform the compatibility check for the device after the chip
detect is done. It is to prevent the mismatch between the device
compatible specified in the device tree and actual device found during
the detect. The ksz9477 device doesn't use any .data in the
of_device_id. But the ksz8795_spi uses .data for assigning the regmap
between 8830 family and 87xx family switch. Changed the regmap
assignment based on the chip_id from the .data.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch moves the ksz_chip_data in ksz8795 and ksz9477 to ksz_common.
At present, the dev->chip_id is iterated with the ksz_chip_data and then
copy its value to the ksz_dev structure. These values are declared as
constant.
Instead of copying the values and referencing it, this patch update the
dev->info to the ksz_chip_data based on the chip_id in the init
function. And also update the ksz_chip_data values for the LAN937x based
switches.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The port_cnt value in the structure is not used in the switch_init.
Instead it uses the fls(chip->cpu_port), this is due to one of port in
the ksz8794 unavailable. The cpu_port for the 8794 is 0x10, fls(0x10) =
5, hence updating it directly in the ksz_chip_data structure in order to
same with all the other switches in ksz8795.c and ksz9477.c files.
Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>