[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7852a2b4-b601-f4e8-bc5f-7b1bc9d9dc69@huawei.com>
Date: Tue, 30 May 2023 10:53:38 +0800
From: "lihuisong (C)" <lihuisong@...wei.com>
To: Sudeep Holla <sudeep.holla@....com>
CC: <andersson@...nel.org>, <matthias.bgg@...il.com>,
<angelogioacchino.delregno@...labora.com>, <shawnguo@...nel.org>,
<arnd@...db.de>, <krzk@...nel.org>, <linux-kernel@...r.kernel.org>,
<soc@...nel.org>, <wanghuiqiang@...wei.com>,
<tanxiaofei@...wei.com>, <liuyonglong@...wei.com>
Subject: Re: [PATCH v2 1/2] soc: hisilicon: Support HCCS driver on Kunpeng SoC
Hi Sudeep,
在 2023/5/25 16:12, lihuisong (C) 写道:
>
> 在 2023/5/25 15:35, Sudeep Holla 写道:
>> On Thu, May 25, 2023 at 10:41:51AM +0800, lihuisong (C) wrote:
>>> Hi Sudeep,
>>>
>>> Here, the interface is used to determine whether a port is in use or
>>> enabled.
>>> If we just use 'status', it cannot inidicates its own meaning by name.
>>> What do you think?
>>>
>> How about "port_status" or "port-status" ?
> The meaning of this status is a little board.
> How about 'enable'? just a read-only entry.
>
>
"using_status" --> "enable" ? What do you think?
Its original purpose was to determine whether a port is in use or enabled.
> In addition, I happen to have another problem when replace ioremap()
> with acpi_os_ioremap().
>
> The driver selects 'M' in .config to compile.
> The driver cannot be compiled if we use acpi_os_ioremap().
> The compiling log is as follows:
> -->
> make -j80
> CALL scripts/checksyscalls.sh
> CC [M] drivers/soc/hisilicon/kunpeng_hccs.o
> MODPOST Module.symvers
> ERROR: modpost: "acpi_os_ioremap"
> [drivers/soc/hisilicon/kunpeng_hccs.ko] undefined!
> scripts/Makefile.modpost:136: recipe for target 'Module.symvers' failed
> make[1]: *** [Module.symvers] Error 1
> Makefile:1978: recipe for target 'modpost' failed
> make: *** [modpost] Error 2
>
> The driver can be compiled if we selects 'Y' or export symbol for
> acpi_os_ioremap.
> So we have to export symbol for acpi_os_ioremap.
> I plan to do it in another patch, and not in this series in case of
> blocking the upload of this driver.
> What do you think?
Someone disagree we do it here. please see the patch[1].
So we have to keep what it was.
[1]
https://lore.kernel.org/linux-arm-kernel/d180192a-afad-00dc-426f-3d8d249cdd89@huawei.com/T/
Powered by blists - more mailing lists