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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 99E4AC43461 for ; Fri, 11 Sep 2020 04:48:16 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EF3792075A for ; Fri, 11 Sep 2020 04:48:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WphknRWr"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=aj.id.au header.i=@aj.id.au header.b="aKGHxqSK"; dkim=temperror (0-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="ZlyozmQp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF3792075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=aj.id.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:To:From:Date:References:In-Reply-To: Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qSCoLoQg74WxYjrRkW2lGwkEJlVsPP9p6TuPFlXLUFE=; b=WphknRWr+i0+m3+lcpwU+a9ef 0cxztCK/3DyQj/HswNX/dbR55QszeLPHlwP81+GOJ8PQoC3Wo7JEOgSdczgz3WejsIXeIRPaCOQ6t Tcae6ZnpakBAhdHD+7rs74WNVjQyw05QLsGFWYez1+SGUDo76hT+ge+0pZRPyysaxI4az/fljcqOf KWkzx3wNtG150jk3vcU1t/74giIqW2nvnrmE3KW9JBY0k71hSj7eRpc9kRixBlFm3/aFjJ9vZbyrC hnLBs2jOtwK8X/8PN1Yz706GBHLQoszDmEcyIoh5yambRkz46UkxY84uk/IzbUqP6RtjOZR4UDokb neSVwjWnQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGaxM-0004vU-7m; Fri, 11 Sep 2020 04:46:40 +0000 Received: from new4-smtp.messagingengine.com ([66.111.4.230]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGaxJ-0004v4-J7 for linux-arm-kernel@lists.infradead.org; Fri, 11 Sep 2020 04:46:38 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id C8127580176; Fri, 11 Sep 2020 00:46:36 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute3.internal (MEProxy); Fri, 11 Sep 2020 00:46:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm3; bh=JE4d8w98uqoH0zAX9kIMQF/kNdFrrfp 5s+XGghxpu2Q=; b=aKGHxqSK44sAvbOa3O+hjcbg+0zGqEmMR955lFtPHVamz0v Vu0s0/ZTrpn6hOPp3gGp1dDwwabK0KDlrnfkXZ3ivtVIO62mZG6yadeKWwFJqJRD XjjW0SY434RBBzc9JYx/dLY6bPcU1utZu9KX5uEmV/3WxsiW0TFBXlPT3s4s5kym jk4zvIHdO8GdrfJmx9M8iGTNwaulSaMG1dkSUnCMQtaI3NuPDwdm8mqIg27yL+ZE l8GFApZEb2TiS9LHPntdP+1KeeuZf9npyx4sYGxoJe3ZdkED+bHxWs26Dv922yUG JKtCud21GlHAWlq63QkfYcEA+bQ6SGJ5Snejp+g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=JE4d8w 98uqoH0zAX9kIMQF/kNdFrrfp5s+XGghxpu2Q=; b=ZlyozmQpKiuycVOB0JnTyV XZKViu2n590EBUbtsKRm+MjMgC6wPf0kl6HR8O9IwtLgfbY+DSo5Z3haYr1Wamoo n2IXzveW19opuXfbEeTzKs5xqiJDY1h+1Hd45xK6V0vhMTbI+Q0VyP2/S5I38Ogo JK7+3ZJD/9FOuCwamp48gOhfB3aypKI4VL5TXUNQBELZ9XV4URThwl6YjxN70U1Q uy2zEoukGSE19Dy0ze3wGmMhsN6ugaGYsFLFAiN6baOqmRCnWaLWQbfkzhmsmdrF PElIzLpDQoGlMGTZ9qzjFH54s0lYQ1TLEpbf2D5cQlS5zKBlbgxS7fDoHXZScoTA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehkedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetnhgu rhgvficulfgvfhhfvghrhidfuceorghnughrvgifsegrjhdrihgurdgruheqnecuggftrf grthhtvghrnhepudfftddvveekfffgteffffeuveegjeelgefhffejtdehtdfhlefgkeef hfefkeeinecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurhgvfiesrghjrdhiugdrrghu X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B6B26E00A6; Fri, 11 Sep 2020 00:46:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3 Mime-Version: 1.0 Message-Id: <551926fc-7bd4-4a0e-8fcf-4675dcdba22b@www.fastmail.com> In-Reply-To: References: <20200911034631.8473-1-chiawei_wang@aspeedtech.com> Date: Fri, 11 Sep 2020 14:15:56 +0930 From: "Andrew Jeffery" To: "Joel Stanley" , "Chia-Wei, Wang" Subject: Re: [PATCH 0/4] Remove LPC register partitioning X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200911_004637_703727_3BAAC736 X-CRM114-Status: GOOD ( 24.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Robert Lippert , Ryan Chen , linux-aspeed , Corey Minyard , Linus Walleij , Linux Kernel Mailing List , OpenBMC Maillist , Rob Herring , Linux ARM , Cyril Bur , Haiyue Wang Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 11 Sep 2020, at 13:33, Joel Stanley wrote: > Hello, > > On Fri, 11 Sep 2020 at 03:46, Chia-Wei, Wang > wrote: > > > > The LPC controller has no concept of the BMC and the Host partitions. > > The incorrect partitioning can impose unnecessary range restrictions > > on register access through the syscon regmap interface. > > > > For instance, HICRB contains the I/O port address configuration > > of KCS channel 1/2. However, the KCS#1/#2 drivers cannot access > > HICRB as it is located at the other LPC partition. Thanks for addressing this, I've regretted that choice for a while now. The split was rooted in trying to support pinmux while not being across every detail of the LPC controller, and so I made some poor decisions. > > > > In addition, to be backward compatible, the newly added HW control > > bits could be added at any reserved bits over the LPC addressing space. > > > > Thereby, this patch series aims to remove the LPC partitioning for > > better driver development and maintenance. > > I support this cleanup. The only consideration is to be careful with > breaking the driver/device-tree relationship. We either need to ensure > the drivers remain compatible with both device trees. > > Another solution is to get agreement from all parties that for the LPC > device the device tree is always the one shipped with the kernel, so > it is okay to make incompatible changes. > > While we are doing a cleanup, Andrew suggested we remove the detailed > description of LPC out of the device tree. We would have the one LPC > node, and create a LPC driver that creates all of the sub devices > (snoop, FW cycles, kcs, bt, vuart). Andrew, can you elaborate on this > plan? I dug up the conversation I had with Rob over a year ago about being unhappy with what I'd cooked up. https://lore.kernel.org/linux-arm-kernel/CAL_JsqJ+sFDG8eKbV3gvmqVHx+otWbki4dY213apzXgfhbXXEw@mail.gmail.com/ But I think you covered most of the idea there: We have the LPC driver create the subdevices and that moves the details out of the devicetree. However, I haven't thought about it more than that, and I think there are still problems with that idea. For instance, how we manage configuration of those devices, and how to enable only the devices a given platform actually cares about (i.e. the problems that devicetree solves for us). It may be that the only way to do that is with platform code, and that's not really a direction we should be going either. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel