From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B41512AEE4; Mon, 23 Mar 2026 08:49:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255775; cv=none; b=apnam3scDaDN9hR5xHcU6QI1x68gWBaMGNBBTYxKAF+/gvPRdWygpqAkalwf2ytedoYFnMhCCX10vjctWxA6ZKL5qRPXx6imao0C6yDnfJk3kZ3iiF6pEJh0vklQqtpnFhECZURvy80u7EEnWNdUIs87uh1zxKrMNA66ATP503I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774255775; c=relaxed/simple; bh=p9B9IgGH88HGmQ61xIwwmQEr8RIY/R3tOPjndnPplWo=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=n8Sb78CvB2xkWi2CHcibl/K4Nzpe/turTDBbpZxJOTGkhxjjWNnUDxOzaXoUektEEQNhVe5sDHuHpmUifwPw3k0WQpGgxDgZkvEGGsE/66ROAMzLcmh8oZV3EjzihK8Fz58R7A16EAKn4c8b64FT1SlTJ41K8JXFOEh+V4XrChE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=q5yHBILY; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=qODxOPEn; arc=none smtp.client-ip=103.168.172.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="q5yHBILY"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="qODxOPEn" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfout.phl.internal (Postfix) with ESMTP id ED0C1EC01D5; Mon, 23 Mar 2026 04:49:32 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-04.internal (MEProxy); Mon, 23 Mar 2026 04:49:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1774255772; x=1774342172; bh=tdJCIcUWditaxcgxgFlEFsn2IU+LFbGTMnX6JWZKdXk=; b= q5yHBILYNTaEj0UGHrUmAVH4w1rePRf4dMjJnjHJIgqCe65RtIHEoyGaqnckTkgm A4UcGDFBgODFKfnYh+5ZmISGd7kUEX9nfN+2yLceV80VzkaEIy40Eiz6CmrUFZRK xIRMItES/zizM6T3Mi+KV3C+l0IMsdn8QwAJA49Ac1HFXQ5JoJHWoe+MKhs3zPgQ +Bf0Jn+SdtcqZ9OKNTZXn4u4elYtFWySYTZ9DeokaWy0s0NghroxBITWdPn2Vvjn vxOjIyyDA32cj9oIwk8j2zP1opyQ9UdbV92FF31JchQCxaNxGT+IJkgXk3/BvOfL T7/bfYLKJ6apIA1jP91rtg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1774255772; x= 1774342172; bh=tdJCIcUWditaxcgxgFlEFsn2IU+LFbGTMnX6JWZKdXk=; b=q ODxOPEnx2VlBZaEVPGjZw+T94REgQ60c2KcRLew88db3/pAF/8MWmYy/s1MaCW++ +sYaRgyIDskk/ZfhKtIszcsccCZnBmdf4QyUgNB8AHVftvLiNjbxpGCRl5bOuL0Z HL28paWI83IC3CHq0lOwbQqwNwdu7u5vEeSG2o3xg4iX6FKTwj9pW5eynAXNRv/J iWlxsY4GLzd25EJ4QHMBPgBgKcyakVUu9Yxlm14VY0RBZElZzh5RRqIotZBVKN58 AZrBYnEFxFw8PjzD/G7c2ZMGb9peWvIg/htDwIHdDPZzpX5x9FkpOvptRhTSWYI5 hYun3QeHE17t1YB9n/Wfg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdefudekvdejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrnhgu uceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrthhtvg hrnhepfefhheetffduvdfgieeghfejtedvkeetkeejfeekkeelffejteevvdeghffhiefh necuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegrrhhnugesrghrnhgusgdruggvpdhnsggprhgt phhtthhopeduiedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggvnhhnihhsrd gurghlvghsshgrnhgurhhosegtohhrnhgvlhhishhnvghtfihorhhkshdrtghomhdprhgt phhtthhopehnihgtkhdruggvshgruhhlnhhivghrshdolhhkmhhlsehgmhgrihhlrdgtoh hmpdhrtghpthhtohepjhhushhtihhnshhtihhtthesghhoohhglhgvrdgtohhmpdhrtghp thhtohepmhhorhgsohesghhoohhglhgvrdgtohhmpdhrtghpthhtohepmhhitghhrggvlh drjhdrrhhuhhhlsehinhhtvghlrdgtohhmpdhrtghpthhtohepmhhikhgvrdhmrghrtghi nhhishiihihnsehinhhtvghlrdgtohhmpdhrtghpthhtoheprghrnhgusehkvghrnhgvlh drohhrghdprhgtphhtthhopehlvghonheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohep mhhinhhgoheskhgvrhhnvghlrdhorhhg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id E1BE6700065; Mon, 23 Mar 2026 04:49:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AhovTUn8f-P3 Date: Mon, 23 Mar 2026 09:48:59 +0100 From: "Arnd Bergmann" To: "Leon Romanovsky" Cc: "Arnd Bergmann" , "Dennis Dalessandro" , "Jason Gunthorpe" , "Nathan Chancellor" , "Mike Marciniszyn" , "Michael J. Ruhl" , "Doug Ledford" , "Nick Desaulniers" , "Bill Wendling" , "Justin Stitt" , "Marco Crivellari" , "Ingo Molnar" , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev Message-Id: <5d5f25fc-e522-4131-ae4b-22db57b92d6e@app.fastmail.com> In-Reply-To: <20260323080848.GF814676@unreal> References: <20260320151511.3420818-1-arnd@kernel.org> <20260320151511.3420818-2-arnd@kernel.org> <6b56c476-86fd-4d43-8dee-c7f89d346941@app.fastmail.com> <20260323080848.GF814676@unreal> Subject: Re: [PATCH 2/3] RDMA/hfi1, rdmavt: open-code rvt_set_ibdev_name() Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, Mar 23, 2026, at 09:08, Leon Romanovsky wrote: > On Fri, Mar 20, 2026 at 04:53:04PM +0100, Arnd Bergmann wrote: >> On Fri, Mar 20, 2026, at 16:12, Arnd Bergmann wrote: >> >> > + */ >> > + ibdev = &dd->verbs_dev.rdi.ibdev; >> > + dev_set_name(&ibdev->dev, "%s_%d", class_name(), dd->unit); >> > + strscpy(&ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX); >> > + >> >> I messed this up during a rebase, that should have been >> >> strscpy(ibdev->name, dev_name(&ibdev->dev), IB_DEVICE_NAME_MAX); >> >> (without the extra &). I'll wait for comments before resending. > > The hfi1 driver is scheduled for removal. Dennis has already posted the > hfi2 driver, which serves as its replacement. Ok, that does sound like a sensible decision, and I'll just drop patches 1 and 3 then, which are just cleanups. The cover letter at [1] suggests that the two drivers will still coexist for a bit though, so I think we'd still want patch 2/3 in order to get a clean 'allmodconfig' build when the -Wmissing-format-attribute is enabled by defaultt. I have a couple of patches in flight. I took a quick look at the hfi2 driver, and noticed a few things that that may be worth addressing before it gets merged, mostly stuff copied from hfi1: - A few global functions with questionable namespacing: user_event_ack, ctxt_reset, iowait_init, register_pinning_interface, sc_{alloc,free,enable,disable}, pio_copy, acquire_hw_mutex, load_firmware, cap_mask. It would make sense to prefix all global identifiers with 'hfi2_', both out of principle, and to allow building hfi1 and hfi2 into an allyesconfig kernel without link failures. - The use of INFINIBAND_RDMAVT seems unnecessary: right now this is only used by hfi1, now shared with hfi2 but later to be exclusive to the latter. Since it is unlikely to ever be used by another driver again, this may be a good time to drop the abstraction again and integrate it all into hfi2, with the old version getting dropped along with hfi1. - The pio_copy() function is particularly slow since it uses the full-barrier version of writeq() in a tight loop, this should probably use __iowrite64_copy() etc to make it work better on arm64 and other architectures - The use of bitfields in drivers/infiniband/hw/hfi2/cport.h makes the structures nonportable especially for big-endian targets, if those describe device interfaces. Similarly the use of __packed attributes in the same file seems arbitrary and inconsistent, to the point where it is likely to cause more harm than it can help. E.g. in +struct ib_cc_table_entry_shadow { + u16 entry; /* shift:2, multiplier:14 */ +}; + > +struct ib_cc_table_attr_shadow { + u16 ccti_limit; /* max CCTI for cc table */ + struct ib_cc_table_entry_shadow ccti_entries[IB_CCT_ENTRIES]; +} __packed; the outer structure is unaligned while the inner one requires alignment. Arnd [1] https://lore.kernel.org/all/177325138778.57064.8330693913074464417.stgit@awdrv-04.cornelisnetworks.com/