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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 78C03C433EF for ; Thu, 27 Jan 2022 21:35:31 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D77AD830D0; Thu, 27 Jan 2022 22:35:28 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="UYQ1iwe6"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A2431830AB; Thu, 27 Jan 2022 22:35:27 +0100 (CET) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5C624830D0 for ; Thu, 27 Jan 2022 22:35:24 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-vk1-xa2a.google.com with SMTP id v192so2700096vkv.4 for ; Thu, 27 Jan 2022 13:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MNbecKCUmJyVOfK8N6h3xSha1H5JR0MtFvt2HdIcGS4=; b=UYQ1iwe6+dhymMS+jw7+tsZmw47yLgVow8gbHAy3A82dHTmUGcbOAf38sgRHdrKMg4 Xc19Ct5xiTZUQ01Uniaobq9dYWlp/nyClGCyDcZ7PnyP1/YZr0fZlSTAYHeqb/Cw2uAG 5kvVmx/hiSHrLoeBwFJ58OL3icpNQQ7YndyuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MNbecKCUmJyVOfK8N6h3xSha1H5JR0MtFvt2HdIcGS4=; b=XQmBdE1X4D/1br6RYPW2hKE+POfrTtvFM9z3O0IDxgZIV/hm/eX9m5CWux6Ipbs0V4 cFAVhaXs7xkO8/3MMEKCbSFNeWYMd0XjXoCFK5DlWdxltPPFRLkrc6MOVUXHj6TjCEOU PNn7qr3Jf26asIxKz4ZNExlEX8YYB1UDLQa680Ytg3toXBvHBKNGD+zK2EM333ow+/KJ ivrv0Qaq8WpkppUxyJk6R+vElXPFIp/IImHTw/NnF+AYlQ0OfKWDS4XTRyZZyXwp2vVY +uO2gxKJwi/03PnbHd6T3wowipLPbrE6iXWevfAwXsowrzmo++Amb3igrPEc6J1enFBK bQzw== X-Gm-Message-State: AOAM530lUDCcrQK6gJAYiIBMpG106MZc5WBmGfziGX0jb0DpCypvuCsy aW9sqx4KetU/UNrlGj/By0gnrDw2B4nFRmseorvWAw== X-Google-Smtp-Source: ABdhPJyGYsCT8d8yHiLr2h2tHJLQzVuU89HShGdffluFjb+BSHgmbsv+wYV03AwP0U718/U/lVMomMrxrKh9nIEiwL4= X-Received: by 2002:a05:6122:990:: with SMTP id g16mr2896902vkd.3.1643319322625; Thu, 27 Jan 2022 13:35:22 -0800 (PST) MIME-Version: 1.0 References: <20220115222504.617013-1-seanga2@gmail.com> <20220115222504.617013-2-seanga2@gmail.com> <9cc38f2d-2c1f-e656-56ca-b7888ff0df63@gmail.com> In-Reply-To: <9cc38f2d-2c1f-e656-56ca-b7888ff0df63@gmail.com> From: Simon Glass Date: Thu, 27 Jan 2022 14:35:11 -0700 Message-ID: Subject: Re: [PATCH 1/7] clk: Make rfree return void To: Sean Anderson Cc: U-Boot Mailing List , Lukasz Majewski Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Hi Sean, On Thu, 27 Jan 2022 at 08:43, Sean Anderson wrote: > > On 1/27/22 10:05 AM, Simon Glass wrote: > > Hi Sean, > > > > On Sat, 15 Jan 2022 at 15:25, Sean Anderson wrote: > >> > >> When freeing a clock there is not much we can do if there is an error, and > >> most callers do not actually check the return value. Even e.g. checking to > >> make sure that clk->id is valid should have been done in request() in the > >> first place (unless someone is messing with the driver behind our back). > >> Just return void and don't bother returning an error. > >> > >> Signed-off-by: Sean Anderson > >> --- > >> > >> drivers/clk/clk-uclass.c | 7 +++---- > >> drivers/clk/clk_sandbox.c | 6 +++--- > >> include/clk-uclass.h | 8 +++----- > >> 3 files changed, 9 insertions(+), 12 deletions(-) > >> > > > > We have the same thing in other places too, but I am a little worried > > about removing error checking. We try to avoid checking arguments too > > much in U-Boot, due to code-size concerns, so I suppose I agree that > > an invalid clk should be caught by a debug assertion rather than a > > full check. But with driver model we have generally added an error > > return to every uclass method, for consistency and to permit returning > > error information if needed. > > > > Regards, > > Simon > > > > So there are a few reasons why I don't think a return value is useful > here. To illustrate this, consider a typical user of the clock API: > > struct clk a, b; > > ret = clk_get_by_name(dev, "a", &a); > if (ret) > return ret; > > ret = clk_get_by_name(dev, "b", &b); > if (ret) > goto free_a; > > ret = clk_set_rate(&a, 5000000); > if (ret) > goto free_b; > > ret = clk_enable(&b); > > free_b: > clk_free(&b); > free_a: > clk_free(&a); > return ret; > > - Because a and b are "thick pointers" they do not need any cleanup to > free their own resources. The only cleanup might be if the clock > driver has allocated something in clk_request (more on this below) > - By the time we call clk_free, the mutable portions of the function > have already completed. In effect, the function has succeeded, > regardless of whether clk_free fails. Additionally, we cannot take any > action if it fails, since we still have to free both clocks. > - clk_free occurs during the error path of the function. Even if it > errored, we do not want to override the existing error from one of the > functions doing "real" work. > > The last thing is that no clock driver actually does anything in rfree. > The only driver with this function is the sandbox driver. I would like > to remove the function altogether. As I understand it, the existing API > is inspired by the reset drivers, so I would like to review its usage in > the reset subsystem before removing it for the clock subsystem. I also > want to make some changes to how rates and enables/disables are > calculated which might provide a case for rfree. But once that is > complete I think there will be no users still. What does this all look like in Linux? Regards, Simon