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=-0.8 required=3.0 tests=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 ECCC1C43603 for ; Tue, 17 Dec 2019 13:25:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C988E218AC for ; Tue, 17 Dec 2019 13:25:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727310AbfLQNZg (ORCPT ); Tue, 17 Dec 2019 08:25:36 -0500 Received: from mga07.intel.com ([134.134.136.100]:34728 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726164AbfLQNZg (ORCPT ); Tue, 17 Dec 2019 08:25:36 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 05:25:35 -0800 X-IronPort-AV: E=Sophos;i="5.69,325,1571727600"; d="scan'208";a="209700078" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 05:25:31 -0800 From: Jani Nikula To: Lee Jones , Hans de Goede Cc: Maarten Lankhorst , Joonas Lahtinen , Rodrigo Vivi , Ville =?utf-8?B?U3lyasOkbMOk?= , "Rafael J . Wysocki" , Len Brown , Andy Shevchenko , linux-acpi@vger.kernel.org, intel-gfx , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight In-Reply-To: <20191217081127.GI18955@dell> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20191210085111.GQ3468@dell> <20191212084546.GA3468@dell> <20191212155209.GC3468@dell> <4d07445d-98b1-f23c-0aac-07709b45df78@redhat.com> <20191213082734.GE3468@dell> <20191216093016.GE3648@dell> <20191217081127.GI18955@dell> Date: Tue, 17 Dec 2019 15:25:29 +0200 Message-ID: <87immfyth2.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Tue, 17 Dec 2019, Lee Jones wrote: > On Mon, 16 Dec 2019, Hans de Goede wrote: > >> Hi, >> >> Doing immutable branches assumes that there is a base point, >> e.g. 5.5-rc1 where the immutable branch can then be based on and >> that the branch can then be merged without issues into both subsystems. >> >> drm is constantly evolving to deal with and mostly catch up with new >> hardware as both GPUs and display-pipelines are evolving quite rapidly >> atm drm-intel-next has about 400 commits on top of 5.5-rc1 so for an >> immutable branch I can either base it on drm-intel-next which >> violates your request for a clean minimal branch to merge; or I can >> base it on 5.5-rc1 which leads to a big chance of problems when >> merging it given to large amount of churn in drm-intel-next. > > This is a *slightly* more compelling reason than the ones you've > previously provided. > >> So instead of the normal case of 2 subsystems seeing some changes >> on both side the case we have here is a part of a file which has >> not changed since 2015-06-26 in one subsys (and changing only >> a single line there!) and OTOH we have bigger changes to a subsys >> which see 400 patches land in the first week since rc1 . > > This is not. > >> I hope that you agree that in this case given the large amount of >> churn in drm-intel-next it makes since to just straight forward >> apply these patches on top of drm-intel-next. > > I have Acked this patch, but remember *this* is the exception rather > than the rule. If/when we have a case where a contributor works > cross-subsystem with DRM and the code/file adapted is live (more > likely to change), I will have to insist on an immutable branch > strategy. DRM will have to deal with that appropriately. Hi, thanks for the ack and reaching an agreement with Hans, and sorry for not responding earlier. It's not unusual for us to have topic branches for cross-subsystem or cross-driver changes, and I think usually we try to be accommodating in merging stuff through whichever tree it makes most sense. In fact my ack to do just that was my first response on this series [1]. So I don't really know why the fuss. We'll anyway deal with any cross-subsystem series on a case by case basis, depending on what makes most sense, and what suits all maintainers involved. Thanks again, Jani. [1] http://mid.mail-archive.com/87pnhnyir8.fsf@intel.com -- Jani Nikula, Intel Open Source Graphics Center 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=-0.8 required=3.0 tests=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 B19B4C2D0CD for ; Tue, 17 Dec 2019 13:25:38 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 9161521582 for ; Tue, 17 Dec 2019 13:25:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9161521582 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CF3636E9DD; Tue, 17 Dec 2019 13:25:37 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 443CE6E9DD; Tue, 17 Dec 2019 13:25:36 +0000 (UTC) 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/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 05:25:35 -0800 X-IronPort-AV: E=Sophos;i="5.69,325,1571727600"; d="scan'208";a="209700078" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 05:25:31 -0800 From: Jani Nikula To: Lee Jones , Hans de Goede Subject: Re: [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight In-Reply-To: <20191217081127.GI18955@dell> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20191210085111.GQ3468@dell> <20191212084546.GA3468@dell> <20191212155209.GC3468@dell> <4d07445d-98b1-f23c-0aac-07709b45df78@redhat.com> <20191213082734.GE3468@dell> <20191216093016.GE3648@dell> <20191217081127.GI18955@dell> Date: Tue, 17 Dec 2019 15:25:29 +0200 Message-ID: <87immfyth2.fsf@intel.com> MIME-Version: 1.0 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: intel-gfx , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-acpi@vger.kernel.org, Rodrigo Vivi , Andy Shevchenko , Len Brown Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, 17 Dec 2019, Lee Jones wrote: > On Mon, 16 Dec 2019, Hans de Goede wrote: > >> Hi, >> >> Doing immutable branches assumes that there is a base point, >> e.g. 5.5-rc1 where the immutable branch can then be based on and >> that the branch can then be merged without issues into both subsystems. >> >> drm is constantly evolving to deal with and mostly catch up with new >> hardware as both GPUs and display-pipelines are evolving quite rapidly >> atm drm-intel-next has about 400 commits on top of 5.5-rc1 so for an >> immutable branch I can either base it on drm-intel-next which >> violates your request for a clean minimal branch to merge; or I can >> base it on 5.5-rc1 which leads to a big chance of problems when >> merging it given to large amount of churn in drm-intel-next. > > This is a *slightly* more compelling reason than the ones you've > previously provided. > >> So instead of the normal case of 2 subsystems seeing some changes >> on both side the case we have here is a part of a file which has >> not changed since 2015-06-26 in one subsys (and changing only >> a single line there!) and OTOH we have bigger changes to a subsys >> which see 400 patches land in the first week since rc1 . > > This is not. > >> I hope that you agree that in this case given the large amount of >> churn in drm-intel-next it makes since to just straight forward >> apply these patches on top of drm-intel-next. > > I have Acked this patch, but remember *this* is the exception rather > than the rule. If/when we have a case where a contributor works > cross-subsystem with DRM and the code/file adapted is live (more > likely to change), I will have to insist on an immutable branch > strategy. DRM will have to deal with that appropriately. Hi, thanks for the ack and reaching an agreement with Hans, and sorry for not responding earlier. It's not unusual for us to have topic branches for cross-subsystem or cross-driver changes, and I think usually we try to be accommodating in merging stuff through whichever tree it makes most sense. In fact my ack to do just that was my first response on this series [1]. So I don't really know why the fuss. We'll anyway deal with any cross-subsystem series on a case by case basis, depending on what makes most sense, and what suits all maintainers involved. Thanks again, Jani. [1] http://mid.mail-archive.com/87pnhnyir8.fsf@intel.com -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel 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=-0.8 required=3.0 tests=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 2ED58C43603 for ; Tue, 17 Dec 2019 13:25:40 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 0F49321835 for ; Tue, 17 Dec 2019 13:25:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F49321835 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 089D06E9E0; Tue, 17 Dec 2019 13:25:38 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 443CE6E9DD; Tue, 17 Dec 2019 13:25:36 +0000 (UTC) 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/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 05:25:35 -0800 X-IronPort-AV: E=Sophos;i="5.69,325,1571727600"; d="scan'208";a="209700078" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2019 05:25:31 -0800 From: Jani Nikula To: Lee Jones , Hans de Goede In-Reply-To: <20191217081127.GI18955@dell> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20191210085111.GQ3468@dell> <20191212084546.GA3468@dell> <20191212155209.GC3468@dell> <4d07445d-98b1-f23c-0aac-07709b45df78@redhat.com> <20191213082734.GE3468@dell> <20191216093016.GE3648@dell> <20191217081127.GI18955@dell> Date: Tue, 17 Dec 2019 15:25:29 +0200 Message-ID: <87immfyth2.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH 2/3] mfd: intel_soc_pmic: Rename pwm_backlight pwm-lookup to pwm_pmic_backlight X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-acpi@vger.kernel.org, Andy Shevchenko , Len Brown Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 17 Dec 2019, Lee Jones wrote: > On Mon, 16 Dec 2019, Hans de Goede wrote: > >> Hi, >> >> Doing immutable branches assumes that there is a base point, >> e.g. 5.5-rc1 where the immutable branch can then be based on and >> that the branch can then be merged without issues into both subsystems. >> >> drm is constantly evolving to deal with and mostly catch up with new >> hardware as both GPUs and display-pipelines are evolving quite rapidly >> atm drm-intel-next has about 400 commits on top of 5.5-rc1 so for an >> immutable branch I can either base it on drm-intel-next which >> violates your request for a clean minimal branch to merge; or I can >> base it on 5.5-rc1 which leads to a big chance of problems when >> merging it given to large amount of churn in drm-intel-next. > > This is a *slightly* more compelling reason than the ones you've > previously provided. > >> So instead of the normal case of 2 subsystems seeing some changes >> on both side the case we have here is a part of a file which has >> not changed since 2015-06-26 in one subsys (and changing only >> a single line there!) and OTOH we have bigger changes to a subsys >> which see 400 patches land in the first week since rc1 . > > This is not. > >> I hope that you agree that in this case given the large amount of >> churn in drm-intel-next it makes since to just straight forward >> apply these patches on top of drm-intel-next. > > I have Acked this patch, but remember *this* is the exception rather > than the rule. If/when we have a case where a contributor works > cross-subsystem with DRM and the code/file adapted is live (more > likely to change), I will have to insist on an immutable branch > strategy. DRM will have to deal with that appropriately. Hi, thanks for the ack and reaching an agreement with Hans, and sorry for not responding earlier. It's not unusual for us to have topic branches for cross-subsystem or cross-driver changes, and I think usually we try to be accommodating in merging stuff through whichever tree it makes most sense. In fact my ack to do just that was my first response on this series [1]. So I don't really know why the fuss. We'll anyway deal with any cross-subsystem series on a case by case basis, depending on what makes most sense, and what suits all maintainers involved. Thanks again, Jani. [1] http://mid.mail-archive.com/87pnhnyir8.fsf@intel.com -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx