Skip to content
  1. Mar 18, 2020
  3. Mar 07, 2020
  5. Feb 15, 2020
    • Gustavo A. R. Silva's avatar
      Input: cyapa - replace zero-length array with flexible-array member · 3dbae155
      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>
Link: https://lore.kernel.org/r/20200214172132.GA28389@embeddedor
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      3dbae155
    • Gustavo A. R. Silva's avatar
      Input: tca6416-keypad - replace zero-length array with flexible-array member · 94bef5d5
      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>
Link: https://lore.kernel.org/r/20200214172022.GA27490@embeddedor
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      94bef5d5
    • Gustavo A. R. Silva's avatar
      Input: gpio_keys_polled - replace zero-length array with flexible-array member · 3d87c75d
      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>
Link: https://lore.kernel.org/r/20200214171907.GA26588@embeddedor
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      3d87c75d
  7. Feb 14, 2020
    • Benjamin Tissoires's avatar
      Input: synaptics - remove the LEN0049 dmi id from topbuttonpad list · 5179a9df
      Benjamin Tissoires authored 
      

The Yoga 11e is using LEN0049, but it doesn't have a trackstick.

Thus, there is no need to create a software top buttons row.

However, it seems that the device works under SMBus, so keep it as part
of the smbus_pnp_ids.

Signed-off-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200115013023.9710-1-benjamin.tissoires@redhat.com
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      5179a9df
    • Gaurav Agrawal's avatar
      Input: synaptics - enable SMBus on ThinkPad L470 · b8a3d819
      Gaurav Agrawal authored 
      

Add touchpad LEN2044 to the list, as it is capable of working with
psmouse.synaptics_intertouch=1

Signed-off-by: default avatarGaurav Agrawal <agrawalgaurav@gnome.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/CADdtggVzVJq5gGNmFhKSz2MBwjTpdN5YVOdr4D3Hkkv=KZRc9g@mail.gmail.com
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      b8a3d819
    • Lyude Paul's avatar
      Input: synaptics - switch T470s to RMI4 by default · bf502391
      Lyude Paul authored 
      

This supports RMI4 and everything seems to work, including the touchpad
buttons. So, let's enable this by default.

Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200204194322.112638-1-lyude@redhat.com
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      bf502391
    • Gustavo A. R. Silva's avatar
      Input: gpio_keys - replace zero-length array with flexible-array member · a1b9b65e
      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>
Link: https://lore.kernel.org/r/20200213002600.GA31916@embeddedor.com
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      a1b9b65e
    • Gustavo A. R. Silva's avatar
      Input: goldfish_events - replace zero-length array with flexible-array member · cfb8d781
      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>
Link: https://lore.kernel.org/r/20200213002430.GA31056@embeddedor.com
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      cfb8d781
  9. Feb 11, 2020
  11. Feb 01, 2020
  13. Jan 28, 2020
  15. Jan 23, 2020
  17. Jan 22, 2020
  19. Jan 21, 2020
    • Alexandru Ardelean's avatar
      Input: ads7846 - use new `delay` structure for SPI transfer delays · 0dfed6dc
      Alexandru Ardelean authored 
      In a recent change to the SPI subsystem [1], a new `delay` struct was added
to replace the `delay_usecs`. This change replaces the current
`delay_usecs` with `delay` for this driver.

The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
that both `delay_usecs` & `delay` are used (in this order to preserve
backwards compatibility).

[1] commit bebcfd27

 ("spi: introduce `delay` field for
`spi_transfer` + spi_transfer_delay_exec()")

Signed-off-by: default avatarAlexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lore.kernel.org/r/20191210141103.15910-1-alexandru.ardelean@analog.com
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      0dfed6dc
    • Stephan Gerhold's avatar
      Input: pm8xxx-vib - fix handling of separate enable register · 996d5d5f
      Stephan Gerhold authored 
      Setting the vibrator enable_mask is not implemented correctly:

For regmap_update_bits(map, reg, mask, val) we give in either
regs->enable_mask or 0 (= no-op) as mask and "val" as value.
But "val" actually refers to the vibrator voltage control register,
which has nothing to do with the enable_mask.

So we usually end up doing nothing when we really wanted
to enable the vibrator.

We want to set or clear the enable_mask (to enable/disable the vibrator).
Therefore, change the call to always modify the enable_mask
and set the bits only if we want to enable the vibrator.

Fixes: d4c7c5c9

 ("Input: pm8xxx-vib - handle separate enable register")
Signed-off-by: default avatarStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200114183442.45720-1-stephan@gerhold.net
Signed-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      996d5d5f
  21. Jan 17, 2020
  23. Jan 11, 2020