Received: by 10.213.65.68 with SMTP id h4csp1549717imn; Thu, 15 Mar 2018 02:58:28 -0700 (PDT) X-Google-Smtp-Source: AG47ELvOgl3N9cKmrbLgmK6iwgE8J7GPFjSdai6wWO5KON42Fn99GO2Hk/tJWB7NbspD6DgMji7M X-Received: by 10.99.117.86 with SMTP id f22mr6152496pgn.180.1521107908676; Thu, 15 Mar 2018 02:58:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521107908; cv=none; d=google.com; s=arc-20160816; b=qqgxAJXNtIwrD/8ysF82A/9spspCrUMUlGRsTeBpfLtTqVewqXyACx2bx+CYF8p2NP 1rBJ0sHqdVutVDwueRjlawBXs/cej+SV5NsMG40MJrMX6PjR8Yl9/73FKU4W2Ix1nds+ 6Yc7jipeORKBrE2/J+wY87ijQW0lh3YpzH+yRloREtidYGAwDt26BkefWD0+GcYgmjuK 1rzKlASWt749Jz0vBfLNlARkgddhMhX8Gtp6Nu0YjHEkezPuEPL7bDnHCk4f3RHykwdQ AgPdazEbDWmMw+3IPFP8G4bEtbIGmNqosOeYMPmf1ymfl9/JsvyoCs6KeL+7Z/ZV7nf3 wDSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=bHb7RUbt+iIvx0+9pQ8lgrRpqxREmzUuEsg1ZrqEyEg=; b=ULNMjJxVWF+a9FGGAbdoC+A6htP2Twua2d6zJJEuj0q+/hbTatckhBgXnrr/6RubYs /oIUS1Q1t8mOtUhzoLUTSO8Y2bKx+lr6pvfBGCi6M8c0c7PrUBWgwoj9eMfUjFEtAciy hCNFIk+GnwoWctYzMDLf/8GhWzq1dOnGcq/TcxCl08/SjGMj9atdYw2e2GiN+LrG8JbS x9pSgpkroSC6kP4CSwdXuZ+DrPUtDFik1h0yHqGd+GdaZ+b9dbwzen+YiL+VCEuDxzBk EGfdede/T08pKrUaWelKR3foEgatpfzNdloX8S8z5YdWMQo+D4OTcVnEf/sPy/aLFylo 7rvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v14si3259783pgo.360.2018.03.15.02.58.14; Thu, 15 Mar 2018 02:58:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751944AbeCOJ5R (ORCPT + 99 others); Thu, 15 Mar 2018 05:57:17 -0400 Received: from mail1.skidata.com ([91.230.2.99]:33709 "EHLO mail1.skidata.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751362AbeCOJ5O (ORCPT ); Thu, 15 Mar 2018 05:57:14 -0400 X-Greylist: delayed 596 seconds by postgrey-1.27 at vger.kernel.org; Thu, 15 Mar 2018 05:57:13 EDT X-IronPort-AV: E=Sophos;i="5.48,310,1517871600"; d="scan'208";a="9232732" Subject: Re: [PATCH 2/3] usb: host: pci: introduce PCI vendor ID for Netlogic To: Oliver Neukum , Richard Leitner , , , CC: , , References: <20180314102933.21367-1-dev@g0hl1n.net> <20180314102933.21367-3-dev@g0hl1n.net> <1521029854.4511.12.camel@suse.com> <1521041253.4511.16.camel@suse.com> <377fb9d5-1cc9-7ab8-c965-2fb0a4dc20f3@skidata.com> <1521105992.18237.2.camel@suse.com> From: Richard Leitner Message-ID: Date: Thu, 15 Mar 2018 10:47:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1521105992.18237.2.camel@suse.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [192.168.111.252] X-ClientProxiedBy: sdex5srv.skidata.net (192.168.111.83) To sdex5srv.skidata.net (192.168.111.83) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/15/2018 10:26 AM, Oliver Neukum wrote: > Am Mittwoch, den 14.03.2018, 16:44 +0100 schrieb Richard Leitner: >> On 03/14/2018 04:27 PM, Oliver Neukum wrote: >>> Am Mittwoch, den 14.03.2018, 14:31 +0100 schrieb Richard Leitner: >>>> >>> Well, but it does not. Removing a redundant definition is a clear >>> benefit. But you are not removing a definition. You are introducing >>> a preprocessor constant. Why? >>> What is its benefit? >> >> AFAIK pci_ids.h collects PCI vendor and device IDs in one single >> point. As the PCI vendor ID of Netlogic is used in multiple files >> IMHO it would be a good idea to add it to pci_ids.h and furthermore >> remove it from arch/mips/include/asm/netlogic/xlp-hal/iomap.h (where >> it's currently defined). >> >> Or am I getting things wrong? > > I think so, yes. We are giving names to constants as a form > of comment or to change them at multiple places at once and > consistently. > > So > > #define XYZ_NETDEV_RESET_RETRIES 2 > > makes clearly sense. So does > > #define XYZ_MAGIC_VALUE1 0xab4e > > because it tells you that you have a magic value. > But you will never redefine a PCI vendor ID. In fact you > must not. And if you have a comparison like > > dev->vID == 0x1234 > > if you change this to > > dev->vID == SOME_VENDOR_ID > > what good does this to you? You already knew it was a vendor ID. > Now you can name it at a glance. So what? If you have a device > you will have to check whether you have some OEM version. You > will always go and check the raw number. And if you have a log > and need to check whether the check will be true, you will have > a number. > Using a constant there is nothing but trouble. Yet one more grep. Thank you for that explanation. But IMHO it was clearer with a human-readable name in such comparisons... For example in the following I see at the first glance which device from which vendor is affected and I don't need any additional comments or ID databases... if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == PCI_DEVICE_ID_TI_TUSB73X0) ...but if that's not the preferred way of doing things I'm perfectly fine with that. Furthermore to me it sounds you are saying that the complete pci_ids.h should be thrown over-board?!? regards;richard.l