Re: [PATCH 2/3] spi: spacemit: introduce SpacemiT K1 SPI controller driver

From: Yixun Lan <dlan@gentoo.org>
To: Alex Elder <elder@riscstar.com>
Cc: broonie@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, linux-spi@vger.kernel.org,
	devicetree@vger.kernel.org, paul.walmsley@sifive.com,
	palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
	p.zabel@pengutronix.de, spacemit@lists.linux.dev,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] spi: spacemit: introduce SpacemiT K1 SPI controller driver
Date: Thu, 18 Sep 2025 22:56:44 +0800	[thread overview]
Message-ID: <20250918145644-GYC1274501@gentoo.org> (raw)
In-Reply-To: <cedaad98-1eba-431f-af4a-b84e106e5f65@riscstar.com>

Hi Alex,

On 09:47 Thu 18 Sep     , Alex Elder wrote:
> On 9/18/25 9:39 AM, Yixun Lan wrote:
> >>>> +	u32 data_reg_addr;		/* DMA address of the data register */
> >>> s/data_reg_addr/ssp_data/? I just feel uncomfortable with redundant 'reg_addr'
> >> My convention is normally "virt" or maybe "base" to represent
> >> a virtual address, and "addr" to represent I/O addresses.
> >>
> >> This symbol represents the physical address that underlies the
> >> "SSP Data Register", which fills the TX FIFO when written and
> >> drains the RX FIFO when read.
> >>
> >> How about "data_addr"?  I know you wouldn't like "reg_addr".
> >>
> > another idea here, instead of introducing a variable here,
> > how about simply using plain iores->start + SSP_DATAR?
> > 
> > so you can cache "iores" instead..
> 
> This code has gone through a huge amount of refactoring.
> 
> I hadn't looked, but now I see this field is used exactly one
> place in the code, in k1_spi_prepare_dma_io().  It's still
> needed though.
> 
> Here's what I plan to do.  Rather than saving data_reg_addr,
> I will simply save base_addr, which is the I/O resource start
> address that corresponds to the mapped virtual pointer, "base".
> 
> Then in k1_spi_prepare_dma_io() I'll use base_addr + SSP_DATAR.
> 
> OK?
> 
Yes, this is what I'm suggesting
-- 
Yixun Lan (dlan)

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv