Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2673657yba; Mon, 6 May 2019 09:45:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqyTlh//g8DwbOYfz2nuR12iXSfzgXXvpNzbG/kn4JvZAydPtl4uCV9NhyKfpktyKzRlkp8k X-Received: by 2002:a63:e048:: with SMTP id n8mr33251043pgj.41.1557161141622; Mon, 06 May 2019 09:45:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557161141; cv=none; d=google.com; s=arc-20160816; b=ygpPhoT6NEbYHKNZ7pAcFCt5OcuoUDK/Ytebw7uNzTy5UC0yhidxzMsVJQBxDWAlQp MCmOylGuL/6qbM3odHaHD2aUv+qwvz6kILTfts18cfYEB6II4vYgwEBqg2YLIE6A0Rp5 ZPwoY4zXmlo7M92CMqMOl90hLNRh5Vz9f4Qt0U53eUdAY9XcZFVLvulhvIaiAJ28ryRL nSLumFv1Kt7O3bkEyxYmJq6d2zH0anP1r2o9H/XvjuHIsWIYLwDsuVDXBQnjmXe/znXz SMUOJbQMwt4GPdJ46PD8L8p/904PpKxB4nZrxtKqykYkAOWz7BRqxCWIcz+9K/VcF51l UeMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=y/ESGkhHUeVCnLLUQ68rMF8w7Oplg6vxmsgXjya34ao=; b=ucGEnk+zeUNofVwbtACae9xU72eRrf/qQP5RM08fIxd2rdvSwCSRVXuiNFbmu8oour mgtKtJw7XXmZ9P9ZaxUB57ly2gSvr6ZJBNr4LTukrcrTn7JgaWAdMZkDULKUZhJqW1aS uxAEj0zoxLDb3WzlVYh2Eqz0DUs/+GJ4T8aSc+8qCSBRHR3mfkWZQ5lZEHM+8zbwaJ2x dR/huY4NNBu68BI4P3hhHD24sQVdCMJjHL8CTdN47baJkMkGgrBgAYIrYQNVKRiuKwQr 4F9uyiuvMd4TBrdynFPM/dR/1JM0jhZxcmg34iqjwKIfzo/KVD84PV6KuXjqvstH/pv1 qVEw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b15si4438643plz.338.2019.05.06.09.45.26; Mon, 06 May 2019 09:45:41 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726690AbfEFQob (ORCPT + 99 others); Mon, 6 May 2019 12:44:31 -0400 Received: from mga01.intel.com ([192.55.52.88]:37006 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726297AbfEFQob (ORCPT ); Mon, 6 May 2019 12:44:31 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 May 2019 09:44:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,438,1549958400"; d="scan'208";a="168539904" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by fmsmga002.fm.intel.com with ESMTP; 06 May 2019 09:44:27 -0700 Received: from andy by smile with local (Exim 4.92) (envelope-from ) id 1hNgj4-0000Se-6N; Mon, 06 May 2019 19:44:26 +0300 Date: Mon, 6 May 2019 19:44:26 +0300 From: Andy Shevchenko To: Esben Haabendal Cc: Lee Jones , linux-serial@vger.kernel.org, Enrico Weigelt , Greg Kroah-Hartman , 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] serial: 8250: Add support for using platform_device resources Message-ID: <20190506164426.GO9224@smile.fi.intel.com> 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> <20190502153124.GA9224@smile.fi.intel.com> <87ef5boaa7.fsf@haabendal.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ef5boaa7.fsf@haabendal.dk> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 06, 2019 at 05:46:56PM +0200, Esben Haabendal wrote: > Andy Shevchenko writes: > >> > On Wed, May 01, 2019 at 09:17:37AM +0200, Esben Haabendal wrote: > >> >> Andy Shevchenko writes: > As an example, the sm501.c driver, the only driver in drivers/mfd/ which > uses serial8250 driver, does not use any code from mfd-core. > Incidentally, it is 1 year older than mfd-core.c, and as never been > refactored to use mfd-core functionality. So, sm501.c should not request resources for its children. This as simple as that. What you are trying to do here is a hack workaround on the current behaviour in the Linux device model (resource management) as I told you already. > > Why not? Again, *slicing* resources is OK and that's what MFD for, *requesting* > > them in the parent is not. > > Why we cannot use request_mem_region() for those memory resources again? Because it's how it was designed. "One device per one resource". If you would like to fix this, it should be done obviously not in 8250 driver or any other driver, but driver core. Nevertheless there is one particular exception here, i.e. IORESOURCE_MUXED. > It fails because the resources are now already owned the mfd driver, on > behalf of the child. Yes. Behaves in order how it's implementer. No issues here. > > Nope, *requesting* resources as you mentioned lock them to the certain user. > > I still think there is some confusion in relation to your use of the > word "requesting". There is no explicit request/lock action in > kernel/resource.c. You have to check IORESOURCE_BUSY. It seems that what you missed in your picture. I didn't comment the rest until we will figure out the IO resource management in general. -- With Best Regards, Andy Shevchenko