Re: Additional patches in my watchdog-next branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Thomas,


On 30 December 2015 at 17:44, Thomas Petazzoni
<thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote:
> Guenter,
>
> On Tue, 29 Dec 2015 09:28:48 -0800, Guenter Roeck wrote:
>
>> Probem with SBSA and pretimeout is two-fold. First, it adds a quite a bit of
>> complexity to the driver, second, it adds a lot of risk to the driver.
>> Reason is that this is not one specific watchdog, but a watchdog implementation
>> based on a standard which, in my opinion, is less than well thought out
>> and leaves a lot of ambiguity when it comes to implementation details.
>
> I agree that calling the SBSA watchdog specification a "specification"
> is a strong word. At least in the version I have, it's 4-5 pages of
> somewhat random thoughts on what a standardized watchdog could look
> like, but not a very well-defined specification that guarantees that
> all implementations will behave in the same way.

Although the basic function is described well in spec 2.3, but it do
need some improvement, in my opinion.

>
>> The more functionality is used, the higher the risk that some implementation
>> won't work.
>
> Maybe we should enforce that all users of the driver use two Device
> Tree compatible strings:
>
>         compatible = "<vendor>,sbsa-gwdt", "arm,sbsa-gwdt";
>
> So that the SBSA watchdog driver can implement vendor specific quirks
> if needed. Though it is true that the HW has some identification
> registers that should allow to differentiate between the implementation.

I think the implementation can be different, but all the SBSA watchdog
should be able to use the same driver.

>
>> I think we should stick with the basic implemementation and not support
>> pretimeout at all with the SBSA driver. If the maximum timeout is insufficient,
>> there are two options: Use the soft-timeout handled by the watchdog core,
>> which will hopefully make it for 4.6, or live with it.
>
> For now, I'm personally fine with a SBSA driver that does not support
> the pretimeout. Is anyone working on submitting something like this ?

I am working on a new non-pretimeout  SBSA driver.

There are two patchsets :
(1) Timur's v4 patch : http://www.spinics.net/lists/linux-watchdog/msg06567.html
(2) my previous non-pretimeout version : https://lkml.org/lkml/2015/6/10/766

>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux