From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F30A30BF6B; Sun, 17 May 2026 20:08:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779048524; cv=none; b=cm3risVYyyA7fwwVLtFZdOlaAR9cggGgIUZKkmkl6HjvrFB3GRPXc/O/3rGIeBojxLwAS0P0jBLdI6RhhFcMnp5Ti7kKo2fRvcNXELmsHAmdBpK14y18veFLjiyXrab6LIpIGhUlAFEYpRWSEn2vjPKhdJKy39EQAAvQFwLJsVI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779048524; c=relaxed/simple; bh=zf+st0yI5heHtI4FZ1FB5w9AS2N7hIXhtUlFxWhN0A0=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=RSv1Qx6kzC6gn7vsNWuEVK+ExdIcaiyEcGxSczsbZbSXl+Uu/D6E+dww91pV6paytT5GnHtIPR+Lbh0qoeSUZKbadFdJQrCb+DXUbeTaNF6e46nmV0gs8apXl2UzvMayM54vvH+BIyaKVquOr4RpphvTg5kuvVXY9eRAJS3HQJI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r9Cr6FMt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r9Cr6FMt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB11BC2BCB0; Sun, 17 May 2026 20:08:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779048524; bh=zf+st0yI5heHtI4FZ1FB5w9AS2N7hIXhtUlFxWhN0A0=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=r9Cr6FMtvqrl4KcQnR9rw/rt/YtdKbgi4CH6bXaVvl93BFfYuauAw0CuAlhP+YG8y pQFc8PBWrnXxdXTuvxnouiHebLJdUwROfykZP6F7iuXPbX1P97I3G5qwqwlqzgFlq6 nHNfVJfXpDTnFKLcIbrBf7R/s1DnZiB8Uz9jxb8DVViitVyMnqiiObGCBtoQ6wAtxr CdmAquxfDrJY2gxARAwkiWfbQ9sEenLKrNqhvUO747YciKmS48mKUkYpPp40wsXwQj Wz92kJmUSz2/ZdAq3sKux4+zxmQ1deFxBWm28+zY2PcgFrIsYTte2+IxxBB11i6zF/ +Ok7YYuzcF2vA== Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfauth.phl.internal (Postfix) with ESMTP id C860BF4007A; Sun, 17 May 2026 16:08:42 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-04.internal (MEProxy); Sun, 17 May 2026 16:08:42 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddufeeiledtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrnhgu uceuvghrghhmrghnnhdfuceorghrnhgusehkvghrnhgvlhdrohhrgheqnecuggftrfgrth htvghrnhepjeejffetteefteekieejudeguedvgfeffeeitdduieekgeegfeekhfduhfel hfevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhguodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduvdekhedujedtvdeg qddvkeejtddtvdeigedqrghrnhgupeepkhgvrhhnvghlrdhorhhgsegrrhhnuggsrdguvg dpnhgspghrtghpthhtohepkedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheprggu uhhrvghghhgvlhhlohessggrhihlihgsrhgvrdgtohhmpdhrtghpthhtohepohhlthgvrg hnvhesghhmrghilhdrtghomhdprhgtphhtthhopehgvghrgheskhgvrhhnvghlrdhorhhg pdhrtghpthhtoheplhhinhhugidqmheikehksehlihhsthhsrdhlihhnuhigqdhmieekkh drohhrghdprhgtphhtthhopegumhgrvghnghhinhgvsehvghgvrhdrkhgvrhhnvghlrdho rhhgpdhrtghpthhtoheplhhinhhugidqtggrnhesvhhgvghrrdhkvghrnhgvlhdrohhrgh dprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhr ghdprhgtphhtthhopehlihhnuhigqdhsphhisehvghgvrhdrkhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i36794607:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id A509E182007A; Sun, 17 May 2026 16:08:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: Am-_gogYW4uZ Date: Sun, 17 May 2026 22:08:22 +0200 From: "Arnd Bergmann" To: "Angelo Dureghello" , "Greg Ungerer" Cc: linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, linux-can@vger.kernel.org, linux-spi@vger.kernel.org, "Vladimir Oltean" Message-Id: <9391b782-7727-47fa-ac37-05cd50821d35@app.fastmail.com> In-Reply-To: References: <20260506142644.3234270-2-gerg@kernel.org> <20260506142644.3234270-8-gerg@kernel.org> <40aefc39-bd98-460d-8aa7-5dd79f562e0d@app.fastmail.com> Subject: Re: [RFC 4/4] m68k: coldfire: fix non-standard readX()/writeX() functions Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, May 17, 2026, at 21:43, Angelo Dureghello wrote: > On Thu, May 07, 2026 at 10:43:01PM +1000, Greg Ungerer wrote: >> On 7/5/26 05:12, Arnd Bergmann wrote: >> > On Wed, May 6, 2026, at 16:26, Greg Ungerer wrote: > > [ 2.270000] fsl-dspi fsl-dspi.0: Not able to get desc for DMA xfer > [ 2.280000] fsl-dspi fsl-dspi.0: DMA transfer failed > [ 2.280000] spi_master spi0: failed to transfer one message from queue > [ 2.290000] spi_master spi0: noqueue transfer failed > [ 2.290000] spi-nor spi0.1: probe with driver spi-nor failed with error -5 > > DSPI is using edma, i will try to understand where the issue is asap. > > About how it works: > - for accesses to edma module (IP) mmio registers, must be native > big_endian, so using the "be" suffix in "mcf"_edma looks ok for me. The twist here is that with the way that readl() is defined on coldfire as a non-swapping operation, and the generic definition assuming the opposite in static inline u32 ioread32be(const void __iomem *addr) { return swab32(readl(addr)); } the function called ioread32be() actually tries to access the registers as little-endian. I can see two possible ways we got here, but don't know which one is currect: a) the device actually has little-endian registers (like it does on i.MX, but unlike all other coldfire devices), and you just never noticed because using ioread32be() worked as you expected. b) you tested the driver using an ioread32be() definition that did not have a byteswap and it correctly accessed big-endian registers at the time, but the version in mainline today does not. > - for accessing the "tcd" memory structure, that must be, from what i > remember, anyway in little endian, independently from the cpu core > endiannes, this is the reason that big_endian flag is needed, it is > used for tcd area accesses, so the IP module was built. > The tcd area may be similar to pci accesses (see mcf54415 RM 19.4.16). edma_read_tcdreg() calls into edma_readl(), which is the same function that is used for normal register access, so from what I can tell, they always use the same endianess here. Arnd