linux-kernel - Re: [PATCH v2 47/67] media: platform: rename sunxi/ to allwinner/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YjA4IRD//lb8SKgs@pendragon.ideasonboard.com>
Date:   Tue, 15 Mar 2022 08:54:25 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Jernej Škrabec <jernej.skrabec@...il.com>,
        Niklas Söderlund 
        <niklas.soderlund+renesas@...natech.se>,
        Cai Huoqing <caihuoqing@...du.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Dinghao Liu <dinghao.liu@....edu.cn>,
        Dmitry Osipenko <digetx@...il.com>,
        Eugen Hristev <eugen.hristev@...rochip.com>,
        Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Jacopo Mondi <jacopo@...ndi.org>,
        Jia-Ju Bai <baijiaju1990@...il.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Maxime Ripard <mripard@...nel.org>,
        Mikhail Rudenko <mike.rudenko@...il.com>,
        Ming Qian <ming.qian@....com>,
        Ondrej Jirman <megous@...ous.com>,
        Robert Foss <robert.foss@...aro.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        Yong Deng <yong.deng@...ewell.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH v2 47/67] media: platform: rename sunxi/ to allwinner/

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 <mchehab@...nel.org>  
> > 
> > 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 sun<x>i 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. Thnk about Freescale vs. NXP, or Altera bought by Intel. 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.

> See for instance, TI. We had initially a single driver, and everywhere it
> was called "omap", which was had gained different versions (omap2, omap3, 
> ...). Then, TI decided to use other names for newer IP (davinci, am437x), 
> and now the current development is at cal and vpe.
> 
> If we had placed a ti/ directory by the time omap were added (and the
> same for the other vendors), we would have avoided the need of this
> reorg.

-- 
Regards,

Laurent Pinchart