On 10/27/22 18:26, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Oct 27, 2022 at 06:11:19PM +0200, Johan Jonker wrote:
>> On 10/25/22 00:05, Sebastian Reichel wrote:
>>> On Mon, Oct 24, 2022 at 01:50:49PM -0500, Rob Herring wrote:
>>>> On Fri, Oct 21, 2022 at 07:59:26PM -0400, Krzysztof Kozlowski wrote:
>>>>> On 21/10/2022 13:06, Sebastian Reichel wrote:
>>>>>> Convert RTC binding for Haoyu Microelectronics HYM8563 to Device Tree
>>>>>> Schema format.
>>>>>>
>>>>>> Signed-off-by: Sebastian Reichel <sebastian.reichel@xxxxxxxxxxxxx>
>>>>>> ---
>>>>>> .../devicetree/bindings/rtc/haoyu,hym8563.txt | 30 ----------
>>>>>> .../bindings/rtc/haoyu,hym8563.yaml | 55 +++++++++++++++++++
>>>>>> 2 files changed, 55 insertions(+), 30 deletions(-)
>>>>>> delete mode 100644 Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
>>>>>> create mode 100644 Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
>>>>>> deleted file mode 100644
>>>>>> index a8934fe2ab4c..000000000000
>>>>>> --- a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
>>>>>> +++ /dev/null
>>>>>> @@ -1,30 +0,0 @@
>>>>>> -Haoyu Microelectronics HYM8563 Real Time Clock
>>>>>> -
>>>>>> -The HYM8563 provides basic rtc and alarm functionality
>>>>>> -as well as a clock output of up to 32kHz.
>>>>>> -
>>>>>> -Required properties:
>>>>>> -- compatible: should be: "haoyu,hym8563"
>>>>>> -- reg: i2c address
>>>>>> -- #clock-cells: the value should be 0
>>>>>> -
>>>>>> -Optional properties:
>>>>>> -- clock-output-names: From common clock binding
>>>>>> -- interrupts: rtc alarm/event interrupt
>>>>>> -
>>>>>> -Example:
>>>>>> -
>>>>>> -hym8563: hym8563@51 {
>>>>>> - compatible = "haoyu,hym8563";
>>>>>> - reg = <0x51>;
>>>>>> -
>>>>>> - interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
>>>>>> -
>>>>>> - #clock-cells = <0>;
>>>>>> -};
>>>>>> -
>>>>>> -device {
>>>>>> -...
>>>>>> - clocks = <&hym8563>;
>>>>>> -...
>>>>>> -};
>>>>>> diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..b0b6126b12dd
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.yaml
>>>>>> @@ -0,0 +1,55 @@
>>>>>> +# SPDX-License-Identifier: GPL-2.0
>>>>>
>>>>> Dual license please. I don't think you copied any content from original
>>>>> bindings... unless the example?
>>>>>
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/rtc/haoyu,hym8563.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: Haoyu Microelectronics HYM8563 RTC
>>>>>> +
>>>>>> +maintainers:
>>>>>> + - Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx>
>>>>>> +
>>>>>> +properties:
>>>>>> + compatible:
>>>>>> + const: haoyu,hym8563
>>>>>> +
>>>>>> + reg:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + interrupts:
>>>>>> + maxItems: 1
>>>>>> +
>>>>>> + "#clock-cells":
>>>>>> + const: 0
>>>>>> +
>>>>>> + clock-output-names:
>>>>>> + description: From common clock binding to override the default output clock name.
>>>>>
>>>>> You need maxItems for this.
>>>>>
>>>>>> +
>>>>>> + wakeup-source:
>>>>>> + description: Enables wake up of host system on alarm.
>>>>>> +
>>>>>> +allOf:
>>>>>> + - $ref: rtc.yaml
>>>>>> +
>>>>>> +unevaluatedProperties: false
>>>>>> +
>>>>>
>>
>>>>> Would be great if you could also correct DTS using these bindings (see
>>>>> warning from Rob).
>>>>
>>>> It looked to me like 'clock-frequency' should be added to the schema.
>>>
>>> I've sent PATCHv2, which removes clock-frequency from all hym8563
>>> users. My reasoning is, that the old txt binding does not describe
>>> it and the current Linux driver does not handle it as far as I can
>>> see.
>>
>> Didn't note you were doing a conversion as well...
>> From my abandonment patch serie
>>
>> clock-frequency:
>> enum: [1, 32, 1024, 32768]
>>
>> The data sheet shows that it can generate 4 different frequencies.
>> Rockchip mostly uses 32768, but that doesn't mean someone else is
>> not alowed to set what he/she prefers.
>
> As far as I can tell 32768 has been cargo copied by everyone, but
> the driver is not parsing this at all and I would expect the clock
> API to be used for requesting a specific frequency.
DT and Linux driver support are 2 different things.
What Linux currently doesn't support might be needed elsewhere.
Johan
>
> -- Sebastian
