Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752820AbcLEX1S (ORCPT ); Mon, 5 Dec 2016 18:27:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43422 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752005AbcLEX1O (ORCPT ); Mon, 5 Dec 2016 18:27:14 -0500 Subject: Re: [PATCH] SPCR: check bit width for the 16550 UART To: Duc Dang , Aleksey Makarov References: <20161205130534.11080-1-aleksey.makarov@linaro.org> Cc: "Rafael J . Wysocki" , linux-acpi@vger.kernel.org, linux-serial@vger.kernel.org, Linux Kernel Mailing List , Greg Kroah-Hartman , Russell King , Peter Hurley , Mark Salter , Graeme Gregory , Len Brown From: Jon Masters Message-ID: Date: Mon, 5 Dec 2016 18:27:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 05 Dec 2016 23:27:14 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1490 Lines: 39 Duc, Aleksey, all, I have a question about this... On 12/05/2016 01:51 PM, Duc Dang wrote: > On Mon, Dec 5, 2016 at 5:05 AM, Aleksey Makarov > wrote: >> Check the 'Register Bit Width' field of the ACPI Generic Address >> Structure that specifies the address of the UART registers to >> decide if the driver should use "mmio32" access instead of "mmio". >> >> If the driver is other than 16550 the access with is defined >> by the Interface Type field of the SPCR table. I have two questions about this: 1). Why is this not a full 16550 (ACPI_DBG2_16550_COMPATIBLE)? 2). Why is it a ACPI_DBG2_16550_SUBSET you are assuming here? The SPCR and DBG2 spec clearly state that the _SUBSET is intended to represent a UART compatible with the earlier DGBP specification, not that a UART is a "subset" of a full 16550 (which seems to be the assumption in this patch). It's important we get this right. I built a test kernel with this patch and updated ACPI tables earlier, but it didn't boot with a console because I had left it a subtype 0, but just changed the width to 32 bit, which is what I expected. Further, I've heard back from Microsoft and they're looking at adding a specific subtype for this. If they do, I'm inclined to address existing designs with your patch (but I would favor this check because against the full 16550) and then switch newer APM based designs to the new subtype. Jon. -- Computer Architect | Sent from my Fedora powered laptop