collisions, and it makes things cleaner
anyway.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 11 Feb 2008 11:55:46 -0800, Andrew Morton wrote:
On Sun, 10 Feb 2008 13:25:36 +0100 Jean Delvare wrote:
Andrew, both patches are
Acked-by: Jean Delvare [EMAIL PROTECTED]
We already have Signed-off-by:you, which I figure outranks acked-by: ;)
Yeah but that wasn't the same me
the work and submit something better later. That
shouldn't delay the merge of what we have now.
Andrew, both patches are
Acked-by: Jean Delvare [EMAIL PROTECTED]
and I am totally fine with you pushing them to Linus now. But of course
having Mark's ack would be good too.
Thanks,
--
Jean Delvare
can do. In the former
case, let's have the PNP code export the information so that hwmon
drivers can decide whether they should bind to the devices or not by
default.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED
Hi Bjorn,
Le 23/12/2007, Bjorn Helgaas [EMAIL PROTECTED] a écrit:
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
The problem is that the it87 driver is used on a variety of motherboards,
some where the hardware monitoring device I/O ports are reserved by the
BIOS, some where
Hi Bjorn,
Le 23/12/2007, Bjorn Helgaas a écrit:
On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote:
This patch makes the it87 driver request only the two ports used for the
Environment Controller device.
The problem is that the IT87xxF chips do decode 4 ports (recent chips,
0x294
Hi Bjorn,
Le 21/12/2007, Bjorn Helgaas [EMAIL PROTECTED] a écrit:
On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote:
My initial idea was to identify the faulty motherboard using DMI and to
force pnpacpi=off on the faulty motherboards. If this is considered too
aggressive, maybe we
, and more importantly, the patch that revealed
the problem has been backported to 2.6.23.10 so people are experiencing
regressions already.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
*/
#endif /*_LINUX_ACPI_H*/
--
Jean Delvare
Suse L3
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Export acpi_check_resource_conflict(), sometimes drivers already have
a struct resource at hand so no need to use the wrappers to build a new
one.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
This is an update of a patch I sent previously, so that it applies
fine on top of the linux/acpi.h
Two cleanups to linux/acpi.h:
* Stop defining acpi_mp_config, it isn't used anywhere.
* Discard nested #ifdef CONFIG_ACPI, they are useless and
error-prone.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
Len, Andrew, this cleanup should go before the patches sent by
Thomas Renninger. I'll
Export acpi_check_resource_conflict(), sometimes drivers already have
a struct resource at hand so no need to use the wrappers to build a new
one.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
Resending, I had forgotten to quilt refresh. Sorry for the noise.
A missing include was causing
to fix the problems seen with
these specific drivers. This is more realistic.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Andrew,
On Thu, 25 Oct 2007 13:24:10 -0700, Andrew Morton wrote:
On Thu, 25 Oct 2007 15:51:35 +0200, Jean Delvare wrote:
Thanks for picking these patches, having them in -mm for some time is
exactly what we need. Let's see how many systems are affected by the
resource conflicts and how
PROTECTED], Andrew
Morton [EMAIL PROTECTED], Jean Delvare [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: [Fwd: [PATCH 3/5] Export acpi_check_resource_conflict]
Date: Wed, 24 Oct 2007 16:33:07 +0200
Organization: Novell/SUSE
X-Mailer: Evolution 2.8.2
Export
send the I2C patch to Jean and the hwmon patch to Mark and we're all good.
Thanks for picking these patches, having them in -mm for some time is
exactly what we need. Let's see how many systems are affected by the
resource conflicts and how we can fix them
--
Jean Delvare
-
To unsubscribe from
, enforce ACPI resource conflict checks, so that users will report
to us.
This patch is NOT meant to go to Linus at this point.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
drivers/acpi/osl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.24-rc1.orig/drivers/acpi/osl.c
On Mon, 24 Sep 2007 23:39:58 -0300, Henrique de Moraes Holschuh wrote:
On Mon, 24 Sep 2007, Jean Delvare wrote:
The name attribute should really read thinkpad not thinkpad_hwmon,
otherwise sensors will present the chip as thinkpad_hwmon-isa-,
its section in /etc/sensors.conf
;
@@ -249,6 +251,8 @@ static struct {
u32 input_device_registered:1;
u32 platform_drv_registered:1;
u32 platform_drv_attrs_registered:1;
+ u32 sensors_pdrv_registered:1;
+ u32 sensors_pdev_attrs_registered:1;
} tp_features;
struct thinkpad_id_data {
--
Jean
, we won't have many reports.
* Can we have similar messages for PNP_MAX_MEM, PNP_MAX_IRQ and
PNP_MAX_DMA? I think that we really want to know when we hit limits for
these too.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message
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-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
in a near future.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
*f71805f_update_device(struct device *dev)
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
it?
No, a LM85 does that too. I don't recall if the current interface allows
for that mapping easily, but if it doesn't, it needs to be modified.
It does, see item pwm[1-*]_auto_channels_temp in
Documentation/hwmon/sysfs-interface. Whether it qualifies as easily
is another problem ;)
--
Jean Delvare
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-acpi 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
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
, 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-acpi in
the body
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-acpi in
the body of a message to [EMAIL PROTECTED
: 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-acpi in
the body of a message to [EMAIL
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
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
dynamical it is? Any
real world example you could present?
Also, you say that port addresses _can_ be dynamically generated, which
suggests that some are not, so the ACPI subsystem could at least
properly request these ones?
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line
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
Hi Zhang,
On Thu, 2007-03-01 at 08:06 +0100, Jean Delvare wrote:
Indeed, ACPI thermal zone may have more thermal trip points than the
hwmon interface specifies. Two of the trip points can be mapped to
temp1_max and temp1_crit, respectively. If we want to handle them all,
then probably
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-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
, are they?
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
the latency) would be better
with a per-I/O-region approach.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
on some selected drivers and start
testing real world scenarii.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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-acpi in
the body of a message to [EMAIL
of thermal zones, i.e. the trip points would be mapped
to temp1_auto_point[1-*]_temp and possibly associated with a fan speed
output.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
attributes anyway, so they will
get their own naming space.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Henrique,
On Mon, 26 Feb 2007 15:06:35 -0300, Henrique de Moraes Holschuh wrote:
On Mon, 26 Feb 2007, Jean Delvare wrote:
Either way, I do not think that knowing the last measured speed is that
useful. Given that it may be completely unrelated with the current
It is, actually, because
(subdirectory)
named fan, and all thermal attributes in a sysfs group named thermal. Is
that acceptable?
No, it's not, as it wouldn't be compatible with what all the other
drivers do and what libsensors expects.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux
. sbs, in turn, is only useful if i2c_ec is
loaded.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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
and load sbs again, and see if it fixes it.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
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-acpi
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
Vladimir,
On Fri, 16 Feb 2007 08:54:25 +0300, Lebedev, Vladimir P wrote:
Yes, you are right, but we are going to remove i2c objects from sbs
driver in near future.
How that? How do you plan to access SMBus devices without using i2c
functions?
Thanks,
--
Jean Delvare
-
To unsubscribe from
otherwise makes thing better, speak up :)
I'm not sure if it is practical for hwmon, but having
report_voltage(x,y) is probably easier than coding sysfs stuff by
hand.
I can't figure out what it would look like in practice. Do you have
some code to show?
Thanks,
--
Jean Delvare
-
To unsubscribe
to know. But is there a practical use for this? I'd suspect
that the user wants to know the battery charge% all the time anyway,
critical or not.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Fix an obviously broken kfree() in acpi/i2c_ec device initialization
error path.
Signed-off-by: Jean Delvare [EMAIL PROTECTED]
---
This function would benefit from some improvements (single error path,
kzalloc) but let's fix that obvious bug first. This would preferably go
to Linus before 2.6.18
to be simple text
files, aren't they?
read(fd, ...);
... handle readout, update GUI ...
}
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
which devices
have hardware monitoring attributes. There are no class attributes in
use. The reason is historical, and also due to the fact that no two
hardware monitoring chips have the same set of features.
--
Jean Delvare
-
To unsubscribe from this list: send the line unsubscribe linux-acpi
65 matches
Mail list logo
