Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752125AbdGERww (ORCPT ); Wed, 5 Jul 2017 13:52:52 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:35722 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751716AbdGERwv (ORCPT ); Wed, 5 Jul 2017 13:52:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170704154503.15998-1-venture@google.com> From: Rob Lippert Date: Wed, 5 Jul 2017 10:52:49 -0700 Message-ID: Subject: Re: [PATCH linux dev-4.10] drivers/misc: (aspeed-lpc-snoop): Add ast2400 to compat To: Patrick Venture Cc: Joel Stanley , Greg KH , Rick Altherr , Arnd Bergmann , linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2653 Lines: 62 On Wed, Jul 5, 2017 at 10:48 AM, Patrick Venture wrote: > On Wed, Jul 5, 2017 at 10:33 AM, Rob Lippert wrote: >> I checked the datasheets when I wrote this and ast2400 does not have >> the (undocumented) HICRB register bits 14,15 that enables the BMC to >> actually respond to the snoop'ed address. > > You're right, it is marked as "reserved" in the datasheet for the ast2400. > >> >> Without setting that bit in the ast2500 the transactions to that I/O >> port would timeout on the host side (although the BMC snoop logic >> would still see it and log it). >> Probably not an issue for x86 systems that don't have any LPC I/O >> error handling anyways but LPC timeouts causes issues with POWER >> systems since it sets a hardware FIR bit which can cause boot >> failures. > > Interesting. I've been running experiments on x86 and I haven't seen > any errors, so that adds more credence to your point. If a device > doesn't respond within X time, three times in a row, you get a triple > fault. But, on x86, I don't think I've seen any mechanism with an > expectation that a port IO write will have a guaranteed response. > > For the use-case I'm chasing, my goal being to snoop PoST codes from > the host, there is in the datasheet a post-code control register set, > but I haven't explored configuring them or whether someone has written > the fifo driver for them. > >> >> -Rob >> >> On Tue, Jul 4, 2017 at 8:45 AM, Patrick Venture wrote: >>> This driver can be used on the aspeed ast2400. >>> >>> Tested: ast2400 on quanta-q71l >>> >>> Signed-off-by: Patrick Venture >>> --- >>> drivers/misc/aspeed-lpc-snoop.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/misc/aspeed-lpc-snoop.c b/drivers/misc/aspeed-lpc-snoop.c >>> index 593905565b74..0647cff6280a 100644 >>> --- a/drivers/misc/aspeed-lpc-snoop.c >>> +++ b/drivers/misc/aspeed-lpc-snoop.c >>> @@ -241,6 +241,7 @@ static int aspeed_lpc_snoop_remove(struct platform_device *pdev) >>> >>> static const struct of_device_id aspeed_lpc_snoop_match[] = { >>> { .compatible = "aspeed,ast2500-lpc-snoop" }, >>> + { .compatible = "aspeed,ast2400-lpc-snoop" }, >>> { }, > > An approach would be to ditch this change and instead refer to the > ast2500-lpc-snoop in my device-tree to avoid anyone non-x86 from > running this configuration and hitting issues. This change is probably fine since the driver does still work but you should also guard the setting of the HICRB bits with #ifdef MACH_ASPEED_G5 or similar to avoid setting reserved bits on the G4 hardware. -Rob