1. 04 1月, 2023 2 次提交
  2. 16 12月, 2022 6 次提交
    • T
      igc: Set Qbv start_time and end_time to end_time if not being configured in GCL · 72abeedd
      Tan Tee Min 提交于
      The default setting of end_time minus start_time is whole 1 second.
      Thus, if it's not being configured in any GCL entry then it will be
      staying at original 1 second.
      
      This patch is changing the start_time and end_time to be end_time as
      if setting zero will be having weird HW behavior where the gate will
      not be fully closed.
      
      Fixes: ec50a9d4 ("igc: Add support for taprio offloading")
      Signed-off-by: NTan Tee Min <tee.min.tan@linux.intel.com>
      Signed-off-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      72abeedd
    • T
      igc: recalculate Qbv end_time by considering cycle time · 6d05251d
      Tan Tee Min 提交于
      Qbv users can specify a cycle time that is not equal to the total GCL
      intervals. Hence, recalculation is necessary here to exclude the time
      interval that exceeds the cycle time. As those GCL which exceeds the
      cycle time will be truncated.
      
      According to IEEE Std. 802.1Q-2018 section 8.6.9.2, once the end of
      the list is reached, it will switch to the END_OF_CYCLE state and
      leave the gates in the same state until the next cycle is started.
      
      Fixes: ec50a9d4 ("igc: Add support for taprio offloading")
      Signed-off-by: NTan Tee Min <tee.min.tan@linux.intel.com>
      Signed-off-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      6d05251d
    • T
      igc: allow BaseTime 0 enrollment for Qbv · e17090eb
      Tan Tee Min 提交于
      Introduce qbv_enable flag in igc_adapter struct to store the Qbv on/off.
      So this allow the BaseTime to enroll with zero value.
      
      Fixes: 61572d5f ("igc: Simplify TSN flags handling")
      Signed-off-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Signed-off-by: NTan Tee Min <tee.min.tan@linux.intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      e17090eb
    • M
      igc: Add checking for basetime less than zero · 3b61764f
      Muhammad Husaini Zulkifli 提交于
      Using the tc qdisc command, the user can set basetime to any value.
      Checking should be done on the driver's side to prevent registering
      basetime values that are less than zero.
      
      Fixes: ec50a9d4 ("igc: Add support for taprio offloading")
      Signed-off-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      3b61764f
    • V
      igc: Use strict cycles for Qbv scheduling · d8f45be0
      Vinicius Costa Gomes 提交于
      Configuring strict cycle mode in the controller forces more well
      behaved transmissions when taprio is offloaded.
      
      When set this strict_cycle and strict_end, transmission is not
      enabled if the whole packet cannot be completed before end of
      the Qbv cycle.
      
      Fixes: 82faa9b7 ("igc: Add support for ETF offloading")
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: NAravindhan Gunasekaran <aravindhan.gunasekaran@intel.com>
      Signed-off-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      d8f45be0
    • V
      igc: Enhance Qbv scheduling by using first flag bit · db0b124f
      Vinicius Costa Gomes 提交于
      The I225 hardware has a limitation that packets can only be scheduled
      in the [0, cycle-time] interval. So, scheduling a packet to the start
      of the next cycle doesn't usually work.
      
      To overcome this, we use the Transmit Descriptor first flag to indicates
      that a packet should be the first packet (from a queue) in a cycle
      according to the section 7.5.2.9.3.4 The First Packet on Each QBV Cycle
      in Intel Discrete I225/6 User Manual.
      
      But this only works if there was any packet from that queue during the
      current cycle, to avoid this issue, we issue an empty packet if that's
      not the case. Also require one more descriptor to be available, to take
      into account the empty packet that might be issued.
      
      Test Setup:
      
      Talker: Use l2_tai to generate the launchtime into packet load.
      
      Listener: Use timedump.c to compute the delta between packet arrival
      and LaunchTime packet payload.
      
      Test Result:
      
      Before:
      
      1666000610127300000,1666000610127300096,96,621273
      1666000610127400000,1666000610127400192,192,621274
      1666000610127500000,1666000610127500032,32,621275
      1666000610127600000,1666000610127600128,128,621276
      1666000610127700000,1666000610127700224,224,621277
      1666000610127800000,1666000610127800064,64,621278
      1666000610127900000,1666000610127900160,160,621279
      1666000610128000000,1666000610128000000,0,621280
      1666000610128100000,1666000610128100096,96,621281
      1666000610128200000,1666000610128200192,192,621282
      1666000610128300000,1666000610128300032,32,621283
      1666000610128400000,1666000610128301056,-98944,621284
      1666000610128500000,1666000610128302080,-197920,621285
      1666000610128600000,1666000610128302848,-297152,621286
      1666000610128700000,1666000610128303872,-396128,621287
      1666000610128800000,1666000610128304896,-495104,621288
      1666000610128900000,1666000610128305664,-594336,621289
      1666000610129000000,1666000610128306688,-693312,621290
      1666000610129100000,1666000610128307712,-792288,621291
      1666000610129200000,1666000610128308480,-891520,621292
      1666000610129300000,1666000610128309504,-990496,621293
      1666000610129400000,1666000610128310528,-1089472,621294
      1666000610129500000,1666000610128311296,-1188704,621295
      1666000610129600000,1666000610128312320,-1287680,621296
      1666000610129700000,1666000610128313344,-1386656,621297
      1666000610129800000,1666000610128314112,-1485888,621298
      1666000610129900000,1666000610128315136,-1584864,621299
      1666000610130000000,1666000610128316160,-1683840,621300
      1666000610130100000,1666000610128316928,-1783072,621301
      1666000610130200000,1666000610128317952,-1882048,621302
      1666000610130300000,1666000610128318976,-1981024,621303
      1666000610130400000,1666000610128319744,-2080256,621304
      1666000610130500000,1666000610128320768,-2179232,621305
      1666000610130600000,1666000610128321792,-2278208,621306
      1666000610130700000,1666000610128322816,-2377184,621307
      1666000610130800000,1666000610128323584,-2476416,621308
      1666000610130900000,1666000610128324608,-2575392,621309
      1666000610131000000,1666000610128325632,-2674368,621310
      1666000610131100000,1666000610128326400,-2773600,621311
      1666000610131200000,1666000610128327424,-2872576,621312
      1666000610131300000,1666000610128328448,-2971552,621313
      1666000610131400000,1666000610128329216,-3070784,621314
      1666000610131500000,1666000610131500032,32,621315
      1666000610131600000,1666000610131600128,128,621316
      1666000610131700000,1666000610131700224,224,621317
      
      After:
      
      1666073510646200000,1666073510646200064,64,2676462
      1666073510646300000,1666073510646300160,160,2676463
      1666073510646400000,1666073510646400256,256,2676464
      1666073510646500000,1666073510646500096,96,2676465
      1666073510646600000,1666073510646600192,192,2676466
      1666073510646700000,1666073510646700032,32,2676467
      1666073510646800000,1666073510646800128,128,2676468
      1666073510646900000,1666073510646900224,224,2676469
      1666073510647000000,1666073510647000064,64,2676470
      1666073510647100000,1666073510647100160,160,2676471
      1666073510647200000,1666073510647200256,256,2676472
      1666073510647300000,1666073510647300096,96,2676473
      1666073510647400000,1666073510647400192,192,2676474
      1666073510647500000,1666073510647500032,32,2676475
      1666073510647600000,1666073510647600128,128,2676476
      1666073510647700000,1666073510647700224,224,2676477
      1666073510647800000,1666073510647800064,64,2676478
      1666073510647900000,1666073510647900160,160,2676479
      1666073510648000000,1666073510648000000,0,2676480
      1666073510648100000,1666073510648100096,96,2676481
      1666073510648200000,1666073510648200192,192,2676482
      1666073510648300000,1666073510648300032,32,2676483
      1666073510648400000,1666073510648400128,128,2676484
      1666073510648500000,1666073510648500224,224,2676485
      1666073510648600000,1666073510648600064,64,2676486
      1666073510648700000,1666073510648700160,160,2676487
      1666073510648800000,1666073510648800000,0,2676488
      1666073510648900000,1666073510648900096,96,2676489
      1666073510649000000,1666073510649000192,192,2676490
      1666073510649100000,1666073510649100032,32,2676491
      1666073510649200000,1666073510649200128,128,2676492
      1666073510649300000,1666073510649300224,224,2676493
      1666073510649400000,1666073510649400064,64,2676494
      1666073510649500000,1666073510649500160,160,2676495
      1666073510649600000,1666073510649600000,0,2676496
      1666073510649700000,1666073510649700096,96,2676497
      1666073510649800000,1666073510649800192,192,2676498
      1666073510649900000,1666073510649900032,32,2676499
      1666073510650000000,1666073510650000128,128,2676500
      
      Fixes: 82faa9b7 ("igc: Add support for ETF offloading")
      Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Co-developed-by: NAravindhan Gunasekaran <aravindhan.gunasekaran@intel.com>
      Signed-off-by: NAravindhan Gunasekaran <aravindhan.gunasekaran@intel.com>
      Co-developed-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Signed-off-by: NMuhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com>
      Signed-off-by: NMalli C <mallikarjuna.chilakala@intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      db0b124f
  3. 03 11月, 2022 1 次提交
  4. 29 10月, 2022 1 次提交
  5. 29 9月, 2022 1 次提交
  6. 09 9月, 2022 1 次提交
  7. 19 8月, 2022 1 次提交
  8. 19 7月, 2022 3 次提交
  9. 15 7月, 2022 1 次提交
    • L
      igc: Reinstate IGC_REMOVED logic and implement it properly · 7c1ddcee
      Lennert Buytenhek 提交于
      The initially merged version of the igc driver code (via commit
      146740f9, "igc: Add support for PF") contained the following
      IGC_REMOVED checks in the igc_rd32/wr32() MMIO accessors:
      
      	u32 igc_rd32(struct igc_hw *hw, u32 reg)
      	{
      		u8 __iomem *hw_addr = READ_ONCE(hw->hw_addr);
      		u32 value = 0;
      
      		if (IGC_REMOVED(hw_addr))
      			return ~value;
      
      		value = readl(&hw_addr[reg]);
      
      		/* reads should not return all F's */
      		if (!(~value) && (!reg || !(~readl(hw_addr))))
      			hw->hw_addr = NULL;
      
      		return value;
      	}
      
      And:
      
      	#define wr32(reg, val) \
      	do { \
      		u8 __iomem *hw_addr = READ_ONCE((hw)->hw_addr); \
      		if (!IGC_REMOVED(hw_addr)) \
      			writel((val), &hw_addr[(reg)]); \
      	} while (0)
      
      E.g. igb has similar checks in its MMIO accessors, and has a similar
      macro E1000_REMOVED, which is implemented as follows:
      
      	#define E1000_REMOVED(h) unlikely(!(h))
      
      These checks serve to detect and take note of an 0xffffffff MMIO read
      return from the device, which can be caused by a PCIe link flap or some
      other kind of PCI bus error, and to avoid performing MMIO reads and
      writes from that point onwards.
      
      However, the IGC_REMOVED macro was not originally implemented:
      
      	#ifndef IGC_REMOVED
      	#define IGC_REMOVED(a) (0)
      	#endif /* IGC_REMOVED */
      
      This led to the IGC_REMOVED logic to be removed entirely in a
      subsequent commit (commit 3c215fb1, "igc: remove IGC_REMOVED
      function"), with the rationale that such checks matter only for
      virtualization and that igc does not support virtualization -- but a
      PCIe device can become detached even without virtualization being in
      use, and without proper checks, a PCIe bus error affecting an igc
      adapter will lead to various NULL pointer dereferences, as the first
      access after the error will set hw->hw_addr to NULL, and subsequent
      accesses will blindly dereference this now-NULL pointer.
      
      This patch reinstates the IGC_REMOVED checks in igc_rd32/wr32(), and
      implements IGC_REMOVED the way it is done for igb, by checking for the
      unlikely() case of hw_addr being NULL.  This change prevents the oopses
      seen when a PCIe link flap occurs on an igc adapter.
      
      Fixes: 146740f9 ("igc: Add support for PF")
      Signed-off-by: NLennert Buytenhek <buytenh@arista.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Acked-by: NSasha Neftin <sasha.neftin@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      7c1ddcee
  10. 01 7月, 2022 2 次提交
  11. 11 5月, 2022 3 次提交
  12. 14 4月, 2022 1 次提交
  13. 13 4月, 2022 2 次提交
    • S
      igc: Fix BUG: scheduling while atomic · c80a29f0
      Sasha Neftin 提交于
      Replace usleep_range() method with udelay() method to allow atomic contexts
      in low-level MDIO access functions.
      
      The following issue can be seen by doing the following:
      $ modprobe -r bonding
      $ modprobe -v bonding max_bonds=1 mode=1 miimon=100 use_carrier=0
      $ ip link set bond0 up
      $ ifenslave bond0 eth0 eth1
      
      [  982.357308] BUG: scheduling while atomic: kworker/u64:0/9/0x00000002
      [  982.364431] INFO: lockdep is turned off.
      [  982.368824] Modules linked in: bonding sctp ip6_udp_tunnel udp_tunnel mlx4_ib ib_uverbs ib_core mlx4_en mlx4_core nfp tls sunrpc intel_rapl_msr iTCO_wdt iTCO_vendor_support mxm_wmi dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate intel_uncore pcspkr lpc_ich mei_me ipmi_ssif mei ipmi_si ipmi_devintf ipmi_msghandler wmi acpi_power_meter xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci crc32c_intel libata i2c_algo_bit tg3 megaraid_sas igc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: bonding]
      [  982.437941] CPU: 25 PID: 9 Comm: kworker/u64:0 Kdump: loaded Tainted: G        W        --------- -  - 4.18.0-348.el8.x86_64+debug #1
      [  982.451333] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 2.7.0 12/005/2017
      [  982.459791] Workqueue: bond0 bond_mii_monitor [bonding]
      [  982.465622] Call Trace:
      [  982.468355]  dump_stack+0x8e/0xd0
      [  982.472056]  __schedule_bug.cold.60+0x3a/0x60
      [  982.476919]  __schedule+0x147b/0x1bc0
      [  982.481007]  ? firmware_map_remove+0x16b/0x16b
      [  982.485967]  ? hrtimer_fixup_init+0x40/0x40
      [  982.490625]  schedule+0xd9/0x250
      [  982.494227]  schedule_hrtimeout_range_clock+0x10d/0x2c0
      [  982.500058]  ? hrtimer_nanosleep_restart+0x130/0x130
      [  982.505598]  ? hrtimer_init_sleeper_on_stack+0x90/0x90
      [  982.511332]  ? usleep_range+0x88/0x130
      [  982.515514]  ? recalibrate_cpu_khz+0x10/0x10
      [  982.520279]  ? ktime_get+0xab/0x1c0
      [  982.524175]  ? usleep_range+0x88/0x130
      [  982.528355]  usleep_range+0xdd/0x130
      [  982.532344]  ? console_conditional_schedule+0x30/0x30
      [  982.537987]  ? igc_put_hw_semaphore+0x17/0x60 [igc]
      [  982.543432]  igc_read_phy_reg_gpy+0x111/0x2b0 [igc]
      [  982.548887]  igc_phy_has_link+0xfa/0x260 [igc]
      [  982.553847]  ? igc_get_phy_id+0x210/0x210 [igc]
      [  982.558894]  ? lock_acquire+0x34d/0x890
      [  982.563187]  ? lock_downgrade+0x710/0x710
      [  982.567659]  ? rcu_read_unlock+0x50/0x50
      [  982.572039]  igc_check_for_copper_link+0x106/0x210 [igc]
      [  982.577970]  ? igc_config_fc_after_link_up+0x840/0x840 [igc]
      [  982.584286]  ? rcu_read_unlock+0x50/0x50
      [  982.588661]  ? lock_release+0x591/0xb80
      [  982.592939]  ? lock_release+0x591/0xb80
      [  982.597220]  igc_has_link+0x113/0x330 [igc]
      [  982.601887]  ? lock_downgrade+0x710/0x710
      [  982.606362]  igc_ethtool_get_link+0x6d/0x90 [igc]
      [  982.611614]  bond_check_dev_link+0x131/0x2c0 [bonding]
      [  982.617350]  ? bond_time_in_interval+0xd0/0xd0 [bonding]
      [  982.623277]  ? rcu_read_lock_held+0x62/0xc0
      [  982.627944]  ? rcu_read_lock_sched_held+0xe0/0xe0
      [  982.633198]  bond_mii_monitor+0x314/0x2500 [bonding]
      [  982.638738]  ? lock_contended+0x880/0x880
      [  982.643214]  ? bond_miimon_link_change+0xa0/0xa0 [bonding]
      [  982.649336]  ? lock_acquire+0x34d/0x890
      [  982.653615]  ? lock_downgrade+0x710/0x710
      [  982.658089]  ? debug_object_deactivate+0x221/0x340
      [  982.663436]  ? rcu_read_unlock+0x50/0x50
      [  982.667811]  ? debug_print_object+0x2b0/0x2b0
      [  982.672672]  ? __switch_to_asm+0x41/0x70
      [  982.677049]  ? __switch_to_asm+0x35/0x70
      [  982.681426]  ? _raw_spin_unlock_irq+0x24/0x40
      [  982.686288]  ? trace_hardirqs_on+0x20/0x195
      [  982.690956]  ? _raw_spin_unlock_irq+0x24/0x40
      [  982.695818]  process_one_work+0x8f0/0x1770
      [  982.700390]  ? pwq_dec_nr_in_flight+0x320/0x320
      [  982.705443]  ? debug_show_held_locks+0x50/0x50
      [  982.710403]  worker_thread+0x87/0xb40
      [  982.714489]  ? process_one_work+0x1770/0x1770
      [  982.719349]  kthread+0x344/0x410
      [  982.722950]  ? kthread_insert_work_sanity_check+0xd0/0xd0
      [  982.728975]  ret_from_fork+0x3a/0x50
      
      Fixes: 5586838f ("igc: Add code for PHY support")
      Reported-by: NCorinna Vinschen <vinschen@redhat.com>
      Suggested-by: NDima Ruinskiy <dima.ruinskiy@intel.com>
      Signed-off-by: NSasha Neftin <sasha.neftin@intel.com>
      Tested-by: NCorinna Vinschen <vinschen@redhat.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      c80a29f0
    • S
      igc: Fix infinite loop in release_swfw_sync · 907862e9
      Sasha Neftin 提交于
      An infinite loop may occur if we fail to acquire the HW semaphore,
      which is needed for resource release.
      This will typically happen if the hardware is surprise-removed.
      At this stage there is nothing to do, except log an error and quit.
      
      Fixes: c0071c7a ("igc: Add HW initialization code")
      Suggested-by: NDima Ruinskiy <dima.ruinskiy@intel.com>
      Signed-off-by: NSasha Neftin <sasha.neftin@intel.com>
      Tested-by: NNaama Meir <naamax.meir@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      907862e9
  14. 01 3月, 2022 2 次提交
  15. 08 2月, 2022 1 次提交
    • C
      igc: avoid kernel warning when changing RX ring parameters · 453307b5
      Corinna Vinschen 提交于
      Calling ethtool changing the RX ring parameters like this:
      
        $ ethtool -G eth0 rx 1024
      
      on igc triggers kernel warnings like this:
      
      [  225.198467] ------------[ cut here ]------------
      [  225.198473] Missing unregister, handled but fix driver
      [  225.198485] WARNING: CPU: 7 PID: 959 at net/core/xdp.c:168
      xdp_rxq_info_reg+0x79/0xd0
      [...]
      [  225.198601] Call Trace:
      [  225.198604]  <TASK>
      [  225.198609]  igc_setup_rx_resources+0x3f/0xe0 [igc]
      [  225.198617]  igc_ethtool_set_ringparam+0x30e/0x450 [igc]
      [  225.198626]  ethnl_set_rings+0x18a/0x250
      [  225.198631]  genl_family_rcv_msg_doit+0xca/0x110
      [  225.198637]  genl_rcv_msg+0xce/0x1c0
      [  225.198640]  ? rings_prepare_data+0x60/0x60
      [  225.198644]  ? genl_get_cmd+0xd0/0xd0
      [  225.198647]  netlink_rcv_skb+0x4e/0xf0
      [  225.198652]  genl_rcv+0x24/0x40
      [  225.198655]  netlink_unicast+0x20e/0x330
      [  225.198659]  netlink_sendmsg+0x23f/0x480
      [  225.198663]  sock_sendmsg+0x5b/0x60
      [  225.198667]  __sys_sendto+0xf0/0x160
      [  225.198671]  ? handle_mm_fault+0xb2/0x280
      [  225.198676]  ? do_user_addr_fault+0x1eb/0x690
      [  225.198680]  __x64_sys_sendto+0x20/0x30
      [  225.198683]  do_syscall_64+0x38/0x90
      [  225.198687]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [  225.198693] RIP: 0033:0x7f7ae38ac3aa
      
      igc_ethtool_set_ringparam() copies the igc_ring structure but neglects to
      reset the xdp_rxq_info member before calling igc_setup_rx_resources().
      This in turn calls xdp_rxq_info_reg() with an already registered xdp_rxq_info.
      
      Make sure to unregister the xdp_rxq_info structure first in
      igc_setup_rx_resources.
      
      Fixes: 73f1071c ("igc: Add support for XDP_TX action")
      Reported-by: NLennert Buytenhek <buytenh@arista.com>
      Signed-off-by: NCorinna Vinschen <vinschen@redhat.com>
      Acked-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      453307b5
  16. 01 2月, 2022 1 次提交
  17. 28 1月, 2022 1 次提交
  18. 30 12月, 2021 1 次提交
  19. 29 12月, 2021 3 次提交
  20. 22 12月, 2021 5 次提交
  21. 16 12月, 2021 1 次提交