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>