All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang\, Ying" <ying.huang@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Huang Ying <ying.huang@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: GHES platform devices
Date: Thu, 17 Nov 2016 09:27:02 +0800	[thread overview]
Message-ID: <87twb6uc9l.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20161116213625.GA10368@bhelgaas-glaptop.roam.corp.google.com> (Bjorn Helgaas's message of "Wed, 16 Nov 2016 15:36:25 -0600")

Hi, Bjorn,

Bjorn Helgaas <helgaas@kernel.org> writes:

> Hi Huang,
>
> 7ad6e9435596 ("ACPI, APEI, Manage GHES as platform devices") added
> platform devices so the GHES driver could be built as a module and
> automatically loaded when needed.
>
> Later, 86cd47334b00 ("ACPI, APEI, GHES, Prevent GHES to be built as
> module") removed the ability to build GHES as a module.
>
> Should we revert 7ad6e9435596?  It's inconsistent to handle GHES, but
> not other error sources, as a platform device.  And having it as a
> platform device probably puts gunk in sysfs that we don't need.

Although other error sources are not platform devices, I think it is
generally good to make GHES platform devices.  To take advantage of
automatic module loading, we can make ghes a module again, but prevent
it from unloading.  What do you think about that?

Best Regards,
Huang, Ying

WARNING: multiple messages have this Message-ID (diff)
From: "Huang\, Ying" <ying.huang@intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Huang Ying <ying.huang@intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>, <linux-acpi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: GHES platform devices
Date: Thu, 17 Nov 2016 09:27:02 +0800	[thread overview]
Message-ID: <87twb6uc9l.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20161116213625.GA10368@bhelgaas-glaptop.roam.corp.google.com> (Bjorn Helgaas's message of "Wed, 16 Nov 2016 15:36:25 -0600")

Hi, Bjorn,

Bjorn Helgaas <helgaas@kernel.org> writes:

> Hi Huang,
>
> 7ad6e9435596 ("ACPI, APEI, Manage GHES as platform devices") added
> platform devices so the GHES driver could be built as a module and
> automatically loaded when needed.
>
> Later, 86cd47334b00 ("ACPI, APEI, GHES, Prevent GHES to be built as
> module") removed the ability to build GHES as a module.
>
> Should we revert 7ad6e9435596?  It's inconsistent to handle GHES, but
> not other error sources, as a platform device.  And having it as a
> platform device probably puts gunk in sysfs that we don't need.

Although other error sources are not platform devices, I think it is
generally good to make GHES platform devices.  To take advantage of
automatic module loading, we can make ghes a module again, but prevent
it from unloading.  What do you think about that?

Best Regards,
Huang, Ying

  reply	other threads:[~2016-11-17  1:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-16 21:36 GHES platform devices Bjorn Helgaas
2016-11-17  1:27 ` Huang, Ying [this message]
2016-11-17  1:27   ` Huang, Ying

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=87twb6uc9l.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=helgaas@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /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.