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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 345F7C433EF for ; Fri, 20 May 2022 07:01:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346156AbiETHBc (ORCPT ); Fri, 20 May 2022 03:01:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346142AbiETHAz (ORCPT ); Fri, 20 May 2022 03:00:55 -0400 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EC5721A0 for ; Fri, 20 May 2022 00:00:46 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id br17so442067lfb.2 for ; Fri, 20 May 2022 00:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=kCCz1rMXqvASGt0+8nSWpqnr2BGj26XTAJy5dg5bcuc=; b=T6vWMnF/d7an2NvWN8T9wfDbjZ0S/C1KGYj28m1VzCYgGY5f1HGix23JczGG13/aiG +5OnaxodASZwGQqEMMDml+eBFiQfV67b56/1yihxw4/SvaPhhSk3ZuVAoAF1/7MBAeQD vnZAGayeo8aihjII7Pk1MoHO8mKyiAQ5DDhR0S6vwhT/ndkWHW47i+/SO9pO3OQ3lIr3 5ZcWbfeTMvfa/thU7pP5mbYkJe38zdfOlWxXJX/IHvYwCdJH9eO9dhCl4IOIxIB4Jn7k 8KupnvWLulymBKOT26GEqd6tiLEVDxUcQi0JY/J/zSsx7jY2WbneJQ0mDzWHyWi1tGl1 erOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=kCCz1rMXqvASGt0+8nSWpqnr2BGj26XTAJy5dg5bcuc=; b=69xEQgdXkxo7Khd9DqvHlcaEQBVAENCDqATZC/3MYS8nLI5M1+miPkEdbs/sphkyjY aPAFjIHqBnfj6dYHu+UwyenJq/Hx5E4a+r/PTyvAqfW9xo+WtdfEH6munnPUR7OKwGnm HswFNMDgnJfAyccTychypVjD1xK9aNVZDcG3VTeDmvqgA916aHnjgmUaogLSkts8cSKM ltg6Q6lsMsVk7Fe7WPbtiBlVfNdBx46urejnhX29/lcOLfzlM3z+CmdPqxyEe9wCNOkE PQBH2OaFaNoEWWq5V4L0eXYviXXqdKGrSVg66qneHCbFL2milC5bk83SSxhS9WVtv5Qa sa3Q== X-Gm-Message-State: AOAM530mVHQuaPfiCVmJrHt5n9Sh62o1V6DXFm9VXdy6AC4OajW3T7N8 1gqBazWUaPzLTlvQfriJqauF8Q== X-Google-Smtp-Source: ABdhPJy6wR430AFBjokcnyv0JB4k1K8iTX33VH2wlKS6T/wU4xDXju/W3bfISPkXtSsE9yku91Gz9w== X-Received: by 2002:a05:6512:12d6:b0:473:b308:ae0e with SMTP id p22-20020a05651212d600b00473b308ae0emr6285355lfg.664.1653030044824; Fri, 20 May 2022 00:00:44 -0700 (PDT) Received: from [192.168.0.17] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id f22-20020ac25336000000b0047255d21190sm542661lfh.191.2022.05.20.00.00.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 May 2022 00:00:44 -0700 (PDT) Message-ID: Date: Fri, 20 May 2022 09:00:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Removal of qcom,board-id and qcom,msm-id Content-Language: en-US To: Dmitry Baryshkov , Stephen Boyd Cc: Andy Gross , Arnd Bergmann , Bjorn Andersson , Olof Johansson , Rob Herring , "devicetree@vger.kernel.org" , linux-arm-msm , Linux Kernel Mailing List References: <35051bec-98ea-b4c5-f734-06b3f22f3562@linaro.org> <8a90ffbc-b376-9115-fb91-0b46d98873b7@linaro.org> <40f29157-52c0-001f-6c14-fb90b351756a@linaro.org> <20220519221227.B66D3C385AA@smtp.kernel.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 20/05/2022 03:39, Dmitry Baryshkov wrote: >> I vaguely recall that the properties had to be extracted during the >> boot.img creation process to create a table of contents header. But >> after some time the bootloader started scanning the DTBs directly for >> the vendor properties and thus the header was deprecated/removed. If the >> bootloader is doing the scanning then I'm not sure what is preventing >> the properties from being documented and allowed. I think the main >> rejection was that the properties were added purely to be extracted >> during post processing and placed into the table of contents header, >> i.e. they weren't actually used by the kernel or the bootloader. If they >> are now used by the bootloader it sounds OK to me if they're kept >> around. > > Yes, as far as I understand, they are used by the bootloader directly. This solves only one part of concern form previous discussions - having entries not used by anything. Kernel still don't use them but some vendor bootloader (not U-boot) does. The second problem with these is still not solved - these duplicate what is already described by compatible. Basically, they do not add any new hardware description, because board or SoC revision should be encoded into the compatible. Imagine now adding such "vendor,device-id" properties to every device node in DTS! Best regards, Krzysztof