From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98850C433EF for ; Fri, 25 Mar 2022 15:55:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349861AbiCYP5F (ORCPT ); Fri, 25 Mar 2022 11:57:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41186 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242758AbiCYP5D (ORCPT ); Fri, 25 Mar 2022 11:57:03 -0400 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EB2299EFB; Fri, 25 Mar 2022 08:55:28 -0700 (PDT) Received: by mail-ej1-f45.google.com with SMTP id r13so16220984ejd.5; Fri, 25 Mar 2022 08:55:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=nBp1rQ230IpvKYOLtxdPVmwxaC/K/6eYv/k0cIvzrGg=; b=ydhh9iorl5wHVKdsPWtYnTYfKWEWODecyKOsVEKQXAZtFKQq08d3HyBCxgqhb9I4Hs ewJ+5sHkOIh6nND8HIH5PY9TECauUcqniNVPYrOOxzWqFdeIFgScEBj2n67rTzZg4raI LnfGimKV9O/HTwxRGGRB3/tnyuN/g9XApfcV1O2/6y3iAWDH9WdyXG+che0KtuHX5QLr CgtZI3KY1hiazH3Gmo7pWWB3CKWOeLD7mjz7jxJk7ZMiBQ4ACk5Z//ih7ageUhoG47CO iR2+DkjZNwi0ro9cW3jEe0JR9lfwnkb9upCzGMZkNUg9pXj8s/tCD8seqtZVhKxymjeJ VPog== X-Gm-Message-State: AOAM533+YjqQVnu+0YNLvxDfa6MAvaTzgVaF6mUtcBIj4zju3vpyUL6b Ih36Hxl0BkLdxO7dm3Q0bSk= X-Google-Smtp-Source: ABdhPJwpK1Kmx/OKEINVZuqpBjuFjLxKskelwEoutmoGUI6L3rkaULEluc9/Vz6It99LqPXqv0mtIw== X-Received: by 2002:a17:907:3f8c:b0:6e0:6970:dc87 with SMTP id hr12-20020a1709073f8c00b006e06970dc87mr12134491ejc.236.1648223726593; Fri, 25 Mar 2022 08:55:26 -0700 (PDT) Received: from [192.168.0.162] (xdsl-188-155-201-27.adslplus.ch. [188.155.201.27]) by smtp.googlemail.com with ESMTPSA id gb29-20020a170907961d00b006e00c7b0f5asm2539273ejc.0.2022.03.25.08.55.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Mar 2022 08:55:26 -0700 (PDT) Message-ID: Date: Fri, 25 Mar 2022 16:55:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH 2/2] regulator: rt5759: Add support for Richtek RT5759 DCDC converter Content-Language: en-US To: ChiYuan Huang Cc: Mark Brown , Rob Herring , Liam Girdwood , cy_huang , gene_chen@richtek.com, lkml , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" References: <1648170401-6351-1-git-send-email-u0084500@gmail.com> <1648170401-6351-3-git-send-email-u0084500@gmail.com> <03999953-77c5-0272-7477-ab8a069b3671@kernel.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 25/03/2022 16:50, ChiYuan Huang wrote: > Krzysztof Kozlowski 於 2022年3月25日 週五 下午11:37寫道： >> >> On 25/03/2022 15:59, ChiYuan Huang wrote: >>> Krzysztof Kozlowski 於 2022年3月25日 週五 下午10:47寫道： >>>> >>>>>>> + >>>>>>> +static const struct of_device_id __maybe_unused rt5759_device_table[] = { >>>>>> >>>>>> I don't think this can be __maybe_unused. It is always referenced via >>>>>> of_match_table, isn't it? >>>>>> >>>>> I think it can declared as '__maybe_unused'. >>>>> If 'of_device_id' is unused, then in probe stage, >>>>> 'of_device_get_match_data' will return NULL. >>>> >>>> But your of_device_id cannot be unused. It is always referenced. >>>> >>> I'm not sure, but your assumption is based on 'CONFIG_OF', right? >>> Only if 'CONFIG_OF' is not defined, then it'll be really unused. >> >> Is it possible to build this driver without CONFIG_OF? Did you try it? >> > No, my development board always use device tree that's defined CONFIG_OF. > > But theoretically, you can also check of_device.h, if CONFIG_OF is not > defined, 'of_device_get_match_data' always return NULL. > If so, my usage is still right. No, it does not look right and your arguments are not even related to the topic. I don't think we talk about the same thing. You mention board, some of_device_get_match_data() so you talk about runtime. maybe_unused is not about runtime. It is about build time. The code you sent cannot have this structure unused. If you think otherwise, please provide argument, but not about runtime (again). You can for example build it without OF and see... Best regards, Krzysztof