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 2C046C761AF for ; Wed, 22 Mar 2023 11:03:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229842AbjCVLDL (ORCPT ); Wed, 22 Mar 2023 07:03:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229662AbjCVLDJ (ORCPT ); Wed, 22 Mar 2023 07:03:09 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3223619C7E; Wed, 22 Mar 2023 04:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679482988; x=1711018988; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Wjvnemr7K7GxTkw8tU1ZW+8hQE4iFHIRWuoX+ttiHQY=; b=DGbqoLjvtO/GhREmaL/15LgxnD4iK8taC5hTB+5Zgzu+j7t4utuhjAjr Ye7KhlULQ5ch4Z2MCPIb1ohore7ceqx63qC/IZPTX1qBLHs3dHB+pZbbI J9RUCvwSA9UPn+OajZmFu7Ydw8zgVKA/vzJt4QHIv49GeAecpzP0wNdKc 1MN8hEOhUAWRnP1PieZKJ90Xai27BrTuL48Wzclz2yArCn9OUpMBrYw4G URDg1narBsxBX0Yzq8X9I+1wGA7xwxhngm9VBJDrd3JLSNvBw36zkK6+h AwWgaMXSibs+W6yYpuU7G5tJuC7Y287Y+BqBMt+LrIzmSfI0hk+IK6N9Z A==; X-IronPort-AV: E=McAfee;i="6600,9927,10656"; a="327564765" X-IronPort-AV: E=Sophos;i="5.98,281,1673942400"; d="scan'208";a="327564765" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2023 04:03:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10656"; a="681856602" X-IronPort-AV: E=Sophos;i="5.98,281,1673942400"; d="scan'208";a="681856602" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga002.jf.intel.com with ESMTP; 22 Mar 2023 04:02:58 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pewF4-0076sm-1u; Wed, 22 Mar 2023 13:02:54 +0200 Date: Wed, 22 Mar 2023 13:02:54 +0200 From: Andy Shevchenko To: Matti Vaittinen Cc: Javier Martinez Canillas , Matti Vaittinen , Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Masahiro Yamada , Randy Dunlap , Shreeya Patel , Krzysztof Kozlowski , Jonathan Cameron , devicetree@vger.kernel.org, Zhigang Shi , Maxime Ripard , Heikki Krogerus , Lars-Peter Clausen , Paul Gazzillo , Maxime Ripard , =?iso-8859-1?Q?Ma=EDra?= Canal , Rob Herring , Dmitry Osipenko , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kunit-dev@googlegroups.com, Stephen Boyd , Emma Anholt , Liam Beguin , Greg Kroah-Hartman , Maarten Lankhorst , Thomas Zimmermann , Daniel Vetter , David Gow , "Rafael J. Wysocki" , Brendan Higgins , David Airlie , linux-kselftest@vger.kernel.org Subject: Re: [PATCH v5 0/8] Support ROHM BU27034 ALS sensor Message-ID: References: <87edphnkg1.fsf@minerva.mail-host-address-is-not-set> <8fe9fea1-b7b8-ee46-9534-de7e2b1726f9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8fe9fea1-b7b8-ee46-9534-de7e2b1726f9@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 22, 2023 at 12:59:33PM +0200, Matti Vaittinen wrote: > On 3/22/23 12:34, Javier Martinez Canillas wrote: > > > On Wed, Mar 22, 2023 at 11:05:23AM +0200, Matti Vaittinen wrote: ... > > > > - copy code from DRM test helper instead of moving it to simplify > > > > merging > > > > > > 1) Why do you think this is a problem? > > > 2) How would we avoid spreading more copies of the same code in the future? > > > > > > > > > 1) Merge conflicts is not a bad thing. It shows that people tested their code > > > in isolation and stabilized it before submitting to the upper maintainer. > > > > > > https://yarchive.net/comp/linux/git_merges_from_upstream.html > > > > > > 2) Spreading the same code when we _know_ this, should be very well justified. > > > Merge conflict is an administrative point, and not a technical obstacle to > > > avoid. > > I definitely agree. This is also why I did the renaming and not copying in > the first version. In this version I did still add the subsequent patch 2/8 > - which drops the duplicates from DRM tree. > > > I believe this was suggested by Maxime and the rationale is that by just > > copying the helpers for now, that would make it easier to land instead of > > requiring coordination between different subystems. > > This is correct. > > > Otherwise the IIO tree will need to provide an inmutable branch for the > > DRM tree to merge and so on. > > Or, if we carry the patch 1/8 via self-test tree, then we get even more > players here. > > Still, I am not opposing immutable branch because that would allow fast > applying of the patch 2/8 as well. Longer that is delayed, more likely we > will see more users of the DRM helpers and harder it gets to remove the > duplicates later. > > > I agree with Maxime that a little bit of duplication (that can be cleaned > > up by each subsystem at their own pace) is the path of least resistance. > > I'd say this depends. It probably is the path of least resistance for people > maintaining the trees. It can also be the path of least resistance in > general - but it depends on if there will be no new users for those DRM > helpers while waiting the new APIs being merged in DRM tree. More users we > see in DRM, more effort the clean-up requires. > > I have no strong opinion on this specific case. I'd just be happy to see the > IIO tests getting in preferably sooner than later - although 'soon' and > 'late' does also depend on other factors besides these helpers... Since I'm not a maintainer of either, and one of them requires something, I can't oppose. -- With Best Regards, Andy Shevchenko 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 793C2C6FD1F for ; Wed, 22 Mar 2023 11:03:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CC1F210E913; Wed, 22 Mar 2023 11:03:08 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9E62310E913 for ; Wed, 22 Mar 2023 11:03:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679482987; x=1711018987; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Wjvnemr7K7GxTkw8tU1ZW+8hQE4iFHIRWuoX+ttiHQY=; b=XNDSWmxt/5Mtx+nzc91/Rz2c1o8jygTdjVJQ0vkdKvxGLV0JcSoXby2Q A7E1F7MIE7d5yna3nxl6VI/ZyDU+vhK09TVu+f6U7/8YqcuZl+77RUiR2 ucoPzmY+fqg/hnArDMwtsa15RxrRUYqvl4Wq2z1gRR3boSrApyHNU/Tlv GkRGUzTp30gPUc792F1gC3Dyc01XG0jbJ6hfutPF6EE6AwNjRj7Z6dL11 gNcUTfgFZsc7cHmRyKQ8WmiMh+27dMjMQl2iUn5Nwn5Ka/6lG5SrLP7P1 x5dXNF1NnnPmmKI9egtQ8YQQxl5TmaH5zL2jylNXUGe4Cb/9OMM/bR7OR g==; X-IronPort-AV: E=McAfee;i="6600,9927,10656"; a="327564761" X-IronPort-AV: E=Sophos;i="5.98,281,1673942400"; d="scan'208";a="327564761" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Mar 2023 04:03:07 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10656"; a="681856602" X-IronPort-AV: E=Sophos;i="5.98,281,1673942400"; d="scan'208";a="681856602" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga002.jf.intel.com with ESMTP; 22 Mar 2023 04:02:58 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1pewF4-0076sm-1u; Wed, 22 Mar 2023 13:02:54 +0200 Date: Wed, 22 Mar 2023 13:02:54 +0200 From: Andy Shevchenko To: Matti Vaittinen Subject: Re: [PATCH v5 0/8] Support ROHM BU27034 ALS sensor Message-ID: References: <87edphnkg1.fsf@minerva.mail-host-address-is-not-set> <8fe9fea1-b7b8-ee46-9534-de7e2b1726f9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8fe9fea1-b7b8-ee46-9534-de7e2b1726f9@gmail.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Heikki Krogerus , linux-kselftest@vger.kernel.org, Emma Anholt , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, dri-devel@lists.freedesktop.org, Brendan Higgins , Krzysztof Kozlowski , Zhigang Shi , Masahiro Yamada , =?iso-8859-1?Q?Ma=EDra?= Canal , Javier Martinez Canillas , Dmitry Osipenko , devicetree@vger.kernel.org, Paul Gazzillo , Liam Beguin , Rob Herring , Maxime Ripard , David Gow , kunit-dev@googlegroups.com, Stephen Boyd , Greg Kroah-Hartman , Randy Dunlap , Matti Vaittinen , linux-kernel@vger.kernel.org, Noralf =?iso-8859-1?Q?Tr=F8nnes?= , Thomas Zimmermann , Shreeya Patel , Jonathan Cameron Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Mar 22, 2023 at 12:59:33PM +0200, Matti Vaittinen wrote: > On 3/22/23 12:34, Javier Martinez Canillas wrote: > > > On Wed, Mar 22, 2023 at 11:05:23AM +0200, Matti Vaittinen wrote: ... > > > > - copy code from DRM test helper instead of moving it to simplify > > > > merging > > > > > > 1) Why do you think this is a problem? > > > 2) How would we avoid spreading more copies of the same code in the future? > > > > > > > > > 1) Merge conflicts is not a bad thing. It shows that people tested their code > > > in isolation and stabilized it before submitting to the upper maintainer. > > > > > > https://yarchive.net/comp/linux/git_merges_from_upstream.html > > > > > > 2) Spreading the same code when we _know_ this, should be very well justified. > > > Merge conflict is an administrative point, and not a technical obstacle to > > > avoid. > > I definitely agree. This is also why I did the renaming and not copying in > the first version. In this version I did still add the subsequent patch 2/8 > - which drops the duplicates from DRM tree. > > > I believe this was suggested by Maxime and the rationale is that by just > > copying the helpers for now, that would make it easier to land instead of > > requiring coordination between different subystems. > > This is correct. > > > Otherwise the IIO tree will need to provide an inmutable branch for the > > DRM tree to merge and so on. > > Or, if we carry the patch 1/8 via self-test tree, then we get even more > players here. > > Still, I am not opposing immutable branch because that would allow fast > applying of the patch 2/8 as well. Longer that is delayed, more likely we > will see more users of the DRM helpers and harder it gets to remove the > duplicates later. > > > I agree with Maxime that a little bit of duplication (that can be cleaned > > up by each subsystem at their own pace) is the path of least resistance. > > I'd say this depends. It probably is the path of least resistance for people > maintaining the trees. It can also be the path of least resistance in > general - but it depends on if there will be no new users for those DRM > helpers while waiting the new APIs being merged in DRM tree. More users we > see in DRM, more effort the clean-up requires. > > I have no strong opinion on this specific case. I'd just be happy to see the > IIO tests getting in preferably sooner than later - although 'soon' and > 'late' does also depend on other factors besides these helpers... Since I'm not a maintainer of either, and one of them requires something, I can't oppose. -- With Best Regards, Andy Shevchenko