Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp746859pxj; Thu, 10 Jun 2021 11:39:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyYdL7rjH4bwez7dq8EF0F35l9riEKY2uR8eNlOmGwH//3LAs82LgT2lQwGKzOWClueFnwp X-Received: by 2002:a05:6402:14d5:: with SMTP id f21mr873880edx.307.1623350395614; Thu, 10 Jun 2021 11:39:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623350395; cv=none; d=google.com; s=arc-20160816; b=iFQPXkWPT1rKlO19xWHt9pDUXctYD0AmfQ/kmFfUszSQe0pS0WAaeaiOjgZDGMd/Iw dJa7h411j3BCRx76093xewwYOYr3uzxn2e8iDIMLIJVtDOBmljSNS7MCJbgwXATd9KLe GNkOjEBqlyv46DFc32mANH4/3oObWxDFNUeOz3k7Sb9KZ/J+u+oY+fniayb4UvmIGv/H M+uqgaXtErYmymoFIFYtm8Q3EQ8uAAxPKW0yC/iBy1+tkkGLmEeQ2p7lBrcVJBPjmTRf 2b+9Sz3asESDD9FnDKJ4lEKjMvUrOKic3eMZKyuYxpKzjW2PibWHHGBCwFPQoW5gyxMR 7acw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=8g3XwfrVCiYHfdSIh1CiC/nVp2Izt6kvMhDhHVDFKMI=; b=p42W28A9AfJl/1dHBH5ClQLIbx7xBUvv9YRn/4YjMFHjvgW03Q4gPT5QCk+tpki3Nl jNsmq/bsOPou3oFwWLcY1Jp8hmgDA8I2CkEOna7Y66zqNUUHgQeqwnNlalenchRvrAW4 m0wyWXwaHF7b7FMQ3S2JIY/SIR/X2J5oZfbw+i6MSpOg8t80LxpDD+/dRRvJN7wwbVx6 xAMv45rgrx2j9R2EcFLdspGZ15nKhTRKG8qQMmg0ImN2Z0mo97HvjlrYhc3pAv0hC5q7 hqj8X5biDRqnjil6Pyo8555xXsrt30/RmhC5r4UjiPeHkuBdwtVytQjY6RV/CmQyd+e5 M2Ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id by27si2718897ejc.657.2021.06.10.11.39.30; Thu, 10 Jun 2021 11:39:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230385AbhFJSkI (ORCPT + 99 others); Thu, 10 Jun 2021 14:40:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230268AbhFJSkH (ORCPT ); Thu, 10 Jun 2021 14:40:07 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::4]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E72BAC061574; Thu, 10 Jun 2021 11:38:10 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id 451559200BC; Thu, 10 Jun 2021 20:38:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 3E7B39200BB; Thu, 10 Jun 2021 20:38:10 +0200 (CEST) Date: Thu, 10 Jun 2021 20:38:10 +0200 (CEST) From: "Maciej W. Rozycki" To: Greg Kroah-Hartman , Jiri Slaby , Thomas Bogendoerfer cc: linux-serial@vger.kernel.org, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] MIPS: Malta: Do not byte-swap accesses to the CBUS UART In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Correct big-endian accesses to the CBUS UART, a Malta on-board discrete TI16C550C part wired directly to the system controller's device bus, and do not use byte swapping with the 32-bit accesses to the device. The CBUS is used for devices such as the boot flash memory needed early on in system bootstrap even before PCI has been initialised. Therefore it uses the system controller's device bus, which follows the endianness set with the CPU, which means no byte-swapping is ever required for data accesses to CBUS, unlike with PCI. The CBUS UART uses the UPIO_MEM32 access method, that is the `readl' and `writel' MMIO accessors, which on the MIPS platform imply byte-swapping with PCI systems. Consequently the wrong byte lane is accessed with the big-endian configuration and the UART is not correctly accessed. As it happens the UPIO_MEM32BE access method makes use of the `ioread32' and `iowrite32' MMIO accessors, which still use `readl' and `writel' respectively, however they byte-swap data passed, effectively cancelling swapping done with the accessors themselves and making it suitable for the CBUS UART. Make the CBUS UART switch between UPIO_MEM32 and UPIO_MEM32BE then, based on the endianness selected. With this change in place the device is correctly recognised with big-endian Malta at boot, along with the Super I/O devices behind PCI: Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled printk: console [ttyS0] disabled serial8250.0: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A printk: console [ttyS0] enabled printk: console [ttyS0] enabled printk: bootconsole [uart8250] disabled printk: bootconsole [uart8250] disabled serial8250.0: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 16550A serial8250.0: ttyS2 at MMIO 0x1f000900 (irq = 20, base_baud = 230400) is a 16550A Signed-off-by: Maciej W. Rozycki Fixes: e7c4782f92fc ("[MIPS] Put an end to 's long and annyoing existence") --- arch/mips/mti-malta/malta-platform.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) linux-mips-malta-cbus-uart-be.diff Index: linux-malta-cbus-uart/arch/mips/mti-malta/malta-platform.c =================================================================== --- linux-malta-cbus-uart.orig/arch/mips/mti-malta/malta-platform.c +++ linux-malta-cbus-uart/arch/mips/mti-malta/malta-platform.c @@ -47,7 +47,8 @@ static struct plat_serial8250_port uart8 .mapbase = 0x1f000900, /* The CBUS UART */ .irq = MIPS_CPU_IRQ_BASE + MIPSCPU_INT_MB2, .uartclk = 3686400, /* Twice the usual clk! */ - .iotype = UPIO_MEM32, + .iotype = IS_ENABLED(CONFIG_CPU_BIG_ENDIAN) ? + UPIO_MEM32BE : UPIO_MEM32, .flags = CBUS_UART_FLAGS, .regshift = 3, },