[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