From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82AC4C001B0 for ; Mon, 24 Jul 2023 08:08:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230356AbjGXIId (ORCPT ); Mon, 24 Jul 2023 04:08:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230412AbjGXIIa (ORCPT ); Mon, 24 Jul 2023 04:08:30 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.154.123]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 767A7113 for ; Mon, 24 Jul 2023 01:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1690186110; x=1721722110; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=FMRmaRUw8VrEz5cIUd4uabLoqD8FojfSTBD+JH7d/78=; b=nCoC26aUDb1FK57JUFPQp9SUN6ZtnO7ARBELfEbVdoLU2kNkUrQ0g0/f y4FML2Oc0tgfRsvZESoLaWAQDG6y8iPkHYJvs8D/swsxkaob7M668pYrt 74vQPW9XPk9ZaB4l9Hs8v2jmyBXldrfQ5/H0U0SSYXfsGQxr62uQNm8Fd Qjaq4nK6ginYUHKHTypNCukprGvSVUIn5lmbeVt+wWoZg9YMKG7ulNJ0f IvsZ0v9QvgGV+9pNKHPsZoEZ4Rw+lRNAgREPlqfadiYZNpWpAqepj04Yu t2FVw1EtQy1iqhyJLlYofZyTQXkygzd2cd2gINVNS3zUhVIU8gODpJqVq Q==; X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="asc'?scan'208";a="221826073" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa4.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 24 Jul 2023 01:08:29 -0700 Received: from chn-vm-ex04.mchp-main.com (10.10.85.152) by chn-vm-ex03.mchp-main.com (10.10.85.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Mon, 24 Jul 2023 01:08:21 -0700 Received: from wendy (10.10.115.15) by chn-vm-ex04.mchp-main.com (10.10.85.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21 via Frontend Transport; Mon, 24 Jul 2023 01:08:20 -0700 Date: Mon, 24 Jul 2023 09:07:46 +0100 From: Conor Dooley To: Sunil V L CC: , , Paul Walmsley , Palmer Dabbelt , Albert Ou , Andrew Jones , kernel test robot Subject: Re: [PATCH v2 -fixes] RISC-V: ACPI: Fix acpi_os_ioremap to return iomem address Message-ID: <20230724-phonics-earthling-d104ef807286@wendy> References: <20230723191758.1262960-1-sunilvl@ventanamicro.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vtD17YszkGN6XtYe" Content-Disposition: inline In-Reply-To: <20230723191758.1262960-1-sunilvl@ventanamicro.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --vtD17YszkGN6XtYe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 24, 2023 at 12:47:58AM +0530, Sunil V L wrote: > acpi_os_ioremap() currently is a wrapper to memremap() on > RISC-V. But the callers of acpi_os_ioremap() expect it to > return __iomem address and hence sparse tool reports a new > warning. Fix this issue by type casting to __iomem type. >=20 > Reported-by: kernel test robot > Closes: https://lore.kernel.org/oe-kbuild-all/202307230357.egcTAefj-lkp@i= ntel.com/ > Fixes: a91a9ffbd3a5 ("RISC-V: Add support to build the ACPI core") > Signed-off-by: Sunil V L > --- > Changes since v1: > 1) Removed enhancements from the fix patch. >=20 > arch/riscv/include/asm/acpi.h | 2 +- > arch/riscv/kernel/acpi.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) >=20 > diff --git a/arch/riscv/include/asm/acpi.h b/arch/riscv/include/asm/acpi.h > index f71ce21ff684..d5604d2073bc 100644 > --- a/arch/riscv/include/asm/acpi.h > +++ b/arch/riscv/include/asm/acpi.h > @@ -19,7 +19,7 @@ typedef u64 phys_cpuid_t; > #define PHYS_CPUID_INVALID INVALID_HARTID > =20 > /* ACPI table mapping after acpi_permanent_mmap is set */ > -void *acpi_os_ioremap(acpi_physical_address phys, acpi_size size); > +void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size= ); > #define acpi_os_ioremap acpi_os_ioremap > =20 > #define acpi_strict 1 /* No out-of-spec workarounds on RISC-V */ > diff --git a/arch/riscv/kernel/acpi.c b/arch/riscv/kernel/acpi.c > index 5ee03ebab80e..e6fdb9edcdd9 100644 > --- a/arch/riscv/kernel/acpi.c > +++ b/arch/riscv/kernel/acpi.c > @@ -215,9 +215,9 @@ void __init __acpi_unmap_table(void __iomem *map, uns= igned long size) > early_iounmap(map, size); > } > =20 > -void *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > +void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) > { > - return memremap(phys, size, MEMREMAP_WB); > + return (__force void __iomem *) memremap(phys, size, MEMREMAP_WB); Why's the __force needed? Does sparse complain about the cast too? --vtD17YszkGN6XtYe Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZL4xUgAKCRB4tDGHoIJi 0g6UAQCpdPC3pWYrjW9HbFWmEsgechOUzkb7sDDVFEdus8ebUwD8DxsbPpagXY7Q XnpxLi85wHlgX8DuIZMxzId9C27Jcw0= =9frk -----END PGP SIGNATURE----- --vtD17YszkGN6XtYe--