public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Yicong Yang <yangyicong@hisilicon.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: <linux-pci@vger.kernel.org>, <prime.zeng@huawei.com>,
	<linuxarm@openeuler.org>, Masahiro Yamada <masahiroy@kernel.org>,
	"Michal Marek" <michal.lkml@markovi.net>,
	<linux-kbuild@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] PCI: Use subdir-ccflags-* to inherit debug flag
Date: Fri, 5 Feb 2021 09:32:36 +0800	[thread overview]
Message-ID: <8b4e51a2-ce4c-50e1-4e06-7752bf892f05@hisilicon.com> (raw)
In-Reply-To: <20210204161048.GA68790@bjorn-Precision-5520>

On 2021/2/5 0:10, Bjorn Helgaas wrote:
> [+cc Masahiro, Michal, linux-kbuild, linux-kernel]
> 
> On Thu, Feb 04, 2021 at 07:30:15PM +0800, Yicong Yang wrote:
>> From: Junhao He <hejunhao2@hisilicon.com>
>>
>> Use subdir-ccflags-* instead of ccflags-* to inherit the debug
>> settings from Kconfig when traversing subdirectories.
> 
> So I guess the current behavior is:
> 
>   If CONFIG_PCI_DEBUG=y, add -DDEBUG to CFLAGS in the current
>   directory, but not in any subdirectories
> 
> and the behavior after this patch is:
> 
>   If CONFIG_PCI_DEBUG=y, add -DDEBUG to CFLAGS in the current
>   directory and any subdirectories
> 
> Is that right?  That makes sense to me.  I wonder if any other places
> have this issue?

that's right. we didn't check other places, but some have individual config
in their sub-directory as you mentioned below.

> 
> 'git grep "^ccflags.*-DDEBUG"' finds a few cases where subdirectories
> use their own debug config options, e.g.,
> 
>   drivers/i2c/Makefile:ccflags-$(CONFIG_I2C_DEBUG_CORE) := -DDEBUG
>   drivers/i2c/algos/Makefile:ccflags-$(CONFIG_I2C_DEBUG_ALGO) := -DDEBUG
>   drivers/i2c/busses/Makefile:ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
>   drivers/i2c/muxes/Makefile:ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
> 
> But some have subdirectories that look like they probably should be
> included by using subdir-ccflags, e.g.,
> 
>   drivers/base/Makefile:ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
>   drivers/base/power/Makefile:ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
>     # drivers/base/{firmware_loader,regmap,test}/ not included
> 
>   drivers/hwmon/Makefile:ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
>     # drivers/hwmon/{occ,pmbus}/ not included
> 
>   drivers/pps/Makefile:ccflags-$(CONFIG_PPS_DEBUG) := -DDEBUG
>   drivers/pps/clients/Makefile:ccflags-$(CONFIG_PPS_DEBUG) := -DDEBUG
>     # drivers/pps/generators/ not included
> 
> There are many more places that add -DDEBUG to ccflags-y that *don't*
> have subdirectories.
> 
> I wonder the default should be that we use subdir-ccflags all the
> time, and use ccflags only when we actually want different
> CONFIG_*_DEBUG options for subdirectories.

agree. if there is no debug config in the sub-directory, the
config should be inherited from its parent directory using subdir-ccflags.

we can post a separate serial to issue other places.

Thanks,
Yicong

> 
>> Signed-off-by: Junhao He <hejunhao2@hisilicon.com>
>> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
>> ---
>>  drivers/pci/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
>> index 11cc794..d62c4ac 100644
>> --- a/drivers/pci/Makefile
>> +++ b/drivers/pci/Makefile
>> @@ -36,4 +36,4 @@ obj-$(CONFIG_PCI_ENDPOINT)	+= endpoint/
>>  obj-y				+= controller/
>>  obj-y				+= switch/
>>  
>> -ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
>> +subdir-ccflags-$(CONFIG_PCI_DEBUG) := -DDEBUG
>> -- 
>> 2.8.1
>>
> 
> .
> 


  reply	other threads:[~2021-02-05  1:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1612438215-33105-1-git-send-email-yangyicong@hisilicon.com>
2021-02-04 16:10 ` [PATCH] PCI: Use subdir-ccflags-* to inherit debug flag Bjorn Helgaas
2021-02-05  1:32   ` Yicong Yang [this message]
2021-02-09 21:25 ` Bjorn Helgaas
2021-02-09 23:43   ` Krzysztof Wilczyński
2021-02-10  9:33   ` Yicong Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8b4e51a2-ce4c-50e1-4e06-7752bf892f05@hisilicon.com \
    --to=yangyicong@hisilicon.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@openeuler.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=prime.zeng@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox