Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp6221328pxb; Mon, 8 Nov 2021 05:15:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyaE6LKn4dlgD3hJ+OuCBpWLMrtZZhvt1XwWOgHWpnhF/vBWHoReLezNPLECo09ZIU0/a7 X-Received: by 2002:a05:6e02:12c2:: with SMTP id i2mr24433644ilm.261.1636377318264; Mon, 08 Nov 2021 05:15:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636377318; cv=none; d=google.com; s=arc-20160816; b=z+snnMlquh1bFywXe3OgDuauFAvKPClmr75VfR+KebfiBcePcakCkEG8+DOKmsv0cB 4fnwvSJlWnehS9X1KcD38tkQGO7JLQel5CbLGad7dzD1f0lweTsGurrTZbgHYNFWKsJ5 rjKheSx3cwDUaeauq0qzmZjkKyzlyrqaaJGd3OHwk63xWZm8WXmU42aJvDulKbWwgWJl ashDI/qbcupd1Gql2aiQQCPrzH8gfpr5YyZZDaZorBGRsLy5cpO1is4R8d83GHAhUAi3 Y7+bQ2VqhC58iHTfiAQNxhhxbKbniEl5i3lM+2yaJqBowGyuwxjwZXny8L/e2XdZYCFc Vzaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ZidGX0bgnEprP+VsESkF91mkr08ooFhWFCbPYDghIhM=; b=zQuNNPTMHuyTYMIrkvfFv2DZMcTlgSFfBQmxhnFjeiPHUx0JfwCOajLOt2aZB4wIKM ag3HhJtPmjLr8jho/a4MiW/4fj40mNeQyNHl6QzohIKJfc4OZsQoPmr6jrSDoelAUU3c dD84/EyDrJf/Pm2Nsl5Rw/9GU5Ezusdqpv3xn2Dq4qttL4qxsbMoK+fJ404KZctZSLlP fzCfcv/yqBNJKiRsIFU1oCdfYdvjj37ABrh6/SpcxU5QJctq3Qxutnlw/Cs7T5KG8C/4 MA2wq4FFs1MuVVcAO+MPEgb0yCcac96y96QGSVbawjxkJotPmV4WL1PeDuAk+h9tN6G7 yxAw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l6si25473054jaj.7.2021.11.08.05.15.04; Mon, 08 Nov 2021 05:15:18 -0800 (PST) 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; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237497AbhKHJU2 (ORCPT + 99 others); Mon, 8 Nov 2021 04:20:28 -0500 Received: from mga17.intel.com ([192.55.52.151]:41360 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233715AbhKHJU1 (ORCPT ); Mon, 8 Nov 2021 04:20:27 -0500 X-IronPort-AV: E=McAfee;i="6200,9189,10161"; a="212928192" X-IronPort-AV: E=Sophos;i="5.87,218,1631602800"; d="scan'208";a="212928192" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2021 01:17:28 -0800 X-IronPort-AV: E=Sophos;i="5.87,218,1631602800"; d="scan'208";a="544398855" Received: from smile.fi.intel.com ([10.237.72.184]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Nov 2021 01:17:21 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1mk0m3-004cLP-Ea; Mon, 08 Nov 2021 11:17:07 +0200 Date: Mon, 8 Nov 2021 11:17:07 +0200 From: Andy Shevchenko To: Emil Renner Berthing Cc: Yury Norov , linux-riscv , devicetree , linux-clk , "open list:GPIO SUBSYSTEM" , "open list:SERIAL DRIVERS" , Palmer Dabbelt , Paul Walmsley , Rob Herring , Michael Turquette , Stephen Boyd , Thomas Gleixner , Marc Zyngier , Philipp Zabel , Linus Walleij , Greg Kroah-Hartman , Daniel Lezcano , Jiri Slaby , Maximilian Luz , Sagar Kadam , Drew Fustini , Geert Uytterhoeven , Michael Zhu , Fu Wei , Anup Patel , Atish Patra , Matteo Croce , Linux Kernel Mailing List Subject: Re: [PATCH v3 09/16] reset: starfive-jh7100: Add StarFive JH7100 reset driver Message-ID: References: <20211102161125.1144023-1-kernel@esmil.dk> <20211102161125.1144023-10-kernel@esmil.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 04, 2021 at 01:15:46PM +0100, Emil Renner Berthing wrote: > On Tue, 2 Nov 2021 at 22:17, Emil Renner Berthing wrote: ... > I'd really like to understand your reasoning here. As far as I can > tell reading 2 adjacent 32bit registers with a 64bit read as you're > proposing is exactly what would cause endian issues. Eg. on little > endian you'd get reg0 | reg1 << 32 whereas on big-endian you'd get > reg0 << 32 | reg1. Nope, it won't. The endianess is a property of both CPU and device. The I/O accessors, such as readl()/writel() and iowrtieXX()/ioreadXX() are _always_ LE. So, writeq() will properly put bits to their places in case device is LE. And most devices are LE (or should be). Of course there are cases, but then you have to specify them explicitly. My motive here is simple as that the device is definitely a set of a few 128-bit bitmaps (in registers) and using bitmap _is_ representing hardware in the kernel. Using something else will deviate from that (maybe not too far, but still...). -- With Best Regards, Andy Shevchenko