From: Esben Haabendal <esben@haabendal.dk> To: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Lee Jones <lee.jones@linaro.org>, "open list\:SERIAL DRIVERS" <linux-serial@vger.kernel.org>, Enrico Weigelt <lkml@metux.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jslaby@suse.com>, Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>, Jisheng Zhang <Jisheng.Zhang@synaptics.com>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, He Zhe <zhe.he@windriver.com>, Marek Vasut <marex@denx.de>, Douglas Anderson <dianders@chromium.org>, Paul Burton <paul.burton@mips.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] serial: 8250: Add support for using platform_device resources Date: Tue, 14 May 2019 14:02:40 +0200 [thread overview] Message-ID: <87zhnpkzvj.fsf@haabendal.dk> (raw) In-Reply-To: <CAHp75VetoajaeqUnUuj4sNjhujqDkbqvQmxE+LMtzFN4so_jwA@mail.gmail.com> (Andy Shevchenko's message of "Tue, 14 May 2019 12:37:25 +0300") Andy Shevchenko <andy.shevchenko@gmail.com> writes: > On Tue, May 14, 2019 at 12:23 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: >> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal <esben@haabendal.dk> 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
WARNING: multiple messages have this Message-ID (diff)
From: Esben Haabendal <esben@haabendal.dk> To: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Lee Jones <lee.jones@linaro.org>, "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>, Enrico Weigelt <lkml@metux.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Jiri Slaby <jslaby@suse.com>, Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>, Jisheng Zhang <Jisheng.Zhang@synaptics.com>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, He Zhe <zhe.he@windriver.com>, Marek Vasut <marex@denx.de>, Douglas Anderson <dianders@chromium.org>, Paul Burton <paul.burton@mips.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] serial: 8250: Add support for using platform_device resources Date: Tue, 14 May 2019 14:02:40 +0200 [thread overview] Message-ID: <87zhnpkzvj.fsf@haabendal.dk> (raw) In-Reply-To: <CAHp75VetoajaeqUnUuj4sNjhujqDkbqvQmxE+LMtzFN4so_jwA@mail.gmail.com> (Andy Shevchenko's message of "Tue, 14 May 2019 12:37:25 +0300") Andy Shevchenko <andy.shevchenko@gmail.com> writes: > On Tue, May 14, 2019 at 12:23 PM Andy Shevchenko > <andy.shevchenko@gmail.com> wrote: >> On Tue, May 14, 2019 at 10:24 AM Esben Haabendal <esben@haabendal.dk> 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
next prev parent reply other threads:[~2019-05-14 12:02 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-30 14:04 [PATCH] serial: 8250: Add support for using platform_device resources Esben Haabendal 2019-04-30 15:37 ` Andy Shevchenko 2019-05-01 7:17 ` Esben Haabendal 2019-05-02 10:45 ` Andy Shevchenko 2019-05-02 12:41 ` Esben Haabendal 2019-05-02 15:31 ` Andy Shevchenko 2019-05-06 15:46 ` Esben Haabendal 2019-05-06 16:44 ` Andy Shevchenko 2019-05-06 17:40 ` Esben Haabendal 2019-05-06 21:04 ` Andy Shevchenko 2019-05-07 9:32 ` Lee Jones 2019-05-07 9:36 ` Lee Jones 2019-05-07 11:32 ` Esben Haabendal 2019-05-07 11:35 ` Esben Haabendal 2019-05-07 11:53 ` Andy Shevchenko 2019-05-07 12:22 ` Esben Haabendal 2019-05-07 15:08 ` Andy Shevchenko 2019-05-14 7:22 ` Esben Haabendal 2019-05-14 9:23 ` Andy Shevchenko 2019-05-14 9:37 ` Andy Shevchenko 2019-05-14 12:02 ` Esben Haabendal [this message] 2019-05-14 12:02 ` Esben Haabendal 2019-05-14 12:42 ` Andy Shevchenko 2019-05-14 12:02 ` Esben Haabendal 2019-05-14 12:02 ` Esben Haabendal 2019-05-14 12:38 ` Andy Shevchenko 2019-05-14 7:37 ` Esben Haabendal 2019-05-02 19:41 ` Enrico Weigelt, metux IT consult 2019-05-06 15:19 ` Esben Haabendal 2019-05-06 15:19 ` Esben Haabendal 2019-05-21 11:34 ` [PATCH resend] " Esben Haabendal 2019-05-21 12:42 ` Andy Shevchenko 2019-05-21 14:43 ` Esben Haabendal 2019-05-21 17:03 ` Andy Shevchenko 2019-05-21 13:11 ` Greg Kroah-Hartman 2019-05-21 14:45 ` Esben Haabendal 2019-05-21 14:53 ` Greg Kroah-Hartman 2019-06-11 18:11 ` Enrico Weigelt, metux IT consult
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87zhnpkzvj.fsf@haabendal.dk \ --to=esben@haabendal.dk \ --cc=Jisheng.Zhang@synaptics.com \ --cc=andriy.shevchenko@linux.intel.com \ --cc=andy.shevchenko@gmail.com \ --cc=bigeasy@linutronix.de \ --cc=darwin.dingel@alliedtelesis.co.nz \ --cc=dianders@chromium.org \ --cc=gregkh@linuxfoundation.org \ --cc=jslaby@suse.com \ --cc=lee.jones@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=lkml@metux.net \ --cc=marex@denx.de \ --cc=paul.burton@mips.com \ --cc=zhe.he@windriver.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.