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 2781EC4332F for ; Tue, 1 Feb 2022 14:49:51 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id B3F068388F; Tue, 1 Feb 2022 15:49:49 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Ot0wz/sO"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8D72D83867; Tue, 1 Feb 2022 15:49:48 +0100 (CET) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 D204D80FDD for ; Tue, 1 Feb 2022 15:49:43 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=seanga2@gmail.com Received: by mail-qk1-x730.google.com with SMTP id b22so15222236qkk.12 for ; Tue, 01 Feb 2022 06:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GBF23lharvBEnRqhPW9z+1BVoGz25Mkv7ZqmUmAi8d4=; b=Ot0wz/sOxlhe6ilzb1M8/H4jHcbt3BW0g03/ld+UuD0hDq3Y8fjyL0qJ+5WoVniBl3 h8IT9cbJpeJRqmt23GWcLj2j8V1v7DbSrbflj0oEh/hXLStpZqSC39dU7wy6XPhAfbmy WZTfaJcdahbGaFbgeSOUyqNf5/oPrcYHN5US7B7bfUGzzNf7XAJ8JAAMnl/QadmUkyeY cs/LCtADJMjxqSdMw12XkLyTnByxbVqkfipkHEBxxF2Km/bqm3/hicW3ivGHEfH62eJR zVQLWwV82Nmo1QqqGLN0nezQ172mYpxYJyqJ8XZO6DP/qLrTCSk3N+moWsccA6uM2wof b7KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GBF23lharvBEnRqhPW9z+1BVoGz25Mkv7ZqmUmAi8d4=; b=F8k8kmrpATp3tzJmNNsi/kROBPKbx8t5GjpOUNr1cbLVcW2eFhafvN+INDyVrIMnb8 OWm73XuttXJEcYDWfTKVmrr6gaSxcExitbmaBnGUjdzcUL51u/c9k9+cDHMzffO+OXsp tZmdtcv2Itec98YSx5sEQeMU9INm4xpMuQEBqBTXY1WJQ1M/R1uzx0H7qhRYwidEVpn1 0HGcXeSSJ3FkJ1ifBuo9XnttCoz2mC9Pi8jc8QKG9SybF9t73QwAc0QUvj+UhVKF3yon u/Tq+cEAXw9M4d+pA28Il7aMayH1U7dEbiJLqOZu9tzWoJR3CZd59JZfjlL/HARu45fi YrtA== X-Gm-Message-State: AOAM532CL+L9XHxH8gHTPxsRD/8wIUHStuK0WSg7i/zIGBfWQHuAApmV ikjV0IxTtfC4P7+HsLiyc+A= X-Google-Smtp-Source: ABdhPJzGrbQfUg9erVKgC5CHXi4mTMP4/Xa78fH+LK+CwDXqZEDLOULgr6EWBIfCJq+a2stsUDbI7w== X-Received: by 2002:a05:620a:4048:: with SMTP id i8mr11351045qko.482.1643726982712; Tue, 01 Feb 2022 06:49:42 -0800 (PST) Received: from [192.168.1.201] (pool-108-18-137-133.washdc.fios.verizon.net. [108.18.137.133]) by smtp.googlemail.com with ESMTPSA id h1sm8017035qkn.71.2022.02.01.06.49.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Feb 2022 06:49:42 -0800 (PST) Subject: Re: [PATCH 1/7] clk: Make rfree return void To: Simon Glass Cc: U-Boot Mailing List , Lukasz Majewski References: <20220115222504.617013-1-seanga2@gmail.com> <20220115222504.617013-2-seanga2@gmail.com> <9cc38f2d-2c1f-e656-56ca-b7888ff0df63@gmail.com> From: Sean Anderson Message-ID: <4bdef436-8cca-6879-f017-20b721f9a8dc@gmail.com> Date: Tue, 1 Feb 2022 09:49:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 On 1/27/22 4:35 PM, Simon Glass wrote: > 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? Their equivalent (clk_put) returns void, and generally so do most other cleanup functions, since .device_remove also returns void. --Sean