linux-kernel - Re: [PATCH v2] hpet: Enable hidden HPET on NVidia motherboards

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]

Date:	Tue, 17 Apr 2007 13:13:54 +0300 (EEST)
From:	Mikko Tiihonen <mikko.tiihonen@....fi>
To:	Andi Kleen <andi@...stfloor.org>
cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] hpet: Enable hidden HPET on NVidia motherboards

On Mon, 16 Apr 2007, Andi Kleen wrote:

> On Tue, Apr 17, 2007 at 12:28:31AM +0300, Mikko Tiihonen wrote:
>> I actually was more worried that someone might complain that the pci
>> scanning is copy & paste code from end of the same file. I did try to use
>> the generic pci functions first but because they insist on enabling
>> interrupts they cannot be used this early. And this code needs to be run
>> before the timer initialization.
>
> Yes that's the issue. You're adding another PCI scanner copy'n'pasted
> from the caller of the function you're adding it to. See the problem?

I'll remove the duplicated scanning code in next patch version by creating a 
more general scanning code.

>> If you want I can submit a separate patch to move the ... not nice pci
>> scanning code to pci directory under some early_pci_scan(u32 *pci_ids,
>> hook) function. The same code was already cut&pasted in
>
> That is what early-quirks is anyways. But the way to scan for multple
> things is not to add anther recursive scan, but to just extend or
> change the main loop.

I don't think the quirk can avoid a recursive scan easily. It is supposed to 
be only run if the first scan finds nvidia chipset, does not detect acpi hpet 
and, as a last resort, tries to scan for the hpet manually to avoid enabling 
the original quirk. In more pictoresque way:

scan-for-chipsets
  -> nvidia chipset found
    -> does acpi hpet exist
      -> did manual_hpet_quirk fail (new)
        -> enable acpi_skip_timer_override quirk

It could be done in one scanning loop provided that it is quaranteed that the 
nvidia chipset is always before the the hpet quirk chip in pci hierarchy. Then 
the nvidia quirk needs to be split to two parts, of which the last part is run 
after all other quirks and to check if hpet quirk was ever activated.

scan-for-pci-ids
  -> nvidia chipset id found
    -> does acpi hpet exist
       -> possibly_enable_acpi_skip_timer_override = 1
  -> nvidia pci-id matching hpet chip found
     -> if possibly_enable_acpi_skip_timer_override
        -> did manual_hpet_quirk work
           -> possibly_enable_acpi_skip_timer_override = 0
if possibly_enable_acpi_skip_timer_override
  -> enable acpi_skip_timer_override quirk

But I really do think that overall the first solution is better, even if it 
does a recursive scan. Assuming of course that stupid code duplication is 
removed.

-Mikko
-
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/