linux-kernel - Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver

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: <56452970.4070209@linaro.org>
Date:	Thu, 12 Nov 2015 17:06:08 -0700
From:	Al Stone <al.stone@...aro.org>
To:	Guenter Roeck <linux@...ck-us.net>, Fu Wei <fu.wei@...aro.org>,
	Timur Tabi <timur@...eaurora.org>
Cc:	Pratyush Anand <panand@...hat.com>, devicetree@...r.kernel.org,
	linux-watchdog@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	linux-doc@...r.kernel.org, Jon Masters <jcm@...hat.com>,
	Linaro ACPI Mailman List <linaro-acpi@...ts.linaro.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	lkml <linux-kernel@...r.kernel.org>,
	Will Deacon <will.deacon@....com>,
	Wim Van Sebroeck <wim@...ana.be>,
	Rob Herring <robherring2@...il.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Wei Fu <tekkamanninja@...il.com>,
	Jonathan Corbet <corbet@....net>,
	Dave Young <dyoung@...hat.com>,
	Vipul Gandhi <vgandhi@...eaurora.org>
Subject: Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA
 watchdog driver

On 11/05/2015 09:41 AM, Guenter Roeck wrote:
> On 11/05/2015 07:00 AM, Fu Wei wrote:
>> Hi Timur,
>>
>> On 5 November 2015 at 22:40, Timur Tabi <timur@...eaurora.org> wrote:
>>> Fu Wei wrote:
>>>>
>>>> Did you really read the "Note" above???????? OK, let me paste it again
>>>> and again:
>>>>
>>>> SBSA 2.3 Page 23 :
>>>> If a larger watch period is required then the compare value can be
>>>> programmed directly into the compare value register.
>>>
>>>
>>> Well, okay.  Sorry, I should have read what you pasted more closely. But I
>>
>> Thanks for reading it again.
>>
>>> think that means during initialization, not during the WS0 timeout.
>>
>> I really don't see SBSA say "during initialization, not during the WS0 timeout",
>> please point it out the page number and the line number in SBSA spec.
>> maybe I miss it?
>> Thanks for your help in advance.
>>
>>>
>>> Anyway, I still don't like the fact that you're programming WCV in the
>>
>> "you don't like" doesn't mean "it is wrong" or "we can't do this", so
>> I will keep this way unless we have better idea to extend second stage
>> timeout.
>>
>>> interrupt handler, but I'm not going to make a big deal about it any more.
>>
>> Deal, Thanks a lot.
>>
> 
> The problem with your driver, as I see it, is that dealing with WS0/WS1
> and pretimeout makes the driver so complex that, at least for my part,
> I am very wary about it. The driver could long since have been accepted
> if it were not for that. Besides that, I really believe that any system designer
> using the highest permitted frequency should be willing to live with the
> consequences, and not force the implementation of a a complex driver.
> 
> Ultimately, you'll have to decide if you want a simple driver accepted, or
> a complex driver hanging in the review queue forever.
> 
> Thanks,
> Guenter

Sorry to poke my head in late like this, but I do have a vested interest in the
outcome so I'm very curious.  For my work, I need to have an ACPI-supported,
SBSA-compliant watchdog timer for arm64, and this series is one of the key
pieces to getting there.  The plan for me has been: (1) get an FDT based SBSA
watchdog timer, (2) add in kernel code to handle the ACPI GTDT table describing
timers, then (3) munge the SBSA watchdog timer for use by ACPI.

So, is this an actual NAK of the patch series as is?  I think it is, but I want
it to be clear, and it has not been explicit yet.

If it is a NAK, that's fine, but I also want to be sure I understand what the
objections are.  Based on my understanding of the discussion so far over the
multiple versions, I think the primary objection is that the use of pretimeout
makes this driver too complex, and indeed complex enough that there is some
concern that it could destabilize a running system.  Do I have that right?

The other possible item I could conclude out of the discussion is that we do
not want to have the pretimeout code as part of the watchdog framework; is that
also the case or did I misunderstand?

And finally, a simpler, single stage timeout watchdog driver would be a
reasonable thing to accept, yes?  I can see where that would make sense.

The issue for me in that case is that the SBSA requires a two stage timeout,
so a single stage driver has no real value for me.  Now, if I can later add in
changes to make the driver into a two stage driver so it is SBSA-compliant,
that would also work, but it will make the driver more complex again.  At that
point, I think I've now gone in a logical circle and the changes would not be
accepted so I could never get to my goal of an SBSA-compliant driver.  I don't
think that's what was meant, so what did I miss?

Thanks in advance for any clarifications that can be provided.....I really do
appreciate it.  Email is not always the clearest mechanism for communication
so sometimes I have to ask odd questions like these so I can understand what
is happening.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Linaro Enterprise Group
al.stone@...aro.org
-----------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/