Re: [PATCH v1 2/2] nvme-pci: Convert to PCI_VDEVICE() macro for Apple devices

From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Sagi Grimberg <sagi@grimberg.me>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Leif Liddy <leif.liddy@gmail.com>,
	linux-nvme@lists.infradead.org, Jens Axboe <axboe@fb.com>,
	Keith Busch <kbusch@kernel.org>
Subject: Re: [PATCH v1 2/2] nvme-pci: Convert to PCI_VDEVICE() macro for Apple devices
Date: Mon, 24 Feb 2020 11:34:59 +0200	[thread overview]
Message-ID: <20200224093459.GV10400@smile.fi.intel.com> (raw)
In-Reply-To: <20200219150625.GE17748@lst.de>

On Wed, Feb 19, 2020 at 04:06:25PM +0100, Christoph Hellwig wrote:
> On Wed, Feb 12, 2020 at 10:34:18PM +0200, Andy Shevchenko wrote:
> > > This actually makes the code longer
> > 
> > I didn't get this. How? The code is for sure shorter.
> 
> Looks at the diffstat.

Yes, but let's calculate a real code (not all lines).
In terms of characters it's shorter, in terms of LOCs it's the same.
On top few comment / blank lines were added.

> > > and adds the antipattern of macros
> > > that use string pasting on their argument,
> > 
> > Anti-pattern to what? Can you elaborate a bit more? Sounds like I missed some
> > very basic thing.
> 
> > > 	and this breaking grep-ability > badly, so NAK.
> > 
> > This like a mantra people are telling, but looks like simple they didn't try.
> > What grep issue do you see in this case (I would agree if we talk about device
> > ID, though)?
> 
> If I want to grep for PCI_VENDOR_ID_APPLE I find the ids in the old code.
> I won't find them in your new code.

But it's matter of writing good enough RE, right?
What about, as rough approximation, `git grep -n 'PCI_[^,]\+APPLE'`?

> > Are you going to remove PCI_VDEVICE() completely? Are you going to be
> > consistent with the rest in this driver?
> 
> If you care strongly about using the same macro please send a patch to
> remove it in nvme.  I certainly don't want the sane version switched
> over to it.

Perhaps in the future, but no guarantees I find a time for that soon.

> > > It isn't by luck.  If the Apple devices were using the proper NVMe
> > > class ID we'd never hit the apple specific entries, but the actually
> > > use a different class code (the nvme one in big endian IIRC).  That
> > > being said I'm all for having the class match last.
> > 
> > Nobody prevents Apple to fix this and re-use old ID. So, under luck we may
> > consider Apple's negligence to the standards.
> 
> I'm just saying the current atch is not by luck.  As said in the previous
> mail I'm fine with moving the class match to the end as it generally
> is a good idea.  I just disagree with the "works by luck" statement for
> the current entries.

Thanks, I will send a new patch just for that.

-- 
With Best Regards,
Andy Shevchenko

_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme