All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: "Jean-François Dagenais" <dagenaisj@sonatest.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: MFD: core assumes that all children are platform devices
Date: Tue, 29 Nov 2011 10:57:46 -0800	[thread overview]
Message-ID: <20111129185746.GA23986@ericsson.com> (raw)
In-Reply-To: <2F9D884C-6B95-4F81-8445-8056676B28D8@sonatest.com>

On Mon, Nov 28, 2011 at 11:23:00AM -0500, Jean-François Dagenais wrote:
> Hi,
> 
> I have a pci driver that registers with UIO for it's operations. As a consequence, the pci device
> instance has a child device of class uio.
> 
> My driver also declares a ds1wm instance that has it's register interface at an offset in BAR0
> of the pci device, as an MFD cell.
> 
> When I call mfd_remove_devices, MFD proceeds to enumerate ALL the parent device's chilren
> and assumes that they are MFD cells, and thus platform_device, which is not true in my case.
> (...uio is a child of the parent pci device)
> 
> I had (luckily or unluckily) not seen signs of this broken assumption on certain setups I have
> used, but in my current setup, this page-faults every time now.
> 
> This is a major thing and I have not found the assumption documented anywhere.
> 
> I could first declare a new child device on my pci device and then declare it as the parent to
> the mfd cells...
> 
I had the same problem, with a Multi-function USB device. Took me a while to figure out that
mfd_remove_devices() removed the USB child devices when I used the USB device as MFD parent device.

My solution was to do what you suggested - my MFD probe function now creates a platform device
to be used as MFD parent device. Works nicely, it doesn't require much additional code,
and I think it is cleaner than other possible solutions (at least the ones I came up with).
We'll see how it flies with the MFD and USB maintainers once I submit the patch ;).

> Or, is there a way for the mfd-core, as it's doing the "for each child device", to recognize
> non-MFD-cell children and skip them?
> 
Looking at your proposed patch, I personally prefer my solution. Of course it would be nice
if it was documented that MFD parent devices MUST be dedicated (platform) devices and must not
have any non-MFD child devices. This would be a simple documentation patch and avoid making
assumptions on MFD child device removal.

Guenter 

  parent reply	other threads:[~2011-11-29 18:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-28 16:23 MFD: core assumes that all children are platform devices Jean-François Dagenais
2011-11-28 19:01 ` [PATCH] mfd: core - make sure children are cells during mfd_remove_devices Jean-François Dagenais
2011-11-29 18:57 ` Guenter Roeck [this message]
2011-11-29 21:40   ` MFD: core assumes that all children are platform devices Jean-François Dagenais
2011-11-29 23:02     ` Guenter Roeck
2011-11-30 14:21       ` Jean-Francois Dagenais
  -- strict thread matches above, loose matches on Subject: below --
2011-11-28 16:31 Jean-Francois Dagenais

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=20111129185746.GA23986@ericsson.com \
    --to=guenter.roeck@ericsson.com \
    --cc=dagenaisj@sonatest.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    /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.