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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 36A4CC4332E for ; Wed, 27 Jan 2021 09:00:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D57BC20756 for ; Wed, 27 Jan 2021 09:00:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234245AbhA0JAT (ORCPT ); Wed, 27 Jan 2021 04:00:19 -0500 Received: from mail.kernel.org ([198.145.29.99]:33802 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233746AbhA0I60 (ORCPT ); Wed, 27 Jan 2021 03:58:26 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id BC32120759; Wed, 27 Jan 2021 08:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1611737863; bh=CRsnxHURAngp2eekJSNGPVdgsCZ9RsnCKwPFaU4Sd6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=zRObluJJlLWARaRpMYCN84a10arkVxS14A/oUfJ5UIAc5qjUwDPxyTz0p+S3i6468 yO4j8HagADFhCkb5Bk9l0N7MJm/Npg12rxCX0U/rkl0ZxNxWpuHIGwOALhrSmqaNgs Hm/BAwV6hQrGeMdJhC2OPnaeyEP2lg2iCtSMs8HI= Date: Wed, 27 Jan 2021 09:57:40 +0100 From: Greg Kroah-Hartman To: Mark Brown Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, Mayulong , Mauro Carvalho Chehab , linux-arm-msm@vger.kernel.org, YueHaibing , Liam Girdwood , Wei Xu , linux-kernel@vger.kernel.org, Stephen Boyd , Rob Herring , linux-arm-kernel@lists.infradead.org, Colin Ian King , Lee Jones , Dan Carpenter Subject: Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging Message-ID: References: <20210126175752.GF4839@sirena.org.uk> <20210126181124.GG4839@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210126181124.GG4839@sirena.org.uk> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote: > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote: > > > > Is there a branch we can pull from? > > > Once 0-day passes, you can pull from my staging-testing branch from > > staging.git on git.kernel.org if you want. Give it 24 hours to pass > > before it hits that location. > > Thanks. Should be out there now if you want to pull. > > Do you need a tag to pull from? > > It'd be nice but not essential. Why do you want/need this? Having these changes in your tree is good, but what about other coding style cleanups that I will end up applying over time before the 5.12-rc1 merge window opens? Are you wanting to take the moved driver in your tree, or something else? Traditionally moving drivers out of staging can be done 2 ways: - all happens in the staging tree, I take an ack from the subsystem maintainer that this is ok to do. - A new driver enters the "real" subsystem tree, and then I delete the driver in the staging tree. This doesn't preserve history as well (not at all), but can be easier for trees that move quickly (like networking.) Which ever works for you is fine with me, but relying on the code to stay "not touched" in my tree after you pull it almost never happens due to the number of drive-by coding style cleanups that end up in the staging tree every week. thanks, greg k-h 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=-8.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 5EF00C433DB for ; Wed, 27 Jan 2021 08:57:47 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (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 D9FBC2075E for ; Wed, 27 Jan 2021 08:57:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9FBC2075E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 384E08708E; Wed, 27 Jan 2021 08:57:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUmVE4+dRJML; Wed, 27 Jan 2021 08:57:45 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by hemlock.osuosl.org (Postfix) with ESMTP id AA0BA87083; Wed, 27 Jan 2021 08:57:45 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by ash.osuosl.org (Postfix) with ESMTP id D7DFC1BF834 for ; Wed, 27 Jan 2021 08:57:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id D24C987083 for ; Wed, 27 Jan 2021 08:57:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZIdh6d6Zc5n for ; Wed, 27 Jan 2021 08:57:43 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id D109387071 for ; Wed, 27 Jan 2021 08:57:43 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id BC32120759; Wed, 27 Jan 2021 08:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1611737863; bh=CRsnxHURAngp2eekJSNGPVdgsCZ9RsnCKwPFaU4Sd6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=zRObluJJlLWARaRpMYCN84a10arkVxS14A/oUfJ5UIAc5qjUwDPxyTz0p+S3i6468 yO4j8HagADFhCkb5Bk9l0N7MJm/Npg12rxCX0U/rkl0ZxNxWpuHIGwOALhrSmqaNgs Hm/BAwV6hQrGeMdJhC2OPnaeyEP2lg2iCtSMs8HI= Date: Wed, 27 Jan 2021 09:57:40 +0100 From: Greg Kroah-Hartman To: Mark Brown Subject: Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging Message-ID: References: <20210126175752.GF4839@sirena.org.uk> <20210126181124.GG4839@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210126181124.GG4839@sirena.org.uk> X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, Mayulong , Mauro Carvalho Chehab , linux-arm-msm@vger.kernel.org, YueHaibing , Liam Girdwood , Wei Xu , linux-kernel@vger.kernel.org, Stephen Boyd , Rob Herring , Dan Carpenter , Colin Ian King , Lee Jones , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote: > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote: > > > > Is there a branch we can pull from? > > > Once 0-day passes, you can pull from my staging-testing branch from > > staging.git on git.kernel.org if you want. Give it 24 hours to pass > > before it hits that location. > > Thanks. Should be out there now if you want to pull. > > Do you need a tag to pull from? > > It'd be nice but not essential. Why do you want/need this? Having these changes in your tree is good, but what about other coding style cleanups that I will end up applying over time before the 5.12-rc1 merge window opens? Are you wanting to take the moved driver in your tree, or something else? Traditionally moving drivers out of staging can be done 2 ways: - all happens in the staging tree, I take an ack from the subsystem maintainer that this is ok to do. - A new driver enters the "real" subsystem tree, and then I delete the driver in the staging tree. This doesn't preserve history as well (not at all), but can be easier for trees that move quickly (like networking.) Which ever works for you is fine with me, but relying on the code to stay "not touched" in my tree after you pull it almost never happens due to the number of drive-by coding style cleanups that end up in the staging tree every week. thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-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=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 068A3C433E0 for ; Wed, 27 Jan 2021 09:00:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 5E39220756 for ; Wed, 27 Jan 2021 09:00:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5E39220756 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lt+ZOTtXHL4xIpy2M/42rXwDpHA03KEv6JUu9bdINAs=; b=Oj/Pt4Ejy8g/CptU6B6Y0LQy7 sh5UdyjATZSfI2MfIFH7qnwXcr3znNzM9RsoEq2xPQ+zOPa289IluP8prlGunQvbNgZNPuL0VwcCl gTthChpUTnNWhPmZFs4HpDH8Ri4//DilIc+K6InMpmPv3WufPOsbbZySYNmqhj+EqLs1Ni/IICIdh VBeR2Io78U1dokM0wePUvODSTK2xCQOf7TlorsaW59Y6vGcw4YZOLG7NnRZhA0kniWWVKjvUbOOW0 v3G6FKmWhEt3gC5p3U/LJKACxyaZzEnE1D6S2cKLjbQnl1GLtr/rL/y0XpB0fYJHQbWhg2p2rsrKi CcSNHrWCg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4gef-00012U-J1; Wed, 27 Jan 2021 08:58:25 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4ge0-0000iJ-U7 for linux-arm-kernel@lists.infradead.org; Wed, 27 Jan 2021 08:57:48 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id BC32120759; Wed, 27 Jan 2021 08:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1611737863; bh=CRsnxHURAngp2eekJSNGPVdgsCZ9RsnCKwPFaU4Sd6Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=zRObluJJlLWARaRpMYCN84a10arkVxS14A/oUfJ5UIAc5qjUwDPxyTz0p+S3i6468 yO4j8HagADFhCkb5Bk9l0N7MJm/Npg12rxCX0U/rkl0ZxNxWpuHIGwOALhrSmqaNgs Hm/BAwV6hQrGeMdJhC2OPnaeyEP2lg2iCtSMs8HI= Date: Wed, 27 Jan 2021 09:57:40 +0100 From: Greg Kroah-Hartman To: Mark Brown Subject: Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging Message-ID: References: <20210126175752.GF4839@sirena.org.uk> <20210126181124.GG4839@sirena.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210126181124.GG4839@sirena.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210127_035745_236373_EC359118 X-CRM114-Status: GOOD ( 19.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, Mayulong , Mauro Carvalho Chehab , linux-arm-msm@vger.kernel.org, YueHaibing , Liam Girdwood , Wei Xu , linux-kernel@vger.kernel.org, Stephen Boyd , Rob Herring , Dan Carpenter , Colin Ian King , Lee Jones , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote: > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote: > > > > Is there a branch we can pull from? > > > Once 0-day passes, you can pull from my staging-testing branch from > > staging.git on git.kernel.org if you want. Give it 24 hours to pass > > before it hits that location. > > Thanks. Should be out there now if you want to pull. > > Do you need a tag to pull from? > > It'd be nice but not essential. Why do you want/need this? Having these changes in your tree is good, but what about other coding style cleanups that I will end up applying over time before the 5.12-rc1 merge window opens? Are you wanting to take the moved driver in your tree, or something else? Traditionally moving drivers out of staging can be done 2 ways: - all happens in the staging tree, I take an ack from the subsystem maintainer that this is ok to do. - A new driver enters the "real" subsystem tree, and then I delete the driver in the staging tree. This doesn't preserve history as well (not at all), but can be easier for trees that move quickly (like networking.) Which ever works for you is fine with me, but relying on the code to stay "not touched" in my tree after you pull it almost never happens due to the number of drive-by coding style cleanups that end up in the staging tree every week. thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel