Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3659743pxb; Wed, 13 Oct 2021 10:16:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjY8O+Wqd3pdh4eUvCMl9Rd7eUNw/5qHqKHyiMYoz1E8JBqwI+aldPONGwqwfmAOEkrXAE X-Received: by 2002:a17:906:d0c3:: with SMTP id bq3mr525372ejb.277.1634145408316; Wed, 13 Oct 2021 10:16:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634145408; cv=none; d=google.com; s=arc-20160816; b=PGGickBjTspNkTirXZEWVxeoiUTb/1NvyjxWtCteo/cS5D3n62NeRms6H9dszDNAjd JnDVAwbfawiJOE8hdibfcFCr1HFgEAVT+0dpOKq22SyFzyRqBwrkCO0jH32yFSSKYuX8 dm6ouAou5ai4n7q5fBn02NCAdYVPAtAL67LwSw0eACToFt1xJqQrfStTbvAwl2q0u98o aQ0jjAm+qOvvA04YHW+AlQ+kE6stSsYOEgrCSqOFfO2yuMcUSyknfn/PZwkgdbL795TS vBhzSRJBxGmyXkA0rmISH98lAFgYc0SHJbxarH+nGNrmrf66CHCSc7WJqP+1Ge9oQ64l NLPQ== 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; bh=FqK/jWK79PuifDKA1/UfvqVKqumXLq/7p6XMlR8ggyA=; b=APMhJtXyraaykEkDPUQehlFeR1BXX/6PgPO1obWbzemyDsphe2ZaVXbebTulzslxT2 0Wkaaz8ua/KvpmANXeZihMQC5s39SgEl8UmJ933hVzDUmgQufDZ8FSb4sj569TqpNei2 GQKbxmfmKKxFB3iGJbiT+nTrVc17NWRda9IWzCMDZVYpkgmmkpt1S9Zh/sJCGui+Iw/X XU6oezOK6G1EIgWE7xZ0UXd9W90MqTxJ7PpFO6Z8Hp9TgTuEnmyswXIuw9L+oIhFo2Uc b/hfFRrB4OfSaWKzQnfDhOaMy8yYy2Mzn8Y7oP6nGc3Hlo8fPdpi60TJX/7NoRFtwkBI xmSQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MAEKzS3+; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z16si95388edm.21.2021.10.13.10.16.00; Wed, 13 Oct 2021 10:16:48 -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=@linaro.org header.s=google header.b=MAEKzS3+; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233767AbhJMRP3 (ORCPT + 99 others); Wed, 13 Oct 2021 13:15:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230216AbhJMRP2 (ORCPT ); Wed, 13 Oct 2021 13:15:28 -0400 Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1E4EC061570 for ; Wed, 13 Oct 2021 10:13:24 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id u5so5869266uao.13 for ; Wed, 13 Oct 2021 10:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FqK/jWK79PuifDKA1/UfvqVKqumXLq/7p6XMlR8ggyA=; b=MAEKzS3+RMUT1I7/97OKNNhT+hVWFG4OM53Pe/WUzd4eT3GOMZcPsQQmJCR8aFQSRy /f8Z9lVDXi9aEnkr/x3Tm+QYLfyW1fKkcXRHbOrrH6G9NXQgkrm3ZlL3gi5jBIXGnT/5 4xFYj9egElMU7OI4G1UeAFz/Hpd3WKNUz3LHQ4QmqkYrfqbB5vUs1ao5sYkEUdVVx790 xrNFHyqMCq2ICTlkh+X7wYGzIXl5d0AHPHq+02HIfKczyllEdjFF2Y1hdLi/aX8Dph+a CvKKxuW753lK6huHPr9YTFJpD4DE47bn+3PDoUVfyhzVxiv8Ggc+3wlN/gJxeHs8GrKt jw5g== 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=FqK/jWK79PuifDKA1/UfvqVKqumXLq/7p6XMlR8ggyA=; b=4JiXNwMTUDLcE0PKor4hokngmT98AohI4tAaj+Rzd/X2V1NVVSwBxjM1FriuLDgksJ 81/xs8OBnNGCqRl8NqWMki4AG7/j6OAMiNDqAqKbRT+Oa8XN4D/lzxyGhuDYgu4CNgB6 2wEMQk+2cQazMPE7J1KqC7xQELzATg/UyT8XQMrVGjskxfy2/wUCBY5XtPLoDZVvqP2C FkbWzDenxWu96NWPY+swJeJL+HbbHIIIHC1RLgLP5N0vFC8em5gwRisDB0RRBLvafwyH BVoTe/ZMR/uSN15arxploXc2EptcwDdbkT7A6HHEN7PUs/R+oQ3M+w5qqrkt+NmW7D/V ydDw== X-Gm-Message-State: AOAM5334wa5l4T15UNy654rP6r5mQr0zuM2CD/LpSKXmQkSybOlITbak NIGIJD5CEfka9YQWR6TdW1bmh+r3KawHMPAJKkw10Q== X-Received: by 2002:a67:d289:: with SMTP id z9mr308540vsi.39.1634145203777; Wed, 13 Oct 2021 10:13:23 -0700 (PDT) MIME-Version: 1.0 References: <20211007182158.7490-1-semen.protsenko@linaro.org> In-Reply-To: From: Sam Protsenko Date: Wed, 13 Oct 2021 20:13:11 +0300 Message-ID: Subject: Re: [PATCH v5] clk: Add write operation for clk_parent debugfs node To: Geert Uytterhoeven Cc: Andy Shevchenko , Michael Turquette , Stephen Boyd , Russell King , Chanwoo Choi , Sylwester Nawrocki , Krzysztof Kozlowski , Mike Tipton , Andy Shevchenko , Fabio Estevam , linux-clk , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 13 Oct 2021 at 19:30, Sam Protsenko wrote: > > On Wed, 13 Oct 2021 at 16:08, Geert Uytterhoeven wrote: > > > > Hi Sam, > > > > On Wed, Oct 13, 2021 at 1:36 PM Sam Protsenko > > wrote: > > > On Tue, 12 Oct 2021 at 21:55, Andy Shevchenko > > > wrote: > > > > On Thu, Oct 07, 2021 at 09:21:58PM +0300, Sam Protsenko wrote: > > > > > Useful for testing mux clocks. One can write the index of the parent to > > > > > be set into clk_parent node, starting from 0. Example > > > > > > > > > > # cd /sys/kernel/debug/clk/mout_peri_bus > > > > > # cat clk_possible_parents > > > > > dout_shared0_div4 dout_shared1_div4 > > > > > # cat clk_parent > > > > > dout_shared0_div4 > > > > > # echo 1 > clk_parent > > > > > # cat clk_parent > > > > > dout_shared1_div4 > > > > > > > > > > CLOCK_ALLOW_WRITE_DEBUGFS has to be defined in drivers/clk/clk.c in > > > > > order to use this feature. > > > > > > > > ... > > > > > > > > > +#ifdef CLOCK_ALLOW_WRITE_DEBUGFS > > > > > + if (core->num_parents > 1) > > > > > + debugfs_create_file("clk_parent", 0644, root, core, > > > > > + ¤t_parent_rw_fops); > > > > > + else > > > > > +#endif > > > > > > > > > + { > > > > > + if (core->num_parents > 0) > > > > > + debugfs_create_file("clk_parent", 0444, root, core, > > > > > + ¤t_parent_fops); > > > > > + } > > > > > > > > Currently there is no need to add the {} along with increased indentation > > > > level. I.o.w. the 'else if' is valid in C. > > > > > > Without those {} we have two bad options: > > > > > > 1. When putting subsequent 'if' block on the same indentation level > > > as 'else': looks ok-ish for my taste (though inconsistent with #ifdef > > > code) and checkpatch swears: > > > > > > WARNING: suspect code indent for conditional statements (8, 8) > > > #82: FILE: drivers/clk/clk.c:3334: > > > + else > > > [...] > > > if (core->num_parents > 0) > > > > > > 2. When adding 1 additional indentation level for subsequent 'if' > > > block: looks plain ugly to me, inconsistent for the case when > > > CLOCK_ALLOW_WRITE_DEBUGFS is not defined, but checkpatch is happy > > > > > > I still think that the way I did that (with curly braces) is better > > > one: it's consistent for all cases, looking ok, checkpatch is happy > > > too. But isn't it hairsplitting? This particular case is not described > > > in kernel coding style doc, so it's about personal preferences. > > > > > > If it's still important to you -- please provide exact code snippet > > > here (with indentations) for what you desire, I'll send v6. But > > > frankly I'd rather spend my time on something more useful. This is > > > minor patch, and I don't see any maintainers wishing to pull it yet. > > > > Note that checkpatch is just a tool, providing advice. It is not perfect, > > and if there is a good reason to ignore it, I'm all for that. > > > > Agreed. Actually I did the same grepping as Andy mentioned in previous > mails, and used that style because that's what other people often do. > checkpatch is more like excuse for me in this case :) > > > Personally, I would write: > > > > #ifdef CLOCK_ALLOW_WRITE_DEBUGFS > > if (core->num_parents > 1) > > debugfs_create_file("clk_parent", 0644, root, core, > > ¤t_parent_rw_fops); > > else > > #endif > > if (core->num_parents > 0) > > debugfs_create_file("clk_parent", 0444, root, core, > > ¤t_parent_fops); > > } > > > Actually... After considering all options and looking at actual diff, I'll go with that option: looks least cluttered, and the delta is really minimal. > That looks good to me. But I'd keep it as is, if you don't have a > strong opinion about this: looks better with braces, because it's > multi-line blocks (although physically and not semantically). > > > Then, I'm wondering if it really is worth it to have separate cases for > > "num_parents> 1" and "num_parents > 0". If there's a single parent, > > current_parent_write() should still work fine with "0", wouldn't it? > > Then the only differences are the file mode and the fops. > > You could handle that with #defines above, like is currently done for > > clk_rate_mode. And the checkpatch issue is gone ;-) > > > > I considered such case. But it would be inconsistent with this already > existing code: > > if (core->num_parents > 1) > debugfs_create_file("clk_possible_parents", 0444, root, core, > &possible_parents_fops); > > Because user would probably want to use both 'clk_parent' and > 'clk_possible_parents' together (e.g. see my example in commit > message). From logical point of view, I designed that code for testing > MUX clocks, and I doubt there are any MUXes with only one parent > (input signal). So I'd like to keep this logic as is, if you don't > mind, even though it might appear bulky. > > So for v6 I'm going to go exactly with what Andy suggested, hope it's > fine with you? > > > Gr{oetje,eeting}s, > > > > Geert > > > > -- > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > > > In personal conversations with technical people, I call myself a hacker. But > > when I'm talking to journalists I just say "programmer" or something like that. > > -- Linus Torvalds