| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
There is a clk == NULL check after the switch to check for
unsupported clk types. Since clk is re-assigned in a loop,
this check is useless right now for anything but the first
round. Let's fix this up by assigning clk = NULL in the
loop before the switch statement.
Fixes: a245fecbb806 ("clk: rockchip: add basic infrastructure for clock branches")
Cc: [email protected]
Signed-off-by: Sebastian Reichel <[email protected]>
[added fixes + stable-cc]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Heiko Stuebner <[email protected]>
|
|
All clocks are registered early using CLK_OF_DECLARE(), which marks
the DT node as processed. For the processed DT node the probe routine
is never called. Thus this whole code is never executed. This could
be "fixed" by using CLK_OF_DECLARE_DRIVER, which avoids marking the
DT node as processed. But then the probe routine would re-register
all the clocks by calling rk3588_clk_init() again.
Signed-off-by: Sebastian Reichel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Heiko Stuebner <[email protected]>
|
|
On an NVMe namespace that does not support metadata, it is possible to
send an IO command with metadata through io-passthru. This allows issues
like [1] to trigger in the completion code path.
nvme_map_user_request() doesn't check if the namespace supports metadata
before sending it forward. It also allows admin commands with metadata to
be processed as it ignores metadata when bdev == NULL and may report
success.
Reject an IO command with metadata when the NVMe namespace doesn't
support it and reject an admin command if it has metadata.
[1] https://lore.kernel.org/all/[email protected]/
Suggested-by: Christoph Hellwig <[email protected]>
Signed-off-by: Puranjay Mohan <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Sagi Grimberg <[email protected]>
Reviewed-by: Anuj Gupta <[email protected]>
Signed-off-by: Keith Busch <[email protected]>
|
|
MULTI GBT AN Control Register is IEEE Standard Register 7.32 (not a mask).
The right place should be in igc_reg.h file. In accordance with the
registers naming convention added IGC_' prefix.
Signed-off-by: Sasha Neftin <[email protected]>
Reviewed-by: Paul Menzel <[email protected]>
Tested-by: Avigail Dahan <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
According to the IEEE standard report the EEE ability (registers 7.60 and
7.62) and the EEE Link Partner ability (registers 7.61 and 7.63). Use the
kernel's 'ethtool_keee' structure and report EEE link modes.
Example:
ethtool --show-eee <device>
Before:
Advertised EEE link modes: Not reported
Link partner advertised EEE link modes: Not reported
After:
Advertised EEE link modes: 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised EEE link modes: 100baseT/Full
1000baseT/Full
2500baseT/Full
Signed-off-by: Sasha Neftin <[email protected]>
Tested-by: Avigail Dahan <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
When running the igc with XDP/ZC in busy polling mode with deferral of hard
interrupts, interrupts still happen from time to time. That is caused by
the igc task watchdog which triggers Rx interrupts periodically.
That mechanism has been introduced to overcome skb/memory allocation
failures [1]. So the Rx clean functions stop processing the Rx ring in case
of such failure. The task watchdog triggers Rx interrupts periodically in
the hope that memory became available in the mean time.
The current behavior is undesirable for real time applications, because the
driver induced Rx interrupts trigger also the softirq processing. However,
all real time packets should be processed by the application which uses the
busy polling method.
Therefore, only trigger the Rx interrupts in case of real allocation
failures. Introduce a new flag for signaling that condition.
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=3be507547e6177e5c808544bd6a2efa2c7f1d436
Reviewed-by: Sebastian Andrzej Siewior <[email protected]>
Acked-by: Vinicius Costa Gomes <[email protected]>
Acked-by: Maciej Fijalkowski <[email protected]>
Signed-off-by: Kurt Kanzenbach <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Mor Bar-Gabay <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
Add support for offloading MQPRIO. The hardware has four priorities as well
as four queues. Each queue must be a assigned with a unique priority.
However, the priorities are only considered in TSN Tx mode. There are two
TSN Tx modes. In case of MQPRIO the Qbv capability is not required.
Therefore, use the legacy TSN Tx mode, which performs strict priority
arbitration.
Example for mqprio with hardware offload:
|tc qdisc replace dev ${INTERFACE} handle 100 parent root mqprio num_tc 4 \
| map 0 0 0 0 0 1 2 3 0 0 0 0 0 0 0 0 \
| queues 1@0 1@1 1@2 1@3 \
| hw 1
The mqprio Qdisc also allows to configure the `preemptible_tcs'. However,
frame preemption is not supported yet.
Tested on Intel i225 and implemented by following data sheet section 7.5.2,
Transmit Scheduling.
Signed-off-by: Kurt Kanzenbach <[email protected]>
Reviewed-by: Wojciech Drewek <[email protected]>
Acked-by: Vinicius Costa Gomes <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Tested-by: Mor Bar-Gabay <[email protected]>
Signed-off-by: Tony Nguyen <[email protected]>
|
|
When VCMDQs are assigned to a VINTF owned by a guest (HYP_OWN bit unset),
only TLB and ATC invalidation commands are supported by the VCMDQ HW. So,
implement the new cmdq->supports_cmd op to scan the input cmd in order to
make sure that it is supported by the selected queue.
Note that the guest VM shouldn't have HYP_OWN bit being set regardless of
guest kernel driver writing it or not, i.e. the hypervisor running in the
host OS should wire this bit to zero when trapping a write access to this
VINTF_CONFIG register from a guest kernel.
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/8160292337059b91271045800e5c62f7295e2c24.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
The VCMDQ in the tegra241-cmdqv driver has a guest mode that supports only
a few invalidation commands. A batch is initialized with a cmdq, so it has
to confirm whether a new command is supported or not.
Add a supports_cmd function pointer to the cmdq structure, where the vcmdq
driver should hook a command scan function. Add an inline helper too so it
can be used by both sides.
If a new command is not supported, simply issue the existing batch and re-
init it as a new batch.
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/aafb24b881504f18c5d0c7c15f2134e40ad2c486.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
NVIDIA's Tegra241 Soc has a CMDQ-Virtualization (CMDQV) hardware, extending
the standard ARM SMMU v3 IP to support multiple VCMDQs with virtualization
capabilities. In terms of command queue, they are very like a standard SMMU
CMDQ (or ECMDQs), but only support CS_NONE in the CS field of CMD_SYNC.
Add a new tegra241-cmdqv driver, and insert its structure pointer into the
existing arm_smmu_device, and then add related function calls in the SMMUv3
driver to interact with the CMDQV driver.
In the CMDQV driver, add a minimal part for the in-kernel support: reserve
VINTF0 for in-kernel use, and assign some of the VCMDQs to the VINTF0, and
select one VCMDQ based on the current CPU ID to execute supported commands.
This multi-queue design for in-kernel use gives some limited improvements:
up to 20% reduction of invalidation time was measured by a multi-threaded
DMA unmap benchmark, compared to a single queue.
The other part of the CMDQV driver will be user-space support that gives a
hypervisor running on the host OS to talk to the driver for virtualization
use cases, allowing VMs to use VCMDQs without trappings, i.e. no VM Exits.
This is designed based on IOMMUFD, and its RFC series is also under review.
It will provide a guest OS a bigger improvement: 70% to 90% reductions of
TLB invalidation time were measured by DMA unmap tests running in a guest,
compared to nested SMMU CMDQ (with trappings).
As the initial version, the CMDQV driver only supports ACPI configurations.
Signed-off-by: Nate Watterson <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Co-developed-by: Nicolin Chen <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/dce50490b2c10b7254fb36aa73ed7ffd812b283a.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
Mimicing the arm-smmu (v2) driver, introduce a struct arm_smmu_impl_ops to
accommodate impl routines.
Suggested-by: Will Deacon <[email protected]>
Signed-off-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/8fe9f3805568aabf771fc6706c116459016bf62d.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
For model-specific implementation, repurpose the acpi_smmu_get_options()
to a wider acpi_smmu_acpi_probe_model(). A new model can add to the list
in this new function.
Suggested-by: Will Deacon <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/79716299829aeab2e55b8c7932f2634b209bb4d5.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
The CMDQV extension in NVIDIA Tegra241 SoC only supports CS_NONE in the
CS field of CMD_SYNC. Add a new SMMU option to accommodate that.
Suggested-by: Will Deacon <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/a3cb9bb2429fbae4a59f7ef517614d226763d717.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
The symbols __arm_smmu_cmdq_skip_err(), arm_smmu_init_one_queue(), and
arm_smmu_cmdq_init() need to be used by the tegra241-cmdqv compilation
unit in a following patch.
Remove the static and put prototypes in the header.
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/c4f2aa5f5f40a2e7c68b132c6d3171d6403de57a.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
So that this function can be used by other cmdqs than &smmu->cmdq only.
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/e11a3c0bde172c9652c2946f12bc2ceed4c3a355.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
The CMDQV extension on NVIDIA Tegra241 SoC only supports CS_NONE in the
CS field of CMD_SYNC, v.s. standard SMMU CMDQ. Pass in the cmdq pointer
directly, so the function can identify a different cmdq implementation.
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/723288287997b6dfbcd2a904d2c11e9b23f82250.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
The driver calls in different places the arm_smmu_get_cmdq() helper, and
it's fine to do so since the helper always returns the single SMMU CMDQ.
However, with NVIDIA CMDQV extension or SMMU ECMDQ, there can be multiple
cmdqs in the system to select one from. And either case requires a batch
of commands to be issued to the same cmdq. Thus, a cmdq has to be decided
in the higher-level callers.
Add a cmdq pointer in arm_smmu_cmdq_batch structure, and decide the cmdq
when initializing the batch. Pass its pointer down to the bottom function.
Update __arm_smmu_cmdq_issue_cmd() accordingly for single command issuers.
Suggested-by: Jason Gunthorpe <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Signed-off-by: Nicolin Chen <[email protected]>
Link: https://lore.kernel.org/r/2cbf5ddefb6ea611e48d67c642271bd24421eb21.1724970714.git.nicolinc@nvidia.com
Signed-off-by: Will Deacon <[email protected]>
|
|
Use the dev_err_probe() helper to simplify error handling during probe.
This also handle scenario, when EDEFER is returned and useless error
is printed.
Signed-off-by: Jinjie Ruan <[email protected]>
Acked-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Use devm_spi_alloc_host() so that there's no need to call
spi_controller_put() in the error path.
Signed-off-by: Jinjie Ruan <[email protected]>
Acked-by: Michal Simek <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial device id for 6.11-rc6
Here's a new modem device id.
This one has been in linux-next with no reported issues.
* tag 'usb-serial-6.11-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: option: add MeiG Smart SRM825L
|
|
Enable compile testing for broader build coverage. None of the drivers
use anything from "asm", so code should build everywhere.
CONFIG_PLAT_VERSATILE is being selected by driver dependencies
(CONFIG_ARCH_INTEGRATOR and CONFIG_ARCH_REALVIEW), so directory can be
always added to Makefile targets without impacting other configurations.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
If device is unbound, the soc_dev should be unregistered to prevent
memory leak.
Fixes: a2974c9c1f83 ("soc: add driver for the ARM RealView")
Cc: [email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
If device is unbound, the memory allocated for soc_dev_attr should be
freed to prevent leaks.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Driver is leaking OF node reference obtained from
of_find_matching_node().
Fixes: f956a785a282 ("soc: move SoC driver for the ARM Integrator")
Cc: [email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
There is only one called of alloc_page_buffers and it doesn't require
__GFP_NOFAIL so drop this allocation mode.
Signed-off-by: Michal Hocko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Song Liu <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>
|
|
We use komeda_crtc_normalize_zpos to normalize zpos of affected planes
to their blending zorder in CU. If there's only one slave plane in
affected planes and its layer_split property is enabled, order++ for
its split layer, so that when calculating the normalized_zpos
of master planes, the split layer of the slave plane is included, but
the max_slave_zorder does not include the split layer and keep zero
because there's only one slave plane in affacted planes, although we
actually use two slave layers in this commit.
In most cases, this bug does not result in a commit failure, but assume
the following situation:
slave_layer 0: zpos = 0, layer split enabled, normalized_zpos =
0;(use slave_layer 2 as its split layer)
master_layer 0: zpos = 2, layer_split enabled, normalized_zpos =
2;(use master_layer 2 as its split layer)
master_layer 1: zpos = 4, normalized_zpos = 4;
master_layer 3: zpos = 5, normalized_zpos = 5;
kcrtc_st->max_slave_zorder = 0;
When we use master_layer 3 as a input of CU in function
komeda_compiz_set_input and check it with function
komeda_component_check_input, the parameter idx is equal to
normailzed_zpos minus max_slave_zorder, the value of idx is 5
and is euqal to CU's max_active_inputs, so that
komeda_component_check_input returns a -EINVAL value.
To fix the bug described above, when calculating the max_slave_zorder
with the layer_split enabled, count the split layer in this calculation
directly.
Signed-off-by: hongchi.peng <[email protected]>
Acked-by: Liviu Dudau <[email protected]>
Signed-off-by: Liviu Dudau <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The current __arm_lpae_unmap() function calls dma_sync() on individual
PTEs after clearing them. Overall unmap performance can be improved by
around 25% for large buffer sizes by combining the syncs for adjacent
leaf entries.
Optimize the unmap time by clearing all the leaf entries and issuing a
single dma_sync() for them.
Below is detailed analysis of average unmap latency(in us) with and
without this optimization obtained by running dma_map_benchmark for
different buffer sizes.
UnMap Latency(us)
Size Without With % gain with
optimiztion optimization optimization
4KB 3 3 0
8KB 4 3.8 5
16KB 6.1 5.4 11.48
32KB 10.2 8.5 16.67
64KB 18.5 14.9 19.46
128KB 35 27.5 21.43
256KB 67.5 52.2 22.67
512KB 127.9 97.2 24.00
1MB 248.6 187.4 24.62
2MB 65.5 65.5 0
4MB 119.2 119 0.17
Reviewed-by: Robin Murphy <[email protected]>
Signed-off-by: Ashish Mhetre <[email protected]>
Acked-by: Will Deacon <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
|
|
PCI ATS has a global Smallest Translation Unit field that is located in
the PF but shared by all of the VFs.
The expectation is that the STU will be set to the root port's global STU
capability which is driven by the IO page table configuration of the iommu
HW. Today it becomes set when the iommu driver first enables ATS.
Thus, to enable ATS on the VF, the PF must have already had the correct
STU programmed, even if ATS is off on the PF.
Unfortunately the PF only programs the STU when the PF enables ATS. The
iommu drivers tend to leave ATS disabled when IDENTITY translation is
being used.
Thus we can get into a state where the PF is setup to use IDENTITY with
the DMA API while the VF would like to use VFIO with a PAGING domain and
have ATS turned on. This fails because the PF never loaded a PAGING domain
and so it never setup the STU, and the VF can't do it.
The simplest solution is to have the iommu driver set the ATS STU when it
probes the device. This way the ATS STU is loaded immediately at boot time
to all PFs and there is no issue when a VF comes to use it.
Add a new call pci_prepare_ats() which should be called by iommu drivers
in their probe_device() op for every PCI device if the iommu driver
supports ATS. This will setup the STU based on whatever page size
capability the iommu HW has.
Signed-off-by: Jason Gunthorpe <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Kevin Tian <[email protected]>
Reviewed-by: Lu Baolu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
|
|
The header file linux/platform_device.h is included
twice. Remove the last one.
Signed-off-by: Hongbo Li <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
intel_spi_populate_chip() use devm_kasprintf() to set pdata->name.
This can return a NULL pointer on failure but this returned value
is not checked.
Fixes: e58db3bcd93b ("spi: intel: Add default partition and name to the second chip")
Signed-off-by: Charles Han <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Currently users can get the Root Ports supported by the PCIe PMU by
"bus" sysfs attributes which indicates the PCIe bus number where
Root Ports are located. This maybe insufficient since Root Ports
supported by different PCIe PMUs may be located on the same PCIe bus.
So export the BDF range the Root Ports additionally.
Signed-off-by: Yicong Yang <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
We make the initial value of event ctrl register as HISI_PCIE_INIT_SET
and modify according to the user options. This will make TLP headers
bandwidth only counting never take effect since HISI_PCIE_INIT_SET
configures to count the TLP payloads bandwidth. Fix this by making
the initial value of event ctrl register as 0.
Fixes: 17d573984d4d ("drivers/perf: hisi: Add TLP filter support")
Signed-off-by: Yicong Yang <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
Currently we set the period and record it as the initial value of the
counter without checking it's set to the hardware successfully or not.
However the counter maybe unwritable if the target event is unsupported
by the device. In such case we will pass user a wrong count:
[start counts when setting the period]
hwc->prev_count = 0x8000000000000000
device.counter_value = 0 // the counter is not set as the period
[when user reads the counter]
event->count = device.counter_value - hwc->prev_count
= 0x8000000000000000 // wrong. should be 0.
Fix this by record the hardware counter counts correctly when setting
the period.
Fixes: 8404b0fbc7fb ("drivers/perf: hisi: Add driver for HiSilicon PCIe PMU")
Signed-off-by: Yicong Yang <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Will Deacon <[email protected]>
|
|
Use perf_allow_kernel() for 'pa_enable' (physical addresses),
'pct_enable' (physical timestamps) and context IDs. This means that
perf_event_paranoid is now taken into account and LSM hooks can be used,
which is more consistent with other perf_event_open calls. For example
PERF_SAMPLE_PHYS_ADDR uses perf_allow_kernel() rather than just
perfmon_capable().
This also indirectly fixes the following error message which is
misleading because perf_event_paranoid is not taken into account by
perfmon_capable():
$ perf record -e arm_spe/pa_enable/
Error:
Access to performance monitoring and observability operations is
limited. Consider adjusting /proc/sys/kernel/perf_event_paranoid
setting ...
Suggested-by: Al Grant <[email protected]>
Signed-off-by: James Clark <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Will Deacon <[email protected]>
|
|
The req_lock is currently implemented as a rw_lock, but there are no
instances where read_lock() is called. This means that the lock is
effectively only used by writers, making it functionally equivalent to
a simple spinlock.
As stated in Documentation/locking/spinlocks.rst:
"Reader-writer locks require more atomic memory operations than simple
spinlocks. Unless the reader critical section is long, you are better
off just using spinlocks."
Since the rw_lock in this case incurs additional atomic memory
operations without any benefit from reader-writer locking, it is more
efficient to replace it with a spinlock. This patch implements that
replacement to optimize the driver's performance.
Signed-off-by: Kuan-Wei Chiu <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Simplify the code by replacing devm_clk_get() and clk_prepare_enable()
with devm_clk_get_enabled(), which also avoids the call to
clk_disable_unprepare().
Signed-off-by: Chunhai Guo <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Simplify the code by replacing devm_clk_get() and clk_prepare() with
devm_clk_get_prepared(), which also avoids the call to clk_unprepare().
Signed-off-by: Chunhai Guo <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
It's unlikely that devm_pm_runtime_enable ever fails. Still, it makes
sense to read the return value and handle errors.
Signed-off-by: Martin Kaiser <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The driver uses the rst variable only for an initial reset when the chip
is probed. There's no need to store rst in the driver's private data, we
can make it a local variable in the probe function.
Signed-off-by: Martin Kaiser <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
The devm_clk_get_enabled() helpers:
- call devm_clk_get()
- call clk_prepare_enable() and register what is needed in order to
call clk_disable_unprepare() when needed, as a managed resource.
This simplifies the code and avoids the calls to clk_disable_unprepare().
Signed-off-by: Huan Yang <[email protected]>
Reviewed-by: Martin Kaiser <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This function is never implemented and used since introduction in
commit 049359d65527 ("crypto: amcc - Add crypt4xx driver").
Signed-off-by: Yue Haibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This function is never implemented and used since introduction in
commit 48fe583fe541 ("crypto: amlogic - Add crypto accelerator for
amlogic GXL").
Signed-off-by: Yue Haibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This function is never implemented and used since introduction in
commit 720419f01832 ("crypto: ccp - Introduce the AMD Secure Processor
device").
Signed-off-by: Yue Haibing <[email protected]>
Acked-by: Tom Lendacky <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This function is never implemented and used since introduction in
commit 10b4f09491bf ("crypto: marvell - add the Virtual Function
driver for CPT")
Signed-off-by: Yue Haibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
This function is never implemented and used since introduction in
commit 46c5338db7bd ("crypto: sl3516 - Add sl3516 crypto engine")
Signed-off-by: Yue Haibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Commit 9744fec95f06 ("crypto: inside-secure - remove request list to
improve performance") declar this but never implemented.
Signed-off-by: Yue Haibing <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
In case of sev PLATFORM_STATUS failure, sev_get_api_version() fails
resulting in sev_data field of psp_master nulled out. This later becomes
a problem when unloading the ccp module because the device has not been
unregistered (via misc_deregister()) before clearing the sev_data field
of psp_master. As a result, on reloading the ccp module, a duplicate
device issue is encountered as can be seen from the dmesg log below.
on reloading ccp module via modprobe ccp
Call Trace:
<TASK>
dump_stack_lvl+0xd7/0xf0
dump_stack+0x10/0x20
sysfs_warn_dup+0x5c/0x70
sysfs_create_dir_ns+0xbc/0xd
kobject_add_internal+0xb1/0x2f0
kobject_add+0x7a/0xe0
? srso_alias_return_thunk+0x5/0xfbef5
? get_device_parent+0xd4/0x1e0
? __pfx_klist_children_get+0x10/0x10
device_add+0x121/0x870
? srso_alias_return_thunk+0x5/0xfbef5
device_create_groups_vargs+0xdc/0x100
device_create_with_groups+0x3f/0x60
misc_register+0x13b/0x1c0
sev_dev_init+0x1d4/0x290 [ccp]
psp_dev_init+0x136/0x300 [ccp]
sp_init+0x6f/0x80 [ccp]
sp_pci_probe+0x2a6/0x310 [ccp]
? srso_alias_return_thunk+0x5/0xfbef5
local_pci_probe+0x4b/0xb0
work_for_cpu_fn+0x1a/0x30
process_one_work+0x203/0x600
worker_thread+0x19e/0x350
? __pfx_worker_thread+0x10/0x10
kthread+0xeb/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x3c/0x60
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
kobject: kobject_add_internal failed for sev with -EEXIST, don't try to register things with the same name in the same directory.
ccp 0000:22:00.1: sev initialization failed
ccp 0000:22:00.1: psp initialization failed
ccp 0000:a2:00.1: no command queues available
ccp 0000:a2:00.1: psp enabled
Address this issue by unregistering the /dev/sev before clearing out
sev_data in case of PLATFORM_STATUS failure.
Fixes: 200664d5237f ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support")
Cc: [email protected]
Signed-off-by: Pavan Kumar Paluri <[email protected]>
Acked-by: Tom Lendacky <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
In case of error in build_tokens_sysfs(), all the memory that has been
allocated is freed at end of this function. But then free_group() is
called which performs memory deallocation again.
Also, instead of free_group() call, there should be exit_dell_smbios_smm()
and exit_dell_smbios_wmi() calls, since there is initialization, but there
is no release of resources in case of an error.
Fix these issues by replacing free_group() call with
exit_dell_smbios_wmi() and exit_dell_smbios_smm().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 33b9ca1e53b4 ("platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens")
Signed-off-by: Aleksandr Mishin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Ilpo Järvinen <[email protected]>
|
|
Simplify memory unwinding on error also fixing current memory
leak that can happen on error.
v2: use devm_kcalloc(Matt A)
Fixes: 3338e4f90c14 ("drm/xe: Use topology to determine page fault queue size")
Cc: Matthew Auld <[email protected]>
Cc: Matthew Brost <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Stuart Summers <[email protected]>
Reviewed-by: Matthew Auld <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Nirmoy Das <[email protected]>
|
|
This driver supports Applied Micro Circuits Corporation QT2025 PHY,
based on a driver for Tehuti Networks TN40xx chips.
The original driver for TN40xx chips supports multiple PHY hardware
(AMCC QT2025, TI TLK10232, Aqrate AQR105, and Marvell 88X3120,
88X3310, and MV88E2010). This driver is extracted from the original
driver and modified to a PHY driver in Rust.
This has been tested with Edimax EN-9320SFP+ 10G network adapter.
Reviewed-by: Trevor Gross <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Signed-off-by: FUJITA Tomonori <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|