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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8257C433DF for ; Mon, 17 Aug 2020 12:29:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B17912076E for ; Mon, 17 Aug 2020 12:29:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728360AbgHQM3Y (ORCPT ); Mon, 17 Aug 2020 08:29:24 -0400 Received: from mga11.intel.com ([192.55.52.93]:5968 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726830AbgHQM3P (ORCPT ); Mon, 17 Aug 2020 08:29:15 -0400 IronPort-SDR: UFF3/rqxtPBecHD/6dwzeP51XCClllW4D/7L3W3Qt5ppdUhM4lhym/553On/+Pkdl4OW51W/1o wLuXiEImBWaw== X-IronPort-AV: E=McAfee;i="6000,8403,9715"; a="152333069" X-IronPort-AV: E=Sophos;i="5.76,322,1592895600"; d="scan'208";a="152333069" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Aug 2020 05:29:15 -0700 IronPort-SDR: jS+1ltab7SxXB6uXxedbLG5oEfT32ddmRqd0rplvi7ACK6kh5dkad/VFRWymy4GiycjmIeIx25 XL5lLibg1aMw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,322,1592895600"; d="scan'208";a="326393088" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga008.jf.intel.com with ESMTP; 17 Aug 2020 05:29:12 -0700 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1k7eGF-009JMR-By; Mon, 17 Aug 2020 15:29:11 +0300 Date: Mon, 17 Aug 2020 15:29:11 +0300 From: Andy Shevchenko To: Sakari Ailus Cc: Jonathan Corbet , joe@perches.com, Bingbu Cao , Yong Zhi , Bingbu Cao , Tian Shu Qiu , linux-media@vger.kernel.org, Mauro Carvalho Chehab Subject: Re: [PATCH v1 6/7] media: ipu3-cio2: Use readl_poll_timeout() helper Message-ID: <20200817122911.GN1891694@smile.fi.intel.com> References: <20200814163017.35001-1-andriy.shevchenko@linux.intel.com> <20200814163017.35001-6-andriy.shevchenko@linux.intel.com> <6b739304-7d12-016f-f42a-089c8fe7efac@linux.intel.com> <20200817094436.GF1891694@smile.fi.intel.com> <20200817111316.GH24582@paasikivi.fi.intel.com> <20200817112006.GH1891694@smile.fi.intel.com> <20200817112746.GI24582@paasikivi.fi.intel.com> <20200817113322.GI1891694@smile.fi.intel.com> <20200817115538.GJ24582@paasikivi.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200817115538.GJ24582@paasikivi.fi.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org On Mon, Aug 17, 2020 at 02:55:38PM +0300, Sakari Ailus wrote: > On Mon, Aug 17, 2020 at 02:33:22PM +0300, Andy Shevchenko wrote: > > On Mon, Aug 17, 2020 at 02:27:47PM +0300, Sakari Ailus wrote: > > > On Mon, Aug 17, 2020 at 02:20:06PM +0300, Andy Shevchenko wrote: > > > > On Mon, Aug 17, 2020 at 02:13:16PM +0300, Sakari Ailus wrote: > > > > > On Mon, Aug 17, 2020 at 12:44:36PM +0300, Andy Shevchenko wrote: > > > > > > On Mon, Aug 17, 2020 at 05:27:33PM +0800, Bingbu Cao wrote: > > > > > > > On 8/15/20 12:30 AM, Andy Shevchenko wrote: > > > > > > > > We may use special helper macro to poll IO till condition or timeout occurs. > > > > > > > > > > > > > > + ret = readl_poll_timeout(dma, value, value & CIO2_CDMAC0_DMA_HALTED, 4000, 2000000); > > > > > > > > > > > > > > This line is too long, need a break, others look good for me. > > > > > > > > > > > > checkpatch doesn't complain, but if you insist, I'll split it in v2. > > > > > > > > > > The coding style hasn't changed, it's just the checkpatch.pl warning that > > > > > has. > > > > > > > > Joe, it seems we have inconsistency now between checkpatch and coding style. > > > > Shouldn't we revert 100 limit warning to 80? > > > > > > There are sometimes genuine reasons for having longer lines than 80, and > > > depending on the code, that happens more often in some places than > > > elsewhere. This tended to generate lots of checkpatch.pl warnings in the > > > past. > > > > > > While I didn't see the patch removing the 80 chars per line limit until it > > > made the news, I think it was a quite reasonable compromise. > > > > But doesn't it make harder life for reviewers like you? You have to keep in > > mind all these inconsistencies and rule either way. > > > > That said, we either would fix the doc, or revert the checkpatch change. > > I don't think the documentation should be changed. There *are* reasons for > the 80-column limit. Although the exact number can be connected to the > width of traditional text terminals, using very long lines makes reading > text harder. IOW, there's a connection to the same reason why wide > newspaper articles are split into several columns. > Would it be reasonable if checkpatch.pl warned about exceeding 80-column > limits if such lines are rare or nonexistent in the same file? I don't think so. If somebody decides to *gradually* move to 100 limit in the driver, it will be painful with all these new old warnings. -- With Best Regards, Andy Shevchenko