On Sun, 2 Sep 2007 23:02:01 -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 02 Sep 2007, Jean Delvare wrote:
> > I guess power[1-*]_average would be OK?
>
> AFAIK, yes. It is probably not 100% in sync with the power supply class,
> though.
Is the power supply class creat
commit this fix. (That was already posted before).
The fix appears to be in the tree already, so you needn't worry.
--
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 Mon, 3 Sep 2007 20:22:25 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 03 Sep 2007, Jean Delvare wrote:
> > I see that the power supply class units are 10^-6 A and 10^-6 W, so if
> > we are supposed to be compatible, I guess we'll have to use this too.
>
> T
Hi Jan, Joe,
On 8/4/2007, "Jan Engelhardt" <[EMAIL PROTECTED]> wrote:
>On Aug 3 2007 15:16, Joe Perches wrote:
>>On Fri, 2007-08-03 at 17:05 +0200, Jean Delvare wrote:
>>> Fine with me, but this first patch should still be correct per se.
>>
>&g
On Tue, 7 Aug 2007 13:19:49 -0700, Andrew Morton wrote:
> On Fri, 03 Aug 2007 15:16:09 -0700
> Joe Perches <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2007-08-03 at 17:05 +0200, Jean Delvare wrote:
> > > Fine with me, but this first patch should still be correct per s
struct device *dev)
> {
> struct i2c_adapter *adap = to_i2c_adapter(dev);
> complete(&adap->dev_released);
> @@ -303,7 +302,7 @@
> { },
> };
>
> -struct class i2c_adapter_class = {
> +static struct class i2c_adapter_class = {
> .owner
d register.
>*/
> if (chip_id == man_id
>- && (address == 0x4F || address == 0x4D)
>+ && (address == 0x4C || address == 0x4D)
> && (reg_config1 &
is valuable. Having a
more standard formatting for log messages is interesting as well,
although dev_info and friends already offer this to some extent. But
you have to realize that kernel logging must stay something very
simple, and that the first tool to read them is "dmesg" and not
ns. I
> think it might look cleaner, at least. Just my two cents, not a NAK or
> anything.
The benefit of having a single call is that other calls to printk()
won't be interlaced with our message. This has been discussed lately in
a different thread. So you may think that the cod
eeds are actually true?
What fan inputs are used by your CPU and system fans? "sensors
-c /dev/null" will tell.
Other than that, I can only ask for the same things Mark already
suggested: compile with HWMON debugging and provide the logs (this will
show what fan div the driver is trying
ips/menelaus.c
> +++ b/drivers/i2c/chips/menelaus.c
> @@ -1198,7 +1198,7 @@ static int menelaus_probe(struct i2c_client *client)
> err = request_irq(client->irq, menelaus_irq, IRQF_DISABLED,
> DRIVER_NAME, menelaus);
> if (err
Hi Stefan,
On Sat, 11 Aug 2007 00:29:36 +0200, Stefan Richter wrote:
> Jean Delvare wrote:
> > I just tried 2.6.23-rc2 on a system where I use the w83627ehf hardware
> > monitoring driver, and was not able to reproduce the problem you
> > described. Fan speeds are reported p
lied, that is.)
I recommend that you don't load the ACPI "thermal" driver together with
the w83627ehf driver, it won't give you any additional information and
the race condition that exists between both drivers can still result in
wrong values being reported from times to times
On Sat, 11 Aug 2007 17:48:41 +0200, Stefan Richter wrote:
> Jean Delvare wrote:
>> So my theory is that something else (BIOS, ACPI?)
>
> (ksensors?)
ACPI if my guess is correct.
>> is changing the bank,
>> probably to read temperature values which are in banks 1 and
ues during early
> init.
> Otherwise, a call to store_fan_min() could access uninitialized variables.
>
> Signed-off-by: Mark M. Hoffman <[EMAIL PROTECTED]>
Good catch.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
>
> diff --git a/drivers/hwmon/w
hip is a W83781D, it doesn't
have thermal sensor type selection, so I couldn't test that.
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
> diff --git a/drivers/hwmon/w83781d.c b/drivers/hwmon/w83781d.c
> index f85b48f..c95909c 100644
> --- a/drivers/hwmon/w83781d.c
> +++ b/d
s concerned, the relevant header
files are only:
F: include/linux/i2c.h
F: include/linux/i2c-dev.h
F: include/linux/i2c-id.h
All the other i2c*.h files are driver-specific.
>
> I2C-TINY-USB DRIVER
> P: Till Harbaum
--
Jean Delvare
-
To unsubscribe from this list: send the line &
sed?
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4faf1ce..91bc5cd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -307,6 +307,7 @@ P:Jean Delvare
> M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED]
>
AINERS
> @@ -367,6 +367,7 @@ P:Rudolf Marek
> M: [EMAIL PROTECTED]
> L: [EMAIL PROTECTED]
> S: Maintained
+F: Documentation/i2c/busses/i2c-ali1563
> +F: drivers/i2c/busses/i2c-ali1563.c
>
> ALPHA PORT
> P: Richard Henderson
--
Jean Delvare
-
To unsubs
; I discussed that problem with Jean Delvare a while ago and he proposed
> to add a prefix to the class name.
>
> http://mcentral.de/~mrec/patches/firmware_class_name_collision.diff
>
> Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
Acked-by: Jean Delvare <[EMAIL PROTE
;firmware-" takes 9
characters, add one for the trailing zero and this only leaves room for
10 characters for the original bus id. While this will be enough for
the i2c case, I suspect that some other bus IDs won't fit.
--
Jean Delvare
-
To unsubscribe from this list: send the line &quo
03f6-03f6 : :00:0f.0
03f6-03f6 : ide0
03f8-03ff : serial
+04d0-04d1 : pnp 00:03
+0800-0805 : pnp 00:03
0cf8-0cff : PCI conf1
4000-407f : pnp 00:02
4000-4003 : ACPI PM1a_EVT_BLK
Let me know if you want me to test anything in particular.
--
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/
hen you can use sysfs_chmod_file() to
change it to read-write where supported. Take a look at the w83781d
driver for an example.
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/
Hi Andrew,
On Fri, 19 Oct 2007 02:23:34 -0700, Andrew Morton wrote:
> On Fri, 19 Oct 2007 11:07:50 +0200 Jean Delvare <[EMAIL PROTECTED]> wrote:
>
> > BTW, as a rule of thumb, I am ignoring patches that are sent to the
> > LKML in addition to the i2c list. If you thi
can fail.
> goto out_register;
> }
>
> @@ -561,10 +559,10 @@ static void ibmpex_msg_handler(struct ipmi_recv_msg
> *msg, void *user_msg_data)
> struct ibmpex_bmc_data *data = (struct ibmpex_bmc_data *)user_msg_data;
>
> if (msg->msgi
On Fri, 19 Oct 2007 17:23:24 +0800, Bryan Wu wrote:
> On 10/19/07, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > If you want me to consider your patches as something that needs my
> > attention, send them to the i2c list only, do not add LKML. This is
> > general advi
u
provide separate patches I'll try to find some time to review them.
Note that this won't be for 2.6.24 anyway, it's too late for that, I've
already sent my i2c patches to Linus. From now on, only bugfixes can go
in 2.6.24, improvements will have to wait for 2.6.25.
--
Jean D
On Fri, 19 Oct 2007 16:35:07 -0700, Darrick J. Wong wrote:
> Ok, I'll change the message to be a bit more accurate.
> ---
> Clean up printk use in ibmpex.
>
> Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
> ---
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
your time doing the initial review of a random i2c patch that
about anyone remotely involved in kernel development would have been
able to review. There's something wrong here.
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
> + * would be buggy, so force clear the
> + * termination bit to avoid doing a full
> + * sg_init_table() in drivers for each command.
> + */
> +
Hi Andrew,
On Tue, 23 Oct 2007 09:18:45 -0700, Andrew Morton wrote:
> On Tue, 23 Oct 2007 13:50:30 +0200 Jean Delvare <[EMAIL PROTECTED]> wrote:
> > You're unfair. I can use the same argument the other way around: if
> > Bart did not post to the wrong list in the first p
Hi Riku,
On Wed, 24 Oct 2007 14:50:34 +0300, Riku Voipio wrote:
> On Fri, Oct 19, 2007 at 02:37:54PM +0200, Jean Delvare wrote:
> > Take a look at the w83781d
> > driver for an example.
>
> Btw, I think your example code has a indentation bug:
>
>
-kernel , Len Brown <[EMAIL
> > 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 1
;s tree and I staged the I2C patch against Jean's tree.
>
> This means that if/when the ACPI patches have gone me->Len->Linus, I can
> 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 tim
y. This
> will force people to report. Open the floodgates; I hope I don't drown.
Good point. Here's a patch. Andrew, can you please apply this on top of
the other patches? Thanks.
Subject: Enforce ACPI resource conflict checks
In -mm, enforce ACPI resource conflict checks, so that us
native.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> #define MAX_PATCH_LEN (255-1)
>
Fixes the problem for me, thanks Dave!
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
This should be applied to Linus' tree quickly.
--
Jean De
-dev interfaces to i2c-dev.h
i2c-at91: Mark as broken
i2c: Rename the PEC functionality bit
Francis Moreau (1):
i2c-bfin-twi: Remove useless twi_lock mutex
Jason Gaston (1):
i2c-i801: Add support for the Intel Tolapai SMBus
Jean Delvare (5):
i2c: Kill struct
RO
> +
> +power[1-*]_reset_history Reset input_highest, input_lowest,
> + average_highest and average_lowest.
> + WO
>
> **
> * Alarms *
Looks good, thanks for your patience :)
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
Not
> to use the new one. I am CC-inj Jean on this.
The new style is preferred, yes.
--
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/
client->name, client->addr << 1);
> +
> + /* Allocate and register AD7142 input device */
> + data->input_dev = input_allocate_device();
> + if (!data->input_dev) {
> + printk(KERN_ERR "AD7142: Can't allocate input
Hi Robin,
On Wed, 17 Oct 2007 15:14:40 -0400, Robin Getz wrote:
> On Wed 17 Oct 2007 10:07, Jean Delvare pondered:
> > Hi Bryan,
> >
> > On Wed, 17 Oct 2007 15:12:00 +0800, Bryan Wu wrote:
> > > Subject: [PATCH try #4] Input/Joystick Driver: add support AD7142
>
}
As a side note, dev_err() should be used instead of printk here, and
possibly in other places. Darrick, could you please send a patch fixing
this?
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/
sure that 0x7e is unique? Does this
> > driver even support slave operation?
> >
>
> It's in fact 0x7F << 1. The same value is used in the 2.4 driver and
> in u-boot, as well. Slave operation is not supported.
I'm not sure what exactly you are doing here, but
ation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -275,13 +275,6 @@ Who: Tejun Heo <[EMAIL PROTECTED]>
>
> ---
>
> -What:Legacy RTC drivers (under drivers/i2c/ch
_TWI_MASTER_CTL(pmsg->len << 6);
> + else if (pmsg->len > 255) {
> + bfin_write_TWI_MASTER_CTL(0xff << 6);
> + iface->manual_stop = 1;
> + }
Same as above: if you can't achieve the transaction, return an error.
>
(p_adap->name));
> + strlcpy(p_adap->name, pdev->name, sizeof(p_adap->name));
> p_adap->algo = &bfin_twi_algorithm;
> p_adap->algo_data = iface;
> p_adap->class = I2C_CLASS_ALL;
> - p_adap->dev.parent = &dev->dev;
> + p_adap-&g
;
>
> + setup_pin_mux(1, iface);
You must check the error code and handle it.
> +
> rc = request_irq(iface->irq, bfin_twi_interrupt_entry,
> IRQF_DISABLED, pdev->name, iface);
> if (rc) {
> @@ -701,6 +724,7 @@ static int i2c_bfin_twi_remove(struct pla
gt; + .name = DRV_NAME,
> .owner = THIS_MODULE,
> },
> };
> @@ -750,9 +759,5 @@ static void __exit i2c_bfin_twi_exit(void)
> platform_driver_unregister(&i2c_bfin_twi_driver);
> }
>
> -MODULE_AUTHOR("Sonic Zhang <[EMAIL PROT
2C_CLIENT_MAX_OPTS] = I2C_CLIENT_DEFAULTS; \
>static unsigned int var##_num; \
> - module_param_array(var, short, &var##_num, 0); \
> + module_param_array(var, short, &var##_num, 0644); \
>MODULE_PARM_DESC(var,desc)
>
> #define I2C_CLIENT_MODULE_PARM_FORCE(name)
core, using them should
become less necessary over time. Ultimately I'd be happy to get rid of
them completely.
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/
t is never
evaluated.) That's pretty confusing, I'll send a patch fixing this.
In the meantime, here's a quick fix so that you can go on testing
the mm snapshot. Apply this at the top of the series:
Fix the breakage for CONFIG_ACPI=n.
Signed-off-by: Jean Delvare <[EMAIL PRO
channels
hwmon/w83793: Hide invalid VID readings
Jean Delvare:
hwmon: Fix the VRD 11 decoding
Rudolf Marek:
hwmon/w83793: Fix the fan input detection
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
I suggest that Linus deletes his old-2.6-bkcvs tree. What do you
think?
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.htm
platform_device_unregister(pdev);
-
platform_driver_unregister(&f71805f_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://vger.kernel.org/m
way related to compiler/linker.
http://jdelvare.pck.nerim.net/linux/relocatable-bug/
gcc version is 3.2.3
ld version is 2.14.90.0.6
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
ps
> back to BIOS.
I can only confirm that. I installed a more recent system on the same
hardware, rebuilt a kernel from the same config file, and now it boots
OK. So it's not related to the hardware. It has to be a compilation-time
issue.
--
Jean Delvare
-
To unsubscribe from this list: send
Hi Vivek,
On Thu, 21 Dec 2006 08:43:26 +0530, Vivek Goyal wrote:
> On Thu, Dec 21, 2006 at 02:13:54PM +0100, Jean Delvare wrote:
> > On Thu, 21 Dec 2006 06:38:14 +0530, Vivek Goyal wrote:
> > > Looks like it might be a tool chain issue. I took Jean's config file and
> &
> ((DELTA_INITSEG) << 4) is 0x200. How does it look like on your machine?
1110: ff a6 14 02 00 00 jmp*0x214(%esi)
So exactly the same.
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM
head.o
Sure, here they are:
http://jdelvare.pck.nerim.net/linux/relocatable-bug/
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
are a pain for testers, and break git bisect too. Grmbl.
Now that it's done... Steve, can you please take a look and provide a
patch so that cifs builds again?
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
although a deeper analysis will be
required to figure out how and why.
--
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/
't have access to this test system at the moment, I'll check, test
and report back once I have access again.
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/
ice
Good catch, applied, thanks. I've also backported this fix to i2c-SVN
and linux-2.4, as they also had the mistake.
> btw, the i2c/smbus docs in Documentation/i2c/ are superb, thanks all :)
You're welcome :)
--
Jean Delvare
-
To unsubscribe from this list: send the line "uns
e whole build tree so that you can peek at files without
waiting for me to upload them. It is temporarily available at:
http://jdelvare.pck.nerim.net/linux/relocatable-bug/
Hidden files are there too, just not listed.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "u
regression on my other systems. Thanks Vivek and Segher!
I guess we now want to push this patch upstream rather sooner than
later, and at any rate before 2.6.20 final is released. Eric, can you
please review the patch, and if it looks OK to you, sign it and send it
to Linus?
Thanks,
--
Jean Delv
teve:
> You had binutils 2.14.90.0.6 .
> Does this patch fix it for you?
I'd really expect it to, Steve please try the patch and confirm.
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
M
ou unload the sbs
driver and see if things get better. If they do, you could try to apply
my patch 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 major
onflicting
accesses between ACPI and the rest of the system, these ways 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 :(
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
acpi as a dependancy. I've never
> figured out what 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 Delvar
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
>
>
should be doable for i2c_ec, as it's only useful if a
given ACPI object is present. 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 majo
uguru driver, dmi info
> 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&#
obody else 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/inclu
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. Wi
e. Andrew, can you please pick this patch?
>
> Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
>
> Index: g26/MAINTAINERS
> ===
> --- g26.orig/MAINTAIN
Most architectures' scatterlist.h use the type dma_addr_t, but omit
to include 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 +
i
r motherboards, ACPI
does _not_ provide any hardware monitoring feature. So we really can't
go tell our users: give up the individual hardware monitoring drivers
and lm_sensors on all ACPI-enabled systems and use whatever ACPI offers
instead. This would be a major functionality loss for a vast majori
sense.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/base/core.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.20.orig/drivers/base/core.c 2007-02-06 09:25:49.0
+0100
+++ linux-2.6.20/drivers/base/core.c2007-02-06 20:
hread, the source code (quickly) and the patches to
ahci.c and sata_via.c, and here are some comments:
It looks like support for the VT8251 was added to the ahci driver in kernel
2.6.18, and was then updated in 2.6.20. The code is different from the
patch Leopold is using with 2.6.16. As I
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.
>
>
, 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?
> >
s mapped at 0x400 so all we need to do is to one byte from
RAM (offset 0x497). 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: s
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
h isn't.
Signed-off-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/pa
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
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
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 (o
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
e
interested in monitoring your CPU temperature, k8temp is IMHO more
convenient 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" i
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 I2C/SMBus drivers, and probably other types of
drivers too. We just can't restrict or blacklist all these drivers
because ACPI
eferences to the device it will be freed 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
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
>
p%d: using %s (%s).\n", nr, port->name,
> Index: g26/drivers/char/tipar.c
> ===
> --- g26.orig/drivers/char/tipar.c 2006-12-09 17:02:09.0 -0800
> +++ g26/drivers/char/tipar.c 2007-02-18 13:43:15.0
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
will be freed 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 <
using the eeprom i2c driver matches that returned by the Windows "IR"
> JP1 tool.
>
> Signed-Off-By: Jonathan McDowell <[EMAIL PROTECTED]>
Patch applied, thanks.
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
at the
time the quirks are run. So I used a two-step quirk as is done for
some other quirks already. First we detect the VIA south bridges
and set the right low and high device limits, then we are ready to
actually run the quirks on the affected devices.
Signed-off-by: Jean Delvare <[EMAIL PROTE
Hi Nick,
Thanks for testing and reporting.
Le Mardi 30 Janvier 2007 03:35, Nick Piggin a écrit :
> Jean Delvare wrote:
> > Here is the patch I have come up with. It might not qualify as elegant,
> > but at least it appears to solve the issue. Nick, can you please give it
> >
601 - 700 of 1633 matches
Mail list logo
