summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2022-03-15RDMA/rxe: Shorten pool names in rxe_pool.cBob Pearson
Replace pool names like "rxe-xx" with "xx". Just reduces clutter. Link: https://lore.kernel.org/r/20220304000808.225811-8-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15RDMA/rxe: Move max_elem into rxe_type_infoBob Pearson
Move the maximum number of elements from a parameter in rxe_pool_init to a member of the rxe_type_info array. Link: https://lore.kernel.org/r/20220304000808.225811-7-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15RDMA/rxe: Replace obj by elem in declarationBob Pearson
Fix a harmless typo replacing obj by elem in the cleanup fields. This has no effect but is confusing. Link: https://lore.kernel.org/r/20220304000808.225811-6-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15RDMA/rxe: Delete _locked() APIs for pool objectsBob Pearson
Since caller managed locks for indexed objects are no longer used these APIs are deleted. Link: https://lore.kernel.org/r/20220304000808.225811-5-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15RDMA/rxe: Reverse the sense of RXE_POOL_NO_ALLOCBob Pearson
There is only one remaining object type that allocates its own memory, that is mr. So the sense of RXE_POOL_NO_ALLOC is changed to RXE_POOL_ALLOC. Add checks to rxe_alloc() and rxe_add_to_pool() to make sure the correct call is used for the setting of this flag. Link: https://lore.kernel.org/r/20220304000808.225811-4-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15RDMA/rxe: Replace mr by rkey in responder resourcesBob Pearson
Currently rxe saves a copy of MR in responder resources for RDMA reads. Since the responder resources are never freed just over written if more are needed this MR may not have a reference freed until the QP is destroyed. This patch uses the rkey instead of the MR and on subsequent packets of a multipacket read reply message it looks up the MR from the rkey for each packet. This makes it possible for a user to deregister an MR or unbind a MW on the fly and get correct behaviour. Link: https://lore.kernel.org/r/20220304000808.225811-3-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15RDMA/rxe: Fix ref error in rxe_av.cBob Pearson
The commit referenced below can take a reference to the AH which is never dropped. This only happens in the UD request path. This patch optionally passes that AH back to the caller so that it can hold the reference while the AV is being accessed and then drop it. Code to do this is added to rxe_req.c. The AV is also passed to rxe_prepare in rxe_net.c as an optimization. Fixes: e2fe06c90806 ("RDMA/rxe: Lookup kernel AH from ah index in UD WQEs") Link: https://lore.kernel.org/r/20220304000808.225811-2-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15hwmon: (scpi-hwmon): Use of_device_get_match_data()Minghao Chi
Use of_device_get_match_data() to simplify the code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Reviewed-by: Jean Delvare <jdelvare@suse.de> Link: https://lore.kernel.org/r/20220315023412.2118415-1-chi.minghao@zte.com.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2022-03-15RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPTYixing Liu
Before destroying MPT, the reserved loopback QPs send loopback IOs (one write operation per SL). Completing these loopback IOs represents that there isn't any outstanding request in MPT, then it's safe to destroy MPT. Link: https://lore.kernel.org/r/20220310042835.38634-1-liangwenpeng@huawei.com Signed-off-by: Yixing Liu <liuyixing1@huawei.com> Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15clk: sifive: Move all stuff into SoCs header files from C filesZong Li
Improve PRCI driver to reduce the complexity, we remove the SoCs C files by putting all stuff in each SoCs header files, and include these SoCs-specific header files in core of PRCI. It can also avoid the W=1 kernel build warnings about variable defined but not used [-Wunused-const-variable=], like commit 487dc7bb6a0c ("clk: sifive: fu540-prci: Declare static const variable 'prci_clk_fu540' where it's used") does. Signed-off-by: Zong Li <zong.li@sifive.com> Suggested-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Lee Jones <lee.jones@linaro.org> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/a3c7ec5c46c1d8be455d1c347db4855bb56cec53.1646388139.git.zong.li@sifive.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: sifive: Add SoCs prefix in each SoCs-dependent dataZong Li
This patch is prerequisite for moving SoCs C files into SoCs header files. Currently, fu540-prci.c and fu740-prci.c use same names for several macro definitions and variables, it would cause redefinition error when we trying to include all stuff in sifive-prci.c. In this patch, we also remove the temporary macro definitions which are added by previous patch. Signed-off-by: Zong Li <zong.li@sifive.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Link: https://lore.kernel.org/r/7728ef662c59449ce954b1b62c6ad5241e07adfb.1646388139.git.zong.li@sifive.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: sifive: duplicate the macro definitions for the time beingZong Li
This is a temporary patch in whole patch set. We are going to change the macro name in dt-binding, in order to avoid breaking the driver build and git bisect, add these macro definitions for the time being, and we will remove them later. Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://lore.kernel.org/r/8cfd57f01cfb59adb716eb13ca0c8250c246dcb2.1646388139.git.zong.li@sifive.com Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: qcom: sm6125-gcc: fix typos in commentsJulia Lawall
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20220314115354.144023-16-Julia.Lawall@inria.fr Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: ti: clkctrl: fix typos in commentsJulia Lawall
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Link: https://lore.kernel.org/r/20220314115354.144023-15-Julia.Lawall@inria.fr Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: imx: Select MXC_CLK for i.MX93 clock driverAbel Vesa
Most of the i.MX clock generic API is built by selecting MXC_CLK. Without it, the i.MX93 clock driver will fail to build: aarch64-linux-gnu-ld: drivers/clk/imx/clk-imx93.o: in function `imx93_clocks_probe': clk-imx93.c:(.text+0xa8): undefined reference to `imx_obtain_fixed_clk_hw' So fix this by selecting MXC_CLK for the CLK_IMX93. Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk") Signed-off-by: Abel Vesa <abel.vesa@nxp.com> Reported-by: kernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20220315082446.3120850-1-abel.vesa@nxp.com Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: ti: Drop legacy compatibility clocks for dra7Tony Lindgren
We no longer have users for the compatibility clocks and we can drop them. These are old duplicate clocks for what we using. Depends-on: 31aa7056bbec ("ARM: dts: Don't use legacy clock defines for dra7 clkctrl") Depends-on: 9206a3af4fc0 ("clk: ti: Move dra7 clock devices out of the legacy section") Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20220203085618.16043-4-tony@atomide.com Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: ti: Drop legacy compatibility clocks for am4Tony Lindgren
We no longer have users for the compatibility clocks and we can drop them. These are old duplicate clocks for what we using. Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20220203085618.16043-3-tony@atomide.com Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15clk: ti: Drop legacy compatibility clocks for am3Tony Lindgren
We no longer have users for the compatibility clocks and we can drop them. These are old duplicate clocks for what we using. Cc: devicetree@vger.kernel.org Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20220203085618.16043-2-tony@atomide.com Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2022-03-15Merge tag 'v5.17-rc4' into clk-tiStephen Boyd
We want to get commit 31aa7056bbec ("ARM: dts: Don't use legacy clock defines for dra7 clkctrl") so merge in the nearest rc.
2022-03-15sr: simplify the local variable initialization in sr_block_open()Lukas Bulwahn
Commit 01d0c698536f ("sr: implement ->free_disk to simplify refcounting") refactored sr_block_open(), initialized one variable with a duplicate assignment (probably an unintended copy & paste duplication) and turned one error case into an early return, which makes the initialization of the return variable needless. So, simplify the local variable initialization in sr_block_open() to make the code a bit more clear. No functional change. No change in resulting object code. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220314150321.17720-1-lukas.bulwahn@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2022-03-15iavf: Fix double free in iavf_reset_taskPrzemyslaw Patynowski
Fix double free possibility in iavf_disable_vf, as crit_lock is freed in caller, iavf_reset_task. Add kernel-doc for iavf_disable_vf. Remove mutex_unlock in iavf_disable_vf. Without this patch there is double free scenario, when calling iavf_reset_task. Fixes: e85ff9c631e1 ("iavf: Fix deadlock in iavf_reset_task") Signed-off-by: Przemyslaw Patynowski <przemyslawx.patynowski@intel.com> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: destroy flow director filter mutex after releasing VSIsSudheer Mogilappagari
Currently fdir_fltr_lock is accessed in ice_vsi_release_all() function after it is destroyed. Instead destroy mutex after ice_vsi_release_all. Fixes: 40319796b732 ("ice: Add flow director support for channel mode") Signed-off-by: Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Tested-by: Bharathi Sreenivas <bharathi.sreenivas@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats()Maciej Fijalkowski
It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL. Fixes: e72bba21355d ("ice: split ice_ring onto Tx/Rx separate structs") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Acked-by: Alexander Lobakin <alexandr.lobakin@intel.com> Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: remove PF pointer from ice_check_vf_initJacob Keller
The ice_check_vf_init function takes both a PF and a VF pointer. Every caller looks up the PF pointer from the VF structure. Some callers only use of the PF pointer is call this function. Move the lookup inside ice_check_vf_init and drop the unnecessary argument. Cleanup the callers to drop the now unnecessary local variables. In particular, replace the local PF pointer with a HW structure pointer in ice_vc_get_vf_res_msg which simplifies a few accesses to the HW structure in that function. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: introduce ice_virtchnl.c and ice_virtchnl.hJacob Keller
Just as we moved the generic virtualization library logic into ice_vf_lib.c, move the virtchnl message handling into ice_virtchnl.c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: cleanup long lines in ice_sriov.cJacob Keller
Before we move the virtchnl message handling from ice_sriov.c into ice_virtchnl.c, cleanup some long line warnings to avoid checkpatch.pl complaints. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: introduce ICE_VF_RESET_LOCK flagJacob Keller
The ice_reset_vf function performs actions which must be taken only while holding the VF configuration lock. Some flows already acquired the lock, while other flows must acquire it just for the reset function. Add the ICE_VF_RESET_LOCK flag to the function so that it can handle taking and releasing the lock instead at the appropriate scope. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: introduce ICE_VF_RESET_NOTIFY flagJacob Keller
In some cases of resetting a VF, the PF would like to first notify the VF that a reset is impending. This is currently done via ice_vc_notify_vf_reset. A wrapper to ice_reset_vf, ice_vf_reset_vf, is used to call this function first before calling ice_reset_vf. In fact, every single call to ice_vc_notify_vf_reset occurs just prior to a call to ice_vc_reset_vf. Now that ice_reset_vf has flags, replace this separate call with an ICE_VF_RESET_NOTIFY flag. This removes an unnecessary exported function of ice_vc_notify_vf_reset, and also makes there be a single function to reset VFs (ice_reset_vf). Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: convert ice_reset_vf to take flagsJacob Keller
The ice_reset_vf function takes a boolean parameter which indicates whether or not the reset is due to a VFLR event. This is somewhat confusing to read because readers must interpret what "true" and "false" mean when seeing a line of code like "ice_reset_vf(vf, false)". We will want to add another toggle to the ice_reset_vf in a following change. To avoid proliferating many arguments, convert this function to take flags instead. ICE_VF_RESET_VFLR will indicate if this is a VFLR reset. A value of 0 indicates no flags. One could argue that "ice_reset_vf(vf, 0)" is no more readable than "ice_reset_vf(vf, false)".. However, this type of flags interface is somewhat common and using 0 to mean "no flags" makes sense in this context. We could bother to add a define for "ICE_VF_RESET_PLAIN" or something similar, but this can be confusing since its not an actual bit flag. This paves the way to add another flag to the function in a following change. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: convert ice_reset_vf to standard error codesJacob Keller
The ice_reset_vf function returns a boolean value indicating whether or not the VF reset. This is a bit confusing since it means that callers need to know how to interpret the return value when needing to indicate an error. Refactor the function and call sites to report a regular error code. We still report success (i.e. return 0) in cases where the reset is in progress or is disabled. Existing callers don't care because they do not check the return value. We keep the error code anyways instead of a void return because we expect future code which may care about or at least report the error value. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: make ice_reset_all_vfs voidJacob Keller
The ice_reset_all_vfs function returns true if any VFs were reset, and false otherwise. However, no callers check the return value. Drop this return value and make the function void since the callers do not care about this. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: drop is_vflr parameter from ice_reset_all_vfsJacob Keller
The ice_reset_all_vfs function takes a parameter to handle whether its operating after a VFLR event or not. This is not necessary as every caller always passes true. Simplify the interface by removing the parameter. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: move reset functionality into ice_vf_lib.cJacob Keller
Now that the reset functions do not rely on Single Root specific behavior, move the ice_reset_vf, ice_reset_all_vfs, and ice_vf_rebuild_host_cfg functions and their dependent helper functions out of ice_sriov.c and into ice_vf_lib.c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: fix a long line warning in ice_reset_vfJacob Keller
We're about to move ice_reset_vf out of ice_sriov.c and into ice_vf_lib.c One of the dev_err statements has a checkpatch.pl violation due to putting the vf->vf_id on the same line as the dev_err. Fix this style issue first before moving the code. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: introduce VF operations structure for reset flowsJacob Keller
The ice driver currently supports virtualization using Single Root IOV, with code in the ice_sriov.c file. In the future, we plan to also implement support for Scalable IOV, which uses slightly different hardware implementations for some functionality. To eventually allow this, we introduce a new ice_vf_ops structure which will contain the basic operations that are different between the two IOV implementations. This primarily includes logic for how to handle the VF reset registers, as well as what to do before and after rebuilding the VF's VSI. Implement these ops structures and call the ops table instead of directly calling the SR-IOV specific function. This will allow us to easily add the Scalable IOV implementation in the future. Additionally, it helps separate the generalized VF logic from SR-IOV specifics. This change allows us to move the reset logic out of ice_sriov.c and into ice_vf_lib.c without placing any Single Root specific details into the generic file. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: fix incorrect dev_dbg print mistaking 'i' for vf->vf_idJacob Keller
If we fail to clear the malicious VF indication after a VF reset, the dev_dbg message which is printed uses the local variable 'i' when it meant to use vf->vf_id. Fix this. Fixes: 0891c89674e8 ("ice: warn about potentially malicious VFs") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15ice: introduce ice_vf_lib.c, ice_vf_lib.h, and ice_vf_lib_private.hJacob Keller
Introduce the ice_vf_lib.c file along with the ice_vf_lib.h and ice_vf_lib_private.h header files. These files will house the generic VF structures and access functions. Move struct ice_vf and its dependent definitions into this new header file. The ice_vf_lib.c is compiled conditionally on CONFIG_PCI_IOV. Some of its functionality is required by all driver files. However, some of its functionality will only be required by other files also conditionally compiled based on CONFIG_PCI_IOV. Declaring these functions used only in CONFIG_PCI_IOV files in ice_vf_lib.h is verbose. This is because we must provide a fallback implementation for each function in this header since it is included in files which may not be compiled with CONFIG_PCI_IOV. Instead, introduce a new ice_vf_lib_private.h header which verifies that CONFIG_PCI_IOV is enabled. This header is intended to be directly included in .c files which are CONFIG_PCI_IOV only. Add a #error indication that will complain if the file ever gets included by another C file on a kernel with CONFIG_PCI_IOV disabled. Add a comment indicating the nature of the file and why it is useful. This makes it so that we can easily define functions exposed from ice_vf_lib.c into other virtualization files without needing to add fallback implementations for every single function. This begins the path to separate out generic code which will be reused by other virtualization implementations from ice_sriov.h and ice_sriov.c Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-03-15RDMA/irdma: Add support for address handle re-useMustafa Ismail
Address handles (AH) are a limited HW resource and some user applications may create large numbers of identical AH's. Avoid running out of AH's by reusing existing identical ones. Link: https://lore.kernel.org/r/20220228183650.290-1-shiraz.saleem@intel.com Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2022-03-15Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2022-03-14 Jacob Keller says: The ice_virtchnl_pf.c file has become a single place for a lot of virtualization functionality. This includes most of the virtchnl message handling, integration with kernel hooks like the .ndo operations, reset logic, and more. We are planning in the future to implement and support Scalable IOV in the ice driver. To do this, much (but not all) of the code in ice_virtchnl_pf.c will want to be reused. Rather than dump all of the Scalable IOV implementation into ice_virtchnl_pf.c it makes sense to house it in a separate file. But that still leaves all of the Single Root IOV code littered among more generic logic. The long term goal is to re-organize the code such that generic re-usable code is split into separate files. The ice_sriov.c file would end up containing all of the Single Root IOV implementation specific details, while ice_vf_lib.[ch] and ice_virtchnl.[ch] contain the generic pieces. As a first step, notice that ice_sriov.c currently does not contain much of the SR-IOV implementation. This is housed primarily in ice_virtchnl_pf.c The code in ice_sriov.c is really generic and relates to the VF mailbox, including mailbox overflow detection. Rename ice_sriov.c to ice_vf_mbx.c, and then rename ice_virtchnl_pf.c to ice_sriov.c A later series will finish the refactor by splitting ice_sriov.c into multiple files, moving the generic code into ice_vf_lib.c and ice_virtchnl.c To prepare for that series, perform some basic cleanup and other refactors that we've accumulated during this development cycle. This series builds on top of the recent hash table refactor work. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: use ice_is_vf_trusted helper function ice: log an error message when eswitch fails to configure ice: cleanup error logging for ice_ena_vfs ice: move ice_set_vf_port_vlan near other .ndo ops ice: refactor spoofchk control code in ice_sriov.c ice: rename ICE_MAX_VF_COUNT to avoid confusion ice: remove unused definitions from ice_sriov.h ice: convert vf->vc_ops to a const pointer ice: remove circular header dependencies on ice.h ice: rename ice_virtchnl_pf.c to ice_sriov.c ice: rename ice_sriov.c to ice_vf_mbx.c ==================== Link: https://lore.kernel.org/r/20220315011155.2166817-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-15drm/amdgpu: Use drm_mode_copy()Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/radeon: Use drm_mode_copy()Ville Syrjälä
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amdgpu: Use ternary operator in `vcn_v1_0_start()`Paul Menzel
Remove the boilerplate of declaring a variable and using an if else statement by using the ternary operator. Reviewed-by: James Zhu <James.Zhu@amd.com> Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amdgpu: Remove pointless on stack mode copiesVille Syrjälä
These on stack copies of the modes appear to be pointless. Just look at the originals directly. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: Nikola Cornij <nikola.cornij@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amd/pm: fix indenting in __smu_cmn_reg_print_error()Dan Carpenter
Smatch complains that the dev_err_ratelimited() is indented one tab more than the surrounding lines. drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:174 __smu_cmn_reg_print_error() warn: inconsistent indenting It looks like it's not a bug, just that the indenting needs to be cleaned up. Reviewed-by: Luben Tuikov <luben.tuikov@amd.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amdgpu/dc: fix typos in commentsJulia Lawall
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amdgpu: fix typos in commentsJulia Lawall
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amd/pm: fix typos in commentsJulia Lawall
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amdgpu: Add stolen reserved memory for MI25 SRIOV.Yongqiang Sun
MI25 SRIOV guest driver loading failed due to allocated memory overlaps with firmware reserved area. Allocate stolen reserved memory for MI25 SRIOV specifically to avoid the memory overlap. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amdgpu: Merge get_reserved_allocation to get_vbios_allocations.Yongqiang Sun
Some ASICs need reserved memory for firmware or other components, which is not allowed to be used by driver. amdgpu_gmc_get_reserved_allocation is to handle additional areas. To avoid any missing calling, merged amdgpu_gmc_get_reserved_allocation to amdgpu_gmc_get_vbios_allocations. Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yongqiang Sun <yongqiang.sun@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-03-15drm/amdkfd: evict svm bo worker handle errorPhilip Yang
Migrate vram to ram may fail to find the vma if process is exiting and vma is removed, evict svm bo worker sets prange->svm_bo to NULL and warn svm_bo ref count != 1 only if migrating vram to ram successfully. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit (git 2.34.1) at 2025-09-14 15:21:45 +0000