This feature was meant to be enabled but was accidentally left disabled.
Also downgrades the select/deselect messages to KERN_INFO to reduce log
spam.
Fixes#14546.
Signed-off-by: Christian Svensson <blue@cmd.nu>
The S3IP (Simplified Switch System INtegration Program) sysfs specification defines a unified interface to access peripheral hardware on devices from different vendors, making it easier for SONiC to support different devices and platforms.
PDDF is a framework to simplify the driver and SONiC platform APIs development for new platforms. This effort is first step in combining the two frameworks.
This specific PR adds S3IP supported sysfs attribute in common FAN driver of PDDF.
The S3IP (Simplified Switch System INtegration Program) sysfs specification defines a unified interface to access peripheral hardware on devices from different vendors, making it easier for SONiC to support different devices and platforms.
PDDF is a framework to simplify the driver and SONiC platform APIs development for new platforms. This effort is first step in combining the two frameworks.
This specific PR adds the S3IP supported sysfs attributes in PDDF common LED driver.
Why I did it
The S3IP (Simplified Switch System INtegration Program) sysfs specification defines a unified interface to access peripheral hardware on devices from different vendors, making it easier for SONiC to support different devices and platforms.
PDDF is a framework to simplify the driver and SONiC platform APIs development for new platforms. This effort is first step in combining the two frameworks.
This specific PR adds support for pddf-s3ip-init.service and enables it in PDDF.
Why I did it
To enable FPGA support in PDDF.
How I did it
Added FPGAI2C and FPGAPCI in the build path for the PDDF debian package
Added the support for FPGA access APIs in the drivers of fan, xcvr, led etc.
Added the FPGA device creation support in PDDF utils and parsers
How to verify it
These changes can be verified on some platform using such FPGAs. For testing purpose, we took Dell S5232f platform and brought it up using PDDF. In doing so, FPGA devices are created using PDDF and optics eeproms were accessed using common FPGA drivers. Below are some of the logs.
Why I did it
Some of the platform vendors use FPGA in the HW design. This FPGA is connected to the CPU via PCIe interface. This FPGA also works as an I2C controller having other devices attached to the I2C channels emanating from it. Adding a common module, a driver and a platform specific algorithm module to be used for such FPGA in PDDF.
How I did it
Added 'pddf_fpgapci_module', 'pddf_fpgapci_driver' and a sample algorithm module for Xilinx device 7021. Kernel modules which takes the platform dependent data from PDDF JSON files and initialises the PCIe FPGA. The sample algorithm module can be used by the ODMs in case the communication algorithms are same for their device. Else, they need to come up with similar algo module.
How to verify it
Any platform having such an FPGA and brought up using PDDF would use these kernel modules. The detail representation of such a device in PDDF JSON file is covered in the HLD.
Why I did it
Some of the platform vendors use FPGA in the HW design. This FPGA is connected to the CPU via I2C bus. Adding a common module and a driver to be used for such FPGA in PDDF.
How I did it
Added 'pddf_fpgai2c_module' and 'pddf_fpgai2c_driver' kernel modules which takes the platform dependent data from PDDF JSON files and creates an I2C client for the FPGA.
How to verify it
Any platform having such an FPGA and brought up using PDDF would use these kernel modules. The detail representation of such a device in PDDF JSON file is covered in the HLD.
- Consolidating multiple read functions in a PSU driver on the basis of byte, word or block read,
- Enhancing PDDF parsing script support for CPU and PCH temperature reading,
- Adding missing methods in PDDF common APIs
Why I did it
- PSU driver changes are to optimize the code and increase the code coverage
- PDDF parser script enhancements to accommodate the CPU and PCH temp reading using hwmon device path
- Some of the new APIs were missing from the PDDF common platform classes
How I did it
Added code changes and verified them on AS7816 adn AS7726 platforms.
As per linux kernel 5.10, 'force_deselct_on_exit' parameter used for driver i2c_mux_pca954x is no longer valid. Instead an attribute 'idle_state' is added per MUX device. This needs to be set to
-1 : For leaving the mux state as is
-2 : For deselecting the channel upon exit
: To always set a channel upon exit
This needs to be accommodated inside the PDDF JSON parser as well.
Why I did it
Some platforms need to run few steps before the PDDF service is actually started.
* Adding pre_pddf_init script in the service file
* Raising exception for get_target_speed() for PSU-fan in PDDF (#8129)
- Why I did it
PDDF utils were python2 compliant and they needed to be migrated to Python3 (as per Bullseye)
PDDF common platform APIs file name changed as the name was already in use
Indentation issues
Dead/redundant code needed to be removed
- How I did it
Made files Python3 compliant
Indentation corrected
Redundant code removed
- How to verify it
AS7326 Accton platform uses PDDF. PDDF utils were run on this platform to verify.
- Why I did it
There were compilation errors and warnings like,
/usr/src/linux-headers-5.10.0-8-2-common/scripts/Makefile.build:69: You cannot use subdir-y/m to visit a module Makefile. Use obj-y/m instead.
fatal error: linux/platform_data/pca954x.h: No such file or directory
hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
If PDDF kernel module compilation fails, the PDDF debian package was not detecting the break.
- How I did it
Modified the code with new kernel 5.10 APIs.
Modified the Makefiles to use 'obj-m' instead of 'subdir-y'
- How to verify it
PDDF is supported on Accton platform. Load the build on AS7326 setup and check the 'dmesg'
This change introduces PDDF which is described here: https://github.com/Azure/SONiC/pull/536
Most of the platform bring up effort goes in developing the platform device drivers, SONiC platform APIs and validating them. Typically each platform vendor writes their own drivers and platform APIs which is very tailor made to that platform. This involves writing code, building, installing it on the target platform devices and testing. Many of the details of the platform are hard coded into these drivers, from the HW spec. They go through this cycle repetitively till everything works fine, and is validated before upstreaming the code.
PDDF aims to make this platform driver and platform APIs development process much simpler by providing a data driven development framework. This is enabled by:
JSON descriptor files for platform data
Generic data-driven drivers for various devices
Generic SONiC platform APIs
Vendor specific extensions for customisation and extensibility
Signed-off-by: Fuzail Khan <fuzail.khan@broadcom.com>
