soc: hisilicon: Support HCCS driver on Kunpeng SoC

Commit Message

lihuisong (C) April 24, 2023, 7:30 a.m. UTC

The Huawei Cache-Coherent System (HCCS) is a bus protocol standard
for ensuring cache coherent on HiSilicon SoC. The performance of
the application may be affected if some hccs ports are in non-full
lane status, have a large number of CRC errors and so on.

This driver provides the query interface of the health status and
port information of HCCS on Kunpeng SoC.

Signed-off-by: Huisong Li <[e-mail]>
---
 MAINTAINERS                          |    6 +
 drivers/soc/Kconfig                  |    1 +
 drivers/soc/Makefile                 |    1 +
 drivers/soc/hisilicon/Kconfig        |   18 +
 drivers/soc/hisilicon/Makefile       |    2 +
 drivers/soc/hisilicon/kunpeng_hccs.c | 1296 ++++++++++++++++++++++++++
 drivers/soc/hisilicon/kunpeng_hccs.h |  204 ++++
 7 files changed, 1528 insertions(+)
 create mode 100644 drivers/soc/hisilicon/Kconfig
 create mode 100644 drivers/soc/hisilicon/Makefile
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h

Comments

Arnd Bergmann April 24, 2023, 8:09 a.m. UTC | #1

On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:

> diff --git a/drivers/soc/hisilicon/Kconfig 
> b/drivers/soc/hisilicon/Kconfig
> new file mode 100644
> index 000000000000..81768d47f572
> --- /dev/null
> +++ b/drivers/soc/hisilicon/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +menu "Hisilicon SoC drivers"
> +	depends on ARCH_HISI
> +
> +config KUNPENG_HCCS
> +	tristate "HCCS driver on Kunpeng SoC"
> +	depends on ARM64 && ACPI

Is there a compile-time dependency on ARM64? If not, it would
be good to allow compile testing. At the same time, you
can probably tighten this to ARCH_HISI instead of ARM64,
since no other vendors are going to use it:

       depends on ACPI
       depends on (ARM64 && ARCH_HISI) || COMPILE_TEST

> +
> +#include "kunpeng_hccs.h"
> +
> +/* PCC defines */
> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)

Should these perhaps be in include/acpi/pcc.h? The 0x50434300
number is just "PCC\0", so it appears to not be HCCS specific.

> +
> +static int hccs_get_device_property(struct hccs_dev *hdev)
> +{
> +	struct device *dev = hdev->dev;
> +
> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
> +		dev_err(hdev->dev, "no device-flags property.\n");
> +		return -ENODEV;
> +	}
> +
> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
> +		dev_err(hdev->dev, "no pcc-type property.\n");
> +		return -ENODEV;
> +	}
> +
> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
> +		dev_err(hdev->dev, "no pcc-channel property.\n");
> +		return -ENODEV;
> +	}
> +
> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
> +	if (!hccs_dev_property_supported(hdev))
> +		return -EOPNOTSUPP;
> +

Where are the device properties documented? I'm never quite sure how
to handle these for ACPI-only drivers, since we don't normally have the
bindings in Documentation/devicetree/bindings/, but it feels like there
should be some properly reviewed document somewhere else.

Adding ACPI and devicetree maintainers to Cc for clarification. 

> +static int hccs_check_chan_cmd_complete(struct hccs_dev *hdev)
> +{
> +	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
> +	struct acpi_pcct_shared_memory *comm_base = cl_info->pcc_comm_addr;
> +	u16 status;
> +	int ret;
> +
> +	/*
> +	 * Poll PCC status register every 3us(delay_us) for maximum of
> +	 * deadline_us(timeout_us) until PCC command complete bit is set(cond)
> +	 */
> +	ret = readw_relaxed_poll_timeout(&comm_base->status, status,
> +					 status & HCCS_PCC_STATUS_CMD_COMPLETE,
> +					 HCCS_POLL_STATUS_TIME_INTERVAL_US,
> +					 cl_info->deadline_us);

Is it both safe and faster to use a relaxed readw here, compared
to the normal one? If there is any access to shared memory
involved, you need the implied barrier for serialization, and since this
is already a sleeping operation, I would guess that you don't care
about the last nanosecond of latency here.

> +static ssize_t hccs_show(struct kobject *k, struct attribute *attr, 
> char *buf)
> +{
> +	struct kobj_attribute *kobj_attr;
> +
> +	kobj_attr = container_of(attr, struct kobj_attribute, attr);
> +
> +	return kobj_attr->show(k, kobj_attr, buf);
> +}
> +
> +static const struct sysfs_ops hccs_comm_ops = {
> +	.show = hccs_show,
> +};

Every sysfs interface needs to be documented in Documentation/ABI/

> diff --git a/drivers/soc/hisilicon/kunpeng_hccs.h 
> b/drivers/soc/hisilicon/kunpeng_hccs.h
> new file mode 100644
> index 000000000000..ca557ef115ea
> --- /dev/null
> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
> @@ -0,0 +1,204 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/* Copyright (c) 2023 Hisilicon Limited. */
> +
> +#ifndef __KUNPENG_HCCS_H__
> +#define __KUNPENG_HCCS_H__

Are you planning to add more drivers that share this file? If not,
just fold the contents into the driver itself.

     Arnd

Krzysztof Kozlowski April 24, 2023, 8:42 a.m. UTC | #2

On 24/04/2023 09:30, Huisong Li wrote:
> The Huawei Cache-Coherent System (HCCS) is a bus protocol standard
> for ensuring cache coherent on HiSilicon SoC. The performance of
> the application may be affected if some hccs ports are in non-full
> lane status, have a large number of CRC errors and so on.
> 
> This driver provides the query interface of the health status and
> port information of HCCS on Kunpeng SoC.
> 
> Signed-off-by: Huisong Li <[e-mail]>
> ---
>  MAINTAINERS                          |    6 +
>  drivers/soc/Kconfig                  |    1 +
>  drivers/soc/Makefile                 |    1 +
>  drivers/soc/hisilicon/Kconfig        |   18 +
>  drivers/soc/hisilicon/Makefile       |    2 +
>  drivers/soc/hisilicon/kunpeng_hccs.c | 1296 ++++++++++++++++++++++++++
>  drivers/soc/hisilicon/kunpeng_hccs.h |  204 ++++
>  7 files changed, 1528 insertions(+)
>  create mode 100644 drivers/soc/hisilicon/Kconfig
>  create mode 100644 drivers/soc/hisilicon/Makefile
>  create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
>  create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eddbc48c61e9..fe0e796e8445 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9399,6 +9399,12 @@ S:	Maintained
>  W:	http://www.hisilicon.com
>  F:	drivers/spi/spi-hisi-sfc-v3xx.c
>  
> +HISILICON KUNPENG SOC HCCS DRIVER
> +M:	Huisong Li <[e-mail]>
> +S:	Maintained
> +F:	drivers/soc/hisilicon/kunpeng_hccs.c
> +F:	drivers/soc/hisilicon/kunpeng_hccs.h
> +
>  HMM - Heterogeneous Memory Management
>  M:	Jérôme Glisse <[e-mail]>
>  L:	[e-mail]
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index 4e176280113a..d21e75d69294 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -10,6 +10,7 @@ source "drivers/soc/bcm/Kconfig"
>  source "drivers/soc/canaan/Kconfig"
>  source "drivers/soc/fsl/Kconfig"
>  source "drivers/soc/fujitsu/Kconfig"
> +source "drivers/soc/hisilicon/Kconfig"
>  source "drivers/soc/imx/Kconfig"
>  source "drivers/soc/ixp4xx/Kconfig"
>  source "drivers/soc/litex/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 3b0f9fb3b5c8..531f46f3ad98 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_MACH_DOVE)		+= dove/
>  obj-y				+= fsl/
>  obj-y				+= fujitsu/
>  obj-$(CONFIG_ARCH_GEMINI)	+= gemini/
> +obj-y				+= hisilicon/
>  obj-y				+= imx/
>  obj-y				+= ixp4xx/
>  obj-$(CONFIG_SOC_XWAY)		+= lantiq/
> diff --git a/drivers/soc/hisilicon/Kconfig b/drivers/soc/hisilicon/Kconfig
> new file mode 100644
> index 000000000000..81768d47f572
> --- /dev/null
> +++ b/drivers/soc/hisilicon/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +menu "Hisilicon SoC drivers"
> +	depends on ARCH_HISI
> +
> +config KUNPENG_HCCS
> +	tristate "HCCS driver on Kunpeng SoC"
> +	depends on ARM64 && ACPI
> +	help
> +	  The Huawei Cache-Coherent System (HCCS) is a bus protocol standard
> +	  for ensuring cache coherent on HiSilicon SoC. The performance of
> +	  the application may be affected if some hccs ports are in non-full
> +	  lane status, have a large number of CRC errors and so on.
> +
> +	  Say M here if you want to include support for querying the health
> +	  status and port information of HCCS on Kunpeng SoC.
> +
> +endmenu
> diff --git a/drivers/soc/hisilicon/Makefile b/drivers/soc/hisilicon/Makefile
> new file mode 100644
> index 000000000000..226e747e70d6
> --- /dev/null
> +++ b/drivers/soc/hisilicon/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_KUNPENG_HCCS)	+= kunpeng_hccs.o
> diff --git a/drivers/soc/hisilicon/kunpeng_hccs.c b/drivers/soc/hisilicon/kunpeng_hccs.c
> new file mode 100644
> index 000000000000..2b52f7dedc78
> --- /dev/null
> +++ b/drivers/soc/hisilicon/kunpeng_hccs.c
> @@ -0,0 +1,1296 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * The Huawei Cache-Coherent System (HCCS) is a bus protocol standard for
> + * ensuring cache coherent on HiSilicon SoC.
> + *
> + * Copyright (c) 2023 Hisilicon Limited.
> + * Author: Huisong Li <[e-mail]>
> + *
> + * HCCS driver for Kunpeng SoC provides the following features:
> + * - Retrieve info as belows each port:
> + *    - port type
> + *    - lane mode
> + *    - using status
> + *    - current lane mode
> + *    - link state machine
> + *    - lane mask
> + *    - CRC error count
> + *
> + * - Retrieve info as belows all ports on die or chip:
> + *    - if all used ports are in linked
> + *    - if all linked ports are in full lane
> + *    - CRC error count sum
> + */
> +#include <linux/sysfs.h>
> +#include <linux/acpi.h>
> +#include <linux/io.h>
> +#include <linux/kobject.h>
> +#include <linux/iopoll.h>
> +#include <linux/platform_device.h>
> +#include <acpi/pcc.h>
> +
> +#include "kunpeng_hccs.h"
> +
> +/* PCC defines */
> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
> +
> +/*
> + * Arbitrary retries in case the remote processor is slow to respond
> + * to PCC commands
> + */
> +#define HCCS_PCC_CMD_WAIT_RETRIES_NUM		500ULL
> +#define HCCS_POLL_STATUS_TIME_INTERVAL_US	3
> +
> +static struct hccs_port_info *kobj_to_port_info(struct kobject *k)
> +{
> +	return container_of(k, struct hccs_port_info, kobj);
> +}
> +
> +static struct hccs_die_info *kobj_to_die_info(struct kobject *k)
> +{
> +	return container_of(k, struct hccs_die_info, kobj);
> +}
> +
> +static struct hccs_chip_info *kobj_to_chip_info(struct kobject *k)
> +{
> +	return container_of(k, struct hccs_chip_info, kobj);
> +}
> +
> +static bool hccs_dev_property_supported(struct hccs_dev *hdev)
> +{
> +	struct device *dev = hdev->dev;
> +
> +	if (hdev->intr_mode) {
> +		dev_err(dev, "interrupt mode is unsupported.\n");
> +		return false;
> +	}
> +
> +	if (hdev->type >= ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE) {
> +		dev_err(dev, "PCC type-%u is unsupported.\n", hdev->type);
> +		return false;
> +	}
> +
> +	return true;
> +}
> +
> +static int hccs_get_device_property(struct hccs_dev *hdev)
> +{
> +	struct device *dev = hdev->dev;
> +
> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
> +		dev_err(hdev->dev, "no device-flags property.\n");
> +		return -ENODEV;
> +	}
> +
> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
> +		dev_err(hdev->dev, "no pcc-type property.\n");
> +		return -ENODEV;
> +	}
> +
> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
> +		dev_err(hdev->dev, "no pcc-channel property.\n");
> +		return -ENODEV;
> +	}
> +
> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
> +	if (!hccs_dev_property_supported(hdev))

Maybe leave a comment that all these are ACPI-only and are not allowed
in DT usage. Without bindings we are not going to review them. OTOH, I
think we don't have a process for such cases in general.

> +		return -EOPNOTSUPP;
> +
> +	return 0;
> +}
> +

(...)

> +static struct attribute *hccs_chip_default_attrs[] = {
> +	&all_linked_on_chip_attr.attr,
> +	&linked_full_lane_on_chip_attr.attr,
> +	&crc_err_cnt_sum_on_chip_attr.attr,
> +	NULL,
> +};
> +ATTRIBUTE_GROUPS(hccs_chip_default);
> +
> +static const struct kobj_type hccs_chip_type = {
> +	.sysfs_ops = &hccs_comm_ops,
> +	.default_groups = hccs_chip_default_groups,

Missing sysfs documentation.

This also looks like:
1. Duplicating parts of socinfo.
2. Open-coding coding sysfs API.

Anyway, after describing this API it might turn out it is not valid for
upstream usage...

> +};
> +
> +static void hccs_remove_die_dir(struct hccs_die_info *die)
> +{
> +	struct hccs_port_info *port;
> +	u8 i;
> +
> +	for (i = 0; i < die->port_num; i++) {
> +		port = &die->ports[i];
> +		if (port->dir_created)
> +			kobject_put(&port->kobj);
> +	}
> +
> +	kobject_put(&die->kobj);
> +}
> +
> +static void hccs_remove_chip_dir(struct hccs_chip_info *chip)
> +{
> +	struct hccs_die_info *die;
> +	u8 i;
> +
> +	for (i = 0; i < chip->die_num; i++) {
> +		die = &chip->dies[i];
> +		if (die->dir_created)
> +			hccs_remove_die_dir(die);
> +	}
> +
> +	kobject_put(&chip->kobj);
> +}
> +
> +static void hccs_remove_topo_dirs(struct hccs_dev *hdev)
> +{
> +	u8 i;
> +
> +	for (i = 0; i < hdev->chip_num; i++)
> +		hccs_remove_chip_dir(&hdev->chips[i]);
> +}
> +
> +static int hccs_create_hccs_dir(struct hccs_dev *hdev,
> +				struct hccs_die_info *die,
> +				struct hccs_port_info *port)
> +{
> +	int ret;
> +
> +	ret = kobject_init_and_add(&port->kobj, &hccs_port_type,
> +				   &die->kobj, "hccs%d", port->port_id);
> +	if (ret) {
> +		kobject_put(&port->kobj);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int hccs_create_die_dir(struct hccs_dev *hdev,
> +			       struct hccs_chip_info *chip,
> +			       struct hccs_die_info *die)
> +{
> +	struct hccs_port_info *port;
> +	int ret;
> +	u16 i;
> +
> +	ret = kobject_init_and_add(&die->kobj, &hccs_die_type,
> +				   &chip->kobj, "die%d", die->die_id);
> +	if (ret) {
> +		kobject_put(&die->kobj);
> +		return ret;
> +	}
> +
> +	for (i = 0; i < die->port_num; i++) {
> +		port = &die->ports[i];
> +		ret = hccs_create_hccs_dir(hdev, die, port);
> +		if (ret) {
> +			dev_err(hdev->dev, "create hccs%d dir failed.\n",
> +				port->port_id);
> +			goto err;
> +		}
> +		port->dir_created = true;
> +	}
> +
> +	return 0;
> +err:
> +	hccs_remove_die_dir(die);
> +
> +	return ret;
> +}
> +
> +static int hccs_create_chip_dir(struct hccs_dev *hdev,
> +				struct hccs_chip_info *chip)
> +{
> +	struct hccs_die_info *die;
> +	int ret;
> +	u16 id;
> +
> +	ret = kobject_init_and_add(&chip->kobj, &hccs_chip_type,
> +				   &hdev->dev->kobj, "chip%d", chip->chip_id);
> +	if (ret) {
> +		kobject_put(&chip->kobj);
> +		return ret;
> +	}
> +
> +	for (id = 0; id < chip->die_num; id++) {
> +		die = &chip->dies[id];
> +		ret = hccs_create_die_dir(hdev, chip, die);
> +		if (ret)
> +			goto err;
> +		die->dir_created = true;
> +	}
> +
> +	return 0;
> +err:
> +	hccs_remove_chip_dir(chip);
> +
> +	return ret;
> +}
> +
> +static int hccs_create_topo_dirs(struct hccs_dev *hdev)
> +{
> +	struct hccs_chip_info *chip;
> +	u8 id, k;
> +	int ret;
> +
> +	for (id = 0; id < hdev->chip_num; id++) {
> +		chip = &hdev->chips[id];
> +		ret = hccs_create_chip_dir(hdev, chip);
> +		if (ret) {
> +			dev_err(hdev->dev, "init chip%d dir failed!\n", id);
> +			goto err;
> +		}
> +	}
> +
> +	return 0;
> +err:
> +	for (k = 0; k < id; k++)
> +		hccs_remove_chip_dir(&hdev->chips[k]);
> +
> +	return ret;
> +}
> +
> +static int hccs_probe(struct platform_device *pdev)
> +{
> +	struct acpi_device *acpi_dev;
> +	struct hccs_dev *hdev;
> +	int rc;
> +
> +	pr_info("kunpeng_hccs is initializing.\n");

Drop.

> +
> +	if (acpi_disabled) {
> +		dev_err(&pdev->dev, "acpi is disabled.\n");

Is it possible for your ACPI-only driver?


> +		return -ENODEV;
> +	}
> +	acpi_dev = ACPI_COMPANION(&pdev->dev);
> +	if (!acpi_dev)
> +		return -ENODEV;
> +
> +	hdev = devm_kzalloc(&pdev->dev, sizeof(*hdev), GFP_KERNEL);
> +	if (!hdev)
> +		return -ENOMEM;
> +	hdev->acpi_dev = acpi_dev;
> +	hdev->dev = &pdev->dev;
> +	platform_set_drvdata(pdev, hdev);
> +
> +	rc = hccs_get_device_property(hdev);
> +	if (rc)
> +		return rc;
> +
> +	mutex_init(&hdev->lock);
> +
> +	rc = hccs_register_pcc_channel(hdev);
> +	if (rc)
> +		return rc;
> +
> +	rc = hccs_get_dev_caps(hdev);
> +	if (rc)
> +		goto err_uninit_mbox_client;
> +
> +	rc = hccs_get_hw_info(hdev);
> +	if (rc)
> +		goto err_uninit_mbox_client;
> +
> +	rc = hccs_create_topo_dirs(hdev);
> +	if (rc)
> +		goto err_uninit_mbox_client;
> +
> +	dev_info(&pdev->dev, "HISI HCCS driver registered!\n");

Drop simple probe success msgs. There's already kernel infrastructure
giving you this information.

> +
> +	return 0;
> +
> +err_uninit_mbox_client:
> +	hccs_unregister_pcc_channel(hdev);
> +
> +	return rc;
> +}
> +
> +static int hccs_remove(struct platform_device *pdev)
> +{
> +	struct hccs_dev *hdev = platform_get_drvdata(pdev);
> +
> +	hccs_remove_topo_dirs(hdev);
> +	hccs_unregister_pcc_channel(hdev);
> +
> +	return 0;
> +}
> +
> +static const struct acpi_device_id hccs_acpi_match[] = {
> +	{ "HISI04B1", },
> +};
> +
> +static struct platform_driver hccs_driver = {
> +	.probe = hccs_probe,
> +	.remove = hccs_remove,
> +	.driver = {
> +		.name = "kunpeng_hccs",
> +		.acpi_match_table = ACPI_PTR(hccs_acpi_match),

Drop ACPI_PTR as it is not balanced with __maybe_unused.

Best regards,
Krzysztof

lihuisong (C) April 25, 2023, 3:04 a.m. UTC | #3

Hi Arnd,

Thanks for your review. My reply is as follows.


在 2023/4/24 16:09, Arnd Bergmann 写道:
> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:
>
>> diff --git a/drivers/soc/hisilicon/Kconfig
>> b/drivers/soc/hisilicon/Kconfig
>> new file mode 100644
>> index 000000000000..81768d47f572
>> --- /dev/null
>> +++ b/drivers/soc/hisilicon/Kconfig
>> @@ -0,0 +1,18 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +
>> +menu "Hisilicon SoC drivers"
>> +	depends on ARCH_HISI
>> +
>> +config KUNPENG_HCCS
>> +	tristate "HCCS driver on Kunpeng SoC"
>> +	depends on ARM64 && ACPI
> Is there a compile-time dependency on ARM64? If not, it would
Yes, no compile-time dependency on ARM64.
> be good to allow compile testing. At the same time, you
> can probably tighten this to ARCH_HISI instead of ARM64,
> since no other vendors are going to use it:
>
>         depends on ACPI
>         depends on (ARM64 && ARCH_HISI) || COMPILE_TEST
What do you think of adjusting it as below?
menu "Hisilicon SoC drivers"
     depends on ARCH_HISI || COMPILE_TEST

config KUNPENG_HCCS
     depends on ACPI
     depends on ARM64 || COMPILE_TEST

>
>> +
>> +#include "kunpeng_hccs.h"
>> +
>> +/* PCC defines */
>> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
>> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
> Should these perhaps be in include/acpi/pcc.h? The 0x50434300
> number is just "PCC\0", so it appears to not be HCCS specific.
This is a PCC signature. As stated in the APCI,
"The signature of a subspace is computed by a bitwiseor of the value 
0x50434300
with the subspace ID. For example, subspace 3 has the signature 0x50434303."

I am not sure if all driver need to use this fixed signature mask.
As far as I know, cppc_acpi.c didn't use this signature and 
xgene-hwmon.c used another mask defined in its driver.
So I place it here.
>
>> +
>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>> +{
>> +	struct device *dev = hdev->dev;
>> +
>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>> +		dev_err(hdev->dev, "no device-flags property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>> +	if (!hccs_dev_property_supported(hdev))
>> +		return -EOPNOTSUPP;
>> +
> Where are the device properties documented? I'm never quite sure how
> to handle these for ACPI-only drivers, since we don't normally have the
> bindings in Documentation/devicetree/bindings/, but it feels like there
> should be some properly reviewed document somewhere else.
These are ACPI-only, instead of DT.
I will add a comment here as Krzysztof suggested.
>
> Adding ACPI and devicetree maintainers to Cc for clarification.
>
>> +static int hccs_check_chan_cmd_complete(struct hccs_dev *hdev)
>> +{
>> +	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
>> +	struct acpi_pcct_shared_memory *comm_base = cl_info->pcc_comm_addr;
>> +	u16 status;
>> +	int ret;
>> +
>> +	/*
>> +	 * Poll PCC status register every 3us(delay_us) for maximum of
>> +	 * deadline_us(timeout_us) until PCC command complete bit is set(cond)
>> +	 */
>> +	ret = readw_relaxed_poll_timeout(&comm_base->status, status,
>> +					 status & HCCS_PCC_STATUS_CMD_COMPLETE,
>> +					 HCCS_POLL_STATUS_TIME_INTERVAL_US,
>> +					 cl_info->deadline_us);
> Is it both safe and faster to use a relaxed readw here, compared
> to the normal one? If there is any access to shared memory
> involved, you need the implied barrier for serialization, and since this
> is already a sleeping operation, I would guess that you don't care
> about the last nanosecond of latency here.
Great comment. I will use the normal one.
>
>> +static ssize_t hccs_show(struct kobject *k, struct attribute *attr,
>> char *buf)
>> +{
>> +	struct kobj_attribute *kobj_attr;
>> +
>> +	kobj_attr = container_of(attr, struct kobj_attribute, attr);
>> +
>> +	return kobj_attr->show(k, kobj_attr, buf);
>> +}
>> +
>> +static const struct sysfs_ops hccs_comm_ops = {
>> +	.show = hccs_show,
>> +};
> Every sysfs interface needs to be documented in Documentation/ABI/
All right, I will add another patch to do this.
>
>> diff --git a/drivers/soc/hisilicon/kunpeng_hccs.h
>> b/drivers/soc/hisilicon/kunpeng_hccs.h
>> new file mode 100644
>> index 000000000000..ca557ef115ea
>> --- /dev/null
>> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
>> @@ -0,0 +1,204 @@
>> +/* SPDX-License-Identifier: GPL-2.0+ */
>> +/* Copyright (c) 2023 Hisilicon Limited. */
>> +
>> +#ifndef __KUNPENG_HCCS_H__
>> +#define __KUNPENG_HCCS_H__
> Are you planning to add more drivers that share this file? If not,
> just fold the contents into the driver itself.
Yes, we will add more drivers in this file.

lihuisong (C) April 25, 2023, 3:16 a.m. UTC | #4

Hi Krzysztof,
Thanks for your review. My reply is as follows.

在 2023/4/24 16:42, Krzysztof Kozlowski 写道:
> On 24/04/2023 09:30, Huisong Li wrote:
>> The Huawei Cache-Coherent System (HCCS) is a bus protocol standard
>> for ensuring cache coherent on HiSilicon SoC. The performance of
>> the application may be affected if some hccs ports are in non-full
>> lane status, have a large number of CRC errors and so on.
>>
>> This driver provides the query interface of the health status and
>> port information of HCCS on Kunpeng SoC.
>>
>> Signed-off-by: Huisong Li <[e-mail]>
>> ---
>>   MAINTAINERS                          |    6 +
>>   drivers/soc/Kconfig                  |    1 +
>>   drivers/soc/Makefile                 |    1 +
>>   drivers/soc/hisilicon/Kconfig        |   18 +
>>   drivers/soc/hisilicon/Makefile       |    2 +
>>   drivers/soc/hisilicon/kunpeng_hccs.c | 1296 ++++++++++++++++++++++++++
>>   drivers/soc/hisilicon/kunpeng_hccs.h |  204 ++++
>>   7 files changed, 1528 insertions(+)
>>   create mode 100644 drivers/soc/hisilicon/Kconfig
>>   create mode 100644 drivers/soc/hisilicon/Makefile
>>   create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
>>   create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index eddbc48c61e9..fe0e796e8445 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -9399,6 +9399,12 @@ S:	Maintained
>>   W:	http://www.hisilicon.com
>>   F:	drivers/spi/spi-hisi-sfc-v3xx.c
>>   
>> +HISILICON KUNPENG SOC HCCS DRIVER
>> +M:	Huisong Li <[e-mail]>
>> +S:	Maintained
>> +F:	drivers/soc/hisilicon/kunpeng_hccs.c
>> +F:	drivers/soc/hisilicon/kunpeng_hccs.h
>> +
>>   HMM - Heterogeneous Memory Management
>>   M:	Jérôme Glisse <[e-mail]>
>>   L:	[e-mail]
>> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
>> index 4e176280113a..d21e75d69294 100644
>> --- a/drivers/soc/Kconfig
>> +++ b/drivers/soc/Kconfig
>> @@ -10,6 +10,7 @@ source "drivers/soc/bcm/Kconfig"
>>   source "drivers/soc/canaan/Kconfig"
>>   source "drivers/soc/fsl/Kconfig"
>>   source "drivers/soc/fujitsu/Kconfig"
>> +source "drivers/soc/hisilicon/Kconfig"
>>   source "drivers/soc/imx/Kconfig"
>>   source "drivers/soc/ixp4xx/Kconfig"
>>   source "drivers/soc/litex/Kconfig"
>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
>> index 3b0f9fb3b5c8..531f46f3ad98 100644
>> --- a/drivers/soc/Makefile
>> +++ b/drivers/soc/Makefile
>> @@ -14,6 +14,7 @@ obj-$(CONFIG_MACH_DOVE)		+= dove/
>>   obj-y				+= fsl/
>>   obj-y				+= fujitsu/
>>   obj-$(CONFIG_ARCH_GEMINI)	+= gemini/
>> +obj-y				+= hisilicon/
>>   obj-y				+= imx/
>>   obj-y				+= ixp4xx/
>>   obj-$(CONFIG_SOC_XWAY)		+= lantiq/
>> diff --git a/drivers/soc/hisilicon/Kconfig b/drivers/soc/hisilicon/Kconfig
>> new file mode 100644
>> index 000000000000..81768d47f572
>> --- /dev/null
>> +++ b/drivers/soc/hisilicon/Kconfig
>> @@ -0,0 +1,18 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +
>> +menu "Hisilicon SoC drivers"
>> +	depends on ARCH_HISI
>> +
>> +config KUNPENG_HCCS
>> +	tristate "HCCS driver on Kunpeng SoC"
>> +	depends on ARM64 && ACPI
>> +	help
>> +	  The Huawei Cache-Coherent System (HCCS) is a bus protocol standard
>> +	  for ensuring cache coherent on HiSilicon SoC. The performance of
>> +	  the application may be affected if some hccs ports are in non-full
>> +	  lane status, have a large number of CRC errors and so on.
>> +
>> +	  Say M here if you want to include support for querying the health
>> +	  status and port information of HCCS on Kunpeng SoC.
>> +
>> +endmenu
>> diff --git a/drivers/soc/hisilicon/Makefile b/drivers/soc/hisilicon/Makefile
>> new file mode 100644
>> index 000000000000..226e747e70d6
>> --- /dev/null
>> +++ b/drivers/soc/hisilicon/Makefile
>> @@ -0,0 +1,2 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +obj-$(CONFIG_KUNPENG_HCCS)	+= kunpeng_hccs.o
>> diff --git a/drivers/soc/hisilicon/kunpeng_hccs.c b/drivers/soc/hisilicon/kunpeng_hccs.c
>> new file mode 100644
>> index 000000000000..2b52f7dedc78
>> --- /dev/null
>> +++ b/drivers/soc/hisilicon/kunpeng_hccs.c
>> @@ -0,0 +1,1296 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * The Huawei Cache-Coherent System (HCCS) is a bus protocol standard for
>> + * ensuring cache coherent on HiSilicon SoC.
>> + *
>> + * Copyright (c) 2023 Hisilicon Limited.
>> + * Author: Huisong Li <[e-mail]>
>> + *
>> + * HCCS driver for Kunpeng SoC provides the following features:
>> + * - Retrieve info as belows each port:
>> + *    - port type
>> + *    - lane mode
>> + *    - using status
>> + *    - current lane mode
>> + *    - link state machine
>> + *    - lane mask
>> + *    - CRC error count
>> + *
>> + * - Retrieve info as belows all ports on die or chip:
>> + *    - if all used ports are in linked
>> + *    - if all linked ports are in full lane
>> + *    - CRC error count sum
>> + */
>> +#include <linux/sysfs.h>
>> +#include <linux/acpi.h>
>> +#include <linux/io.h>
>> +#include <linux/kobject.h>
>> +#include <linux/iopoll.h>
>> +#include <linux/platform_device.h>
>> +#include <acpi/pcc.h>
>> +
>> +#include "kunpeng_hccs.h"
>> +
>> +/* PCC defines */
>> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
>> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
>> +
>> +/*
>> + * Arbitrary retries in case the remote processor is slow to respond
>> + * to PCC commands
>> + */
>> +#define HCCS_PCC_CMD_WAIT_RETRIES_NUM		500ULL
>> +#define HCCS_POLL_STATUS_TIME_INTERVAL_US	3
>> +
>> +static struct hccs_port_info *kobj_to_port_info(struct kobject *k)
>> +{
>> +	return container_of(k, struct hccs_port_info, kobj);
>> +}
>> +
>> +static struct hccs_die_info *kobj_to_die_info(struct kobject *k)
>> +{
>> +	return container_of(k, struct hccs_die_info, kobj);
>> +}
>> +
>> +static struct hccs_chip_info *kobj_to_chip_info(struct kobject *k)
>> +{
>> +	return container_of(k, struct hccs_chip_info, kobj);
>> +}
>> +
>> +static bool hccs_dev_property_supported(struct hccs_dev *hdev)
>> +{
>> +	struct device *dev = hdev->dev;
>> +
>> +	if (hdev->intr_mode) {
>> +		dev_err(dev, "interrupt mode is unsupported.\n");
>> +		return false;
>> +	}
>> +
>> +	if (hdev->type >= ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE) {
>> +		dev_err(dev, "PCC type-%u is unsupported.\n", hdev->type);
>> +		return false;
>> +	}
>> +
>> +	return true;
>> +}
>> +
>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>> +{
>> +	struct device *dev = hdev->dev;
>> +
>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>> +		dev_err(hdev->dev, "no device-flags property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>> +	if (!hccs_dev_property_supported(hdev))
> Maybe leave a comment that all these are ACPI-only and are not allowed
> in DT usage. Without bindings we are not going to review them. OTOH, I
> think we don't have a process for such cases in general.
Thanks for your suggestion. will add it.
>
>> +		return -EOPNOTSUPP;
>> +
>> +	return 0;
>> +}
>> +
> (...)
>
>> +static struct attribute *hccs_chip_default_attrs[] = {
>> +	&all_linked_on_chip_attr.attr,
>> +	&linked_full_lane_on_chip_attr.attr,
>> +	&crc_err_cnt_sum_on_chip_attr.attr,
>> +	NULL,
>> +};
>> +ATTRIBUTE_GROUPS(hccs_chip_default);
>> +
>> +static const struct kobj_type hccs_chip_type = {
>> +	.sysfs_ops = &hccs_comm_ops,
>> +	.default_groups = hccs_chip_default_groups,
> Missing sysfs documentation.
I will add another patch to do this.
>
> This also looks like:
> 1. Duplicating parts of socinfo.
Where is the duplicating part. Sorry, I cannot get it.
> 2. Open-coding coding sysfs API.
I cannot understand it. Can you be more specific?
>
> Anyway, after describing this API it might turn out it is not valid for
> upstream usage...
>
>> +};
>> +
>> +static void hccs_remove_die_dir(struct hccs_die_info *die)
>> +{
>> +	struct hccs_port_info *port;
>> +	u8 i;
>> +
>> +	for (i = 0; i < die->port_num; i++) {
>> +		port = &die->ports[i];
>> +		if (port->dir_created)
>> +			kobject_put(&port->kobj);
>> +	}
>> +
>> +	kobject_put(&die->kobj);
>> +}
>> +
>> +static void hccs_remove_chip_dir(struct hccs_chip_info *chip)
>> +{
>> +	struct hccs_die_info *die;
>> +	u8 i;
>> +
>> +	for (i = 0; i < chip->die_num; i++) {
>> +		die = &chip->dies[i];
>> +		if (die->dir_created)
>> +			hccs_remove_die_dir(die);
>> +	}
>> +
>> +	kobject_put(&chip->kobj);
>> +}
>> +
>> +static void hccs_remove_topo_dirs(struct hccs_dev *hdev)
>> +{
>> +	u8 i;
>> +
>> +	for (i = 0; i < hdev->chip_num; i++)
>> +		hccs_remove_chip_dir(&hdev->chips[i]);
>> +}
>> +
>> +static int hccs_create_hccs_dir(struct hccs_dev *hdev,
>> +				struct hccs_die_info *die,
>> +				struct hccs_port_info *port)
>> +{
>> +	int ret;
>> +
>> +	ret = kobject_init_and_add(&port->kobj, &hccs_port_type,
>> +				   &die->kobj, "hccs%d", port->port_id);
>> +	if (ret) {
>> +		kobject_put(&port->kobj);
>> +		return ret;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +static int hccs_create_die_dir(struct hccs_dev *hdev,
>> +			       struct hccs_chip_info *chip,
>> +			       struct hccs_die_info *die)
>> +{
>> +	struct hccs_port_info *port;
>> +	int ret;
>> +	u16 i;
>> +
>> +	ret = kobject_init_and_add(&die->kobj, &hccs_die_type,
>> +				   &chip->kobj, "die%d", die->die_id);
>> +	if (ret) {
>> +		kobject_put(&die->kobj);
>> +		return ret;
>> +	}
>> +
>> +	for (i = 0; i < die->port_num; i++) {
>> +		port = &die->ports[i];
>> +		ret = hccs_create_hccs_dir(hdev, die, port);
>> +		if (ret) {
>> +			dev_err(hdev->dev, "create hccs%d dir failed.\n",
>> +				port->port_id);
>> +			goto err;
>> +		}
>> +		port->dir_created = true;
>> +	}
>> +
>> +	return 0;
>> +err:
>> +	hccs_remove_die_dir(die);
>> +
>> +	return ret;
>> +}
>> +
>> +static int hccs_create_chip_dir(struct hccs_dev *hdev,
>> +				struct hccs_chip_info *chip)
>> +{
>> +	struct hccs_die_info *die;
>> +	int ret;
>> +	u16 id;
>> +
>> +	ret = kobject_init_and_add(&chip->kobj, &hccs_chip_type,
>> +				   &hdev->dev->kobj, "chip%d", chip->chip_id);
>> +	if (ret) {
>> +		kobject_put(&chip->kobj);
>> +		return ret;
>> +	}
>> +
>> +	for (id = 0; id < chip->die_num; id++) {
>> +		die = &chip->dies[id];
>> +		ret = hccs_create_die_dir(hdev, chip, die);
>> +		if (ret)
>> +			goto err;
>> +		die->dir_created = true;
>> +	}
>> +
>> +	return 0;
>> +err:
>> +	hccs_remove_chip_dir(chip);
>> +
>> +	return ret;
>> +}
>> +
>> +static int hccs_create_topo_dirs(struct hccs_dev *hdev)
>> +{
>> +	struct hccs_chip_info *chip;
>> +	u8 id, k;
>> +	int ret;
>> +
>> +	for (id = 0; id < hdev->chip_num; id++) {
>> +		chip = &hdev->chips[id];
>> +		ret = hccs_create_chip_dir(hdev, chip);
>> +		if (ret) {
>> +			dev_err(hdev->dev, "init chip%d dir failed!\n", id);
>> +			goto err;
>> +		}
>> +	}
>> +
>> +	return 0;
>> +err:
>> +	for (k = 0; k < id; k++)
>> +		hccs_remove_chip_dir(&hdev->chips[k]);
>> +
>> +	return ret;
>> +}
>> +
>> +static int hccs_probe(struct platform_device *pdev)
>> +{
>> +	struct acpi_device *acpi_dev;
>> +	struct hccs_dev *hdev;
>> +	int rc;
>> +
>> +	pr_info("kunpeng_hccs is initializing.\n");
> Drop.
Ack.
>
>> +
>> +	if (acpi_disabled) {
>> +		dev_err(&pdev->dev, "acpi is disabled.\n");
> Is it possible for your ACPI-only driver?
Yes
>
>
>> +		return -ENODEV;
>> +	}
>> +	acpi_dev = ACPI_COMPANION(&pdev->dev);
>> +	if (!acpi_dev)
>> +		return -ENODEV;
>> +
>> +	hdev = devm_kzalloc(&pdev->dev, sizeof(*hdev), GFP_KERNEL);
>> +	if (!hdev)
>> +		return -ENOMEM;
>> +	hdev->acpi_dev = acpi_dev;
>> +	hdev->dev = &pdev->dev;
>> +	platform_set_drvdata(pdev, hdev);
>> +
>> +	rc = hccs_get_device_property(hdev);
>> +	if (rc)
>> +		return rc;
>> +
>> +	mutex_init(&hdev->lock);
>> +
>> +	rc = hccs_register_pcc_channel(hdev);
>> +	if (rc)
>> +		return rc;
>> +
>> +	rc = hccs_get_dev_caps(hdev);
>> +	if (rc)
>> +		goto err_uninit_mbox_client;
>> +
>> +	rc = hccs_get_hw_info(hdev);
>> +	if (rc)
>> +		goto err_uninit_mbox_client;
>> +
>> +	rc = hccs_create_topo_dirs(hdev);
>> +	if (rc)
>> +		goto err_uninit_mbox_client;
>> +
>> +	dev_info(&pdev->dev, "HISI HCCS driver registered!\n");
> Drop simple probe success msgs. There's already kernel infrastructure
> giving you this information.
All right, drop it.
>
>> +
>> +	return 0;
>> +
>> +err_uninit_mbox_client:
>> +	hccs_unregister_pcc_channel(hdev);
>> +
>> +	return rc;
>> +}
>> +
>> +static int hccs_remove(struct platform_device *pdev)
>> +{
>> +	struct hccs_dev *hdev = platform_get_drvdata(pdev);
>> +
>> +	hccs_remove_topo_dirs(hdev);
>> +	hccs_unregister_pcc_channel(hdev);
>> +
>> +	return 0;
>> +}
>> +
>> +static const struct acpi_device_id hccs_acpi_match[] = {
>> +	{ "HISI04B1", },
>> +};
>> +
>> +static struct platform_driver hccs_driver = {
>> +	.probe = hccs_probe,
>> +	.remove = hccs_remove,
>> +	.driver = {
>> +		.name = "kunpeng_hccs",
>> +		.acpi_match_table = ACPI_PTR(hccs_acpi_match),
> Drop ACPI_PTR as it is not balanced with __maybe_unused.
ok, will drop it in v2.

Arnd Bergmann April 25, 2023, 6:08 a.m. UTC | #5

On Tue, Apr 25, 2023, at 05:04, lihuisong (C) wrote:
> 在 2023/4/24 16:09, Arnd Bergmann 写道:
>> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:

>>         depends on ACPI
>>         depends on (ARM64 && ARCH_HISI) || COMPILE_TEST
> What do you think of adjusting it as below?
> menu "Hisilicon SoC drivers"
>      depends on ARCH_HISI || COMPILE_TEST
>
> config KUNPENG_HCCS
>      depends on ACPI
>      depends on ARM64 || COMPILE_TEST

Yes, that's perfect.

>>
>>> +
>>> +#include "kunpeng_hccs.h"
>>> +
>>> +/* PCC defines */
>>> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
>>> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
>> Should these perhaps be in include/acpi/pcc.h? The 0x50434300
>> number is just "PCC\0", so it appears to not be HCCS specific.
> This is a PCC signature. As stated in the APCI,
> "The signature of a subspace is computed by a bitwiseor of the value 
> 0x50434300
> with the subspace ID. For example, subspace 3 has the signature 0x50434303."
>
> I am not sure if all driver need to use this fixed signature mask.
> As far as I know, cppc_acpi.c didn't use this signature and 
> xgene-hwmon.c used another mask defined in its driver.
> So I place it here.

I would still put it into the generic header, but it doesn't
really matter much, so do it whichever way you prefer. No need
for a separate patch if you decide to use the global header,
it can just be part of your normal patch.

>>> +
>>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>>> +{
>>> +	struct device *dev = hdev->dev;
>>> +
>>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>>> +		dev_err(hdev->dev, "no device-flags property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>>> +	if (!hccs_dev_property_supported(hdev))
>>> +		return -EOPNOTSUPP;
>>> +
>> Where are the device properties documented? I'm never quite sure how
>> to handle these for ACPI-only drivers, since we don't normally have the
>> bindings in Documentation/devicetree/bindings/, but it feels like there
>> should be some properly reviewed document somewhere else.
> These are ACPI-only, instead of DT.
> I will add a comment here as Krzysztof suggested.

I understand that they are ACPI-only, what I'm more interested here is
the general question of how we should document them, to ensure these
are handled consistently across drivers.

>>> --- /dev/null
>>> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
>>> @@ -0,0 +1,204 @@
>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>> +/* Copyright (c) 2023 Hisilicon Limited. */
>>> +
>>> +#ifndef __KUNPENG_HCCS_H__
>>> +#define __KUNPENG_HCCS_H__
>> Are you planning to add more drivers that share this file? If not,
>> just fold the contents into the driver itself.
> Yes, we will add more drivers in this file.

Ok.


       Arnd

lihuisong (C) April 25, 2023, 9:42 a.m. UTC | #6

在 2023/4/25 14:08, Arnd Bergmann 写道:
> On Tue, Apr 25, 2023, at 05:04, lihuisong (C) wrote:
>> 在 2023/4/24 16:09, Arnd Bergmann 写道:
>>> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:
>>>          depends on ACPI
>>>          depends on (ARM64 && ARCH_HISI) || COMPILE_TEST
>> What do you think of adjusting it as below?
>> menu "Hisilicon SoC drivers"
>>       depends on ARCH_HISI || COMPILE_TEST
>>
>> config KUNPENG_HCCS
>>       depends on ACPI
>>       depends on ARM64 || COMPILE_TEST
> Yes, that's perfect.
>
>>>> +
>>>> +#include "kunpeng_hccs.h"
>>>> +
>>>> +/* PCC defines */
>>>> +#define HCCS_PCC_SIGNATURE_MASK		0x50434300
>>>> +#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
>>> Should these perhaps be in include/acpi/pcc.h? The 0x50434300
>>> number is just "PCC\0", so it appears to not be HCCS specific.
>> This is a PCC signature. As stated in the APCI,
>> "The signature of a subspace is computed by a bitwiseor of the value
>> 0x50434300
>> with the subspace ID. For example, subspace 3 has the signature 0x50434303."
>>
>> I am not sure if all driver need to use this fixed signature mask.
>> As far as I know, cppc_acpi.c didn't use this signature and
>> xgene-hwmon.c used another mask defined in its driver.
>> So I place it here.
> I would still put it into the generic header, but it doesn't
> really matter much, so do it whichever way you prefer. No need
> for a separate patch if you decide to use the global header,
> it can just be part of your normal patch.
ok, keep it the way it is now.
>
>>>> +
>>>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>>>> +{
>>>> +	struct device *dev = hdev->dev;
>>>> +
>>>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>>>> +		dev_err(hdev->dev, "no device-flags property.\n");
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>>>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>>>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>>>> +		return -ENODEV;
>>>> +	}
>>>> +
>>>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>>>> +	if (!hccs_dev_property_supported(hdev))
>>>> +		return -EOPNOTSUPP;
>>>> +
>>> Where are the device properties documented? I'm never quite sure how
>>> to handle these for ACPI-only drivers, since we don't normally have the
>>> bindings in Documentation/devicetree/bindings/, but it feels like there
>>> should be some properly reviewed document somewhere else.
>> These are ACPI-only, instead of DT.
>> I will add a comment here as Krzysztof suggested.
> I understand that they are ACPI-only, what I'm more interested here is
> the general question of how we should document them, to ensure these
> are handled consistently across drivers.
These device properties are reported by ACPI table in firmware.
They are fixed in platform firmware. The user cannot modify them.
Do we need to document them?
>
>>>> --- /dev/null
>>>> +++ b/drivers/soc/hisilicon/kunpeng_hccs.h
>>>> @@ -0,0 +1,204 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0+ */
>>>> +/* Copyright (c) 2023 Hisilicon Limited. */
>>>> +
>>>> +#ifndef __KUNPENG_HCCS_H__
>>>> +#define __KUNPENG_HCCS_H__
>>> Are you planning to add more drivers that share this file? If not,
>>> just fold the contents into the driver itself.
>> Yes, we will add more drivers in this file.
> Ok.
>
>
>         Arnd
> .

Sudeep Holla April 25, 2023, 10:30 a.m. UTC | #7

Thanks Arnd for cc-ing the ALKML.

On Mon, Apr 24, 2023 at 10:09:47AM +0200, Arnd Bergmann wrote:
> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:

[...]

> > +
> > +static int hccs_get_device_property(struct hccs_dev *hdev)
> > +{
> > +	struct device *dev = hdev->dev;
> > +
> > +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
> > +		dev_err(hdev->dev, "no device-flags property.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
> > +		dev_err(hdev->dev, "no pcc-type property.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
> > +		dev_err(hdev->dev, "no pcc-channel property.\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
> > +	if (!hccs_dev_property_supported(hdev))
> > +		return -EOPNOTSUPP;
> > +
>
> Where are the device properties documented? I'm never quite sure how
> to handle these for ACPI-only drivers, since we don't normally have the
> bindings in Documentation/devicetree/bindings/, but it feels like there
> should be some properly reviewed document somewhere else.
>
> Adding ACPI and devicetree maintainers to Cc for clarification.

Why are these DSD style properties added here ? Why can't we just make
use of _CRS with Generic Address Structure(GAS) register entry for each
of the PCC channel which eliminates the need of "pcc-chan-id". The type
must be deduced from the order in the list of _CRS if needed. I don't
quite understand what magic the flags contain here to provide any info
there.

--
Regards,
Sudeep

Sudeep Holla April 25, 2023, 11:24 a.m. UTC | #8

On Tue, Apr 25, 2023 at 11:16:32AM +0800, lihuisong (C) wrote:
> Hi Krzysztof,
> Thanks for your review. My reply is as follows.
> 
> 在 2023/4/24 16:42, Krzysztof Kozlowski 写道:

[...]

> > Maybe leave a comment that all these are ACPI-only and are not allowed
> > in DT usage. Without bindings we are not going to review them. OTOH, I
> > think we don't have a process for such cases in general.
> Thanks for your suggestion. will add it.

Please look at my response and continue the discussion as why _CRS can't
be used[1] before you add any DT bindings. I would prefer to avoid any
DSD style properties especially if it is used only in ACPI.

lihuisong (C) April 25, 2023, 1 p.m. UTC | #9

在 2023/4/25 18:30, Sudeep Holla 写道:
> Thanks Arnd for cc-ing the ALKML.
>
> On Mon, Apr 24, 2023 at 10:09:47AM +0200, Arnd Bergmann wrote:
>> On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:
> [...]
>
>>> +
>>> +static int hccs_get_device_property(struct hccs_dev *hdev)
>>> +{
>>> +	struct device *dev = hdev->dev;
>>> +
>>> +	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
>>> +		dev_err(hdev->dev, "no device-flags property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
>>> +		dev_err(hdev->dev, "no pcc-type property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
>>> +		dev_err(hdev->dev, "no pcc-channel property.\n");
>>> +		return -ENODEV;
>>> +	}
>>> +
>>> +	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
>>> +	if (!hccs_dev_property_supported(hdev))
>>> +		return -EOPNOTSUPP;
>>> +
>> Where are the device properties documented? I'm never quite sure how
>> to handle these for ACPI-only drivers, since we don't normally have the
>> bindings in Documentation/devicetree/bindings/, but it feels like there
>> should be some properly reviewed document somewhere else.
>>
>> Adding ACPI and devicetree maintainers to Cc for clarification.
> Why are these DSD style properties added here ? Why can't we just make
> use of _CRS with Generic Address Structure(GAS) register entry for each
> of the PCC channel which eliminates the need of "pcc-chan-id". The type
> must be deduced from the order in the list of _CRS if needed. I don't
For firmware, DSD way is simpler and easier to manage these virtual 
platform devices,
and it's an usual way in kernel.
Driver only needs to get a fixed value, like pcc-id and type, here.

Any vantage if using _CRS with GAS compared with DSD?
> quite understand what magic the flags contain here to provide any info
> there.
This flag is used to report other properties, and every bit means a 
property.
For instance, driver doesn't need to request PCC channel during the 
probing phase if driver use PCC operation Region.
>
> .

Sudeep Holla April 25, 2023, 1:19 p.m. UTC | #10

On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
> 
> For firmware, DSD way is simpler and easier to manage these virtual platform
> devices, and it's an usual way in kernel.

Any specific examples you are referring here. We had lots of debate when
DSD was introduced. It must be used only when there is no standard ACPI
way to achieve the same. But in this I don't (yet) think that is the case.
Further "simplicity" is remotely not the reason why you must use DSD.
So until you provide me technical reasons as why _CRS can't work, I
have to NACK this approach. DSD in this case seems like pure hack.

> Driver only needs to get a fixed value, like pcc-id and type, here.
>

Yes and _CRS is used to get similar such properties in ACPI. It includes
normally MMIO and interrupts and since GAS supports PCC and _CRS can
contain GAS, you must simply use that.

> Any vantage if using _CRS with GAS compared with DSD?

Simple IMO, it is also existing standard to achieve things you are trying
to here and DSD is not. You are defining new properties to make DSD work.

So the real question is if _CRS can be used what is the point in defining
DSD for that. Unless I hear more technical and solid reasoning, I see
DSD as just hack and misuse here. It wasn't designed for that and must not
be allowed to make use of it for such use case.

Anyways in case we decide to take DSD route(after more deeper and technical
discussions), as in the kernel docs, please refer [1] for DSD. You need
to publish properties there so that no one comes up with similar but
alternate solution to do exactly this.

> > quite understand what magic the flags contain here to provide any info
> > there.
> This flag is used to report other properties, and every bit means a
> property.
> For instance, driver doesn't need to request PCC channel during the probing
> phase if driver use PCC operation Region.

Sorry I still don't understand it fully.

lihuisong (C) April 26, 2023, 12:12 p.m. UTC | #11

在 2023/4/25 21:19, Sudeep Holla 写道:
> On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
>> For firmware, DSD way is simpler and easier to manage these virtual platform
>> devices, and it's an usual way in kernel.
> Any specific examples you are referring here. We had lots of debate when
> DSD was introduced. It must be used only when there is no standard ACPI
> way to achieve the same. But in this I don't (yet) think that is the case.
> Further "simplicity" is remotely not the reason why you must use DSD.
> So until you provide me technical reasons as why _CRS can't work, I
> have to NACK this approach. DSD in this case seems like pure hack.
>
>> Driver only needs to get a fixed value, like pcc-id and type, here.
>>
> Yes and _CRS is used to get similar such properties in ACPI. It includes
> normally MMIO and interrupts and since GAS supports PCC and _CRS can
> contain GAS, you must simply use that.
Hi Sudeep,
Can you give me some usage examples about this? I will try to do it.
>
>> Any vantage if using _CRS with GAS compared with DSD?
> Simple IMO, it is also existing standard to achieve things you are trying
> to here and DSD is not. You are defining new properties to make DSD work.
>
> So the real question is if _CRS can be used what is the point in defining
> DSD for that. Unless I hear more technical and solid reasoning, I see
> DSD as just hack and misuse here. It wasn't designed for that and must not
> be allowed to make use of it for such use case.
>
> Anyways in case we decide to take DSD route(after more deeper and technical
> discussions), as in the kernel docs, please refer [1] for DSD. You need
> to publish properties there so that no one comes up with similar but
> alternate solution to do exactly this.
All right.
>
>>> quite understand what magic the flags contain here to provide any info
>>> there.
>> This flag is used to report other properties, and every bit means a
>> property.
>> For instance, driver doesn't need to request PCC channel during the probing
>> phase if driver use PCC operation Region.
> Sorry I still don't understand it fully.
If a driver uses type2 with polling way on one platform, and uses PCC 
operation Region way to obtain some information on other platform.
The driver doesn't need to request PCC channel when it uses PCC 
Operation Region.
So this driver must be aware of the communication way in advance in a 
way during initialization.

>

lihuisong (C) May 4, 2023, 1:16 p.m. UTC | #12

在 2023/4/25 21:19, Sudeep Holla 写道:
> On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
>> For firmware, DSD way is simpler and easier to manage these virtual platform
>> devices, and it's an usual way in kernel.
> Any specific examples you are referring here. We had lots of debate when
> DSD was introduced. It must be used only when there is no standard ACPI
> way to achieve the same. But in this I don't (yet) think that is the case.
> Further "simplicity" is remotely not the reason why you must use DSD.
> So until you provide me technical reasons as why _CRS can't work, I
> have to NACK this approach. DSD in this case seems like pure hack.
>
>> Driver only needs to get a fixed value, like pcc-id and type, here.
>>
> Yes and _CRS is used to get similar such properties in ACPI. It includes
> normally MMIO and interrupts and since GAS supports PCC and _CRS can
> contain GAS, you must simply use that.
Hi Sudeep,

I'm tring to use CRS with GAS to report PCC channel ID and get other 
informations driver need by address.
I found a way to obtain the generic register information according to 
"Referencing the PCC address space" in ACPI spec.
And driver also get the PCC generic register information successfully.

But I don't know how to set and use the address in PCC register.
Where should this address come from?
It seems that ACPI spec is not very detailed about this.
Do you have any suggestions?

On the other hand, we think that System Memory space + method can also 
achieve above goal.
What do you think of that?

Best regards,
Huisong

lihuisong (C) May 15, 2023, 3:37 a.m. UTC | #13

在 2023/5/4 21:16, lihuisong (C) 写道:
>
> 在 2023/4/25 21:19, Sudeep Holla 写道:
>> On Tue, Apr 25, 2023 at 09:00:31PM +0800, lihuisong (C) wrote:
>>> For firmware, DSD way is simpler and easier to manage these virtual 
>>> platform
>>> devices, and it's an usual way in kernel.
>> Any specific examples you are referring here. We had lots of debate when
>> DSD was introduced. It must be used only when there is no standard ACPI
>> way to achieve the same. But in this I don't (yet) think that is the 
>> case.
>> Further "simplicity" is remotely not the reason why you must use DSD.
>> So until you provide me technical reasons as why _CRS can't work, I
>> have to NACK this approach. DSD in this case seems like pure hack.
>>
>>> Driver only needs to get a fixed value, like pcc-id and type, here.
>>>
>> Yes and _CRS is used to get similar such properties in ACPI. It includes
>> normally MMIO and interrupts and since GAS supports PCC and _CRS can
>> contain GAS, you must simply use that.
> Hi Sudeep,
>
> I'm tring to use CRS with GAS to report PCC channel ID and get other 
> informations driver need by address.
> I found a way to obtain the generic register information according to 
> "Referencing the PCC address space" in ACPI spec.
> And driver also get the PCC generic register information successfully.
>
> But I don't know how to set and use the address in PCC register.
> Where should this address come from?
> It seems that ACPI spec is not very detailed about this.
> Do you have any suggestions?
>
> On the other hand, we think that System Memory space + method can also 
> achieve above goal.
> What do you think of that?
>
>
Hi Sudeep,

Can you give us some suggestions about above question and idea?

Looking forward to your reply.

/Huisong

Sudeep Holla May 15, 2023, 1:08 p.m. UTC | #14

On Thu, May 04, 2023 at 09:16:16PM +0800, lihuisong (C) wrote:
>
> I'm tring to use CRS with GAS to report PCC channel ID and get other
> informations driver need by address.

OK you had pcc-chan-id pcc-type and device-flags in the DSD style bindings
to begin with. I haven't understood device-flags here so can't comment on
that.

> I found a way to obtain the generic register information according to
> "Referencing the PCC address space" in ACPI spec.
> And driver also get the PCC generic register information successfully.
>

Can you elaborate ? I assume by that you must be able to get pcc-chan-id
right ? You must not need pcc-type as the pcc mailbox driver must handle
the type for you. If not, we may need to fix or add any missing support.

> But I don't know how to set and use the address in PCC register.

It must be same as what you would have specified in you new bindings
under "pcc-chan-id". I am confused as you say you were able to get the
PCC generic register information successfully but you still claim you
don't know how to set or use the address.

> Where should this address come from?
> It seems that ACPI spec is not very detailed about this.
> Do you have any suggestions?
>

I am afraid, I don't have any as I am failing to understand the exact issue
you are facing. 

Let me try to ask the question explicity here: 

If you are just referring to just the <RegisterAddress,> in

Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)

then,

RegisterAddress is usually the offset in the comms address associated with
the PCC subspace ID specified in AccessSize. Yes the use of AccessSize for
the PCC subspace ID is bit confusing though.

You can either list all the registers with _CRS individually or the driver
can just use the PCC subspace ID in AccessSize and keep RegisterAddress = 0
but access individual offset based on its own knowledge. I haven't seen the
full driver yet but I assuming that's how you would have used if you went with
your DSD pcc-chan-id proposal.

> On the other hand, we think that System Memory space + method can also
> achieve above goal. What do you think of that?

Again I don't understand what you mean by that.

lihuisong (C) May 16, 2023, 7:35 a.m. UTC | #15

在 2023/5/15 21:08, Sudeep Holla 写道:
> On Thu, May 04, 2023 at 09:16:16PM +0800, lihuisong (C) wrote:
>> I'm tring to use CRS with GAS to report PCC channel ID and get other
>> informations driver need by address.
> OK you had pcc-chan-id pcc-type and device-flags in the DSD style bindings
> to begin with. I haven't understood device-flags here so can't comment on
> that.

We want to use the 'device-flags' to report some information by bit.
Currently, this driver requests PCC channel and use type2 to communicate 
with firmware.
But, if some platform support type3 and PCC Operation Region, driver can 
choice this method to communicate with firmware.
So firmware and driver have to use this flag to make compatibility.

>
>> I found a way to obtain the generic register information according to
>> "Referencing the PCC address space" in ACPI spec.
>> And driver also get the PCC generic register information successfully.
>>
> Can you elaborate ? I assume by that you must be able to get pcc-chan-id

Yes，driver can get pcc-chan-id by below register.

Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)

> right ? You must not need pcc-type as the pcc mailbox driver must handle
> the type for you. If not, we may need to fix or add any missing support.
Yes, PCC driver doesn't support it currently. And aother patch [1] we've 
been talking about does it.
If it is applied to kernel, we can drop this pcc-type here.

[1] 
https://patchwork.kernel.org/project/linux-acpi/patch/[e-mail]/
>
>> But I don't know how to set and use the address in PCC register.
> It must be same as what you would have specified in you new bindings
> under "pcc-chan-id". I am confused as you say you were able to get the
> PCC generic register information successfully but you still claim you
> don't know how to set or use the address.
My confusion about this address is mentioned below.
>> Where should this address come from?
>> It seems that ACPI spec is not very detailed about this.
>> Do you have any suggestions?
>>
> I am afraid, I don't have any as I am failing to understand the exact issue
> you are facing.
>
> Let me try to ask the question explicity here:
>
> If you are just referring to just the <RegisterAddress,> in
>
> Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)
Yeah, this is what I'm using.
>
> then,
>
> RegisterAddress is usually the offset in the comms address associated with
Communication subspace in share memory of PCC subspace?
> the PCC subspace ID specified in AccessSize. Yes the use of AccessSize for
> the PCC subspace ID is bit confusing though.
>
> You can either list all the registers with _CRS individually or the driver
List all the registers as following way?
Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
{
     QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, 
NonCacheable, ReadWrite,
         0x0000000000000000, // Granularity
         0x0000000098190000, // Range Minimum
         0x000000009819FFFF, // Range Maximum
         0x0000000000000000, // Translation Offset
         0x0000000000010000, // Length
         ,, , AddressRangeMemory, TypeStatic)
})
> can just use the PCC subspace ID in AccessSize and keep RegisterAddress = 0
> but access individual offset based on its own knowledge. I haven't seen the
Following words come from ACPI spec.
-->
As an example, the following resource template refers to the feld 
occupying bits 8 through 15 at address 0x30 in PCC
subspace 9:
ResourceTemplate()
{
Register (
     PCC, //AddressSpaceKeyword
     8, //RegisterBitWidth
     8, //RegisterBitOffset
     0x30, //RegisterAddress
     9 //AccessSize (subspace ID)
     )
}

If the width of the address is 32bit, set RegisterAddress to 0, 
RegisterBitOffset to 0 and set RegisterBitWidth to 64 here.
Driver can access to the ((void __iomem *)pcc_comm_addr + 0x8 + 0) and 
((void __iomem *)pcc_comm_addr + 0x8 + 4) address，right?
(This virtual address = pcc mapped address + header size + offset within 
PCC subspace.)
> full driver yet but I assuming that's how you would have used if you went with
> your DSD pcc-chan-id proposal.
>
>> On the other hand, we think that System Memory space + method can also
>> achieve above goal. What do you think of that?
> Again I don't understand what you mean by that.
Sorry, here is what I want to say.
-->
OperationRegion (CCS0, SystemMemory, 0x00000002081000CC, 0x04)
Field (CCS0, DWordAcc, NoLock, Preserve)
{
     HAU1,   32
}
OperationRegion (CCS1, SystemMemory, 0x0000000201070410, 0x04)
Field (CCS1, DWordAcc, NoLock, Preserve)
{
     HCGE,   32
}
Method (_DSM, 2, Serialized)  // _DSM: Device-Specific Method
{
     If ((Arg0 == ToUUID ("b06b81ab-0134-4a45-9b0c-483447b95fa7")))
     {
         If ((Arg1 == One))
         {
             Return (HAU1)
         }

         Return (HCGE)
     }
}

Driver can call _DSM method to get some information, such as pcc_chan_id 
and device_flags.
>

Sudeep Holla May 16, 2023, 12:29 p.m. UTC | #16

On Tue, May 16, 2023 at 03:35:54PM +0800, lihuisong (C) wrote:
>
> 在 2023/5/15 21:08, Sudeep Holla 写道:
> > On Thu, May 04, 2023 at 09:16:16PM +0800, lihuisong (C) wrote:
> > > I'm tring to use CRS with GAS to report PCC channel ID and get other
> > > informations driver need by address.
> > OK you had pcc-chan-id pcc-type and device-flags in the DSD style bindings
> > to begin with. I haven't understood device-flags here so can't comment on
> > that.
>
> We want to use the 'device-flags' to report some information by bit.

Please give more details, until then NACK for the idea.

> Currently, this driver requests PCC channel and use type2 to communicate
> with firmware.

OKAY...

> But, if some platform support type3 and PCC Operation Region, driver can
> choice this method to communicate with firmware.
> So firmware and driver have to use this flag to make compatibility.
>

I would rather add such things to the spec if it is any sort of limitation
with the current specification.

> >
> > > I found a way to obtain the generic register information according to
> > > "Referencing the PCC address space" in ACPI spec.
> > > And driver also get the PCC generic register information successfully.
> > >
> > Can you elaborate ? I assume by that you must be able to get pcc-chan-id
>
> Yes，driver can get pcc-chan-id by below register.
>
> Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)
>

Good to know.

> > right ? You must not need pcc-type as the pcc mailbox driver must handle
> > the type for you. If not, we may need to fix or add any missing support.
> Yes, PCC driver doesn't support it currently. And aother patch [1] we've
> been talking about does it.
> If it is applied to kernel, we can drop this pcc-type here.
>
> [1] https://patchwork.kernel.org/project/linux-acpi/patch/[e-mail]/

OK then we are good, no need for pcc-type then ?

> >
> > > But I don't know how to set and use the address in PCC register.
> > It must be same as what you would have specified in you new bindings
> > under "pcc-chan-id". I am confused as you say you were able to get the
> > PCC generic register information successfully but you still claim you
> > don't know how to set or use the address.
> My confusion about this address is mentioned below.

OK

> > > Where should this address come from?
> > > It seems that ACPI spec is not very detailed about this.
> > > Do you have any suggestions?
> > >
> > I am afraid, I don't have any as I am failing to understand the exact issue
> > you are facing.
> >
> > Let me try to ask the question explicity here:
> >
> > If you are just referring to just the <RegisterAddress,> in
> >
> > Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)
> Yeah, this is what I'm using.
> >
> > then,
> >
> > RegisterAddress is usually the offset in the comms address associated with
> Communication subspace in share memory of PCC subspace?
> > the PCC subspace ID specified in AccessSize. Yes the use of AccessSize for
> > the PCC subspace ID is bit confusing though.
> >
> > You can either list all the registers with _CRS individually or the driver
> List all the registers as following way?
> Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
> {
>     QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
> NonCacheable, ReadWrite,
>         0x0000000000000000, // Granularity
>         0x0000000098190000, // Range Minimum
>         0x000000009819FFFF, // Range Maximum
>         0x0000000000000000, // Translation Offset
>         0x0000000000010000, // Length
>         ,, , AddressRangeMemory, TypeStatic)
> })

Not sure if you can use QWordMemory here TBH.

> > can just use the PCC subspace ID in AccessSize and keep RegisterAddress = 0
> > but access individual offset based on its own knowledge. I haven't seen the
> Following words come from ACPI spec.
> -->
> As an example, the following resource template refers to the feld occupying
> bits 8 through 15 at address 0x30 in PCC
> subspace 9:
> ResourceTemplate()
> {
> Register (
>     PCC, //AddressSpaceKeyword
>     8, //RegisterBitWidth
>     8, //RegisterBitOffset
>    pcc 0x30, //RegisterAddress
>     9 //AccessSize (subspace ID)
>     )
> }
>
> If the width of the address is 32bit, set RegisterAddress to 0,
> RegisterBitOffset to 0 and set RegisterBitWidth to 64 here.
> Driver can access to the ((void __iomem *)pcc_comm_addr + 0x8 + 0) and
> ((void __iomem *)pcc_comm_addr + 0x8 + 4) address，right?
> (This virtual address = pcc mapped address + header size + offset within PCC
> subspace.)

Yes that's my understanding. I remember seeing the driver is just fetching
pcc-chan-id using DSD style key-value pair, which means you don't need
any other info other than the PCC subspace/channel ID, just have address
as 0.

Also I see the driver uses type for just rejecting the type 3 PCCT. The
question is will the driver probe and run on a platform with type 3 PCCT ?
If so what is the problem running on such a platform. I see it is useless
check in the driver and can be dropped. Also the comment above enum
HCCS_DEV_FLAGS_INTR_B is confusing and  so is the way flags is used.

> > full driver yet but I assuming that's how you would have used if you went with
> > your DSD pcc-chan-id proposal.
> >
> > > On the other hand, we think that System Memory space + method can also
> > > achieve above goal. What do you think of that?
> > Again I don't understand what you mean by that.
> Sorry, here is what I want to say.
> -->
> OperationRegion (CCS0, SystemMemory, 0x00000002081000CC, 0x04)
> Field (CCS0, DWordAcc, NoLock, Preserve)
> {
>     HAU1,   32
> }
> OperationRegion (CCS1, SystemMemory, 0x0000000201070410, 0x04)
> Field (CCS1, DWordAcc, NoLock, Preserve)
> {
>     HCGE,   32
> }
> Method (_DSM, 2, Serialized)  // _DSM: Device-Specific Method
> {
>     If ((Arg0 == ToUUID ("b06b81ab-0134-4a45-9b0c-483447b95fa7")))
>     {
>         If ((Arg1 == One))
>         {
>             Return (HAU1)
>         }
>
>         Return (HCGE)
>     }
> }
>
> Driver can call _DSM method to get some information, such as pcc_chan_id and
> device_flags.

Big fat NACK for _DSM for the above purpose, please stop abusing _DSM or _DSD
for such information which can be obtained with the existing _CRS.

--
Regards,
Sudeep

lihuisong (C) May 16, 2023, 2:13 p.m. UTC | #17

Hi Sudeep,

Thanks for your reply.


在 2023/5/16 20:29, Sudeep Holla 写道:
> On Tue, May 16, 2023 at 03:35:54PM +0800, lihuisong (C) wrote:
>> 在 2023/5/15 21:08, Sudeep Holla 写道:
>>> On Thu, May 04, 2023 at 09:16:16PM +0800, lihuisong (C) wrote:
>>>> I'm tring to use CRS with GAS to report PCC channel ID and get other
>>>> informations driver need by address.
>>> OK you had pcc-chan-id pcc-type and device-flags in the DSD style bindings
>>> to begin with. I haven't understood device-flags here so can't comment on
>>> that.
>> We want to use the 'device-flags' to report some information by bit.
> Please give more details, until then NACK for the idea.
ok.
>
>> Currently, this driver requests PCC channel and use type2 to communicate
>> with firmware.
> OKAY...
>
>> But, if some platform support type3 and PCC Operation Region, driver can
>> choice this method to communicate with firmware.
>> So firmware and driver have to use this flag to make compatibility.
>>
> I would rather add such things to the spec if it is any sort of limitation
> with the current specification.
Agreed. but I think there isn't any limitation for this with the current 
specification.
There is no strong connection between PCC Operation Region and type3.
Driver can also use PCC to communicate with platform even if the type is 
type3.
In other words, it depends on driver's choice.

Here, we want to use one bit in device-flags to indicates that
firmware and driver use PCC operation Region on feature platform instead 
of only using PCC.

Sorry, I have to admit that the implementation of this driver about this 
really needs
to be optimized to make it more clear.
>
>>>> I found a way to obtain the generic register information according to
>>>> "Referencing the PCC address space" in ACPI spec.
>>>> And driver also get the PCC generic register information successfully.
>>>>
>>> Can you elaborate ? I assume by that you must be able to get pcc-chan-id
>> Yes，driver can get pcc-chan-id by below register.
>>
>> Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)
>>
> Good to know.
>
>>> right ? You must not need pcc-type as the pcc mailbox driver must handle
>>> the type for you. If not, we may need to fix or add any missing support.
>> Yes, PCC driver doesn't support it currently. And aother patch [1] we've
>> been talking about does it.
>> If it is applied to kernel, we can drop this pcc-type here.
>>
>> [1] https://patchwork.kernel.org/project/linux-acpi/patch/[e-mail]/
> OK then we are good, no need for pcc-type then ?
If driver may support more PCC types, the type also need be known by driver.
Because not all types have the same header size.
The PCC type can be obtained from the PCCT by requesting PCC channel.
 From this point, this pcc type here is unnecessary, right?
>
>>>> But I don't know how to set and use the address in PCC register.
>>> It must be same as what you would have specified in you new bindings
>>> under "pcc-chan-id". I am confused as you say you were able to get the
>>> PCC generic register information successfully but you still claim you
>>> don't know how to set or use the address.
>> My confusion about this address is mentioned below.
> OK
>
>>>> Where should this address come from?
>>>> It seems that ACPI spec is not very detailed about this.
>>>> Do you have any suggestions?
>>>>
>>> I am afraid, I don't have any as I am failing to understand the exact issue
>>> you are facing.
>>>
>>> Let me try to ask the question explicity here:
>>>
>>> If you are just referring to just the <RegisterAddress,> in
>>>
>>> Register (PCC, RegisterBitWidth, RegisterBitOffset, RegisterAddress, AccessSize)
>> Yeah, this is what I'm using.
>>> then,
>>>
>>> RegisterAddress is usually the offset in the comms address associated with
>> Communication subspace in share memory of PCC subspace?
>>> the PCC subspace ID specified in AccessSize. Yes the use of AccessSize for
>>> the PCC subspace ID is bit confusing though.
>>>
>>> You can either list all the registers with _CRS individually or the driver
>> List all the registers as following way?
>> Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
>> {
>>      QWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
>> NonCacheable, ReadWrite,
>>          0x0000000000000000, // Granularity
>>          0x0000000098190000, // Range Minimum
>>          0x000000009819FFFF, // Range Maximum
>>          0x0000000000000000, // Translation Offset
>>          0x0000000000010000, // Length
>>          ,, , AddressRangeMemory, TypeStatic)
>> })
> Not sure if you can use QWordMemory here TBH.
Above way is what you say?
>
>>> can just use the PCC subspace ID in AccessSize and keep RegisterAddress = 0
>>> but access individual offset based on its own knowledge. I haven't seen the
>> Following words come from ACPI spec.
>> -->
>> As an example, the following resource template refers to the feld occupying
>> bits 8 through 15 at address 0x30 in PCC
>> subspace 9:
>> ResourceTemplate()
>> {
>> Register (
>>      PCC, //AddressSpaceKeyword
>>      8, //RegisterBitWidth
>>      8, //RegisterBitOffset
>>     pcc 0x30, //RegisterAddress
>>      9 //AccessSize (subspace ID)
>>      )
>> }
>>
>> If the width of the address is 32bit, set RegisterAddress to 0,
>> RegisterBitOffset to 0 and set RegisterBitWidth to 64 here.
>> Driver can access to the ((void __iomem *)pcc_comm_addr + 0x8 + 0) and
>> ((void __iomem *)pcc_comm_addr + 0x8 + 4) address，right?
>> (This virtual address = pcc mapped address + header size + offset within PCC
>> subspace.)
> Yes that's my understanding. I remember seeing the driver is just fetching
> pcc-chan-id using DSD style key-value pair, which means you don't need
> any other info other than the PCC subspace/channel ID, just have address
> as 0.
But I still need the device-flags to report if use PCC operation Region.
If so I have to dig one address register from comm subspace, right?
>
> Also I see the driver uses type for just rejecting the type 3 PCCT. The
> question is will the driver probe and run on a platform with type 3 PCCT ?
Yes，some platforms may use PCC operation Region.
> If so what is the problem running on such a platform. I see it is useless
I didn't found any problems. But this driver should consider the 
possibility above mentioned.
> check in the driver and can be dropped. Also the comment above enum
> HCCS_DEV_FLAGS_INTR_B is confusing and  so is the way flags is used.
Thanks for you bringing it up.
Indeed, this HCCS_DEV_FLAGS_INTR_B is not good.
I'm going to replace it with PCC operation Region flag.
>
>>> full driver yet but I assuming that's how you would have used if you went with
>>> your DSD pcc-chan-id proposal.
>>>
>>>> On the other hand, we think that System Memory space + method can also
>>>> achieve above goal. What do you think of that?
>>> Again I don't understand what you mean by that.
>> Sorry, here is what I want to say.
>> -->
>> OperationRegion (CCS0, SystemMemory, 0x00000002081000CC, 0x04)
>> Field (CCS0, DWordAcc, NoLock, Preserve)
>> {
>>      HAU1,   32
>> }
>> OperationRegion (CCS1, SystemMemory, 0x0000000201070410, 0x04)
>> Field (CCS1, DWordAcc, NoLock, Preserve)
>> {
>>      HCGE,   32
>> }
>> Method (_DSM, 2, Serialized)  // _DSM: Device-Specific Method
>> {
>>      If ((Arg0 == ToUUID ("b06b81ab-0134-4a45-9b0c-483447b95fa7")))
>>      {
>>          If ((Arg1 == One))
>>          {
>>              Return (HAU1)
>>          }
>>
>>          Return (HCGE)
>>      }
>> }
>>
>> Driver can call _DSM method to get some information, such as pcc_chan_id and
>> device_flags.
> Big fat NACK for _DSM for the above purpose, please stop abusing _DSM or _DSD
> for such information which can be obtained with the existing _CRS.
Get it. Thanks.
> .

Sudeep Holla May 16, 2023, 2:35 p.m. UTC | #18

On Tue, May 16, 2023 at 10:13:58PM +0800, lihuisong (C) wrote:
[...]

>
> But I still need the device-flags to report if use PCC operation Region.
> If so I have to dig one address register from comm subspace, right?

[...]

> Thanks for you bringing it up.
> Indeed, this HCCS_DEV_FLAGS_INTR_B is not good.
> I'm going to replace it with PCC operation Region flag.

From the above 2, I am getting a sense that all these flags dance is for
sharing a PCC subspace ID between this driver and the firmware PCC Opregion ?
If so that may not work as the current implementation of PCC Opregion
assumes the exclusive access to the channel. Since it is initialised
quite early, Opregion must succeed to get the mbox channel acquired and
this driver must fail if they are sharing the channel. Making the sharing
across firmware and this driver may need changes in the PCC Opregion
support code. One possible way is to acquire and release the channel for
each transaction which will be definitely overhead.

lihuisong (C) May 17, 2023, 7:16 a.m. UTC | #19

在 2023/5/16 22:35, Sudeep Holla 写道:
> On Tue, May 16, 2023 at 10:13:58PM +0800, lihuisong (C) wrote:
> [...]
>
>> But I still need the device-flags to report if use PCC operation Region.
>> If so I have to dig one address register from comm subspace, right?
> [...]
>
>> Thanks for you bringing it up.
>> Indeed, this HCCS_DEV_FLAGS_INTR_B is not good.
>> I'm going to replace it with PCC operation Region flag.
> >From the above 2, I am getting a sense that all these flags dance is for
> sharing a PCC subspace ID between this driver and the firmware PCC Opregion ?
No. I want to use this flag to make compability between different platforms.
This driver only use PCC OpRegion to access to the channel if platform 
support use PCC OpRegion.
Driver must select one of them (PCC and PCC OpRegion) to communicate 
with firmware on one platform.
> If so that may not work as the current implementation of PCC Opregion
> assumes the exclusive access to the channel. Since it is initialised
> quite early, Opregion must succeed to get the mbox channel acquired and
> this driver must fail if they are sharing the channel. Making the sharing
> across firmware and this driver may need changes in the PCC Opregion
Only using PCC OpRegion after requesting and releasing PCC channel 
shouldn't change PCC OpRegion code?
> support code. One possible way is to acquire and release the channel for
> each transaction which will be definitely overhead.
Yes, transaction will be definitely overhead.
The following method should be no such problem.
-->
If driver want to obtain other info by RegisterAddress and offset in PCC 
Register(),
driver generally needs to do it as follows:
1> get channel ID and RegisterAddress and offset.
2> call pcc_mbox_request_channel to acquire the channel.
3> ioremap 'shmem_base_addr' to get 'pcc_comm_addr'
4> obtain other info based on RegisterAddress, offset and 'pcc_comm_addr'.
If driver selects PCC OpRegion method, driver may also need to release 
this PCC channel by calling pcc_mbox_free_channel.
Because this channel will be requested when PCC OpRegion method is 
executed for the first time.


Overall, the above process is a bit cumbersome if this driver only use 
PCC OpRegion.
In addition, I have to dig one address from comm space in share memory,
which will cause the available size of comm space to decrease, right?
So it is better to use other way to do get channel ID and other info if 
it is possible.
What do you think?
>

Sudeep Holla May 17, 2023, 9:30 a.m. UTC | #20

On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:

[...]

> No. I want to use this flag to make compability between different platforms.
> This driver only use PCC OpRegion to access to the channel if platform
> support use PCC OpRegion.

What do you mean by that ? It is not correct. If there is a PCC Opregion,
then you need to make it work with drivers/acpi/acpi_pcc.c

You need to have all the other details in the firmware(ASL). By looking
at the driver, it has no connection to PCC Opregion IMO unless I am missing
something.

> Driver must select one of them (PCC and PCC OpRegion) to communicate with
> firmware on one platform.

No for reasons mentioned above. PCC Opregion support in the kernel will
be minimal and already there. Fix that if it is not working. If you are
attempting to do something with PCC Opregion in this driver, it is just
wrong and I will NACK it if I see anything around that.

> > If so that may not work as the current implementation of PCC Opregion
> > assumes the exclusive access to the channel. Since it is initialised
> > quite early, Opregion must succeed to get the mbox channel acquired and
> > this driver must fail if they are sharing the channel. Making the sharing
> > across firmware and this driver may need changes in the PCC Opregion
> Only using PCC OpRegion after requesting and releasing PCC channel shouldn't
> change PCC OpRegion code?

I don't understand what exactly that means. The spec states clearly that
PCC subspaces that are used for PCC Operation Regions must not be used
as PCC subspaces for other std ACPI features. I don't understand what
really is going on, on this platform as I don't see what you are saying
(which is wrong and I disagree with approach) in the code posted yet.

> > support code. One possible way is to acquire and release the channel for
> > each transaction which will be definitely overhead.
> Yes, transaction will be definitely overhead.
> The following method should be no such problem.
> -->
> If driver want to obtain other info by RegisterAddress and offset in PCC
> Register(), driver generally needs to do it as follows:
> 1> get channel ID and RegisterAddress and offset.
> 2> call pcc_mbox_request_channel to acquire the channel.
> 3> ioremap 'shmem_base_addr' to get 'pcc_comm_addr'
> 4> obtain other info based on RegisterAddress, offset and 'pcc_comm_addr'.

Above sound good but it is not PCC Opregion. Either you are not giving
full context or you are confusing what PCC Opregion means. There is a
section "Declaring PCC Operation Regions", please refer and see if that
is what you have on your platform.

> If driver selects PCC OpRegion method, driver may also need to release this
> PCC channel by calling pcc_mbox_free_channel.

As I mentioned, the driver must not do anything related to PCC Opregion.

> Because this channel will be requested when PCC OpRegion method is executed
> for the first time.
>

drivers/acpi/acpi_pcc.c must take care of that. If not patch that and get
it working. It must be generic and nothing to do with your platform.

> 
> Overall, the above process is a bit cumbersome if this driver only use PCC
> OpRegion.

Yes and hence must not touch anything around PCC Opregion.

> In addition, I have to dig one address from comm space in share memory,
> which will cause the available size of comm space to decrease, right?
> So it is better to use other way to do get channel ID and other info if it
> is possible.
> What do you think?

I am more confused about your platform than yesterday, so I don't have
much valuable suggestions ATM.

lihuisong (C) May 17, 2023, 11:35 a.m. UTC | #21

在 2023/5/17 17:30, Sudeep Holla 写道:
> On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
>
> [...]
>
>> No. I want to use this flag to make compability between different platforms.
>> This driver only use PCC OpRegion to access to the channel if platform
>> support use PCC OpRegion.
> What do you mean by that ? It is not correct. If there is a PCC Opregion,
> then you need to make it work with drivers/acpi/acpi_pcc.c
>
> You need to have all the other details in the firmware(ASL). By looking
> at the driver, it has no connection to PCC Opregion IMO unless I am missing
> something.
Driver just needs to call these APIs, such as acpi_evaluate_integer(), 
if want to use PCC OpRegion.
I know that. I have tested PCC OpRegion before.
You've completely misunderstood what I said.

Sudeep Holla May 17, 2023, 1:16 p.m. UTC | #22

On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
> 
> 在 2023/5/17 17:30, Sudeep Holla 写道:
> > On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
> > 
> > [...]
> > 
> > > No. I want to use this flag to make compability between different platforms.
> > > This driver only use PCC OpRegion to access to the channel if platform
> > > support use PCC OpRegion.
> > What do you mean by that ? It is not correct. If there is a PCC Opregion,
> > then you need to make it work with drivers/acpi/acpi_pcc.c
> > 
> > You need to have all the other details in the firmware(ASL). By looking
> > at the driver, it has no connection to PCC Opregion IMO unless I am missing
> > something.
> Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
> want to use PCC OpRegion.

OK, please provide examples. I am definitely lost as it doesn't match with
my understanding of how PCC Opregions are/can be used.

> I know that. I have tested PCC OpRegion before.

Cool, examples please.

> You've completely misunderstood what I said.

lihuisong (C) May 18, 2023, 8:24 a.m. UTC | #23

在 2023/5/17 21:16, Sudeep Holla 写道:
> On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
>> 在 2023/5/17 17:30, Sudeep Holla 写道:
>>> On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
>>>
>>> [...]
>>>
>>>> No. I want to use this flag to make compability between different platforms.
>>>> This driver only use PCC OpRegion to access to the channel if platform
>>>> support use PCC OpRegion.
>>> What do you mean by that ? It is not correct. If there is a PCC Opregion,
>>> then you need to make it work with drivers/acpi/acpi_pcc.c
>>>
>>> You need to have all the other details in the firmware(ASL). By looking
>>> at the driver, it has no connection to PCC Opregion IMO unless I am missing
>>> something.
>> Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
>> want to use PCC OpRegion.
> OK, please provide examples. I am definitely lost as it doesn't match with
> my understanding of how PCC Opregions are/can be used.
>
>> I know that. I have tested PCC OpRegion before.
> Cool, examples please.
>
>> You've completely misunderstood what I said.

Sudeep Holla May 18, 2023, 8:38 a.m. UTC | #24

On Thu, May 18, 2023 at 04:24:36PM +0800, lihuisong (C) wrote:
> 
> 在 2023/5/17 21:16, Sudeep Holla 写道:
> > On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
> > > 在 2023/5/17 17:30, Sudeep Holla 写道:
> > > > On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > No. I want to use this flag to make compability between different platforms.
> > > > > This driver only use PCC OpRegion to access to the channel if platform
> > > > > support use PCC OpRegion.
> > > > What do you mean by that ? It is not correct. If there is a PCC Opregion,
> > > > then you need to make it work with drivers/acpi/acpi_pcc.c
> > > > 
> > > > You need to have all the other details in the firmware(ASL). By looking
> > > > at the driver, it has no connection to PCC Opregion IMO unless I am missing
> > > > something.
> > > Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
> > > want to use PCC OpRegion.
> > OK, please provide examples. I am definitely lost as it doesn't match with
> > my understanding of how PCC Opregions are/can be used.
> > 
> > > I know that. I have tested PCC OpRegion before.
> > Cool, examples please.
> > 
> > > You've completely misunderstood what I said.

lihuisong (C) May 18, 2023, 12:29 p.m. UTC | #25

在 2023/5/18 16:38, Sudeep Holla 写道:
> On Thu, May 18, 2023 at 04:24:36PM +0800, lihuisong (C) wrote:
>> 在 2023/5/17 21:16, Sudeep Holla 写道:
>>> On Wed, May 17, 2023 at 07:35:25PM +0800, lihuisong (C) wrote:
>>>> 在 2023/5/17 17:30, Sudeep Holla 写道:
>>>>> On Wed, May 17, 2023 at 03:16:12PM +0800, lihuisong (C) wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>> No. I want to use this flag to make compability between different platforms.
>>>>>> This driver only use PCC OpRegion to access to the channel if platform
>>>>>> support use PCC OpRegion.
>>>>> What do you mean by that ? It is not correct. If there is a PCC Opregion,
>>>>> then you need to make it work with drivers/acpi/acpi_pcc.c
>>>>>
>>>>> You need to have all the other details in the firmware(ASL). By looking
>>>>> at the driver, it has no connection to PCC Opregion IMO unless I am missing
>>>>> something.
>>>> Driver just needs to call these APIs, such as acpi_evaluate_integer(), if
>>>> want to use PCC OpRegion.
>>> OK, please provide examples. I am definitely lost as it doesn't match with
>>> my understanding of how PCC Opregions are/can be used.
>>>
>>>> I know that. I have tested PCC OpRegion before.
>>> Cool, examples please.
>>>
>>>> You've completely misunderstood what I said.

lihuisong (C) July 28, 2023, 3:03 a.m. UTC | #26

This series add HCCS driver to query the health status and port information
of HCCS on Kunpeng SoC as well as document all sysfs entries provided by
this driver.

---
 v4:
 - remove useless header and reorder linux header.
 - use __ATTR_RO to replace __ATTR for port attributes.
 - add MODULE_DEVICE_TABLE to autoload the driver.
 - update the date to "November 2023".
 - fix some comments about HCCS description.

 v3:
  - replace "using_status" with "enable" attribute.
  - fix some comments in codes.

 v2:
  - Document all sysfs entries provided by driver.
  - drop 'pcc_type' and 'intr_mode' in struct hccs_dev.
  - using _CRS with PCC GAS to get channel ID instead of _DSD.
  - replace readw_relaxed_poll_timeout with readw_poll_timeout.
  - use sysfs_emit() instead of sprintf().
  - drop ACPI_PTR in hccs_driver.
  - drop useless log during the probe phase.

Huisong Li (2):
  soc: hisilicon: Support HCCS driver on Kunpeng SoC
  doc: soc: hisilicon: Add Kunpeng HCCS driver documentation

 .../sysfs-devices-platform-kunpeng_hccs       |   76 +
 MAINTAINERS                                   |    7 +
 drivers/soc/Kconfig                           |    1 +
 drivers/soc/Makefile                          |    1 +
 drivers/soc/hisilicon/Kconfig                 |   20 +
 drivers/soc/hisilicon/Makefile                |    2 +
 drivers/soc/hisilicon/kunpeng_hccs.c          | 1282 +++++++++++++++++
 drivers/soc/hisilicon/kunpeng_hccs.h          |  196 +++
 8 files changed, 1585 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
 create mode 100644 drivers/soc/hisilicon/Kconfig
 create mode 100644 drivers/soc/hisilicon/Makefile
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h

lihuisong (C) July 29, 2023, 8:26 a.m. UTC | #27

This series add HCCS driver to query the health status and port information
of HCCS on Kunpeng SoC as well as document all sysfs entries provided by
this driver.

---
 v5:
 - fix document format to eliminate warning of making htmldocs.

 v4:
 - remove useless header and reorder linux header.
 - use __ATTR_RO to replace __ATTR for port attributes.
 - add MODULE_DEVICE_TABLE to autoload the driver.
 - update the date to "November 2023".
 - fix some comments about HCCS description.

 v3:
  - replace "using_status" with "enable" attribute.
  - fix some comments in codes.

 v2:
  - Document all sysfs entries provided by driver.
  - drop 'pcc_type' and 'intr_mode' in struct hccs_dev.
  - using _CRS with PCC GAS to get channel ID instead of _DSD.
  - replace readw_relaxed_poll_timeout with readw_poll_timeout.
  - use sysfs_emit() instead of sprintf().
  - drop ACPI_PTR in hccs_driver.
  - drop useless log during the probe phase.

Huisong Li (2):
  soc: hisilicon: Support HCCS driver on Kunpeng SoC
  doc: soc: hisilicon: Add Kunpeng HCCS driver documentation

 .../sysfs-devices-platform-kunpeng_hccs       |   81 ++
 MAINTAINERS                                   |    7 +
 drivers/soc/Kconfig                           |    1 +
 drivers/soc/Makefile                          |    1 +
 drivers/soc/hisilicon/Kconfig                 |   20 +
 drivers/soc/hisilicon/Makefile                |    2 +
 drivers/soc/hisilicon/kunpeng_hccs.c          | 1282 +++++++++++++++++
 drivers/soc/hisilicon/kunpeng_hccs.h          |  196 +++
 8 files changed, 1590 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
 create mode 100644 drivers/soc/hisilicon/Kconfig
 create mode 100644 drivers/soc/hisilicon/Makefile
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h

lihuisong (C) Aug. 1, 2023, 2:41 a.m. UTC | #28

This series add HCCS driver to query the health status and port information
of HCCS on Kunpeng SoC as well as document all sysfs entries provided by
this driver.

---
 v6:
 - fix the new entry in MAINTAINERS file to keep alphabetical order

 v5:
 - fix document format to eliminate warning of making htmldocs.

 v4:
 - remove useless header and reorder linux header.
 - use __ATTR_RO to replace __ATTR for port attributes.
 - add MODULE_DEVICE_TABLE to autoload the driver.
 - update the date to "November 2023".
 - fix some comments about HCCS description.

 v3:
  - replace "using_status" with "enable" attribute.
  - fix some comments in codes.

 v2:
  - Document all sysfs entries provided by driver.
  - drop 'pcc_type' and 'intr_mode' in struct hccs_dev.
  - using _CRS with PCC GAS to get channel ID instead of _DSD.
  - replace readw_relaxed_poll_timeout with readw_poll_timeout.
  - use sysfs_emit() instead of sprintf().
  - drop ACPI_PTR in hccs_driver.
  - drop useless log during the probe phase.

Huisong Li (2):
  soc: hisilicon: Support HCCS driver on Kunpeng SoC
  doc: soc: hisilicon: Add Kunpeng HCCS driver documentation

 .../sysfs-devices-platform-kunpeng_hccs       |   81 ++
 MAINTAINERS                                   |    7 +
 drivers/soc/Kconfig                           |    1 +
 drivers/soc/Makefile                          |    1 +
 drivers/soc/hisilicon/Kconfig                 |   20 +
 drivers/soc/hisilicon/Makefile                |    2 +
 drivers/soc/hisilicon/kunpeng_hccs.c          | 1282 +++++++++++++++++
 drivers/soc/hisilicon/kunpeng_hccs.h          |  196 +++
 8 files changed, 1590 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
 create mode 100644 drivers/soc/hisilicon/Kconfig
 create mode 100644 drivers/soc/hisilicon/Makefile
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h

lihuisong (C) Aug. 8, 2023, 2:36 a.m. UTC | #29

This series add HCCS driver to query the health status and port information
of HCCS on Kunpeng SoC as well as document all sysfs entries provided by
this driver.

---
 v7:
 - split patch 1/2 to make it easier to review.                 
 - fix a wrong command code in hccs_get_die_all_link_status(). 
 - remove unused code and fix a log description in error branch.

 v6:
 - fix the new entry in MAINTAINERS file to keep alphabetical order

 v5:
 - fix document format to eliminate warning of making htmldocs.

 v4:
 - remove useless header and reorder linux header.
 - use __ATTR_RO to replace __ATTR for port attributes.
 - add MODULE_DEVICE_TABLE to autoload the driver.
 - update the date to "November 2023".
 - fix some comments about HCCS description.

 v3:
  - replace "using_status" with "enable" attribute.
  - fix some comments in codes.

 v2:
  - Document all sysfs entries provided by driver.
  - drop 'pcc_type' and 'intr_mode' in struct hccs_dev.
  - using _CRS with PCC GAS to get channel ID instead of _DSD.
  - replace readw_relaxed_poll_timeout with readw_poll_timeout.
  - use sysfs_emit() instead of sprintf().
  - drop ACPI_PTR in hccs_driver.
  - drop useless log during the probe phase.

Huisong Li (3):
  soc: hisilicon: Support HCCS driver on Kunpeng SoC
  soc: hisilicon: add sysfs entry to query information of HCCS
  doc: soc: hisilicon: Add Kunpeng HCCS driver documentation

 .../sysfs-devices-platform-kunpeng_hccs       |   81 ++
 MAINTAINERS                                   |    7 +
 drivers/soc/Kconfig                           |    1 +
 drivers/soc/Makefile                          |    1 +
 drivers/soc/hisilicon/Kconfig                 |   20 +
 drivers/soc/hisilicon/Makefile                |    2 +
 drivers/soc/hisilicon/kunpeng_hccs.c          | 1275 +++++++++++++++++
 drivers/soc/hisilicon/kunpeng_hccs.h          |  191 +++
 8 files changed, 1578 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
 create mode 100644 drivers/soc/hisilicon/Kconfig
 create mode 100644 drivers/soc/hisilicon/Makefile
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
 create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h

Wei Xu Aug. 11, 2023, 9:30 a.m. UTC | #30

Hi Huisong,

On 2023/8/8 10:36, Huisong Li wrote:
> This series add HCCS driver to query the health status and port information
> of HCCS on Kunpeng SoC as well as document all sysfs entries provided by
> this driver.
> 
> ---
>  v7:
>  - split patch 1/2 to make it easier to review.                 
>  - fix a wrong command code in hccs_get_die_all_link_status(). 
>  - remove unused code and fix a log description in error branch.
> 
>  v6:
>  - fix the new entry in MAINTAINERS file to keep alphabetical order
> 
>  v5:
>  - fix document format to eliminate warning of making htmldocs.
> 
>  v4:
>  - remove useless header and reorder linux header.
>  - use __ATTR_RO to replace __ATTR for port attributes.
>  - add MODULE_DEVICE_TABLE to autoload the driver.
>  - update the date to "November 2023".
>  - fix some comments about HCCS description.
> 
>  v3:
>   - replace "using_status" with "enable" attribute.
>   - fix some comments in codes.
> 
>  v2:
>   - Document all sysfs entries provided by driver.
>   - drop 'pcc_type' and 'intr_mode' in struct hccs_dev.
>   - using _CRS with PCC GAS to get channel ID instead of _DSD.
>   - replace readw_relaxed_poll_timeout with readw_poll_timeout.
>   - use sysfs_emit() instead of sprintf().
>   - drop ACPI_PTR in hccs_driver.
>   - drop useless log during the probe phase.
> 
> Huisong Li (3):
>   soc: hisilicon: Support HCCS driver on Kunpeng SoC
>   soc: hisilicon: add sysfs entry to query information of HCCS
>   doc: soc: hisilicon: Add Kunpeng HCCS driver documentation
> 
>  .../sysfs-devices-platform-kunpeng_hccs       |   81 ++
>  MAINTAINERS                                   |    7 +
>  drivers/soc/Kconfig                           |    1 +
>  drivers/soc/Makefile                          |    1 +
>  drivers/soc/hisilicon/Kconfig                 |   20 +
>  drivers/soc/hisilicon/Makefile                |    2 +
>  drivers/soc/hisilicon/kunpeng_hccs.c          | 1275 +++++++++++++++++
>  drivers/soc/hisilicon/kunpeng_hccs.h          |  191 +++
>  8 files changed, 1578 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-devices-platform-kunpeng_hccs
>  create mode 100644 drivers/soc/hisilicon/Kconfig
>  create mode 100644 drivers/soc/hisilicon/Makefile
>  create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.c
>  create mode 100644 drivers/soc/hisilicon/kunpeng_hccs.h
> 

Thanks!
Series applied to the hisilicon driver tree.

Best Regards,
Wei

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index eddbc48c61e9..fe0e796e8445 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9399,6 +9399,12 @@  S:	Maintained
 W:	http://www.hisilicon.com
 F:	drivers/spi/spi-hisi-sfc-v3xx.c
 
+HISILICON KUNPENG SOC HCCS DRIVER
+M:	Huisong Li <[e-mail]>
+S:	Maintained
+F:	drivers/soc/hisilicon/kunpeng_hccs.c
+F:	drivers/soc/hisilicon/kunpeng_hccs.h
+
 HMM - Heterogeneous Memory Management
 M:	Jérôme Glisse <[e-mail]>
 L:	[e-mail]
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 4e176280113a..d21e75d69294 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -10,6 +10,7 @@  source "drivers/soc/bcm/Kconfig"
 source "drivers/soc/canaan/Kconfig"
 source "drivers/soc/fsl/Kconfig"
 source "drivers/soc/fujitsu/Kconfig"
+source "drivers/soc/hisilicon/Kconfig"
 source "drivers/soc/imx/Kconfig"
 source "drivers/soc/ixp4xx/Kconfig"
 source "drivers/soc/litex/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 3b0f9fb3b5c8..531f46f3ad98 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -14,6 +14,7 @@  obj-$(CONFIG_MACH_DOVE)		+= dove/
 obj-y				+= fsl/
 obj-y				+= fujitsu/
 obj-$(CONFIG_ARCH_GEMINI)	+= gemini/
+obj-y				+= hisilicon/
 obj-y				+= imx/
 obj-y				+= ixp4xx/
 obj-$(CONFIG_SOC_XWAY)		+= lantiq/
diff --git a/drivers/soc/hisilicon/Kconfig b/drivers/soc/hisilicon/Kconfig
new file mode 100644
index 000000000000..81768d47f572
--- /dev/null
+++ b/drivers/soc/hisilicon/Kconfig
@@ -0,0 +1,18 @@ 
+# SPDX-License-Identifier: GPL-2.0-only
+
+menu "Hisilicon SoC drivers"
+	depends on ARCH_HISI
+
+config KUNPENG_HCCS
+	tristate "HCCS driver on Kunpeng SoC"
+	depends on ARM64 && ACPI
+	help
+	  The Huawei Cache-Coherent System (HCCS) is a bus protocol standard
+	  for ensuring cache coherent on HiSilicon SoC. The performance of
+	  the application may be affected if some hccs ports are in non-full
+	  lane status, have a large number of CRC errors and so on.
+
+	  Say M here if you want to include support for querying the health
+	  status and port information of HCCS on Kunpeng SoC.
+
+endmenu
diff --git a/drivers/soc/hisilicon/Makefile b/drivers/soc/hisilicon/Makefile
new file mode 100644
index 000000000000..226e747e70d6
--- /dev/null
+++ b/drivers/soc/hisilicon/Makefile
@@ -0,0 +1,2 @@ 
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_KUNPENG_HCCS)	+= kunpeng_hccs.o
diff --git a/drivers/soc/hisilicon/kunpeng_hccs.c b/drivers/soc/hisilicon/kunpeng_hccs.c
new file mode 100644
index 000000000000..2b52f7dedc78
--- /dev/null
+++ b/drivers/soc/hisilicon/kunpeng_hccs.c
@@ -0,0 +1,1296 @@ 
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * The Huawei Cache-Coherent System (HCCS) is a bus protocol standard for
+ * ensuring cache coherent on HiSilicon SoC.
+ *
+ * Copyright (c) 2023 Hisilicon Limited.
+ * Author: Huisong Li <[e-mail]>
+ *
+ * HCCS driver for Kunpeng SoC provides the following features:
+ * - Retrieve info as belows each port:
+ *    - port type
+ *    - lane mode
+ *    - using status
+ *    - current lane mode
+ *    - link state machine
+ *    - lane mask
+ *    - CRC error count
+ *
+ * - Retrieve info as belows all ports on die or chip:
+ *    - if all used ports are in linked
+ *    - if all linked ports are in full lane
+ *    - CRC error count sum
+ */
+#include <linux/sysfs.h>
+#include <linux/acpi.h>
+#include <linux/io.h>
+#include <linux/kobject.h>
+#include <linux/iopoll.h>
+#include <linux/platform_device.h>
+#include <acpi/pcc.h>
+
+#include "kunpeng_hccs.h"
+
+/* PCC defines */
+#define HCCS_PCC_SIGNATURE_MASK		0x50434300
+#define HCCS_PCC_STATUS_CMD_COMPLETE	BIT(0)
+
+/*
+ * Arbitrary retries in case the remote processor is slow to respond
+ * to PCC commands
+ */
+#define HCCS_PCC_CMD_WAIT_RETRIES_NUM		500ULL
+#define HCCS_POLL_STATUS_TIME_INTERVAL_US	3
+
+static struct hccs_port_info *kobj_to_port_info(struct kobject *k)
+{
+	return container_of(k, struct hccs_port_info, kobj);
+}
+
+static struct hccs_die_info *kobj_to_die_info(struct kobject *k)
+{
+	return container_of(k, struct hccs_die_info, kobj);
+}
+
+static struct hccs_chip_info *kobj_to_chip_info(struct kobject *k)
+{
+	return container_of(k, struct hccs_chip_info, kobj);
+}
+
+static bool hccs_dev_property_supported(struct hccs_dev *hdev)
+{
+	struct device *dev = hdev->dev;
+
+	if (hdev->intr_mode) {
+		dev_err(dev, "interrupt mode is unsupported.\n");
+		return false;
+	}
+
+	if (hdev->type >= ACPI_PCCT_TYPE_EXT_PCC_MASTER_SUBSPACE) {
+		dev_err(dev, "PCC type-%u is unsupported.\n", hdev->type);
+		return false;
+	}
+
+	return true;
+}
+
+static int hccs_get_device_property(struct hccs_dev *hdev)
+{
+	struct device *dev = hdev->dev;
+
+	if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
+		dev_err(hdev->dev, "no device-flags property.\n");
+		return -ENODEV;
+	}
+
+	if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
+		dev_err(hdev->dev, "no pcc-type property.\n");
+		return -ENODEV;
+	}
+
+	if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
+		dev_err(hdev->dev, "no pcc-channel property.\n");
+		return -ENODEV;
+	}
+
+	hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
+	if (!hccs_dev_property_supported(hdev))
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
+static void hccs_chan_tx_done(struct mbox_client *cl, void *msg, int ret)
+{
+	if (ret < 0)
+		pr_debug("TX did not complete: CMD sent:0x%x, ret:%d\n",
+			 *(u8 *)msg, ret);
+	else
+		pr_debug("TX completed. CMD sent:0x%x, ret:%d\n",
+			 *(u8 *)msg, ret);
+}
+
+static void hccs_unregister_pcc_channel(struct hccs_dev *hdev)
+{
+	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
+
+	if (hdev->intr_mode)
+		return;
+
+	if (cl_info->pcc_comm_addr)
+		iounmap(cl_info->pcc_comm_addr);
+	pcc_mbox_free_channel(hdev->cl_info.pcc_chan);
+}
+
+static int hccs_register_pcc_channel(struct hccs_dev *hdev)
+{
+	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
+	struct mbox_client *cl = &cl_info->client;
+	struct pcc_mbox_chan *pcc_chan;
+	struct device *dev = hdev->dev;
+	int rc;
+
+	if (hdev->intr_mode)
+		return 0;
+
+	cl->dev = dev;
+	cl->tx_block = false;
+	cl->knows_txdone = true;
+	cl->tx_done = hccs_chan_tx_done;
+	pcc_chan = pcc_mbox_request_channel(cl, hdev->chan_id);
+	if (IS_ERR(pcc_chan)) {
+		dev_err(dev, "PPC channel request failed.\n");
+		rc = -ENODEV;
+		goto out;
+	}
+	cl_info->pcc_chan = pcc_chan;
+	cl_info->mbox_chan = pcc_chan->mchan;
+	/*
+	 * pcc_chan->latency is just a nominal value. In reality the remote
+	 * processor could be much slower to reply. So add an arbitrary amount
+	 * of wait on top of nominal.
+	 */
+	cl_info->deadline_us =
+			HCCS_PCC_CMD_WAIT_RETRIES_NUM * pcc_chan->latency;
+	if (cl_info->mbox_chan->mbox->txdone_irq) {
+		dev_err(dev, "PCC IRQ in PCCT is enabled.\n");
+		rc = -EINVAL;
+		goto err_mbx_channel_free;
+	}
+
+	if (pcc_chan->shmem_base_addr) {
+		cl_info->pcc_comm_addr = (void __force *)ioremap(
+			pcc_chan->shmem_base_addr, pcc_chan->shmem_size);
+		if (!cl_info->pcc_comm_addr) {
+			dev_err(dev, "Failed to ioremap PCC communication region for channel-%d.\n",
+				hdev->chan_id);
+			rc = -ENOMEM;
+			goto err_mbx_channel_free;
+		}
+	}
+
+	return 0;
+
+err_mbx_channel_free:
+	pcc_mbox_free_channel(cl_info->pcc_chan);
+out:
+	return rc;
+}
+
+static int hccs_check_chan_cmd_complete(struct hccs_dev *hdev)
+{
+	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
+	struct acpi_pcct_shared_memory *comm_base = cl_info->pcc_comm_addr;
+	u16 status;
+	int ret;
+
+	/*
+	 * Poll PCC status register every 3us(delay_us) for maximum of
+	 * deadline_us(timeout_us) until PCC command complete bit is set(cond)
+	 */
+	ret = readw_relaxed_poll_timeout(&comm_base->status, status,
+					 status & HCCS_PCC_STATUS_CMD_COMPLETE,
+					 HCCS_POLL_STATUS_TIME_INTERVAL_US,
+					 cl_info->deadline_us);
+	if (unlikely(ret))
+		dev_err(hdev->dev, "poll PCC status failed, ret = %d.\n", ret);
+
+	return ret;
+}
+
+static int hccs_pcc_cmd_send(struct hccs_dev *hdev, u8 cmd,
+			     struct hccs_desc *desc)
+{
+	struct hccs_mbox_client_info *cl_info = &hdev->cl_info;
+	struct acpi_pcct_shared_memory *comm_base = cl_info->pcc_comm_addr;
+	void *comm_space = (void *)(comm_base + 1);
+	struct hccs_fw_inner_head *fw_inner_head;
+	struct acpi_pcct_shared_memory tmp = {0};
+	u16 comm_space_size;
+	int ret;
+
+	/* Write signature for this subspace */
+	tmp.signature = HCCS_PCC_SIGNATURE_MASK | hdev->chan_id;
+	/* Write to the shared command region */
+	tmp.command = cmd;
+	/* Clear cmd complete bit */
+	tmp.status = 0;
+	memcpy_toio(comm_base, (void *)&tmp,
+			sizeof(struct acpi_pcct_shared_memory));
+
+	/* Copy the message to the PCC comm space */
+	comm_space_size = HCCS_PCC_SHARE_MEM_BYTES -
+				sizeof(struct acpi_pcct_shared_memory);
+	memcpy_toio(comm_space, (void *)desc, comm_space_size);
+
+	/* Ring doorbell */
+	ret = mbox_send_message(cl_info->mbox_chan, &cmd);
+	if (ret < 0) {
+		dev_err(hdev->dev, "Send PCC mbox message failed, ret = %d.\n",
+			ret);
+		goto end;
+	}
+
+	/* Wait for completion */
+	ret = hccs_check_chan_cmd_complete(hdev);
+	if (ret)
+		goto end;
+
+	/* Copy response data */
+	memcpy_fromio((void *)desc, comm_space, comm_space_size);
+	fw_inner_head = &desc->rsp.fw_inner_head;
+	if (fw_inner_head->retStatus) {
+		dev_err(hdev->dev, "Execute PCC command failed, error code = %u.\n",
+			fw_inner_head->retStatus);
+		ret = -EIO;
+	}
+
+end:
+	mbox_client_txdone(cl_info->mbox_chan, ret);
+	return ret;
+}
+
+static void hccs_init_req_desc(struct hccs_desc *desc)
+{
+	struct hccs_req_desc *req = &desc->req;
+
+	memset(desc, 0, sizeof(*desc));
+	req->req_head.module_code = HCCS_SERDES_MODULE_CODE;
+}
+
+static int hccs_get_dev_caps(struct hccs_dev *hdev)
+{
+	struct hccs_desc desc;
+	int ret;
+
+	hccs_init_req_desc(&desc);
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_DEV_CAP, &desc);
+	if (ret) {
+		dev_err(hdev->dev, "Get device capabilities failed, ret = %d.\n",
+			ret);
+		return ret;
+	}
+	memcpy(&hdev->caps, desc.rsp.data, sizeof(hdev->caps));
+
+	return 0;
+}
+
+static int hccs_query_chip_num_on_platform(struct hccs_dev *hdev)
+{
+	struct hccs_desc desc;
+	int ret;
+
+	hccs_init_req_desc(&desc);
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_CHIP_NUM, &desc);
+	if (ret) {
+		dev_err(hdev->dev, "query system chip number failed, ret = %d.\n",
+			ret);
+		return ret;
+	}
+
+	hdev->chip_num = *((u8 *)&desc.rsp.data);
+	if (!hdev->chip_num) {
+		dev_err(hdev->dev, "chip num obtained from firmware is zero.\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int hccs_get_chip_info(struct hccs_dev *hdev,
+			      struct hccs_chip_info *chip)
+{
+	struct hccs_die_num_req_param *req_param;
+	struct hccs_desc desc;
+	int ret;
+
+	hccs_init_req_desc(&desc);
+	req_param = (struct hccs_die_num_req_param *)desc.req.data;
+	req_param->chip_id = chip->chip_id;
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_DIE_NUM, &desc);
+	if (ret)
+		return ret;
+
+	chip->die_num = *((u8 *)&desc.rsp.data);
+
+	return 0;
+}
+
+static int hccs_query_chip_info_on_platform(struct hccs_dev *hdev)
+{
+	struct hccs_chip_info *chip;
+	int ret;
+	u8 idx;
+
+	ret = hccs_query_chip_num_on_platform(hdev);
+	if (ret) {
+		dev_err(hdev->dev, "query chip number on platform failed, ret = %d.\n",
+			ret);
+		return ret;
+	}
+
+	hdev->chips = devm_kzalloc(hdev->dev,
+				hdev->chip_num * sizeof(struct hccs_chip_info),
+				GFP_KERNEL);
+	if (!hdev->chips) {
+		dev_err(hdev->dev, "allocate all chips memory failed.\n");
+		return -ENOMEM;
+	}
+
+	for (idx = 0; idx < hdev->chip_num; idx++) {
+		chip = &hdev->chips[idx];
+		chip->chip_id = idx;
+		ret = hccs_get_chip_info(hdev, chip);
+		if (ret) {
+			dev_err(hdev->dev, "get chip%u info failed, ret = %d.\n",
+				idx, ret);
+			return ret;
+		}
+		chip->hdev = hdev;
+	}
+
+	return 0;
+}
+
+static int hccs_query_die_info_on_chip(struct hccs_dev *hdev, u8 chip_id,
+				       u8 die_idx, struct hccs_die_info *die)
+{
+	struct hccs_die_info_req_param *req_param;
+	struct hccs_die_info_rsp_data *rsp_data;
+	struct hccs_desc desc;
+	int ret;
+
+	hccs_init_req_desc(&desc);
+	req_param = (struct hccs_die_info_req_param *)desc.req.data;
+	req_param->chip_id = chip_id;
+	req_param->die_idx = die_idx;
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_DIE_INFO, &desc);
+	if (ret)
+		return ret;
+
+	rsp_data = (struct hccs_die_info_rsp_data *)desc.rsp.data;
+	die->die_id = rsp_data->die_id;
+	die->port_num = rsp_data->port_num;
+	die->min_port_id = rsp_data->min_port_id;
+	die->max_port_id = rsp_data->max_port_id;
+	if (die->min_port_id > die->max_port_id) {
+		dev_err(hdev->dev, "min port id(%u) > max port id(%u) on die_idx(%u).\n",
+			die->min_port_id, die->max_port_id, die_idx);
+		return -EINVAL;
+	}
+	if (die->max_port_id > HCCS_DIE_MAX_PORT_ID) {
+		dev_err(hdev->dev, "max port id(%u) on die_idx(%u) is too big.\n",
+			die->max_port_id, die_idx);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int hccs_query_all_die_info_on_platform(struct hccs_dev *hdev)
+{
+	struct device *dev = hdev->dev;
+	struct hccs_chip_info *chip;
+	struct hccs_die_info *die;
+	u8 i, j;
+	int ret;
+
+	for (i = 0; i < hdev->chip_num; i++) {
+		chip = &hdev->chips[i];
+		if (!chip->die_num)
+			continue;
+
+		chip->dies = devm_kzalloc(hdev->dev,
+				chip->die_num * sizeof(struct hccs_die_info),
+				GFP_KERNEL);
+		if (!chip->dies) {
+			dev_err(dev, "allocate all dies memory on chip%u failed.\n",
+				i);
+			return -ENOMEM;
+		}
+
+		for (j = 0; j < chip->die_num; j++) {
+			die = &chip->dies[j];
+			ret = hccs_query_die_info_on_chip(hdev, i, j, die);
+			if (ret) {
+				dev_err(dev, "get die idx (%u) info on chip%u failed, ret = %d.\n",
+					j, i, ret);
+				return ret;
+			}
+			die->chip = chip;
+		}
+	}
+
+	return 0;
+}
+
+static int hccs_get_bd_info(struct hccs_dev *hdev, u8 opcode,
+			    struct hccs_desc *desc,
+			    void *buf, size_t buf_len,
+			    struct hccs_rsp_head *rsp_head)
+{
+	struct hccs_rsp_head *head;
+	struct hccs_rsp_desc *rsp;
+	int ret;
+
+	ret = hccs_pcc_cmd_send(hdev, opcode, desc);
+	if (ret)
+		return ret;
+
+	rsp = &desc->rsp;
+	head = &rsp->rsp_head;
+	if (head->data_len > buf_len) {
+		dev_err(hdev->dev,
+			"buffer overflow (buf_len = %lu, data_len = %u)!\n",
+			buf_len, head->data_len);
+		return -ENOMEM;
+	}
+
+	memcpy(buf, rsp->data, head->data_len);
+	*rsp_head = *head;
+
+	return 0;
+}
+
+static int hccs_get_all_port_attr(struct hccs_dev *hdev,
+				  struct hccs_die_info *die,
+				  struct hccs_port_attr *attrs, u16 size)
+{
+	struct hccs_die_comm_req_param *req_param;
+	struct hccs_req_head *req_head;
+	struct hccs_rsp_head rsp_head;
+	struct hccs_desc desc;
+	size_t left_buf_len;
+	u32 data_len = 0;
+	u8 start_id;
+	u8 *buf;
+	int ret;
+
+	buf = (u8 *)attrs;
+	left_buf_len = sizeof(struct hccs_port_attr) * size;
+	start_id = die->min_port_id;
+	while (start_id <= die->max_port_id) {
+		hccs_init_req_desc(&desc);
+		req_head = &desc.req.req_head;
+		req_head->start_id = start_id;
+		req_param = (struct hccs_die_comm_req_param *)desc.req.data;
+		req_param->chip_id = die->chip->chip_id;
+		req_param->die_id = die->die_id;
+
+		ret = hccs_get_bd_info(hdev, HCCS_GET_DIE_PORT_INFO, &desc,
+				       buf + data_len, left_buf_len, &rsp_head);
+		if (ret) {
+			dev_err(hdev->dev,
+				"get the information of port%u on die%u failed, ret = %d.\n",
+				start_id, die->die_id, ret);
+			return ret;
+		}
+
+		data_len += rsp_head.data_len;
+		left_buf_len -= rsp_head.data_len;
+		if (unlikely(rsp_head.next_id <= start_id)) {
+			dev_err(hdev->dev,
+				"next port id (%u) is not greater than last start id (%u) on die%u.\n",
+				rsp_head.next_id, start_id, die->die_id);
+			return -EINVAL;
+		}
+		start_id = rsp_head.next_id;
+	}
+
+	return 0;
+}
+
+static int hccs_get_all_port_info_on_die(struct hccs_dev *hdev,
+					 struct hccs_die_info *die)
+{
+	struct hccs_port_attr *attrs;
+	struct hccs_port_info *port;
+	int ret;
+	u8 i;
+
+	attrs = kcalloc(die->port_num, sizeof(struct hccs_port_attr),
+			GFP_KERNEL);
+	if (!attrs)
+		return -ENOMEM;
+
+	ret = hccs_get_all_port_attr(hdev, die, attrs, die->port_num);
+	if (ret)
+		goto out;
+
+	for (i = 0; i < die->port_num; i++) {
+		port = &die->ports[i];
+		port->port_id = attrs[i].port_id;
+		port->port_type = attrs[i].port_type;
+		port->lane_mode = attrs[i].lane_mode;
+		port->is_used = attrs[i].is_used;
+		port->die = die;
+	}
+
+out:
+	kfree(attrs);
+	return ret;
+}
+
+static int hccs_query_all_port_info_on_platform(struct hccs_dev *hdev)
+{
+
+	struct device *dev = hdev->dev;
+	struct hccs_chip_info *chip;
+	struct hccs_die_info *die;
+	u8 i, j;
+	int ret;
+
+	for (i = 0; i < hdev->chip_num; i++) {
+		chip = &hdev->chips[i];
+		for (j = 0; j < chip->die_num; j++) {
+			die = &chip->dies[j];
+			if (!die->port_num)
+				continue;
+
+			die->ports = devm_kzalloc(dev,
+				die->port_num * sizeof(struct hccs_port_info),
+				GFP_KERNEL);
+			if (!die->ports) {
+				dev_err(dev, "allocate ports memory on chip%u/die%u failed.\n",
+					i, die->die_id);
+				return -ENOMEM;
+			}
+
+			ret = hccs_get_all_port_info_on_die(hdev, die);
+			if (ret) {
+				dev_err(dev, "get die(%u) info on chip%u failed, ret = %d.\n",
+					die->die_id, i, ret);
+				return ret;
+			}
+		}
+	}
+
+	return 0;
+}
+
+static int hccs_get_hw_info(struct hccs_dev *hdev)
+{
+	int ret;
+
+	ret = hccs_query_chip_info_on_platform(hdev);
+	if (ret) {
+		dev_err(hdev->dev, "query chip info on platform  failed, ret = %d.\n",
+			ret);
+		return ret;
+	}
+
+	ret = hccs_query_all_die_info_on_platform(hdev);
+	if (ret) {
+		dev_err(hdev->dev, "query all die info on platform failed, ret = %d.\n",
+			ret);
+		return ret;
+	}
+
+	ret = hccs_query_all_port_info_on_platform(hdev);
+	if (ret) {
+		dev_err(hdev->dev, "query all port info on platform failed, ret = %d.\n",
+			ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int hccs_query_port_link_status(struct hccs_dev *hdev,
+				       const struct hccs_port_info *port,
+				       struct hccs_link_status *link_status)
+{
+	const struct hccs_die_info *die = port->die;
+	const struct hccs_chip_info *chip = die->chip;
+	struct hccs_port_comm_req_param *req_param;
+	struct hccs_desc desc;
+	int ret;
+
+	hccs_init_req_desc(&desc);
+	req_param = (struct hccs_port_comm_req_param *)desc.req.data;
+	req_param->chip_id = chip->chip_id;
+	req_param->die_id = die->die_id;
+	req_param->port_id = port->port_id;
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_PORT_LINK_STATUS, &desc);
+	if (ret) {
+		dev_err(hdev->dev,
+			"get port link status info failed, ret = %d.\n", ret);
+		return ret;
+	}
+
+	*link_status = *((struct hccs_link_status *)desc.rsp.data);
+
+	return 0;
+}
+
+static int hccs_query_port_crc_err_cnt(struct hccs_dev *hdev,
+				       const struct hccs_port_info *port,
+				       u64 *crc_err_cnt)
+{
+	const struct hccs_die_info *die = port->die;
+	const struct hccs_chip_info *chip = die->chip;
+	struct hccs_port_comm_req_param *req_param;
+	struct hccs_desc desc;
+	int ret;
+
+	hccs_init_req_desc(&desc);
+	req_param = (struct hccs_port_comm_req_param *)desc.req.data;
+	req_param->chip_id = chip->chip_id;
+	req_param->die_id = die->die_id;
+	req_param->port_id = port->port_id;
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_PORT_CRC_ERR_CNT, &desc);
+	if (ret) {
+		dev_err(hdev->dev,
+			"get port crc error count failed, ret = %d.\n", ret);
+		return ret;
+	}
+
+	memcpy(crc_err_cnt, &desc.rsp.data, sizeof(u64));
+
+	return 0;
+}
+
+static int hccs_get_die_all_link_status(struct hccs_dev *hdev,
+					const struct hccs_die_info *die,
+					u8 *all_linked)
+{
+	struct hccs_die_comm_req_param *req_param;
+	struct hccs_desc desc;
+	int ret;
+
+	if (die->port_num == 0) {
+		*all_linked = 1;
+		return 0;
+	}
+
+	hccs_init_req_desc(&desc);
+	req_param = (struct hccs_die_comm_req_param *)desc.req.data;
+	req_param->chip_id = die->chip->chip_id;
+	req_param->die_id = die->die_id;
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_DIE_PORTS_LANE_STA, &desc);
+	if (ret) {
+		dev_err(hdev->dev,
+			"get link status of all ports failed on die%u, ret = %d.\n",
+			die->die_id, ret);
+		return ret;
+	}
+
+	*all_linked = *((u8 *)&desc.rsp.data);
+
+	return 0;
+}
+
+static int hccs_get_die_all_port_lane_status(struct hccs_dev *hdev,
+					     const struct hccs_die_info *die,
+					     u8 *full_lane)
+{
+	struct hccs_die_comm_req_param *req_param;
+	struct hccs_desc desc;
+	int ret;
+
+	if (die->port_num == 0) {
+		*full_lane = 1;
+		return 0;
+	}
+
+	hccs_init_req_desc(&desc);
+	req_param = (struct hccs_die_comm_req_param *)desc.req.data;
+	req_param->chip_id = die->chip->chip_id;
+	req_param->die_id = die->die_id;
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_DIE_PORTS_LANE_STA, &desc);
+	if (ret) {
+		dev_err(hdev->dev, "get lane status of all ports failed on die%u, ret = %d.\n",
+			die->die_id, ret);
+		return ret;
+	}
+
+	*full_lane = *((u8 *)&desc.rsp.data);
+
+	return 0;
+}
+
+static int hccs_get_die_total_crc_err_cnt(struct hccs_dev *hdev,
+					  const struct hccs_die_info *die,
+					  u64 *total_crc_err_cnt)
+{
+	struct hccs_die_comm_req_param *req_param;
+	struct hccs_desc desc;
+	int ret;
+
+	if (die->port_num == 0) {
+		*total_crc_err_cnt = 0;
+		return 0;
+	}
+
+	hccs_init_req_desc(&desc);
+	req_param = (struct hccs_die_comm_req_param *)desc.req.data;
+	req_param->chip_id = die->chip->chip_id;
+	req_param->die_id = die->die_id;
+	ret = hccs_pcc_cmd_send(hdev, HCCS_GET_DIE_PORTS_CRC_ERR_CNT, &desc);
+	if (ret) {
+		dev_err(hdev->dev, "get crc error count sum failed on die%u, ret = %d.\n",
+			die->die_id, ret);
+		return ret;
+	}
+
+	memcpy(total_crc_err_cnt, &desc.rsp.data, sizeof(u64));
+
+	return 0;
+}
+
+static ssize_t hccs_show(struct kobject *k, struct attribute *attr, char *buf)
+{
+	struct kobj_attribute *kobj_attr;
+
+	kobj_attr = container_of(attr, struct kobj_attribute, attr);
+
+	return kobj_attr->show(k, kobj_attr, buf);
+}
+
+static const struct sysfs_ops hccs_comm_ops = {
+	.show = hccs_show,
+};
+
+static ssize_t type_show(struct kobject *kobj, struct kobj_attribute *attr,
+			 char *buf)
+{
+	const struct hccs_port_info *port = kobj_to_port_info(kobj);
+
+	return sprintf(buf, "HCCS-v%u\n", port->port_type);
+}
+
+static struct kobj_attribute hccs_type_attr =
+			__ATTR(type, 0444, type_show, NULL);
+
+static ssize_t lane_mode_show(struct kobject *kobj, struct kobj_attribute *attr,
+			      char *buf)
+{
+	const struct hccs_port_info *port = kobj_to_port_info(kobj);
+
+	return sprintf(buf, "x%u\n", port->lane_mode);
+}
+
+static struct kobj_attribute lane_mode_attr =
+			__ATTR(lane_mode, 0444, lane_mode_show, NULL);
+
+static ssize_t using_status_show(struct kobject *kobj,
+				 struct kobj_attribute *attr, char *buf)
+{
+	const struct hccs_port_info *port = kobj_to_port_info(kobj);
+
+	return sprintf(buf, "%u\n", port->is_used);
+}
+
+static struct kobj_attribute using_status_attr =
+			__ATTR(using_status, 0444, using_status_show, NULL);
+
+static ssize_t cur_lane_num_show(struct kobject *kobj,
+				 struct kobj_attribute *attr, char *buf)
+{
+	const struct hccs_port_info *port = kobj_to_port_info(kobj);
+	struct hccs_dev *hdev = port->die->chip->hdev;
+	struct hccs_link_status link_status = {0};
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	ret = hccs_query_port_link_status(hdev, port, &link_status);
+	mutex_unlock(&hdev->lock);
+	if (ret)
+		return sprintf(buf, "get current lane num failed\n");
+
+	return sprintf(buf, "%u\n", link_status.lane_num);
+}
+
+static struct kobj_attribute cur_lane_num_attr =
+			__ATTR(cur_lane_num, 0444, cur_lane_num_show, NULL);
+
+static ssize_t link_fsm_show(struct kobject *kobj,
+			     struct kobj_attribute *attr, char *buf)
+{
+	const struct hccs_port_info *port = kobj_to_port_info(kobj);
+	struct hccs_dev *hdev = port->die->chip->hdev;
+	struct hccs_link_status link_status = {0};
+	const struct {
+		u8 link_fsm;
+		char *str;
+	} link_fsm_map[] = {
+		{HCCS_PORT_RESET, "reset"},
+		{HCCS_PORT_SETUP, "setup"},
+		{HCCS_PORT_CONFIG, "config"},
+		{HCCS_PORT_READY, "link-up"},
+	};
+	const char *link_fsm_str = "unknown";
+	size_t i;
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	ret = hccs_query_port_link_status(hdev, port, &link_status);
+	mutex_unlock(&hdev->lock);
+	if (ret)
+		return sprintf(buf, "get link fsm failed\n");
+
+	for (i = 0; i < ARRAY_SIZE(link_fsm_map); i++) {
+		if (link_fsm_map[i].link_fsm == link_status.link_fsm) {
+			link_fsm_str = link_fsm_map[i].str;
+			break;
+		}
+	}
+
+	return sprintf(buf, "%s\n", link_fsm_str);
+}
+
+static struct kobj_attribute link_fsm_attr =
+			__ATTR(link_fsm, 0444, link_fsm_show, NULL);
+
+static ssize_t lane_mask_show(struct kobject *kobj,
+			      struct kobj_attribute *attr, char *buf)
+{
+	const struct hccs_port_info *port = kobj_to_port_info(kobj);
+	struct hccs_dev *hdev = port->die->chip->hdev;
+	struct hccs_link_status link_status = {0};
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	ret = hccs_query_port_link_status(hdev, port, &link_status);
+	mutex_unlock(&hdev->lock);
+	if (ret)
+		return sprintf(buf, "get lane mask failed\n");
+
+	return sprintf(buf, "0x%x\n", link_status.lane_mask);
+}
+
+static struct kobj_attribute lane_mask_attr =
+			__ATTR(lane_mask, 0444, lane_mask_show, NULL);
+
+static ssize_t crc_err_cnt_show(struct kobject *kobj,
+				struct kobj_attribute *attr, char *buf)
+{
+	const struct hccs_port_info *port = kobj_to_port_info(kobj);
+	struct hccs_dev *hdev = port->die->chip->hdev;
+	u64 crc_err_cnt;
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	ret = hccs_query_port_crc_err_cnt(hdev, port, &crc_err_cnt);
+	mutex_unlock(&hdev->lock);
+	if (ret)
+		return sprintf(buf, "get crc error count failed\n");
+
+	return sprintf(buf, "%llu\n", crc_err_cnt);
+}
+
+static struct kobj_attribute crc_err_cnt_attr =
+			__ATTR(crc_err_cnt, 0444, crc_err_cnt_show, NULL);
+
+static struct attribute *hccs_port_default_attrs[] = {
+	&hccs_type_attr.attr,
+	&lane_mode_attr.attr,
+	&using_status_attr.attr,
+	&cur_lane_num_attr.attr,
+	&link_fsm_attr.attr,
+	&lane_mask_attr.attr,
+	&crc_err_cnt_attr.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(hccs_port_default);
+
+static const struct kobj_type hccs_port_type = {
+	.sysfs_ops = &hccs_comm_ops,
+	.default_groups = hccs_port_default_groups,
+};
+
+static ssize_t all_linked_on_die_show(struct kobject *kobj,
+				      struct kobj_attribute *attr, char *buf)
+{
+	const struct hccs_die_info *die = kobj_to_die_info(kobj);
+	struct hccs_dev *hdev = die->chip->hdev;
+	u8 all_linked;
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	ret = hccs_get_die_all_link_status(hdev, die, &all_linked);
+	mutex_unlock(&hdev->lock);
+	if (ret)
+		return sprintf(buf, "get link status failed\n");
+
+	return sprintf(buf, "%u\n", all_linked);
+}
+static struct kobj_attribute all_linked_on_die_attr =
+		__ATTR(all_linked, 0444, all_linked_on_die_show, NULL);
+
+static ssize_t linked_full_lane_on_die_show(struct kobject *kobj,
+					    struct kobj_attribute *attr,
+					    char *buf)
+{
+	const struct hccs_die_info *die = kobj_to_die_info(kobj);
+	struct hccs_dev *hdev = die->chip->hdev;
+	u8 full_lane;
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	ret = hccs_get_die_all_port_lane_status(hdev, die, &full_lane);
+	mutex_unlock(&hdev->lock);
+	if (ret)
+		return sprintf(buf, "get full lane status failed\n");
+
+	return sprintf(buf, "%u\n", full_lane);
+}
+static struct kobj_attribute linked_full_lane_on_die_attr =
+	__ATTR(linked_full_lane, 0444, linked_full_lane_on_die_show, NULL);
+
+static ssize_t crc_err_cnt_sum_on_die_show(struct kobject *kobj,
+					   struct kobj_attribute *attr,
+					   char *buf)
+{
+	const struct hccs_die_info *die = kobj_to_die_info(kobj);
+	struct hccs_dev *hdev = die->chip->hdev;
+	u64 total_crc_err_cnt;
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	ret = hccs_get_die_total_crc_err_cnt(hdev, die, &total_crc_err_cnt);
+	mutex_unlock(&hdev->lock);
+	if (ret)
+		return sprintf(buf, "get total crc error count failed\n");
+
+	return sprintf(buf, "%llu\n", total_crc_err_cnt);
+}
+static struct kobj_attribute crc_err_cnt_sum_on_die_attr =
+	__ATTR(crc_err_cnt, 0444, crc_err_cnt_sum_on_die_show, NULL);
+
+static struct attribute *hccs_die_default_attrs[] = {
+	&all_linked_on_die_attr.attr,
+	&linked_full_lane_on_die_attr.attr,
+	&crc_err_cnt_sum_on_die_attr.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(hccs_die_default);
+
+static const struct kobj_type hccs_die_type = {
+	.sysfs_ops = &hccs_comm_ops,
+	.default_groups = hccs_die_default_groups,
+};
+
+static ssize_t all_linked_on_chip_show(struct kobject *kobj,
+				       struct kobj_attribute *attr, char *buf)
+{
+	const struct hccs_chip_info *chip = kobj_to_chip_info(kobj);
+	struct hccs_dev *hdev = chip->hdev;
+	const struct hccs_die_info *die;
+	u8 all_linked = 1;
+	u8 i, tmp;
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	for (i = 0; i < chip->die_num; i++) {
+		die = &chip->dies[i];
+		ret = hccs_get_die_all_link_status(hdev, die, &tmp);
+		if (ret) {
+			mutex_unlock(&hdev->lock);
+			return sprintf(buf, "get all linked status failed\n");
+		}
+		if (tmp != all_linked) {
+			all_linked = 0;
+			break;
+		}
+	}
+	mutex_unlock(&hdev->lock);
+
+	return sprintf(buf, "%u\n", all_linked);
+}
+static struct kobj_attribute all_linked_on_chip_attr =
+		__ATTR(all_linked, 0444, all_linked_on_chip_show, NULL);
+
+static ssize_t linked_full_lane_on_chip_show(struct kobject *kobj,
+					     struct kobj_attribute *attr,
+					     char *buf)
+{
+	const struct hccs_chip_info *chip = kobj_to_chip_info(kobj);
+	struct hccs_dev *hdev = chip->hdev;
+	const struct hccs_die_info *die;
+	u8 full_lane = 1;
+	u8 i, tmp;
+	int ret;
+
+	mutex_lock(&hdev->lock);
+	for (i = 0; i < chip->die_num; i++) {
+		die = &chip->dies[i];
+		ret = hccs_get_die_all_port_lane_status(hdev, die, &tmp);
+		if (ret) {
+			mutex_unlock(&hdev->lock);
+			return sprintf(buf, "get full lane status failed\n");
+		}
+		if (tmp != full_lane) {
+			full_lane = 0;
+			break;
+		}
+	}
+	mutex_unlock(&hdev->lock);
+
+	return sprintf(buf, "%u\n", full_lane);
+}
+static struct kobj_attribute linked_full_lane_on_chip_attr =
+	__ATTR(linked_full_lane, 0444, linked_full_lane_on_chip_show, NULL);
+
+static ssize_t crc_err_cnt_sum_on_chip_show(struct kobject *kobj,
+					    struct kobj_attribute *attr,
+					    char *buf)
+{
+	const struct hccs_chip_info *chip = kobj_to_chip_info(kobj);
+	u64 crc_err_cnt, total_crc_err_cnt = 0;
+	struct hccs_dev *hdev = chip->hdev;
+	const struct hccs_die_info *die;
+	int ret;
+	u16 i;
+
+	mutex_lock(&hdev->lock);
+	for (i = 0; i < chip->die_num; i++) {
+		die = &chip->dies[i];
+		ret = hccs_get_die_total_crc_err_cnt(hdev, die, &crc_err_cnt);
+		if (ret) {
+			mutex_unlock(&hdev->lock);
+			return sprintf(buf, "get full lane status failed\n");
+		}
+
+		total_crc_err_cnt += crc_err_cnt;
+	}
+	mutex_unlock(&hdev->lock);
+
+	return sprintf(buf, "%llu\n", total_crc_err_cnt);
+}
+static struct kobj_attribute crc_err_cnt_sum_on_chip_attr =
+		__ATTR(crc_err_cnt, 0444, crc_err_cnt_sum_on_chip_show, NULL);
+
+static struct attribute *hccs_chip_default_attrs[] = {
+	&all_linked_on_chip_attr.attr,
+	&linked_full_lane_on_chip_attr.attr,
+	&crc_err_cnt_sum_on_chip_attr.attr,
+	NULL,
+};
+ATTRIBUTE_GROUPS(hccs_chip_default);
+
+static const struct kobj_type hccs_chip_type = {
+	.sysfs_ops = &hccs_comm_ops,
+	.default_groups = hccs_chip_default_groups,
+};
+
+static void hccs_remove_die_dir(struct hccs_die_info *die)
+{
+	struct hccs_port_info *port;
+	u8 i;
+
+	for (i = 0; i < die->port_num; i++) {
+		port = &die->ports[i];
+		if (port->dir_created)
+			kobject_put(&port->kobj);
+	}
+
+	kobject_put(&die->kobj);
+}
+
+static void hccs_remove_chip_dir(struct hccs_chip_info *chip)
+{
+	struct hccs_die_info *die;
+	u8 i;
+
+	for (i = 0; i < chip->die_num; i++) {
+		die = &chip->dies[i];
+		if (die->dir_created)
+			hccs_remove_die_dir(die);
+	}
+
+	kobject_put(&chip->kobj);
+}
+
+static void hccs_remove_topo_dirs(struct hccs_dev *hdev)
+{
+	u8 i;
+
+	for (i = 0; i < hdev->chip_num; i++)
+		hccs_remove_chip_dir(&hdev->chips[i]);
+}
+
+static int hccs_create_hccs_dir(struct hccs_dev *hdev,
+				struct hccs_die_info *die,
+				struct hccs_port_info *port)
+{
+	int ret;
+
+	ret = kobject_init_and_add(&port->kobj, &hccs_port_type,
+				   &die->kobj, "hccs%d", port->port_id);
+	if (ret) {
+		kobject_put(&port->kobj);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int hccs_create_die_dir(struct hccs_dev *hdev,
+			       struct hccs_chip_info *chip,
+			       struct hccs_die_info *die)
+{
+	struct hccs_port_info *port;
+	int ret;
+	u16 i;
+
+	ret = kobject_init_and_add(&die->kobj, &hccs_die_type,
+				   &chip->kobj, "die%d", die->die_id);
+	if (ret) {
+		kobject_put(&die->kobj);
+		return ret;
+	}
+
+	for (i = 0; i < die->port_num; i++) {
+		port = &die->ports[i];
+		ret = hccs_create_hccs_dir(hdev, die, port);
+		if (ret) {
+			dev_err(hdev->dev, "create hccs%d dir failed.\n",
+				port->port_id);
+			goto err;
+		}
+		port->dir_created = true;
+	}
+
+	return 0;
+err:
+	hccs_remove_die_dir(die);
+
+	return ret;
+}
+
+static int hccs_create_chip_dir(struct hccs_dev *hdev,
+				struct hccs_chip_info *chip)
+{
+	struct hccs_die_info *die;
+	int ret;
+	u16 id;
+
+	ret = kobject_init_and_add(&chip->kobj, &hccs_chip_type,
+				   &hdev->dev->kobj, "chip%d", chip->chip_id);
+	if (ret) {
+		kobject_put(&chip->kobj);
+		return ret;
+	}
+
+	for (id = 0; id < chip->die_num; id++) {
+		die = &chip->dies[id];
+		ret = hccs_create_die_dir(hdev, chip, die);
+		if (ret)
+			goto err;
+		die->dir_created = true;
+	}
+
+	return 0;
+err:
+	hccs_remove_chip_dir(chip);
+
+	return ret;
+}
+
+static int hccs_create_topo_dirs(struct hccs_dev *hdev)
+{
+	struct hccs_chip_info *chip;
+	u8 id, k;
+	int ret;
+
+	for (id = 0; id < hdev->chip_num; id++) {
+		chip = &hdev->chips[id];
+		ret = hccs_create_chip_dir(hdev, chip);
+		if (ret) {
+			dev_err(hdev->dev, "init chip%d dir failed!\n", id);
+			goto err;
+		}
+	}
+
+	return 0;
+err:
+	for (k = 0; k < id; k++)
+		hccs_remove_chip_dir(&hdev->chips[k]);
+
+	return ret;
+}
+
+static int hccs_probe(struct platform_device *pdev)
+{
+	struct acpi_device *acpi_dev;
+	struct hccs_dev *hdev;
+	int rc;
+
+	pr_info("kunpeng_hccs is initializing.\n");
+
+	if (acpi_disabled) {
+		dev_err(&pdev->dev, "acpi is disabled.\n");
+		return -ENODEV;
+	}
+	acpi_dev = ACPI_COMPANION(&pdev->dev);
+	if (!acpi_dev)
+		return -ENODEV;
+
+	hdev = devm_kzalloc(&pdev->dev, sizeof(*hdev), GFP_KERNEL);
+	if (!hdev)
+		return -ENOMEM;
+	hdev->acpi_dev = acpi_dev;
+	hdev->dev = &pdev->dev;
+	platform_set_drvdata(pdev, hdev);
+
+	rc = hccs_get_device_property(hdev);
+	if (rc)
+		return rc;
+
+	mutex_init(&hdev->lock);
+
+	rc = hccs_register_pcc_channel(hdev);
+	if (rc)
+		return rc;
+
+	rc = hccs_get_dev_caps(hdev);
+	if (rc)
+		goto err_uninit_mbox_client;
+
+	rc = hccs_get_hw_info(hdev);
+	if (rc)
+		goto err_uninit_mbox_client;
+
+	rc = hccs_create_topo_dirs(hdev);
+	if (rc)
+		goto err_uninit_mbox_client;
+
+	dev_info(&pdev->dev, "HISI HCCS driver registered!\n");
+
+	return 0;
+
+err_uninit_mbox_client:
+	hccs_unregister_pcc_channel(hdev);
+
+	return rc;
+}
+
+static int hccs_remove(struct platform_device *pdev)
+{
+	struct hccs_dev *hdev = platform_get_drvdata(pdev);
+
+	hccs_remove_topo_dirs(hdev);
+	hccs_unregister_pcc_channel(hdev);
+
+	return 0;
+}
+
+static const struct acpi_device_id hccs_acpi_match[] = {
+	{ "HISI04B1", },
+};
+
+static struct platform_driver hccs_driver = {
+	.probe = hccs_probe,
+	.remove = hccs_remove,
+	.driver = {
+		.name = "kunpeng_hccs",
+		.acpi_match_table = ACPI_PTR(hccs_acpi_match),
+	},
+};
+
+module_platform_driver(hccs_driver);
+
+MODULE_DESCRIPTION("Kunpeng SoC HCCS driver");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Huisong Li <[e-mail]>");
diff --git a/drivers/soc/hisilicon/kunpeng_hccs.h b/drivers/soc/hisilicon/kunpeng_hccs.h
new file mode 100644
index 000000000000..ca557ef115ea
--- /dev/null
+++ b/drivers/soc/hisilicon/kunpeng_hccs.h
@@ -0,0 +1,204 @@ 
+/* SPDX-License-Identifier: GPL-2.0+ */
+/* Copyright (c) 2023 Hisilicon Limited. */
+
+#ifndef __KUNPENG_HCCS_H__
+#define __KUNPENG_HCCS_H__
+
+/*
+ * |---------------  Chip0  ---------------|----------------  ChipN  -------------|
+ * |--------Die0-------|--------DieN-------|--------Die0-------|-------DieN-------|
+ * | P0 | P1 | P2 | P3 | P0 | P1 | P2 | P3 | P0 | P1 | P2 | P3 |P0 | P1 | P2 | P3 |
+ */
+
+/*
+ * This value cannot be 255, otherwise the loop of the multi-BD communication
+ * case cannot end.
+ */
+#define HCCS_DIE_MAX_PORT_ID	254
+
+struct hccs_port_info {
+	u8 port_id;
+	u8 port_type;
+	u8 lane_mode;
+	bool is_used; /* if the link is used. */
+	struct kobject kobj;
+	bool dir_created;
+	struct hccs_die_info *die; /* point to the die the port is located */
+};
+
+struct hccs_die_info {
+	u8 die_id;
+	u8 port_num;
+	u8 min_port_id;
+	u8 max_port_id;
+	struct hccs_port_info *ports;
+	struct kobject kobj;
+	bool dir_created;
+	struct hccs_chip_info *chip; /* point to the chip the die is located */
+};
+
+struct hccs_chip_info {
+	u8 chip_id;
+	u8 die_num;
+	struct hccs_die_info *dies;
+	struct kobject kobj;
+	struct hccs_dev *hdev;
+};
+
+struct hccs_mbox_client_info {
+	struct mbox_client client;
+	struct mbox_chan *mbox_chan;
+	struct pcc_mbox_chan *pcc_chan;
+	u64 deadline_us;
+	void *pcc_comm_addr;
+};
+
+enum HCCS_DEV_FLAG_BITS {
+	/* 1 means that driver works on the interrupt mode. */
+	HCCS_DEV_FLAGS_INTR_B = 0,
+};
+
+struct hccs_dev {
+	struct device *dev;
+	struct acpi_device *acpi_dev;
+	u32 flags;
+	u8 type;
+	bool intr_mode;
+	u64 caps;
+	u8 chip_num;
+	struct hccs_chip_info *chips;
+	u32 chan_id;
+	struct mutex lock;
+	struct hccs_mbox_client_info cl_info;
+};
+
+#define HCCS_SERDES_MODULE_CODE 0x32
+enum hccs_subcmd_type {
+	HCCS_GET_CHIP_NUM = 0x1,
+	HCCS_GET_DIE_NUM,
+	HCCS_GET_DIE_INFO,
+	HCCS_GET_DIE_PORT_INFO,
+	HCCS_GET_DEV_CAP,
+	HCCS_GET_PORT_LINK_STATUS,
+	HCCS_GET_PORT_CRC_ERR_CNT,
+	HCCS_GET_DIE_PORTS_LANE_STA,
+	HCCS_GET_DIE_PORTS_LINK_STA,
+	HCCS_GET_DIE_PORTS_CRC_ERR_CNT,
+	HCCS_SUB_CMD_MAX = 255,
+};
+
+struct hccs_die_num_req_param {
+	u8 chip_id;
+};
+
+struct hccs_die_info_req_param {
+	u8 chip_id;
+	u8 die_idx;
+};
+
+struct hccs_die_info_rsp_data {
+	u8 die_id;
+	u8 port_num;
+	u8 min_port_id;
+	u8 max_port_id;
+};
+
+struct hccs_port_attr {
+	u8 port_id;
+	u8 port_type;
+	u8 lane_mode;
+	u8 is_used : 1; /* if the link is used. */
+	u16 rsv[2];
+};
+
+/*
+ * The common command request for getting the all information of HCCS port on
+ * specified DIE.
+ */
+struct hccs_die_comm_req_param {
+	u8 chip_id;
+	u8 die_id; /* id in hardware */
+};
+
+/* The common command request for getting the information of a specific port */
+struct hccs_port_comm_req_param {
+	u8 chip_id;
+	u8 die_id;
+	u8 port_id;
+};
+
+#define HCCS_PORT_RESET         1
+#define HCCS_PORT_SETUP         2
+#define HCCS_PORT_CONFIG        3
+#define HCCS_PORT_READY         4
+struct hccs_link_status {
+	u8 lane_mask; /* indicate which lanes are used. */
+	u8 link_fsm : 3; /* link fsm, 1: reset 2: setup 3: config 4: link-up */
+	u8 lane_num : 5; /* current lane number */
+};
+
+struct hccs_req_head {
+	u8 module_code; /* set to 0x32 for serdes */
+	u8 start_id;
+	u8 rsv[2];
+};
+
+struct hccs_rsp_head {
+	u8 data_len;
+	u8 next_id;
+	u8 rsv[2];
+};
+
+struct hccs_fw_inner_head {
+	u8 retStatus; /* 0: success, other: failure */
+	u8 rsv[7];
+};
+
+#define HCCS_PCC_SHARE_MEM_BYTES	64
+#define HCCS_FW_INNER_HEAD_BYTES	8
+#define HCCS_RSP_HEAD_BYTES		4
+
+#define HCCS_MAX_RSP_DATA_BYTES		(HCCS_PCC_SHARE_MEM_BYTES - \
+					 HCCS_FW_INNER_HEAD_BYTES - \
+					 HCCS_RSP_HEAD_BYTES)
+#define HCCS_MAX_RSP_DATA_SIZE_MAX	(HCCS_MAX_RSP_DATA_BYTES / 4)
+
+/*
+ * Note: Actual available size of data field also depands on the PCC header
+ * bytes of the specific type. Driver needs to copy the response data in the
+ * communication space based on the real length.
+ */
+struct hccs_rsp_desc {
+	struct hccs_fw_inner_head fw_inner_head; /* 8 Bytes */
+	struct hccs_rsp_head rsp_head; /* 4 Bytes */
+	u32 data[HCCS_MAX_RSP_DATA_SIZE_MAX];
+};
+
+#define HCCS_REQ_HEAD_BYTES		4
+#define HCCS_MAX_REQ_DATA_BYTES		(HCCS_PCC_SHARE_MEM_BYTES - \
+					 HCCS_REQ_HEAD_BYTES)
+#define HCCS_MAX_REQ_DATA_SIZE_MAX	(HCCS_MAX_REQ_DATA_BYTES / 4)
+
+/*
+ * Note: Actual available size of data field also depands on the PCC header
+ * bytes of the specific type. Driver needs to copy the request data to the
+ * communication space based on the real length.
+ */
+struct hccs_req_desc {
+	struct hccs_req_head req_head; /* 4 Bytes */
+	u32 data[HCCS_MAX_REQ_DATA_SIZE_MAX];
+};
+
+struct hccs_desc {
+	union {
+		struct hccs_req_desc req;
+		struct hccs_rsp_desc rsp;
+	};
+};
+
+#define hccs_get_field(origin, mask, shift) \
+	(((origin) & (mask)) >> (shift))
+#define hccs_get_bit(origin, shift) \
+	hccs_get_field((origin), (0x1UL << (shift)), (shift))
+
+#endif /* __KUNPENG_HCCS_H__ */