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;
Date:   Thu, 3 Feb 2022 11:13:42 +0100 (CET)
From:   Richard Weinberger <richard@nod.at>
To:     Miquel Raynal <miquel.raynal@bootlin.com>
Cc:     =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= <kernel@kempniu.pl>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Boris Brezillon <boris.brezillon@collabora.com>,
        linux-mtd <linux-mtd@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>
Message-ID: <340602071.12640.1643883222200.JavaMail.zimbra@nod.at>
In-Reply-To: <20220203104654.6cb43ea3@xps13>
References: <20220125104822.8420-1-kernel@kempniu.pl> <20220125104822.8420-5-kernel@kempniu.pl> <1173246756.12597.1643879936765.JavaMail.zimbra@nod.at> <20220203104654.6cb43ea3@xps13>
Subject: Re: [PATCH v3 4/4] mtdchar: add MEMREAD ioctl
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Thread-Topic: mtdchar: add MEMREAD ioctl
Thread-Index: hZNaN/vnabP7CZbdubDi1iosoXSpeQ==
Precedence: bulk

----- Ursprüngliche Mail -----
> Von: "Miquel Raynal" <miquel.raynal@bootlin.com>
>> If mtd->erasesize is large (which is not uncommon these days) you might
>> request more from kmalloc() than it can serve.
>> Maybe kvmalloc() makes more sense?
> 
> Mmmh, I would really like these buffers dma-able.
> 
> I just discovered mtd_kmalloc_up_to(). Would this work?

mtd_kmalloc_up_to() makes sense to be more friendly to the system.
It tries to get memory without forcing write-back and such.
But if we're out of continuous memory it won't help much. 

Regarding dma-able, as soon you use something like UBI/UBIFS ontop of it
the mtd driver has to be able to deal in any way with vmalloc()'ed memory.

Another option would be not working on full erase blocks.

Thanks,
//richard