From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932516AbcFNSvN (ORCPT ); Tue, 14 Jun 2016 14:51:13 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:53981 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932322AbcFNSvK (ORCPT ); Tue, 14 Jun 2016 14:51:10 -0400 Date: Tue, 14 Jun 2016 11:51:08 -0700 From: Stephen Boyd To: Linus Walleij Cc: lee.jones@linaro.org, linux-kernel@vger.kernel.org, Bjorn Andersson , stable@vger.kernel.org Subject: Re: [PATCH] mfd: qcom_rpm: fix offset error for msm8660 Message-ID: <20160614185108.GF28218@codeaurora.org> References: <1465897725-16213-1-git-send-email-linus.walleij@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1465897725-16213-1-git-send-email-linus.walleij@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/14, Linus Walleij wrote: > The RPM in MSM8660/APQ8060 has different offsets to the selector > ACK and request context ACK registers. Make all these register > offsets part of the per-SoC data and assign the right values. > > The bug was found by verifying backwards to the vendor tree in > the out-of-tree files : all were using > offsets 3,11,15,23 except the MSM8660/APQ8060 which was using > offsets 3,11,19,27. > > Cc: stable@vger.kernel.org > Fixes: 58e214382bdd ("mfd: qcom-rpm: Driver for the Qualcomm RPM") > Cc: Björn Andersson > Cc: Stephen Boyd > Signed-off-by: Linus Walleij Good catch! That macro maze is fun. > --- > drivers/mfd/qcom_rpm.c | 37 +++++++++++++++++++++++++++---------- > 1 file changed, 27 insertions(+), 10 deletions(-) > > diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c > index 4f589cf75549..82cc7986e1ca 100644 > --- a/drivers/mfd/qcom_rpm.c > +++ b/drivers/mfd/qcom_rpm.c > @@ -34,7 +34,11 @@ struct qcom_rpm_resource { > struct qcom_rpm_data { > u32 version; > const struct qcom_rpm_resource *resource_table; > - unsigned n_resources; > + unsigned int n_resources; > + unsigned int req_ctx_off; > + unsigned int req_sel_off; > + unsigned int ack_ctx_off; > + unsigned int ack_sel_off; > }; > > struct qcom_rpm { > @@ -61,10 +65,6 @@ struct qcom_rpm { > > #define RPM_REQUEST_TIMEOUT (5 * HZ) > > -#define RPM_REQUEST_CONTEXT 3 > -#define RPM_REQ_SELECT 11 > -#define RPM_ACK_CONTEXT 15 > -#define RPM_ACK_SELECTOR 23 > #define RPM_SELECT_SIZE 7 The RPM_SELECT_SIZE is 7 on 8660, but now you've pointed out that otherwise the size is 4. I think you've uncovered another bug. > > #define RPM_NOTIFICATION BIT(30) > @@ -398,10 +414,10 @@ int qcom_rpm_write(struct qcom_rpm *rpm, > bitmap_set((unsigned long *)sel_mask, res->select_id, 1); > for (i = 0; i < ARRAY_SIZE(sel_mask); i++) { > writel_relaxed(sel_mask[i], > - RPM_CTRL_REG(rpm, RPM_REQ_SELECT + i)); > + RPM_CTRL_REG(rpm, rpm->data->req_sel_off + i)); Here we write from 0 to ARRAY_SIZE(sel_mask) which is 7. That would mean we write into the ack context that starts at 15 (we start writing at req_sel_off which is always 11). Oops. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project