From: Prarit Bhargava <prarit@redhat.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: linux-kernel@vger.kernel.org, Peter Tyser <ptyser@xes-inc.com>,
Samuel Ortiz <sameo@linux.intel.com>
Subject: Re: [PATCH] x86, lpc, Allow only one load of lpc_ich
Date: Wed, 03 Sep 2014 08:23:30 -0400 [thread overview]
Message-ID: <54070842.2000700@redhat.com> (raw)
In-Reply-To: <20140903121941.GF28985@lee--X1>
On 09/03/2014 08:19 AM, Lee Jones wrote:
> On Wed, 03 Sep 2014, Prarit Bhargava wrote:
>> On 09/03/2014 07:35 AM, Lee Jones wrote:
>>>>>> This occurs because there are two LPC devices on the system:
>>>>>>
>>>>>> 00:1f.0 ISA bridge: Intel Corporation 82801JIB (ICH10) LPC Interface Controller
>>>>>> 80:1f.0 ISA bridge: Intel Corporation 82801JIB (ICH10) LPC Interface Controller
>>>>>>
>>>>>> which AFAICT is a hardware configuration error that can be resolved in
>>>>>> firmware by hiding the second LPC device. Having two of these results in
>>>>>> two GPIO mappings and two Watchdog Timers which doesn't make much sense.
>>>>>>
>>>>>> An end user has no idea what the splats mean. We should inform the user that
>>>>>> the issue lies with the hardware and that they should contact their vendor
>>>>>> for resolution.
>>>>>
>>>>> Why is it a problem for 2 of these devices to exist on a single system?
>>>>>
>>>>> Shouldn't the driver just be able to handle 2 devices?
>>>>>
>>
>>>>
>>>> You end up with two watchdogs on the same system (and more confusingly they use
>>>> the same global interface). Additionally you end up with two sets of GPIOs
>>>> which also use the same global interface ... not good.
>>>
>>> I understand the problem with the _driver_, but why is it a problem
>>> that two of these _devices_ exist on one system? Bailing out of the
>>> second .probe() sounds hacky to me. The driver should know that this
>>> is possible and act accordingly, or the second devices shouldn't be
>>> registered.
>>>
>>> Can these devices be controlled seperately?
>>
>> Let's just try and address this for now ... They can be controlled separately
>> but that's not the issue here.
>>
>> Consider just the watchdog timer (because it is easier to explain). The way the
>> watchdog timer works is that we write to it every 30 seconds (or so ... it
>> depends on your setup obviously). If we don't write to it within 30 seconds the
>> system will panic and reboot.
>>
>> Now ... suppose you have two on a system. To what end? It doesn't make sense to
>> have two. Either you can write from userspace or you can't. Now you have two
>> running with different timeouts -- why? That doesn't make sense either. It
>
> You only have 2 running if you start them both.
>
>> isn't like the one with the longer timeout is ever going to cause a reboot.
>>
>> Does that explain things better? It's a not a real-world scenario.
>
> On the h/w I'm currently working on, we have 3 Watchdogs.
"3": what are they? Are they all system-level watchdogs? I can understand the
BMC having a watchdog, the system HW having a watchdog (which is what we're
talking about here), and I'm sure we can think of other watchdogs ... but two
that are EXACTLY the same?
>
>> You also asked ...
>>
>>> 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.
>
> In the WARNING you submitted only sysfs was having a hard time.
> Perhaps the real fix would be to allow the Watchdog and GPIO driver to
> change their name when registering, so they can each have their own
> sysfs entries.
/me scratches head.
How does that help having multiple devices which shouldn't be exposed?
P.
>
next prev parent reply other threads:[~2014-09-03 12:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-02 21:58 [PATCH] x86, lpc, Allow only one load of lpc_ich Prarit Bhargava
2014-09-03 7:43 ` Lee Jones
2014-09-03 10:13 ` Prarit Bhargava
2014-09-03 11:35 ` Lee Jones
2014-09-03 11:55 ` Prarit Bhargava
2014-09-03 12:19 ` Lee Jones
2014-09-03 12:23 ` Prarit Bhargava [this message]
2014-09-03 12:36 ` Lee Jones
2014-09-03 15:57 ` Guenter Roeck
2014-09-03 17:29 ` Peter Tyser
2014-09-03 17:56 ` Prarit Bhargava
2014-09-03 19:13 ` Peter Tyser
2014-09-03 20:08 ` Guenter Roeck
2014-09-03 19:22 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54070842.2000700@redhat.com \
--to=prarit@redhat.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptyser@xes-inc.com \
--cc=sameo@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox