Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     Nicolas Saenz Julienne <nsaenz@kernel.org>,
        bcm-kernel-feedback-list@broadcom.com,
        linux-rpi-kernel@lists.infradead.org,
        linux-arm-kernel@lists.infradead.org,
        linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org,
        ira.weiny@intel.com, outreachy@lists.linux.dev
Subject: Re: [PATCH] staging: vc04_services: Convert kmap() to kmap_local_page()
Date:   Fri, 01 Apr 2022 10:07:36 +0200
Message-ID: <3162339.aeNJFYEL58@leap>
In-Reply-To: <20220330191414.23141-1-fmdefrancesco@gmail.com>
References: <20220330191414.23141-1-fmdefrancesco@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Precedence: bulk

On mercoled=EC 30 marzo 2022 21:14:14 CEST Fabio M. De Francesco wrote:
> The use of kmap() is being deprecated in favor of kmap_local_page()
> where it is feasible. In file interface/vchiq_arm/vchiq_arm.c,
> function free_pagelist() calls kmap() / kunmap() from two places.
>=20
> With kmap_local_page(), the mapping is per thread, CPU local and not
> globally visible. Therefore, free_pagelist() is a function where the
> use of kmap_local_page() in place of kmap() is correctly suited.
>=20
> Convert to kmap_local_page() but, instead of open coding it, use the
> memcpy_to_page() helper.
>=20
> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> ---
>  .../vc04_services/interface/vchiq_arm/vchiq_arm.c   | 13 +++++--------
>  1 file changed, 5 insertions(+), 8 deletions(-)
>=20
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.=
c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index f0bfacfdea80..efb1383b5218 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -431,21 +431,18 @@ free_pagelist(struct vchiq_pagelist_info *pagelisti=
nfo,
>  			if (head_bytes > actual)
>  				head_bytes =3D actual;
> =20
> -			memcpy((char *)kmap(pages[0]) +
> +			memcpy_to_page(pages[0],
>  				pagelist->offset,
>  				fragments,
>  				head_bytes);
> -			kunmap(pages[0]);
>  		}
>  		if ((actual >=3D 0) && (head_bytes < actual) &&
> -		    (tail_bytes !=3D 0)) {
> -			memcpy((char *)kmap(pages[num_pages - 1]) +
> -				((pagelist->offset + actual) &
> -				(PAGE_SIZE - 1) & ~(g_cache_line_size - 1)),
> +		    (tail_bytes !=3D 0))
> +			memcpy_to_page(pages[num_pages - 1],
> +				(pagelist->offset + actual) &
> +				(PAGE_SIZE - 1) & ~(g_cache_line_size - 1),
>  				fragments + g_cache_line_size,
>  				tail_bytes);
> -			kunmap(pages[num_pages - 1]);
> -		}
> =20
>  		down(&g_free_fragments_mutex);
>  		*(char **)fragments =3D g_free_fragments;
> --=20
> 2.34.1
>=20
Hi Greg,

I've just received a message from you that says that a patch that I sent
on March 31 has been applied to staging testing. I know that you usually
apply patches in first come first served fashion (FIFO), therefore I wonder
why this patch has not yet been applied.

Please don't misunderstand me: I have no hurry. I'm asking only because=20
I suspect that this patch, sent on March 30th) could have been overlooked=20
since it has the very identical subject of another patch that I sent on=20
the same day (or the day before, I'm not sure about it now) and which has=20
already been applied. Therefore, they may appear to be the same patch,
because the only difference is that the drivers are different.

Thanks,

=46abio