Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp7647802ybi; Wed, 5 Jun 2019 22:28:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwpo+AMU1tQjK3Sgaowdd0Pjcgh+hBYlhFyL5hemZbS67H3Q9Jxhrb8il5FQiMpelkvFf5t X-Received: by 2002:a17:902:42e2:: with SMTP id h89mr46968690pld.271.1559798905883; Wed, 05 Jun 2019 22:28:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559798905; cv=none; d=google.com; s=arc-20160816; b=OnmuV9U/Y2ROz2EoYjf0uA66uYn6wuY8Fm/Dz+TfEzGEVvG8YI7lgF75CrxUAfhmfm OAj3OmG2dP3PmRssZo8tq5uYcqR3KxYachW2d1U+sfR2KR1Fm7JoSkNMfI+ijF/b8vev OXdvlbXuddJ8pFzRJjAm94qQK4iJbu7om+kB+W6q0i8dJtE4S6mtqZS04OkW2IRdHyXn w6rvGnF/Bknl6uINYyP08T/3HYX8kyk/B1h8paM/fsFsz0E3uIy9MDjxIN9pyOv8emqL TNkb8qZiTI91aDc+yj4VzQAVlu0ytSeIRMXzSU93ybtJVKnH+OGsJ3mCO6IqNU65MipY KwrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Vet3rWA51CMnPKU0OwZ/zSGewScYG6Ll5Y6AZ+aj4o8=; b=yLXCfSR6nC/b1NLrTUf9x11Eojh+qIp3CnIL3vtsne1YhaONQJQmwlGyKRCaPjORLV Koh6mgXI2LXj4PJY+41t9pEhz2WSPHtQ8f3naatARET42/qEFdsGfiRhev/8vahVQl5G C9UQONufnMag/JcYq8QtJRvOkcghjmgz7W7tdPye+mlc9Du7KFfrxsTzbvtrYGeolNv5 117GBpPDHm/12RnIdpG3BNsu9SN6GtP9rI/Yo34RnZpTOZe2appiaJWqmAJWFvmvjJJ9 dFOAn+FVwI5Y0gmvxcZaY5H1fVWOHaGcp7AQE3Kimhscu3ejSMquaYiWZV8HOfeqWO96 rIdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NpMyBXef; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id e11si786778plb.407.2019.06.05.22.28.09; Wed, 05 Jun 2019 22:28:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NpMyBXef; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1726294AbfFFF1E (ORCPT + 99 others); Thu, 6 Jun 2019 01:27:04 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:40692 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725766AbfFFF1E (ORCPT ); Thu, 6 Jun 2019 01:27:04 -0400 Received: by mail-wr1-f66.google.com with SMTP id p11so941917wre.7 for ; Wed, 05 Jun 2019 22:27:03 -0700 (PDT) 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:content-transfer-encoding:in-reply-to :user-agent; bh=Vet3rWA51CMnPKU0OwZ/zSGewScYG6Ll5Y6AZ+aj4o8=; b=NpMyBXefRfQh6ZTPZQ1aIMSBBwQ5y+gMO11DDvjr9nTqAJnnJXEUsKgmSS0T0NSu2C ldlNxdQS/9ViW8gN+qwbD8IpcpBuVkOy7uArneX5FTmcjiPVMfmbc33VgZjsDzH0YRTZ beBl+xI1NyVdDHf1AEi5wPyOXCZ5DfHqHuNufvUhwl4+Zv/pYmKTHbWZ24SJpZynDPXY f2ETsur4YdsOIXRyIo24elHPQq9LYRJ34UmUl/0wIKFG5DA6Ni7//4LQkVeHn9dTwlu4 fE1xhyXSNtyJRDfo3zsrMKFVYkpHewi+LatCwwGklpXTa8vzIn9wbGEask8oV/+xzao6 VGSw== 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:content-transfer-encoding :in-reply-to:user-agent; bh=Vet3rWA51CMnPKU0OwZ/zSGewScYG6Ll5Y6AZ+aj4o8=; b=ZplKa0hxjnuz6LKuXbNcNVCQ+/vU58NrisjS/+sb8wnpE1ZyyM+L16Xqa45QqTFCVz d6sq7szlnaABVYb6G8vjV7WQExdxNbVWDqzs4jY+skzB06up+XvmHClNr5/D4tB8oSEF QBeb9AWpoT7DUDw2ulHlLpKBttWrPqCnVFOMinJItx0LEoISvc8zkoZld14TPltQDGFl rUES23kDo6o6FHPzSpZaeaqKiU7WxgALInDKbMq4BmRKFBdf72l2megIJtGpxiaoz70D gW27TpuHCruMGymRsUf2HhJhMhMf/HM+wA4oE2//hpfOz2TC82UQKBXTzUCjy8mo0w6X E28A== X-Gm-Message-State: APjAAAXlgJFnkazLA36IYs9xj/LLWnluJmqTNrEPG7uMNCmp7s8tThoY RmLm/dOJOosuUp7QNzcBOMVz1yEpQS4= X-Received: by 2002:adf:f050:: with SMTP id t16mr13031877wro.99.1559798822395; Wed, 05 Jun 2019 22:27:02 -0700 (PDT) Received: from dell ([2.31.167.229]) by smtp.gmail.com with ESMTPSA id f2sm778088wru.31.2019.06.05.22.27.01 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Jun 2019 22:27:01 -0700 (PDT) Date: Thu, 6 Jun 2019 06:27:00 +0100 From: Lee Jones To: Robert Hancock Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mfd: core: Support multiple OF child devices of the same type Message-ID: <20190606052700.GZ4797@dell> References: <1559687743-31879-1-git-send-email-hancock@sedsystems.ca> <1559687743-31879-2-git-send-email-hancock@sedsystems.ca> <20190605063108.GF4797@dell> <7561b2af-52b4-af78-f854-00ba0b86c822@sedsystems.ca> <20190605184505.GT4797@dell> <3a961f58-05d0-95ab-95e1-6d336336193c@sedsystems.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3a961f58-05d0-95ab-95e1-6d336336193c@sedsystems.ca> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 05 Jun 2019, Robert Hancock wrote: > On 2019-06-05 12:45 p.m., Lee Jones wrote: > >>>> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h > >>>> index 99c0395..470f6cb 100644 > >>>> --- a/include/linux/mfd/core.h > >>>> +++ b/include/linux/mfd/core.h > >>>> @@ -55,6 +55,9 @@ struct mfd_cell { > >>>> */ > >>>> const char *of_compatible; > >>>> > >>>> + /* Optionally match against a specific device of a given type */ > >>>> + const char *of_full_name; > >>>> + > >>> > >>> Can you give me an example for when this might be useful? > >> > >> This is an example of some device tree entries for our MFD device: > >> > >> axi_iic_0: i2c@c0000 { > >> compatible = "xlnx,xps-iic-2.00.a"; > >> clocks = <&axi_clk>; > >> clock-frequency = <100000>; > >> interrupts = <7>; > >> #size-cells = <0>; > >> #address-cells = <1>; > >> }; > >> > >> axi_iic_1: i2c@d0000 { > >> compatible = "xlnx,xps-iic-2.00.a"; > >> clocks = <&axi_clk>; > >> clock-frequency = <100000>; > >> interrupts = <8>; > >> #size-cells = <0>; > >> #address-cells = <1>; > >> }; > >> > >> and the corresponding MFD cells: > >> > >> { > >> .name = "axi_iic_0", > >> .of_compatible = "xlnx,xps-iic-2.00.a", > >> .of_full_name = "i2c@c0000", > >> .num_resources = ARRAY_SIZE(dbe_i2c1_resources), > >> .resources = dbe_i2c1_resources > >> }, > >> { > >> .name = "axi_iic_1", > >> .of_compatible = "xlnx,xps-iic-2.00.a", > >> .of_full_name = "i2c@d0000", > >> .num_resources = ARRAY_SIZE(dbe_i2c2_resources), > >> .resources = dbe_i2c2_resources > >> }, > >> > >> Without having the .of_full_name support, both MFD cells ended up > >> wrongly matching against the i2c@c0000 device tree node since we just > >> picked the first one where of_compatible matched. > > > > What is contained in each of their resources? > > These are the resource entries for those two devices: > > static const struct resource dbe_i2c1_resources[] = { > { > .start = 0xc0000, > .end = 0xcffff, > .name = "xi2c1_regs", > .flags = IORESOURCE_MEM, > .desc = IORES_DESC_NONE > }, > }; > > static const struct resource dbe_i2c2_resources[] = { > { > .start = 0xd0000, > .end = 0xdffff, > .name = "xi2c2_regs", > .flags = IORESOURCE_MEM, > .desc = IORES_DESC_NONE > }, > }; This is your problem. You are providing the memory resources through *both* DT and MFD. I don't believe I've seen your MFD driver, but it looks like it's probably not required at all. Just allow DT to probe each of your child devices. You can obtain the IO memory from there directly using the usual platform_get_resource() calls. > Ideally the IO memory resource entries would be picked up and mapped > through the device tree as well, as they are with the interrupts, but I > haven't yet found the device tree magic that would allow that to happen > yet, if it's possible. The setup we have has a number of peripherals on > an AXI bus which are behind a PCIe to AXI bridge, and we're using mfd to > instantiate each of those AXI devices under the PCIe device. > -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog