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@xxxxxxxxx> >>>>> Cc: Geert Uytterhoeven <geert+renesas@xxxxxxxxx> >>>>> Cc: Phil Edworthy <phil.edworthy@xxxxxxxxxxx> >>>>> Cc: Simon Horman <horms+renesas@xxxxxxxxxxxx> >>>>> Cc: Wolfram Sang <wsa@xxxxxxxxxxxxx> >>>>> Cc: linux-renesas-soc@xxxxxxxxxxxxxxx >>>>> --- >>>>> 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. 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/* ? thanks, -- ~Randy
