Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp196402pxb; Mon, 7 Feb 2022 09:11:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJxb149s5k2TRhugaDkKKeAPgUjvkP4hQqmkl/BwMtRgz/JTb1ys8ADU8XN8zp9j3tmcFMbB X-Received: by 2002:a63:2158:: with SMTP id s24mr316498pgm.190.1644253891852; Mon, 07 Feb 2022 09:11:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644253891; cv=none; d=google.com; s=arc-20160816; b=P/XE3TOjkpWce+UGwbb55Iafi/ZO/AM4nY6WSPLOB+6UvRK5o6i/9g6ix+hGYRstk6 cUVbVF3QUudeG1W0xPkvTQTodqjJdoTORITeKfib9fes3HnQB1WKP/I4e/ulAChynFOQ N2cyheejPoJni9ypYPaUV60oRxkow+y6DIi3NZBXFJ/ki4pknbUTo2AIMLmCz+mp0pPw Ld/QB+L4koJOuE9pLAjYSXJTmRgA1sEXVYabX0woWRrC5Z7v1LLQZsk4a/746JwfY7HE oB4GQRmUAhhxF3NAMyRpn9UgM7HuNIEhzX7oQwwzlLHgZQq4d99ashbWEJVI//HC3aha 2kiw== 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=pDySLD49Od9ppT5fF1VG9msX8bYroKjD1B55FHPH58o=; b=KkaJfZd78JyJSZsbUU/Spv23uY/9pUDZukkLglDTNGmrIZOXv72I58g9uCYfTdYPeK Bv8KG2hEVCYJZE2AYh+az/4pNjU13KeZsumEW218qvBTuSZuiTOnQkCCk0zV33NnhOeb UGzfPp8jZrldkBe5r0Hr0260gttuz8cNyv1cYHEyd4FhoPK4aOLQZFpaptkkN8mo9dGT Rey9cAzwmgXqBb0Afn6quVOsmGifIeLwwv/Hw5sX9BdMB1PktmhXJfQ9dXIo64RecRHs lZHzamWVAsWQqeXRekBhQFBcheTN3kPoDtu+NBIMMYCYByzIZIftGQEiRfhhJTyD3inC v7hQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Ry0lEsVB; 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=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l11si11134539plg.151.2022.02.07.09.11.17; Mon, 07 Feb 2022 09:11:31 -0800 (PST) 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=@linaro.org header.s=google header.b=Ry0lEsVB; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245648AbiBCK31 (ORCPT + 99 others); Thu, 3 Feb 2022 05:29:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59478 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243133AbiBCK30 (ORCPT ); Thu, 3 Feb 2022 05:29:26 -0500 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D012C06173B for ; Thu, 3 Feb 2022 02:29:25 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id l13so1761621plg.9 for ; Thu, 03 Feb 2022 02:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=pDySLD49Od9ppT5fF1VG9msX8bYroKjD1B55FHPH58o=; b=Ry0lEsVBCpgcS1blKtvJPs+19daf+8Hwxusy8ZKY7MmPiUk2SgCkkAez2CnxJPShgP i3CSAUEN4gh48bw/c5TYBsPzmHPPkQFMqx17rweN5l01thiDWgFhEAwElqYqN8Xluzm4 LP0lY366cYHR8x81YoetishaETS9BYdEZGGI14uYvSaryTZQXwaAh32a4rp4letWaUb1 o9CA3ntDuR2WxidEpq5m7o0nccgFceT0si0eUJvCGI26SdMdkYyCNypS2o7rk0hf3h8H 8RE2+GEs2Na+7hhGmmv6CgXkoG1x+1GgM6LPB7+cPxp/fbb7GsgUjrMVf6MGnEJhoO8v G2rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=pDySLD49Od9ppT5fF1VG9msX8bYroKjD1B55FHPH58o=; b=AU35kcxl8aDVOo1tA10c7MXjJ5f/gM0A3n8wzLDK0bJVIa2Ou47f/jxFmt785sN39s yfzlYMiGjsjF6q6jbJZhZRhjmD9MfpHGSLS6PUza8sav6sJwLrT1c6ZHkMzUU/Fw5Q2s GF3nJYfu8JwQBTZ8DpRxmV5tEpgPIDReSBF8jlW0vfwOAkVFZOmZBsZM6/acjiIv5UYB B1PbE+euEQewtPPUgyvm6jlwTlR43HI3/sT9okliBxvpvn8aGu5jfglsbnLCqO2L7hZd IPV/mXmtWhJ6WV3VfnWQ9lQqtgSVxyxWIHpxKHtfSiY3rmnOSFI0fs+bTfDCtBecxm9P XZcA== X-Gm-Message-State: AOAM532xko+UySMTfkKj5TSO5A3bQtdzAL7UmG0b5yhFiKIKVD1fBvR2 /1wOAqg5qUbr0VZr0Q/grUtK X-Received: by 2002:a17:90b:3ece:: with SMTP id rm14mr8882107pjb.220.1643884164685; Thu, 03 Feb 2022 02:29:24 -0800 (PST) Received: from thinkpad ([117.217.179.179]) by smtp.gmail.com with ESMTPSA id l13sm36476955pgs.16.2022.02.03.02.29.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 02:29:23 -0800 (PST) Date: Thu, 3 Feb 2022 15:59:17 +0530 From: Manivannan Sadhasivam To: Alex Elder Cc: mhi@lists.linux.dev, hemantk@codeaurora.org, bbhatt@codeaurora.org, quic_jhugo@quicinc.com, vinod.koul@linaro.org, bjorn.andersson@linaro.org, dmitry.baryshkov@linaro.org, skananth@codeaurora.org, vpernami@codeaurora.org, vbadigan@codeaurora.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 02/20] bus: mhi: Move common MHI definitions out of host directory Message-ID: <20220203102917.GA6298@thinkpad> References: <20211202113553.238011-1-manivannan.sadhasivam@linaro.org> <20211202113553.238011-3-manivannan.sadhasivam@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Alex, Thanks a lot for the inputs. I've incorporated a portion of your suggestions and kept remaining ones post upstream. On Wed, Jan 05, 2022 at 06:22:25PM -0600, Alex Elder wrote: > On 12/2/21 5:35 AM, Manivannan Sadhasivam wrote: > > Move the common MHI definitions in host "internal.h" to "common.h" so > > that the endpoint code can make use of them. This also avoids > > duplicating the definitions in the endpoint stack. > > > > Still, the MHI register definitions are not moved since the offsets > > vary between host and endpoint. > > > > Signed-off-by: Manivannan Sadhasivam > > --- > > drivers/bus/mhi/common.h | 182 ++++++++++++++++++++++++++++++++ > > drivers/bus/mhi/host/internal.h | 154 +-------------------------- > > 2 files changed, 183 insertions(+), 153 deletions(-) > > create mode 100644 drivers/bus/mhi/common.h > > [...] > > + > > +#define EV_CTX_RESERVED_MASK GENMASK(7, 0) > > +#define EV_CTX_INTMODC_MASK GENMASK(15, 8) > > +#define EV_CTX_INTMODC_SHIFT 8 > > +#define EV_CTX_INTMODT_MASK GENMASK(31, 16) > > +#define EV_CTX_INTMODT_SHIFT 16 > > +struct mhi_event_ctxt { > > These fields should all be explicitly marked as little endian. > It so happens Intel and ARM use that, but defining them as > simple unsigned values is not correct for an external interface. > > This comment applies to the command and channel context structures > also. > Ack > > + __u32 intmod; > > + __u32 ertype; > > + __u32 msivec; > > + > > I think you can just define the entire struct as __packed > and __aligned(4) rather than defining all of these fields > with those attributes. > This was suggested by Arnd during the MHI host review. He preferred adding the aligned parameter only for members that require them. > > + __u64 rbase __packed __aligned(4); > > + __u64 rlen __packed __aligned(4); > > + __u64 rp __packed __aligned(4); > > + __u64 wp __packed __aligned(4); > > +}; > > + > > +#define CHAN_CTX_CHSTATE_MASK GENMASK(7, 0) > > +#define CHAN_CTX_CHSTATE_SHIFT 0 > > Please eliminate all the _SHIFT definitions like this, > where you are already defining the corresponding _MASK. > The _SHIFT is redundant (and could lead to error, and > takes up extra space). > > You are using bitfield operations (like FIELD_GET()) in > at least some places already. Use them consistently > throughout the driver. Those macros simplify the code > and obviate the need for any shift definitions. > Ack. Thanks, Mani