Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2616864ybk; Mon, 18 May 2020 03:47:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNlm/eoz8d5usXqIKcOfuZevlTYpHEKROTfBFME/8Ap4eeMe00/kiFQ5tYtj8WT2IJ1E44 X-Received: by 2002:a17:906:b08c:: with SMTP id x12mr12890655ejy.154.1589798838779; Mon, 18 May 2020 03:47:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589798838; cv=none; d=google.com; s=arc-20160816; b=iJDbHNwkHc5T0F2f6FIXCdWIufKMLRhy4K3POmF6KcoxbKDRSuF+GHDab8BhrvSyL5 +vP83Njwn1ixaDPR8qDzNhi7e3n4EX0iOVOGvDXzH7aHgCUTq1oojcgCAdRVK7H1Jhj/ mYuq1OrHAem+oO7aEYkec+Uy78tTacl2HrRZDeCvxFF51FRj8chN543UoDniNVrHfFrG tfDVpikGevyNgmWWliUMYrbqG7RVutFlbIqE1g8rCdZVg+Pjdi7226Of81rhE5HEqRYi 4sdiAYnzzGpMZmaDAOtkTHK27HmOKvoE1y/WjrhIQohwboYRUvJ7/OTD025PHLyFsttI F5qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=hE6kxSlc/mEJ+YZKX8B1+sByxpuTTLbhqigf1AXAxVw=; b=E3KrpzxS5ao6/OeMkB7F2Qy8TJLYEapxaCrfcqeNTS5HgL89+9S1HEc/0UwtgSeOrq 9E14XPvgpz/55jRMwjCpJWiJV9NiRBngceM+Pg/ULLmLx+QxwxGftsB6FUMsVKblY9He YzZxpGSEYbHCslDmjBUfUjPhIQiIgn+uWi88y2xHXbqCtts5lWVDsCmVqt5yICGwZlji w7bXpiTHz6TOsN0SCYi/MF6E/CiBqsTe5maIK4g4Ite0tYyzYjjgLIzTJRupJNlK2KyQ +bUJ6YXEbXncgVyHt3bkbOMfamjTMmbgucsOwF6kNGEK9mUEPAmZ75aB9WjOf1cJsby2 oxWw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="hYc/PMH+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y31si6349397ede.507.2020.05.18.03.46.55; Mon, 18 May 2020 03:47:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="hYc/PMH+"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726560AbgERKpC (ORCPT + 99 others); Mon, 18 May 2020 06:45:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726302AbgERKpB (ORCPT ); Mon, 18 May 2020 06:45:01 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5636BC05BD09 for ; Mon, 18 May 2020 03:45:00 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id l17so11263562wrr.4 for ; Mon, 18 May 2020 03:45:00 -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=hE6kxSlc/mEJ+YZKX8B1+sByxpuTTLbhqigf1AXAxVw=; b=hYc/PMH+QFxVF4H286qlDXrAO66M1kONtHWhqYKGHxITlJODYwexD7Xsjow3VJ1R1a cG/pRhf1ZghXtPCPbEJqHi9Qt1sLok0yTiFZmNxf4vP7ZdD2C6F4hvmVB6lC2AKGedaX wqgo18ftlCSOoCZJ2tjpT2gnrhEOVLab/ZxgKjAe4qT+f84bg0YehgHC2bP43GmaDM5h QNSpahnlU9Afm5EtPmBFTk3WWZku1PEx6iozm6zK2VmNqK5puae3YgeNYiQfVnvzfWXj ebS6GhnpqCC/oGgIDzOdqI+QJKFWRmdX1Iu/wHLI9s3PeEDbMSLcjxzZPU1zPzuBjgyv cKHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=hE6kxSlc/mEJ+YZKX8B1+sByxpuTTLbhqigf1AXAxVw=; b=qwzb6ewdmaCu5rvu2ZxCUn/+H1UcXGYWZukYIt8y+49N46PyAUKM1p5w0JJVc5n5Fj ialT4SzfEea6l0+P1+HBJrNT6Y3gxxisvW5IfdswdGmPvEuOVjMSf1em/Ly4LEJp4Ora uqOUaF1a04G7tGtWllW3MRKRGyX0IwENozqoS2VJX6nENhOEeoCy47fxptjlYfpgsCKK DF5oYQk4mrHf0Mah38Zro9LWZ4I3DqsQx65kdpiAuVYBS0jIkVakRK5e6Bo/jf9lo90D A0VyhJVi1xUbGi5Mdw2oV47CpL8x49gekt/4ZFyxfr3n6Mbm+QoQT+kVyKKuuCTGRedh IpqA== X-Gm-Message-State: AOAM533VXS31C4G3SHeptelYb016fOxfKOmvLThDc4SaHzTIFay2jiDY q3LTJ03xVFUg/+H7lut3CTWfow== X-Received: by 2002:adf:fa47:: with SMTP id y7mr18123438wrr.337.1589798698943; Mon, 18 May 2020 03:44:58 -0700 (PDT) Received: from [192.168.86.34] (cpc89974-aztw32-2-0-cust43.18-1.cable.virginm.net. [86.30.250.44]) by smtp.googlemail.com with ESMTPSA id d6sm17201443wra.63.2020.05.18.03.44.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2020 03:44:58 -0700 (PDT) Subject: Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support To: "Ravi Kumar Bokka (Temp)" , Rob Herring Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, rnayak@codeaurora.org, saiprakash.ranjan@codeaurora.org, dhavalp@codeaurora.org, mturney@codeaurora.org, sparate@codeaurora.org, c_rbokka@codeaurora.org, mkurumel@codeaurora.org, dianders@chromium.org References: <1589307480-27508-1-git-send-email-rbokka@codeaurora.org> <1589307480-27508-3-git-send-email-rbokka@codeaurora.org> <14e1fa51-066c-6e1b-01a4-2103612de9e9@codeaurora.org> From: Srinivas Kandagatla Message-ID: Date: Mon, 18 May 2020 11:44:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/05/2020 11:39, Ravi Kumar Bokka (Temp) wrote: >> > > Based on the compatible, do i need to separate probe function for > qfprom-efuse and maintain separate nvmem object to register nvmem > framework. Is this what you are suggesting to implementing this in to > one existing driver? Yes for same driver we should add new compatible string and add support to this in existing qfprom driver. Ideally we should allocate nvmem_config object at probe with different parameters based on compatible string. > Do I need to maintain separate efuse dt node? Not sure what you mean this w.r.t driver, but based on compatible string the device tree bindings might vary like clocks, regulators and so on. --srini > > Could you please suggest me to proceed further.