RE: [PATCH v3 5/8] dt-bindings: memory: lpddr3: deprecate manufacturer ID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




>-----Original Message-----
>From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@xxxxxxxxxxxxx]
>Sent: Monday, February 7, 2022 2:27 PM
>To: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>; 'Rob Herring'
><robh+dt@xxxxxxxxxx>; 'Lukasz Luba' <lukasz.luba@xxxxxxx>; 'Dmitry
>Osipenko' <digetx@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx;
>devicetree@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx; linux-samsung-
>soc@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [PATCH v3 5/8] dt-bindings: memory: lpddr3: deprecate
>manufacturer ID
>
>On 07/02/2022 05:14, Alim Akhtar wrote:
>> Hi Krzysztof
>>
>>> -----Original Message-----
>>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@xxxxxxxxxxxxx]
>>> Sent: Sunday, February 6, 2022 7:28 PM
>>> To: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx>; Rob
>>> Herring <robh+dt@xxxxxxxxxx>; Lukasz Luba <lukasz.luba@xxxxxxx>; Alim
>>> Akhtar <alim.akhtar@xxxxxxxxxxx>; Dmitry Osipenko
><digetx@xxxxxxxxx>;
>>> linux- kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
>>> pm@xxxxxxxxxxxxxxx; linux-samsung-soc@xxxxxxxxxxxxxxx; linux-arm-
>>> kernel@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxx>
>>> ---
>>> .../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.
>
Ok, so there are two part of it, first one to get the compatible and bind the device 
and second one to get the manufacturer ID from MR5 for say user application.
Second one can still be handled at driver side, so

Reviewed-by: Alim Akhtar <alim.akhtar@xxxxxxxxxxx>


>Best regards,
>Krzysztof





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux