From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A1F03CE79CE for ; Wed, 20 Sep 2023 14:12:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ocygwlr2DwxQaSoonMWy2WUWKhYlAWICZGGsEk90CNA=; b=RPkaj2FjHiP6B8 7334s/8fyhbHO9a/5OmFThYsFHyC0hrWzYy5pZieB3M2D5LY1Vl0xMS6pUmTHnOaEc6K90RDUlGNH qB6gzEbX9tzLgUlFS0NsXIJ6CSevMkMSl1QjW4V0cbL9PFiVHYkcP67Rmdn6krr7AYMd5J0voTVx3 APwTzTQfzNeZ571erJYrCHjQkGtLo/dPNz9k9/aK1sffjU7g44uXVGH/xpNWu6kl7+z2zXNmJPotm DWTQC330x/pq0QuitdJh/n49sAXG94C75X4Wl3929OcfnCVONMDrJZyW/1XK84uXYxbP7yRyodJHI frZ3coLYL0xOVXwTrM+g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qixvq-003HrG-1R; Wed, 20 Sep 2023 14:11:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qixvm-003HqU-1u for linux-arm-kernel@lists.infradead.org; Wed, 20 Sep 2023 14:11:56 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0EBD11FB; Wed, 20 Sep 2023 07:12:28 -0700 (PDT) Received: from bogus (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 994813F5A1; Wed, 20 Sep 2023 07:11:49 -0700 (PDT) Date: Wed, 20 Sep 2023 15:11:47 +0100 From: Sudeep Holla To: Huisong Li Cc: rafael@kernel.org, rafael.j.wysocki@intel.com, xuwei5@hisilicon.com, Sudeep Holla , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, soc@kernel.org, linux-arm-kernel@lists.infradead.org, liuyonglong@huawei.com Subject: Re: [PATCH v2 2/2] soc: kunpeng_hccs: add the check for PCC subspace type Message-ID: <20230920141147.bq7cjiqjk6c36t6d@bogus> References: <20230914115753.9064-1-lihuisong@huawei.com> <20230920064703.23543-1-lihuisong@huawei.com> <20230920064703.23543-3-lihuisong@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230920064703.23543-3-lihuisong@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230920_071154_758698_01E52398 X-CRM114-Status: GOOD ( 24.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Sep 20, 2023 at 02:47:03PM +0800, Huisong Li wrote: > Currently, HCCS driver directly uses Generic Communications Channel Shared > Memory Region which is used in type0/1/2 to communicate with platform, > but actually doesn't support type3/4/5. > So this patch adds the check for PCC subspace type. > > Signed-off-by: Huisong Li > --- > drivers/soc/hisilicon/kunpeng_hccs.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/drivers/soc/hisilicon/kunpeng_hccs.c b/drivers/soc/hisilicon/kunpeng_hccs.c > index f3810d9d1caa..4ba3bfd45a01 100644 > --- a/drivers/soc/hisilicon/kunpeng_hccs.c > +++ b/drivers/soc/hisilicon/kunpeng_hccs.c > @@ -174,6 +174,19 @@ static int hccs_register_pcc_channel(struct hccs_dev *hdev) > return rc; > } > > +static int hccs_check_pcc_info(struct hccs_dev *hdev) > +{ > + struct pcc_mbox_chan *pcc_chan = hdev->cl_info.pcc_chan; > + > + if (pcc_chan->type >= ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE) { > + dev_err(hdev->dev, "unsupport for subspace type%u.\n", > + pcc_chan->type); > + return -EOPNOTSUPP; > + } Is this the only use of the PCC type information you have or do you plan to use it for something other than the validation. Just for sake of argument, I can say all users of PCC must then do the similar validation. I don't know where to draw the line here. Ideally I would expect the driver to make this transparent and give error during transmit if not supported. The driver must be able to work with different PCC type to support variety of platforms TBH. What is the issue exactly here ? Is this to prevent the use of Type 4 ? I think we must do something better but I don't know what that is yet. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel