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 635C3C433E2 for ; Fri, 11 Sep 2020 04:04:55 +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 DC00E2078D for ; Fri, 11 Sep 2020 04:04:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mWRmtQAi"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=jms.id.au header.i=@jms.id.au header.b="UusFb+aT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC00E2078D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jms.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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=njv7EWokVCm3d0Br8ryecuVP3qQjXc86RISfmJoCvMY=; b=mWRmtQAihBsA6j6OR00zXZ/hD Qhxpxr7IrgyP7IYmUBSU/BJsq9sN3UxIsnYDcnuksS3otTtbXTR7fExpHKRdpdC9LueYzU9F2IE/G CxXNbqfSmtXnKCcbGr4gvvSV+IhIs/tm8f2Eenkbhxt4c08HZlWYj2zjitIldSEnc6ZHSdXATrR3T cbm+8wfNX8aWHBSO450uTwKFv7FldtgOl/NXH5tM8BVT08Y5HVh3enOVD8HM+EjHeaZrPpH35EN6l jNiI0YTcN/XHj5rGrcson8woj8qxZil8RLEqXoAbVXNeoFk162prVldxjlkLUQaDt7Cdbb5J0RoTz 2d+/mbXlw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGaHX-0001QN-F9; Fri, 11 Sep 2020 04:03:27 +0000 Received: from mail-ed1-x544.google.com ([2a00:1450:4864:20::544]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGaHU-0001Q0-H2 for linux-arm-kernel@lists.infradead.org; Fri, 11 Sep 2020 04:03:25 +0000 Received: by mail-ed1-x544.google.com with SMTP id c8so8556545edv.5 for ; Thu, 10 Sep 2020 21:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gXglIxAgElc5JjCRgYm+CHHvgWMa69XLOEv6ewz6NfI=; b=UusFb+aTghNK80Ck3+ShuwAxKTlzIJ+xIFwzjJjt+k4IY0onVTpSnDt7SHAVOEug4r xGP1V6xP16jg2oH88ptXy2jSP1R90aUfjH0RQPxRm5YqPzaTxYut4jiJmiW3vE7A4ERn 6FxLSdVy0vg1bAC8H8yXlKiOIY51tRrmsIpAg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gXglIxAgElc5JjCRgYm+CHHvgWMa69XLOEv6ewz6NfI=; b=ZUMWzOY6hdzncqQytPP4IETna9TiNn84DCW6S3ddJ8llTJK/YKaftDaYkyyOBruJ80 v0pjzTjvc72MpayHVW5M1cBnoYejFYZtJzJZ3dttPkgBok3jwKZtWlrlNQyTwEsNE8Ro utPsHpM6EPstqtyfZaEWKlQVIzb3ncCe3BoGWjLxEuUux+vXa6/pPjE+hNULeiNYcxXl avzeRFJeRMNm0uAvBX3bIXZQm4ba5QKwk/aMFhQZz4iw3yL46+lf5rvZXGR9SJ5VXSbK v76MBiA6L9k93zYxf5DmmGGvjNemfoN6nYgH82k0m1bDtxkiRdGfUrN9CbbQeay94Ybm jL3g== X-Gm-Message-State: AOAM530za6h81BniImyj7X5q2oNazYRqqQUYXW1k12awnHEU7CQnKS/H VueSzlqiYgnJe7w50owVLv29meIvcg44EI46oxc= X-Google-Smtp-Source: ABdhPJzJKUM6X8Vqn2Bh8HF7DPndQmawbtKXMcUpYvj+R+0ipCkW4mPTs1IbtuqKuV2AY2IAR3Whe9cJEpT3LI60gk0= X-Received: by 2002:a05:6402:18d:: with SMTP id r13mr15404edv.267.1599797003384; Thu, 10 Sep 2020 21:03:23 -0700 (PDT) MIME-Version: 1.0 References: <20200911034631.8473-1-chiawei_wang@aspeedtech.com> In-Reply-To: <20200911034631.8473-1-chiawei_wang@aspeedtech.com> From: Joel Stanley Date: Fri, 11 Sep 2020 04:03:11 +0000 Message-ID: Subject: Re: [PATCH 0/4] Remove LPC register partitioning To: "Chia-Wei, Wang" , Andrew Jeffery X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200911_000324_743890_4A07D30E X-CRM114-Status: GOOD ( 19.02 ) 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 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. > > 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? Cheers, Joel > > Chia-Wei, Wang (4): > ARM: dts: Remove LPC BMC and Host partitions > soc: aspeed: Fix LPC register offsets > ipmi: kcs: aspeed: Fix LPC register offsets > pinctrl: aspeed-g5: Fix LPC register offsets > > arch/arm/boot/dts/aspeed-g4.dtsi | 74 +++++------ > arch/arm/boot/dts/aspeed-g5.dtsi | 135 +++++++++------------ > arch/arm/boot/dts/aspeed-g6.dtsi | 135 +++++++++------------ > drivers/char/ipmi/kcs_bmc_aspeed.c | 13 +- > drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +- > drivers/soc/aspeed/aspeed-lpc-ctrl.c | 6 +- > drivers/soc/aspeed/aspeed-lpc-snoop.c | 11 +- > 7 files changed, 162 insertions(+), 214 deletions(-) > > -- > 2.17.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel