Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6280723yba; Tue, 14 May 2019 05:06:50 -0700 (PDT) X-Google-Smtp-Source: APXvYqxABcxSbKTdMW5gG9bvPzL47uTl5gwcxXt140iYqODbfpKGRPbnQCiiroZnHhhIsgJSj0fs X-Received: by 2002:aa7:9356:: with SMTP id 22mr39541737pfn.188.1557835610027; Tue, 14 May 2019 05:06:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557835610; cv=none; d=google.com; s=arc-20160816; b=HUDhj8BykfkXlFpb0/w0OEodxjIgwIt5f0uH2HrRrfMKkAS73lwT0UI7+yc/gl4/Ds ZDGS3GsTtMPa41plwoDtj3KB37npsJeYj7Z7TcOZ3eqIFLry5oNnSg0WN3WtR8ln/ADG wosvZSu483qogz1UoSjRn/UENOGlbtXnxozJexZnwdPvuXT532fynoD0EvKGgh3rKETV a9fNTKvLlBuH/VORFJWLiJikv/eyFlWtKp/NdAtdG8hhe7DhRsKL1tEKniTzbzgLkNXt +UYqXsd8GNMHqiy6MjgynhAw7a92bpjqCfvLi8c7MJH+T1wDRXZ1pnpA+F4Ah540VBiY OBzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from:dkim-signature; bh=5sv3t5JTJ3ZU3du0fNjgMbkaEr65ujxjxS+6J7R4VNo=; b=ATymTvQnix2KnZF/2gluJCbld8CZm52Zi8b7BMIZDUnOuPf3ZbSXSLz3h24xRarz2+ x9egMUbpTSwIRpV1rZCtcuU3gMgwHn3VrhLhPDB/qSzHjsEofYuRe/KRDTVu8R1fiVhI FnnuVvLyJ3W/u6V6rSYLpBdCKb9l+rEywABYIJ8JMyZ2z6AZhY7txNmR2mdkVIrH7LTx kud94R70HsbSseTVgjXOkmtzN1Qxc2ELBvTk70QjxHtksd6XCY/d6xklT71WelFVEYJB 2ufGIMi4yCMQrgVNvsWbrWz3yE9UGOZGNmpbIZN6jroSExP3EQW3QVfqs6NJZhWMeskL DHNw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@haabendal.dk header.s=20140924 header.b=nbP0sEYk; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w8si18783304plz.301.2019.05.14.05.06.34; Tue, 14 May 2019 05:06:50 -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=@haabendal.dk header.s=20140924 header.b=nbP0sEYk; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726491AbfENMCp (ORCPT + 99 others); Tue, 14 May 2019 08:02:45 -0400 Received: from mailrelay1-1.pub.mailoutpod1-cph3.one.com ([46.30.210.182]:34437 "EHLO mailrelay1-1.pub.mailoutpod1-cph3.one.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726472AbfENMCo (ORCPT ); Tue, 14 May 2019 08:02:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=haabendal.dk; s=20140924; h=content-type:mime-version:message-id:in-reply-to:date:references:subject:cc: to:from:from; bh=5sv3t5JTJ3ZU3du0fNjgMbkaEr65ujxjxS+6J7R4VNo=; b=nbP0sEYkUeQa4ml6M5q0hxeCdNcs7yG4INE6mm/YKbHBKpNM+MyZAtW1RCi7ZRjZ7wmSjAtqwvIxC x0LUUHSfRHIwmj7W1VWScoZQEa+9+3M65Po+i6lJ5rZ3QL36FQ5FAD5Pd/vyp0voawFJquzSbbddjT yvMEzStRsL4Da1ZE= X-HalOne-Cookie: a6a677708409723a01024242b1d8a93317ea455c X-HalOne-ID: 2c981014-7640-11e9-bc24-d0431ea8a283 Received: from localhost (unknown [193.163.1.7]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 2c981014-7640-11e9-bc24-d0431ea8a283; Tue, 14 May 2019 12:02:41 +0000 (UTC) From: Esben Haabendal To: Andy Shevchenko Cc: Andy Shevchenko , Lee Jones , "open list\:SERIAL DRIVERS" , Enrico Weigelt , Greg Kroah-Hartman , Jiri Slaby , Darwin Dingel , Jisheng Zhang , Sebastian Andrzej Siewior , He Zhe , Marek Vasut , Douglas Anderson , Paul Burton , Linux Kernel Mailing List Subject: Re: [PATCH] serial: 8250: Add support for using platform_device resources References: <20190430140416.4707-1-esben@geanix.com> <20190430153736.GL9224@smile.fi.intel.com> <874l6efxta.fsf@haabendal.dk> <20190502104556.GS9224@smile.fi.intel.com> <87pnp11112.fsf@haabendal.dk> <20190507093239.GB4529@dell> <87sgtqjy3l.fsf@haabendal.dk> <20190507115325.GV9224@smile.fi.intel.com> <87k1f2jvyd.fsf@haabendal.dk> <20190507150847.GW9224@smile.fi.intel.com> <87k1etmrfk.fsf@haabendal.dk> Date: Tue, 14 May 2019 14:02:40 +0200 In-Reply-To: (Andy Shevchenko's message of "Tue, 14 May 2019 12:37:25 +0300") Message-ID: <87zhnpkzvj.fsf@haabendal.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Shevchenko writes: > On Tue, May 14, 2019 at 12:23 PM Andy Shevchenko > wrote: >> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal wrote: > >> > Please take a look at https://lkml.org/lkml/2019/4/9/576 >> > ("[PATCH v2 2/4] mfd: ioc3: Add driver for SGI IOC3 chip") >> >> Thank you for this link. >> Now, look at this comment: >> >> + /* >> + * Map all IOC3 registers. These are shared between subdevices >> + * so the main IOC3 module manages them. >> + */ >> >> Is it your case? Can we see the code? > > They do not request resources by the way. Actually, that looks like a bug in ioc3.c driver. It is using mfd_add_devices() with a mem_base that has not been properly requested, and the platform_get_resource() calls made by child drivers does not guarantee exclusive access to the memory resources, as they are not inserted in the root memory resource tree. > You may do the same, I told you this several times. In drivers/mfd/ioc3.c: First, the uart resources are defined. The register memory resource is defined relative to the mfd driver memory resource. +static struct resource ioc3_uarta_resources[] = { + DEFINE_RES_MEM(offsetof(struct ioc3, sregs.uarta), + sizeof_field(struct ioc3, sregs.uarta)), + DEFINE_RES_IRQ(6) +}; This is then used when creating the uart cell. + cell->name = "ioc3-serial8250"; + cell->id = ioc3_serial_id++; + cell->resources = ioc3_uarta_resources; + cell->num_resources = ARRAY_SIZE(ioc3_uarta_resources); Finally, the mfd_add_devices() call is made, giving the resource for the BAR0 region (&ipd->pdev->resource[0]) as mem_base argument: + mfd_add_devices(&ipd->pdev->dev, -1, ioc3_mfd_cells, + cell - ioc3_mfd_cells, &ipd->pdev->resource[0], + 0, ipd->domain); This is just what I want to do. But in order to guarantee exclusive access to the memory resource, I need to have it requested. /Esben