From: Zaid Alali <zaidal@os.amperecomputing.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: rafael@kernel.org, lenb@kernel.org, james.morse@arm.com,
tony.luck@intel.com, bp@alien8.de, robert.moore@intel.com,
dan.j.williams@intel.com, Benjamin.Cheatham@amd.com,
Avadhut.Naik@amd.com, viro@zeniv.linux.org.uk, arnd@arndb.de,
ira.weiny@intel.com, dave.jiang@intel.com,
sthanneeru.opensrc@micron.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, acpica-devel@lists.linux.dev
Subject: Re: [PATCH v2 3/9] ACPI: APEI: EINJ: Fix kernel test robot sparse warning
Date: Thu, 2 Jan 2025 13:24:43 -0800 [thread overview]
Message-ID: <Z3cEGw0qFqj8peoQ@zaid-VirtualBox> (raw)
In-Reply-To: <20241224152855.000044d0@huawei.com>
On Tue, Dec 24, 2024 at 03:28:55PM +0000, Jonathan Cameron wrote:
> On Thu, 5 Dec 2024 13:18:48 -0800
> Zaid Alali <zaidal@os.amperecomputing.com> wrote:
>
> > This patch fixes the kernel test robot warning reported here:
> > https://lore.kernel.org/all/202410241620.oApALow5-lkp@intel.com/
> >
> > Signed-off-by: Zaid Alali <zaidal@os.amperecomputing.com>
> > ---
> > drivers/acpi/apei/einj-core.c | 41 +++++++++++++++++++++--------------
> > 1 file changed, 25 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
> > index 04731a5b01fa..74dfb3daba50 100644
> > --- a/drivers/acpi/apei/einj-core.c
> > +++ b/drivers/acpi/apei/einj-core.c
> > @@ -215,20 +215,22 @@ static void check_vendor_extension(u64 paddr,
> > {
> > int offset = v5param->vendor_extension;
> > struct vendor_error_type_extension *v;
> > + void __iomem *p;
> > u32 sbdf;
> >
> > if (!offset)
> > return;
> > - v = acpi_os_map_iomem(paddr + offset, sizeof(*v));
> > - if (!v)
> > + p = acpi_os_map_iomem(paddr + offset, sizeof(*v));
> > + if (!p)
> > return;
> > + v = __io_virt(p);
>
> That's a nasty forced cast. Far as I can tell all this code
> should not be assuming it can just cast away the __iomem
>
> I think it should be fixed by using readl() etc or
> memcpy_fromio()
>
> Maybe it is safe to just ignore the marking for all current ACPI
> platforms, I'm not sure. This isn't a high performance path so
> personally I'd just do it the generic way even if it is not
> strictly necessary.
>
> Jonathan
>
Hi Jonathan,
Thank you for taking the time to review the patches!
These iomem warnings were there before the new patches, since the code has to
access iomem location for read/write to communicate with firmware.
I agree with you on ignoring the marking for ACPI platforms. I can also change
the code to use memcpy_fromio() to create local copies of iomem locations, and
write them back later instead. However, it will add a little more
complexity to the code, because iomem mapping and subsequent reads/writes
happen in different functions.
please let me know if you have any more thoughts on this.
Thanks,
Zaid Alali
>
>
> > get_oem_vendor_struct(paddr, offset, v);
> > sbdf = v->pcie_sbdf;
> > sprintf(vendor_dev, "%x:%x:%x.%x vendor_id=%x device_id=%x rev_id=%x\n",
> > sbdf >> 24, (sbdf >> 16) & 0xff,
> > (sbdf >> 11) & 0x1f, (sbdf >> 8) & 0x7,
> > v->vendor_id, v->device_id, v->rev_id);
> > - acpi_os_unmap_iomem(v, sizeof(*v));
> > + acpi_os_unmap_iomem(p, sizeof(*v));
> > }
> >
> > static void *einj_get_parameter_address(void)
> > @@ -253,9 +255,11 @@ static void *einj_get_parameter_address(void)
> > }
> > if (pa_v5) {
> > struct set_error_type_with_address *v5param;
> > + void __iomem *p;
> >
> > - v5param = acpi_os_map_iomem(pa_v5, sizeof(*v5param));
> > - if (v5param) {
> > + p = acpi_os_map_iomem(pa_v5, sizeof(*v5param));
> > + if (p) {
> > + v5param = __io_virt(p);
> > acpi5 = 1;
> > check_vendor_extension(pa_v5, v5param);
> > return v5param;
> > @@ -263,12 +267,14 @@ static void *einj_get_parameter_address(void)
> > }
> > if (param_extension && pa_v4) {
> > struct einj_parameter *v4param;
> > + void __iomem *p;
> >
> > - v4param = acpi_os_map_iomem(pa_v4, sizeof(*v4param));
> > - if (!v4param)
> > + p = acpi_os_map_iomem(pa_v4, sizeof(*v4param));
> > + if (!p)
> > return NULL;
> > + v4param = __io_virt(p);
> > if (v4param->reserved1 || v4param->reserved2) {
> > - acpi_os_unmap_iomem(v4param, sizeof(*v4param));
> > + acpi_os_unmap_iomem(p, sizeof(*v4param));
> > return NULL;
> > }
> > return v4param;
> > @@ -325,6 +331,7 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
> > u32 table_size;
> > int rc = -EIO;
> > struct acpi_generic_address *trigger_param_region = NULL;
> > + void __iomem *p;
> >
> > r = request_mem_region(trigger_paddr, sizeof(*trigger_tab),
> > "APEI EINJ Trigger Table");
> > @@ -335,11 +342,12 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
> > sizeof(*trigger_tab) - 1);
> > goto out;
> > }
> > - trigger_tab = ioremap_cache(trigger_paddr, sizeof(*trigger_tab));
> > - if (!trigger_tab) {
> > + p = ioremap_cache(trigger_paddr, sizeof(*trigger_tab));
> > + if (!p) {
> > pr_err("Failed to map trigger table!\n");
> > goto out_rel_header;
> > }
> > + trigger_tab = __io_virt(p);
> > rc = einj_check_trigger_header(trigger_tab);
> > if (rc) {
> > pr_warn(FW_BUG "Invalid trigger error action table.\n");
> > @@ -361,12 +369,13 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
> > (unsigned long long)trigger_paddr + table_size - 1);
> > goto out_rel_header;
> > }
> > - iounmap(trigger_tab);
> > - trigger_tab = ioremap_cache(trigger_paddr, table_size);
> > - if (!trigger_tab) {
> > + iounmap(p);
> > + p = ioremap_cache(trigger_paddr, table_size);
> > + if (!p) {
> > pr_err("Failed to map trigger table!\n");
> > goto out_rel_entry;
> > }
> > + trigger_tab = __io_virt(p);
> > trigger_entry = (struct acpi_whea_header *)
> > ((char *)trigger_tab + sizeof(struct acpi_einj_trigger));
> > apei_resources_init(&trigger_resources);
> > @@ -424,8 +433,8 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
> > out_rel_header:
> > release_mem_region(trigger_paddr, sizeof(*trigger_tab));
> > out:
> > - if (trigger_tab)
> > - iounmap(trigger_tab);
> > + if (p)
> > + iounmap(p);
> >
> > return rc;
> > }
> > @@ -860,7 +869,7 @@ static void __exit einj_remove(struct platform_device *pdev)
> > sizeof(struct set_error_type_with_address) :
> > sizeof(struct einj_parameter);
> >
> > - acpi_os_unmap_iomem(einj_param, size);
> > + acpi_os_unmap_iomem((void __iomem *)einj_param, size);
> > if (vendor_errors.size)
> > acpi_os_unmap_memory(vendor_errors.data, vendor_errors.size);
> > }
>
next prev parent reply other threads:[~2025-01-02 21:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 21:18 [PATCH v2 0/9] Enable EINJv2 support Zaid Alali
2024-12-05 21:18 ` [PATCH v2 1/9] ACPICA: Update values to hex to follow ACPI specs Zaid Alali
2024-12-05 21:18 ` [PATCH v2 2/9] ACPICA: Add EINJv2 get error type action Zaid Alali
2024-12-05 21:18 ` [PATCH v2 3/9] ACPI: APEI: EINJ: Fix kernel test robot sparse warning Zaid Alali
2024-12-06 3:21 ` kernel test robot
2024-12-24 15:28 ` Jonathan Cameron
2025-01-02 21:24 ` Zaid Alali [this message]
2024-12-05 21:18 ` [PATCH v2 4/9] ACPI: APEI: EINJ: Remove redundant calls to einj_get_available_error_type Zaid Alali
2024-12-24 15:32 ` Jonathan Cameron
2024-12-05 21:18 ` [PATCH v2 5/9] ACPI: APEI: EINJ: Enable the discovery of EINJv2 capabilities Zaid Alali
2024-12-06 3:10 ` kernel test robot
2024-12-06 4:54 ` kernel test robot
2024-12-06 21:02 ` kernel test robot
2024-12-24 15:46 ` Jonathan Cameron
2024-12-05 21:18 ` [PATCH v2 6/9] ACPI: APEI: EINJ: Add einjv2 extension struct Zaid Alali
2024-12-24 15:51 ` Jonathan Cameron
2025-02-06 22:08 ` Zaid Alali
2024-12-05 21:18 ` [PATCH v2 7/9] ACPI: APEI: EINJ: Add debugfs files for EINJv2 support Zaid Alali
2024-12-05 21:18 ` [PATCH v2 8/9] ACPI: APEI: EINJ: Enable EINJv2 error injections Zaid Alali
2024-12-24 15:57 ` Jonathan Cameron
2024-12-05 21:18 ` [PATCH v2 9/9] ACPI: APEI: EINJ: Update the documentation for EINJv2 support Zaid Alali
2025-01-08 9:55 ` Lai, Yi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z3cEGw0qFqj8peoQ@zaid-VirtualBox \
--to=zaidal@os.amperecomputing.com \
--cc=Avadhut.Naik@amd.com \
--cc=Benjamin.Cheatham@amd.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=acpica-devel@lists.linux.dev \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=ira.weiny@intel.com \
--cc=james.morse@arm.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.com \
--cc=sthanneeru.opensrc@micron.com \
--cc=tony.luck@intel.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.