From owner-freebsd-acpi@FreeBSD.ORG Wed May 16 20:07:47 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0ED31065673; Wed, 16 May 2012 20:07:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B2C7D8FC16; Wed, 16 May 2012 20:07:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 86D1DB948; Wed, 16 May 2012 16:07:46 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 16 May 2012 16:07:43 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <4FAF7343.8010808@cran.org.uk> <201205161050.35759.jhb@freebsd.org> <4FB3D351.6030804@FreeBSD.org> In-Reply-To: <4FB3D351.6030804@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205161607.43286.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 16 May 2012 16:07:47 -0400 (EDT) Cc: Bruce Cran , freebsd-acpi@freebsd.org, freebsd-current Subject: Re: ACPI 'driver bug: Unable to set devclass' X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 20:07:48 -0000 On Wednesday, May 16, 2012 12:18:25 pm Andriy Gapon wrote: > 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. Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() (and/or, not make the unit number in cpuX mean anything at all, but use a separate ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think the last approach is really the right way to fix this. -- John Baldwin