Hi Mark,
On Sun, 15 Apr 2007 11:03:20 -0400, Mark M. Hoffman wrote:
Hi Jean, et al:
* Jean Delvare [EMAIL PROTECTED] [2007-04-10 15:02:27 +0200]:
I am resigning from my role as hardware monitoring subsystem
(drivers/hwmon) maintainer. This is too much work for me, I do not have
to get
around it. After all, there must be a reason why there is no native
sensors support in Windows and every vendor provides it's own tool.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi Len,
On Wed, 18 Apr 2007 13:42:56 -0400, Lennart Sorensen wrote:
On Sat, Apr 14, 2007 at 07:28:07PM +0200, Jean Delvare wrote:
Otherwise it looks OK to me, I take the patch. If others have comments
or objections, just speak up and submit incremental patches as needed.
Now I would
= __SPIN_LOCK_UNLOCKED(s3c24xx_i2c.lock),
.wait = __WAIT_QUEUE_HEAD_INITIALIZER(s3c24xx_i2c.wait),
.adap = {
.name = s3c2410-i2c,
Applied, thanks.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi Lennart,
On Thu, 19 Apr 2007 16:59:42 -0400, Lennart Sorensen wrote:
On Thu, Apr 19, 2007 at 08:54:13AM +0200, Jean Delvare wrote:
The major difference is that the implementation in scx200_i2c is
hardware-specific, while the i2c-gpio driver is a generic one, so it's
a lot better
*/
+
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Vitaly,
On Sun, 22 Apr 2007 15:29:37 +0400, Vitaly Bordug wrote:
On Sat, 21 Apr 2007 09:57:07 +0200 Jean Delvare wrote:
I wonder what's the point of having a separate i2c algorithm driver.
We don't expect any other driver than i2c-rpx to ever use it, do we?
In that case, all the code
Lennart,
On Sun, 22 Apr 2007 11:41:51 -0400, Lennart Sorensen wrote:
On Fri, Apr 20, 2007 at 07:49:33PM +0200, Jean Delvare wrote:
The scx200_acb driver was heavily modified in 2.6.17 and 2.6.18, not
much since then. I am not familiar with the hardware so I can't comment
on which chips
On Fri, 9 Mar 2007 12:04:59 +0800, Sonic Zhang wrote:
On 3/8/07, Jean Delvare [EMAIL PROTECTED] wrote:
i2c-core can emulate SMBus transactions using master_xfer, so in
general when you have a complete master_xfer implementation you do not
need to define a separate smbus_xfer function
extend dev_driver_string to deal with
new-style class devices:
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/base/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux-2.6.21-rc3.orig/drivers/base/core.c 2007-02-28 09:48:19.0
+0100
+++ linux-2.6.21-rc3
);
+}
What's the point of these?
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
by AML
and SMM. Without this information, we can never be sure that OS-level
code won't conflict with ACPI or SMM.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
Hi Alexey,
On Fri, 09 Mar 2007 13:39:33 +0300, Alexey Starikovskiy wrote:
Jean Delvare wrote:
I can only second Pavel's wish here. This would be highly convenient
for OS developers to at least know which resources are accessed by AML
and SMM. Without this information, we can never be sure
that we'll be able to get rid of the I2C device driver
IDs pretty soon thanks to your new i2c-core model, but I'm not sure if
we'll be able to get rid of I2C adapter drivers IDs that quickly. But I
agree with you, please let's not add new unused IDs.
--
Jean Delvare
-
To unsubscribe from this list: send
additionally uses BAR 0.
Without documentation it's hard to be sure this is a 3rd SMBus channel,
but it sure looks so. Maybe you'll want to hack the i2c-nforce2 driver
a bit to confirm or infirm this theory.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
:1;
+ unsigned int scl_is_open_drain:1;
+ unsigned int scl_is_output_only:1;
+};
+
+#endif /* _LINUX_I2C_GPIO_H */
Would you mind also adding yourself to MAINTAINERS for this driver? I
would appreciate it.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line
to 100 in i2c-algo-bit,
but i2c-algo-bit uses the i2c_algo_bit_data timeout field. The
i2c_adapter timeout field is unused.
This is clearly calling for a cleanup but I don't have time for this
right now.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
it, then we have
to add it. Alan?
*If* the VT8251 needs the VIA IRQ quirk, then the attached patch may help.
Leopold, can you give it a try?
--
Jean Delvare
Suse L3
Enable the VIA IRQ quirk on the VT8237S and VT8251 south bridges.
Needs testing.
Signed-off-by: Jean Delvare [EMAIL PROTECTED
Hi Leopold,
Le Lundi 12 Février 2007 17:23, Leopold Palomo-Avellaneda a écrit :
A Dilluns 12 Febrer 2007 10:11, Jean Delvare va escriure:
Did you report the problem to Asus? They should fix it. Maybe this new
BIOS actually fixes some other problems you have.
no. It's on the todo list
, 764 insertions(+), 116 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-pasemi.c
---
David Brownell:
i2c/vt8231: Remove superfluous initialization
i2c: Add driver suspend/resume/shutdown support
Jean Delvare:
i2c-ali1563: Improve the status messages
i2c
Le Mardi 13 Février 2007 17:11, Leopold Palomo-Avellaneda a écrit :
A Dimarts 13 Febrer 2007 12:20, Jean Delvare va escriure:
(...)
*If* the VT8251 needs the VIA IRQ quirk, then the attached patch may
help. Leopold, can you give it a try?
Well, making your patch to the vanilla
). This is how Suse's hwinfo does.
But maybe the first question to ask is: why is the BIOS setting lost in
the first place? Why is the kernel resetting the led state?
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
of alternate config index port
Ralf Baechle:
hwmon/lm70: Make lm70_remove a __devexit function
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/parport/parport_pc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.20-rc1.orig/drivers/parport/parport_pc.c 2006-12-17
16:08:05.0 +0100
+++ linux-2.6.20-rc1/drivers/parport/parport_pc.c 2006-12-17
17:36
WARNING: drivers/video/i810/i810fb.o - Section mismatch: reference
to .init.data: from .text between 'i810_check_params' (at offset
0x1123) and 'encode_fix'
yres cannot be declared __devinitdata as it is used in
i810_check_params(), which isn't __devinit.
Signed-off-by: Jean Delvare [EMAIL
On Thu, 15 Feb 2007 06:34:35 -0800, H. Peter Anvin wrote:
Jean Delvare wrote:
On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
RAM (offset 0x497). This is how Suse's hwinfo does.
Perhaps that's
Hi Linus,
On Wed, 14 Feb 2007 11:32:34 -0800 (PST), Linus Torvalds wrote:
On Wed, 14 Feb 2007, Jean Delvare wrote:
On x86, the BIOS led state can be read from byte 0x97 the BIOS RAM. The
BIOS RAM is mapped at 0x400 so all we need to do is to one byte from
RAM (offset 0x497). This is how
Linus,
Please don't forget to pull the hwmon subsystem updates for Linux
2.6.21 from:
git://jdelvare.pck.nerim.net/jdelvare-2.6 hwmon-for-linus
The merge window is closing soon and I'd like these changes to be in
2.6.21-rc1.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send
to use than ACPI, as it interfaces properly with libsensors
and all hardware monitoring user interfaces.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
here, not k8temp, so let's fix ACPI instead. ACPI
doesn't conflict with only k8temp, but with virtually all hardware
monitoring drivers, all I2C/SMBus drivers, and probably other types of
drivers too. We just can't restrict or blacklist all these drivers
because ACPI misbehaves.
--
Jean Delvare
and
the fucntion will try to access freed memory.
However we now have an explicit call to put_device() at the end of
platform_device_unregister() so I guess the original problem no longer
exists and it is safe to revert that change.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/base
Hi Dmitry,
On Mon, 19 Feb 2007 01:05:30 -0500, Dmitry Torokhov wrote:
On Sunday 18 February 2007 15:30, Jean Delvare wrote:
In platform_device_del(), we currently delete the device resources
first, then we delete the device itself. This causes a (minor) bug to
occur when one unregisters
;
spin_lock(pnp_lock);
Thanks for doing this :)
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
and x86_64) to reliably report the errors? I guess it's a
simple matter of changing the prototypes of the functions? If we can
get this upstream, this would make the integration of the coretemp
driver easier and faster.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe
Hi Richard,
On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote:
On 3/3/07, Jean Delvare wrote:
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
Assuming arbitration of access, what's the problem with having two
drivers accessing the same hardware? Do these chips generally
to change it, but thought I'd pass it
along.
This appears to be a common problem with these devices, the hdaps driver
(IBM) needs to invert the axis on some models too, and I seem to
remember something similar for the (not yet merged) HP laptops
accelerometer driver.
--
Jean Delvare
-
To unsubscribe
PROTECTED]
Reviewed-by: Andrew Morton [EMAIL PROTECTED]
Reviewed-by: Alexey Dobriyan [EMAIL PROTECTED]
Reviewed-by: Jean Delvare [EMAIL PROTECTED]
Cc: David Brownell [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/i2c/busses/Kconfig| 16
drivers/i2c
The i2c linux driver for blackfin architecture which supports blackfin
on-chip TWI controller i2c operation.
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
Reviewed-by: Andrew Morton [EMAIL PROTECTED]
Reviewed-by: Alexey Dobriyan [EMAIL PROTECTED]
Reviewed-by: Jean Delvare [EMAIL PROTECTED]
Cc
term is not free
Damn, I hate it when legal idiocy takes the lead on technical clarity :(
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mike,
On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote:
On 3/21/07, Jean Delvare [EMAIL PROTECTED] wrote:
+ p_adap-class = I2C_CLASS_ALL;
This pretty much voids the point of these probing classes. You should
only select the classes matching devices which may actually
details
This sounds easy when you're in the embedded world. Now come and try to
support the literally thousands of different PC motherboard models out
there that way!
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
changed, 31 insertions(+), 1 deletions(-)
---
Cyrill V. Gorcunov:
i2c/ds1374: Check workqueue creation status
Jean Delvare:
i2c-amd8111: Missed cleanup
i2c-i801: Restore the device state before leaving
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send
myself, no need to resend. This also means
that, from now on, any change to this driver should be provided as an
incremental patch on top of this version.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
: yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips: 1724.04
clflush size: 32
Thomas, Len, any idea? I can help with testing as needed.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe
PROTECTED]
Cc: Alexey Dobriyan [EMAIL PROTECTED]
Cc: Dave Jones [EMAIL PROTECTED]
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
Andrew, can you please pick this patch? I don't want to keep it in my
hwmon tree, as it might useful for others as well.
arch/i386/lib/msr-on-cpu.c | 71
Hi Andrew,
On Sun, 25 Mar 2007 14:22:15 -0800, Andrew Morton wrote:
On Sun, 25 Mar 2007 14:18:23 +0200 Jean Delvare [EMAIL PROTECTED] wrote:
Add support for _safe (exception handled) variants of rdmsr_on_cpu
and wrmsr_on_cpu. This is needed for the upcoming coretemp hardware
monitoring
Hi Mikael,
On Mon, 26 Mar 2007 13:57:29 +0200 (MEST), Mikael Pettersson wrote:
On Mon, 26 Mar 2007 13:29:37 +0200, Jean Delvare wrote:
* * * * * Updated patch * * * * *
From: Rudolf Marek [EMAIL PROTECTED]
Add safe (exception handled) variants of rdmsr_on_cpu and wrmsr_on_cpu.
You
be nice to have.
Note that this patch depends on another header fixup patch I submitted
to LKML yesterday:
[PATCH] scatterlist.h needs types.h
http://lkml.org/lkml/2007/3/01/141
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
arch/alpha/kernel/err_common.c |1 -
arch/alpha
.
There probably isn't much we can do, except increasing the delay or the
retry count, and hope it'll be sufficient. Can you please try the
following patch and see if it helps?
Wait longer between read retries.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/hwmon/w83l785ts.c | 11
of the i2c subsystem. This kind of patch should be built
on top on Andrew Morton's latest tree, not Linus Torvalds'.
What is the merge plan?
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Hi Hans,
On Tue, 10 Apr 2007 17:40:54 +0200, Hans de Goede wrote:
Jean Delvare wrote:
I am resigning from my role as hardware monitoring subsystem
(drivers/hwmon) maintainer. This is too much work for me, I do not have
the necessary bandwidth to review all the incoming patches
, and the sysfs_create_group() and
sysfs_remove_group() calls.
I'm sorry but I really don't have the time for a complete review of
your driver.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
++---
algos/Kconfig |8 +---
busses/Kconfig | 93
+++--
chips/Kconfig | 23 ++
4 files changed, 62 insertions(+), 77 deletions(-)
Applied, thanks.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux
-scsi.diff
menuconfig-w1.diff
As far as I can see, the hwmon subsystem would benefit from that too.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
this.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
in a near future.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ingo Molnar's semaphore to mutex conversions left some noise on a few
trylock calls. Clean it up.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
---
drivers/media/video/zoran_driver.c |2 +-
drivers/mtd/mtd_blkdevs.c |4 ++--
2 files changed, 3
Hi David,
On Mon, 19 Feb 2007 08:40:30 -0800, David Brownell wrote:
On Monday 19 February 2007 6:18 am, Jean Delvare wrote:
Hi David,
On Sun, 18 Feb 2007 21:08:07 -0800, David Brownell wrote:
Currently a parport_driver can't get a handle on the device node for the
underlying parport
-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/base/platform.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- linux-2.6.21-pre.orig/drivers/base/platform.c 2007-02-20
11:05:25.0 +0100
+++ linux-2.6.21-pre/drivers/base/platform.c2007-02-20 22:44:35.0
and load sbs again, and see if it fixes it.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
are likely
to be vendor-specific as well, and not documented.
Either way, this means we need the support from hardware vendors to
solve this concurrent access problem, and unfortunately I doubt this
happens anytime soon :(
--
Jean Delvare
-
To unsubscribe from this list: send the line
Hi Matthew,
On Tue, 20 Feb 2007 15:18:13 +, Matthew Garrett wrote:
On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:
ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
doesn't conflict with only k8temp, but with virtually all hardware
monitoring drivers, all
the cause is. For a long time I was thinking
that we had an explicit modprobe for it in an initscript, but
grepping for it in /etc turns up zip.
How could it be, given that asus_acpi doesn't export any symbol?
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed, 21 Feb 2007 11:03:07 -0500, Chuck Ebbert wrote:
Jean Delvare wrote:
Can you try to load the i2c-dev driver, then run the following commands
and report the results:
$ i2cdetect -l
For each bus listed:
$ i2cdetect N
FWIW it's really an ATIIXP chipset, but supposedly PIIX4
. sbs, in turn, is only useful if i2c_ec is
loaded.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
could also be used to automatically set the module options needed on the 2
oldest uguru featuring abit motherboards. What do you think about this?
Given that the uguru chips are hard (impossible) to detect and only a
small number of boards need it, yes, I think it's a good idea.
--
Jean
was bitten by this one yet... i386 seems to
need the same so I've fixed it as well.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
include/asm-i386/io_apic.h |1 +
include/asm-x86_64/io_apic.h |1 +
2 files changed, 2 insertions(+)
--- linux-2.6.20.orig/include/asm-i386/io_apic.h
Hi Andrew,
On Tue, 27 Feb 2007 12:25:51 -0800, Andrew Morton wrote:
On Sun, 25 Feb 2007 14:15:30 +0100 Jean Delvare [EMAIL PROTECTED] wrote:
Hi Andrew, all,
I appear to need the following fix to be able to build 2.6.20-mm2 on
x86_64. Without the fix, my build attempt dies
please pick this patch?
Signed-off-by: David Brownell [EMAIL PROTECTED]
Acked-by: Jean Delvare [EMAIL PROTECTED]
Index: g26/MAINTAINERS
===
--- g26.orig/MAINTAINERS 2007-02-28 12:46:00.0 -0800
+++ g26
Most architectures' scatterlist.h use the type dma_addr_t, but omit
to include asm/types.h which defines it. This could lead to build
failures, so let's add the missing includes.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
include/asm-alpha/scatterlist.h |1 +
include/asm-avr32
instead. This would be a major functionality loss for a vast majority
of users.
What do you propose?
[1] http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Hi Andrew,
On Thu, 1 Mar 2007 16:11:06 -0800, Andrew Morton wrote:
On Thu, 1 Mar 2007 13:55:16 +0100
Jean Delvare [EMAIL PROTECTED] wrote:
Most architectures' scatterlist.h use the type dma_addr_t, but omit
to include asm/types.h which defines it. This could lead to build
failures, so
the patch if the general opinion is that these
changes aren't safe. The tested part would still be nice to have.
Note that this patch depends on another header fixup patch I submitted
to LKML yesterday:
[PATCH] scatterlist.h needs types.h
http://lkml.org/lkml/2007/3/01/141
Signed-off-by: Jean Delvare
On Thu, 1 Mar 2007 12:48:06 -0500, Dave Jones wrote:
On Thu, Mar 01, 2007 at 03:26:55PM +0100, Jean Delvare wrote:
Firstly, the first records of hidden SMBus, in September 2000, predate
ACPI.
The earliest ACPI spec I have handy is 1.0b, which came out in Feb 2 1999
so this isn't true
to the BIOS author.)
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
that move may be underway as we are
moving out of /proc.
Great, looking forward.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
, are they?
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
on some selected drivers and start
testing real world scenarii.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On Fri, 2 Mar 2007 14:18:40 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 03:10:55PM +0100, Jean Delvare wrote:
I'm not familiar with APCI at all so I didn't know, but what you write
here brings some hope. Would it be possible to parse all the DSDT code
at boot time and deduce all
: ACPI GPE1_BLK
Given that these ports were reserved by ACPI it is perfectly legitimate
that ACPI accesses it, so we must not print a warning in this case. We
need to exclude from the test the regions those name starts with
ACPI, but I'm not sure how we can do that.
Thanks,
--
Jean Delvare
On Fri, 2 Mar 2007 14:57:06 +0100, Pavel Machek wrote:
On Fri 2007-03-02 14:37:20, Jean Delvare wrote:
drivers/pci/quirks.c is full of things we do against the BIOS authors
intent. You don't plan to remove them all, do you?
Notice how quirks.c is careful to name machines where given quirk
Hi Matthew,
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
It might be more elegant but it won't work. We don't want to prevent
ACPI from accessing these I/O ports. If we need to choose only one
driver accessing the I
consequences as was underlined elsewhere in this
thread.
What we want is to grant access to the resources to at least ACPI (and
ACPI only if we can't do better), or if possible to both ACPI and
individual drivers but with some mechanism avoiding concurrent access
(be it a mutex or a port forwarder.)
--
Jean
accesses the hardware monitoring chip, and if two drivers want to
check the AML lock, they'll exclude each other as well.) But I wonder
if this is a problem in practice. Maybe we'll have to make some
profiling on both solutions and compare.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send
which one. There aren't that many patches so it should be
relatively quick.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
Hi All,
On Tue, 6 Mar 2007 09:45:43 +0100, Jean Delvare wrote:
I guess we need to wait and see if someone hits the same problems
with an in-kernel driver.
I just did, with i2c-nforce2. The key to trigger it seems to be to load
an i2c bus driver _after_ loading i2c-isa and a suitable i2c
strlcpy already accounts for the trailing zero in its length
computation, so there is no need to substract one to the buffer size.
Untested, as I do not have the hardware.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
arch/s390/kernel/debug.c |2 +-
arch/xtensa/platform-iss
, while they might have to (e.g. the W83781D has a bank
register too.)
The AML lock approach, OTOH, should work fine in all cases as long as
the context doesn't need to be remembered across AML sections.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
with other drivers.
What benefit do you see compared to a lock taken by both AML and the
hardware monitoring drivers?
Care to submit a sample implementation?
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
: I'm afraid you are trying to
solve the halting problem (- impossible).
Can you please translate this into something mere humans like myself
have a chance to understand?
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
report.
We will release it as lm-sensors 2.10.3 soon.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
...
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Matthew,
On Fri, 2 Mar 2007 21:46:43 +, Matthew Garrett wrote:
On Fri, Mar 02, 2007 at 10:41:55PM +0100, Jean Delvare wrote:
I like the patch, after adding some casts to the printf args it
compiles fine. However you print warnings each time a resource has been
reserved... without
Hi Bodo,
On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:
On Tue, 6 Mar 2007, Jean Delvare wrote:
On Mon, 05 Mar 2007 14:56:44 +0100, Bodo Eggert wrote:
2) make ACPI take this lock whenever it touches ports not allocated by
itself
and release it on function return
-scripts-0.20/patch-scripts-0.20.tar.gz
too
Alternatively, you can use quilt [1] to manage your patches and enable
the --strip-trailing-whitespace option by default.
[1] http://savannah.nongnu.org/projects/quilt/
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux
[EMAIL PROTECTED]
Reviewed-by: Alexey Dobriyan [EMAIL PROTECTED]
Reviewed-by: Jean Delvare [EMAIL PROTECTED]
Actually I had only reviewed the Kconfig part, not the driver itself.
Here's a more complete review:
---
drivers/i2c/busses/Kconfig | 47
drivers/i2c/busses/Makefile
*f71805f_update_device(struct device *dev)
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Dave,
On Mon, 2 Apr 2007 15:22:09 -0400, Dave Jones wrote:
On Mon, Apr 02, 2007 at 05:48:59PM +0200, Jean Delvare wrote:
+ u8 val;
+#ifdef CONFIG_ACPI
+ acpi_ut_acquire_mutex(ACPI_MTX_INTERPRETER);
+#endif
outb(reg, data-addr + ADDR_REG_OFFSET);
- return inb(data-addr
region handler defined by ACPI, doesn't it? If ACPI already
has an infrastructure to handle this problem, we probably want to use
it rather than implementing our own.
[1] http://marc.info/?l=linux-kernelm=117302946017204w=2
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe
skeptical, as I don't
quite get how libtool would be involved in the kernel building process
at all.
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
1 - 100 of 3166 matches
Mail list logo
