From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E20E6C142 for ; Mon, 4 Sep 2023 18:35:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69D54C433C8; Mon, 4 Sep 2023 18:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1693852505; bh=0+pfR6J8fXVjZ9aVVhS9oTLS2rHVNQuuiRh7m5K41tw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GsXcUj2wEVVGOD4dBkVhSgBTfXEHdluXok4qgAcFa+nMX2MIybiLEIO1cDq5g17ko VapaB4nKXkglM9F+JFQanDNv/qfSY4gOlHw8/EfJI0I6jJpNW2r9d84Jg6LXmLGYQr SJf7xtK5EEb1SelrZ9S+rNoEBSWIXox48n8d1IJ0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Hugo Villeneuve , Lech Perczak Subject: [PATCH 6.1 23/31] serial: sc16is7xx: fix bug when first setting GPIO direction Date: Mon, 4 Sep 2023 19:30:31 +0100 Message-ID: <20230904182948.136719581@linuxfoundation.org> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20230904182946.999390199@linuxfoundation.org> References: <20230904182946.999390199@linuxfoundation.org> User-Agent: quilt/0.67 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Hugo Villeneuve commit 9baeea723c0fb9c3ba9a336369f758ed9bc6831d upstream. When configuring a pin as an output pin with a value of logic 0, we end up as having a value of logic 1 on the output pin. Setting a logic 0 a second time (or more) after that will correctly output a logic 0 on the output pin. By default, all GPIO pins are configured as inputs. When we enter sc16is7xx_gpio_direction_output() for the first time, we first set the desired value in IOSTATE, and then we configure the pin as an output. The datasheet states that writing to IOSTATE register will trigger a transfer of the value to the I/O pin configured as output, so if the pin is configured as an input, nothing will be transferred. Therefore, set the direction first in IODIR, and then set the desired value in IOSTATE. This is what is done in NXP application note AN10587. Fixes: dfeae619d781 ("serial: sc16is7xx") Cc: stable@vger.kernel.org Signed-off-by: Hugo Villeneuve Reviewed-by: Lech Perczak Tested-by: Lech Perczak Link: https://lore.kernel.org/r/20230807214556.540627-6-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman --- drivers/tty/serial/sc16is7xx.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -1345,9 +1345,18 @@ static int sc16is7xx_gpio_direction_outp state |= BIT(offset); else state &= ~BIT(offset); - sc16is7xx_port_write(port, SC16IS7XX_IOSTATE_REG, state); + + /* + * If we write IOSTATE first, and then IODIR, the output value is not + * transferred to the corresponding I/O pin. + * The datasheet states that each register bit will be transferred to + * the corresponding I/O pin programmed as output when writing to + * IOSTATE. Therefore, configure direction first with IODIR, and then + * set value after with IOSTATE. + */ sc16is7xx_port_update(port, SC16IS7XX_IODIR_REG, BIT(offset), BIT(offset)); + sc16is7xx_port_write(port, SC16IS7XX_IOSTATE_REG, state); return 0; }