From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752203AbdGVGs4 (ORCPT <rfc822;w@1wt.eu>);
        Sat, 22 Jul 2017 02:48:56 -0400
Received: from mga01.intel.com ([192.55.52.88]:31997 "EHLO mga01.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750989AbdGVGsy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 22 Jul 2017 02:48:54 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.40,394,1496127600"; 
   d="scan'208";a="1154104817"
Date: Sat, 22 Jul 2017 12:21:33 +0530
From: Vinod Koul <vinod.koul@intel.com>
To: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Cc: Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>,
        Alexandre Torgue <alexandre.torgue@st.com>,
        Russell King <linux@armlinux.org.uk>,
        Dan Williams <dan.j.williams@intel.com>,
        "M'boumba Cedric Madianga" <cedric.madianga@gmail.com>,
        Fabrice GASNIER <fabrice.gasnier@st.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Fabien DESSENNE <fabien.dessenne@st.com>,
        Amelie Delaunay <amelie.delaunay@st.com>, dmaengine@vger.kernel.org,
        devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/5] dmaengine: Add STM32 DMAMUX driver
Message-ID: <20170722065133.GT3053@localhost>
References: <1499343623-5964-1-git-send-email-pierre-yves.mordret@st.com>
 <1499343623-5964-3-git-send-email-pierre-yves.mordret@st.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1499343623-5964-3-git-send-email-pierre-yves.mordret@st.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jul 06, 2017 at 02:20:20PM +0200, Pierre-Yves MORDRET wrote:
> +static int stm32_dmamux_probe(struct platform_device *pdev)
> +{
> +	struct device_node *node = pdev->dev.of_node;
> +	struct device_node *dma_node;
> +	struct stm32_dmamux_data *stm32_dmamux;
> +	struct resource *res;
> +	void __iomem *iomem;
> +	int i, ret;
> +
> +	if (!node)
> +		return -ENODEV;
> +
> +	stm32_dmamux = devm_kzalloc(&pdev->dev, sizeof(*stm32_dmamux),
> +				    GFP_KERNEL);
> +	if (!stm32_dmamux)
> +		return -ENOMEM;
> +
> +	dma_node = of_parse_phandle(node, "dma-masters", 0);
> +	if (!dma_node) {
> +		dev_err(&pdev->dev, "Can't get DMA master node\n");
> +		return -ENODEV;
> +	}
> +
> +	if (device_property_read_u32(&pdev->dev, "dma-channels",
> +				     &stm32_dmamux->dmamux_channels))
> +		stm32_dmamux->dmamux_channels = STM32_DMAMUX_MAX_CHANNELS;
> +
> +	if (device_property_read_u32(&pdev->dev, "dma-requests",
> +				     &stm32_dmamux->dmamux_requests))
> +		stm32_dmamux->dmamux_requests = STM32_DMAMUX_MAX_REQUESTS;

I think defaults should be warned here too

> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res)
> +		return -ENODEV;
> +
> +	iomem = devm_ioremap_resource(&pdev->dev, res);
> +	if (!iomem)
> +		return -ENOMEM;
> +
> +	spin_lock_init(&stm32_dmamux->lock);
> +
> +	stm32_dmamux->clk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(stm32_dmamux->clk)) {
> +		dev_info(&pdev->dev, "Missing controller clock\n");

Can you check for EPROBE_DEFER and print only for if that is not the error
otherwise we end up sapmming with defered probe issues

> +
> +#ifndef __DMA_STM32_DMAMUX_H
> +#define __DMA_STM32_DMAMUX_H
> +
> +#if defined(CONFIG_STM32_DMAMUX)
> +int stm32_dmamux_set_config(struct device *dev, void *route_data, u32 chan_id);

Why do we need a custom API in this case?

-- 
~Vinod