Received: by 2002:a25:86ce:0:0:0:0:0 with SMTP id y14csp1038072ybm; Tue, 21 May 2019 07:45:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqwUgR8QI1RmVv29qgpi8bTrxl7QJCWCr1m3wU6fo+U9+NECXAGPWMlSGFZBC+8BTfLopKea X-Received: by 2002:a63:9548:: with SMTP id t8mr83457773pgn.256.1558449905307; Tue, 21 May 2019 07:45:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558449905; cv=none; d=google.com; s=arc-20160816; b=XEwdDsAWPPAvvulTjtToUxa5DL19F9KQWQn3mNfk/k6TRrJVKOY1oyaU5IcrVS8ZKa 6fO9LZNCh2AynqSINmQU1tSmXhV6L1ZNqDvUtgKIK/xGMsv+/oCddB9uVSDnQFWIu5JB ysHKZmkKqjsPlGlHzf5kcC//NCCI6RS8X7qfGli44lcq/qa8rcUpZdTuPO14UFNTndim 6GmefrksRKoiWAw8awyI+KZJM3+WQmbBqtErU3u7HDm3rja9b7DS7L20l0zEQIXGecgx Fq0hmeMAepNmpzY8nHy2Dqx70fGATCxh1JrcxatphPVohhTeHlkdaPWzCh3TGA7Sq2s3 hKsQ== 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=mhtqROY1BvR1+GxmZcfAWSC/BHyhG7CyJw5UFaMfTWg=; b=GoNC6YCGz9RHtwQrizxFW6bPv897U6Wc0ni4oBs59VzI0CGNizVlBv527Uc2nCPnSB CpnJfROdOt3Tv4CTMyKLZbLQ5oBSOBTLl6q0rySr0Y9r9XWnA0VcI3f/RU1/hekrhR0/ E/QY7KS3grIUtSnJ9sPadlKO+XTl0HupPTAk0O+g6SUJ7mZyuHkNqvTYbRkiECbhfiYc L5mb0kVp2azikURFJMB6gCDwMfdrZCqesQD5PWw58BF7OlARVHIdpNXTQshRLQNIjUsi 2nPjg0p64e0MeHxOFiZiFqzGdSpNLLIeQTpMo80i9H9kbwXmhGYoxJu2CWR2IUIdQlRU lgXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@haabendal.dk header.s=20140924 header.b=uXotGHvj; 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 b16si4475268pgk.387.2019.05.21.07.44.49; Tue, 21 May 2019 07:45:05 -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=uXotGHvj; 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 S1728370AbfEUOnW (ORCPT + 99 others); Tue, 21 May 2019 10:43:22 -0400 Received: from mailrelay1-1.pub.mailoutpod1-cph3.one.com ([46.30.210.182]:49476 "EHLO mailrelay1-1.pub.mailoutpod1-cph3.one.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728289AbfEUOnW (ORCPT ); Tue, 21 May 2019 10:43:22 -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=mhtqROY1BvR1+GxmZcfAWSC/BHyhG7CyJw5UFaMfTWg=; b=uXotGHvj8jPuRaLFW0U37O4kAH9aRinsATkXxy0wHsQHXJBPtKtv+ZQOE7lh19jMPVnlG2aIGj98w UokinghtSoa70ea01yLx2/qCacltHLfb3ha7NkckYQMS2C9fwKg3b2xG0uu361ce0VqPAGyxF42Zn1 UQrpap98na+7Gpps= X-HalOne-Cookie: 085d6690cb8d3a04163c483bd50c4bce644ce569 X-HalOne-ID: c6359395-7bd6-11e9-bc27-d0431ea8a283 Received: from localhost (unknown [193.163.1.7]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id c6359395-7bd6-11e9-bc27-d0431ea8a283; Tue, 21 May 2019 14:43:19 +0000 (UTC) From: Esben Haabendal To: Andy Shevchenko Cc: Greg Kroah-Hartman , linux-serial@vger.kernel.org, Lee Jones , Enrico Weigelt , Jiri Slaby , Darwin Dingel , Jisheng Zhang , Sebastian Andrzej Siewior , He Zhe , Marek Vasut , Douglas Anderson , Paul Burton , linux-kernel@vger.kernel.org Subject: Re: [PATCH resend] serial: 8250: Add support for using platform_device resources References: <20190430140416.4707-1-esben@geanix.com> <20190521113426.16790-1-esben@geanix.com> <20190521124202.GE9224@smile.fi.intel.com> Date: Tue, 21 May 2019 16:43:18 +0200 In-Reply-To: <20190521124202.GE9224@smile.fi.intel.com> (Andy Shevchenko's message of "Tue, 21 May 2019 15:42:02 +0300") Message-ID: <87d0kbna0p.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 21, 2019 at 01:34:26PM +0200, Esben Haabendal wrote: >> Allow getting memory resource (mapbase or iobase) as well as irq from >> platform_device resources. >> >> The UPF_DEV_RESOURCES flag must be set for devices where platform_device >> resources are to be used. When not set, driver behaves as before. >> >> This allows use of the serial8250 driver together with devices with >> resources added by platform_device_add_resources(), such as mfd child >> devices added with mfd_add_devices(). >> >> When UPF_DEV_RESOURCES flag is set, the following platform_data fields should >> not be used: mapbase, iobase, mapsize, and irq. They are superseded by the >> resources attached to the device. >> > > Same comment here: Requesting resource is orthogonal to the retrieving or > slicing them. Yes. But for MFD devices, I do think it makes sense for the MFD parent device to request the entire memory resource, and then split it. And for drivers that actually are aware of the struct resource given, both approaches work. Throwing away the resource.parent information and calling out request_mem_region() manually breaks the idea of managing IORESOURCE_MEM as a tree structure. Are we not supposed to be using the parent/child part of struct resource? >> + if (p->flags & UPF_DEV_RESOURCES) { >> + serial8250_probe_resources(dev, i, p, &uart); > > This can be easily detected by checking for the resources directly, like > > res = platform_get_resource(...); > if (res) > new_scheme(); > else > old_scheme(); > > Otherwise looks good. Sounds fine with me. I was afraid that it could cause problems with existing drivers, where platform_get_resource() would work, but return something else than desired. That would probably have gone unnoticed by now. But can ofcourse be fixed if it occurs. >> - if (!request_mem_region(port->mapbase, size, "serial")) { >> + if (!(port->flags & UPF_DEV_RESOURCES) && >> + !request_mem_region(port->mapbase, size, "serial")) { > >> - release_mem_region(port->mapbase, size); >> + if (!(port->flags & UPF_DEV_RESOURCES)) >> + release_mem_region(port->mapbase, size); > >> - if (!request_region(port->iobase, size, "serial")) >> + if (!(port->flags & UPF_DEV_RESOURCES) && >> + !request_region(port->iobase, size, "serial")) > >> - release_mem_region(port->mapbase, size); >> + if (!(port->flags & UPF_DEV_RESOURCES)) >> + release_mem_region(port->mapbase, size); > >> - release_region(port->iobase, size); >> + if (!(port->flags & UPF_DEV_RESOURCES)) >> + release_region(port->iobase, size); > > All these changes are not related to what you describe in the commit message. > is a workaround for the bug in the parent MFD driver of the 8250. You are right, this is not adequately described in commit message. But unless we are not supposed to allow parent/child memory resource management, I don't think it is a workaround, but a fix. But I can split it out in a separate patch. Would be nice if I at least can get the other part of the change merged. /Esben