1. 14 Apr, 2004 1 commit
  2. 12 Apr, 2004 7 commits
    • Jean Delvare's avatar
      [PATCH] I2C: No reset not limit init in via686a · 6088582c
      Jean Delvare authored
      The following patch removes limits initialization in the via686a driver.
      It was decided some times ago that this belongs to user-space, not
      kernel. See the thread here:
      http://archives.andrew.net.au/lm-sensors/msg06134.html
      
      It also prevents the sensor chip from being savagely reset at load time.
      This too follows a decision taken long ago that drivers should do as
      little as possible in their init procedure. See the thread here:
      http://archives.andrew.net.au/lm-sensors/msg04593.html
      
      This should make the driver smaller, safer and faster to load. The same
      was done to our 2.4/CVS version of the driver 5 months ago and it seems
      to work just fine.
      6088582c
    • Jean Delvare's avatar
      [PATCH] I2C: Fix voltage rounding in lm80 · 02dd2c14
      Jean Delvare authored
      This one line patch fixes voltage rounding in the lm80 chip driver.
      02dd2c14
    • Mark M. Hoffman's avatar
      [PATCH] I2C: fix asb100 bug · 998f14c4
      Mark M. Hoffman authored
      Hi nymisi, Greg:
      
      * Nyeste Mihály <nymisi@freemail.hu> [2004-01-27 16:02:04 +0100]:
      > Hi!
      >
      > I reported a bug of asb100 chip at:
      > http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1539
      >
      > The reply was the follow:
      >
      > "Is there a BIOS option you can disable, e.g. Asus "COP",
      > "QFAN", or some such?  My guess is that the BIOS is
      > somehow interfering with the asb100 driver.  Otherwise
      > I don´t know how this could happen.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      
      Yeah, I wrote that.
      
      "You do that, you go to the box, you know.  Two minutes by
      yourself, and you feel shame, you know." - Denis the goalie
      
      Greg, please apply this fix (vs. 2.6.5):
      998f14c4
    • Jean Delvare's avatar
    • Jean Delvare's avatar
      [PATCH] I2C: pwm support in w83781d.c · a30b044a
      Jean Delvare authored
      Here is a general pwm support cleanup patch for the w83781d chip driver.
      Featuring:
      
      * Don't pretend that we handle PWM on AS99127F chips. We don't know how
      it works, and one of the register we are accessing for now is clearly
      not a PWM register, and changing its value usually breaks temperature
      readings.
      
      * Discard irrelevant comments.
      
      * Rewrite show_pwmenable_reg. It was obviously taken from the 2.4
      driver, with unneeded tests and the code was much too complicated
      anyway. And now we handle errors correctly.
      
      * Initialize pwm_enable at load time. So far it was done conditionally
      (if init=1) while it should always be done. And pwm2_enable wasn't read
      from the chip, while it should.
      
      I could test that my AS99127F doesn't expose pwm files through ssysfs
      anymore. Which means that I couldn't test the rest of the pwm changes,
      unfortunately.
      
      I've applied similar changes to our 2.4/CVS repository.
      a30b044a
    • Jean Delvare's avatar
      [PATCH] I2C: Error paths in it87 and via686a drivers · ee23f4b7
      Jean Delvare authored
      Here comes the patch that fixes error paths in the it87 and via686a
      detection functions. The it87 part also adds missing error values.
      ee23f4b7
    • Jean Delvare's avatar
      [PATCH] I2C: Rework memory allocation in i2c chip drivers · 2dbac597
      Jean Delvare authored
      Additional remarks:
      
      1* This patch also removes an unused struct member in via686a and fixes
      an error message in ds1621.
      
      2* I discovered error path problems in it87 and via686a detection
      functions. For the it87, I think that this patch makes it even more
      broken. I will fix both drivers in a later patch (really soon).
      2dbac597
  3. 09 Apr, 2004 4 commits
  4. 08 Apr, 2004 3 commits
  5. 02 Apr, 2004 4 commits
  6. 30 Mar, 2004 5 commits
    • Jean Delvare's avatar
      [PATCH] I2C: Discard pointless comment in via686a · ff74142e
      Jean Delvare authored
      The simple patch below discards a comment in via686a referencing a file
      that doesn't belong to the Linux tree. Now that I tell people not to do
      that in my porting guide, we better follow our own advice.
      ff74142e
    • Jean Delvare's avatar
      [PATCH] I2C: Incorrect memset in eeprom.c · af109398
      Jean Delvare authored
      Quoting Ralf Roesch:
      
      > currently I'm only working with Linux MIPS 2.4 kernel,
      > so it would be nice if you could forward the patch for 2.6.
      
      OK, so here we are. Greg, this is the port to 2.6 of Ralf patch that
      fixes an incorrect memset while initializing the eeprom driver. Please
      apply.
      af109398
    • Jean Delvare's avatar
      [PATCH] I2C: i2c documentation update (2/2) · a4a5e7cf
      Jean Delvare authored
      Here is a patch to Documentation/i2c/sysfs-interface. This is mostly my
      intent to make the document more readable. There are also a few
      incorrectnesses fixed, and some comments added.
      a4a5e7cf
    • Jean Delvare's avatar
      [PATCH] I2C: i2c documentation update (1/2) · 92e54f42
      Jean Delvare authored
      Here is an update to my 2.4 to 2.6 i2c client porting guide. The changes
      were inspired by the feedback I got with the drivers that have been
      ported so far.
      92e54f42
    • Jean Delvare's avatar
      [PATCH] I2C: Prevent misdetections in adm1021 driver · 9f3e7af6
      Jean Delvare authored
      Yet another patch for the adm1021 chip driver. I refined the detection
      code a bit in order to prevent chip misdetection. Some chips handled
      by the adm1021 driver are hard to detect and identify (LM84 and
      MAX1617) so we tend to accept any chip it the valid I2C address range
      as one of these. It has caused much, much trouble already. See these
      threads for example:
      
      http://archives.andrew.net.au/lm-sensors/msg04448.html
      http://archives.andrew.net.au/lm-sensors/msg04624.html
      http://archives.andrew.net.au/lm-sensors/msg05560.html
      http://archives.andrew.net.au/lm-sensors/msg05871.html
      http://archives.andrew.net.au/lm-sensors/msg06754.html
      http://archives.andrew.net.au/lm-sensors/msg07181.html
      
      And this ticket:
      
      http://www2.lm-sensors.nu/~lm78/readticket.cgi?ticket=1434
      
      So I thought it would be good to prevent this kind of problems if
      possible, and read the 8 datasheets again in search for ways to refine
      the detection method.
      
      I changed it in sensors-detect already, and had positive feedback from
      one user. I will also backport the changes to the driver to the 2.4
      version we have in CVS.
      
      What the patch does:
      
      * Use unused bits of two more registers (configuration and conversion
      rate) to reduce misdetections.
      
      * Return with -ENODEV if the detection fails.
      
      * Change the order in which we try to identify the chips. We better
      finish with the LM84 and the MAX1617, in this order, because they are
      harder to identify and are more likely to result in false positives.
      
      * Refine LM84 detection. The LM84 has less features than the other
      chips(chip cannot be stopped, conversion rate cannot be set, no low
      limits) so it has extra unused bits.
      
      * Do not intialize the chip if it was detected as an LM84. This one
      cannot be stopped so why would we try to start it again? And as said
      right before, conversion rate isn't changeable either.
      
      Note that I couldn't test the changes on any supported chip since I
      don't own any. Still I believe that they should be applied, since the
      current code already broke one system and seriously harmed several
      others. I believe it's not critical if it turns out that we reject
      valid chips (which shouldn't happen if the datasheets are correct,
      anyway). People will simply let us know and we'll be less restrictive.
      In the meantime they can force the driver. That said, testers are
      welcome, as usual.
      9f3e7af6
  7. 26 Mar, 2004 2 commits
    • Jean Delvare's avatar
      [PATCH] I2C: Setting w83627hf fan_div preserves fan_min · 742647e9
      Jean Delvare authored
      Here is a patch that updates the w83627hf driver in the exact same way I
      did recently for the w83781d driver. There were two problems:
      1* Fan divisor storing code was ugly, badly ripped from the 2.4 w83627hf
         driver and/or the 2.6 w83781d driver.
      2* Setting fan divisors wouldn't preserve fan mins.
      
      Exactly the same as w83781d:
      http://archives.andrew.net.au/lm-sensors/msg06952.html
      http://archives.andrew.net.au/lm-sensors/msg07008.html
      
      No surprise since the w83627hf driver is a fork of the w83781d driver.
      
      Since the two drivers are strongly similar, I took the code directly
      from the updated w83781d driver. I cannot test the w83627hf driver
      (testers welcome BTW) but this makes me feel confident that the code is
      correct.
      
      To make it clear, this single patch is the w83627f equivalent of the
      three patches I submitted for the w83781d:
      * Cleanup
      * Refactoring
      * Setting fan_div preserves fan_min
      All in one (much better looking BTW).
      742647e9
    • Jean Delvare's avatar
      [PATCH] I2C: adm1021 (probably) does something VERY,VERY BAD · 4b65ed3a
      Jean Delvare authored
      Quoting myself:
      
      > 3* Drop adm1021's limit init. This was already done in the 2.4 driver
      > and should have been done in 2.6 as well.
      
      Here is a patch that does that. It also prevents bit 7 (and unused bits)
      of configuration register from being reset, as was discussed before:
        http://archives.andrew.net.au/lm-sensors/msg04593.html
      That second part needs to be backported to the 2.4 driver, and I will do
      so.
      
      Additionally, we get rid of a useless label.
      
      The patch is untested (I don't own any supported chip) but quite
      straightforward IMHO.
      4b65ed3a
  8. 25 Mar, 2004 2 commits
    • Jean Delvare's avatar
      [PATCH] I2C: initialize fan_mins in w83781d, asb100 and lm78 · 7b218f51
      Jean Delvare authored
      Quoting myself:
      
      > While testing, I found a corner case that isn't handled properly. It
      > doesn't seem to be handled by the lm78 and the asb100 either. Setting
      > fanN_div before ever reading from the chip or setting fanN_min will
      > make use of fanN_min while it was never initialized.
      
      The following patch addesses the issue. Tested to work on my AS99127F
      rev.1 (which means that only the changes to the w83781d driver were
      actually tested). Testers welcome.
      7b218f51
    • Jean Delvare's avatar
      [PATCH] I2C: Discard out-of-date comment in adm1021 driver · b3da4be8
      Jean Delvare authored
      This simple patch discards an out-of-date comment in the adm1021 driver.
      I've done the same in our CVS repository where many more drivers were
      affected.
      
      I agree it's not very important, but I prefer it to be done before any
      driver with the error is used as a base to port a new driver, and the
      misinformation spreads.
      b3da4be8
  9. 19 Mar, 2004 12 commits
    • Aurelien Jarno's avatar
      [PATCH] I2C: add new chip driver: pcf8574 · c395ba51
      Aurelien Jarno authored
      Please find below a patch against kernel 2.6.5-rc1 to add the pcf8574
      driver (an I/O expander for the I2C bus). I have ported it from the 2.4
      version, and it includes some fixes and simplifications.
      
      It has been reviewed by Jean Delvare on IRC.
      c395ba51
    • Jean Delvare's avatar
      [PATCH] I2C: w83781d fan_div code refactoring · 004215f8
      Jean Delvare authored
      Quoting myself:
      
      > This tends to increase the size of the three set_store_regs_fan_div
      > functions, and I am considering refactoring them at some point. Later
      > though.
      
      Here is the promised refactoring. Tested on my AS99127F rev.1, seems to
      work. As for the previous patch, there is a part that I cannot test with
      the AS99127F, so additional testing is welcome.
      
      I agree this makes the code slightly less readable, but this saves 60
      lines of code (1754 bytes, around 3% of the driver total), and is
      actually far less complex that I first feared.
      004215f8
    • Linus Torvalds's avatar
      Merge http://linux-sound.bkbits.net/linux-sound · 27cd7e0f
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      27cd7e0f
    • Linus Torvalds's avatar
      Merge bk://gkernel.bkbits.net/net-drivers-2.6 · c4620fd6
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      c4620fd6
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/net-2.6 · c5d40033
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      c5d40033
    • Rusty Russell's avatar
      [PATCH] Hotplug CPUs: Remove CPU_OFFLINE Notifier · e7830385
      Rusty Russell authored
      We no longer have a CPU_OFFLINE notifier: we freeze the machine and
      kill the CPU atomically.  Remove it.
      e7830385
    • Rusty Russell's avatar
      [PATCH] Hotplug CPUs: Other CPU_DEAD Notifiers · 279ce7b2
      Rusty Russell authored
      Various files keep per-cpu caches which need to be freed/moved when a
      CPU goes down.  All under CONFIG_HOTPLUG_CPU ifdefs.
      
      scsi.c: drain dead cpu's scsi_done_q onto this cpu.
      
      buffer.c: brelse the bh_lrus queue for dead cpu.
      
      timer.c: migrate timers from dead cpu, being careful of lock order vs
      	__mod_timer.
      
      radix_tree.c: free dead cpu's radix_tree_preloads
      
      page_alloc.c: empty dead cpu's nr_pagecache_local into nr_pagecache, and
      	free pages on cpu's local cache.
      
      slab.c: stop reap_timer for dead cpu, adjust each cache's free limit, and
      	free each slab cache's per-cpu block.
      
      swap.c: drain dead cpu's lru_add_pvecs into ours, and empty its committed_space
      	counter into global counter.
      
      dev.c: drain device queues from dead cpu into this one.
      
      flow.c: drain dead cpu's flow cache.
      279ce7b2
    • Rusty Russell's avatar
      [PATCH] Hotplug CPUs: Kswapd Changes · 9bd3badf
      Rusty Russell authored
      Keep track of kswapds: it's OK that they get moved off a node when the
      last CPU goes down, but when a CPU comes back, we should try to move
      the kswapd back onto its node.
      9bd3badf
    • Rusty Russell's avatar
      [PATCH] Hotplug CPUs: Workqueue Changes · 6bcaa29d
      Rusty Russell authored
      Workqueues need to bring up/destroy the per-cpu thread on cpu up/down.
      
      1) Add a global list of workqueues, and keep the name in the structure
         (to name the newly created thread).
      
      2) Remove BUG_ON in run_workqueue, since thread is dragged off CPU when
         it goes down.
      
      3) Lock out cpu up/down in flush_workqueue, create_workqueue and
         destroy_workqueue.
      
      4) Add notifier to add/destroy workqueue threads, and take over work.
      6bcaa29d
    • Rusty Russell's avatar
      [PATCH] Hotplug CPUs: Make ksoftirqd Handle CPU Going Down · 010b27dc
      Rusty Russell authored
      Change ksoftirqd not to assume it's on the CPU: when a cpu goes down,
      it will be rudely dragged off.  Since do_softirq() uses
      smp_processor_id(), it's easiest to disable preemption, check that the
      cpu is still up, then call do_softirq().
      
      If the cpu is actually offline, wait for the notifier, which kills us.
      
      Take over tasklets from dead cpu in the notifier.
      
      Clean up redundant double assignment in CPU_UP callback.
      010b27dc
    • Rusty Russell's avatar
      [PATCH] Hotplug CPUs: Read Copy Update Changes · 211b2fce
      Rusty Russell authored
      Add hook for RCU to handle jobs on dead cpu.  Requires new
      tasklet_kill_immediate for RCU to clean up its tasklet (which might
      have been about to run, so tasklet_kill won't work).
      211b2fce
    • Rusty Russell's avatar
      [PATCH] Hotplug CPUs: Make Migration Thread Handle CPUs Going · eac9256c
      Rusty Russell authored
      Change the migration thread to directly use its cpu arg, rather than
      smp_processor_id(): if a cpu goes up then down rapidly, it can be on
      the wrong cpu just before it is stopped.
      
      Add code to stop the migration thread on CPU_DEAD and CPU_UP_CANCELED.
      
      Remove the (bogus) priority of the notifier.
      eac9256c