[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140903192224.GA6008@roeck-us.net>
Date: Wed, 3 Sep 2014 12:22:24 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Prarit Bhargava <prarit@...hat.com>
Cc: Peter Tyser <ptyser@...-inc.com>, Lee Jones <lee.jones@...aro.org>,
linux-kernel@...r.kernel.org, Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: [PATCH] x86, lpc, Allow only one load of lpc_ich
On Wed, Sep 03, 2014 at 01:56:51PM -0400, Prarit Bhargava wrote:
>
>
> On 09/03/2014 01:29 PM, Peter Tyser wrote:
> >>>>>> Then why do they [have two devices specified]?
> >>>>>
> >>>>> Because the vendor didn't/forgot to hide one from the kernel in BIOS --
> >>>>> hence FW_BUG.
> >>>>
> >>>> If only one is useful, why have the second one in the first place?
> >>>
> >>> That's just it -- it shouldn't have been exposed (again, according to
> >>> Intel).>
> >>>> If the devices are present and we can see them, why not have 2? Some
> >>>> users might find a use for them.
> >>>
> >>> No one will.
> >>
> >> Really ? I must be the "no one" then.
> >>
> >> If available, I like using two watchdogs: One to be controlled by, say,
> >> systemd, one to be controlled by the watchdog daemon. If I have three, I
> >> might find use for it as well: One more to be controlled by whatever
> >> application is running on the system.
>
> IMO you're conflating a general system watchdog with the iTCO watchdog. They're
> two very different things.
>
The lpc driver instantiates iTCO watchdogs, so yes, this is the one I refer to.
Please explain its difference to a 'system watchdog', and what your
understanding of a system watchdog is if it is different to the iTCO watchdog.
> http://h50146.www5.hp.com/products/software/oe/linux/mainstream/support/whitepaper/pdfs/c03231796.pdf
>
This document talks about consistent device names, so guess I must be missing
something.
> >>
> >> Sure, that may be considered overkill, but declaring that "no one will use
> >> them" if more than one watchdog is available is just not correct. After
> >> all, there was a _reason_ for introducing the capability to support more
> >> than one watchdog into the watchdog subsystem.
>
> I thought that was to get all the various watchdogs (NMI, softlockup, fs, etc)
> using the same functionality? But I do see your point.
>
No. It lets you, for example, use a SuperIO based watchdog _and_ the iTCO
watchdog in the same system at the same time. Plus, if you want, you can add
a software watchdog as well.
> >>
> >> Similar, if there are multiple LPCs with separate GPIO pins on each in the
> >> system, I don't entirely understand why the GPIO pins on the second chip
> >> would or should be declared to be unusable. Why ?
>
> Hmm ... good question. I'll have to see whether or not ACPI, etc., can even
> distinguish between two.
>
> >
> > I agree with Guenter - I'd like to support and use as many watchdogs and GPIOs
> > as available. High reliability applications often have 2 watchdogs as a data
> > point, and more GPIO is always nice!
> >
> > Can you give more background on your hardware and firmware setup?
>
> Unfortunately I cannot :( The system isn't "mine" per se. It is (as the dumps
> show) IBM's.
>
> Are there
> > physically two ICH bridges, or just one that is showing up two times due to a
> > firmware bug?
>
> I can answer that. There are two physical ICH bridges, and according to Intel
> one should be masked off. We shouldn't run with two.
>
But if the second chip is not masked off, what prevents the system vendor from
enabling the iTCO watchdog on both, and/or the GPIO pins on both ? Plus, even
if only one of the ICHs is supposed to be used, but if both are enabled by the
BIOS, how is the OS supposed to know which of the two chips is the one that is
supposed to be active ? How does the OS know that or if it is the first chip
it encounters and not the second one ?
Thanks,
Guenter
--
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/
Powered by blists - more mailing lists