Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

[Guenter Roeck <linux@roeck-us.net>]

On 05/23/2015 10:26 AM, Fu Wei wrote:
> Hi Timur,
>
>
>
> On 23 May 2015 at 23:08, Timur Tabi <timur@codeaurora.org> wrote:
>> Arnd Bergmann wrote:
>>>
>>> I think it's a reasonable assumption that someone will sooner or later
>>> put that hardware into an ARM32 machine,
>>
>>
>> I'm going to have to disagree.  If they haven't done it by now, I can't
>> imagine any ARM SOC vendor creating a 32-bit ARM SOC with an SBSA watchdog
>> in it.  I can imagine a vendor trying to repurpose an existing 32-bit ARM
>> SOC for the server market, but that SOC won't have an SBSA watchdog in it.
>
> I will agree with you on this, ONLY IF a people can represent ARM and
> all chip vendors say publicly:
> " We never ever use SBSA watchdog IP core on ARM32!" or " SBSA
> watchdog IP core is imcompatible with ARM32"
>
> Although the SBSA is all about ARMv8, but in "5 APPENDIX A: GENERIC
> WATCHDOG", it doesn't say "this is only for ARMv8".
> and its clock source "system counter" and arm_arch_timer have been in
> ARM32 Soc for years,
> and all the regs in SBSA watchdog is 32bit. I can't see why we can not
> do that, unless I miss something.
>
> I wonder why you are so sure "that SOC won't have an SBSA watchdog in
> it."  any documentation ?
> Sorry, I am not a chip design engineer, I can't see why 32-bit ARM
> won't have an SBSA watchdog in it.
>

I think it is quite unfortunate that the specification is not public.
We have heard many statements about what is in the spec or not.
We have two possible implementations of the SBSA watchdog, but not
even the implementers of those two implementations seem to be able
to agree what the specification actually mandates/supports, or what
it doesn't mandate/support.

We have heard that the SBSA watchdog would require ACPI, and that it
doesn't. We have heard that it would require ARM64, and that it doesn't.
We have heard various assumptions about how WS0 and WS1 are supposed
to be wired. We have heard that all its registers are 32 bit (which
would suggest they have to be treated as such), but then we have a
64 bit register access in one of the drivers, and a more complex
implementation to read the same value as two 32-bit reads in the other.
We have heard that WS0 and WS1 are at least to some degree independent
of each other (and thus that it makes sense to set them separately),
and we have heard that WS1 is always equal to WS0 * 2. We have one
implementation limiting support to architecture revision 0, and the
other not imposing such a restriction.

Is the specification really that vague in such key areas ?
How do you expect anyone who doesn't have access to the specification
to be able to figure out what is actually correct and how to proceed ?

Thanks,
Guenter