Re: [PATCH V2] PCI: rcar: Clean up the macros

[Marek Vasut <marek.vasut@gmail.com>]

On 04/08/2018 08:03 PM, Randy Dunlap wrote:
> On 04/08/2018 09:53 AM, Marek Vasut wrote:
>> On 04/08/2018 06:51 PM, Randy Dunlap wrote:
>>> On 04/08/2018 09:34 AM, Marek Vasut wrote:
>>>> On 04/08/2018 05:27 PM, Randy Dunlap wrote:
>>>>> On 04/08/2018 06:09 AM, Marek Vasut wrote:
>>>>>> This patch replaces the (1 << n) with BIT(n) and cleans up whitespace,
>>>>>> no functional change.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>>> Cc: Phil Edworthy <phil.edworthy@renesas.com>
>>>>>> Cc: Simon Horman <horms+renesas@verge.net.au>
>>>>>> Cc: Wolfram Sang <wsa@the-dreams.de>
>>>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>>>> ---
>>>>>> V2: Reword the commit message
>>>>>> ---
>>>>>>  drivers/pci/host/pcie-rcar.c | 52 ++++++++++++++++++++++----------------------
>>>>>>  1 file changed, 26 insertions(+), 26 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
>>>>>> index 25f68305322c..5ab7bf6a8de0 100644
>>>>>> --- a/drivers/pci/host/pcie-rcar.c
>>>>>> +++ b/drivers/pci/host/pcie-rcar.c
>>>>>> @@ -30,9 +30,9 @@
>>>>>
>>>>> missing this:
>>>>>
>>>>> #include <linux/bitops.h>
>>>>
>>>> This compiles just fine without it though, which means it's probably
>>>> pulled in through some of the other includes already present.
>>>>
>>>
>>> I suspected that. However, please see rule #1 in
>>> Documentation/process/submit-checklist.rst:
>>>
>>> 1) If you use a facility then #include the file that defines/declares
>>>    that facility.  Don't depend on other header files pulling in ones
>>>    that you use.
>>
>> If I was to include every single header from which I use something,
>> wouldn't that make the list real long then ? Is that really worth it?
> 
> The length of the list of headers is not an issue.
> And if you are "cleaning up," you might as well do a full job of it.

I sent a V3 of this "clean up".

> Just because it builds on one $ARCH (with various pulled-in headers) does
> not mean that it will build on another $ARCH (with different pulled-in headers).
> 
> Or did you build it on all linux/arch/* ?

No, since it is limited in Kconfig:
        depends on ARCH_RENESAS || (ARM && COMPILE_TEST)

-- 
Best regards,
Marek Vasut