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 for Android: free password hash cracker in your pocket

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

Message-ID: <af586d51-3080-3667-b277-65a8338fbf6f@loongson.cn>
Date:   Wed, 2 Oct 2019 08:53:36 +0800
From:   Tiezhu Yang <yangtiezhu@...ngson.cn>
To:     Bjorn Helgaas <helgaas@...nel.org>
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 10/01/2019 08:50 PM, Bjorn Helgaas wrote:
> 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.

Hi Bjorn,

Thanks for your valuable suggestion, it is very useful. In the next work,
I will submit a series of patches as soon as possible.

Thanks,

Tiezhu Yang

>
> Bjorn