[Adding tglx to CC as he knows more about HPET's than I]
On Sunday 03 February 2008 18:33:57 [EMAIL PROTECTED] wrote:
> Hello,
> I have a asus a6t with nforce4/MCP51 chipset. I pass to kernel 2.6.24
> 32 bit the options acpi_use_timer_override and hpet=force, in this way
> and the timer IRQ ends
On Tuesday 12 February 2008 04:41:42 Linus Torvalds wrote:
>
> On Mon, 11 Feb 2008, Carlos Corbacho wrote:
> >
> > WMI drivers, like their ACPI counterparts, should also check if ACPI is
> > disabled or not, and bail out if so, otherwise we cause a crash.
>
> S
On Wednesday 13 February 2008 04:03:25 Al Viro wrote:
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: Carlos Corbacho <[EMAIL PROTECTED]>
> ---
> d2d6f5b9eb315a53043a722d952bb21ed5ca1229
> diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c
> index 457ed3d..efa
> gcc drop their inlining and the module are hot plugged.
>
> Fix by annotating acer_led_init() and acer_backlight_init() __devinit.
>
> Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
> Cc: Len Brown <[EMAIL P
On Sunday 17 February 2008 18:20:08 Ingo Molnar wrote:
> i suspect this should be merged by the char driver tree which is
> affected by the addition of these new entries.
Where is such a tree, and who's responsible for it though? I grep'ed
MAINTAINERS and didn't turn up anyone.
-Carlos
--
E-Mai
On Thursday 07 February 2008 22:34:55 Pavel Machek wrote:
> +3) What is the ACPI-WMI mapper
> +
> +The Linux ACPI-WMI driver is the implementation of this mapper for Linux.
>
> Yes, please. This needs translation into plain english.
In plain English? ACPI-WMI is a nasty hack/ abuse of ACPI by M
On Thursday 07 February 2008 23:33:54 Ray Lee wrote:
> Do you have list of hardware/platforms that require this feature to
> get the hardware to work? (acer abc123, tcm1100 xyz)
I have a very long list of Acer laptops that are supported - which is far too
long, and changes on far too much of a re
On Friday 08 February 2008 00:12:24 Ray Lee wrote:
> While I'm not trying to set you up for a firing squad, if you can show
> that the only use this driver has is as underlying support for Acer/HP
> xyz drivers,
Certainly at the moment, this is the only real use it has (and the only reason
I spe
On Friday 08 February 2008 00:12:24 Ray Lee wrote:
> On Feb 7, 2008 3:51 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote:
> > On Thursday 07 February 2008 23:33:54 Ray Lee wrote:
> > > Do you have list of hardware/platforms that require this feature to
> > > get t
On Friday 08 February 2008 01:38:01 Ray Lee wrote:
> That's clear to me (whereas the original wasn't), though I would
> still argue for this driver being select'ed by the drivers that
> require it. As you note, other laptop specific drivers do so, and
> Linus has come down in favor of that as well
On Friday 08 February 2008 06:53:13 Pavel Machek wrote:
> I believe selct is the way to go here. What do acer-wmi handle?
> Additional buttons? Leds? Temperatures? Fan states?
Enabling wireless, bluetooth and 3G; and exposing the mail LED and backlight.
tc1100-wmi handles wireless and the jog dia
The source code for this driver is currently located in drivers/char, and
given that this is not an x86 processor feature, it shouldn't live in the
x86 Kconfig.
So lets move it to the Kconfig for drivers/char instead, and just add
a dependency on x86.
Signed-off-by: Carlos Corbacho &l
latest tree, since x86 git seems to be missing an
earlier Kconfig patch for I8K that dropped the x86_32 limitation.
-Carlos
---
Carlos Corbacho (2):
toshiba - Move Kconfig entry to drivers/char
i8k - Move Kconfig entry to drivers/char
arch/x86/Kconfig | 36
The source code for this driver is currently located in drivers/char, and
given that this is not an x86 processor feature, it shouldn't live in the
x86 Kconfig.
So lets move it to the Kconfig for drivers/char instead.
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
CC: Jonat
ere on my other box that lacks ACPI-WMI.
Ingo, can you try the patch below and see if this cures it?
---
ACPI: WMI: Fix crash on WMI free systems
From: Carlos Corbacho <[EMAIL PROTECTED]>
We have two pointers in the find_guid() code that aren't checked before
we use them. On ACPI-WMI
tc1100-wmi - Fail gracefully if ACPI is disabled
From: Carlos Corbacho <[EMAIL PROTECTED]>
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho &
acer-wmi - Fail gracefully if ACPI is disabled
From: Carlos Corbacho <[EMAIL PROTECTED]>
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho &
On Monday 11 February 2008 09:17:43 Ingo Molnar wrote:
> no, it does not help - see the attached .config and the crash.log.
Thanks Ingo - the cause of the crash is ACPI being disabled on your system for
some reason. I can reproduce your crash every time here with acpi=off.
The two WMI based driv
On Saturday 05 January 2008 17:52:06 Rémi Hérilier wrote:
> What about finding what does this BIOS function and writing
> an equivalent in C? There would be no BIOS call anymore and
> this module could be used in the x86-64 port.
>
> But, is it a sane solution?
The problem is that the BIOS call wo
(CC'ing linux-input, as that is the relevant subsystem list for wistron-btns).
Rémi Hérilier wrote:
> To use my previous patch (wistron_btns support for fujitsu-siemens amilo
> pro edition v3505) with my laptop, I need to make the wistron module
> compile for x86_64. It is based on Linux 2.4.24-rc
On Sunday 23 December 2007 23:12:47 H. Peter Anvin wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 23 of December 2007, Linus Torvalds wrote:
> >> On Sun, 23 Dec 2007, Rafael J. Wysocki wrote:
> >>> The patch is fine by me, so if anyone has objections, please speak up.
> >>
> >> There is absolutel
On Monday 24 December 2007 01:14:34 Linus Torvalds wrote:
> Side note: we could obviously undo the commit that triggered this for you
> [..]
> In other words, we'd have to go back to our original ordering, which Len
> said was fundamentally wrong. I don't think anybody really wants that.
Nor would
On Monday 24 December 2007 18:34:21 Linus Torvalds wrote:
> On Mon, 24 Dec 2007, Rafael J. Wysocki wrote:
> > Well, having considered that for a longer while, I think the AML code is
> > referring to a device that we have suspended already, and since it's in a
> > low power state, it just can't han
On Monday 24 December 2007 22:40:46 Robert Hancock wrote:
> The ACPI spec has the following to say about the _PTS method:
>
> "The platform must not make any assumptions about the state of the
> machine when _PTS is called. For example, operation region accesses that
> require devices to be configu
Adding Linux-ACPI to CC.
On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
> According to the earlier versions of the ACPI spec, Linux is doing the
> wrong thing - we should call _PTS() before we start powerding down devices,
> or notifying device drivers to start suspending.
&
Pavel,
On Tuesday 25 December 2007 12:12:31 Pavel Machek wrote:
> > The patch is fine by me, so if anyone has objections, please speak up.
>
> Just.. I have been running with very similar patch for few years... it
> fixes few prototype machines I have here.
I've withdrawn the patch since it doesn
On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote:
> Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning
> from the Working to the Sleeping State (which is what we're discussing
> here):
>
> 3. OSPM places all device drivers into their respective Dx state. If the
>
On Tuesday 25 December 2007 14:07:22 Rafael J. Wysocki wrote:
> OK, sorry, the approach is generally reasonable, IMO, but it needs to be a
> bit more fine grained.
I know, hence this was marked as a hack and not signed off; it's just a
demonstration of the general idea with code instead of words.
On Thursday 27 December 2007 18:03:52 Rafael J. Wysocki wrote:
> Please review (and test, if possible).
Suspend now works properly here with this patch set.
Tested-by: Carlos Corbacho <[EMAIL PROTECTED]>
--
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE7
cannot currently test that):
Tested-by: Carlos Corbacho <[EMAIL PROTECTED]>
However, my only concerns are that:
1) tifm_ms was not autoloaded
2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not.
Although, whether this is an issue with userspace (ie. udev) not dealin
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote:
> On Dec 31 2007 00:01, Carlos Corbacho wrote:
> >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote:
> >> From: Alex Dubov <[EMAIL PROTECTED]>
> >>
> >> Sony MemoryStick cards are
On Monday 31 December 2007 01:01:08 Alex Dubov wrote:
> This is exactly the same as with tifm_sd module if you noticed.
Unfortunately not, I've really never used tifm_sd as I don't have any MMC/ SD
cards.
> Second, it is impossible to guess in advance, which type of card is put
> into slot (Pro,
On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote:
> I suspect the manufacturers would say "Oh, the sensors? The BIOS
> isn't broken, you're just supposed to use WMI or some (undocumented)
> ACPI device to get at those."
It's quite possible - can we have DSDTs for the boards in question s
On Thursday 20 December 2007 02:13:22 Elvis Pranskevichus wrote:
> Hi Carlos,
>
> I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to
> bugzilla entry #9514:
>
> http://bugzilla.kernel.org/attachment.cgi?id=14132
A quick look over the DSDT shows that there is no ACPI-WMI map
From: Carlos Corbacho <[EMAIL PROTECTED]>
This patch adds a quirk from LinuxBIOS to force enable HPET on
the nVidia CK804 (nForce 4) chipset.
This quirk can very likely support more than just nForce 4
(LinuxBIOS use the same code for nForce 5), and possibly nForce 3,
but I don't
From: Carlos Corbacho <[EMAIL PROTECTED]>
Actually set force_hpet_resume_type.
---
Whoops, just noticed I forgot to re-add this to the patch before submitting it.
arch/x86/kernel/quirks.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/quirks.c
Thomas,
On Friday 19 October 2007 07:50:08 Thomas Gleixner wrote:
> So if there are working quirks, please refactor them analogous to the
> existing ones in quirks.c.
>
> All undocumented chipset poking needs to be protected by the
> hpet=force boot option, so the default is not to do scan for it
From: Carlos Corbacho <[EMAIL PROTECTED]>
Add support to force_hpet for all known MCP55 (nForce 5) chipset
LPC bridges.
---
These are the untested nForce 5 chips (taken from Mikko's original
patch, and checked against pci.ids).
arch/x86/kernel/quirks.c | 18
(Resend with CC's fixed)
Back in April, Mikko posted a patch to force enable the HPET on some nVidia
chipsets:
v2:
http://lkml.org/lkml/2007/4/16/46
v3:
http://lkml.org/lkml/2007/4/17/354
What would need to be done to this patch to get it into x86 now (besides i386/
x86_64 -> x86 conversion),
Bernhard Rosenkraenzer wrote:
> The patch below adds support for Medion WIM2160 notebooks to the
> wistron-btns driver.
Do these keys emit proper scancodes though? If yes (i.e. you press a button
and get a warning about "unknown scancodes" in dmesg), then they should not
be added to wistron-btns,
40 matches
Mail list logo
