Messages in this thread |  | | Subject | Re: [PATCH 1/1] ARM: LPAE: use phys_addr_t instead of unsigned long in outercache hooks | From | "Leizhen (ThunderTown)" <> | Date | Tue, 29 Dec 2020 14:30:56 +0800 |
| |
On 2020/12/26 20:13, Russell King - ARM Linux admin wrote: > On Fri, Dec 25, 2020 at 07:44:58PM +0800, Zhen Lei wrote: >> The outercache of some Hisilicon SOCs support physical addresses wider >> than 32-bits. The unsigned long datatype is not sufficient for mapping >> physical addresses >= 4GB. The commit ad6b9c9d78b9 ("ARM: 6671/1: LPAE: >> use phys_addr_t instead of unsigned long in outercache functions") has >> already modified the outercache functions. But the parameters of the >> outercache hooks are not changed. This patch use phys_addr_t instead of >> unsigned long in outercache hooks: inv_range, clean_range, flush_range. >> >> To ensure the outercache that does not support LPAE works properly, do >> cast phys_addr_t to unsigned long by adding a middle-tier function. > > Please don't do that. The cast can be done inside the L2 functions > themselves without needing all these additional functions.
OK. At first, I wanted to fit in like this:
-static void l2c220_inv_range(unsigned long start, unsigned long end) +static void l2c220_inv_range(phys_addr_t lpae_start, phys_addr_t lpae_end) { + unsigned long start = lpae_start; + unsigned long end = lpae_end;
> > We probably ought to also add some protection against addresses > 4GB, > although these are hot paths, so we don't want to add tests in these > functions. Maybe instead checking whether the system has memory above > 4GB while the L2 cache is being initialised would be a good idea? >
I'm sorry, I didn't quite understand what you meant. Currently, the biggest problem is the compilation problem. The sizeof(long) may be 32, and the 64-bit physical address cannot be transferred from outcache functions to outcache hooks.
|  |