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 A9C94C43334 for ; Tue, 21 Jun 2022 07:12:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346687AbiFUHMr (ORCPT ); Tue, 21 Jun 2022 03:12:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346636AbiFUHMn (ORCPT ); Tue, 21 Jun 2022 03:12:43 -0400 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53CD8222BC for ; Tue, 21 Jun 2022 00:12:35 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id o9so8831564edt.12 for ; Tue, 21 Jun 2022 00:12:35 -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=rZJJbO9tmvN3skIIZSoGEawfNisxmFvqIY3afbWNk0k=; b=x2XlL1khCI/cWLpErGp+GFQadkpgwCUNIt+y1cFMvLTJ8QTD7icTnugWki3Lf7ie0f CzpfEy2ptqM4Or39eOzCVLWFUbbJ2PC9H0+mGo9O0onCHMRUuPsb3WAeSPuJruh0qEHI hqvnIxLIflrU6ZD/ACM33uG6PKa2OeNCvg6GXPKN3zkTWRDrNdF9rOWDhcki1S8gcNaQ Q1z1S5ftZ1jeXv98c1WhlbFXcXrCnDbSkd7cVLYa9sLp7OyywI19eVDbBck+Xtr+lToJ hPC69Xik8O4j6WZJgBESUKybjciq3r2LktSTdr4j8UhSCxkdLptWhSOGA+Po/D8cl8tM umDQ== 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=rZJJbO9tmvN3skIIZSoGEawfNisxmFvqIY3afbWNk0k=; b=pRyew+E/xfIsOwROcV2Ja+ubBD6FKoxpJ+wM8BY2Cbu76IPPhGtxiJBMxzEuZNVSoh 3DBTeu6dxiSOoPKVrUJu2aThT7B69SxlhEv3vlwsQE3wKzviPOuRxcfD/Lop/i6xuX7W tlQyU3nWcx67XtnxX0UIYH7j7bqaV7N96SW7UjQmA7Whxqa+c+EoJBc6KrVNcaWAxzTD 0QWHoiTW18Cysf2MhJj/5LGsh1npEmlvo2bCWFqpEm2m9iTGmP6NwvdPpsd9QPZ1m441 jdQm6mMUzVbcWk1aedt53quPnYCPW2LFblLDxuo533nZOaPPYEvnuBarIxYNA79TuVRL Hepg== X-Gm-Message-State: AJIora8MFiv1JCeoaUtN1mqn7Xm344bhBMT67ZNpUqywDN7VJTHlgIoW oCinvcxiY77Ojq8hh2RydLnLyg== X-Google-Smtp-Source: AGRyM1vrygzsyf1XkfWBidpFgjIUaEYcyGJLiMBB9DaYIq+y5D3cEOQOG47m6jnRBlKuRDUEajM72Q== X-Received: by 2002:aa7:c1c7:0:b0:435:5cb2:c202 with SMTP id d7-20020aa7c1c7000000b004355cb2c202mr27028883edp.10.1655795553854; Tue, 21 Jun 2022 00:12:33 -0700 (PDT) Received: from [192.168.0.216] (xdsl-188-155-176-92.adslplus.ch. [188.155.176.92]) by smtp.gmail.com with ESMTPSA id e16-20020a170906315000b0071cef6c53aesm6096627eje.0.2022.06.21.00.12.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jun 2022 00:12:33 -0700 (PDT) Message-ID: <1c2bbc12-0aa5-6d2a-c701-577ce70f7502@linaro.org> Date: Tue, 21 Jun 2022 09:12:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH net-next 01/28] dt-bindings: phy: Add QorIQ SerDes binding Content-Language: en-US To: Sean Anderson , "David S . Miller" , Jakub Kicinski , Madalin Bucur , netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Paolo Abeni , Russell King , Eric Dumazet , Kishon Vijay Abraham I , Krzysztof Kozlowski , Rob Herring , Vinod Koul , devicetree@vger.kernel.org, linux-phy@lists.infradead.org, Ioana Ciornei References: <20220617203312.3799646-1-sean.anderson@seco.com> <20220617203312.3799646-2-sean.anderson@seco.com> <110c4a4b-8007-1826-ee27-02eaedd22d8f@linaro.org> <535a0389-6c97-523d-382f-e54d69d3907e@seco.com> <16684442-35d4-df51-d9f7-4de36d7cf6fd@linaro.org> <50fa16ce-ac24-8e4c-5d81-0218535cd05c@seco.com> <5d724f49-71c4-96ad-b756-06b5683fa112@seco.com> From: Krzysztof Kozlowski In-Reply-To: <5d724f49-71c4-96ad-b756-06b5683fa112@seco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/06/2022 20:51, Sean Anderson wrote: > On 6/20/22 2:21 PM, Krzysztof Kozlowski wrote: >>>>> - samsung_usb2_phy_config in drivers/phy/samsung/ >>>> >>>> This one is a good example - where do you see there compatibles with >>>> arbitrary numbers attached? >>> >>> samsung_usb2_phy_of_match in drivers/phy/samsung/phy-samsung-usb2.c >>> >>> There is a different compatible for each SoC variant. Each compatible selects a struct >>> containing >>> >>> - A list of phys, each with custom power on and off functions >>> - A function which converts a rate to an arbitrary value to program into a register >>> >>> This is further documented in Documentation/driver-api/phy/samsung-usb2.rst >> >> Exactly, please follow this approach. Compatible is per different >> device, e.g. different SoC variant. Of course you could have different >> devices on same SoC, but "1" and "2" are not different devices. > > (in this case they are) In a meaning of descriptive compatible - it's not. >>> >>> - For some SerDes on the same SoC, these fields are reserved >> >> That all sounds like quite different devices, which indeed usually is >> described with different compatibles. Still "xxx-1" and "xxx-2" are not >> valid compatibles. You need to come with some more reasonable name >> describing them. Maybe the block has revision or different model/vendor. > > There is none AFAIK. Maybe someone from NXP can comment (since there are many > undocumented registers). Maybe it's also possible to invent some reasonable name based on protocols supported? If nothing comes then please add a one-liner comment explaining logic behind 1/2 suffix. >>> The compatibles suggested were "fsl,ls1046-serdes-1" and -2. As noted above, these are separate >>> devices which, while having many similarities, have different register layouts and protocol >>> support. They are *not* 100% compatible with each other. Would you require that clock drivers >>> for different SoCs use the same compatibles just because they had the same registers, even though >>> the clocks themselves had different functions and hierarchy? >> >> You miss the point. Clock controllers on same SoC have different names >> used in compatibles. We do not describe them as "vendor,aa-clk-1" and >> "vendor,aa-clk-2". >> >> Come with proper naming and entire discussion might be not valid >> (although with not perfect naming Rob might come with questions). I >> cannot propose the name because I don't know these hardware blocks and I >> do not have access to datasheet. >> >> Other way, if any reasonable naming is not possible, could be also to >> describe the meaning of "-1" suffix, e.g. that it does not mean some >> index but a variant from specification. > > The documentation refers to these devices as "SerDes1", "SerDes2", etc. > > Wold you prefer something like > > serdes0: phy@1ea0000 { > compatible = "fsl,ls1046a-serdes"; > variant = <0>; > }; No, it's the same problem, just embeds compatible in different property. Best regards, Krzysztof