From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7504CC433FE for ; Mon, 7 Nov 2022 11:50:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231667AbiKGLup (ORCPT ); Mon, 7 Nov 2022 06:50:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231589AbiKGLuo (ORCPT ); Mon, 7 Nov 2022 06:50:44 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F00941A38E; Mon, 7 Nov 2022 03:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667821844; x=1699357844; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=XpXWt8wuTNay08we0kpVyVUQSkZOZQKYsYrZtuRP7q8=; b=I9mZzES2MP2IwtQGlczr15X9hIlrpg9wCuvekHNRmup1SvQakH2Uar2t mk7j0BFpw0B158p+EGBvkhfnVnbpepDCVdEaK8iynOiQrMdtLsFTwUsJ5 +jRoLQ2BKfSvv5S4DWt3bkI81vS0JzvARw+D5m8AaaB+d62k6fIY4TeZ+ 1czgsYLZvuKl3NoC9BuUW5/xzZajOJiuVqLHC7hZ9/F6RxC96j6HBOZ7l 7iKQfh8vnyt8Wz7Fcj6BZY8crM7+E9PYXD3IQ+6/HC+orkqKfgGpmvJBo FfdQVHoJ+WZuDKycHP8zLPMAJNq8hiCqRGjLhIrCXza6HzhNsinBu0vtI A==; X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="311525697" X-IronPort-AV: E=Sophos;i="5.96,143,1665471600"; d="scan'208";a="311525697" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2022 03:50:43 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="635880143" X-IronPort-AV: E=Sophos;i="5.96,143,1665471600"; d="scan'208";a="635880143" Received: from gschoede-mobl1.ger.corp.intel.com ([10.252.46.211]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2022 03:50:41 -0800 Date: Mon, 7 Nov 2022 13:50:38 +0200 (EET) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Andy Shevchenko cc: Greg Kroah-Hartman , Jiri Slaby , linux-serial , LKML Subject: Re: [PATCH 0/4] 8250: DMA Fixes In-Reply-To: Message-ID: References: <20221107110708.58223-1-ilpo.jarvinen@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-958723828-1667820915=:56477" Content-ID: Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-958723828-1667820915=:56477 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: <3087fb9-ada7-8275-9bc3-a0b62ca08322@linux.intel.com> On Mon, 7 Nov 2022, Andy Shevchenko wrote: > On Mon, Nov 07, 2022 at 01:07:04PM +0200, Ilpo Järvinen wrote: > > Here are a number of 8250 DMA related fixes. The last one seems the > > most serious problem able to corrupt the payload ordering. > > > > Ilpo Järvinen (4): > > serial: 8250: Fall back to non-DMA Rx if IIR_RDI occurs > > 8250_port? > > > serial: 8250_lpss: Configure DMA also w/o DMA filter > > serial: 8250_lpss: Use 16B DMA burst with Elkhart Lake > > serial: 8250: Flush DMA Rx on RLSI > > 8250_port? Why? To me this 8250_core/port split is still integral part of the same 8250 even if they're in the end technically loaded into different modules or the code is in a different file. There's even some trickery to access internals of the other part to workaround the circular module dependency logic that would otherwise prevent the split (like we learned not so long time ago with that setup_irq change). I can start to use 8250_port if you insist but it seems pointless 5 extra characters out from a resource that is scarse to begin with, IMHO (the summary line is not that long). -- i. --8323329-958723828-1667820915=:56477--