From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Benedikt Spranger <b.spranger@linutronix.de>
Cc: netdev@vger.kernel.org,
Alexander Frank <Alexander.Frank@eberspaecher.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
"Hans J. Koch" <hjk@hansjkoch.de>,
Holger Dengler <dengler@linutronix.de>
Subject: Re: [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading
Date: Thu, 15 Aug 2013 01:09:01 -0700 [thread overview]
Message-ID: <20130815080901.GC7080@kroah.com> (raw)
In-Reply-To: <20130815092753.5a23810b@mitra.spranger.biz>
On Thu, Aug 15, 2013 at 09:27:53AM +0200, Benedikt Spranger wrote:
> On Wed, 14 Aug 2013 23:59:36 -0700
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > Hm. Ah, doesn't this work like PCI, when a PCI device is removed from
> > the system, reads just start returning all 0xFF, so the userspace UIO
> > driver now knows the device is gone from the system. Doesn't MFD
> > hardware work the same way? Why would removing the MFD driver affect
> > UIO at all, as it's just an interrupt and memory, both of which are
> > controlled by UIO, not MFD at all.
> >
> > confused,
> Sorry for the confusion.
>
> MFD core allocates the platform device structure and platform data
> dynamicaly and fill it up with appropriate data from the MFD cell data.
> And MFD core frees this memory on unregistering.
>
> Therefore the UIO driver needs to know that the underlaying platform device
> struct and platform device data are invalid and should not be used any more.
> The whole point are dynamicaly allocated devices and UIO.
Given that a UIO driver does need to specificly bind to a device (be it
a PCI, OF, or something else), it should be the one that is notified
when a device is removed.
Again, just like PCI is handled today, why is MFD so "special" that it
can't tell the drivers bound to its devices that it is going away?
Do you have a specific example of an in-tree UIO driver that has this
problem that I can look at to try to understand this better?
Still confused,
greg k-h
next prev parent reply other threads:[~2013-08-15 8:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-13 9:08 [PATCH 0/7] add FlexRay support Benedikt Spranger
2013-08-13 9:08 ` Benedikt Spranger
2013-08-13 9:08 ` [PATCH 1/7] uio: add module owner to prevent inappropriate module unloading Benedikt Spranger
2013-08-13 17:48 ` Greg Kroah-Hartman
2013-08-14 7:19 ` Benedikt Spranger
2013-08-14 16:33 ` Greg Kroah-Hartman
2013-08-15 6:42 ` Benedikt Spranger
2013-08-15 6:59 ` Greg Kroah-Hartman
2013-08-15 7:27 ` Benedikt Spranger
2013-08-15 8:09 ` Greg Kroah-Hartman [this message]
2013-08-15 8:18 ` Sebastian Andrzej Siewior
2013-08-15 15:55 ` Greg Kroah-Hartman
2013-08-15 16:03 ` Sebastian Andrzej Siewior
2013-08-15 16:42 ` Greg Kroah-Hartman
2013-08-15 16:54 ` Sebastian Andrzej Siewior
2013-08-15 17:13 ` Greg Kroah-Hartman
2013-08-13 9:08 ` [PATCH 2/7] uio: Allow to create custom UIO attributes Benedikt Spranger
2013-08-13 17:54 ` Greg Kroah-Hartman
2013-08-13 9:08 ` [PATCH 3/7] mfd: core: copy DMA mask and params from parent Benedikt Spranger
2013-08-13 10:03 ` Lee Jones
2013-08-13 9:08 ` [PATCH 4/7] mfd: add MFD based flexcard driver Benedikt Spranger
2013-08-13 9:55 ` Lee Jones
2013-08-14 8:12 ` Benedikt Spranger
2013-08-14 9:45 ` Lee Jones
2013-08-13 9:08 ` [PATCH 5/7] clocksource: Add flexcard support Benedikt Spranger
2013-08-13 9:08 ` [PATCH 6/7] net: add the AF_FLEXRAY protocol Benedikt Spranger
2013-08-18 18:50 ` Oliver Hartkopp
2013-08-13 9:08 ` [PATCH 7/7] net: add a flexray driver Benedikt Spranger
Reply instructions:
You may reply publicly 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=20130815080901.GC7080@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Alexander.Frank@eberspaecher.com \
--cc=b.spranger@linutronix.de \
--cc=bigeasy@linutronix.de \
--cc=dengler@linutronix.de \
--cc=hjk@hansjkoch.de \
--cc=netdev@vger.kernel.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.