lkml.org 
[lkml]   [2023]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH V3] dt-bindings: nvmem: convert base example to use "nvmem-layout" node
    From
    On 10.03.2023 09:59, Miquel Raynal wrote:
    > Hi Rafał,
    >
    > zajec5@gmail.com wrote on Fri, 10 Mar 2023 08:51:45 +0100:
    >
    >> From: Rafał Miłecki <rafal@milecki.pl>
    >>
    >> With support for "fixed-layout" binding we can use now "nvmem-layout"
    >> even for fixed NVMEM cells. Use that in the base example as it should be
    >> preferred over placing cells directly in the device node.
    >>
    >> New and other bindings should follow as old binding will get deprecated
    >> at some point.
    >>
    >> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
    >> ---
    >> .../devicetree/bindings/nvmem/nvmem.yaml | 42 +++++++++++--------
    >> 1 file changed, 24 insertions(+), 18 deletions(-)
    >>
    >> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
    >> index 732162e9d13e..c77be1c20e47 100644
    >> --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
    >> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
    >> @@ -67,24 +67,30 @@ examples:
    >>
    >> /* ... */
    >>
    >> - /* Data cells */
    >> - tsens_calibration: calib@404 {
    >> - reg = <0x404 0x10>;
    >> - };
    >> -
    >> - tsens_calibration_bckp: calib_bckp@504 {
    >> - reg = <0x504 0x11>;
    >> - bits = <6 128>;
    >> - };
    >> -
    >> - pvs_version: pvs-version@6 {
    >> - reg = <0x6 0x2>;
    >> - bits = <7 2>;
    >> - };
    >> -
    >> - speed_bin: speed-bin@c{
    >> - reg = <0xc 0x1>;
    >> - bits = <2 3>;
    >> + nvmem-layout {
    >
    > I believe we should not introduce "intermediate state" bindings when
    > this is not strictly required, in order to avoid confusion with what is
    > backward and what is transitory. So I would expect this to only apply
    > after the switch to:
    >
    > nvmem-layout@xxx {
    > reg = <xxx>;
    >
    > I don't care who will take care of it, but I think it would be better
    > to have everything in one series.
    >
    > Other than the "order" problematic which I think is important here, I
    > agree with this series.

    I fail to see how / why:
    1. Adding new NVMEM layout
    2. Supporting mutliple NVMEM layouts
    would depend on each other.

    We already have 2 NVMEM layouts bindings. I'm just adding a new (third)
    one.

    If having NVMEM layouts bindings puts us in any kind of intermediate
    state then we're already there. I don't think my new NVMEM layout
    changes this situation.


    >> + compatible = "fixed-layout";
    >> + #address-cells = <1>;
    >> + #size-cells = <1>;
    >> +
    >> + /* Data cells */
    >> + tsens_calibration: calib@404 {
    >> + reg = <0x404 0x10>;
    >> + };
    >> +
    >> + tsens_calibration_bckp: calib_bckp@504 {
    >> + reg = <0x504 0x11>;
    >> + bits = <6 128>;
    >> + };
    >> +
    >> + pvs_version: pvs-version@6 {
    >> + reg = <0x6 0x2>;
    >> + bits = <7 2>;
    >> + };
    >> +
    >> + speed_bin: speed-bin@c{
    >> + reg = <0xc 0x1>;
    >> + bits = <2 3>;
    >> + };
    >> };
    >> };

    \
     
     \ /
      Last update: 2023-03-27 00:53    [W:4.838 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site