Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1786122pxa; Thu, 20 Aug 2020 22:21:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx3cIWA0miX4jcC71DbZd3U3LyNlD5cszUzau56iSEohCbfbim4x5KF7NR7QVB346MGxB6d X-Received: by 2002:a17:906:9609:: with SMTP id s9mr1245937ejx.232.1597987269305; Thu, 20 Aug 2020 22:21:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597987269; cv=none; d=google.com; s=arc-20160816; b=JX/BSm4RyeylCbkd18z3tWVmztSm4uqXlgH0e6eG1BV50c69GlEZ9zcSWkjv/mZ7HW hdp5qqtj+ctp+4prAN77+EVFHw7zE9IAfYjJK2Xqd+j0ws0h6q6/K4oJnZmyGRacfuit r7ltxoDqPryQH9iSls30OlLu1iVz5qbwca/a7GCRtTx6zVzQytcjGGp++wJ/gX3ZLPtM oLMPJ75Wco/pAjdbCeUyVXYrCnDedZc+wqlgHooApWCzbYdAly+4+SxZTXEKKqp2TLyb n+qK0IGrTMmjpeAwmLW/C9Hssu2ksgYP1ClMxkjQZMmNU7uXQZUsl1ADn0hfm2+AWa2S 4CuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=auUqpE3kcymKw8/e6dfkqog7BDUxhvFbcL40rA+HA1A=; b=bqCrxC8uNMDNAeiHYWp9N8rEUqVT6o3QuIuLtI2I/wEdWSG+IsoHmRlAZ4U7d4kv7r zQAQ4xGU2y2DHzfX1xCeruPAcWtzM+6gOAGqa9cMKq7mePXhn7zGJ6TAP7BAJ6Snx+vl 3TbJub17qYMFiEbYyLnpHh9N6M29eGeDjOZ/eC9eU7xKwf7mf4JcCajFIq3LU6aNdouY hCNe/ptHlaxWqHDcN/fsNd6KCiVj+ctzA+aKnMsMO7T750jLuhqGIzgGn6De3M/s0WPe ppueGXl+Nm72seluHc3Uxl/1rZC88uz5tV9kJSErlC/xLqQzCYsjs2Vywydu9J081M+6 IA8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=zLz1Atbc; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r14si478363ejb.283.2020.08.20.22.20.44; Thu, 20 Aug 2020 22:21:09 -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=@kernel.org header.s=default header.b=zLz1Atbc; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726993AbgHUFSy (ORCPT + 99 others); Fri, 21 Aug 2020 01:18:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:51094 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726243AbgHUFSx (ORCPT ); Fri, 21 Aug 2020 01:18:53 -0400 Received: from localhost (unknown [122.171.38.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 97A2121734; Fri, 21 Aug 2020 05:18:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597987132; bh=mmhRfihkzkkhMIK7A3ZIDER3eFubJHpxbN8wAHHp6gI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=zLz1Atbcda2iiVJiXgF7Jfx3Hx+M5Nw7LRvhTNtH2Tnhknz8MoVRSAW1J4IZPoK/R koj0jhejhLL+SgxFb8CSD3bP7QlKATqjzkq2goZz7gwDoMe10pSd9ov6Mmi5pxlD/3 H0WeyOEH5yS/Ljji6UohaP1jgFX88MYW5pjRJYw0= Date: Fri, 21 Aug 2020 10:48:48 +0530 From: Vinod Koul To: Geert Uytterhoeven Cc: Liam Beguin , Kishon Vijay Abraham I , Linux Kernel Mailing List Subject: Re: [PATCH v3 1/1] phy: tusb1210: use bitmasks to set VENDOR_SPECIFIC2 Message-ID: <20200821051848.GM2639@vkoul-mobl> References: <20200817163152.13468-1-liambeguin@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19-08-20, 15:57, Geert Uytterhoeven wrote: > Hi Liam, > > > On Mon, Aug 17, 2020 at 7:38 PM Liam Beguin wrote: > > From: Liam Beguin > > > > Start by reading the content of the VENDOR_SPECIFIC2 register and update > > each bit field based on device properties when defined. > > > > The use of bit masks prevents fields from overriding each other and > > enables users to clear bits which are set by default, like datapolarity > > in this instance. > > > > Signed-off-by: Liam Beguin > > --- > > Changes since v1: > > - use set_mask_bits > > > > Changes since v2: > > - fix missing bit shift dropped in v2 > > - rebase on 5.9-rc1 > > > > drivers/phy/ti/phy-tusb1210.c | 27 +++++++++++++++++---------- > > 1 file changed, 17 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/phy/ti/phy-tusb1210.c b/drivers/phy/ti/phy-tusb1210.c > > index d8d0cc11d187..358842b5790f 100644 > > --- a/drivers/phy/ti/phy-tusb1210.c > > +++ b/drivers/phy/ti/phy-tusb1210.c > > @@ -14,8 +14,11 @@ > > > > #define TUSB1210_VENDOR_SPECIFIC2 0x80 > > #define TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT 0 > > +#define TUSB1210_VENDOR_SPECIFIC2_IHSTX_MASK GENMASK(3, 0) > > #define TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_SHIFT 4 > > +#define TUSB1210_VENDOR_SPECIFIC2_ZHSDRV_MASK GENMASK(5, 4) > > #define TUSB1210_VENDOR_SPECIFIC2_DP_SHIFT 6 > > +#define TUSB1210_VENDOR_SPECIFIC2_DP_MASK BIT(6) > > > > struct tusb1210 { > > struct ulpi *ulpi; > > @@ -118,23 +121,27 @@ static int tusb1210_probe(struct ulpi *ulpi) > > * diagram optimization and DP/DM swap. > > */ > > > > + reg = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2); > > + > > /* High speed output drive strength configuration */ > > - device_property_read_u8(&ulpi->dev, "ihstx", &val); > > - reg = val << TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT; > > + if (!device_property_read_u8(&ulpi->dev, "ihstx", &val)) > > + reg = set_mask_bits(®, TUSB1210_VENDOR_SPECIFIC2_IHSTX_MASK, > > + val << TUSB1210_VENDOR_SPECIFIC2_IHSTX_SHIFT); > > Triggered by your patches to add support for cmpxchg on u8 pointers to > various architectures (which is a valuable goal in itself ;-), I decided > to have a look at the underlying problem you were facing. > > IMHO, using set_mask_bits() is overkill here. That helper is meant to > update individual bits in a variable that may be accessed concurrently, > hence its use of cmpxchg(). > > In this driver, you just want to modify a local variable, by clearing a > field, and setting some bits. No concurrency is involved. > Perhaps using FIELD_PREP() from include/linux/bitfield.h is more > appropriate? Yeah i discovered the include/linux/bitfield.h and yes that looks more apt here. u32_encode_bits() would make sense here and get rid of mask and shift stuff too. -- ~Vinod