On 11/8/23 08:40, Dan Carpenter wrote:
The r535_gsp_cmdq_get() function returns error pointers but this code
checks for NULL. Also we need to propagate the error pointer back to
the callers in r535_gsp_rpc_get(). Returning NULL will lead to a NULL
pointer dereference.
Fixes: 176fdcbddfd2
The logic to calculate bandwidth limits may be used at multiple call sites
so split it up into its own static function instead.
No intended functional changes.
Suggested-by: Ilpo Järvinen
Signed-off-by: Mario Limonciello
---
v2->v3:
* Split from previous patch version
---
drivers/pci/pci.c |
The USB4 spec specifies that PCIe ports that are used for tunneling
PCIe traffic over USB4 fabric will be hardcoded to advertise 2.5GT/s and
behave as a PCIe Gen1 device. The actual performance of these ports is
controlled by the fabric implementation.
Callers for pcie_bandwidth_available() will
All callers have switched to dev_is_removable() for detecting
hotpluggable PCIe devices.
Signed-off-by: Mario Limonciello
---
v2->v3:
* No changes
---
include/linux/pci.h | 22 --
1 file changed, 22 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index
commit 493fb50e958c ("PCI: pciehp: Assume NoCompl+ for Thunderbolt
ports") added a check into pciehp code to explicitly set NoCompl+
for all Intel Thunderbolt controllers, including those that don't
need it.
This overloaded the purpose of the `is_thunderbolt` member of
`struct pci_device` because
USB4 routers support a feature called "PCIe tunneling". This
allows PCIe traffic to be transmitted over USB4 fabric.
PCIe root ports that are used in this fashion can be discovered
by device specific data that specifies the USB4 router they are
connected to. For the PCI core, the specific
pci_is_thunderbolt_attached() looks at the hierarchy of the PCIe device
to determine if any bridge along the way has the is_thunderbolt bit set.
This bit will only be set when one of the devices in the hierarchy is an
Intel Thunderbolt device.
However PCIe devices can be connected to USB4 hubs
pci_is_thunderbolt_attached() looks at the hierarchy of the PCIe device
to determine if any bridge along the way has the is_thunderbolt bit set.
This bit will only be set when one of the devices in the hierarchy is an
Intel Thunderbolt device.
However PCIe devices can be connected to USB4 hubs
The wrong values are reported from pcie_bandwidth_available() which
can cause problems for performance of eGPUs.
This series overhauls Thunderbolt related device detection and uses
the changes to change the behavior of pcie_bandwidth_available().
v2->v3:
* Stop lumping all thunderbolt VSEC and
On 11/5/23 21:37, Dave Airlie wrote:
From: Dave Airlie
If we get back ENODEV don't fail load.
Maybe worth to note why this is OK in this case, might not be obvious
to future readers of the code.
Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
Maybe I'm missing
Hi Yuran,
On 10/26/23 19:03, Yuran Pereira wrote:
There are instances where the "args" argument passed to
nouveau_uvmm_sm_prepare() is NULL.
I.e. when nouveau_uvmm_sm_prepare() is called from
nouveau_uvmm_sm_unmap_prepare()
```
static int
nouveau_uvmm_sm_unmap_prepare(struct nouveau_uvmm
11 matches
Mail list logo
