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 E2275C6FA99 for ; Fri, 10 Mar 2023 07:47:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230151AbjCJHrT (ORCPT ); Fri, 10 Mar 2023 02:47:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230496AbjCJHqi (ORCPT ); Fri, 10 Mar 2023 02:46:38 -0500 Received: from sender4-op-o10.zoho.com (sender4-op-o10.zoho.com [136.143.188.10]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11A4D59F1; Thu, 9 Mar 2023 23:46:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678434342; cv=none; d=zohomail.com; s=zohoarc; b=Ru7IYBxv1TeMY1HDSIbcbhxUNtx0dao2F3QOW2pbVrTwW8MMATPUUfhpbPFDqiDvMQKahq7ri2Mjiem2lj9SCcw7TkhylZSmeax3MK2J/VXzpVq0e8LoVw6F0Lyc+GVikjDwhJ+02yn6gCRLlLwrAU8XmJgfer7Iz/t5NdVBCVs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1678434342; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=5U8jD0mceNdxMH5d+XXNMoLuXyA0CAviMCHpJ7kQo4A=; b=Nlr0Yw6/VEg6XyZsWZZjN5V+6CSnxtknPmaDq4A1F1Aq0jElIB0fJixzWdmEx39LOFK24K6DTfFAd0WuZflWOJs9fZXNuYm3ByHDcJ0sC+fsJVPd0N5srafRM1XWvuVrVQ8pY4FF5jJKqm8UdH+LKfiUUxXn5dZAzJT3cTpeXqM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=arinc9.com; spf=pass smtp.mailfrom=arinc.unal@arinc9.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1678434342; s=zmail; d=arinc9.com; i=arinc.unal@arinc9.com; h=Message-ID:Date:Date:MIME-Version:Subject:Subject:To:To:Cc:Cc:References:From:From:In-Reply-To:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=5U8jD0mceNdxMH5d+XXNMoLuXyA0CAviMCHpJ7kQo4A=; b=JUSLKQwACAis7T3MVKl2xbQaFmgnTQo32wE1WLFdrJdA3G0c59CgRzZ19UN+6JQh MwtY0l61oqaAqNpV7FUhS0MXf2b1ywfgpncP3s5GnBaNnVlNwq7QzsVNhAA00kLHeZc rJLu4yaNfejgJibc+I4PLJsuL2k//ZaEdZRqu7XI= Received: from [10.10.10.3] (212.68.60.226 [212.68.60.226]) by mx.zohomail.com with SMTPS id 1678434340115989.170333737338; Thu, 9 Mar 2023 23:45:40 -0800 (PST) Message-ID: <6019d3ff-3fdf-543f-c5fb-cba512582fb3@arinc9.com> Date: Fri, 10 Mar 2023 10:45:33 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 09/20] dt-bindings: pinctrl: ralink: {mt7620,mt7621}: rename to mediatek To: Sergio Paracuellos Cc: Krzysztof Kozlowski , Rob Herring , Linus Walleij , Krzysztof Kozlowski , linux-mediatek@lists.infradead.org, linux-mips@vger.kernel.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Matthias Brugger , Sean Wang , William Dean , Daniel Golle , Daniel Santos , Luiz Angelo Daros de Luca , Frank Wunderlich , Landen Chao , DENG Qingfang , Sean Wang , erkin.bozoglu@xeront.com References: <20230303002850.51858-1-arinc.unal@arinc9.com> <20230303002850.51858-10-arinc.unal@arinc9.com> <20230308210514.GA3767521-robh@kernel.org> <12be053e-b70a-faca-71c8-d8eef69a3b73@arinc9.com> <9663817e-7f6f-c3b1-8bf9-321f9b067e96@linaro.org> <81cf9e50-d626-cbb3-ebb1-56d080eca66d@arinc9.com> Content-Language: en-US From: =?UTF-8?B?QXLEsW7DpyDDnE5BTA==?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ZohoMailClient: External Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10.03.2023 10:05, Sergio Paracuellos wrote: > On Thu, Mar 9, 2023 at 10:09 PM Arınç ÜNAL wrote: >> >> On 9.03.2023 14:33, Sergio Paracuellos wrote: >>> On Thu, Mar 9, 2023 at 11:34 AM Arınç ÜNAL wrote: >>>> >>>> On 9.03.2023 12:52, Krzysztof Kozlowski wrote: >>>>> On 09/03/2023 08:53, Arınç ÜNAL wrote: >>>>>> On 9.03.2023 00:19, Arınç ÜNAL wrote: >>>>>>> On 9.03.2023 00:05, Rob Herring wrote: >>>>>>>> On Fri, Mar 03, 2023 at 03:28:38AM +0300, arinc9.unal@gmail.com wrote: >>>>>>>>> From: Arınç ÜNAL >>>>>>>>> >>>>>>>>> This platform from Ralink was acquired by MediaTek in 2011. Then, >>>>>>>>> MediaTek >>>>>>>>> introduced these SoCs which utilise this platform. Rename the schemas to >>>>>>>>> mediatek to address the incorrect naming. >>>>>>>> >>>>>>>> I said we don't do renames due to acquistions, you said that wasn't the >>>>>>>> reason, but then that's your reasoning here. >>>>>>> >>>>>>> It's not a marketing/acquistion rename as the name of these SoCs were >>>>>>> wrong from the get go. The information on the first sentence is to give >>>>>>> the idea of why these SoCs were wrongfully named as the base platform >>>>>>> that these new MediaTek SoCs share code with was called Ralink. >>>>>>> >>>>>>>> >>>>>>>> To give you another example, *new* i.MX things are still called >>>>>>>> 'fsl,imx...' and it has been how many years since merging with NXP? >>>>>>> >>>>>>> Ok this is a point I see now. Though, I fail to see how this is called >>>>>>> renaming when there's only new SoCs (from NXP in this case) to be added. >>>>>> >>>>>> If I understand correctly, i.MX is a family from Freescale so the name >>>>> >>>>> It's the same "family" as your platform, because as you said: >>>>> "introduced these SoCs which utilise this platform" >>>>> >>>>>> was kept the same on new SoC releases from NXP. I believe it's different >>>>>> in this case here. There's no family name. The closest thing on the name >>>>>> of the SoC model is, it's RT for Ralink, MT for MediaTek. >>>>> >>>>> It's not about the name. NXP took Freescale platform and since many >>>>> years makes entirely new products, currently far, far away from original >>>>> platform. >>>>> >>>>> That's the same case you have here - Mediatek took existing platform and >>>>> started making new products with it. >>>>> >>>>>> >>>>>> On top of that, mediatek strings already exist for MT SoCs already, at >>>>>> least for MT7621. >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/tree/Documentation/devicetree/bindings/mips/ralink.yaml?id=dd3cb467ebb5659d6552999d6f16a616653f9933#n83 >>>>> >>>>> NXP also has compatibles with nxp, thus still not that good reason. >>>> >>>> Ok, makes sense. Am I free to call the SoCs MediaTek, change the schema >>>> name from ralink,mtXXXX-pinctrl.yaml to mediatek,mtXXXX-pinctrl.yaml >>>> whilst keeping the compatible string ralink? >>>> >>>> I plan to do some cleanup on ralink.yaml as well. From what I >>>> understand, I should change the mediatek,mt7621-soc compatible string to >>>> ralink,mt7621-soc? >>> >>> You have to take care of these SoC strings since they are used in the >>> very beginning of the ralink startup platforms for any single ralink >>> SoC. See for example [0] and [1] (but they are in all soc init code). >>> I think it is better to maintain the ralink.yaml file as it is. >> >> I'd really rather address this inconsistency everywhere possible. The >> code you pointed out looks different than what I did on the pinctrl >> driver but, surely it's possible on the code to introduce ralink and >> keep the mediatek string for the sake of old DTs, no? > > In any case, the changes you might have in mind for this should be a > different patch series. Agreed. Arınç