Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp81750ybg; Fri, 25 Oct 2019 17:05:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwVcODTygAl6016rgKUC4GvttbrzpBxYmB2dBZm41p0qzFIF+Bc1Xh4IyfmJKws+nOudqbD X-Received: by 2002:a17:906:9618:: with SMTP id s24mr6121625ejx.185.1572048325339; Fri, 25 Oct 2019 17:05:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572048325; cv=none; d=google.com; s=arc-20160816; b=LKQ9hcOtI95TYHz6LeHq7WNySEhPthc1tjj+o8UK1/ZfsscHAyq+OsmbJEnHO0zv0H okmtIGsKFYXUn/EC3qi1K8K5+IgIrjCgtXYLOCbjWM2E9P5Kp2bKyDOMwjjwa+kQsxFR MXFTDkYx+pVcvHRrw9quzgnBrl+lKMUEHjLXFTTMXIAX/WIU8F7X2M3t/jcYCyi5ANPm aJn/nifd1KvJeucZA6hZKR3tLmyKhWVwUiLH1oxz40q7Ecb3XfAPViw6CSEqg7vn+U/q XmDMDVvHGMPbKPCEEUUo9BHM7jNTbKXVYDobQE1l01PC+wFZfv2KVdcD/Sufv/fMg+Wj DKQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=rmR5t0ADsYfno5vVZm/vi2FgzFz346rAEYBMOAdK/VQ=; b=hiH5I1ZU84/eIv13iWLaTTkpJaMgQUQ51JwbcRykQLy/d+7wlloE1H3DzgTYoT/YXJ KO0cuim5bGzDLLlLDaxvlijXwgiM6NziopkLy6RQFMGybXDazT9RYGq7/K9525UBH9W2 dCBddEzaCXaEVXFKIpyat+uFQ3ENBIcylFa08UktUO0wQuNbBPkhffU/YGjWod9yQQuW CHYP5bhOLwIP9+NGAu4ikEVp62ICOiU0TBQOqwQiAIdyovAYp6guFjXsDU6A6GHvcz5j y6M7cA4wmZ0Ux31/33PdLgvF1Nq6b5KIYvOnJfC59iQn4SqB+Uf5T9YBYpBrh44kzfS9 U4rg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z5si2657102edk.157.2019.10.25.17.04.35; Fri, 25 Oct 2019 17:05:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726010AbfJZADs (ORCPT + 99 others); Fri, 25 Oct 2019 20:03:48 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:40124 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725847AbfJZADs (ORCPT ); Fri, 25 Oct 2019 20:03:48 -0400 Received: by mail-ot1-f67.google.com with SMTP id d8so3219379otc.7; Fri, 25 Oct 2019 17:03:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rmR5t0ADsYfno5vVZm/vi2FgzFz346rAEYBMOAdK/VQ=; b=H/sUUkILyLwtjjcXwtqox/t+P55WUFqQc/lUt0+ycZdm20mZ0rAnX6t4IuC1Mrdl23 Jt0T9zY2nSHJupYV0cCVACXp+9V4JAuIzWGylxy0AU8LjfaicytXzmUMCUDR0MNG9Y26 eoWTBB33szC10QOgehJ9rduFzPnwp5VA2xcO4wJDLDqsalaFWvoMqD89SAVT3hfkoo6g /cYp9B5BOPtUnwiIfijTaPSyYtZatwE1j4JcsFh4sZkth3w54PMU7uZQRqg7X1mLPk1Y Qpw3jj11hz+MUgrvg3BbmNIZQdRG0Q8ZhjMgxDdwYpKzGJbz1AAU1bY6dPwvFpHxpWpM QoWg== X-Gm-Message-State: APjAAAVIFVG5nlCKQm7jkjjK6q9k9BN7dtwaTSLxhgRsnTqgT6UsiLPd UGZvqQG1wTdy82VTvYDwXQ== X-Received: by 2002:a9d:66d:: with SMTP id 100mr4878305otn.302.1572048226729; Fri, 25 Oct 2019 17:03:46 -0700 (PDT) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id v6sm1031983oie.4.2019.10.25.17.03.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Oct 2019 17:03:46 -0700 (PDT) Date: Fri, 25 Oct 2019 19:03:45 -0500 From: Rob Herring To: Mateusz Holenko Cc: Mark Rutland , Greg Kroah-Hartman , Jiri Slaby , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, Stafford Horne , Karol Gugala , Mauro Carvalho Chehab , "David S. Miller" , "Paul E. McKenney" , Filip Kokosinski , Joel Stanley , Jonathan Cameron , Maxime Ripard , Shawn Guo , Heiko Stuebner , Sam Ravnborg , Icenowy Zheng , Laurent Pinchart , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/4] litex: add common LiteX header Message-ID: <20191026000345.GA10810@bogus> References: <20191023114634.13657-0-mholenko@antmicro.com> <20191023114634.13657-2-mholenko@antmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191023114634.13657-2-mholenko@antmicro.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 23, 2019 at 11:47:04AM +0200, Mateusz Holenko wrote: > It provides helper CSR access functions used by all > LiteX drivers. > > Signed-off-by: Mateusz Holenko > --- > This commit has been introduced in v2 of the patchset. > > MAINTAINERS | 6 +++++ > include/linux/litex.h | 59 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 65 insertions(+) > create mode 100644 include/linux/litex.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 296de2b51c83..eaa51209bfb2 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9493,6 +9493,12 @@ F: Documentation/misc-devices/lis3lv02d.rst > F: drivers/misc/lis3lv02d/ > F: drivers/platform/x86/hp_accel.c > > +LITEX PLATFORM > +M: Karol Gugala > +M: Mateusz Holenko > +S: Maintained > +F: include/linux/litex.h > + > LIVE PATCHING > M: Josh Poimboeuf > M: Jiri Kosina > diff --git a/include/linux/litex.h b/include/linux/litex.h > new file mode 100644 > index 000000000000..e793d2d7c881 > --- /dev/null > +++ b/include/linux/litex.h > @@ -0,0 +1,59 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common LiteX header providing > + * helper functions for accessing CSRs. > + * > + * Copyright (C) 2019 Antmicro > + */ > + > +#ifndef _LINUX_LITEX_H > +#define _LINUX_LITEX_H > + > +#include > +#include > +#include > + > +#define LITEX_REG_SIZE 0x4 > +#define LITEX_SUBREG_SIZE 0x1 > +#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8) > + > +#ifdef __LITTLE_ENDIAN > +# define LITEX_READ_REG(addr) ioread32(addr) > +# define LITEX_READ_REG_OFF(addr, off) ioread32(addr + off) > +# define LITEX_WRITE_REG(val, addr) iowrite32(val, addr) > +# define LITEX_WRITE_REG_OFF(val, addr, off) iowrite32(val, addr + off) > +#else > +# define LITEX_READ_REG(addr) ioread32be(addr) > +# define LITEX_READ_REG_OFF(addr, off) ioread32be(addr + off) > +# define LITEX_WRITE_REG(val, addr) iowrite32be(val, addr) > +# define LITEX_WRITE_REG_OFF(val, addr, off) iowrite32be(val, addr + off) Defining custom accessors makes it harder for others to understand the code. The __raw_readl/writel accessors are native endian, so use those. One difference though is they don't have a memory barrier, but based on the below functions, you may want to do your own barrier anyways. And if DMA is not involved you don't need the barriers either. The _OFF variants don't add anything. LITEX_READ_REG(addr + off) is just as easy to read if not easier than LITEX_READ_REG_OFF(addr, off). > +#endif > + > +/* Helper functions for manipulating LiteX registers */ > + > +static inline void litex_set_reg(void __iomem *reg, u32 reg_size, u32 val) > +{ > + u32 shifted_data, shift, i; > + > + for (i = 0; i < reg_size; ++i) { > + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT); > + shifted_data = val >> shift; > + LITEX_WRITE_REG(shifted_data, reg + (LITEX_REG_SIZE * i)); > + } > +} The problem with this is it hides whether you need to do any locking. Normally, you would assume a register access is atomic when it's not here. You could add locking in this function, but then you're doing locking even when not needed. It doesn't look like you actually use this in your series, so maybe remove until you do. > + > +static inline u32 litex_get_reg(void __iomem *reg, u32 reg_size) > +{ > + u32 shifted_data, shift, i; > + u32 result = 0; > + > + for (i = 0; i < reg_size; ++i) { > + shifted_data = LITEX_READ_REG(reg + (LITEX_REG_SIZE * i)); > + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT); > + result |= (shifted_data << shift); > + } > + > + return result; > +} > + > +#endif /* _LINUX_LITEX_H */ > -- > 2.23.0