Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3626486yba; Mon, 29 Apr 2019 05:59:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwTAXsGXBxAVo0M72mh8ROONA6MChbKgPGCcx265rv2/ynKuJBuFsG6C9s3BgxGxqymanc9 X-Received: by 2002:a62:70c6:: with SMTP id l189mr63008573pfc.139.1556542774513; Mon, 29 Apr 2019 05:59:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556542774; cv=none; d=google.com; s=arc-20160816; b=bTgGwXOb79yqtYrzYesjoZjrwdHsY7LJSeJFvZfeSA9QwXxizBit6br5on9iKsKj4f blsOH8fiYobQggZlV508409LI76DQkOzWIrqOs8gq8fuNpw+e1NOko4nlY8KWjGZl8Ae pijJslU8fbjLltI2hUp6+LR+VydNZPdo6rvVcVJcHZxQewIdRNb8tFGzVnfVF+xiUzRx cyLoAlKHnsFyPA/MENhXwu0uNotUTYwQ5Yhh6W5/c9cdyzEWLDcHK6vS7dYlVNmultB4 nDpi+s5JJht0fxrsRXnhSrkXkpc6CdjGwLfgcuwsaa83kr1YWnN70E1MYvH5vHXUY9Al VHyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=uAetoLohS5RuD2YfwHQ5uJHrB2ZQowO5MhcQiGanUAA=; b=BDilbvEqvUNRlkyEZNu7MI+gid2j12cc3Assy39wG3sjc8KxccvqCmPydbLH3de0+j 4xC42X5dQC2H7crYv+59jekT5pEmyx9vAkNovbgEWvi3eTcIKISV9uxfCN1pjS5bZg0A yqKwNZ/g/coLwIXDRqnRJtdrzNFk42hXAlf/niMVtQIN+3sfgdHHJfUKwW7LD7DvspAt 0zzTACoA5k44bq/Y43PliKOi6pWN2v/RSOyHEYrVAWc++DEPRUtRcyIA8nWewFnge1/w BwDSc3W3aWxvTm/SxEmo9tVAuAsnc82OyAild1FGTBsng2fFj5ePwUdgtvZKMGzUzJpH kiFQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b8si33232328pfd.55.2019.04.29.05.59.18; Mon, 29 Apr 2019 05:59:34 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728158AbfD2M62 (ORCPT + 99 others); Mon, 29 Apr 2019 08:58:28 -0400 Received: from mout.kundenserver.de ([217.72.192.74]:58397 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727764AbfD2M61 (ORCPT ); Mon, 29 Apr 2019 08:58:27 -0400 Received: from [192.168.1.110] ([77.9.18.117]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1N6KMR-1gjiq62ZhJ-016j4B; Mon, 29 Apr 2019 14:57:03 +0200 Subject: Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF To: Esben Haabendal , Andy Shevchenko Cc: Andy Shevchenko , "open list:SERIAL DRIVERS" , Greg Kroah-Hartman , Jiri Slaby , Darwin Dingel , He Zhe , Jisheng Zhang , Sebastian Andrzej Siewior , Linux Kernel Mailing List References: <20190426084038.6377-1-esben@geanix.com> <20190426084038.6377-2-esben@geanix.com> <20190426143946.GX9224@smile.fi.intel.com> <871s1og11u.fsf@haabendal.dk> <20190426215103.GD9224@smile.fi.intel.com> <87tvejakot.fsf@haabendal.dk> <87y33tz5oz.fsf@haabendal.dk> <87ef5lxiqm.fsf@haabendal.dk> From: "Enrico Weigelt, metux IT consult" Organization: metux IT consult Message-ID: Date: Mon, 29 Apr 2019 14:56:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87ef5lxiqm.fsf@haabendal.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:Xi8+kN3ggy0q8UqlVr1mLGr8tMECSCR4gGXzRpXnZEKUZYiwx2o HhfmKEnGaURE5cshKsrrdPF76Oc0UxXE1prabduHmA1hGT7P0K+DuQdw8yV71LqE8tOiFiu 5aLrpYObZMDq4NrxNifckSW7PHUQ+5/WWBxP/TddhRQMK76RCMUKcebpdIVT2cMSEo3mlIU Nmx01LhrSuW/OuY5vmRNg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lUPD7tiF4iY=:3HMXJNqzKnQgJJNa0/hYLA y8oOBd4maeBkvhV0Bpy0xL/kkHLEb85rglY1FxVy/UkM9uwGZxyslvdf+2boltKtvoDc8Sv+n kSVoJoCLShJLGsK0/IMa6ALrCvkNHFaryiSvxEMYl9f3iWpFCdsJCeBXcgvicnTgxRQP9xCDN FrRlWpbQDGb1RjRQomTAZlNoa8DahUrzn918C01Yemz1q0iktKluHJgglG/4eUGpdsSB9k4bG p5OnJskSzmTIVmKfrWMXYLVA2FE1l0zYaGyzBKjIACKc/7Y5mGymGhGusCcNwPYEY5q6KeTIl mjqioKKcDSSqAtdl3kZuILYKrvsHNYwDwnniQ0UkATL19magrZ9zXezcocg+Za4o5nLVukgg9 8FmFYNGPSYqNoKyyj4VwRwO7vJ3gBpfduNbhQF518XQJoS2nt2Bvg7SSVqiUpUJhPzRaXGuoT OL2A+6QjOqff7lpaw3pq9MYT44cqIW7LmI2nTpufSOXT/2KFLfJ3HJaD6aRXj8XWPdXaxwLJB oX6CKXd2n9XRsd52rj3mciqWcAAbY7NwcK4o13aRjwfBlGP6ntoOBxFpAe3ilOoT3DCm/3BhG rL3xKmvPoCrCYxAU7Y1GLTCgz4l9U+4hE45xjhaWsLpeu00q5afpK2PTjIITaD1MN2PJr5iyN XbWdRdYcmWTkKCUMdcSJUlkhcuWrjKXtUlkuDo7dbvGgs4RlWaokTcpqRhldzFSWO6JqOCrzW BkN1vpmErmz+Vi+I3ANGvWIhtity3zqn+XK2mRh3UK6Ll75HB47GHy+bDA60IKvAUnP+32ifN 2Ie4IJXRyqjeRxPyc94RTE6osbUT5XMQxfmz1zOWMK/So2iMnI/iH7Nnw3Qg4y05nirQfjh Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29.04.19 11:29, Esben Haabendal wrote: > So maybe we should go down that direction intead, extending 8250 driver > to replace mapbase with a resource struct instead? Yeah, I already was up to do that. But that would be a pretty massive change, as the actual use of fields like mapsize/mapbase in the drivers is so diverse. Some even don't use mapsize. That's why I started harmonizing that step by step. In little steps, that are easier to review (unfortunately, don't have the corresponding hardware to do real tests). Finally, I'd like to have all drivers just use appropriate helpers to declare their IO area and let the core do all the mapping stuff. Then we IMHO could easily switch to struct resource internally. > No, I actually try to do the right thing in relation to Linux device > resource model. But 8250 is just not behaving very well in that > respect, not having been made really aware of the resource model. I see it the same way. The serial (especially 8250) drivers are a tricky thing, and I'd like to make it simpler / easier to understand. But I can understand that Greg is pretty reluctant to any changes, as some actual hardware seems to be hard to get. (OTOH, if it's so rare, could we risk some potential breaks and just wait for anybody complaining ?) --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287