summaryrefslogtreecommitdiffstats
path: root/.cocciconfig (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-06-22memory: tegra: Fix an error handling path in tegra186_emc_probe()Christophe JAILLET1-5/+11
The call to tegra_bpmp_get() must be balanced by a call to tegra_bpmp_put() in case of error, as already done in the remove function. Add an error handling path and corresponding goto. Fixes: 52d15dd23f0b ("memory: tegra: Support DVFS on Tegra186 and later") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-06-22memory: tegra30-emc: Poll EMC-CaR handshake instead of waiting for interruptDmitry Osipenko1-72/+44
The memory clock-rate change could be running on a non-boot CPU, while the boot CPU handles the EMC interrupt. This introduces an unnecessary latency since boot CPU should handle the interrupt and then notify the sibling CPU about clock-rate change completion. In some rare cases boot CPU could be in uninterruptible state for a significant time (like in a case of KASAN + NFS root), it could get to the point that completion timeouts before boot CPU gets a chance to handle interrupt. The solution is to get rid of the completion and replace it with interrupt-status polling. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-06-22memory: tegra20-emc: Poll EMC-CaR handshake instead of waiting for interruptDmitry Osipenko1-17/+11
The memory clock-rate change could be running on a non-boot CPU, while the boot CPU handles the EMC interrupt. This introduces an unnecessary latency since boot CPU should handle the interrupt and then notify the sibling CPU about clock-rate change completion. In some rare cases boot CPU could be in uninterruptible state for a significant time (like in a case of KASAN + NFS root), it could get to the point that completion timeouts before boot CPU gets a chance to handle interrupt. The solution is to get rid of the completion and replace it with interrupt-status polling. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-06-22memory: tegra: Support derated timings on Tegra210Thierry Reding4-13/+363
Derated timings are used to ensure that the memory chips keep operating correctly at high temperatures. This adds code to support polling of the chip operating state when high temperatures are measured on the chip and change the refresh mode accordingly. Under very high temperatures, the driver will switch to the derated tables to ensure proper operation of the memory chips. Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-06-22memory: tegra: Add EMC scaling sequence code for Tegra210Joseph Lo4-1/+1875
This patch includes the sequence for clock tuning and the dynamic training mechanism for the clock above 800MHz. And historically there have been different sequences to change the EMC clock. The sequence to be used is specified in the EMC table. However, for the currently supported upstreaming platform, only the most recent sequence is used. So only support that in this patch. Based on the work of Peter De Schrijver <pdeschrijver@nvidia.com>. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-06-22memory: tegra: Add EMC scaling support code for Tegra210Joseph Lo7-0/+2828
This is the initial patch for Tegra210 EMC frequency scaling. It has the code to program various aspects of the EMC that are standardized, but it does not yet include the specific programming sequence needed for clock scaling. The driver is designed to support LPDDR4 SDRAM. Devices that use LPDDR4 need to perform training of the RAM before it can be used. Firmware will perform this training during early boot and pass a table of supported frequencies to the kernel via device tree. For the frequencies above 800 MHz, periodic retraining is needed to compensate for changes in timing. This periodic training will have to be performed until the frequency drops back to or below 800 MHz. This driver provides helpers used during this runtime retraining that will be used by the sequence specific code in a follow-up patch. Based on work by Peter De Schrijver <pdeschrijver@nvidia.com>. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-06-22memory: tegra: Make debugfs permissions human-readableDmitry Osipenko3-9/+9
Replace the symbolic permissions with octals in order to make them readable. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-06-14Linux 5.8-rc1v5.8-rc1Linus Torvalds1-2/+2
2020-06-14security: Add LSM hooks to set*gid syscallsThomas Cedeno5-1/+40
The SafeSetID LSM uses the security_task_fix_setuid hook to filter set*uid() syscalls according to its configured security policy. In preparation for adding analagous support in the LSM for set*gid() syscalls, we add the requisite hook here. Tested by putting print statements in the security_task_fix_setgid hook and seeing them get hit during kernel boot. Signed-off-by: Thomas Cedeno <thomascedeno@google.com> Signed-off-by: Micah Morton <mortonm@chromium.org>
2020-06-14Revert "btrfs: switch to iomap_dio_rw() for dio"David Sterba4-166/+169
This reverts commit a43a67a2d715540c1368b9501a22b0373b5874c0. This patch reverts the main part of switching direct io implementation to iomap infrastructure. There's a problem in invalidate page that couldn't be solved as regression in this development cycle. The problem occurs when buffered and direct io are mixed, and the ranges overlap. Although this is not recommended, filesystems implement measures or fallbacks to make it somehow work. In this case, fallback to buffered IO would be an option for btrfs (this already happens when direct io is done on compressed data), but the change would be needed in the iomap code, bringing new semantics to other filesystems. Another problem arises when again the buffered and direct ios are mixed, invalidation fails, then -EIO is set on the mapping and fsync will fail, though there's no real error. There have been discussions how to fix that, but revert seems to be the least intrusive option. Link: https://lore.kernel.org/linux-btrfs/20200528192103.xm45qoxqmkw7i5yl@fiona/ Signed-off-by: David Sterba <dsterba@suse.com>
2020-06-14net: ethernet: ti: ale: fix allmulti for nu type aleGrygorii Strashko1-9/+40
On AM65xx MCU CPSW2G NUSS and 66AK2E/L NUSS allmulti setting does not allow unregistered mcast packets to pass. This happens, because ALE VLAN entries on these SoCs do not contain port masks for reg/unreg mcast packets, but instead store indexes of ALE_VLAN_MASK_MUXx_REG registers which intended for store port masks for reg/unreg mcast packets. This path was missed by commit 9d1f6447274f ("net: ethernet: ti: ale: fix seeing unreg mcast packets with promisc and allmulti disabled"). Hence, fix it by taking into account ALE type in cpsw_ale_set_allmulti(). Fixes: 9d1f6447274f ("net: ethernet: ti: ale: fix seeing unreg mcast packets with promisc and allmulti disabled") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-14net: ethernet: ti: am65-cpsw-nuss: fix ale parameters initGrygorii Strashko1-1/+1
The ALE parameters structure is created on stack, so it has to be reset before passing to cpsw_ale_create() to avoid garbage values. Fixes: 93a76530316a ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-14net: atm: Remove the error message according to the atomic contextLiao Pingfang1-3/+1
Looking into the context (atomic!) and the error message should be dropped. Signed-off-by: Liao Pingfang <liao.pingfang@zte.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>