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: <PH0PR84MB17181C316E55073EBC28C386881E9@PH0PR84MB1718.NAMPRD84.PROD.OUTLOOK.COM>
Date:   Tue, 29 Mar 2022 21:45:19 +0000
From:   "Hawkins, Nick" <nick.hawkins@....com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        "Verdun, Jean-Marie" <verdun@....com>,
        Olof Johansson <olof@...om.net>,
        "soc@...nel.org" <soc@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device
 tree



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@...db.de] 
Sent: Tuesday, March 29, 2022 4:13 PM
To: Hawkins, Nick <nick.hawkins@....com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>; Verdun, Jean-Marie <verdun@....com>; Arnd Bergmann <arnd@...db.de>; Olof Johansson <olof@...om.net>; soc@...nel.org; Rob Herring <robh+dt@...nel.org>; linux-arm-kernel@...ts.infradead.org; devicetree@...r.kernel.org; linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@....com>> wrote:

>> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
>
>> For instance with our watchdog controls we have:
>
>> @90 the countdown value
>> @96 the configuration
>
>> And for our timer we have:
>> @80 the countdown value
>> @94 the configuration
>> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
>
>> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.

> I think this is most commonly done using a 'syscon' node, have a look at the files listed by


> $ git grep syscon drivers/watchdog/ drivers/clocksource/

Is this a good example of what you were thinking of? I found this in arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi

sysctrl@...40000 {
                        compatible = "socionext,uniphier-ld11-sysctrl",
                                     "simple-mfd", "syscon";
                        reg = <0x61840000 0x10000>;

                        sys_clk: clock {
                                compatible = "socionext,uniphier-ld11-clock";
                                #clock-cells = <1>;
                        };

                        sys_rst: reset {
                                compatible = "socionext,uniphier-ld11-reset";
                                #reset-cells = <1>;
                        };

                        watchdog {
                                compatible = "socionext,uniphier-wdt";
                        };
 };

If that is the case..

timectrl@80 {
	compatible = "hpe,gxp-timectrl","syscon";
	reg = <0x80 0x16>;

	watchdog0: watchdog {
		compatible = "hpe,gxp-wdt";
	}

	timer0: timer {
		compatible = "hpe,gxp-timer";
	}
}
	

> You may also want to look at those drivers to find if any of them can be directly reused, this is perhaps a licensed IP block that others are using as well.

I will look and see if any of them have the same register sets and functionality.

Thanks,

-Nick Hawkins

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ