On Thu, May 15, 2025 at 03:41:08PM +0530, Usyskin, Alexander wrote:
> > On Thu, Apr 24, 2025 at 04:25:26PM +0300, Alexander Usyskin wrote:
> > > Add auxiliary driver for intel discrete graphics
> > > non-volatile memory device.
...
> > > + for (n = 0, i = 0; i < INTEL_DG_NVM_REGIONS; i++) {
> > > + if (!invm->regions[i].name)
> > > + continue;
> > > +
> > > + name = kasprintf(GFP_KERNEL, "%s.%s",
> > > + dev_name(&aux_dev->dev), invm-
> > >regions[i].name);
> > > + if (!name)
> > > + continue;
> > > + nvm->regions[n].name = name;
> > > + nvm->regions[n].id = i;
> > > + n++;
> > > + }
> > > + nvm->nregions = n; /* in case where kasprintf fail */
> >
> > Considering kasprintf failure, should we move forward if n == 0?
> Not sure if adding exit path here adds something positive to driver
> other than complexity.
With an error path already in place it shouldn't be too complex, but upto you.
...
> > > +static void intel_dg_mtd_remove(struct auxiliary_device *aux_dev)
> > > +{
> > > + struct intel_dg_nvm *nvm = dev_get_drvdata(&aux_dev->dev);
> > > +
> > > + if (!nvm)
> > > + return;
> >
> > Are we expecting this?
> >
> > > + dev_set_drvdata(&aux_dev->dev, NULL);
> >
> > Do we need this?
> Is there guaranty by auxiliary device that after release nothing is called?
Any reports/link to read about such issues? My understanding is that driver
->remove() callbacks are bus lock held and there won't be an active instance
to be called after unbind.
Raag
