From owner-freebsd-arch@freebsd.org Wed Apr 14 21:06:38 2021 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DBAD65D02FA for ; Wed, 14 Apr 2021 21:06:38 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FLFQQ0XVxz4Sl4 for ; Wed, 14 Apr 2021 21:06:37 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7CAAA8D4A2D1; Wed, 14 Apr 2021 21:06:29 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 362EAE70815; Wed, 14 Apr 2021 21:06:28 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id VCL4vhN9qInZ; Wed, 14 Apr 2021 21:06:27 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:9d90:e0cc:c9da:e24b]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F0B89E70814; Wed, 14 Apr 2021 21:06:26 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Warner Losh" Cc: freebsd-arch@freebsd.org Subject: Re: New device wiring option Date: Wed, 14 Apr 2021 21:06:25 +0000 X-Mailer: MailMate (2.0BETAr6151) Message-ID: <08A076D6-369B-4CE5-9DE6-012E2708F792@lists.zabbadoz.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4FLFQQ0XVxz4Sl4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:4f8:13b:39f::9f:25:from]; SPAMHAUS_ZRD(0.00)[2a01:4f8:13b:39f::9f:25:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arch] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 21:06:38 -0000 On 14 Apr 2021, at 18:35, Warner Losh wrote: > for wiring up CAM devices. However, while these extra uses would be nice, > supporting them is beyond the scope of the initial work (though hopefully > the initial work would make enabling these later easier). I plan on > implementing a generic locator KPI for this, but will focus on only the > uefi and newbus locators initially. Later acpi, ofw, fdt and other location > mechanisms can be added. The uefi path stuff, btw, does not require the > system boot using UEFI. Probably USB as well? Having 10 serial consoles on USB Hubs and unplugging one “early” one it is easy to end up re-numbering the entire chain after a reboot. Not sure if this really fits into your problem/implementation domain. /bz