From owner-freebsd-hackers@freebsd.org Fri Sep 11 04:59:25 2015 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 E50E7A01EEB for ; Fri, 11 Sep 2015 04:59:25 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 A331419E7 for ; Fri, 11 Sep 2015 04:59:25 +0000 (UTC) (envelope-from alex.burlyga.ietf@gmail.com) Received: by vkhf67 with SMTP id f67so20866157vkh.1 for ; Thu, 10 Sep 2015 21:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QslbW8oXzVsg0V8nw7hjR8W+1j3B0vUR6o3KamuSqZ8=; b=mXthswlAGmnsem/YP6eU36vNiy5IQs6U23qmxxVgNUCTSv1Kah/PCdkf7Qb0rc2r9f rMMSXGJiHpq8BAmEA/PnY4P6mfNTrSu25AQElLpC0y06cZSr/JXmdem9vjCNYPQeIfvR e9OoPr9UG18r1I9ATXdxzzh5P6kR484e5GuETm8pRDcUDq14rlPEa8lW6kRKPUN19exn Vq+6npHHWCQkc1RIz/MqaitGqT95qqtoBLndl/FO02rz8vBD5DeNPAaxR1jUyuNf1D4Y U6BbL0fQo3IjTd+99oEm6gCT1JFzsAOsh9S5+cTyUG9CTW4N0Ar8aWdIrF37IsumGZQi dt4w== MIME-Version: 1.0 X-Received: by 10.31.136.9 with SMTP id k9mr3096631vkd.92.1441947564557; Thu, 10 Sep 2015 21:59:24 -0700 (PDT) Received: by 10.103.81.193 with HTTP; Thu, 10 Sep 2015 21:59:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Sep 2015 21:59:24 -0700 Message-ID: Subject: Re: bus_.*_resource() and rid From: "alex.burlyga.ietf alex.burlyga.ietf" To: "Pokala, Ravi" Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 04:59:26 -0000 See replies in-line. On Tue, Sep 8, 2015 at 7:37 PM, Pokala, Ravi wrote: > Hi folks, > > I'm modifying a home-grown device driver; this is the first time I've > played around in device-probe and -attach, so I'm a bit out of my element > here. This is an LPC device attached to a PCI-ISA bridge (aka the LPC > controller). It's accessed through IOPORT, and the BIOS sets up enough > stuff that we can look for it. > > One thing that's confusing me is the "rid" which is passed to a bunch of > the bus_.*_resource() functions. I've looked at bus_set_resource(9), > bus_alloc_resource(9), and section 10.5 of the Architecture Handbook[1], > and I'm still confused. > > bus_alloc_resource(9) says: > > rid points to a bus specific handle that identifies the resource being > allocated. For ISA this is an index into an array of resources that > have > been setup for this device by either the PnP mechanism, or via the > hints > mechanism. ... > > > But there's no indication as to how we get that index. One possibility is > that the value passed in doesn't matter; bus_alloc_resource() sets it > correctly and the caller can use the new value. However, that doesn't > appear to be the case, since lots of times rid is ignored after the call > to bus_alloc_resource(). It's a discriminator for the resource type. It's bus specific, so in case of ISA it's just an integer in a range of 0 to 50(i think). > > For the sake of discussion, here are stripped-down versions of our probe > and attach functions: > > xxx_probe_unit(device_t dev) > { > uint32_t ioport_base; > uint32_t ioport_size; > int rc; > > /* Device identification stuff; details unimportant, but we determine > * ioport_base and ioport_size. > */ > > rc = bus_set_resource( > /* dev */ dev, > /* type */ SYS_RES_IOPORT, > /* rid */ 0, > /* start */ ioport_base, > /* count */ ioport_size); > } > > Most of those args are obvious, but I have no idea why rid is 0. It looks > like lots of drivers pass in a rid of 0, and the original author might > have just shrugged and gone with "convention". Depends on the device, if it only has one IOPORT then this makes sense. > > xxx_attach_unit(device_t dev) > { > struct xxx_softc *sc; > int rid; > struct resource res; > > sc = device_get_softc(dev); > > /* Device configuration stuff; details unimportant. */ > > rid = 0; > res = bus_alloc_resource( > /* dev */ dev, > /* type */ SYS_RES_IOPORT, > /* rid */ &rid, > /* start */ 0, > /* end */ ~0, > /* count */ sc->ioport_size, > /* flags */ RF_ACTIVE); > > /* save stuff for use with bus_space_{read,write}_1() */ > sc->iobase_addr = rman_get_start(res); > sc->iobase_bustag = rman_get_bustag(res); > sc->iobase_bushandle = rman_get_bushandle(res); > sc->dev = dev; > } > > Again, most things are fairly obvious, but I have no idea why rid is 0. > It's passed by reference to bus_alloc_resource(), but the > potentially-altered value is never stored or used. You are attaching a driver to a device, so you are actually allocating resource for the range you claimed in the probe function with bus_set_resource. Again since device has only one IOPORT, and ISA does not change "rid" so there is no need to store "rid" anywhere. > > The lazy part of me says to just go with blindly passing in 0, because it > works. However, the new device I'm adding support for will have multiple > IOPORT ranges associated with it, so I'm not sure if passing 0 is the > right thing. I think you have options here, during probe you can go with just 0 as "rid" but then during allocation you would need to populate start and end parameters with appropriate offsets. Or you can do "rid" per IOPORT and then you can retain 0, ~0 for start end and pass appropriate "rid" during attach phase. > > Any help would be appreciated. > > Thanks, > > Ravi > > [1] > https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/isa-driver- > resources.html > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"