Hi Peter,
On 10/16/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-10-15 at 20:28 -0700, David Hubbard wrote:
> > I am not subscribed to LKML, so please CC me in replies. I am
> > reporting a regression when CONFIG_DEBUG_LOCKDEP is enabled in
> > 2.
Hi Stefan, (Replying to everyone on the list, sorry!)
On 8/10/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Should I hardwire correct dividers or pulse per rev in sensors.conf or
> is the driver supposed to work the correct dividers out --- like it did
> before 2.6.23-rc?
The dividers are read-
Hi Jean,
I didn't say I would leave entirely. I plan to stay around and keep
helping with the lm-sensors project and hwmon drivers.
Thanks! This is great news.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More ma
Hi Rudolf,
On 4/10/07, Rudolf Marek <[EMAIL PROTECTED]> wrote:
Hello all,
First I would like to thank Jean for his great work even if could be seen as
"slow". He did the perfect job, allowing only just perfect code to enter the
trees.
I completely agree.
> I haven't seen anything from Rudo
Hi Hans,
On 4/10/07, Hans de Goede <[EMAIL PROTECTED]> wrote:
Jean Delvare wrote:
> Hi all,
>
> 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, in
Jean,
I for one will greatly miss your knowledge and helpful hints when I
work on hardware monitoring drivers. I hope you find success in all
the things you do!
I understand the difficult position you're in, and if there's any way
I could convince you to stay, I would. Maybe you would be willing
Hi Jean, Rudolf,
1* It requires that we modify each driver individually. It's quite a
shame that we have to update drivers all around the kernel tree with
specific code to workaround a problem which is originally located in a
single place (the ACPI subsystem.) That being said this isn't a blocke
Hi Jean,
Is there anything preventing us from doing such a walk and pre-allocate
all the I/O ranges? I am not familiar with the ACPI code at all, would
you possibly propose a patch doing that?
Here's a random idea -- what do you think of it?
ACPI already allocates some I/O ranges, which was a
8 matches
Mail list logo