[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cd174dbaa3171f92e083d5dca89732aa64e32f15.camel@siemens.com>
Date: Sat, 8 Nov 2025 11:41:25 +0000
From: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To: "christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
CC: "hui.wang@...onical.com" <hui.wang@...onical.com>, "mwalle@...nel.org"
<mwalle@...nel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "florent.trinh-thai@...soprasteria.com"
<florent.trinh-thai@...soprasteria.com>, "arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH] eeprom: at25: convert to spi-mem API
Hi Christophe,
On Sat, 2025-11-08 at 12:14 +0100, Christophe Leroy wrote:
> > Now I'm trying to understand why the problem surfaced with commit
> > 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API")
> >
>
> The reason why it was not a problem before was that the transfer was
> done into of->prealloc_buf (fs/kernfs/file.c) which is a kmalloc() with
> size (PAGE_SIZE + 1).
>
> Following the rework of at25 it now goes into the bounce buffer which is
> allocated with the exact size of the transfer.
>
> Why do we need an intermediate bounce buffer now, why can't
> of->prealloc_buf be used directly as before ?
userspace access is only one part of the story, the other is NVMEM
kernel-internal API, like nvmem_cell_read*() and I suppose there is
no requirement for a destination buffer to be DMA-able.
--
Alexander Sverdlin
Siemens AG
www.siemens.com
Powered by blists - more mailing lists