From patchwork Sat Feb 27 00:26:01 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Douglas Anderson X-Patchwork-Id: 12107477 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, 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 AB9E4C433DB for ; Sat, 27 Feb 2021 00:27:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 687EC64E20 for ; Sat, 27 Feb 2021 00:27:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230019AbhB0A1O (ORCPT ); Fri, 26 Feb 2021 19:27:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229745AbhB0A1H (ORCPT ); Fri, 26 Feb 2021 19:27:07 -0500 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11F93C061786 for ; Fri, 26 Feb 2021 16:26:27 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id 17so6142094pli.10 for ; Fri, 26 Feb 2021 16:26:27 -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=R/UVGg/ISF601pQ44Q+AW/V2c0aA7uu1NXfRGhEzBS0=; b=keTd5zYbqA9gwk4Uaro+3JqZ9872UDO1JsC80/jsTJxIsyuig3TVI/q4lNsDYk5ftd S7N6YBXAhQY7hlWOxjTl0Iic+WFw/i+v7dcGsQzxxBJR8GHd/DbPSSg5Kq9uFsXdrs2/ L+etcLD4oHplqJ3hp7Wo1d4Tepqr7omII7sT8= 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=R/UVGg/ISF601pQ44Q+AW/V2c0aA7uu1NXfRGhEzBS0=; b=l4HUOX36BxYYGxEDP6dh7r9qV5z+bIYgZiK9KMpwbwRp2HShmPE1Y8owP/paTaKJ6O ytvMwpRkrS45/AK3WLkRg+UXABpzEDK4lIHZVLT/92VALTgQf/Q5ab3Hu0zU+9gymwis rd3ZFraW9TxQv38Cm6xyj8BS1/odBIUiBUQ4VW8bF+MKb1PB3RiIHlRUeVJIFOV7OgvY Qqf7Mdy1Ft/8kaxef8FvPQOSkytyihefXwnbXAwYZnnl2Yo3e9EmhaxS0WJlcfEVDPYR /nBit6o4e/HxWTGHnwJDouSps+L5ZC1vmf8l5g6e5L06o2FfIdk9qDjtHlP/3RdHnuWK dfZQ== X-Gm-Message-State: AOAM532PeQUI2aJp2+oA3DNsQFlDrwOSlXfJNh1NQv5Ai010FG+fq98j qmQMBT22EVLdWS3c3zullr54yw== X-Google-Smtp-Source: ABdhPJzIq2C5D14QoUWkzHAZD2YlxQuywims+rrfXXpNGQ/xXi+aZQWAi1bXsvy4+Ten03V0eUsjgA== X-Received: by 2002:a17:90b:1c03:: with SMTP id oc3mr6085295pjb.124.1614385586622; Fri, 26 Feb 2021 16:26:26 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:7525:b50:4b48:1a6d]) by smtp.gmail.com with ESMTPSA id t6sm9793744pgp.57.2021.02.26.16.26.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Feb 2021 16:26:25 -0800 (PST) From: Douglas Anderson To: Rob Clark , Jordan Crouse Cc: Niklas Cassel , Ulf Hansson , Bjorn Andersson , swboyd@chromium.org, linux-arm-msm@vger.kernel.org, Akhil P Oommen , Jorge Ramirez-Ortiz , 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 1/3] drm/msm: Fix speed-bin support not to access outside valid memory Date: Fri, 26 Feb 2021 16:26:01 -0800 Message-Id: <20210226162521.1.Ib5ae69a80704c3a2992100b9b5bac1a6cc470249@changeid> X-Mailer: git-send-email 2.30.1.766.gb4fecdf3b7-goog In-Reply-To: <20210227002603.3260599-1-dianders@chromium.org> References: <20210227002603.3260599-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org When running the latest kernel on an sc7180 with KASAN I got this splat: BUG: KASAN: slab-out-of-bounds in a6xx_gpu_init+0x618/0x644 Read of size 4 at addr ffffff8088f36100 by task kworker/7:1/58 CPU: 7 PID: 58 Comm: kworker/7:1 Not tainted 5.11.0+ #3 Hardware name: Google Lazor (rev1 - 2) with LTE (DT) Workqueue: events deferred_probe_work_func Call trace: dump_backtrace+0x0/0x3a8 show_stack+0x24/0x30 dump_stack+0x174/0x1e0 print_address_description+0x70/0x2e4 kasan_report+0x178/0x1bc __asan_report_load4_noabort+0x44/0x50 a6xx_gpu_init+0x618/0x644 adreno_bind+0x26c/0x438 This is because the speed bin is defined like this: gpu_speed_bin: gpu_speed_bin@1d2 { reg = <0x1d2 0x2>; bits = <5 8>; }; As you can see the "length" is 2 bytes. That means that the nvmem subsystem allocates only 2 bytes. The GPU code, however, was casting the pointer allocated by nvmem to a (u32 *) and dereferencing. That's not so good. Let's fix this to just use the nvmem_cell_read_u16() accessor function which simplifies things and also gets rid of the splat. Let's also put an explicit conversion from little endian in place just to make things clear. The nvmem subsystem today is assuming little endian and this makes it clear. Specifically, the way the above sc7180 cell is interpreted: NVMEM: +--------+--------+--------+--------+--------+ | ...... | 0x1d3 | 0x1d2 | ...... | 0x000 | +--------+--------+--------+--------+--------+ ^ ^ msb lsb You can see that the least significant data is at the lower address which is little endian. NOTE: someone who is truly paying attention might wonder about me picking the "u16" version of this accessor instead of the "u8" (since the value is 8 bits big) or the u32 version (just for fun). At the moment you need to pick the accessor that exactly matches the length the cell was specified as in the device tree. Hopefully future patches to the nvmem subsystem will fix this. Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu") Signed-off-by: Douglas Anderson --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++++++-------------------- 1 file changed, 8 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index ba8e9d3cf0fe..0e2024defd79 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -1350,35 +1350,20 @@ static int a6xx_set_supported_hw(struct device *dev, struct a6xx_gpu *a6xx_gpu, u32 revn) { struct opp_table *opp_table; - struct nvmem_cell *cell; u32 supp_hw = UINT_MAX; - void *buf; - - cell = nvmem_cell_get(dev, "speed_bin"); - /* - * -ENOENT means that the platform doesn't support speedbin which is - * fine - */ - if (PTR_ERR(cell) == -ENOENT) - return 0; - else if (IS_ERR(cell)) { - DRM_DEV_ERROR(dev, - "failed to read speed-bin. Some OPPs may not be supported by hardware"); - goto done; - } + u16 speedbin; + int ret; - buf = nvmem_cell_read(cell, NULL); - if (IS_ERR(buf)) { - nvmem_cell_put(cell); + ret = nvmem_cell_read_u16(dev, "speed_bin", &speedbin); + if (ret) { DRM_DEV_ERROR(dev, - "failed to read speed-bin. Some OPPs may not be supported by hardware"); + "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, *((u32 *) buf)); - - kfree(buf); - nvmem_cell_put(cell); + supp_hw = fuse_to_supp_hw(dev, revn, speedbin); done: opp_table = dev_pm_opp_set_supported_hw(dev, &supp_hw, 1); From patchwork Sat Feb 27 00:26:02 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Douglas Anderson X-Patchwork-Id: 12107479 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, 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 E9CE0C433E6 for ; Sat, 27 Feb 2021 00:27:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1A4764F0D for ; Sat, 27 Feb 2021 00:27:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230081AbhB0A1U (ORCPT ); Fri, 26 Feb 2021 19:27:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230018AbhB0A1S (ORCPT ); Fri, 26 Feb 2021 19:27:18 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79492C06178A for ; Fri, 26 Feb 2021 16:26:28 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id w18so6141246plc.12 for ; Fri, 26 Feb 2021 16:26:28 -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=d6xwfju9BuFcpoWFF+EpsUXmn1rhhTh/1d4BevylldU=; b=U9XrEzTZEa6ZtFSOnGv0xX009LgynEPCNjHI5nkM5UPGFqmhMonONwq+UcvaIMxcdE n8d+N2kjGAyaAl0MFwyJcXI1yE5vZGrRo1671A9HgEzLTfOxt4hgDVWMIDSw67gF4YrH 03AcM0vfSMulmin+9lx9fMr9KQeJu7kHMRBF4= 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=d6xwfju9BuFcpoWFF+EpsUXmn1rhhTh/1d4BevylldU=; b=MoAdp599rvq7ogErZ42J9LRWOkz4vQ76RS018WbQJnxGNCVJ9YYQIoWgUmKoWb/The SR8uZohD9M/xMDsa8gCaxYXyg/8BiesanbSuWyBwuwsoT1mGjoGiVgdo4rVcSEZDQwRj HQfMSU6rbUTehW7s1aDcqv112vNwuya80aVDJ0PyJwF/YkSbo4lTc1ECsNmJwEDRvcA9 evtCCrrRAof3vb8fZQ3nxUA4zpmrO+Wx9ZOGh7a06P6lGewB2JX8uYSOMDpNgSbP4eKz VsZIw7scrU7G4v7Lje7P+yRnEjzhj13p8mvSnFCpYdAyn3E9nTxSV5LPL2Z/WXGRxgFf QX8w== X-Gm-Message-State: AOAM532EFcEcS6bXgqfkCZwfb1m/hFBytHtO07njLZSjIi93gMBgUnSS ETOvRGX/kKtq1PrqimcZaaFKow== X-Google-Smtp-Source: ABdhPJxqsTpIpJOgV+oMX+GrdwRyY7sg/lnD0/dnqpwJHzAxL9+L6hynLWWhyh7RMCenYlHxWR1ZPA== X-Received: by 2002:a17:90a:4301:: with SMTP id q1mr5757456pjg.57.1614385588022; Fri, 26 Feb 2021 16:26:28 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:7525:b50:4b48:1a6d]) by smtp.gmail.com with ESMTPSA id t6sm9793744pgp.57.2021.02.26.16.26.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Feb 2021 16:26:27 -0800 (PST) From: Douglas Anderson To: Rob Clark , Jordan Crouse Cc: Niklas Cassel , Ulf Hansson , Bjorn Andersson , swboyd@chromium.org, linux-arm-msm@vger.kernel.org, Akhil P Oommen , Jorge Ramirez-Ortiz , Douglas Anderson , Srinivas Kandagatla , linux-kernel@vger.kernel.org Subject: [PATCH 2/3] nvmem: core: Allow nvmem_cell_read_u16/32/64 to read smaller cells Date: Fri, 26 Feb 2021 16:26:02 -0800 Message-Id: <20210226162521.2.I7c9190630cf9131b42d521aa1c5b97135012a734@changeid> X-Mailer: git-send-email 2.30.1.766.gb4fecdf3b7-goog In-Reply-To: <20210227002603.3260599-1-dianders@chromium.org> References: <20210227002603.3260599-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org The current way that cell "length" is specified for nvmem cells is a little fuzzy. For instance, let's look at the gpu speed bin currently in sc7180.dtsi: gpu_speed_bin: gpu_speed_bin@1d2 { reg = <0x1d2 0x2>; bits = <5 8>; }; This is an 8-bit value (as specified by the "bits" field). However, it has a "length" of 2 (bytes), presumably because the value spans across two bytes. When querying this value right now, it's hard for a client to know if they should be calling nvmem_cell_read_u16() or nvmem_cell_read_u8(). Today they must call nvmem_cell_read_u16() because the "length" of the cell was 2 (bytes). However, if a later SoC ever came around and didn't span across 2 bytes it would be unclear. If a later Soc specified, for instance: gpu_speed_bin: gpu_speed_bin@100 { reg = <0x100 0x1>; bits = <0 8>; }; ...then the caller would need to change to try calling nvmem_cell_read_u8() because the u16 version would fail. Let's solve this by allowing clients to read a "larger" value. We'll just fill it in with 0. If a client truly wants to know exactly how big the cell was they can fall back to calling nvmem_cell_read() directly. NOTE: current implementation assumes that cells are little endian when up-casting the size, but that's already pretty implicit in the way nvmem works now anyway. See nvmem_shift_read_buffer_in_place(). Let's document this but not do any auto-conversions just in case there was an instance where someone was using this API to read big endian data on a big endian machine and it happened to be working because there was no bit offset. Signed-off-by: Douglas Anderson --- I will freely admit that I always end up thinking in circles and getting dizzy when I think too much about endian considerations. If anyone has better intuition than I do and see that I've goofed this up then please yell. drivers/nvmem/core.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index a5ab1e0c74cf..8602390bb124 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -1534,12 +1534,14 @@ static int nvmem_cell_read_common(struct device *dev, const char *cell_id, nvmem_cell_put(cell); return PTR_ERR(buf); } - if (len != count) { + if (len > count) { kfree(buf); nvmem_cell_put(cell); return -EINVAL; + } else if (len != count) { + memset(val + len, 0, count - len); } - memcpy(val, buf, count); + memcpy(val, buf, len); kfree(buf); nvmem_cell_put(cell); @@ -1564,6 +1566,11 @@ EXPORT_SYMBOL_GPL(nvmem_cell_read_u8); /** * nvmem_cell_read_u16() - Read a cell value as a u16 * + * This function can be used to read any cell value 16-bits or less. If + * this function needs to upcast (or if the cell was stored in nvmem with + * a bit offset) it will assume that the cell is little endian. Clients + * should generally call le16_to_cpu() on the returned value. + * * @dev: Device that requests the nvmem cell. * @cell_id: Name of nvmem cell to read. * @val: pointer to output value. @@ -1579,6 +1586,11 @@ EXPORT_SYMBOL_GPL(nvmem_cell_read_u16); /** * nvmem_cell_read_u32() - Read a cell value as a u32 * + * This function can be used to read any cell value 32-bits or less. If + * this function needs to upcast (or if the cell was stored in nvmem with + * a bit offset) it will assume that the cell is little endian. Clients + * should generally call le32_to_cpu() on the returned value. + * * @dev: Device that requests the nvmem cell. * @cell_id: Name of nvmem cell to read. * @val: pointer to output value. @@ -1594,6 +1606,11 @@ EXPORT_SYMBOL_GPL(nvmem_cell_read_u32); /** * nvmem_cell_read_u64() - Read a cell value as a u64 * + * This function can be used to read any cell value 64-bits or less. If + * this function needs to upcast (or if the cell was stored in nvmem with + * a bit offset) it will assume that the cell is little endian. Clients + * should generally call le64_to_cpu() on the returned value. + * * @dev: Device that requests the nvmem cell. * @cell_id: Name of nvmem cell to read. * @val: pointer to output value. From patchwork Sat Feb 27 00:26:03 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Douglas Anderson X-Patchwork-Id: 12107481 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, 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 764C8C433E0 for ; Sat, 27 Feb 2021 00:28:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3D56864EE7 for ; Sat, 27 Feb 2021 00:28:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230104AbhB0A1s (ORCPT ); Fri, 26 Feb 2021 19:27:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230079AbhB0A1p (ORCPT ); Fri, 26 Feb 2021 19:27:45 -0500 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5DB7C061793 for ; Fri, 26 Feb 2021 16:26:29 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id b8so3342732plh.0 for ; Fri, 26 Feb 2021 16:26:29 -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=7vT9C4uK5m9m8aSd4JIqeVek2WQmiJglw5BM22hi2qE=; b=ExBnl+1zHVaGtFVHNR7bFHyLqGMR9rgJu/ts+PqWr/fJVyC2AZvd3SEpb36Qm8GHB7 Ta1pg7NnrSVBong/uGVc6ETZ6bNXqj5goRvlhvBhAX9PR6/hlgcaAdtkcLUyO8HRxt9w k2xwR2Z7r47DF5mqFNITKvWD0WWUOJbG0K81Q= 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=7vT9C4uK5m9m8aSd4JIqeVek2WQmiJglw5BM22hi2qE=; b=uhPktGkNaY1e+uXHplF1HYAVDu8im/vtSbNp8ojrHahm+Z6apyixJw2CeOUnxezEDK MdTJUJJPW3BJuQr/KrY0TM0axHD8FVtPqr+TF1qijW6KGTEeaQgUwdkTL9rcfwruCz7K KibBNxg/DqZWtuwaFwZssA1kln3z1o9BAn3bNQe8E8O2oAWUTA8PWkJy7ZsPNgPHMmEb aCgWkrlEiN7Pnec6reEd1CcU+6s6zuptjBN8+E+Vwbglp9+JEkWkSCZcGrc0Z2Rtl2vo DyKghPcMQ9sdWU6+Jdpg3Nudl3WVz9b2c/VBkkuJDcXo/6OQkW74YryF2ECYvLGHDccu Qr1g== X-Gm-Message-State: AOAM533th3rf3cXeSjUgRnGKJE9HJpQQBZPY0CpmS7AIF7B/BXCDQ3hp wyL/3IAKD24+m5M2n9kYGM2jgQ== X-Google-Smtp-Source: ABdhPJxRz+kMv//a9n7/44AZQdUJvK6HEviDg4TqN0DeHJRGDDYbx5409puKNu0VN0yQLeCTKTJ87g== X-Received: by 2002:a17:90a:b782:: with SMTP id m2mr5833394pjr.220.1614385589412; Fri, 26 Feb 2021 16:26:29 -0800 (PST) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:1:7525:b50:4b48:1a6d]) by smtp.gmail.com with ESMTPSA id t6sm9793744pgp.57.2021.02.26.16.26.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Feb 2021 16:26:29 -0800 (PST) From: Douglas Anderson To: Rob Clark , Jordan Crouse Cc: Niklas Cassel , Ulf Hansson , Bjorn Andersson , swboyd@chromium.org, linux-arm-msm@vger.kernel.org, Akhil P Oommen , Jorge Ramirez-Ortiz , Douglas Anderson , Srinivas Kandagatla , linux-kernel@vger.kernel.org Subject: [PATCH 3/3] nvmem: core: nvmem_cell_read() should return the true size Date: Fri, 26 Feb 2021 16:26:03 -0800 Message-Id: <20210226162521.3.I4bf6b274645a06943a421a90c14a97e8c03e6830@changeid> X-Mailer: git-send-email 2.30.1.766.gb4fecdf3b7-goog In-Reply-To: <20210227002603.3260599-1-dianders@chromium.org> References: <20210227002603.3260599-1-dianders@chromium.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org If we look at the gpu speed bin currently in sc7180.dtsi: gpu_speed_bin: gpu_speed_bin@1d2 { reg = <0x1d2 0x2>; bits = <5 8>; }; We can see that this is an 8-bit value. However we had to specify the "reg" as 16 bits because the value was spread out over two bytes. It doesn't make sense to expose the fact that the value was spread out over two bytes to the client. Let's use the number of bits to return the length to the client. NOTE: this change has the potential to break clients! Hopefully this breakage will be lessened (or eliminated) with the previous patch ("nvmem: core: Allow nvmem_cell_read_u16/32/64 to read smaller cells"), but it is possible for anyone directly calling nvmem_cell_read(). From a quick audit of mainline I don't _see_ any problems. Most cases won't change at all (number of bits matched the length) and the big case that will change is the Qualcomm "CPR" driver which seems to handle the length properly (it could probably be simplified now, actually). Signed-off-by: Douglas Anderson --- drivers/nvmem/core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 8602390bb124..00454d841a7f 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -1379,6 +1379,7 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem, void *buf, size_t *len) { int rc; + size_t bytes; rc = nvmem_reg_read(nvmem, cell->offset, buf, cell->bytes); @@ -1386,11 +1387,15 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem, return rc; /* shift bits in-place */ - if (cell->bit_offset || cell->nbits) + if (cell->bit_offset || cell->nbits) { nvmem_shift_read_buffer_in_place(cell, buf); + bytes = DIV_ROUND_UP(cell->nbits, 8); + } else { + bytes = cell->bytes; + } if (len) - *len = cell->bytes; + *len = bytes; return 0; }