Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp390365pxb; Wed, 24 Feb 2021 05:10:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJx9TXdAYktRyAhRDgbfaIpgzSefx7FgLZiqaDTc3c/822qqOfplx1sWhQsqkZZI/fkeLZqc X-Received: by 2002:a17:906:81cf:: with SMTP id e15mr21871658ejx.131.1614172205374; Wed, 24 Feb 2021 05:10:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614172205; cv=none; d=google.com; s=arc-20160816; b=F5ZRjsefSgsw2WW1TsMOMymmF7RRR8N006HLcIWR1zssOe77kmpgHDJ41fs1WMBI9k p2dZxKllQcnpZ/4tLHTUerjfz0QCBgDFW//Ydx0BEXFAkoFIkvTrcrAShgFtISmAMKa2 x8Klf7/SEhWSP3BrfjS98EaqNwTZPaIonihf/l5QTvSw/hVvqry0okgcdanmeXeoEhoZ 4pv2LSCxk91ZmQGFalrSkWBEqnIJb0e3eMU4b+tFjLRhepSnppeUpjWcfgABKM5ZG7Sa hguq0rHomGWN+ja4rsddm6dZHW6VXwWYuqT8IS+dPr3ok8b/LFvRLLnkobDJaGo3V98n RLVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=sDUQBtoJ1QDEgAEx6TiLz7gVd16XYFqfW5f6ghjKKEU=; b=e9RrOoLH8D89uek3K7K+KuH2OHEu92Sm2ZQXvtp1ZljSUcmYe30sHNRtO81EoUQniT 9544KiEX2Kc3beWaRl9EQxvPynmw2jf+naBEG8ii3WmsOSE+jA0Ssr7Hwq9YA0RstybP s96G4qlvJfiCoT7zdCErm9CWYqV0vwc2hTq1j2VQ/PSDrs1FmOMzaeZoC/OlJnYyAkzr 3N9/jVX1uXNVaiZFzYAFrN8X2wSRJO6FkIB/vVqHVcYlMYmG0fyPVTOhywyA9sPmicsp 2pAsX8ghG3X1Aj9bM3S1qxBUQ61353XYwohlRHUASZpu2UTC3MsSJe7+Kbp55CjrNjEc x2uQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hc41si1250222ejc.381.2021.02.24.05.09.23; Wed, 24 Feb 2021 05:10:05 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234824AbhBXJ6G (ORCPT + 99 others); Wed, 24 Feb 2021 04:58:06 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:12996 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234767AbhBXJ5M (ORCPT ); Wed, 24 Feb 2021 04:57:12 -0500 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Dlrqx6LFrzjRHk; Wed, 24 Feb 2021 17:54:53 +0800 (CST) Received: from [127.0.0.1] (10.69.38.196) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.498.0; Wed, 24 Feb 2021 17:56:20 +0800 Subject: Re: [PATCH 1/4] driver core: Use subdir-ccflags-* to inherit debug flag To: Daniel Thompson CC: Greg KH , , , , , , , , , , , , , , , , References: <1612518255-23052-1-git-send-email-yangyicong@hisilicon.com> <1612518255-23052-2-git-send-email-yangyicong@hisilicon.com> <08017751-a1be-ea07-50de-73d14ab6d57e@hisilicon.com> <1f0b2f37-db56-c220-dfe1-8c376031404f@hisilicon.com> <20210210114203.jvhst2veqbx73r5g@maple.lan> From: Yicong Yang Message-ID: Date: Wed, 24 Feb 2021 17:56:20 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20210210114203.jvhst2veqbx73r5g@maple.lan> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.69.38.196] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/2/10 19:42, Daniel Thompson wrote: > On Mon, Feb 08, 2021 at 09:09:20PM +0800, Yicong Yang wrote: >> On 2021/2/8 18:47, Greg KH wrote: >>> On Mon, Feb 08, 2021 at 06:44:52PM +0800, Yicong Yang wrote: >>>> On 2021/2/5 17:53, Greg KH wrote: >>>>> What does this offer in benefit of the existing way? What is it fixing? >>>>> Why do this "churn"? >>>> >>>> currently we have added ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG in the Makefile >>>> of driver/base and driver/base/power, but not in the subdirectory >>>> driver/base/firmware_loader. we cannot turn the debug on for subdirectory >>>> firmware_loader if we config DEBUG_DRIVER and there is no kconfig option >>>> for the it. >>> >>> Is that necessary? Does that directory need it? >> >> there are several debug prints in firmware_loader/main.c: >> >> ./main.c:207: pr_debug("%s: fw-%s fw_priv=%p\n", __func__, fw_name, fw_priv); >> ./main.c:245: pr_debug("batched request - sharing the same struct fw_priv and lookup for multiple requests\n"); >> > > Even if these are not in scope for CONFIG_DEBUG_DRVIER there is a > config option that would allow you to observe them without changing > any code (CONFIG_DYNAMIC_DEBUG). > yes. they're two mechanisms of debug. i think it's the right thing to make both work properly. > > Daniel. > > . >