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 0F29BC43334 for ; Wed, 29 Jun 2022 08:47:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232833AbiF2Irn (ORCPT ); Wed, 29 Jun 2022 04:47:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231558AbiF2Irm (ORCPT ); Wed, 29 Jun 2022 04:47:42 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E293E3CA62; Wed, 29 Jun 2022 01:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656492461; x=1688028461; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=CoZ4DKPpgtGqYVqyBw6YdCVH1MrmDvlVaHZ2vdLt+Ls=; b=kBB8LDa9vDfbWE56LLYDBs1edFzpJ+Xr/+0PKWm6spVqS7s67LL7556m ddNCxoIRk8Slk4SHJfb+n9gMF1oY2o1ArJ+37wu/X3HG5kA34OACed0sU ksqtkxtNp8TcSotEj5ol7krP74jRRlF6prUqCYTqpHlzpIciQV1fDCNld wAc2EpvhKOSzRUEHL46+jGEbi/WoY9coB9oCaloDDgXaAzVLvqnoLQcfp TI5ELPkB+FJY3alwZp3zFDHl21WMML8tuGV6/mK3BWmBJNy5McqA+265F 30fXOgW1LvCYW6xR6FcF6SBLIq6lvqDk2ndNilGX5tZtteIkDldzujQLJ g==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="283068906" X-IronPort-AV: E=Sophos;i="5.92,231,1650956400"; d="scan'208";a="283068906" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2022 01:47:41 -0700 X-IronPort-AV: E=Sophos;i="5.92,231,1650956400"; d="scan'208";a="647303570" Received: from dsummer-mobl.ger.corp.intel.com ([10.252.38.121]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jun 2022 01:47:38 -0700 Date: Wed, 29 Jun 2022 11:47:36 +0300 (EEST) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= To: Andy Shevchenko cc: "open list:SERIAL DRIVERS" , Greg KH , Jiri Slaby , Andy Shevchenko , Linux Kernel Mailing List Subject: Re: [PATCH 4/4] serial: 8250_dw: Rework ->serial_out() LCR write retry logic In-Reply-To: Message-ID: <29b084c-183b-4a84-2376-2c88eff7d5a@linux.intel.com> References: <20220628134234.53771-1-ilpo.jarvinen@linux.intel.com> <20220628134234.53771-5-ilpo.jarvinen@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-624552388-1656489970=:1529" 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-624552388-1656489970=:1529 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 28 Jun 2022, Andy Shevchenko wrote: > On Tue, Jun 28, 2022 at 3:43 PM Ilpo Järvinen > wrote: > > > > Currently dw8250_verify_write() (was dw8250_check_lcr()) nullifies the > > benefit from differentiated ->serial_out() by having big if tree to > > select correct write type. > > > > Rework the logic such that the LCR write can be retried within the > > relevant ->serial_out() handler: > > 1. Move retries counter on the caller level and pass as pointer to > > dw8250_verify_write() > > 2. Make dw8250_verify_write() return bool > > 3. Retry the write on caller level (if needed) > > I'm wondering if it's possible to utilize one of iopoll.h macro here > instead of copying retries and that not-so-obvious IO poll write. Eh, are you suggesting I should do write as a side-effect inside one of the iopoll.h macros? Because those available seem to only read? Or should I create another macro there which writes too? -- i. --8323329-624552388-1656489970=:1529--