Received: by 2002:a05:6358:111d:b0:dc:6189:e246 with SMTP id f29csp713958rwi; Wed, 2 Nov 2022 17:38:50 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6Qbu4ZWFKj+80lheSTKoNnC3EJS0XH3Xc5xlT3+S6Nt4XXp5S7RrvTh5JZKZjt7Ff34Vdc X-Received: by 2002:a17:906:8a7b:b0:7ac:baef:6de1 with SMTP id hy27-20020a1709068a7b00b007acbaef6de1mr26555134ejc.734.1667435930335; Wed, 02 Nov 2022 17:38:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667435930; cv=none; d=google.com; s=arc-20160816; b=iiuNl5mO7u5JQTjFZc5R1q8L/Tu1KstbVAZr4HvMLCAezcVqAMlTRngeayKjyy+oQY z0x99bSU/aSEkKonHtWSrzPWt2VFBUNZM7nK/EiRoN3MHkKJ2br9JMO4CZNLdHUV56oC Pvyqnqd8+1+znFfGRTc8MuCzBPOW6+cUtjeyEaxxZwmUaZaH1YkZ00eJsj9cdoFeaKmC WS5Yp6+KhEfA2XMML5yNiBXpCidaKj7+dstXTK5w/dDJjs7TemtaEB8A08Go5sFSi0GM 7XKgCnNqh0dUY+MsOwCbpp0js0AWPWbuu4xaP4GmmQFufDex1RxQUkN9TijxO017yEnE 5swA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=7UkoDbHI597GDjRPkvUtAFnl0OIH+592S9/loIK/Tnk=; b=FU4EyGeMudCAGoARk6EHDQ7pCbVG8XKNipuvQ6GqaTSl7C1pQzsAqbfFXyYd6S1XK/ Cc4s4mZhusHQMqTiHBD4YRShbxPi9rp5iWtQeLTEV9wItjkwtZeBXL0qbbL9H+vQsLZH rTw0F/KL3Ep9hNm1hbBxOIQxvyKk4xka+zkilaX+TiEnq1dWlHFSRuECUd0EWnSbaCa8 uxeS20X+NdMFZUHQy5BiiHQQcv+uG+ezLFfr1SWNOE2AS7KOE0mBGFi9U5+iYc5lAkph xiPDhO2blDDWkJk+m7ZdqBAcAHZq3BQENZHhSY1ig/P403GHLYLC6u84uHloyjfcuP1m PMdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oBWSsDcX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u11-20020a50eacb000000b0044e8fe826a0si15667958edp.156.2022.11.02.17.38.26; Wed, 02 Nov 2022 17:38:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=oBWSsDcX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230499AbiKCAWI (ORCPT + 97 others); Wed, 2 Nov 2022 20:22:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229950AbiKCAWH (ORCPT ); Wed, 2 Nov 2022 20:22:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E727AE6B; Wed, 2 Nov 2022 17:22:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 32F00B8257E; Thu, 3 Nov 2022 00:22:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24A9EC433D6; Thu, 3 Nov 2022 00:22:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1667434923; bh=NwgGWuXDoJ/N2xA4iOMxJoFQXwgYWNNpaY65FQ6JJys=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oBWSsDcXybP1tP3PQGxE/ItyJlvLU6be32w5TRFltAz0EjEhRGzGlRXRZLH39jRIq uQAsFTzJjStXbCs9L/kx9c5Awp3oDaIX4gH1ZsSUsWJgdhhm+ICQVlEhjMzRz90qdi Q2TQidYGWS9VjJ49c94tR6chUmeX1/lrD7VtlHwQ= Date: Thu, 3 Nov 2022 01:22:59 +0100 From: Greg Kroah-Hartman To: Elliot Berman Cc: Jassi Brar , Bjorn Andersson , Murali Nalajala , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Prakruthi Deepak Heragu , Andy Gross , Dmitry Baryshkov , linux-arm-kernel@lists.infradead.org, Mark Rutland , Lorenzo Pieralisi , Sudeep Holla , Marc Zyngier , Rob Herring , Krzysztof Kozlowski , Jonathan Corbet , Will Deacon , Catalin Marinas , Arnd Bergmann , Srinivas Kandagatla , Amol Maheshwari , Kalle Valo , devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 10/21] gunyah: rsc_mgr: Add resource manager RPC core Message-ID: References: <20221026185846.3983888-1-quic_eberman@quicinc.com> <20221026185846.3983888-11-quic_eberman@quicinc.com> <3d2858fe-ea3e-159c-faff-5052cba1e08c@quicinc.com> <28eaa4bd-a9ee-c415-57c4-a9a56ffeef18@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28eaa4bd-a9ee-c415-57c4-a9a56ffeef18@quicinc.com> X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 02, 2022 at 11:04:45AM -0700, Elliot Berman wrote: > > > > > +/* Resource Manager Header */ > > > > > +struct gh_rm_rpc_hdr { > > > > > + u8 version : 4, hdr_words : 4; > > > > > + u8 type : 2, fragments : 6; > > > > > > > > Ick, that's hard to read. One variable per line please? > > > > > > Ack. > > > > > > > And why the bit packed stuff? Are you sure this is the way to do this? > > > > Why not use a bitmask instead? > > > > > > > > > > I felt bit packed implementation is cleaner and easier to map to > > > understanding what the fields are used for. > > > > Ah, so this isn't what is on the "wire", then don't use a bitfield like > > this, use a real variable and that will be faster and simpler to > > understand. > > > > This is what's on the "wire". Whether I use bitfield or bit packed would be > functionally the same and is just a cosmetic change IMO. Ah, that wasn't obvious at all. Usually using bitfields like this for "wire" protocols is not a good idea (endian issues and all of that.) Please use a bitmask instead, as that way you know exactly what is happening, and the compiler can usually generate much better code overall. And as this is on the wire, please specify the endian values, _AND_ use the proper kernel types for stuff that goes between user/kernel or kernel/hardware, as you are not doing that here. thanks, greg k-h