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 30BA9C7EE25 for ; Mon, 12 Jun 2023 12:57:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232591AbjFLM5u (ORCPT ); Mon, 12 Jun 2023 08:57:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230467AbjFLM5l (ORCPT ); Mon, 12 Jun 2023 08:57:41 -0400 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9D8AE4C for ; Mon, 12 Jun 2023 05:57:39 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id ca18e2360f4ac-777b1b5ff50so209049939f.3 for ; Mon, 12 Jun 2023 05:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1686574659; x=1689166659; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mcs/mzLIm1WsqdeHjzGZbuX7KtKU1yS6rQCOIH1J8I0=; b=xqC6MKpngECoQvoYMSW33//Z/IKlUMIllTI83I+x158liBOcOl7RCaT7RULcYvp7Ph m+2/w5j/2GbjBdORnBj2KHO+dN9IJXC3j1upgDuHEpXaGEYJCI4ibKda0jN0ubmaa0Fq rxiLTZ6SUZsGYZ4H91fpDNokyCdWkS0gBl436W3T9kxDSOAea7eovYflrFEakmL/qkg2 alAwlke7UkgcmKzfQZOgkbETVsxnSKwq3bnCrNm8NbwUJzJgWvUl//zSJnKzcnA9Jx8j rUoEgmIEphfcjVDijdVjk8/Tnky7TXrFqLA1ZG3kDtaBrB9RaBxvPYZdEmFIiJ2UwmKx 6/cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686574659; x=1689166659; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mcs/mzLIm1WsqdeHjzGZbuX7KtKU1yS6rQCOIH1J8I0=; b=IxmUJjW6hD5pBDyHH6Dzh7TwnuVMMT9u7Sy7sAeLH+Vjy+U0X8RxX9RcbcZQNrqIB3 KX1j2jCE5xItD3M2sRJ21yrOAwcxSD5LuENOaXHxqFZqXHgyCwFZPcqpgy7AKfxnnWke 5oAi2BCD9uIzigGhfq5FBW1QJXVXSW2NHdmdJS+wpZrIiKXd7EGzp3mQRM192mths1OH g8GlKlbm5XCyoT6/HKiDXNS0iNnjqWf6c1nwWoAquCt008jA4rFz9E9QXALOu4d23CpQ hmFZQy25ZPVb2PI7e1Ltm8/7WKijYewNaeH271XomUbCWPGK7o1McXY9fUHnGuPIMG5s WCNA== X-Gm-Message-State: AC+VfDxtIAck0ZvdrxibevBa6FR8WemX7C4Yavwv2qFjPdma3D19nlK1 xZh61kaytB1jolg2gIfGTttm/A== X-Google-Smtp-Source: ACHHUZ4154bImSu2u2zX5xxEjDVt2RyADN5K86hrxC1hYjrP9agk1PMGoXyFm23au2IshSS0kJicBw== X-Received: by 2002:a05:6602:1851:b0:76c:6c78:5144 with SMTP id d17-20020a056602185100b0076c6c785144mr8089910ioi.17.1686574659284; Mon, 12 Jun 2023 05:57:39 -0700 (PDT) Received: from [172.22.22.28] ([98.61.227.136]) by smtp.gmail.com with ESMTPSA id w1-20020a02cf81000000b0041675393f68sm2690066jar.6.2023.06.12.05.57.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jun 2023 05:57:38 -0700 (PDT) Message-ID: <31b88290-5e2b-5c13-338c-3a08ad1e02fb@linaro.org> Date: Mon, 12 Jun 2023 07:57:37 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v13 17/24] gunyah: vm_mgr: Add framework for VM Functions Content-Language: en-US To: Elliot Berman , Srinivas Kandagatla , Prakruthi Deepak Heragu , Jonathan Corbet Cc: Murali Nalajala , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Dmitry Baryshkov , Bjorn Andersson , Konrad Dybcio , Arnd Bergmann , Greg Kroah-Hartman , Rob Herring , Krzysztof Kozlowski , Bagas Sanjaya , Will Deacon , Andy Gross , Catalin Marinas , Jassi Brar , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <20230509204801.2824351-1-quic_eberman@quicinc.com> <20230509204801.2824351-18-quic_eberman@quicinc.com> <3dd82ec0-2a9a-3401-5385-965c624f9f32@linaro.org> From: Alex Elder In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On 6/9/23 2:49 PM, Elliot Berman wrote: >>> +static struct gh_vm_function *gh_vm_get_function(u32 type) >>> +{ >>> +    struct gh_vm_function *fn; >>> +    int r; >>> + >>> +    fn = xa_load(&gh_vm_functions, type); >>> +    if (!fn) { >>> +        r = request_module("ghfunc:%d", type); >>> +        if (r) >>> +            return ERR_PTR(r > 0 ? -r : r); >> >> Almost all callers of request_module() simply ignore the >> return value.  What positive values are you expecting to >> see here (and are you sure they're positive errno values)? >> > > I can ignore the return value here, too, to follow the convention. > > I had observed request_module can return modprobe's exit code. I actually like checking the return value, but if a positive one comes back it's not clear at all that it should be interpreted as an errno. Given that almost everybody ignores the return value, maybe the called function should change, but blk_request_module() and cpufreq_parse_governor() (for two examples) actually use the return value to affect behavior. If you check its return, and it's positive, I would return a known negative errno rather than just negating it--and perhaps issue a warning. But it's OK with me if you just ignore it like most other callers. -Alex