* [PATCH v5 0/2] Make all it87 drivers SMP safe @ 2011-04-12 20:48 ` Nat Gurumoorthy 0 siblings, 0 replies; 30+ messages in thread From: Nat Gurumoorthy @ 2011-04-12 20:48 UTC (permalink / raw) To: Jean Delvare, Guenter Roeck, Wim Van Sebroeck Cc: Mike Waychison, lm-sensors, linux-kernel, linux-watchdog, Nat Gurumoorthy There are 3 different drivers that touch the it87 hardware registers. The 3 drivers have been written independently and access the it87 hardware registers assuming they are the only driver accessing it. This change attempts to serialize access to the hardware by using "request_muxed_region" macro defined by Alan Cox. Call to this macro will hold off the requestor if the resource is currently busy. The use of the above macro makes it possible to get rid of spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. This also greatly simplifies the implementation of it87_wdt.c driver. 01 - Changes to it87 watchdog driver to use "request_muxed_region" drivers/watchdog/it8712f_wdt.c drivers/watchdog/it87_wdt.c 02 - Chages to hwmon it87 driver to use "request_muxed_region" drivers/hwmon/it87.c drivers/hwmon/it87.c | 6 +++++ drivers/watchdog/it8712f_wdt.c | 11 +++++---- drivers/watchdog/it87_wdt.c | 41 +++++---------------------------------- 3 files changed, 18 insertions(+), 40 deletions(-) Signed-off-by: Nat Gurumoorthy <natg@google.com> Patch History: v5: - Remove unnecessary while from superio_enter. v4: - Remove extra braces in superio_enter routines. v3: - Totally abandon the spinlock based approach and use "request_muxed_region" to hold off requestors if the resource is busy. v2: - More verbose patch headers. Add In-Reply-To: field. ^ permalink raw reply [flat|nested] 30+ messages in thread
* [lm-sensors] [PATCH v5 0/2] Make all it87 drivers SMP safe @ 2011-04-12 20:48 ` Nat Gurumoorthy 0 siblings, 0 replies; 30+ messages in thread From: Nat Gurumoorthy @ 2011-04-12 20:48 UTC (permalink / raw) To: Jean Delvare, Guenter Roeck, Wim Van Sebroeck Cc: Mike Waychison, lm-sensors, linux-kernel, linux-watchdog, Nat Gurumoorthy There are 3 different drivers that touch the it87 hardware registers. The 3 drivers have been written independently and access the it87 hardware registers assuming they are the only driver accessing it. This change attempts to serialize access to the hardware by using "request_muxed_region" macro defined by Alan Cox. Call to this macro will hold off the requestor if the resource is currently busy. The use of the above macro makes it possible to get rid of spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. This also greatly simplifies the implementation of it87_wdt.c driver. 01 - Changes to it87 watchdog driver to use "request_muxed_region" drivers/watchdog/it8712f_wdt.c drivers/watchdog/it87_wdt.c 02 - Chages to hwmon it87 driver to use "request_muxed_region" drivers/hwmon/it87.c drivers/hwmon/it87.c | 6 +++++ drivers/watchdog/it8712f_wdt.c | 11 +++++---- drivers/watchdog/it87_wdt.c | 41 +++++---------------------------------- 3 files changed, 18 insertions(+), 40 deletions(-) Signed-off-by: Nat Gurumoorthy <natg@google.com> Patch History: v5: - Remove unnecessary while from superio_enter. v4: - Remove extra braces in superio_enter routines. v3: - Totally abandon the spinlock based approach and use "request_muxed_region" to hold off requestors if the resource is busy. v2: - More verbose patch headers. Add In-Reply-To: field. _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-12 20:48 ` [lm-sensors] " Nat Gurumoorthy @ 2011-04-12 20:49 ` Nat Gurumoorthy -1 siblings, 0 replies; 30+ messages in thread From: Nat Gurumoorthy @ 2011-04-12 20:49 UTC (permalink / raw) To: Jean Delvare, Guenter Roeck, Wim Van Sebroeck Cc: Mike Waychison, lm-sensors, linux-kernel, linux-watchdog, Nat Gurumoorthy 01 - Changes to it87 watchdog driver to use "request_muxed_region" Serialize access to the hardware by using "request_muxed_region" macro defined by Alan Cox. Call to this macro will hold off the requestor if the resource is currently busy. The use of the above macro makes it possible to get rid of spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. This also greatly simplifies the implementation of it87_wdt.c driver. Signed-off-by: Nat Gurumoorthy <natg@google.com> --- diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c index 6143f52..51bfbc0 100644 --- a/drivers/watchdog/it8712f_wdt.c +++ b/drivers/watchdog/it8712f_wdt.c @@ -51,7 +51,6 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close"); static unsigned long wdt_open; static unsigned expect_close; -static spinlock_t io_lock; static unsigned char revision; /* Dog Food address - We use the game port address */ @@ -123,7 +122,11 @@ static inline void superio_select(int ldn) static inline void superio_enter(void) { - spin_lock(&io_lock); + /* + * Reserve REG and REG + 1 for exclusive access. + */ + (void) request_muxed_region(REG, 2, NAME); + outb(0x87, REG); outb(0x01, REG); outb(0x55, REG); @@ -134,7 +137,7 @@ static inline void superio_exit(void) { outb(0x02, REG); outb(0x02, VAL); - spin_unlock(&io_lock); + release_region(REG, 2); } static inline void it8712f_wdt_ping(void) @@ -382,8 +385,6 @@ static int __init it8712f_wdt_init(void) { int err = 0; - spin_lock_init(&io_lock); - if (it8712f_wdt_find(&address)) return -ENODEV; diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c index b1bc72f..ac7d26a 100644 --- a/drivers/watchdog/it87_wdt.c +++ b/drivers/watchdog/it87_wdt.c @@ -137,7 +137,6 @@ static unsigned int base, gpact, ciract, max_units, chip_type; static unsigned long wdt_status; -static DEFINE_SPINLOCK(spinlock); static int nogameport = DEFAULT_NOGAMEPORT; static int exclusive = DEFAULT_EXCLUSIVE; @@ -165,6 +164,11 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started, default=" static inline void superio_enter(void) { + /* + * Reserve REG and REG + 1 for exclusive access. + */ + (void) request_muxed_region(REG, 2, WATCHDOG_NAME); + outb(0x87, REG); outb(0x01, REG); outb(0x55, REG); @@ -175,6 +179,7 @@ static inline void superio_exit(void) { outb(0x02, REG); outb(0x02, VAL); + release_region(REG, 2); } static inline void superio_select(int ldn) @@ -257,9 +262,6 @@ static void wdt_keepalive(void) static void wdt_start(void) { - unsigned long flags; - - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); @@ -270,14 +272,10 @@ static void wdt_start(void) wdt_update_timeout(); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } static void wdt_stop(void) { - unsigned long flags; - - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); @@ -288,7 +286,6 @@ static void wdt_stop(void) superio_outb(0x00, WDTVALMSB); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } /** @@ -303,8 +300,6 @@ static void wdt_stop(void) static int wdt_set_timeout(int t) { - unsigned long flags; - if (t < 1 || t > max_units * 60) return -EINVAL; @@ -313,14 +308,12 @@ static int wdt_set_timeout(int t) else timeout = t; - spin_lock_irqsave(&spinlock, flags); if (test_bit(WDTS_TIMER_RUN, &wdt_status)) { superio_enter(); superio_select(GPIO); wdt_update_timeout(); superio_exit(); } - spin_unlock_irqrestore(&spinlock, flags); return 0; } @@ -339,11 +332,8 @@ static int wdt_set_timeout(int t) static int wdt_get_status(int *status) { - unsigned long flags; - *status = 0; if (testmode) { - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); if (superio_inb(WDTCTRL) & WDT_ZERO) { @@ -353,7 +343,6 @@ static int wdt_get_status(int *status) } superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } if (test_and_clear_bit(WDTS_KEEPALIVE, &wdt_status)) *status |= WDIOF_KEEPALIVEPING; @@ -560,16 +549,13 @@ static int __init it87_wdt_init(void) int rc = 0; int try_gameport = !nogameport; u8 chip_rev; - unsigned long flags; wdt_status = 0; - spin_lock_irqsave(&spinlock, flags); superio_enter(); chip_type = superio_inw(CHIPID); chip_rev = superio_inb(CHIPREV) & 0x0f; superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); switch (chip_type) { case IT8702_ID: @@ -603,7 +589,6 @@ static int __init it87_wdt_init(void) return -ENODEV; } - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); @@ -621,14 +606,12 @@ static int __init it87_wdt_init(void) gpact = superio_inb(ACTREG); superio_outb(0x01, ACTREG); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); if (request_region(base, 1, WATCHDOG_NAME)) set_bit(WDTS_USE_GP, &wdt_status); else rc = -EIO; } else { superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } /* If we haven't Gameport support, try to get CIR support */ @@ -646,7 +629,6 @@ static int __init it87_wdt_init(void) goto err_out; } base = CIR_BASE; - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(CIR); @@ -660,7 +642,6 @@ static int __init it87_wdt_init(void) } superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } if (timeout < 1 || timeout > max_units * 60) { @@ -711,21 +692,17 @@ err_out_reboot: err_out_region: release_region(base, test_bit(WDTS_USE_GP, &wdt_status) ? 1 : 8); if (!test_bit(WDTS_USE_GP, &wdt_status)) { - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(CIR); superio_outb(ciract, ACTREG); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } err_out: if (try_gameport) { - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GAMEPORT); superio_outb(gpact, ACTREG); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } return rc; @@ -733,10 +710,6 @@ err_out: static void __exit it87_wdt_exit(void) { - unsigned long flags; - int nolock; - - nolock = !spin_trylock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); superio_outb(0x00, WDTCTRL); @@ -752,8 +725,6 @@ static void __exit it87_wdt_exit(void) superio_outb(ciract, ACTREG); } superio_exit(); - if (!nolock) - spin_unlock_irqrestore(&spinlock, flags); misc_deregister(&wdt_miscdev); unregister_reboot_notifier(&wdt_notifier); -- 1.7.3.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-12 20:49 ` Nat Gurumoorthy 0 siblings, 0 replies; 30+ messages in thread From: Nat Gurumoorthy @ 2011-04-12 20:49 UTC (permalink / raw) To: Jean Delvare, Guenter Roeck, Wim Van Sebroeck Cc: Mike Waychison, lm-sensors, linux-kernel, linux-watchdog, Nat Gurumoorthy 01 - Changes to it87 watchdog driver to use "request_muxed_region" Serialize access to the hardware by using "request_muxed_region" macro defined by Alan Cox. Call to this macro will hold off the requestor if the resource is currently busy. The use of the above macro makes it possible to get rid of spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. This also greatly simplifies the implementation of it87_wdt.c driver. Signed-off-by: Nat Gurumoorthy <natg@google.com> --- diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c index 6143f52..51bfbc0 100644 --- a/drivers/watchdog/it8712f_wdt.c +++ b/drivers/watchdog/it8712f_wdt.c @@ -51,7 +51,6 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close"); static unsigned long wdt_open; static unsigned expect_close; -static spinlock_t io_lock; static unsigned char revision; /* Dog Food address - We use the game port address */ @@ -123,7 +122,11 @@ static inline void superio_select(int ldn) static inline void superio_enter(void) { - spin_lock(&io_lock); + /* + * Reserve REG and REG + 1 for exclusive access. + */ + (void) request_muxed_region(REG, 2, NAME); + outb(0x87, REG); outb(0x01, REG); outb(0x55, REG); @@ -134,7 +137,7 @@ static inline void superio_exit(void) { outb(0x02, REG); outb(0x02, VAL); - spin_unlock(&io_lock); + release_region(REG, 2); } static inline void it8712f_wdt_ping(void) @@ -382,8 +385,6 @@ static int __init it8712f_wdt_init(void) { int err = 0; - spin_lock_init(&io_lock); - if (it8712f_wdt_find(&address)) return -ENODEV; diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c index b1bc72f..ac7d26a 100644 --- a/drivers/watchdog/it87_wdt.c +++ b/drivers/watchdog/it87_wdt.c @@ -137,7 +137,6 @@ static unsigned int base, gpact, ciract, max_units, chip_type; static unsigned long wdt_status; -static DEFINE_SPINLOCK(spinlock); static int nogameport = DEFAULT_NOGAMEPORT; static int exclusive = DEFAULT_EXCLUSIVE; @@ -165,6 +164,11 @@ MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started, default=" static inline void superio_enter(void) { + /* + * Reserve REG and REG + 1 for exclusive access. + */ + (void) request_muxed_region(REG, 2, WATCHDOG_NAME); + outb(0x87, REG); outb(0x01, REG); outb(0x55, REG); @@ -175,6 +179,7 @@ static inline void superio_exit(void) { outb(0x02, REG); outb(0x02, VAL); + release_region(REG, 2); } static inline void superio_select(int ldn) @@ -257,9 +262,6 @@ static void wdt_keepalive(void) static void wdt_start(void) { - unsigned long flags; - - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); @@ -270,14 +272,10 @@ static void wdt_start(void) wdt_update_timeout(); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } static void wdt_stop(void) { - unsigned long flags; - - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); @@ -288,7 +286,6 @@ static void wdt_stop(void) superio_outb(0x00, WDTVALMSB); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } /** @@ -303,8 +300,6 @@ static void wdt_stop(void) static int wdt_set_timeout(int t) { - unsigned long flags; - if (t < 1 || t > max_units * 60) return -EINVAL; @@ -313,14 +308,12 @@ static int wdt_set_timeout(int t) else timeout = t; - spin_lock_irqsave(&spinlock, flags); if (test_bit(WDTS_TIMER_RUN, &wdt_status)) { superio_enter(); superio_select(GPIO); wdt_update_timeout(); superio_exit(); } - spin_unlock_irqrestore(&spinlock, flags); return 0; } @@ -339,11 +332,8 @@ static int wdt_set_timeout(int t) static int wdt_get_status(int *status) { - unsigned long flags; - *status = 0; if (testmode) { - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); if (superio_inb(WDTCTRL) & WDT_ZERO) { @@ -353,7 +343,6 @@ static int wdt_get_status(int *status) } superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } if (test_and_clear_bit(WDTS_KEEPALIVE, &wdt_status)) *status |= WDIOF_KEEPALIVEPING; @@ -560,16 +549,13 @@ static int __init it87_wdt_init(void) int rc = 0; int try_gameport = !nogameport; u8 chip_rev; - unsigned long flags; wdt_status = 0; - spin_lock_irqsave(&spinlock, flags); superio_enter(); chip_type = superio_inw(CHIPID); chip_rev = superio_inb(CHIPREV) & 0x0f; superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); switch (chip_type) { case IT8702_ID: @@ -603,7 +589,6 @@ static int __init it87_wdt_init(void) return -ENODEV; } - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); @@ -621,14 +606,12 @@ static int __init it87_wdt_init(void) gpact = superio_inb(ACTREG); superio_outb(0x01, ACTREG); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); if (request_region(base, 1, WATCHDOG_NAME)) set_bit(WDTS_USE_GP, &wdt_status); else rc = -EIO; } else { superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } /* If we haven't Gameport support, try to get CIR support */ @@ -646,7 +629,6 @@ static int __init it87_wdt_init(void) goto err_out; } base = CIR_BASE; - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(CIR); @@ -660,7 +642,6 @@ static int __init it87_wdt_init(void) } superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } if (timeout < 1 || timeout > max_units * 60) { @@ -711,21 +692,17 @@ err_out_reboot: err_out_region: release_region(base, test_bit(WDTS_USE_GP, &wdt_status) ? 1 : 8); if (!test_bit(WDTS_USE_GP, &wdt_status)) { - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(CIR); superio_outb(ciract, ACTREG); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } err_out: if (try_gameport) { - spin_lock_irqsave(&spinlock, flags); superio_enter(); superio_select(GAMEPORT); superio_outb(gpact, ACTREG); superio_exit(); - spin_unlock_irqrestore(&spinlock, flags); } return rc; @@ -733,10 +710,6 @@ err_out: static void __exit it87_wdt_exit(void) { - unsigned long flags; - int nolock; - - nolock = !spin_trylock_irqsave(&spinlock, flags); superio_enter(); superio_select(GPIO); superio_outb(0x00, WDTCTRL); @@ -752,8 +725,6 @@ static void __exit it87_wdt_exit(void) superio_outb(ciract, ACTREG); } superio_exit(); - if (!nolock) - spin_unlock_irqrestore(&spinlock, flags); misc_deregister(&wdt_miscdev); unregister_reboot_notifier(&wdt_notifier); -- 1.7.3.1 _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-12 20:49 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Nat Gurumoorthy @ 2011-04-13 6:50 ` Hans de Goede -1 siblings, 0 replies; 30+ messages in thread From: Hans de Goede @ 2011-04-13 6:50 UTC (permalink / raw) To: Nat Gurumoorthy Cc: Jean Delvare, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison Hi, On 04/12/2011 10:49 PM, Nat Gurumoorthy wrote: > 01 - Changes to it87 watchdog driver to use "request_muxed_region" > Serialize access to the hardware by using "request_muxed_region" macro defined > by Alan Cox. Call to this macro will hold off the requestor if the resource is > currently busy. > > The use of the above macro makes it possible to get rid of > spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. > This also greatly simplifies the implementation of it87_wdt.c driver. > > Signed-off-by: Nat Gurumoorthy<natg@google.com> > --- > > diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c > index 6143f52..51bfbc0 100644 > --- a/drivers/watchdog/it8712f_wdt.c > +++ b/drivers/watchdog/it8712f_wdt.c > @@ -51,7 +51,6 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close"); > > static unsigned long wdt_open; > static unsigned expect_close; > -static spinlock_t io_lock; > static unsigned char revision; > > /* Dog Food address - We use the game port address */ > @@ -123,7 +122,11 @@ static inline void superio_select(int ldn) > > static inline void superio_enter(void) > { > - spin_lock(&io_lock); > + /* > + * Reserve REG and REG + 1 for exclusive access. > + */ > + (void) request_muxed_region(REG, 2, NAME); > + You shouldn't (void) this, there is a reason you get a warning otherwise! request_muxed_region can still fail if some other driver has done a none muxed request_region on the same region, and in that case you should not continue with accessing the io-ports. Regards, Hans ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 6:50 ` Hans de Goede 0 siblings, 0 replies; 30+ messages in thread From: Hans de Goede @ 2011-04-13 6:50 UTC (permalink / raw) To: Nat Gurumoorthy Cc: Jean Delvare, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison Hi, On 04/12/2011 10:49 PM, Nat Gurumoorthy wrote: > 01 - Changes to it87 watchdog driver to use "request_muxed_region" > Serialize access to the hardware by using "request_muxed_region" macro defined > by Alan Cox. Call to this macro will hold off the requestor if the resource is > currently busy. > > The use of the above macro makes it possible to get rid of > spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. > This also greatly simplifies the implementation of it87_wdt.c driver. > > Signed-off-by: Nat Gurumoorthy<natg@google.com> > --- > > diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c > index 6143f52..51bfbc0 100644 > --- a/drivers/watchdog/it8712f_wdt.c > +++ b/drivers/watchdog/it8712f_wdt.c > @@ -51,7 +51,6 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close"); > > static unsigned long wdt_open; > static unsigned expect_close; > -static spinlock_t io_lock; > static unsigned char revision; > > /* Dog Food address - We use the game port address */ > @@ -123,7 +122,11 @@ static inline void superio_select(int ldn) > > static inline void superio_enter(void) > { > - spin_lock(&io_lock); > + /* > + * Reserve REG and REG + 1 for exclusive access. > + */ > + (void) request_muxed_region(REG, 2, NAME); > + You shouldn't (void) this, there is a reason you get a warning otherwise! request_muxed_region can still fail if some other driver has done a none muxed request_region on the same region, and in that case you should not continue with accessing the io-ports. Regards, Hans _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 6:50 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Hans de Goede @ 2011-04-13 8:05 ` Natarajan Gurumoorthy -1 siblings, 0 replies; 30+ messages in thread From: Natarajan Gurumoorthy @ 2011-04-13 8:05 UTC (permalink / raw) To: Hans de Goede Cc: Jean Delvare, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison Hans, Comments below On Tue, Apr 12, 2011 at 11:50 PM, Hans de Goede <hdegoede@redhat.com> wrote: > > You shouldn't (void) this, there is a reason you get a warning > otherwise! request_muxed_region can still fail if some other driver > has done a none muxed request_region on the same region, and in that > case you should not continue with accessing the io-ports. There are 3 it87 drivers and they all have to do the exact same sequence to put the chip into a mode where they can modify its state. The sequences involve non atomic sequences that write locations 0x2e and 0x2f. When they are done they write a different sequence to these 2 locations. The entry routine is superio_enter and exit is superio_exit. All the it87 drivers reserve these 2 locations before they start manipulating the chip. This macro will hold off requestors if the resource is busy because one of the other drivers is manipulating the chip. Once the an it87 driver is done it calls superio_exit which will release the reservation on those 2 locations letting any other driver on the wait queue to now gain access two locations. Please read code in kernel/resource.c function "__request_region". "request_muxed_region" turns on IORESOURCE_MUXED bit and that means that only way an it87 driver will get back from a call to "request_muxed_region" is when it gets hold of the region. The scenario you mention above can never happen. Regards Nat > > Regards, > > Hans > -- Regards Nat Gurumoorthy AB6SJ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 8:05 ` Natarajan Gurumoorthy 0 siblings, 0 replies; 30+ messages in thread From: Natarajan Gurumoorthy @ 2011-04-13 8:05 UTC (permalink / raw) To: Hans de Goede Cc: Jean Delvare, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison Hans, Comments below On Tue, Apr 12, 2011 at 11:50 PM, Hans de Goede <hdegoede@redhat.com> wrote: > > You shouldn't (void) this, there is a reason you get a warning > otherwise! request_muxed_region can still fail if some other driver > has done a none muxed request_region on the same region, and in that > case you should not continue with accessing the io-ports. There are 3 it87 drivers and they all have to do the exact same sequence to put the chip into a mode where they can modify its state. The sequences involve non atomic sequences that write locations 0x2e and 0x2f. When they are done they write a different sequence to these 2 locations. The entry routine is superio_enter and exit is superio_exit. All the it87 drivers reserve these 2 locations before they start manipulating the chip. This macro will hold off requestors if the resource is busy because one of the other drivers is manipulating the chip. Once the an it87 driver is done it calls superio_exit which will release the reservation on those 2 locations letting any other driver on the wait queue to now gain access two locations. Please read code in kernel/resource.c function "__request_region". "request_muxed_region" turns on IORESOURCE_MUXED bit and that means that only way an it87 driver will get back from a call to "request_muxed_region" is when it gets hold of the region. The scenario you mention above can never happen. Regards Nat > > Regards, > > Hans > -- Regards Nat Gurumoorthy AB6SJ _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 8:05 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Natarajan Gurumoorthy @ 2011-04-13 8:34 ` Jean Delvare -1 siblings, 0 replies; 30+ messages in thread From: Jean Delvare @ 2011-04-13 8:34 UTC (permalink / raw) To: Natarajan Gurumoorthy Cc: Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison On Wed, 13 Apr 2011 01:05:33 -0700, Natarajan Gurumoorthy wrote: > Hans, > Comments below > > On Tue, Apr 12, 2011 at 11:50 PM, Hans de Goede <hdegoede@redhat.com> wrote: > > > > You shouldn't (void) this, there is a reason you get a warning > > otherwise! request_muxed_region can still fail if some other driver > > has done a none muxed request_region on the same region, and in that > > case you should not continue with accessing the io-ports. > There are 3 it87 drivers and they all have to do the exact same > sequence to put the chip into a mode where they can modify its state. > The sequences involve non atomic sequences that write locations 0x2e > and 0x2f. When they are done they write a different sequence to these > 2 locations. The entry routine is superio_enter and exit is > superio_exit. All the it87 drivers reserve these 2 locations before > they start manipulating the chip. This macro will hold off requestors > if the resource is busy because one of the other drivers is > manipulating the chip. Once the an it87 driver is done it calls > superio_exit which will release the reservation on those 2 locations > letting any other driver on the wait queue to now gain access two > locations. > > Please read code in kernel/resource.c function "__request_region". > "request_muxed_region" turns on IORESOURCE_MUXED bit and that means > that only way an it87 driver will get back from a call to > "request_muxed_region" is when it gets hold of the region. > > The scenario you mention above can never happen. Let me be straight clear, as apparently you have difficulties understanding Hans's simple request: You do not get to (void) the return of request_muxed_region(), period. This is _not_ negotiable. What other it87 drivers currently in the tree do or don't do is totally irrelevant. There can be new it87 drivers added later, there can be out-of-tree it87 drivers (including old copies of in-tree ones), and there can be non-it87 drivers accessing the I/O ports (or at least attempting to.) So the scenario mentioned by Hans can very well happen, and you have to deal with it. Thanks, -- Jean Delvare ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 8:34 ` Jean Delvare 0 siblings, 0 replies; 30+ messages in thread From: Jean Delvare @ 2011-04-13 8:34 UTC (permalink / raw) To: Natarajan Gurumoorthy Cc: Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison On Wed, 13 Apr 2011 01:05:33 -0700, Natarajan Gurumoorthy wrote: > Hans, > Comments below > > On Tue, Apr 12, 2011 at 11:50 PM, Hans de Goede <hdegoede@redhat.com> wrote: > > > > You shouldn't (void) this, there is a reason you get a warning > > otherwise! request_muxed_region can still fail if some other driver > > has done a none muxed request_region on the same region, and in that > > case you should not continue with accessing the io-ports. > There are 3 it87 drivers and they all have to do the exact same > sequence to put the chip into a mode where they can modify its state. > The sequences involve non atomic sequences that write locations 0x2e > and 0x2f. When they are done they write a different sequence to these > 2 locations. The entry routine is superio_enter and exit is > superio_exit. All the it87 drivers reserve these 2 locations before > they start manipulating the chip. This macro will hold off requestors > if the resource is busy because one of the other drivers is > manipulating the chip. Once the an it87 driver is done it calls > superio_exit which will release the reservation on those 2 locations > letting any other driver on the wait queue to now gain access two > locations. > > Please read code in kernel/resource.c function "__request_region". > "request_muxed_region" turns on IORESOURCE_MUXED bit and that means > that only way an it87 driver will get back from a call to > "request_muxed_region" is when it gets hold of the region. > > The scenario you mention above can never happen. Let me be straight clear, as apparently you have difficulties understanding Hans's simple request: You do not get to (void) the return of request_muxed_region(), period. This is _not_ negotiable. What other it87 drivers currently in the tree do or don't do is totally irrelevant. There can be new it87 drivers added later, there can be out-of-tree it87 drivers (including old copies of in-tree ones), and there can be non-it87 drivers accessing the I/O ports (or at least attempting to.) So the scenario mentioned by Hans can very well happen, and you have to deal with it. Thanks, -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 8:34 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Jean Delvare @ 2011-04-13 17:59 ` Natarajan Gurumoorthy -1 siblings, 0 replies; 30+ messages in thread From: Natarajan Gurumoorthy @ 2011-04-13 17:59 UTC (permalink / raw) To: Jean Delvare Cc: Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison John, Unfortunately you are right. After grepping though drivers/hwmon and drivers/watchdog I realize the ugliness is fairly deep rooted. All of the following drivers need to be cleaned up as far as the "superio_enter" "superio_exit" operation is concerned if we want this stuff to be SMP clean and allow multiple drivers to coexist. drivers/watchdog f71808e_wdt.c it8712f_wdt.c it87_wdt.c sch311x_wdt.c iTCO_vendor_support.c ibmasr.c w83697hf_wdt.c w83697ug_wdt.c: drivers/hwmon dme1737.c:1935:static inline void dme1737_sio_enter(int sio_cip) f71805f.c:100:superio_enter(int base) f71882fg.c:196:static inline int superio_enter(int base); it87.c:112:superio_enter(void) pc87360.c:1009: /* No superio_enter */ sch5627.c:118:static inline int superio_enter(int base) smsc47b397.c:75:static inline void superio_enter(void) smsc47m1.c:77:superio_enter(void) vt1211.c:223:static inline void superio_enter(int sio_cip) w83627ehf.c:135:superio_enter(int ioreg) w83627hf.c:134:superio_enter(struct w83627hf_sio_data *sio) Have I missed any other drivers that also need to be cleaned. Even if I got my boss to sign up to clean this I can only test the it8712f drivers and thats it. Regards Nat On Wed, Apr 13, 2011 at 1:34 AM, Jean Delvare <khali@linux-fr.org> wrote: > On Wed, 13 Apr 2011 01:05:33 -0700, Natarajan Gurumoorthy wrote: >> Hans, >> Comments below >> >> On Tue, Apr 12, 2011 at 11:50 PM, Hans de Goede <hdegoede@redhat.com> wrote: >> > >> > You shouldn't (void) this, there is a reason you get a warning >> > otherwise! request_muxed_region can still fail if some other driver >> > has done a none muxed request_region on the same region, and in that >> > case you should not continue with accessing the io-ports. >> There are 3 it87 drivers and they all have to do the exact same >> sequence to put the chip into a mode where they can modify its state. >> The sequences involve non atomic sequences that write locations 0x2e >> and 0x2f. When they are done they write a different sequence to these >> 2 locations. The entry routine is superio_enter and exit is >> superio_exit. All the it87 drivers reserve these 2 locations before >> they start manipulating the chip. This macro will hold off requestors >> if the resource is busy because one of the other drivers is >> manipulating the chip. Once the an it87 driver is done it calls >> superio_exit which will release the reservation on those 2 locations >> letting any other driver on the wait queue to now gain access two >> locations. >> >> Please read code in kernel/resource.c function "__request_region". >> "request_muxed_region" turns on IORESOURCE_MUXED bit and that means >> that only way an it87 driver will get back from a call to >> "request_muxed_region" is when it gets hold of the region. >> >> The scenario you mention above can never happen. > > Let me be straight clear, as apparently you have difficulties > understanding Hans's simple request: > > You do not get to (void) the return of request_muxed_region(), period. > This is _not_ negotiable. > > What other it87 drivers currently in the tree do or don't do is totally > irrelevant. There can be new it87 drivers added later, there can be > out-of-tree it87 drivers (including old copies of in-tree ones), and > there can be non-it87 drivers accessing the I/O ports (or at least > attempting to.) So the scenario mentioned by Hans can very well happen, > and you have to deal with it. > > Thanks, > -- > Jean Delvare > -- Regards Nat Gurumoorthy AB6SJ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 17:59 ` Natarajan Gurumoorthy 0 siblings, 0 replies; 30+ messages in thread From: Natarajan Gurumoorthy @ 2011-04-13 17:59 UTC (permalink / raw) To: Jean Delvare Cc: Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison John, Unfortunately you are right. After grepping though drivers/hwmon and drivers/watchdog I realize the ugliness is fairly deep rooted. All of the following drivers need to be cleaned up as far as the "superio_enter" "superio_exit" operation is concerned if we want this stuff to be SMP clean and allow multiple drivers to coexist. drivers/watchdog f71808e_wdt.c it8712f_wdt.c it87_wdt.c sch311x_wdt.c iTCO_vendor_support.c ibmasr.c w83697hf_wdt.c w83697ug_wdt.c: drivers/hwmon dme1737.c:1935:static inline void dme1737_sio_enter(int sio_cip) f71805f.c:100:superio_enter(int base) f71882fg.c:196:static inline int superio_enter(int base); it87.c:112:superio_enter(void) pc87360.c:1009: /* No superio_enter */ sch5627.c:118:static inline int superio_enter(int base) smsc47b397.c:75:static inline void superio_enter(void) smsc47m1.c:77:superio_enter(void) vt1211.c:223:static inline void superio_enter(int sio_cip) w83627ehf.c:135:superio_enter(int ioreg) w83627hf.c:134:superio_enter(struct w83627hf_sio_data *sio) Have I missed any other drivers that also need to be cleaned. Even if I got my boss to sign up to clean this I can only test the it8712f drivers and thats it. Regards Nat On Wed, Apr 13, 2011 at 1:34 AM, Jean Delvare <khali@linux-fr.org> wrote: > On Wed, 13 Apr 2011 01:05:33 -0700, Natarajan Gurumoorthy wrote: >> Hans, >> Comments below >> >> On Tue, Apr 12, 2011 at 11:50 PM, Hans de Goede <hdegoede@redhat.com> wrote: >> > >> > You shouldn't (void) this, there is a reason you get a warning >> > otherwise! request_muxed_region can still fail if some other driver >> > has done a none muxed request_region on the same region, and in that >> > case you should not continue with accessing the io-ports. >> There are 3 it87 drivers and they all have to do the exact same >> sequence to put the chip into a mode where they can modify its state. >> The sequences involve non atomic sequences that write locations 0x2e >> and 0x2f. When they are done they write a different sequence to these >> 2 locations. The entry routine is superio_enter and exit is >> superio_exit. All the it87 drivers reserve these 2 locations before >> they start manipulating the chip. This macro will hold off requestors >> if the resource is busy because one of the other drivers is >> manipulating the chip. Once the an it87 driver is done it calls >> superio_exit which will release the reservation on those 2 locations >> letting any other driver on the wait queue to now gain access two >> locations. >> >> Please read code in kernel/resource.c function "__request_region". >> "request_muxed_region" turns on IORESOURCE_MUXED bit and that means >> that only way an it87 driver will get back from a call to >> "request_muxed_region" is when it gets hold of the region. >> >> The scenario you mention above can never happen. > > Let me be straight clear, as apparently you have difficulties > understanding Hans's simple request: > > You do not get to (void) the return of request_muxed_region(), period. > This is _not_ negotiable. > > What other it87 drivers currently in the tree do or don't do is totally > irrelevant. There can be new it87 drivers added later, there can be > out-of-tree it87 drivers (including old copies of in-tree ones), and > there can be non-it87 drivers accessing the I/O ports (or at least > attempting to.) So the scenario mentioned by Hans can very well happen, > and you have to deal with it. > > Thanks, > -- > Jean Delvare > -- Regards Nat Gurumoorthy AB6SJ _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 17:59 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Natarajan Gurumoorthy @ 2011-04-13 20:34 ` Jean Delvare -1 siblings, 0 replies; 30+ messages in thread From: Jean Delvare @ 2011-04-13 20:34 UTC (permalink / raw) To: Natarajan Gurumoorthy Cc: Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison Hi Nat, Please don't top-post. On Wed, 13 Apr 2011 10:59:45 -0700, Natarajan Gurumoorthy wrote: > John, > Unfortunately you are right. After grepping though drivers/hwmon > and drivers/watchdog I realize the ugliness is fairly deep rooted. All > of the following drivers need to be cleaned up as far as the > "superio_enter" "superio_exit" operation is concerned if we want this > stuff to be SMP clean and allow multiple drivers to coexist. > > drivers/watchdog > f71808e_wdt.c > it8712f_wdt.c > it87_wdt.c > sch311x_wdt.c > iTCO_vendor_support.c > ibmasr.c > w83697hf_wdt.c > w83697ug_wdt.c: > > > drivers/hwmon > dme1737.c:1935:static inline void dme1737_sio_enter(int sio_cip) > f71805f.c:100:superio_enter(int base) > f71882fg.c:196:static inline int superio_enter(int base); > it87.c:112:superio_enter(void) > pc87360.c:1009: /* No superio_enter */ > sch5627.c:118:static inline int superio_enter(int base) > smsc47b397.c:75:static inline void superio_enter(void) > smsc47m1.c:77:superio_enter(void) > vt1211.c:223:static inline void superio_enter(int sio_cip) > w83627ehf.c:135:superio_enter(int ioreg) > w83627hf.c:134:superio_enter(struct w83627hf_sio_data *sio) > > Have I missed any other drivers that also need to be cleaned. f71882fg and sch5627 already call request_muxed_region() so I think these are safe. OTOH you missed pc87427 at least. And there are probably a few non-watchdog, non-hwmon drivers which need the same fix (for example drivers/parport/parport_pc.c and drivers/net/irda/via-ircc.h are suspect.) > Even if > I got my boss to sign up to clean this I can only test the it8712f > drivers and thats it. For one thing, you don't have to. Converting just a subset is already a welcomed step in the right direction. But anyway the changes should be fairly easy and not too risky so I wouldn't mind you doing them without testing them all. And we can find testers for most hwmon drivers, I'm sure (I can personally test f71805f and w83627ehf, maybe w83627hf). -- Jean Delvare ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 20:34 ` Jean Delvare 0 siblings, 0 replies; 30+ messages in thread From: Jean Delvare @ 2011-04-13 20:34 UTC (permalink / raw) To: Natarajan Gurumoorthy Cc: Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison Hi Nat, Please don't top-post. On Wed, 13 Apr 2011 10:59:45 -0700, Natarajan Gurumoorthy wrote: > John, > Unfortunately you are right. After grepping though drivers/hwmon > and drivers/watchdog I realize the ugliness is fairly deep rooted. All > of the following drivers need to be cleaned up as far as the > "superio_enter" "superio_exit" operation is concerned if we want this > stuff to be SMP clean and allow multiple drivers to coexist. > > drivers/watchdog > f71808e_wdt.c > it8712f_wdt.c > it87_wdt.c > sch311x_wdt.c > iTCO_vendor_support.c > ibmasr.c > w83697hf_wdt.c > w83697ug_wdt.c: > > > drivers/hwmon > dme1737.c:1935:static inline void dme1737_sio_enter(int sio_cip) > f71805f.c:100:superio_enter(int base) > f71882fg.c:196:static inline int superio_enter(int base); > it87.c:112:superio_enter(void) > pc87360.c:1009: /* No superio_enter */ > sch5627.c:118:static inline int superio_enter(int base) > smsc47b397.c:75:static inline void superio_enter(void) > smsc47m1.c:77:superio_enter(void) > vt1211.c:223:static inline void superio_enter(int sio_cip) > w83627ehf.c:135:superio_enter(int ioreg) > w83627hf.c:134:superio_enter(struct w83627hf_sio_data *sio) > > Have I missed any other drivers that also need to be cleaned. f71882fg and sch5627 already call request_muxed_region() so I think these are safe. OTOH you missed pc87427 at least. And there are probably a few non-watchdog, non-hwmon drivers which need the same fix (for example drivers/parport/parport_pc.c and drivers/net/irda/via-ircc.h are suspect.) > Even if > I got my boss to sign up to clean this I can only test the it8712f > drivers and thats it. For one thing, you don't have to. Converting just a subset is already a welcomed step in the right direction. But anyway the changes should be fairly easy and not too risky so I wouldn't mind you doing them without testing them all. And we can find testers for most hwmon drivers, I'm sure (I can personally test f71805f and w83627ehf, maybe w83627hf). -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 17:59 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Natarajan Gurumoorthy @ 2011-04-14 9:25 ` Alan Cox -1 siblings, 0 replies; 30+ messages in thread From: Alan Cox @ 2011-04-14 9:25 UTC (permalink / raw) To: Natarajan Gurumoorthy Cc: Jean Delvare, Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison > Have I missed any other drivers that also need to be cleaned. Even if > I got my boss to sign up to clean this I can only test the it8712f > drivers and thats it. I would just fix the it87 drivers. The rest is the problem of the authors/users of the other drivers. Really only they can test it and you've given them a worked reference ! Alan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-14 9:25 ` Alan Cox 0 siblings, 0 replies; 30+ messages in thread From: Alan Cox @ 2011-04-14 9:25 UTC (permalink / raw) To: Natarajan Gurumoorthy Cc: Jean Delvare, Hans de Goede, Guenter Roeck, Wim Van Sebroeck, linux-watchdog, lm-sensors, linux-kernel, Mike Waychison > Have I missed any other drivers that also need to be cleaned. Even if > I got my boss to sign up to clean this I can only test the it8712f > drivers and thats it. I would just fix the it87 drivers. The rest is the problem of the authors/users of the other drivers. Really only they can test it and you've given them a worked reference ! Alan _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 6:50 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Hans de Goede @ 2011-04-14 17:58 ` Guenter Roeck -1 siblings, 0 replies; 30+ messages in thread From: Guenter Roeck @ 2011-04-14 17:58 UTC (permalink / raw) To: Hans de Goede Cc: Nat Gurumoorthy, Jean Delvare, Wim Van Sebroeck, linux-watchdog@vger.kernel.org, lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org, Mike Waychison On Wed, 2011-04-13 at 02:50 -0400, Hans de Goede wrote: > Hi, > > On 04/12/2011 10:49 PM, Nat Gurumoorthy wrote: > > 01 - Changes to it87 watchdog driver to use "request_muxed_region" > > Serialize access to the hardware by using "request_muxed_region" macro defined > > by Alan Cox. Call to this macro will hold off the requestor if the resource is > > currently busy. > > > > The use of the above macro makes it possible to get rid of > > spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. > > This also greatly simplifies the implementation of it87_wdt.c driver. > > > > Signed-off-by: Nat Gurumoorthy<natg@google.com> > > --- > > > > diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c > > index 6143f52..51bfbc0 100644 > > --- a/drivers/watchdog/it8712f_wdt.c > > +++ b/drivers/watchdog/it8712f_wdt.c > > @@ -51,7 +51,6 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close"); > > > > static unsigned long wdt_open; > > static unsigned expect_close; > > -static spinlock_t io_lock; > > static unsigned char revision; > > > > /* Dog Food address - We use the game port address */ > > @@ -123,7 +122,11 @@ static inline void superio_select(int ldn) > > > > static inline void superio_enter(void) > > { > > - spin_lock(&io_lock); > > + /* > > + * Reserve REG and REG + 1 for exclusive access. > > + */ > > + (void) request_muxed_region(REG, 2, NAME); > > + > > You shouldn't (void) this, there is a reason you get a warning > otherwise! request_muxed_region can still fail if some other driver > has done a none muxed request_region on the same region, and in that > case you should not continue with accessing the io-ports. > Absolutely agree - even if that means adding a return code to superio_enter() and checking it from the calling code. Guenter ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-14 17:58 ` Guenter Roeck 0 siblings, 0 replies; 30+ messages in thread From: Guenter Roeck @ 2011-04-14 17:58 UTC (permalink / raw) To: Hans de Goede Cc: Nat Gurumoorthy, Jean Delvare, Wim Van Sebroeck, linux-watchdog@vger.kernel.org, lm-sensors@lm-sensors.org, linux-kernel@vger.kernel.org, Mike Waychison On Wed, 2011-04-13 at 02:50 -0400, Hans de Goede wrote: > Hi, > > On 04/12/2011 10:49 PM, Nat Gurumoorthy wrote: > > 01 - Changes to it87 watchdog driver to use "request_muxed_region" > > Serialize access to the hardware by using "request_muxed_region" macro defined > > by Alan Cox. Call to this macro will hold off the requestor if the resource is > > currently busy. > > > > The use of the above macro makes it possible to get rid of > > spinlocks in it8712f_wdt.c and it87_wdt.c watchdog drivers. > > This also greatly simplifies the implementation of it87_wdt.c driver. > > > > Signed-off-by: Nat Gurumoorthy<natg@google.com> > > --- > > > > diff --git a/drivers/watchdog/it8712f_wdt.c b/drivers/watchdog/it8712f_wdt.c > > index 6143f52..51bfbc0 100644 > > --- a/drivers/watchdog/it8712f_wdt.c > > +++ b/drivers/watchdog/it8712f_wdt.c > > @@ -51,7 +51,6 @@ MODULE_PARM_DESC(nowayout, "Disable watchdog shutdown on close"); > > > > static unsigned long wdt_open; > > static unsigned expect_close; > > -static spinlock_t io_lock; > > static unsigned char revision; > > > > /* Dog Food address - We use the game port address */ > > @@ -123,7 +122,11 @@ static inline void superio_select(int ldn) > > > > static inline void superio_enter(void) > > { > > - spin_lock(&io_lock); > > + /* > > + * Reserve REG and REG + 1 for exclusive access. > > + */ > > + (void) request_muxed_region(REG, 2, NAME); > > + > > You shouldn't (void) this, there is a reason you get a warning > otherwise! request_muxed_region can still fail if some other driver > has done a none muxed request_region on the same region, and in that > case you should not continue with accessing the io-ports. > Absolutely agree - even if that means adding a return code to superio_enter() and checking it from the calling code. Guenter _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-12 20:49 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Nat Gurumoorthy @ 2011-04-13 7:03 ` Wim Van Sebroeck -1 siblings, 0 replies; 30+ messages in thread From: Wim Van Sebroeck @ 2011-04-13 7:03 UTC (permalink / raw) To: Nat Gurumoorthy Cc: Jean Delvare, Guenter Roeck, Mike Waychison, lm-sensors, linux-kernel, linux-watchdog Hi Nat, > + (void) request_muxed_region(REG, 2, NAME); Why do we need to typecast this? Can't we just use + request_muxed_region(REG, 2, NAME); Kind regards, Wim. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 7:03 ` Wim Van Sebroeck 0 siblings, 0 replies; 30+ messages in thread From: Wim Van Sebroeck @ 2011-04-13 7:03 UTC (permalink / raw) To: Nat Gurumoorthy Cc: Jean Delvare, Guenter Roeck, Mike Waychison, lm-sensors, linux-kernel, linux-watchdog Hi Nat, > + (void) request_muxed_region(REG, 2, NAME); Why do we need to typecast this? Can't we just use + request_muxed_region(REG, 2, NAME); Kind regards, Wim. _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 7:03 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Wim Van Sebroeck @ 2011-04-13 8:15 ` Natarajan Gurumoorthy -1 siblings, 0 replies; 30+ messages in thread From: Natarajan Gurumoorthy @ 2011-04-13 8:15 UTC (permalink / raw) To: Wim Van Sebroeck Cc: Jean Delvare, Guenter Roeck, Mike Waychison, lm-sensors, linux-kernel, linux-watchdog Wim, Old habits die hard. I will get rid of it and ship out a new patch. Regards Nat On Wed, Apr 13, 2011 at 12:03 AM, Wim Van Sebroeck <wim@iguana.be> wrote: > Hi Nat, > >> + (void) request_muxed_region(REG, 2, NAME); > > Why do we need to typecast this? Can't we just use > + request_muxed_region(REG, 2, NAME); > > Kind regards, > Wim. > > > -- Regards Nat Gurumoorthy AB6SJ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 8:15 ` Natarajan Gurumoorthy 0 siblings, 0 replies; 30+ messages in thread From: Natarajan Gurumoorthy @ 2011-04-13 8:15 UTC (permalink / raw) To: Wim Van Sebroeck Cc: Jean Delvare, Guenter Roeck, Mike Waychison, lm-sensors, linux-kernel, linux-watchdog Wim, Old habits die hard. I will get rid of it and ship out a new patch. Regards Nat On Wed, Apr 13, 2011 at 12:03 AM, Wim Van Sebroeck <wim@iguana.be> wrote: > Hi Nat, > >> + (void) request_muxed_region(REG, 2, NAME); > > Why do we need to typecast this? Can't we just use > + request_muxed_region(REG, 2, NAME); > > Kind regards, > Wim. > > > -- Regards Nat Gurumoorthy AB6SJ _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 7:03 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Wim Van Sebroeck @ 2011-04-13 9:29 ` Alan Cox -1 siblings, 0 replies; 30+ messages in thread From: Alan Cox @ 2011-04-13 9:29 UTC (permalink / raw) To: Wim Van Sebroeck Cc: Nat Gurumoorthy, Jean Delvare, Guenter Roeck, Mike Waychison, lm-sensors, linux-kernel, linux-watchdog On Wed, 13 Apr 2011 09:03:00 +0200 Wim Van Sebroeck <wim@iguana.be> wrote: > Hi Nat, > > > + (void) request_muxed_region(REG, 2, NAME); > > Why do we need to typecast this? Can't we just use > + request_muxed_region(REG, 2, NAME); We really ought to use if () in theory the request can fail if someone has hogged the resource and not muxed it. I'm not clear what the right thing to do in that case is - given it should never happen I guess log an error and bail out but that's a rather bigger change and perhaps should be a follow up patch ? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-13 9:29 ` Alan Cox 0 siblings, 0 replies; 30+ messages in thread From: Alan Cox @ 2011-04-13 9:29 UTC (permalink / raw) To: Wim Van Sebroeck Cc: Nat Gurumoorthy, Jean Delvare, Guenter Roeck, Mike Waychison, lm-sensors, linux-kernel, linux-watchdog On Wed, 13 Apr 2011 09:03:00 +0200 Wim Van Sebroeck <wim@iguana.be> wrote: > Hi Nat, > > > + (void) request_muxed_region(REG, 2, NAME); > > Why do we need to typecast this? Can't we just use > + request_muxed_region(REG, 2, NAME); We really ought to use if () in theory the request can fail if someone has hogged the resource and not muxed it. I'm not clear what the right thing to do in that case is - given it should never happen I guess log an error and bail out but that's a rather bigger change and perhaps should be a follow up patch ? _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-13 9:29 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Alan Cox @ 2011-04-14 19:00 ` Mike Waychison -1 siblings, 0 replies; 30+ messages in thread From: Mike Waychison @ 2011-04-14 19:00 UTC (permalink / raw) To: Alan Cox Cc: Wim Van Sebroeck, Nat Gurumoorthy, Jean Delvare, Guenter Roeck, lm-sensors, linux-kernel, linux-watchdog On Wed, Apr 13, 2011 at 4:29 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Wed, 13 Apr 2011 09:03:00 +0200 > Wim Van Sebroeck <wim@iguana.be> wrote: > >> Hi Nat, >> >> > + (void) request_muxed_region(REG, 2, NAME); >> >> Why do we need to typecast this? Can't we just use >> + request_muxed_region(REG, 2, NAME); > > We really ought to use > > if () > > in theory the request can fail if someone has hogged the resource and not > muxed it. I'm not clear what the right thing to do in that case is - > given it should never happen I guess log an error and bail out but that's > a rather bigger change and perhaps should be a follow up patch ? > request_muxed_region() is sorta gross: it's essentially acting like a lock, meant to be used for short periods of time, but it can fail if someone else decides it should. Would it make more sense to have drivers that need to use the current request_muxed_region() be able to force a region into a mux-only state at driver init? That would lead to much less contorted code to handle the off-chance that the request_muxed_region() fails. Ie: Driver init: if (!request_muxed_region(base, size, DRV_NAME)) goto cleanup_driver_init_failed; Driver cleanup release_muxed_region(base, size); /* returns void */ And then within drivers: use_muxed_region(base, size); /* sleeps until region is usable -- returns void */ /* Do stuff */ unuse_muxed_region(base, size); /* returns void */ I realize the above example re-uses the 'request_muxed_region()' name, but at least this would be much more consistent with how request_region is used in other drivers. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-14 19:00 ` Mike Waychison 0 siblings, 0 replies; 30+ messages in thread From: Mike Waychison @ 2011-04-14 19:00 UTC (permalink / raw) To: Alan Cox Cc: Wim Van Sebroeck, Nat Gurumoorthy, Jean Delvare, Guenter Roeck, lm-sensors, linux-kernel, linux-watchdog On Wed, Apr 13, 2011 at 4:29 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Wed, 13 Apr 2011 09:03:00 +0200 > Wim Van Sebroeck <wim@iguana.be> wrote: > >> Hi Nat, >> >> > + (void) request_muxed_region(REG, 2, NAME); >> >> Why do we need to typecast this? Can't we just use >> + request_muxed_region(REG, 2, NAME); > > We really ought to use > > if () > > in theory the request can fail if someone has hogged the resource and not > muxed it. I'm not clear what the right thing to do in that case is - > given it should never happen I guess log an error and bail out but that's > a rather bigger change and perhaps should be a follow up patch ? > request_muxed_region() is sorta gross: it's essentially acting like a lock, meant to be used for short periods of time, but it can fail if someone else decides it should. Would it make more sense to have drivers that need to use the current request_muxed_region() be able to force a region into a mux-only state at driver init? That would lead to much less contorted code to handle the off-chance that the request_muxed_region() fails. Ie: Driver init: if (!request_muxed_region(base, size, DRV_NAME)) goto cleanup_driver_init_failed; Driver cleanup release_muxed_region(base, size); /* returns void */ And then within drivers: use_muxed_region(base, size); /* sleeps until region is usable -- returns void */ /* Do stuff */ unuse_muxed_region(base, size); /* returns void */ I realize the above example re-uses the 'request_muxed_region()' name, but at least this would be much more consistent with how request_region is used in other drivers. _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers 2011-04-14 19:00 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Mike Waychison @ 2011-04-14 20:41 ` Alan Cox -1 siblings, 0 replies; 30+ messages in thread From: Alan Cox @ 2011-04-14 20:41 UTC (permalink / raw) To: Mike Waychison Cc: Wim Van Sebroeck, Nat Gurumoorthy, Jean Delvare, Guenter Roeck, lm-sensors, linux-kernel, linux-watchdog > request_muxed_region() is sorta gross: it's essentially acting like a > lock, meant to be used for short periods of time, but it can fail if > someone else decides it should. Which is exactly how the hardware situation works. If some other driver comes along and is rude then the only safe thing to do is to moan a bit. > Would it make more sense to have drivers that need to use the current > request_muxed_region() be able to force a region into a mux-only state > at driver init? That would lead to much less contorted code to handle > the off-chance that the request_muxed_region() fails. Send patches > I realize the above example re-uses the 'request_muxed_region()' name, > but at least this would be much more consistent with how > request_region is used in other drivers. I guess you'd need some kind of r = add_muxed_resource() removed_muxed_resource(r) that inserted/removed them from the resource tree ? I think the basic resource tree code could be extended this way IFF someone does the work, if not the current code actually should work just fine. Alan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 @ 2011-04-14 20:41 ` Alan Cox 0 siblings, 0 replies; 30+ messages in thread From: Alan Cox @ 2011-04-14 20:41 UTC (permalink / raw) To: Mike Waychison Cc: Wim Van Sebroeck, Nat Gurumoorthy, Jean Delvare, Guenter Roeck, lm-sensors, linux-kernel, linux-watchdog > request_muxed_region() is sorta gross: it's essentially acting like a > lock, meant to be used for short periods of time, but it can fail if > someone else decides it should. Which is exactly how the hardware situation works. If some other driver comes along and is rude then the only safe thing to do is to moan a bit. > Would it make more sense to have drivers that need to use the current > request_muxed_region() be able to force a region into a mux-only state > at driver init? That would lead to much less contorted code to handle > the off-chance that the request_muxed_region() fails. Send patches > I realize the above example re-uses the 'request_muxed_region()' name, > but at least this would be much more consistent with how > request_region is used in other drivers. I guess you'd need some kind of r = add_muxed_resource() removed_muxed_resource(r) that inserted/removed them from the resource tree ? I think the basic resource tree code could be extended this way IFF someone does the work, if not the current code actually should work just fine. Alan _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v5 2/2] Use "request_muxed_region" in it87 hwmon drivers 2011-04-12 20:48 ` [lm-sensors] " Nat Gurumoorthy @ 2011-04-12 20:50 ` Nat Gurumoorthy -1 siblings, 0 replies; 30+ messages in thread From: Nat Gurumoorthy @ 2011-04-12 20:50 UTC (permalink / raw) To: Jean Delvare, Guenter Roeck, Wim Van Sebroeck Cc: Mike Waychison, lm-sensors, linux-kernel, linux-watchdog, Nat Gurumoorthy 02 - Chages to hwmon it87 driver to use "request_muxed_region" Serialize access to the hardware by using "request_muxed_region" macro defined by Alan Cox. Call to this macro will hold off the requestor if the resource is currently busy. Signed-off-by: Nat Gurumoorthy <natg@google.com> --- diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c index 316b648..3945569 100644 --- a/drivers/hwmon/it87.c +++ b/drivers/hwmon/it87.c @@ -111,6 +111,11 @@ superio_select(int ldn) static inline void superio_enter(void) { + /* + * Reserve REG and REG + 1 for exclusive access. + */ + (void) request_muxed_region(REG, 2, DRVNAME); + outb(0x87, REG); outb(0x01, REG); outb(0x55, REG); @@ -122,6 +127,7 @@ superio_exit(void) { outb(0x02, REG); outb(0x02, VAL); + release_region(REG, 2); } /* Logical device 4 registers */ -- 1.7.3.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [lm-sensors] [PATCH v5 2/2] Use "request_muxed_region" in it87 @ 2011-04-12 20:50 ` Nat Gurumoorthy 0 siblings, 0 replies; 30+ messages in thread From: Nat Gurumoorthy @ 2011-04-12 20:50 UTC (permalink / raw) To: Jean Delvare, Guenter Roeck, Wim Van Sebroeck Cc: Mike Waychison, lm-sensors, linux-kernel, linux-watchdog, Nat Gurumoorthy 02 - Chages to hwmon it87 driver to use "request_muxed_region" Serialize access to the hardware by using "request_muxed_region" macro defined by Alan Cox. Call to this macro will hold off the requestor if the resource is currently busy. Signed-off-by: Nat Gurumoorthy <natg@google.com> --- diff --git a/drivers/hwmon/it87.c b/drivers/hwmon/it87.c index 316b648..3945569 100644 --- a/drivers/hwmon/it87.c +++ b/drivers/hwmon/it87.c @@ -111,6 +111,11 @@ superio_select(int ldn) static inline void superio_enter(void) { + /* + * Reserve REG and REG + 1 for exclusive access. + */ + (void) request_muxed_region(REG, 2, DRVNAME); + outb(0x87, REG); outb(0x01, REG); outb(0x55, REG); @@ -122,6 +127,7 @@ superio_exit(void) { outb(0x02, REG); outb(0x02, VAL); + release_region(REG, 2); } /* Logical device 4 registers */ -- 1.7.3.1 _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply related [flat|nested] 30+ messages in thread
end of thread, other threads:[~2011-04-14 20:41 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-12 20:48 [PATCH v5 0/2] Make all it87 drivers SMP safe Nat Gurumoorthy 2011-04-12 20:48 ` [lm-sensors] " Nat Gurumoorthy 2011-04-12 20:49 ` [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Nat Gurumoorthy 2011-04-12 20:49 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Nat Gurumoorthy 2011-04-13 6:50 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Hans de Goede 2011-04-13 6:50 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Hans de Goede 2011-04-13 8:05 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Natarajan Gurumoorthy 2011-04-13 8:05 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Natarajan Gurumoorthy 2011-04-13 8:34 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Jean Delvare 2011-04-13 8:34 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Jean Delvare 2011-04-13 17:59 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Natarajan Gurumoorthy 2011-04-13 17:59 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Natarajan Gurumoorthy 2011-04-13 20:34 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Jean Delvare 2011-04-13 20:34 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Jean Delvare 2011-04-14 9:25 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Alan Cox 2011-04-14 9:25 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Alan Cox 2011-04-14 17:58 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Guenter Roeck 2011-04-14 17:58 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Guenter Roeck 2011-04-13 7:03 ` [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Wim Van Sebroeck 2011-04-13 7:03 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Wim Van Sebroeck 2011-04-13 8:15 ` [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Natarajan Gurumoorthy 2011-04-13 8:15 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Natarajan Gurumoorthy 2011-04-13 9:29 ` [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Alan Cox 2011-04-13 9:29 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Alan Cox 2011-04-14 19:00 ` [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Mike Waychison 2011-04-14 19:00 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Mike Waychison 2011-04-14 20:41 ` [PATCH v5 1/2] Use "request_muxed_region" in it87 watchdog drivers Alan Cox 2011-04-14 20:41 ` [lm-sensors] [PATCH v5 1/2] Use "request_muxed_region" in it87 Alan Cox 2011-04-12 20:50 ` [PATCH v5 2/2] Use "request_muxed_region" in it87 hwmon drivers Nat Gurumoorthy 2011-04-12 20:50 ` [lm-sensors] [PATCH v5 2/2] Use "request_muxed_region" in it87 Nat Gurumoorthy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.