[Qemu-devel] [PATCH] vfio/pci: replace 1 with PCI_CAP_LIST_NEXT to make code self-explain
Use the macro PCI_CAP_LIST_NEXT instead of 1, so that the code would be more self-explain. This patch makes this change and also fixs one typo in comment. Signed-off-by: Wei Yang --- hw/vfio/pci.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index 1fb868c..17d1462 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -1472,7 +1472,7 @@ static uint8_t vfio_std_cap_max_size(PCIDevice *pdev, uint8_t pos) uint8_t tmp, next = 0xff; for (tmp = pdev->config[PCI_CAPABILITY_LIST]; tmp; - tmp = pdev->config[tmp + 1]) { + tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT]) { if (tmp > pos && tmp < next) { next = tmp; } @@ -1661,7 +1661,7 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t pos) int ret; cap_id = pdev->config[pos]; -next = pdev->config[pos + 1]; +next = pdev->config[pos + PCI_CAP_LIST_NEXT]; /* * If it becomes important to configure capabilities to their actual @@ -1675,7 +1675,7 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t pos) * pci_add_capability always inserts the new capability at the head * of the chain. Therefore to end up with a chain that matches the * physical device, we insert from the end by making this recursive. - * This is also why we pre-caclulate size above as cached config space + * This is also why we pre-calculate size above as cached config space * will be changed as we unwind the stack. */ if (next) { @@ -1691,7 +1691,7 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t pos) } /* Use emulated next pointer to allow dropping caps */ -pci_set_byte(vdev->emulated_config_bits + pos + 1, 0xff); +pci_set_byte(vdev->emulated_config_bits + pos + PCI_CAP_LIST_NEXT, 0xff); switch (cap_id) { case PCI_CAP_ID_MSI: -- 2.5.0
Re: [Qemu-devel] [PATCH] vfio/pci: replace 1 with PCI_CAP_LIST_NEXT to make code self-explain
On Wed, Mar 16, 2016 at 12:52:52PM +0100, Paolo Bonzini wrote: > > >On 16/03/2016 12:27, Michael Tokarev wrote: >>> > for (tmp = pdev->config[PCI_CAPABILITY_LIST]; tmp; >>> > - tmp = pdev->config[tmp + 1]) { >>> > + tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT]) { >>> > -next = pdev->config[pos + 1]; >>> > +next = pdev->config[pos + PCI_CAP_LIST_NEXT]; >> Hmm. I'm not sure the new version is better, to me "+1" reads >> easier than the new symbolic constant variant. >> >> If it were something like pdev->config[PCI_CAP_LIST_NEXT], that'd be >> nice, but not "pos + PCI_CAP_LIST_NEXT". >> >> But again, I'm not pci config space expert and don't understand >> the basics :) Thanks Michael for your comment. By using the macro, audience is more easy to understand it tries to get the position of next capability. > >Each capability is a node of a linked list, and the position of the next >capability is at offset 1 inside the capability (here it is at offset 1 >from the tmp or pos base). I think the patch is an improvement. > Thanks Paolo for your reply. :-) >Paolo -- Wei Yang Help you, Help me
Re: [Qemu-devel] [PATCH] vfio/pci: replace 1 with PCI_CAP_LIST_NEXT to make code self-explain
11.02.2016 03:54, Wei Yang wrote: > Use the macro PCI_CAP_LIST_NEXT instead of 1, so that the code would be > more self-explain. > > This patch makes this change and also fixs one typo in comment. > > for (tmp = pdev->config[PCI_CAPABILITY_LIST]; tmp; > - tmp = pdev->config[tmp + 1]) { > + tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT]) { > -next = pdev->config[pos + 1]; > +next = pdev->config[pos + PCI_CAP_LIST_NEXT]; Hmm. I'm not sure the new version is better, to me "+1" reads easier than the new symbolic constant variant. If it were something like pdev->config[PCI_CAP_LIST_NEXT], that'd be nice, but not "pos + PCI_CAP_LIST_NEXT". But again, I'm not pci config space expert and don't understand the basics :) Thanks, /mjt
Re: [Qemu-devel] [PATCH] vfio/pci: replace 1 with PCI_CAP_LIST_NEXT to make code self-explain
On 16/03/2016 12:27, Michael Tokarev wrote: >> > for (tmp = pdev->config[PCI_CAPABILITY_LIST]; tmp; >> > - tmp = pdev->config[tmp + 1]) { >> > + tmp = pdev->config[tmp + PCI_CAP_LIST_NEXT]) { >> > -next = pdev->config[pos + 1]; >> > +next = pdev->config[pos + PCI_CAP_LIST_NEXT]; > Hmm. I'm not sure the new version is better, to me "+1" reads > easier than the new symbolic constant variant. > > If it were something like pdev->config[PCI_CAP_LIST_NEXT], that'd be > nice, but not "pos + PCI_CAP_LIST_NEXT". > > But again, I'm not pci config space expert and don't understand > the basics :) Each capability is a node of a linked list, and the position of the next capability is at offset 1 inside the capability (here it is at offset 1 from the tmp or pos base). I think the patch is an improvement. Paolo