From: Yasunori Goto <y-goto@jp.fujitsu.com>
To: mail@renninger.de
Cc: Thomas Renninger <trenn@suse.de>,
akpm@osdl.org, "Brown, Len" <len.brown@intel.com>,
keith mannthey <kmannth@us.ibm.com>,
ACPI-ML <linux-acpi@vger.kernel.org>,
Linux Kernel ML <linux-kernel@vger.kernel.org>,
Linux Hotplug Memory Support <lhms-devel@lists.sourceforge.net>,
naveen.b.s@intel.com
Subject: Re: [PATCH](memory hotplug) Repost remove useless message at boot time from 2.6.18-rc4.
Date: Tue, 29 Aug 2006 10:57:23 +0900 [thread overview]
Message-ID: <20060829102200.FC1D.Y-GOTO@jp.fujitsu.com> (raw)
In-Reply-To: <1156799818.12158.9.camel@linux-1vxn.site>
> > Old code registers handler for all of memory devices even if it is not
> > enabled.
> Yeah, therefore the mem_device cannot be passed as callback data as it
> might get generated in the notify handler func and all the additional
> stuff is needed..., ouch.
> >
> > If my understanding is wrong, please let me know. ;-)
> It's me who is wrong, thanks a lot for checking!
>
> > Memory device might not have _EJ0/_EJD, but parent device
> > (like one NUMA node) might be able to be ejectable.
> > In this case, only the parent device has _EJ0/_EJD.
> > So, one more check is necessary.
>
> I feared something like that (should have add a comment...), as the EJ0
> and _STA functions are only used on the device itself I thought checking
> for them makes sense, but for a missing EJ0 func powering down the
> device just fails and it should not be harmful.
> So the only useful thing from my patch (as long as .add is only invoked
> if device is present) is using the general acpi_bus_get_status() func.
> Hmm, it must be used if the _STA function on the memory device is also
> missing and the parent _STA must be used then? Could make sense on a
> machine where a whole node must be inserted/ejected? The
> acpi_bus_get_status() function already contains the checking for the
> parent's _STA function and uses this one if the device itself has none.
I don't have any report like "no _STA on memory device" so far.
Current code assume each memory device has _STA.
I suppose each memory device should have _STA method. For example,
if a memory device is broken, its _STA should return disable status.
So, basically checking _STA of only memory device should be ok now.
However I'm not sure that every vendor will do it in the future.
If there is no _STA on memory device, parents, grand-parents or
more ancestor might have _STA for it.
(See acpi_get_pxm() in driver/acpi/numa.c. It searches ancestor's _PXM.
If insane vendor make like it, it will be good reference.)
Bye.
--
Yasunori Goto
next prev parent reply other threads:[~2006-08-29 1:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-04 12:37 [PATCH](memory hotplug) remove useless message at boot time from 2.6.18-rc3 Yasunori Goto
2006-08-10 5:32 ` [PATCH](memory hotplug) Repost remove useless message at boot time from 2.6.18-rc4 Yasunori Goto
2006-08-10 20:26 ` Prarit Bhargava
2006-08-10 20:54 ` Len Brown
2006-08-10 20:55 ` Prarit Bhargava
2006-08-15 12:03 ` Thomas Renninger
2006-08-15 21:36 ` Yasunori Goto
2006-08-25 11:59 ` Yasunori Goto
2006-08-27 12:50 ` Thomas Renninger
2006-08-28 14:12 ` Yasunori Goto
2006-08-28 21:16 ` Thomas Renninger
2006-08-29 1:57 ` Yasunori Goto [this message]
2006-08-31 22:22 ` Bjorn Helgaas
2006-08-27 15:19 ` [PATCH 2/2] ACPI memory_hotplug cleanups Thomas Renninger
2006-08-27 17:19 ` [PATCH 1/2] acpi hotplug cleanups, move install notifier to add function Thomas Renninger
2006-08-30 21:48 ` keith mannthey
2006-08-27 17:58 ` [PATCH 2/2] " Thomas Renninger
2006-08-28 8:08 ` Yasunori Goto
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=20060829102200.FC1D.Y-GOTO@jp.fujitsu.com \
--to=y-goto@jp.fujitsu.com \
--cc=akpm@osdl.org \
--cc=kmannth@us.ibm.com \
--cc=len.brown@intel.com \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@renninger.de \
--cc=naveen.b.s@intel.com \
--cc=trenn@suse.de \
/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
Powered by JetHome