Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3365052pxb; Wed, 13 Oct 2021 04:39:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyO2KgmrqdBfmz+Oo+9JXWWn3r1sBlZWK4ZkKtIgjiMwvf5V4nh+xk/q1RWmKlRo4LJRnZG X-Received: by 2002:a17:906:f184:: with SMTP id gs4mr40851579ejb.116.1634125172379; Wed, 13 Oct 2021 04:39:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634125172; cv=none; d=google.com; s=arc-20160816; b=0kM2IfhORc0fY8EjSkGFL+xnUTKKrxwQnrpL3R5qy5r2nZffzUkHDqOYi9EjjyKKpQ cw5jjEmV10IGxQDSZ4eM1ZSVv58u6N4K8yo3QeHdMITnLb2YJi1gWFB+qj/IiT0bFHkX QJ8PKGnParPQyMyCzRrzXiJaNA+Lvk25KyexeCjJ9EWc15zfA/j8Cg28tJfQL1DiWorI adQG+CSQ/nCqzGEMaMtWWdQblGJFy5vDZ4Uh4kgqhmhUBK1/GM9Sw9oQ35+0ovVf5mQz FA+3DVMTIaficA3RfC/MMEzNHSNpGmU17Vo7FBlf2bdyOAl5/JiygdT3cjMReDl58DuU 0xxg== 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=1BHXXzvtzeANnGlYj0j/Y48TNpRv6ZNQOg6UzSjdT00=; b=QbdlGxR42en2ZV1PornvV+g7tZZ7rk4v9Qv/fxTzaVhEc2TlL90ua08aFQlFsweogi oE7pzj/xFq66HKBHJc6gOUePfmH9dOphAAEHE4+E9ENzvjVVX8V3j4hGlwGDpfh6B1sg 0ODFHYvW2p+Q4bJRBwwnnsXmB85q2RQzxXAkpduZNuZJnIJOUvxc2uliQa+cmMI6awBf Y3YlM24ERU5zGT7ti8kb/4u77jrfmVgvVl5JO+MmUveJAZAuTxMW7d031rs0ybryIsU0 PjgR624eCSuQodhc2sFghRx6pL/Zudg/77V262vzjFwViIheoqHrE0QTeeuns/FsIEVZ JZuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=CaxxwZx5; 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 g1si20829622ejp.158.2021.10.13.04.39.07; Wed, 13 Oct 2021 04:39:32 -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=CaxxwZx5; 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 S231346AbhJMLiF (ORCPT + 99 others); Wed, 13 Oct 2021 07:38:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231294AbhJMLiE (ORCPT ); Wed, 13 Oct 2021 07:38:04 -0400 Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13FACC061570 for ; Wed, 13 Oct 2021 04:36:01 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id u5so3700129uao.13 for ; Wed, 13 Oct 2021 04:36:01 -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=1BHXXzvtzeANnGlYj0j/Y48TNpRv6ZNQOg6UzSjdT00=; b=CaxxwZx5QBPBptY9NbvsOzzkgYhmLshDyqM8s5zJ9u+q4tXDuc4QD6J1pSVZWT9SZI mFKihFPK1keHRYr+o4rfQZVnmKF5pLtnkivygAdMSQKWnmLo7Ggtcz+SJ+h9JlVMGC6Z Wznr0axqgDcJpPZtmQqSXEKSa5jrY13EEAIhlFfFxH0tIiAPpV0d+FBb0L0bbX61AL/4 uCaTW+RsowGPSIQ3wdWN/2qQMy2D2+wzC+PHJdumfJVYjbeg/rdj95IO0ckvVyNgxWoH MEZJ669IBFk82K+4RgrmlifRgVP5oi+vwbwg9omah8VgIXxStFOJfdvq6w7OrexWOMSq 6Bmg== 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=1BHXXzvtzeANnGlYj0j/Y48TNpRv6ZNQOg6UzSjdT00=; b=lvQ+Tm66oLjRvKRQrxuxM/Ci3IG8mLdUnfRXrlry/0vG+BFkhSIS6B7/4CDilISsWX uBPeRJyPOL2c8GUN3bjnd/E3DUlk+dIfXvHXEH0sRmwSpsrX/U6gJp6JqNIxsDvqBKA8 Lb+uH2+fvzb7ZrhsRjk7nkdgwgdt9B7ub3oXYRmSsRgQPLRgS710Xa6yDhN7XWkNhL2B HD+QNo51E5mLl25Q+6E/6NiQEbkejfKIu9MVcHmWRNx6+nrfkGpnCvqc/Tt/Aodok7FU W3+Ka/7/Uh/hrmjME4drTRB2UdjAVVL3SCyWF+KVu9I6t6C0UMer/+0AYHy+b0aPCVuu iFtw== X-Gm-Message-State: AOAM530TLmjz6/aKSBr8kOKpPq8qYg3tGvQm26SbieMG8EiKfQN+YC7d HsibMZmqErb3K9Ha6crqC1jsbHxmXEf23qIpty1Uxg== X-Received: by 2002:ab0:708e:: with SMTP id m14mr28558622ual.104.1634124960204; Wed, 13 Oct 2021 04:36:00 -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 14:35:48 +0300 Message-ID: Subject: Re: [PATCH v5] clk: Add write operation for clk_parent debugfs node To: Andy Shevchenko Cc: Michael Turquette , Stephen Boyd , Russell King , Chanwoo Choi , Sylwester Nawrocki , Krzysztof Kozlowski , Mike Tipton , Andy Shevchenko , Geert Uytterhoeven , 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 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. Btw, if you know someone who can take it, could you please reference them here? > -- > With Best Regards, > Andy Shevchenko > >