From nobody Thu May 22 02:42:27 2025 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4b2syZ71FLz5wx29; Thu, 22 May 2025 02:42:30 +0000 (UTC) (envelope-from rpokala@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4b2syZ5r8Sz3mtv; Thu, 22 May 2025 02:42:30 +0000 (UTC) (envelope-from rpokala@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747881750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aLjWoJ6YZbCeFxq88hhkdpmz0a+A0WY9zv6Zw5BL52o=; b=eb2JllwSydiQ0xBRi+LySf82YGtQvCvl/5Q4IdHYYbKYOgNRL/xaQUmz0oBG/5AizUiqnw HMIZZO5BEOV6bN7Zhc2tnx2Na7TumAHUigMDUtAecpO9UebyEpFXBSDYpUKWwrgKmSdC15 JpFNJUXgGSrW87L+YA0rhJLnDE0pCEdv/kl/+UucG9RnvgZHLYCDr0vz0WKBpmDaaoMmf/ mgA3UOAGQDwDCQRZL04CnQTTCf9n3kEhFmGnirvYtPKQL8h3pbLTWfBk611icSv3znIA8e blIc3INwTDy6OhB1lsB9202GdSS0xkFmXNKynqeStqgW6OEnMY99+x7A4ujoKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1747881750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aLjWoJ6YZbCeFxq88hhkdpmz0a+A0WY9zv6Zw5BL52o=; b=JPDFqsI2j1l3N6ysHl+eMf+aaYIg8maPUt17qDL2dOGUKNixhWNOzI+849zDAfEtC4FSEI FC14OKn+4Qtr/5I2C6r6pn5TP692rbBZDcPcueiX0S/zEbzVHRELvWYZMyMq5gEHr9WCeq HnkUgQHlQl382UQ62HnmlI4kOLjmnTOALFEJpmNJy+LDTvIl6UchqE1t2hjh05bEu+IpMr iutDtG5QwCCA/hLM73y+pJPZwCL8hLXeCJG25yum4sx27HJU6SQkiW8FMHe9VIKMzMmhpb AdX9TJA+dcuyRWsckUDZiPdkXypevKeoXt6YQRlyQ5jT99mm3O2kxK6bOhA+sg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1747881750; a=rsa-sha256; cv=none; b=arHE8UkNu2VL6ikUYvaSQQ60VEQH+HAZjfx5tzloCtBmdg3YXbIIiYtzwGOQjFQAhM6UR8 vJAbzkwHMCesGdRYXBq/GlCwla1+GdR2nmjbM/7LNrVAB2Z6wvzrcUOego+qjSf83VzmW9 ZCwLnWtJsJlgzSn/ZAoOFMYBI8bwelAFWxa8DxlEwwPTjbHKw66ZITW4GXwdrBSFIIGp30 fOkem+JMZbZPsxKuf4M1HAjJru/mbRJK3dmUVDLc2ImazWPsZdSlDMg8FsIPA8VXi8O80s ukSrc8Dnn1BPVMRhyj6AIT9KkP+ov+87ts4ZdWu0X3UBYs24LsRmgRegNNxXvQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from [172.20.3.247] (unknown [50.222.117.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: rpokala) by smtp.freebsd.org (Postfix) with ESMTPSA id 4b2syZ4F71zMx5; Thu, 22 May 2025 02:42:30 +0000 (UTC) (envelope-from rpokala@freebsd.org) User-Agent: Microsoft-MacOutlook/16.97.25051816 Date: Wed, 21 May 2025 22:42:27 -0400 Subject: Re: 0d2fd5b99c95 - main - ns8250: use LSR_THRE instead of LSR_TEMT for checking tx flush From: Ravi Pokala To: Andriy Gapon , , , , Message-ID: <37BF51C0-C631-493F-B3AF-3AA9FC32551B@panasas.com> Thread-Topic: 0d2fd5b99c95 - main - ns8250: use LSR_THRE instead of LSR_TEMT for checking tx flush References: <202505201457.54KEvD1r053951@gitrepo.freebsd.org> <1a11f640-be62-4f4e-b537-70806ac54831@FreeBSD.org> In-Reply-To: List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > Additionally, ns8250_bus_transmit uses ns8250_drain(UART_DRAIN_TRANSMITTE= R) in broken_txfifo case. FWIW, I just had to enable the 'hw.broken_txfifo=3D1' workaround on physical = hardware; see [Bug 286703]. Thanks, Ravi (rpokala@) =EF=BB=BF-----Original Message----- From: > on behalf of Andriy Gapon > Date: Tuesday, May 20, 2025 at 17:12 To: >, >, >, > Subject: Re: git: 0d2fd5b99c95 - main - ns8250: use LSR_THRE instead of LSR= _TEMT for checking tx flush On 20/05/2025 21:28, Michal Meloun wrote: >=20 >=20 > On 20.05.2025 16:57, Andriy Gapon wrote: >> The branch main has been updated by avg: >> >> URL: https://cgit.FreeBSD.org/src/commit/? =20 >> id=3D0d2fd5b99c95329085d0700a4dd38507a054a50d >> >> commit 0d2fd5b99c95329085d0700a4dd38507a054a50d >> Author: Andriy Gapon > >> AuthorDate: 2024-11-10 11:15:30 +0000 >> Commit: Andriy Gapon > >> CommitDate: 2025-05-20 14:55:18 +0000 >> >> ns8250: use LSR_THRE instead of LSR_TEMT for checking tx flush >> LSR_TEMT bit is set if both transmit hold and shift registers are >> empty, but the flush command flushes only the hold register. > I don't think that's true.=20 I am not sure to which part of the commit message your "that" refers to, so= I'll=20 try to justify everything. T_H_R_E - transmitter holding register empty T_EMPT - transmitter empty All hardware documentation that I have around describes those bits like tha= t. We do not have direct control over the shift register, hardware clears it a= fter=20 sending. > Imho, ns8250_flush() is used also before changing > baud rate, so we need to ensure that all bits are flushed, including the > transmit register. That's an interesting point. My intention was actually to avoid bogus "FCR is broken" message which can=20 happen because of a race between the UART transmission and code execution. I think that LSR_THRE is proper for checking that FCR works. But to actually detect and ensure that all transmission has completed we sh= ould=20 use LSR_TEMT like you say. At the same time, this UART flush is not like stdout flush, of course, wher= e we=20 ensure that all buffered data is transmitted. For UART, we just clear the F= IFO=20 and the holding register. So, I am not sure if polling for empty transmitte= r is=20 important. Besides, I do not see the code which would flush transmitter when parameter= s are=20 changing. I can find only two places where UART_FLUSH_TRANSMITTER is passed: - ns8250_bus_attach - ns8250_bus_probe Additionally, ns8250_bus_transmit uses ns8250_drain(UART_DRAIN_TRANSMITTER)= in=20 broken_txfifo case. P.S. Maybe I don't understand the code, but UART_FLUSH_RECEIVER in ns8250_bus_at= tach=20 looks strange to me. It's one thing to flush data while in the loop-back mo= de,=20 but I think that in ns8250_bus_attach the hardware is fully set up to recei= ve=20 data from the outside world. So, how can we hope to drain all of it and to=20 reliably detect whether FIFO flushing works. I mean that something on the o= ther=20 end could be continuously transmitting. --=20 Andriy Gapon