public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Chang, Junxiao" <junxiao.chang@intel.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"Li, Lili" <lili.li@intel.com>
Subject: Re: [PATCH] platform: release resource itself instead of resource tree
Date: Fri, 26 Jul 2019 16:01:18 +0200	[thread overview]
Message-ID: <20190726140118.GA23143@kroah.com> (raw)
In-Reply-To: <840F6BCBBBA89F46BAD0D7D6EF39E6E350F5072A@SHSMSX107.ccr.corp.intel.com>


A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Fri, Jul 26, 2019 at 10:24:22AM +0000, Chang, Junxiao wrote:
> Hi Greg,
> 
> Thank you for looking at it.
> 
> Below example is simplified description. Our detail problem is:
> 1. ACPI driver registers a MEM resource during bootup;
> 2. Our PUNIT(Intel CPU power management module) platform device reads ACPI driver's resource, and registers same MEM resource;
> 3. According to current resource management logic, if two resources are same, later registered resource will be parent. That is, PUNIT platform device's resource will be ACPI driver resource's parent.
> 4. PUNIT kernel module is removed, its resource will be removed. If we use original API "release_resource", ACPI driver's resource will be released as well because it is PUNIT device's child;

Why did you remove this module?  That never happens unless you do it "by
hand", and as root.  Just don't do this if it causes problems in your
system, right?

Anyway, if you create a child reference you should always clean up all
of your children before removing yourself from memory.  So try fixing
that up first.

> 5. Next time PUNIT platform device kernel module is inserted, it might read wrong ACPI MEM resource because it has been released in step 4.
> 
> How should we handle this case? :) 

Don't unload kernel modules unless you know what you are doing :)

Seriously, you are creating a dependancy here that you are not
expressing in your module reference count, and you are not properly
cleaning up after yourself when removing your devices.  Just delete your
child devices when unloading yourself and you should be fine, right?

> We should not register same MEM resource in step 2? Or, make change in
> resource management logic, if two resources are same, later registered
> resource should be child instead of parent?

I don't know how your resource management logic works, try working with
the developers who wrote that.  But as you describe it, it is not
correct at least when you try to clean things up.

thanks,

greg k-h

      reply	other threads:[~2019-07-26 14:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25  6:24 [PATCH] platform: release resource itself instead of resource tree junxiao.chang
2019-05-30  3:50 ` Chang, Junxiao
2019-07-25 13:38 ` Greg KH
2019-07-26 10:24   ` Chang, Junxiao
2019-07-26 14:01     ` Greg KH [this message]

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=20190726140118.GA23143@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=junxiao.chang@intel.com \
    --cc=lili.li@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox