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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ad788d84-48ea-2fdb-607a-a8d49c8fe52c@kernel.org>
Date:   Tue, 30 May 2023 10:01:39 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Romain Perier <romain.perier@...il.com>
Cc:     Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Daniel Palmer <daniel@...f.com>,
        Rob Herring <robh+dt@...nel.org>, linux-rtc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/3] dt-bindings: rtc: Add Mstar SSD20xD RTC devicetree
 bindings documentation

On 22/05/2023 13:27, Romain Perier wrote:
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - mstar,ssd20xd-rtc
>>
>> Why rtc suffix? Can it be anything else?
> 
> Well, it is the dt-bindings for an RTC block ? suppose tomorrow we
> have an ethernet block specific to the SoC SSD202D, it should be
> "mstar,ssd202d-ethernet" , how do you make
> the difference if you just put "mstar,sd202d" ? Plus a lot of rtc
> dt-bindings have this suffix (when it is not an IP name).

There are a lot of bad design choices or bugs - are you going to
implement the same mistakes because someone did it?

> This is
> exactly the case for rtc-msc313e and it was not an issue.

So that was my question - can it be anything else? There is literally no
description of the hardware... Neither in commit msg nor in description:
field in bindings.

What is SSD202D? SoC? RTC?


> 
>>
>> Missing blank line
> 
> ack
> 
>>
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  start-year: true
>>
>> Drop
>>
>> What about interrupt line?
> 
> There is currently no interrupt right now, we have not yet the irqchip
> code for handling the alarm irq of this rtc block.

So you are going to change the hardware and add the interrupt line? We
do not talk about drivers, but hardware. Whether your driver handles it
or not, matters less.

Describe the hardware, not the current implementation of one driver.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ