From mboxrd@z Thu Jan 1 00:00:00 1970 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E16DBC433F5 for ; Thu, 10 Mar 2022 06:22:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236131AbiCJGXx (ORCPT ); Thu, 10 Mar 2022 01:23:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239758AbiCJGXv (ORCPT ); Thu, 10 Mar 2022 01:23:51 -0500 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D50155BD5 for ; Wed, 9 Mar 2022 22:22:51 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id e2so3982753pls.10 for ; Wed, 09 Mar 2022 22:22:51 -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=dj3Da4QhbJDmhrY8mSKQqYTUZVJxjA5itzJkwxjbVvc=; b=bco7wNeVdItOHRyMV/9kQklokd8pyaVi4D5UcIAJXykHgePKLX7vSB+w/Ou7HLGUcN GWzkVQGi2JMldobJXkNDPyqJXGPbePpZtSUZow7wPbhJt6DGdgBodrHtJeuZwca/ZMg3 qqIlsjzSYRezLrG+HVDyyyd5gI74vvvzAmH22eqGQAnpoRaCDG822CEdwsHJ3jPIM0mT 1KUJROb0EpkLfI3NgCYHoVze34B3cfCJjDwbkZdSsh6iANCOrTSIrDw+uNX6YIKOG/AZ vGkK8V7exH6D5Fid1frJeLIbeOpZTqebp6FFFbU2VZOipU6EqP0nF6DLbqvCZdObJH71 O9AQ== 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=dj3Da4QhbJDmhrY8mSKQqYTUZVJxjA5itzJkwxjbVvc=; b=EZdsWQ+5oOk567MFMpb8datmyZZq4M/AL9jX6xR6TCcTaByDd91dAM5rnFBkPTH+dd QyJq81WEkpG/ucfyBuqP3vW3+bsCgbCUxLhyuFbZBlpSgtr8JmTc/jIHvkeAC/vp1JtI Ql+VwILkGg6OJ6X/fUd9uQ8vo1DmEvoiF4rIz7Bxpgy1fNyBEvTVnQDu29QdPoMETk2A pEJg2rw92xJQcZba+uSX9lKhuNhecC5+o40Zrwbr3r8+irBEZfCEHm2afNeBkdYT9UfJ 6tFYut9QfUSfCf7cu7P5CXqsOThhC7EM2EIJdJgiNMWw+20l9R9WGGuTBUwmIn7uwc9y XH8A== X-Gm-Message-State: AOAM531UQ8k8/RTUadq+Sm5EWoH8YJF0OUfTUcMnPbntjuf36DgQIAMd hyUv+YBd74KFODDXo7cgjyNf X-Google-Smtp-Source: ABdhPJxDHyzHli8Jhs+yCEcE4GMsLd+yFXyYIKOWUKjEjMCfZ/IZyUVZBKx3X5A5+KFOS592SfQ41w== X-Received: by 2002:a17:90b:384b:b0:1bf:12d8:62c0 with SMTP id nl11-20020a17090b384b00b001bf12d862c0mr14574030pjb.142.1646893370373; Wed, 09 Mar 2022 22:22:50 -0800 (PST) Received: from thinkpad ([117.193.208.22]) by smtp.gmail.com with ESMTPSA id i192-20020a636dc9000000b0037c7149fb0asm4425473pgc.89.2022.03.09.22.22.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Mar 2022 22:22:49 -0800 (PST) Date: Thu, 10 Mar 2022 11:52:42 +0530 From: Manivannan Sadhasivam To: Serge Semin Cc: Frank Li , Serge Semin , gustavo.pimentel@synopsys.com, hongxing.zhu@nxp.com, l.stach@pengutronix.de, linux-imx@nxp.com, linux-pci@vger.kernel.org, dmaengine@vger.kernel.org, lznuaa@gmail.com, vkoul@kernel.org, lorenzo.pieralisi@arm.com, robh@kernel.org, kw@linux.com, bhelgaas@google.com, shawnguo@kernel.org Subject: Re: [PATCH v3 1/6] dmaengine: dw-edma: fix dw_edma_probe() can't be call globally Message-ID: <20220310062242.GB4869@thinkpad> References: <20220307224750.18055-1-Frank.Li@nxp.com> <20220309133940.3le2ma24aqlhips4@mobilestation> <20220309181233.GC134091@thinkpad> <20220309190123.dnivojpqhl52o5vc@mobilestation> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220309190123.dnivojpqhl52o5vc@mobilestation> Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Wed, Mar 09, 2022 at 10:01:23PM +0300, Serge Semin wrote: [...] > > I'm afraid that this will not work for all cases (unless I miss something). As > > Zhi Li pointed out, there are places where only chip pointer will be passed and > > we'd need to extract the private data (dw_edma) from it. > > > > Tbh I also considered your idea but because of the above mentioned issue and > > also referring to other implementations like gpiochip, I settled with Frank's > > idea of copying the fields. > > What places are these? I see the only obstacle is the dw_edma_remove() > method. But it's easily fixable. Yeah, right. I overlooked that part. > Except that, everything else is more > or less straightforward (just a few methods need to have prototypes > converted to accepting dw_edma instead dw_edma_chip). > > In order to make the code design more coherent, we need to split up > private data and device/platform info. As I see it dw_edma_chip is > nothing but a chip info data. The eDMA driver is supposed to mainly > use and pass it's private data, not the platform info. It will greatly > improve the code readability and maintainability. Such approach will > also prevent a temptation of adding new private data fields into the > dw_edma_chip structure since reaching the pointer to dw_edma will be > much easier that getting the dw_edma_chip data. In this case > dw_edma_chip will be something like i2c_board_info in i2c. > > Ideally dw_edma_chip could be a temporarily defined device info, which > memory after the dw_edma_probe() method invocation could be freed. But > in order to implement that we'd need a bit more modifications > introduced. > While at it, we should also consider adding an ops structure for passing the callbacks from controller drivers. Currently the eDMA driver has the callbacks defined in v0-core.c but it is used directly instead of as a callback. This should anyway needs to be fixed when another version of the IP get's added. Thanks, Mani