Add PCI ID to support QEMU ufs.
The new qemu ufs device can be found at
https://lore.kernel.org/qemu-devel/20230727155239.GA979354@fedora
Signed-off-by: Jeuk Kim <[email protected]>
---
drivers/ufs/host/ufshcd-pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ufs/host/ufshcd-pci.c b/drivers/ufs/host/ufshcd-pci.c
index cf3987773051..29d322931427 100644
--- a/drivers/ufs/host/ufshcd-pci.c
+++ b/drivers/ufs/host/ufshcd-pci.c
@@ -590,6 +590,7 @@ static const struct dev_pm_ops ufshcd_pci_pm_ops = {
};
static const struct pci_device_id ufshcd_pci_tbl[] = {
+ { PCI_VENDOR_ID_REDHAT, 0x0013, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ PCI_VENDOR_ID_SAMSUNG, 0xC00C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ PCI_VDEVICE(INTEL, 0x9DFA), (kernel_ulong_t)&ufs_intel_cnl_hba_vops },
{ PCI_VDEVICE(INTEL, 0x4B41), (kernel_ulong_t)&ufs_intel_ehl_hba_vops },
--
2.34.1
On 1/08/23 10:37, Jeuk Kim wrote:
> Add PCI ID to support QEMU ufs.
>
> The new qemu ufs device can be found at
> https://lore.kernel.org/qemu-devel/20230727155239.GA979354@fedora
Please say something about why a UFS device is being virtualized
and what features it is expected to support.
>
> Signed-off-by: Jeuk Kim <[email protected]>
> ---
> drivers/ufs/host/ufshcd-pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/ufs/host/ufshcd-pci.c b/drivers/ufs/host/ufshcd-pci.c
> index cf3987773051..29d322931427 100644
> --- a/drivers/ufs/host/ufshcd-pci.c
> +++ b/drivers/ufs/host/ufshcd-pci.c
> @@ -590,6 +590,7 @@ static const struct dev_pm_ops ufshcd_pci_pm_ops = {
> };
>
> static const struct pci_device_id ufshcd_pci_tbl[] = {
> + { PCI_VENDOR_ID_REDHAT, 0x0013, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { PCI_VENDOR_ID_SAMSUNG, 0xC00C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> { PCI_VDEVICE(INTEL, 0x9DFA), (kernel_ulong_t)&ufs_intel_cnl_hba_vops },
> { PCI_VDEVICE(INTEL, 0x4B41), (kernel_ulong_t)&ufs_intel_ehl_hba_vops },
On 1/08/23, Adrian Hunter wrote:
> On 1/08/23 10:37, Jeuk Kim wrote:
> > Add PCI ID to support QEMU ufs.
> >
> > The new qemu ufs device can be found at
> > https://lore.kernel.org/qemu-devel/20230727155239.GA979354@fedora
>
> Please say something about why a UFS device is being virtualized
> and what features it is expected to support.
Hi Adrian!
UFS device emulation feature has been newly added to QEMU recently.
Currently, QEMU UFS supports basic io and query request features,
and plans to add more features in the future.
With the addition of the QEMU ufs device emulation feature,
QEMU UFS decided to use the pci device id of 0x0013 in the REDHAT vendor id (0x1b36).
However, this information is not registered in the linux ufs driver,
so the current linux kernel does not recognize the QEMU UFS device.
Therefore, I want to register the QEMU ufs pci id through this patch.
Do I need to add the above content to the commit message?
Thanks,
Jeuk
> >
> > Signed-off-by: Jeuk Kim <[email protected]>
> > ---
> > drivers/ufs/host/ufshcd-pci.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/ufs/host/ufshcd-pci.c b/drivers/ufs/host/ufshcd-pci.c
> > index cf3987773051..29d322931427 100644
> > --- a/drivers/ufs/host/ufshcd-pci.c
> > +++ b/drivers/ufs/host/ufshcd-pci.c
> > @@ -590,6 +590,7 @@ static const struct dev_pm_ops ufshcd_pci_pm_ops = {
> > };
> >
> > static const struct pci_device_id ufshcd_pci_tbl[] = {
> > + { PCI_VENDOR_ID_REDHAT, 0x0013, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> > { PCI_VENDOR_ID_SAMSUNG, 0xC00C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> > { PCI_VDEVICE(INTEL, 0x9DFA), (kernel_ulong_t)&ufs_intel_cnl_hba_vops },
> > { PCI_VDEVICE(INTEL, 0x4B41), (kernel_ulong_t)&ufs_intel_ehl_hba_vops },
On 1/08/23 12:20, Jeuk Kim wrote:
> On 1/08/23, Adrian Hunter wrote:
>> On 1/08/23 10:37, Jeuk Kim wrote:
>>> Add PCI ID to support QEMU ufs.
>>>
>>> The new qemu ufs device can be found at
>>> https://lore.kernel.org/qemu-devel/20230727155239.GA979354@fedora
>>
>> Please say something about why a UFS device is being virtualized
>> and what features it is expected to support.
>
> Hi Adrian!
>
> UFS device emulation feature has been newly added to QEMU recently.
> Currently, QEMU UFS supports basic io and query request features,
> and plans to add more features in the future.
>
> With the addition of the QEMU ufs device emulation feature,
> QEMU UFS decided to use the pci device id of 0x0013 in the REDHAT vendor id (0x1b36).
>
> However, this information is not registered in the linux ufs driver,
> so the current linux kernel does not recognize the QEMU UFS device.
> Therefore, I want to register the QEMU ufs pci id through this patch.
>
> Do I need to add the above content to the commit message?
I was really hoping for an explanation of "Why?" i.e.
why does anyone want a virtual UFS device? Why not use
any existing virtual block device?
And yes, please add to the commit message
>
> Thanks,
> Jeuk
>
>>>
>>> Signed-off-by: Jeuk Kim <[email protected]>
>>> ---
>>> drivers/ufs/host/ufshcd-pci.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/ufs/host/ufshcd-pci.c b/drivers/ufs/host/ufshcd-pci.c
>>> index cf3987773051..29d322931427 100644
>>> --- a/drivers/ufs/host/ufshcd-pci.c
>>> +++ b/drivers/ufs/host/ufshcd-pci.c
>>> @@ -590,6 +590,7 @@ static const struct dev_pm_ops ufshcd_pci_pm_ops = {
>>> };
>>>
>>> static const struct pci_device_id ufshcd_pci_tbl[] = {
>>> + { PCI_VENDOR_ID_REDHAT, 0x0013, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
>>> { PCI_VENDOR_ID_SAMSUNG, 0xC00C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
>>> { PCI_VDEVICE(INTEL, 0x9DFA), (kernel_ulong_t)&ufs_intel_cnl_hba_vops },
>>> { PCI_VDEVICE(INTEL, 0x4B41), (kernel_ulong_t)&ufs_intel_ehl_hba_vops },
On 8/1/23 04:12, Adrian Hunter wrote:
> I was really hoping for an explanation of "Why?" i.e.
> why does anyone want a virtual UFS device? Why not use
> any existing virtual block device?
I hope this will enable testing of the UFS driver inside a virtual machine
on systems without UFS host controller. Jeuk, is that correct?
Thanks,
Bart.
On 8/1/23, Bart Van Assche wrote:
> On 8/1/23 04:12, Adrian Hunter wrote:
> > I was really hoping for an explanation of "Why?" i.e.
> > why does anyone want a virtual UFS device? Why not use
> > any existing virtual block device?
>
> I hope this will enable testing of the UFS driver inside a virtual machine
> on systems without UFS host controller. Jeuk, is that correct?
>
> Thanks,
>
> Bart.
Hi Bart!
That's right.
I would say there are 3 main reasons why we need UFS virtualization.
1) As Bart said, it enables to test UFS drivers on virtual machines on
systems without UFS host controller.
2) It works as an emulation, so it's easier to reproduce and debug bug
situations on the device than on a real device.
3) It is easy to preemptively implement and test new features before the
real device is created.
Thanks,
Jeuk