1. 13 Jul, 2022 15 commits
    • Guenter Roeck's avatar
      hwmon: (lm90) Use single flag to indicate extended temperature support · b977ed27
      Guenter Roeck authored
      Since temperature conversion functions are now unified, there is no need
      to keep "the chip supports a configurable extended temperature range" and
      "the chip has extended temperature range enabled" flags separate.
      Use a single flag instead to reflect both.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      b977ed27
    • Guenter Roeck's avatar
      hwmon: (lm90) Support multiple temperature resolutions · a8ddcc57
      Guenter Roeck authored
      While most LM90 compatible chips support a temperature sensor resolution
      of 11 bit, this is not the case for all chips. ADT7461 only supports a
      resolution of 10 bit, and TMP451/TMP461 support a resolution of 12 bit.
      
      Add support for various temperature sensor resolutions. To do this,
      model all temperature sensors as 16 bit sensors, and use unified
      temperature conversion functions which take the sensor resolution
      as parameter.
      
      While enhancing functionality, this has the positive side effect of
      reducing code size by about 5%.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      a8ddcc57
    • Guenter Roeck's avatar
      hwmon: (lm90) Only re-read registers if volatile · 8f19501d
      Guenter Roeck authored
      When reading 16-bit volatile registers, the code uses a trick to
      determine if a temperature is consistent: It reads the high part
      of the register twice. If the values are the same, the code assumes
      that the reading is consistent. If the value differs, the code
      re-reads the second register as well and assumes that it now has
      correct values.
      
      This is only necessary for volatile registers. Add a parameter to
      lm90_read16() to indicate if the register is volatile to avoid the
      extra overhead for non-volatile registers.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      8f19501d
    • Guenter Roeck's avatar
      hwmon: (lm90) Add support for unsigned and signed temperatures · b2644494
      Guenter Roeck authored
      ADT7461 and TMP451 temperature sensors support extended temperature ranges.
      If standard temperature range is selected, the temperature range is
      unsigned and limited to 0 .. 127 degrees C. For TMP461, the standard
      temperature range is -128000 ... 127000 degrees C. Distinguish between
      the two chips by introducing a feature flag indicating if the standard
      temperature range is signed or unsigned. Use the same flag for MAX6646/
      MAX6647 as well since those chips also support unsigned temperatures.
      
      Note that while the datasheet for ADT7461 suggests that the default
      temperature range is unsigned, tests with a real chip suggest that this
      is not the case: If the temperature offset is set to a value << 0,
      the temperature register does report negative values.
      
      Tests with real chips show that MAX6680/MAX6681 and SA56004 report
      temperatures of 128 degrees C and higher as negative temperatures.
      Add respective comments to the code.
      
      Also use clamp_val() and DIV_ROUND_CLOSEST where appropriate in
      calculations.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      b2644494
    • Guenter Roeck's avatar
      hwmon: (lm90) Enable full PEC support for ADT7461A · d70fa73d
      Guenter Roeck authored
      Experiments show that ADT7461A and NCT1008 support PEC, even though it is
      not documented. Enable support for it in the driver. Since ADT7461 only
      supports partial PEC, this means that the configuration for ADT7461A
      needs to be separated from ADT7461.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      d70fa73d
    • Guenter Roeck's avatar
      hwmon: (lm90) Add partial PEC support for ADT7461 · 425f5b5d
      Guenter Roeck authored
      Revision 0 of the ADT7461 datasheet suggests that the chip supports PEC
      (packet error checking). This information is gone in later versions of the
      datasheet. Experiments show that PEC support on ADT7461 is similar to PEC
      support in ADM1032, ie it is only supported for read operations. Add
      support for it to the driver.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      425f5b5d
    • Guenter Roeck's avatar
      hwmon: (lm90) Improve PEC support · 3b0982ff
      Guenter Roeck authored
      PEC (packet error checking) support for ADM1032 is currently only enabled
      if the chip was auto-detected, but not if a chip is instantiated
      explicitly. Always enable PEC support by introducing a chip feature flag
      indicating partial PEC support. Also, for consistency, disable PEC support
      by default to match existing functionality if the chip was not auto-
      detected.
      
      At the same time, introduce generic support for PEC with a separate feature
      flag. This will be used when support for chips with full PEC functionality
      is added.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      3b0982ff
    • Guenter Roeck's avatar
      hwmon: (lm90) Stop using R_/W_ register prefix · f68480cc
      Guenter Roeck authored
      The register write address either matches the read address, or it is the
      read address plus 6. Simplify the code and resolve the write address
      programmatically instead of having two defines for each register.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      f68480cc
    • Guenter Roeck's avatar
      hwmon: (lm90) Move status register bit shifts to compile time · ca7b9b14
      Guenter Roeck authored
      Handling bit shifts necessary to extract status bits during compile time
      reduces code and data size by almost 5% when building for x86_64.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      ca7b9b14
    • Guenter Roeck's avatar
      hwmon: (lm90) Use BIT macro · ddf2a609
      Guenter Roeck authored
      Use BIT macro instead of shift operation to improve readability.
      No functional change.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      ddf2a609
    • Guenter Roeck's avatar
      hwmon: (lm90) Reorder chip enumeration to be in alphabetical order · ff8f0a65
      Guenter Roeck authored
      Reorder chip enumeration in alphabetical order to make it easier to
      see which chips are supported, and to clarify where to add support
      new chip types. No functional change.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      ff8f0a65
    • Guenter Roeck's avatar
      hwmon: (lm90) Reorder include files in alphabetical order · 479f21d4
      Guenter Roeck authored
      Reorder include files in alphabetical order to reduce the chance of
      duplicates and to make it clear where new include files should be
      added. Drop the unnecessary include of linux/sysfs.h. Include
      linux/device.h instead because that is what is actually used.
      
      No functional change.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      479f21d4
    • Guenter Roeck's avatar
      hwmon: (lm90) Rework alarm/status handling · f6d07751
      Guenter Roeck authored
      Many chips supported by this driver clear status registers after it
      is read and update it in the next measurement cycle. Normally this falls
      under the radar because all registers are only read once per measurement
      cycle. However, there is an exception: Status registers are always read
      during interrupt and laert handling. This can result in invalid status
      reports if userspace reads an alarm attribute immediately afterwards.
      
      Rework alarm/status handling by keeping a shadow register with 'current'
      alarms, and by ensuring that the register is either only updated once per
      measurement cycle or not cleared.
      
      A second problem is related to alert handling: Alert handling is disabled
      for chips with broken alert after an alert was reported, but only
      re-enabled if attributes are read by the user. This means that alert
      conditions may appear and disappear unnoticed. Remedy the situation
      by introducing a worker to periodically read the status register(s) while
      alert handling is disabled, and re-enable alerts after the alert condition
      clears.
      
      Yet another problem is that sysfs and udev events are currently only
      reported to userspace if an alarm is raised, but not if an alarm condition
      clears. Use the new worker to detect that situation and also generate
      sysfs and udev events in that case.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      f6d07751
    • Guenter Roeck's avatar
      hwmon: (lm90) Generate sysfs and udev events for all alarms · eaf87c00
      Guenter Roeck authored
      So far the driver only generated sysfs and udev events for minimum and
      maximum alarms. Also generate events for critical and emergency alarms.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      eaf87c00
    • Guenter Roeck's avatar
      hwmon: (pmbus) Move pec attribute to I2C device · f30ce040
      Guenter Roeck authored
      Enabling and disabling PEC for PMBus devices is currently only supported
      with a debugfs attribute, which requires debugfs to be enabled and is
      thus less than perfect. Take the lm90 driver as example and add a 'pec'
      attribute to the I2C device if both the I2C adapter and the PMBus device
      support it. Remove the now obsolete 'pec' attribute from debugfs.
      
      Cc: Andrew Jeffery <andrew@aj.id.au>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      f30ce040
  2. 03 Jul, 2022 4 commits
    • Linus Torvalds's avatar
      Linux 5.19-rc5 · 88084a3d
      Linus Torvalds authored
      88084a3d
    • Linus Torvalds's avatar
      lockref: remove unused 'lockref_get_or_lock()' function · b8d5109f
      Linus Torvalds authored
      Looking at the conditional lock acquire functions in the kernel due to
      the new sparse support (see commit 4a557a5d "sparse: introduce
      conditional lock acquire function attribute"), it became obvious that
      the lockref code has a couple of them, but they don't match the usual
      naming convention for the other ones, and their return value logic is
      also reversed.
      
      In the other very similar places, the naming pattern is '*_and_lock()'
      (eg 'atomic_put_and_lock()' and 'refcount_dec_and_lock()'), and the
      function returns true when the lock is taken.
      
      The lockref code is superficially very similar to the refcount code,
      only with the special "atomic wrt the embedded lock" semantics.  But
      instead of the '*_and_lock()' naming it uses '*_or_lock()'.
      
      And instead of returning true in case it took the lock, it returns true
      if it *didn't* take the lock.
      
      Now, arguably the reflock code is quite logical: it really is a "either
      decrement _or_ lock" kind of situation - and the return value is about
      whether the operation succeeded without any special care needed.
      
      So despite the similarities, the differences do make some sense, and
      maybe it's not worth trying to unify the different conditional locking
      primitives in this area.
      
      But while looking at this all, it did become obvious that the
      'lockref_get_or_lock()' function hasn't actually had any users for
      almost a decade.
      
      The only user it ever had was the shortlived 'd_rcu_to_refcount()'
      function, and it got removed and replaced with 'lockref_get_not_dead()'
      back in 2013 in commits 0d98439e ("vfs: use lockred 'dead' flag to
      mark unrecoverably dead dentries") and e5c832d5 ("vfs: fix dentry
      RCU to refcounting possibly sleeping dput()")
      
      In fact, that single use was removed less than a week after the whole
      function was introduced in commit b3abd802 ("lockref: add
      'lockref_get_or_lock() helper") so this function has been around for a
      decade, but only had a user for six days.
      
      Let's just put this mis-designed and unused function out of its misery.
      
      We can think about the naming and semantic oddities of the remaining
      'lockref_put_or_lock()' later, but at least that function has users.
      
      And while the naming is different and the return value doesn't match,
      that function matches the whole '{atomic,refcount}_dec_and_test()'
      pattern much better (ie the magic happens when the count goes down to
      zero, not when it is incremented from zero).
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b8d5109f
    • Linus Torvalds's avatar
      sparse: introduce conditional lock acquire function attribute · 4a557a5d
      Linus Torvalds authored
      The kernel tends to try to avoid conditional locking semantics because
      it makes it harder to think about and statically check locking rules,
      but we do have a few fundamental locking primitives that take locks
      conditionally - most obviously the 'trylock' functions.
      
      That has always been a problem for 'sparse' checking for locking
      imbalance, and we've had a special '__cond_lock()' macro that we've used
      to let sparse know how the locking works:
      
          # define __cond_lock(x,c)        ((c) ? ({ __acquire(x); 1; }) : 0)
      
      so that you can then use this to tell sparse that (for example) the
      spinlock trylock macro ends up acquiring the lock when it succeeds, but
      not when it fails:
      
          #define raw_spin_trylock(lock)  __cond_lock(lock, _raw_spin_trylock(lock))
      
      and then sparse can follow along the locking rules when you have code like
      
              if (!spin_trylock(&dentry->d_lock))
                      return LRU_SKIP;
      	.. sparse sees that the lock is held here..
              spin_unlock(&dentry->d_lock);
      
      and sparse ends up happy about the lock contexts.
      
      However, this '__cond_lock()' use does result in very ugly header files,
      and requires you to basically wrap the real function with that macro
      that uses '__cond_lock'.  Which has made PeterZ NAK things that try to
      fix sparse warnings over the years [1].
      
      To solve this, there is now a very experimental patch to sparse that
      basically does the exact same thing as '__cond_lock()' did, but using a
      function attribute instead.  That seems to make PeterZ happy [2].
      
      Note that this does not replace existing use of '__cond_lock()', but
      only exposes the new proposed attribute and uses it for the previously
      unannotated 'refcount_dec_and_lock()' family of functions.
      
      For existing sparse installations, this will make no difference (a
      negative output context was ignored), but if you have the experimental
      sparse patch it will make sparse now understand code that uses those
      functions, the same way '__cond_lock()' makes sparse understand the very
      similar 'atomic_dec_and_lock()' uses that have the old '__cond_lock()'
      annotations.
      
      Note that in some cases this will silence existing context imbalance
      warnings.  But in other cases it may end up exposing new sparse warnings
      for code that sparse just didn't see the locking for at all before.
      
      This is a trial, in other words.  I'd expect that if it ends up being
      successful, and new sparse releases end up having this new attribute,
      we'll migrate the old-style '__cond_lock()' users to use the new-style
      '__cond_acquires' function attribute.
      
      The actual experimental sparse patch was posted in [3].
      
      Link: https://lore.kernel.org/all/20130930134434.GC12926@twins.programming.kicks-ass.net/ [1]
      Link: https://lore.kernel.org/all/Yr60tWxN4P568x3W@worktop.programming.kicks-ass.net/ [2]
      Link: https://lore.kernel.org/all/CAHk-=wjZfO9hGqJ2_hGQG3U_XzSh9_XaXze=HgPdvJbgrvASfA@mail.gmail.com/ [3]
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Alexander Aring <aahringo@redhat.com>
      Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4a557a5d
    • Linus Torvalds's avatar
      Merge tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 20855e4c
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
       "This fixes some stalling problems and corrects the last of the
        problems (I hope) observed during testing of the new atomic xattr
        update feature.
      
         - Fix statfs blocking on background inode gc workers
      
         - Fix some broken inode lock assertion code
      
         - Fix xattr leaf buffer leaks when cancelling a deferred xattr update
           operation
      
         - Clean up xattr recovery to make it easier to understand.
      
         - Fix xattr leaf block verifiers tripping over empty blocks.
      
         - Remove complicated and error prone xattr leaf block bholding mess.
      
         - Fix a bug where an rt extent crossing EOF was treated as "posteof"
           blocks and cleaned unnecessarily.
      
         - Fix a UAF when log shutdown races with unmount"
      
      * tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: prevent a UAF when log IO errors race with unmount
        xfs: dont treat rt extents beyond EOF as eofblocks to be cleared
        xfs: don't hold xattr leaf buffers across transaction rolls
        xfs: empty xattr leaf header blocks are not corruption
        xfs: clean up the end of xfs_attri_item_recover
        xfs: always free xattri_leaf_bp when cancelling a deferred op
        xfs: use invalidate_lock to check the state of mmap_lock
        xfs: factor out the common lock flags assert
        xfs: introduce xfs_inodegc_push()
        xfs: bound maximum wait time for inodegc work
      20855e4c
  3. 02 Jul, 2022 8 commits
  4. 01 Jul, 2022 13 commits