Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4836142imm; Mon, 14 May 2018 14:05:38 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpsKVb2qsUDkp4nbDr8V6eKJ6LF6W2tiCrfODnDva34QIWaAdHQNwdOAEX13Fx1Sz7KXAC8 X-Received: by 2002:a63:7e08:: with SMTP id z8-v6mr9654749pgc.383.1526331938353; Mon, 14 May 2018 14:05:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526331938; cv=none; d=google.com; s=arc-20160816; b=mrVHgt10ckVvLYqRIfZI0AYJQwC5sLQAI1nC1bhekXcfacCrnN4gTuDLuolS7uQMwu jvlL64qwY2G+7gLwJBZ/yKDMTAN4WQfmM8U5xbO8+0mnxMlfq5+vHm+Pma5W2FwCkJOp FVY9QGIaxPG714twsGSfRFhb7xh+jS31n1DrvoM24mjUNdELCMBODgXRthczoDxDN4Sk 5kJ5q6jw5akJdr5dge7Vc+KdSPmcC/4qzDNTnlY7n4RIGmiQRYtq+BW93vqpv7e1Gn7m b5jBNxOdyNYSIaVQR8AsdRE7efZnqzy2yLYrx1md6JwyUThhRizHNWZ1ckov53Tu1bMS 9zQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=KicP4r5bHFjjoyEIfa7Bs5ZEM/YGw281zMriX8kNfhE=; b=m/R9MUOIoOMHlvagcDoAcXErHXd0lVxJLUR+VKbs9QL92/948JwIac8Ph9IdjOo9vZ MhOdG1dKLE9xBouefwFEn1jEoy16ctJ8KlIuNGQnT52PNptbE57ArdfzPImYC/LMGq4G nTq1pbWyVUbGtevlcqOL6457gLg8QkLs0fiMdyhB6Xd/4z148n+kmx769RFhtGTeBIAg mUdn+W2n6f8cvhveAkxg0jwPJ6fOqxMxO4mItkowuUJIqkmS/qxvt8eYOuf6Pj+prEoF OIIJ39rjKc8gScHwSjnOG7QvqqxVqXN75JSZ32Lj5yw3175JmsVaK7S4AYu21WL7409F 3sNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=bWw9csAH; dkim=pass header.i=@codeaurora.org header.s=default header.b=LqZ2ApNQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g11-v6si10770001plt.284.2018.05.14.14.05.24; Mon, 14 May 2018 14:05:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=bWw9csAH; dkim=pass header.i=@codeaurora.org header.s=default header.b=LqZ2ApNQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752677AbeENVEi (ORCPT + 99 others); Mon, 14 May 2018 17:04:38 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:53774 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752195AbeENVEg (ORCPT ); Mon, 14 May 2018 17:04:36 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id F062D60C67; Mon, 14 May 2018 21:04:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526331876; bh=FjjjkDfNodHKYcVByvxCWtNUD1yGwi/cfCEoUqg1w5k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=bWw9csAH9rdsZVE8YZP9nYnFoRJNWFV7vKFM2LUuV79bAIZta62ZdL0j8i96YubRn h4gPTQNQUrhRIXQ5F9HQHrH03EbMfJ39PPyW50OQ2bfjQUGVdbuWvITdTJiJTTa7Ob DkG/unQrWoVlsYTjZzHi8kyaSmEpbg2AdbDdyqow= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.226.58.143] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pprakash@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id BF74860A06; Mon, 14 May 2018 21:04:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526331872; bh=FjjjkDfNodHKYcVByvxCWtNUD1yGwi/cfCEoUqg1w5k=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LqZ2ApNQJHeb8tWv4JzKgPDMtdM/a5sCvF4uHykmsaiR46+dOrvDVEslL5ABfM64z wgNEkydHjzfmCK81fUhKTEJrNNrsk3GSMs+g/jgA1iPPP1moq+UUT8j61mavbEbKjn YfG/S9ijXE177i01yNHKfRcFcdPPGAhQtW7Iqp0U= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org BF74860A06 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=pprakash@codeaurora.org Subject: Re: [PATCH v3 3/3] mailbox: ACPI: erroneous error message when parsing the ACPI PCCT To: Al Stone , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Jassi Brar , "Rafael J . Wysocki" , Len Brown References: <20180501003907.4322-1-ahs3@redhat.com> <20180501003907.4322-4-ahs3@redhat.com> From: "Prakash, Prashanth" Message-ID: <17197481-bd76-f2ec-9d6e-4cd0d94b9265@codeaurora.org> Date: Mon, 14 May 2018 15:04:30 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180501003907.4322-4-ahs3@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/30/2018 6:39 PM, Al Stone wrote: > There have been multiple reports of the following error message: > > [ 0.068293] Error parsing PCC subspaces from PCCT > > This error message is not correct. In multiple cases examined, the PCCT > (Platform Communications Channel Table) concerned is actually properly > constructed; the problem is that acpi_pcc_probe() which reads the PCCT > is making the assumption that the only valid PCCT is one that contains > subtables of one of two types: ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE or > ACPI_PCCT_TYPE_HW_REDUCED_TYPE2. The number of subtables of these > types are counted and as long as there is at least one of the desired > types, the acpi_pcc_probe() succeeds. When no subtables of these types > are found, regardless of whether or not any other subtable types are > present, the error mentioned above is reported. > > In the cases reported to me personally, the PCCT contains exactly one > subtable of type ACPI_PCCT_TYPE_GENERIC_SUBSPACE. The function > acpi_pcc_probe() does not count it as a valid subtable, so believes > there to be no valid subtables, and hence outputs the error message. > > An example of the PCCT being reported as erroneous yet perfectly fine > is the following: > > Signature : "PCCT" > Table Length : 0000006E > Revision : 05 > Checksum : A9 > Oem ID : "XXXXXX" > Oem Table ID : "XXXXX " > Oem Revision : 00002280 > Asl Compiler ID : "XXXX" > Asl Compiler Revision : 00000002 > > Flags (decoded below) : 00000001 > Platform : 1 > Reserved : 0000000000000000 > > Subtable Type : 00 [Generic Communications Subspace] > Length : 3E > > Reserved : 000000000000 > Base Address : 00000000DCE43018 > Address Length : 0000000000001000 > > Doorbell Register : [Generic Address Structure] > Space ID : 01 [SystemIO] > Bit Width : 08 > Bit Offset : 00 > Encoded Access Width : 01 [Byte Access:8] > Address : 0000000000001842 > > Preserve Mask : 00000000000000FD > Write Mask : 0000000000000002 > Command Latency : 00001388 > Maximum Access Rate : 00000000 > Minimum Turnaround Time : 0000 > > To fix this, we count up all of the possible subtable types for the > PCCT, and only report an error when there are none (which could mean > either no subtables, or no valid subtables), or there are too many. > We also change the logic so that if there is a valid subtable, we > do try to initialize it per the PCCT subtable contents. This is a > change in functionality; previously, the probe would have returned > right after the error message and would not have tried to use any > other subtable definition. > > Tested on my personal laptop which showed the error previously; the > error message no longer appears and the laptop appears to operate > normally. > > Signed-off-by: Al Stone > Cc: Jassi Brar > Cc: Rafael J. Wysocki > Cc: Len Brown > --- > drivers/mailbox/pcc.c | 96 +++++++++++++++++++++++++++++++++------------------ > 1 file changed, 63 insertions(+), 33 deletions(-) > > diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c > index 3ef7f036ceea..72af37d7e95e 100644 > --- a/drivers/mailbox/pcc.c > +++ b/drivers/mailbox/pcc.c > @@ -372,13 +372,37 @@ static const struct mbox_chan_ops pcc_chan_ops = { > .send_data = pcc_send_data, > }; > > +/* > + * > + * count_pcc_subspaces -- Count PCC subspaces not used in reduced HW systems. > + * @header: Pointer to the ACPI subtable header under the PCCT. > + * @end: End of subtable entry. > + * > + * Return: If we find a PCC subspace entry that is one of the types used > + * in reduced hardware systems, return -EINVAL. Otherwise, return 0. > + * > + * This gets called for each subtable in the PCC table. > + */ > +static int count_pcc_subspaces(struct acpi_subtable_header *header, > + const unsigned long end) > +{ > + struct acpi_pcct_subspace *pcct_ss = (struct acpi_pcct_subspace *) header; > + > + if ((pcct_ss->header.type <= ACPI_PCCT_TYPE_RESERVED) && > + (pcct_ss->header.type != ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE) && > + (pcct_ss->header.type != ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2)) > + return 0; > + > + return -EINVAL; > +} > + > /** > - * parse_pcc_subspace - Parse the PCC table and verify PCC subspace > - * entries. There should be one entry per PCC client. > + * parse_pcc_subspaces -- Count PCC subspaces used only in reduced HW systems. > * @header: Pointer to the ACPI subtable header under the PCCT. > * @end: End of subtable entry. > * > - * Return: 0 for Success, else errno. > + * Return: If we find a PCC subspace entry that is one of the types used > + * in reduced hardware systems, return 0. Otherwise, return -EINVAL. > * > * This gets called for each entry in the PCC table. > */ > @@ -393,10 +417,8 @@ static int parse_pcc_subspace(struct acpi_subtable_header *header, > if ((pcct_ss->header.type != > ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE) > && (pcct_ss->header.type != > - ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2)) { > - pr_err("Incorrect PCC Subspace type detected\n"); > + ACPI_PCCT_TYPE_HW_REDUCED_SUBSPACE_TYPE2)) > return -EINVAL; > - } > } > > return 0; Can't we combine  parse_pcc_subspace and count_pcc_subspaces into a single function? parse_pcc_subspace can return 0 for supported subspace types and -EINVAL for others. The limitation on number of subspaces(max = 256) applies to all types of PCC subspaces (see Table 14-351 in ACPI 6.2).  The MAX_PCC_SUBSPACES check in  parse_pcc_subspace seems invalid as pcc_mbox_ctrl.num_chans will not be initialized yet at that moment. Given above, I think it is probably better to update parse_pcc_subspace to only check for a valid PCC subspace type. The check to make sure overall count of subspace is  less than 256 is already present following the call to acpi_table_parse_entries_array(). -- Thanks, Prashanth