From owner-freebsd-hackers@freebsd.org Wed Aug 24 07:49:25 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8866EBC4E50 for ; Wed, 24 Aug 2016 07:49:25 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FE3F1343 for ; Wed, 24 Aug 2016 07:49:25 +0000 (UTC) (envelope-from karu.pruun@gmail.com) Received: by mail-ua0-x22d.google.com with SMTP id 74so14984307uau.0 for ; Wed, 24 Aug 2016 00:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TrpeLhkOaCUisYzicITcgBmXCLaiTtkgYQl+P4M0S6w=; b=Br+l7nKobKLJGRTVWSQQ+RrjC82V1dtjpn6vUxD9BFEtI9o4WoY9mR22Nb/Nh3ggAv C0u7+DoRxn1YusjvSVfj5L95Ih8GQA88px7fG4doSlS6E3MotURhjCcEpJpCQMWck4S0 7UyaHceqjOKAmIsMUUNDZIQjmN4tKhpKAjck4L6fXH6won/BDGy5w+rKrwZ92hZzTLRs pqwQFs3M4+/cLKrO5cZhUYErOcO23Wobz0hPo9CflDihE68SC8RvisfOxL84g9EX9R3X G6aNT7yKjrtYQBhlWIDDbmAbxz7h7cJHEt8pI3a87S8BNheAFFeOWxvrv4+uL0rbOgCF 49AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TrpeLhkOaCUisYzicITcgBmXCLaiTtkgYQl+P4M0S6w=; b=VXnZt2oTj911qnHk64eeGQ49l3LdB7O0PKwW0LGwzIYjbk5+TyIhrvIT1OmJym+qvo NdHggEPFXDUjs+DtPTdlpvOLC83qT6SXxruY7yA7vHVTIw6zD3oqa9SO+ag6Nkqkb5l3 z7Q/oxqKr4AM89kTMH6dHWeV8ERGJ+dJFRcC4KuPi5YU+SOdEafV7gi5TwemD5ffJWE5 Ub9BclOyo9hInY5d+h2x92G7y8YilXXc7//e/0qJnBf9WEbvCjbUAtJZ6abMPKRV7w0k MLMN8eZt7QAabZYFlyo2+tHtC2mkFpuJyyRVDwVB6vITvqL3/maUG0OIx72TbmDhwjkF tmFQ== X-Gm-Message-State: AEkoouv05D0ksv4BOI20z0U4kYsjdvHH8BlVXlWtN8ugFsEGa8pqmpJEaPnHrUDLzSbuMbc1ucaNgQ2OK1mDsQ== X-Received: by 10.31.170.9 with SMTP id t9mr937353vke.131.1472024964406; Wed, 24 Aug 2016 00:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.2.10 with HTTP; Wed, 24 Aug 2016 00:49:23 -0700 (PDT) In-Reply-To: <082EEC89-4BFF-48B9-84DA-C971D396A6CD@panasas.com> References: <20A27669-0B16-4199-853F-46D84E876AE9@panasas.com> <082EEC89-4BFF-48B9-84DA-C971D396A6CD@panasas.com> From: "karu.pruun" Date: Wed, 24 Aug 2016 10:49:23 +0300 Message-ID: Subject: Re: problem attaching driver at LPC bus To: Ravi Pokala Cc: Warner Losh , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 07:49:25 -0000 On Tue, Aug 23, 2016 at 6:45 PM, Ravi Pokala wrote: > -----Original Message----- > From: on behalf of Warner Losh > Date: 2016-08-23, Tuesday at 08:20 > To: Ravi Pokala > Cc: "freebsd-hackers@freebsd.org" , < > karu.pruun@gmail.com> > Subject: Re: problem attaching driver at LPC bus > > On Tue, Aug 23, 2016 at 9:13 AM, Ravi Pokala wrote: > >> ... > >> > >> One thing to note is that I was careful about keeping track of the > RIDs. Several of the existing drivers in the tree seem to just use 0 > indiscriminately, and it works because they only use one resource. > > > > For ISA drivers, RID is just a number, best thought of as an index. > > So incrementing here like you've done is the right call. > > > > Warner > > Right, someone (jhb?) explained that to me at the time. My point is that > the common practice of just passing in 0 doesn't always DTRT, especially if > you're dealing with multiple resources. > > -Ravi (rpokala@) > > Hi Ravi Thanks for these suggestions. I'll study the spec and try implement this. Question: the XXX_base in bus_set_resource --- did you find this address from the spec? I suppose in my case this is the one I see in the acpi tables, 0x0700. Another question: on my naive thinking, the acpi subsystem scans the acpi tables and populates the entries in the device tree, setting aside the address ranges (IO and mem) for which there is no driver. The handle items in the tree (e.g. \_SB_.PCI0.LPCB.GMUX) look very similar to the ones in the acpi tables. So I thought the driver then later claims these resource using the bus_alloc_resource(). Does this sound like anything that is actually happening? Thanks again Peeter --