linux-kernel - Re: [PATCH] PCI: Add Loongson vendor ID and device IDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 1 Oct 2019 07:50:10 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc:     Andrew Murray <andrew.murray@....com>, zenglu@...ngson.cn,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: Add Loongson vendor ID and device IDs

On Tue, Oct 01, 2019 at 10:53:44AM +0800, Tiezhu Yang wrote:
> On 09/30/2019 10:02 PM, Andrew Murray wrote:
> > On Mon, Sep 30, 2019 at 12:55:20PM +0800, Tiezhu Yang wrote:
> > > Add the Loongson vendor ID and device IDs to pci_ids.h
> > > to be used in the future.
> > > 
> > > The Loongson IDs can be found at the following link:
> > > https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.ids
> > > 
> > > Co-developed-by: Lu Zeng <zenglu@...ngson.cn>
> > > Signed-off-by: Lu Zeng <zenglu@...ngson.cn>
> > > Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
> > > ---
> > >   include/linux/pci_ids.h | 19 +++++++++++++++++++
> > >   1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > > index 21a5724..119639d 100644
> > > --- a/include/linux/pci_ids.h
> > > +++ b/include/linux/pci_ids.h
> > > @@ -3111,4 +3111,23 @@
> > > 
> > >   #define PCI_VENDOR_ID_NCUBE            0x10ff
> > > 
> > > +#define PCI_VENDOR_ID_LOONGSON                 0x0014
> > > +#define PCI_DEVICE_ID_LOONGSON_HT              0x7a00
> > > +#define PCI_DEVICE_ID_LOONGSON_APB             0x7a02
> > > +#define PCI_DEVICE_ID_LOONGSON_GMAC            0x7a03
> > > +#define PCI_DEVICE_ID_LOONGSON_OTG             0x7a04
> > > +#define PCI_DEVICE_ID_LOONGSON_GPU_2K1000      0x7a05
> > > +#define PCI_DEVICE_ID_LOONGSON_DC              0x7a06
> > > +#define PCI_DEVICE_ID_LOONGSON_HDA             0x7a07
> > > +#define PCI_DEVICE_ID_LOONGSON_SATA            0x7a08
> > > +#define PCI_DEVICE_ID_LOONGSON_PCIE_X1         0x7a09
> > > +#define PCI_DEVICE_ID_LOONGSON_SPI             0x7a0b
> > > +#define PCI_DEVICE_ID_LOONGSON_LPC             0x7a0c
> > > +#define PCI_DEVICE_ID_LOONGSON_DMA             0x7a0f
> > > +#define PCI_DEVICE_ID_LOONGSON_EHCI            0x7a14
> > > +#define PCI_DEVICE_ID_LOONGSON_GPU_7A1000      0x7a15
> > > +#define PCI_DEVICE_ID_LOONGSON_PCIE_X4         0x7a19
> > > +#define PCI_DEVICE_ID_LOONGSON_OHCI            0x7a24
> > > +#define PCI_DEVICE_ID_LOONGSON_PCIE_X8         0x7a29
> > Hi Tiezhu,
> > 
> > Thanks for the patch - however it is preferred to provide new PCI
> > definitions along with the drivers that use them. They don't
> > provide any useful value without drivers that use them.
> 
> Thanks for your reply. This is the first step of the Loongson kernel
> team, we will submit other related individual driver patches step by
> step in the near future, these small patches make an easily
> understood change that can be verified by reviewers.

There are two opposing goals here:

  1) The "publish early, publish often" idea that posting small things
  early helps get useful feedback.

  2) The idea of waiting until things can be published in logical
  units so readers can see context and how things fit together.

I think Andrew's point (which I agree with) is that an individual
trivial patch like this is not enough to give meaningful feedback.  I
think you'll get better feedback if you wait and collect things until
you can post a series that actually fixes a bug or adds a small
feature.  It also makes it easier for me to track patches if I can
deal with a whole series at once instead of trying to figure out which
individual patches are related.

So I'd encourage you to think in terms of a series of 3-10 patches
that are all related and together produce something useful.  That's
easier for readers to digest than the same patches posted
incrementally over several days or weeks.

Bjorn