Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3792796pxu; Mon, 30 Nov 2020 10:19:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJwS1/zUW376U9kJoAm+0q9j+sdoyFi6nlnAGPglLeEzpxRmeQWUDCPk6tY7TkqHiTW92xFo X-Received: by 2002:aa7:d407:: with SMTP id z7mr23895770edq.234.1606760377111; Mon, 30 Nov 2020 10:19:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606760377; cv=none; d=google.com; s=arc-20160816; b=cN9WYB1qIvt+f+/yOzcqYdv+Ex3WwsmbRRqrBSNnBmfSZgO7w6P2gmC0cEEx9stok/ +UnJCodxJuURYq8b+Wnsfa2vF9T4jkmVjQsKPlkD53x5oueeWiYGWuNPiFKcy/R1R4uT KEfB7xxwkJz37oCoSSqUjOzkCWVKtjhPpZKr9qMicbVW5D3ZP8nef3icstGpaDpZfIVi k4hazSvoK2Df90LrKW5KiUnkL8iZ2dyjZ6XDkkBplVTEgDei5mRaqNW9SYX7I31i0bIc QnumzIX61WtykmtKUAWhoDplbc+Tn2f6ntLuTjVCCZhK/MHHxUipUZlne+auMWc3iHCO 4q0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=2AKXanvK88R+UrndJ2+lfJo0jOvZRiWePigHL5MOrpQ=; b=Vj2SVE2AwgyTuAlW+18CYgdGJl6YQI1HWOfcnsudWwyqEcQmLXNYKSGI753jqUKh2u RAM9iCwrg96rYteK9tydGijgJjtzUAkgo4UM6w5GQC1PL1sm3OVLDNdLZS/NXU07WH/v PxoTCxPXQbKX211F+ST8HMBfB+avaamjDB/ECpSX/rLskuu1EvS3PlBBt/S4Qp9d0E3U kPmtcIvnwBZ2julP2y1umdWPy/iFMZhbjc/VoWZLfATNWqscCAyXq+612VKeE+i9kT1P HH/wiOnScauypCAI5mHrFTlC1h2rRaW9LCWqsmoTQdZ27h4ly+t1heuDY/ZH+WcktZT4 9prw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=t+oYd2k8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id se15si10372822ejb.270.2020.11.30.10.19.13; Mon, 30 Nov 2020 10:19:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=t+oYd2k8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S2388046AbgK3SRM (ORCPT + 99 others); Mon, 30 Nov 2020 13:17:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728003AbgK3SRL (ORCPT ); Mon, 30 Nov 2020 13:17:11 -0500 Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEA14C0613CF for ; Mon, 30 Nov 2020 10:16:30 -0800 (PST) Received: by mail-ed1-x541.google.com with SMTP id v22so17418856edt.9 for ; Mon, 30 Nov 2020 10:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2AKXanvK88R+UrndJ2+lfJo0jOvZRiWePigHL5MOrpQ=; b=t+oYd2k8L4bXGdr4bOORSo2JgpR5uXWDVrx56F+4FY0EeuamLMDp1YW6JIH5sInuGT rTtQHZ+qSZjUS9YTu5LGYXDH/CwUXJuHgVdcM1yCQto3Ahh9igxg3+ITRIiOgHGpDCJj c59bFtLaWRLYYh2JDbgappg+NEZjyEZGr+/z2fboCh3SXTBDnK6syDMRhDLA8npvxTfS V3oMTCVXoi9kMmsNTD82DGqL12LHuXk0zgHJYWHzPXC9vdYyBpb1Y95Bzz0QCC4YZax1 A98oOIB+j1krv9rUn5NtvQXBe9iCccCHcTRWMmQJ+ekRgUtEBsEgOqN+oz2dVRGzJb46 R34w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2AKXanvK88R+UrndJ2+lfJo0jOvZRiWePigHL5MOrpQ=; b=bvgK5DWL/Rmtcg8p+bgSvnov3OGn3pEjj8r8q88X9hd2ra0FnBhQgK6yig0+r6opl9 Qm4mTqKizLqS9e/s67ckb0t8+CHIcZcROqDckBNLDTppioLEVI15SnyJWXndEK7dtGhH Q5Bu9LiJXdjxgdpTqBLH+y9dDuvhr051xrnD9HuIj2q1S49QCkyB67afxmVXj6ehEvhG /Fkmg49LTtDHXpCOVvmJrAYF9EfjWVjQODprWSkENG5RhK2pCaJFe7xVuk+DVmxh2XcU Vr981s1P+en2k4bOpJ/zr3Zt2v8KuP1liaugp7t5Uz4KTW6+Z1iZt1+IpnbeHkTjTsBP jiDw== X-Gm-Message-State: AOAM5308puQTU3quuu8w9pT8s9jTJXOl2q3Q3gLNjX3gXvUmizvaGS9b RRmuUhbHlMeVguSDtyRP42ujcfqmNon3068/kwuV+w== X-Received: by 2002:a05:6402:2373:: with SMTP id a19mr23118798eda.212.1606760189619; Mon, 30 Nov 2020 10:16:29 -0800 (PST) MIME-Version: 1.0 References: <1606533966-22821-1-git-send-email-hemantk@codeaurora.org> <1606533966-22821-5-git-send-email-hemantk@codeaurora.org> In-Reply-To: <1606533966-22821-5-git-send-email-hemantk@codeaurora.org> From: Loic Poulain Date: Mon, 30 Nov 2020 19:22:44 +0100 Message-ID: Subject: Re: [PATCH v13 4/4] bus: mhi: Add userspace client interface driver To: Hemant Kumar Cc: Manivannan Sadhasivam , Greg Kroah-Hartman , linux-arm-msm , open list , Jeffrey Hugo , Bhaumik Bhatt , Network Development Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 28 Nov 2020 at 04:26, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > raw data between MHI device and host using standard file operations. > Driver instantiates UCI device object which is associated to device > file node. UCI device object instantiates UCI channel object when device > file node is opened. UCI channel object is used to manage MHI channels > by calling MHI core APIs for read and write operations. MHI channels > are started as part of device open(). MHI channels remain in start > state until last release() is called on UCI device file node. Device > file node is created with format [...] > +struct uci_chan { > + struct uci_dev *udev; > + wait_queue_head_t ul_wq; > + > + /* ul channel lock to synchronize multiple writes */ > + struct mutex write_lock; > + > + wait_queue_head_t dl_wq; > + > + /* dl channel lock to synchronize multiple reads */ > + struct mutex read_lock; > + > + /* > + * protects pending list in bh context, channel release, read and > + * poll > + */ > + spinlock_t dl_pending_lock; > + > + struct list_head dl_pending; > + struct uci_buf *cur_buf; > + size_t dl_size; > + struct kref ref_count; > +}; [...] > + * struct uci_dev - MHI UCI device > + * @minor: UCI device node minor number > + * @mhi_dev: associated mhi device object > + * @uchan: UCI uplink and downlink channel object > + * @mtu: max TRE buffer length > + * @enabled: Flag to track the state of the UCI device > + * @lock: mutex lock to manage uchan object > + * @ref_count: uci_dev reference count > + */ > +struct uci_dev { > + unsigned int minor; > + struct mhi_device *mhi_dev; > + struct uci_chan *uchan; Why a pointer to uci_chan and not just plainly integrating the structure here, AFAIU uci_chan describes the channels and is just a subpart of uci_dev. That would reduce the number of dynamic allocations you manage and the extra kref. do you even need a separate structure for this? [...] > +static int mhi_uci_dev_start_chan(struct uci_dev *udev) > +{ > + int ret = 0; > + struct uci_chan *uchan; > + > + mutex_lock(&udev->lock); > + if (!udev->uchan || !kref_get_unless_zero(&udev->uchan->ref_count)) { This test is suspicious, kref_get_unless_zero should be enough to test, right? if (kref_get_unless_zero(&udev->ref)) goto skip_init; > + uchan = kzalloc(sizeof(*uchan), GFP_KERNEL); > + if (!uchan) { > + ret = -ENOMEM; > + goto error_chan_start; > + } > + > + udev->uchan = uchan; > + uchan->udev = udev; > + init_waitqueue_head(&uchan->ul_wq); > + init_waitqueue_head(&uchan->dl_wq); > + mutex_init(&uchan->write_lock); > + mutex_init(&uchan->read_lock); > + spin_lock_init(&uchan->dl_pending_lock); > + INIT_LIST_HEAD(&uchan->dl_pending); > + > + ret = mhi_prepare_for_transfer(udev->mhi_dev); > + if (ret) { > + dev_err(&udev->mhi_dev->dev, "Error starting transfer channels\n"); > + goto error_chan_cleanup; > + } > + > + ret = mhi_queue_inbound(udev); > + if (ret) > + goto error_chan_cleanup; > + > + kref_init(&uchan->ref_count); > + } > + > + mutex_unlock(&udev->lock); > + > + return 0; > + > +error_chan_cleanup: > + mhi_uci_dev_chan_release(&uchan->ref_count); > +error_chan_start: > + mutex_unlock(&udev->lock); > + return ret; > +} Regards, Loic