From owner-freebsd-hackers@freebsd.org Sun Sep 9 22:44:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D456310A1167 for ; Sun, 9 Sep 2018 22:44:17 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78B3784707 for ; Sun, 9 Sep 2018 22:44:17 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id 26AF51DAE; Sun, 9 Sep 2018 18:44:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 09 Sep 2018 18:44:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=8opAWpZ8U6Cus0BSsaCba9kvlM40r twEG3mhCoAekkY=; b=xOpZeiASaXZNqh3Po3+bH3Cu949DAGDnp0qelqYGWjTfP UeaDuAej4+2B5516VKLSUhsxwAl0GvHpoMDHs/CWCfz8801kI0dOUydGeEWuTWZd +C+qakj3C4kC1X6xZe3dkMETSs9oN2o1VHZumGfzM/aGWWWqIs1HW6cjjoyEYJnt 4m/6MsCS/X7YqtuWSZMibsG8uAnkrM/Xb7h2wG9NvzEdiKSUxwnbfiQ9bPm2lZTQ Ct6wOnDojl1cV94wGi02ZowxZFvHTVSZmIXoD2hI/6j16gbrQELmGfYXClYze7Jk SjZKLy1CvRcr00bUVDqJIFd1kGcyrjtHqpd3PbCig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=8opAWp Z8U6Cus0BSsaCba9kvlM40rtwEG3mhCoAekkY=; b=gqfIlYTeFR2/Y+FCyM21RD qRJhWBeFIMNyapKC1vVg6bA+NT6bWAx+p3pmRRTLwJS1+na6qyEj8fdhPM0StD0X ELRtinvqRFBbIuRuv9DcCpLZbuUNA5jl8zlQ7s9HC6REXNkvFVnepqLcpeWk7h9i 38M6RiVPFX7gOkpet1QL8mJ9LwhazByGjnGE2gjRPSJyo4wO//RUZyl/RJllDwek NpGNkRxsjxv3EAkvYK3VOUw50+zjQynyO0ed4a9UyeX05+PwQmU85F/3OMRMAM1R EG6eEShp8za965pW65VpI1T+QSNr7Z6Yd3dsv72Q+R4U9KMG5KCkjwJCUrPhMCRw == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [94.233.225.59]) by mail.messagingengine.com (Postfix) with ESMTPA id B1FEB10297; Sun, 9 Sep 2018 18:44:09 -0400 (EDT) Subject: Re: acpi, pci, spibus -- tying it all together To: Konstantin Belousov Cc: freebsd-hackers References: <30e41db8-a56d-e916-0490-7e184063a811@yuripv.net> <20180909092255.GM3161@kib.kiev.ua> From: Yuri Pankov Message-ID: <4770e2e5-ebb7-8740-dd7c-e16998bef970@yuripv.net> Date: Mon, 10 Sep 2018 01:44:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180909092255.GM3161@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 22:44:18 -0000 Konstantin Belousov wrote: > On Sun, Sep 09, 2018 at 10:25:44AM +0300, Yuri Pankov wrote: >> I have modified intelspi to attach to SPI master (Sunrise Point-H Serial >> IO SPI) located on pci bus, and on attach I have the spibus0 and spibus1 >> buses added. >> >> As spibus is not self-enumerating, the only way to find the slave device >> I need is via acpi bus probe, that works, but I don't see a way to make >> it a child of spibus1 (where it's located). >> >> In ACPI terms it looks like the below (from DSDT): >> >> ... >> \_SB_.PCI0.SPI0 "Device (SPI0)" >> \_SB_.PCI0.SPI1 "Device (SPI1)" >> ... >> Scope (SPI1) { >> Device (SPIT) { >> ...here comes all the data we need, >> including the ACPI ID we can probe... >> } >> } >> ... >> >> I hope that made at least some sense. And the question is if there any >> existing way of tying it all together, and adding that slave device to >> the spibus1 (which only knows about hinted children at the moment)? > > I had very similar situation where I wrote NVDIMM driver. > > The suggestion I got was to implement DEVICE_IDENTIFY() method. It > gets the driver_t and the parent bus device_t arguments. In the method, > you create children' device_t, iterating over the ACPI enumerated entries. > Practically, you would use acpica AcpiWalkNamespace(ACPI_TYPE_DEVICE, ...) > function and call BUS_ADD_CHILD() when needed. Set the ACPI handle for > the created child. [Get the Intel' ACPICA reference manual to understand > the KPI]. > > Then probe does nothing, and attach verifies against the handle. > > You can see that in https://kib.kiev.ua/kib/nvdimm.7.patch > nvdimm_identify(), nvdimm_foreach_acpi(), and nvdimm_create_dev(). Thank you, it was helpful indeed, especially the walk part.