[PATCH v2] scsi: ufs: ti-j721e-ufs: Fix error return in ti_j721e_ufs_probe()
Fix to return error code PTR_ERR() from the error handling case instead
of 0.
Fixes: 22617e216331 ("scsi: ufs: ti-j721e-ufs: Fix unwinding of pm_runtime
changes")
Signed-off-by: Jing Xiangfeng
---
drivers/scsi/ufs/ti-j721e-ufs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ufs/ti-j721e-ufs.c b/drivers/scsi/ufs/ti-j721e-ufs.c
index 46bb905b4d6a..eafe0db98d54 100644
--- a/drivers/scsi/ufs/ti-j721e-ufs.c
+++ b/drivers/scsi/ufs/ti-j721e-ufs.c
@@ -38,6 +38,7 @@ static int ti_j721e_ufs_probe(struct platform_device *pdev)
/* Select MPHY refclk frequency */
clk = devm_clk_get(dev, NULL);
if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
dev_err(dev, "Cannot claim MPHY clock.\n");
goto clk_err;
}
--
2.17.1
[PATCH v4] perf test: Introduce script for Arm CoreSight testing
We need a simple method to test Perf with Arm CoreSight drivers, this
could be used for smoke testing when new patch is coming for perf or
CoreSight drivers, and we also can use the test to confirm if the
CoreSight has been enabled successfully on new platforms.
This patch introduces the shell script test_arm_coresight.sh which is
under the 'pert test' framework. This script provides three testing
scenarios:
Test scenario 1: traverse all possible paths between source and sink
For traversing possible paths, simply to say, the testing rationale
is source oriented testing, it traverses every source (now only refers
to ETM device) and test its all possible sinks. To search the complete
paths from one specific source to its sinks, this patch relies on the
sysfs '/sys/bus/coresight/devices/devX/out:Y' for depth-first search
(DFS) for iteration connected device nodes, if the output device is
detected as one of ETR, ETF, or ETB types then it will test trace data
recording and decoding for this PMU device.
The script runs three output testings for every trace data:
- Test branch samples dumping with 'perf script' command;
- Test branch samples reporting with 'perf report' command;
- Use option '--itrace=i1000i' to insert synthesized instructions events
and the script will check if perf can output the percentage value
successfully based on the instruction samples.
Test scenario 2: CPU wide mode test
For CPU wide mode testing, it passes option '-a' to perf tool to enable
tracing on all CPUs, so it's hard to say which program will be traced.
But perf tool itself contributes much overload in this case, so it will
parse trace data and check if process 'perf' can be detected or not.
Test scenario 3: snapshot mode test.
For snapshot mode testing, it uses 'dd' command to launch a long running
program, so this can give chance to send signal -USR2; it will check the
captured trace data contains 'dd' related thread info or not.
If any test fails, it will report failure and directly exit with error.
This test will be only applied on a platform with PMU event 'cs_etm//',
otherwise will skip the testing.
Below is detailed usage for it:
# cd $linux/tools/perf -> This is important so can use shell script
# perf test list
[...]
65: probe libc's inet_pton & backtrace it with ping
66: Check Arm CoreSight trace data recording and branch samples
67: Check open filename arg using perf trace + vfs_getname
68: Zstd perf.data compression/decompression
69: Add vfs_getname probe to get syscall args filenames
70: Use vfs_getname probe to get syscall args filenames
# perf test 66
66: Check Arm CoreSight trace data recording and branch samples: Ok
Signed-off-by: Leo Yan
---
tools/perf/tests/shell/test_arm_coresight.sh | 172 +++
1 file changed, 172 insertions(+)
create mode 100755 tools/perf/tests/shell/test_arm_coresight.sh
diff --git a/tools/perf/tests/shell/test_arm_coresight.sh
b/tools/perf/tests/shell/test_arm_coresight.sh
new file mode 100755
index ..73b973bada26
--- /dev/null
+++ b/tools/perf/tests/shell/test_arm_coresight.sh
@@ -0,0 +1,172 @@
+#!/bin/sh
+# Check Arm CoreSight trace data recording and branch samples
+
+# Uses the 'perf record' to record trace data with Arm CoreSight sinks;
+# then verify if there have any branch samples and instruction samples
+# are generated by CoreSight with 'perf script' and 'perf report'
+# commands.
+
+# SPDX-License-Identifier: GPL-2.0
+# Leo Yan , 2020
+
+perfdata=$(mktemp /tmp/__perf_test.perf.data.X)
+file=$(mktemp /tmp/temporary_file.X)
+
+skip_if_no_cs_etm_event() {
+ perf list | grep -q 'cs_etm//' && return 0
+
+ # cs_etm event doesn't exist
+ return 2
+}
+
+skip_if_no_cs_etm_event || exit 2
+
+record_touch_file() {
+ echo "Recording trace (only user mode) with path: CPU$2 => $1"
+ perf record -o ${perfdata} -e cs_etm/@$1/u --per-thread \
+ -- taskset -c $2 touch $file
+}
+
+perf_script_branch_samples() {
+ echo "Looking at perf.data file for dumping branch samples:"
+
+ # Below is an example of the branch samples dumping:
+ # touch 6512 1 branches:u: b220824c
strcmp+0xc (/lib/aarch64-linux-gnu/ld-2.27.so)
+ # touch 6512 1 branches:u: b22082e0
strcmp+0xa0 (/lib/aarch64-linux-gnu/ld-2.27.so)
+ # touch 6512 1 branches:u: b2208320
strcmp+0xe0 (/lib/aarch64-linux-gnu/ld-2.27.so)
+ perf script -F,-time -i ${perfdata} | \
+ egrep " +$1 +[0-9]+ .* +branches:([u|k]:)? +"
+}
+
+perf_report_branch_samples() {
+ echo "Looking at perf.data file for reporting branch samples:"
+
+ # Below is an example of the branch samples reporting:
+ # 73.04%73.04% touchlibc-2.27.so [.] _dl_addr
+ #7.71% 7.71% touchlibc-2.27.so [.] getenv
+ #2.59% 2.59% touchld-2.27
RE: [PATCH v2] scsi: ufs: ti-j721e-ufs: Fix error return in ti_j721e_ufs_probe()
>
> Fix to return error code PTR_ERR() from the error handling case instead
> of 0.
>
> Fixes: 22617e216331 ("scsi: ufs: ti-j721e-ufs: Fix unwinding of pm_runtime
> changes")
> Signed-off-by: Jing Xiangfeng
Reviewed-by: Avri Altman
Re: KASAN: use-after-free Read in __cfg8NUM_wpan_dev_from_attrs (2)
syzbot suspects this issue was fixed by commit: commit bf64ff4c2aac65d680dc639a511c781cf6b6ec08 Author: Cong Wang Date: Sat Jun 27 07:12:24 2020 + genetlink: get rid of family->attrbuf bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1206949490 start commit: e44f65fd xen-netfront: remove redundant assignment to vari.. git tree: net-next kernel config: https://syzkaller.appspot.com/x/.config?x=829871134ca5e230 dashboard link: https://syzkaller.appspot.com/bug?extid=14e0e4960091ffae7cf7 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11818aa710 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f997d310 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: genetlink: get rid of family->attrbuf For information about bisection process see: https://goo.gl/tpsmEJ#bisection
[PATCH] MIPS: Introduce cmdline argument writecombine=
Loongson processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times,
after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine
mapping for MIPS"), there exists some errors such as blurred screen
and lockup, and so on.
With this patch, disable writecombine by default for Loongson64 to
work well with ATI Radeon or AMD GPU, and it has no influence on the
other platforms due to writecombine is enabled by default.
Additionally, if it is necessary, writecombine=on can be set manually
in the cmdline to enhance the performance for Loongson LS7A integrated
graphics in the future.
[ 60.958721] radeon :03:00.0: ring 0 stalled for more than 10079msec
[ 60.965315] radeon :03:00.0: GPU lockup (current fence id
0x0112 last fence id 0x011d on ring 0)
[ 60.976525] radeon :03:00.0: ring 3 stalled for more than 10086msec
[ 60.983156] radeon :03:00.0: GPU lockup (current fence id
0x0374 last fence id 0x03a8 on ring 3)
Signed-off-by: Tiezhu Yang
---
arch/mips/include/asm/pgtable.h | 4
arch/mips/kernel/cpu-probe.c| 19 +++
2 files changed, 23 insertions(+)
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index dd7a0f5..34869f7 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -473,6 +473,10 @@ static inline pgprot_t pgprot_noncached(pgprot_t _prot)
static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
{
unsigned long prot = pgprot_val(_prot);
+ extern bool mips_writecombine;
+
+ if (!mips_writecombine)
+ return pgprot_noncached(_prot);
/* cpu_data[0].writecombine is already shifted by _CACHE_SHIFT */
prot = (prot & ~_CACHE_MASK) | cpu_data[0].writecombine;
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index e2955f1..98777ca 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -459,6 +459,25 @@ static int __init ftlb_disable(char *s)
__setup("noftlb", ftlb_disable);
+#ifdef CONFIG_MACH_LOONGSON64
+bool mips_writecombine; /* initialise to false by default */
+#else
+bool mips_writecombine = true;
+#endif
+EXPORT_SYMBOL(mips_writecombine);
+
+static int __init writecombine_setup(char *str)
+{
+ if (strcmp(str, "on") == 0)
+ mips_writecombine = true;
+ else if (strcmp(str, "off") == 0)
+ mips_writecombine = false;
+
+ return 1;
+}
+
+__setup("writecombine=", writecombine_setup);
+
/*
* Check if the CPU has per tc perf counters
*/
--
2.1.0
Re: [PATCH] docs: remove the 2.6 "Upgrading I2C Drivers" guide
Hi Wolfram, On Wed, 5 Aug 2020 23:53:51 +0200, Wolfram Sang wrote: > On Wed, Aug 05, 2020 at 08:31:49PM +0200, Stephen Kitt wrote: > > All the drivers have long since been upgraded, and all the important > > information here is also included in the "Implementing I2C device > > drivers" guide. > > > > Signed-off-by: Stephen Kitt > > True! Thanks. > > But I can't apply the patch? > > > base-commit: 2324d50d051ec0f14a548e78554fb02513d6dcef > > Maybe because I don't have the commit in my tree? Can you rebase on top > of 5.8? Ah, yes, the commit is on top of Linus’ current master, following the merge of docs-5.9 from Jon’s tree. In 5.8 the file is a .txt file, but Mauro converted it to .rst for 5.9, and this patch removes the latter file (to avoid a merge conflict later on...). If you prefer, I can submit it to the docs tree instead! > And please also remove the reference in Documentation/i2c/index.rst Oops, yes, I’ll do that in v2 once we decide where it should go. Regards, Stephen pgpyI_S92lBh5.pgp Description: OpenPGP digital signature
RE: [PATCH v3 3/4] fpga: dfl: create a dfl bus type to support DFL devices
> > > +static int dfl_bus_uevent(struct device *dev, struct kobj_uevent_env
> *env)
> > > +{
> > > +struct dfl_device *ddev = to_dfl_dev(dev);
> > > +
> > > +return add_uevent_var(env, "MODALIAS=dfl:t%08Xf%04X",
> > > + ddev->type, ddev->feature_id);
> >
> > Then we only print 12bit of feature_id will be enough?
> > should we make type shorter as well as feature id?
>
> I could envision that we need a struct
>
> struct dfl_feature_id {
> u16 id: 12;
> }
>
> for it.
>
> But it seems more complex and I didn't see the benifit. We don't have to
> worry about the invalid values cause we parse all the ddev->feature_id in
> dfl driver, and ensures it will not be larger than 12bit value.
Ideally type is only 4bits per spec, but looks like it's adding more zero before
the type value, and also the feature id. This may not be a real problem, but
may look a little wired, isn't it?
>
> > And do you think if we should add a new field for dfl version?
>
> I think it may not be necessary now. If we support dfl v1 in future, we
> still could try to check uuid first, then fall back to type &
> feature_id.
I think it's all about the uevent and it's user, and for users, they may have
to
deal with different versions, right? As you mentioned, if the event will be
different format for v1 and it's not compatible with v0, anyway we need
the version sooner or later, is my understanding correct?
>
> Do you have any idea for the potential usage of dfl version.
>
> > > +/* then add irq resource */
> > > +if (feature->nr_irqs) {
> > > +ddev->irqs = kcalloc(feature->nr_irqs,
> > > + sizeof(*ddev->irqs), GFP_KERNEL);
> > > +if (!ddev->irqs) {
> > > +ret = -ENOMEM;
> > > +goto put_dev;
> > > +}
> > > +
> > > +for (i = 0; i < feature->nr_irqs; i++)
> > > +ddev->irqs[i] = feature->irq_ctx[i].irq;
> > > +
> > > +ddev->num_irqs = feature->nr_irqs;
> >
> > Do we need to consider using IORESOURCE_IRQ here as well?
>
> The helper functions for IORESOURCE_IRQ are all for platform_devices,
> We need to define a set of functions similar to them, I think current
> implementation is simpler, for dfl bus and drivers.
If some case that it's going to reuse some platform device driver,
then dfl_device driver will create platform device, it has to pass the mmio
and irq resources to platform device driver, how you plan to do that?
> > > +static int dfl_devs_init(struct platform_device *pdev)
> > > +{
> > > +struct dfl_feature_platform_data *pdata = dev_get_platdata(&pdev-
> > > >dev);
> > > +struct dfl_feature *feature;
> > > +struct dfl_device *ddev;
> > > +
> > > +dfl_fpga_dev_for_each_feature(pdata, feature) {
> > > +if (feature->ioaddr || feature->priv)
> >
> > Why checks priv here?
>
> I want to make sure the dfl_device is not already created.
Is that a valid case that we expected? or sounds like error code needs
to be returned?
Thanks
Hao
Re: [PATCH] arm64: tlb: fix ARM64_TLB_RANGE with LLVM's integrated assembler
Hi,
On 2020/8/6 2:19, Sami Tolvanen wrote:
> Commit 7c78f67e9bd9 ("arm64: enable tlbi range instructions") breaks
> LLVM's integrated assembler, because -Wa,-march is only passed to
> external assemblers and therefore, the new instructions are not enabled
> when IAS is used.
>
I have looked through the discussion on Github issues. The best way to
solve this problem is try to pass the "-Wa,-march" parameter to clang
even when IAS is enabled, which may need the cooperation of compilation
tool chains :(
Currently, I think we can solve the problem by passing
the '-march=armv8.4-a' when using the integrated assembler, just like:
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 55bc8546d9c7..e5ce184e98c2 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -91,8 +91,12 @@ KBUILD_CFLAGS += $(branch-prot-flags-y)
ifeq ($(CONFIG_AS_HAS_ARMV8_4), y)
# make sure to pass the newest target architecture to -march.
+ifneq ($(LLVM),)
+KBUILD_CFLAGS += -march=armv8.4-a
+else
KBUILD_CFLAGS += -Wa,-march=armv8.4-a
endif
+endif
ifeq ($(CONFIG_SHADOW_CALL_STACK), y)
No need to worry about that this might generate instructions that are not
supported on older hardware, because the 'TLB range' feature is only
enabled when the hardware support ARMv8.4.
> As binutils doesn't support .arch_extension tlb-rmi, this change adds
> .arch armv8.4-a to __TLBI_0 and __TLBI_1 to fix the issue with both LLVM
> IAS and binutils.
>
> Fixes: 7c78f67e9bd9 ("arm64: enable tlbi range instructions")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1106
> Signed-off-by: Sami Tolvanen
Thanks,
Zhenyu
Re: [PATCH v7 0/4] scsi: ufs: Add Host Performance Booster Support
Hi Daejun, On 2020-08-05 11:37, Daejun Park wrote: Changelog: v6 -> v7 1. Remove UFS feature layer. 2. Cleanup for sparse error. v5 -> v6 Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 v4 -> v5 Delete unused macro define. v3 -> v4 1. Cleanup. v2 -> v3 1. Add checking input module parameter value. 2. Change base commit from 5.8/scsi-queue to 5.9/scsi-queue. 3. Cleanup for unused variables and label. v1 -> v2 1. Change the full boilerplate text to SPDX style. 2. Adopt dynamic allocation for sub-region data structure. 3. Cleanup. NAND flash memory-based storage devices use Flash Translation Layer (FTL) to translate logical addresses of I/O requests to corresponding flash memory addresses. Mobile storage devices typically have RAM with constrained size, thus lack in memory to keep the whole mapping table. Therefore, mapping tables are partially retrieved from NAND flash on demand, causing random-read performance degradation. To improve random read performance, JESD220-3 (HPB v1.0) proposes HPB (Host Performance Booster) which uses host system memory as a cache for the FTL mapping table. By using HPB, FTL data can be read from host memory faster than from NAND flash memory. The current version only supports the DCM (device control mode). This patch consists of 3 parts to support HPB feature. 1) HPB probe and initialization process 2) READ -> HPB READ using cached map information 3) L2P (logical to physical) map management In the HPB probe and init process, the device information of the UFS is queried. After checking supported features, the data structure for the HPB is initialized according to the device information. A read I/O in the active sub-region where the map is cached is changed to HPB READ by the HPB. The HPB manages the L2P map using information received from the device. For active sub-region, the HPB caches through ufshpb_map request. For the in-active region, the HPB discards the L2P map. When a write I/O occurs in an active sub-region area, associated dirty bitmap checked as dirty for preventing stale read. HPB is shown to have a performance improvement of 58 - 67% for random read workload. [1] This series patches are based on the 5.9/scsi-queue branch. [1]: https://www.usenix.org/conference/hotstorage17/program/presentation/jeong Daejun park (4): scsi: ufs: Add UFS feature related parameter scsi: ufs: Introduce HPB feature scsi: ufs: L2P map management for HPB read scsi: ufs: Prepare HPB read for cached sub-region drivers/scsi/ufs/Kconfig | 18 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs.h| 12 + drivers/scsi/ufs/ufshcd.c | 42 + drivers/scsi/ufs/ufshcd.h |9 + drivers/scsi/ufs/ufshpb.c | 1926 drivers/scsi/ufs/ufshpb.h | 241 + 7 files changed, 2249 insertions(+) created mode 100644 drivers/scsi/ufs/ufshpb.c created mode 100644 drivers/scsi/ufs/ufshpb.h I only gave my reviewed-by tag to the very first patch (changes to ufshcd.h), but not the whole series. Please remove those tags accordingly. Thanks, Can Guo.
[PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of operations executed in a driver. Thus, does not change its behavior.
During this process, it was found that "#if defined(CONFIG_PM)" at line 1434 is
redundant. This was introduced in the commit
42ddb453a0cd ("radeon: Conditionally compile PM code").
Before 42ddb453a0cd:
$ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
"#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
Based on output in terminal:
547:#ifdef CONFIG_PM
|-- 959:#ifdef CONFIG_PPC_PMAC
|-- 972:#endif
|-- 1291:#ifdef CONFIG_PPC_OF
|-- 1301:#endif /* CONFIG_PPC_OF */
|-- 1943:#ifdef CONFIG_PPC_OF
|-- 2206:#if 0 /* Not ready yet */
|-- 2508:#endif /* 0 */
|-- 2510:#endif /* CONFIG_PPC_OF */
|-- 2648:#ifdef CONFIG_PPC_PMAC
|-- 2654:#endif /* CONFIG_PPC_PMAC */
|-- 2768:#ifdef CONFIG_PPC_PMAC
|-- 2774:#endif /* CONFIG_PPC_PMAC */
|-- 2791:#ifdef CONFIG_PPC_OF__disabled
|-- 2801:#endif /* CONFIG_PPC_OF */
2803:#endif /* CONFIG_PM */
After 42ddb453a0cd:
$ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
"#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
Based on output in terminal:
547:#ifdef CONFIG_PM
|-- 959:#ifdef CONFIG_PPC_PMAC
|-- 972:#endif
|-- 1291:#ifdef CONFIG_PPC_OF
|-- 1301:#endif /* CONFIG_PPC_OF */
|-- 1430:#if defined(CONFIG_PM)
|-- 1431:#if defined(CONFIG_X86) || defined(CONFIG_PPC_PMAC)
|-- 1944:#endif
|-- 1946:#ifdef CONFIG_PPC_OF
|-- 1947:#ifdef CONFIG_PPC_PMAC
|-- 2208:#endif
|-- 2209:#endif
|-- 2211:#if 0 /* Not ready yet */
|-- 2513:#endif /* 0 */
|-- 2515:#endif /* CONFIG_PPC_OF */
|-- 2653:#ifdef CONFIG_PPC_PMAC
|-- 2659:#endif /* CONFIG_PPC_PMAC */
|-- 2773:#ifdef CONFIG_PPC_PMAC
|-- 2779:#endif /* CONFIG_PPC_PMAC */
|-- 2796:#ifdef CONFIG_PPC_OF__disabled
|-- 2806:#endif /* CONFIG_PPC_OF */
2808:#endif /* CONFIG_PM */
This also affected the CONFIG_PPC_OF container (line 1943 at commit
65122f7e80b5)
The patch-series fixes it along with PM upgrade.
All patches are compile-tested only.
Test tools:
- Compiler: gcc (GCC) 10.1.0
- allmodconfig build: make -j$(nproc) W=1 all
Vaibhav Gupta (2):
video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
fbdev: radeonfb:use generic power management
drivers/video/fbdev/aty/radeon_base.c | 10 ---
drivers/video/fbdev/aty/radeon_pm.c | 38 ---
drivers/video/fbdev/aty/radeonfb.h| 3 +--
3 files changed, 35 insertions(+), 16 deletions(-)
--
2.27.0
[PATCH] mtd: rawnand: vf610: disable clk on error handling path in probe
vf610_nfc_probe() does not invoke clk_disable_unprepare() on one error
handling path. The patch fixes that.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 6f0ce4dfc5a3 ("mtd: rawnand: vf610: Avoid a potential NULL pointer
dereference")
Signed-off-by: Evgeny Novikov
---
drivers/mtd/nand/raw/vf610_nfc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/vf610_nfc.c b/drivers/mtd/nand/raw/vf610_nfc.c
index 7248c5901183..fcca45e2abe2 100644
--- a/drivers/mtd/nand/raw/vf610_nfc.c
+++ b/drivers/mtd/nand/raw/vf610_nfc.c
@@ -852,8 +852,10 @@ static int vf610_nfc_probe(struct platform_device *pdev)
}
of_id = of_match_device(vf610_nfc_dt_ids, &pdev->dev);
- if (!of_id)
- return -ENODEV;
+ if (!of_id) {
+ err = -ENODEV;
+ goto err_disable_clk;
+ }
nfc->variant = (enum vf610_nfc_variant)of_id->data;
--
2.26.2
Re: [PATCH v2 19/24] vdpa: make sure set_features in invoked for legacy
On 2020/8/6 下午1:53, Michael S. Tsirkin wrote: On Thu, Aug 06, 2020 at 11:23:05AM +0800, Jason Wang wrote: On 2020/8/5 下午7:40, Michael S. Tsirkin wrote: On Wed, Aug 05, 2020 at 02:14:07PM +0800, Jason Wang wrote: On 2020/8/4 上午5:00, Michael S. Tsirkin wrote: Some legacy guests just assume features are 0 after reset. We detect that config space is accessed before features are set and set features to 0 automatically. Note: some legacy guests might not even access config space, if this is reported in the field we might need to catch a kick to handle these. I wonder whether it's easier to just support modern device? Thanks Well hardware vendors are I think interested in supporting legacy guests. Limiting vdpa to modern only would make it uncompetitive. My understanding is that, IOMMU_PLATFORM is mandatory for hardware vDPA to work. Hmm I don't really see why. Assume host maps guest memory properly, VM does not have an IOMMU, legacy guest can just work. Yes, guest may not set IOMMU_PLATFORM. Care explaining what's wrong with this picture? The problem is virtio_vdpa, without IOMMU_PLATFORM it uses PA which can not work if IOMMU is enabled. Thanks So it can only work for modern device ... Thanks
[PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
Linux Kernel Mentee: Remove Legacy Power Management.
The original goal of the patch series is to upgrade the power management
framework of radeonfb fbdev driver. This has been done by upgrading .suspend()
and .resume() callbacks.
The upgrade makes sure that the involvement of PCI Core does not change the
order of operations executed in a driver. Thus, does not change its behavior.
During this process, it was found that "#if defined(CONFIG_PM)" at line 1434 is
redundant. This was introduced in the commit
42ddb453a0cd ("radeon: Conditionally compile PM code").
Before 42ddb453a0cd:
$ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n
"#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
Based on output in terminal:
547:#ifdef CONFIG_PM
|-- 959:#ifdef CONFIG_PPC_PMAC
|-- 972:#endif
|-- 1291:#ifdef CONFIG_PPC_OF
|-- 1301:#endif /* CONFIG_PPC_OF */
|-- 1943:#ifdef CONFIG_PPC_OF
|-- 2206:#if 0 /* Not ready yet */
|-- 2508:#endif /* 0 */
|-- 2510:#endif /* CONFIG_PPC_OF */
|-- 2648:#ifdef CONFIG_PPC_PMAC
|-- 2654:#endif /* CONFIG_PPC_PMAC */
|-- 2768:#ifdef CONFIG_PPC_PMAC
|-- 2774:#endif /* CONFIG_PPC_PMAC */
|-- 2791:#ifdef CONFIG_PPC_OF__disabled
|-- 2801:#endif /* CONFIG_PPC_OF */
2803:#endif /* CONFIG_PM */
After 42ddb453a0cd:
$ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n
"#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef"
Based on output in terminal:
547:#ifdef CONFIG_PM
|-- 959:#ifdef CONFIG_PPC_PMAC
|-- 972:#endif
|-- 1291:#ifdef CONFIG_PPC_OF
|-- 1301:#endif /* CONFIG_PPC_OF */
|-- 1430:#if defined(CONFIG_PM)
|-- 1431:#if defined(CONFIG_X86) || defined(CONFIG_PPC_PMAC)
|-- 1944:#endif
|-- 1946:#ifdef CONFIG_PPC_OF
|-- 1947:#ifdef CONFIG_PPC_PMAC
|-- 2208:#endif
|-- 2209:#endif
|-- 2211:#if 0 /* Not ready yet */
|-- 2513:#endif /* 0 */
|-- 2515:#endif /* CONFIG_PPC_OF */
|-- 2653:#ifdef CONFIG_PPC_PMAC
|-- 2659:#endif /* CONFIG_PPC_PMAC */
|-- 2773:#ifdef CONFIG_PPC_PMAC
|-- 2779:#endif /* CONFIG_PPC_PMAC */
|-- 2796:#ifdef CONFIG_PPC_OF__disabled
|-- 2806:#endif /* CONFIG_PPC_OF */
2808:#endif /* CONFIG_PM */
This also affected the CONFIG_PPC_OF container (line 1943 at commit
65122f7e80b5)
The patch-series fixes it along with PM upgrade.
All patches are compile-tested only.
Test tools:
- Compiler: gcc (GCC) 10.1.0
- allmodconfig build: make -j$(nproc) W=1 all
Vaibhav Gupta (2):
video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
fbdev: radeonfb:use generic power management
drivers/video/fbdev/aty/radeon_base.c | 10 ---
drivers/video/fbdev/aty/radeon_pm.c | 38 ---
drivers/video/fbdev/aty/radeonfb.h| 3 +--
3 files changed, 35 insertions(+), 16 deletions(-)
--
2.27.0
Re: [Patch v2] mm/sparse: only sub-section aligned range would be populated
On 05.08.20 23:49, Wei Yang wrote: > On Fri, Jul 03, 2020 at 11:18:28AM +0800, Wei Yang wrote: >> There are two code path which invoke __populate_section_memmap() >> >> * sparse_init_nid() >> * sparse_add_section() >> >> For both case, we are sure the memory range is sub-section aligned. >> >> * we pass PAGES_PER_SECTION to sparse_init_nid() >> * we check range by check_pfn_span() before calling >>sparse_add_section() >> >> Also, the counterpart of __populate_section_memmap(), we don't do such >> calculation and check since the range is checked by check_pfn_span() in >> __remove_pages(). >> >> Clear the calculation and check to keep it simple and comply with its >> counterpart. >> >> Signed-off-by: Wei Yang >> > > Hi, Andrew, > > Is this one picked up? I can spot it in -next via the -mm tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=68ad9becb23be14622e39ed36e5b0621a90a41d9 -- Thanks, David / dhildenb
[PATCH v1 1/2] video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container
Fixes commit 42ddb453a0cd ("radeon: Conditionally compile PM code")
Before the above mentioned patch, codes between the line number 547 and
2803 were already inside "#ifdef CONFIG_PM" container. Thus, addition of
"#if defined(CONFIG_PM)" was not required in the patch. It also affected
the "#ifdef CONFIG_PPC_OF" container (line 1943-2510).
>From the current snapshot of radeon_pm.c, remove:
1434 | #if defined(CONFIG_PM)
and,
2213 | #endif
This removes the redundant CONFIG_PM directive as well as fixes the
CONFIG_PPC (earlier CONFIG_PPC_OF) container.
Signed-off-by: Vaibhav Gupta
---
drivers/video/fbdev/aty/radeon_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_pm.c
b/drivers/video/fbdev/aty/radeon_pm.c
index 7c4483c7f313..b9af70bd656a 100644
--- a/drivers/video/fbdev/aty/radeon_pm.c
+++ b/drivers/video/fbdev/aty/radeon_pm.c
@@ -1431,7 +1431,6 @@ static void radeon_pm_full_reset_sdram(struct
radeonfb_info *rinfo)
mdelay( 15);
}
-#if defined(CONFIG_PM)
#if defined(CONFIG_X86) || defined(CONFIG_PPC_PMAC)
static void radeon_pm_reset_pad_ctlr_strength(struct radeonfb_info *rinfo)
{
@@ -2210,7 +2209,6 @@ static void radeon_reinitialize_M9P(struct radeonfb_info
*rinfo)
radeon_pm_m10_enable_lvds_spread_spectrum(rinfo);
}
#endif
-#endif
#if 0 /* Not ready yet */
static void radeon_reinitialize_QW(struct radeonfb_info *rinfo)
--
2.27.0
[PATCH v1 2/2] fbdev: radeonfb:use generic power management
Drivers using legacy PCI power management .suspend()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a "struct dev_pm_ops"
variable to take the unnecessary load from the driver.
This also avoids the need for the driver to directly call most of the PCI
helper functions and device power state control functions, as through
the generic framework PCI Core takes care of the necessary operations,
and drivers are required to do only device-specific jobs.
Signed-off-by: Vaibhav Gupta
---
drivers/video/fbdev/aty/radeon_base.c | 10 +---
drivers/video/fbdev/aty/radeon_pm.c | 36 +--
drivers/video/fbdev/aty/radeonfb.h| 3 +--
3 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c
b/drivers/video/fbdev/aty/radeon_base.c
index e116a3f9ad56..232dbe154666 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2559,16 +2559,18 @@ static void radeonfb_pci_unregister(struct pci_dev
*pdev)
framebuffer_release(info);
}
+#ifdef CONFIG_PM
+#define RADEONFB_PCI_PM_OPS (&radeonfb_pci_pm_ops)
+#else
+#define RADEONFB_PCI_PM_OPS NULL
+#endif
static struct pci_driver radeonfb_driver = {
.name = "radeonfb",
.id_table = radeonfb_pci_table,
.probe = radeonfb_pci_register,
.remove = radeonfb_pci_unregister,
-#ifdef CONFIG_PM
- .suspend= radeonfb_pci_suspend,
- .resume = radeonfb_pci_resume,
-#endif /* CONFIG_PM */
+ .driver.pm = RADEONFB_PCI_PM_OPS,
};
#ifndef MODULE
diff --git a/drivers/video/fbdev/aty/radeon_pm.c
b/drivers/video/fbdev/aty/radeon_pm.c
index b9af70bd656a..352d0bb4773a 100644
--- a/drivers/video/fbdev/aty/radeon_pm.c
+++ b/drivers/video/fbdev/aty/radeon_pm.c
@@ -2611,8 +2611,9 @@ static void radeon_set_suspend(struct radeonfb_info
*rinfo, int suspend)
}
}
-int radeonfb_pci_suspend(struct pci_dev *pdev, pm_message_t mesg)
+static int radeonfb_pci_suspend_late(struct device *dev, pm_message_t mesg)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
@@ -2660,11 +2661,6 @@ int radeonfb_pci_suspend(struct pci_dev *pdev,
pm_message_t mesg)
pmac_suspend_agp_for_card(pdev);
#endif /* CONFIG_PPC_PMAC */
- /* It's unclear whether or when the generic code will do that, so let's
-* do it ourselves. We save state before we do any power management
-*/
- pci_save_state(pdev);
-
/* If we support wakeup from poweroff, we save all regs we can
including cfg
* space
*/
@@ -2689,7 +2685,6 @@ int radeonfb_pci_suspend(struct pci_dev *pdev,
pm_message_t mesg)
msleep(20);
OUTREG(LVDS_GEN_CNTL, INREG(LVDS_GEN_CNTL) &
~(LVDS_DIGON));
}
- pci_disable_device(pdev);
}
/* If we support D2, we go to it (should be fixed later with a flag
forcing
* D3 only for some laptops)
@@ -2705,6 +2700,21 @@ int radeonfb_pci_suspend(struct pci_dev *pdev,
pm_message_t mesg)
return 0;
}
+static int radeonfb_pci_suspend(struct device *dev)
+{
+ return radeonfb_pci_suspend_late(dev, PMSG_SUSPEND);
+}
+
+static int radeonfb_pci_hibernate(struct device *dev)
+{
+ return radeonfb_pci_suspend_late(dev, PMSG_HIBERNATE);
+}
+
+static int radeonfb_pci_freeze(struct device *dev)
+{
+ return radeonfb_pci_suspend_late(dev, PMSG_FREEZE);
+}
+
static int radeon_check_power_loss(struct radeonfb_info *rinfo)
{
return rinfo->save_regs[4] != INPLL(CLK_PIN_CNTL) ||
@@ -2712,8 +2722,9 @@ static int radeon_check_power_loss(struct radeonfb_info
*rinfo)
rinfo->save_regs[3] != INPLL(SCLK_CNTL);
}
-int radeonfb_pci_resume(struct pci_dev *pdev)
+static int radeonfb_pci_resume(struct device *dev)
{
+ struct pci_dev *pdev = to_pci_dev(dev);
struct fb_info *info = pci_get_drvdata(pdev);
struct radeonfb_info *rinfo = info->par;
int rc = 0;
@@ -2795,6 +2806,15 @@ int radeonfb_pci_resume(struct pci_dev *pdev)
return rc;
}
+const struct dev_pm_ops radeonfb_pci_pm_ops = {
+ .suspend= radeonfb_pci_suspend,
+ .resume = radeonfb_pci_resume,
+ .freeze = radeonfb_pci_freeze,
+ .thaw = radeonfb_pci_resume,
+ .poweroff = radeonfb_pci_hibernate,
+ .restore= radeonfb_pci_resume,
+};
+
#ifdef CONFIG_PPC__disabled
static void radeonfb_early_resume(void *data)
{
diff --git a/drivers/video/fbdev/aty/radeonfb.h
b/drivers/video/fbdev/aty/radeonfb.h
index 131b34dd65af..93f403cbb415 100644
--- a/drivers/video/fbdev/aty/radeonfb.h
+++ b/drivers/vid
Re: [PATCH] sound: isa: delete repeated words in comments
On Thu, 06 Aug 2020 04:19:16 +0200,
Randy Dunlap wrote:
>
> Drop duplicated words in sound/isa/.
> {be, bit}
>
> Signed-off-by: Randy Dunlap
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: alsa-de...@alsa-project.org
Thanks, applied.
Takashi
[Patch v2 1/4] dt-bindings: dma: Add DT binding document
Add DT binding document for Nvidia Tegra GPCDMA controller.
Signed-off-by: Rajesh Gumasta
---
.../bindings/dma/nvidia,tegra-gpc-dma.yaml | 99 ++
1 file changed, 99 insertions(+)
create mode 100644
Documentation/devicetree/bindings/dma/nvidia,tegra-gpc-dma.yaml
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra-gpc-dma.yaml
b/Documentation/devicetree/bindings/dma/nvidia,tegra-gpc-dma.yaml
new file mode 100644
index 000..39827ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra-gpc-dma.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/nvidia,tegra-gpc-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nvidia Tegra GPC DMA Controller Device Tree Bindings
+
+description: |
+ Tegra GPC DMA controller is a general purpose dma used for faster data
+ transfers between memory to memory, memory to device and device to memory.
+ Terms 'dma' and 'gpcdma' can be used interchangeably.
+
+maintainers:
+ - Jon Hunter
+ - Rajesh Gumasta
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ "#dma-cells":
+const: 1
+
+ compatible:
+- enum:
+ - nvidia,tegra186-gpcdma
+ - nvidia,tegra194-gpcdma
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ resets:
+maxItems: 1
+
+ reset-names:
+const: gpcdma
+
+ iommus:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - resets
+ - reset-names
+ - "#dma-cells"
+ - iommus
+
+examples:
+ - |
+gpcdma: dma@260 {
+ compatible = "nvidia,tegra186-gpcdma";
+ reg = <0x0 0x260 0x0 0x21>;
+ resets = <&bpmp TEGRA186_RESET_GPCDMA>;
+ reset-names = "gpcdma";
+ interrupts = ;
+ #dma-cells = <1>;
+ iommus = <&smmu TEGRA_SID_GPCDMA_0>;
+ dma-coherent;
+ };
+
+...
--
2.7.4
[Patch v2 2/4] dmaengine: tegra: Add Tegra GPC DMA driver
Adding GPC DMA controller driver for Tegra186 and Tegra194. The driver supports dma transfers between memory to memory, IO peripheral to memory and memory to IO peripheral. Signed-off-by: Pavan Kunapuli Signed-off-by: Rajesh Gumasta --- drivers/dma/Kconfig | 12 + drivers/dma/Makefile|1 + drivers/dma/tegra-gpc-dma.c | 1472 +++ 3 files changed, 1485 insertions(+) create mode 100644 drivers/dma/tegra-gpc-dma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e9ed916..84b3a0a 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -639,6 +639,18 @@ config TEGRA210_ADMA peripheral and vice versa. It does not support memory to memory data transfer. +config TEGRA_GPC_DMA + tristate "NVIDIA Tegra GPC DMA support" + depends on ARCH_TEGRA_186_SOC || ARCH_TEGRA_194_SOC || COMPILE_TEST + select DMA_ENGINE + help + Support for the NVIDIA Tegra186 and Tegra194 GPC DMA controller + driver. The DMA controller has multiple DMA channels which can + be configured for different peripherals like UART, SPI, etc + which are on APB bus. + This DMA controller transfers data from memory to peripheral FIFO + or vice versa. It also supports memory to memory data transfer. + config TIMB_DMA tristate "Timberdale FPGA DMA support" depends on MFD_TIMBERDALE || COMPILE_TEST diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index e60f813..43e3a6e 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -76,6 +76,7 @@ obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o obj-$(CONFIG_TEGRA210_ADMA) += tegra210-adma.o +obj-$(CONFIG_TEGRA_GPC_DMA) += tegra-gpc-dma.o obj-$(CONFIG_TIMB_DMA) += timb_dma.o obj-$(CONFIG_UNIPHIER_MDMAC) += uniphier-mdmac.o obj-$(CONFIG_UNIPHIER_XDMAC) += uniphier-xdmac.o diff --git a/drivers/dma/tegra-gpc-dma.c b/drivers/dma/tegra-gpc-dma.c new file mode 100644 index 000..723b352 --- /dev/null +++ b/drivers/dma/tegra-gpc-dma.c @@ -0,0 +1,1472 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * DMA driver for Nvidia's Tegra186 and Tegra194 GPC DMA controller. + * + * Copyright (c) 2014-2020, NVIDIA CORPORATION. All rights reserved. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "virt-dma.h" + +/* CSR register */ +#define TEGRA_GPCDMA_CHAN_CSR 0x00 +#define TEGRA_GPCDMA_CSR_ENB BIT(31) +#define TEGRA_GPCDMA_CSR_IE_EOCBIT(30) +#define TEGRA_GPCDMA_CSR_ONCE BIT(27) +#define TEGRA_GPCDMA_CSR_FC_MODE_NO_MMIO (0 << 24) +#define TEGRA_GPCDMA_CSR_FC_MODE_ONE_MMIO BIT(24) +#define TEGRA_GPCDMA_CSR_FC_MODE_TWO_MMIO BIT(25) +#define TEGRA_GPCDMA_CSR_FC_MODE_FOUR_MMIO GENMASK(25, 24) +#define TEGRA_GPCDMA_CSR_DMA_IO2MEM_NO_FC (0 << 21) +#define TEGRA_GPCDMA_CSR_DMA_IO2MEM_FC BIT(21) +#define TEGRA_GPCDMA_CSR_DMA_MEM2IO_NO_FC BIT(22) +#define TEGRA_GPCDMA_CSR_DMA_MEM2IO_FC GENMASK(22, 21) +#define TEGRA_GPCDMA_CSR_DMA_MEM2MEM BIT(23) +#define TEGRA_GPCDMA_CSR_DMA_FIXED_PAT GENMASK(23, 22) +#define TEGRA_GPCDMA_CSR_REQ_SEL_SHIFT 16 +#define TEGRA_GPCDMA_CSR_REQ_SEL_MASK GENMASK(20, 16) +#define TEGRA_GPCDMA_CSR_REQ_SEL_UNUSEDBIT(18) +#define TEGRA_GPCDMA_CSR_IRQ_MASK BIT(15) +#define TEGRA_GPCDMA_CSR_WEIGHT_SHIFT 10 + +/* STATUS register */ +#define TEGRA_GPCDMA_CHAN_STATUS 0x004 +#define TEGRA_GPCDMA_STATUS_BUSY BIT(31) +#define TEGRA_GPCDMA_STATUS_ISE_EOCBIT(30) +#define TEGRA_GPCDMA_STATUS_PING_PONG BIT(28) +#define TEGRA_GPCDMA_STATUS_DMA_ACTIVITY BIT(27) +#define TEGRA_GPCDMA_STATUS_CHANNEL_PAUSE BIT(26) +#define TEGRA_GPCDMA_STATUS_CHANNEL_RX BIT(25) +#define TEGRA_GPCDMA_STATUS_CHANNEL_TX BIT(24) +#define TEGRA_GPCDMA_STATUS_IRQ_INTR_STA BIT(23) +#define TEGRA_GPCDMA_STATUS_IRQ_STABIT(21) +#define TEGRA_GPCDMA_STATUS_IRQ_TRIG_STA BIT(20) + +#define TEGRA_GPCDMA_CHAN_CSRE 0x008 +#define TEGRA_GPCDMA_CHAN_CSRE_PAUSE BIT(31) + +/* Source address */ +#define TEGRA_GPCDMA_CHAN_SRC_PTR 0x00C + +/* Destination address */ +#define TEGRA_GPCDMA_CHAN_DST_PTR 0x010 + +/* High address pointer */ +#define TEGRA_GPCDMA_CHAN_HIGH_ADDR_PTR0x014 +#define TEGRA_GPCDMA_HIGH_ADDR_SCR_PTR_SHIFT 0 +#define TEGRA_GPCDMA_HIGH_ADDR_SCR_PTR_MASK0xFF +#define TEGRA_GPCDMA_HIGH_ADDR_DST_PTR_SHIFT 16 +#define TEGRA_GPCDMA_HIGH_ADDR_DST_PTR_MASK0xFF + +/* MC sequence register */ +#define TEGRA_GPCDMA_CHAN_MCSEQ
Re: [PATCH] sound: pci: delete repeated words in comments
On Thu, 06 Aug 2020 04:19:26 +0200,
Randy Dunlap wrote:
>
> Drop duplicated words in sound/pci/.
> {and, the, at}
>
> Signed-off-by: Randy Dunlap
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: alsa-de...@alsa-project.org
> Cc: Clemens Ladisch
Thanks, applied.
Takashi
[Patch v2 0/4] Add Nvidia Tegra GPC-DMA driver
Changes in patch v2: Addressed review comments in patch v1 v1 - https://lkml.org/lkml/2020/7/20/96 Rajesh Gumasta (4): dt-bindings: dma: Add DT binding document dmaengine: tegra: Add Tegra GPC DMA driver arm64: configs: enable tegra gpc dma arm64: tegra: Add GPCDMA node in dt .../bindings/dma/nvidia,tegra-gpc-dma.yaml | 99 ++ arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi |4 + arch/arm64/boot/dts/nvidia/tegra186.dtsi | 46 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 44 + arch/arm64/configs/defconfig |1 + drivers/dma/Kconfig| 12 + drivers/dma/Makefile |1 + drivers/dma/tegra-gpc-dma.c| 1472 8 files changed, 1679 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra-gpc-dma.yaml create mode 100644 drivers/dma/tegra-gpc-dma.c -- 2.7.4
[Patch v2 3/4] arm64: configs: enable tegra gpc dma
Enable TEGRA_GPC_DMA in defconfig for Tegra186 and Tegra196 gpc dma controller driver Signed-off-by: Rajesh Gumasta --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 883e8ba..600f568 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -775,6 +775,7 @@ CONFIG_MV_XOR_V2=y CONFIG_OWL_DMA=y CONFIG_PL330_DMA=y CONFIG_TEGRA20_APB_DMA=y +CONFIG_TEGRA_GPC_DMA=m CONFIG_QCOM_BAM_DMA=y CONFIG_QCOM_HIDMA_MGMT=y CONFIG_QCOM_HIDMA=y -- 2.7.4
[Patch v2 4/4] arm64: tegra: Add GPCDMA node in dt
Add device tree node for GPCDMA controller on Tegra186 target
and Tegra194 target.
Signed-off-by: Rajesh Gumasta
---
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 4 +++
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 46 ++
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 44
3 files changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
index 2fcaa2e..56ed8d8 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi
@@ -54,6 +54,10 @@
};
};
+ dma@260 {
+ status = "okay";
+ };
+
memory-controller@2c0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 58100fb..91bb17e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -70,6 +70,52 @@
snps,rxpbl = <8>;
};
+ gpcdma: dma@260 {
+ compatible = "nvidia,tegra186-gpcdma";
+ reg = <0x0 0x260 0x0 0x21>;
+ resets = <&bpmp TEGRA186_RESET_GPCDMA>;
+ reset-names = "gpcdma";
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+ #dma-cells = <1>;
+ iommus = <&smmu TEGRA186_SID_GPCDMA_0>;
+ dma-coherent;
+ nvidia,start-dma-channel-index = <1>;
+ dma-channels = <31>;
+ status = "disabled";
+ };
+
aconnect {
compatible = "nvidia,tegra186-aconnect",
"nvidia,tegra210-aconnect";
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 4bc187a..0bd67bd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -68,6 +68,50 @@
snps,rxpbl = <8>;
};
+ gpcdma: dma@260 {
+ compatible = "nvidia,tegra194-gpcdma";
+ reg = <0x0 0x260 0x0 0x21>;
+ resets = <&bpmp TEGRA194_RESET_GPCDMA>;
+ reset-names = "gpcdma";
+ interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+
Re: [PATCH] drm/amdgpu: fix spelling mistake "Falied" -> "Failed"
On Thu, Aug 06, 2020 at 09:36:41AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 05 Aug 2020 15:19:38 -0700 Joe Perches wrote:
> >
> > On Wed, 2020-08-05 at 17:27 -0400, Alex Deucher wrote:
> > > On Wed, Aug 5, 2020 at 4:53 PM Joe Perches wrote:
> > > > On Wed, 2020-08-05 at 16:01 -0400, Alex Deucher wrote:
> > > > > On Wed, Aug 5, 2020 at 7:35 AM Colin King
> > > > > wrote:
> > > > > > From: Colin Ian King
> > > > > >
> > > > > > There is a spelling mistake in a DRM_ERROR message. Fix it.
> > > > > >
> > > > > > Signed-off-by: Colin Ian King
> > > > >
> > > > > This is already fixed.
> > > >
> > > > This fix is not in today's -next.
> > > >
> > > > Perhaps whatever tree it's fixed in should be in -next.
> > > >
> > >
> > > Weird. It's in the drm-next tree as:
> > >
> > > commit 4afaa61db9cf5250b5734c2531b226e7b3a3d691
> > > Author: Colin Ian King
> > > Date: Fri Jul 10 09:37:58 2020 +0100
> > >
> > > drm/amdgpu: fix spelling mistake "Falied" -> "Failed"
> > >
> > > There is a spelling mistake in a DRM_ERROR error message. Fix it.
> > >
> > > Signed-off-by: Colin Ian King
> > > Signed-off-by: Alex Deucher
> > >
> > > Alex
> > >
> > > > $ git show --oneline -s
> > > > d15fe4ec0435 (HEAD, tag: next-20200805, origin/master, origin/HEAD) Add
> > > > linux-next specific files for 20200805
> > > >
> > > > $ git grep -i falied drivers
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:
> > > > DRM_ERROR("Falied to terminate tmr\n");
> > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> > > > []
> > > > > > @@ -2010,7 +2010,7 @@ static int psp_suspend(void *handle)
> > > > > >
> > > > > > ret = psp_tmr_terminate(psp);
> > > > > > if (ret) {
> > > > > > - DRM_ERROR("Falied to terminate tmr\n");
> > > > > > + DRM_ERROR("Failed to terminate tmr\n");
> > > > > > return ret;
> > > > > > }
> >
> > Dunno.
> >
> > Maybe it's due to some ordering of trees in
> > how -next accumulates patches?
>
> The spelling error is introduced in two commits:
>
> c564b8601ae9 ("drm/amdgpu: add TMR destory function for psp")
>
> in Linus' tree between v5.8-rc4 and rc5
>
> 90937420c44f ("drm/amdgpu: add TMR destory function for psp")
>
> in the amdgpu tree between two merges by the drm tree. In this same
> interval, the error is corrected by commit
>
> 4afaa61db9cf ("drm/amdgpu: fix spelling mistake "Falied" -> "Failed"")
>
> so when David comes to merge the amdgpu tree in commit
>
> 206739119508 ("Merge tag 'amd-drm-next-5.9-2020-07-17' of
> git://people.freedesktop.org/~agd5f/linux into drm-next")
>
> the spelling error has been introduced on one side of the merge and
> introduced and corrected on the other. This would have produced a
> conflict which David presumably resolved in haste by picking the HEAD
> side of the merge instead of the MERGE_HEAD side (it happens).
>
> This could have been avoided by not cherry-picking fix commits around
> in the amdgpu process - instead having a fixes branch that is merged
> into the next branch after the fixes branch has been accepted upstream
> (that way there is only one commit for each fix and less conflicts).
>
> I have to deal with these sort of conflicts (sometimes daily) due to
> the drm processes. Its a pain as I have to track down each conflict to
> see if the same patches appear on both sides of merges and then try to
> figure out what other changes occur. (This is only slightly helped by
> have the "cherry-picked from" tags in the fix commits.)
Yeah cherry-picking breaks if you only occasionally cherry-pick - then
stuff gets lost.
I'd say just apply it once more for the merge window fixes pull.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] MIPS: Introduce cmdline argument writecombine=
在 2020/8/6 下午3:09, Tiezhu Yang 写道:
Loongson processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times,
after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine
mapping for MIPS"), there exists some errors such as blurred screen
and lockup, and so on.
With this patch, disable writecombine by default for Loongson64 to
work well with ATI Radeon or AMD GPU, and it has no influence on the
other platforms due to writecombine is enabled by default.
Additionally, if it is necessary, writecombine=on can be set manually
in the cmdline to enhance the performance for Loongson LS7A integrated
graphics in the future.
[ 60.958721] radeon :03:00.0: ring 0 stalled for more than 10079msec
[ 60.965315] radeon :03:00.0: GPU lockup (current fence id
0x0112 last fence id 0x011d on ring 0)
[ 60.976525] radeon :03:00.0: ring 3 stalled for more than 10086msec
[ 60.983156] radeon :03:00.0: GPU lockup (current fence id
0x0374 last fence id 0x03a8 on ring 3)
Hi Tiezhu,
Thanks for your patch.
Personally I didn't have any issue with writecombine on my test systems,
but there
are some complains about unstable graphic card from users. So generally
a cmdline
writecombine switch is necessary.
Signed-off-by: Tiezhu Yang
---
arch/mips/include/asm/pgtable.h | 4
arch/mips/kernel/cpu-probe.c| 19 +++
2 files changed, 23 insertions(+)
diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
index dd7a0f5..34869f7 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -473,6 +473,10 @@ static inline pgprot_t pgprot_noncached(pgprot_t _prot)
static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
{
unsigned long prot = pgprot_val(_prot);
+ extern bool mips_writecombine;
+
+ if (!mips_writecombine)
+ return pgprot_noncached(_prot);
You can simply override c->writecombine to _CACHE_UNCACHED in
cpu-probe.c with
out this kind of hijack.
/* cpu_data[0].writecombine is already shifted by _CACHE_SHIFT */
prot = (prot & ~_CACHE_MASK) | cpu_data[0].writecombine;
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index e2955f1..98777ca 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -459,6 +459,25 @@ static int __init ftlb_disable(char *s)
__setup("noftlb", ftlb_disable);
+#ifdef CONFIG_MACH_LOONGSON64
+bool mips_writecombine; /* initialise to false by default */
+#else
+bool mips_writecombine = true;
+#endif
+EXPORT_SYMBOL(mips_writecombine);
There is no need to export this symbol, see comment before.
+
+static int __init writecombine_setup(char *str)
+{
+ if (strcmp(str, "on") == 0)
+ mips_writecombine = true;
+ else if (strcmp(str, "off") == 0)
+ mips_writecombine = false;
+
+ return 1;
+}
+
+__setup("writecombine=", writecombine_setup);
Use early_param here seems more reasonable, it will be probed earlier.
+
/*
* Check if the CPU has per tc perf counters
*/
Thanks
- Jiaxun
Re: [PATCH v17 17/21] mm/lru: replace pgdat lru_lock with lruvec lock
Hi Johannes, Michal,
>From page to its lruvec, a few memory access under lock cause extra cost.
Would you like to save the per memcg lruvec pointer to page->private?
Thanks
Alex
在 2020/7/25 下午8:59, Alex Shi 写道:
> /**
> * mem_cgroup_page_lruvec - return lruvec for isolating/putting an LRU page
> * @page: the page
> @@ -1215,7 +1228,8 @@ struct lruvec *mem_cgroup_page_lruvec(struct page
> *page, struct pglist_data *pgd
> goto out;
> }
>
> - memcg = page->mem_cgroup;
> + VM_BUG_ON_PAGE(PageTail(page), page);
> + memcg = READ_ONCE(page->mem_cgroup);
> /*
>* Swapcache readahead pages are added to the LRU - and
>* possibly migrated - before they are charged.
> @@ -1236,6 +1250,51 @@ struct lruvec *mem_cgroup_page_lruvec(struct page
> *page, struct pglist_data *pgd
> return lruvec;
> }
>
> +struct lruvec *lock_page_lruvec(struct page *page)
> +{
> + struct lruvec *lruvec;
> + struct pglist_data *pgdat = page_pgdat(page);
> +
> + rcu_read_lock();
> + lruvec = mem_cgroup_page_lruvec(page, pgdat);
> + spin_lock(&lruvec->lru_lock);
> + rcu_read_unlock();
> +
> + lruvec_memcg_debug(lruvec, page);
> +
> + return lruvec;
> +}
> +
[PATCH] loop: unset GENHD_FL_NO_PART_SCAN on LOOP_CONFIGURE
When LOOP_CONFIGURE is used with LO_FLAGS_PARTSCAN we need to propagate this into the GENHD_FL_NO_PART_SCAN. LOOP_SETSTATUS does this, LOOP_CONFIGURE doesn't so far. Effect is that setting up a loopback device with partition scanning doesn't actually work when LOOP_CONFIGURE is issued, though it works fine with LOOP_SETSTATUS. Let's correct that and propagate the flag in LOOP_SETSTATUS too. Signed-off-by: Lennart Poettering --- drivers/block/loop.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index d18160146226..2f137d6ce169 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -1171,6 +1171,8 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, if (part_shift) lo->lo_flags |= LO_FLAGS_PARTSCAN; partscan = lo->lo_flags & LO_FLAGS_PARTSCAN; + if (partscan) + lo->lo_disk->flags &= ~GENHD_FL_NO_PART_SCAN; /* Grab the block_device to prevent its destruction after we * put /dev/loopXX inode. Later in __loop_clr_fd() we bdput(bdev). -- 2.26.2
[PATCH] ASoC: fsl-asoc-card: Get "extal" clock rate by clk_get_rate
On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
with the mclk of codec, then the clock rate is also different.
So it is better to get clock rate of "extal" rate by clk_get_rate,
don't reuse the clock rate of mclk.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/fsl-asoc-card.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 52adedc03245..2c92a5efad61 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -696,6 +696,13 @@ static int fsl_asoc_card_probe(struct platform_device
*pdev)
goto asrc_fail;
}
} else if (of_node_name_eq(cpu_np, "esai")) {
+ struct clk *esai_clk = clk_get(&cpu_pdev->dev, "extal");
+
+ if (!IS_ERR(esai_clk)) {
+ priv->cpu_priv.sysclk_freq[TX] = clk_get_rate(esai_clk);
+ priv->cpu_priv.sysclk_freq[RX] = clk_get_rate(esai_clk);
+ clk_put(esai_clk);
+ }
priv->cpu_priv.sysclk_id[1] = ESAI_HCKT_EXTAL;
priv->cpu_priv.sysclk_id[0] = ESAI_HCKR_EXTAL;
} else if (of_node_name_eq(cpu_np, "sai")) {
--
2.27.0
Re: [PATCH v4] mm/hugetlb: add mempolicy check in the reservation routine
On Tue, Jul 28, 2020 at 11:49 AM Muchun Song wrote:
>
> In the reservation routine, we only check whether the cpuset meets
> the memory allocation requirements. But we ignore the mempolicy of
> MPOL_BIND case. If someone mmap hugetlb succeeds, but the subsequent
> memory allocation may fail due to mempolicy restrictions and receives
> the SIGBUS signal. This can be reproduced by the follow steps.
>
> 1) Compile the test case.
> cd tools/testing/selftests/vm/
> gcc map_hugetlb.c -o map_hugetlb
>
> 2) Pre-allocate huge pages. Suppose there are 2 numa nodes in the
> system. Each node will pre-allocate one huge page.
> echo 2 > /proc/sys/vm/nr_hugepages
>
> 3) Run test case(mmap 4MB). We receive the SIGBUS signal.
> numactl --membind=0 ./map_hugetlb 4
>
> With this patch applied, the mmap will fail in the step 3) and throw
> "mmap: Cannot allocate memory".
>
> Signed-off-by: Muchun Song
> Reported-by: Jianchao Guo
> Suggested-by: Michal Hocko
> Reviewed-by: Mike Kravetz
Hi Andrew,
Any comments or forgot to add this to the queue for the
merge window?
> ---
> changelog in v4:
> 1) Fix compilation errors with !CONFIG_NUMA.
>
> changelog in v3:
> 1) Do not allocate nodemask on the stack.
> 2) Update comment.
>
> changelog in v2:
> 1) Reuse policy_nodemask().
>
> include/linux/mempolicy.h | 14 ++
> mm/hugetlb.c | 22 ++
> mm/mempolicy.c| 2 +-
> 3 files changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
> index ea9c15b60a96..0656ece1ccf1 100644
> --- a/include/linux/mempolicy.h
> +++ b/include/linux/mempolicy.h
> @@ -152,6 +152,15 @@ extern int huge_node(struct vm_area_struct *vma,
> extern bool init_nodemask_of_mempolicy(nodemask_t *mask);
> extern bool mempolicy_nodemask_intersects(struct task_struct *tsk,
> const nodemask_t *mask);
> +extern nodemask_t *policy_nodemask(gfp_t gfp, struct mempolicy *policy);
> +
> +static inline nodemask_t *policy_nodemask_current(gfp_t gfp)
> +{
> + struct mempolicy *mpol = get_task_policy(current);
> +
> + return policy_nodemask(gfp, mpol);
> +}
> +
> extern unsigned int mempolicy_slab_node(void);
>
> extern enum zone_type policy_zone;
> @@ -281,5 +290,10 @@ static inline int mpol_misplaced(struct page *page,
> struct vm_area_struct *vma,
> static inline void mpol_put_task_policy(struct task_struct *task)
> {
> }
> +
> +static inline nodemask_t *policy_nodemask_current(gfp_t gfp)
> +{
> + return NULL;
> +}
> #endif /* CONFIG_NUMA */
> #endif
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 589c330df4db..a34458f6a475 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3463,13 +3463,21 @@ static int __init default_hugepagesz_setup(char *s)
> }
> __setup("default_hugepagesz=", default_hugepagesz_setup);
>
> -static unsigned int cpuset_mems_nr(unsigned int *array)
> +static unsigned int allowed_mems_nr(struct hstate *h)
> {
> int node;
> unsigned int nr = 0;
> + nodemask_t *mpol_allowed;
> + unsigned int *array = h->free_huge_pages_node;
> + gfp_t gfp_mask = htlb_alloc_mask(h);
> +
> + mpol_allowed = policy_nodemask_current(gfp_mask);
>
> - for_each_node_mask(node, cpuset_current_mems_allowed)
> - nr += array[node];
> + for_each_node_mask(node, cpuset_current_mems_allowed) {
> + if (!mpol_allowed ||
> + (mpol_allowed && node_isset(node, *mpol_allowed)))
> + nr += array[node];
> + }
>
> return nr;
> }
> @@ -3648,12 +3656,18 @@ static int hugetlb_acct_memory(struct hstate *h, long
> delta)
> * we fall back to check against current free page availability as
> * a best attempt and hopefully to minimize the impact of changing
> * semantics that cpuset has.
> +*
> +* Apart from cpuset, we also have memory policy mechanism that
> +* also determines from which node the kernel will allocate memory
> +* in a NUMA system. So similar to cpuset, we also should consider
> +* the memory policy of the current task. Similar to the description
> +* above.
> */
> if (delta > 0) {
> if (gather_surplus_pages(h, delta) < 0)
> goto out;
>
> - if (delta > cpuset_mems_nr(h->free_huge_pages_node)) {
> + if (delta > allowed_mems_nr(h)) {
> return_unused_surplus_pages(h, delta);
> goto out;
> }
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 93fcfc1f2fa2..fce14c3f4f38 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -1873,7 +1873,7 @@ static int apply_policy_zone(struct mempolicy *policy,
> enum zone_type zone)
> * Return a nodemask representing a mempolicy for filtering nodes for
> * page allocation
> */
> -stati
Re: [PATCH] x86/paravirt: Add missing noinstr to arch_local*() helpers
On Wed, Aug 05, 2020 at 07:31PM +0200, Marco Elver wrote:
...
> Oh well, it seems that KCSAN on syzbot still crashes even with this
> "fix". It's harder to reproduce though, and I don't have a clear
> reproducer other than "fuzz the kernel" right now. I think the new IRQ
> state tracking code is still not compatible with KCSAN, even though we
> thought it would be. Most likely there are still ways to get recursion
> lockdep->KCSAN. An alternative would be to deal with the recursion
> like we did before, instead of trying to squash all of it. I'll try to
> investigate -- Peter, if you have ideas, help is appreciated.
Testing my hypothesis that raw then nested non-raw
local_irq_save/restore() breaks IRQ state tracking -- see the reproducer
below. This is at least 1 case I can think of that we're bound to hit.
Thanks,
-- Marco
-- >8 --
diff --git a/init/main.c b/init/main.c
index 15bd0efff3df..0873319dcff4 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1041,6 +1041,22 @@ asmlinkage __visible void __init start_kernel(void)
sfi_init_late();
kcsan_init();
+ /* DEBUG CODE */
+ lockdep_assert_irqs_enabled(); /* Pass. */
+ {
+ unsigned long flags1;
+ raw_local_irq_save(flags1);
+ {
+ unsigned long flags2;
+ lockdep_assert_irqs_enabled(); /* Pass - expectedly
blind. */
+ local_irq_save(flags2);
+ lockdep_assert_irqs_disabled(); /* Pass. */
+ local_irq_restore(flags2);
+ }
+ raw_local_irq_restore(flags1);
+ }
+ lockdep_assert_irqs_enabled(); /* FAIL! */
+
/* Do the rest non-__init'ed, we're now alive */
arch_call_rest_init();
Re: [PATCH] drivers/net/wan/lapbether: Added needed_headroom and a skb->len check
On Thu, Aug 6, 2020 at 3:51 AM Xie He wrote: > > 1. Added a skb->len check > > This driver expects upper layers to include a pseudo header of 1 byte > when passing down a skb for transmission. This driver will read this > 1-byte header. This patch added a skb->len check before reading the > header to make sure the header exists. > > 2. Changed to use needed_headroom instead of hard_header_len to request > necessary headroom to be allocated > > In net/packet/af_packet.c, the function packet_snd first reserves a > headroom of length (dev->hard_header_len + dev->needed_headroom). > Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header, > which calls dev->header_ops->create, to create the link layer header. > If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of > length (dev->hard_header_len), and assumes the user to provide the > appropriate link layer header. > > So according to the logic of af_packet.c, dev->hard_header_len should > be the length of the header that would be created by > dev->header_ops->create. > > However, this driver doesn't provide dev->header_ops, so logically > dev->hard_header_len should be 0. > > So we should use dev->needed_headroom instead of dev->hard_header_len > to request necessary headroom to be allocated. > > This change fixes kernel panic when this driver is used with AF_PACKET > SOCK_RAW sockets. > > Call stack when panic: > > [ 168.399197] skbuff: skb_under_panic: text:819d95fb len:20 > put:14 head:8882704c0a00 data:8882704c09fd tail:0x11 end:0xc0 > dev:veth0 > ... > [ 168.399255] Call Trace: > [ 168.399259] skb_push.cold+0x14/0x24 > [ 168.399262] eth_header+0x2b/0xc0 > [ 168.399267] lapbeth_data_transmit+0x9a/0xb0 [lapbether] > [ 168.399275] lapb_data_transmit+0x22/0x2c [lapb] > [ 168.399277] lapb_transmit_buffer+0x71/0xb0 [lapb] > [ 168.399279] lapb_kick+0xe3/0x1c0 [lapb] > [ 168.399281] lapb_data_request+0x76/0xc0 [lapb] > [ 168.399283] lapbeth_xmit+0x56/0x90 [lapbether] > [ 168.399286] dev_hard_start_xmit+0x91/0x1f0 > [ 168.399289] ? irq_init_percpu_irqstack+0xc0/0x100 > [ 168.399291] __dev_queue_xmit+0x721/0x8e0 > [ 168.399295] ? packet_parse_headers.isra.0+0xd2/0x110 > [ 168.399297] dev_queue_xmit+0x10/0x20 > [ 168.399298] packet_sendmsg+0xbf0/0x19b0 > .. > > Cc: Willem de Bruijn > Cc: Martin Schiller > Cc: Brian Norris > Signed-off-by: Xie He Acked-by: Willem de Bruijn The in-band signal byte is required, but stripped by lapbeth_xmit. Subsequent code will prefix additional headers, including an Ethernet link layer. The extra space needs to be reserved, but not pulled in packet_snd with skb_reserve, so has to use needed_headroom instead of hard_header_len.
[PATCH net-next] hinic: fix strncpy output truncated compile warnings
fix the compile warnings of 'strncpy' output truncated before
terminating nul copying N bytes from a string of the same length
Signed-off-by: Luo bin
Reported-by: kernel test robot
---
drivers/net/ethernet/huawei/hinic/hinic_devlink.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
index c6adc776f3c8..1dc948c07b94 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
@@ -342,9 +342,9 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
level = event->event.chip.err_level;
if (level < FAULT_LEVEL_MAX)
- strncpy(level_str, fault_level[level],
strlen(fault_level[level]));
+ strncpy(level_str, fault_level[level],
strlen(fault_level[level]) + 1);
else
- strncpy(level_str, "Unknown", strlen("Unknown"));
+ strncpy(level_str, "Unknown", sizeof(level_str));
if (level == FAULT_LEVEL_SERIOUS_FLR) {
err = devlink_fmsg_u32_pair_put(fmsg, "Function level err
func_id",
@@ -388,9 +388,9 @@ static int fault_report_show(struct devlink_fmsg *fmsg,
int err;
if (event->type < FAULT_TYPE_MAX)
- strncpy(type_str, fault_type[event->type],
strlen(fault_type[event->type]));
+ strncpy(type_str, fault_type[event->type],
strlen(fault_type[event->type]) + 1);
else
- strncpy(type_str, "Unknown", strlen("Unknown"));
+ strncpy(type_str, "Unknown", sizeof(type_str));
err = devlink_fmsg_string_pair_put(fmsg, "Fault type", type_str);
if (err)
--
2.17.1
Re: [PATCH v3 0/3] io_uring: add restrictions to support untrusted applications and guests
Gentle ping. I'll rebase on master, but if there are any things that I can improve, I'll be happy to do. Thanks, Stefano On Tue, Jul 28, 2020 at 06:00:58PM +0200, Stefano Garzarella wrote: > v3: > - added IORING_RESTRICTION_SQE_FLAGS_ALLOWED and >IORING_RESTRICTION_SQE_FLAGS_REQUIRED > - removed IORING_RESTRICTION_FIXED_FILES_ONLY opcode > - enabled restrictions only when the rings start > > RFC v2: > https://lore.kernel.org/io-uring/20200716124833.93667-1-sgarz...@redhat.com > > RFC v1: > https://lore.kernel.org/io-uring/20200710141945.129329-1-sgarz...@redhat.com > > Following the proposal that I send about restrictions [1], I wrote this series > to add restrictions in io_uring. > > I also wrote helpers in liburing and a test case > (test/register-restrictions.c) > available in this repository: > https://github.com/stefano-garzarella/liburing (branch: io_uring_restrictions) > > Just to recap the proposal, the idea is to add some restrictions to the > operations (sqe opcode and flags, register opcode) to safely allow untrusted > applications or guests to use io_uring queues. > > The first patch changes io_uring_register(2) opcodes into an enumeration to > keep track of the last opcode available. > > The second patch adds IOURING_REGISTER_RESTRICTIONS opcode and the code to > handle restrictions. > > The third patch adds IORING_SETUP_R_DISABLED flag to start the rings disabled, > allowing the user to register restrictions, buffers, files, before to start > processing SQEs. > > Comments and suggestions are very welcome. > > Thank you in advance, > Stefano > > [1] > https://lore.kernel.org/io-uring/20200609142406.upuwpfmgqjeji4lc@steredhat/ > > Stefano Garzarella (3): > io_uring: use an enumeration for io_uring_register(2) opcodes > io_uring: add IOURING_REGISTER_RESTRICTIONS opcode > io_uring: allow disabling rings during the creation > > fs/io_uring.c | 167 -- > include/uapi/linux/io_uring.h | 60 +--- > 2 files changed, 207 insertions(+), 20 deletions(-) > > -- > 2.26.2 >
[PATCH 1/2] selinux: add tracepoint on denials
The audit data currently captures which process and which target
is responsible for a denial. There is no data on where exactly in the
process that call occurred. Debugging can be made easier by being able to
reconstruct the unified kernel and userland stack traces [1]. Add a
tracepoint on the SELinux denials which can then be used by userland
(i.e. perf).
Although this patch could manually be added by each OS developer to
trouble shoot a denial, adding it to the kernel streamlines the
developers workflow.
[1] https://source.android.com/devices/tech/debug/native_stack_dump
Signed-off-by: Thiébaud Weksteen
Suggested-by: Joel Fernandes
Reviewed-by: Peter Enderborg
---
MAINTAINERS| 1 +
include/trace/events/avc.h | 37 +
security/selinux/avc.c | 5 +
3 files changed, 43 insertions(+)
create mode 100644 include/trace/events/avc.h
diff --git a/MAINTAINERS b/MAINTAINERS
index c8e8232c65da..0efaea0e144c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15426,6 +15426,7 @@ T: git
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
F: Documentation/ABI/obsolete/sysfs-selinux-checkreqprot
F: Documentation/ABI/obsolete/sysfs-selinux-disable
F: Documentation/admin-guide/LSM/SELinux.rst
+F: include/trace/events/avc.h
F: include/uapi/linux/selinux_netlink.h
F: scripts/selinux/
F: security/selinux/
diff --git a/include/trace/events/avc.h b/include/trace/events/avc.h
new file mode 100644
index ..07c058a9bbcd
--- /dev/null
+++ b/include/trace/events/avc.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Author: Thiébaud Weksteen
+ */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM avc
+
+#if !defined(_TRACE_SELINUX_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_SELINUX_H
+
+#include
+
+TRACE_EVENT(selinux_audited,
+
+ TP_PROTO(struct selinux_audit_data *sad),
+
+ TP_ARGS(sad),
+
+ TP_STRUCT__entry(
+ __field(unsigned int, tclass)
+ __field(unsigned int, audited)
+ ),
+
+ TP_fast_assign(
+ __entry->tclass = sad->tclass;
+ __entry->audited = sad->audited;
+ ),
+
+ TP_printk("tclass=%u audited=%x",
+ __entry->tclass,
+ __entry->audited)
+);
+
+#endif
+
+/* This part must be outside protection */
+#include
diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index d18cb32a242a..b0a0af778b70 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -31,6 +31,9 @@
#include "avc_ss.h"
#include "classmap.h"
+#define CREATE_TRACE_POINTS
+#include
+
#define AVC_CACHE_SLOTS512
#define AVC_DEF_CACHE_THRESHOLD512
#define AVC_CACHE_RECLAIM 16
@@ -706,6 +709,8 @@ static void avc_audit_post_callback(struct audit_buffer
*ab, void *a)
u32 scontext_len;
int rc;
+ trace_selinux_audited(sad);
+
rc = security_sid_to_context(sad->state, sad->ssid, &scontext,
&scontext_len);
if (rc)
--
2.28.0.163.g6104cc2f0b6-goog
[PATCH 2/2] selinux: add attributes to avc tracepoint
From: Peter Enderborg
Add further attributes to filter the trace events from AVC.
Signed-off-by: Peter Enderborg
Reviewed-by: Thiébaud Weksteen
---
include/trace/events/avc.h | 41 --
security/selinux/avc.c | 22 +++-
2 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/include/trace/events/avc.h b/include/trace/events/avc.h
index 07c058a9bbcd..ac5ef2e1c2c5 100644
--- a/include/trace/events/avc.h
+++ b/include/trace/events/avc.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * Author: Thiébaud Weksteen
+ * Authors:Thiébaud Weksteen
+ * Peter Enderborg
*/
#undef TRACE_SYSTEM
#define TRACE_SYSTEM avc
@@ -12,23 +13,43 @@
TRACE_EVENT(selinux_audited,
- TP_PROTO(struct selinux_audit_data *sad),
+ TP_PROTO(struct selinux_audit_data *sad,
+ char *scontext,
+ char *tcontext,
+ const char *tclass
+ ),
- TP_ARGS(sad),
+ TP_ARGS(sad, scontext, tcontext, tclass),
TP_STRUCT__entry(
- __field(unsigned int, tclass)
- __field(unsigned int, audited)
+ __field(u32, requested)
+ __field(u32, denied)
+ __field(u32, audited)
+ __field(int, result)
+ __string(scontext, scontext)
+ __string(tcontext, tcontext)
+ __string(tclass, tclass)
+ __field(u32, ssid)
+ __field(u32, tsid)
),
TP_fast_assign(
- __entry->tclass = sad->tclass;
- __entry->audited = sad->audited;
+ __entry->requested = sad->requested;
+ __entry->denied = sad->denied;
+ __entry->audited= sad->audited;
+ __entry->result = sad->result;
+ __entry->ssid = sad->ssid;
+ __entry->tsid = sad->tsid;
+ __assign_str(tcontext, tcontext);
+ __assign_str(scontext, scontext);
+ __assign_str(tclass, tclass);
),
- TP_printk("tclass=%u audited=%x",
- __entry->tclass,
- __entry->audited)
+ TP_printk("requested=0x%x denied=0x%x audited=0x%x result=%d ssid=%u
tsid=%u scontext=%s tcontext=%s tclass=%s",
+ __entry->requested, __entry->denied, __entry->audited,
__entry->result,
+ __entry->ssid, __entry->tsid, __get_str(scontext),
__get_str(tcontext),
+ __get_str(tclass)
+ )
);
#endif
diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index b0a0af778b70..7de5cc5169af 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -705,35 +705,39 @@ static void avc_audit_post_callback(struct audit_buffer
*ab, void *a)
{
struct common_audit_data *ad = a;
struct selinux_audit_data *sad = ad->selinux_audit_data;
- char *scontext;
+ char *scontext = NULL;
+ char *tcontext = NULL;
+ const char *tclass = NULL;
u32 scontext_len;
+ u32 tcontext_len;
int rc;
- trace_selinux_audited(sad);
-
rc = security_sid_to_context(sad->state, sad->ssid, &scontext,
&scontext_len);
if (rc)
audit_log_format(ab, " ssid=%d", sad->ssid);
else {
audit_log_format(ab, " scontext=%s", scontext);
- kfree(scontext);
}
- rc = security_sid_to_context(sad->state, sad->tsid, &scontext,
-&scontext_len);
+ rc = security_sid_to_context(sad->state, sad->tsid, &tcontext,
+&tcontext_len);
if (rc)
audit_log_format(ab, " tsid=%d", sad->tsid);
else {
- audit_log_format(ab, " tcontext=%s", scontext);
- kfree(scontext);
+ audit_log_format(ab, " tcontext=%s", tcontext);
}
- audit_log_format(ab, " tclass=%s", secclass_map[sad->tclass-1].name);
+ tclass = secclass_map[sad->tclass-1].name;
+ audit_log_format(ab, " tclass=%s", tclass);
if (sad->denied)
audit_log_format(ab, " permissive=%u", sad->result ? 0 : 1);
+ trace_selinux_audited(sad, scontext, tcontext, tclass);
+ kfree(tcontext);
+ kfree(scontext);
+
/* in case of invalid context report also the actual context string */
rc = security_sid_to_context_inval(sad->state, sad->ssid, &scontext,
&scontext_len);
--
2.28.0.163.g6104cc2f0b6-goog
Re: [PATCH] MIPS: SGI-IP27: always enable NUMA in Kconfig
On Wed, Aug 05, 2020 at 03:51:41PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> When a configuration has NUMA disabled and SGI_IP27 enabled, the build
> fails:
>
> CC kernel/bounds.s
> CC arch/mips/kernel/asm-offsets.s
> In file included from arch/mips/include/asm/topology.h:11,
> from include/linux/topology.h:36,
> from include/linux/gfp.h:9,
> from include/linux/slab.h:15,
> from include/linux/crypto.h:19,
> from include/crypto/hash.h:11,
> from include/linux/uio.h:10,
> from include/linux/socket.h:8,
> from include/linux/compat.h:15,
> from arch/mips/kernel/asm-offsets.c:12:
> include/linux/topology.h: In function 'numa_node_id':
> arch/mips/include/asm/mach-ip27/topology.h:16:27: error: implicit declaration
> of function 'cputonasid'; did you mean 'cpu_vpe_id'?
> [-Werror=implicit-function-declaration]
> #define cpu_to_node(cpu) (cputonasid(cpu))
>^~
> include/linux/topology.h:119:9: note: in expansion of macro 'cpu_to_node'
> return cpu_to_node(raw_smp_processor_id());
> ^~~
> include/linux/topology.h: In function 'cpu_cpu_mask':
> arch/mips/include/asm/mach-ip27/topology.h:19:7: error: implicit declaration
> of function 'hub_data' [-Werror=implicit-function-declaration]
> &hub_data(node)->h_cpus)
>^~~~
> include/linux/topology.h:210:9: note: in expansion of macro 'cpumask_of_node'
> return cpumask_of_node(cpu_to_node(cpu));
> ^~~
> arch/mips/include/asm/mach-ip27/topology.h:19:21: error: invalid type
> argument of '->' (have 'int')
> &hub_data(node)->h_cpus)
> ^~
> include/linux/topology.h:210:9: note: in expansion of macro 'cpumask_of_node'
> return cpumask_of_node(cpu_to_node(cpu));
> ^~~
>
> Before switch from discontigmem to sparsemem, there always was
> CONFIG_NEED_MULTIPLE_NODES=y because it was selected by DISCONTIGMEM.
> Without DISCONTIGMEM it is possible to have SPARSEMEM without NUMA for
> SGI_IP27 and as many things there rely on custom node definition, the
> build breaks.
>
> As Thomas noted "... there are right now too many places in IP27 code,
> which assumes NUMA enabled", the simplest solution would be to always
> enable NUMA for SGI-IP27 builds.
>
> Reported-by: kernel test robot
> Fixes: 397dc00e249e ("mips: sgi-ip27: switch from DISCONTIGMEM to SPARSEMEM")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Mike Rapoport
> ---
> arch/mips/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH 00/23] proc: Introduce /proc/namespaces/ directory to expose namespaces lineary
On Mon, Aug 03, 2020 at 01:03:17PM +0300, Kirill Tkhai wrote: > On 31.07.2020 01:13, Eric W. Biederman wrote: > > Kirill Tkhai writes: > > > >> On 30.07.2020 17:34, Eric W. Biederman wrote: > >>> Kirill Tkhai writes: > >>> > Currently, there is no a way to list or iterate all or subset of > namespaces > in the system. Some namespaces are exposed in /proc/[pid]/ns/ > directories, > but some also may be as open files, which are not attached to a process. > When a namespace open fd is sent over unix socket and then closed, it is > impossible to know whether the namespace exists or not. > > Also, even if namespace is exposed as attached to a process or as open > file, > iteration over /proc/*/ns/* or /proc/*/fd/* namespaces is not fast, > because > this multiplies at tasks and fds number. > >>> > >>> I am very dubious about this. > >>> > >>> I have been avoiding exactly this kind of interface because it can > >>> create rather fundamental problems with checkpoint restart. > >> > >> restart/restore :) > >> > >>> You do have some filtering and the filtering is not based on current. > >>> Which is good. > >>> > >>> A view that is relative to a user namespace might be ok.It almost > >>> certainly does better as it's own little filesystem than as an extension > >>> to proc though. > >>> > >>> The big thing we want to ensure is that if you migrate you can restore > >>> everything. I don't see how you will be able to restore these files > >>> after migration. Anything like this without having a complete > >>> checkpoint/restore story is a non-starter. > >> > >> There is no difference between files in /proc/namespaces/ directory and > >> /proc/[pid]/ns/. > >> > >> CRIU can restore open files in /proc/[pid]/ns, the same will be with > >> /proc/namespaces/ files. > >> As a person who worked deeply for pid_ns and user_ns support in CRIU, I > >> don't see any > >> problem here. > > > > An obvious diffference is that you are adding the inode to the inode to > > the file name. Which means that now you really do have to preserve the > > inode numbers during process migration. > > > > Which means now we have to do all of the work to make inode number > > restoration possible. Which means now we need to have multiple > > instances of nsfs so that we can restore inode numbers. > > > > I think this is still possible but we have been delaying figuring out > > how to restore inode numbers long enough that may be actual technical > > problems making it happen. > > Yeah, this matters. But it looks like here is not a dead end. We just need > change the names the namespaces are exported to particular fs and to support > rename(). > > Before introduction a principally new filesystem type for this, can't > this be solved in current /proc? do you mean to introduce names for namespaces which users will be able to change? By default, this can be uuid. And I have a suggestion about the structure of /proc/namespaces/. Each namespace is owned by one of user namespaces. Maybe it makes sense to group namespaces by their user-namespaces? /proc/namespaces/ user mnt-X mnt-Y pid-X uts-Z user-X/ user mnt-A mnt-B user-C user-C/ user user-Y/ user Do we try to invent cgroupfs for namespaces? Thanks, Andrei
Re: [PATCH v4 00/14] liblockdep fixes for 5.9-rc1
* Sasha Levin wrote: > Hi Linus, > > Please consider applying these patches for liblockdep, or alternatively > pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git > tags/liblockdep-fixes-040820 > > The patches fix up compilation and functionality of liblockdep on 5.8, > they were tested using liblockdep's internal testsuite. > > I was unable to get the x86 folks to pull these fixes for the past few > months: So the primary reason I didn't pull is that liblockdep was permanently build-broken from February 2019 to around February 2020, despite me pinging you multiple times about it. > - https://lkml.org/lkml/2020/2/17/1089 This pull request still said that if fixes "most of" liblockdep, not "all of", which is the benchmark really after such a long series of breakage. > - https://lkml.org/lkml/2020/4/18/817 This still said "most of". > - https://lkml.org/lkml/2020/6/22/1262 Same 'most of' verbiage. > Which is why this pull request ends up going straight to you. So at this point I think we need to ask whether it's worth it: are there any actual users of liblockdep, besides the testcases in liblockdep itself? I see there's a 'liblockdep-dev' package for Debian, but not propagated to Ubuntu or other popular variants AFAICS. Also, could you please specify whether all bugs are fixed or just 'most'? > Sasha Levin (14): > tools headers: Add kprobes.h header > tools headers: Add rcupdate.h header > tools/kernel.h: extend with dummy RCU functions > tools bitmap: add bitmap_andnot definition > tools/lib/lockdep: add definition required for IRQ flag tracing > tools bitmap: add bitmap_clear definition > tools/lib/lockdep: Hook up vsprintf, find_bit, hweight libraries > tools/lib/lockdep: Enable building with CONFIG_TRACE_IRQFLAGS > tools/lib/lockdep: New stacktrace API > tools/lib/lockdep: call lockdep_init_task on init > tools/lib/lockdep: switch to using lockdep_init_map_waits > tools/kernel.h: hide noinstr > tools/lib/lockdep: explicitly declare lockdep_init_task() > tools/kernel.h: hide task_struct.hardirq_chain_key Style nits, please use consistent titles for patches: - First word should be capitalized consistently, instead of mismash of lower case mixed with upper case. - First word should preferably be a verb, i.e. "Add new stacktrace API stubs", not "New stacktrace API" Also, please always check linux-next whether there's some new upstream changes that liblockdep needs to adapt to. Right now there's a new build breakage even with all your fixes applied: thule:~/tip/tools/lib/lockdep> make CC common.o In file included from ../../include/linux/lockdep.h:24, from common.c:5: ../../include/linux/../../../include/linux/lockdep.h:13:10: fatal error: linux/lockdep_types.h: No such file or directory 13 | #include | ^~~ At which point we need to step back and analyze the development model: this comparatively high rate of breakage derives from the unorthodox direct coupling of a kernel subsystem to a user-space library. The solution for that would be to use the method how perf syncs to kernel space headers, by maintaining a 100% copy in tools/include/ and having automatic mechanism that warns about out of sync headers but doesn't break functionality. See tools/perf/check-headers.sh for details. I believe this same half-automated sync-on-upstream-changes model could be used for liblockdep as well, i.e. lets copy kernel/lockdep.c and lockdep*.h over to tools/lib/lockdep/, and reuse the perf header syncing method to keep it synchronized from that point on. That would result in a far more maintainable liblockdep end result IMO? Thanks, Ingo
Re: [PATCHv2 2/2] hwrng: optee: fix wait use case
On 06/08/20, Sumit Garg wrote:
> On Thu, 6 Aug 2020 at 12:00, Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > On 06/08/20, Sumit Garg wrote:
> > > On Thu, 6 Aug 2020 at 02:08, Jorge Ramirez-Ortiz, Foundries
> > > wrote:
> > > >
> > > > On 05/08/20, Sumit Garg wrote:
> > > > > Apologies for my delayed response as I was busy with some other tasks
> > > > > along with holidays.
> > > >
> > > > no pb! was just making sure this wasnt falling through some cracks.
> > > >
> > > > >
> > > > > On Fri, 24 Jul 2020 at 19:53, Jorge Ramirez-Ortiz, Foundries
> > > > > wrote:
> > > > > >
> > > > > > On 24/07/20, Sumit Garg wrote:
> > > > > > > On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > The current code waits for data to be available before
> > > > > > > > attempting a
> > > > > > > > second read. However the second read would not be executed as
> > > > > > > > the
> > > > > > > > while loop exits.
> > > > > > > >
> > > > > > > > This fix does not wait if all data has been read and reads a
> > > > > > > > second
> > > > > > > > time if only partial data was retrieved on the first read.
> > > > > > > >
> > > > > > > > This fix also does not attempt to read if not data is requested.
> > > > > > >
> > > > > > > I am not sure how this is possible, can you elaborate?
> > > > > >
> > > > > > currently, if the user sets max 0, get_optee_rng_data will
> > > > > > regardless
> > > > > > issuese a call to the secure world requesting 0 bytes from the RNG
> > > > > >
> > > > >
> > > > > This case is already handled by core API: rng_dev_read().
> > > >
> > > > ah ok good point, you are right
> > > > but yeah, there is no consequence to the actual patch.
> > > >
> > >
> > > So, at least you could get rid of the corresponding text from commit
> > > message.
> > >
> > > > >
> > > > > > with this patch, this request is avoided.
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Signed-off-by: Jorge Ramirez-Ortiz
> > > > > > > > ---
> > > > > > > > v2: tidy up the while loop to avoid reading when no data is
> > > > > > > > requested
> > > > > > > >
> > > > > > > > drivers/char/hw_random/optee-rng.c | 4 ++--
> > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/char/hw_random/optee-rng.c
> > > > > > > > b/drivers/char/hw_random/optee-rng.c
> > > > > > > > index 5bc4700c4dae..a99d82949981 100644
> > > > > > > > --- a/drivers/char/hw_random/optee-rng.c
> > > > > > > > +++ b/drivers/char/hw_random/optee-rng.c
> > > > > > > > @@ -122,14 +122,14 @@ static int optee_rng_read(struct hwrng
> > > > > > > > *rng, void *buf, size_t max, bool wait)
> > > > > > > > if (max > MAX_ENTROPY_REQ_SZ)
> > > > > > > > max = MAX_ENTROPY_REQ_SZ;
> > > > > > > >
> > > > > > > > - while (read == 0) {
> > > > > > > > + while (read < max) {
> > > > > > > > rng_size = get_optee_rng_data(pvt_data, data,
> > > > > > > > (max - read));
> > > > > > > >
> > > > > > > > data += rng_size;
> > > > > > > > read += rng_size;
> > > > > > > >
> > > > > > > > if (wait && pvt_data->data_rate) {
> > > > > > > > - if (timeout-- == 0)
> > > > > > > > + if ((timeout-- == 0) || (read == max))
> > > > > > >
> > > > > > > If read == max, would there be any sleep?
> > > > > >
> > > > > > no but I see no reason why there should be a wait since we already
> > > > > > have
> > > > > > all the data that we need; the msleep is only required when we need
> > > > > > to
> > > > > > wait for the RNG to generate entropy for the number of bytes we are
> > > > > > requesting. if we are requesting 0 bytes, the entropy is already
> > > > > > available. at leat this is what makes sense to me.
> > > > > >
> > > > >
> > > > > Wouldn't it lead to a call as msleep(0); that means no wait as well?
> > > >
> > > > I dont understand: there is no reason to wait if read == max and this
> > > > patch will not wait: if read == max it calls 'return read'
> > > >
> > > > am I misunderstanding your point?
> > >
> > > What I mean is that we shouldn't require this extra check here as
> > > there wasn't any wait if read == max with existing implementation too.
> >
> > um, I am getting confused Sumit
> >
> > with the exisiting implementation (the one we aim to replace), if
> > get_optee_rng_data reads all the values requested on the first call (ie,
> > read = 0) with wait set to true, the call will wait with msleep(0). Which
> > is unnecessary and waits for a jiffy (ie, the call to msleep 0 will
> > schedule a one jiffy timeout interrruptible)
> >
> > with this alternative implementation, msleep(0) does not get called.
> >
> > are we in synch?
>
> Ah, I see msleep(0) also by default schedules timeout for 1 jiffy. So
> we are in sync now. Probably you can clarify this in commit message as
> well to avoid confusion.
ok will do.
s
Re: [PATCH v2] MIPS: Provide Kconfig option for default IEEE 754 conformance mode
On Wed, Aug 05, 2020 at 09:59:15PM +0800, Jiaxun Yang wrote: > > > 在 2020/8/1 14:11, Jiaxun Yang 写道: > >Requested by downstream distros, a Kconfig option for default > >IEEE 754 conformance mode allows them to set their mode to > >relaxed by default. > > > >Signed-off-by: Jiaxun Yang > >Reviewed-by: WANG Xuerui > >Reviewed-by: Serge Semin > >Reviewed-by: Huacai Chen > > > >-- > >v2: Reword according to Xuerui's suggestion. > >--- > Hi Thomas, > > Is it possible to get this patch into 5.9 merge window? > I think it have got enough review tag, and the config option was requested > by a Debian developer. The next Debian release will take 5.9 lts kernel and > they don't want to ship a non-bootable kernel in a major release. no I won't include it into 5.9, I need to first go through links pointed to by Maciej and fully understand what a proper solution could be. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
[PATCH v3 1/3] syscalls: use uaccess_kernel in addr_limit_user_check
From: Christoph Hellwig Patch series "clean up address limit helpers", v2. In preparation for eventually phasing out direct use of set_fs(), this series removes the segment_eq() arch helper that is only used to implement or duplicate the uaccess_kernel() API, and then adds descriptive helpers to force the kernel address limit. This patch (of 6): Use the uaccess_kernel helper instead of duplicating it. Link: http://lkml.kernel.org/r/20200714105505.935079-1-...@lst.de Link: http://lkml.kernel.org/r/20200710135706.537715-1-...@lst.de Link: http://lkml.kernel.org/r/20200710135706.537715-2-...@lst.de Signed-off-by: Christoph Hellwig Acked-by: Linus Torvalds Cc: Nick Hu Cc: Greentime Hu Cc: Vincent Chen Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Stephen Rothwell --- include/linux/syscalls.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index b951a87da987..e933a43d4a69 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -263,7 +263,7 @@ static inline void addr_limit_user_check(void) return; #endif - if (CHECK_DATA_CORRUPTION(!segment_eq(get_fs(), USER_DS), + if (CHECK_DATA_CORRUPTION(uaccess_kernel(), "Invalid address limit on user-mode return")) force_sig(SIGKILL); -- 2.25.0
[PATCH v3 3/3] powerpc/uaccess: simplify the get_fs() set_fs() logic
On powerpc, we only have USER_DS and KERNEL_DS
Today, this is managed as an 'unsigned long' data space limit
which is used to compare the passed address with, plus a bit
in the thread_info flags that is set whenever modifying the limit
to enable the verification in addr_limit_user_check()
The limit is either the last address of user space when USER_DS is
set, and the last address of address space when KERNEL_DS is set.
In both cases, the limit is a compiletime constant.
get_fs() returns the limit, which is part of thread_info struct
set_fs() updates the limit then set the TI_FSCHECK flag.
addr_limit_user_check() check the flag, and if it is set it checks
the limit is the user limit, then unsets the TI_FSCHECK flag.
In addition, when the flag is set the syscall exit work is involved.
This exit work is heavy compared to normal syscall exit as it goes
through normal exception exit instead of the fast syscall exit.
Rename this TI_FSCHECK flag to TIF_UACCESS_KERNEL flag which tells
whether KERNEL_DS or USER_DS is set. Get mm_segment_t be redifined as
a bool struct that is either false (for USER_DS) or true (for
KERNEL_DS). When TIF_UACCESS_KERNEL is set, the limit is ~0UL.
Otherwise it is TASK_SIZE_USER (resp TASK_SIZE_USER64 on PPC64). When
KERNEL_DS is set, there is no range to check. Define TI_FSCHECK as an
alias to TIF_UACCESS_KERNEL.
On exit, involve exit work when the bit is set, i.e. when KERNEL_DS
is set. addr_limit_user_check() will clear the bit and kill the
user process.
Signed-off-by: Christophe Leroy
---
v3: Rebased and taken into account removal of segment_eq() and comments from mpe
---
arch/powerpc/include/asm/processor.h | 5 +---
arch/powerpc/include/asm/thread_info.h | 9 ---
arch/powerpc/include/asm/uaccess.h | 35 +-
arch/powerpc/lib/sstep.c | 2 +-
4 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index ed0d633ab5aa..86a9c4395b99 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -84,7 +84,7 @@ void start_thread(struct pt_regs *regs, unsigned long fdptr,
unsigned long sp);
void release_thread(struct task_struct *);
typedef struct {
- unsigned long seg;
+ bool uaccess_kernel;
} mm_segment_t;
#define TS_FPR(i) fp_state.fpr[i][TS_FPROFFSET]
@@ -148,7 +148,6 @@ struct thread_struct {
unsigned long ksp_vsid;
#endif
struct pt_regs *regs; /* Pointer to saved register state */
- mm_segment_taddr_limit; /* for get_fs() validation */
#ifdef CONFIG_BOOKE
/* BookE base exception scratch space; align on cacheline */
unsigned long normsave[8] cacheline_aligned;
@@ -295,7 +294,6 @@ struct thread_struct {
#define INIT_THREAD { \
.ksp = INIT_SP, \
.ksp_limit = INIT_SP_LIMIT, \
- .addr_limit = KERNEL_DS, \
.pgdir = swapper_pg_dir, \
.fpexc_mode = MSR_FE0 | MSR_FE1, \
SPEFSCR_INIT \
@@ -303,7 +301,6 @@ struct thread_struct {
#else
#define INIT_THREAD { \
.ksp = INIT_SP, \
- .addr_limit = KERNEL_DS, \
.fpexc_mode = 0, \
}
#endif
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/powerpc/include/asm/thread_info.h
index ca6c97025704..123232a63ee7 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -69,7 +69,7 @@ struct thread_info {
#define INIT_THREAD_INFO(tsk) \
{ \
.preempt_count = INIT_PREEMPT_COUNT,\
- .flags =0, \
+ .flags =_TIF_UACCESS_KERNEL,\
}
#define THREAD_SIZE_ORDER (THREAD_SHIFT - PAGE_SHIFT)
@@ -90,7 +90,8 @@ void arch_setup_new_exec(void);
#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
#define TIF_SIGPENDING 1 /* signal pending */
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
-#define TIF_FSCHECK3 /* Check FS is USER_DS on return */
+#define TIF_UACCESS_KERNEL 3 /* KERNEL_DS is set */
+#define TIF_FSCHECKTIF_UACCESS_KERNEL
#define TIF_SYSCALL_EMU4 /* syscall emulation active */
#define TIF_RESTORE_TM 5 /* need to restore TM FP/VEC/VSX */
#define TIF_PATCH_PENDING 6 /* pending live patching update */
@@ -130,7 +131,7 @@ void arch_setup_new_exec(void);
#define _TIF_SYSCALL_TRACEPOINT(1thread.addr_limit = fs;
- /* On user-mode return check addr_limit (fs) is correct */
- set_thread_flag(TIF_FSCHECK);
+ update_thread_flag(TIF_UACCESS_KERNEL, fs.uaccess_kernel);
}
-#define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)
-#de
drivers/staging/comedi/drivers/pcl730.c:223:25: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 47ec5303d73ea344e84f46660fff693c57641386 commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 7 weeks ago config: riscv-randconfig-s031-20200806 (attached as .config) compiler: riscv32-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-117-g8c7aee71-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/staging/comedi/drivers/pcl730.c:223:25: sparse: sparse: cast removes >> address space '__iomem' of expression >> drivers/staging/comedi/drivers/pcl730.c:223:25: sparse: sparse: incorrect >> type in argument 2 (different address spaces) @@ expected void volatile >> [noderef] __iomem *addr @@ got void * @@ >> drivers/staging/comedi/drivers/pcl730.c:223:25: sparse: expected void >> volatile [noderef] __iomem *addr drivers/staging/comedi/drivers/pcl730.c:223:25: sparse: got void * drivers/staging/comedi/drivers/pcl730.c:225:25: sparse: sparse: cast removes address space '__iomem' of expression drivers/staging/comedi/drivers/pcl730.c:225:25: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/staging/comedi/drivers/pcl730.c:225:25: sparse: expected void volatile [noderef] __iomem *addr drivers/staging/comedi/drivers/pcl730.c:225:25: sparse: got void * drivers/staging/comedi/drivers/pcl730.c:227:25: sparse: sparse: cast removes address space '__iomem' of expression drivers/staging/comedi/drivers/pcl730.c:227:25: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/staging/comedi/drivers/pcl730.c:227:25: sparse: expected void volatile [noderef] __iomem *addr drivers/staging/comedi/drivers/pcl730.c:227:25: sparse: got void * drivers/staging/comedi/drivers/pcl730.c:229:25: sparse: sparse: cast removes address space '__iomem' of expression drivers/staging/comedi/drivers/pcl730.c:229:25: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void * @@ drivers/staging/comedi/drivers/pcl730.c:229:25: sparse: expected void volatile [noderef] __iomem *addr drivers/staging/comedi/drivers/pcl730.c:229:25: sparse: got void * drivers/staging/comedi/drivers/pcl730.c:243:15: sparse: sparse: cast removes address space '__iomem' of expression >> drivers/staging/comedi/drivers/pcl730.c:243:15: sparse: sparse: incorrect >> type in argument 1 (different address spaces) @@ expected void const >> volatile [noderef] __iomem *addr @@ got void * @@ >> drivers/staging/comedi/drivers/pcl730.c:243:15: sparse: expected void >> const volatile [noderef] __iomem *addr drivers/staging/comedi/drivers/pcl730.c:243:15: sparse: got void * drivers/staging/comedi/drivers/pcl730.c:245:25: sparse: sparse: cast removes address space '__iomem' of expression drivers/staging/comedi/drivers/pcl730.c:245:25: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/staging/comedi/drivers/pcl730.c:245:25: sparse: expected void const volatile [noderef] __iomem *addr drivers/staging/comedi/drivers/pcl730.c:245:25: sparse: got void * drivers/staging/comedi/drivers/pcl730.c:247:25: sparse: sparse: cast removes address space '__iomem' of expression drivers/staging/comedi/drivers/pcl730.c:247:25: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/staging/comedi/drivers/pcl730.c:247:25: sparse: expected void const volatile [noderef] __iomem *addr drivers/staging/comedi/drivers/pcl730.c:247:25: sparse: got void * drivers/staging/comedi/drivers/pcl730.c:249:25: sparse: sparse: cast removes address space '__iomem' of expression drivers/staging/comedi/drivers/pcl730.c:249:25: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected
[GIT PULL] livepatching for 5.9
Linus, please pull the latest livepatching changes from git://git.kernel.org/pub/scm/linux/kernel/git/livepatching/livepatching tags/livepatching-for-5.9 == - Improvements and cleanups of livepatching self tests. Joe Lawrence (5): selftests/livepatch: simplify test-klp-callbacks busy target tests selftests/livepatch: Don't clear dmesg when running tests selftests/livepatch: refine dmesg 'taints' in dmesg comparison selftests/livepatch: add test delimiter to dmesg selftests/livepatch: Use "comm" instead of "diff" for dmesg Petr Mladek (1): selftests/livepatch: adopt to newer sysctl error format Yannick Cote (3): selftests/livepatch: rework test-klp-shadow-vars selftests/livepatch: more verification in test-klp-shadow-vars selftests/livepatch: fix mem leaks in test-klp-shadow-vars lib/livepatch/test_klp_callbacks_busy.c| 37 +++- lib/livepatch/test_klp_shadow_vars.c | 240 +++-- tools/testing/selftests/livepatch/README | 16 +- tools/testing/selftests/livepatch/functions.sh | 40 +++- .../testing/selftests/livepatch/test-callbacks.sh | 84 +++- tools/testing/selftests/livepatch/test-ftrace.sh | 6 +- .../testing/selftests/livepatch/test-livepatch.sh | 12 +- .../selftests/livepatch/test-shadow-vars.sh| 85 +--- tools/testing/selftests/livepatch/test-state.sh| 21 +- 9 files changed, 296 insertions(+), 245 deletions(-) Best Regards, Petr
[PATCH v3 2/3] uaccess: remove segment_eq
From: Christoph Hellwig
segment_eq is only used to implement uaccess_kernel. Just open code
uaccess_kernel in the arch uaccess headers and remove one layer of
indirection.
Link: http://lkml.kernel.org/r/20200710135706.537715-5-...@lst.de
Signed-off-by: Christoph Hellwig
Acked-by: Linus Torvalds
Acked-by: Greentime Hu
Acked-by: Geert Uytterhoeven
Cc: Nick Hu
Cc: Vincent Chen
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Signed-off-by: Andrew Morton
Signed-off-by: Stephen Rothwell
---
arch/alpha/include/asm/uaccess.h | 2 +-
arch/arc/include/asm/segment.h| 3 +--
arch/arm/include/asm/uaccess.h| 4 ++--
arch/arm64/include/asm/uaccess.h | 2 +-
arch/csky/include/asm/segment.h | 2 +-
arch/h8300/include/asm/segment.h | 2 +-
arch/ia64/include/asm/uaccess.h | 2 +-
arch/m68k/include/asm/segment.h | 2 +-
arch/microblaze/include/asm/uaccess.h | 2 +-
arch/mips/include/asm/uaccess.h | 2 +-
arch/nds32/include/asm/uaccess.h | 2 +-
arch/nios2/include/asm/uaccess.h | 2 +-
arch/openrisc/include/asm/uaccess.h | 2 +-
arch/parisc/include/asm/uaccess.h | 2 +-
arch/powerpc/include/asm/uaccess.h| 3 +--
arch/riscv/include/asm/uaccess.h | 4 +---
arch/s390/include/asm/uaccess.h | 2 +-
arch/sh/include/asm/segment.h | 3 +--
arch/sparc/include/asm/uaccess_32.h | 2 +-
arch/sparc/include/asm/uaccess_64.h | 2 +-
arch/x86/include/asm/uaccess.h| 2 +-
arch/xtensa/include/asm/uaccess.h | 2 +-
include/asm-generic/uaccess.h | 4 ++--
include/linux/uaccess.h | 2 --
24 files changed, 25 insertions(+), 32 deletions(-)
diff --git a/arch/alpha/include/asm/uaccess.h b/arch/alpha/include/asm/uaccess.h
index 1fe2b56cb861..1b6f25efa247 100644
--- a/arch/alpha/include/asm/uaccess.h
+++ b/arch/alpha/include/asm/uaccess.h
@@ -20,7 +20,7 @@
#define get_fs() (current_thread_info()->addr_limit)
#define set_fs(x) (current_thread_info()->addr_limit = (x))
-#define segment_eq(a, b) ((a).seg == (b).seg)
+#define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)
/*
* Is a address valid? This does a straightforward calculation rather
diff --git a/arch/arc/include/asm/segment.h b/arch/arc/include/asm/segment.h
index 6a2a5be5026d..871f8ab11bfd 100644
--- a/arch/arc/include/asm/segment.h
+++ b/arch/arc/include/asm/segment.h
@@ -14,8 +14,7 @@ typedef unsigned long mm_segment_t;
#define KERNEL_DS MAKE_MM_SEG(0)
#define USER_DSMAKE_MM_SEG(TASK_SIZE)
-
-#define segment_eq(a, b) ((a) == (b))
+#define uaccess_kernel() (get_fs() == KERNEL_DS)
#endif /* __ASSEMBLY__ */
#endif /* __ASMARC_SEGMENT_H */
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 98c6b91be4a8..b19c9bec1f7a 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -76,7 +76,7 @@ static inline void set_fs(mm_segment_t fs)
modify_domain(DOMAIN_KERNEL, fs ? DOMAIN_CLIENT : DOMAIN_MANAGER);
}
-#define segment_eq(a, b) ((a) == (b))
+#define uaccess_kernel() (get_fs() == KERNEL_DS)
/* We use 33-bit arithmetic here... */
#define __range_ok(addr, size) ({ \
@@ -263,7 +263,7 @@ extern int __put_user_8(void *, unsigned long long);
*/
#define USER_DSKERNEL_DS
-#define segment_eq(a, b) (1)
+#define uaccess_kernel() (true)
#define __addr_ok(addr)((void)(addr), 1)
#define __range_ok(addr, size) ((void)(addr), 0)
#define get_fs() (KERNEL_DS)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index bc5c7b091152..fcb8174de505 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -49,7 +49,7 @@ static inline void set_fs(mm_segment_t fs)
CONFIG_ARM64_UAO));
}
-#define segment_eq(a, b) ((a) == (b))
+#define uaccess_kernel() (get_fs() == KERNEL_DS)
/*
* Test whether a block of memory is a valid user space address.
diff --git a/arch/csky/include/asm/segment.h b/arch/csky/include/asm/segment.h
index db2640d5f575..79ede9b1a646 100644
--- a/arch/csky/include/asm/segment.h
+++ b/arch/csky/include/asm/segment.h
@@ -13,6 +13,6 @@ typedef struct {
#define USER_DS((mm_segment_t) { 0x8000UL })
#define get_fs() (current_thread_info()->addr_limit)
#define set_fs(x) (current_thread_info()->addr_limit = (x))
-#define segment_eq(a, b) ((a).seg == (b).seg)
+#define uaccess_kernel() (get_fs().seg == KERNEL_DS.seg)
#endif /* __ASM_CSKY_SEGMENT_H */
diff --git a/arch/h8300/include/asm/segment.h b/arch/h8300/include/asm/segment.h
index a407978f9f9f..37950725d9b9 100644
--- a/arch/h8300/include/asm/segment.h
+++ b/arch/h8300/include/asm/segment.h
@@ -33,7 +33,7 @@ static inline mm_segment_t get_fs(void)
return USER_DS;
}
-#define segment_eq(a, b) ((a
Re: [PATCH] USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter
Hi Patrick, On Wed, Aug 5, 2020 at 9:57 PM Patrick Riphagen wrote: > > The device added has an FTDI chip inside. > The device is used to connect Xsens USB Motion Trackers. > > Signed-off-by: Patrick Riphagen Now you've dropped the backport to stable. Just put Cc: sta...@vger.kernel.org just before your sign-off. Everything will be taken care of automatically once the patch is merged. Frans
Re: [PATCH v2] powerpc/uaccess: simplify the get_fs() set_fs() logic
Le 25/07/2020 à 13:22, Michael Ellerman a écrit : Hi Christophe, Unfortunately this would collide messily with "uaccess: remove segment_eq" in linux-next, so I'll ask you to do a respin based on that, some comments below. Done, sent as v3, together with the 2 patchs from Linux next to get it build and boot. Christophe Leroy writes: On powerpc, we only have USER_DS and KERNEL_DS Today, this is managed as an 'unsigned long' data space limit which is used to compare the passed address with, plus a bit in the thread_info flags that is set whenever modifying the limit to enable the verification in addr_limit_user_check() The limit is either the last address of user space when USER_DS is set, and the last address of address space when KERNEL_DS is set. In both cases, the limit is a compiletime constant. get_fs() returns the limit, which is part of thread_info struct set_fs() updates the limit then set the TI_FSCHECK flag. addr_limit_user_check() check the flag, and if it is set it checks the limit is the user limit, then unsets the TI_FSCHECK flag. In addition, when the flag is set the syscall exit work is involved. This exit work is heavy compared to normal syscall exit as it goes through normal exception exit instead of the fast syscall exit. Rename this TI_FSCHECK flag to TIF_KERNEL_DS flag which tells whether KERNEL_DS or USER_DS is set. Get mm_segment_t be redifined as a bool struct that is either false (for USER_DS) or true (for KERNEL_DS). When TIF_KERNEL_DS is set, the limit is ~0UL. Otherwise it is TASK_SIZE_USER (resp TASK_SIZE_USER64 on PPC64). When KERNEL_DS is set, there is no range to check. Define TI_FSCHECK as an alias to TIF_KERNEL_DS. I'd rather avoid the "DS" name any more than we have to. Maybe it means "data space" but that's not a very common term. I thought it was a reference to the ds/fs/gs ... segment registers in the 8086 ? The generic helper these days is called uaccess_kernel(), which returns true when uaccess routines are allowed to access the kernel. So calling it TIF_UACCESS_KERNEL would work I think? ok The bool could be called uaccess_kernel. And END_OF_USER_DS could be USER_ADDR_MAX. ok On exit, involve exit work when the bit is set, i.e. when KERNEL_DS is set. addr_limit_user_check() will clear the bit and kill the user process. I guess this is safe. The check was added to make sure we never return to userspace with KERNEL_DS set, but using the actual TIF flag to determine the address limit should be equally safe, and avoid the overhead of the check in the good case. That's the purpose indeed, yes. christophe
Re: [RFC v6 00/10] DAMON: Support Physical Memory Address Space Monitoring
On Wed, 5 Aug 2020 08:59:41 +0200 SeongJae Park wrote:
> From: SeongJae Park
>
> Changes from Previous Version
> =
>
> - paddr: Support nested iomem sections (Du Fan)
> - Rebase on v5.8
>
> Introduction
>
>
> DAMON[1] programming interface users can extend DAMON for any address space by
> configuring the address-space specific low level primitives with appropriate
> ones including their own implementations. However, because the implementation
> for the virtual address space is only available now, the users should
> implement
> their own for other address spaces. Worse yet, the user space users who rely
> on the debugfs interface and user space tool, cannot implement their own.
>
> This patchset implements another reference implementation of the low level
> primitives for the physical memory address space. With this change, hence,
> the
> kernel space users can monitor both the virtual and the physical address
> spaces
> by simply changing the configuration in the runtime. Further, this patchset
> links the implementation to the debugfs interface and the user space tool for
> the user space users.
>
> Note that the implementation supports only the user memory, as same to the
> idle
> page access tracking feature.
>
> [1] https://lore.kernel.org/linux-mm/20200706115322.29598-1-sjp...@amazon.com/
This patchset doesn't works for physical address monitoring because I forgot
below patch. Sorry for missing it. Please apply it before you test this
patchset. Or, you can clone the patch applied complete git tree:
$ git clone git://github.com/sjp38/linux -b cdamon/rfc/v6.1
The web is also available:
https://github.com/sjp38/linux/releases/tag/cdamon/rfc/v6.1
The patch will be split and squashed in appropriate patch in the next spin.
=== >8 ===
>From edf6b586f4ac3f8f4d61ebde56d644422bd93bee Mon Sep 17 00:00:00 2001
From: SeongJae Park
Date: Thu, 6 Aug 2020 08:18:49 +
Subject: [PATCH] mm/damon: Fix paddr target id problem
The target id for 'paddr' is meaningless, but we set it as '-1' for fun
and smooth interaction with the user space interfaces. However, the
target ids are 'unsigned long' and thus using '-1' makes no sense. This
commit changes the fake number to another funny but unsigned number,
'42'.
Signed-off-by: SeongJae Park
---
Documentation/admin-guide/mm/damon/usage.rst | 4 ++--
mm/damon.c | 2 +-
tools/damon/_damon.py| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst
b/Documentation/admin-guide/mm/damon/usage.rst
index 88b8e9254a7e..3e2f1519c96a 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -334,12 +334,12 @@ check it again::
Users can also monitor the physical memory address space of the system by
writing a special keyword, "``paddr\n``" to the file. Because physical address
space monitoring doesn't support multiple targets, reading the file will show a
-fake value, ``-1``, as below::
+fake value, ``42``, as below::
# cd /damon
# echo paddr > target_ids
# cat target_ids
--1
+42
Note that setting the target ids doesn't start the monitoring.
diff --git a/mm/damon.c b/mm/damon.c
index a9757a0e5cf7..66268cb45b51 100644
--- a/mm/damon.c
+++ b/mm/damon.c
@@ -2047,7 +2047,7 @@ static ssize_t debugfs_target_ids_write(struct file *file,
ctx->target_valid = NULL;
/* target id is meaningless here, but we set it just for fun */
- snprintf(kbuf, count, "-1");
+ snprintf(kbuf, count, "42");
} else {
/* Configure the context for virtual memory monitoring */
ctx->init_target_regions = kdamond_init_vm_regions;
diff --git a/tools/damon/_damon.py b/tools/damon/_damon.py
index cf14a0d59b94..6ff278117e84 100644
--- a/tools/damon/_damon.py
+++ b/tools/damon/_damon.py
@@ -28,7 +28,7 @@ def set_target(tid, init_regions=[]):
return 0
if tid == 'paddr':
-tid = -1
+tid = 42
string = ' '.join(['%s %d %d' % (tid, r[0], r[1]) for r in init_regions])
return subprocess.call('echo "%s" > %s' % (string, debugfs_init_regions),
shell=True, executable='/bin/bash')
--
2.17.1
Re: [PATCH] MIPS: Introduce cmdline argument writecombine=
On 08/06/2020 03:39 PM, Jiaxun Yang wrote:
在 2020/8/6 下午3:09, Tiezhu Yang 写道:
Loongson processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times,
after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine
mapping for MIPS"), there exists some errors such as blurred screen
and lockup, and so on.
With this patch, disable writecombine by default for Loongson64 to
work well with ATI Radeon or AMD GPU, and it has no influence on the
other platforms due to writecombine is enabled by default.
Additionally, if it is necessary, writecombine=on can be set manually
in the cmdline to enhance the performance for Loongson LS7A integrated
graphics in the future.
[ 60.958721] radeon :03:00.0: ring 0 stalled for more than
10079msec
[ 60.965315] radeon :03:00.0: GPU lockup (current fence id
0x0112 last fence id 0x011d on ring 0)
[ 60.976525] radeon :03:00.0: ring 3 stalled for more than
10086msec
[ 60.983156] radeon :03:00.0: GPU lockup (current fence id
0x0374 last fence id 0x03a8 on ring 3)
Hi Tiezhu,
Thanks for your patch.
Personally I didn't have any issue with writecombine on my test
systems, but there
are some complains about unstable graphic card from users. So
generally a cmdline
writecombine switch is necessary.
Signed-off-by: Tiezhu Yang
---
arch/mips/include/asm/pgtable.h | 4
arch/mips/kernel/cpu-probe.c| 19 +++
2 files changed, 23 insertions(+)
diff --git a/arch/mips/include/asm/pgtable.h
b/arch/mips/include/asm/pgtable.h
index dd7a0f5..34869f7 100644
--- a/arch/mips/include/asm/pgtable.h
+++ b/arch/mips/include/asm/pgtable.h
@@ -473,6 +473,10 @@ static inline pgprot_t pgprot_noncached(pgprot_t
_prot)
static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
{
unsigned long prot = pgprot_val(_prot);
+extern bool mips_writecombine;
+
+if (!mips_writecombine)
+return pgprot_noncached(_prot);
You can simply override c->writecombine to _CACHE_UNCACHED in
cpu-probe.c with
out this kind of hijack.
/* cpu_data[0].writecombine is already shifted by
_CACHE_SHIFT */
prot = (prot & ~_CACHE_MASK) | cpu_data[0].writecombine;
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index e2955f1..98777ca 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -459,6 +459,25 @@ static int __init ftlb_disable(char *s)
__setup("noftlb", ftlb_disable);
+#ifdef CONFIG_MACH_LOONGSON64
+bool mips_writecombine; /* initialise to false by default */
+#else
+bool mips_writecombine = true;
+#endif
+EXPORT_SYMBOL(mips_writecombine);
There is no need to export this symbol, see comment before.
+
+static int __init writecombine_setup(char *str)
+{
+if (strcmp(str, "on") == 0)
+mips_writecombine = true;
+else if (strcmp(str, "off") == 0)
+mips_writecombine = false;
+
+return 1;
+}
+
+__setup("writecombine=", writecombine_setup);
Use early_param here seems more reasonable, it will be probed earlier.
Hi Jiaxun,
Thanks for your suggestion, it looks better.
I will modify and test it, then I will send v2 with another
document patch to explain this cmdline argument.
Thanks,
Tiezhu
+
/*
* Check if the CPU has per tc perf counters
*/
Thanks
- Jiaxun
Re: [PATCH] docs: remove the 2.6 "Upgrading I2C Drivers" guide
> > Maybe because I don't have the commit in my tree? Can you rebase on top > > of 5.8? > > Ah, yes, the commit is on top of Linus’ current master, following the merge > of docs-5.9 from Jon’s tree. In 5.8 the file is a .txt file, but Mauro > converted it to .rst for 5.9, and this patch removes the latter file (to > avoid a merge conflict later on...). If you prefer, I can submit it to the > docs tree instead! I see. Thanks for the heads up! > > And please also remove the reference in Documentation/i2c/index.rst > > Oops, yes, I’ll do that in v2 once we decide where it should go. I am fine with either it going via the doc-tree or you sending me v2 again after 5.9-rc1. For the first case: Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: [PATCH 1/2] perf: Add closing sibling events' file descriptors
On Wed, Jul 08, 2020 at 06:16:34PM +0300, Alexander Shishkin wrote: > Currently, perf requires one file descriptor per event. In large groups, > this may mean running into the limit on open file descriptors. However, > the sibling events in a group only need file descriptors for the initial > configuration stage, after which they may not be needed any more. > > This adds an opt-in flag to the perf_event_open() syscall to retain > sibling events after their file descriptors are closed. In this case, the > actual events will be closed with the group leader. So having the 1:1 relation with filedesc imposes a resource limit on userspace. This patch breaks that and enables a user to basically DoS the system by creating unbound events.
Re: [PATCH 0/2] perf: Allow closing siblings' file descriptors
On Thu, Aug 06, 2020 at 09:15:08AM +0300, Adrian Hunter wrote: > On 8/07/20 6:16 pm, Alexander Shishkin wrote: > > Hi guys, > > > > I've been looking at reducing the number of open file descriptors per perf > > session. If we retain one descriptor per event, in a large group they add > > up. At the same time, we're not actually using them for anything after the > > SET_OUTPUT and maybe SET_FILTER ioctls. So, this series is a stab at that. > > I am wondering if instead we should be looking at creating a kernel API that > allows associating a multitude of tracepoints with a single event. Thoughts > anyone? https://lkml.kernel.org/r/1290445737.2072.338.camel@laptop
Re: Minor RST rant
On 2020-08-06 08:48, Christoph Hellwig wrote: On Wed, Aug 05, 2020 at 05:12:30PM +0200, pet...@infradead.org wrote: On Wed, Aug 05, 2020 at 04:49:50PM +0200, Vegard Nossum wrote: FWIW, I *really* like how the extra markup renders in a browser, and I don't think I'm the only one. The thing is, I write code in a text editor, not a browser. When a header file says: read Documentation/foo I do 'gf' and that file gets opened in a buffer. Needing a browser is a fail. And that is my main problem with all the RST craze. It optmizes for shiny display in a browser, but copletely messed up the typical developer flow. If you are using vim, you can put this in ~/.vim/after/syntax/rst.vim: syn region rstInlineLiteral matchgroup=Special start="``" end="``" concealends syn region rstEmphasis matchgroup=Special start="\*\*" end="\*\*" concealends setlocal conceallevel=2 This will hide the ``foo`` and **bar** markup on lines that are not currently under the cursor. Vegard
Re: [PATCH v7 06/13] pwm: add support for sl28cpld PWM controller
Hello Michael, I'm nearly happy now; see below. On Mon, Aug 03, 2020 at 11:35:52AM +0200, Michael Walle wrote: > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index 7dbcf6973d33..a0d50d70c3b9 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -428,6 +428,16 @@ config PWM_SIFIVE > To compile this driver as a module, choose M here: the module > will be called pwm-sifive. > > +config PWM_SL28CPLD > + tristate "Kontron sl28cpld PWM support" > + select MFD_SIMPLE_MFD_I2C Is it sensible to present this option to everyone? Maybe depends on SOME_SYMBOL_ONLY_TRUE_ON_SL28CPLD || COMPILE_TEST . > + help > + Generic PWM framework driver for board management controller > + found on the Kontron sl28 CPLD. > + > + To compile this driver as a module, choose M here: the module > + will be called pwm-sl28cpld. > + > config PWM_SPEAR > tristate "STMicroelectronics SPEAr PWM support" > depends on PLAT_SPEAR || COMPILE_TEST > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile > index 2c2ba0a03557..cbdcd55d69ee 100644 > --- a/drivers/pwm/Makefile > +++ b/drivers/pwm/Makefile > @@ -40,6 +40,7 @@ obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o > obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o > obj-$(CONFIG_PWM_SAMSUNG)+= pwm-samsung.o > obj-$(CONFIG_PWM_SIFIVE) += pwm-sifive.o > +obj-$(CONFIG_PWM_SL28CPLD) += pwm-sl28cpld.o > obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o > obj-$(CONFIG_PWM_SPRD) += pwm-sprd.o > obj-$(CONFIG_PWM_STI)+= pwm-sti.o > diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c > new file mode 100644 > index ..bb298af36f0b > --- /dev/null > +++ b/drivers/pwm/pwm-sl28cpld.c > @@ -0,0 +1,235 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * sl28cpld PWM driver > + * > + * Copyright (c) 2020 Michael Walle > + * > + * There is no public datasheet available for this PWM core. But it is easy > + * enough to be briefly explained. It consists of one 8-bit counter. The PWM > + * supports four distinct frequencies by selecting when to reset the counter. > + * With the prescaler setting you can select which bit of the counter is used > + * to reset it. This implies that the higher the frequency the less remaining > + * bits are available for the actual counter. > + * > + * Let cnt[7:0] be the counter, clocked at 32kHz: > + * +---++--+---+---+ > + * | prescaler | reset | counter bits | frequency | period length | > + * +---++--+---+---+ > + * | 0 | cnt[7] | cnt[6:0] |250 Hz |400 ns | > + * | 1 | cnt[6] | cnt[5:0] |500 Hz |200 ns | > + * | 2 | cnt[5] | cnt[4:0] | 1 kHz |100 ns | > + * | 3 | cnt[4] | cnt[3:0] | 2 kHz | 50 ns | > + * +---++--+---+---+ > + * > + * Limitations: > + * - The hardware cannot generate a 100% duty cycle if the prescaler is 0. > + * - The hardware cannot atomically set the prescaler and the counter value, > + * which might lead to glitches and inconsistent states if a write fails. > + * - The counter is not reset if you switch the prescaler which leads > + * to glitches, too. > + * - The duty cycle will switch immediately and not after a complete cycle. > + * - Depending on the actual implementation, disabling the PWM might have > + * side effects. For example, if the output pin is shared with a GPIO pin > + * it will automatically switch back to GPIO mode. Very nice. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* > + * PWM timer block registers. > + */ > +#define SL28CPLD_PWM_CTRL0x00 > +#define SL28CPLD_PWM_CTRL_ENABLE BIT(7) > +#define SL28CPLD_PWM_CTRL_PRESCALER_MASK GENMASK(1, 0) > +#define SL28CPLD_PWM_CYCLE 0x01 > +#define SL28CPLD_PWM_CYCLE_MAX GENMASK(6, 0) > + > +#define SL28CPLD_PWM_CLK 32000 /* 32 kHz */ > +#define SL28CPLD_PWM_MAX_DUTY_CYCLE(prescaler) (1 << (7 - (prescaler))) > +#define SL28CPLD_PWM_PERIOD(prescaler) \ > + (NSEC_PER_SEC / SL28CPLD_PWM_CLK * > SL28CPLD_PWM_MAX_DUTY_CYCLE(prescaler)) > + > +/* > + * We calculate the duty cycle like this: > + * duty_cycle_ns = pwm_cycle_reg * max_period_ns / max_duty_cycle > + * > + * With > + * max_period_ns = 1 << (7 - prescaler) / pwm_clk * NSEC_PER_SEC > + * max_duty_cycle = 1 << (7 - prescaler) > + * this then simplifies to: > + * duty_cycle_ns = pwm_cycle_reg / pwm_clk * NSEC_PER_SEC > + * > + * NSEC_PER_SEC and SL28CPLD_PWM_CLK is integer here, so we're not losing > + * precision by doing the divison first. Apart from the grammatical issue (s/is/are/) this is not the relevant fact. The relevant thing is t
Re: [PATCH v7] Makefile: Add clang-tidy and static analyzer support to makefile
On Tue, Jul 28, 2020 at 9:47 AM Nathan Huckleberry wrote:
>
> This patch adds clang-tidy and the clang static-analyzer as make
> targets. The goal of this patch is to make static analysis tools
> usable and extendable by any developer or researcher who is familiar
> with basic c++.
>
> The current static analysis tools require intimate knowledge of the
> internal workings of the static analysis. Clang-tidy and the clang
> static analyzers expose an easy to use api and allow users unfamiliar
> with clang to write new checks with relative ease.
>
> ===Clang-tidy===
>
> Clang-tidy is an easily extendable 'linter' that runs on the AST.
> Clang-tidy checks are easy to write and understand. A check consists of
> two parts, a matcher and a checker. The matcher is created using a
> domain specific language that acts on the AST
> (https://clang.llvm.org/docs/LibASTMatchersReference.html). When AST
> nodes are found by the matcher a callback is made to the checker. The
> checker can then execute additional checks and issue warnings.
>
> Here is an example clang-tidy check to report functions that have calls
> to local_irq_disable without calls to local_irq_enable and vice-versa.
> Functions flagged with __attribute((annotation("ignore_irq_balancing")))
> are ignored for analysis. (https://reviews.llvm.org/D65828)
>
> ===Clang static analyzer===
>
> The clang static analyzer is a more powerful static analysis tool that
> uses symbolic execution to find bugs. Currently there is a check that
> looks for potential security bugs from invalid uses of kmalloc and
> kfree. There are several more general purpose checks that are useful for
> the kernel.
>
> The clang static analyzer is well documented and designed to be
> extensible.
> (https://clang-analyzer.llvm.org/checker_dev_manual.html)
> (https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf)
>
> The main draw of the clang tools is how accessible they are. The clang
> documentation is very nice and these tools are built specifically to be
> easily extendable by any developer. They provide an accessible method of
> bug-finding and research to people who are not overly familiar with the
> kernel codebase.
>
> Signed-off-by: Nathan Huckleberry
> ---
> Changes v6->v7
> * Fix issues with relative paths
> * Additional style fixes
> MAINTAINERS | 1 +
> Makefile | 3 +
> scripts/clang-tools/Makefile.clang-tools | 23 ++
> .../{ => clang-tools}/gen_compile_commands.py | 0
> scripts/clang-tools/run-clang-tools.py| 74 +++
> 5 files changed, 101 insertions(+)
> create mode 100644 scripts/clang-tools/Makefile.clang-tools
> rename scripts/{ => clang-tools}/gen_compile_commands.py (100%)
> create mode 100755 scripts/clang-tools/run-clang-tools.py
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1d4aa7f942de..a444564e5572 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4198,6 +4198,7 @@ W:https://clangbuiltlinux.github.io/
> B: https://github.com/ClangBuiltLinux/linux/issues
> C: irc://chat.freenode.net/clangbuiltlinux
> F: Documentation/kbuild/llvm.rst
> +F: scripts/clang-tools/
> K: \b(?i:clang|llvm)\b
>
> CLEANCACHE API
> diff --git a/Makefile b/Makefile
> index fe0164a654c7..3e2df010b342 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -747,6 +747,7 @@ KBUILD_CFLAGS += $(call
> cc-option,-fno-allow-store-data-races)
>
> include scripts/Makefile.kcov
> include scripts/Makefile.gcc-plugins
> +include scripts/clang-tools/Makefile.clang-tools
>
> ifdef CONFIG_READABLE_ASM
> # Disable optimizations that make assembler listings hard to read.
> @@ -1543,6 +1544,8 @@ help:
> @echo ' export_report - List the usages of all exported symbols'
> @echo ' headerdep - Detect inclusion cycles in headers'
> @echo ' coccicheck - Check with Coccinelle'
> + @echo ' clang-analyzer - Check with clang static analyzer'
> + @echo ' clang-tidy - Check with clang-tidy'
> @echo ''
> @echo 'Tools:'
> @echo ' nsdeps - Generate missing symbol namespace
> dependencies'
> diff --git a/scripts/clang-tools/Makefile.clang-tools
> b/scripts/clang-tools/Makefile.clang-tools
> new file mode 100644
> index ..5c9d76f77595
> --- /dev/null
> +++ b/scripts/clang-tools/Makefile.clang-tools
> @@ -0,0 +1,23 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Copyright (C) Google LLC, 2020
> +#
> +# Author: Nathan Huckleberry
> +#
> +PHONY += clang-tidy
> +clang-tidy:
> +ifdef CONFIG_CC_IS_CLANG
> + $(PYTHON3) scripts/clang-tools/gen_compile_commands.py
> + $(PYTHON3) scripts/clang-tools/run-clang-tools.py clang-tidy
> compile_commands.json
> +else
> + $(error clang-tidy requires CC=clang)
> +endif
> +
> +PHONY += clang-analyzer
> +clang-analyzer:
> +ifdef CONFIG_CC_IS_CLANG
> + $(PY
Re: [PATCH] arm: Add support for ZSTD compressed kernel
Am Do., 6. Aug. 2020 um 02:30 Uhr schrieb Russell King - ARM Linux admin : > > On Thu, Aug 06, 2020 at 01:05:55AM +0200, Norbert Lange wrote: > > diff --git a/arch/arm/boot/compressed/head.S > > b/arch/arm/boot/compressed/head.S > > index 434a16982e34..1af01bfe6638 100644 > > --- a/arch/arm/boot/compressed/head.S > > +++ b/arch/arm/boot/compressed/head.S > > @@ -614,7 +614,11 @@ not_relocated: mov r0, #0 > > */ > > mov r0, r4 > > mov r1, sp @ malloc space above stack > > +#if defined(CONFIG_KERNEL_ZSTD) > > + add r2, sp, #0x3@ Context needs ~160K > > That's going to mess up kexec: > > /* > * The zImage length does not include its stack (4k) or its > * malloc space (64k). Include this. > */ > len += 0x11000; > > I guess we need to add this to the information provided to kexec. Ouch, I guess it's rather impossible to load a new ZSTD kernel with a old kexec version in that case. Some ideas to fix that would be: - Increase the padding to "192K + 4K is enough for everyone" in kexec - Add the required/recommended stack+heap size to zImage so kexec can use it. - change boot logic to place heap before/after the *output* range. with the various ways of booting arm this will likely cause other issues in some combinations. - try to reduce zstd context size safetly below 64K. I believe the entropy tables are computed once and never modified, so those could be part of the zImage (at some loss of compression rate of course). Would need some host tool to inject those. Norbert
Re: [PATCH 5.7 0/7] 5.7.14-rc2 review
On Thu, 6 Aug 2020 at 01:29, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.7.14 release. > There are 7 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri, 07 Aug 2020 19:59:06 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.14-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.7.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.7.14-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.7.y git commit: 0ceaad177e510974c093f79a5d1f3bb058a4fdf2 git describe: v5.7.13-8-g0ceaad177e51 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.7-oe/build/v5.7.13-8-g0ceaad177e51 No regressions (compared to build v5.7.12-117-gd3223abaf6fd) No fixes (compared to build v5.7.12-117-gd3223abaf6fd) Ran 30546 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * install-android-platform-tools-r2800 * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * v4l2-compliance * ltp-dio-tests * ltp-io-tests * ltp-ipc-tests * ltp-commands-tests * ltp-containers-tests * ltp-cve-tests * ltp-math-tests * ltp-open-posix-tests * ltp-syscalls-tests * network-basic-tests * igt-gpu-tools -- Linaro LKFT https://lkft.linaro.org
[PATCH] powerpc/signal: Move and simplify get_clean_sp()
get_clean_sp() is only used in kernel/signal.c . Move it there.
And GCC is smart enough to reduce the function when on PPC32, no
need of a special PPC32 simple version.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/processor.h | 14 --
arch/powerpc/kernel/signal.c | 7 +++
2 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index ed0d633ab5aa..5c20b6d509ae 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -404,20 +404,6 @@ static inline void prefetchw(const void *x)
#define HAVE_ARCH_PICK_MMAP_LAYOUT
-#ifdef CONFIG_PPC64
-static inline unsigned long get_clean_sp(unsigned long sp, int is_32)
-{
- if (is_32)
- return sp & 0x0UL;
- return sp;
-}
-#else
-static inline unsigned long get_clean_sp(unsigned long sp, int is_32)
-{
- return sp;
-}
-#endif
-
/* asm stubs */
extern unsigned long isa300_idle_stop_noloss(unsigned long psscr_val);
extern unsigned long isa300_idle_stop_mayloss(unsigned long psscr_val);
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index d15a98c758b8..bd0ba7c5e2cf 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -171,6 +171,13 @@ inline unsigned long copy_ckfpr_from_user(struct
task_struct *task,
int show_unhandled_signals = 1;
+static unsigned long get_clean_sp(unsigned long sp, int is_32)
+{
+ if (is_32)
+ return sp & 0x0UL;
+ return sp;
+}
+
/*
* Allocate space for the signal frame
*/
--
2.25.0
Re: [PATCH 5.4 0/9] 5.4.57-rc1 review
On Wed, 5 Aug 2020 at 21:23, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.57 release. > There are 9 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri, 07 Aug 2020 15:34:53 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.57-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.4.57-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: 1c4819817cd892724f91e5d253eec5f746243602 git describe: v5.4.56-10-g1c4819817cd8 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.56-10-g1c4819817cd8 No regressions (compared to build v5.4.55-87-g47b594b8993f) No fixes (compared to build v5.4.55-87-g47b594b8993f) Ran 35321 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * install-android-platform-tools-r2800 * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * v4l2-compliance * ltp-dio-tests * ltp-io-tests * ltp-ipc-tests * ltp-commands-tests * ltp-containers-tests * ltp-cve-tests * ltp-math-tests * ltp-open-posix-tests * ltp-syscalls-tests * network-basic-tests * igt-gpu-tools -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v3 3/4] fpga: dfl: create a dfl bus type to support DFL devices
On Thu, Aug 06, 2020 at 03:11:14PM +0800, Wu, Hao wrote:
> > > > +static int dfl_bus_uevent(struct device *dev, struct kobj_uevent_env
> > *env)
> > > > +{
> > > > +struct dfl_device *ddev = to_dfl_dev(dev);
> > > > +
> > > > +return add_uevent_var(env, "MODALIAS=dfl:t%08Xf%04X",
> > > > + ddev->type, ddev->feature_id);
> > >
> > > Then we only print 12bit of feature_id will be enough?
> > > should we make type shorter as well as feature id?
> >
> > I could envision that we need a struct
> >
> > struct dfl_feature_id {
> > u16 id: 12;
> > }
> >
> > for it.
> >
> > But it seems more complex and I didn't see the benifit. We don't have to
> > worry about the invalid values cause we parse all the ddev->feature_id in
> > dfl driver, and ensures it will not be larger than 12bit value.
>
> Ideally type is only 4bits per spec, but looks like it's adding more zero
> before
> the type value, and also the feature id. This may not be a real problem, but
> may look a little wired, isn't it?
OK, I could change the print.
>
> >
> > > And do you think if we should add a new field for dfl version?
> >
> > I think it may not be necessary now. If we support dfl v1 in future, we
> > still could try to check uuid first, then fall back to type &
> > feature_id.
>
> I think it's all about the uevent and it's user, and for users, they may have
> to
> deal with different versions, right? As you mentioned, if the event will be
> different format for v1 and it's not compatible with v0, anyway we need
> the version sooner or later, is my understanding correct?
The version is not needed for uevent. The different formats of
uevents explain themselves (dfl v0 or dfl v1), is it?
If we add the dfl version in uevent then we should also add
the version in struct dfl_device_id, and all dfl driver should fill the
version info in its id_table. But actually that's redundent work to
driver developer.
The version in struct dfl_device may simplify the internal code on how
to format the uevent. But considering the only extension of dflv1 I
think checking the null uuid is also simply enough.
>
> >
> > Do you have any idea for the potential usage of dfl version.
> >
>
> > > > +/* then add irq resource */
> > > > +if (feature->nr_irqs) {
> > > > +ddev->irqs = kcalloc(feature->nr_irqs,
> > > > + sizeof(*ddev->irqs), GFP_KERNEL);
> > > > +if (!ddev->irqs) {
> > > > +ret = -ENOMEM;
> > > > +goto put_dev;
> > > > +}
> > > > +
> > > > +for (i = 0; i < feature->nr_irqs; i++)
> > > > +ddev->irqs[i] = feature->irq_ctx[i].irq;
> > > > +
> > > > +ddev->num_irqs = feature->nr_irqs;
> > >
> > > Do we need to consider using IORESOURCE_IRQ here as well?
> >
> > The helper functions for IORESOURCE_IRQ are all for platform_devices,
> > We need to define a set of functions similar to them, I think current
> > implementation is simpler, for dfl bus and drivers.
>
> If some case that it's going to reuse some platform device driver,
> then dfl_device driver will create platform device, it has to pass the mmio
> and irq resources to platform device driver, how you plan to do that?
I think even we create struct resource array for dfl_devices, the dfl
driver still has to create and fill its pdev resource as needed. There
is little chance the driver could just memcpy them. So the dfl driver
could fill the irq resources of pdev according to ddev->irqs & num_irqs.
>
> > > > +static int dfl_devs_init(struct platform_device *pdev)
> > > > +{
> > > > +struct dfl_feature_platform_data *pdata = dev_get_platdata(&pdev-
> > > > >dev);
> > > > +struct dfl_feature *feature;
> > > > +struct dfl_device *ddev;
> > > > +
> > > > +dfl_fpga_dev_for_each_feature(pdata, feature) {
> > > > +if (feature->ioaddr || feature->priv)
> > >
> > > Why checks priv here?
> >
> > I want to make sure the dfl_device is not already created.
>
> Is that a valid case that we expected? or sounds like error code needs
> to be returned?
OK. It is invalid, I could error out in this case.
>
> Thanks
> Hao
Re: [PATCH 1/2] sched/topology: Allow archs to override cpu_smt_mask
On Thu, Aug 06, 2020 at 03:32:25PM +1000, Michael Ellerman wrote: > That brings with it a bunch of problems, such as existing software that > has been developed/configured for Power8 and expects to see SMT8. > > We also allow LPARs to be live migrated from Power8 to Power9 (and back), so > maintaining the illusion of SMT8 is considered a requirement to make that > work. So how does that work if the kernel booted on P9 and demuxed the SMT8 into 2xSMT4? If you migrate that state onto a P8 with actual SMT8 you're toast again. > Yeah I agree the naming is confusing. > > Let's call them "SMT4 cores" and "SMT8 cores"? Works for me, thanks! > The problem is we are already lying to userspace, because firmware lies to us. > > ie. the firmware on these systems shows us an SMT8 core, and so current > kernels > show SMT8 to userspace. I don't think we can realistically change that fact > now, > as these systems are already out in the field. > > What this patch tries to do is undo some of the mess, and at least give the > scheduler the right information. What a mess... I think it depends on what you do with that P9 to P8 migration case. Does it make sense to have a "p8_compat" boot arg for the case where you want LPAR migration back onto P8 systems -- in which case it simply takes the firmware's word as gospel and doesn't untangle things, because it can actually land on a P8.
[PATCH v8 0/4] scsi: ufs: Add Host Performance Booster Support
Changelog: v7 -> v8 Remove wrongly added tags. v6 -> v7 1. Remove UFS feature layer. 2. Cleanup for sparse error. v5 -> v6 Change base commit to b53293fa662e28ae0cdd40828dc641c09f133405 v4 -> v5 Delete unused macro define. v3 -> v4 1. Cleanup. v2 -> v3 1. Add checking input module parameter value. 2. Change base commit from 5.8/scsi-queue to 5.9/scsi-queue. 3. Cleanup for unused variables and label. v1 -> v2 1. Change the full boilerplate text to SPDX style. 2. Adopt dynamic allocation for sub-region data structure. 3. Cleanup. NAND flash memory-based storage devices use Flash Translation Layer (FTL) to translate logical addresses of I/O requests to corresponding flash memory addresses. Mobile storage devices typically have RAM with constrained size, thus lack in memory to keep the whole mapping table. Therefore, mapping tables are partially retrieved from NAND flash on demand, causing random-read performance degradation. To improve random read performance, JESD220-3 (HPB v1.0) proposes HPB (Host Performance Booster) which uses host system memory as a cache for the FTL mapping table. By using HPB, FTL data can be read from host memory faster than from NAND flash memory. The current version only supports the DCM (device control mode). This patch consists of 3 parts to support HPB feature. 1) HPB probe and initialization process 2) READ -> HPB READ using cached map information 3) L2P (logical to physical) map management In the HPB probe and init process, the device information of the UFS is queried. After checking supported features, the data structure for the HPB is initialized according to the device information. A read I/O in the active sub-region where the map is cached is changed to HPB READ by the HPB. The HPB manages the L2P map using information received from the device. For active sub-region, the HPB caches through ufshpb_map request. For the in-active region, the HPB discards the L2P map. When a write I/O occurs in an active sub-region area, associated dirty bitmap checked as dirty for preventing stale read. HPB is shown to have a performance improvement of 58 - 67% for random read workload. [1] This series patches are based on the 5.9/scsi-queue branch. [1]: https://www.usenix.org/conference/hotstorage17/program/presentation/jeong Daejun park (4): scsi: ufs: Add UFS feature related parameter scsi: ufs: Introduce HPB feature scsi: ufs: L2P map management for HPB read scsi: ufs: Prepare HPB read for cached sub-region drivers/scsi/ufs/Kconfig | 18 + drivers/scsi/ufs/Makefile |1 + drivers/scsi/ufs/ufs.h| 12 + drivers/scsi/ufs/ufshcd.c | 42 + drivers/scsi/ufs/ufshcd.h |9 + drivers/scsi/ufs/ufshpb.c | 1926 drivers/scsi/ufs/ufshpb.h | 241 + 7 files changed, 2249 insertions(+) created mode 100644 drivers/scsi/ufs/ufshpb.c created mode 100644 drivers/scsi/ufs/ufshpb.h
[PATCH] USB: serial: ftdi_sio: add IDs for Xsens Mti USB converter
The device added has an FTDI chip inside.
The device is used to connect Xsens USB Motion Trackers.
Cc: sta...@vger.kernel.org
Signed-off-by: Patrick Riphagen
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 9ad44a96dfe3..2c08cad32f1d 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -713,6 +713,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(XSENS_VID, XSENS_AWINDA_STATION_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_MTDEVBOARD_PID) },
+ { USB_DEVICE(XSENS_VID, XSENS_MTIUSBCONVERTER_PID) },
{ USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
{ USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index e8373528264c..b5ca17a5967a 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -160,6 +160,7 @@
#define XSENS_AWINDA_DONGLE_PID 0x0102
#define XSENS_MTW_PID 0x0200 /* Xsens MTw */
#define XSENS_MTDEVBOARD_PID 0x0300 /* Motion Tracker Development Board */
+#define XSENS_MTIUSBCONVERTER_PID 0x0301 /* MTi USB converter */
#define XSENS_CONVERTER_PID0xD00D /* Xsens USB-serial converter */
/* Xsens devices using FTDI VID */
--
2.25.1
Re: [PATCH v1] scsi: ufs: no need to send one Abort Task TM in case the task in DB was cleared
Hi Bean,
On 2020-08-04 20:35, Bean Huo wrote:
From: Bean Huo
If the bit corresponds to a task in the Doorbell register has been
cleared, no need to poll the status of the task on the device side
and to send an Abort Task TM.
This patch also deletes dispensable dev_err() in case of the task
already completed.
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufshcd.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 307622284239..581b4ab52bf4 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6425,19 +6425,16 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
return ufshcd_eh_host_reset_handler(cmd);
ufshcd_hold(hba, false);
- reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
/* If command is already aborted/completed, return SUCCESS */
- if (!(test_bit(tag, &hba->outstanding_reqs))) {
- dev_err(hba->dev,
- "%s: cmd at tag %d already completed, outstanding=0x%lx,
doorbell=0x%x\n",
- __func__, tag, hba->outstanding_reqs, reg);
+ if (!(test_bit(tag, &hba->outstanding_reqs)))
goto out;
- }
+ reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
if (!(reg & (1 << tag))) {
dev_err(hba->dev,
"%s: cmd was completed, but without a notifying intr, tag = %d",
__func__, tag);
+ goto out;
Please check Stanley's recent change to ufshcd_abort, you may
want to rebase your change on his and do goto cleanup here.
@Stanley correct me if I am wrong.
But even if you do a goto cleanup here, we still lost the
chances to dump host infos/regs like it does in the old code.
If a cmd was completed but without a notifying intr, this is
kind of a problem that we/host should look into, because it's
pasted at least 30 sec since the cmd was sent, so those dumps
are necessary to debug the problem. How about moving blow prints
in front of this part?
Thanks,
Can Guo.
}
/* Print Transfer Request of aborted task */
Re: [PATCH] net: core: explicitly call linkwatch_fire_event to speed up the startup of network services
在 2020/8/5 上午6:58, David Miller 写道: From: Wen Yang Date: Sat, 1 Aug 2020 16:58:45 +0800 diff --git a/net/core/link_watch.c b/net/core/link_watch.c index 75431ca..6b9d44b 100644 --- a/net/core/link_watch.c +++ b/net/core/link_watch.c @@ -98,6 +98,9 @@ static bool linkwatch_urgent_event(struct net_device *dev) if (netif_is_lag_port(dev) || netif_is_lag_master(dev)) return true; + if ((dev->flags & IFF_UP) && dev->operstate == IF_OPER_DOWN) + return true; + return netif_carrier_ok(dev) && qdisc_tx_changing(dev); } You're bypassing explicitly the logic here: /* * Limit the number of linkwatch events to one * per second so that a runaway driver does not * cause a storm of messages on the netlink * socket. This limit does not apply to up events * while the device qdisc is down. */ if (!urgent_only) linkwatch_nextevent = jiffies + HZ; /* Limit wrap-around effect on delay. */ else if (time_after(linkwatch_nextevent, jiffies + HZ)) linkwatch_nextevent = jiffies; Something about this isn't right. We need to analyze what you are seeing, what device you are using, and what systemd is doing to figure out what the right place for the fix. Thank you. Thank you very much for your comments. We are using virtio_net and the environment is a microvm similar to firecracker. Let's briefly explain. net_device->operstate is assigned through linkwatch_event, and the call stack is as follows: process_one_work -> linkwatch_event -> __linkwatch_run_queue -> linkwatch_do_dev -> rfc2863_policy -> default_operstate During the machine startup process, net_device->operstate has the following two-step state changes: STEP A: virtnet_probe detects the network card and triggers the execution of linkwatch_fire_event. Since linkwatch_nextevent is initialized to 0, linkwatch_work will run. And since net_device->state is 6 (__LINK_STATE_PRESENT | __LINK_STATE_NOCARRIER), net_device->operstate will be changed from IF_OPER_UNKNOWN to IF_OPER_DOWN: eth0 operstate:0 (IF_OPER_UNKNOWN) -> operstate:2 (IF_OPER_DOWN) virtnet_probe then executes netif_carrier_on to update net_device->state, it will be changed from ‘__LINK_STATE_PRESENT | __LINK_STATE_NOCARRIER’ to __LINK_STATE_PRESENT: eth0 state: 6 (__LINK_STATE_PRESENT | __LINK_STATE_NOCARRIER) -> 2 (__LINK_STATE_PRESENT) STEP B: One second later (because linkwatch_nextevent = jiffies + HZ), linkwatch_work is executed again. At this time, since net_device->state is __LINK_STATE_PRESENT, so the net_device->operstate will be changed from IF_OPER_DOWN to IF_OPER_UP: eth0 operstate:2 (IF_OPER_DOWN) -> operstate:6 (IF_OPER_UP) The above state change can be completed within 2 seconds. Generally, the machine will load the initramfs first, and do some initialization in the initramfs, which takes some time; then switch_root to the system disk and continue the initialization, which will also take some time, and finally start the systemd-networkd service, bringing link, etc., In this way, the linkwatch_work work queue has enough time to run twice, and the state of net_device->operstate is already IF_OPER_UP, So bringing link up quickly returns the following information: Aug 06 16:35:55.966121 iZuf6h1kfgutxc3el68z2lZ systemd-networkd[580]: eth0: bringing link up ... Aug 06 16:35:55.990461 iZuf6h1kfgutxc3el68z2lZ systemd-networkd[580]: eth0: flags change: +UP +LOWER_UP +RUNNING But we are now using MicroVM, which requires extreme speed to start, bypassing the initramfs and directly booting the trimmed system on the disk. systemd-networkd starts in less than 1 second after booting. the STEP B has not been run yet, so it will wait for several hundred milliseconds here, as follows: Jul 20 22:00:47.432552 systemd-networkd[210]: eth0: bringing link up ... Jul 20 22:00:47.446108 systemd-networkd[210]: eth0: flags change: +UP +LOWER_UP ... Jul 20 22:00:47.781463 systemd-networkd[210]: eth0: flags change: +RUNNING Note: dhcp pays attention to IFF_RUNNING status, we may refer to: https://www.kernel.org/doc/Documentation/networking/operstates.txt A routing daemon or dhcp client just needs to care for IFF_RUNNING or waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before considering the interface / querying a DHCP address. Finally, the STEP B above only updates the value of operstate based on the known state (operstate/state) on the net_device, without any hardware interaction involved, so it is not very reasonable to wait for 1 second there. By adding: + if ((dev->flags & IFF_UP) && dev->operstate == IF_OPER_DOWN) + return true; + We hope to improve the linkwatch_urgent_event function a bit. Hope to get more of your advice and guidance. Best wishes, Wen
Re: [PATCH 2/3] KVM: x86: introduce KVM_MEM_PCI_HOLE memory
Andrew Jones writes: > On Tue, Jul 28, 2020 at 04:37:40PM +0200, Vitaly Kuznetsov wrote: >> PCIe config space can (depending on the configuration) be quite big but >> usually is sparsely populated. Guest may scan it by accessing individual >> device's page which, when device is missing, is supposed to have 'pci >> hole' semantics: reads return '0xff' and writes get discarded. Compared >> to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate >> real memory and stuff it with '0xff'. >> >> Suggested-by: Michael S. Tsirkin >> Signed-off-by: Vitaly Kuznetsov >> --- >> Documentation/virt/kvm/api.rst | 19 +++- >> arch/x86/include/uapi/asm/kvm.h | 1 + >> arch/x86/kvm/mmu/mmu.c | 5 - >> arch/x86/kvm/mmu/paging_tmpl.h | 3 +++ >> arch/x86/kvm/x86.c | 10 ++--- >> include/linux/kvm_host.h| 7 +- >> include/uapi/linux/kvm.h| 3 ++- >> virt/kvm/kvm_main.c | 39 +++-- >> 8 files changed, 68 insertions(+), 19 deletions(-) >> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst >> index 644e5326aa50..fbbf533a331b 100644 >> --- a/Documentation/virt/kvm/api.rst >> +++ b/Documentation/virt/kvm/api.rst >> @@ -1241,6 +1241,7 @@ yet and must be cleared on entry. >>/* for kvm_memory_region::flags */ >>#define KVM_MEM_LOG_DIRTY_PAGES (1UL << 0) >>#define KVM_MEM_READONLY (1UL << 1) >> + #define KVM_MEM_PCI_HOLE (1UL << 2) >> >> This ioctl allows the user to create, modify or delete a guest physical >> memory slot. Bits 0-15 of "slot" specify the slot id and this value >> @@ -1268,12 +1269,18 @@ It is recommended that the lower 21 bits of >> guest_phys_addr and userspace_addr >> be identical. This allows large pages in the guest to be backed by large >> pages in the host. >> >> -The flags field supports two flags: KVM_MEM_LOG_DIRTY_PAGES and >> -KVM_MEM_READONLY. The former can be set to instruct KVM to keep track of >> -writes to memory within the slot. See KVM_GET_DIRTY_LOG ioctl to know how >> to >> -use it. The latter can be set, if KVM_CAP_READONLY_MEM capability allows >> it, >> -to make a new slot read-only. In this case, writes to this memory will be >> -posted to userspace as KVM_EXIT_MMIO exits. >> +The flags field supports the following flags: KVM_MEM_LOG_DIRTY_PAGES, >> +KVM_MEM_READONLY, KVM_MEM_READONLY: > > The second KVM_MEM_READONLY should be KVM_MEM_PCI_HOLE. Or just drop the > list here, as they're listed below anyway > >> +- KVM_MEM_LOG_DIRTY_PAGES can be set to instruct KVM to keep track of >> writes to >> + memory within the slot. See KVM_GET_DIRTY_LOG ioctl to know how to use >> it. >> +- KVM_MEM_READONLY can be set, if KVM_CAP_READONLY_MEM capability allows it, >> + to make a new slot read-only. In this case, writes to this memory will be >> + posted to userspace as KVM_EXIT_MMIO exits. >> +- KVM_MEM_PCI_HOLE can be set, if KVM_CAP_PCI_HOLE_MEM capability allows it, >> + to create a new virtual read-only slot which will always return '0xff' >> when >> + guest reads from it. 'userspace_addr' has to be set to NULL. This flag is >> + mutually exclusive with KVM_MEM_LOG_DIRTY_PAGES/KVM_MEM_READONLY. All >> writes >> + to this memory will be posted to userspace as KVM_EXIT_MMIO exits. > > I see 2/3's of this text is copy+pasted from above, but how about this > > - KVM_MEM_LOG_DIRTY_PAGES: log writes. Use KVM_GET_DIRTY_LOG to retreive >the log. > - KVM_MEM_READONLY: exit to userspace with KVM_EXIT_MMIO on writes. Only >available when KVM_CAP_READONLY_MEM is present. > - KVM_MEM_PCI_HOLE: always return 0xff on reads, exit to userspace with >KVM_EXIT_MMIO on writes. Only available when KVM_CAP_PCI_HOLE_MEM is >present. When setting the memory region 'userspace_addr' must be NULL. >This flag is mutually exclusive with KVM_MEM_LOG_DIRTY_PAGES and with >KVM_MEM_READONLY. Sound better, thanks! Will add in v2. > >> >> When the KVM_CAP_SYNC_MMU capability is available, changes in the backing of >> the memory region are automatically reflected into the guest. For example, >> an >> diff --git a/arch/x86/include/uapi/asm/kvm.h >> b/arch/x86/include/uapi/asm/kvm.h >> index 17c5a038f42d..cf80a26d74f5 100644 >> --- a/arch/x86/include/uapi/asm/kvm.h >> +++ b/arch/x86/include/uapi/asm/kvm.h >> @@ -48,6 +48,7 @@ >> #define __KVM_HAVE_XSAVE >> #define __KVM_HAVE_XCRS >> #define __KVM_HAVE_READONLY_MEM >> +#define __KVM_HAVE_PCI_HOLE_MEM >> >> /* Architectural interrupt line count. */ >> #define KVM_NR_INTERRUPTS 256 >> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c >> index 8597e8102636..c2e3a1deafdd 100644 >> --- a/arch/x86/kvm/mmu/mmu.c >> +++ b/arch/x86/kvm/mmu/mmu.c >> @@ -3253,7 +3253,7 @@ static int kvm_mmu_hugepage_adjust(struct kvm_vcpu >> *vcpu, gfn_t gfn, >> return PG_LEVEL_4K; >> >> slot = gfn_to_memslot_dirty_bitmap(vcpu, gf
[PATCH v8 1/4] scsi: ufs: Add UFS feature related parameter
This is a patch for parameters to be used for UFS feature and HPB
module.
Reviewed-by: Can Guo
Tested-by: Bean Huo
Signed-off-by: Daejun Park
---
drivers/scsi/ufs/ufs.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index f8ab16f30fdc..ae557b8d3eba 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -122,6 +122,7 @@ enum flag_idn {
QUERY_FLAG_IDN_WB_EN= 0x0E,
QUERY_FLAG_IDN_WB_BUFF_FLUSH_EN = 0x0F,
QUERY_FLAG_IDN_WB_BUFF_FLUSH_DURING_HIBERN8 = 0x10,
+ QUERY_FLAG_IDN_HPB_RESET= 0x11,
};
/* Attribute idn for Query requests */
@@ -195,6 +196,9 @@ enum unit_desc_param {
UNIT_DESC_PARAM_PHY_MEM_RSRC_CNT= 0x18,
UNIT_DESC_PARAM_CTX_CAPABILITIES= 0x20,
UNIT_DESC_PARAM_LARGE_UNIT_SIZE_M1 = 0x22,
+ UNIT_DESC_HPB_LU_MAX_ACTIVE_REGIONS = 0x23,
+ UNIT_DESC_HPB_LU_PIN_REGION_START_OFFSET= 0x25,
+ UNIT_DESC_HPB_LU_NUM_PIN_REGIONS= 0x27,
UNIT_DESC_PARAM_WB_BUF_ALLOC_UNITS = 0x29,
};
@@ -235,6 +239,8 @@ enum device_desc_param {
DEVICE_DESC_PARAM_PSA_MAX_DATA = 0x25,
DEVICE_DESC_PARAM_PSA_TMT = 0x29,
DEVICE_DESC_PARAM_PRDCT_REV = 0x2A,
+ DEVICE_DESC_PARAM_HPB_VER = 0x40,
+ DEVICE_DESC_PARAM_HPB_CONTROL = 0x42,
DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP = 0x4F,
DEVICE_DESC_PARAM_WB_PRESRV_USRSPC_EN = 0x53,
DEVICE_DESC_PARAM_WB_TYPE = 0x54,
@@ -283,6 +289,10 @@ enum geometry_desc_param {
GEOMETRY_DESC_PARAM_ENM4_MAX_NUM_UNITS = 0x3E,
GEOMETRY_DESC_PARAM_ENM4_CAP_ADJ_FCTR = 0x42,
GEOMETRY_DESC_PARAM_OPT_LOG_BLK_SIZE= 0x44,
+ GEOMETRY_DESC_HPB_REGION_SIZE = 0x48,
+ GEOMETRY_DESC_HPB_NUMBER_LU = 0x49,
+ GEOMETRY_DESC_HPB_SUBREGION_SIZE= 0x4A,
+ GEOMETRY_DESC_HPB_DEVICE_MAX_ACTIVE_REGIONS = 0x4B,
GEOMETRY_DESC_PARAM_WB_MAX_ALLOC_UNITS = 0x4F,
GEOMETRY_DESC_PARAM_WB_MAX_WB_LUNS = 0x53,
GEOMETRY_DESC_PARAM_WB_BUFF_CAP_ADJ = 0x54,
@@ -327,6 +337,7 @@ enum {
/* Possible values for dExtendedUFSFeaturesSupport */
enum {
+ UFS_DEV_HPB_SUPPORT = BIT(7),
UFS_DEV_WRITE_BOOSTER_SUP = BIT(8),
};
@@ -537,6 +548,7 @@ struct ufs_dev_info {
u8 *model;
u16 wspecversion;
u32 clk_gating_wait_us;
+ u8 b_ufs_feature_sup;
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;
--
2.17.1
Re: [PATCH 2/3] KVM: x86: introduce KVM_MEM_PCI_HOLE memory
Jim Mattson writes: > On Tue, Jul 28, 2020 at 7:38 AM Vitaly Kuznetsov wrote: >> >> PCIe config space can (depending on the configuration) be quite big but >> usually is sparsely populated. Guest may scan it by accessing individual >> device's page which, when device is missing, is supposed to have 'pci >> hole' semantics: reads return '0xff' and writes get discarded. Compared >> to the already existing KVM_MEM_READONLY, VMM doesn't need to allocate >> real memory and stuff it with '0xff'. > > Note that the bus error semantics described should apply to *any* > unbacked guest physical addresses, not just addresses in the PCI hole. > (Typically, this also applies to the standard local APIC page > (0xfee00xxx) when the local APIC is either disabled or in x2APIC mode, > which is an area that kvm has had trouble with in the past.) Yes, we can make KVM return 0xff on all read access to unbacked memory, not only KVM_MEM_PCI_HOLE slots (and drop them completely). This, however, takes the control from userspace: with KVM_MEM_PCI_HOLE memslots we're saying 'accessing this unbacked memory is fine' and we can still trap accesses to all other places. This should help in detecting misbehaving guests. -- Vitaly
[PATCH v8 2/4] scsi: ufs: Introduce HPB feature
This is a patch for the HPB feature.
This patch adds HPB function calls to UFS core driver.
The mininum size of the memory pool used in the HPB is implemented as a
Kconfig parameter (SCSI_UFS_HPB_HOST_MEM), so that it can be configurable.
Tested-by: Bean Huo
Signed-off-by: Daejun Park
---
drivers/scsi/ufs/Kconfig | 18 +
drivers/scsi/ufs/Makefile | 1 +
drivers/scsi/ufs/ufshcd.c | 42 +++
drivers/scsi/ufs/ufshcd.h | 9 +
drivers/scsi/ufs/ufshpb.c | 738 ++
drivers/scsi/ufs/ufshpb.h | 169 +
6 files changed, 977 insertions(+)
create mode 100644 drivers/scsi/ufs/ufshpb.c
create mode 100644 drivers/scsi/ufs/ufshpb.h
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index f6394999b98c..33296478f411 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -182,3 +182,21 @@ config SCSI_UFS_CRYPTO
Enabling this makes it possible for the kernel to use the crypto
capabilities of the UFS device (if present) to perform crypto
operations on data being transferred to/from the device.
+
+config SCSI_UFS_HPB
+ bool "Support UFS Host Performance Booster"
+ depends on SCSI_UFSHCD
+ help
+ A UFS HPB Feature improves random read performance. It caches
+ L2P map of UFS to host DRAM. The driver uses HPB read command
+ by piggybacking physical page number for bypassing FTL's L2P address
+ translation.
+
+config SCSI_UFS_HPB_HOST_MEM
+ int "Host-side cached memory size (KB) for HPB support"
+ default 32
+ depends on SCSI_UFS_HPB
+ help
+ The mininum size of the memory pool used in the HPB module. It can
+ be configurable by the user. If this value is larger than required
+ memory size, kernel resizes cached memory size.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 4679af1b564e..663e17cee359 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SCSI_UFSHCD) += ufshcd-core.o
ufshcd-core-y += ufshcd.o ufs-sysfs.o
ufshcd-core-$(CONFIG_SCSI_UFS_BSG) += ufs_bsg.o
ufshcd-core-$(CONFIG_SCSI_UFS_CRYPTO) += ufshcd-crypto.o
+ufshcd-core-$(CONFIG_SCSI_UFS_HPB) += ufshpb.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
obj-$(CONFIG_SCSI_UFS_HISI) += ufs-hisi.o
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 307622284239..c60a6bf6ddc6 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -234,6 +234,17 @@ static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool
enable);
static int ufshcd_wb_toggle_flush_during_h8(struct ufs_hba *hba, bool set);
static inline void ufshcd_wb_toggle_flush(struct ufs_hba *hba, bool enable);
+#ifndef CONFIG_SCSI_UFS_HPB
+static void ufshpb_resume(struct ufs_hba *hba) {}
+static void ufshpb_suspend(struct ufs_hba *hba) {}
+static void ufshpb_reset(struct ufs_hba *hba) {}
+static void ufshpb_reset_host(struct ufs_hba *hba) {}
+static void ufshpb_rsp_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) {}
+static void ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb *lrbp) {}
+static void ufshpb_remove(struct ufs_hba *hba) {}
+static void ufshpb_scan_feature(struct ufs_hba *hba) {}
+#endif
+
static inline bool ufshcd_valid_tag(struct ufs_hba *hba, int tag)
{
return tag >= 0 && tag < hba->nutrs;
@@ -2559,6 +2570,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *cmd)
ufshcd_comp_scsi_upiu(hba, lrbp);
+ ufshpb_prep(hba, lrbp);
+
err = ufshcd_map_sg(hba, lrbp);
if (err) {
lrbp->cmd = NULL;
@@ -4681,6 +4694,19 @@ static int ufshcd_change_queue_depth(struct scsi_device
*sdev, int depth)
return scsi_change_queue_depth(sdev, depth);
}
+static void ufshcd_hpb_configure(struct ufs_hba *hba, struct scsi_device *sdev)
+{
+ /* skip well-known LU */
+ if (sdev->lun >= UFS_UPIU_MAX_UNIT_NUM_ID)
+ return;
+
+ if (!(hba->dev_info.b_ufs_feature_sup & UFS_DEV_HPB_SUPPORT))
+ return;
+
+ atomic_inc(&hba->ufsf.slave_conf_cnt);
+ wake_up(&hba->ufsf.sdev_wait);
+}
+
/**
* ufshcd_slave_configure - adjust SCSI device configurations
* @sdev: pointer to SCSI device
@@ -4690,6 +4716,8 @@ static int ufshcd_slave_configure(struct scsi_device
*sdev)
struct ufs_hba *hba = shost_priv(sdev->host);
struct request_queue *q = sdev->request_queue;
+ ufshcd_hpb_configure(hba, sdev);
+
blk_queue_update_dma_pad(q, PRDT_DATA_BYTE_COUNT_PAD - 1);
if (ufshcd_is_rpm_autosuspend_allowed(hba))
@@ -4818,6 +4846,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
*/
pm_runtime_get_noresume(hba->dev);
}
+
+ if
Re: [PATCH 4.19 0/6] 4.19.138-rc1 review
On Wed, 5 Aug 2020 at 21:23, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.138 release. > There are 6 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri, 07 Aug 2020 15:34:53 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.138-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.138-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 2f4ec68a8dc81295799b14aaebf6dd12aec9a2fa git describe: v4.19.137-7-g2f4ec68a8dc8 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.137-7-g2f4ec68a8dc8 No regressions (compared to build v4.19.136-53-ga820898d10fd) No fixes (compared to build v4.19.136-53-ga820898d10fd) Ran 34829 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * igt-gpu-tools * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-ipc-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * ltp-dio-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-mm-tests * network-basic-tests * ltp-commands-tests * ltp-math-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * ssuite -- Linaro LKFT https://lkft.linaro.org
Re: [PATCHv2 2/2] hwrng: optee: fix wait use case
On Thu, 6 Aug 2020 at 13:44, Jorge Ramirez-Ortiz, Foundries
wrote:
>
> On 06/08/20, Sumit Garg wrote:
> > On Thu, 6 Aug 2020 at 12:00, Jorge Ramirez-Ortiz, Foundries
> > wrote:
> > >
> > > On 06/08/20, Sumit Garg wrote:
> > > > On Thu, 6 Aug 2020 at 02:08, Jorge Ramirez-Ortiz, Foundries
> > > > wrote:
> > > > >
> > > > > On 05/08/20, Sumit Garg wrote:
> > > > > > Apologies for my delayed response as I was busy with some other
> > > > > > tasks
> > > > > > along with holidays.
> > > > >
> > > > > no pb! was just making sure this wasnt falling through some cracks.
> > > > >
> > > > > >
> > > > > > On Fri, 24 Jul 2020 at 19:53, Jorge Ramirez-Ortiz, Foundries
> > > > > > wrote:
> > > > > > >
> > > > > > > On 24/07/20, Sumit Garg wrote:
> > > > > > > > On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > The current code waits for data to be available before
> > > > > > > > > attempting a
> > > > > > > > > second read. However the second read would not be executed as
> > > > > > > > > the
> > > > > > > > > while loop exits.
> > > > > > > > >
> > > > > > > > > This fix does not wait if all data has been read and reads a
> > > > > > > > > second
> > > > > > > > > time if only partial data was retrieved on the first read.
> > > > > > > > >
> > > > > > > > > This fix also does not attempt to read if not data is
> > > > > > > > > requested.
> > > > > > > >
> > > > > > > > I am not sure how this is possible, can you elaborate?
> > > > > > >
> > > > > > > currently, if the user sets max 0, get_optee_rng_data will
> > > > > > > regardless
> > > > > > > issuese a call to the secure world requesting 0 bytes from the RNG
> > > > > > >
> > > > > >
> > > > > > This case is already handled by core API: rng_dev_read().
> > > > >
> > > > > ah ok good point, you are right
> > > > > but yeah, there is no consequence to the actual patch.
> > > > >
> > > >
> > > > So, at least you could get rid of the corresponding text from commit
> > > > message.
> > > >
> > > > > >
> > > > > > > with this patch, this request is avoided.
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Signed-off-by: Jorge Ramirez-Ortiz
> > > > > > > > > ---
> > > > > > > > > v2: tidy up the while loop to avoid reading when no data is
> > > > > > > > > requested
> > > > > > > > >
> > > > > > > > > drivers/char/hw_random/optee-rng.c | 4 ++--
> > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/char/hw_random/optee-rng.c
> > > > > > > > > b/drivers/char/hw_random/optee-rng.c
> > > > > > > > > index 5bc4700c4dae..a99d82949981 100644
> > > > > > > > > --- a/drivers/char/hw_random/optee-rng.c
> > > > > > > > > +++ b/drivers/char/hw_random/optee-rng.c
> > > > > > > > > @@ -122,14 +122,14 @@ static int optee_rng_read(struct hwrng
> > > > > > > > > *rng, void *buf, size_t max, bool wait)
> > > > > > > > > if (max > MAX_ENTROPY_REQ_SZ)
> > > > > > > > > max = MAX_ENTROPY_REQ_SZ;
> > > > > > > > >
> > > > > > > > > - while (read == 0) {
> > > > > > > > > + while (read < max) {
> > > > > > > > > rng_size = get_optee_rng_data(pvt_data, data,
> > > > > > > > > (max - read));
> > > > > > > > >
> > > > > > > > > data += rng_size;
> > > > > > > > > read += rng_size;
> > > > > > > > >
> > > > > > > > > if (wait && pvt_data->data_rate) {
> > > > > > > > > - if (timeout-- == 0)
> > > > > > > > > + if ((timeout-- == 0) || (read == max))
> > > > > > > >
> > > > > > > > If read == max, would there be any sleep?
> > > > > > >
> > > > > > > no but I see no reason why there should be a wait since we
> > > > > > > already have
> > > > > > > all the data that we need; the msleep is only required when we
> > > > > > > need to
> > > > > > > wait for the RNG to generate entropy for the number of bytes we
> > > > > > > are
> > > > > > > requesting. if we are requesting 0 bytes, the entropy is already
> > > > > > > available. at leat this is what makes sense to me.
> > > > > > >
> > > > > >
> > > > > > Wouldn't it lead to a call as msleep(0); that means no wait as well?
> > > > >
> > > > > I dont understand: there is no reason to wait if read == max and this
> > > > > patch will not wait: if read == max it calls 'return read'
> > > > >
> > > > > am I misunderstanding your point?
> > > >
> > > > What I mean is that we shouldn't require this extra check here as
> > > > there wasn't any wait if read == max with existing implementation too.
> > >
> > > um, I am getting confused Sumit
> > >
> > > with the exisiting implementation (the one we aim to replace), if
> > > get_optee_rng_data reads all the values requested on the first call (ie,
> > > read = 0) with wait set to true, the call will wait with msleep(0). Which
> > > is unnecessary and waits for a jiffy (ie, the call to msleep 0 will
[PATCH v8 3/4] scsi: ufs: L2P map management for HPB read
This is a patch for managing L2P map in HPB module.
The HPB divides logical addresses into several regions. A region consists
of several sub-regions. The sub-region is a basic unit where L2P mapping is
managed. The driver loads L2P mapping data of each sub-region. The loaded
sub-region is called active-state. The HPB driver unloads L2P mapping data
as region unit. The unloaded region is called inactive-state.
Sub-region/region candidates to be loaded and unloaded are delivered from
the UFS device. The UFS device delivers the recommended active sub-region
and inactivate region to the driver using sensedata.
The HPB module performs L2P mapping management on the host through the
delivered information.
A pinned region is a pre-set regions on the UFS device that is always
activate-state.
The data structure for map data request and L2P map uses mempool API,
minimizing allocation overhead while avoiding static allocation.
The map_work manages active/inactive by 2 "to-do" lists.
Each hpb lun maintains 2 "to-do" lists:
hpb->lh_inact_rgn - regions to be inactivated, and
hpb->lh_act_srgn - subregions to be activated
Those lists are maintained on IO completion.
Tested-by: Bean Huo
Signed-off-by: Daejun Park
---
drivers/scsi/ufs/ufshpb.c | 973 +-
drivers/scsi/ufs/ufshpb.h | 72 +++
2 files changed, 1039 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index e1f9c68ae415..25cd7153f102 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -26,6 +26,14 @@ static ssize_t __name##_show(struct ufshpb_lu *hpb, char
*buf) \
#define HPB_ATTR_RO(_name) \
struct ufshpb_sysfs_entry hpb_attr_##_name = __ATTR_RO(_name)
+/* memory management */
+static struct kmem_cache *ufshpb_mctx_cache;
+static mempool_t *ufshpb_mctx_pool;
+static mempool_t *ufshpb_page_pool;
+static unsigned int ufshpb_host_map_kbytes;
+
+static struct workqueue_struct *ufshpb_wq;
+
/* HPB enabled lu list */
static LIST_HEAD(lh_hpb_lu);
@@ -38,6 +46,62 @@ static inline int ufshpb_is_valid_srgn(struct ufshpb_region
*rgn,
srgn->srgn_state == HPB_SRGN_VALID;
}
+static inline bool ufshpb_is_general_lun(int lun)
+{
+ return lun < UFS_UPIU_MAX_UNIT_NUM_ID;
+}
+
+static inline bool
+ufshpb_is_pinned_region(struct ufshpb_lu *hpb, int rgn_idx)
+{
+ if (hpb->lu_pinned_end != PINNED_NOT_SET &&
+ rgn_idx >= hpb->lu_pinned_start &&
+ rgn_idx <= hpb->lu_pinned_end)
+ return true;
+
+ return false;
+}
+
+static bool ufshpb_is_empty_rsp_lists(struct ufshpb_lu *hpb)
+{
+ bool ret = true;
+ unsigned long flags;
+
+ spin_lock_irqsave(&hpb->rsp_list_lock, flags);
+ if (!list_empty(&hpb->lh_inact_rgn) || !list_empty(&hpb->lh_act_srgn))
+ ret = false;
+ spin_unlock_irqrestore(&hpb->rsp_list_lock, flags);
+
+ return ret;
+}
+
+static inline int ufshpb_may_field_valid(struct ufs_hba *hba,
+struct ufshcd_lrb *lrbp,
+struct ufshpb_rsp_field *rsp_field)
+{
+ if (be16_to_cpu(rsp_field->sense_data_len) != DEV_SENSE_SEG_LEN ||
+ rsp_field->desc_type != DEV_DES_TYPE ||
+ rsp_field->additional_len != DEV_ADDITIONAL_LEN ||
+ rsp_field->hpb_type == HPB_RSP_NONE ||
+ rsp_field->active_rgn_cnt > MAX_ACTIVE_NUM ||
+ rsp_field->inactive_rgn_cnt > MAX_INACTIVE_NUM ||
+ (!rsp_field->active_rgn_cnt && !rsp_field->inactive_rgn_cnt))
+ return -EINVAL;
+
+ if (!ufshpb_is_general_lun(lrbp->lun)) {
+ dev_warn(hba->dev, "ufshpb: lun(%d) not supported\n",
+lrbp->lun);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static inline struct ufshpb_lu *ufshpb_get_hpb_data(struct scsi_cmnd *cmd)
+{
+ return cmd->device->hostdata;
+}
+
static inline int ufshpb_get_state(struct ufshpb_lu *hpb)
{
return atomic_read(&hpb->hpb_state);
@@ -52,8 +116,737 @@ void ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb
*lrbp)
{
}
+static struct ufshpb_req *ufshpb_get_map_req(struct ufshpb_lu *hpb,
+struct ufshpb_subregion *srgn)
+{
+ struct ufshpb_req *map_req;
+ struct request *req;
+ struct bio *bio;
+
+ map_req = kmem_cache_alloc(hpb->map_req_cache, GFP_KERNEL);
+ if (!map_req)
+ return NULL;
+
+ req = blk_get_request(hpb->sdev_ufs_lu->request_queue,
+ REQ_OP_SCSI_IN, BLK_MQ_REQ_PREEMPT);
+ if (IS_ERR(req))
+ goto free_map_req;
+
+ bio = bio_alloc(GFP_KERNEL, hpb->pages_per_srgn);
+ if (!bio) {
+ blk_put_request(req);
+ goto free_map_req;
+ }
+
+ map_req->hpb = hpb;
+ map_req->req = req;
+ map_req->bio = bio;
+
+
Re: [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks
Looks great! Thanks. Reviewed-by: Dan Carpenter regards, dan carpenter
Re: [PATCH v3 3/3] powerpc/uaccess: simplify the get_fs() set_fs() logic
Do you urgently need this? My plan for 5.10 is to rebased and submit the remaining bits of this branch: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/set_fs-removal which will kill off set_fs/get_fs entirely.
Re: [PATCH v1 2/2] perf/core: Fake regs for leaked kernel samples
On Thu, Aug 06, 2020 at 10:26:29AM +0800, Jin, Yao wrote:
> > +static struct pt_regs *sanitize_sample_regs(struct perf_event *event,
> > struct pt_regs *regs)
> > +{
> > + struct pt_regs *sample_regs = regs;
> > +
> > + /* user only */
> > + if (!event->attr.exclude_kernel || !event->attr.exclude_hv ||
> > + !event->attr.exclude_host || !event->attr.exclude_guest)
> > + return sample_regs;
> > +
>
> Is this condition correct?
>
> Say counting user event on host, exclude_kernel = 1 and exclude_host = 0. It
> will go "return sample_regs" path.
I'm not sure, I'm terminally confused on virt stuff.
Suppose we have nested virt:
L0-hv
|
G0/L1-hv
|
G1
And we're running in G0, then:
- 'exclude_hv' would exclude L0 events
- 'exclude_host' would ... exclude L1-hv events?
- 'exclude_guest' would ... exclude G1 events?
Then the next question is, if G0 is a host, does the L1-hv run in
G0 userspace or G0 kernel space?
I was assuming G0 userspace would not include anything L1 (kvm is a
kernel module after all), but what do I know.
> > @@ -11609,7 +11636,8 @@ SYSCALL_DEFINE5(perf_event_open,
> > if (err)
> > return err;
> > - if (!attr.exclude_kernel) {
> > + if (!attr.exclude_kernel || !attr.exclude_callchain_kernel ||
> > + !attr.exclude_hv || !attr.exclude_host || !attr.exclude_guest) {
> > err = perf_allow_kernel(&attr);
> > if (err)
> > return err;
> >
>
> I can understand the conditions "!attr.exclude_kernel ||
> !attr.exclude_callchain_kernel".
>
> But I'm not very sure about the "!attr.exclude_hv || !attr.exclude_host ||
> !attr.exclude_guest".
Well, I'm very sure G0 userspace should never see L0 or G1 state, so
exclude_hv and exclude_guest had better be true.
> On host, exclude_hv = 1, exclude_guest = 1 and exclude_host = 0, right?
Same as above, is G0 host state G0 userspace?
> So even exclude_kernel = 1 but exclude_host = 0, we will still go
> perf_allow_kernel path. Please correct me if my understanding is wrong.
Yes, because with those permission checks in place it means you have
permission to see kernel bits.
Re: [PATCH 0/3] KVM: x86: KVM_MEM_PCI_HOLE memory
"Michael S. Tsirkin" writes: > On Tue, Jul 28, 2020 at 04:37:38PM +0200, Vitaly Kuznetsov wrote: >> This is a continuation of "[PATCH RFC 0/5] KVM: x86: KVM_MEM_ALLONES >> memory" work: >> https://lore.kernel.org/kvm/20200514180540.52407-1-vkuzn...@redhat.com/ >> and pairs with Julia's "x86/PCI: Use MMCONFIG by default for KVM guests": >> https://lore.kernel.org/linux-pci/20200722001513.298315-1-jus...@redhat.com/ >> >> PCIe config space can (depending on the configuration) be quite big but >> usually is sparsely populated. Guest may scan it by accessing individual >> device's page which, when device is missing, is supposed to have 'pci >> hole' semantics: reads return '0xff' and writes get discarded. >> >> When testing Linux kernel boot with QEMU q35 VM and direct kernel boot >> I observed 8193 accesses to PCI hole memory. When such exit is handled >> in KVM without exiting to userspace, it takes roughly 0.01 sec. >> Handling the same exit in userspace is six times slower (0.06 sec) so >> the overal; difference is 0.04 sec. This may be significant for 'microvm' >> ideas. >> >> Note, the same speed can already be achieved by using KVM_MEM_READONLY >> but doing this would require allocating real memory for all missing >> devices and e.g. 8192 pages gives us 32mb. This will have to be allocated >> for each guest separately and for 'microvm' use-cases this is likely >> a no-go. >> >> Introduce special KVM_MEM_PCI_HOLE memory: userspace doesn't need to >> back it with real memory, all reads from it are handled inside KVM and >> return '0xff'. Writes still go to userspace but these should be extremely >> rare. >> >> The original 'KVM_MEM_ALLONES' idea had additional optimizations: KVM >> was mapping all 'PCI hole' pages to a single read-only page stuffed with >> 0xff. This is omitted in this submission as the benefits are unclear: >> KVM will have to allocate SPTEs (either on demand or aggressively) and >> this also consumes time/memory. > > Curious about this: if we do it aggressively on the 1st fault, > how long does it take to allocate 256 huge page SPTEs? > And the amount of memory seems pretty small then, right? Right, this could work but we'll need a 2M region (one per KVM host of course) filled with 0xff-s instead of a single 4k page. Generally, I'd like to reach an agreement on whether this feature (and the corresponding Julia's patch addding PV feature bit) is worthy. In case it is (meaning it gets merged in this simplest form), we can suggest further improvements. It would also help if firmware (SeaBIOS, OVMF) would start recognizing the PV feature bit too, this way we'll be seeing even bigger improvement and this may or may not be a deal-breaker when it comes to the 'aggressive PTE mapping' idea. -- Vitaly
Re: [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks
On Tue, Aug 04, 2020 at 06:35:20AM +, Oleksandr Andrushchenko wrote:
>
> On 8/4/20 9:12 AM, Jürgen Groß wrote:
> > On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
> >> display frontend" from Apr 3, 2018, leads to the following static
> >> checker warning:
> >>
> >> drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
> >> warn: passing zero to 'ERR_CAST'
> >>
> >> drivers/gpu/drm/xen/xen_drm_front_gem.c
> >> 133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device
> >> *dev,
> >> 134 size_t size)
> >> 135 {
> >> 136 struct xen_gem_object *xen_obj;
> >> 137
> >> 138 xen_obj = gem_create(dev, size);
> >> 139 if (IS_ERR_OR_NULL(xen_obj))
> >> 140 return ERR_CAST(xen_obj);
> >>
> >> Fix this and the rest of misused places with IS_ERR_OR_NULL in the
> >> driver.
> >>
> >> Fixes: c575b7eeb89f: "drm/xen-front: Add support for Xen PV display
> >> frontend"
> >
> > Again forgot to Cc stable?
>
> I was just not sure if these minor fixes need to go the stable, but I will add
Correct. It's still a bug because it's setting the error code
incorrectly on the impossible path. But fortunately impossible things
don't affect runtime.
regards,
dan carpenter
[PATCH v17 04/12] soc: mediatek: Add multiple step bus protection control
MT8192, MT8183 and MT6765 have more control steps of bus protection
than previous project. And there add more bus protection registers
reside at infracfg & smi-common.
Extend function to support multiple step bus protection control
with more customized arguments.
And then use bp_table for bus protection of all compatibles,
instead of mixing bus_prot_mask and bus_prot_reg_update.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 235 +++---
1 file changed, 168 insertions(+), 67 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index b603af7..5a2c323 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -78,11 +78,6 @@
#define PWR_STATUS_HIF1BIT(26) /* MT7622 */
#define PWR_STATUS_WB BIT(27) /* MT7622 */
-#define INFRA_TOPAXI_PROTECTEN 0x0220
-#define INFRA_TOPAXI_PROTECTSTA1 0x0228
-#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
-#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
-
#define MT2701_TOP_AXI_PROT_EN_MM_M0 BIT(1)
#define MT2701_TOP_AXI_PROT_EN_CONN_M BIT(2)
#define MT2701_TOP_AXI_PROT_EN_CONN_S BIT(8)
@@ -103,6 +98,45 @@
#define MAX_CLKS 3
+#define MAX_STEPS 5
+
+#define _BUS_PROT(_type, _set_ofs, _clr_ofs, \
+ _en_ofs, _sta_ofs, _mask, _ignore_clr_ack) {\
+ .type = _type, \
+ .set_ofs = _set_ofs,\
+ .clr_ofs = _clr_ofs,\
+ .en_ofs = _en_ofs, \
+ .sta_ofs = _sta_ofs,\
+ .mask = _mask, \
+ .ignore_clr_ack = _ignore_clr_ack, \
+ }
+
+#define BUS_PROT(_type, _set_ofs, _clr_ofs,\
+ _en_ofs, _sta_ofs, _mask) \
+ _BUS_PROT(_type, _set_ofs, _clr_ofs,\
+ _en_ofs, _sta_ofs, _mask, false)
+
+#define BUS_PROT_IGN(_type, _set_ofs, _clr_ofs,\
+ _en_ofs, _sta_ofs, _mask) \
+ _BUS_PROT(_type, _set_ofs, _clr_ofs,\
+ _en_ofs, _sta_ofs, _mask, true)
+
+enum regmap_type {
+ INVALID_TYPE = 0,
+ IFR_TYPE,
+ SMI_TYPE,
+};
+
+struct bus_prot {
+ enum regmap_type type;
+ u32 set_ofs;
+ u32 clr_ofs;
+ u32 en_ofs;
+ u32 sta_ofs;
+ u32 mask;
+ bool ignore_clr_ack;
+};
+
/**
* struct scp_domain_data - scp domain data for power on/off flow
* @name: The domain name.
@@ -110,9 +144,9 @@
* @ctl_offs: The offset for main power control register.
* @sram_pdn_bits: The mask for sram power control bits.
* @sram_pdn_ack_bits: The mask for sram power control acked bits.
- * @bus_prot_mask: The mask for single step bus protection.
* @basic_clk_name: The basic clocks required by this power domain.
* @caps: The flag for active wake-up action.
+ * @bp_table: The mask table for multiple step bus protection.
*/
struct scp_domain_data {
const char *name;
@@ -120,9 +154,9 @@ struct scp_domain_data {
int ctl_offs;
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
- u32 bus_prot_mask;
const char *basic_clk_name[MAX_CLKS];
u8 caps;
+ struct bus_prot bp_table[MAX_STEPS];
};
struct scp;
@@ -146,8 +180,8 @@ struct scp {
struct device *dev;
void __iomem *base;
struct regmap *infracfg;
+ struct regmap *smi_common;
struct scp_ctrl_reg ctrl_reg;
- bool bus_prot_reg_update;
};
struct scp_subdomain {
@@ -161,7 +195,6 @@ struct scp_soc_data {
const struct scp_subdomain *subdomains;
int num_subdomains;
const struct scp_ctrl_reg regs;
- bool bus_prot_reg_update;
};
static int scpsys_domain_is_on(struct scp_domain *scpd)
@@ -271,53 +304,87 @@ static int scpsys_sram_disable(struct scp_domain *scpd,
void __iomem *ctl_addr)
MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
}
+static int set_bus_protection(struct regmap *map, const struct bus_prot *bp)
+{
+ u32 val;
+
+ if (bp->set_ofs)
+ regmap_write(map, bp->set_ofs, bp->mask);
+ else
+ regmap_update_bits(map, bp->en_ofs, bp->mask, bp->mask);
+
+ return regmap_read_poll_timeout(map, bp->sta_ofs,
+ val, (val & bp->mask) == bp->mask,
+ MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
+}
+
+static int clear_bus_protection(struct regmap *map, const struct bus_prot *bp)
+{
+ u32 val;
+
+ if (bp->clr_ofs)
+ regmap_write(map, bp->clr_ofs, bp->mask);
+ else
+ regmap_update_bits(map, bp->en_ofs, bp->mask, 0);
+
+ if (bp->ignore_clr_ack)
+ return 0;
+
[PATCH v17 02/12] soc: mediatek: Add basic_clk_name to scp_power_data
Try to stop extending the clk_id or clk_names if there are
more and more new BASIC clocks. To get its own clocks by the
basic_clk_name of each power domain.
And then use basic_clk_name strings for all compatibles, instead of
mixing clk_id and clk_name.
Signed-off-by: Weiyi Lu
Reviewed-by: Nicolas Boichat
---
drivers/soc/mediatek/mtk-scpsys.c | 134 --
1 file changed, 41 insertions(+), 93 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index f669d37..c9c3cf7 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -78,34 +78,6 @@
#define PWR_STATUS_HIF1BIT(26) /* MT7622 */
#define PWR_STATUS_WB BIT(27) /* MT7622 */
-enum clk_id {
- CLK_NONE,
- CLK_MM,
- CLK_MFG,
- CLK_VENC,
- CLK_VENC_LT,
- CLK_ETHIF,
- CLK_VDEC,
- CLK_HIFSEL,
- CLK_JPGDEC,
- CLK_AUDIO,
- CLK_MAX,
-};
-
-static const char * const clk_names[] = {
- NULL,
- "mm",
- "mfg",
- "venc",
- "venc_lt",
- "ethif",
- "vdec",
- "hif_sel",
- "jpgdec",
- "audio",
- NULL,
-};
-
#define MAX_CLKS 3
/**
@@ -116,7 +88,7 @@ enum clk_id {
* @sram_pdn_bits: The mask for sram power control bits.
* @sram_pdn_ack_bits: The mask for sram power control acked bits.
* @bus_prot_mask: The mask for single step bus protection.
- * @clk_id: The basic clocks required by this power domain.
+ * @basic_clk_name: The basic clocks required by this power domain.
* @caps: The flag for active wake-up action.
*/
struct scp_domain_data {
@@ -126,7 +98,7 @@ struct scp_domain_data {
u32 sram_pdn_bits;
u32 sram_pdn_ack_bits;
u32 bus_prot_mask;
- enum clk_id clk_id[MAX_CLKS];
+ const char *basic_clk_name[MAX_CLKS];
u8 caps;
};
@@ -411,12 +383,19 @@ static int scpsys_power_off(struct generic_pm_domain
*genpd)
return ret;
}
-static void init_clks(struct platform_device *pdev, struct clk **clk)
+static int init_basic_clks(struct platform_device *pdev, struct clk **clk,
+ const char * const *name)
{
int i;
- for (i = CLK_NONE + 1; i < CLK_MAX; i++)
- clk[i] = devm_clk_get(&pdev->dev, clk_names[i]);
+ for (i = 0; i < MAX_CLKS && name[i]; i++) {
+ clk[i] = devm_clk_get(&pdev->dev, name[i]);
+
+ if (IS_ERR(clk[i]))
+ return PTR_ERR(clk[i]);
+ }
+
+ return 0;
}
static struct scp *init_scp(struct platform_device *pdev,
@@ -426,9 +405,8 @@ static struct scp *init_scp(struct platform_device *pdev,
{
struct genpd_onecell_data *pd_data;
struct resource *res;
- int i, j;
+ int i, ret;
struct scp *scp;
- struct clk *clk[CLK_MAX];
scp = devm_kzalloc(&pdev->dev, sizeof(*scp), GFP_KERNEL);
if (!scp)
@@ -481,8 +459,6 @@ static struct scp *init_scp(struct platform_device *pdev,
pd_data->num_domains = num;
- init_clks(pdev, clk);
-
for (i = 0; i < num; i++) {
struct scp_domain *scpd = &scp->domains[i];
struct generic_pm_domain *genpd = &scpd->genpd;
@@ -493,17 +469,9 @@ static struct scp *init_scp(struct platform_device *pdev,
scpd->data = data;
- for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
- struct clk *c = clk[data->clk_id[j]];
-
- if (IS_ERR(c)) {
- dev_err(&pdev->dev, "%s: clk unavailable\n",
- data->name);
- return ERR_CAST(c);
- }
-
- scpd->clk[j] = c;
- }
+ ret = init_basic_clks(pdev, scpd->clk, data->basic_clk_name);
+ if (ret)
+ return ERR_PTR(ret);
genpd->name = data->name;
genpd->power_off = scpsys_power_off;
@@ -560,7 +528,6 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.ctl_offs = SPM_CONN_PWR_CON,
.bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN_M |
MT2701_TOP_AXI_PROT_EN_CONN_S,
- .clk_id = {CLK_NONE},
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
[MT2701_POWER_DOMAIN_DISP] = {
@@ -568,7 +535,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.sta_mask = PWR_STATUS_DISP,
.ctl_offs = SPM_DIS_PWR_CON,
.sram_pdn_bits = GENMASK(11, 8),
- .clk_id = {CLK_MM},
+ .basic_clk_name = {"mm"},
.bus_prot_mask = MT2701_TOP_AXI_PROT_EN_MM_M0,
.caps = MTK_SCPD_ACTIVE_WAKEUP,
},
@@ -578,7 +545,7 @@ static void mtk_register
Re: [PATCH] Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled"
On Tue 2020-07-21 13:17:00, Miroslav Benes wrote:
> On Fri, 17 Jul 2020, Josh Poimboeuf wrote:
>
> > Use of the new -flive-patching flag was introduced with the following
> > commit:
> >
> > 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is
> > enabled")
> >
> > This reverts commit 43bd3a95c98e1a86b8b55d97f745c224ecff02b9.
> >
> > Fixes: 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is
> > enabled")
> > Reported-by: Randy Dunlap
> > Signed-off-by: Josh Poimboeuf
>
> Acked-by: Miroslav Benes
Acked-by: Petr Mladek
Hmm, the patch has not been pushed into livepatching.git and is not
available in the pull request for 5.9.
Is it OK to leave it for 5.10?
Or would you prefer to get it into 5.9 even on this stage?
I personally do not mind. It depends how urgent it is for others.
Best Regards,
Petr
[PATCH v17 00/12] Mediatek MT8183 scpsys support
This series is based on v5.8-rc1 change since v16: - Introduce hierarchical scpsys device node to show the dependency between each power domain. And could be more clearly to group subsys clocks into power domain sub node. change since v15: - remove unneeded error log in [PATCH 06/11] changes since v14: - fix commit message typo - use property name "mediatek,smi" for smi phandle changes since v13: - document optional property "smi-comm" - move defines in scpsyc.h to mtk-scpsys.c directly - minor coding sytle fixes change since v12: - separate the fix of comma at the end into a new patch [PATCH 09/11] changes since v11: - re-order patches "Remove infracfg misc driver support" and "Add multiple step bus protection" - add cap MTK_SCPD_SRAM_ISO for extra sram control - minor coding sytle fixes and reword commit messages changes since v10: - squash PATCH 04 and PATCH 06 in v9 into its previous patch - add "ignore_clr_ack" for multiple step bus protection control to have a clean definition of power domain data - keep the mask register bit definitions and do the same for MT8183 changes since v9: - add new PATCH 04 and PATCH 06 to replace by new method for all compatibles - add new PATCH 07 to remove infracfg misc driver - minor coding sytle fix changes since v7: - reword in binding document [PATCH 02/14] - fix error return checking bug in subsys clock control [PATCH 10/14] - add power domains properity to mfgcfg patch [PATCH 14/14] from https://patchwork.kernel.org/patch/11126199/ changes since v6: - remove the patch of SPDX license identifier because it's already fixed changes since v5: - fix documentation in [PATCH 04/14] - remove useless variable checking and reuse API of clock control in [PATCH 06/14] - coding style fix of bus protection control in [PATCH 08/14] - fix naming of new added data in [PATCH 09/14] - small refactor of multiple step bus protection control in [PATCH 10/14] changes since v4: - add property to mt8183 smi-common - seperate refactor patches and new add function - add power controller device node Weiyi Lu (12): dt-bindings: mediatek: Add property to mt8183 smi-common soc: mediatek: Add basic_clk_name to scp_power_data soc: mediatek: Remove infracfg misc driver support soc: mediatek: Add multiple step bus protection control dt-bindings: soc: Add MT8183 power dt-bindings soc: mediatek: Add support for hierarchical scpsys device node soc: mediatek: Add subsys clock control for bus protection soc: mediatek: Add extra sram control soc: mediatek: Add MT8183 scpsys support soc: mediatek: Add a comma at the end arm64: dts: Add power controller device node of MT8183 arm64: dts: Add power-domains property to mfgcfg .../mediatek,smi-common.txt | 2 +- .../bindings/soc/mediatek/scpsys.txt | 81 +- arch/arm64/boot/dts/mediatek/mt8183.dtsi | 124 +++ drivers/soc/mediatek/Kconfig | 10 - drivers/soc/mediatek/Makefile | 1 - drivers/soc/mediatek/mtk-infracfg.c | 79 -- drivers/soc/mediatek/mtk-scpsys.c | 770 ++ include/dt-bindings/power/mt8183-power.h | 26 + include/linux/soc/mediatek/infracfg.h | 39 - 9 files changed, 845 insertions(+), 287 deletions(-) delete mode 100644 drivers/soc/mediatek/mtk-infracfg.c create mode 100644 include/dt-bindings/power/mt8183-power.h delete mode 100644 include/linux/soc/mediatek/infracfg.h
[PATCH 0/3] Add board support for HK10 board variants
Added support for HK10-C1 and HK10-C2 board variants based on IPQ8074 SoC. Both these variants support dual QCN9000 PCIe cards that uses MHI communication protocol over PCIe. In addition, HK10-C1 support on-chip radio. Both these variants slightly differ in clock configuation for ethernet. Gokul Sriram Palanisamy (3): dt-bindings: qcom: Add ipq8074 bindings arm64: dts: Add board support for HK10 arm64: dts: Enabled mhi device over PCIe Documentation/devicetree/bindings/arm/qcom.yaml | 4 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/ipq8074-hk10-c1.dts| 11 ++ arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dts| 14 +++ arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi | 134 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 8 ++ 6 files changed, 173 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk10-c1.dts create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dts create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi -- 2.7.4
[PATCH v17 09/12] soc: mediatek: Add MT8183 scpsys support
Add scpsys driver for MT8183
Signed-off-by: Weiyi Lu
Reviewed-by: Nicolas Boichat
---
drivers/soc/mediatek/mtk-scpsys.c | 229 ++
1 file changed, 229 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 4587cef..9a699b4 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#define MTK_POLL_DELAY_US 10
#define MTK_POLL_TIMEOUTUSEC_PER_SEC
@@ -100,6 +101,34 @@
#define MT8173_TOP_AXI_PROT_EN_MFG_M1 BIT(22)
#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
+#define MT8183_TOP_AXI_PROT_EN_DISP(BIT(10) | BIT(11))
+#define MT8183_TOP_AXI_PROT_EN_CONN(BIT(13) | BIT(14))
+#define MT8183_TOP_AXI_PROT_EN_MFG (BIT(21) | BIT(22))
+#define MT8183_TOP_AXI_PROT_EN_CAM BIT(28)
+#define MT8183_TOP_AXI_PROT_EN_VPU_TOP BIT(27)
+#define MT8183_TOP_AXI_PROT_EN_1_DISP (BIT(16) | BIT(17))
+#define MT8183_TOP_AXI_PROT_EN_1_MFG GENMASK(21, 19)
+#define MT8183_TOP_AXI_PROT_EN_MM_ISP (BIT(3) | BIT(8))
+#define MT8183_TOP_AXI_PROT_EN_MM_ISP_2ND BIT(10)
+#define MT8183_TOP_AXI_PROT_EN_MM_CAM (BIT(4) | BIT(5) | \
+BIT(9) | BIT(13))
+#define MT8183_TOP_AXI_PROT_EN_MM_VPU_TOP (GENMASK(9, 6) | \
+BIT(12))
+#define MT8183_TOP_AXI_PROT_EN_MM_VPU_TOP_2ND (BIT(10) | BIT(11))
+#define MT8183_TOP_AXI_PROT_EN_MM_CAM_2ND BIT(11)
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE0_2ND (BIT(0) | BIT(2) | \
+BIT(4))
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE1_2ND (BIT(1) | BIT(3) | \
+BIT(5))
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE0 BIT(6)
+#define MT8183_TOP_AXI_PROT_EN_MCU_VPU_CORE1 BIT(7)
+#define MT8183_SMI_COMMON_SMI_CLAMP_DISP GENMASK(7, 0)
+#define MT8183_SMI_COMMON_SMI_CLAMP_VENC BIT(1)
+#define MT8183_SMI_COMMON_SMI_CLAMP_ISPBIT(2)
+#define MT8183_SMI_COMMON_SMI_CLAMP_CAM(BIT(3) |
BIT(4))
+#define MT8183_SMI_COMMON_SMI_CLAMP_VPU_TOP(BIT(5) | BIT(6))
+#define MT8183_SMI_COMMON_SMI_CLAMP_VDEC BIT(7)
+
#define MAX_CLKS 3
#define MAX_SUBSYS_CLKS 10
@@ -1246,6 +1275,194 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
{MT8173_POWER_DOMAIN_MFG_2D, MT8173_POWER_DOMAIN_MFG},
};
+/*
+ * MT8183 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt8183[] = {
+ [MT8183_POWER_DOMAIN_AUDIO] = {
+ .name = "audio",
+ .sta_mask = PWR_STATUS_AUDIO,
+ .ctl_offs = 0x0314,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .basic_clk_name = {"audio", "audio1", "audio2"},
+ },
+ [MT8183_POWER_DOMAIN_CONN] = {
+ .name = "conn",
+ .sta_mask = PWR_STATUS_CONN,
+ .ctl_offs = 0x032c,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .bp_table = {
+ BUS_PROT(IFR_TYPE, 0x2a0, 0x2a4, 0, 0x228,
+ MT8183_TOP_AXI_PROT_EN_CONN),
+ },
+ },
+ [MT8183_POWER_DOMAIN_MFG_ASYNC] = {
+ .name = "mfg_async",
+ .sta_mask = PWR_STATUS_MFG_ASYNC,
+ .ctl_offs = 0x0334,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .basic_clk_name = {"mfg"},
+ },
+ [MT8183_POWER_DOMAIN_MFG] = {
+ .name = "mfg",
+ .sta_mask = PWR_STATUS_MFG,
+ .ctl_offs = 0x0338,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_CORE0] = {
+ .name = "mfg_core0",
+ .sta_mask = BIT(7),
+ .ctl_offs = 0x034c,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_CORE1] = {
+ .name = "mfg_core1",
+ .sta_mask = BIT(20),
+ .ctl_offs = 0x0310,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT8183_POWER_DOMAIN_MFG_2D] = {
+ .name = "mfg_2d",
+ .sta_mask = PWR_STATUS_MFG_2D,
+ .ctl_offs = 0x0348,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GE
[PATCH 1/3] dt-bindings: qcom: Add ipq8074 bindings
Document the new device-tree bindings for boards HK10-C1 and HK10-C2 based on ipq8074 SoC. Signed-off-by: Gokul Sriram Palanisamy --- Documentation/devicetree/bindings/arm/qcom.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 6031aee..7b294be 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -47,6 +47,8 @@ description: | cp01-c1 dragonboard hk01 +hk10-c1 +hk10-c2 idp liquid mtp @@ -148,6 +150,8 @@ properties: - items: - enum: - qcom,ipq8074-hk01 + - qcom,ipq8074-hk10-c1 + - qcom,ipq8074-hk10-c2 - const: qcom,ipq8074 - items: -- 2.7.4
Re: [PATCH v1 2/2] perf/core: Fake regs for leaked kernel samples
On Thu, Aug 06, 2020 at 11:18:27AM +0200, pet...@infradead.org wrote:
> On Thu, Aug 06, 2020 at 10:26:29AM +0800, Jin, Yao wrote:
>
> > > +static struct pt_regs *sanitize_sample_regs(struct perf_event *event,
> > > struct pt_regs *regs)
> > > +{
> > > + struct pt_regs *sample_regs = regs;
> > > +
> > > + /* user only */
> > > + if (!event->attr.exclude_kernel || !event->attr.exclude_hv ||
> > > + !event->attr.exclude_host || !event->attr.exclude_guest)
> > > + return sample_regs;
> > > +
> >
> > Is this condition correct?
> >
> > Say counting user event on host, exclude_kernel = 1 and exclude_host = 0. It
> > will go "return sample_regs" path.
>
> I'm not sure, I'm terminally confused on virt stuff.
[A]
> Suppose we have nested virt:
>
> L0-hv
> |
> G0/L1-hv
> |
> G1
>
> And we're running in G0, then:
>
> - 'exclude_hv' would exclude L0 events
> - 'exclude_host' would ... exclude L1-hv events?
> - 'exclude_guest' would ... exclude G1 events?
[B]
> Then the next question is, if G0 is a host, does the L1-hv run in
> G0 userspace or G0 kernel space?
>
> I was assuming G0 userspace would not include anything L1 (kvm is a
> kernel module after all), but what do I know.
>
> > > @@ -11609,7 +11636,8 @@ SYSCALL_DEFINE5(perf_event_open,
> > > if (err)
> > > return err;
> > > - if (!attr.exclude_kernel) {
> > > + if (!attr.exclude_kernel || !attr.exclude_callchain_kernel ||
> > > + !attr.exclude_hv || !attr.exclude_host || !attr.exclude_guest) {
> > > err = perf_allow_kernel(&attr);
> > > if (err)
> > > return err;
> > >
> >
> > I can understand the conditions "!attr.exclude_kernel ||
> > !attr.exclude_callchain_kernel".
> >
> > But I'm not very sure about the "!attr.exclude_hv || !attr.exclude_host ||
> > !attr.exclude_guest".
>
> Well, I'm very sure G0 userspace should never see L0 or G1 state, so
> exclude_hv and exclude_guest had better be true.
>
> > On host, exclude_hv = 1, exclude_guest = 1 and exclude_host = 0, right?
>
> Same as above, is G0 host state G0 userspace?
>
> > So even exclude_kernel = 1 but exclude_host = 0, we will still go
> > perf_allow_kernel path. Please correct me if my understanding is wrong.
>
> Yes, because with those permission checks in place it means you have
> permission to see kernel bits.
So if I understand 'exclude_host' wrong -- a distinct possibility -- can
we then pretty please have the above [A-B] corrected and put in a
comment near perf_event_attr and the exclude_* comments changed to refer
to that?
[PATCH 3/3] arm64: dts: Enabled MHI device over PCIe
Enabled MHI device support over PCIe and added memory
reservation required for MHI enabled QCN9000 PCIe card.
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi | 58 ++
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 8 +
2 files changed, 66 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
index 0827055..d201a7b 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
@@ -24,6 +24,22 @@
device_type = "memory";
reg = <0x0 0x4000 0x0 0x2000>;
};
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ qcn9000_pcie0: memory@50f0 {
+ no-map;
+ reg = <0x0 0x50f0 0x0 0x0370>;
+ };
+
+ qcn9000_pcie1: memory@5460 {
+ no-map;
+ reg = <0x0 0x5460 0x0 0x0370>;
+ };
+ };
};
&blsp1_spi1 {
@@ -74,3 +90,45 @@
nand-bus-width = <8>;
};
};
+
+&pcie0_rp {
+ status = "ok";
+
+ mhi_0: qcom,mhi@0 {
+ reg = <0 0 0 0 0 >;
+ qrtr_instance_id = <0x20>;
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+
+ base-addr = <0x50f0>;
+ qcom,caldb-addr = <0x53E0>;
+ qrtr_node_id = <0x27>;
+ mhi,max-channels = <30>;
+ mhi,timeout = <1>;
+
+ pcie0_mhi: pcie0_mhi {
+ status = "ok";
+ };
+ };
+};
+
+&pcie1_rp {
+ status = "ok";
+
+ mhi_1: qcom,mhi@1 {
+ reg = <0 0 0 0 0 >;
+ qrtr_instance_id = <0x21>;
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+
+ base-addr = <0x5460>;
+ qcom,caldb-addr = <0x5750>;
+ qrtr_node_id = <0x28>;
+ mhi,max-channels = <30>;
+ mhi,timeout = <1>;
+
+ pcie1_mhi: pcie1_mhi {
+ status = "ok";
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index b651345..eef47c1 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -709,6 +709,10 @@
"ahb",
"axi_m_sticky";
status = "disabled";
+
+ pcie1_rp: pcie1_rp {
+ reg = <0 0 0 0 0>;
+ };
};
pcie0: pci@2000 {
@@ -779,6 +783,10 @@
"axi_m_sticky",
"axi_s_sticky";
status = "disabled";
+
+ pcie0_rp: pcie0_rp {
+ reg = <0 0 0 0 0>;
+ };
};
tcsr_q6: syscon@1945000 {
--
2.7.4
Re: [PATCH] powerpc/signal: Move and simplify get_clean_sp()
On Thu, Aug 06, 2020 at 08:50:20AM +, Christophe Leroy wrote: > get_clean_sp() is only used in kernel/signal.c . Move it there. > > And GCC is smart enough to reduce the function when on PPC32, no > need of a special PPC32 simple version. What about just open coding it in the only caller, which would seem even cleaner?
[PATCH 2/3] arm64: dts: Add board support for HK10
Add initial support for IPQ8074 SoC based HK10-C1
and HK10-C2 evaluation boards.
Signed-off-by: Gokul Sriram Palanisamy
---
arch/arm64/boot/dts/qcom/Makefile| 2 +
arch/arm64/boot/dts/qcom/ipq8074-hk10-c1.dts | 11
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dts | 14 +
arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi | 76
4 files changed, 103 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk10-c1.dts
create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dts
create mode 100644 arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index c98bafe..ea933fb 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -4,6 +4,8 @@ dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
dtb-$(CONFIG_ARCH_QCOM)+= ipq6018-cp01-c1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= ipq8074-hk01.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= ipq8074-hk10-c1.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= ipq8074-hk10-c2.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-longcheer-l8150.dtb
dtb-$(CONFIG_ARCH_QCOM)+= msm8916-samsung-a3u-eur.dtb
diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk10-c1.dts
b/arch/arm64/boot/dts/qcom/ipq8074-hk10-c1.dts
new file mode 100644
index 000..2bfcf42
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk10-c1.dts
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2020 The Linux Foundation. All rights reserved.
+ */
+/dts-v1/;
+
+#include "ipq8074-hk10.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C1";
+ compatible = "qcom,ipq8074-hk10-c1", "qcom,ipq8074";
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dts
b/arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dts
new file mode 100644
index 000..1897e96
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/dts-v1/;
+/* Copyright (c) 2020 The Linux Foundation. All rights reserved.
+ */
+#include "ipq8074-hk10.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2";
+ compatible = "qcom,ipq8074-hk10-c2", "qcom,ipq8074";
+};
+
+&q6v5_wcss {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
new file mode 100644
index 000..0827055
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk10.dtsi
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+/dts-v1/;
+
+#include "ipq8074.dtsi"
+
+/ {
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+
+ interrupt-parent = <&intc>;
+
+ aliases {
+ serial0 = &blsp1_uart5;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x4000 0x0 0x2000>;
+ };
+};
+
+&blsp1_spi1 {
+ status = "ok";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ };
+};
+
+&blsp1_uart5 {
+ status = "ok";
+};
+
+&pcie0 {
+ status = "ok";
+ perst-gpio = <&tlmm 58 0x1>;
+};
+
+&pcie1 {
+ status = "ok";
+ perst-gpio = <&tlmm 61 0x1>;
+};
+
+&qmp_pcie_phy0 {
+ status = "ok";
+};
+
+&qmp_pcie_phy1 {
+ status = "ok";
+};
+
+&qpic_bam {
+ status = "ok";
+};
+
+&qpic_nand {
+ status = "ok";
+
+ nand@0 {
+ reg = <0>;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ nand-bus-width = <8>;
+ };
+};
--
2.7.4
[PATCH v8 4/4] scsi: ufs: Prepare HPB read for cached sub-region
This patch changes the read I/O to the HPB read I/O.
If the logical address of the read I/O belongs to active sub-region, the
HPB driver modifies the read I/O command to HPB read. It modifies the UPIU
command of UFS instead of modifying the existing SCSI command.
In the HPB version 1.0, the maximum read I/O size that can be converted to
HPB read is 4KB.
The dirty map of the active sub-region prevents an incorrect HPB read that
has stale physical page number which is updated by previous write I/O.
Tested-by: Bean Huo
Signed-off-by: Daejun Park
---
drivers/scsi/ufs/ufshpb.c | 227 ++
1 file changed, 227 insertions(+)
diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 25cd7153f102..fe24b2277621 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -46,6 +46,22 @@ static inline int ufshpb_is_valid_srgn(struct ufshpb_region
*rgn,
srgn->srgn_state == HPB_SRGN_VALID;
}
+static inline bool ufshpb_is_read_cmd(struct scsi_cmnd *cmd)
+{
+ return req_op(cmd->request) == REQ_OP_READ;
+}
+
+static inline bool ufshpb_is_write_discard_cmd(struct scsi_cmnd *cmd)
+{
+ return op_is_write(req_op(cmd->request)) ||
+ op_is_discard(req_op(cmd->request));
+}
+
+static inline bool ufshpb_is_support_chunk(int transfer_len)
+{
+ return transfer_len <= HPB_MULTI_CHUNK_HIGH;
+}
+
static inline bool ufshpb_is_general_lun(int lun)
{
return lun < UFS_UPIU_MAX_UNIT_NUM_ID;
@@ -112,8 +128,219 @@ static inline void ufshpb_set_state(struct ufshpb_lu
*hpb, int state)
atomic_set(&hpb->hpb_state, state);
}
+static inline u32 ufshpb_get_lpn(struct scsi_cmnd *cmnd)
+{
+ return blk_rq_pos(cmnd->request) >>
+ (ilog2(cmnd->device->sector_size) - 9);
+}
+
+static inline unsigned int ufshpb_get_len(struct scsi_cmnd *cmnd)
+{
+ return blk_rq_sectors(cmnd->request) >>
+ (ilog2(cmnd->device->sector_size) - 9);
+}
+
+static void ufshpb_set_ppn_dirty(struct ufshpb_lu *hpb, int rgn_idx,
+int srgn_idx, int srgn_offset, int cnt)
+{
+ struct ufshpb_region *rgn;
+ struct ufshpb_subregion *srgn;
+ int set_bit_len;
+ int bitmap_len = hpb->entries_per_srgn;
+
+next_srgn:
+ rgn = hpb->rgn_tbl + rgn_idx;
+ srgn = rgn->srgn_tbl + srgn_idx;
+
+ if ((srgn_offset + cnt) > bitmap_len)
+ set_bit_len = bitmap_len - srgn_offset;
+ else
+ set_bit_len = cnt;
+
+ if (rgn->rgn_state != HPB_RGN_INACTIVE &&
+ srgn->srgn_state == HPB_SRGN_VALID)
+ bitmap_set(srgn->mctx->ppn_dirty, srgn_offset, set_bit_len);
+
+ srgn_offset = 0;
+ if (++srgn_idx == hpb->srgns_per_rgn) {
+ srgn_idx = 0;
+ rgn_idx++;
+ }
+
+ cnt -= set_bit_len;
+ if (cnt > 0)
+ goto next_srgn;
+
+ WARN_ON(cnt < 0);
+}
+
+static bool ufshpb_test_ppn_dirty(struct ufshpb_lu *hpb, int rgn_idx,
+ int srgn_idx, int srgn_offset, int cnt)
+{
+ struct ufshpb_region *rgn;
+ struct ufshpb_subregion *srgn;
+ int bitmap_len = hpb->entries_per_srgn;
+ int bit_len;
+
+next_srgn:
+ rgn = hpb->rgn_tbl + rgn_idx;
+ srgn = rgn->srgn_tbl + srgn_idx;
+
+ if (!ufshpb_is_valid_srgn(rgn, srgn))
+ return true;
+
+ /*
+* If the region state is active, mctx must be allocated.
+* In this case, check whether the region is evicted or
+* mctx allcation fail.
+*/
+ WARN_ON(!srgn->mctx);
+
+ if ((srgn_offset + cnt) > bitmap_len)
+ bit_len = bitmap_len - srgn_offset;
+ else
+ bit_len = cnt;
+
+ if (find_next_bit(srgn->mctx->ppn_dirty,
+ bit_len, srgn_offset) >= srgn_offset)
+ return true;
+
+ srgn_offset = 0;
+ if (++srgn_idx == hpb->srgns_per_rgn) {
+ srgn_idx = 0;
+ rgn_idx++;
+ }
+
+ cnt -= bit_len;
+ if (cnt > 0)
+ goto next_srgn;
+
+ return false;
+}
+
+static u64 ufshpb_get_ppn(struct ufshpb_lu *hpb,
+ struct ufshpb_map_ctx *mctx, int pos, int *error)
+{
+ u64 *ppn_table;
+ struct page *page;
+ int index, offset;
+
+ index = pos / (PAGE_SIZE / HPB_ENTRY_SIZE);
+ offset = pos % (PAGE_SIZE / HPB_ENTRY_SIZE);
+
+ page = mctx->m_page[index];
+ if (unlikely(!page)) {
+ *error = -ENOMEM;
+ dev_err(&hpb->sdev_ufs_lu->sdev_dev,
+ "error. cannot find page in mctx\n");
+ return 0;
+ }
+
+ ppn_table = page_address(page);
+ if (unlikely(!ppn_table)) {
+ *error = -ENOMEM;
+ dev_err(&hpb->sdev_ufs_lu->sdev_dev,
+ "error. cannot get ppn_table\n");
+ return 0;
[PATCH v17 07/12] soc: mediatek: Add subsys clock control for bus protection
For the bus protection operations, some subsys clocks need to be enabled
before releasing the protection, and vice versa.
But those subsys clocks could only be controlled once its corresponding
power domain is turned on first.
In this patch, we add the subsys clock control into its relevant steps.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 39 +--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 502b66f..ec62143 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -97,6 +98,7 @@
#define MT8173_TOP_AXI_PROT_EN_MFG_SNOOP_OUT BIT(23)
#define MAX_CLKS 3
+#define MAX_SUBSYS_CLKS 10
#define MAX_STEPS 5
@@ -165,6 +167,7 @@ struct scp_domain {
struct generic_pm_domain genpd;
struct scp *scp;
struct clk *clk[MAX_CLKS];
+ struct clk *subsys_clk[MAX_SUBSYS_CLKS];
const struct scp_domain_data *data;
struct regulator *supply;
};
@@ -427,16 +430,22 @@ static int scpsys_power_on(struct generic_pm_domain
*genpd)
val |= PWR_RST_B_BIT;
writel(val, ctl_addr);
- ret = scpsys_sram_enable(scpd, ctl_addr);
+ ret = scpsys_clk_enable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
if (ret < 0)
goto err_pwr_ack;
+ ret = scpsys_sram_enable(scpd, ctl_addr);
+ if (ret < 0)
+ goto err_sram;
+
ret = scpsys_bus_protect_disable(scpd);
if (ret < 0)
- goto err_pwr_ack;
+ goto err_sram;
return 0;
+err_sram:
+ scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
err_pwr_ack:
scpsys_clk_disable(scpd->clk, MAX_CLKS);
err_clk:
@@ -463,6 +472,8 @@ static int scpsys_power_off(struct generic_pm_domain *genpd)
if (ret < 0)
goto out;
+ scpsys_clk_disable(scpd->subsys_clk, MAX_SUBSYS_CLKS);
+
/* subsys power off */
val = readl(ctl_addr);
val |= PWR_ISO_BIT;
@@ -500,6 +511,24 @@ static int scpsys_power_off(struct generic_pm_domain
*genpd)
return ret;
}
+static int init_subsys_clks(struct device_node *np,
+ struct clk **clk)
+{
+ int sub_clk_cnt = of_clk_get_parent_count(np);
+ int i;
+
+ BUG_ON(sub_clk_cnt > MAX_SUBSYS_CLKS);
+
+ for (i = 0; i < sub_clk_cnt; i++) {
+ clk[i] = of_clk_get(np, i);
+
+ if (IS_ERR(clk[i]))
+ return PTR_ERR(clk[i]);
+ }
+
+ return 0;
+}
+
static int init_basic_clks(struct platform_device *pdev, struct clk **clk,
const char * const *name)
{
@@ -533,11 +562,17 @@ static int scpsys_get_domain(struct platform_device
*pdev, struct scp *scp,
struct device_node *sub;
u32 parent_id, child_id;
int ret;
+ struct scp_domain *scpd;
ret = scpsys_get_domain_id(node, &parent_id);
if (ret)
return ret;
+ scpd = &scp->domains[parent_id];
+ ret = init_subsys_clks(node, scpd->subsys_clk);
+ if (ret)
+ return ret;
+
for_each_child_of_node(node, sub) {
ret = scpsys_get_domain_id(sub, &child_id);
if (ret)
--
1.8.1.1.dirty
[PATCH v17 08/12] soc: mediatek: Add extra sram control
For some power domains like vpu_core on MT8183 whose sram need to
do clock and internal isolation while power on/off sram.
We add a cap "MTK_SCPD_SRAM_ISO" to judge if we need to do
the extra sram isolation control or not.
Signed-off-by: Weiyi Lu
Reviewed-by: Nicolas Boichat
---
drivers/soc/mediatek/mtk-scpsys.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index ec62143..4587cef 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -26,6 +26,7 @@
#define MTK_SCPD_ACTIVE_WAKEUP BIT(0)
#define MTK_SCPD_FWAIT_SRAMBIT(1)
+#define MTK_SCPD_SRAM_ISO BIT(2)
#define MTK_SCPD_CAPS(_scpd, _x) ((_scpd)->data->caps & (_x))
#define SPM_VDE_PWR_CON0x0210
@@ -57,6 +58,8 @@
#define PWR_ON_BIT BIT(2)
#define PWR_ON_2ND_BIT BIT(3)
#define PWR_CLK_DIS_BITBIT(4)
+#define PWR_SRAM_CLKISO_BITBIT(5)
+#define PWR_SRAM_ISOINT_B_BIT BIT(6)
#define PWR_STATUS_CONNBIT(1)
#define PWR_STATUS_DISPBIT(3)
@@ -290,6 +293,14 @@ static int scpsys_sram_enable(struct scp_domain *scpd,
void __iomem *ctl_addr)
return ret;
}
+ if (MTK_SCPD_CAPS(scpd, MTK_SCPD_SRAM_ISO)) {
+ val = readl(ctl_addr) | PWR_SRAM_ISOINT_B_BIT;
+ writel(val, ctl_addr);
+ udelay(1);
+ val &= ~PWR_SRAM_CLKISO_BIT;
+ writel(val, ctl_addr);
+ }
+
return 0;
}
@@ -299,8 +310,15 @@ static int scpsys_sram_disable(struct scp_domain *scpd,
void __iomem *ctl_addr)
u32 pdn_ack = scpd->data->sram_pdn_ack_bits;
int tmp;
- val = readl(ctl_addr);
- val |= scpd->data->sram_pdn_bits;
+ if (MTK_SCPD_CAPS(scpd, MTK_SCPD_SRAM_ISO)) {
+ val = readl(ctl_addr) | PWR_SRAM_CLKISO_BIT;
+ writel(val, ctl_addr);
+ val &= ~PWR_SRAM_ISOINT_B_BIT;
+ writel(val, ctl_addr);
+ udelay(1);
+ }
+
+ val = readl(ctl_addr) | scpd->data->sram_pdn_bits;
writel(val, ctl_addr);
/* Either wait until SRAM_PDN_ACK all 1 or 0 */
--
1.8.1.1.dirty
[PATCH v17 05/12] dt-bindings: soc: Add MT8183 power dt-bindings
Add power dt-bindings of MT8183.
Add an optional "mediatek,smi" property for phandle to smi-common
node for power controller.
Introduce properties for power domain sub nodes.
Signed-off-by: Weiyi Lu
---
.../devicetree/bindings/soc/mediatek/scpsys.txt| 81 --
include/dt-bindings/power/mt8183-power.h | 26 +++
2 files changed, 102 insertions(+), 5 deletions(-)
create mode 100644 include/dt-bindings/power/mt8183-power.h
diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
index 2bc3677..efe2025 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt
@@ -15,8 +15,9 @@ power/power-domain.yaml. It provides the power domains
defined in
- include/dt-bindings/power/mt2701-power.h
- include/dt-bindings/power/mt2712-power.h
- include/dt-bindings/power/mt7622-power.h
+- include/dt-bindings/power/mt8183-power.h
-Required properties:
+Required properties for power controller:
- compatible: Should be one of:
- "mediatek,mt2701-scpsys"
- "mediatek,mt2712-scpsys"
@@ -27,12 +28,15 @@ Required properties:
- "mediatek,mt7623a-scpsys": For MT7623A SoC
- "mediatek,mt7629-scpsys", "mediatek,mt7622-scpsys": For MT7629 SoC
- "mediatek,mt8173-scpsys"
+ - "mediatek,mt8183-scpsys"
- #power-domain-cells: Must be 1
+- #address-cells: Should be 1
+- #size-cells: Should be 0
- reg: Address range of the SCPSYS unit
- infracfg: must contain a phandle to the infracfg controller
-- clock, clock-names: clocks according to the common clock binding.
- These are clocks which hardware needs to be
- enabled before enabling certain power domains.
+- clocks, clock-names: clocks according to the common clock binding.
+ These are clocks which hardware needs to be
+ enabled before enabling certain power domains.
Required clocks for MT2701 or MT7623: "mm", "mfg", "ethif"
Required clocks for MT2712: "mm", "mfg", "venc", "jpgdec", "audio",
"vdec"
Required clocks for MT6765: MUX: "mm", "mfg"
@@ -43,8 +47,11 @@ Required properties:
Required clocks for MT7622 or MT7629: "hif_sel"
Required clocks for MT7623A: "ethif"
Required clocks for MT8173: "mm", "mfg", "venc", "venc_lt"
+ Required clocks for MT8183: "audio", "audio1", "audio2", "mfg", "mm",
+ "cam", "isp", "vpu", "vpu1", "vpu2",
+ "vpu3";
-Optional properties:
+Optional properties for power controller:
- vdec-supply: Power supply for the vdec power domain
- venc-supply: Power supply for the venc power domain
- isp-supply: Power supply for the isp power domain
@@ -55,6 +62,16 @@ Optional properties:
- mfg_async-supply: Power supply for the mfg_async power domain
- mfg_2d-supply: Power supply for the mfg_2d power domain
- mfg-supply: Power supply for the mfg power domain
+- mediatek,smi : A phandle to the smi_common node
+
+Required properties for power domain sub nodes:
+- reg: index of the power domain, should use macros in:
+ "include/dt-bindings/power/mt8192-power.h" - for power domain of MT8192.
+
+Optional properties for power domain sub nodes:
+- clocks: clocks according to the common clock binding.
+ These are clocks which hardware needs to be enabled before
+ releasing the bus protection.
Example:
@@ -70,6 +87,60 @@ Example:
clock-names = "mfg", "mm", "venc", "venc_lt";
};
+Example(power domain sub node within power controller):
+
+ scpsys: power-controller@10006000 {
+ compatible = "mediatek,mt8183-scpsys", "syscon";
+ reg = <0 0x10006000 0 0x1000>;
+ clocks = <&topckgen CLK_TOP_MUX_MM>,
+<&topckgen CLK_TOP_MUX_IPU_IF>,
+<&topckgen CLK_TOP_MUX_DSP>,
+<&topckgen CLK_TOP_MUX_DSP1>,
+<&topckgen CLK_TOP_MUX_DSP2>;
+ clock-names = "mm", "vpu", "vpu1", "vpu2", "vpu3";
+ infracfg = <&infracfg>;
+ mediatek,smi = <&smi_common>;
+ #power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ conn@MT8183_POWER_DOMAIN_CONN {
+ reg = ;
+ };
+
+ disp@MT8183_POWER_DOMAIN_DISP {
+ reg = ;
+ clocks = <&mmsys CLK_MM_SMI_COMMON>,
+<&mmsys CLK_MM_SMI_LARB0>,
+<&mmsys CLK_MM_SMI_LARB1>,
+<&mmsys CLK_MM_GALS_COMM0>,
+<&mmsys CLK_MM_GALS_COMM1>,
+<&mmsys CLK_MM_GALS_CCU2MM>,
+
[PATCH v17 12/12] arm64: dts: Add power-domains property to mfgcfg
mfgcfg clock is under MFG_ASYNC power domain
Signed-off-by: Weiyi Lu
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 4940bda..43db225 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -800,6 +800,7 @@
compatible = "mediatek,mt8183-mfgcfg", "syscon";
reg = <0 0x1300 0 0x1000>;
#clock-cells = <1>;
+ power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_ASYNC>;
};
mmsys: syscon@1400 {
--
1.8.1.1.dirty
[PATCH v17 03/12] soc: mediatek: Remove infracfg misc driver support
The functions provided by infracfg misc driver have no other user except
the scpsys driver so move those into scpsys driver directly.
And then, remove infracfg misc driver which is no longer being used.
BTW, in next patch, we're going to extend the bus protection functions
with more customized arguments.
Signed-off-by: Weiyi Lu
Reviewed-by: Enric Balletbo i Serra
---
drivers/soc/mediatek/Kconfig | 10 -
drivers/soc/mediatek/Makefile | 1 -
drivers/soc/mediatek/mtk-infracfg.c | 79 ---
drivers/soc/mediatek/mtk-scpsys.c | 66 +
include/linux/soc/mediatek/infracfg.h | 39 -
5 files changed, 57 insertions(+), 138 deletions(-)
delete mode 100644 drivers/soc/mediatek/mtk-infracfg.c
delete mode 100644 include/linux/soc/mediatek/infracfg.h
diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index 59a56cd..3f5e5cb 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -10,21 +10,12 @@ config MTK_CMDQ
depends on ARCH_MEDIATEK || COMPILE_TEST
select MAILBOX
select MTK_CMDQ_MBOX
- select MTK_INFRACFG
help
Say yes here to add support for the MediaTek Command Queue (CMDQ)
driver. The CMDQ is used to help read/write registers with critical
time limitation, such as updating display configuration during the
vblank.
-config MTK_INFRACFG
- bool "MediaTek INFRACFG Support"
- select REGMAP
- help
- Say yes here to add support for the MediaTek INFRACFG controller. The
- INFRACFG controller contains various infrastructure registers not
- directly associated to any device.
-
config MTK_PMIC_WRAP
tristate "MediaTek PMIC Wrapper Support"
depends on RESET_CONTROLLER
@@ -38,7 +29,6 @@ config MTK_SCPSYS
bool "MediaTek SCPSYS Support"
default ARCH_MEDIATEK
select REGMAP
- select MTK_INFRACFG
select PM_GENERIC_DOMAINS if PM
help
Say yes here to add support for the MediaTek SCPSYS power domain
diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
index 01f9f87..2afa7b9 100644
--- a/drivers/soc/mediatek/Makefile
+++ b/drivers/soc/mediatek/Makefile
@@ -1,6 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
-obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
diff --git a/drivers/soc/mediatek/mtk-infracfg.c
b/drivers/soc/mediatek/mtk-infracfg.c
deleted file mode 100644
index 341c7ac..000
--- a/drivers/soc/mediatek/mtk-infracfg.c
+++ /dev/null
@@ -1,79 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2015 Pengutronix, Sascha Hauer
- */
-
-#include
-#include
-#include
-#include
-#include
-
-#define MTK_POLL_DELAY_US 10
-#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
-
-#define INFRA_TOPAXI_PROTECTEN 0x0220
-#define INFRA_TOPAXI_PROTECTSTA1 0x0228
-#define INFRA_TOPAXI_PROTECTEN_SET 0x0260
-#define INFRA_TOPAXI_PROTECTEN_CLR 0x0264
-
-/**
- * mtk_infracfg_set_bus_protection - enable bus protection
- * @regmap: The infracfg regmap
- * @mask: The mask containing the protection bits to be enabled.
- * @reg_update: The boolean flag determines to set the protection bits
- * by regmap_update_bits with enable register(PROTECTEN) or
- * by regmap_write with set register(PROTECTEN_SET).
- *
- * This function enables the bus protection bits for disabled power
- * domains so that the system does not hang when some unit accesses the
- * bus while in power down.
- */
-int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
- bool reg_update)
-{
- u32 val;
- int ret;
-
- if (reg_update)
- regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask,
- mask);
- else
- regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
-
- ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
- val, (val & mask) == mask,
- MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
-
- return ret;
-}
-
-/**
- * mtk_infracfg_clear_bus_protection - disable bus protection
- * @regmap: The infracfg regmap
- * @mask: The mask containing the protection bits to be disabled.
- * @reg_update: The boolean flag determines to clear the protection bits
- * by regmap_update_bits with enable register(PROTECTEN) or
- * by regmap_write with clear register(PROTECTEN_CLR).
- *
- * This function disables the bus protection bits previously enabled with
- * mtk_infracfg_set_bus_protection.
- */
-
-int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
Re: stable rc 4.4 - v4.4.232-33-g0b3898baf614 - build breaks on arm64, arm, x86_64 and i386.
On Wed 05-08-20 22:42:08, Naresh Kamboju wrote: > stable rc 4.4 build breaks on arm64, arm, x86_64 and i386. > > Here are the build log failures on arm64. >git_repo: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > target_arch: arm64 > toolchain: gcc-9 > git_short_log: 0b3898baf614 (\Linux 4.4.233-rc1\) > git_sha: 0b3898baf61459e1f963dcf893b4683174668975 > git_describe: v4.4.232-33-g0b3898baf614 > kernel_version: 4.4.233-rc1 > > make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arm64 > CROSS_COMPILE=aarch64-linux-gnu- HOSTCC=gcc CC="sccache > aarch64-linux-gnu-gcc" O=build Image > # > ../arch/arm64/kernel/hw_breakpoint.c: In function ‘arch_bp_generic_fields’: > ../arch/arm64/kernel/hw_breakpoint.c:348:5: note: parameter passing > for argument of type ‘struct arch_hw_breakpoint_ctrl’ changed in GCC > 9.1 > 348 | int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl, > | ^~ > ../fs/ext4/inode.c: In function ‘ext4_direct_IO’: > ../fs/ext4/inode.c:3355:9: error: ‘offset’ redeclared as different > kind of symbol > 3355 | loff_t offset = iocb->ki_pos; > | ^~ > ../fs/ext4/inode.c:3349:17: note: previous definition of ‘offset’ was here > 3349 | loff_t offset) > | ~~~^~ This looks like a breakage from "ext4: fix direct I/O read error" where for 4.4 the patch needs to be updated (addition of the line "loff_t offset = iocb->ki_pos;" needs to be removed from the patch because 'offset' is already passed from the caller. Jiang, will you update the patch for 4.4 kernels please? Honza > make[3]: *** [../scripts/Makefile.build:277: fs/ext4/inode.o] Error 1 > make[3]: Target '__build' not remade because of errors. > make[2]: *** [../scripts/Makefile.build:484: fs/ext4] Error 2 > ../drivers/net/ethernet/apm/xgene/xgene_enet_main.c:32:36: warning: > array ‘xgene_enet_acpi_match’ assumed to have one element >32 | static const struct acpi_device_id xgene_enet_acpi_match[]; > |^ > make[2]: Target '__build' not remade because of errors. > make[1]: *** [/linux/Makefile:1006: fs] Error 2 > make[1]: Target 'Image' not remade because of errors. > make: *** [Makefile:152: sub-make] Error 2 > make: Target 'Image' not remade because of errors. > > -- > Linaro LKFT > https://lkft.linaro.org -- Jan Kara SUSE Labs, CR
[PATCH v17 06/12] soc: mediatek: Add support for hierarchical scpsys device node
Try to list all the power domains of under power controller
node to show the dependency between each power domain directly
instead of filling the dependency in scp_soc_data.
And could be more clearly to group subsys clocks into power domain
sub node to introduce subsys clocks of bus protection in next patch.
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 103 +++---
1 file changed, 95 insertions(+), 8 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 5a2c323..502b66f 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -182,11 +182,13 @@ struct scp {
struct regmap *infracfg;
struct regmap *smi_common;
struct scp_ctrl_reg ctrl_reg;
+ struct list_head dep_links;
};
struct scp_subdomain {
int origin;
int subdomain;
+ struct list_head list;
};
struct scp_soc_data {
@@ -513,6 +515,79 @@ static int init_basic_clks(struct platform_device *pdev,
struct clk **clk,
return 0;
}
+static int scpsys_get_domain_id(struct device_node *node, u32 *id)
+{
+ int ret;
+
+ ret = of_property_read_u32(node, "reg", id);
+ if (ret)
+ pr_err("%pOFn: failed to retrieve domain id, ret=%d\n", node,
ret);
+
+ return ret;
+}
+
+static int scpsys_get_domain(struct platform_device *pdev, struct scp *scp,
+ struct device_node *node, const struct scp_domain_data
*data)
+{
+ struct scp_subdomain *dep_node;
+ struct device_node *sub;
+ u32 parent_id, child_id;
+ int ret;
+
+ ret = scpsys_get_domain_id(node, &parent_id);
+ if (ret)
+ return ret;
+
+ for_each_child_of_node(node, sub) {
+ ret = scpsys_get_domain_id(sub, &child_id);
+ if (ret)
+ goto out;
+
+ dep_node = devm_kzalloc(&pdev->dev, sizeof(*dep_node),
GFP_KERNEL);
+ if (!dep_node) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ dep_node->origin = parent_id;
+ dep_node->subdomain = child_id;
+ list_add(&dep_node->list, &scp->dep_links);
+
+ scpsys_get_domain(pdev, scp, sub, data);
+ }
+
+ return 0;
+
+out:
+ of_node_put(sub);
+ return ret;
+}
+
+static int traverse_scp(struct platform_device *pdev, struct scp *scp,
+ const struct scp_domain_data *scp_domain_data)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *sub;
+ int ret;
+
+ INIT_LIST_HEAD(&scp->dep_links);
+
+ for_each_available_child_of_node(np, sub) {
+ ret = scpsys_get_domain(pdev, scp, sub, scp_domain_data);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to handle node %pOFn:
%d\n", sub, ret);
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ of_node_put(sub);
+ return ret;
+}
+
static struct scp *init_scp(struct platform_device *pdev,
const struct scp_domain_data *scp_domain_data, int num,
const struct scp_ctrl_reg *scp_ctrl_reg)
@@ -582,6 +657,10 @@ static struct scp *init_scp(struct platform_device *pdev,
pd_data->num_domains = num;
+ ret = traverse_scp(pdev, scp, scp_domain_data);
+ if (ret)
+ return ERR_PTR(ret);
+
for (i = 0; i < num; i++) {
struct scp_domain *scpd = &scp->domains[i];
struct generic_pm_domain *genpd = &scpd->genpd;
@@ -1208,7 +1287,7 @@ static int scpsys_probe(struct platform_device *pdev)
const struct scp_soc_data *soc;
struct scp *scp;
struct genpd_onecell_data *pd_data;
- int i, ret;
+ int i, ret = 0;
soc = of_device_get_match_data(&pdev->dev);
@@ -1220,15 +1299,23 @@ static int scpsys_probe(struct platform_device *pdev)
pd_data = &scp->pd_data;
- for (i = 0, sd = soc->subdomains; i < soc->num_subdomains; i++, sd++) {
- ret = pm_genpd_add_subdomain(pd_data->domains[sd->origin],
-pd_data->domains[sd->subdomain]);
- if (ret && IS_ENABLED(CONFIG_PM))
- dev_err(&pdev->dev, "Failed to add subdomain: %d\n",
- ret);
+ if (soc->subdomains && soc->num_subdomains) {
+ for (i = 0, sd = soc->subdomains; i < soc->num_subdomains; i++,
sd++) {
+ ret =
pm_genpd_add_subdomain(pd_data->domains[sd->origin],
+
pd_data->domains[sd->subdomain]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain:
[PATCH v17 10/12] soc: mediatek: Add a comma at the end
A minor coding style fix
Signed-off-by: Weiyi Lu
---
drivers/soc/mediatek/mtk-scpsys.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index 9a699b4..7158863b 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -1468,7 +1468,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.num_domains = ARRAY_SIZE(scp_domain_data_mt2701),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1479,7 +1479,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.num_subdomains = ARRAY_SIZE(scp_subdomain_mt2712),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1490,7 +1490,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.num_subdomains = ARRAY_SIZE(scp_subdomain_mt6797),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS_MT6797,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6797,
},
};
@@ -1499,7 +1499,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.num_domains = ARRAY_SIZE(scp_domain_data_mt7622),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1508,7 +1508,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.num_domains = ARRAY_SIZE(scp_domain_data_mt7623a),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1519,7 +1519,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.num_subdomains = ARRAY_SIZE(scp_subdomain_mt8173),
.regs = {
.pwr_sta_offs = SPM_PWR_STATUS,
- .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND
+ .pwr_sta2nd_offs = SPM_PWR_STATUS_2ND,
},
};
@@ -1528,7 +1528,7 @@ static void mtk_register_power_domains(struct
platform_device *pdev,
.num_domains = ARRAY_SIZE(scp_domain_data_mt8183),
.regs = {
.pwr_sta_offs = 0x0180,
- .pwr_sta2nd_offs = 0x0184
+ .pwr_sta2nd_offs = 0x0184,
}
};
--
1.8.1.1.dirty
[PATCH v17 01/12] dt-bindings: mediatek: Add property to mt8183 smi-common
For scpsys driver using regmap based syscon driver API. Signed-off-by: Weiyi Lu Acked-by: Rob Herring --- .../devicetree/bindings/memory-controllers/mediatek,smi-common.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt index b478ade..01744ec 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt @@ -20,7 +20,7 @@ Required properties: "mediatek,mt2712-smi-common" "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" "mediatek,mt8173-smi-common" - "mediatek,mt8183-smi-common" + "mediatek,mt8183-smi-common", "syscon" - reg : the register and size of the SMI block. - power-domains : a phandle to the power domain of this local arbiter. - clocks : Must contain an entry for each entry in clock-names. -- 1.8.1.1.dirty
[PATCH v2 1/3] dt-bindings: qcom: Add ipq8074 bindings
Document the new device-tree bindings for boards HK10-C1 and HK10-C2 based on ipq8074 SoC. Signed-off-by: Gokul Sriram Palanisamy --- Documentation/devicetree/bindings/arm/qcom.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 6031aee..7b294be 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -47,6 +47,8 @@ description: | cp01-c1 dragonboard hk01 +hk10-c1 +hk10-c2 idp liquid mtp @@ -148,6 +150,8 @@ properties: - items: - enum: - qcom,ipq8074-hk01 + - qcom,ipq8074-hk10-c1 + - qcom,ipq8074-hk10-c2 - const: qcom,ipq8074 - items: -- 2.7.4
Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting
pet...@infradead.org writes: > On Mon, Aug 03, 2020 at 09:22:53PM +0200, Thomas Gleixner wrote: > >>totaltime = irqtime + tasktime >> >> Ignoring irqtime and pretending that totaltime is what the scheduler >> can control and deal with is naive at best. > > Well no, that's what we call system overhead and is assumed to be > included in the 'error margin'. > > The way things are set up is that we say that, by default, RT tasks can > consume 95% of cputime and the remaining 5% is sufficient to keep the > system alive. > > Those 5% include all system overhead, IRQs, RCU, !RT workqueues etc.. > > Obviously IRQ_TIME accounting changes the balance a bit, but that's what > it is. We can't really do anything better. > > Apparently this SoC has significant IRQ time for some reason. Also, > relying on RT throttling for 'correct' behaviour is also wrong. What > needs to be done is find who is using all this RT time and why, that > isn't right. It's a test case and we know already who is using the time. But that's not the point. A runaway RT task resulting in a RCU stall or whatever lockup of the system is definitely not the right answer. The throttler, as much as it's a horrible hack, is there to prevent this and to give the admin a chance to pinpoint and kill that thing instead of having to press the reset button and scratching head what might have caused this. Thanks, tglx
