On 08/03/2025 at 18:40:43 GMT, J. Neuschäfer wrote:
> Miquel, what do you think about Rob's suggestion below?
>
> On Mon, Mar 03, 2025 at 08:00:21AM -0600, Rob Herring wrote:
>> On Wed, Feb 26, 2025 at 12:45:17PM -0600, Rob Herring (Arm) wrote:
>> >
>> > On Wed, 26 Feb 2025 18:01:41 +0100, J. Ne
Hello,
>> > In some scenarios, such as under the Freescale eLBC bus, there are raw
>> > NAND chips with a unit address that has a comma in it (cs,offset).
>> > Relax the $nodename pattern in raw-nand-chip.yaml to allow such unit
>> > addresses.
>>
>> This is super specific to this controller, I'd
Hello,
On 07/02/2025 at 22:30:29 +01, J. Neuschäfer via B4 Relay
wrote:
> From: "J. Neuschäfer"
>
> In some scenarios, such as under the Freescale eLBC bus, there are raw
> NAND chips with a unit address that has a comma in it (cs,offset).
> Relax the $nodename pattern in raw-nand-chip.yaml to
Hi Julian,
jvet...@kalrayinc.com wrote on Tue, 8 Oct 2024 09:50:21 +0200:
> The UM arch doesn't have HAS_IOMEM=y, so the build fails because the
> functions memcpy_fromio and memcpy_toio are not defined anymore. These
> functions are only build for targets which have HAS_IOMEM=y or
> INDIRECT_IO
On Wed, 2024-08-28 at 09:24:27 UTC, Charles Han wrote:
> devm_kasprintf() can return a NULL pointer on failure but this
> returned value is not checked.
>
> Fixes: acfe63ec1c59 ("mtd: Convert to using %pOFn instead of
> device_node.name")
> Signed-off-by: Charles Han
Applied to https://git.kern
Hi Marco,
m.fel...@pengutronix.de wrote on Thu, 18 Jul 2024 11:17:53 +0200:
> Hi Miquel,
>
> On 24-07-17, Miquel Raynal wrote:
> > Hi Marco,
> >
> > > > > > Overall I think the idea of getting rid of these misc/ drivers is
> > > >
Hi Marco,
> > > > Overall I think the idea of getting rid of these misc/ drivers is goes
> > > > into the right direction, but registering directly into NVMEM makes
> > > > more sense IMO.
> > >
> > > So you propose to have two places for the partition handling (one for
> > > MTD and one for
Hi Marco,
> > > > >> I also found a thread from 2013 by Maxime Ripard (+Cc) suggesting
> > > > >> adding
> > > > >> EEPROMs to MTD [1]. The main purpose would have been unifying the
> > > > >> EEPROM
> > > > >> drivers under a single interface. I am not sure what came of it
> > > > >> though,
>
Hi,
> > >> >> Port the current misc/eeprom/at24.c driver to the MTD framework since
> > >> >> EEPROMs are memory-technology devices and the framework already
> > >> >> supports
> > >> >
> > >> > I was under the impression that MTD devices are tightly coupled by
> > >> > erase
> > >> > blocks.
On Thu, 2024-06-27 at 15:00:28 UTC, Piotr Wojtaszczyk wrote:
> Move away from pl08x platform data towards device tree.
>
> Signed-off-by: Piotr Wojtaszczyk
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
Miquel
Hi Piotr,
piotr.wojtaszc...@timesys.com wrote on Fri, 21 Jun 2024 14:44:21 +0200:
> On Fri, Jun 21, 2024 at 10:30 AM Miquel Raynal
> wrote:
> >
> > Hi Piotr,
> >
> > piotr.wojtaszc...@timesys.com wrote on Thu, 20 Jun 2024 19:56:39 +0200:
> >
> > &g
Hi Piotr,
piotr.wojtaszc...@timesys.com wrote on Thu, 20 Jun 2024 19:56:39 +0200:
> Move away from pl08x platform data towards device tree.
>
> Signed-off-by: Piotr Wojtaszczyk
I don't see any change regarding the NAND controller node in the device
tree, is there any dependency with other patc
gt;
> Fixes: ea0c0ad6b6eb ("memory: Enable compile testing for most of the drivers")
> Signed-off-by: Esben Haabendal
Looks good to me.
Reviewed-by: Miquel Raynal
Thanks,
Miquèl
Hello Uwe,
u.kleine-koe...@pengutronix.de wrote on Tue, 5 Dec 2023 08:39:11 +0100:
> Hello Miquel,
>
> On Tue, Dec 05, 2023 at 07:51:10AM +0100, Miquel Raynal wrote:
> > u.kleine-koe...@pengutronix.de wrote on Mon, 4 Dec 2023 19:30:40 +0100:
> > > (implicit) v1 of thi
Hi Uwe,
u.kleine-koe...@pengutronix.de wrote on Mon, 4 Dec 2023 19:30:40 +0100:
> Hello,
>
> (implicit) v1 of this series can be found at
> https://lore.kernel.org/netdev/20231117095922.876489-1-u.kleine-koe...@pengutronix.de.
> Changes since then:
>
> - Dropped patch #1 as Alex objected. Pat
Hi Yi,
yiyan...@huawei.com wrote on Thu, 19 Oct 2023 01:30:50 +:
> devm_kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful by
> checking the pointer validity.
>
> Fixes: acfe63ec1c59 ("mtd: Convert to using %pO
On Sun, 2023-10-08 at 20:01:29 UTC, =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is ignored (apart
>
Hi Thomas,
t...@linutronix.de wrote on Wed, 01 Mar 2023 22:07:48 +0100:
> Miquel!
>
> On Wed, Mar 01 2023 at 11:55, Miquel Raynal wrote:
> > t...@linutronix.de wrote on Fri, 11 Nov 2022 14:54:22 +0100 (CET):
> >
> >> When a range of descriptors is freed then all
Hi Thomas,
t...@linutronix.de wrote on Fri, 11 Nov 2022 14:54:22 +0100 (CET):
> When a range of descriptors is freed then all of them are not associated to
> a linux interrupt. Remove the filter and add a warning to the free function.
>
> Signed-off-by: Thomas Gleixner
> ---
[...]
> --- a/ker
Hi Christophe,
Christophe Leroy wrote on Wed, 23 Jun
2021 11:41:46 +0200:
> Le 19/06/2021 à 20:40, Miquel Raynal a écrit :
> > Hi Christophe,
> >
> >>>> Now and then I'm using one of the latest kernels (Today is 5.13-rc6),
> >>>> and som
Hello,
Lee Jones wrote on Fri, 20 Nov 2020 07:50:00
+:
> On Thu, 19 Nov 2020, Miquel Raynal wrote:
>
> > On Mon, 2020-11-09 at 18:22:06 UTC, Lee Jones wrote:
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > > drivers/mtd/devic
:
> the device
> drivers/mtd/devices/powernv_flash.c:161: warning: Cannot understand * @mtd:
> the device
> drivers/mtd/devices/powernv_flash.c:184: warning: Function parameter or
> member 'dev' not described in 'powernv_flash_set_driver_info'
>
> Cc
Hi Lee,
Lee Jones wrote on Fri, 6 Nov 2020 21:36:32
+:
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> v1 => v2:
> - Added tags
> - Satisfied Miquel's review comments
>
You
Hi Christophe,
Christophe Leroy wrote on Thu, 05 Nov
2020 10:06:51 +0100:
> Quoting Miquel Raynal :
>
> > Hi Christophe,
> >
> > Christophe Leroy wrote on Wed, 4 Nov 2020
> > 19:37:57 +0100:
> >
> >> Hi Miquel,
> >>
> >> Le 04/
Hi Christophe,
Christophe Leroy wrote on Wed, 4 Nov 2020
19:37:57 +0100:
> Hi Miquel,
>
> Le 04/11/2020 à 18:38, Miquel Raynal a écrit :
> > Hi Christophe,
> >
> > Christophe Leroy wrote on Wed, 04 Nov
> > 2020 18:33:53 +0100:
> >
> >> Hi
Hi Christophe,
Christophe Leroy wrote on Wed, 04 Nov
2020 18:33:53 +0100:
> Hi Miquel,
>
> I'm unable to boot 5.10-rc1 on my boards. I get the following error:
>
> [4.125811] nand: device found, Manufacturer ID: 0xad, Chip ID: 0x76
> [4.131992] nand: Hynix NAND 64MiB 3,3V 8-bit
> [
* @mtd:
> the device
> drivers/mtd/devices/powernv_flash.c:161: warning: Cannot understand * @mtd:
> the device
> drivers/mtd/devices/powernv_flash.c:184: warning: Function parameter or
> member 'dev' not described in 'powernv_flash_set_driver_info'
>
Hi Joe,
For MTD:
> drivers/mtd/nand/raw/nandsim.c| 2 +-
Reviewed-by: Miquel Raynal
Thanks,
Miquèl
On Wed, 2020-06-03 at 13:49:22 UTC, Boris Brezillon wrote:
> Those properties are no longer parsed by the driver which is being passed
> those information by the core now. Let's deprecate them.
>
> Signed-off-by: Boris Brezillon
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linu
y()")
> Signed-off-by: Boris Brezillon
> Reviewed-by: Miquel Raynal
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
Miquel
On Wed, 2020-06-03 at 13:49:14 UTC, Boris Brezillon wrote:
> fsl_upm_nand.parts is unused, let's get rid of it.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Miquel Raynal
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
Miquel
On Wed, 2020-06-03 at 13:49:15 UTC, Boris Brezillon wrote:
> This simplifies the init error patch and remove function.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Miquel Raynal
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
Miquel
On Wed, 2020-06-03 at 13:49:16 UTC, Boris Brezillon wrote:
> This simplifies the init() error path and the remove() handler.
>
> Signed-off-by: Boris Brezillon
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
Miquel
On Wed, 2020-06-03 at 13:49:17 UTC, Boris Brezillon wrote:
> Replace the of_address_to_resource() + devm_ioremap() calls by
> platform_get_resource() + devm_ioremap_resource() ones which allows us
> to get rid of one error message since devm_ioremap_resource() already
> takes care of that.
>
> Sig
While at it, we use devm_gpiod_get_index_optional() so we can get rid
> of the manual gpio desc release done in the init error path and in the
> remove function.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Miquel Raynal
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
Miquel
On Wed, 2020-06-03 at 13:49:19 UTC, Boris Brezillon wrote:
> Explicitly inherit from nand_controller instead of relying on the
> nand_chip.legacy.dummy_controller field.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Miquel Raynal
Applied to https://git.kernel.org/pub/scm/l
On Wed, 2020-06-03 at 13:49:20 UTC, Boris Brezillon wrote:
> Implement exec_op() so we can get rid of the legacy interface
> implementation.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Miquel Raynal
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
On Wed, 2020-06-03 at 13:49:21 UTC, Boris Brezillon wrote:
> Now that the driver implements exec_op(), we can get rid of the legacy
> interface implementation.
>
> Signed-off-by: Boris Brezillon
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
Miquel
> +static const struct nand_controller_ops fun_ops = {
> + .exec_op = fun_exec_op,
> +};
> +
> static int fun_probe(struct platform_device *ofdev)
> {
> struct fsl_upm_nand *fun;
> @@ -271,6 +356,7 @@ static int fun_probe(struct platform_device *ofdev)
> FSL_UPM_WAIT_WRITE_BYTE;
>
> nand_controller_init(&fun->base);
> + fun->base.ops = &fun_ops;
> fun->dev = &ofdev->dev;
> fun->last_ctrl = NAND_CLE;
>
Looks fine!
Reviewed-by: Miquel Raynal
tatic int fun_probe(struct platform_device *ofdev)
> fun->wait_flags = FSL_UPM_WAIT_RUN_PATTERN |
> FSL_UPM_WAIT_WRITE_BYTE;
>
> + nand_controller_init(&fun->base);
> fun->dev = &ofdev->dev;
> fun->last_ctrl = NAND_CLE;
>
Reviewed-by: Miquel Raynal
e changed, 10 insertions(+), 34 deletions(-)
>
Reviewed-by: Miquel Raynal
int last_ctrl;
> - struct mtd_partition *parts;
> struct fsl_upm upm;
> uint8_t upm_addr_offset;
> uint8_t upm_cmd_offset;
Reviewed-by: Miquel Raynal
and_to_mtd(&fun->chip);
> int cnt = 100;
>
> while (--cnt && !fun_chip_ready(&fun->chip))
Reviewed-by: Miquel Raynal
Boris Brezillon wrote on Wed, 3 Jun
2020 15:49:17 +0200:
> Replace the of_address_to_resource() + devm_ioremap() calls by
> platform_get_resource() + devm_ioremap_resource() ones which allows us
> to get rid of one error message since devm_ioremap_resource() already
> takes care of that.
>
>
Boris Brezillon wrote on Wed, 3 Jun
2020 15:49:16 +0200:
> This simplifies the init() error path and the remove() handler.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/mtd/nand/raw/fsl_upm.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/
Boris Brezillon wrote on Wed, 3 Jun
2020 15:49:15 +0200:
> This simplifies the init error patch and remove function.
path?
Otherwise:
Reviewed-by: Miquel Raynal
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/mtd/nand/raw
Hi Masahiro,
Masahiro Yamada wrote on Fri, 3 May
2019 19:36:35 +0900:
> Hi Miquel,
>
> On Thu, May 2, 2019 at 11:14 PM Miquel Raynal
> wrote:
> >
> > Hi Masahiro,
> >
> > Masahiro Yamada wrote on Tue, 23 Apr
> > 2019 12:49:53 +0900:
> >
>
Hi Masahiro,
Masahiro Yamada wrote on Tue, 23 Apr
2019 12:49:53 +0900:
> This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
> place. We need to eliminate potential issues beforehand.
>
> Kbuild test robot has never reported -Wmaybe-uninitialized warning
> for this probably beca
Hi Boris,
On Tue, 13 Feb 2018 09:17:14 +0100, Boris Brezillon
wrote:
> On Tue, 13 Feb 2018 08:42:46 +0100
> Miquel Raynal wrote:
>
> > Hi Boris,
> >
> > Just a few comments about the form.
> >
> > Otherwise:
> > Reviewed-by: Miquel Raynal
>
Hi Boris,
Just a few comments about the form.
Otherwise:
Reviewed-by: Miquel Raynal
> diff --git a/drivers/mtd/devices/lart.c b/drivers/mtd/devices/lart.c
> index 555b94406e0b..3d6c8ffd351f 100644
> --- a/drivers/mtd/devices/lart.c
> +++ b/drivers/mtd/devices/lart.c
> @
50 matches
Mail list logo
