- 24 6月, 2022 7 次提交
-
-
由 Arun Ramadoss 提交于
This patch move the 10% broadcast protection from the individual setup to ksz_setup. In the ksz9477, broadcast protection is updated in reset function. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arun Ramadoss 提交于
This patch move the common initialization of switches to ksz_setup and perform the switch specific initialization using the ksz_dev_ops function pointer. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arun Ramadoss 提交于
In order to transmit the STP BPDU packet to the CPU port, the STP address 01-80-c2-00-00-00 has to be added to static alu table for ksz8795 series switch. For the ksz9477 switch, there is reserved multicast table which handles forwarding the particular set of multicast address to cpu port. So enabling the multicast reserved table and updated the cpu port index. The stp addr is enabled during the setup phase using the enable_stp_addr pointer in struct ksz_dev_ops. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arun Ramadoss 提交于
To have the common set of initialization in ksz_setup, introduced the new config_cpu_port member to ksz_dev_ops. Since both the ksz8795.c and ksz9477.c configuring the cpu port in the setup function, introduced the member. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arun Ramadoss 提交于
This patch renames the shutdown to reset in ksz_dev_ops in order to use the reset dev_ops in the ksz_setup. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Russell King 提交于
Currently, all the device specific speed setting functions convert SPEED_MAX to the actual speed of the port. Rather than having each of the mv88e6xxx chip specifics handling SPEED_MAX, derive it from the mac_capabilities instead. This is only needed for CPU and DSA ports, so move the logic up into mv88e6xxx_setup_port() - which allows us to kill off all users of SPEED_MAX throughout the driver. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Russell King (Oracle) 提交于
Remove mv88e6065_port_set_speed_duplex() - this is never called, and thus is completely redundant. Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 23 6月, 2022 2 次提交
-
-
由 Christian Marangi 提交于
The current mgmt ethernet timeout is set to 100ms. This value is too big and would slow down any mdio command in case the mgmt ethernet packet have some problems on the receiving part. Reduce it to just 5ms to handle case when some operation are done on the master port that would cause the mgmt ethernet to not work temporarily. Fixes: 5950c7c0 ("net: dsa: qca8k: add support for mgmt read/write in Ethernet packet") Signed-off-by: NChristian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20220621151633.11741-1-ansuelsmth@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
由 Christian Marangi 提交于
It was discovered that the Documentation lacks of a fundamental detail on how to correctly change the MAX_FRAME_SIZE of the switch. In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the switch panics and cease to send any packet. This cause the mgmt ethernet system to not receive any packet (the slow fallback still works) and makes the device not reachable. To recover from this a switch reset is required. To correctly handle this, turn off the cpu ports before changing the MAX_FRAME_SIZE and turn on again after the value is applied. Fixes: f58d2598 ("net: dsa: qca8k: implement the port MTU callbacks") Cc: stable@vger.kernel.org Signed-off-by: NChristian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20220621151122.10220-1-ansuelsmth@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
-
- 21 6月, 2022 11 次提交
-
-
由 Arun Ramadoss 提交于
This patch assigns the get_phy_flags & mtu hook of ksz8795 and ksz9477 in dsa_switch_ops to ksz_common. For get_phy_flags hooks,checks whether the chip is ksz8863/kss8793 then it returns error for port1. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
-
由 Arun Ramadoss 提交于
This patch makes the dsa_switch_hook for fdbs to use ksz_common.c file. And from ksz_common, individual switches fdb functions are called using the dev->dev_ops. And removed the r_dyn_mac_table, r_sta_mac_table and w_sta_mac_table from ksz_dev_ops as it is used only in ksz8795.c Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
-
由 Arun Ramadoss 提交于
ksz_mdb_add/del in ksz_common.c is specific for the ksz8795.c file. The ksz9477 has its separate ksz9477_port_mdb_add/del functions. This patch moves the ksz8795 specific mdb functionality from ksz_common to ksz8795. And this dsa_switch_ops hooks for ksz8795/ksz9477 are invoked through the ksz_port_mdb_add/del. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
-
由 Arun Ramadoss 提交于
This patch assigns the phylink_get_caps in ksz8795 and ksz9477 to ksz_phylink_get_caps. And update their mac_capabilities in the respective ksz_dev_ops. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
-
由 Arun Ramadoss 提交于
At present, P_STP_CTRL register value is passed as parameter to ksz_port_stp_state from the individual dsa_switch_ops hooks. This patch update the function to retrieve the register value through the ksz_chip_data member. And add the static to ksz_update_port_member since it is not called outside the ksz_common. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
-
由 Arun Ramadoss 提交于
This patch updates the common port mirror add/del dsa_switch_ops in ksz_common.c. The individual switches implementation is executed based on the ksz_dev_ops function pointers. 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: NPaolo Abeni <pabeni@redhat.com>
-
由 Arun Ramadoss 提交于
This patch moves the vlan dsa_switch_ops such as vlan_add, vlan_del and vlan_filtering from the individual files ksz8795.c, ksz9477.c to ksz_common.c file. Signed-off-by: NArun Ramadoss <arun.ramadoss@microchip.com> Reviewed-by: NVladimir Oltean <olteanv@gmail.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
-
由 Arun Ramadoss 提交于
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>
-
由 Arun Ramadoss 提交于
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>
-
由 Arun Ramadoss 提交于
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>
-
由 Arun Ramadoss 提交于
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>
-
- 19 6月, 2022 1 次提交
-
-
由 Xiaoliang Yang 提交于
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>
-
- 18 6月, 2022 1 次提交
-
-
由 Oleksij Rempel 提交于
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>
-
- 17 6月, 2022 6 次提交
-
-
由 Ong Boon Leong 提交于
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>
-
由 Alvin Šipraga 提交于
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>
-
由 Alvin Šipraga 提交于
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>
-
由 Alvin Šipraga 提交于
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>
-
由 Alvin Šipraga 提交于
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>
-
由 Alvin Šipraga 提交于
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>
-
- 15 6月, 2022 3 次提交
-
-
由 Frank Wunderlich 提交于
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>
-
由 Frank Wunderlich 提交于
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>
-
由 Frank Wunderlich 提交于
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>
-
- 09 6月, 2022 4 次提交
-
-
由 Alvin Šipraga 提交于
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>
-
由 Russell King (Oracle) 提交于
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>
-
由 Russell King (Oracle) 提交于
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>
-
由 Marek Behún 提交于
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>
-
- 08 6月, 2022 2 次提交
-
-
由 Miaoqian Lin 提交于
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>
-
由 Christophe JAILLET 提交于
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>
-
- 27 5月, 2022 1 次提交
-
-
由 Miaoqian Lin 提交于
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>
-
- 23 5月, 2022 2 次提交
-
-
由 Vladimir Oltean 提交于
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>
-
由 Vladimir Oltean 提交于
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>
-