Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp1064781rwd; Thu, 15 Jun 2023 06:02:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ532qDW/NFhPELA8oB90g1dZYwTmmeNBSVTQ24s/Cd9O8xjm9B+f8a2jENpupP17Eabfcr7 X-Received: by 2002:a17:907:804:b0:973:d3ee:6bdf with SMTP id wv4-20020a170907080400b00973d3ee6bdfmr16647476ejb.43.1686834175458; Thu, 15 Jun 2023 06:02:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686834175; cv=none; d=google.com; s=arc-20160816; b=0n/rnJmDgWtBG5iateygF5gBGk+JJNstTcSNQyfNQ9dzxzmYUIWibrXqI9N23cFJh0 uFpQA23YPqbNkqWEBMesjBLl4S6OxOuZeoIB8l1IGu9Cs7JbO6jcRAVP3baRefgZKyiV 0l/NxErdHp7wdLGGA1ARx1dZG05EWkh09kMCZ/1E0wNgG6/LrMG0XzPkNh4M/l0ibjHZ qacRBxzcHx91+JdlQHIwk/EWSuPMKNQ8NO98g+2VMPeCksMQ7eFrqjdHfcw/qpLnOF80 R0VrhYc75h7WjlZcFGlPbA3zMTM4ytv79KzA4noFS+LePHoofYIWEZECJwGGR6ubdVXR vDfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=EVx3Juzw7MX0bdBli7DJ6XOub6KiQQ2HiyU7XgT5nUs=; b=H6Hyz8VNDyBtckJFgCOL7oRg1f/LgonxYn7X6bPpG+T5/ORdwxVDJuGMSp3ZWldHZO 8nsmFoKV9jYGBbj7W/opnv4jIkIvxbXryM42I0Lf0bNpA2LlRUx1ecMgNUrM8TsVY7ZU u45ioyURIiuvfONVPBa1x64mNLd/4GD2rLIj603Vw7lUhRvHRrvo0eTGoCUF+Zr53lBQ Qzr2s1yC7DfEdXIssxrMptxTno+rjdbqsiBqmh2V+2dONN5fW5XDhqN5apltWYj0wN7+ FwOrxyheQVgZxcjPBulHS9A5r/RRRlWR9UvR+/dsN0i0UsMyQUQ0+vZ/frnxYfdbSXfR mPVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Yh4oUiVo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q13-20020a1709064c8d00b0097860824fc1si9401746eju.819.2023.06.15.06.02.03; Thu, 15 Jun 2023 06:02:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Yh4oUiVo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245466AbjFOMuh (ORCPT + 99 others); Thu, 15 Jun 2023 08:50:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48434 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239033AbjFOMug (ORCPT ); Thu, 15 Jun 2023 08:50:36 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D40A2126; Thu, 15 Jun 2023 05:50:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CCA23625F0; Thu, 15 Jun 2023 12:50:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBA46C433C8; Thu, 15 Jun 2023 12:50:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1686833434; bh=9C0lIysBzhK2NDkLZ8zuWOZP34c6lCF4sNn1JWvzNkc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Yh4oUiVoqClwbgiExl0clwXIAhBdc+EGfyc1pP8k5YyWihS/NjiHOyXPKOW1APa+0 jO7L1bcu4ev6Hr9gPCVFxpMPK0L2ECM7+HUo1gVyMTWF669az9mbhAE+ACBvJochTz zhZVopAKEqBqa96MZ0tFFhKfstjFskNC9/t1nZQU= Date: Thu, 15 Jun 2023 14:50:31 +0200 From: Greg Kroah-Hartman To: Souradeep Chowdhury Cc: Andy Gross , Konrad Dybcio , Krzysztof Kozlowski , Bjorn Andersson , Rob Herring , Alex Elder , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, Sibi Sankar , Rajendra Nayak Subject: Re: [PATCH V23 2/3] misc: dcc: Add driver support for Data Capture and Compare unit(DCC) Message-ID: <2023061515-unbuckled-consonant-e207@gregkh> References: <2259ab0348282349e88905ea99bcb4aa815d941f.1683265984.git.quic_schowdhu@quicinc.com> <2023061542-reformed-unholy-10a3@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 15, 2023 at 06:13:53PM +0530, Souradeep Chowdhury wrote: > > > On 6/15/2023 4:03 PM, Greg Kroah-Hartman wrote: > > On Thu, May 04, 2023 at 11:36:22PM -0700, Souradeep Chowdhury wrote: > > > +/** > > > + * struct dcc_config_entry - configuration information related to each dcc instruction > > > + * @base: Base address of the register to be configured in dcc > > > > Why is this a u32 and not a bigger size? > > Currently only 32 bit register addresses are supported for DCC > configuration. > > > > > > + * @offset: Offset to the base address to be configured in dcc > > > + * @len: Length of the address in words to be configured in dcc > > > > What is a "word" here, 16 bits? > > Each word is 4 bytes(32 bits) See, I guess wrong, you should say what this is :) > > > + * @loop_cnt: The number of times to loop on the register address in case > > > + of loop instructions > > > + * @write_val: The value to be written on the register address in case of > > > + write instructions > > > + * @mask: Mask corresponding to the value to be written in case of > > > + write instructions > > > + * @apb_bus: Type of bus to be used for the instruction, can be either > > > + 'apb' or 'ahb' > > > > How can a bool be either "apb" or "ahb"? > > 1 stands for apb and 0 for ahb. Will update the same here. Why not have an enum? Will there ever be another "bus"? > > > +static ssize_t ready_read(struct file *filp, char __user *userbuf, > > > + size_t count, loff_t *ppos) > > > +{ > > > + int ret = 0; > > > + char *buf; > > > + struct dcc_drvdata *drvdata = filp->private_data; > > > + > > > + mutex_lock(&drvdata->mutex); > > > + > > > + if (!is_dcc_enabled(drvdata)) { > > > + ret = -EINVAL; > > > + goto out_unlock; > > > + } > > > + > > > + if (!FIELD_GET(BIT(1), readl(drvdata->base + dcc_status(drvdata->mem_map_ver)))) > > > + buf = "Y\n"; > > > + else > > > + buf = "N\n"; > > > +out_unlock: > > > + mutex_unlock(&drvdata->mutex); > > > + > > > + if (ret < 0) > > > + return -EINVAL; > > > + else > > > > You do the "lock, get a value, unlock, do something with the value" > > thing a bunch, but what prevents the value from changing after the lock > > happens? So why is the lock needed at all? > > The lock is used to prevent concurrent accesses of the drv_data when > scripts are being run from userspace. How would that matter? The state can change instantly after the lock is given up, and then the returned value is now incorrect. So no need for a lock at all as you really aren't "protecting" anything, or am I missing something else? thanks, greg k-h