Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1573565pxb; Wed, 4 Nov 2020 12:37:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJwtyUDT7cC9eZMnANMcCjn9zQQBySMDgfV/qHEBQ8ydP5QpfAyCNMdc+mP76fgUy0Yp8v7Y X-Received: by 2002:a17:907:d1e:: with SMTP id gn30mr14547670ejc.148.1604522251682; Wed, 04 Nov 2020 12:37:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604522251; cv=none; d=google.com; s=arc-20160816; b=uu6PUXBlSFwsf2jeil7kogh4cg2YXl0RgoXzAMUlZM9ZBHQcRM87tWxJNygOK95m76 8N+GUN2SXm6apUwts8wMIq8aDbi1bgk5m2mteaMZpBYfr8O+rP/s51fc86CJSvb/PPU0 xCXeylMCzkQov2hxyhbIHnlWnEhPufV+mVifwS5hrzWy7WUCXqBgIn8RqAAR2KMbsXxQ NvJQv84ZcSPoIIoo5V4nMgPn/7AfYb+Hz5ZnvfblrPDuP/tDoZm/7MjLOHBA759cpOwP H+FZEvW+Nqf9d6Md3zEostc26A07tgJ6rdbw4SdneYieZis/MNHSJIfCnJ9EuDCbmvPd xfHA== 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=Z8gc6ARs/YzzuiIYGit2cDBKpxrUS5sAZ12IGbVfp4I=; b=eKsiLqxK/JiiGgpURfc3Ss1y6hHUXa5EcY/s1gMZJ3zUnlObJbfoqEPeCpeTguFJgj KCegUzLkFLrg7UhjD2xjqwHuKW35XqM+l5V8VmCJNoEqkV8yTYCvjHNR4brRBW00JzCt 5dW1gukiu1n8CikgSyPSoTZyNJ4uOctwgV7rGtmVbW6z1U9RPqkqiyTYuPrl3tccGqW9 OY5ManTtO1Lt8uZMyqiN04k/dCM0owHgF1QDEhwIMwoIGM88rQU6xBKd5F4Fown93WYX qzsFDDCW7mVStlAVt+Lswp/NO1OKVvRt+2wayo4Igt2IIcuaYN7Fz+tBAl9RzUsE6sDf 38gA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=mS9aIDQz; 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 oi22si2561000ejb.466.2020.11.04.12.37.09; Wed, 04 Nov 2020 12:37:31 -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=mS9aIDQz; 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 S1732328AbgKDSVu (ORCPT + 99 others); Wed, 4 Nov 2020 13:21:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730274AbgKDSVt (ORCPT ); Wed, 4 Nov 2020 13:21:49 -0500 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88B65C0613D3 for ; Wed, 4 Nov 2020 10:21:49 -0800 (PST) Received: by mail-pg1-x544.google.com with SMTP id i26so17266066pgl.5 for ; Wed, 04 Nov 2020 10:21:49 -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=Z8gc6ARs/YzzuiIYGit2cDBKpxrUS5sAZ12IGbVfp4I=; b=mS9aIDQz02BPksqMQmtfWq2bRIfqGdCcrb3TZ8qXpCcucwMkUkXsnRClnS4SlW9Bsc 7BJNnaw7i7WOANvIk6NmLJpreM9AlXCICLQDhtF6oWj40nunCVTsiVFQ2MgOsMgp0dZT e94ZVvvSWBcWyRqDjMdvS/B8S2znVU0A+7eShjWgu0NNLbWl5tSfmpYLB160GSEJvbBA Dd6HG7wOuW9ZYLK5A4EmSECwPyxgd4n3ZSqEmVE6IlntJ3LSBrFH+y3UNjHtCwyVV56p nJTniVE6YIbcOL1xuGB1GPwpo6+N2DWAUPigNRnLlvHkxU6NLjDdTy/JboMLapL3k/Z7 OVDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Z8gc6ARs/YzzuiIYGit2cDBKpxrUS5sAZ12IGbVfp4I=; b=XkZ9DfqOV7FcejstwJe7izS+U7dLBx2S7Ry+qzfHymbWIgVv/nAASS6762j8Yykj3y Kxdze/tkEetK+/kKA9zHk/YAnTnZBB2QyHswUeg4NtE1jhZntekJsV4ogiVwWHKP2FCu 1V0BzKBa4BFrkXNMyMa9/eX/Ohi7OAdQZe+cTE/CXmCcm5sXJJK+2iAuWh7QfKFB++QA 2jiQRlBRgUDTpZA/THgHoqSYn8/oOTlVJ6fUiC0jqjn7mdps1e7Zg9LNS3rvZyQSrxPE 7anVxEu7BHl+dsEFpNtF4jcfxZZeTQBnfnCf/KGltivFCF//SbGUia/gAUhE6sgqv6y/ f0Fg== X-Gm-Message-State: AOAM532RS4SzEqDjri8n8R8GnfLp4PNyodyshk1PDlkwaiIHAfm9D7bG hx5t+hVr4pyV1amQEkIRAQS4Nw== X-Received: by 2002:a63:4c51:: with SMTP id m17mr22137626pgl.270.1604514109032; Wed, 04 Nov 2020 10:21:49 -0800 (PST) Received: from xps15 (S0106002369de4dac.cg.shawcable.net. [68.147.8.254]) by smtp.gmail.com with ESMTPSA id u5sm2785866pjn.15.2020.11.04.10.21.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Nov 2020 10:21:48 -0800 (PST) Date: Wed, 4 Nov 2020 11:21:46 -0700 From: Mathieu Poirier To: Alexander Lobakin Cc: Amit Shah , Arnd Bergmann , Greg Kroah-Hartman , Arnaud Pouliquen , Suman Anna , Bjorn Andersson , Ohad Ben-Cohen , "Michael S. Tsirkin" , Jason Wang , virtualization@lists.linux-foundation.org, linux-remoteproc@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH virtio] virtio: virtio_console: fix DMA memory allocation for rproc serial Message-ID: <20201104182146.GC2893396@xps15> References: 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 On Wed, Nov 04, 2020 at 03:31:36PM +0000, Alexander Lobakin wrote: > Since commit 086d08725d34 ("remoteproc: create vdev subdevice with > specific dma memory pool"), every remoteproc has a DMA subdevice > ("remoteprocX#vdevYbuffer") for each virtio device, which inherits > DMA capabilities from the corresponding platform device. This allowed > to associate different DMA pools with each vdev, and required from > virtio drivers to perform DMA operations with the parent device > (vdev->dev.parent) instead of grandparent (vdev->dev.parent->parent). > > virtio_rpmsg_bus was already changed in the same merge cycle with > commit d999b622fcfb ("rpmsg: virtio: allocate buffer from parent"), > but virtio_console did not. In fact, operations using the grandparent > worked fine while the grandparent was the platform device, but since > commit c774ad010873 ("remoteproc: Fix and restore the parenting > hierarchy for vdev") this was changed, and now the grandparent device > is the remoteproc device without any DMA capabilities. > So, starting v5.8-rc1 the following warning is observed: > > [ 2.483925] ------------[ cut here ]------------ > [ 2.489148] WARNING: CPU: 3 PID: 101 at kernel/dma/mapping.c:427 0x80e7eee8 > [ 2.489152] Modules linked in: virtio_console(+) > [ 2.503737] virtio_rpmsg_bus rpmsg_core > [ 2.508903] > [ 2.528898] > [ 2.913043] > [ 2.914907] ---[ end trace 93ac8746beab612c ]--- > [ 2.920102] virtio-ports vport1p0: Error allocating inbufs > > kernel/dma/mapping.c:427 is: > > WARN_ON_ONCE(!dev->coherent_dma_mask); > > obviously because the grandparent now is remoteproc dev without any > DMA caps: You are correct. > > [ 3.104943] Parent: remoteproc0#vdev1buffer, grandparent: remoteproc0 > > Fix this the same way as it was for virtio_rpmsg_bus, using just the > parent device (vdev->dev.parent, "remoteprocX#vdevYbuffer") for DMA > operations. > This also allows now to reserve DMA pools/buffers for rproc serial > via Device Tree. > > Fixes: c774ad010873 ("remoteproc: Fix and restore the parenting hierarchy for vdev") > Cc: stable@vger.kernel.org # 5.1+ > Signed-off-by: Alexander Lobakin > --- > drivers/char/virtio_console.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c > index a2da8f768b94..1836cc56e357 100644 > --- a/drivers/char/virtio_console.c > +++ b/drivers/char/virtio_console.c > @@ -435,12 +435,12 @@ static struct port_buffer *alloc_buf(struct virtio_device *vdev, size_t buf_size > /* > * Allocate DMA memory from ancestor. When a virtio > * device is created by remoteproc, the DMA memory is > - * associated with the grandparent device: > - * vdev => rproc => platform-dev. > + * associated with the parent device: > + * virtioY => remoteprocX#vdevYbuffer. > */ > - if (!vdev->dev.parent || !vdev->dev.parent->parent) > + buf->dev = vdev->dev.parent; > + if (!buf->dev) > goto free_buf; > - buf->dev = vdev->dev.parent->parent; Reviewed-by: Mathieu Poirier > > /* Increase device refcnt to avoid freeing it */ > get_device(buf->dev); > -- > 2.29.2 > >