[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <057f2f54-c370-455c-95ca-83f97d884f3f@riscstar.com>
Date: Thu, 18 Sep 2025 10:44:10 -0500
From: Alex Elder <elder@...cstar.com>
To: Yixun Lan <dlan@...too.org>
Cc: broonie@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
conor+dt@...nel.org, linux-spi@...r.kernel.org, devicetree@...r.kernel.org,
paul.walmsley@...ive.com, palmer@...belt.com, aou@...s.berkeley.edu,
alex@...ti.fr, p.zabel@...gutronix.de, spacemit@...ts.linux.dev,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] spi: spacemit: introduce SpacemiT K1 SPI controller
driver
On 9/18/25 9:39 AM, Yixun Lan wrote:
>>>> + void *bufp = io->buf ? : dummy;
>>> simply s/bufp/buf/, embed pointer info into variable doesn't really help
>>> let's leave compiler to check
>> I called it "buf" originally and changed it to "bufp" because it
>> actually advances through the buffer (either the one in the IO
>> structure or the dummy buffer) in the loop.
>>
>> I don't understand your comment about the compiler.
>>
> for the compiler to check the type.. because people could even name it as
> u32 bufp;
OK now I see what you're saying. To me, "bufp" as a pointer
that moves through a buffer; it would normally be initialized
to "buf". Where used, "buf" doesn't change (points to the
start of the buffer), while "bufp" does.
It is an established convention, so at least to me it's carries
that meaning. I am *not* using the "p" to indicate it's a
pointer.
I looked around for some examples, and there aren't a ton of
them, but here are a few:
setup_dma_scatter()
__cmdline_find_option()
tmc_etb_dump_hw()
dnet_start_xmit()
I'm planning to keep it "bufp".
-Alex
Powered by blists - more mailing lists