From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sakura.ysato.name (ik1-413-38519.vs.sakura.ne.jp [153.127.30.23]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 41769152788 for ; Thu, 2 May 2024 14:00:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=153.127.30.23 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714658420; cv=none; b=Vdnu6cSAEF3l3bo814dOZ14x9HfxQejnLrxdqdt7vpF7MQqAktANMoERsa7Cp2W+Gp9gKo/EPrlriR+QHsW5O1brlvzCPpkuTzXgSCh6OrO+mxDkGSHH9hA9MnUxuqktHrgqDi0PEPWsZilNJ6ypHGE1hVcpkFAObia4mAJvlFc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1714658420; c=relaxed/simple; bh=8quZaRT8DOKODye95RNwXhlVf4S2B1EFDI9fcuSpwy8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=gyEPgXruMV6eWhQUeqNSlyEq0AcqTPmtbxSjzHAiQ1l13lFVKCrZxlUc/BP2bM1WJmfD9w5D0dUBHfhpcsoRVWhk7+Gv8f+4QGaltvVQHlwWGtGYvgCyM/YIlhslzGtRvJadyIod1YclSi2EO30TYV3qUutXeuesirC47qGhI74= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=users.sourceforge.jp; spf=fail smtp.mailfrom=users.sourceforge.jp; arc=none smtp.client-ip=153.127.30.23 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=users.sourceforge.jp Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=users.sourceforge.jp Received: from SIOS1075.ysato.ml (ZM005235.ppp.dion.ne.jp [222.8.5.235]) by sakura.ysato.name (Postfix) with ESMTPSA id D408D1C0109; Thu, 2 May 2024 22:50:41 +0900 (JST) Date: Thu, 02 May 2024 22:50:41 +0900 Message-ID: <87o79o9vbi.wl-ysato@users.sourceforge.jp> From: Yoshinori Sato To: Geert Uytterhoeven Cc: John Paul Adrian Glaubitz , Rich Felker , Arnd Bergmann , linux-sh@vger.kernel.org Subject: Re: [PATCH] sh: boot: Remove sh5 cache handling In-Reply-To: References: <23e9b3fd0d78e46c9fc1835852ba226aba92c3ca.1713959531.git.geert+renesas@glider.be> <23a3abf08f358588ef448c1a2f2ef53013ce6b69.camel@physik.fu-berlin.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-sh@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 29 Apr 2024 17:06:44 +0900, Geert Uytterhoeven wrote: >=20 > Hi Adrian, >=20 > On Mon, Apr 29, 2024 at 9:52=E2=80=AFAM John Paul Adrian Glaubitz > wrote: > > On Mon, 2024-04-29 at 09:49 +0200, Geert Uytterhoeven wrote: > > > On Mon, Apr 29, 2024 at 9:46=E2=80=AFAM John Paul Adrian Glaubitz > > > wrote: > > > > On Wed, 2024-04-24 at 13:54 +0200, Geert Uytterhoeven wrote: > > > > > Commit 37744feebc086908 ("sh: remove sh5 support") in v5.8 forgot= to > > > > > remove the sh5 cache handling. > > > > > > > > > > Suggested-by: Yoshinori Sato > > > > > Signed-off-by: Geert Uytterhoeven > > > > > > > > --- a/arch/sh/boot/compressed/cache.c > > > > > +++ /dev/null > > > > > @@ -1,13 +0,0 @@ > > > > > -// SPDX-License-Identifier: GPL-2.0 > > > > > -int cache_control(unsigned int command) > > > > > -{ > > > > > - volatile unsigned int *p =3D (volatile unsigned int *) 0x80= 000000; > > > > > - int i; > > > > > - > > > > > - for (i =3D 0; i < (32 * 1024); i +=3D 32) { > > > > > - (void)*p; > > > > > - p +=3D (32 / sizeof(int)); > > > > > - } > > > > > - > > > > > - return 0; > > > > > -} > > > > > > > Interesting, looking at boot/compressed/cache.c, it seems that the = whole code > > > > is actually a no-op and does nothing but increasing a pointer. So I= agree we > > > > should just delete it. > > > > > > It is not a no-op: it also reads from memory, to load new data in > > > the cache, and evicting the old data. > > > > Yeah, I actually came to this conclusion right after sending my reply. = However, the > > command parameter is never used. > > > > Don't have the 32-bit SH CPUs any caches? The code itself is unconditio= nally executed, > > it seems. >=20 > They do. E.g. SH7751 has 8+8 KiB of L1 cache. > But e.g. sh7724 has 32+32KiB L1 cache, and 256 KiB of unified L2 cache. > SH772[34] have l2_cache_init() to enable the L2 cache, so probably they > boot with L2 disabled, and we are fine. >=20 > Unfortunately I don't have access to a SH772[34] system. > Sato-san: can you confirm? > Thanks! 32-bit SH requires different cache control for each SoC. It's difficult to put general purpose cache control code here. The location where the zImage is expanded is not in the instruction cache, so there is no problem even if it is not explicitly flushed after expansion. boot/compressed/cache.c also has no meaning now. > Gr{oetje,eeting}s, >=20 > Geert >=20 > --=20 > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m6= 8k.org >=20 > In personal conversations with technical people, I call myself a hacker. = But > when I'm talking to journalists I just say "programmer" or something like= that. > -- Linus Torvalds --=20 Yosinori Sato