Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i0ad843c9:Fastmail
Message-ID: <30171937-dfb5-4bba-23c1-607271c9a791@sholland.org>
Date:   Sun, 1 Jan 2023 12:59:24 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux ppc64le; rv:102.0) Gecko/20100101
 Thunderbird/102.3.3
Content-Language: en-US
From:   Samuel Holland <samuel@sholland.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Rob Herring <robh@kernel.org>
Cc:     Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org, linux-sunxi@lists.linux.dev
References: <20220814173656.11856-1-samuel@sholland.org>
 <20220814173656.11856-4-samuel@sholland.org>
 <20220825210252.GA1671168-robh@kernel.org>
 <68274f65-48f0-fe37-cefc-876d18e327e6@sholland.org>
Subject: Re: [PATCH 3/4] dt-bindings: nvmem: Allow bit offsets greater than a
 byte
In-Reply-To: <68274f65-48f0-fe37-cefc-876d18e327e6@sholland.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/8/22 22:29, Samuel Holland wrote:
> On 8/25/22 4:02 PM, Rob Herring wrote:
>> On Sun, Aug 14, 2022 at 12:36:54PM -0500, Samuel Holland wrote:
>>> Some NVMEM devices contain cells which do not start at a multiple of the
>>> device's stride. However, the "reg" property of a cell must be aligned
>>> to its provider device's stride.
>>
>> How is a DT author supposed to know this? 
> 
> To know the stride? They know the compatible string of the NVMEM provider
> device, and the stride is a property of the hardware.
> 
> To know that alignment to the stride is required? That's not documented in the
> binding. I can add that to the "reg" description in this file.
> 
>> I would lean toward it's the OS's problem to deal with (your option 1 I 
>> guess). I worry that one client could expect it one way and another 
>> client the other. Or folks making DT changes to 'fix' things.
> 
> After this binding change, the meaning of
> 
> 	reg = <0x2a 1>;
> 	bits = <0 8>; // optional
> 
> and
> 
> 	reg = <0x28 4>;
> 	bits = <16 8>;
> 
> would be identical.
> 
> With option 1, only the first representation would be valid in the DT.
> 
> With this series (option 2), either representation would validate in the DT, but
> only the second representation would be accepted by Linux for the driver in
> question (sunxi-sid).
> 
> With option 3, either representation would work in the DT and Linux.
> 
> Note that there is no restriction on the bit length, so the following are
> already equivalent today:
> 
> 	reg = <0x28 1>;
> 	bits = <0 8>; // optional
> 
> and
> 
> 	reg = <0x28 2>;
> 	bits = <0 8>;
> 
> So there are already multiple possible representations. I don't really think
> that is a problem, since the meaning is still unambiguous.

Does anyone have further thoughts on this?

From Rob's comment on the alignment being "the OS's problem", it sounds
like I should implement option 3 -- have the NVMEM core transform the
cell to match the driver's alignment/size requirements. Before I start
implementing it, does that sound workable?

Regards,
Samuel

>>> These cells can be represented in the DT using the "bits" property if
>>> that property allows offsets up to the full stride. 63 is chosen
>>> assuming that NVMEM devices will not have strides larger than 8 bytes.
>>>
>>> Signed-off-by: Samuel Holland <samuel@sholland.org>
>>> ---
>>>
>>>  Documentation/devicetree/bindings/nvmem/nvmem.yaml | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
>>> index 3bb349c634cb..4f440ab6a13c 100644
>>> --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
>>> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
>>> @@ -53,7 +53,7 @@ patternProperties:
>>>          $ref: /schemas/types.yaml#/definitions/uint32-array
>>>          items:
>>>            - minimum: 0
>>> -            maximum: 7
>>> +            maximum: 63
>>>              description:
>>>                Offset in bit within the address range specified by reg.
>>>            - minimum: 1
>>> -- 
>>> 2.35.1
>>>
>>>
> 
>