DriverDev-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Christian.Gromm@microchip.com
Cc: driverdev-devel@linuxdriverproject.org
Subject: Re: [PATCH RFC v3 5/9] staging: most: usb: check for NULL device
Date: Wed, 15 Jan 2020 16:37:13 +0100
Message-ID: <20200115153713.GA3881751@kroah.com> (raw)
In-Reply-To: <570cc8ba04c4939b57726e21064ea5a1357417cb.camel@microchip.com>

On Wed, Jan 15, 2020 at 03:32:48PM +0000, Christian.Gromm@microchip.com wrote:
> On Wed, 2020-01-15 at 13:18 +0100, Greg KH wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> > 
> > On Tue, Jan 14, 2020 at 04:57:54PM +0100, Christian Gromm wrote:
> > > Check if the dci structer has been allocated before trying to
> > > release it.
> > > 
> > > Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
> > > ---
> > > v3:
> > >       This patch has been added to the series.
> > > 
> > >  drivers/staging/most/usb/usb.c | 6 ++++--
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/staging/most/usb/usb.c
> > > b/drivers/staging/most/usb/usb.c
> > > index fe3384a..cae7553 100644
> > > --- a/drivers/staging/most/usb/usb.c
> > > +++ b/drivers/staging/most/usb/usb.c
> > > @@ -1205,8 +1205,10 @@ static void hdm_disconnect(struct
> > > usb_interface *interface)
> > >       del_timer_sync(&mdev->link_stat_timer);
> > >       cancel_work_sync(&mdev->poll_work_obj);
> > > 
> > > -     most_put_iface_dev(mdev->dci->dev.parent);
> > > -     device_unregister(&mdev->dci->dev);
> > > +     if (mdev->dci) {
> > > +             most_put_iface_dev(mdev->dci->dev.parent);
> > > +             device_unregister(&mdev->dci->dev);
> > > +     }
> > 
> > How can this happen?
> 
> Depending on the Vendor/Product ID pair of the device that
> probes the USB driver, this 'dci' structure is being allocated
> and registered or not. And that is why this check is necessary. 
> 
> > 
> > And why is it up to the child function here to unregister the device,
> 
> Child function? The device is being registered in the probe function
> and unregistered in the disconnect function. What is wrong here?

Ah, ok, I got confused here with the previous patch, sorry.

greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 15:57 [PATCH RFC v3 0/9] staging: most: move core module out of staging Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 1/9] staging: most: core: fix date in file comment Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 2/9] staging: most: core: use dev_* function for logging Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 3/9] staging: most: core: remove noisy log messages Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 4/9] staging: most: move interface dev to private section Christian Gromm
2020-01-15 12:17   ` Greg KH
2020-01-15 16:04     ` Christian.Gromm
2020-01-14 15:57 ` [PATCH RFC v3 5/9] staging: most: usb: check for NULL device Christian Gromm
2020-01-15 12:18   ` Greg KH
2020-01-15 15:32     ` Christian.Gromm
2020-01-15 15:37       ` Greg KH [this message]
2020-01-14 15:57 ` [PATCH RFC v3 6/9] staging: most: change storage class of struct mostcore Christian Gromm
2020-01-15 12:19   ` Greg KH
2020-01-14 15:57 ` [PATCH RFC v3 7/9] staging: most: move core files out of the staging area Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 8/9] staging: most: Documentation: update ABI description Christian Gromm
2020-01-14 15:57 ` [PATCH RFC v3 9/9] staging: most: Documentation: move ABI description files out of staging area Christian Gromm
2020-01-15 12:20 ` [PATCH RFC v3 0/9] staging: most: move core module out of staging Greg KH

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200115153713.GA3881751@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Christian.Gromm@microchip.com \
    --cc=driverdev-devel@linuxdriverproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DriverDev-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/driverdev-devel/0 driverdev-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 driverdev-devel driverdev-devel/ https://lore.kernel.org/driverdev-devel \
		driverdev-devel@linuxdriverproject.org devel@driverdev.osuosl.org
	public-inbox-index driverdev-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linuxdriverproject.driverdev-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git