Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 07 9月, 2022 1 次提交
  3. 24 8月, 2022 2 次提交
    • A
      ice: Print human-friendly PHY types · f8c74ca6
      由 Anirudh Venkataramanan 提交于 
      Provide human readable description of PHY capabilities
and report_mode.

Sample output:

Old:
[  286.130405] ice 0000:16:00.0: get phy caps - report_mode = 0x2
[  286.130409] ice 0000:16:00.0:        phy_type_low = 0x108021020502000
[  286.130412] ice 0000:16:00.0:        phy_type_high = 0x0
[  286.130415] ice 0000:16:00.0:        caps = 0xc8
[  286.130419] ice 0000:16:00.0:        low_power_ctrl_an = 0x4
[  286.130421] ice 0000:16:00.0:        eee_cap = 0x0
[  286.130424] ice 0000:16:00.0:        eeer_value = 0x0
[  286.130427] ice 0000:16:00.0:        link_fec_options = 0xdf
[  286.130430] ice 0000:16:00.0:        module_compliance_enforcement = 0x0
[  286.130433] ice 0000:16:00.0:    extended_compliance_code = 0xb
[  286.130435] ice 0000:16:00.0:    module_type[0] = 0x11
[  286.130438] ice 0000:16:00.0:    module_type[1] = 0x1
[  286.130441] ice 0000:16:00.0:    module_type[2] = 0x0

New:
[ 1128.297347] ice 0000:16:00.0: get phy caps dump
[ 1128.297351] ice 0000:16:00.0: phy_caps_active: phy_type_low: 0x0108021020502000
[ 1128.297355] ice 0000:16:00.0: phy_caps_active:   bit(13): 10G_SFI_DA
[ 1128.297359] ice 0000:16:00.0: phy_caps_active:   bit(20): 25GBASE_CR
[ 1128.297362] ice 0000:16:00.0: phy_caps_active:   bit(22): 25GBASE_CR1
[ 1128.297365] ice 0000:16:00.0: phy_caps_active:   bit(29): 25G_AUI_C2C
[ 1128.297368] ice 0000:16:00.0: phy_caps_active:   bit(36): 50GBASE_CR2
[ 1128.297371] ice 0000:16:00.0: phy_caps_active:   bit(41): 50G_LAUI2
[ 1128.297374] ice 0000:16:00.0: phy_caps_active:   bit(51): 100GBASE_CR4
[ 1128.297377] ice 0000:16:00.0: phy_caps_active:   bit(56): 100G_CAUI4
[ 1128.297380] ice 0000:16:00.0: phy_caps_active: phy_type_high: 0x0000000000000000
[ 1128.297383] ice 0000:16:00.0: phy_caps_active: report_mode = 0x4
[ 1128.297386] ice 0000:16:00.0: phy_caps_active: caps = 0xc8
[ 1128.297389] ice 0000:16:00.0: phy_caps_active: low_power_ctrl_an = 0x4
[ 1128.297392] ice 0000:16:00.0: phy_caps_active: eee_cap = 0x0
[ 1128.297394] ice 0000:16:00.0: phy_caps_active: eeer_value = 0x0
[ 1128.297397] ice 0000:16:00.0: phy_caps_active: link_fec_options = 0xdf
[ 1128.297400] ice 0000:16:00.0: phy_caps_active: module_compliance_enforcement = 0x0
[ 1128.297402] ice 0000:16:00.0: phy_caps_active: extended_compliance_code = 0xb
[ 1128.297405] ice 0000:16:00.0: phy_caps_active: module_type[0] = 0x11
[ 1128.297408] ice 0000:16:00.0: phy_caps_active: module_type[1] = 0x1
[ 1128.297411] ice 0000:16:00.0: phy_caps_active: module_type[2] = 0x0
Signed-off-by: NAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Co-developed-by: NLukasz Plachno <lukasz.plachno@intel.com>
Signed-off-by: NLukasz Plachno <lukasz.plachno@intel.com>
Reviewed-by: NAlexander Lobakin <alexandr.lobakin@intel.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      f8c74ca6
    • A
      ice: Add port option admin queue commands · 781f15ea
      由 Anatolii Gerasymenko 提交于 
      Implement support for Get/Set Port Options admin queue commands
(0x06EA/0x06EB). These firmware commands allow the driver to change port
specific options and will be used in the next patch.
Co-developed-by: NLev Faerman <lev.faerman@intel.com>
Signed-off-by: NLev Faerman <lev.faerman@intel.com>
Co-developed-by: NDamian Milosek <damian.milosek@intel.com>
Signed-off-by: NDamian Milosek <damian.milosek@intel.com>
Co-developed-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NAnatolii Gerasymenko <anatolii.gerasymenko@intel.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      781f15ea
  5. 18 8月, 2022 1 次提交
  7. 22 7月, 2022 1 次提交
  9. 03 3月, 2022 1 次提交
  11. 19 2月, 2022 1 次提交
    • T
      ice: initialize local variable 'tlv' · 5950bdc8
      由 Tom Rix 提交于 
      Clang static analysis reports this issues
ice_common.c:5008:21: warning: The left expression of the compound
  assignment is an uninitialized value. The computed value will
  also be garbage
  ldo->phy_type_low |= ((u64)buf << (i * 16));
  ~~~~~~~~~~~~~~~~~ ^

When called from ice_cfg_phy_fec() ldo is the uninitialized local
variable tlv.  So initialize.

Fixes: ea78ce4d ("ice: add link lenient and default override support")
Signed-off-by: NTom Rix <trix@redhat.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      5950bdc8
  13. 10 2月, 2022 2 次提交
  15. 07 1月, 2022 1 次提交
  17. 22 12月, 2021 1 次提交
  19. 16 12月, 2021 1 次提交
    • J
      ice: support immediate firmware activation via devlink reload · 399e27db
      由 Jacob Keller 提交于 
      The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).

Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.

In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.

 * The EMP firmware itself can be reloaded by issuing a special update
   to the device called an Embedded Management Processor reset (EMP
   reset). This reset causes the device to reset and reload the EMP
   firmware.

 * PCI configuration changes are only reloaded after a cold PCIe reset.
   Unfortunately there is no generic way to trigger this for a PCIe
   device without a system reboot.

When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.

The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.

The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:

 * A full power on is required
 * A cold PCIe reset is required
 * An EMP reset is required

The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.

For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.

Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.

For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".

Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.

Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.

For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.

For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.

Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.

Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.

Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.

Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:

 # Check current version
 $ devlink dev info

 # Update the device
 $ devlink dev flash pci/0000:af:00.0 file firmware.bin

 # Confirm stored version updated
 $ devlink dev info

 # Reload to activate new firmware
 $ devlink dev reload pci/0000:af:00.0 action fw_activate

 # Confirm running version updated
 $ devlink dev info

Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NGurucharan G <gurucharanx.g@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      399e27db
  21. 15 12月, 2021 4 次提交
  23. 21 10月, 2021 1 次提交
  25. 14 10月, 2021 3 次提交
  27. 11 10月, 2021 2 次提交
  29. 11 6月, 2021 4 次提交
    • J
      ice: register 1588 PTP clock device object for E810 devices · 06c16d89
      由 Jacob Keller 提交于 
      Add a new ice_ptp.c file for holding the basic PTP clock interface
functions. If the device supports PTP, call the new ice_ptp_init and
ice_ptp_release functions where appropriate.

If the function owns the hardware resource associated with the PTP
hardware clock, register with the PTP_1588_CLOCK infrastructure to
allocate a new clock object that represents the device hardware clock.

Implement basic functionality for reading and setting the clock time,
performing clock adjustments, and adjusting the clock frequency.

Future changes will introduce functionality for handling related
features including Tx and Rx timestamps.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      06c16d89
    • J
      ice: add support for set/get of driver-stored firmware parameters · 7f9ab54d
      由 Jacob Keller 提交于 
      Depending on the device configuration, the ice hardware may share the
PTP hardware clock timer between multiple PFs. Each PF is informed by
firmware during initialization of the PTP timer association.

When bringing up PTP, only the PFs which own the timer shall allocate
a PTP hardware clock. Other PFs associated with that timer must report
the correct PTP clock index in order to allow userspace software the
ability to know which ports are connected to the same clock.

To support this, the firmware has driver shared parameters. These
parameters enable one PF to write the clock index into firmware, and
have other PFs read the associated value out. This enables the driver to
have only a single PF allocate and control the device timer registers,
while other PFs associated with that timer can report the correct clock
in the ETHTOOL_GET_TS_INFO report.

Add support for the necessary admin queue commands to enable reading and
writing of the driver shared parameters. This will be used in a future
change to enable sharing the PTP clock index between PF drivers.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      7f9ab54d
    • J
      ice: process 1588 PTP capabilities during initialization · 9733cc94
      由 Jacob Keller 提交于 
      The device firmware reports PTP clock capabilities to each PF during
initialization. This includes various information for both the overall
device and the individual function, including

For functions:
* whether this function has timesync enabled
* whether this function owns one of the 2 possible clock timers, and
  which one
* which timer the function is associated with
* the clock frequency, if the device supports multiple clock frequencies
* The GPIO pin association for the timer owned by this PF, if any

For the device:
* Which PF owns timer 0, if any
* Which PF owns timer 1, if any
* whether timer 0 is enabled
* whether timer 1 is enabled

Extract the bits from the capabilities information reported by firmware
and store them in the device and function capability structures.o

This information will be used in a future change to have the function
driver enable PTP hardware clock support.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      9733cc94
    • J
      ice: add support for sideband messages · 8f5ee3c4
      由 Jacob Keller 提交于 
      In order to support certain device features, including enabling the PTP
hardware clock, the ice driver needs to control some registers on the
device PHY.

These registers are accessed by sending sideband messages. For some
hardware, these messages must be sent over the device admin queue, while
other hardware has a dedicated control queue for the sideband messages.

Add the neighbor device message structure for sending a message to the
neighboring device. Where supported, initialize the sideband control
queue and handle cleanup.

Add a wrapper function for sending sideband control queue messages that
read or write a neighboring device register.

Because some devices send sideband messages over the AdminQ, also
increase the length of the admin queue to allow more messages to be
queued up. This is important because the sideband messages add
additional pressure on the AQ usage.

This support will be used in following patches to enable support for
CONFIG_1588_PTP_CLOCK.
Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NTony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      8f5ee3c4
  31. 07 6月, 2021 1 次提交
  33. 29 5月, 2021 2 次提交
  35. 08 4月, 2021 4 次提交
  37. 01 4月, 2021 2 次提交
  39. 30 3月, 2021 1 次提交
  41. 24 3月, 2021 1 次提交
  43. 09 2月, 2021 3 次提交