linux-kernel - Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c7d9c3c5-e400-c60a-52e0-0f267ec8c517@huawei.com>
Date:   Tue, 25 Apr 2023 21:00:31 +0800
From:   "lihuisong (C)" <lihuisong@...wei.com>
To:     Sudeep Holla <sudeep.holla@....com>, Arnd Bergmann <arnd@...db.de>
CC:     Bjorn Andersson <andersson@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Shawn Guo <shawnguo@...nel.org>,
        <linux-kernel@...r.kernel.org>, <soc@...nel.org>,
        <wanghuiqiang@...wei.com>, <tanxiaofei@...wei.com>,
        <liuyonglong@...wei.com>, <huangdaode@...wei.com>,
        <linux-acpi@...r.kernel.org>, Len Brown <lenb@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        <devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Subject: Re: [PATCH] soc: hisilicon: Support HCCS driver on Kunpeng SoC


在 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.
>
> .