From nobody Tue Oct 11 13:23:01 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MmxL03PgFz4fjjK for ; Tue, 11 Oct 2022 13:23:04 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MmxKz4vr2z3gw3 for ; Tue, 11 Oct 2022 13:23:03 +0000 (UTC) (envelope-from jrtc27@jrtc27.com) Received: by mail-wm1-f50.google.com with SMTP id e18so8594826wmq.3 for ; Tue, 11 Oct 2022 06:23:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gZwDMwQ9e04nfWV0MeSBZ4bznPVvIzXn8ioHqX87Odg=; b=vwzc7xAiy7LXUF+xs3k2gVU5MlCvla3+DMico3U9ak6AgM7OKjRWxct1qPOB2vecrS 2qMKgVaq6hmERIwxsLjUyquaN5qwPr7rIpxUabzLE7rc2zRt9TrMMzfp6Nnt/07ll/Ph M3sUGGShnWEtbAW0XdRB9nx1sWj5rjbIlbUzGofunHPmxgJurT3Gjc6H+UTmBiUqBevB QMISFZ9q+dVnTWUE+g98y201ANL2Qndt1by2HgijmwAHSayZZ5OFsG0jG6RZL4NhWM99 Vh3Bs18qoZoxh0zrs8jmF7hDjT+zqdc5MWORDtXBdMs1sTlAIcVJ7Hm3YXuwk60HCeb9 PgKg== X-Gm-Message-State: ACrzQf0F1bLWsaRz2QkiNyZ1VVPaH+BnYzSWxTOlZOsqR/10AXMsYNnD QizbUg34BqaH2TGGvM2fL0bnbKAKF8kbzXGP X-Google-Smtp-Source: AMsMyM4yIjSzyVx0IQCdX1ndOZMgHiMwrv1AB4Bf6vabiK6sgON6JBODOEOpFwNIyqAAvIuLP3uaNw== X-Received: by 2002:a05:600c:3b21:b0:3c6:172:9c5a with SMTP id m33-20020a05600c3b2100b003c601729c5amr8983101wms.129.1665494582358; Tue, 11 Oct 2022 06:23:02 -0700 (PDT) Received: from smtpclient.apple (global-5-142.n-2.net.cam.ac.uk. [131.111.5.142]) by smtp.gmail.com with ESMTPSA id d9-20020adff2c9000000b0021badf3cb26sm13945896wrp.63.2022.10.11.06.23.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Oct 2022 06:23:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: git: 99e6980fcf5e - main - device_get_property: add a HANDLE case From: Jessica Clarke In-Reply-To: Date: Tue, 11 Oct 2022 14:23:01 +0100 Cc: "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7D99DFCA-2455-43E2-A9AB-2C3EDB8BC7AE@freebsd.org> References: <202210092153.299LriCA024248@gitrepo.freebsd.org> <9C2F0D00-829F-4EF6-9F27-AC4242C60A3A@freebsd.org> To: "Bjoern A. Zeeb" X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Queue-Id: 4MmxKz4vr2z3gw3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of jrtc27@jrtc27.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=jrtc27@jrtc27.com X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; TO_DN_EQ_ADDR_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; FROM_HAS_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.128.50:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEFALL_USER(0.00)[jrtc27]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[jrtc27@freebsd.org,jrtc27@jrtc27.com]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.128.50:from] X-ThisMailContainsUnwantedMimeParts: N On 11 Oct 2022, at 13:10, Bjoern A. Zeeb wrote: >=20 > On Tue, 11 Oct 2022, Jessica Clarke wrote: >=20 >> On 9 Oct 2022, at 22:53, Bjoern A. Zeeb wrote: >>>=20 >>> The branch main has been updated by bz: >>>=20 >>> URL: = https://cgit.FreeBSD.org/src/commit/?id=3D99e6980fcf5e12654c3e89b97b774de8= 07d740a4 >>>=20 >>> commit 99e6980fcf5e12654c3e89b97b774de807d740a4 >>> Author: Bjoern A. Zeeb >>> AuthorDate: 2022-09-29 12:41:58 +0000 >>> Commit: Bjoern A. Zeeb >>> CommitDate: 2022-10-09 21:51:25 +0000 >>>=20 >>> device_get_property: add a HANDLE case >>>=20 >>> This will resolve a reference and return the appropriate handle, a = node >>> on the simplebus or an ACPI_HANDLE for ACPI. For now we do not try = to >>> further abstract the return type. >>=20 >> How=E2=80=99s this supposed to be used though? phandle_t is a = uint32_t and >> ACPI_HANDLE is a void *, which are not the same size (aside from >> ILP32), let alone the same type. The existing interface lets you not >> care about the bus because the type corresponds to what you ask for >> (string or fixed-width integer), but this totally breaks that. This >> really should be abstracting the type as well, presumably to a >> uintptr_t. >=20 > While that is all true, basic types are always easier to handle :) >=20 > All known use cases so far have entirely different code paths in ACPI = and > FDT as they are "described" differently and there would be more work = to be > done to harmonize these cases. Not once you get in to the DSD world, where you have device tree = bindings inside ACPI and want to be able to use one code path for both. > Making it a uintptr_t wouldn't solve that problem and that later code = has to > deal with the appropriate type still and call non-bus-bus-specific = functions > (e.g., acpi_get_device vs. OF_device_from_xref) with the appropriate = type and > I'd almost vote for extending this to return a device instead rather > than a handle, but that may be highly dependent on the use case I am > aware of. Using a device wouldn=E2=80=99t let you get at intermediary nodes that = have no device. You do want a way to turn the handle into a device in a bus-agnostic way, though. > In earlier code I used the DEVICE_PROP_ANY with the bus-sized encoded > handle. Now we get at least proper size checks on each bus, and avoid > putting ACPI-internal code into drivers and avoid code duplication = there > and we have a way to track the use-cases. >=20 > mw@ had initially asked for this to be broken out of another review = and said > he's working on more code (I haven't seen) which will hopefully = benefit from > this and I assume once we get there and some more bus-abstractions may > be dealt with, we may be able to refine this. My concern is this is just not quite the right shape for the use cases I=E2=80=99m imagining, but tweaking it slightly (using uintptr_t, or integer-in-a-void *), would allow for that whilst being completely compatible with whatever you=E2=80=99re trying to achieve here. My = problem is I=E2=80=99ve been looking at trying to do more complete DSD things to = support PRP0001 bindings and this isn=E2=80=99t taking into account the = existence of that. Jess > Hence the "For now ..." in the commit message. I'll highly likely = defer > the MFC for longer than specified for those reasons but I like to have > the email to not forget about it. >=20 > /bz >=20 > --=20 > Bjoern A. Zeeb r15:7