Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp843577pxb; Thu, 30 Sep 2021 19:38:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwOOXUJ1ZvlkvhwD1C6RDbd7AaGqEN97BPvj13/rKs3oBbxRSAAszAw2H1FxRSOq5ERFrl X-Received: by 2002:a17:906:abcc:: with SMTP id kq12mr3275940ejb.107.1633055929500; Thu, 30 Sep 2021 19:38:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633055929; cv=none; d=google.com; s=arc-20160816; b=ald5PZr7XYJzHUO+mEGvrcs1S1PZTKrXrb1RK434X91EmBXD4lhW54jB6/qlukB2y0 IePCWytcPNHhvVYX93BL1KYgwW3vFwLq/k1sFH6Z2X95JWO1sGq/XY2m6B6K7QEnqGHg cklB3oo5RG5anG6mWl2j9+DU/uRejsNC4MaGCbzL53RYK+qd6sZBPxA/T3PXvycyzwd0 uHiCSQJ4Uj03nRhRx6k1D1HteyOQ6N8fE+m1XtxiiEuOUSVwPqGF2dL4GbG63gIuhTC9 kSiM9C28ZOZpfFSm8x3D+1OjkWRjH8AohfcsZb17KxC/tnqPxqyD3tlGWjw9+xV6foIq Q/qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=jp1gszKRynAEW3NTt0Yi1MVdwVlsDuFC+9KQNXhPqUg=; b=TnjoWSUDVni+JBPwlnFvo34betv5vSXJjLtWS7AN2dqyTu8sYdsyMdj+ffRJ5e1Lw8 +64JhmaFITUyCSPXmjpu/jivXpsZJ+rBLkVurhY9C21slRZSXDlSt3Un+le0IxGXk1Eu HIVK1gDbT8E/UrrpeU8uJyXAijdEkqhzyC/HFXOwufdrPSWfHBwsBOV+41xD2CAAXFJp c2ldvWVqG96tfcsJCIozsh+MsawfiVS2hcuMAQbWvjpYTNAYx123fBMN5Rg6yGROS/2/ pg0SJ4kYlAaxRzFi6M2esW+7KKNR4o4QsPKjp9QD8XlS84tJAnTPiID6NBfFxEhA3hsK PrIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b="0NWwGmW/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x12si5358898edr.305.2021.09.30.19.38.24; Thu, 30 Sep 2021 19:38:49 -0700 (PDT) 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; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b="0NWwGmW/"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351600AbhJACf6 (ORCPT + 99 others); Thu, 30 Sep 2021 22:35:58 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:24485 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230260AbhJACf5 (ORCPT ); Thu, 30 Sep 2021 22:35:57 -0400 Received: from mail-pj1-f52.google.com (mail-pj1-f52.google.com [209.85.216.52]) (authenticated) by conssluserg-04.nifty.com with ESMTP id 1912XmqA003060 for ; Fri, 1 Oct 2021 11:33:48 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com 1912XmqA003060 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1633055628; bh=jp1gszKRynAEW3NTt0Yi1MVdwVlsDuFC+9KQNXhPqUg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0NWwGmW/80rLewKIAKrRISoOF3ipenbsSiPuryilQs7WbS6UX4N7LiH7FsucfWKBn 9/K92fQnBsEHBq0E78l0Ivk1/M1tHgdErTGgxzO0x7bQ+5Q5PSGXUoKv7GiqtQqm++ 0tpiMiRf8/TFwmOtfuIlXlOSxMeIQDj+xQCfHGB/87QSojkfFuStInTf25x+pkYaYE UE/hMSBWfwxmZaWwpzfzZSA1MZLsJy/IvNvI6vHpEpgzwDoHrtkM2jC+S7mZRigSTT XwyObv9dSXUfM7Cfe0Dx66A2bao/+81u5C+4uevCHGNOZwvcxuOvgBqm+f3S0ZjTvA /HZ5wQ4Tvg41g== X-Nifty-SrcIP: [209.85.216.52] Received: by mail-pj1-f52.google.com with SMTP id na16-20020a17090b4c1000b0019f5bb661f9so2405034pjb.0 for ; Thu, 30 Sep 2021 19:33:48 -0700 (PDT) X-Gm-Message-State: AOAM531FNaLlnTDfY2yHFH4Y53kGXUFyO2TcJi7g613rSZy0hyRXzcT9 1mmOvGpB/Oq03wdeDauiySNclwtfq2ou02t/eUE= X-Received: by 2002:a17:90b:1d0f:: with SMTP id on15mr8403278pjb.77.1633055627838; Thu, 30 Sep 2021 19:33:47 -0700 (PDT) MIME-Version: 1.0 References: <20210929183357.1490204-1-lucas.demarchi@intel.com> <20210929183357.1490204-4-lucas.demarchi@intel.com> <20210930155547.rtz6pdae42gqvm6p@ldmartin-desk2> In-Reply-To: <20210930155547.rtz6pdae42gqvm6p@ldmartin-desk2> From: Masahiro Yamada Date: Fri, 1 Oct 2021 11:33:11 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] Move IS_CONFIG_NONZERO() to kconfig.h To: Lucas De Marchi Cc: intel-gfx , Daniel Vetter , dri-devel , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 1, 2021 at 12:55 AM Lucas De Marchi wrote: > > On Thu, Sep 30, 2021 at 11:01:36PM +0900, Masahiro Yamada wrote: > >On Thu, Sep 30, 2021 at 3:34 AM Lucas De Marchi > > wrote: > >> > >> The check for config value doesn't really belong to i915_utils.h - we > >> are trying to eliminate that utils helper and share them when possible > >> with other drivers and subsystems. > >> > >> Rationale for having such macro is in commit > >> babaab2f4738 ("drm/i915: Encapsulate kconfig constant values inside boolean predicates") > >> whereas later it is improved to not break the build if used with > >> undefined configs. The caveat is detailed in the documentation: unlike > >> IS_ENABLED(): it's not preprocessor-only logic so can't be used for > >> things like `#if IS_CONFIG_NONZERO(...)` > >> > >> Signed-off-by: Lucas De Marchi > > > > > >Hypothetical "it would be nice to have ..." is really unneeded. > > > > if (context && CONFIG_DRM_I915_FENCE_TIMEOUT > 0) > > return > >msecs_to_jiffies_timeout(CONFIG_DRM_I915_FENCE_TIMEOUT); > > > > > >is enough, and much cleaner. > > > > > > > >This warning is shown only when a constant is used > >together with '&&'. > > > >Most of IS_ACTIVE can go away. > > > >Given that, there are not many places where the IS_ACTIVE macro > >is useful, even in the i915 driver. > > > >For a few sources of the warnings, > >replacing it with != 0 or > 0 is just fine. > > humn... maybe. Let me do a conversion in that direction and see what is > the outcome. > > My original intention was to make IS_ENABLED() even uglier to cover the > int case, but after some tries it seems impossible to do on preprocessor > context, so I thought maybe it would be ok as a separate one. > > > > >Of course, such an ugly macro is not worth being moved to > > if we don't handle the undefined case and only worry about encapsulating > it inside a boolean predicate, the macro would be very simple. Would > that be worth having in kconfig.h maybe? I do not think so. #define IS_CONFIG_NONZERO(config) ((config) != 0) seems like a stupid macro. What is bad about writing the direct code? if (x && CONFIG_FOO > 0) .... > > > thanks > Lucas De Marchi -- Best Regards Masahiro Yamada