From patchwork Sat Mar 6 00:26:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 394612 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable 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 83527C43381 for ; Sat, 6 Mar 2021 00:27:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 488F365081 for ; Sat, 6 Mar 2021 00:27:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229669AbhCFA0u (ORCPT ); Fri, 5 Mar 2021 19:26:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49800 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229493AbhCFA0m (ORCPT ); Fri, 5 Mar 2021 19:26:42 -0500 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 120D5C06175F for ; Fri, 5 Mar 2021 16:26:42 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id p21so2449537pgl.12 for ; Fri, 05 Mar 2021 16:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=8ioBMuO2igmW4BL3UDTs4zCq3jWXemfM9CQDn/Vb8qk=; b=UyTGutIQgvDw9NddvZT0M7jm5lw13e0rBcAmuLOdh3y4WLpcn4DrE6HTXb05d4kvR2 3XeS6Bcm7gGno8lDvUbVR5XVvi094lQUPwpTS090oK7/Zg4dxdjyENdH3TzXZz86Yle9 1oTDF7ZSjLvj3n26VdEQRPL31+foAmo7vLHaM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=8ioBMuO2igmW4BL3UDTs4zCq3jWXemfM9CQDn/Vb8qk=; b=oLLV/xiEDKHAWbWNA8ZkaZqEcq+g+8ES3P4O/ovz0nNoZrt/amMcjZ4IFzbDj0mcbd VSCFOUqVN8xdMRu62mSS0ZDSwqpppsQvUdG3tP9vw0C5eDtyDfV/Gq/rUocraaigD/7R ABxCOqCf19YZQP8RGbfjr4UNLxD9Xy+rH3Ak4WXDrp12NO2t+JKJen2A6VfS7Egh232O nCq+U/oOw/GCPqD9wvNCTNMHto+Md590Sg9G998WGscQSsIHbl0XtTWobxwYVfZXBuBp NB2PmKZEJ66D7+H+Jbt//aNbB5HfoHq1zPoW06pC9qY7z/HmPHNy2IiWDYicroPXKIuu ehSw== X-Gm-Message-State: AOAM530SStaNUHvxo4KI8AldAGPWiFAHGV59xRM3D3XgHnbzLkO2+lzP gXH5cW7gz5dle03i34SAxQaBAg== X-Google-Smtp-Source: ABdhPJxIuI1xVSWldNRPbKE21vi/oPh7r05GVS2zHYb//NYvqS5YxTPZ0GeqWuTUjzMikt0VX32vgg== X-Received: by 2002:a62:87c3:0:b029:1ee:761:bb33 with SMTP id i186-20020a6287c30000b02901ee0761bb33mr11367606pfe.52.1614990401431; Fri, 05 Mar 2021 16:26:41 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:48f0:8f48:7388:d921]) by smtp.gmail.com with ESMTPSA id 192sm3608905pfa.122.2021.03.05.16.26.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Mar 2021 16:26:40 -0800 (PST) From: Douglas Anderson To: "Rafael J . Wysocki" , Rob Clark , Jordan Crouse Cc: Ulf Hansson , Niklas Cassel , Jorge Ramirez-Ortiz , swboyd@chromium.org, linux-arm-msm@vger.kernel.org, Bjorn Andersson , Akhil P Oommen , Douglas Anderson , Srinivas Kandagatla , linux-kernel@vger.kernel.org Subject: [PATCH 1/3] nvmem: core: Add functions to make number reading easy Date: Fri, 5 Mar 2021 16:26:20 -0800 Message-Id: <20210305162546.1.I323dad4343256b48af2be160b84b1e87985cc9be@changeid> X-Mailer: git-send-email 2.30.1.766.gb4fecdf3b7-goog MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Sometimes the clients of nvmem just want to get a number out of nvmem. They don't want to think about exactly how many bytes the nvmem cell took up. They just want the number. Let's make it easy. In general this concept is useful because nvmem space is precious and usually the fewest bits are allocated that will hold a given value on a given system. However, even though small numbers might be fine on one system that doesn't mean that logically the number couldn't be bigger. Imagine nvmem containing a max frequency for a component. On one system perhaps that fits in 16 bits. On another system it might fit in 32 bits. The code reading this number doesn't care--it just wants the number. We'll provide two functions: nvmem_cell_read_variable_le_u32() and nvmem_cell_read_variable_le_u64(). Comparing these to the existing functions like nvmem_cell_read_u32(): * These new functions have no problems if the value was stored in nvmem in fewer bytes. It's OK to use these function as long as the value stored will fit in 32-bits (or 64-bits). * These functions avoid problems that the earlier APIs had with bit offsets. For instance, you can't use nvmem_cell_read_u32() to read a value has nbits=32 and bit_offset=4 because the nvmem cell must be at least 5 bytes big to hold this value. The new API accounts for this and works fine. * These functions make it very explicit that they assume that the number was stored in little endian format. The old functions made this assumption whenever bit_offset was non-zero (see nvmem_shift_read_buffer_in_place()) but didn't whenever the bit_offset was zero. NOTE: it's assumed that we don't need an 8-bit or 16-bit version of this function. The 32-bit version of the function can be used to read 8-bit or 16-bit data. At the moment, I'm only adding the "unsigned" versions of these functions, but if it ends up being useful someone could add a "signed" version that did 2's complement sign extension. At the moment, I'm only adding the "little endian" versions of these functions. Adding the "big endian" version would require adding "big endian" support to nvmem_shift_read_buffer_in_place(). Signed-off-by: Douglas Anderson Reviewed-by: Srinivas Kandagatla --- This is a logical follow-up to: https://lore.kernel.org/r/20210227002603.3260599-1-dianders@chromium.org/ ...but since it doesn't really share any of the same patches I'm not marking it as a v2. drivers/nvmem/core.c | 95 ++++++++++++++++++++++++++++++++++ include/linux/nvmem-consumer.h | 4 ++ 2 files changed, 99 insertions(+) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index a5ab1e0c74cf..635e3131eb5f 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -1606,6 +1606,101 @@ int nvmem_cell_read_u64(struct device *dev, const char *cell_id, u64 *val) } EXPORT_SYMBOL_GPL(nvmem_cell_read_u64); +static void *nvmem_cell_read_variable_common(struct device *dev, + const char *cell_id, + size_t max_len, size_t *len) +{ + struct nvmem_cell *cell; + int nbits; + void *buf; + + cell = nvmem_cell_get(dev, cell_id); + if (IS_ERR(cell)) + return cell; + + nbits = cell->nbits; + buf = nvmem_cell_read(cell, len); + nvmem_cell_put(cell); + if (IS_ERR(buf)) + return buf; + + /* + * If nbits is set then nvmem_cell_read() can significantly exaggerate + * the length of the real data. Throw away the extra junk. + */ + if (nbits) + *len = DIV_ROUND_UP(nbits, 8); + + if (*len > max_len) { + kfree(buf); + return ERR_PTR(-ERANGE); + } + + return buf; +} + +/** + * nvmem_cell_read_variable_le_u32() - Read up to 32-bits of data as a little endian number. + * + * @dev: Device that requests the nvmem cell. + * @cell_id: Name of nvmem cell to read. + * @val: pointer to output value. + * + * Return: 0 on success or negative errno. + */ +int nvmem_cell_read_variable_le_u32(struct device *dev, const char *cell_id, + u32 *val) +{ + size_t len; + u8 *buf; + int i; + + buf = nvmem_cell_read_variable_common(dev, cell_id, sizeof(*val), &len); + if (IS_ERR(buf)) + return PTR_ERR(buf); + + /* Copy w/ implicit endian conversion */ + *val = 0; + for (i = 0; i < len; i++) + *val |= buf[i] << (8 * i); + + kfree(buf); + + return 0; +} +EXPORT_SYMBOL_GPL(nvmem_cell_read_variable_le_u32); + +/** + * nvmem_cell_read_variable_le_u64() - Read up to 64-bits of data as a little endian number. + * + * @dev: Device that requests the nvmem cell. + * @cell_id: Name of nvmem cell to read. + * @val: pointer to output value. + * + * Return: 0 on success or negative errno. + */ +int nvmem_cell_read_variable_le_u64(struct device *dev, const char *cell_id, + u64 *val) +{ + size_t len; + u8 *buf; + int i; + + buf = nvmem_cell_read_variable_common(dev, cell_id, sizeof(*val), &len); + if (IS_ERR(buf)) + return PTR_ERR(buf); + + /* Copy w/ implicit endian conversion */ + *val = 0; + for (i = 0; i < len; i++) + *val |= buf[i] << (8 * i); + + kfree(buf); + + return 0; +} +EXPORT_SYMBOL_GPL(nvmem_cell_read_variable_le_u64); + /** * nvmem_device_cell_read() - Read a given nvmem device and cell * diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h index 052293f4cbdb..923dada24eb4 100644 --- a/include/linux/nvmem-consumer.h +++ b/include/linux/nvmem-consumer.h @@ -65,6 +65,10 @@ int nvmem_cell_read_u8(struct device *dev, const char *cell_id, u8 *val); int nvmem_cell_read_u16(struct device *dev, const char *cell_id, u16 *val); int nvmem_cell_read_u32(struct device *dev, const char *cell_id, u32 *val); int nvmem_cell_read_u64(struct device *dev, const char *cell_id, u64 *val); +int nvmem_cell_read_variable_le_u32(struct device *dev, const char *cell_id, + u32 *val); +int nvmem_cell_read_variable_le_u64(struct device *dev, const char *cell_id, + u64 *val); /* direct nvmem device read/write interface */ struct nvmem_device *nvmem_device_get(struct device *dev, const char *name); From patchwork Sat Mar 6 00:26:21 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 395185 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT 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 5842FC433E6 for ; Sat, 6 Mar 2021 00:27:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1BDE965009 for ; Sat, 6 Mar 2021 00:27:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229637AbhCFA0u (ORCPT ); Fri, 5 Mar 2021 19:26:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229616AbhCFA0o (ORCPT ); Fri, 5 Mar 2021 19:26:44 -0500 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EDACFC061760 for ; Fri, 5 Mar 2021 16:26:43 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id g4so2445710pgj.0 for ; Fri, 05 Mar 2021 16:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=SnpC6f7BpJ8tZNLRp5Cw3z8Kw07+oTU7VTtXi15iO+E=; b=jq1Lw6tgvNAk9hkISI/vE38aIwoYVIf0ldffXAOzjjMLMAFsY1E1xwsn5sYNYhJMXv w+f+/HJ96aPz1nGb/W0K4TmbIx1yzm+KrATFMa5hlXh7tqsf2F9sdUJOVcnJ8AetWJAY frywgkx4ti1iVC19r6plKwgpfS8LySG8CkUb4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SnpC6f7BpJ8tZNLRp5Cw3z8Kw07+oTU7VTtXi15iO+E=; b=dCyz1A9iYX4ygkhLsoZ4nur5KfsgmSKlFsRV/MB+csrDCsYBkVZhyh7AMwaMHpCrOc FGwdi101RRV96YDpUVxkQY5StciQOKzaI8FPwIiwovnxj/aWard/SU/jb4DGrlZ/1KTQ cOnFpFhAlT4mLjT/ikCVUPQrotPKxE/aX7vkHHmlBsAKKv+0kedzAZGsmgh20Bx5xVRd 1xyuLMdznbiFLZwJHRJGf8ebYTeQ3tjWg7jc7i4XlvgOGYEnGPR+pL6KYPu5+Z9mj2As KoYObeF7tsvCpzC4MI3An/GaIgkRTlTcyGewySNF/qhdsJp5xGIVwXkMbqAGXgYNpdlk 0Txg== X-Gm-Message-State: AOAM530LRa5jsffPocPwMQLuqsiu1C+61D4/4hI2vK6th5yn86UwcCAd DpXBSsNA0lDiHlx3cdzVMDC6MA== X-Google-Smtp-Source: ABdhPJzBIFwqkw60RxxzGbz2ZZTXuBOwt5iqDwSUgfGViCIoDu5mwu/y3DnzPCgRutYL0MesqDnn2Q== X-Received: by 2002:a63:cf06:: with SMTP id j6mr10633599pgg.195.1614990403493; Fri, 05 Mar 2021 16:26:43 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:48f0:8f48:7388:d921]) by smtp.gmail.com with ESMTPSA id 192sm3608905pfa.122.2021.03.05.16.26.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Mar 2021 16:26:42 -0800 (PST) From: Douglas Anderson To: "Rafael J . Wysocki" , Rob Clark , Jordan Crouse Cc: Ulf Hansson , Niklas Cassel , Jorge Ramirez-Ortiz , swboyd@chromium.org, linux-arm-msm@vger.kernel.org, Bjorn Andersson , Akhil P Oommen , Douglas Anderson , Daniel Vetter , David Airlie , Eric Anholt , Jonathan Marek , Sai Prakash Ranjan , Sean Paul , Sharat Masetty , dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/3] drm/msm: Use nvmem_cell_read_variable_le_u32() to read speed bin Date: Fri, 5 Mar 2021 16:26:21 -0800 Message-Id: <20210305162546.2.Id496c6fea0cb92ff6ea8ef1faf5d468eb09465e3@changeid> X-Mailer: git-send-email 2.30.1.766.gb4fecdf3b7-goog In-Reply-To: <20210305162546.1.I323dad4343256b48af2be160b84b1e87985cc9be@changeid> References: <20210305162546.1.I323dad4343256b48af2be160b84b1e87985cc9be@changeid> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Let's use the newly-added nvmem_cell_read_variable_le_u32() to future proof ourselves a little bit. Signed-off-by: Douglas Anderson --- This is based on my previous patch ("drm/msm: Fix speed-bin support not to access outside valid memory") which has already landed in msm-next. In case it's not obvious, this patch has a strong dependency on my previous patch and also on patch #1 in this series. drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index 0e2024defd79..e34705d17559 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1351,17 +1351,16 @@ static int a6xx_set_supported_hw(struct device *dev, struct a6xx_gpu *a6xx_gpu, { struct opp_table *opp_table; u32 supp_hw = UINT_MAX; - u16 speedbin; + u32 speedbin; int ret; - ret = nvmem_cell_read_u16(dev, "speed_bin", &speedbin); + ret = nvmem_cell_read_variable_le_u32(dev, "speed_bin", &speedbin); if (ret) { DRM_DEV_ERROR(dev, "failed to read speed-bin (%d). Some OPPs may not be supported by hardware", ret); goto done; } - speedbin = le16_to_cpu(speedbin); supp_hw = fuse_to_supp_hw(dev, revn, speedbin); From patchwork Sat Mar 6 00:26:22 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 394613 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=-18.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER, INCLUDES_PATCH, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT 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 DD0ACC433DB for ; Sat, 6 Mar 2021 00:27:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AE2536507C for ; Sat, 6 Mar 2021 00:27:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229701AbhCFA0v (ORCPT ); Fri, 5 Mar 2021 19:26:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229642AbhCFA0p (ORCPT ); Fri, 5 Mar 2021 19:26:45 -0500 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7129CC061760 for ; Fri, 5 Mar 2021 16:26:45 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id g4so2445746pgj.0 for ; Fri, 05 Mar 2021 16:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=NS5Lxo9BxfuP6QZPK99yTL5xf7oG57S72PW7587sqTc=; b=OF6iKVvJm7nV+Gc6VzMBqvRN+neWOeuyd6iZR7wU09QDxn7EQnsj7+mPPzIhA1gFfz qXUN0tIMY34ELyjVsu3NaI/MfTZe+jt4+rQDRc7hFeve/QQCJvijj4rI3wZggNfn7cAN mUSGSDyOoEsAOQOwwLa3CtWnXCMsWKzKOJAaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=NS5Lxo9BxfuP6QZPK99yTL5xf7oG57S72PW7587sqTc=; b=fx3705d3EBAEk+R8NicDPl3ECnfVB3ZSgKimtEdl5CuD3gF39/ucMKmHQHrLzyg6Zc Lw5RxQ42mm2TqiANjn7jtwsMrur2Ezx8vJVD1AioxFoinxqLpPhjNmJrWajAeqTaRAqw 0jLtsdopdjlKJ6fpFIQdcyeXJk7aueSvfuDCLGYLuN2DNyPng7sKm8Nb+gyIsJxv6tEH qxf0/bOpsKwyZ0Y65kEyHEYyL/b68ojsVNXu1eiJjxOTIrdtvsU81HBefoEKDIsS37Km JMPzHcjvXudf81JXKYXY6Uc3wCsztEjIulSddyaDqCL6hGU+ObH95f0Re86V3p0g/+W+ wTFQ== X-Gm-Message-State: AOAM532meMbkTAyQcP2dGyhFVQRFuYJMyBnaHUk47lwmOIE6n3dnZA2m BdHLGtbNJbwlXd+nRQjcxsrFsQ== X-Google-Smtp-Source: ABdhPJwYNoTKdPo4SqwlHiwi1KRPqS0VHMbOkjyM8E0HzhGRyeLI+96z4eeI1IbBhhONP/H+U667ow== X-Received: by 2002:a63:5c1e:: with SMTP id q30mr10501289pgb.259.1614990404968; Fri, 05 Mar 2021 16:26:44 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:48f0:8f48:7388:d921]) by smtp.gmail.com with ESMTPSA id 192sm3608905pfa.122.2021.03.05.16.26.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Mar 2021 16:26:44 -0800 (PST) From: Douglas Anderson To: "Rafael J . Wysocki" , Rob Clark , Jordan Crouse Cc: Ulf Hansson , Niklas Cassel , Jorge Ramirez-Ortiz , swboyd@chromium.org, linux-arm-msm@vger.kernel.org, Bjorn Andersson , Akhil P Oommen , Douglas Anderson , Andy Gross , Niklas Cassel , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [PATCH 3/3] PM: AVS: qcom-cpr: Use nvmem_cell_read_variable_le_u32() Date: Fri, 5 Mar 2021 16:26:22 -0800 Message-Id: <20210305162546.3.Id1c70158722750aec0673d60c12e46a9c66bbfed@changeid> X-Mailer: git-send-email 2.30.1.766.gb4fecdf3b7-goog In-Reply-To: <20210305162546.1.I323dad4343256b48af2be160b84b1e87985cc9be@changeid> References: <20210305162546.1.I323dad4343256b48af2be160b84b1e87985cc9be@changeid> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Let's delete the private function cpr_read_efuse() since it does the basically the same thing as the new API call nvmem_cell_read_variable_le_u32(). Differences between the new API call and the old private function: * less error printing (I assume this is OK). * will give an error if the value doesn't fit in 32-bits (the old code would have truncated silently). Signed-off-by: Douglas Anderson --- I haven't done any more than compile-test this. Mostly I'm just writing this patch because it helped provide inspiration for the general API function. drivers/soc/qcom/cpr.c | 43 +++++------------------------------------- 1 file changed, 5 insertions(+), 38 deletions(-) diff --git a/drivers/soc/qcom/cpr.c b/drivers/soc/qcom/cpr.c index b24cc77d1889..4ce8e816154f 100644 --- a/drivers/soc/qcom/cpr.c +++ b/drivers/soc/qcom/cpr.c @@ -801,38 +801,6 @@ static int cpr_set_performance_state(struct generic_pm_domain *domain, return ret; } -static int cpr_read_efuse(struct device *dev, const char *cname, u32 *data) -{ - struct nvmem_cell *cell; - ssize_t len; - char *ret; - int i; - - *data = 0; - - cell = nvmem_cell_get(dev, cname); - if (IS_ERR(cell)) { - if (PTR_ERR(cell) != -EPROBE_DEFER) - dev_err(dev, "undefined cell %s\n", cname); - return PTR_ERR(cell); - } - - ret = nvmem_cell_read(cell, &len); - nvmem_cell_put(cell); - if (IS_ERR(ret)) { - dev_err(dev, "can't read cell %s\n", cname); - return PTR_ERR(ret); - } - - for (i = 0; i < len; i++) - *data |= ret[i] << (8 * i); - - kfree(ret); - dev_dbg(dev, "efuse read(%s) = %x, bytes %zd\n", cname, *data, len); - - return 0; -} - static int cpr_populate_ring_osc_idx(struct cpr_drv *drv) { @@ -843,8 +811,7 @@ cpr_populate_ring_osc_idx(struct cpr_drv *drv) int ret; for (; fuse < end; fuse++, fuses++) { - ret = cpr_read_efuse(drv->dev, fuses->ring_osc, - &data); + ret = nvmem_cell_read_variable_le_u32(drv->dev, fuses->ring_osc, &data); if (ret) return ret; fuse->ring_osc_idx = data; @@ -863,7 +830,7 @@ static int cpr_read_fuse_uV(const struct cpr_desc *desc, u32 bits = 0; int ret; - ret = cpr_read_efuse(drv->dev, init_v_efuse, &bits); + ret = nvmem_cell_read_variable_le_u32(drv->dev, init_v_efuse, &bits); if (ret) return ret; @@ -932,7 +899,7 @@ static int cpr_fuse_corner_init(struct cpr_drv *drv) } /* Populate target quotient by scaling */ - ret = cpr_read_efuse(drv->dev, fuses->quotient, &fuse->quot); + ret = nvmem_cell_read_variable_le_u32(drv->dev, fuses->quotient, &fuse->quot); if (ret) return ret; @@ -1001,7 +968,7 @@ static int cpr_calculate_scaling(const char *quot_offset, prev_fuse = fuse - 1; if (quot_offset) { - ret = cpr_read_efuse(drv->dev, quot_offset, "_diff); + ret = nvmem_cell_read_variable_le_u32(drv->dev, quot_offset, "_diff); if (ret) return ret; @@ -1701,7 +1668,7 @@ static int cpr_probe(struct platform_device *pdev) * initialized after attaching to the power domain, * since it depends on the CPU's OPP table. */ - ret = cpr_read_efuse(dev, "cpr_fuse_revision", &cpr_rev); + ret = nvmem_cell_read_variable_le_u32(dev, "cpr_fuse_revision", &cpr_rev); if (ret) return ret;