Re: [PATCH] led-class.c permission change
On 05 May 2007 at 22h05, Alan Cox wrote: Hi, > > This patch changes the led brightness file's permissions to 0666, > > so that a user's MUA can light up the mail LED without needing root > > permissions. > > NAK. > > The management of user specific temporary permissions belongs in user > space with a safe "no" default value to stop background daemons doing > silly things. Mmh, ok... My usage pattern for this is for an MUA plugin[1] that does write 1 to /sys/class/leds/asus:mail/brightness, for example, when new mail comes. The MUA typically runs as user and until now most of the handled LEDs had no such permission problems (/proc/acpi/asus/mled, /proc/acpi/acer/mailled etc). So, I've got to find a way to write into that file as user so that things automatically work. > Take a look at the various pam console management modules (and also > beat people up to get revoke() support into the kernel). So, you suggest me to link my plugin to libpam and find something that allows the plugin to write into /brightness? Thanks, [1] http://www.claws-mail.org/plugin.php?plugin=acpinotifier -- Colin signature.asc Description: PGP signature
[PATCH] led-class.c permission change
Hi, This patch changes the led brightness file's permissions to 0666, so that a user's MUA can light up the mail LED without needing root permissions. Thanks! Signed-Off-By: Colin Leroy <[EMAIL PROTECTED]> --- a/drivers/leds/led-class.c 2007-05-05 12:45:20.0 +0200 +++ b/drivers/leds/led-class.c 2007-05-05 12:41:28.0 +0200 @@ -56,7 +56,7 @@ static ssize_t led_brightness_store(stru return ret; } -static CLASS_DEVICE_ATTR(brightness, 0644, led_brightness_show, +static CLASS_DEVICE_ATTR(brightness, 0666, led_brightness_show, led_brightness_store); #ifdef CONFIG_LEDS_TRIGGERS static CLASS_DEVICE_ATTR(trigger, 0644, led_trigger_show, led_trigger_store); - 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/
[PATCH] led-class.c permission change
Hi, This patch changes the led brightness file's permissions to 0666, so that a user's MUA can light up the mail LED without needing root permissions. Thanks! Signed-Off-By: Colin Leroy [EMAIL PROTECTED] --- a/drivers/leds/led-class.c 2007-05-05 12:45:20.0 +0200 +++ b/drivers/leds/led-class.c 2007-05-05 12:41:28.0 +0200 @@ -56,7 +56,7 @@ static ssize_t led_brightness_store(stru return ret; } -static CLASS_DEVICE_ATTR(brightness, 0644, led_brightness_show, +static CLASS_DEVICE_ATTR(brightness, 0666, led_brightness_show, led_brightness_store); #ifdef CONFIG_LEDS_TRIGGERS static CLASS_DEVICE_ATTR(trigger, 0644, led_trigger_show, led_trigger_store); - 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/
Re: [PATCH] led-class.c permission change
On 05 May 2007 at 22h05, Alan Cox wrote: Hi, This patch changes the led brightness file's permissions to 0666, so that a user's MUA can light up the mail LED without needing root permissions. NAK. The management of user specific temporary permissions belongs in user space with a safe no default value to stop background daemons doing silly things. Mmh, ok... My usage pattern for this is for an MUA plugin[1] that does write 1 to /sys/class/leds/asus:mail/brightness, for example, when new mail comes. The MUA typically runs as user and until now most of the handled LEDs had no such permission problems (/proc/acpi/asus/mled, /proc/acpi/acer/mailled etc). So, I've got to find a way to write into that file as user so that things automatically work. Take a look at the various pam console management modules (and also beat people up to get revoke() support into the kernel). So, you suggest me to link my plugin to libpam and find something that allows the plugin to write into /brightness? Thanks, [1] http://www.claws-mail.org/plugin.php?plugin=acpinotifier -- Colin signature.asc Description: PGP signature
[PATCH] fix oom_kill_task
Hi,
oom_kill_task's comment states that we should be careful about not sending
SIGKILL to processes with SYS_CAP_RAWIO, then the code happily sends it
anyway.
Here's a patch that fixes that.
Signed-Off-By: Colin Leroy <[EMAIL PROTECTED]>
--- a/mm/oom_kill.c 2005-09-09 17:29:08.0 +0200
+++ b/mm/oom_kill.c 2005-09-09 17:29:10.0 +0200
@@ -199,7 +199,12 @@ static void __oom_kill_task(task_t *p)
p->time_slice = HZ;
set_tsk_thread_flag(p, TIF_MEMDIE);
- force_sig(SIGKILL, p);
+ /* This process has hardware access, be more careful. */
+ if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
+ force_sig(SIGTERM, p);
+ } else {
+ force_sig(SIGKILL, p);
+ }
}
static struct mm_struct *oom_kill_task(task_t *p)
-
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/
Re: [PATCH] fix oom_kill_task
Hi,
Alternatively, if sending SIGKILL is intended, here's the patch that fixes the
comment.
Thanks,
Signed-Off-By: Colin Leroy <[EMAIL PROTECTED]>
--- a/mm/oom_kill.c 2005-09-09 17:29:08.0 +0200
+++ b/mm/oom_kill.c 2005-09-09 17:32:47.0 +0200
@@ -168,11 +168,6 @@ static struct task_struct * select_bad_p
return chosen;
}
-/**
- * We must be careful though to never send SIGKILL a process with
- * CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
- * we select a process with CAP_SYS_RAW_IO set).
- */
static void __oom_kill_task(task_t *p)
{
if (p->pid == 1) {
-
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/
Re: [PATCH] fix oom_kill_task
Hi,
Alternatively, if sending SIGKILL is intended, here's the patch that fixes the
comment.
Thanks,
Signed-Off-By: Colin Leroy [EMAIL PROTECTED]
--- a/mm/oom_kill.c 2005-09-09 17:29:08.0 +0200
+++ b/mm/oom_kill.c 2005-09-09 17:32:47.0 +0200
@@ -168,11 +168,6 @@ static struct task_struct * select_bad_p
return chosen;
}
-/**
- * We must be careful though to never send SIGKILL a process with
- * CAP_SYS_RAW_IO set, send SIGTERM instead (but it's unlikely that
- * we select a process with CAP_SYS_RAW_IO set).
- */
static void __oom_kill_task(task_t *p)
{
if (p-pid == 1) {
-
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/
[PATCH] fix oom_kill_task
Hi,
oom_kill_task's comment states that we should be careful about not sending
SIGKILL to processes with SYS_CAP_RAWIO, then the code happily sends it
anyway.
Here's a patch that fixes that.
Signed-Off-By: Colin Leroy [EMAIL PROTECTED]
--- a/mm/oom_kill.c 2005-09-09 17:29:08.0 +0200
+++ b/mm/oom_kill.c 2005-09-09 17:29:10.0 +0200
@@ -199,7 +199,12 @@ static void __oom_kill_task(task_t *p)
p-time_slice = HZ;
set_tsk_thread_flag(p, TIF_MEMDIE);
- force_sig(SIGKILL, p);
+ /* This process has hardware access, be more careful. */
+ if (cap_t(p-cap_effective) CAP_TO_MASK(CAP_SYS_RAWIO)) {
+ force_sig(SIGTERM, p);
+ } else {
+ force_sig(SIGKILL, p);
+ }
}
static struct mm_struct *oom_kill_task(task_t *p)
-
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/
2.6.12-rc3 cpufreq compile error on ppc32
Hi guys,
One of Ben's patches ("ppc32: Fix cpufreq problems") went in 2.6.12-
rc3, but it depended on another patch that's still in -mm only:
add-suspend-method-to-cpufreq-core.patch
In addition to this, there's a third patch in -mm that fixes warnings
and line length to the previous patch, but it doesn't apply cleanly
anymore. It's named add-suspend-method-to-cpufreq-core-warning-fix.patch
Here's an updated version. HTH,
Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
--- a/drivers/cpufreq/cpufreq.c 2005-04-21 09:14:28.0 +0200
+++ b/drivers/cpufreq/cpufreq.c 2005-04-21 09:18:11.0 +0200
@@ -955,7 +955,6 @@
{
int cpu = sysdev->id;
unsigned int ret = 0;
- unsigned int cur_freq = 0;
struct cpufreq_policy *cpu_policy;
dprintk("resuming cpu %u\n", cpu);
@@ -995,21 +994,24 @@
cur_freq = cpufreq_driver->get(cpu_policy->cpu);
if (!cur_freq || !cpu_policy->cur) {
- printk(KERN_ERR "cpufreq: resume failed to assert
current frequency is what timing core thinks it is.\n");
+ printk(KERN_ERR "cpufreq: resume failed to assert "
+ "current frequency is what timing core "
+ "thinks it is.\n");
goto out;
}
if (unlikely(cur_freq != cpu_policy->cur)) {
struct cpufreq_freqs freqs;
- printk(KERN_WARNING "Warning: CPU frequency is %u, "
- "cpufreq assumed %u kHz.\n", cur_freq,
cpu_policy->cur);
+ printk(KERN_WARNING "Warning: CPU frequency is %u,
cpufreq assumed "
+ "%u kHz.\n", cur_freq,
cpu_policy->cur);
freqs.cpu = cpu;
freqs.old = cpu_policy->cur;
freqs.new = cur_freq;
- notifier_call_chain(_transition_notifier_list,
CPUFREQ_RESUMECHANGE, );
+ notifier_call_chain(_transition_notifier_list,
+ CPUFREQ_RESUMECHANGE, );
adjust_jiffies(CPUFREQ_RESUMECHANGE, );
cpu_policy->cur = cur_freq;
-
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/
hpfsck question
Hi Klaus, Yesterday I tried to mount my iPod as usual, but the hfsplus kernel module complained the following: HFS+-fs warning: Filesystem was not cleanly unmounted, running fsck.hfsplus is recommended. mounting read-only. So I installed your hfsplusutils package and ran hpfsck. After that I tried to remount /dev/sda3, and sure enough, the kernel spit out the same message. After a bit of time debugging what was wrong during the hpfsck run, I found out that the filesystem is opened read-only: result = fscheck_volume_open(, device, HFSP_MODE_RDONLY); Hence, the volume_close() call couldn't write anything like HFSPLUS_VOL_UNMNT in the FS' attributes... Once I changed that to open the device read-write, the next mount attempt worked. Is there any reason why hpfsck would attempt to fix a filesystem read-only ? -- Colin - 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/
hpfsck question
Hi Klaus, Yesterday I tried to mount my iPod as usual, but the hfsplus kernel module complained the following: HFS+-fs warning: Filesystem was not cleanly unmounted, running fsck.hfsplus is recommended. mounting read-only. So I installed your hfsplusutils package and ran hpfsck. After that I tried to remount /dev/sda3, and sure enough, the kernel spit out the same message. After a bit of time debugging what was wrong during the hpfsck run, I found out that the filesystem is opened read-only: result = fscheck_volume_open(vol, device, HFSP_MODE_RDONLY); Hence, the volume_close() call couldn't write anything like HFSPLUS_VOL_UNMNT in the FS' attributes... Once I changed that to open the device read-write, the next mount attempt worked. Is there any reason why hpfsck would attempt to fix a filesystem read-only ? -- Colin - 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/
2.6.12-rc3 cpufreq compile error on ppc32
Hi guys,
One of Ben's patches (ppc32: Fix cpufreq problems) went in 2.6.12-
rc3, but it depended on another patch that's still in -mm only:
add-suspend-method-to-cpufreq-core.patch
In addition to this, there's a third patch in -mm that fixes warnings
and line length to the previous patch, but it doesn't apply cleanly
anymore. It's named add-suspend-method-to-cpufreq-core-warning-fix.patch
Here's an updated version. HTH,
Signed-off-by: Colin Leroy [EMAIL PROTECTED]
--- a/drivers/cpufreq/cpufreq.c 2005-04-21 09:14:28.0 +0200
+++ b/drivers/cpufreq/cpufreq.c 2005-04-21 09:18:11.0 +0200
@@ -955,7 +955,6 @@
{
int cpu = sysdev-id;
unsigned int ret = 0;
- unsigned int cur_freq = 0;
struct cpufreq_policy *cpu_policy;
dprintk(resuming cpu %u\n, cpu);
@@ -995,21 +994,24 @@
cur_freq = cpufreq_driver-get(cpu_policy-cpu);
if (!cur_freq || !cpu_policy-cur) {
- printk(KERN_ERR cpufreq: resume failed to assert
current frequency is what timing core thinks it is.\n);
+ printk(KERN_ERR cpufreq: resume failed to assert
+ current frequency is what timing core
+ thinks it is.\n);
goto out;
}
if (unlikely(cur_freq != cpu_policy-cur)) {
struct cpufreq_freqs freqs;
- printk(KERN_WARNING Warning: CPU frequency is %u,
- cpufreq assumed %u kHz.\n, cur_freq,
cpu_policy-cur);
+ printk(KERN_WARNING Warning: CPU frequency is %u,
cpufreq assumed
+ %u kHz.\n, cur_freq,
cpu_policy-cur);
freqs.cpu = cpu;
freqs.old = cpu_policy-cur;
freqs.new = cur_freq;
- notifier_call_chain(cpufreq_transition_notifier_list,
CPUFREQ_RESUMECHANGE, freqs);
+ notifier_call_chain(cpufreq_transition_notifier_list,
+ CPUFREQ_RESUMECHANGE, freqs);
adjust_jiffies(CPUFREQ_RESUMECHANGE, freqs);
cpu_policy-cur = cur_freq;
-
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/
Re: [PATCH] hfsplus: add an option to force r/w mount
On 20 Apr 2005 at 22h04, Roman Zippel wrote: Hi, > > for some reason yet unknown, fsck.hfsplus doesn't correctly set the > > HFSPLUS_VOL_UNMNT flag here. > > If fsck doesn't mark it clean, there must be a reason By the way, the reason is that this stupid utility opens the device read-only (hence it can't fix nothing). from hfsplusutils/libhfsp/src/fscheck.c: result = fscheck_volume_open(, device, HFSP_MODE_RDONLY); Seeing that it has been untouched since 2002, I guess it'll be hard to get it fixed. Or maybe it's just me being idiot and I should use another fsck ? -- Colin - 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/
Re: [PATCH] hfsplus: add an option to force r/w mount
On 20 Apr 2005 at 22h04, Roman Zippel wrote: Hi, > Hi, > > On Wed, 20 Apr 2005, Colin Leroy wrote: > > > for some reason yet unknown, fsck.hfsplus doesn't correctly set the > > HFSPLUS_VOL_UNMNT flag here. > > If fsck doesn't mark it clean, there must be a reason and that also > means you shouldn't mount it writable. that's what i thought too, but adding debug printf() to it, i see that it marks it clean at the end. However that doesn't seem to effectively land on the disc. imho the patch has an interest anyway... -- Colin - 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/
Re: [PATCH] hfsplus: add an option to force r/w mount
On 20 Apr 2005 at 22h04, Roman Zippel wrote: Hi, Hi, On Wed, 20 Apr 2005, Colin Leroy wrote: for some reason yet unknown, fsck.hfsplus doesn't correctly set the HFSPLUS_VOL_UNMNT flag here. If fsck doesn't mark it clean, there must be a reason and that also means you shouldn't mount it writable. that's what i thought too, but adding debug printf() to it, i see that it marks it clean at the end. However that doesn't seem to effectively land on the disc. imho the patch has an interest anyway... -- Colin - 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/
Re: [PATCH] hfsplus: add an option to force r/w mount
On 20 Apr 2005 at 22h04, Roman Zippel wrote: Hi, for some reason yet unknown, fsck.hfsplus doesn't correctly set the HFSPLUS_VOL_UNMNT flag here. If fsck doesn't mark it clean, there must be a reason By the way, the reason is that this stupid utility opens the device read-only (hence it can't fix nothing). from hfsplusutils/libhfsp/src/fscheck.c: result = fscheck_volume_open(vol, device, HFSP_MODE_RDONLY); Seeing that it has been untouched since 2002, I guess it'll be hard to get it fixed. Or maybe it's just me being idiot and I should use another fsck ? -- Colin - 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/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Thu, 07 Apr 2005 09:02:57 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > Interesting. Looks like pci_enable_wake(dev, state, 0) isn't > > actually disabling wakeup on your hardware. (Assuming > > CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went > > back to sleep!) Do you think that might be related to those calls > > manipulating the Apple ASICs being in the OHCI layer rather than up > > nearer the generic PCI glue? (I still think they don't belong in > > USB code -- ohci or usbcore -- at all. If the platform-specific > > PCI hooks don't suffice, they need fixing.) > > There are no platform hooks in the right place for now afaik. Nope, not in upstream, but I used the ohci patch from Paul Mackerras previously. > Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not > an Apple ASIC, it's not doing anything in those calls. -- Colin - 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/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wed, 6 Apr 2005 13:11:53 -0700 David Brownell <[EMAIL PROTECTED]> wrote: > Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually > disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if > not, then it's odd that the system went back to sleep!) Yes, CONFIG_USB_SUSPEND is disabled here. > Do you think > that might be related to those calls manipulating the Apple ASICs > being in the OHCI layer rather than up nearer the generic PCI glue? To be honest, I don't really know :) > Thanks for the testing update. I'm glad to know that there seems to > be only one (minor) glitch that's PPC-specific! Yup, me too, I consider it working quite well now :) > OK, I just posted the patch cleaning up EHCI port power switching; > that should remove the need for that separate patch. (As well as > fixing some minor annoyances.) Seen that, thanks. -- Colin - 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/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Wed, 6 Apr 2005 13:11:53 -0700 David Brownell [EMAIL PROTECTED] wrote: Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Yes, CONFIG_USB_SUSPEND is disabled here. Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? To be honest, I don't really know :) Thanks for the testing update. I'm glad to know that there seems to be only one (minor) glitch that's PPC-specific! Yup, me too, I consider it working quite well now :) OK, I just posted the patch cleaning up EHCI port power switching; that should remove the need for that separate patch. (As well as fixing some minor annoyances.) Seen that, thanks. -- Colin - 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/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On Thu, 07 Apr 2005 09:02:57 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Interesting. Looks like pci_enable_wake(dev, state, 0) isn't actually disabling wakeup on your hardware. (Assuming CONFIG_USB_SUSPEND=n; if not, then it's odd that the system went back to sleep!) Do you think that might be related to those calls manipulating the Apple ASICs being in the OHCI layer rather than up nearer the generic PCI glue? (I still think they don't belong in USB code -- ohci or usbcore -- at all. If the platform-specific PCI hooks don't suffice, they need fixing.) There are no platform hooks in the right place for now afaik. Nope, not in upstream, but I used the ohci patch from Paul Mackerras previously. Anyway, I think Colin's controller is an OHCI/EHCI NEC chip, so not an Apple ASIC, it's not doing anything in those calls. -- Colin - 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/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On 05 Apr 2005 at 13h04, David Brownell wrote: Hi, > > There are known issues with USB after suspend/resume (D3 hot) on > > powerpc. > > Also known fixes to some of them, which haven't yet been merged. > I'll repost these as followups to this message, to linux-usb-devel > and CC Colin. They're in the 2.6.12-rc2-mm1 patchset. > > To my understanding, such issues have been around for some time > now, although recent kernels have tossed monkey wrenches into > several other cases that previously worked just fine. (Ergo those > nyet-merged patches...) > > > > For example, plugging or unplugging devices during sleep > > results in oopses at resume; and one time out of two, the USB ports > > are unpowered on resume (because the registers think they are, and > > linux doesn't repower them. but they're not). > > > > Both of these issues have patches available, patches that can be > > found there for example: > > > > http://colino.net/ibookg4/usb-ohci-fixes.patch > > http://colino.net/ibookg4/usb-ehci-power.patch > > > > What kind of work on these is needed so that they get in? > > Briefly, given 2.6.12-rc2 plus the patches mentioned above, > find out what else is needed. > > * The first of them is Paul's patch, and I never got a >response to the questions I asked him about it. > > - 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING, >which should supplant the need for a new "suspending" quirk. > > - And the first of those patches waiting merge does update the >handling of IRQs in the PCI-to-USB glue. > > - So the main change from that patch which is unresolved is >moving the PMAC-specific stuff up from the OHCI code into >into the the usb/core/hcd-pci code. Presumably you could >do that? I assume that it really is needed at that layer, >though it'll only relate to OHCI cells on Apple ASICs. > > * As for the second, that looks to be a hardware-specfic issue >that just wouldn't reproduce with the controllers I was using >for PM testing. What I'll do is wrap up an equivalent fix with >some related EHCI updates for power switching, post that, and >ask you to verify that it works (probably simplest to do that >with OHCI non-modular and not loaded). > > How's that sound? Nice :) Ok, here are the results of my tests with 2.6.12-rc2 and the patches you sent me applied: - plug USB device, sleep, unplug USB device, resume: no more oops - sleep, plug in USB device: no oops, but it wakes the laptop up for a few seconds; then, it goes back to sleep. No oops on second resume. I can live with that :) - once out of two resumes, resume leaves the ports unpowered; so I still need my usb-ehci-power.patch that re-powers ports unconditionnaly. -- Colin - 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/
Re: [linux-usb-devel] USB glitches after suspend on ppc
On 05 Apr 2005 at 13h04, David Brownell wrote: Hi, There are known issues with USB after suspend/resume (D3 hot) on powerpc. Also known fixes to some of them, which haven't yet been merged. I'll repost these as followups to this message, to linux-usb-devel and CC Colin. They're in the 2.6.12-rc2-mm1 patchset. To my understanding, such issues have been around for some time now, although recent kernels have tossed monkey wrenches into several other cases that previously worked just fine. (Ergo those nyet-merged patches...) For example, plugging or unplugging devices during sleep results in oopses at resume; and one time out of two, the USB ports are unpowered on resume (because the registers think they are, and linux doesn't repower them. but they're not). Both of these issues have patches available, patches that can be found there for example: http://colino.net/ibookg4/usb-ohci-fixes.patch http://colino.net/ibookg4/usb-ehci-power.patch What kind of work on these is needed so that they get in? Briefly, given 2.6.12-rc2 plus the patches mentioned above, find out what else is needed. * The first of them is Paul's patch, and I never got a response to the questions I asked him about it. - 2.6.12-rc2 does have the fix to check for HC_STATE_QUIESCING, which should supplant the need for a new suspending quirk. - And the first of those patches waiting merge does update the handling of IRQs in the PCI-to-USB glue. - So the main change from that patch which is unresolved is moving the PMAC-specific stuff up from the OHCI code into into the the usb/core/hcd-pci code. Presumably you could do that? I assume that it really is needed at that layer, though it'll only relate to OHCI cells on Apple ASICs. * As for the second, that looks to be a hardware-specfic issue that just wouldn't reproduce with the controllers I was using for PM testing. What I'll do is wrap up an equivalent fix with some related EHCI updates for power switching, post that, and ask you to verify that it works (probably simplest to do that with OHCI non-modular and not loaded). How's that sound? Nice :) Ok, here are the results of my tests with 2.6.12-rc2 and the patches you sent me applied: - plug USB device, sleep, unplug USB device, resume: no more oops - sleep, plug in USB device: no oops, but it wakes the laptop up for a few seconds; then, it goes back to sleep. No oops on second resume. I can live with that :) - once out of two resumes, resume leaves the ports unpowered; so I still need my usb-ehci-power.patch that re-powers ports unconditionnaly. -- Colin - 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/
USB glitches after suspend on ppc
Hi, There are known issues with USB after suspend/resume (D3 hot) on powerpc. For example, plugging or unplugging devices during sleep results in oopses at resume; and one time out of two, the USB ports are unpowered on resume (because the registers think they are, and linux doesn't repower them. but they're not). Both of these issues have patches available, patches that can be found there for example: http://colino.net/ibookg4/usb-ohci-fixes.patch http://colino.net/ibookg4/usb-ehci-power.patch What kind of work on these is needed so that they get in? Thanks, -- Colin - 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/
USB glitches after suspend on ppc
Hi, There are known issues with USB after suspend/resume (D3 hot) on powerpc. For example, plugging or unplugging devices during sleep results in oopses at resume; and one time out of two, the USB ports are unpowered on resume (because the registers think they are, and linux doesn't repower them. but they're not). Both of these issues have patches available, patches that can be found there for example: http://colino.net/ibookg4/usb-ohci-fixes.patch http://colino.net/ibookg4/usb-ehci-power.patch What kind of work on these is needed so that they get in? Thanks, -- Colin - 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/
[PATCH] fix shared key auth in zd1201
Hi, this is a resend of a patch that Andrew put in -mm, but that I think is ok and should go into mainline. I did not get any feedback (positive or negative) about it. Please either apply it or explain why not... It's currently impossible to associate with a shared-key-only access point using the zd1201 driver. The attached patch fixes it. The reason was (probably) a typo in the definitions of the authentification types. I found that they should be (1,2) instead of (0,1) by looking at the old linux-wlan-ng driver by Zydas. Signed-off-by: Colin Leroy <[EMAIL PROTECTED]> --- a/drivers/usb/net/zd1201.h 2005-03-25 09:14:49.0 +0100 +++ b/drivers/usb/net/zd1201.h 2005-03-25 09:11:59.0 +0100 @@ -141,7 +141,7 @@ #define ZD1201_RATEB5 4 /* 5.5 really, but 5 is shorter :) */ #define ZD1201_RATEB11 8 -#define ZD1201_CNFAUTHENTICATION_OPENSYSTEM0 -#define ZD1201_CNFAUTHENTICATION_SHAREDKEY 1 +#define ZD1201_CNFAUTHENTICATION_OPENSYSTEM0x0001 +#define ZD1201_CNFAUTHENTICATION_SHAREDKEY 0x0002 #endif /* _INCLUDE_ZD1201_H_ */ - 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/
[PATCH] fix shared key auth in zd1201
Hi, this is a resend of a patch that Andrew put in -mm, but that I think is ok and should go into mainline. I did not get any feedback (positive or negative) about it. Please either apply it or explain why not... It's currently impossible to associate with a shared-key-only access point using the zd1201 driver. The attached patch fixes it. The reason was (probably) a typo in the definitions of the authentification types. I found that they should be (1,2) instead of (0,1) by looking at the old linux-wlan-ng driver by Zydas. Signed-off-by: Colin Leroy [EMAIL PROTECTED] --- a/drivers/usb/net/zd1201.h 2005-03-25 09:14:49.0 +0100 +++ b/drivers/usb/net/zd1201.h 2005-03-25 09:11:59.0 +0100 @@ -141,7 +141,7 @@ #define ZD1201_RATEB5 4 /* 5.5 really, but 5 is shorter :) */ #define ZD1201_RATEB11 8 -#define ZD1201_CNFAUTHENTICATION_OPENSYSTEM0 -#define ZD1201_CNFAUTHENTICATION_SHAREDKEY 1 +#define ZD1201_CNFAUTHENTICATION_OPENSYSTEM0x0001 +#define ZD1201_CNFAUTHENTICATION_SHAREDKEY 0x0002 #endif /* _INCLUDE_ZD1201_H_ */ - 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/
RFC: workaround quality bug in zd1201 hardware
Hi,
I saw in zd1201.c that there's a hardware bug related to quality
statistics:
/* Unfortunatly the quality and noise reported is useless.
they seem to be accumulators that increase until you
read them, unless we poll on a fixed interval we can't
use them
*/
Given that I couldn't find any spec for the zd1201, I tried the
following patch to see if we could cheat by updating commsquality while
scanning. The idea is to use the values we find during scan and copy
them to zd->iwstats; this can be useful because there are a lots of
tools out there that perform scanning periodically (netapplet,
NetworkManager, ...).
Unfortunately this doesn't work perfectly, because it looks like the
scale is different when reporting AP quality on scanning and
"normal" quality.
Maybe this can be made useful with a simple conversion ?
If anyone that has more knowledge on 802.11b than I have could give me
an hint, it'd be appreciated.
Thanks!
Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
--- a/drivers/usb/net/zd1201.c 2005-03-23 15:17:12.0 +0100
+++ b/drivers/usb/net/zd1201.c 2005-03-23 15:17:50.0 +0100
@@ -1160,6 +1160,7 @@
return -EIO;
for(i=8; irxlen; i+=62) {
+ const char *ap_essid;
iwe.cmd = SIOCGIWAP;
iwe.u.ap_addr.sa_family = ARPHRD_ETHER;
memcpy(iwe.u.ap_addr.sa_data, zd->rxdata+i+6, 6);
@@ -1169,6 +1170,7 @@
iwe.u.data.length = zd->rxdata[i+16];
iwe.u.data.flags = 1;
cev = iwe_stream_add_point(cev, end_buf, , zd->rxdata+i+18);
+ ap_essid = zd->rxdata+i+18;
iwe.cmd = SIOCGIWMODE;
if (zd->rxdata[i+14]&0x01)
@@ -1204,6 +1206,17 @@
iwe.u.qual.noise= zd->rxdata[i+2]/10-100;
iwe.u.qual.level = (256+zd->rxdata[i+4]*100)/255-100;
iwe.u.qual.updated = 7;
+
+ if (ap_essid && zd->essid && !strcmp(ap_essid, zd->essid)) {
+ /* hack: work around hardware bug, update current
+* link quality using the scan result.
+*/
+ zd->iwstats.qual.qual = iwe.u.qual.qual;
+ zd->iwstats.qual.level = iwe.u.qual.level;
+ zd->iwstats.qual.noise = iwe.u.qual.noise;
+ zd->iwstats.qual.updated = 2;
+ }
+
cev = iwe_stream_add_event(cev, end_buf, , IW_EV_QUAL_LEN);
}
-
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/
RFC: workaround quality bug in zd1201 hardware
Hi,
I saw in zd1201.c that there's a hardware bug related to quality
statistics:
/* Unfortunatly the quality and noise reported is useless.
they seem to be accumulators that increase until you
read them, unless we poll on a fixed interval we can't
use them
*/
Given that I couldn't find any spec for the zd1201, I tried the
following patch to see if we could cheat by updating commsquality while
scanning. The idea is to use the values we find during scan and copy
them to zd-iwstats; this can be useful because there are a lots of
tools out there that perform scanning periodically (netapplet,
NetworkManager, ...).
Unfortunately this doesn't work perfectly, because it looks like the
scale is different when reporting AP quality on scanning and
normal quality.
Maybe this can be made useful with a simple conversion ?
If anyone that has more knowledge on 802.11b than I have could give me
an hint, it'd be appreciated.
Thanks!
Signed-off-by: Colin Leroy [EMAIL PROTECTED]
--- a/drivers/usb/net/zd1201.c 2005-03-23 15:17:12.0 +0100
+++ b/drivers/usb/net/zd1201.c 2005-03-23 15:17:50.0 +0100
@@ -1160,6 +1160,7 @@
return -EIO;
for(i=8; izd-rxlen; i+=62) {
+ const char *ap_essid;
iwe.cmd = SIOCGIWAP;
iwe.u.ap_addr.sa_family = ARPHRD_ETHER;
memcpy(iwe.u.ap_addr.sa_data, zd-rxdata+i+6, 6);
@@ -1169,6 +1170,7 @@
iwe.u.data.length = zd-rxdata[i+16];
iwe.u.data.flags = 1;
cev = iwe_stream_add_point(cev, end_buf, iwe, zd-rxdata+i+18);
+ ap_essid = zd-rxdata+i+18;
iwe.cmd = SIOCGIWMODE;
if (zd-rxdata[i+14]0x01)
@@ -1204,6 +1206,17 @@
iwe.u.qual.noise= zd-rxdata[i+2]/10-100;
iwe.u.qual.level = (256+zd-rxdata[i+4]*100)/255-100;
iwe.u.qual.updated = 7;
+
+ if (ap_essid zd-essid !strcmp(ap_essid, zd-essid)) {
+ /* hack: work around hardware bug, update current
+* link quality using the scan result.
+*/
+ zd-iwstats.qual.qual = iwe.u.qual.qual;
+ zd-iwstats.qual.level = iwe.u.qual.level;
+ zd-iwstats.qual.noise = iwe.u.qual.noise;
+ zd-iwstats.qual.updated = 2;
+ }
+
cev = iwe_stream_add_event(cev, end_buf, iwe, IW_EV_QUAL_LEN);
}
-
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/
`dd` problem from cdrom
Hi,
Using 2.6.10 and 2.6.11, trying to use dd from the ide cdrom in my
Ibook G4 fails like this:
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ dd if=/dev/hdc of=/dev/null
dd: reading `/dev/hdc': Input/output error
0+0 records in
0+0 records out
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ dmesg
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 0
Buffer I/O error on device hdc, logical block 0
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 8
Buffer I/O error on device hdc, logical block 1
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 16
Buffer I/O error on device hdc, logical block 2
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 24
Buffer I/O error on device hdc, logical block 3
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 32
Buffer I/O error on device hdc, logical block 4
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 40
Buffer I/O error on device hdc, logical block 5
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 48
Buffer I/O error on device hdc, logical block 6
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 56
Buffer I/O error on device hdc, logical block 7
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 0
Buffer I/O error on device hdc, logical block 0
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ hdparm /dev/hdc
/dev/hdc:
HDIO_GET_MULTCOUNT failed: Invalid argument
IO_support = 0 (default 16-bit)
unmaskirq= 1 (on)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
HDIO_GETGEO failed: Invalid argument
I didn't try older kernels yet; Any idea about this? Is it a kernel bug
or a configuration issue?
--
Colin
-
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/
`dd` problem from cdrom
Hi,
Using 2.6.10 and 2.6.11, trying to use dd from the ide cdrom in my
Ibook G4 fails like this:
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ dd if=/dev/hdc of=/dev/null
dd: reading `/dev/hdc': Input/output error
0+0 records in
0+0 records out
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ dmesg
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 0
Buffer I/O error on device hdc, logical block 0
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 8
Buffer I/O error on device hdc, logical block 1
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 16
Buffer I/O error on device hdc, logical block 2
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 24
Buffer I/O error on device hdc, logical block 3
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 32
Buffer I/O error on device hdc, logical block 4
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 40
Buffer I/O error on device hdc, logical block 5
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 48
Buffer I/O error on device hdc, logical block 6
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 56
Buffer I/O error on device hdc, logical block 7
hdc: command error: status=0x51 { DriveReady SeekComplete Error }
hdc: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 0
Buffer I/O error on device hdc, logical block 0
[EMAIL PROTECTED] /usr/src/linux-2.6.10]$ hdparm /dev/hdc
/dev/hdc:
HDIO_GET_MULTCOUNT failed: Invalid argument
IO_support = 0 (default 16-bit)
unmaskirq= 1 (on)
using_dma= 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead= 256 (on)
HDIO_GETGEO failed: Invalid argument
I didn't try older kernels yet; Any idea about this? Is it a kernel bug
or a configuration issue?
--
Colin
-
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/
[PATCH] Make therm_adt746x handle latest powerbooks
Hi,
This patch lets therm_adt746x handle the latest powerbooks. In these
ones, Apple doesn't put the i2c bus number in the "reg" property of
the fan node. Instead, we can get the bus number from the fan node
path, which looks like "/proc/device-tree/.../[EMAIL PROTECTED]/.../fan".
Here's a patch that handles both old and new form.
Please apply :)
Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
--- a/drivers/macintosh/therm_adt746x.c 2005-03-07
09:03:58.0 +0100
+++ b/drivers/macintosh/therm_adt746x.c 2005-03-07
09:04:35.0 +0100
@@ -548,7 +548,15 @@
prop = (u32 *)get_property(np, "reg", NULL);
if (!prop)
return -ENODEV;
- therm_bus = ((*prop) >> 8) & 0x0f;
+
+ /* look for bus either by path or using "reg" */
+ if (strstr(np->full_name, "/i2c-bus@") != NULL) {
+ const char *tmp_bus = (strstr(np->full_name, "/i2c-bus@") + 9);
+ therm_bus = tmp_bus[0]-'0';
+ } else {
+ therm_bus = ((*prop) >> 8) & 0x0f;
+ }
+
therm_address = ((*prop) & 0xff) >> 1;
printk(KERN_INFO "adt746x: Thermostat bus: %d, address: 0x%02x, "
-
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/
[PATCH] Make therm_adt746x handle latest powerbooks
Hi,
This patch lets therm_adt746x handle the latest powerbooks. In these
ones, Apple doesn't put the i2c bus number in the reg property of
the fan node. Instead, we can get the bus number from the fan node
path, which looks like /proc/device-tree/.../[EMAIL PROTECTED]/.../fan.
Here's a patch that handles both old and new form.
Please apply :)
Signed-off-by: Colin Leroy [EMAIL PROTECTED]
--- a/drivers/macintosh/therm_adt746x.c 2005-03-07
09:03:58.0 +0100
+++ b/drivers/macintosh/therm_adt746x.c 2005-03-07
09:04:35.0 +0100
@@ -548,7 +548,15 @@
prop = (u32 *)get_property(np, reg, NULL);
if (!prop)
return -ENODEV;
- therm_bus = ((*prop) 8) 0x0f;
+
+ /* look for bus either by path or using reg */
+ if (strstr(np-full_name, /i2c-bus@) != NULL) {
+ const char *tmp_bus = (strstr(np-full_name, /i2c-bus@) + 9);
+ therm_bus = tmp_bus[0]-'0';
+ } else {
+ therm_bus = ((*prop) 8) 0x0f;
+ }
+
therm_address = ((*prop) 0xff) 1;
printk(KERN_INFO adt746x: Thermostat bus: %d, address: 0x%02x,
-
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/
Re: [PATCH] therm_adt746x: smooth fan
> This patchs allows a smoother fan speed switching with therm_adt746x. > Instead of setting 0 or 128, it scales speed according to temperature. Thanks, but you'd have saved some of your time if you had checked 2.6.10: I implemented such a system, it's in since 2.6.10 :) > It would be even better if I'd have more precise temp data, but I'm > not sure if it's even supported by the chip. It's not possible, iirc. Also, it's better to Cc: the maintainer of a module when submitting patches. I'm not subscribed to lkml currently, and would have missed your mail if I didn't get it from a friend. -- Colin - 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/
Re: [PATCH] therm_adt746x: smooth fan
This patchs allows a smoother fan speed switching with therm_adt746x. Instead of setting 0 or 128, it scales speed according to temperature. Thanks, but you'd have saved some of your time if you had checked 2.6.10: I implemented such a system, it's in since 2.6.10 :) It would be even better if I'd have more precise temp data, but I'm not sure if it's even supported by the chip. It's not possible, iirc. Also, it's better to Cc: the maintainer of a module when submitting patches. I'm not subscribed to lkml currently, and would have missed your mail if I didn't get it from a friend. -- Colin - 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/
