Re: [PATCH v12 3/3] mtd: Add driver for concatenating devices

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Mahapatra, Amit Kumar" <amit.kumar-mahapatra@amd.com>
Cc: "richard@nod.at" <richard@nod.at>,
	 "vigneshr@ti.com" <vigneshr@ti.com>,
	"robh@kernel.org" <robh@kernel.org>,
	 "krzk+dt@kernel.org" <krzk+dt@kernel.org>,
	 "conor+dt@kernel.org" <conor+dt@kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 "git (AMD-Xilinx)" <git@amd.com>,
	 "amitrkcian2002@gmail.com" <amitrkcian2002@gmail.com>,
	 Bernhard Frauendienst <kernel@nospam.obeliks.de>
Subject: Re: [PATCH v12 3/3] mtd: Add driver for concatenating devices
Date: Fri, 16 May 2025 16:06:41 +0200	[thread overview]
Message-ID: <87o6vsejke.fsf@bootlin.com> (raw)
In-Reply-To: <IA0PR12MB7699B60558C5211F8F80C471DC96A@IA0PR12MB7699.namprd12.prod.outlook.com> (Amit Kumar Mahapatra's message of "Tue, 13 May 2025 14:45:39 +0000")

On 13/05/2025 at 14:45:39 GMT, "Mahapatra, Amit Kumar" <amit.kumar-mahapatra@amd.com> wrote:

> [AMD Official Use Only - AMD Internal Distribution Only]
>
> Hello Miquel,
>
>> >> > +           mtd->dev.parent = concat->subdev[0]->dev.parent;
>> >> > +           mtd->dev = concat->subdev[0]->dev;
>> >> > +
>> >> > +           /* Register the platform device */
>> >> > +           ret = mtd_device_register(mtd, NULL, 0);
>> >> > +           if (ret)
>> >> > +                   goto destroy_concat;
>> >> > +   }
>> >> > +
>> >> > +   return 0;
>> >> > +
>> >> > +destroy_concat:
>> >> > +   mtd_concat_destroy(mtd);
>> >> > +
>> >> > +   return ret;
>> >> > +}
>> >> > +
>> >> > +late_initcall(mtd_virt_concat_create_join);
>> >>
>> >> The current implementation does not support probe deferrals, I
>> >> believe it should be handled.
>> >
>> > I see that the parse_mtd_partitions() API can return -EPROBE_DEFER
>> > during MTD device registration, but this behavior is specific to the
>> > parse_qcomsmem_part parser. None of the other parsers appear to
>> > support probe deferral. As discussed in RFC [1], the virtual concat
>> > feature is purely a fixed-partition capability, and based on my
>> > understanding, the fixed-partition parser does not support probe deferral.
>> > Please let me know if you can think of any other probe deferral
>> > scenarios that might impact the virtual concat driver.
>>
>> That's true, but I kind of dislike the late_initcall, I fear it might break in creative ways.
>
> I understand, but since we require the partition information to be
> available, late_initcall seems to be the most suitable choice among the
> initcall levels—if we decide to proceed with using an initcall.
> Regarding potential failures, as far as I can tell, the operation would
> fail if, at the time of concatenation, one or more of the MTD devices
> involved in the concat are not yet available. In such a scenario, we can
> issue a kernel warning and exit gracefully. But, However, if you prefer
> to move away from using initcalls and have an alternative
> implementation approach in mind, please let us know.

I am sorry but this does not work with modules, and we cannot ignore this
case I believe. More specifically, if a controller probe is deferred
(with EPROBE_DEFER or just prevented because some dependencies are not
yet satisfied), you'll get incorrectly defined mtd devices.

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/