On 5/18/23 11:16 PM, Eric W. Biederman wrote:
> Mike Christie writes:
>
>> On 5/18/23 1:28 PM, Eric W. Biederman wrote:
>>> Still the big issue seems to be the way get_signal is connected into
>>> these threads so that it keeps getting called. Calling get_signal after
>>> a fatal signal has been
Add the documentation and Kconfig entry for pds_vdpa driver.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
---
.../device_drivers/ethernet/amd/pds_vdpa.rst | 85 +++
.../device_drivers/ethernet/index.rst | 1 +
MAINTAINERS | 4 +
These are the adminq commands that will be needed for
setting up and using the vDPA device. There are a number
of commands defined in the FW's API, but by making use of
the FW's virtio BAR we only need a few of these commands
for vDPA support.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
Register for the pds_core's notification events, primarily to
find out when the FW has been reset so we can pass this on
back up the chain.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
---
drivers/vdpa/pds/vdpa_dev.c | 59 -
drivers/vdpa/pds/vdpa_dev.h
Prep and use the "modern" virtio bar utilities to get our
virtio config space ready.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
---
drivers/vdpa/pds/aux_drv.c | 25 +
drivers/vdpa/pds/aux_drv.h | 3 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/vdp
This is the vDPA device support, where we advertise that we can
support the virtio queues and deal with the configuration work
through the pds_core's adminq.
Signed-off-by: Shannon Nelson
---
Note: this had previously been Acked-by Jason Wang, but changed enough
in v6 that I felt it needs
Add new adminq definitions in support for vDPA operations.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
---
include/linux/pds/pds_adminq.h | 226 +
1 file changed, 226 insertions(+)
diff --git a/include/linux/pds/pds_adminq.h b/include/linux/pds/pds_adminq
Find the vDPA management information from the DSC in order to
advertise it to the vdpa subsystem.
Signed-off-by: Shannon Nelson
Acked-by: Jason Wang
---
drivers/vdpa/pds/Makefile | 3 +-
drivers/vdpa/pds/aux_drv.c | 17 ++
drivers/vdpa/pds/aux_drv.h | 7 +++
drivers/vdpa/pds/debugf
This is the initial auxiliary driver framework for a new vDPA
device driver, an auxiliary_bus client of the pds_core driver.
The pds_core driver supplies the PCI services for the VF device
and for accessing the adminq in the PF device.
This patch adds the very basics of registering for the auxilia
The pds_core_logical_qtype enum and IFNAMSIZ are not needed
in the common PDS header, only needed when working with the
adminq, so move them to the adminq header.
Note: This patch might conflict with pds_vfio patches that are
in review, depending on which patchset gets pulled first.
Signed-
To add a bit of vendor flexibility with various virtio based devices,
allow the caller to check for a different device id. This adds a function
pointer field to struct virtio_pci_modern_device to specify an override
device id check. If defined by the driver, this function will be called
to check
This patchset implements a new module for the AMD/Pensando DSC that
supports vDPA services on PDS Core VF devices. This code is based on
and depends on include files from the pds_core driver described here[0].
The pds_core driver creates the auxiliary_bus devices that this module
connects to, and
To add a bit of vendor flexibility with various virtio based devices,
allow the caller to specify a different DMA mask. This adds a dma_mask
field to struct virtio_pci_modern_device. If defined by the driver,
this mask will be used in a call to dma_set_mask_and_coherent() instead
of the tradition
On Thu, May 18, 2023, at 23:56, Dave Hansen wrote:
> On 5/16/23 12:35, Arnd Bergmann wrote:
>>
>> All of the warnings have to be addressed in some form before the warning
>> can be enabled by default.
>
> I picked up the ones that were blatantly obvious, but left out 03, 04,
> 10, 12 and 19 for th
On Thu, May 18, 2023, at 19:28, Dave Hansen wrote:
> On 5/16/23 12:35, Arnd Bergmann wrote:
>>
>> arch/x86/xen/enlighten_pv.c:1233:34: error: no previous prototype for
>> 'xen_start_kernel' [-Werror=missing-prototypes]
>> arch/x86/xen/irq.c:22:14: error: no previous prototype for
>> 'xen_force_e
On Fri, May 19, 2023 at 12:56 AM Dave Hansen wrote:
> On 5/16/23 12:35, Arnd Bergmann wrote:
> I picked up the ones that were blatantly obvious, but left out 03, 04,
> 10, 12 and 19 for the moment.
Btw, there is series that went unnoticed
https://lore.kernel.org/all/2029110017.48510-1-andri
16 matches
Mail list logo
