Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Jul 2013 15:18:51 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        sbruno@freebsd.org
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r253708 - head/sys/dev/ipmi
Message-ID:  <201307301518.51746.jhb@freebsd.org>
In-Reply-To: <1375210620.1496.30.camel@localhost>
References:  <201307271632.r6RGWYF8046749@svn.freebsd.org> <201307301202.19954.jhb@freebsd.org> <1375210620.1496.30.camel@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, July 30, 2013 2:57:00 pm Sean Bruno wrote:
> 
> > > 
> > > Ok then what is this ^^^^^^^^^ ?  Doesn't this mean that if
> > > device_find_child() returns a child node that we should abort?  Is that
> > > not the same as what I'm going on about?
> > 
> > This makes it only add at most one child device.  It is a common idiom in
> > identify routines so that if you kldunload and re-kldload you don't end
> > up with two "ipmi" devices added by the identify routine.
> > 
> Ok, understood.  Why, in this edge case, is ipmi attaching twice then?
> Shouldn't device_find_child() return non-NULL because the ACPI interface
> is attached and /dev/ipmi0 has been started?  Or is it too early in the
> probe/attach device enumeration process for this check to succeed?

Two _different_ buses.  This prevents multiple ipmiX devices on the parent 
"isa0" device.  The other ipmiX device is one on acpi0, not isa0.

> Because of this, doesn't the BUS_ADD_CHILD later on "contaminate" our
> device tree with a device that doesn't exist?  I'm being kind of a PITA
> about this, I know.  I just want to understand what I'm missing here.

Well, except it does exist (in a manner of speaking). :)  The ACPI ipmiX 
device represents a device in the ACPI namespace that has a known _HID for 
IPMI BMCs.  The ISA ipmiX device represents a device discovered via the SMBIOS 
tables.  In practice the same physical device is being enumerated two 
different ways.  Most physical devices don't have aliases in this fashion, but 
x86 has a lot of cruft, and so in this particular instance you can find out 
about the device from two very different sources, and there are systems that 
support ACPI, but only enumerate the IPMI BMC via SMBIOS, so we can't just 
ignore the SMBIOS table if ACPI is being used.  Instead, we have to wait until
the SMBIOS-enumerated device probes to decide that we have a fully functional
ACPI-enumerated device that already "owns" the device.

> I'm "arguing" that the attempted creation (even though it fails)
> of /dev/ipmi1 in any way is really a bug.

To be clear, we never attempt to create /dev/ipmi1 (a character device in
/dev).  We might have a new-bus node named ipmi1 that represents the IPMI
BMC described by the SMBIOS table, but that is different from /dev/ipmi1.

> Sounds good.  Done.  Tests look good.  commited r253813.

Looks good to me, thanks.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307301518.51746.jhb>