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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CBB8FC433EF for ; Tue, 28 Sep 2021 13:51:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B0006611BD for ; Tue, 28 Sep 2021 13:51:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240988AbhI1NxG (ORCPT ); Tue, 28 Sep 2021 09:53:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241112AbhI1NxF (ORCPT ); Tue, 28 Sep 2021 09:53:05 -0400 Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25A26C061604 for ; Tue, 28 Sep 2021 06:51:26 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id d21so58067153wra.12 for ; Tue, 28 Sep 2021 06:51:26 -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=Mr2XW/ExcapYxP/Bo4qXwpJMhGFNi4fgDwMu2/rJrI0=; b=ewnHE/tgkUjMvexYV183LLT3n8rtLClqvwmklt30vsDGsH8tqJ5y61zXyv15nUUN4b cMDZzKiREL9qF83rYKrt/iW9E3uiXL5JRKVjKJvgbaHyNofO1LPNxuCXWgdUp7HvRA0D dxFoM21AnRLPgO/KoKN1meyELOTpcl9oYfz7/aFAhTIDOSNhMEh8KzHuRjc7dMTBYNAf bOOkAXBvkbEeIZSsC8LEh9uQBCivo20VUsFiXaZ4Tsaxm80VOZs/l5SQazRUuKx7oQem 0v+kHMSbt2Fd1Jgbj4825V3ArXcGRep6VYz5C2nCK7NnE0bpc9eSqFasPNuca9X8/uuk MeCA== 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=Mr2XW/ExcapYxP/Bo4qXwpJMhGFNi4fgDwMu2/rJrI0=; b=kzPrUFpOCythr/h5XcUH9C9qhnXqzkyU+e+HapYtT9ddrdCb/CicDFRd9duL1GZWdN iHUEmNy3O9Fgq+rZSCWYiRw+AmPbg8nSf7L1SWkixrqJimlUY0/kdyjPioBS4LlE2g7p NgYG9Ksy4JFg9vDCPL0WmrksTbgEslo9XPeRwiiUIaINnzzC9tG8R6kPvdPR4XEKg1Ih gJvXnJTA+lajvL6j8qSq023Rn4lZmJJp1nNq9ydU4760UiigqDoBh8KFmcZIJAWG9ecq 85iE0JTF12Jxll7lCWyU00zMGgXvHRtFlQmW9Yu9yy75Z1z01aSjFrsL9vt5pxcq8TVR A6HA== X-Gm-Message-State: AOAM530iG4+aDKiVnkCIRyN7nlF44lkA+YVAMNzdswjoMKydvhodHAAV +0QgMZhZw4tdv/ba0D0BS2iT2A== X-Google-Smtp-Source: ABdhPJztboiKRs3oQxSHpFkZq5VbHxMvwwnjnApD67goEFd4tgtXRrAnkDVGbYH0U181PZXZgsLkGA== X-Received: by 2002:a05:6000:362:: with SMTP id f2mr82981wrf.197.1632837084740; Tue, 28 Sep 2021 06:51:24 -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 e5sm19777680wrd.1.2021.09.28.06.51.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Sep 2021 06:51:24 -0700 (PDT) Subject: Re: [PATCH v2 1/3] nvmem: core: introduce cells parser To: Vadym Kochan Cc: John Thomson , Rob Herring , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Robert Marko References: <20210608190327.22071-1-vadym.kochan@plvision.eu> <20210608190327.22071-2-vadym.kochan@plvision.eu> <43023500-dd6a-5180-057e-cecc1f1b6500@linaro.org> <20210616123356.GA9951@plvision.eu> <7e6d75ed-cebc-597f-7062-34261d184968@linaro.org> <0e471789-fe29-b747-5153-75c9b4616c7f@linaro.org> <1da03714-8f23-1004-e89a-891e4599e04a@linaro.org> <1e146349-9fef-972b-9084-577f02d5168b@linaro.org> <169d3f36-4297-32a3-3d23-824989625b26@linaro.org> <77b11bf7-3003-483f-b91e-bd93576eaae1@www.fastmail.com> <56fb5c64-4142-03ef-2ea8-fc586fd239e1@linaro.org> From: Srinivas Kandagatla Message-ID: Date: Tue, 28 Sep 2021 14:51:23 +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=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 28/09/2021 14:31, Vadym Kochan wrote: >>>> Can I note here that I would like to parse >>>> TLV data from an SPI-NOR device to NVMEM cells. >>>> The same general use case (getting mac-address from OEM data). >>>> >>>> Was planning to base my work on this series, as well as >>>> https://lore.kernel.org/all/20210908100257.17833-1-qiangqing.zhang@nxp.com/ >>>> (thanks for pointing that out Srinivas) >>>> >>>> Cheers, >>> What about at least to have just one call in core.c to make it a bit >>> de-coupled, like: >> Why do you want to decouple this? the provider driver should be very >> well aware of the format the data layout. >> > In my understanding nvmem device should not aware about the data layout > (in case it does not rely on device's specific characteristics). Same > cells layout (TLV, etc) might exist on other nvmem devices. > How would provider driver parse this without even knowing data layout? >> Its fine to an extent to adding parse_cells() callback in nvmem_config. >> > OK, in that case it will require small change in the core. > >>> core.c >>> >>> struct nvmem_device *nvmem_register(const struct nvmem_config *config) >>> { >>> ... >>> rval = nvmem_add_cells_from_table(nvmem); >>> if (rval) >>> goto err_remove_cells; >>> >>> + rval = nvmem_parse_cells(nvmem, of); >>> + if (rval) { >>> + /* err handling */ >>> + } >>> + >>> rval = nvmem_add_cells_from_of(nvmem); >>> if (rval) >>> goto err_remove_cells; >>> >>> blocking_notifier_call_chain(&nvmem_notifier, NVMEM_ADD, nvmem); >>> >>> return nvmem; >>> >>> ... >>> >>> } >>> >>> somewhere in nvmem-parser.c: >> However this is totally over kill. >> >>> /* retreive parser name from of_node and call appropriate function to parse >>> non-fixed cells and update via of_update */ >> This is completely provider drivers job, nothing nvmem core should worry >> about. >> >> If you have concern of having code duplicated then we could make some of >> the common functions as library functions, But it still is within the >> scope of provider drivers. >> > Do I understand correctly that this parser function should be exported > from at24.c (in case of ONIE) and not from a separate C module ? Or > it just means that if there will be more users of this parsing function > then it might be moved to separate C module ? yes. For now am not really sure how many users are for such parsing function. > >> --srini >> > BTW, what if such change will be declined by particular nvmem driver > maintainer ? You would need some changes to provider driver to be able to flag that there is some kind of parsing required anyway. --srini >