From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751986AbdJFQHy (ORCPT ); Fri, 6 Oct 2017 12:07:54 -0400 Received: from relmlor2.renesas.com ([210.160.252.172]:27787 "EHLO relmlie1.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751484AbdJFQHw (ORCPT ); Fri, 6 Oct 2017 12:07:52 -0400 X-IronPort-AV: E=Sophos;i="5.42,484,1500908400"; d="scan'208";a="258719523" From: Chris Brandt To: Christoph Hellwig , Nicolas Pitre CC: Alexander Viro , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-embedded@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v5 0/5] cramfs refresh for embedded usage Thread-Topic: [PATCH v5 0/5] cramfs refresh for embedded usage Thread-Index: AQHTPk02Mu+9P5rETEy0R9mkuQSd0aLWXxGAgACa3mA= Date: Fri, 6 Oct 2017 16:07:45 +0000 Message-ID: References: <20171006024531.8885-1-nicolas.pitre@linaro.org> <20171006063919.GA16556@infradead.org> In-Reply-To: <20171006063919.GA16556@infradead.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Chris.Brandt@renesas.com; x-originating-ip: [75.60.247.61] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;SG2PR06MB1165;20:LO4uN2gzFNWaFG63+1wdHqEgekm5JNPRoaHSSujkNffYFd6rzd2kM2NEZ1RZ6+y+Yf2WbN4H5fYznyPnluoRe0YwkG3tASpA5s++E47hE3hNpvGCaENIa2ffUYQsdobDSTcPVmJuT+MJq0/46HPeJWis6tGJgGZp89fHPv9ZoDU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9b53b954-7170-428c-fda0-08d50cd461c2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:SG2PR06MB1165; x-ms-traffictypediagnostic: SG2PR06MB1165: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:SG2PR06MB1165;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:SG2PR06MB1165; x-forefront-prvs: 0452022BE1 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(346002)(376002)(189002)(199003)(24454002)(81156014)(478600001)(68736007)(53936002)(33656002)(97736004)(81166006)(8676002)(4326008)(5250100002)(2900100001)(3280700002)(189998001)(3660700001)(3846002)(72206003)(102836003)(54906003)(110136005)(316002)(6116002)(5660300001)(7736002)(6246003)(74316002)(76176999)(50986999)(54356999)(6436002)(2906002)(6506006)(305945005)(101416001)(14454004)(8936002)(106356001)(99286003)(229853002)(2950100002)(25786009)(55016002)(66066001)(9686003)(105586002)(86362001)(7696004);DIR:OUT;SFP:1102;SCL:1;SRVR:SG2PR06MB1165;H:SG2PR06MB1165.apcprd06.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-OriginatorOrg: renesas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2017 16:07:45.2749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR06MB1165 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v96G7w2W007173 On Friday, October 06, 2017, Christoph Hellwig wrote: > This is still missing a proper API for accessing the file system, > as said before specifying a physical address in the mount command > line is a an absolute non-no. > > Either work with the mtd folks to get the mtd core down to an absolute > minimum suitable for you, or figure out a way to specify fs nodes > through DT or similar. On my system, the QSPI Flash is memory mapped and set up by the boot loader. In order to test the upstream kernel, I use a squashfs image and mtd-rom. So, 0x18000000 is the physical address of flash as it is seen by the CPU. Is there any benefit to doing something similar to this? /* File System */ /* Requires CONFIG_MTD_ROM=y */ qspi@18000000 { compatible = "mtd-rom"; probe-type = "map_rom"; reg = <0x18000000 0x4000000>; /* 64 MB*/ bank-width = <4>; device-width = <1>; #address-cells = <1>; #size-cells = <1>; partition@800000 { label ="user"; reg = <0x0800000 0x800000>; /* 8MB @ 0x18800000 */ read-only; }; }; Of course this basically ioremaps the entire space on probe, but I think what you really want to do is just ioremap pages at a time (maybe..I might not be following your code correctly) Chris From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Chris Brandt To: Christoph Hellwig , Nicolas Pitre CC: Alexander Viro , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-embedded@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH v5 0/5] cramfs refresh for embedded usage Date: Fri, 6 Oct 2017 16:07:45 +0000 Message-ID: References: <20171006024531.8885-1-nicolas.pitre@linaro.org> <20171006063919.GA16556@infradead.org> In-Reply-To: <20171006063919.GA16556@infradead.org> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: On Friday, October 06, 2017, Christoph Hellwig wrote: > This is still missing a proper API for accessing the file system, > as said before specifying a physical address in the mount command > line is a an absolute non-no. >=20 > Either work with the mtd folks to get the mtd core down to an absolute > minimum suitable for you, or figure out a way to specify fs nodes > through DT or similar. On my system, the QSPI Flash is memory mapped and set up by the boot=20 loader. In order to test the upstream kernel, I use a squashfs image and=20 mtd-rom. So, 0x18000000 is the physical address of flash as it is seen by the=20 CPU. Is there any benefit to doing something similar to this? /* File System */ /* Requires CONFIG_MTD_ROM=3Dy */ qspi@18000000 { compatible =3D "mtd-rom"; probe-type =3D "map_rom"; reg =3D <0x18000000 0x4000000>; /* 64 MB*/ bank-width =3D <4>; device-width =3D <1>; #address-cells =3D <1>; #size-cells =3D <1>; partition@800000 { label =3D"user"; reg =3D <0x0800000 0x800000>; /* 8MB @ 0x18800000 */ read-only; }; }; Of course this basically ioremaps the entire space on probe, but I think what you really want to do is just ioremap pages at a time (maybe..I=20 might not be following your code correctly) Chris -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org