[PATCH 08/14] mtd: rawnand: atmel: Warn about failure to unregister mtd device
Miquel Raynal
miquel.raynal at bootlin.com
Mon Jun 6 23:14:36 PDT 2022
Hi Uwe,
u.kleine-koenig at pengutronix.de wrote on Mon, 6 Jun 2022 21:37:21 +0200:
> On Mon, Jun 06, 2022 at 03:16:20PM +0200, Miquel Raynal wrote:
> > Hi Uwe,
> >
> > u.kleine-koenig at pengutronix.de wrote on Fri, 3 Jun 2022 23:07:52 +0200:
> >
> > > The Linux device core doesn't intend remove callbacks to fail. If an
> > > error code is returned the device is removed anyhow. So wail loudly if
> > > the atmel specific remove callback fails and return 0 anyhow to suppress
> > > the generic (and little helpful) error message by the device core.
> > >
> > > Also check the remove callback to actually exist before calling it. That
> > > might happen if nc->caps->ops points to atmel_nand_controller_ops.
> >
> > I believe you got mislead by grepping the code because there is:
> >
> > * struct nand_controller_ops atmel_nand_controller_ops
> > -> this is a NAND-wide controller ops structure
> >
> > * struct atmel_nand_controller_ops atmel_<smtg>_nc_ops
> > -> this is a driver specific structure to provide different
> > registration helpers.
> >
> > The latter always provide a probe and a remove implementation, so I
> > believe the addition if the "if (nc->caps->ops->remove)" check is not
> > relevant, unless I missed something.
>
> You're right. I assume it's easiest for you if I send a v2 with all 14
> patches? If you consider this a waste of bytes, please advise. The
> patches are independant, so it would work if you pick up 1-7 + 9-14,
> too. Then I'd resend a fixed patch 8 individually.
Please just resend patch 8, I'll handle it.
>
> Best regards
> Uwe
>
Thanks,
Miquèl
More information about the linux-mtd
mailing list