lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 17 Feb 2024 15:25:30 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Markus Schneider-Pargmann <msp@...libre.com>,
 Rob Herring <robh@...nel.org>
Cc: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
 Tero Kristo <kristo@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
 Santosh Shilimkar <ssantosh@...nel.org>, Andrew Davis <afd@...com>,
 linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] dt-bindings: hwinfo: ti,k3-socinfo: Add nvmem-cells

On 14/02/2024 10:31, Markus Schneider-Pargmann wrote:
> Hi Rob,
> 
> On Tue, Feb 06, 2024 at 06:43:05PM +0000, Rob Herring wrote:
>> On Tue, Feb 06, 2024 at 03:37:09PM +0100, Markus Schneider-Pargmann wrote:
>>> The information k3-socinfo requires is stored in an efuse area. This
>>> area is required by other devices/drivers as well, so using nvmem-cells
>>> can be a cleaner way to describe which information are used.
>>>
>>> If nvmem-cells are supplied, the address range is not required.
>>> Cells chipvariant, chippartno and chipmanufacturer are introduced to
>>> cover all required information.
>>>
>>> Signed-off-by: Markus Schneider-Pargmann <msp@...libre.com>
>>> Reviewed-by: Andrew Davis <afd@...com>
>>> ---
>>>  .../bindings/hwinfo/ti,k3-socinfo.yaml        | 23 ++++++++++++++++++-
>>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>>> index dada28b47ea0..f085b7275b7d 100644
>>> --- a/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>>> +++ b/Documentation/devicetree/bindings/hwinfo/ti,k3-socinfo.yaml
>>> @@ -26,9 +26,24 @@ properties:
>>>    reg:
>>>      maxItems: 1
>>>  
>>> +  nvmem-cells:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
>>> +
>>> +  nvmem-cell-names:
>>> +    items:
>>> +      - const: chipvariant
>>> +      - const: chippartno
>>> +      - const: chipmanufacturer
>>> +
>>>  required:
>>>    - compatible
>>> -  - reg
>>> +
>>> +oneOf:
>>> +  - required:
>>> +      - reg
>>> +  - required:
>>> +      - nvmem-cells
>>> +      - nvmem-cell-names
>>>  
>>>  additionalProperties: false
>>>  
>>> @@ -38,3 +53,9 @@ examples:
>>>          compatible = "ti,am654-chipid";
>>>          reg = <0x43000014 0x4>;
>>>      };
>>> +  - |
>>> +    chipid: chipid@14 {
>>> +        compatible = "ti,am654-chipid";
>>
>> This isn't compatible if you have a completely different way to access 
>> it. 
> 
> Thanks, it is not entirely clear to me how I could go forward with this?
> Are you suggesting to use a different compatible? Or is it something
> else I could do to proceed with this conversion?

What you claim now, is that you have one device with entirely different
interfaces and programming model. So either this is not the same device
or you just wrote bindings to whatever you have in driver.

Nothing in commit msg explains this.

What you should do? Depends. If you just write bindings for driver, then
stop. It's a NAK. Instead write bindings for hardware.

If the first choice, just the hardware is somehow like this, then
explain in commit msg and device description, how this device can be
connected over other bus, not MMIO. You can draw some schematics in
commit msg explaining architecture etc.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ