1. 19 Apr, 2020 10 commits
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux · 86cc3398
      Linus Torvalds authored
      Pull clk fixes from Stephen Boyd:
       "Two build fixes for a couple clk drivers and a fix for the Unisoc
        serial clk where we want to keep it on for earlycon"
      
      * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
        clk: sprd: don't gate uart console clock
        clk: mmp2: fix link error without mmp2
        clk: asm9260: fix __clk_hw_register_fixed_rate_with_accuracy typo
      86cc3398
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 0fe5f9ca
      Linus Torvalds authored
      Pull x86 and objtool fixes from Thomas Gleixner:
       "A set of fixes for x86 and objtool:
      
        objtool:
      
         - Ignore the double UD2 which is emitted in BUG() when
           CONFIG_UBSAN_TRAP is enabled.
      
         - Support clang non-section symbols in objtool ORC dump
      
         - Fix switch table detection in .text.unlikely
      
         - Make the BP scratch register warning more robust.
      
        x86:
      
         - Increase microcode maximum patch size for AMD to cope with new CPUs
           which have a larger patch size.
      
         - Fix a crash in the resource control filesystem when the removal of
           the default resource group is attempted.
      
         - Preserve Code and Data Prioritization enabled state accross CPU
           hotplug.
      
         - Update split lock cpu matching to use the new X86_MATCH macros.
      
         - Change the split lock enumeration as Intel finaly decided that the
           IA32_CORE_CAPABILITIES bits are not architectural contrary to what
           the SDM claims. !@#%$^!
      
         - Add Tremont CPU models to the split lock detection cpu match.
      
         - Add a missing static attribute to make sparse happy"
      
      * tag 'x86-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/split_lock: Add Tremont family CPU models
        x86/split_lock: Bits in IA32_CORE_CAPABILITIES are not architectural
        x86/resctrl: Preserve CDP enable over CPU hotplug
        x86/resctrl: Fix invalid attempt at removing the default resource group
        x86/split_lock: Update to use X86_MATCH_INTEL_FAM6_MODEL()
        x86/umip: Make umip_insns static
        x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE
        objtool: Make BP scratch register warning more robust
        objtool: Fix switch table detection in .text.unlikely
        objtool: Support Clang non-section symbols in ORC generation
        objtool: Support Clang non-section symbols in ORC dump
        objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings
      0fe5f9ca
    • Linus Torvalds's avatar
      Merge tag 'timers-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 3e0dea57
      Linus Torvalds authored
      Pull time namespace fix from Thomas Gleixner:
       "An update for the proc interface of time namespaces: Use symbolic
        names instead of clockid numbers. The usability nuisance of numbers
        was noticed by Michael when polishing the man page"
      
      * tag 'timers-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        proc, time/namespace: Show clock symbolic names in /proc/pid/timens_offsets
      3e0dea57
    • Linus Torvalds's avatar
      Merge tag 'perf-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · b7374586
      Linus Torvalds authored
      Pull perf tooling fixes and updates from Thomas Gleixner:
      
       - Fix the header line of perf stat output for '--metric-only --per-socket'
      
       - Fix the python build with clang
      
       - The usual tools UAPI header synchronization
      
      * tag 'perf-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        tools headers: Synchronize linux/bits.h with the kernel sources
        tools headers: Adopt verbatim copy of compiletime_assert() from kernel sources
        tools headers: Update x86's syscall_64.tbl with the kernel sources
        tools headers UAPI: Sync drm/i915_drm.h with the kernel sources
        tools headers UAPI: Update tools's copy of drm.h headers
        tools headers kvm: Sync linux/kvm.h with the kernel sources
        tools headers UAPI: Sync linux/fscrypt.h with the kernel sources
        tools include UAPI: Sync linux/vhost.h with the kernel sources
        tools arch x86: Sync asm/cpufeatures.h with the kernel sources
        tools headers UAPI: Sync linux/mman.h with the kernel
        tools headers UAPI: Sync sched.h with the kernel
        tools headers: Update linux/vdso.h and grab a copy of vdso/const.h
        perf stat: Fix no metric header if --per-socket and --metric-only set
        perf python: Check if clang supports -fno-semantic-interposition
        tools arch x86: Sync the msr-index.h copy with the kernel sources
      b7374586
    • Linus Torvalds's avatar
      Merge tag 'irq-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 80ade29e
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A set of fixes/updates for the interrupt subsystem:
      
         - Remove setup_irq() and remove_irq(). All users have been converted
           so remove them before new users surface.
      
         - A set of bugfixes for various interrupt chip drivers
      
         - Add a few missing static attributes to address sparse warnings"
      
      * tag 'irq-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() static
        irqchip/irq-mvebu-icu: Make legacy_bindings static
        irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock order
        irqchip/sifive-plic: Fix maximum priority threshold value
        irqchip/ti-sci-inta: Fix processing of masked irqs
        irqchip/mbigen: Free msi_desc on device teardown
        irqchip/gic-v4.1: Update effective affinity of virtual SGIs
        irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling
        genirq: Remove setup_irq() and remove_irq()
      80ade29e
    • Linus Torvalds's avatar
      Merge tag 'sched-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 08dd3872
      Linus Torvalds authored
      Pull scheduler fixes from Thomas Gleixner:
       "Two fixes for the scheduler:
      
         - Work around an uninitialized variable warning where GCC can't
           figure it out.
      
         - Allow 'isolcpus=' to skip unknown subparameters so that older
           kernels work with the commandline of a newer kernel. Improve the
           error output while at it"
      
      * tag 'sched-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        sched/vtime: Work around an unitialized variable warning
        sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters
      08dd3872
    • Linus Torvalds's avatar
      Merge tag 'core-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 5e7de581
      Linus Torvalds authored
      Pull RCU fix from Thomas Gleixner:
       "A single bugfix for RCU to prevent taking a lock in NMI context"
      
      * tag 'core-urgent-2020-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        rcu: Don't acquire lock in NMI handler in rcu_nmi_enter_common()
      5e7de581
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 439f1da9
      Linus Torvalds authored
      Pull ext4 fixes from Ted Ts'o:
       "Miscellaneous bug fixes and cleanups for ext4, including a fix for
        generic/388 in data=journal mode, removing some BUG_ON's, and cleaning
        up some compiler warnings"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: convert BUG_ON's to WARN_ON's in mballoc.c
        ext4: increase wait time needed before reuse of deleted inode numbers
        ext4: remove set but not used variable 'es' in ext4_jbd2.c
        ext4: remove set but not used variable 'es'
        ext4: do not zeroout extents beyond i_disksize
        ext4: fix return-value types in several function comments
        ext4: use non-movable memory for superblock readahead
        ext4: use matching invalidatepage in ext4_writepage
      439f1da9
    • Linus Torvalds's avatar
      Merge tag '5.7-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6 · aee0314b
      Linus Torvalds authored
      Pull cifs fixes from Steve French:
       "Three small smb3 fixes: two debug related (helping network tracing for
        SMB2 mounts, and the other removing an unintended debug line on
        signing failures), and one fixing a performance problem with 64K
        pages"
      
      * tag '5.7-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
        smb3: remove overly noisy debug line in signing errors
        cifs: improve read performance for page size 64KB & cache=strict & vers=2.1+
        cifs: dump the session id and keys also for SMB2 sessions
      aee0314b
    • Linus Torvalds's avatar
      Merge tag 'flexible-array-member-5.7-rc2' of... · 13402837
      Linus Torvalds authored
      Merge tag 'flexible-array-member-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux
      
      Pull flexible-array member conversion from Gustavo Silva:
       "The current codebase makes use of the zero-length array language
        extension to the C90 standard, but the preferred mechanism to declare
        variable-length types such as these ones is a flexible array
        member[1][2], introduced in C99:
      
          struct foo {
              int stuff;
              struct boo array[];
          };
      
        By making use of the mechanism above, we will get a compiler warning
        in case the flexible array does not occur last in the structure, which
        will help us prevent some kind of undefined behavior bugs from being
        inadvertently introduced[3] to the codebase from now on.
      
        Also, notice that, dynamic memory allocations won't be affected by
        this change:
      
         "Flexible array members have incomplete type, and so the sizeof
          operator may not be applied. As a quirk of the original
          implementation of zero-length arrays, sizeof evaluates to zero."[1]
      
        sizeof(flexible-array-member) triggers a warning because flexible
        array members have incomplete type[1]. There are some instances of
        code in which the sizeof operator is being incorrectly/erroneously
        applied to zero-length arrays and the result is zero. Such instances
        may be hiding some bugs. So, this work (flexible-array member
        convertions) will also help to get completely rid of those sorts of
        issues.
      
        Notice that all of these patches have been baking in linux-next for
        quite a while now and, 238 more of these patches have already been
        merged into 5.7-rc1.
      
        There are a couple hundred more of these issues waiting to be
        addressed in the whole codebase"
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      
      * tag 'flexible-array-member-5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: (28 commits)
        xattr.h: Replace zero-length array with flexible-array member
        uapi: linux: fiemap.h: Replace zero-length array with flexible-array member
        uapi: linux: dlm_device.h: Replace zero-length array with flexible-array member
        tpm_eventlog.h: Replace zero-length array with flexible-array member
        ti_wilink_st.h: Replace zero-length array with flexible-array member
        swap.h: Replace zero-length array with flexible-array member
        skbuff.h: Replace zero-length array with flexible-array member
        sched: topology.h: Replace zero-length array with flexible-array member
        rslib.h: Replace zero-length array with flexible-array member
        rio.h: Replace zero-length array with flexible-array member
        posix_acl.h: Replace zero-length array with flexible-array member
        platform_data: wilco-ec.h: Replace zero-length array with flexible-array member
        memcontrol.h: Replace zero-length array with flexible-array member
        list_lru.h: Replace zero-length array with flexible-array member
        lib: cpu_rmap: Replace zero-length array with flexible-array member
        irq.h: Replace zero-length array with flexible-array member
        ihex.h: Replace zero-length array with flexible-array member
        igmp.h: Replace zero-length array with flexible-array member
        genalloc.h: Replace zero-length array with flexible-array member
        ethtool.h: Replace zero-length array with flexible-array member
        ...
      13402837
  2. 18 Apr, 2020 30 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 50cc09c1
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Seven fixes: three in target, one on a sg error leg, two in qla2xxx
        fixing warnings introduced in the last merge window and updating
        MAINTAINERS and one in hisi_sas fixing a problem introduced by libata"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: sg: add sg_remove_request in sg_common_write
        scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN
        scsi: target: fix PR IN / READ FULL STATUS for FC
        scsi: target: Write NULL to *port_nexus_ptr if no ISID
        scsi: MAINTAINERS: Update qla2xxx FC-SCSI driver maintainer
        scsi: qla2xxx: Fix regression warnings
        scsi: hisi_sas: Fix build error without SATA_HOST
      50cc09c1
    • Gustavo A. R. Silva's avatar
      xattr.h: Replace zero-length array with flexible-array member · 43951585
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      43951585
    • Gustavo A. R. Silva's avatar
      uapi: linux: fiemap.h: Replace zero-length array with flexible-array member · 6e88abb8
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      6e88abb8
    • Gustavo A. R. Silva's avatar
      uapi: linux: dlm_device.h: Replace zero-length array with flexible-array member · d6cdad87
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      d6cdad87
    • Gustavo A. R. Silva's avatar
      tpm_eventlog.h: Replace zero-length array with flexible-array member · 06ccf63d
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      06ccf63d
    • Gustavo A. R. Silva's avatar
      ti_wilink_st.h: Replace zero-length array with flexible-array member · 4ea19ecf
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      4ea19ecf
    • Gustavo A. R. Silva's avatar
      swap.h: Replace zero-length array with flexible-array member · 16c3380f
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      16c3380f
    • Gustavo A. R. Silva's avatar
      skbuff.h: Replace zero-length array with flexible-array member · 5c91aa1d
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      5c91aa1d
    • Gustavo A. R. Silva's avatar
      sched: topology.h: Replace zero-length array with flexible-array member · fe946db6
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      fe946db6
    • Gustavo A. R. Silva's avatar
      rslib.h: Replace zero-length array with flexible-array member · 9dd8bb5f
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      9dd8bb5f
    • Gustavo A. R. Silva's avatar
      rio.h: Replace zero-length array with flexible-array member · a1c4b924
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      a1c4b924
    • Gustavo A. R. Silva's avatar
      posix_acl.h: Replace zero-length array with flexible-array member · 70f1451e
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      70f1451e
    • Gustavo A. R. Silva's avatar
      platform_data: wilco-ec.h: Replace zero-length array with flexible-array member · 1223f3db
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      1223f3db
    • Gustavo A. R. Silva's avatar
      memcontrol.h: Replace zero-length array with flexible-array member · 307ed94c
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      307ed94c
    • Gustavo A. R. Silva's avatar
      list_lru.h: Replace zero-length array with flexible-array member · 859b4941
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      859b4941
    • Gustavo A. R. Silva's avatar
      lib: cpu_rmap: Replace zero-length array with flexible-array member · 31232272
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      31232272
    • Gustavo A. R. Silva's avatar
      irq.h: Replace zero-length array with flexible-array member · 7856e9f1
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      7856e9f1
    • Gustavo A. R. Silva's avatar
      ihex.h: Replace zero-length array with flexible-array member · 1d9e13e8
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      1d9e13e8
    • Gustavo A. R. Silva's avatar
      igmp.h: Replace zero-length array with flexible-array member · 0ead3364
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      0ead3364
    • Gustavo A. R. Silva's avatar
      genalloc.h: Replace zero-length array with flexible-array member · 89f60a5d
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      89f60a5d
    • Gustavo A. R. Silva's avatar
      ethtool.h: Replace zero-length array with flexible-array member · 5299a11a
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      5299a11a
    • Gustavo A. R. Silva's avatar
      energy_model.h: Replace zero-length array with flexible-array member · beb69f15
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      beb69f15
    • Gustavo A. R. Silva's avatar
      enclosure.h: Replace zero-length array with flexible-array member · 19219946
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      19219946
    • Gustavo A. R. Silva's avatar
      dirent.h: Replace zero-length array with flexible-array member · a2008395
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      a2008395
    • Gustavo A. R. Silva's avatar
      digsig.h: Replace zero-length array with flexible-array member · 1fa0949b
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      1fa0949b
    • Gustavo A. R. Silva's avatar
      can: dev: peak_canfd.h: Replace zero-length array with flexible-array member · e76018cb
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      e76018cb
    • Gustavo A. R. Silva's avatar
      blk_types: Replace zero-length array with flexible-array member · 5a58ec8c
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      5a58ec8c
    • Gustavo A. R. Silva's avatar
      blk-mq: Replace zero-length array with flexible-array member · f36aaf8b
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      f36aaf8b
    • Gustavo A. R. Silva's avatar
      bio: Replace zero-length array with flexible-array member · 0a368bf0
      Gustavo A. R. Silva authored
      The current codebase makes use of the zero-length array language
      extension to the C90 standard, but the preferred mechanism to declare
      variable-length types such as these ones is a flexible array member[1][2],
      introduced in C99:
      
      struct foo {
              int stuff;
              struct boo array[];
      };
      
      By making use of the mechanism above, we will get a compiler warning
      in case the flexible array does not occur last in the structure, which
      will help us prevent some kind of undefined behavior bugs from being
      inadvertently introduced[3] to the codebase from now on.
      
      Also, notice that, dynamic memory allocations won't be affected by
      this change:
      
      "Flexible array members have incomplete type, and so the sizeof operator
      may not be applied. As a quirk of the original implementation of
      zero-length arrays, sizeof evaluates to zero."[1]
      
      This issue was found with the help of Coccinelle.
      
      [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
      [2] https://github.com/KSPP/linux/issues/21
      [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      0a368bf0
    • Linus Torvalds's avatar
      Merge tag 'hwmon-for-v5.7-rc2' of... · eeaa7625
      Linus Torvalds authored
      Merge tag 'hwmon-for-v5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging
      
      Pull hwmon fixes from Guenter Roeck:
      
       - Fix up chip IDs (isl68137)
      
       - error handling for invalid temperatures and use true module name
         (drivetemp)
      
       - Fix static symbol warnings (k10temp)
      
       - Use valid hwmon device name (jc42)
      
      * tag 'hwmon-for-v5.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
        hwmon: (jc42) Fix name to have no illegal characters
        hwmon: (k10temp) make some symbols static
        hwmon: (drivetemp) Return -ENODATA for invalid temperatures
        hwmon: (drivetemp) Use drivetemp's true module name in Kconfig section
        hwmon: (pmbus/isl68137) Fix up chip IDs
      eeaa7625