Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38897C433F5 for ; Mon, 15 Nov 2021 10:21:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2432C61B39 for ; Mon, 15 Nov 2021 10:21:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237671AbhKOKYw (ORCPT ); Mon, 15 Nov 2021 05:24:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:52566 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237342AbhKOKYn (ORCPT ); Mon, 15 Nov 2021 05:24:43 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 7FD84630EF; Mon, 15 Nov 2021 10:21:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636971708; bh=ngAS50rMmpV59azjOqW2oXCBrEGHx6Ekm0yN36KEY7k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=oHFZaspA4e0JT2Bappei5MG7xUfxAKnXH43mnsdk+R7rbsdvrD3kUDLGpF994Lv8o iEcy1Ug+arpeVBA1gxKJr+XFzRMEEncjc2K9qzGu6o1iL3o1bXVBgArPKaXh3sM1KT pqByKGVIvlUsnVpeQARzzgb4qc9a17HQolmIyWVeIgrGPfLon8Wq7NbhnRmyj2zeoK 0Pg+gQgghuvRxMHQ7IajfS53HSxlou+O9e931O/rQqPebWyZ0jpnTj4gKlP7r3MKfQ +aPZLeOvA+8d8JqKBiRKzMCqrAk2Zb1jIIa11uVmY4fIYw/I+SHpBH5/oWpHirfE6z g6me8ygTpOC9g== Received: by mail-wr1-f46.google.com with SMTP id i5so29626340wrb.2; Mon, 15 Nov 2021 02:21:48 -0800 (PST) X-Gm-Message-State: AOAM5328cnFBJh5jxqbW8F8sqIOXUa0MI8BJ4l7FUZ3oMLmIUvAjEeYe T9dGB+//kTVPZnDtriBt1j1Qyq50lQ3BV48bGoY= X-Google-Smtp-Source: ABdhPJyrUjRCeMXfDabLLUXG4+a6meFiuvFYQKG804WvMbrQRiaBMGWgH0F0OdgqzdIGH+oZqJIqfFrTkkuSnIDyxB0= X-Received: by 2002:adf:df89:: with SMTP id z9mr45196660wrl.336.1636971706955; Mon, 15 Nov 2021 02:21:46 -0800 (PST) MIME-Version: 1.0 References: <20211115085403.360194-1-arnd@kernel.org> <20211115085403.360194-9-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 15 Nov 2021 11:21:30 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 08/11] dmaengine: xilinx_dpdma: stop using slave_id field To: Laurent Pinchart Cc: Vinod Koul , Arnd Bergmann , Andy Gross , Andy Shevchenko , Baolin Wang , Bjorn Andersson , Chunyan Zhang , Greg Kroah-Hartman , Hyun Kwon , Jaroslav Kysela , Jon Hunter , Lars-Peter Clausen , Laxman Dewangan , Manivannan Sadhasivam , Mark Brown , Michal Simek , Nicolas Saenz Julienne , Orson Zhai , Robert Jarzmik , Scott Branden , Takashi Iwai , Thierry Reding , ALSA Development Mailing List , bcm-kernel-feedback-list , dmaengine@vger.kernel.org, dri-devel , Linux ARM , linux-arm-msm , Linux Kernel Mailing List , linux-mmc , linux-mtd , "moderated list:BROADCOM BCM2835 ARM ARCHITECTURE" , "open list:SERIAL DRIVERS" , linux-spi , linux-staging@lists.linux.dev, "open list:TEGRA ARCHITECTURE SUPPORT" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 15, 2021 at 10:14 AM Laurent Pinchart wrote: > On Mon, Nov 15, 2021 at 09:54:00AM +0100, Arnd Bergmann wrote: > > @@ -1285,11 +1287,13 @@ static int xilinx_dpdma_config(struct dma_chan *dchan, > > spin_lock_irqsave(&chan->lock, flags); > > > > /* > > - * Abuse the slave_id to indicate that the channel is part of a video > > - * group. > > + * Abuse the peripheral_config to indicate that the channel is part > > Is it still an abuse, or is this now the right way to pass custom data > to the DMA engine driver ? It doesn't make the driver any more portable, but it's now being more explicit about it. As far as I can tell, this is the best way to pass data that cannot be expressed through the regular interfaces in DT and the dmaengine API. Ideally there would be a generic way to pass this flag, but I couldn't figure out what this is actually doing, or whether there is a better way. Maybe Vinod has an idea. I'll change s/Abuse/Use/ for the moment until I get a definite answer. > > + * of a video group. > > */ > > - if (chan->id <= ZYNQMP_DPDMA_VIDEO2) > > - chan->video_group = config->slave_id != 0; > > + pconfig = config->peripheral_config; > > This could be moved to the variable declaration above, up to you. I considered that but since it doesn't fit in a normal 80-column line, it seemed best to do it here. > > + if (chan->id <= ZYNQMP_DPDMA_VIDEO2 && > > + config->peripheral_size == sizeof(*pconfig)) > > Silently ignoring a size mismatch isn't nice. Could we validate the size > at the beginning of the function and return an error ? Yes, good idea. Since this would mean a bug in another driver, I'll add a WARN_ON() as well to make it clear which driver caused it. This is what I have now, let me know if you have any further suggestions: /* * Use the peripheral_config to indicate that the channel is part * of a video group. This requires matching use of the custom * structure in each driver. */ pconfig = config->peripheral_config; if (WARN_ON(config->peripheral_size != 0 && config->peripheral_size != sizeof(*pconfig))) return -EINVAL; spin_lock_irqsave(&chan->lock, flags); if (chan->id <= ZYNQMP_DPDMA_VIDEO2 && config->peripheral_size == sizeof(*pconfig)) chan->video_group = pconfig->video_group; spin_unlock_irqrestore(&chan->lock, flags); return 0; > With these issues addressed, > > Reviewed-by: Laurent Pinchart Thanks, Arnd