[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YVFCetbrNV+WkJ5Q@kroah.com>
Date: Mon, 27 Sep 2021 06:03:06 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: "David E. Box" <david.e.box@...ux.intel.com>
Cc: lee.jones@...aro.org, hdegoede@...hat.com, mgross@...ux.intel.com,
andriy.shevchenko@...ux.intel.com, srinivas.pandruvada@...el.com,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 2/2] platform/x86: Add Intel Software Defined Silicon
driver
On Sun, Sep 26, 2021 at 06:15:16PM -0700, David E. Box wrote:
> > > +static int sdsi_remove(struct platform_device *pdev)
> > > +{
> > > + struct sdsi_priv *priv = platform_get_drvdata(pdev);
> > > +
> > > + priv->dev_present = false;
> > > + sysfs_remove_bin_file(&priv->pdev->dev.kobj, &priv->registers_bin_attr);
> > > + misc_deregister(&priv->miscdev);
> > > + kref_put(&priv->kref, sdsi_priv_release);
> >
> > Why do you need a kref for a structure that already can be controlled by
> > a different lifetime rule?
>
> Which rule am I missing? This kref allows the structure to remain in case the device is removed
> while the file is open.
This device is on a hardware bus that allows removal?
Anyway, you now are dealing with lifetime rules of 3 structures all at
once, and the interactions between them is not very obvious. It would
probably be simpler just to stick with 2, right? You really only care
about the misc structure here.
thanks,
greg k-h
Powered by blists - more mailing lists