From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E5E3C433EF for ; Wed, 8 Sep 2021 09:21:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E58ED61104 for ; Wed, 8 Sep 2021 09:21:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351324AbhIHJXE (ORCPT ); Wed, 8 Sep 2021 05:23:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245487AbhIHJXD (ORCPT ); Wed, 8 Sep 2021 05:23:03 -0400 Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B9D10C061575 for ; Wed, 8 Sep 2021 02:21:55 -0700 (PDT) Received: by mail-wr1-x436.google.com with SMTP id b6so2185414wrh.10 for ; Wed, 08 Sep 2021 02:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nS+TQNLnq4FEJNrW462G2s7CfEi1/BnWJvgcmlinvMw=; b=nfUnMZ6OHC8ke4ASEgy8gCYfmyYVY7nHJM9+N/qgyof697LSufnCRly45AJOTSJxUI 0JNGACYMzb8cvQhpbCrBki/HHmxN3S3hFc1jFZ3qG4iHWrus+Gho2aWfUaDRh+E3kenj vckSHv46/ixlOyXU0m7GwfwglB+LuhAo1Aw88j2MAOQReZyLb4R6Rg68/fkk7ZVRBzUU agYXC0oJ8OR3rgGhPwFN2G6qyngDhWQcxHISyMeOT6n+4eL6SrJZf2ZY8hP9v4CUXC9h sggL2EGcXH75bNrCtClJstqPBIl2uw0CmNIhebrQQeC9ZoseIKP+dv70eP3VDrX90NaS 5B4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nS+TQNLnq4FEJNrW462G2s7CfEi1/BnWJvgcmlinvMw=; b=Tjsleuir730HHMWMYfz/RkF0/XcSEDqw801SLKbHj+T3fAZwJe4KgB+VbL2vDJRh7J BFgGG8yX8xAPi3HWE9X22YEB9gLP9jnBpdSr621beuohKNY+L0XREw8GKn3ALnm4+8Sq 59twV/BYtZHu+Abt/JNZdnw1CQFbxsyS7/udCV+gL1d1Ztl7zF+xULH3wFP9eVbFZML/ /eT6ke6+LM+2QOOCliGON5Lfpze8mmN6C4sPVftyv6RzZeEKt5p0ybpd1EA+Hon2CVEK a+rZu24rC/GPOxZLesD13BDCSFrZj1J12bHf7YHZtMa5Dffl3ThT4Y0dqizQTTlOP+44 ZjHA== X-Gm-Message-State: AOAM530x6id6wpR52ZjnBTAOL+kg01a7fqqkJ2DzhBi1RTCh3vPgahAo 6xX7PaGHEF/DCx5P9LFIkvomyg== X-Google-Smtp-Source: ABdhPJwFmMqQoutuscofX3SwHUNi2CAmgGuU86QFaa+fM4Ide7jf3GTZ3a4AvIIEToJFXpQg575F4A== X-Received: by 2002:a5d:6cca:: with SMTP id c10mr2784271wrc.224.1631092914221; Wed, 08 Sep 2021 02:21:54 -0700 (PDT) Received: from [192.168.86.34] (cpc86377-aztw32-2-0-cust226.18-1.cable.virginm.net. [92.233.226.227]) by smtp.googlemail.com with ESMTPSA id k14sm1531223wri.46.2021.09.08.02.21.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Sep 2021 02:21:53 -0700 (PDT) Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data" property To: Joakim Zhang , Rob Herring Cc: "shawnguo@kernel.org" , "kernel@pengutronix.de" , dl-linux-imx , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20210810073510.18218-1-qiangqing.zhang@nxp.com> <20210810073510.18218-2-qiangqing.zhang@nxp.com> <6e3f6881-929d-1663-58f1-39bf35069175@linaro.org> <2ab0b16d-5a22-2abe-e228-c058b5a853ff@linaro.org> From: Srinivas Kandagatla Message-ID: Date: Wed, 8 Sep 2021 10:21:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 08/09/2021 09:57, Joakim Zhang wrote: > > Hi Srinivas, > >> -----Original Message----- >> From: Srinivas Kandagatla >> Sent: 2021Äê9ÔÂ8ÈÕ 16:49 >> To: Joakim Zhang ; Rob Herring >> >> Cc: shawnguo@kernel.org; kernel@pengutronix.de; dl-linux-imx >> ; devicetree@vger.kernel.org; >> linux-kernel@vger.kernel.org >> Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data" >> property >> >> >> >> On 08/09/2021 08:14, Joakim Zhang wrote: >>> >>> Hi Srinivas, >>> >>> [...] >>>> I have pushed some nvmem core patches which are just compile tested >>>> to >>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit >>>> .kern%2F&data=04%7C01%7Cqiangqing.zhang%40nxp.com%7Cb8b85 >> eab6bc34 >>>> >> 917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0% >> 7C6376 >>>> >> 66877370588296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC >> JQIjoiV2 >>>> >> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=diFgK2ufOUK >> eXwd >>>> 0Ez8pCFjCUH8rXz5jfW7io8KDKmw%3D&reserved=0 >>>> >> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Flog% >>>> >> 2F%3Fh%3Dtopic%2Fpost-processing&data=04%7C01%7Cqiangqing.zhan >>>> >> g%40nxp.com%7Cadfa3ba63c634937876308d971e7e71f%7C686ea1d3bc2b4c6 >>>> >> fa92cd99c5c301635%7C0%7C0%7C637666063097239185%7CUnknown%7CT >>>> >> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ >>>> >> XVCI6Mn0%3D%7C1000&sdata=W9yAnGm9rYzlSZuAAGiN4VHUtKYUTt9S >>>> oyGQ9QsY7fI%3D&reserved=0 >>>> >>>> This should provide the callback hook I was talking about. >>> >>> Thanks a lot! Yes, this could be more common, vendors can parse their >>> mac address for different encoding style, also can extend for other cases. >> >> Yes, that is the idea, >>> >>>> Can you take a look at them and let me know if it works for you. >>> >>> There are some small issues need to be update: >>> 1) >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern >> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Fcom >> mit%2F%3Fh%3Dtopic%2Fpost-processing%26id%3D624f2cc99b48bbfe05c11e >> 58fb73f84abb1a646e&data=04%7C01%7Cqiangqing.zhang%40nxp.com% >> 7Cb8b85eab6bc34917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c3 >> 01635%7C0%7C0%7C637666877370598253%7CUnknown%7CTWFpbGZsb3d8e >> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D >> %7C1000&sdata=APDzSbLob%2FRiZyyhU7VAhoUEAmSG95NsilQDQ53Hbf >> A%3D&reserved=0 >>> of_get_property() can't get the cell value, so I change to >>> of_property_read_s32() >>> 2) >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern >> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Fcom >> mit%2F%3Fh%3Dtopic%2Fpost-processing%26id%3Da424302c7b15da41e1e8d >> e56b0c78021b9a96c1e&data=04%7C01%7Cqiangqing.zhang%40nxp.com >> %7Cb8b85eab6bc34917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c >> 301635%7C0%7C0%7C637666877370598253%7CUnknown%7CTWFpbGZsb3d8 >> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D >> %7C1000&sdata=5E49DVzkpBVdkA4a%2B9tMXN%2B6k%2BG%2B3rQuVJ >> qTUgdbmKU%3D&reserved=0 >>> if (!nvmem->cell_post_process) {} should be if (nvmem->cell_post_process) >> {}, if we have this callback, we need do the post-processing. >>> >> I have pushed these changes now to the branch. >> >>>> I have also added some test changes to imx provider driver as well, >>>> which you might have to take a closer look to get it working. >>>> >>>> You need to look at adding/changing two things: >>>> >>>> 1. setting reverse_mac_address flag in imx driver. >>>> Does IMX always has mac-address reversed? if yes then we do not need >>>> any new bindings for imx nvmem provider, if no we might need to add >>>> some kind of flag to indicate this. >>> >>> No, it's depend on how to program the effuse. >>> To avoid introducing consumer property in devicetree, I prefer to move >>> reverse_mac_address flag into ocotp_params struct, since each >>> platforms has their own, it's easy to indicate this. I tried it, and >>> works. > >> >> As long as provider can figure out how the efuse is programmed then it is fine >> with me. >> >> >>>> 2. In imx devicetree for mac-address nvmem cell make sure you add >>>> >>>> cell-type = ; >>>> >>>> >>>> >>>> >>>>> >>>>>> Option 2: nvmem core handles the post processing. >>>>>> >>>>>> Pros: >>>>>> - provider driver does not need to implement callbacks >>>>>> >>>>>> Cons: >>>>>> - We have to find a way to define vendor specific non-standard >>>>>> encoding information in generic bindings which is going to be a >>>>>> challenge and high chance of ending up in to much of clutter in generic >>>> bindings. >>>>>> >>>>>> Finally, The way I look at this is that once we start adding >>>>>> post-processing in nvmem core then we might endup with code that will >>>>>> not be really used for most of the usecases and might endup with >>>>>> cases that might not be possible to handle in the core. >>>>>> >>>>>> >>>>>> Does Option 1 work for you? >>>>> >>>>> Yes, I also prefer to implement it in specific driver, as you mention >>>>> above, these code are for very rarely use cases. >>>>> >>>>> If we chose Option 1, I want to implement it totally in specific >>>>> driver(imx-ocotp.c), and I have a draft, could it be acdeptable? >>>> Yes, this is the direction, however we need a proper callback to do this. And >>>> offset information is still comes from Device tree. >>>> >>>> >>>> Have a look at the patches pushed into topic/post-processing branch. >>> >>> I have improved this patch set according above comments and tested it. Also >> rebase to >>> the nvmem/for-next branch. >>> >>> I plan to keep you as the nvmem part author and send out this patch set with >> dts changes. If it's fine for you? >> >> Yes please, can you pick the new patches from the branch before you send >> the series out. > > As you define the type variable is "int", so had better use of_property_read_s32(), instead if of_property_read_u32(), right? We should probably make that u32, as we are not expecting any negative range. I tried to fix this in new patches. --srini > > Best Regards, > Joakim Zhang >