1. 24 6月, 2022 7 次提交
  2. 23 6月, 2022 2 次提交
  3. 21 6月, 2022 11 次提交
  4. 19 6月, 2022 1 次提交
    • X
      net: dsa: felix: update base time of time-aware shaper when adjusting PTP time · 8670dc33
      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>
      8670dc33
  5. 18 6月, 2022 1 次提交
    • O
      net: dsa: ar9331: fix potential dead lock on mdio access · 7a49f219
      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>
      7a49f219
  6. 17 6月, 2022 6 次提交
  7. 15 6月, 2022 3 次提交
  8. 09 6月, 2022 4 次提交
  9. 08 6月, 2022 2 次提交
  10. 27 5月, 2022 1 次提交
  11. 23 5月, 2022 2 次提交
    • V
      net: dsa: felix: tag_8021q preparation for multiple CPU ports · a4e044dc
      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>
      a4e044dc
    • V
      net: mscc: ocelot: switch from {,un}set to {,un}assign for tag_8021q CPU ports · c295f983
      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>
      c295f983