[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a8364e4-3160-4459-9db4-c9d877ba8c6e@riscstar.com>
Date: Thu, 18 Sep 2025 11:22:19 -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:
>>>> + ret = of_property_read_u32(np, "spi-max-frequency", &host->max_speed_hz);
>>>> + if (ret < 0) {
>>>> + if (ret != -EINVAL)
>>>> + dev_warn(dev, "bad spi-max-frequency, using %u\n",
>>>> + K1_SPI_MAX_SPEED_HZ);
>>> the err msg does't really usefull..
>> You mean there should be no error message, or that it
>> should say something else?
>>
>>>> + host->max_speed_hz = K1_SPI_MAX_SPEED_HZ;
>>>> + }
>>> so in any case, there will be an assignment, I'd rather simplify it as
>>>
>>> if (of_property_read_u32(np, "spi-max-frequency", &host->max_speed_hz);
>>> host->max_speed_hz = K1_SPI_MAX_SPEED_HZ;
>> I add the warning so it's clear we're using something different
>> than is specified in the DT.
>>
> I personally do not really care about the msg as long as there is a known good value,
> but you could weigh this..
>
> further I feel the warning message isn't accurate, if spi-max-frequency is
> "bad", why not let user fix it? does "bad" means invalid or overflow?
The reality is that this is a property in the DTB, so it can't
be "fixed" by the user. It defines the *maximum* frequency
that this particular controller (on this board, or possibly
limited by what the SoC is capable of) will implement.
Stating that it's "bad" seems enough, given it normally can't
be changed--and we will use a sane default instead.
It might helpful to indicate what the bad value is, but that
complicates the code ("bad" could mean the property was
specified without a value too).
> I don't want to have bikeshedding on this, feel free to pick my suggestion
> or keep yours, there is no much real difference
I plan to keep the code as-is.
I don't actually know whether the limitation is on the SoC
or the board (or even whether it truly is the upper bound).
I'll ask SpacemiT about that.
The default value is expected to work on all platforms. If
If it's specified at all, it should be done in the board
file (so it won't be in "k1.dtsi").
If I don't learn of specific constraints, I'll omit it in
the DTS file (it's currently unused).
However I *will* add some new code that verifies that the
value (if specified) is within the SoC-supported range,
which is 6.25 Kbps-51.2Mbps.
> thanks for your efforts to work on this
And thank you for your review feedback.
-Alex>
> -- Yixun Lan (dlan)
Powered by blists - more mailing lists