Skip to content
GitLab
  1. Jun 13, 2021
  3. Jun 12, 2021
  5. Jun 11, 2021
  7. Jun 10, 2021
    • Robert Marko's avatar
      hwmon: (tps23861) correct shunt LSB values · e13d1127
      Robert Marko authored 
      Current shunt LSB values got reversed during in the
original driver commit.

So, correct the current shunt LSB values according to
the datasheet.

This caused reading slightly skewed current values.

Fixes: fff7b8ab

 ("hwmon: add Texas Instruments TPS23861 driver")
Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
Link: https://lore.kernel.org/r/20210609220728.499879-3-robert.marko@sartura.hr


Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      e13d1127
    • Robert Marko's avatar
      hwmon: (tps23861) set current shunt value · b325d352
      Robert Marko authored 
      TPS23861 has a configuration bit for setting of the
current shunt value used on the board.
Its bit 0 of the General Mask 1 register.

According to the datasheet bit values are:
0 for 255 mOhm (Default)
1 for 250 mOhm

So, configure the bit before registering the hwmon
device according to the value passed in the DTS or
default one if none is passed.

This caused potentially reading slightly skewed values
due to max current value being 1.02A when 250mOhm shunt
is used instead of 1.0A when 255mOhm is used.

Fixes: fff7b8ab

 ("hwmon: add Texas Instruments TPS23861 driver")
Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
Link: https://lore.kernel.org/r/20210609220728.499879-2-robert.marko@sartura.hr


Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      b325d352
    • Robert Marko's avatar
      hwmon: (tps23861) define regmap max register · fb8543fb
      Robert Marko authored 
      Define the max register address the device supports.
This allows reading the whole register space via
regmap debugfs, without it only register 0x0 is visible.

This was forgotten in the original driver commit.

Fixes: fff7b8ab

 ("hwmon: add Texas Instruments TPS23861 driver")
Signed-off-by: default avatarRobert Marko <robert.marko@sartura.hr>
Link: https://lore.kernel.org/r/20210609220728.499879-1-robert.marko@sartura.hr


Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      fb8543fb
    • Takashi Iwai's avatar
      ALSA: seq: Fix race of snd_seq_timer_open() · 83e197a8
      Takashi Iwai authored 
      

The timer instance per queue is exclusive, and snd_seq_timer_open()
should have managed the concurrent accesses.  It looks as if it's
checking the already existing timer instance at the beginning, but
it's not right, because there is no protection, hence any later
concurrent call of snd_seq_timer_open() may override the timer
instance easily.  This may result in UAF, as the leftover timer
instance can keep running while the queue itself gets closed, as
spotted by syzkaller recently.

For avoiding the race, add a proper check at the assignment of
tmr->timeri again, and return -EBUSY if it's been already registered.

Reported-by: default avatar <syzbot+ddc1260a83ed1cbf6fb5@syzkaller.appspotmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/000000000000dce34f05c42f110c@google.com
Link: https://lore.kernel.org/r/20210610152059.24633-1-tiwai@suse.de


Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      83e197a8
    • Stephen Boyd's avatar
      drm/msm/dsi: Stash away calculated vco frequency on recalc · 170b7635
      Stephen Boyd authored 
      A problem was reported on CoachZ devices where the display wouldn't come
up, or it would be distorted. It turns out that the PLL code here wasn't
getting called once dsi_pll_10nm_vco_recalc_rate() started returning the
same exact frequency, down to the Hz, that the bootloader was setting
instead of 0 when the clk was registered with the clk framework.

After commit 001d8dc3 ("drm/msm/dsi: remove temp data from global
pll structure") we use a hardcoded value for the parent clk frequency,
i.e.  VCO_REF_CLK_RATE, and we also hardcode the value for FRAC_BITS,
instead of getting it from the config structure. This combination of
changes to the recalc function allows us to properly calculate the
frequency of the PLL regardless of whether or not the PLL has been
clk_prepare()d or clk_set_rate()d. That's a good improvement.

Unfortunately, this means that now we won't call down into the PLL clk
driver when we call clk_set_rate() because the frequency calculated in
the framework matches the frequency that is set in hardware. If the rate
is the same as what we want it should be OK to not call the set_rate PLL
op. The real problem is that the prepare op in this driver uses a
private struct member to stash away the vco frequency so that it can
call the set_rate op directly during prepare. Once the set_rate op is
never called because recalc_rate told us the rate is the same, we don't
set this private struct member before the prepare op runs, so we try to
call the set_rate function directly with a frequency of 0. This
effectively kills the PLL and configures it for a rate that won't work.
Calling set_rate from prepare is really quite bad and will confuse any
downstream clks about what the rate actually is of their parent. Fixing
that will be a rather large change though so we leave that to later.

For now, let's stash away the rate we calculate during recalc so that
the prepare op knows what frequency to set, instead of 0. This way
things keep working and the display can enable the PLL properly. In the
future, we should remove that code from the prepare op so that it
doesn't even try to call the set rate function.

Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Abhinav Kumar <abhinavk@codeaurora.org>
Fixes: 001d8dc3

 ("drm/msm/dsi: remove temp data from global pll structure")
Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210608195519.125561-1-swboyd@chromium.org


Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
      170b7635
    • Alexander Kuznetsov's avatar
      cgroup1: don't allow '\n' in renaming · b7e24eb1
      Alexander Kuznetsov authored 
      

cgroup_mkdir() have restriction on newline usage in names:
$ mkdir $'/sys/fs/cgroup/cpu/test\ntest2'
mkdir: cannot create directory
'/sys/fs/cgroup/cpu/test\ntest2': Invalid argument

But in cgroup1_rename() such check is missed.
This allows us to make /proc/<pid>/cgroup unparsable:
$ mkdir /sys/fs/cgroup/cpu/test
$ mv /sys/fs/cgroup/cpu/test $'/sys/fs/cgroup/cpu/test\ntest2'
$ echo $$ > $'/sys/fs/cgroup/cpu/test\ntest2'
$ cat /proc/self/cgroup
11:pids:/
10:freezer:/
9:hugetlb:/
8:cpuset:/
7:blkio:/user.slice
6:memory:/user.slice
5:net_cls,net_prio:/
4:perf_event:/
3:devices:/user.slice
2:cpu,cpuacct:/test
test2
1:name=systemd:/
0::/

Signed-off-by: default avatarAlexander Kuznetsov <wwfq@yandex-team.ru>
Reported-by: default avatarAndrey Krasichkov <buglloc@yandex-team.ru>
Acked-by: default avatarDmitry Yakunin <zeil@yandex-team.ru>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      b7e24eb1
    • Alaa Hleihel's avatar
      IB/mlx5: Fix initializing CQ fragments buffer · 2ba0aa2f
      Alaa Hleihel authored 
      The function init_cq_frag_buf() can be called to initialize the current CQ
fragments buffer cq->buf, or the temporary cq->resize_buf that is filled
during CQ resize operation.

However, the offending commit started to use function get_cqe() for
getting the CQEs, the issue with this change is that get_cqe() always
returns CQEs from cq->buf, which leads us to initialize the wrong buffer,
and in case of enlarging the CQ we try to access elements beyond the size
of the current cq->buf and eventually hit a kernel panic.

 [exception RIP: init_cq_frag_buf+103]
  [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]
  [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]
  [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]
  [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]
  [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]
  [ffff9f799ddcbec8] kthread at ffffffffa66c5da1
  [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd

Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that
takes the correct source buffer as a parameter.

Fixes: 388ca8be ("IB/mlx5: Implement fragmented completion queue (CQ)")
Link: https://lore.kernel.org/r/90a0e8c924093cfa50a482880ad7e7edb73dc19a.1623309971.git.leonro@nvidia.com


Signed-off-by: default avatarAlaa Hleihel <alaa@nvidia.com>
Signed-off-by: default avatarLeon Romanovsky <leonro@nvidia.com>
Signed-off-by: default avatarJason Gunthorpe <jgg@nvidia.com>
      2ba0aa2f