Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758110AbbEWSfU (ORCPT ); Sat, 23 May 2015 14:35:20 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:60460 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757984AbbEWSfP (ORCPT ); Sat, 23 May 2015 14:35:15 -0400 Message-ID: <5560C85B.8040100@roeck-us.net> Date: Sat, 23 May 2015 11:35:07 -0700 From: Guenter Roeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Fu Wei , Timur Tabi CC: Arnd Bergmann , Hanjun Guo , Suravee Suthikulpanit , Linaro ACPI Mailman List , linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Wei Fu , G Gregory , Al Stone , Ashwin Chaugule , vgandhi@codeaurora.org, wim@iguana.be, Jon Masters , Leo Duran , Jon Corbet , Mark Rutland Subject: Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver References: <=fu.wei@linaro.org> <1432197156-16947-7-git-send-email-fu.wei@linaro.org> <555F4236.7040206@linaro.org> <4095167.UOriXdSu53@wuerfel> <556097D5.9050103@codeaurora.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2972 Lines: 67 On 05/23/2015 10:26 AM, Fu Wei wrote: > Hi Timur, > > > > On 23 May 2015 at 23:08, Timur Tabi 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/