From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F70813D4E8 for ; Fri, 2 Feb 2024 12:16:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706876196; cv=none; b=j09wqJEuxgIOqhpCiD84WHF59uMZtHhDMIcIHr3fdx4Caxeb2+pGHN6lZSVugTAlv6CyIDi98gojlVx3uGtG7LbtbPJa8QmEUlNG3DCQqRs5BaQOIjKsjxkq1V3M15ND+coULMRqNDFZxESz5vC/JD+oyGM5zCYAu5GkQYKjeRc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706876196; c=relaxed/simple; bh=vsCTrypPgQBUy+UjcZZL2T6JpKJkNjDRlOAk0xfL4jg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GQPxzOq8//HWOBecb9QFTkNuaBNtEV40Ic5/y6spfAlUgpIANlyk1i+Zw/te00+ifgkhRcIiY5pYxWiqrd9u+dEy15llXAmZ84+mNFoVi7IpKdnX/BVxleCbYRGNHjHcNIh0qL6I9+YwNKw3yV0qj+VtqIq/OcakD1SwyZNWg0Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=rNCFbgx3; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="rNCFbgx3" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6da4a923b1bso1364360b3a.2 for ; Fri, 02 Feb 2024 04:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1706876194; x=1707480994; darn=lists.linux.dev; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=3WrQlKWmTzgxXM9Xq7iWZ37ybL6PQV7GmW6fl32Nxz8=; b=rNCFbgx3i155KgM0TCjvbFtYQkjmSZOh/2PnkcD7vLCW8+6rY+KL+NAQYf6ze0Z3vi KpuUerTkMgq3aHEAGtbjJDyS4wnxN7mKuekuaXRH1iSRUqwlFwHz/Q9XYtMvaYpxhYsi pH84eb4MQlgclvwym14HS2FLgbK5jXvApOILJKl4sB4S2GXREbuW5U/NSgfdFxItaZ1f PGCxzL5bfmIcP6hef/1vXIeWm7ZtHqps/Wg6l1l0knlNi2iziaWsw4v4kfgSefXf+md3 xMnp/EvVp0OzH6csD0MUXpIkYxDkVJZ9JJiHhj80Xf9ep65IZwjmf9YctS6GaI50Mai2 tZQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706876194; x=1707480994; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3WrQlKWmTzgxXM9Xq7iWZ37ybL6PQV7GmW6fl32Nxz8=; b=P39q21pMoAeqJ02gf88dMmFf0ODyTJSurVNAXwDL01hTRM1Rxd5cYMIcjIyFom6mQQ 22IqhKUwd8cM8SgnOqVFHboo4HGBveIiKLnl6/NeRbhUBPPjJ2+RQRpCq7S4Nbrs7Mol 6M22oKYFQpojuQeylDE281ZQL5hxx0fkn2hEPGNB3Q+K9vHu6J+aC9FsCSAxT4g2vC/4 PU5SqT/8+eijL83O7vEPRrYfv6p7KqsWZHPk/+wUbUZpY+q+hh2D5HS2eXBIeG+UPQTh mJbaH5CM7FtgaUbZ71+kwoTXJhWDmWFQZZMNn1MMnrCyQac7UmaRe86BPVbjg9GFMIcF 6gsQ== X-Gm-Message-State: AOJu0YyGDrRk0lmIAs+7jmpcV4Coa5375Jcj+GS1nrlBYcX6WVu8ea6h CPuvMso9Q4psah9EcoT6uAP6jvkAkS0jQiY8QXJvl2yl90nlZ1bAeFIVMTrM4g== X-Google-Smtp-Source: AGHT+IFSwEV2m0Gdmgd6lEedpwK/MfSLND1vfenzThu++22xu2B5azEXkWVeQKf2qKJSz4JPkb0iug== X-Received: by 2002:a05:6a20:7d83:b0:19e:3c7f:cbbe with SMTP id v3-20020a056a207d8300b0019e3c7fcbbemr6479540pzj.9.1706876194527; Fri, 02 Feb 2024 04:16:34 -0800 (PST) X-Forwarded-Encrypted: i=0; AJvYcCWIbd9h/zN8zW55YNPgvoxkUt0iVLXCIPcM/ljKjrL3w8GQ/vvoo5s6qZJFJUuatnCU7xjeeTWtjCJ/+6TQew2LXihhqmXW6rmhgxOtd54sMqN9Tu9sJayCep52VVQM/7WlK+NkLmBy9lcoYgWqkKefIxYDPRsDbZg72ZQiE6Cp Received: from thinkpad ([120.56.198.122]) by smtp.gmail.com with ESMTPSA id b19-20020a63eb53000000b005cda7a1d72dsm1439531pgk.74.2024.02.02.04.16.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 04:16:34 -0800 (PST) Date: Fri, 2 Feb 2024 17:46:30 +0530 From: Manivannan Sadhasivam To: Baochen Qiang Cc: Kalle Valo , mhi@lists.linux.dev, ath11k@lists.infradead.org, linux-wireless@vger.kernel.org Subject: Re: [PATCH RFC v2 2/8] bus: mhi: host: add new interfaces to handle MHI channels directly Message-ID: <20240202121630.GC8020@thinkpad> References: <20231127162022.518834-1-kvalo@kernel.org> <20231127162022.518834-3-kvalo@kernel.org> <20240130181938.GB4218@thinkpad> <20240201100040.GB17027@thinkpad> <07668be1-8366-43b5-83ca-bf66d0d8087b@quicinc.com> <20240202071011.GA2961@thinkpad> <34e80f19-8804-4505-b134-f099e087b53e@quicinc.com> Precedence: bulk X-Mailing-List: mhi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <34e80f19-8804-4505-b134-f099e087b53e@quicinc.com> On Fri, Feb 02, 2024 at 06:49:19PM +0800, Baochen Qiang wrote: > > > On 2/2/2024 3:10 PM, Manivannan Sadhasivam wrote: > > On Fri, Feb 02, 2024 at 02:42:58PM +0800, Baochen Qiang wrote: > > > > > > > > > On 2/1/2024 6:00 PM, Manivannan Sadhasivam wrote: > > > > On Wed, Jan 31, 2024 at 03:39:26PM +0800, Baochen Qiang wrote: > > > > > > > > > > > > > > > On 1/31/2024 2:19 AM, Manivannan Sadhasivam wrote: > > > > > > On Mon, Nov 27, 2023 at 06:20:16PM +0200, Kalle Valo wrote: > > > > > > > From: Baochen Qiang > > > > > > > > > > > > > > When using mhi_power_down_no_destroy() MHI hosts need to unprepare MHI channels > > > > > > > by themselves. Similarly, MHI stack will also not create new MHI device since > > > > > > > old devices were not destroyed, so MHI hosts need to prepare channels as well. > > > > > > > Hence add these two interfaces to make that possible. > > > > > > > > > > > > > > Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 > > > > > > > > > > > > > > Signed-off-by: Baochen Qiang > > > > > > > Signed-off-by: Kalle Valo > > > > > > > --- > > > > > > > drivers/bus/mhi/host/main.c | 107 ++++++++++++++++++++++++++++++++++++ > > > > > > > include/linux/mhi.h | 20 ++++++- > > > > > > > 2 files changed, 126 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c > > > > > > > index d80975f4bba8..3f677fc628ad 100644 > > > > > > > --- a/drivers/bus/mhi/host/main.c > > > > > > > +++ b/drivers/bus/mhi/host/main.c > > > > > > > @@ -1669,6 +1669,58 @@ int mhi_prepare_for_transfer_autoqueue(struct mhi_device *mhi_dev) > > > > > > > } > > > > > > > EXPORT_SYMBOL_GPL(mhi_prepare_for_transfer_autoqueue); > > > > > > > +static int ____mhi_prepare_for_transfer(struct device *dev, void *data) > > > > > > > > > > > > "__mhi_prepare_all_for_transfer" > > > > > > > > > > This is to prepare one single child device, I don't think a name like > > > > > __mhi_prepare_all_for_transfer (with 'all' inside) make sense, right? > > > > > How about changing to "mhi_prepare_dev_for_transfer" or > > > > > "mhi_prepare_single_for_transfer"? > > > > > > > > > > > > > I think most of the checks in this function can be moved inside > > > > mhi_prepare_for_transfer() API. With that you can just reuse the API without > > > > adding a new helper. > > > > > > > > For autoqueue channels, you can add another API > > > > mhi_prepare_all_for_transfer_autoqueue() just like > > > > mhi_prepare_for_transfer_autoqueue() to maintain uniformity. > > > > > > > > - Mani > > > If we do that, we need to call two APIs together, does it make sense? From > > > the view of an MHI user, what we want is an API to prepare all channels, no > > > matter whether a channel is configured as autoqueue or non-autoqueue, we > > > don't care about it. > > > > > > > You are calling this API from a wrong place first up. > > mhi_{prepare/unprepare}_transfer* APIs are meant to be used by the client > > drivers like QRTR. Controller drivers should not call them. > > > > What you need here is the hibernation support for QRTR itself and call these > > APIs from there. > > OK, I got your point. QRTR is the right place to manage MHI channels, not > ath11k it self. > And we even don't need these two APIs if change to do it in QRTR. > > > > > > And besides, I don't think there is a scenario where we need to use them > > > separately. So if we always need to use them together, why not merge them in > > > a single API? > > > > > > > A single controller driver may expose multiple channels and those will bind to > > multiple client drivers. So only the client drivers should manage the channels, > > not the controller drivers themselves. > Exactly. > > Great thanks for the proposal, Mani. Will change accordingly in next > version. > And you can drop the RFC tag in the version. - Mani -- மணிவண்ணன் சதாசிவம்