Date: Wed, 16 May 2012 19:18:25 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Bruce Cran <bruce@cran.org.uk>, freebsd-acpi@FreeBSD.org, freebsd-current <freebsd-current@FreeBSD.org>, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: ACPI 'driver bug: Unable to set devclass' Message-ID: <4FB3D351.6030804@FreeBSD.org> In-Reply-To: <201205161050.35759.jhb@freebsd.org> References: <4FAF7343.8010808@cran.org.uk> <201205151034.13994.jhb@freebsd.org> <4FB285C0.1090905@FreeBSD.org> <201205161050.35759.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 16/05/2012 17:50 John Baldwin said the following: > On Tuesday, May 15, 2012 12:35:12 pm Andriy Gapon wrote: >> Not sure what you disagree with... >> First, the wildcard device is added to the child list during the walk. >> Then, the unit 0 device is added to the list when acpi_timer identify is executed. >> Then, the wildcard device is probed and gets unit number of zero. >> Then, the fixed device is being probed and the unit number conflict arises. >> >> Am I misunderstanding something? > > Yes. The third step will see that unit 0 is already in use and shouldn't > reuse unit 0. > Looks like I missed the call to devclass_add_device() in make_device(). Your guess: > I wonder if this is related to the recent changes to set the unit number for CPUs? seems to be true. The device_t-s created for CPUs have NULL driver name / devclass, but a non-wildcard unit number. So when such a device with unit number 0 is probed by acpi_timer we get a unit number conflict with acpi_timer0 pre-created via the identify. Similarly we get conflicts for acpi_sysresource driver, because we do an early probe-and-attach for this driver and the attached devices get some unit numbers (0, 1, etc). So when during the normal probe pass the "CPU" devices with matching unit numbers are passed to the driver the conflict results. I guess that it is an unorthodox use of newbus to specify a unit number without specifying a driver name... It's like saying "this device must be unit N whatever driver claims it (be it kbdN or diskN) just because I say so". Not sure if this ever makes sense and maybe we should prohibit such a combination (reject it earlier). I guess that in this particular case we already know that the devices are really CPU devices and are going to be claimed by acpi cpu driver. So we should pass "cpu" as the name. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FB3D351.6030804>