linux-kernel - Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling 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: <200811241736.53067.trenn@suse.de>
Date:	Mon, 24 Nov 2008 17:36:52 +0100
From:	Thomas Renninger <trenn@...e.de>
To:	Tom Hughes <tom@...pton.nu>
Cc:	Cristiano Prisciandaro <cristiano.p@...net.ch>,
	Dave Jones <davej@...hat.com>, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org, acpi4asus-user@...ts.sourceforge.net
Subject: Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver

On Monday 24 November 2008 04:13:24 pm Thomas Renninger wrote:
> On Monday 24 November 2008 10:38:58 am Tom Hughes wrote:
> > Cristiano Prisciandaro wrote:
> > > From: Cristiano Prisciandaro <cristiano.p@...net.ch>
> > >
> > > The bios of the eeepc 900 exposes an acpi method that allows clocking
> > > the cpu to 630/900 MHz. This driver allows controlling the frequency
> > > switch through the cpufreq subsystem.
> >
> > I should perhaps add at this point that I have an alternative patch
> > based on Cristiano's code, which adds this cpufreq driver to the
> > existing eeepc-laptop module rather than creating a separate module for
> > it.
> >
> > Personally I'm quite happy with either solution so I'll leave it to you
> > to decide what is the best way to go, but my patch is available if you
> > want it.
>
> Either way, shouldn't you be able to provide a dmi matching module alias:
> MODULE_ALIAS("dmi:...")
> for autoloading?
>
> Or are these two cpufreq functions part of an ACPI device you could match
> for, then it should get an ACPI driver?
Oh, they are part of this general Asus \\_SB.ATKD device, which is only
used by asus_laptop.c until now?
I don't know \\_SB.ATKD in detail, but it has not a HID to match against and 
contains ASUS specific ACPI helper functions?

Looks like a growing mess in the ASUS ACPI area...

Some more questions:
Why are they providing their own cpufreq interface and not following the
spec (providing _PSS, ..)?
Could it be that you are only throttling the CPU?

Are these functions already used by the ACPI tables internally?
  - could be dangerous
  - could be helpful -> Is there some upper level device/interface in ASL?

Could it happen that upcoming machines provide this interface (the two ACPI 
functions) and also can do real CPU frequency/volt switching, e.g. via 
acpi-cpufreq?

     Thomas

> If this ACPI device provides more functions, then these should probably
> also be added to this driver.
> Splitting the OS drivers the same way as BIOS splits up functionality into
> ACPI devices is a good idea.
>
> Could you paste at least the whole ACPI device in which:
> #define ASUS_CPUFV_READ_METHOD   "CFVG"
> #define ASUS_CPUFV_WRITE_METHOD  "CFVS"
> sit or better point to an acpidump/dsdt output.
>
>      Thomas
--
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/