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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E903C04AB4 for ; Tue, 14 May 2019 12:02:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5E1102147A for ; Tue, 14 May 2019 12:02:46 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=haabendal.dk header.i=@haabendal.dk header.b="nbP0sEYk" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726510AbfENMCp (ORCPT ); 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Esben Haabendal Subject: Re: [PATCH] serial: 8250: Add support for using platform_device resources Date: Tue, 14 May 2019 14:02:40 +0200 Message-ID: <87zhnpkzvj.fsf@haabendal.dk> 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> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: (Andy Shevchenko's message of "Tue, 14 May 2019 12:37:25 +0300") Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: linux-serial@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