Subject: Re: [PATCH] serial: 8250_bcm7271: UART errors after resuming from S2
To:     Al Cooper <alcooperx@gmail.com>, linux-kernel@vger.kernel.org
Cc:     bcm-kernel-feedback-list@broadcom.com,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>, linux-serial@vger.kernel.org
References: <20211201201402.47446-1-alcooperx@gmail.com>
From:   Florian Fainelli <f.fainelli@gmail.com>
Message-ID: <847997ca-1a24-485e-010b-9cba35ff2b0c@gmail.com>
Date:   Wed, 1 Dec 2021 12:39:31 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <20211201201402.47446-1-alcooperx@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 12/1/21 12:14 PM, Al Cooper wrote:
> There is a small window in time during resume where the hardware
> flow control signal RTS can be asserted (which allows a sender to
> resume sending data to the UART) but the baud rate has not yet
> been restored. This will cause corrupted data and FRAMING, OVERRUN
> and BREAK errors. This is happening because the MCTRL register is
> shadowed in uart_port struct and is later used during resume to set
> the MCTRL register during both serial8250_do_startup() and
> uart_resume_port(). Unfortunately, serial8250_do_startup()
> happens before the UART baud rate is restored. The fix is to clear
> the shadowed mctrl value at the end of suspend and restore it at the
> end of resume.
> 
> Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver")
> Signed-off-by: Al Cooper <alcooperx@gmail.com>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian