Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp34475pxp; Tue, 15 Mar 2022 22:58:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyqpMdMYn2l4ddzcvXh0ZBrz76tVAXXjzGXTIAdLE/8CEnA8M7Iwks+HZT0i94Mz5ctWpD3 X-Received: by 2002:a17:902:f552:b0:153:9db5:d73f with SMTP id h18-20020a170902f55200b001539db5d73fmr5962161plf.77.1647410339205; Tue, 15 Mar 2022 22:58:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647410339; cv=none; d=google.com; s=arc-20160816; b=BKVSIkl9rQQPE9Al4FRRg2OIlHnzOk/NcPk9QopI/T5pR0nxZhVikUlSkkNPANkA+c atqxMGqhslUUlBHt7mmDBweHemSxvFT7rzH1S3QAUtlvM8NbNsApK0QL0yW/ApUuatGl +8OH4ttHD3LPNZ53qRK5U01JyB4gqY+p/k14aQtPqswXhaBgKaByBImXyOrEy03cuKr9 WRbQzQf3iwAtiktBv6+LWL7XjLB0JytrOf/7GlIxTdMjUzyeacdUR1FCEAWlCIsbVtjx 8pz7d50lhcuMVje8SWgRBRg6i2dXAIzSGJ9sKUV2JrShtaFOT9rcDKlLLuTcszUKD3Ft 5BTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=pO76GVxVdbEqxPilbb6pnhMbOehVpPCXKWMzjhowEaE=; b=vWdrLwiKCmwR7V8H/hg+t8btYpsuJ+F3Hyd3o0I+9t5rb1hcGV9tlX/HwX5qkeBa6Y +fexGmr3Xx8xrPmXbq6T9TjI6XNZymOZ5wGq0bPI8tdwo59CmvF+tBGJ9qMM8ZQ5k2LD xIFuECVJMasSvcu4Y2SFXi8A7qkjCygS13HdVqq2FGYdA15Ca0CwSNXLODx1p0a4gjen pJRKI2Dcypx6Kh7oC6ZtobHl9hF+XEBUouxMId6/8/fKC0RYb4A5VVf9DIYGhkFYJX4V mdJLAmvbpn2EhMGT49NwpIuqCUHivSbsMyUoVkjBeF5E15VOLSnA3BGwhZVYlWMhDJnn GJHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=pQshLCVv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q75-20020a632a4e000000b0037843b0a6dasi1123285pgq.3.2022.03.15.22.58.45; Tue, 15 Mar 2022 22:58:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=pQshLCVv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237563AbiCOIgg (ORCPT + 99 others); Tue, 15 Mar 2022 04:36:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231668AbiCOIgf (ORCPT ); Tue, 15 Mar 2022 04:36:35 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16A6547554; Tue, 15 Mar 2022 01:35:24 -0700 (PDT) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 229ED51C; Tue, 15 Mar 2022 09:35:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1647333322; bh=2B1abWspufHcU+WluNkys+YV9mGWKvBYO+9++Bkm3NY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pQshLCVv7y+XpgxHB+4/J8hdZXKj/9Ux7RpMusc18nIvYIbx2SbrZICKrYwDpbHz2 3g0l4lmMYeH+H+To1GCyd/U+HiiDvpKSaPoogxtT+pp5PE3d3V5w8Hg4JYnARcVw+p 6/kz7vCp33yNnqmwiapggEtyAhpU0Mv4ZJSbfB8o= Date: Tue, 15 Mar 2022 10:35:05 +0200 From: Laurent Pinchart To: Mauro Carvalho Chehab Cc: Jernej =?utf-8?Q?=C5=A0krabec?= , Niklas =?utf-8?Q?S=C3=B6derlund?= , Cai Huoqing , Chen-Yu Tsai , Dinghao Liu , Dmitry Osipenko , Eugen Hristev , Ezequiel Garcia , Hans Verkuil , Jacopo Mondi , Jia-Ju Bai , Jonathan Cameron , Maxime Ripard , Mikhail Rudenko , Ming Qian , Ondrej Jirman , Robert Foss , Sakari Ailus , Tomi Valkeinen , Yong Deng , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linux-sunxi@lists.linux.dev Subject: Re: [PATCH v2 47/67] media: platform: rename sunxi/ to allwinner/ Message-ID: References: <85266b480902079391d4206b8aa276ff131a730f.1647274407.git.mchehab@kernel.org> <2816975.e9J7NaK4W3@kista> <20220315064005.10ecdab2@coco.lan> <20220315092736.7e805c81@coco.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220315092736.7e805c81@coco.lan> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 15, 2022 at 09:27:36AM +0100, Mauro Carvalho Chehab wrote: > Em Tue, 15 Mar 2022 08:54:25 +0200 > Laurent Pinchart escreveu: > > > Hi Mauro, > > > > On Tue, Mar 15, 2022 at 06:40:05AM +0100, Mauro Carvalho Chehab wrote: > > > Em Mon, 14 Mar 2022 18:22:20 +0100 Jernej Škrabec escreveu: > > > > > > > Dne ponedeljek, 14. marec 2022 ob 17:34:42 CET je Mauro Carvalho Chehab > > > > napisal(a): > > > > > As the end goal is to have platform drivers split by vendor, > > > > > rename sunxi/ to allwinner/. > > > > > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > I would rather not do that. Everything related to Allwinner is called sunxi, > > > > albeit there are a few outliers. This is similar to Amlogic/meson situation. > > > > > > The rationale of having one directory per manufacturer is that, if drivers > > > for newer platforms with different names from the same manufacturers are > > > added, those will still fit under allwinner/ and amlogic/. > > > > > > The Kconfig names for sunxi and meson didn't change, nor the driver's name. > > > Also, the directories under allwinner preserve suni name on them: > > > > > > drivers/media/platform/allwinner/ > > > ├── sun4i-csi > > > ├── sun6i-csi > > > ├── sun8i-di > > > └── sun8i-rotate > > > > > > and so the directory under amlogic/: > > > > > > drivers/media/platform/amlogic/ > > > └── meson-ge2d > > > > > > Now, if Allinner decides to release a new platforms named after another star, > > > let's say, "Vega" and "Rigel", it would be just a matter of adding > > > "vega/" and "rigel/" directories under allwinner. No need to touch > > > media/platform/Kconfig and media/platform/Makefile. Everything will happen > > > on much more smaller vendor-specific Kconfig/Makefile. > > > > But the day Allwinner changes its name to Noloser, we'll have a similar > > problem. > > Not really. It will still be a single directory per vendor (whatever > name it is). > > > Thnk about Freescale vs. NXP, or Altera bought by Intel. > > Yeah, when some drivers move from one vendor to another one that > already exists there, we should probably move the directories, in > order to keep things well organized. I'm not sure we should. We still have arch/arm64/boot/dts/freescale/ for instance. We can answer that question later though, when confronted with the situation. > The worse case scenario is really if, let's say, TI decides to sell their > omap architecture to NXP, keeping the rest. On such case, the best would > be to move platform/ti/omap* to the directory of its newer owner. > > That's said, when things like that happen, there are usually a change > at MAINTAINERS, as e-mails, mailing lists and contact people will > likely change. So, this will very likely generate patches anyway. > > > No > > naming scheme is totally future-proof. If the accepted standard through > > the kernel is to use sunxi to refer to Allwinner SoCs, I don't think > > it's a bit idea to go with that. > > I'm not too concerned about the name here, but rather about the > process. Needing to do reorg like this is painful, as it causes > all pending work to fail merging against upstream, requiring rebases. > So, we should avoid needing to re-do it by trying our best to avoid > the need of another global change like that in the future. Most of the pain we'll go through in the immediate future comes from the fact that we never really cared about this. I think renames (of vendors or product lines) will be infrequent enough that picking sunxi for Allwinner drivers wouldn't be an issue. There's a similar think with Renesas, which had an SH product line and then moved to ARM, creating R-Mobile and R-Car (among other product liens). That's why we still have drivers/dma/sh/ for Renesas DMA drivers. > By organizing entries per vendor, while we may need to do puntual > per-vendor adjustments when they rename and change IP with other > vendors, the global platform Kconfig/Make will contain a single entry > per vendor. I can't foresee any need to change this in the future, > if we take care of keeping the entries there properly sorted. > > With regards to naming the per-vendor directory, while I do prefer to have > the directories named after the vendor, and not after a vendor's nick > name, It should also be ok to use a vendor's nick name, provided that > such name is meant to be used by all their current and future IP. > > Not sure if "sunxi" is actually a vendor's nick name. It sounds > much likely that it is, instead, a brand name that covers their > current media-related SoC. > > Can someone from the vendor shed a light on it? Maybe we can let the Allwinner upstream community tell us what name to pick ? I'm sure they know better than us :-) -- Regards, Laurent Pinchart