From patchwork Tue Aug 16 20:41:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Conor Dooley X-Patchwork-Id: 597616 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 12729C25B0E for ; Tue, 16 Aug 2022 20:41:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236629AbiHPUlb (ORCPT ); Tue, 16 Aug 2022 16:41:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231594AbiHPUl3 (ORCPT ); Tue, 16 Aug 2022 16:41:29 -0400 Received: from esa.microchip.iphmx.com (esa.microchip.iphmx.com [68.232.153.233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60D5E80359; Tue, 16 Aug 2022 13:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=microchip.com; i=@microchip.com; q=dns/txt; s=mchp; t=1660682488; x=1692218488; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3ZdsDUVcfw2/ao3YXPnvSfYOsWA/6BZ9e1kIhpTqJvM=; b=EATEemoN2EG+v1uTbAv0vmwn3+DQn5iHwvJeCu7QcnADWNtKxNIic6X3 tAjIvkG4KkuJ+Uqas2VqMPJM7hvYpTYzNKX9aj4eTjWdyIC1rFgETQ5H5 Hoqi6Rhpo3DNuHrPlZ5IKRBoZxh/LfN2MVKtHVeHLP/4VQmahwzHiMud6 K0P0yYrWLeYYHhg/cAFt5ulBtoPfP/JNRj2QdQsxw92zkcnbdXp4M+E16 UsqiNFdBaTXZsWlA6VG6KVx5cZ659Uit342zL86VFvLzNyG1bQqRI4Xwf 4usnkNqGCcmcz5663p1Cevrek1BgSCyr0PLA0RRX7h0nJ47qiNFYrG+75 g==; X-IronPort-AV: E=Sophos;i="5.93,242,1654585200"; d="scan'208,223";a="176659473" Received: from unknown (HELO email.microchip.com) ([170.129.1.10]) by esa3.microchip.iphmx.com with ESMTP/TLS/AES256-SHA256; 16 Aug 2022 13:41:23 -0700 Received: from chn-vm-ex02.mchp-main.com (10.10.85.144) 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.12; Tue, 16 Aug 2022 13:41:23 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (10.10.215.89) by email.microchip.com (10.10.87.72) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12 via Frontend Transport; Tue, 16 Aug 2022 13:41:22 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DpS74fsWfKZkHH9tA5BG34ABfv0gPUPVdJPmSBKaDdmh+NYjcFM2EjfhqBQVqzRoPVPyHdDuBDS3d5fNd4N3rdjbbfB/0m3EF56VWXJYimpuvMGScz4FgiR8zb9pZ2rIRpyX1dgDIxQtcqP18PXP4nZE8HAseyigAE02Mf2SBgnxUhKt2mHS0iGOdXMENHyD3riBBF/lEce6ywW6tY0Qd5K0laGK5cfLWUrWehcTrlWbxNCoPE4M50jtzSXzRedZULeiCcoGeK1kMpvSYqC/kP/6xYsYSKOdHupY/lztz6O+TRCesucOaqZSTXckCF/Q556c4D2/eVfd6Dqsvq/vTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6XaZlO8nz3v0YO//QFi927MR019xD23XV8mFpGm7S1U=; b=lJP4vESvqzjPUDLjOfXP8zkpfSA8AZU+IUeVKtjJzd6UZg2TLbX5Tf4xQmv0sZvv4iZFEAEOZyJkeQ0lKSZ8o4H3kSj95sa+LvY7u//TfkY6SfhvbCYweYtAkJshgPBpEcPF4QoJtTHj57G2DhNnNUaOtewQ+n6l5LdgnETWZUeg4UKEzhHR5whXH8+3yL9ApDxQI5Yvs7r2JpGPaTk8QYpdrqMQcsWkMvqk9XC7spSfptsXyu2hfL3eK4y4i45xjlV1Cu01dtwT7fg5iiLnqULo2pC5Af2WX8Ujdh4UN4atmpgwAXER5o5JBU/iZIMETFfftLbxg2OVIqnC2iHn/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microchip.com; dmarc=pass action=none header.from=microchip.com; dkim=pass header.d=microchip.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microchiptechnology.onmicrosoft.com; s=selector2-microchiptechnology-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6XaZlO8nz3v0YO//QFi927MR019xD23XV8mFpGm7S1U=; b=msnSna0yGVOBio2S4f+TH6P63bOlBCotzPf6ikzUl2EynbJo89xDUij5OViMyZxu2twHLFuSMUs0GG5qB5DV/ALhKzs6i4Dhop8Pe1jsxAp/woK6Slzoj+0Cf5E1sAfAseKLF6+5+dvzKj+IWu4f6HigRNxx5CT8qO2j9fXr9X0= Received: from CO1PR11MB5154.namprd11.prod.outlook.com (2603:10b6:303:99::15) by BN6PR11MB3875.namprd11.prod.outlook.com (2603:10b6:405:80::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5504.16; Tue, 16 Aug 2022 20:41:06 +0000 Received: from CO1PR11MB5154.namprd11.prod.outlook.com ([fe80::ac89:75cd:26e0:51c3]) by CO1PR11MB5154.namprd11.prod.outlook.com ([fe80::ac89:75cd:26e0:51c3%8]) with mapi id 15.20.5525.011; Tue, 16 Aug 2022 20:41:06 +0000 From: To: CC: , , , , , , , , , Subject: RISC-V reserved memory problems Thread-Topic: RISC-V reserved memory problems Thread-Index: AQHYsbCBsK9tslJtmkuav8PF23o9Vw== Date: Tue, 16 Aug 2022 20:41:05 +0000 Message-ID: References: <8e10bf15-9fa9-fe90-1656-35bf3e87e7f8@microchip.com> In-Reply-To: <8e10bf15-9fa9-fe90-1656-35bf3e87e7f8@microchip.com> Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 x-forwarded-message-id: <8e10bf15-9fa9-fe90-1656-35bf3e87e7f8@microchip.com> authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microchip.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7489047d-a99e-4966-f1cc-08da7fc7a468 x-ms-traffictypediagnostic: BN6PR11MB3875:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JRi6L9ttHIYLI0ugHXtn/azQSOtFuthSRYJDoFrUCH4fWP8oKox/D+maNl9lF+QfP9rtriTTTAfndCIdhWAilEyUjnIo4HhhuydE7ccTq8qGPoThGFLMBphrX0ZWpNfAO0v2Wyk5RcAyE3htJ7qDUigkhwQNCCmxcqnqMDgdVookcqAH1lA2A+Nf9hAW6oG809Rhtvy/heOnKAdbsQafE3iLtBg56BYO8/XdVYlxqVTtUX4cYhPDKiKxFOWhNUIF/Ao9ZOm7bywbANUm/i4fcoTIy/qjymrFvFXMvLXkI4E0frJNoMqPo2Z6jWdQQreXYLGpUb0R9vf2+TiefLSGxJF/wBEq7C4SBfAoOkGOVEe+Sy0rEr2BNw6XF5qDXpXanf3Q61uWijUTns7ERu6WIpNIcBahcDp/qzlQKU/RhQPP9Ps2fITv9+Hw2N+TeVeIL7LszWsF2cSm8MC/rYFEawV65AwawVr9k5E4FwRqIHYNpy4uhK8HjnsjBtz4m5fQVEqMIjX9t9V6Yj9Pf/C+8Ul/I5g1/j4aHAdPbNsG5d4JbAa9VT+RGqLr+BKrvA1PQS1FQa4vmbkOsHBP+zOE4vhaSJsK5joJLcVVTUOyv2hDcwsJfxYi4mfXvQVGqaMnrmBpfN8e7xUg6TgaznUUZjvROatHTjEhlXH4EB6FN8RSWtjHwIdOhl7jB6PnxFN3iMLsXQsJ4pZYPn4ZIMprKNUAUry8hHVEs3KuuT45FJirjcFX/ijafuzJn5/dNzxkQ1kjw4li4eGVnZS1a9jWcWgVBLLU4pAvtY654186dH+a3xl+wkRgQodxQJ3fc6ezuExYt26SrKJLpJOg6jHChW9ba0hCZmmbTdC7Qk/a4U7VazE+ddFjtsD79rFgULNcwyFjYrLSnT/1B21EuxAVDw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5154.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(346002)(376002)(136003)(396003)(39860400002)(366004)(3480700007)(76116006)(31696002)(83380400001)(2906002)(66946007)(66476007)(4326008)(8676002)(38070700005)(2616005)(186003)(91956017)(84970400001)(64756008)(107886003)(66556008)(86362001)(36756003)(6486002)(478600001)(66446008)(41300700001)(38100700002)(45080400002)(8936002)(26005)(99936003)(316002)(31686004)(6916009)(6506007)(6512007)(54906003)(71200400001)(5660300002)(122000001)(45980500001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?q?UMdbhC6O8ER25drTVDnjCRue9v3f?= =?utf-8?q?5jfTYzYSIvvYW55FKCEgSrV9X3m9q58mRjmxPGDayR6iaGuYtYhaMMv9wmxghMg2g?= =?utf-8?q?h5pQjSjqN9bQG5FiphqwkAlkkQRYDwdbmSSqeZXoIxhptl5Z+WAqvPlzRslpH2FKg?= =?utf-8?q?dvmZHj0dOaAmAAcUAGy/TD001e+pzG44mqOkNe4n51uSEgDSxRsyAFnbw41gyzVM9?= =?utf-8?q?OZNiVWI2BMzxy2VXipBoQV+nYFrtlUo0yZRNHTjiyUzBdoMedybsxeCqcvdz9W2pJ?= =?utf-8?q?6vJ+4Hm+J8kiC/79TCxBrf5PDpn5/j8/hWFj/mYfwrwWUv3R2Hp9x+jZeIN6umWTm?= =?utf-8?q?EpGCbvhLvbpObW3u7Shpmcsnt+lXPQhpqvCkRg6GmPdt0QxHpbWeYsZBO51MkC0Oy?= =?utf-8?q?/RsyBZXY85MJ8RXVtj0yEZgN6P6luR0y7E0Rqx/U0XooB0um0J61bfAUgEIVM7Edy?= =?utf-8?q?tJywtK2zjAYwhusi3+Nugt695bSp/tuiWTcNgK4nzZVQioaZ/3pA++i+Ky3cyNc/E?= =?utf-8?q?cq5Bm5zwsG5O/OyUmsQlknzeSZstBPxByNf/GMskyrgtREAyylsLM4l3f9DZYAce9?= =?utf-8?q?S3bE2UMnNwORRBO1VhRrHutEQSpzLi1ykOKJflS/3ei241qVBnAV1cZztgcjVPa5x?= =?utf-8?q?0b/FmlHOIoKR4BiZoO7eJSu5ib6BX3yoGd/pODWcz36nLbbs+EZgMbOffcvzgWscd?= =?utf-8?q?V2yHV/cA0l+nR0DziqRhpM3zkhxglEdpDSkCXI2H/Fe9RNQSI5D9AB3hFk6GxUMiw?= =?utf-8?q?KDLr+l/3JKzU7pJZ1fqEIfYzui21PoNRJsJrh8FRLoD/JNuYZkHp6BnprR4lsm/Po?= =?utf-8?q?eEDl3yDDMTOTQ7gWaMMOx4/DVLcHrTQFlZALY4oHNHVCYp5L32zC7ur+cK2Jedvg+?= =?utf-8?q?Jv3xwSzutwCMxUOdc20MgeogOBq7zKnYiBqa9+l6OJu+IGEZ4AAAjHsGNi/4nfE8m?= =?utf-8?q?OHsXFmDNmtrIqPEVxmciBTJsoLSEOqNw3BkXeUS+K2AcdgIdbyEccOteSrIg8B4py?= =?utf-8?q?4TChtWNsBbJy3N+lddbWHrQoT6wzsw/wZZKFIxD97uOwk1c9sNgQTx8bbFm3zBeaO?= =?utf-8?q?DphJjQM93IRo9tVZ/FTXaav1hM81K9xiRzhRMYREoHtj18ozjHaGPA2iYxF+ksk9o?= =?utf-8?q?3sAFMdsmW0fOXN01GC96wr7uWtF0m5Hc0qwjkuMEMh/ySKeyco86gO1nOG9d6YstB?= =?utf-8?q?rIzIqt7JFx6ND9PPzjZ0uq1c3keZ1uc3MpQqfksRJ+TP8WxCRawuA97gp3Ll9uiVu?= =?utf-8?q?xdyhh37mqvVoONHYl4Jb8QsNC0w8TPjpHlcR8gVvFYze1j260APl2u1KI6xMtNham?= =?utf-8?q?ZubmWQYqa4dkuut60lakuSBstRJNVLUYncgO4DoLE8Me4YPSBC1TCOiALOEuPOyJp?= =?utf-8?q?nlXrAy9QsuyCCkgJ1UIRjwJq6jVzYzbwuIGWHx6kz4lj+9x44ddAo1A3coKXcScXU?= =?utf-8?q?JzUhdST98sXJrX1SWCcettLyzqb9v50WuzKttiQ6ipsNW/Pv8by3OJ0qp/ZD1o/4N?= =?utf-8?q?WMS7W0b0rvb6?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5154.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7489047d-a99e-4966-f1cc-08da7fc7a468 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2022 20:41:05.9594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2wFebCPvRV+rahz8RDAy1KGdzpdnu5n1IGtmLbw7Zonz9dpZim3TdHd4CKWCPFhPFC762V1hAwo+7HatEkVshEwKcFVZdmjOshbmsML7i6o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3875 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hey all, We've run into a bit of a problem with reserved memory on PolarFire, or more accurately a pair of problems that seem to have opposite fixes. The first of these problems is triggered when trying to implement a remoteproc driver. To get the reserved memory buffer, remoteproc does an of_reserved_mem_lookup(), something like: np = of_parse_phandle(pdev->of_node, "memory-region", 0); if (!np) return -EINVAL; rmem = of_reserved_mem_lookup(np); if (!rmem) return -EINVAL; of_reserved_mem_lookup() then uses reserved_mem[i].name to try and find a match - but this was triggering kernel panics for us. We did some debugging and found that the name string's pointer was pointing to an address in the 0x4000_0000 range. The minimum reproduction for this crash is attached - it hacks in some print_reserved_mem()s into setup_vm_final() around a tlb flush so you can see the before/after. (You'll need a reserved memory node in your dts to replicate) The output is like so, with the same crash as in the remoteproc driver: [ 0.000000] Linux version 6.0.0-rc1-00001-g0d9d6953d834 (conor@wendy) (riscv64-unknown-linux-gnu-gcc (g5964b5cd727) 11.1.0, GNU ld (GNU Binutils) 2.37) #1 SMP Tue Aug 16 13:42:09 IST 2022 [ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000 [ 0.000000] Machine model: Microchip PolarFire-SoC Icicle Kit [ 0.000000] earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8') [ 0.000000] printk: bootconsole [ns16550a0] enabled [ 0.000000] printk: debug: skip boot console de-registration. [ 0.000000] efi: UEFI not found. [ 0.000000] before flush [ 0.000000] OF: reserved mem: debug name is fabricbuf@ae000000 [ 0.000000] after flush [ 0.000000] Unable to handle kernel paging request at virtual address 00000000401c31ac [ 0.000000] Oops [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.0.0-rc1-00001-g0d9d6953d834 #1 [ 0.000000] Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) [ 0.000000] epc : string+0x4a/0xea [ 0.000000] ra : vsnprintf+0x1e4/0x336 [ 0.000000] epc : ffffffff80335ea0 ra : ffffffff80338936 sp : ffffffff81203be0 [ 0.000000] gp : ffffffff812e0a98 tp : ffffffff8120de40 t0 : 0000000000000000 [ 0.000000] t1 : ffffffff81203e28 t2 : 7265736572203a46 s0 : ffffffff81203c20 [ 0.000000] s1 : ffffffff81203e28 a0 : ffffffff81203d22 a1 : 0000000000000000 [ 0.000000] a2 : ffffffff81203d08 a3 : 0000000081203d21 a4 : ffffffffffffffff [ 0.000000] a5 : 00000000401c31ac a6 : ffff0a00ffffff04 a7 : ffffffffffffffff [ 0.000000] s2 : ffffffff81203d08 s3 : ffffffff81203d00 s4 : 0000000000000008 [ 0.000000] s5 : ffffffff000000ff s6 : 0000000000ffffff s7 : 00000000ffffff00 [ 0.000000] s8 : ffffffff80d9821a s9 : ffffffff81203d22 s10: 0000000000000002 [ 0.000000] s11: ffffffff80d9821c t3 : ffffffff812f3617 t4 : ffffffff812f3617 [ 0.000000] t5 : ffffffff812f3618 t6 : ffffffff81203d08 [ 0.000000] status: 0000000200000100 badaddr: 00000000401c31ac cause: 000000000000000d [ 0.000000] [] vsnprintf+0x1e4/0x336 [ 0.000000] [] vprintk_store+0xf6/0x344 [ 0.000000] [] vprintk_emit+0x56/0x192 [ 0.000000] [] vprintk_default+0x16/0x1e [ 0.000000] [] vprintk+0x72/0x80 [ 0.000000] [] _printk+0x36/0x50 [ 0.000000] [] print_reserved_mem+0x1c/0x24 [ 0.000000] [] paging_init+0x528/0x5bc [ 0.000000] [] setup_arch+0xd0/0x592 [ 0.000000] [] start_kernel+0x82/0x73c [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- We traced this back to early_init_fdt_scan_reserved_mem() in setup_bootmem() - moving it later back up the boot sequence to after the dt has been remapped etc has fixed the problem for us. The least movement to get it working is attached, and also pushed here: git.kernel.org/conor/c/1735589baefc The second problem is a bit more complicated to explain - but we found the solution conflicted with the remoteproc fix as we had to move early_init_fdt_scan_reserved_mem() _earlier_ in the boot process to solve this one. We want to have a node in our devicetree that contains some memory that is non-cached & marked as reserved-memory. Maybe we have just missed something, but from what we've seen: - the really early setup looks at the dtb, picks the highest bit of memory and puts the dtb etc there so it can start using it - early_init_fdt_scan_reserved_mem() is then called, which figures out if memory is reserved or not. Unfortunately, the highest bit of memory is the non-cached bit so everything falls over, but we can avoid this by moving the call to early_init_fdt_scan_reserved_mem() above the dtb memblock alloc that takes place right before it in setup_bootmem(). Obviously, both of these changes are moving the function call in opposite directions and we can only really do one of them. We are not sure if what we are doing with the non-cached reserved-memory section is just not permitted & cannot work - or if this is something that was overlooked for RISC-V specifically and works for other archs. It does seem like the first issue is a real bug, and I am happy to submit the patch for that whenever - but having two problems with opposite fixes seemed as if there was something else lurking that we just don't have enough understanding to detect. Any help would be great! Thanks, Conor. >From 14447dc618a3007bf17dd27c03f7fec095efbc6f Mon Sep 17 00:00:00 2001 From: Valentina Fernandez Date: Wed, 13 Jul 2022 10:56:47 +0100 Subject: [PATCH] Debug tlb_flush with reserved memory --- arch/riscv/boot/dts/microchip/Makefile | 1 + .../microchip/mpfs-icicle-kit-context-a.dts | 203 ++++++++++++++++++ arch/riscv/mm/init.c | 9 +- drivers/of/of_reserved_mem.c | 6 + include/linux/of_reserved_mem.h | 2 + 5 files changed, 220 insertions(+), 1 deletion(-) create mode 100644 arch/riscv/boot/dts/microchip/mpfs-icicle-kit-context-a.dts diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index d466ec670e1f..5458519c3eb4 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -20,7 +20,7 @@ #include #include #include - +#include #include #include #include @@ -1112,8 +1112,15 @@ static void __init setup_vm_final(void) /* Move to swapper page table */ csr_write(CSR_SATP, PFN_DOWN(__pa_symbol(swapper_pg_dir)) | satp_mode); + + pr_err("before flush\n"); + print_reserved_mem(); + local_flush_tlb_all(); + pr_err("after flush\n"); + print_reserved_mem(); + pt_ops_set_late(); } #else diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c index 75caa6f5d36f..6aaebb05730d 100644 --- a/drivers/of/of_reserved_mem.c +++ b/drivers/of/of_reserved_mem.c @@ -445,3 +445,9 @@ struct reserved_mem *of_reserved_mem_lookup(struct device_node *np) return NULL; } EXPORT_SYMBOL_GPL(of_reserved_mem_lookup); + +void print_reserved_mem(void) +{ + pr_err("debug name is %s\n", reserved_mem[0].name); +} +EXPORT_SYMBOL_GPL(print_reserved_mem); \ No newline at end of file diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h index 4de2a24cadc9..1fe504af3944 100644 --- a/include/linux/of_reserved_mem.h +++ b/include/linux/of_reserved_mem.h @@ -40,6 +40,8 @@ int of_reserved_mem_device_init_by_name(struct device *dev, void of_reserved_mem_device_release(struct device *dev); struct reserved_mem *of_reserved_mem_lookup(struct device_node *np); + +void print_reserved_mem(void); #else #define RESERVEDMEM_OF_DECLARE(name, compat, init) \ -- 2.25.1