devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tony Camuso <tcamuso@redhat.com>
To: minyard@acm.org
Cc: Robert Evans <Robert.Evans@stratus.com>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, rob.herring@calxeda.com,
	grant.likely@secretlab.ca, Jim Paradis <jparadis@redhat.com>,
	openipmi-developer@lists.sourceforge.net,
	Corey Minyard <tcminyard@gmail.com>
Subject: Re: [PATCH] ipmi: add new kernel options to prevent automatic ipmi init
Date: Fri, 14 Dec 2012 09:23:30 -0500	[thread overview]
Message-ID: <50CB3662.5080100@redhat.com> (raw)
In-Reply-To: <50CA31BB.2030507@acm.org>

RHEL builds the ipmi_si into the kernel by default, rather than as a
module, because it is required early in order to be available for ACPI
opregion access. However, it appears that some of our customers have
custom ipmi drivers, and this gets in their way.

Stratus is currently evaluating your suggestions, and we are expecting a
response from them sometime today or early next week.

On 12/13/2012 02:51 PM, Corey Minyard wrote:
> Well, the built-in driver works on systems that have more than one interface
> and more than one BMC, and multiple IPMBs (and all of the other channel
> types for that matter, and the driver handles all the multiplexing and nasty
> addressing).  There is, in fact, no arbitrary limit, and IBM tested
> this fairly extensively with some of their systems.  I'm not sure why you
> would need a custom driver, and if there are some custom things that need
> to be done for your servers, I'd be happy to add that.  I've worked with a
> number of other vendors to get changes like this in.  And then ipmitool,
> freeipmi, openipmi, etc. will work with the device.
>
> I don't have a big problem with this patch.  I wonder why you would want
> to compile the standard driver into your kernel if you expected to load a
> module with a custom driver later, though.  None of the distros I know of
> compile it in, it's always a module.
>
> You can also dynamically remove the device from the driver using the hot
> add/remove capability.  To remove it, you can do:
>    echo remove,`cat /proc/ipmi/0/params`
> and it will disassociate that device (IPMI interface 0 in this case) from the
> driver.  So you can iterate through all the devices in /proc/ipmi and
> remove them all at startup.
>
> If none of the above options work for you, we can go ahead with this
> patch.  Just wanted to let you know that current options exist, and see
> if you wanted to take a different direction.
>
> -corey
>

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

  reply	other threads:[~2012-12-14 14:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-13 18:40 [PATCH] ipmi: add new kernel options to prevent automatic ipmi init Tony Camuso
2012-12-13 19:51 ` Corey Minyard
2012-12-14 14:23   ` Tony Camuso [this message]
     [not found]     ` <50CB3662.5080100-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-01-08 20:12       ` [PATCH] ipmi: replace call to try_smi_init() with call to add_smi() Tony Camuso
     [not found]         ` <50EC7DAF.8030606-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-01-09 13:39           ` Tony Camuso
     [not found]   ` <50CA38CE.2040005@redhat.com>
     [not found]     ` <AC1B83CE65082B4DBDDB681ED2F6B2EF023202A7@EXHQ.corp.stratus.com>
2012-12-14 16:25       ` [PATCH] ipmi: add new kernel options to prevent automatic ipmi init Evans, Robert
2012-12-14 17:02         ` Corey Minyard
2012-12-17 21:14           ` Evans, Robert
     [not found]             ` <AC1B83CE65082B4DBDDB681ED2F6B2EF023202B4-d72qy8bFiXh4vSn6MaHdYpqQE7yCjDx5@public.gmane.org>
2012-12-21 21:38               ` Evans, Robert

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=50CB3662.5080100@redhat.com \
    --to=tcamuso@redhat.com \
    --cc=Robert.Evans@stratus.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=jparadis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minyard@acm.org \
    --cc=openipmi-developer@lists.sourceforge.net \
    --cc=rob.herring@calxeda.com \
    --cc=tcminyard@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).