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: <a98e3620-57da-000e-f5ee-2c2e47e97906@huawei.com>
Date:   Wed, 17 May 2023 15:16:12 +0800
From:   "lihuisong (C)" <lihuisong@...wei.com>
To:     Sudeep Holla <sudeep.holla@....com>
CC:     Arnd Bergmann <arnd@...db.de>,
        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/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?
>