[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<IA0PR12MB7699B60558C5211F8F80C471DC96A@IA0PR12MB7699.namprd12.prod.outlook.com>
Date: Tue, 13 May 2025 14:45:39 +0000
From: "Mahapatra, Amit Kumar" <amit.kumar-mahapatra@....com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
CC: "richard@....at" <richard@....at>, "vigneshr@...com" <vigneshr@...com>,
"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "git
(AMD-Xilinx)" <git@....com>, "amitrkcian2002@...il.com"
<amitrkcian2002@...il.com>, Bernhard Frauendienst <kernel@...pam.obeliks.de>
Subject: RE: [PATCH v12 3/3] mtd: Add driver for concatenating devices
[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.
Regards,
Amit
>
> Thanks,
> Miquèl
Powered by blists - more mailing lists