char: Convert pci_table entries to PCI_VDEVICE (if PCI_ANY_ID is used)

From: Peter Huewe <[email protected]>

This patch converts pci_table entries, where .subvendor=PCI_ANY_ID and .subdevice=PCI_ANY_ID, .class=0 and .class_mask=0, to use the PCI_VDEVICE macro, and thus improves readability.

Signed-off-by Peter Huewe <[email protected]>

---
 drivers/char/epca.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

drivers/char/epca.c +0 -0

index d9df46a..5dafcdb 100644
@@ -2762,10 +2762,10 @@ err_out:
 

I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

Quoted 2 lines · Greg KH

I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

grepping for pci device ids using constants and
expecting the result to be comprehensive isn't
sensible.

$ grep -rwP --include=*.[ch] -w PCI_VDEVICE drivers/char | wc -l
32

The current drivers/ use of PCI_VDEVICE to PCI_DEVICE is ~50/50

$ grep --include=*.[ch] -rwP PCI_DEVICE drivers | wc -l
866
$ grep --include=*.[ch] -rwP PCI_VDEVICE drivers | wc -l
768

Quoted 6 lines · Joe Perches

Quoted 2 lines · Greg KH

I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

grepping for pci device ids using constants and
expecting the result to be comprehensive isn't
sensible.

But it's a nice goal :)

Quoted 8 lines · Greg KH

Quoted 6 lines · Joe Perches

Quoted 2 lines · Greg KH

I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

grepping for pci device ids using constants and
expecting the result to be comprehensive isn't
sensible.

But it's a nice goal :)

I think your goal is not a good one.

For instance:

$ grep -rP --include=*.[ch] "\bPCI_VDEVICE\s*\(\s*INTEL" drivers | wc -l
201
$ grep -rP --include=*.[ch] "\bPCI_DEVICE\s*\(PCI_VENDOR_ID_INTEL" drivers | wc -l
45
$ grep -rP --include=*.[ch] "\bPCI_DEVICE\s*\(\s*0x8086" drivers | wc -l
38

I'd much rather do a search for "PCI_VDEVICE.*INTEL"

Quoted 13 lines · Joe Perches

Quoted 8 lines · Greg KH

Quoted 6 lines · Joe Perches

Quoted 2 lines · Greg KH

I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

grepping for pci device ids using constants and
expecting the result to be comprehensive isn't
sensible.

But it's a nice goal :)

I think your goal is not a good one.

For instance:

Quoted 7 lines

$ grep -rP --include=*.[ch] "\bPCI_VDEVICE\s*\(\s*INTEL" drivers | wc -l
201
$ grep -rP --include=*.[ch] "\bPCI_DEVICE\s*\(PCI_VENDOR_ID_INTEL" drivers | wc -l
45
$ grep -rP --include=*.[ch] "\bPCI_DEVICE\s*\(\s*0x8086" drivers | wc -l
38
I'd much rather do a search for "PCI_VDEVICE.*INTEL"

I'd much rather use 'cscope' or 'ctags' than trying to remember regular expressions like the above.

Quoted 21 lines · Greg KH

Quoted 20 lines · Joe Perches

Quoted 8 lines · Greg KH

Quoted 6 lines · Joe Perches

Quoted 2 lines · Greg KH

I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

grepping for pci device ids using constants and
expecting the result to be comprehensive isn't
sensible.

But it's a nice goal :)

I think your goal is not a good one.

For instance:

$ grep -rP --include=*.[ch] "\bPCI_VDEVICE\s*\(\s*INTEL" drivers | wc -l
201
$ grep -rP --include=*.[ch] "\bPCI_DEVICE\s*\(PCI_VENDOR_ID_INTEL" drivers | wc -l
45
$ grep -rP --include=*.[ch] "\bPCI_DEVICE\s*\(\s*0x8086" drivers | wc -l
38
I'd much rather do a search for "PCI_VDEVICE.*INTEL"

Quoted 2 lines

I'd much rather use 'cscope' or 'ctags' than trying to remember regular expressions like the above.

Then it appears your original argument doesn't have much merit.

The main reason I hate this macro, is that it now makes it almost impossible to grep for any users of the PCI_VENDOR_DIGI pci vendor id. I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

Am Donnerstag 15 Juli 2010 22:45:40 schrieb Greg KH:

Quoted 4 lines

The main reason I hate this macro, is that it now makes it almost impossible to grep for any users of the PCI_VENDOR_DIGI pci vendor id. I much prefer the PCI_DEVICE() macro instead, and as such, I'm not willing to take any of these patches, sorry.

No problem ;)
Patches are just proposals - nothing else.

The only question that remains is, do you see any point in converting the patches to use PCI_DEVICE?
Since you have to address/set the .driver_data explicitly I guess there's no point in doing it.

It's
{ PCI_VENDOR_DIGI, PCI_DEVICE_XRJ, PCI_ANY_ID, PCI_ANY_ID, 0, 0, brd_xrj }, vs.
{ PCI_DEVICE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_XR), .driver_data=brd_xrj },
and I guess it isn't really an improvement.

Maybe there should be a version of PCI_DEVICE that addresses this issue? But I have to admit, something like:
{ PCI_DEVICE_DD(PCI_VENDOR_ID_DIGI, PCI_DEVICE_XR), brd_xrj }, doesn't look that much better.

Quoted 4 lines

Maybe there should be a version of PCI_DEVICE that addresses this issue? But I have to admit, something like:
{ PCI_DEVICE_DD(PCI_VENDOR_ID_DIGI, PCI_DEVICE_XR), brd_xrj }, doesn't look that much better.

You can do:
{ PCI_DEVICE_TABLE(PCI_VENDOR_ID_DIGI, PCI_DEVICE_XR), brd_xrj },
just fine today, so do that if you want to.