From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752940AbcKQJR4 (ORCPT <rfc822;w@1wt.eu>);
        Thu, 17 Nov 2016 04:17:56 -0500
Received: from mout.kundenserver.de ([212.227.126.130]:59447 "EHLO
        mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751584AbcKQJQ7 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 17 Nov 2016 04:16:59 -0500
From: Arnd Bergmann <arnd@arndb.de>
To: Andrew Jeffery <andrew@aj.id.au>
Cc: Lee Jones <lee.jones@linaro.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Joel Stanley <joel@jms.id.au>, Rob Herring <robh+dt@kernel.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org
Subject: Re: [RFC PATCH] mfd: dt: Add Aspeed LPC binding
Date: Thu, 17 Nov 2016 10:16:15 +0100
Message-ID: <4751029.AudB7s5avo@wuerfel>
User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; )
In-Reply-To: <20161117060633.3837-1-andrew@aj.id.au>
References: <20161117060633.3837-1-andrew@aj.id.au>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Provags-ID: V03:K0:5sOvrOZSElcd3DSEf5zVdC1KMrQCkVSJNHNB/mdws03JazZiNFm
 +ahtGXZFVAAA2YvT4Nri+HQer5kqCWxWp2m6Hw7Dvid0rnnkFKGJoSZXvE4frmgiSuKJoQM
 hvXcS0GApM8SsfGvqfFR7nVAdqnFFMcl4VjEd933ey/YHrg/bGp/Bm39reIbC3GDvG1cqPI
 S52ciBl5nb4dkw5FqahoA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:VfTgFZ+Hh5g=:Na7eRgbWPPlbe27tXJ5Ur2
 ANrcfHWT2CLrJbeWw8OIjneNKxEwWW2TJ7xxxTeQ+m4ZYXaet9VV84jX2iDKDBN90zDydZor3
 b+E6ZVRmq49DqrHQoNixYyQUjccShUKEExh0u6AqwCWsVpjB73Is+2TP374nFn3JxBAm/VR1w
 eCdp+BRJHblVhg9aU7sfX/L5nEooqp3pv+S7n76AMk6/sJgUmVAYGsxqjvrd/fw68dxnLz2Rl
 RH58fFlfXmFVE6uxvc3oEZfgDtXc8D0yBIEcj4q5EpCEc8UIY4UfBtLQnm2N4mml9K1nbKxEJ
 DI+d6SAc7im9EI81VKp9dj+jRijGOAuaROtEnR/oYGLz4jyBxbpWXGgBRnDO2NBbc1Vo5Mz0S
 1Cl2nV+7xL72s7oD1tlwNw2IkRPyXXKJYFSVXCnq4xL6T3vRVj7VPwCk+sLRCO7DCP9axcW77
 Jz4BUjzcCaBgWdpY0J+M3bsxUGWrEj0AOjGOi5borBrSCDo4uyqewHGgShMQL9q+Ba4h+qCr2
 7Zs/honQKN4DVQuyu8tjW0LSOXV84QQ+2YEoZfRuQTf6STYK3Fbu9rVFJB11qsi5KsdZ2VBxu
 JcpI+5vf/DGuSEeNV1hlSpW2t/9vbtJ6V2ifeRpKwpANLFbggNoHfufrUgSrKUtU3iCjuxrXA
 p22wIGo6agaJHdwCeYUaQqeGHzuBy9uVXtfLUyepMgLFdly1i3V3uFO22sQUNADRZcciGTsTk
 KaOE30y2DwWyVZiD
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thursday, November 17, 2016 4:36:33 PM CET Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> 
> I'd like to start a discussion about how to handle the LPC register space in
> the Aspeed SoC. There are a number of issues, largely concerned with the layout
> of the registers but also with the fact that LPC register state is used by the
> pinmux to determine some pin functionality.
...
> 
> What is the recommended approach to managing such hardware?

Can you clarify which side of the LPC bus this is? We are currently having
a discussion for how to integrate the LPC master on an ARM64 server that
uses LPC to access an Aspeed LPC slave. For this one we want to use the
traditional ISA DT binding.

I'm guessing that you are interesting in the other side here, for mapping
the registers of the LPC slave on the Aspeed BMC, but that's not clear from
your email, as I'm assuming that the same chip has both master and slave
interfaces.

	Arnd