All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Alim Akhtar <alim.akhtar@samsung.com>,
	'Rob Herring' <robh+dt@kernel.org>,
	'Lukasz Luba' <lukasz.luba@arm.com>,
	'Dmitry Osipenko' <digetx@gmail.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 5/8] dt-bindings: memory: lpddr3: deprecate manufacturer ID
Date: Mon, 7 Feb 2022 09:56:39 +0100	[thread overview]
Message-ID: <4b18991e-1c93-077d-368f-a861e8c2b845@canonical.com> (raw)
In-Reply-To: <0a7101d81bd9$33088840$991998c0$@samsung.com>

On 07/02/2022 05:14, Alim Akhtar wrote:
> Hi Krzysztof
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
>> Sent: Sunday, February 6, 2022 7:28 PM
>> To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>; Rob Herring
>> <robh+dt@kernel.org>; Lukasz Luba <lukasz.luba@arm.com>; Alim Akhtar
>> <alim.akhtar@samsung.com>; Dmitry Osipenko <digetx@gmail.com>; linux-
>> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> pm@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org
>> Subject: [PATCH v3 5/8] dt-bindings: memory: lpddr3: deprecate
>> manufacturer ID
>>
>> The memory manufacturer should be described in vendor part of compatible,
>> so there is no need to duplicate it in a separate property.
>> Similarly is done in LPDDR2 bindings.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
>> ---
>> .../bindings/memory-controllers/ddr/jedec,lpddr3.yaml         | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpddr3.yaml
>> b/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpddr3.yaml
>> index d6787b5190ee..3bcba15098ea 100644
>> --- a/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpddr3.yaml
>> +++ b/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpd
>> +++ dr3.yaml
>> @@ -40,7 +40,9 @@ properties:
>>   manufacturer-id:
>>     $ref: /schemas/types.yaml#/definitions/uint32
>>     description: |
>> -      Manufacturer ID value read from Mode Register 5.
>> +      Manufacturer ID value read from Mode Register 5.  The property is
>> +      deprecated, manufacturer should be derived from the compatible.
>> +    deprecated: true
>>
> 
> Shouldn't it be the other way? As DT describes hardware and MR5 does contain
> the Manufacturer ID, 
> so getting Manufacturer ID from MR5 makes aligned to hardware description.

The code/driver can read MR5 and report it to user-space in case for
example we have a device compatible with different vendor and same
compatible is used. So compatible is re-used but we want real
manufacturer ID from the hardware.

But storing a fixed MR5 value in DT does not fit here. If someone takes
effort to encode manufacturer ID in the DTS, then he/she should take
effort to actually document the compatible.

Basically having MR5 in DT is equal to having a compatible in DTS. I
prefer the latter - simpler, less properties, using existing property
from DT spec instead of custom one.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
To: Alim Akhtar <alim.akhtar@samsung.com>,
	'Rob Herring' <robh+dt@kernel.org>,
	'Lukasz Luba' <lukasz.luba@arm.com>,
	'Dmitry Osipenko' <digetx@gmail.com>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 5/8] dt-bindings: memory: lpddr3: deprecate manufacturer ID
Date: Mon, 7 Feb 2022 09:56:39 +0100	[thread overview]
Message-ID: <4b18991e-1c93-077d-368f-a861e8c2b845@canonical.com> (raw)
In-Reply-To: <0a7101d81bd9$33088840$991998c0$@samsung.com>

On 07/02/2022 05:14, Alim Akhtar wrote:
> Hi Krzysztof
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
>> Sent: Sunday, February 6, 2022 7:28 PM
>> To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>; Rob Herring
>> <robh+dt@kernel.org>; Lukasz Luba <lukasz.luba@arm.com>; Alim Akhtar
>> <alim.akhtar@samsung.com>; Dmitry Osipenko <digetx@gmail.com>; linux-
>> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> pm@vger.kernel.org; linux-samsung-soc@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org
>> Subject: [PATCH v3 5/8] dt-bindings: memory: lpddr3: deprecate
>> manufacturer ID
>>
>> The memory manufacturer should be described in vendor part of compatible,
>> so there is no need to duplicate it in a separate property.
>> Similarly is done in LPDDR2 bindings.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
>> ---
>> .../bindings/memory-controllers/ddr/jedec,lpddr3.yaml         | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpddr3.yaml
>> b/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpddr3.yaml
>> index d6787b5190ee..3bcba15098ea 100644
>> --- a/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpddr3.yaml
>> +++ b/Documentation/devicetree/bindings/memory-
>> controllers/ddr/jedec,lpd
>> +++ dr3.yaml
>> @@ -40,7 +40,9 @@ properties:
>>   manufacturer-id:
>>     $ref: /schemas/types.yaml#/definitions/uint32
>>     description: |
>> -      Manufacturer ID value read from Mode Register 5.
>> +      Manufacturer ID value read from Mode Register 5.  The property is
>> +      deprecated, manufacturer should be derived from the compatible.
>> +    deprecated: true
>>
> 
> Shouldn't it be the other way? As DT describes hardware and MR5 does contain
> the Manufacturer ID, 
> so getting Manufacturer ID from MR5 makes aligned to hardware description.

The code/driver can read MR5 and report it to user-space in case for
example we have a device compatible with different vendor and same
compatible is used. So compatible is re-used but we want real
manufacturer ID from the hardware.

But storing a fixed MR5 value in DT does not fit here. If someone takes
effort to encode manufacturer ID in the DTS, then he/she should take
effort to actually document the compatible.

Basically having MR5 in DT is equal to having a compatible in DTS. I
prefer the latter - simpler, less properties, using existing property
from DT spec instead of custom one.

Best regards,
Krzysztof

  reply	other threads:[~2022-02-07  8:58 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-06 13:57 [PATCH v3 0/8] dt-bindings: memory: convert to dtschema Krzysztof Kozlowski
2022-02-06 13:57 ` Krzysztof Kozlowski
2022-02-06 13:58 ` [PATCH v3 1/8] dt-bindings: memory: lpddr2-timings: " Krzysztof Kozlowski
2022-02-06 13:58   ` Krzysztof Kozlowski
2022-02-06 13:58 ` [PATCH v3 2/8] dt-bindings: memory: lpddr3-timings: " Krzysztof Kozlowski
2022-02-06 13:58   ` Krzysztof Kozlowski
2022-02-06 13:58 ` [PATCH v3 3/8] dt-bindings: memory: lpddr3: " Krzysztof Kozlowski
2022-02-06 13:58   ` Krzysztof Kozlowski
2022-02-06 15:33   ` Dmitry Osipenko
2022-02-06 15:33     ` Dmitry Osipenko
2022-02-06 13:58 ` [PATCH v3 4/8] dt-bindings: memory: lpddr3: adjust IO width to spec Krzysztof Kozlowski
2022-02-06 13:58   ` Krzysztof Kozlowski
2022-02-06 13:58 ` [PATCH v3 5/8] dt-bindings: memory: lpddr3: deprecate manufacturer ID Krzysztof Kozlowski
2022-02-06 13:58   ` Krzysztof Kozlowski
2022-02-07  4:14   ` Alim Akhtar
2022-02-07  4:14     ` Alim Akhtar
2022-02-07  8:56     ` Krzysztof Kozlowski [this message]
2022-02-07  8:56       ` Krzysztof Kozlowski
2022-02-07 11:24       ` Alim Akhtar
2022-02-07 11:24         ` Alim Akhtar
2022-02-06 13:58 ` [PATCH v3 6/8] dt-bindings: memory: lpddr3: deprecate passing timings frequency as unit address Krzysztof Kozlowski
2022-02-06 13:58   ` Krzysztof Kozlowski
2022-02-06 15:33   ` Dmitry Osipenko
2022-02-06 15:33     ` Dmitry Osipenko
2022-02-06 13:58 ` [PATCH v3 7/8] memory: of: parse max-freq property Krzysztof Kozlowski
2022-02-06 13:58   ` Krzysztof Kozlowski
2022-02-06 15:33   ` Dmitry Osipenko
2022-02-06 15:33     ` Dmitry Osipenko
2022-02-07  4:16   ` Alim Akhtar
2022-02-07  4:16     ` Alim Akhtar
2022-02-06 13:59 ` [PATCH v3 8/8] ARM: dts: exynos: remove deprecated unit address for LPDDR3 timings on Odroid Krzysztof Kozlowski
2022-02-06 13:59   ` Krzysztof Kozlowski
2022-02-06 15:35   ` Dmitry Osipenko
2022-02-06 15:35     ` Dmitry Osipenko
2022-04-04 17:02   ` (subset) " Krzysztof Kozlowski
2022-04-04 17:02     ` Krzysztof Kozlowski
2022-02-07 21:57 ` [PATCH v3 0/8] dt-bindings: memory: convert to dtschema Rob Herring
2022-02-07 21:57   ` Rob Herring
2022-02-09 14:36 ` Krzysztof Kozlowski
2022-02-09 14:36   ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4b18991e-1c93-077d-368f-a861e8c2b845@canonical.com \
    --to=krzysztof.kozlowski@canonical.com \
    --cc=alim.akhtar@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=digetx@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.