Received: by 2002:a05:6500:1b45:b0:1f5:f2ab:c469 with SMTP id cz5csp485622lqb; Wed, 17 Apr 2024 02:16:37 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCV1FdastqjH/O6/DV+Alzuw76SHU4eJ4DCPsD+RkyYMSwD+RWL6muNInNHCjEYOCvLSK+1hTFVc9bwwgDSX3slDi2WgeIpwPOZM2zvVLw== X-Google-Smtp-Source: AGHT+IHfHn4CUA22Ik4FKR3y7SIihBlPS4/S8yoAvkzN7XVn00YI1AXnLFv1YO51VblXO0N4zm6/ X-Received: by 2002:a05:6870:5589:b0:22e:ddd1:53ab with SMTP id qj9-20020a056870558900b0022eddd153abmr18381038oac.41.1713345397099; Wed, 17 Apr 2024 02:16:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713345397; cv=pass; d=google.com; s=arc-20160816; b=MvMjm7CoBX5/d5DJmSyhLshB90iWo5iswtRuUB+oNcLIVDR84TFr2QjrorpkbUyWaF HbnFmweiwVvd+MMpdl8oPuh1uAEiEjTzd9uyJSK9B7SBIj7Lr5tGpXs4vxWtN/vjHjzv zMgtK4NAQKdofBHGSAbDpkpRhJ88+vp+qyjLiIDf0UaAXsm4k14ML79CWzQgMO1McRcj MC0Pqzvb3xi7GUZfXawAYtdrdZiebD1Ydlt4x7iwYKyqlC36kXtgztO4eYScfDBDDJNl IuiXhaLr4DHOvLxCbIrZrBb3k/gYyaHFxzlfgZ4+BfxnznsTH9uGwPj0GGjHNPDg39yW hhcA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:in-reply-to:subject:cc:to:date:from :dkim-signature; bh=AP/LWbNCE1EEY6vIn01WNvCGGI5mW90FHd7Ie+hxE1k=; fh=fGTo4NLE0nVeS5GudB5/rSy/43bxnonXb7xyfNLGx+w=; b=K4Gx7xkVBgmnQPTvuPk474q2R7BQ5sQNm8iZRRaozekx2B/g4NfLgr0m5XFf2frEaT FU5bMobnwTBLlvMXOrNGDQ2eyho10N3PDsPwAfEprxFqmvr8mwpPf2xyApZkNWQPODID eo9+cFgPfO0SLiiGlSl+JOREx4JIjNkaCyK3QFl9wGcHg2bKLcLoOwJw6q3XWCYgvMR9 66BCpFWypE2uxh4EJdIfJJdItENnUiuVFCJwNYqR+w1EE6Jsdy0PgoQ8sQnZm6ygWhk5 P297ozP6W/7T5XqSHJUyROIf+wSFpCOw5pllDv9DVMsu06uwvOcj/D3nzURFMMKEHy8k HE7w==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W6JgFA7d; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-148111-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-148111-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id o15-20020a62f90f000000b006ecf3964f66si11237350pfh.219.2024.04.17.02.16.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Apr 2024 02:16:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-148111-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=W6JgFA7d; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-148111-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-148111-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 04769B23967 for ; Wed, 17 Apr 2024 08:14:00 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E9F2D7D095; Wed, 17 Apr 2024 08:13:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="W6JgFA7d" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 8FFB46A02E; Wed, 17 Apr 2024 08:13:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713341610; cv=none; b=nLyGyEcBeejDwAA9JnrfUdtxwYMBwH6Tlico642CGjxqNPMxFWI40VHZ6Q/6pvBJActlohk5XP8wipwPDB/APjKQewMlkLo9AbMyvmhCrcBCq/xc+zMxdwy60rHE9gUAVAXijPs7dCBo6U1sNAwXv3cf8tVPQcgS0WjaNUhk7Jk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713341610; c=relaxed/simple; bh=Fx5PXmOnt+cu8UKI/4+7CAwyifLLmMRP4sxlDsBLIqg=; h=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=at2xlLvD0BCCd+dt2x0OPeleO4bzXd5c6kmxHaYLmwsnews6M4X5ZQZso1+wb2eBLVQbu9mcge/QiEVTwgXVqPBwUvK5E/UbrF++UAVU5nsX7sk0LUtTCcMEHok8Ri9WMLFqe4P7fLkSYw6OpVzxAR9+c10FG/JD49ZY8DfHXSg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=W6JgFA7d; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713341608; x=1744877608; h=from:date:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=Fx5PXmOnt+cu8UKI/4+7CAwyifLLmMRP4sxlDsBLIqg=; b=W6JgFA7drF0o6KTbkn2f3q8ilIHT3v/MK8ckABXMniBsVUYVO4n3F/0O 5sqjJee8PWiqzw+9QVwpT0nW/yCNau0YROe0N+jsWdpSgaJDarEmm9UhW ujTjn6DpunL+g21kB4QUyKTOwVtdxrT4bCrddAL2pS3WmD82yB4DlInBD hmdNXcduqGElOhF1FXQGVbAU8SW/GPJaAA3pApX6hYN77uBgaEO1o42pO 0q5/Nk+6Fsu3cjuqGaqBvBE60QGl+7AQhDMPiR2c/anHt4Q4G84cO5WYd pEvVV98/bKROfLZaFhnCJoIhujC5cGGoIDRwQAmHmmBpnzYvU1EhFRAwR w==; X-CSE-ConnectionGUID: LkPksYK3SDuravLB6emjNw== X-CSE-MsgGUID: S+BcJxjCTyqHbQ1rbKdVOg== X-IronPort-AV: E=McAfee;i="6600,9927,11046"; a="8679119" X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="8679119" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Apr 2024 01:13:27 -0700 X-CSE-ConnectionGUID: 4i3Fn0c/QZGSzXPKPX/6Uw== X-CSE-MsgGUID: K1VgBYjtTfGYPpnA1JUHjg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,208,1708416000"; d="scan'208";a="22616220" Received: from ijarvine-desk1.ger.corp.intel.com (HELO localhost) ([10.245.247.35]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Apr 2024 01:13:25 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Wed, 17 Apr 2024 11:13:21 +0300 (EEST) To: Michael Pratt cc: Andy Shevchenko , LKML , linux-serial , Greg Kroah-Hartman , Jiri Slaby , Wander Lairson Costa , Vamshi Gajjela Subject: Re: [PATCH v2 3/3] serial: 8250: Set fifo timeout using uart_fifo_timeout() In-Reply-To: Message-ID: <7e66eafe-902c-38ab-b624-d9386c1bcd22@linux.intel.com> References: <20240416182741.22514-1-mcpratt@pm.me> <20240416182741.22514-4-mcpratt@pm.me> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Tue, 16 Apr 2024, Michael Pratt wrote: > On Tuesday, April 16th, 2024 at 14:57, Andy Shevchenko wrote: > > > > unsigned int status, tmout = 10000; > > > > > > - /* Wait up to 10ms for the character(s) to be sent. / > > > + / Wait for a time relative to buffer size and baud */ > > > + if (up->fifo_enable && up->port.timeout) > > > + tmout = jiffies_to_usecs(up->port.timeout); > > > > > > Why do we still use that default? Can't we calculate timeout even for\ > > FIFO-less / FIFO-disabled devices? Yes we definitely should be able to. Unfortunately these patches just keep coming back not in the form that follows the review feedback, but they come up their own way of doing things which is way worse and ignores the given feedback. > Maybe it's possible that there is some kind of rare case where the LSR register > is not working or not configured properly for a device in which support > is being worked on...without a timeout, that would result in an infinite loop. "without a timeout" is not what Andy said. He said you should always have a timeout, regardless of there being FIFO or not. And that timeout should be derived in the same manner from baudrate and FIFO size (to address the cases w/o FIFO, the fifosize should be lower bounded to 1 while calculating the FIFO timeout). > AFAIK, when everything is working properly, there is no such thing as needing > a timeout for a uart device without fifo, as every single byte written would trigger > an interrupt anyway. While I agree the general principle, that this is backup that should not even be needed, the statement is partly incorrect. We don't get interrupts during console write because they're disabled. But LSR should still change and allow progress without the backup timeout. -- i.