Re: ks-sa-rng.c:undefined reference to `devm_platform_ioremap_resource'
Hi! On 27/11/2020 06:48, Herbert Xu wrote: > On Fri, Nov 13, 2020 at 11:02:13PM +0800, kernel test robot wrote: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master >> head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba >> commit: 90c4b29eb1e555fee66f8329a18cb8a070090ad6 hwrng: ks-sa - Enable >> COMPILE_TEST >> date: 12 months ago >> config: s390-randconfig-r022-20201113 (attached as .config) >> compiler: s390-linux-gcc (GCC) 9.3.0 >> reproduce (this is a W=1 build): >> wget >> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O >> ~/bin/make.cross >> chmod +x ~/bin/make.cross >> # >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90c4b29eb1e555fee66f8329a18cb8a070090ad6 >> git remote add linus >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> git fetch --no-tags linus master >> git checkout 90c4b29eb1e555fee66f8329a18cb8a070090ad6 >> # save the attached .config to linux build tree >> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross >> ARCH=s390 >> >> If you fix the issue, kindly add following tag as appropriate >> Reported-by: kernel test robot >> >> All errors (new ones prefixed by >>): > >>s390-linux-ld: drivers/char/hw_random/ks-sa-rng.o: in function >> `ks_sa_rng_probe': ks-sa-rng.c:(.text+0x2fa): undefined reference to `devm_platform_ioremap_resource' > > ---8<--- > This patch adds a dependency for KEYSTONE on HAS_IOMEM and OF to > prevent COMPILE_TEST build failures. > > Reported-by: kernel test robot > Signed-off-by: Herbert Xu Reviewed-by: Alexander Sverdlin > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig > index ab33a2e17cdf..9ff4fb3236f7 100644 > --- a/drivers/char/hw_random/Kconfig > +++ b/drivers/char/hw_random/Kconfig > @@ -508,6 +508,7 @@ config HW_RANDOM_NPCM > > config HW_RANDOM_KEYSTONE > depends on ARCH_KEYSTONE || COMPILE_TEST > + depends on HAS_IOMEM && OF > default HW_RANDOM > tristate "TI Keystone NETCP SA Hardware random number generator" > help > -- Best regards, Alexander Sverdlin.
Re: [PATCH bpf-next 2/2] bpf: Add a selftest for the tracing bpf_get_socket_cookie
On 11/26/20 9:02 AM, Florent Revest wrote:
This builds up on the existing socket cookie test which checks whether
the bpf_get_socket_cookie helpers provide the same value in
cgroup/connect6 and sockops programs for a socket created by the
userspace part of the test.
Adding a tracing program to the existing objects requires a different
attachment strategy and different headers.
Signed-off-by: Florent Revest
---
.../selftests/bpf/progs/socket_cookie_prog.c | 41 ---
.../selftests/bpf/test_socket_cookie.c| 18 +---
Do you think it is possible to migrate test_socket_cookie.c to
selftests/bpf/prog_tests so it can be part of test_progs so
it will be regularly exercised?
2 files changed, 49 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/socket_cookie_prog.c
b/tools/testing/selftests/bpf/progs/socket_cookie_prog.c
index 0cb5656a22b0..a11026aeaaf1 100644
--- a/tools/testing/selftests/bpf/progs/socket_cookie_prog.c
+++ b/tools/testing/selftests/bpf/progs/socket_cookie_prog.c
@@ -1,11 +1,13 @@
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2018 Facebook
[...]
diff --git a/tools/testing/selftests/bpf/test_socket_cookie.c
b/tools/testing/selftests/bpf/test_socket_cookie.c
index ca7ca87e91aa..0d955c65a4f8 100644
--- a/tools/testing/selftests/bpf/test_socket_cookie.c
+++ b/tools/testing/selftests/bpf/test_socket_cookie.c
@@ -133,6 +133,7 @@ static int run_test(int cgfd)
struct bpf_prog_load_attr attr;
struct bpf_program *prog;
struct bpf_object *pobj;
+ struct bpf_link *link;
const char *prog_name;
int server_fd = -1;
int client_fd = -1;
@@ -153,11 +154,18 @@ static int run_test(int cgfd)
bpf_object__for_each_program(prog, pobj) {
prog_name = bpf_program__section_name(prog);
- if (libbpf_attach_type_by_name(prog_name, _type))
- goto err;
-
- err = bpf_prog_attach(bpf_program__fd(prog), cgfd, attach_type,
- BPF_F_ALLOW_OVERRIDE);
+ if (bpf_program__is_tracing(prog)) {
+ link = bpf_program__attach(prog);
+ err = !link;
+ continue;
+ } else {
+ if (libbpf_attach_type_by_name(prog_name, _type))
+ goto err;
+
+ err = bpf_prog_attach(bpf_program__fd(prog), cgfd,
+ attach_type,
+ BPF_F_ALLOW_OVERRIDE);
+ }
if (err) {
log_err("Failed to attach prog %s", prog_name);
goto out;
Re: Fair Pay - The Red Carpet Star is Islamic! (with video playlist)
https://www.youtube.com/playlist?list=PLpA7__w8yeJ2U8b8uo6rQ9ooJ8XgpBtC5 Media created the idea of "The Star". I have been that star, and corrected monotheism, making this potential available to the seeker. See also the playlist! The Fair Pay Initiative fully supports this ofcourse! Serenity, Ywe Cærlyn The Fair Pay Initiative. https://www.youtube.com/channel/UCqt17eaSO66UV4xvIYJvD4g
Re: [PATCH v3] mfd: kempld-core: Check for DMI definition before ACPI
On Mon, 16 Nov 2020, Michael Brunner wrote: > Change the detection order to priorize DMI table entries over available > ACPI entries. > > This makes it more easy for product developers to patch product specific > handling into the driver. > Furthermore it allows to simplify the implementation a bit and > especially to remove the need to force synchronous probing. > > Signed-off-by: Michael Brunner > Reviewed-by: Guenter Roeck > --- > > v3: Cleaned up comment, added Reviewed-by > > drivers/mfd/kempld-core.c | 24 +++- > 1 file changed, 3 insertions(+), 21 deletions(-) Nit: Just letting you know that checkpatch.pl complains about your patches, since your From: address does not match your SoB one. Patch applied though, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/3] mm,thp,shm: limit gfp mask to no more than specified
On Thu 26-11-20 13:04:14, Rik van Riel wrote: > On Thu, 2020-11-26 at 14:40 +0100, Michal Hocko wrote: > > On Tue 24-11-20 14:49:24, Rik van Riel wrote: > > > Matthew Wilcox pointed out that the i915 driver opportunistically > > > allocates tmpfs memory, but will happily reclaim some of its > > > pool if no memory is available. > > > > > > Make sure the gfp mask used to opportunistically allocate a THP > > > is always at least as restrictive as the original gfp mask. > > > > I have brought this up in the previous version review and I feel my > > feedback hasn't been addressed. Please describe the expected behavior > > by > > those shmem users including GFP_KERNEL restriction which would make > > the > > THP flags incompatible. Is this a problem? Is there any actual > > problem > > if the THP uses its own set of flags? > > In the case of i915, the gfp flags passed in by the i915 > driver expect the VM to easily fail the allocation, in > which case the i915 driver will reclaim some existing > buffers and try again. The existing code tries hard to prevent from the oom killer AFAIU. At least that is what i915_gem_object_get_pages_gtt says. And that is ok for order-0 (or low order) requests. But THPs are costly orders and therefore __GFP_NORETRY has a different meaning. It still controls how hard to try compact but this is not a OOM control. ttm_tt_swapout is similar except it chosen to try harder for order-0 cases but still want to prevent the oom killer. > Trying harder than the original gfp_mask would change the OOM behavior > of systems using the i915 driver. > > > I am also not happy how those two sets of flags are completely > > detached > > and we can only expect surprises there. > > I would be more than happy to implement things differently, > but I am not sure what alternative you are suggesting. Simply do not alter gfp flags? Or warn in some cases of a serious mismatch. E.g. GFP_ZONEMASK mismatch because there are already GFP_KERNEL users of shmem. -- Michal Hocko SUSE Labs
linux-next: manual merge of the akpm-current tree with the tip tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/highmem.c
between commits:
298fa1ad5571 ("highmem: Provide generic variant of kmap_atomic*")
5fbda3ecd14a ("sched: highmem: Store local kmaps in task struct")
from the tip tree and commit:
72d22a0d0e86 ("mm: support THPs in zero_user_segments")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc mm/highmem.c
index 83f9660f168f,e2da8c9770e9..
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@@ -358,260 -367,68 +358,319 @@@ void kunmap_high(struct page *page
if (need_wakeup)
wake_up(pkmap_map_wait);
}
-
EXPORT_SYMBOL(kunmap_high);
+
+ #ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ void zero_user_segments(struct page *page, unsigned start1, unsigned end1,
+ unsigned start2, unsigned end2)
+ {
+ unsigned int i;
+
+ BUG_ON(end1 > page_size(page) || end2 > page_size(page));
+
+ for (i = 0; i < compound_nr(page); i++) {
+ void *kaddr;
+ unsigned this_end;
+
+ if (end1 == 0 && start2 >= PAGE_SIZE) {
+ start2 -= PAGE_SIZE;
+ end2 -= PAGE_SIZE;
+ continue;
+ }
+
+ if (start1 >= PAGE_SIZE) {
+ start1 -= PAGE_SIZE;
+ end1 -= PAGE_SIZE;
+ if (start2) {
+ start2 -= PAGE_SIZE;
+ end2 -= PAGE_SIZE;
+ }
+ continue;
+ }
+
+ kaddr = kmap_atomic(page + i);
+
+ this_end = min_t(unsigned, end1, PAGE_SIZE);
+ if (end1 > start1)
+ memset(kaddr + start1, 0, this_end - start1);
+ end1 -= this_end;
+ start1 = 0;
+
+ if (start2 >= PAGE_SIZE) {
+ start2 -= PAGE_SIZE;
+ end2 -= PAGE_SIZE;
+ } else {
+ this_end = min_t(unsigned, end2, PAGE_SIZE);
+ if (end2 > start2)
+ memset(kaddr + start2, 0, this_end - start2);
+ end2 -= this_end;
+ start2 = 0;
+ }
+
+ kunmap_atomic(kaddr);
+ flush_dcache_page(page + i);
+
+ if (!end1 && !end2)
+ break;
+ }
+
+ BUG_ON((start1 | start2 | end1 | end2) != 0);
+ }
+ EXPORT_SYMBOL(zero_user_segments);
+ #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
-#endif/* CONFIG_HIGHMEM */
+#endif /* CONFIG_HIGHMEM */
+
+#ifdef CONFIG_KMAP_LOCAL
+
+#include
+
+/*
+ * With DEBUG_KMAP_LOCAL the stack depth is doubled and every second
+ * slot is unused which acts as a guard page
+ */
+#ifdef CONFIG_DEBUG_KMAP_LOCAL
+# define KM_INCR 2
+#else
+# define KM_INCR 1
+#endif
+
+static inline int kmap_local_idx_push(void)
+{
+ WARN_ON_ONCE(in_irq() && !irqs_disabled());
+ current->kmap_ctrl.idx += KM_INCR;
+ BUG_ON(current->kmap_ctrl.idx >= KM_MAX_IDX);
+ return current->kmap_ctrl.idx - 1;
+}
+
+static inline int kmap_local_idx(void)
+{
+ return current->kmap_ctrl.idx - 1;
+}
+
+static inline void kmap_local_idx_pop(void)
+{
+ current->kmap_ctrl.idx -= KM_INCR;
+ BUG_ON(current->kmap_ctrl.idx < 0);
+}
+
+#ifndef arch_kmap_local_post_map
+# define arch_kmap_local_post_map(vaddr, pteval) do { } while (0)
+#endif
+
+#ifndef arch_kmap_local_pre_unmap
+# define arch_kmap_local_pre_unmap(vaddr) do { } while (0)
+#endif
+
+#ifndef arch_kmap_local_post_unmap
+# define arch_kmap_local_post_unmap(vaddr)do { } while (0)
+#endif
+
+#ifndef arch_kmap_local_map_idx
+#define arch_kmap_local_map_idx(idx, pfn) kmap_local_calc_idx(idx)
+#endif
+
+#ifndef arch_kmap_local_unmap_idx
+#define arch_kmap_local_unmap_idx(idx, vaddr) kmap_local_calc_idx(idx)
+#endif
+
+#ifndef arch_kmap_local_high_get
+static inline void *arch_kmap_local_high_get(struct page *page)
+{
+ return NULL;
+}
+#endif
+
+/* Unmap a local mapping which was obtained by kmap_high_get() */
+static inline bool kmap_high_unmap_local(unsigned long vaddr)
+{
+#ifdef ARCH_NEEDS_KMAP_HIGH_GET
+ if (vaddr >= PKMAP_ADDR(0) && vaddr < PKMAP_ADDR(LAST_PKMAP)) {
+ kunmap_high(pte_page(pkmap_page_table[PKMAP_NR(vaddr)]));
+ return true;
+ }
+#endif
+ return false;
+}
+
+static
Re: Question about domain_init (v5.3-v5.7)
Lu Baolu @ 2020-11-26 19:12 MST: > Hi Jerry, > > On 11/27/20 5:35 AM, Jerry Snitselaar wrote: >> Lu Baolu @ 2020-11-26 04:01 MST: >> >>> Hi Jerry, >>> >>> On 2020/11/26 4:27, Jerry Snitselaar wrote: Is there a reason we check the requested guest address width against the iommu's mgaw, instead of the agaw that we already know for the iommu? I've run into a case with a new system where the mgaw reported is 57, but if they set PAE to 46 instead of 52 in the bios, then sagaw reports the highest supported agaw is 48 and the domain_init code fails here. In >>> >>> Isn't this a platform bug? If it's too late to fix it in the BIOS, you >>> maybe have to add a platform specific quirk to set mgaw to the highest >>> supported agaw? >>> >>> Best regards, >>> baolu >> Is there somewhere you can point me to that discusses how they >> should be >> setting the mgaw? I misunderstood when I previously asked you about >> whether the mgaw could be a value that was greater than any of sagaw. >> If it is a bios issue, then they should fix it there. > > MGAW indicates the max gpa width supported by 2nd translation. The VT-d > spec requires that this value must be at least equal to the host > physical addressibility. According to this, BIOS is good, right? > Yes, the host address width is 46. MGAW reports 57 (56+1), and highest sagaw bit is for 48. > For this failure case, domain_init() just wants to find a suitable agaw > for the private domain. I think it makes sense to check against > iommu->agaw instead of cap_mgaw. > > Best regards, > baolu > >> >>> other places like prepare_domain_attach_device, the dmar domain agaw gets adjusted down to the iommu agaw. The agaw of the iommu gets determined based off what is reported for sagaw. I'm wondering if it can't instead do: --- drivers/iommu/intel-iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c index 6ca5c92ef2e5..a8e41ec36d9e 100644 --- a/drivers/iommu/intel-iommu.c +++ b/drivers/iommu/intel-iommu.c @@ -1862,8 +1862,8 @@ static int domain_init(struct dmar_domain *domain, struct intel_iommu *iommu, domain_reserve_special_ranges(domain); /* calculate AGAW */ - if (guest_width > cap_mgaw(iommu->cap)) - guest_width = cap_mgaw(iommu->cap); + if (guest_width > agaw_to_width(iommu->agaw)) + guest_width = agaw_to_width(iommu->agaw); domain->gaw = guest_width; adjust_width = guestwidth_to_adjustwidth(guest_width); agaw = width_to_agaw(adjust_width); -- 2.27.0 Thoughts? With the former code the ehci device for the ilo fails when trying to get a private domain. Thanks, Jerry >>
Re: [PATCH -next] perf util: Fix memory leak in __parse_regs()
Ping...
On Fri, Jul 03, 2020 at 05:33:44PM +0800, Zheng Zengkai wrote:
when using perf record option '-I' or '--user-regs='
along with argument '?' to list available register names,
memory of variable 'os' allocated by strdup() needs to be released
before __parse_regs() returns, otherwise memory leak will occur.
Fixes: bcc84ec65ad1 ("perf record: Add ability to name registers to record")
Signed-off-by: Zheng Zengkai
Acked-by: Jiri Olsa
thanks,
jirka
---
tools/perf/util/parse-regs-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-regs-options.c
b/tools/perf/util/parse-regs-options.c
index e687497b3aac..a4a100425b3a 100644
--- a/tools/perf/util/parse-regs-options.c
+++ b/tools/perf/util/parse-regs-options.c
@@ -54,7 +54,7 @@ __parse_regs(const struct option *opt, const char *str, int
unset, bool intr)
#endif
fputc('\n', stderr);
/* just printing available regs */
- return -1;
+ goto error;
}
#ifdef HAVE_PERF_REGS_SUPPORT
for (r = sample_reg_masks; r->name; r++) {
--
2.20.1
.
[PATCH] wdt: sp805: add watchdog_stop on reboot
From: Zhao Qiang Call watchdog_stop_on_reboot in probe func Signed-off-by: Zhao Qiang --- drivers/watchdog/sp805_wdt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c index 190d26e..958dc32 100644 --- a/drivers/watchdog/sp805_wdt.c +++ b/drivers/watchdog/sp805_wdt.c @@ -291,6 +291,7 @@ sp805_wdt_probe(struct amba_device *adev, const struct amba_id *id) set_bit(WDOG_HW_RUNNING, >wdd.status); } + watchdog_stop_on_reboot(>wdd); ret = watchdog_register_device(>wdd); if (ret) goto err; -- 2.7.4
Re: [PATCH v4] mfd: tps65910: Correct power-off programming sequence
On Sun, 15 Nov 2020, Dmitry Osipenko wrote: > Correct power-off programming sequence in order to fix shutting down > devices which are using TPS65910 PMIC. > > In accordance to the TPS65910 datasheet, the PMIC's state-machine > transitions into the OFF state only when DEV_OFF bit of DEVCTRL_REG is > set. The ON / SLEEP states also should be cleared, otherwise PMIC won't > get into a proper state on shutdown. Devices like Nexus 7 tablet and Ouya > game console are shutting down properly now. > > Tested-by: Peter Geis > Tested-by: Zack Pearsall > Signed-off-by: Dmitry Osipenko > --- > > Changelog: > > v4: - Rebased on a recent linux-next. > > v3: - Removed the DEV_SLP_MASK clearing and adding clarifying comment to > the code about why clearing PWR_OFF bit needs to be done, which was > suggested by Michał Mirosław in a review comment to v2. > > - Added tested-by from Peter Geis who tested v3 on his Ouya game > console. > > v2: - Now using a single tps65910_reg_update_bits() instead of set+clear. > Thanks to Michał Mirosław for the suggestion. > > drivers/mfd/tps65910.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH -next] mfd: altera-sysmgr: Use resource_size function on resource object
On Sat, 14 Nov 2020, Zou Wei wrote: > ./drivers/mfd/altera-sysmgr.c:155:36-39: WARNING: Suspicious code. > resource_size is maybe missing with res > > Generated by: scripts/coccinelle/api/resource_size.cocci > > Signed-off-by: Zou Wei > --- > drivers/mfd/altera-sysmgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
linux-next: manual merge of the akpm-current tree with the tip tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/kernel.h
between commit:
74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT")
from the tip tree and commit:
761ace49e56f ("kernel.h: Split out mathematical helpers")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/kernel.h
index dbf6018fc312,f97ab3283a8b..
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@@ -272,48 -145,13 +159,6 @@@ extern void __cant_migrate(const char *
#define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
- /**
- * abs - return absolute value of an argument
- * @x: the value. If it is unsigned type, it is converted to signed type
first.
- * char is treated as if it was signed (regardless of whether it really
is)
- * but the macro's return type is preserved as char.
- *
- * Return: an absolute value of x.
- */
- #define abs(x)__abs_choose_expr(x, long long,
\
- __abs_choose_expr(x, long, \
- __abs_choose_expr(x, int, \
- __abs_choose_expr(x, short, \
- __abs_choose_expr(x, char, \
- __builtin_choose_expr( \
- __builtin_types_compatible_p(typeof(x), char), \
- (char)({ signed char __x = (x); __x<0?-__x:__x; }), \
- ((void)0)))
-
- #define __abs_choose_expr(x, type, other) __builtin_choose_expr( \
- __builtin_types_compatible_p(typeof(x), signed type) || \
- __builtin_types_compatible_p(typeof(x), unsigned type), \
- ({ signed type __x = (x); __x < 0 ? -__x : __x; }), other)
-
- /**
- * reciprocal_scale - "scale" a value into range [0, ep_ro)
- * @val: value
- * @ep_ro: right open interval endpoint
- *
- * Perform a "reciprocal multiplication" in order to "scale" a value into
- * range [0, @ep_ro), where the upper interval endpoint is right-open.
- * This is useful, e.g. for accessing a index of an array containing
- * @ep_ro elements, for example. Think of it as sort of modulus, only that
- * the result isn't that of modulo. ;) Note that if initial input is a
- * small value, then result will return 0.
- *
- * Return: a result based on @val in interval [0, @ep_ro).
- */
- static inline u32 reciprocal_scale(u32 val, u32 ep_ro)
- {
- return (u32)(((u64) val * ep_ro) >> 32);
- }
-#ifndef CONFIG_PREEMPT_RT
-# define cant_migrate() cant_sleep()
-#else
- /* Placeholder for now */
-# define cant_migrate() do { } while (0)
-#endif
--
#if defined(CONFIG_MMU) && \
(defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_DEBUG_ATOMIC_SLEEP))
#define might_fault() __might_fault(__FILE__, __LINE__)
pgpr3m5up5suF.pgp
Description: OpenPGP digital signature
Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown
On Fri, 27 Nov 2020, Pkshih wrote: > > The subject prefix doesn't need 'realtek:'; use 'rtw88:'. > > On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote: > > Also strip out other duplicates from driver specific headers. > > > > Ensure 'main.h' is explicitly included in 'pci.h' since the latter > > uses some defines from the former. It avoids issues like: > > > > from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5: > > drivers/net/wireless/realtek/rtw88/pci.h:209:28: error: > > ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean > > ‘RTK_MAX_RX_DESC_NUM’? > > 209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM); > > | ^~~~ > > > > Fixes the following W=1 kernel build warning(s): > > > > drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous > > prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes] > > 1488 | int rtw_pci_probe(struct pci_dev *pdev, > > | ^ > > drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous > > prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes] > > 1568 | void rtw_pci_remove(struct pci_dev *pdev) > > | ^~ > > drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous > > prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes] > > 1590 | void rtw_pci_shutdown(struct pci_dev *pdev) > > | ^~~~ > > > > Cc: Yan-Hsuan Chuang > > Cc: Kalle Valo > > Cc: "David S. Miller" > > Cc: Jakub Kicinski > > Cc: linux-wirel...@vger.kernel.org > > Cc: net...@vger.kernel.org > > Signed-off-by: Lee Jones > > --- > > drivers/net/wireless/realtek/rtw88/pci.h | 8 > > drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 + > > drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 > > drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 + > > drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 > > drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 + > > drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 > > drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 + > > drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 > > 9 files changed, 12 insertions(+), 16 deletions(-) > > > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.h > > b/drivers/net/wireless/realtek/rtw88/pci.h > > index ca17aa9cf7dc7..cda56919a5f0f 100644 > > --- a/drivers/net/wireless/realtek/rtw88/pci.h > > +++ b/drivers/net/wireless/realtek/rtw88/pci.h > > @@ -5,6 +5,8 @@ > > #ifndef __RTK_PCI_H_ > > #define __RTK_PCI_H_ > > > > +#include "main.h" > > + > > Please #include "main.h" ahead of "pci.h" in each of rtw8e.c. You mean instead of in pci.h? Surely that's a hack. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH bpf-next 1/2] bpf: Add a bpf_kallsyms_lookup helper
On 11/26/20 8:57 AM, Florent Revest wrote:
This helper exposes the kallsyms_lookup function to eBPF tracing
programs. This can be used to retrieve the name of the symbol at an
address. For example, when hooking into nf_register_net_hook, one can
audit the name of the registered netfilter hook and potentially also
the name of the module in which the symbol is located.
Signed-off-by: Florent Revest
---
include/uapi/linux/bpf.h | 16 +
kernel/trace/bpf_trace.c | 41 ++
tools/include/uapi/linux/bpf.h | 16 +
3 files changed, 73 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index c3458ec1f30a..670998635eac 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -3817,6 +3817,21 @@ union bpf_attr {
*The **hash_algo** is returned on success,
***-EOPNOTSUP** if IMA is disabled or **-EINVAL** if
*invalid arguments are passed.
+ *
+ * long bpf_kallsyms_lookup(u64 address, char *symbol, u32 symbol_size, char
*module, u32 module_size)
+ * Description
+ * Uses kallsyms to write the name of the symbol at *address*
+ * into *symbol* of size *symbol_sz*. This is guaranteed to be
+ * zero terminated.
+ * If the symbol is in a module, up to *module_size* bytes of
+ * the module name is written in *module*. This is also
+ * guaranteed to be zero-terminated. Note: a module name
+ * is always shorter than 64 bytes.
+ * Return
+ * On success, the strictly positive length of the full symbol
+ * name, If this is greater than *symbol_size*, the written
+ * symbol is truncated.
+ * On error, a negative value.
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -3981,6 +3996,7 @@ union bpf_attr {
FN(bprm_opts_set), \
FN(ktime_get_coarse_ns),\
FN(ima_inode_hash), \
+ FN(kallsyms_lookup),\
/* */
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d255bc9b2bfa..9d86e20c2b13 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
@@ -1260,6 +1261,44 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = {
.arg5_type = ARG_ANYTHING,
};
+BPF_CALL_5(bpf_kallsyms_lookup, u64, address, char *, symbol, u32, symbol_size,
+ char *, module, u32, module_size)
+{
+ char buffer[KSYM_SYMBOL_LEN];
+ unsigned long offset, size;
+ const char *name;
+ char *modname;
+ long ret;
+
+ name = kallsyms_lookup(address, , , , buffer);
+ if (!name)
+ return -EINVAL;
+
+ ret = strlen(name) + 1;
+ if (symbol_size) {
+ strncpy(symbol, name, symbol_size);
+ symbol[symbol_size - 1] = '\0';
+ }
+
+ if (modname && module_size) {
+ strncpy(module, modname, module_size);
+ module[module_size - 1] = '\0';
In this case, module name may be truncated and user did not get any
indication from return value. In the helper description, it is mentioned
that module name currently is most 64 bytes. But from UAPI perspective,
it may be still good to return something to let user know the name
is truncated.
I do not know what is the best way to do this. One suggestion is
to break it into two helpers, one for symbol name and another
for module name. What is the use cases people want to get both
symbol name and module name and is it common?
+ }
+
+ return ret;
+}
+
+const struct bpf_func_proto bpf_kallsyms_lookup_proto = {
+ .func = bpf_kallsyms_lookup,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_ANYTHING,
+ .arg2_type = ARG_PTR_TO_MEM,
ARG_PTR_TO_UNINIT_MEM?
+ .arg3_type = ARG_CONST_SIZE,
ARG_CONST_SIZE_OR_ZERO? This is especially true for current format
which tries to return both symbol name and module name and
user may just want to do one of them.
+ .arg4_type = ARG_PTR_TO_MEM,
ARG_PTR_TO_UNINIT_MEM?
+ .arg5_type = ARG_CONST_SIZE,
ARG_CONST_SIZE_OR_ZERO?
+};
+
const struct bpf_func_proto *
bpf_tracing_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
@@ -1356,6 +1395,8 @@ bpf_tracing_func_proto(enum bpf_func_id func_id, const
struct bpf_prog *prog)
return _per_cpu_ptr_proto;
case BPF_FUNC_bpf_this_cpu_ptr:
return _this_cpu_ptr_proto;
+ case BPF_FUNC_kallsyms_lookup:
+ return _kallsyms_lookup_proto;
default:
return NULL;
}
[...]
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/Kconfig
between commit:
5cb0080f1bfd ("riscv: Enable ARCH_STACKWALK")
from the risc-v tree and commit:
46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on
DEBUG_PAGEALLOC")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/riscv/Kconfig
index 8a2a0523a9a3,9283c6f9ae2a..
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -14,7 -14,7 +14,8 @@@ config RISC
def_bool y
select ARCH_CLOCKSOURCE_INIT
select ARCH_SUPPORTS_ATOMIC_RMW
+ select ARCH_STACKWALK
+ select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEBUG_VIRTUAL if MMU
pgpVXOo6tKqMS.pgp
Description: OpenPGP digital signature
Re: [PATCH] usb: dwc3: meson-g12a: disable clk on error handling path in probe
Ping...
On Wed, Nov 11, 2020 at 10:48 AM Zheng Zengkai wrote:
dwc3_meson_g12a_probe() does not invoke clk_bulk_disable_unprepare()
on one error handling path. This patch fixes that.
Fixes: 347052e3bf1b ("usb: dwc3: meson-g12a: fix USB2 PHY initialization on G12A and
A1 SoCs")
Reported-by: Hulk Robot
Signed-off-by: Zheng Zengkai
Reviewed-by: Martin Blumenstingl
many thanks for this fix!
Best regards
Martin
.
linux-next: build failure after merge of the regmap tree
Hi all,
After merging the regmap tree, today's linux-next build (powerpc
allyesconfig) failed like this:
ld: sound/soc/codecs/rt715-sdca.o:(.opd+0xf0): multiple definition of
`rt715_init'; sound/soc/codecs/rt715.o:(.opd+0x108): first defined here
ld: sound/soc/codecs/rt715-sdca.o: in function `.rt715_init':
rt715-sdca.c:(.text.rt715_init+0x0): multiple definition of `.rt715_init';
sound/soc/codecs/rt715.o:rt715.c:(.text.rt715_init+0x0): first defined here
ld: sound/soc/codecs/rt715-sdca.o:(.opd+0x108): multiple definition of
`rt715_io_init'; sound/soc/codecs/rt715.o:(.opd+0x120): first defined here
ld: sound/soc/codecs/rt715-sdca.o: in function `.rt715_io_init':
rt715-sdca.c:(.text.rt715_io_init+0x0): multiple definition of
`.rt715_io_init'; sound/soc/codecs/rt715.o:rt715.c:(.text.rt715_io_init+0x0):
first defined here
Caused by commit
6f4a038b9967 ("ASoC/SoundWire: rt715-sdca: First version of rt715 sdw sdca
codec driver")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpb50tt4mT1l.pgp
Description: OpenPGP digital signature
Re: [PATCH 7/7] mm,hwpoison: Remove drain_all_pages from shake_page
On Thu, Nov 26, 2020 at 02:52:32PM +0100, Vlastimil Babka wrote: > > @@ -275,9 +275,6 @@ void shake_page(struct page *p, int access) > > lru_add_drain_all(); > > if (PageLRU(p)) > > return; > > - drain_all_pages(page_zone(p)); > > - if (PageLRU(p) || is_free_buddy_page(p)) > > - return; > > I wonder if page in the lru pagevec can in fact become free after draining > the lru - in that case we could keep the is_free_buddy_page() check. Uhm, yes, I think it can happen. After all, once the page hits one of the inactives' LRU it can be reclaimed. I am fine with joining the left PageLRU and is_free_buddy_page check. Will do that in the next revision. Thanks! -- Oscar Salvador SUSE L3
[PATCH] dmaengine: ti: k3-udma-glue: Add new class for glue channels
The dev_release must be provided for a device and in case of the udma glue
layer it is in essence an empty function as the struct containing the
registered device is devm managed.
Reported-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
Hi,
now that we actually have the silicon and the glue layer got into use it was
descovered that we need to have a class with dev_release function for the
devices we create for the physical channels used by the glue layer.
Vinod: I would prefer to send v3 and squash this patch down to the parent.
Regards,
Peter
drivers/dma/ti/k3-udma-glue.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index 2d0b26a7bf78..790027a99c4c 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -85,6 +85,16 @@ struct k3_udma_glue_rx_channel {
u32 flows_ready;
};
+static void chan_dev_release(struct device *dev)
+{
+ /* The struct containing the device is devm managed */
+}
+
+static struct class k3_udma_glue_devclass = {
+ .name = "k3_udma_glue_chan",
+ .dev_release= chan_dev_release,
+};
+
#define K3_UDMAX_TDOWN_TIMEOUT_US 1000
static int of_k3_udma_glue_parse(struct device_node *udmax_np,
@@ -286,6 +296,7 @@ struct k3_udma_glue_tx_channel
*k3_udma_glue_request_tx_chn(struct device *dev,
}
tx_chn->udma_tchan_id = xudma_tchan_get_id(tx_chn->udma_tchanx);
+ tx_chn->common.chan_dev.class = _udma_glue_devclass;
tx_chn->common.chan_dev.parent = xudma_get_device(tx_chn->common.udmax);
dev_set_name(_chn->common.chan_dev, "tchan%d-0x%04x",
tx_chn->udma_tchan_id, tx_chn->common.dst_thread);
@@ -903,6 +914,7 @@ k3_udma_glue_request_rx_chn_priv(struct device *dev, const
char *name,
}
rx_chn->udma_rchan_id = xudma_rchan_get_id(rx_chn->udma_rchanx);
+ rx_chn->common.chan_dev.class = _udma_glue_devclass;
rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
dev_set_name(_chn->common.chan_dev, "rchan%d-0x%04x",
rx_chn->udma_rchan_id, rx_chn->common.src_thread);
@@ -1033,6 +1045,7 @@ k3_udma_glue_request_remote_rx_chn(struct device *dev,
const char *name,
goto err;
}
+ rx_chn->common.chan_dev.class = _udma_glue_devclass;
rx_chn->common.chan_dev.parent = xudma_get_device(rx_chn->common.udmax);
dev_set_name(_chn->common.chan_dev, "rchan_remote-0x%04x",
rx_chn->common.src_thread);
@@ -1419,3 +1432,9 @@ void k3_udma_glue_rx_cppi5_to_dma_addr(struct
k3_udma_glue_rx_channel *rx_chn,
*addr &= (u64)GENMASK(K3_ADDRESS_ASEL_SHIFT - 1, 0);
}
EXPORT_SYMBOL_GPL(k3_udma_glue_rx_cppi5_to_dma_addr);
+
+static int __init k3_udma_glue_class_init(void)
+{
+ return class_register(_udma_glue_devclass);
+}
+arch_initcall(k3_udma_glue_class_init);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] tomoyo: Avoid potential null pointer access
Hello Tetsuo, On 2020/11/26 15:33, Zheng Zengkai wrote: As your say, I found the function tomoyo_assign_namespace( ) in security/tomoyo/domain.c has the similar situation, Can I add __GFP_NOWARN for both and remove the null check for _entry_ in tomoyo_assign_namespace( )? Good catch. Yes, please send as a patch. . I have resent a patch, thanks!
Re: [GIT PULL] OP-TEE driver for v5.11
Hi Arnd, On Thu, Nov 26, 2020 at 10:00 PM Arnd Bergmann wrote: > > On Wed, Nov 25, 2020 at 1:01 PM Jens Wiklander > wrote: > > > > Hello arm-soc maintainers, > > > > Please pull this small patch which allows the OP-TEE driver to work with > > ARMv7 based single CPU systems. > > Can you rebase that branch onto -rc1? I had started the arm/drivers > branch early on top of that, so I'd prefer to avoid a backmerged. > > For the commit itself, shouldn't that be marked as a bugfix and get > merged into v5.10 instead? If it should, you don't have to rebase > since the arm/fixes branch is already ahead. Yes it is a bit of a bugfix, so if you don't mind taking it as that I'm sure that Rui would be happy to get it in this release. > > Also, it would be nice to Cc linux-arm-kernel on the pull request > in addition to linux-kernel. I'll keep that in mind the next time. Thanks for the feedback. Cheers, Jens
Re: [PATCH v4 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC
Hello Jonathan,
On Fri, Nov 27, 2020 at 12:19:31AM +0100, Jonathan Neuschäfer wrote:
> On Tue, Nov 24, 2020 at 09:20:19AM +0100, Uwe Kleine-König wrote:
> > On Sun, Nov 22, 2020 at 11:27:36PM +0100, Jonathan Neuschäfer wrote:
> [...]
> > > +/*
> > > + * The time base used in the EC is 8MHz, or 125ns. Period and duty cycle
> > > are
> > > + * measured in this unit.
> > > + */
> > > +#define TIME_BASE_NS 125
> > > +
> > > +/*
> > > + * The maximum input value (in nanoseconds) is determined by the time
> > > base and
> > > + * the range of the hardware registers that hold the converted value.
> > > + * It fits into 32 bits, so we can do our calculations in 32 bits as
> > > well.
> > > + */
> > > +#define MAX_PERIOD_NS (TIME_BASE_NS * 0x)
> > > +
> > > +static int ntxec_pwm_apply(struct pwm_chip *chip, struct pwm_device
> > > *pwm_dev,
> > > +const struct pwm_state *state)
> > > +{
> > > + struct ntxec_pwm *priv = pwmchip_to_priv(pwm_dev->chip);
> > > + unsigned int duty = state->duty_cycle;
> > > + unsigned int period = state->period;
> >
> > state->duty_cycle and state->period are u64, so you're losing
> > information here. Consider state->duty_cycle = 0x10001 and
> > state->period = 0x20001.
>
> Oh, good point, I didn't notice the truncation.
>
> The reason I picked unsigned int was to avoid a 64-bit division;
> I suppose I can do something like this:
>
> period = (u32)period / TIME_BASE_NS;
> duty = (u32)duty / TIME_BASE_NS;
You can do that after you checked period > MAX_PERIOD_NS below, yes.
Something like:
if (state->polarity != PWM_POLARITY_NORMAL)
return -EINVAL;
if (state->period > MAX_PERIOD_NS) {
period = MAX_PERIOD_NS;
else
period = state->period;
if (state->duty_cycle > period)
duty_cycle = period;
else
duty_cycle = state->duty_cycle;
should work with even keeping the local variables as unsigned int.
> > > + int res = 0;
> > > +
> > > + if (state->polarity != PWM_POLARITY_NORMAL)
> > > + return -EINVAL;
> > > +
> > > + if (period > MAX_PERIOD_NS) {
> > > + period = MAX_PERIOD_NS;
> > > +
> > > + if (duty > period)
> > > + duty = period;
> > > + }
> > > +
> > > + period /= TIME_BASE_NS;
> > > + duty /= TIME_BASE_NS;
> > > +
> > > + res = regmap_write(priv->ec->regmap, NTXEC_REG_PERIOD_HIGH,
> > > ntxec_reg8(period >> 8));
> > > + if (res)
> > > + return res;
> >
> > I wonder if you can add some logic to the regmap in the mfd driver such
> > that ntxec_reg8 isn't necessary for all users.
>
> I think that would involve:
>
> 1. adding custom register access functions to the regmap, which decide
>based on the register number whether a register needs 8-bit or 16-bit
>access. So far I have avoided information about registers into the
>main driver, when the registers are only used in the sub-drivers.
>
> or
>
> 2. switching the regmap configuration to little endian, which would be
>advantageous for 8-bit registers, inconsequential for 16-bit
>registers that consist of independent high and low halves, and wrong
>for the 16-bit registers 0x41, which reads the battery voltage ADC
>value. It is also different from how the vendor kernel treats 16-bit
>registers.
>
> Perhaps there is another option that I haven't considered yet.
I don't know enough about regmap to teach you something here. But maybe
Mark has an idea. (I promoted him from Cc: to To:, maybe he will
notice.)
> > > + res = regmap_write(priv->ec->regmap, NTXEC_REG_PERIOD_LOW,
> > > ntxec_reg8(period));
> > > + if (res)
> > > + return res;
> > > +
> > > + res = regmap_write(priv->ec->regmap, NTXEC_REG_DUTY_HIGH,
> > > ntxec_reg8(duty >> 8));
> > > + if (res)
> > > + return res;
> > > +
> > > + res = regmap_write(priv->ec->regmap, NTXEC_REG_DUTY_LOW,
> > > ntxec_reg8(duty));
> > > + if (res)
> > > + return res;
> >
> > I think I already asked, but I don't remember the reply: What happens to
> > the output between these writes? A comment here about this would be
> > suitable.
>
> I will add something like the following:
>
> /*
> * Changes to the period and duty cycle take effect as soon as the
> * corresponding low byte is written, so the hardware may be configured
> * to an inconsistent state after the period is written and before the
> * duty cycle is fully written. If, in such a case, the old duty cycle
> * is longer than the new period, the EC will output 100% for a moment.
> */
Is the value pair taken over by hardware atomically? That is, is it
really "will" in your last line, or only "might". (E.g. when changing
from duty_cycle, period = 1000, 2000 to 500, 800 and a new cycle begins
after reducing period, the new duty_cycle is probably written before the
counter reaches 500. Do we get a 100% cycle here?)
Other than that the info is fine. Make sure
[PATCH] powerpc: Use common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro
Use the common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro rule for
the linker script in an effort.
Signed-off-by: Youling Tang
---
arch/powerpc/kernel/vdso32/vdso32.lds.S | 42 -
arch/powerpc/kernel/vdso64/vdso64.lds.S | 42 -
2 files changed, 8 insertions(+), 76 deletions(-)
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S
b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 7eadac7..8b5c7eb 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -4,6 +4,7 @@
* library
*/
#include
+#include
#ifdef __LITTLE_ENDIAN__
OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
@@ -68,44 +69,9 @@ SECTIONS
__end = .;
PROVIDE(end = .);
- /*
-* Stabs debugging sections are here too.
-*/
- .stab 0 : { *(.stab) }
- .stabstr 0 : { *(.stabstr) }
- .stab.excl 0 : { *(.stab.excl) }
- .stab.exclstr 0 : { *(.stab.exclstr) }
- .stab.index 0 : { *(.stab.index) }
- .stab.indexstr 0 : { *(.stab.indexstr) }
- .comment 0 : { *(.comment) }
-
- /*
-* DWARF debug sections.
-* Symbols in the DWARF debugging sections are relative to the beginning
-* of the section so we begin them at 0.
-*/
- /* DWARF 1 */
- .debug 0 : { *(.debug) }
- .line 0 : { *(.line) }
- /* GNU DWARF 1 extensions */
- .debug_srcinfo 0 : { *(.debug_srcinfo) }
- .debug_sfnames 0 : { *(.debug_sfnames) }
- /* DWARF 1.1 and DWARF 2 */
- .debug_aranges 0 : { *(.debug_aranges) }
- .debug_pubnames 0 : { *(.debug_pubnames) }
- /* DWARF 2 */
- .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
- .debug_abbrev 0 : { *(.debug_abbrev) }
- .debug_line 0 : { *(.debug_line) }
- .debug_frame0 : { *(.debug_frame) }
- .debug_str 0 : { *(.debug_str) }
- .debug_loc 0 : { *(.debug_loc) }
- .debug_macinfo 0 : { *(.debug_macinfo) }
- /* SGI/MIPS DWARF 2 extensions */
- .debug_weaknames 0 : { *(.debug_weaknames) }
- .debug_funcnames 0 : { *(.debug_funcnames) }
- .debug_typenames 0 : { *(.debug_typenames) }
- .debug_varnames 0 : { *(.debug_varnames) }
+ STABS_DEBUG
+ DWARF_DEBUG
+ ELF_DETAILS
/DISCARD/ : {
*(.note.GNU-stack)
diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S
b/arch/powerpc/kernel/vdso64/vdso64.lds.S
index 256fb97..0002f4e 100644
--- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
@@ -4,6 +4,7 @@
* library
*/
#include
+#include
#ifdef __LITTLE_ENDIAN__
OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
@@ -67,44 +68,9 @@ SECTIONS
_end = .;
PROVIDE(end = .);
- /*
-* Stabs debugging sections are here too.
-*/
- .stab 0 : { *(.stab) }
- .stabstr 0 : { *(.stabstr) }
- .stab.excl 0 : { *(.stab.excl) }
- .stab.exclstr 0 : { *(.stab.exclstr) }
- .stab.index0 : { *(.stab.index) }
- .stab.indexstr 0 : { *(.stab.indexstr) }
- .comment 0 : { *(.comment) }
-
- /*
-* DWARF debug sections.
-* Symbols in the DWARF debugging sections are relative to the beginning
-* of the section so we begin them at 0.
-*/
- /* DWARF 1 */
- .debug 0 : { *(.debug) }
- .line 0 : { *(.line) }
- /* GNU DWARF 1 extensions */
- .debug_srcinfo 0 : { *(.debug_srcinfo) }
- .debug_sfnames 0 : { *(.debug_sfnames) }
- /* DWARF 1.1 and DWARF 2 */
- .debug_aranges 0 : { *(.debug_aranges) }
- .debug_pubnames 0 : { *(.debug_pubnames) }
- /* DWARF 2 */
- .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
- .debug_abbrev 0 : { *(.debug_abbrev) }
- .debug_line 0 : { *(.debug_line) }
- .debug_frame0 : { *(.debug_frame) }
- .debug_str 0 : { *(.debug_str) }
- .debug_loc 0 : { *(.debug_loc) }
- .debug_macinfo 0 : { *(.debug_macinfo) }
- /* SGI/MIPS DWARF 2 extensions */
- .debug_weaknames 0 : { *(.debug_weaknames) }
- .debug_funcnames 0 : { *(.debug_funcnames) }
- .debug_typenames 0 : { *(.debug_typenames) }
- .debug_varnames 0 : { *(.debug_varnames) }
+ STABS_DEBUG
+ DWARF_DEBUG
+ ELF_DETAILS
/DISCARD/ : {
*(.note.GNU-stack)
--
2.1.0
Re: [PATCH bpf-next v3 6/6] bpf: Test bpf_sk_storage_get in tcp iterators
On 11/26/20 8:44 AM, Florent Revest wrote:
This extends the existing bpf_sk_storage_get test where a socket is
created and tagged with its creator's pid by a task_file iterator.
A TCP iterator is now also used at the end of the test to negate the
values already stored in the local storage. The test therefore expects
-getpid() to be stored in the local storage.
Signed-off-by: Florent Revest
Ack with a minor comment below.
Acked-by: Yonghong Song
---
.../selftests/bpf/prog_tests/bpf_iter.c| 13 +
.../progs/bpf_iter_bpf_sk_storage_helpers.c| 18 ++
2 files changed, 31 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
index 9336d0f18331..b8362147c9e3 100644
--- a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
@@ -978,6 +978,8 @@ static void test_bpf_sk_storage_delete(void)
/* This creates a socket and its local storage. It then runs a task_iter BPF
* program that replaces the existing socket local storage with the tgid of
the
* only task owning a file descriptor to this socket, this process,
prog_tests.
+ * It then runs a tcp socket iterator that negates the value in the existing
+ * socket local storage, the test verifies that the resulting value is -pid.
*/
static void test_bpf_sk_storage_get(void)
{
@@ -994,6 +996,10 @@ static void test_bpf_sk_storage_get(void)
if (CHECK(sock_fd < 0, "socket", "errno: %d\n", errno))
goto out;
+ err = listen(sock_fd, 1);
+ if (CHECK(err != 0, "listen", "errno: %d\n", errno))
+ goto out;
+
map_fd = bpf_map__fd(skel->maps.sk_stg_map);
err = bpf_map_update_elem(map_fd, _fd, , BPF_NOEXIST);
@@ -1007,6 +1013,13 @@ static void test_bpf_sk_storage_get(void)
"map value wasn't set correctly (expected %d, got %d, err=%d)\n",
getpid(), val, err);
+ do_dummy_read(skel->progs.negate_socket_local_storage);
+
+ err = bpf_map_lookup_elem(map_fd, _fd, );
+ CHECK(err || val != -getpid(), "bpf_map_lookup_elem",
+ "map value wasn't set correctly (expected %d, got %d, err=%d)\n",
+ -getpid(), val, err);
+
close_socket:
close(sock_fd);
out:
diff --git
a/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
b/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
index d7a7a802d172..b3f0cb139c55 100644
--- a/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
+++ b/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
@@ -46,3 +46,21 @@ int fill_socket_owner(struct bpf_iter__task_file *ctx)
return 0;
}
+SEC("iter/tcp")
+int negate_socket_local_storage(struct bpf_iter__tcp *ctx)
+{
+ struct sock_common *sk_common = ctx->sk_common;
+ int *sock_tgid;
+
+ if (!sk_common)
+ return 0;
+
+ sock_tgid = bpf_sk_storage_get(_stg_map, sk_common, 0, 0);
+ if (!sock_tgid)
+ return 0;
+
+ *sock_tgid = -*sock_tgid;
+
+ return 0;
+}
+
extra empty line here.
Re: [PATCH bpf-next v3 5/6] bpf: Add an iterator selftest for bpf_sk_storage_get
On 11/26/20 8:44 AM, Florent Revest wrote:
The eBPF program iterates over all files and tasks. For all socket
files, it stores the tgid of the last task it encountered with a handle
to that socket. This is a heuristic for finding the "owner" of a socket
similar to what's done by lsof, ss, netstat or fuser. Potentially, this
information could be used from a cgroup_skb/*gress hook to try to
associate network traffic with processes.
The test makes sure that a socket it created is tagged with prog_tests's
pid.
Signed-off-by: Florent Revest
Ack with two minor comments below.
Acked-by: Yonghong Song
---
.../selftests/bpf/prog_tests/bpf_iter.c | 40 +++
.../progs/bpf_iter_bpf_sk_storage_helpers.c | 25
2 files changed, 65 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
index bb4a638f2e6f..9336d0f18331 100644
--- a/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_iter.c
@@ -975,6 +975,44 @@ static void test_bpf_sk_storage_delete(void)
bpf_iter_bpf_sk_storage_helpers__destroy(skel);
}
+/* This creates a socket and its local storage. It then runs a task_iter BPF
+ * program that replaces the existing socket local storage with the tgid of the
+ * only task owning a file descriptor to this socket, this process, prog_tests.
+ */
+static void test_bpf_sk_storage_get(void)
+{
+ struct bpf_iter_bpf_sk_storage_helpers *skel;
+ int err, map_fd, val = -1;
+ int sock_fd = -1;
+
+ skel = bpf_iter_bpf_sk_storage_helpers__open_and_load();
+ if (CHECK(!skel, "bpf_iter_bpf_sk_storage_helpers__open_and_load",
+ "skeleton open_and_load failed\n"))
+ return;
+
+ sock_fd = socket(AF_INET6, SOCK_STREAM, 0);
+ if (CHECK(sock_fd < 0, "socket", "errno: %d\n", errno))
+ goto out;
+
+ map_fd = bpf_map__fd(skel->maps.sk_stg_map);
+
+ err = bpf_map_update_elem(map_fd, _fd, , BPF_NOEXIST);
+ if (CHECK(err, "bpf_map_update_elem", "map_update_failed\n"))
+ goto close_socket;
+
+ do_dummy_read(skel->progs.fill_socket_owner);
+
+ err = bpf_map_lookup_elem(map_fd, _fd, );
+ CHECK(err || val != getpid(), "bpf_map_lookup_elem",
+ "map value wasn't set correctly (expected %d, got %d, err=%d)\n",
+ getpid(), val, err);
+
+close_socket:
+ close(sock_fd);
+out:
+ bpf_iter_bpf_sk_storage_helpers__destroy(skel);
+}
+
static void test_bpf_sk_storage_map(void)
{
DECLARE_LIBBPF_OPTS(bpf_iter_attach_opts, opts);
@@ -1131,6 +1169,8 @@ void test_bpf_iter(void)
test_bpf_sk_storage_map();
if (test__start_subtest("bpf_sk_storage_delete"))
test_bpf_sk_storage_delete();
+ if (test__start_subtest("bpf_sk_storage_get"))
+ test_bpf_sk_storage_get();
if (test__start_subtest("rdonly-buf-out-of-bound"))
test_rdonly_buf_out_of_bound();
if (test__start_subtest("buf-neg-offset"))
diff --git
a/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
b/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
index 01ff3235e413..d7a7a802d172 100644
--- a/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
+++ b/tools/testing/selftests/bpf/progs/bpf_iter_bpf_sk_storage_helpers.c
@@ -21,3 +21,28 @@ int delete_bpf_sk_storage_map(struct
bpf_iter__bpf_sk_storage_map *ctx)
return 0;
}
+
+SEC("iter/task_file")
+int fill_socket_owner(struct bpf_iter__task_file *ctx)
+{
+ struct task_struct *task = ctx->task;
+ struct file *file = ctx->file;
+ struct socket *sock;
+ int *sock_tgid;
+
+ if (!task || !file || task->tgid != task->pid)
task->tgid != task->pid is not needed here.
The task_file iterator already tries to skip task with task->pid
if its file table is the same as task->tgid.
+ return 0;
+
+ sock = bpf_sock_from_file(file);
+ if (!sock)
+ return 0;
+
+ sock_tgid = bpf_sk_storage_get(_stg_map, sock->sk, 0, 0);
+ if (!sock_tgid)
+ return 0;
+
+ *sock_tgid = task->tgid;
+
+ return 0;
+}
+
Extra empty line.
[PATCH v3 5/5] Documentation: Add L1D flushing Documentation
Add documentation of l1d flushing, explain the need for the feature and how it can be used. Signed-off-by: Balbir Singh Signed-off-by: Thomas Gleixner --- Documentation/admin-guide/hw-vuln/index.rst | 1 + .../admin-guide/hw-vuln/l1d_flush.rst | 69 +++ .../admin-guide/kernel-parameters.txt | 17 + Documentation/userspace-api/spec_ctrl.rst | 8 +++ 4 files changed, 95 insertions(+) create mode 100644 Documentation/admin-guide/hw-vuln/l1d_flush.rst diff --git a/Documentation/admin-guide/hw-vuln/index.rst b/Documentation/admin-guide/hw-vuln/index.rst index ca4dbdd9016d..21710f8609fe 100644 --- a/Documentation/admin-guide/hw-vuln/index.rst +++ b/Documentation/admin-guide/hw-vuln/index.rst @@ -15,3 +15,4 @@ are configurable at compile, boot or run time. tsx_async_abort multihit.rst special-register-buffer-data-sampling.rst + l1d_flush.rst diff --git a/Documentation/admin-guide/hw-vuln/l1d_flush.rst b/Documentation/admin-guide/hw-vuln/l1d_flush.rst new file mode 100644 index ..9db0f5e568cb --- /dev/null +++ b/Documentation/admin-guide/hw-vuln/l1d_flush.rst @@ -0,0 +1,69 @@ +L1D Flushing + + +With an increasing number of vulnerabilities being reported around data +leaks from the Level 1 Data cache (L1D) the kernel provides an opt-in +mechanism to flush the L1D cache on context switch. + +This mechanism can be used to address e.g. CVE-2020-0550. For applications +the mechanism keeps them safe from vulnerabilities, related to leaks +(snooping of) from the L1D cache. + + +Related CVEs + +The following CVEs can be addressed by this +mechanism + += == +CVE-2020-0550 Improper Data Forwarding OS related aspects += == + +Usage Guidelines + + +Please see document: :ref:`Documentation/userspace-api/spec_ctrl.rst +` for details. + +**NOTE**: The feature is disabled by default, applications need to +specifically opt into the feature to enable it. + +Mitigation +-- + +When PR_SET_L1D_FLUSH is enabled for a task a flush of the L1D cache is +performed when the task is scheduled out and the incoming task belongs to a +different process and therefore to a different address space. + +If the underlying CPU supports L1D flushing in hardware, the hardware +mechanism is used, software fallback for the mitigation, is not supported. + +Mitigation control on the kernel command line +- + +The kernel command line allows to control the L1D flush mitigations at boot +time with the option "l1d_flush_out=". The valid arguments for this option are: + + = + off Disables the prctl interface, applications trying to use +the prctl() will fail with an error + = + +By default the API is enabled and applications opt-in by using the prctl +API. + +Limitations +--- + +The mechanism does not mitigate L1D data leaks between tasks belonging to +different processes which are concurrently executing on sibling threads of +a physical CPU core when SMT is enabled on the system. + +This can be addressed by controlled placement of processes on physical CPU +cores or by disabling SMT. See the relevant chapter in the L1TF mitigation +document: :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst `. + +**NOTE** : The opt-in of a task for L1D flushing will work only when the +tasks affinity is limited to cores running in non-SMT mode. Running the task +on a CPU with SMT enabled would result in the task getting a SIGBUS when +t executes on the non-SMT core. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 44fde25bb221..e3ed24af91d1 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2320,6 +2320,23 @@ feature (tagged TLBs) on capable Intel chips. Default is 1 (enabled) + l1d_flush_out= [X86,INTEL] + Control mitigation for L1D based snooping vulnerability. + + Certain CPUs are vulnerable to an exploit against CPU + internal buffers which can forward information to a + disclosure gadget under certain conditions. + + In vulnerable processors, the speculatively + forwarded data can be used in a cache side channel + attack, to access data to which the attacker does + not have direct access. + + This parameter controls the mitigation. The + options are: + +
[PATCH v3 3/5] x86/mm: Optionally flush L1D on context switch
Implement a mechanism to selectively flush the L1D cache. The goal is to
allow tasks that want to save sensitive information, found by the recent
snoop assisted data sampling vulnerabilites, to flush their L1D on being
switched out. This protects their data from being snooped or leaked via
side channels after the task has context switched out.
There are two scenarios we might want to protect against, a task leaving
the CPU with data still in L1D (which is the main concern of this patch),
the second scenario is a malicious task coming in (not so well trusted)
for which we want to clean up the cache before it starts. Only the case
for the former is addressed.
A new thread_info flag TIF_SPEC_L1D_FLUSH is added to track tasks which
opt-into L1D flushing. cpu_tlbstate.last_user_mm_spec is used to convert
the TIF flags into mm state (per cpu via last_user_mm_spec) in
cond_mitigation(), which then used to do decide when to flush the
L1D cache.
A new helper inline function l1d_flush_hw() has been introduced.
Currently it returns an error code if hardware flushing is not
supported. The caller currently does not check the return value, in the
context of these patches, the routine is called only when HW assisted
flushing is available.
Suggested-by: Thomas Gleixner
Signed-off-by: Balbir Singh
Signed-off-by: Thomas Gleixner
Link: https://lore.kernel.org/r/20200729001103.6450-4-sbl...@amazon.com
---
arch/x86/include/asm/cacheflush.h | 8
arch/x86/include/asm/thread_info.h | 9 +++--
arch/x86/mm/tlb.c | 30 +++---
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/cacheflush.h
b/arch/x86/include/asm/cacheflush.h
index b192d917a6d0..554eaf697f3f 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -10,4 +10,12 @@
void clflush_cache_range(void *addr, unsigned int size);
+static inline int l1d_flush_hw(void)
+{
+ if (static_cpu_has(X86_FEATURE_FLUSH_L1D)) {
+ wrmsrl(MSR_IA32_FLUSH_CMD, L1D_FLUSH);
+ return 0;
+ }
+ return -EOPNOTSUPP;
+}
#endif /* _ASM_X86_CACHEFLUSH_H */
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 44733a4bfc42..36a11cfb1061 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -84,7 +84,7 @@ struct thread_info {
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
#define TIF_SPEC_IB9 /* Indirect branch speculation
mitigation */
-#define TIF_SPEC_FORCE_UPDATE 10 /* Force speculation MSR update in
context switch */
+#define TIF_SPEC_L1D_FLUSH 10 /* Flush L1D on mm switches (processes)
*/
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
@@ -96,6 +96,7 @@ struct thread_info {
#define TIF_MEMDIE 20 /* is terminating due to OOM killer */
#define TIF_POLLING_NRFLAG 21 /* idle is polling for TIF_NEED_RESCHED
*/
#define TIF_IO_BITMAP 22 /* uses I/O bitmap */
+#define TIF_SPEC_FORCE_UPDATE 23 /* Force speculation MSR update in
context switch */
#define TIF_FORCED_TF 24 /* true if TF in eflags artificially */
#define TIF_BLOCKSTEP 25 /* set when we want DEBUGCTLMSR_BTF */
#define TIF_LAZY_MMU_UPDATES 27 /* task is updating the mmu lazily */
@@ -113,7 +114,7 @@ struct thread_info {
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
-#define _TIF_SPEC_FORCE_UPDATE (1 << TIF_SPEC_FORCE_UPDATE)
+#define _TIF_SPEC_L1D_FLUSH(1 << TIF_SPEC_L1D_FLUSH)
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -124,6 +125,7 @@ struct thread_info {
#define _TIF_SLD (1 << TIF_SLD)
#define _TIF_POLLING_NRFLAG(1 << TIF_POLLING_NRFLAG)
#define _TIF_IO_BITMAP (1 << TIF_IO_BITMAP)
+#define _TIF_SPEC_FORCE_UPDATE (1 << TIF_SPEC_FORCE_UPDATE)
#define _TIF_FORCED_TF (1 << TIF_FORCED_TF)
#define _TIF_BLOCKSTEP (1 << TIF_BLOCKSTEP)
#define _TIF_LAZY_MMU_UPDATES (1 << TIF_LAZY_MMU_UPDATES)
@@ -228,6 +230,9 @@ static inline int arch_within_stack_frames(const void *
const stack,
current_thread_info()->status & TS_COMPAT)
#endif
+extern int enable_l1d_flush_for_task(struct task_struct *tsk);
+extern int disable_l1d_flush_for_task(struct task_struct *tsk);
+
extern void arch_task_cache_init(void);
extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct
[PATCH v3 4/5] prctl: Hook L1D flushing in via prctl
Use the existing PR_GET/SET_SPECULATION_CTRL API to expose the L1D
flush capability. For L1D flushing PR_SPEC_FORCE_DISABLE and
PR_SPEC_DISABLE_NOEXEC are not supported.
Enabling L1D flush does not check if the task is running on
an SMT enabled core, rather a check is done at runtime (at the
time of flush), if the task runs on a non SMT enabled core
then the task is sent a SIGBUS (this is done prior to the task
executing on the core, so no data is leaked). This is better
than the other alternatives of
a. Ensuring strict affinity of the task (hard to enforce
without further changes in the scheduler)
b. Silently skipping flush for tasks that move to SMT enabled
cores.
An arch config ARCH_HAS_PARANOID_L1D_FLUSH has been added
and struct task carries a callback_head for arch's that support
this config (currently on x86), this callback head is used
to schedule task work (SIGBUS delivery).
There is also no seccomp integration for the feature.
Suggested-by: Thomas Gleixner
Signed-off-by: Balbir Singh
Signed-off-by: Thomas Gleixner
---
arch/Kconfig | 4 +++
arch/x86/Kconfig | 1 +
arch/x86/kernel/cpu/bugs.c | 54 ++
arch/x86/mm/tlb.c | 30 -
include/linux/sched.h | 10 +++
include/uapi/linux/prctl.h | 1 +
6 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 56b6ccc0e32d..d4a0501ac7fc 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -311,6 +311,10 @@ config ARCH_32BIT_OFF_T
still support 32-bit off_t. This option is enabled for all such
architectures explicitly.
+config ARCH_HAS_PARANOID_L1D_FLUSH
+ bool
+ default n
+
config HAVE_ASM_MODVERSIONS
bool
help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f6946b81f74a..4f6caa6dae16 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -101,6 +101,7 @@ config X86
select ARCH_WANTS_DYNAMIC_TASK_STRUCT
select ARCH_WANT_HUGE_PMD_SHARE
select ARCH_WANTS_THP_SWAP if X86_64
+ select ARCH_HAS_PARANOID_L1D_FLUSH
select BUILDTIME_TABLE_SORT
select CLKEVT_I8253
select CLOCKSOURCE_VALIDATE_LAST_CYCLE
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 581fb7223ad0..dece79e4d1e9 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -296,6 +296,13 @@ enum taa_mitigations {
TAA_MITIGATION_TSX_DISABLED,
};
+enum l1d_flush_out_mitigations {
+ L1D_FLUSH_OUT_OFF,
+ L1D_FLUSH_OUT_ON,
+};
+
+static enum l1d_flush_out_mitigations l1d_flush_out_mitigation __ro_after_init
= L1D_FLUSH_OUT_ON;
+
/* Default mitigation for TAA-affected CPUs */
static enum taa_mitigations taa_mitigation __ro_after_init =
TAA_MITIGATION_VERW;
static bool taa_nosmt __ro_after_init;
@@ -379,6 +386,18 @@ static void __init taa_select_mitigation(void)
pr_info("%s\n", taa_strings[taa_mitigation]);
}
+static int __init l1d_flush_out_parse_cmdline(char *str)
+{
+ if (!boot_cpu_has_bug(X86_BUG_L1TF))
+ return 0;
+
+ if (!strcmp(str, "off"))
+ l1d_flush_out_mitigation = L1D_FLUSH_OUT_OFF;
+
+ return 0;
+}
+early_param("l1d_flush_out", l1d_flush_out_parse_cmdline);
+
static int __init tsx_async_abort_parse_cmdline(char *str)
{
if (!boot_cpu_has_bug(X86_BUG_TAA))
@@ -1215,6 +1234,23 @@ static void task_update_spec_tif(struct task_struct *tsk)
speculation_ctrl_update_current();
}
+static int l1d_flush_out_prctl_set(struct task_struct *task, unsigned long
ctrl)
+{
+
+ if (l1d_flush_out_mitigation == L1D_FLUSH_OUT_OFF)
+ return -EPERM;
+
+ switch (ctrl) {
+ case PR_SPEC_ENABLE:
+ return enable_l1d_flush_for_task(task);
+ case PR_SPEC_DISABLE:
+ return disable_l1d_flush_for_task(task);
+ default:
+ return -ERANGE;
+ }
+ return 0;
+}
+
static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
{
if (ssb_mode != SPEC_STORE_BYPASS_PRCTL &&
@@ -1324,6 +1360,8 @@ int arch_prctl_spec_ctrl_set(struct task_struct *task,
unsigned long which,
return ssb_prctl_set(task, ctrl);
case PR_SPEC_INDIRECT_BRANCH:
return ib_prctl_set(task, ctrl);
+ case PR_SPEC_L1D_FLUSH_OUT:
+ return l1d_flush_out_prctl_set(task, ctrl);
default:
return -ENODEV;
}
@@ -1340,6 +1378,20 @@ void arch_seccomp_spec_mitigate(struct task_struct *task)
}
#endif
+static int l1d_flush_out_prctl_get(struct task_struct *task)
+{
+ int ret;
+
+ if (l1d_flush_out_mitigation == L1D_FLUSH_OUT_OFF)
+ return PR_SPEC_FORCE_DISABLE;
+
+ ret = test_ti_thread_flag(>thread_info, TIF_SPEC_L1D_FLUSH);
+ if (ret)
+ return PR_SPEC_PRCTL | PR_SPEC_ENABLE;
+ else
+ return
[PATCH v3 2/5] x86/mm: Refactor cond_ibpb() to support other use cases
cond_ibpb() has the necessary bits required to track the previous mm in
switch_mm_irqs_off(). This can be reused for other use cases like L1D
flushing on context switch.
[ tglx: Moved comment, added a separate define for state (re)initialization ]
Suggested-by: Thomas Gleixner
Signed-off-by: Balbir Singh
Signed-off-by: Thomas Gleixner
Link: https://lkml.kernel.org/r/20200510014803.12190-4-sbl...@amazon.com
Link: https://lore.kernel.org/r/20200729001103.6450-3-sbl...@amazon.com
---
arch/x86/include/asm/tlbflush.h | 2 +-
arch/x86/mm/tlb.c | 53 ++---
2 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 8c87a2e0b660..a927d40664df 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -83,7 +83,7 @@ struct tlb_state {
/* Last user mm for optimizing IBPB */
union {
struct mm_struct*last_user_mm;
- unsigned long last_user_mm_ibpb;
+ unsigned long last_user_mm_spec;
};
u16 loaded_mm_asid;
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 11666ba19b62..ca021e039451 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -42,10 +42,14 @@
*/
/*
- * Use bit 0 to mangle the TIF_SPEC_IB state into the mm pointer which is
- * stored in cpu_tlb_state.last_user_mm_ibpb.
+ * Bits to mangle the TIF_SPEC_IB state into the mm pointer which is
+ * stored in cpu_tlb_state.last_user_mm_spec.
*/
#define LAST_USER_MM_IBPB 0x1UL
+#define LAST_USER_MM_SPEC_MASK (LAST_USER_MM_IBPB)
+
+/* Bits to set when tlbstate and flush is (re)initialized */
+#define LAST_USER_MM_INIT LAST_USER_MM_IBPB
/*
* The x86 feature is called PCID (Process Context IDentifier). It is similar
@@ -316,20 +320,29 @@ void switch_mm(struct mm_struct *prev, struct mm_struct
*next,
local_irq_restore(flags);
}
-static inline unsigned long mm_mangle_tif_spec_ib(struct task_struct *next)
+static inline unsigned long mm_mangle_tif_spec_bits(struct task_struct *next)
{
unsigned long next_tif = task_thread_info(next)->flags;
- unsigned long ibpb = (next_tif >> TIF_SPEC_IB) & LAST_USER_MM_IBPB;
+ unsigned long spec_bits = (next_tif >> TIF_SPEC_IB) &
LAST_USER_MM_SPEC_MASK;
- return (unsigned long)next->mm | ibpb;
+ return (unsigned long)next->mm | spec_bits;
}
-static void cond_ibpb(struct task_struct *next)
+static void cond_mitigation(struct task_struct *next)
{
+ unsigned long prev_mm, next_mm;
+
if (!next || !next->mm)
return;
+ next_mm = mm_mangle_tif_spec_bits(next);
+ prev_mm = this_cpu_read(cpu_tlbstate.last_user_mm_spec);
+
/*
+* Avoid user/user BTB poisoning by flushing the branch predictor
+* when switching between processes. This stops one process from
+* doing Spectre-v2 attacks on another.
+*
* Both, the conditional and the always IBPB mode use the mm
* pointer to avoid the IBPB when switching between tasks of the
* same process. Using the mm pointer instead of mm->context.ctx_id
@@ -339,8 +352,6 @@ static void cond_ibpb(struct task_struct *next)
* exposed data is not really interesting.
*/
if (static_branch_likely(_mm_cond_ibpb)) {
- unsigned long prev_mm, next_mm;
-
/*
* This is a bit more complex than the always mode because
* it has to handle two cases:
@@ -370,20 +381,14 @@ static void cond_ibpb(struct task_struct *next)
* Optimize this with reasonably small overhead for the
* above cases. Mangle the TIF_SPEC_IB bit into the mm
* pointer of the incoming task which is stored in
-* cpu_tlbstate.last_user_mm_ibpb for comparison.
-*/
- next_mm = mm_mangle_tif_spec_ib(next);
- prev_mm = this_cpu_read(cpu_tlbstate.last_user_mm_ibpb);
-
- /*
+* cpu_tlbstate.last_user_mm_spec for comparison.
+*
* Issue IBPB only if the mm's are different and one or
* both have the IBPB bit set.
*/
if (next_mm != prev_mm &&
(next_mm | prev_mm) & LAST_USER_MM_IBPB)
indirect_branch_prediction_barrier();
-
- this_cpu_write(cpu_tlbstate.last_user_mm_ibpb, next_mm);
}
if (static_branch_unlikely(_mm_always_ibpb)) {
@@ -392,11 +397,12 @@ static void cond_ibpb(struct task_struct *next)
* different context than the user space task which ran
* last on this CPU.
*/
- if (this_cpu_read(cpu_tlbstate.last_user_mm) != next->mm) {
+ if ((prev_mm & ~LAST_USER_MM_SPEC_MASK) !=
+
[PATCH v3 1/5] x86/mm: change l1d flush runtime prctl behaviour
Detection of task affinities at API opt-in time is not the best
approach, the approach is to kill the task if it runs on a
SMT enable core. This is better than not flushing the L1D cache
when the task switches from a non-SMT core to an SMT enabled core.
Signed-off-by: Balbir Singh
---
arch/x86/include/asm/processor.h | 2 ++
arch/x86/kernel/smpboot.c| 11 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 82a08b585818..60dbcdcb833f 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -136,6 +136,8 @@ struct cpuinfo_x86 {
u16 logical_die_id;
/* Index into per_cpu list: */
u16 cpu_index;
+ /* Is SMT active on this core? */
+ boolsmt_active;
u32 microcode;
/* Address space bits used by the cache internally */
u8 x86_cache_bits;
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index de776b2e6046..9a94934fae5f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -635,6 +635,9 @@ void set_cpu_sibling_map(int cpu)
threads = cpumask_weight(topology_sibling_cpumask(cpu));
if (threads > __max_smt_threads)
__max_smt_threads = threads;
+
+ for_each_cpu(i, topology_sibling_cpumask(cpu))
+ cpu_data(i).smt_active = threads > 1;
}
/* maps the cpu to the sched domain representing multi-core */
@@ -1548,10 +1551,16 @@ static void remove_siblinginfo(int cpu)
for_each_cpu(sibling, topology_die_cpumask(cpu))
cpumask_clear_cpu(cpu, topology_die_cpumask(sibling));
- for_each_cpu(sibling, topology_sibling_cpumask(cpu))
+
+ for_each_cpu(sibling, topology_sibling_cpumask(cpu)) {
cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling));
+ if (cpumask_weight(topology_sibling_cpumask(sibling)) == 1)
+ cpu_data(sibling).smt_active = false;
+ }
+
for_each_cpu(sibling, cpu_llc_shared_mask(cpu))
cpumask_clear_cpu(cpu, cpu_llc_shared_mask(sibling));
+
cpumask_clear(cpu_llc_shared_mask(cpu));
cpumask_clear(topology_sibling_cpumask(cpu));
cpumask_clear(topology_core_cpumask(cpu));
--
2.17.1
[PATCH v3 0/5] Next revision of the L1D flush patches
Implement a mechanism that allows tasks to conditionally flush their L1D cache (mitigation mechanism suggested in [2]). The previous posts of these patches were sent for inclusion (see [3]) and were not included due to the concern for the need for additional checks, those checks were: 1. Implement this mechanism only for CPUs affected by the L1TF bug 2. Disable the software fallback 3. Provide an override to disable this mechanism completely 4. Be SMT aware in the implementation The patches support a use case where the entire system is not in non SMT mode, but rather a few CPUs can have their SMT turned off and processes that want to opt-in are expected to run on non SMT cores. This gives the administrator complete control over setting up the mitigation for the issue. In addition, the administrator has a boot time override (l1d_flush_out=off) to turn of the mechanism completely. To implement these efficiently, a new per cpu view of whether the core is in SMT mode or not is implemented in patch 1. The code is refactored in patch 2 so that the existing code can allow for other speculation related checks when switching mm between tasks, this mechanism has not changed since the last post. The ability to flush L1D for tasks if the TIF_SPEC_L1D_FLUSH bit is set and the task has context switched out of a non SMT core is provided by patch 3. Hooks for the user space API, for this feature to be invoked via prctl are provided in patch 4, along with the checks described above (1, 2, and 3). Documentation updates are in patch 5, with updates on l1d_flush, the prctl changes and updates to the kernel-parameters (l1d_flush_out). The checks for opting into L1D flushing are: a. If the CPU is affected by L1TF b. Hardware L1D flush mechanism is available A task running on a core with SMT enabled and opting into this feature will receive a SIGBUS. References [1] https://software.intel.com/security-software-guidance/software-guidance/snoop-assisted-l1-data-sampling [2] https://software.intel.com/security-software-guidance/insights/deep-dive-snoop-assisted-l1-data-sampling [3] https://lkml.org/lkml/2020/6/2/1150 [4] https://lore.kernel.org/lkml/20200729001103.6450-1-sbl...@amazon.com/ [5] https://lore.kernel.org/lkml/20201117234934.25985-2-sbl...@amazon.com/ Changelog v3: - Implement the SIGBUS mechansim - Update and fix the documentation Balbir Singh (5): x86/mm: change l1d flush runtime prctl behaviour x86/mm: Refactor cond_ibpb() to support other use cases x86/mm: Optionally flush L1D on context switch prctl: Hook L1D flushing in via prctl Documentation: Add L1D flushing Documentation Documentation/admin-guide/hw-vuln/index.rst | 1 + .../admin-guide/hw-vuln/l1d_flush.rst | 69 .../admin-guide/kernel-parameters.txt | 17 +++ Documentation/userspace-api/spec_ctrl.rst | 8 ++ arch/Kconfig | 4 + arch/x86/Kconfig | 1 + arch/x86/include/asm/cacheflush.h | 8 ++ arch/x86/include/asm/processor.h | 2 + arch/x86/include/asm/thread_info.h| 9 +- arch/x86/include/asm/tlbflush.h | 2 +- arch/x86/kernel/cpu/bugs.c| 54 + arch/x86/kernel/smpboot.c | 11 +- arch/x86/mm/tlb.c | 105 ++ include/linux/sched.h | 10 ++ include/uapi/linux/prctl.h| 1 + 15 files changed, 274 insertions(+), 28 deletions(-) create mode 100644 Documentation/admin-guide/hw-vuln/l1d_flush.rst -- 2.17.1
[tip:x86/platform] BUILD SUCCESS caf371103ea17de58251714131b06682d86b0df8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/platform branch HEAD: caf371103ea17de58251714131b06682d86b0df8 x86/platform/uv: Update MAINTAINERS for uv_sysfs driver elapsed time: 762m configs tested: 142 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig h8300 h8s-sim_defconfig powerpc mpc834x_itx_defconfig sh rsk7203_defconfig arm lubbock_defconfig sparc sparc32_defconfig powerpc mpc837x_mds_defconfig arc axs101_defconfig mips pic32mzda_defconfig arm imx_v6_v7_defconfig powerpc64alldefconfig sh sh7724_generic_defconfig m68km5307c3_defconfig csky alldefconfig xtensa iss_defconfig sh defconfig armclps711x_defconfig mips ath25_defconfig powerpc mpc8315_rdb_defconfig arc allyesconfig powerpc mpc8313_rdb_defconfig powerpc mpc83xx_defconfig arm viper_defconfig s390defconfig sh ap325rxa_defconfig powerpc pasemi_defconfig mips bigsur_defconfig mipsomega2p_defconfig xtensa common_defconfig powerpc kilauea_defconfig arm corgi_defconfig shtitan_defconfig mips sb1250_swarm_defconfig arm moxart_defconfig sh alldefconfig powerpc mpc8272_ads_defconfig armdove_defconfig sh rts7751r2dplus_defconfig powerpc mpc836x_mds_defconfig powerpc mpc5200_defconfig powerpc chrp32_defconfig arm tct_hammer_defconfig powerpc rainier_defconfig m68kmvme147_defconfig mips tb0219_defconfig powerpc tqm8555_defconfig mipsmaltaup_xpa_defconfig mipsbcm47xx_defconfig c6x defconfig powerpc katmai_defconfig arm assabet_defconfig c6xevmc6474_defconfig mipsnlm_xlp_defconfig mips ip28_defconfig powerpc eiger_defconfig powerpc ppc44x_defconfig mips tb0287_defconfig nios2 10m50_defconfig mips db1xxx_defconfig sparc defconfig mipsgpr_defconfig arm alldefconfig powerpc mpc885_ads_defconfig sh microdev_defconfig arm tango4_defconfig arc axs103_defconfig mips decstation_defconfig archsdk_defconfig powerpc ppc40x_defconfig shdreamcast_defconfig arm spear13xx_defconfig umkunit_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig i386 allyesconfig sparcallyesconfig i386defconfig nios2 defconfig nds32 allnoconfig c6x allyesconfig mips
linux-next: build failure after merge of the dma-mapping tree
Hi all,
After merging the dma-mapping tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
In file included from include/linux/dma-direct.h:10,
from arch/powerpc/kernel/dma-iommu.c:9:
include/linux/dma-map-ops.h:328:41: error: expected identifier or '(' before
numeric constant
328 | #define arch_dma_map_page_direct(d, a) (0)
| ^
arch/powerpc/kernel/dma-iommu.c:16:6: note: in expansion of macro
'arch_dma_map_page_direct'
16 | bool arch_dma_map_page_direct(struct device *dev, phys_addr_t addr)
| ^~~~
include/linux/dma-map-ops.h:329:43: error: expected identifier or '(' before
numeric constant
329 | #define arch_dma_unmap_page_direct(d, a) (0)
| ^
arch/powerpc/kernel/dma-iommu.c:26:6: note: in expansion of macro
'arch_dma_unmap_page_direct'
26 | bool arch_dma_unmap_page_direct(struct device *dev, dma_addr_t
dma_handle)
| ^~
include/linux/dma-map-ops.h:330:42: error: expected identifier or '(' before
numeric constant
330 | #define arch_dma_map_sg_direct(d, s, n) (0)
| ^
arch/powerpc/kernel/dma-iommu.c:34:6: note: in expansion of macro
'arch_dma_map_sg_direct'
34 | bool arch_dma_map_sg_direct(struct device *dev, struct scatterlist *sg,
| ^~
include/linux/dma-map-ops.h:331:44: error: expected identifier or '(' before
numeric constant
331 | #define arch_dma_unmap_sg_direct(d, s, n) (0)
|^
arch/powerpc/kernel/dma-iommu.c:51:6: note: in expansion of macro
'arch_dma_unmap_sg_direct'
51 | bool arch_dma_unmap_sg_direct(struct device *dev, struct scatterlist
*sg,
| ^~~~
Caused by commit
4e52b96ac85c ("powerpc/dma: Fallback to dma_ops when persistent memory
present")
I have applied the following patch for today.
From: Stephen Rothwell
Date: Fri, 27 Nov 2020 17:49:28 +1100
Subject: [PATCH] powerpc/dma: fix for "powerpc/dma: Fallback to dma_ops when
persistent memory present"
Fixes: 4e52b96ac85c ("powerpc/dma: Fallback to dma_ops when persistent memory
present")
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/dma-iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index c724548ca295..6364311eb6e9 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -10,6 +10,8 @@
#include
#include
+#ifdef CONFIG_ARCH_HAS_DMA_MAP_DIRECT
+
#define can_map_direct(dev, addr) \
((dev)->bus_dma_limit >= phys_to_dma((dev), (addr)))
@@ -64,6 +66,7 @@ bool arch_dma_unmap_sg_direct(struct device *dev, struct
scatterlist *sg,
return true;
}
+#endif /* CONFIG_ARCH_HAS_DMA_MAP_DIRECT */
/*
* Generic iommu implementation
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpZ1Z2ni6Bxi.pgp
Description: OpenPGP digital signature
[PATCH] media: gp8psk: initialize stats at power control logic
As reported on:
https://lore.kernel.org/linux-media/20190627222020.45909-1-willemdebruijn.ker...@gmail.com/
if gp8psk_usb_in_op() returns an error, the status var is not
initialized. Yet, this var is used later on, in order to
identify:
- if the device was already started;
- if firmware has loaded;
- if the LNBf was powered on.
Using status = 0 seems to ensure that everything will be
properly powered up.
So, instead of the proposed solution, let's just set
status = 0.
Reported-by: syzbot
Reported-by: Willem de Bruijn
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb/gp8psk.c
b/drivers/media/usb/dvb-usb/gp8psk.c
index c07f46f5176e..b4f661bb5648 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -182,7 +182,7 @@ static int gp8psk_load_bcm4500fw(struct dvb_usb_device *d)
static int gp8psk_power_ctrl(struct dvb_usb_device *d, int onoff)
{
- u8 status, buf;
+ u8 status = 0, buf;
int gp_product_id = le16_to_cpu(d->udev->descriptor.idProduct);
if (onoff) {
--
2.28.0
Fair Pay - Guad - Correction for good word flow.
Analysing the arabic script written right to left "Al Ilah", we seem to get La Guad, in latin. Updated prayer translation. SINO is the only Guad. It should be a solid background for Fair Pay, and the needed step forward. https://www.youtube.com/watch?v=gQjHE0WnenA And really necessary step. Looking at "Linux" history it might actually seem it was not meant to be a success. But an abusers joke, where you are "just a nerd", and no success at all. "Even with all the computers in the world, you could not escape the evil agenda". I do not believe this to be true, and have corrected monotheism for this. Based on many years of research! Serenity, Ywe Cærlyn The Fair Pay Initiative. https://www.youtube.com/channel/UCqt17eaSO66UV4xvIYJvD4g
Re: [PATCH v3] crypto: ccree - rework cache parameters handling
On Sun, Nov 22, 2020 at 09:51:53AM +0200, Gilad Ben-Yossef wrote: > Rework the setting of DMA cache parameters, program more appropriate > values and explicitly set sharability domain. > > Signed-off-by: Gilad Ben-Yossef > --- > > Changes from previous versions: > - After discussion with Rob H., drop notion of setting the parameters > from device tree and just use good defaults for cached/non cached. > > drivers/crypto/ccree/cc_driver.c | 75 +--- > drivers/crypto/ccree/cc_driver.h | 6 +-- > drivers/crypto/ccree/cc_pm.c | 2 +- > 3 files changed, 63 insertions(+), 20 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: marvell/octeontx - Use dma_set_mask_and_coherent to simplify code
On Sat, Nov 21, 2020 at 08:49:16AM +0100, Christophe JAILLET wrote: > 'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by > an equivalent 'dma_set_mask_and_coherent()' which is much less verbose. > > Signed-off-by: Christophe JAILLET > --- > drivers/crypto/marvell/octeontx/otx_cptpf_main.c | 10 ++ > drivers/crypto/marvell/octeontx/otx_cptvf_main.c | 10 ++ > 2 files changed, 4 insertions(+), 16 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: cavium/zip - Use dma_set_mask_and_coherent to simplify code
On Sat, Nov 21, 2020 at 08:31:31AM +0100, Christophe JAILLET wrote: > 'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by > an equivalent 'dma_set_mask_and_coherent()' which is much less verbose. > > Signed-off-by: Christophe JAILLET > --- > drivers/crypto/cavium/zip/zip_main.c | 10 ++ > 1 file changed, 2 insertions(+), 8 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: cavium - Use dma_set_mask_and_coherent to simplify code
On Sat, Nov 21, 2020 at 08:56:47AM +0100, Christophe JAILLET wrote: > 'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by > an equivalent 'dma_set_mask_and_coherent()' which is much less verbose. > > Signed-off-by: Christophe JAILLET > --- > drivers/crypto/cavium/cpt/cptpf_main.c | 10 ++ > drivers/crypto/cavium/cpt/cptvf_main.c | 10 ++ > 2 files changed, 4 insertions(+), 16 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 075/141] crypto: ccree - Fix fall-through warnings for Clang
On Fri, Nov 20, 2020 at 12:34:56PM -0600, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > warnings by explicitly adding multiple break statements instead of > letting the code fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva > --- > drivers/crypto/ccree/cc_cipher.c | 3 +++ > 1 file changed, 3 insertions(+) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/4] crypto: hisilicon/trng - add HiSilicon TRNG driver support
On Fri, Nov 20, 2020 at 04:56:59PM +0800, Weili Qian wrote: > 1. Move HiSilicon TRNG driver form 'drivers/char/hw_random/' >to 'drivers/crypto/hisilicon/'. > 2. Add support for PRNG in Crypto subsystem. > > Weili Qian (4): > hwrng: hisi - remove HiSilicon TRNG driver > crypto: hisilicon/trng - add HiSilicon TRNG driver support > crypto: hisilicon/trng - add support for PRNG > MAINTAINERS: Move HiSilicon TRNG V2 driver > > MAINTAINERS| 2 +- > arch/arm64/configs/defconfig | 1 + > drivers/char/hw_random/Kconfig | 13 -- > drivers/char/hw_random/Makefile| 1 - > drivers/char/hw_random/hisi-trng-v2.c | 99 -- > drivers/crypto/hisilicon/Kconfig | 8 + > drivers/crypto/hisilicon/Makefile | 1 + > drivers/crypto/hisilicon/trng/Makefile | 2 + > drivers/crypto/hisilicon/trng/trng.c | 334 > + > 9 files changed, 347 insertions(+), 114 deletions(-) > delete mode 100644 drivers/char/hw_random/hisi-trng-v2.c > create mode 100644 drivers/crypto/hisilicon/trng/Makefile > create mode 100644 drivers/crypto/hisilicon/trng/trng.c All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RESEND] crypto: qat - fix excluded_middle.cocci warnings
On Thu, Nov 19, 2020 at 10:25:19PM +, Giovanni Cabiddu wrote:
>
> Condition !A || A && B is equivalent to !A || B.
>
> Generated by: scripts/coccinelle/misc/excluded_middle.cocci
>
> Fixes: b76f0ea01312 ("coccinelle: misc: add excluded_middle.cocci script")
> CC: Denis Efremov
> Reported-by: kernel test robot
> Signed-off-by: kernel test robot
> Signed-off-by: Julia Lawall
> Signed-off-by: Giovanni Cabiddu
> ---
> drivers/crypto/qat/qat_common/adf_dev_mgr.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [Patch v2 0/6] Enable Qualcomm Crypto Engine on sdm845
On Thu, Nov 19, 2020 at 10:52:27AM -0500, Thara Gopinath wrote: > Qualcomm crypto engine supports hardware accelerated algorithms for > encryption and authentication. Enable support for aes,des,3des encryption > algorithms and sha1,sha256, hmac(sha1),hmac(sha256) authentication > algorithms on sdm845.The patch series has been tested using the kernel > crypto testing module tcrypto.ko. > > v1->v2: > - Rebased to linux-next v5.10-rc4. > - Fixed subject line format in all patches as per Bjorn's feedback. > > Thara Gopinath (6): > dt-binding:clock: Add entry for crypto engine RPMH clock resource > clk:qcom:rpmh: Add CE clock on sdm845. > drivers:crypto:qce: Enable support for crypto engine on sdm845. > drivers:crypto:qce: Fix SHA result buffer corruption issues. > dts:qcom:sdm845: Add dt entries to support crypto engine. > devicetree:bindings:crypto: Extend qcom-qce binding to add support for > crypto engine version 5.4 > > .../devicetree/bindings/crypto/qcom-qce.txt | 4 ++- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 30 +++ > drivers/clk/qcom/clk-rpmh.c | 2 ++ > drivers/crypto/qce/core.c | 17 ++- > drivers/crypto/qce/sha.c | 2 +- > include/dt-bindings/clock/qcom,rpmh.h | 1 + > 6 files changed, 53 insertions(+), 3 deletions(-) Patches 3-4 applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v9 0/3] Add Novatek NT36xxx touchscreen driver
On Thu, 29 Oct 2020 at 06:32, wrote: > > From: AngeloGioacchino Del Regno > > This patch series adds support for the Novatek NT36xxx Series' In-Cell > touchscreen (integrated into the DriverIC). > > This patch series has been tested against the following devices: > - Sony Xperia 10(SDM630 Ganges Kirin) > - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) > Tested the patch series on Xiaomi Poco F1 (SDM845 Beryllium, Novatek NT36672A IC). For the whole series: Tested-by: Amit Pundir Regards, Amit Pundir > Changes in v2: > - Fixed sparse warnings from lkp kernel test robot > > Changes in v3 (as requested by Dmitry Torokhov): > - Using shorthand u16/u32 (sorry for the overlook!) > - Now using more input and touchscreen APIs > - Fixed useless workqueue involvements > - Removed useless locking > - Switched reads and writes to use regmap > - Moved header contents to nt36xxx.c > - Fixed reset gpio handling > - Other cleanups > - P.S.: Thanks, Dmitry! > > Changes in v4: > - Fixed regmap read length for CRC_ERR_FLAG final check > - Fixed YAML binding, as requested by Krzysztof Kozlowski > > Changes in v5: > - Replaced subsystem maintainer's name with .. mine, > usage of additionalProperties to unevaluatedProperties > and a typo fix for reset-gpios as per Rob Herring's review > - Changed compatible string as per Krzysztof K. request > - Renamed the novatek,nt36xxx.yaml file to just nt36xxx.yaml > in order to now reflect the driver name instead of the DT > compatible > - Fixed blank line at EOF > > Changes in v6: > - Removed include of_gpio.h, added mod_devicetable.h and > gpio/consumer.h > - Added kerneldoc to relevant functions/enum > - Used traditional patterns for error checking where possible > - Documented calls to usleep/msleep > - Using be16_to_cpu / get_unaligned_be16 where possible > - Added helper for CRC error check on retrieved buffer > - Decreased indentation in the CRC reboot recovery function > - Removed instances of error code sum > - Dropped all likely/unlikely optimization as per request > - Removed redundant reset_gpio checks > - Dropped of_match_ptr and ifdefs for CONFIG_OF > > Changes in v7: > - Fixed typo in nt36xxx.c > > Changes in v8: > - Fixed typo reset-gpio -> reset-gpios in dt-bindings > > Changes in v9: > - Includes are now sorted > - Used proposed sizeof variable instead of sizeof type > - Fixed a return value check for common pattern > - Added NULL check to devm_kasprintf call > - Returning ret on probe function to be consistent > > AngeloGioacchino Del Regno (3): > dt-bindings: Add vendor prefix for Novatek Microelectronics Corp. > Input: Add Novatek NT36xxx touchscreen driver > dt-bindings: touchscreen: Add binding for Novatek NT36xxx series > driver > > .../bindings/input/touchscreen/nt36xxx.yaml | 59 ++ > .../devicetree/bindings/vendor-prefixes.yaml | 2 + > drivers/input/touchscreen/Kconfig | 12 + > drivers/input/touchscreen/Makefile| 1 + > drivers/input/touchscreen/nt36xxx.c | 894 ++ > drivers/input/touchscreen/nt36xxx.h | 122 +++ > 6 files changed, 1090 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/touchscreen/nt36xxx.yaml > create mode 100644 drivers/input/touchscreen/nt36xxx.c > create mode 100644 drivers/input/touchscreen/nt36xxx.h > > -- > 2.28.0 >
Re: [PATCH v4 12/24] iommu/mediatek: Move hw_init into attach_device
On Thu, 2020-11-26 at 16:43 +, Robin Murphy wrote:
> On 2020-11-11 12:38, Yong Wu wrote:
> > In attach device, it will update the pagetable base address register.
> > Move the hw_init function also here. Then it only need call
> > pm_runtime_get/put one time here if m4u has power domain.
>
> Doesn't that mean you'll end up writing most of the registers twice
> every time? (first from mtk_iommu_resume(), then again from
> mtk_iommu_hw_init())
I have skipped the first resume from mtk_iommu_resume with the code in
[15/24]:
@@ -828,6 +848,9 @@ static int __maybe_unused
mtk_iommu_runtime_resume(struct device *dev)
+/* Avoid first resume to affect the default value of registers below.*/
+if (!m4u_dom)
+ return 0;
> It might be neater to have mtk_iommu_hw_init() simply populate the
> mtk_iommu_suspend_reg data with the initial values at probe time and
> manually call mtk_iommu_resume() if the hardware is already powered up
> at that point. Or maybe just don't bother saving those registers on
Yes. All the power-domains are enabled in lk when bootup.
Actually I have plan to remove the pm_runtime_get in this attach_device
in the later patchset.
This is for fixing a issue that the screen is turned off when bootup.
In android project. we always show boot image. If iommu call
pm_runtime_get/put here, the display power-domain will be turned off
here given that iommu always probe before display drivers and iommu's
power-domain always is display's power-domain.
Even I plan to move the device's pm_runtime_enable into this
attach_device in the case all the drivers(iommu and display...) build as
modules. it is for skipping turn off display's power-domain in
genpd_power_off_unused.
This is only a plan, I'm not sure if power-domain could fix it like[1].
In this patchset, I'd like to keep current status.
[1]
https://patchwork.kernel.org/project/linux-clk/patch/20190630150230.7878-3-robdcl...@gmail.com/
> suspend and put the initialisation directly in the resume path.
>
> Robin.
>
> > Signed-off-by: Yong Wu
> > ---
> > drivers/iommu/mtk_iommu.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 55f9b329e637..cfdf5ce696fd 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -125,6 +125,8 @@ struct mtk_iommu_domain {
> >
> > static const struct iommu_ops mtk_iommu_ops;
> >
> > +static int mtk_iommu_hw_init(const struct mtk_iommu_data *data);
> > +
> > /*
> >* In M4U 4GB mode, the physical address is remapped as below:
> >*
> > @@ -380,12 +382,16 @@ static int mtk_iommu_attach_device(struct
> > iommu_domain *domain,
> > {
> > struct mtk_iommu_data *data = dev_iommu_priv_get(dev);
> > struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> > + int ret;
> >
> > if (!data)
> > return -ENODEV;
> >
> > /* Update the pgtable base address register of the M4U HW */
> > if (!data->m4u_dom) {
> > + ret = mtk_iommu_hw_init(data);
> > + if (ret)
> > + return ret;
> > data->m4u_dom = dom;
> > writel(dom->cfg.arm_v7s_cfg.ttbr & MMU_PT_ADDR_MASK,
> >data->base + REG_MMU_PT_BASE_ADDR);
> > @@ -729,10 +735,6 @@ static int mtk_iommu_probe(struct platform_device
> > *pdev)
> >
> > platform_set_drvdata(pdev, data);
> >
> > - ret = mtk_iommu_hw_init(data);
> > - if (ret)
> > - return ret;
> > -
> > ret = iommu_device_sysfs_add(>iommu, dev, NULL,
> > "mtk-iommu.%pa", );
> > if (ret)
> >
Re: [PATCH v4 09/24] iommu/io-pgtable-arm-v7s: Clear LVL_SHIFT/BITS macro instead of the formula
On Thu, 2020-11-26 at 16:03 +, Robin Murphy wrote: > On 2020-11-11 12:38, Yong Wu wrote: > > The current _ARM_V7S_LVL_BITS/ARM_V7S_LVL_SHIFT use a formula to calculate > > the corresponding value for level1 and level2 to pretend the code sane. > > Actually their level1 and level2 values are different from each other. > > This patch only clear the two macro. No functional change. > > Grammar nit: to "clear" the macro sounds like you're making it empty or > removing it entirely; I think you mean to say "clarify" here. English is > the worst language sometimes... :) Thanks for the review. Feel free to tell me if some words is not fit:) I will use "clarify" in the title. > > Reviewed-by: Robin Murphy > > > Suggested-by: Robin Murphy > > Signed-off-by: Yong Wu > > --- > > drivers/iommu/io-pgtable-arm-v7s.c | 8 +++- > > 1 file changed, 3 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/iommu/io-pgtable-arm-v7s.c > > b/drivers/iommu/io-pgtable-arm-v7s.c > > index 4d0aa079470f..58cc201c10a3 100644 > > --- a/drivers/iommu/io-pgtable-arm-v7s.c > > +++ b/drivers/iommu/io-pgtable-arm-v7s.c > > @@ -44,13 +44,11 @@ > > > > /* > >* We have 32 bits total; 12 bits resolved at level 1, 8 bits at level 2, > > - * and 12 bits in a page. With some carefully-chosen coefficients we can > > - * hide the ugly inconsistencies behind these macros and at least let the > > - * rest of the code pretend to be somewhat sane. > > + * and 12 bits in a page. > >*/ > > #define ARM_V7S_ADDR_BITS 32 > > -#define _ARM_V7S_LVL_BITS(lvl) (16 - (lvl) * 4) > > -#define ARM_V7S_LVL_SHIFT(lvl) (ARM_V7S_ADDR_BITS - (4 + 8 * > > (lvl))) > > +#define _ARM_V7S_LVL_BITS(lvl) ((lvl) == 1 ? 12 : 8) > > +#define ARM_V7S_LVL_SHIFT(lvl) ((lvl) == 1 ? 20 : 12) > > #define ARM_V7S_TABLE_SHIFT 10 > > > > #define ARM_V7S_PTES_PER_LVL(lvl) (1 << _ARM_V7S_LVL_BITS(lvl)) > >
Re: [PATCH v4 17/24] iommu/mediatek: Add single domain
On Thu, 2020-11-26 at 17:11 +, Robin Murphy wrote:
> On 2020-11-11 12:38, Yong Wu wrote:
> > Defaultly the iova range is 0-4G. here we add a single-domain(0-4G)
> > for the previous SoC. this also is a preparing patch for supporting
> > multi-domains.
> >
> > Signed-off-by: Yong Wu
> > ---
> > drivers/iommu/mtk_iommu.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index bf3f4e0f4748..a7727a3899d1 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -161,6 +161,10 @@ struct mtk_iommu_iova_region {
> > unsigned long long size;
> > };
> >
> > +static const struct mtk_iommu_iova_region single_domain[] = {
> > + {.iova_base = 0,.size = SZ_4G},
> > +};
>
> Hang on, given how the previous patch works, surely this means you're
> now going to *reserve* the entire address space? That doesn't seem
> right... :/
Could you help share more? in which case it is not right?
In the code:
domain->geometry.aperture_end = iova_base + size - 1.
this is same with DMA_BIT_MASK(32). It looks don't change anything.
>
> Robin.
>
> > +
> > /*
> >* There may be 1 or 2 M4U HWs, But we always expect they are in the same
> > domain
> >* for the performance.
> > @@ -922,6 +926,8 @@ static const struct mtk_iommu_plat_data mt2712_data = {
> > .m4u_plat = M4U_MT2712,
> > .flags= HAS_4GB_MODE | HAS_BCLK | HAS_VLD_PA_RNG,
> > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > + .iova_region = single_domain,
> > + .iova_region_nr = ARRAY_SIZE(single_domain),
> > .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}, {6}, {7}},
> > };
> >
> > @@ -929,6 +935,8 @@ static const struct mtk_iommu_plat_data mt6779_data = {
> > .m4u_plat = M4U_MT6779,
> > .flags = HAS_SUB_COMM | OUT_ORDER_WR_EN | WR_THROT_EN,
> > .inv_sel_reg = REG_MMU_INV_SEL_GEN2,
> > + .iova_region = single_domain,
> > + .iova_region_nr = ARRAY_SIZE(single_domain),
> > .larbid_remap = {{0}, {1}, {2}, {3}, {5}, {7, 8}, {10}, {9}},
> > };
> >
> > @@ -944,6 +952,8 @@ static const struct mtk_iommu_plat_data mt8173_data = {
> > .flags= HAS_4GB_MODE | HAS_BCLK | RESET_AXI |
> > HAS_LEGACY_IVRP_PADDR,
> > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > + .iova_region = single_domain,
> > + .iova_region_nr = ARRAY_SIZE(single_domain),
> > .larbid_remap = {{0}, {1}, {2}, {3}, {4}, {5}}, /* Linear mapping. */
> > };
> >
> > @@ -951,6 +961,8 @@ static const struct mtk_iommu_plat_data mt8183_data = {
> > .m4u_plat = M4U_MT8183,
> > .flags= RESET_AXI,
> > .inv_sel_reg = REG_MMU_INV_SEL_GEN1,
> > + .iova_region = single_domain,
> > + .iova_region_nr = ARRAY_SIZE(single_domain),
> > .larbid_remap = {{0}, {4}, {5}, {6}, {7}, {2}, {3}, {1}},
> > };
> >
> >
Re: [PATCH] iommu: Improve the performance for direct_mapping
On Thu, 2020-11-26 at 15:19 +, Robin Murphy wrote:
> On 2020-11-20 09:06, Yong Wu wrote:
> > Currently direct_mapping always use the smallest pgsize which is SZ_4K
> > normally to mapping. This is unnecessary. we could gather the size, and
> > call iommu_map then, iommu_map could decide how to map better with the
> > just right pgsize.
> >
> > From the original comment, we should take care overlap, otherwise,
> > iommu_map may return -EEXIST. In this overlap case, we should map the
> > previous region before overlap firstly. then map the left part.
> >
> > Each a iommu device will call this direct_mapping when its iommu
> > initialize, This patch is effective to improve the boot/initialization
> > time especially while it only needs level 1 mapping.
> >
> > Signed-off-by: Anan Sun
> > Signed-off-by: Yong Wu
> > ---
> > drivers/iommu/iommu.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index df87c8e825f7..854a8fcb928d 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -737,6 +737,7 @@ static int iommu_create_device_direct_mappings(struct
> > iommu_group *group,
> > /* We need to consider overlapping regions for different devices */
> > list_for_each_entry(entry, , list) {
> > dma_addr_t start, end, addr;
> > + size_t unmapped_sz = 0;
> >
> > if (domain->ops->apply_resv_region)
> > domain->ops->apply_resv_region(dev, domain, entry);
> > @@ -752,10 +753,25 @@ static int iommu_create_device_direct_mappings(struct
> > iommu_group *group,
> > phys_addr_t phys_addr;
> >
> > phys_addr = iommu_iova_to_phys(domain, addr);
> > - if (phys_addr)
> > + if (phys_addr == 0) {
> > + unmapped_sz += pg_size; /* Gather the size. */
> > continue;
> > + }
>
> I guess the reason we need to validate every page is because they may
> already have been legitimately mapped if someone else's reserved region
> overlaps - is it worth explicitly validating that, i.e. bail out if
> something's gone wrong enough that phys_addr != addr?
I'm not sure the history about why to validate every page. this
direct_mapping is called very early, normally after alloc_default_domain
and _attach_device. the "phys_addr != addr" looks impossible.
If there is a normal flow that may cause "phys_addr != addr", then
something go wrong, Could we give a warning like adding a
WARN_ON_ONCE(phys_addr != addr)? and it should be in a another patch.
>
> Other than the naming issue (I agree that map_size is a far, far better
> choice), I don't have any strong opinions about the rest of the
> implementation - I've written enough variations of this pattern to know
> that there's just no "nice" way to do it in C; all you can do is shuffle
> the clunkiness around :)
:). I will send a v2.
Thanks.
>
> Robin.
>
> >
> > - ret = iommu_map(domain, addr, addr, pg_size,
> > entry->prot);
> > + if (unmapped_sz) {
> > + /* Map the region before the overlap. */
> > + ret = iommu_map(domain, start, start,
> > + unmapped_sz, entry->prot);
> > + if (ret)
> > + goto out;
> > + start += unmapped_sz;
> > + unmapped_sz = 0;
> > + }
> > + start += pg_size;
> > + }
> > + if (unmapped_sz) {
> > + ret = iommu_map(domain, start, start, unmapped_sz,
> > + entry->prot);
> > if (ret)
> > goto out;
> > }
> >
>
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH] soundwire: master: use pm_runtime_set_active() on add
On 26-11-20, 09:52, Vinod Koul wrote: > > > > @@ -154,7 +163,12 @@ int sdw_master_device_add(struct sdw_bus *bus, > > > struct device *parent, > > > > bus->dev = >dev; > > > > bus->md = md; > > > > > > > > + pm_runtime_set_autosuspend_delay(>md->dev, > > > SDW_MASTER_SUSPEND_DELAY_MS); > > > > + pm_runtime_use_autosuspend(>md->dev); > > > > + pm_runtime_mark_last_busy(>md->dev); > > > > + pm_runtime_set_active(>md->dev); > > > > pm_runtime_enable(>md->dev); > > > > + pm_runtime_idle(>md->dev); > > > > > > I understand that this needs to be done somewhere but is the core the > > > right > > > place. In intel case it maybe a dummy device but other controllers are > > > real > > > devices and may not support pm. > > > > > > I think better idea would be to do this in respective driver.. that way it > > > would be an opt-in for device supporting pm. > > > > Should it be put in the same place as pm_runtime_enable? > > IMHO, pm_runtime_enable is in the core already and it seems to be harmless > > for devices which don't support pm. And pm can still be optional on md's > > parent device. > > For intel case yes, but world is not only intel, there are md which do > not have a parent like sof. they are real sdw controller devices Sorry I confused md with real master device ;-) I guess this patch should be okay then.. As the real parent will control. Thanks -- ~Vinod
Re: [PATCH v2] acpi: Fix use-after-free in acpi_ipmi.c
Hi,
On 11/26/2020 10:22 PM, Rafael J. Wysocki wrote:
On Thu, Nov 26, 2020 at 2:26 AM Youling Tang wrote:
kfree() has been called inside put_device so anther kfree would cause a
use-after-free bug.
Signed-off-by: Youling Tang
---
drivers/acpi/acpi_ipmi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c
index 9d6c0fc..18edf8b 100644
--- a/drivers/acpi/acpi_ipmi.c
+++ b/drivers/acpi/acpi_ipmi.c
@@ -142,7 +142,6 @@ static void ipmi_dev_release(struct acpi_ipmi_device
*ipmi_device)
{
ipmi_destroy_user(ipmi_device->user_interface);
put_device(ipmi_device->dev);
Does putting ipmi_device->dev (which is a different object than
ipmi_device itself) really cause ipmi_device to be freed
automatically? If not, the change below will introduce a memory leak.
ipmi_device will be free so that there is no memory leak.
Similar to the following:
https://lore.kernel.org/patchwork/patch/1342136/
Thanks,
Youling.
- kfree(ipmi_device);
}
static void ipmi_dev_release_kref(struct kref *kref)
--
Re: [PATCH] x86/PCI: Convert force_disable_hpet() to standard quirk
Hi Thomas,
On Fri, Nov 27, 2020 at 12:27:34AM +0100, Thomas Gleixner wrote:
> Feng,
>
> On Thu, Nov 26 2020 at 09:24, Feng Tang wrote:
> > On Wed, Nov 25, 2020 at 01:46:23PM +0100, Thomas Gleixner wrote:
> >> Now the more interesting question is why this needs to be a PCI quirk in
> >> the first place. Can't we just disable the HPET based on family/model
> >> quirks?
> >>
> >> e0748539e3d5 ("x86/intel: Disable HPET on Intel Ice Lake platforms")
> >> f8edbde885bb ("x86/intel: Disable HPET on Intel Coffee Lake H platforms")
> >> fc5db58539b4 ("x86/quirks: Disable HPET on Intel Coffe Lake platforms")
> >> 62187910b0fc ("x86/intel: Add quirk to disable HPET for the Baytrail
> >> platform")
>
> > I added this commit, and I can explain some for Baytrail. There was
> > some discussion about the way to disable it:
> > https://lore.kernel.org/lkml/20140328073718.GA12762@feng-snb/t/
> >
> > It uses PCI ID early quirk in the hope that later Baytrail stepping
> > doesn't have the problem. And later on, there was official document
> > (section 18.10.1.3
> > http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-1.pdf)
> > stating Baytrail's HPET halts in deep idle. So I think your way of
> > using CPUID to disable Baytrail HPET makes more sense.
>
> Correct.
>
> >> I might be missing something here, but in general on anything modern
> >> HPET is mostly useless.
> >
> > IIUC, nowdays HPET's main use is as a clocksource watchdog monitor.
>
> Plus for the TSC refined calibration, where it is really better than
> anything else we have _if_ it is functional.
>
> > And in one debug case, we found it still useful. The debug platform has
> > early serial console which prints many messages in early boot phase,
> > when the HPET is disabled, the software 'jiffies' clocksource will
> > be used as the monitor. Early printk will disable interrupt will
> > printing message, and this could be quite long for a slow 115200
> > device, and cause the periodic HW timer interrupt get missed, and
> > make the 'jiffies' clocksource not accurate, which will in turn
> > judge the TSC clocksrouce inaccurate, and disablt it. (Adding Rui,
> > Len for more details)
>
> Yes, that can happen. But OTOH, we should start to think about the
> requirements for using the TSC watchdog.
>
> I'm inclined to lift that requirement when the CPU has:
>
> 1) X86_FEATURE_CONSTANT_TSC
> 2) X86_FEATURE_NONSTOP_TSC
> 3) X86_FEATURE_NONSTOP_TSC_S3
IIUC, this feature exists for several generations of Atom platforms,
and it is always coupled with 1) and 2), so it could be skipped for
the checking.
> 4) X86_FEATURE_TSC_ADJUST
>
> 5) At max. 4 sockets
>
> After two decades of horrors we're finally at a point where TSC seems to
> be halfways reliable and less abused by BIOS tinkerers. TSC_ADJUST was
> really key as we can now detect even small modifications reliably and
> the important point is that we can cure them as well (not pretty but
> better than all other options).
>
> The only nasty one in the list above is #5 because AFAIK there is still
> no architecural guarantee for TSCs being synchronized on machines with
> more than 4 sockets. I might be wrong, but then nobody told me.
>
> The only reason I hate to disable HPET upfront at least during boot is
> that HPET is the best mechanism for the refined TSC calibration. PMTIMER
> sucks because it's slow and wraps around pretty quick.
>
> So we could do the following even on platforms where HPET stops in some
> magic PC? state:
>
> - Register it during early boot as clocksource
>
> - Prevent the enablement as clockevent and the chardev hpet timer muck
>
> - Prevent the magic PC? state up to the point where the refined
> TSC calibration is finished.
>
> - Unregister it once the TSC has taken over as system clocksource and
> enable the magic PC? state in which HPET gets disfunctional.
This looks reasonable to me.
I have thought about lowering the hpet rating to lower than PMTIMER, so it
still contributes in early boot phase, and fades out after PMTIMER is
initialised.
Thanks,
Feng
> Hmm?
>
> Thanks,
>
> tglx
>
>
RE: [PATCH] can: m_can: add support for bosch mcan version 3.3.0
> From: Oliver Hartkopp > Subject: Re: [PATCH] can: m_can: add support for bosch mcan version 3.3.0 > > > > On 26.11.20 11:48, Marc Kleine-Budde wrote: > > On 11/26/20 5:51 AM, Pankaj Sharma wrote: > >> Add support for mcan bit timing and control mode according to bosch > >> mcan IP version 3.3.0 The mcan version read from the Core Release > >> field of CREL register would be 33. Accordingly the properties are to > >> be set for mcan v3.3.0 > > > > BTW: do you have the v3.2 and v3.1 datasheets? > > Unfortunately Bosch does not give access to older documents, so I tried to > concentrate all my downloaded versions of public available information here: > > https://protect2.fireeye.com/v1/url?k=6afc7639-35674f23-6afdfd76- > 000babff24ad-be473a015905c7ca=1=8d02d5be-2511-407d-bfd1- > 1d9135e21b7c=https%3A%2F%2Fgithub.com%2Fhartkopp%2FM_CAN-User- > Manual-History Thanks Oliver for sharing the link. @Marc: I have used the documents from the link provided by Oliver. Regards Pankaj Sharma > > PR's with updates are welcome ;-) > > Best, > Oliver > > ps. @Bosch Semiconductors - Read the README there! I would like to remove > my own collection. > > > > > Marc > > > >> Signed-off-by: Pankaj Sharma > >> --- > >> Depends on: > >> https://protect2.fireeye.com/v1/url?k=6c628f8e-33f9b694-6c6304c1-000b > >> abff24ad-a2e76f208a6b1470=1=8d02d5be-2511-407d-bfd1- > 1d9135e21b7c& > >> u=https%3A%2F%2Fmarc.info%2F%3Fl%3Dlinux- > can%26m%3D160624495218700%26 > >> w%3D2 > >> > >> drivers/net/can/m_can/m_can.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/drivers/net/can/m_can/m_can.c > >> b/drivers/net/can/m_can/m_can.c index 86bbbfa..7652175 100644 > >> --- a/drivers/net/can/m_can/m_can.c > >> +++ b/drivers/net/can/m_can/m_can.c > >> @@ -1385,6 +1385,8 @@ static int m_can_dev_setup(struct m_can_classdev > *m_can_dev) > >> > _can_data_bittiming_const_31X; > >>break; > >>case 32: > >> + case 33: > >> + /* Support both MCAN version v3.2.x and v3.3.0 */ > >>m_can_dev->can.bittiming_const = m_can_dev->bit_timing ? > >>m_can_dev->bit_timing : > _can_bittiming_const_31X; > >> > >> > > > >
REPLY ME URGENTLY
Greeting Please forgive me for stressing you with my predicaments and I sorry to approach you through this media it is because it serves the fastest means of communication. I came across your E-mail from my personal search and I decided to contact you believing you will be honest to fulfill my final wish before I die. I am Mrs. Elizabeth Edward, 63 years, from USA, I am childless and I am suffering from a pro-long critical cancer, my doctors confirmed I may not live beyond two months from now as my ill health has defiled all forms of medical treatment. Since my days are numbered, I’ve decided willingly to fulfill my long-time promise to donate you the sum ($5.000.000.00) million dollars I inherited from my late husband Mr. Edward Herbart, foreign bank account over years. I need a very honest person who can assist in transfer of this money to his or her account and use the funds for charities work of God while you use 50% for yourself. I want you to know there are no risk involved, it is 100% hitch free & safe. If you will be interesting to assist in getting this fund into your account for charity project to fulfill my promise before I die please let me know immediately. I will appreciate your utmost confidentiality as I wait for your reply. Best Regards Mrs. Elizabeth Edward
[PATCH v3] drivers/perf: Add support for ARMv8.3-SPE
Armv8.3 extends the SPE by adding:
- Alignment field in the Events packet, and filtering on this event
using PMSEVFR_EL1.
- Support for the Scalable Vector Extension (SVE).
The main additions for SVE are:
- Recording the vector length for SVE operations in the Operation Type
packet. It is not possible to filter on vector length.
- Incomplete predicate and empty predicate fields in the Events packet,
and filtering on these events using PMSEVFR_EL1.
Update the check of pmsevfr for empty/partial predicated SVE and
alignment event in SPE driver. For adaption by the version of SPE,
expose 'pmsver' as cap attribute to userspace.
Signed-off-by: Wei Li
---
v2 -> v3:
- Make the definition of 'pmsevfr_res0' progressive and easy to check.
(Suggested by Will.)
---
v1 -> v2:
- Rename 'pmuver' to 'pmsver', change it's type to 'u16' from 'int'.
(Suggested by Will and Leo.)
- Expose 'pmsver' as cap attribute through sysfs, instead of printing.
(Suggested by Will.)
---
arch/arm64/include/asm/sysreg.h | 9 -
drivers/perf/arm_spe_pmu.c | 21 +++--
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index d52c1b3ce589..57e5aee6f7e6 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -287,7 +287,11 @@
#define SYS_PMSFCR_EL1_ST_SHIFT18
#define SYS_PMSEVFR_EL1sys_reg(3, 0, 9, 9, 5)
-#define SYS_PMSEVFR_EL1_RES0 0x00ff0f55UL
+#define SYS_PMSEVFR_EL1_RES0_8_2 \
+ (GENMASK_ULL(47, 32) | GENMASK_ULL(23, 16) | GENMASK_ULL(11, 8) |\
+BIT_ULL(6) | BIT_ULL(4) | BIT_ULL(2) | BIT_ULL(0))
+#define SYS_PMSEVFR_EL1_RES0_8_3 \
+ (SYS_PMSEVFR_EL1_RES0_8_2 & ~(BIT_ULL(18) | BIT_ULL(17) | BIT_ULL(11)))
#define SYS_PMSLATFR_EL1 sys_reg(3, 0, 9, 9, 6)
#define SYS_PMSLATFR_EL1_MINLAT_SHIFT 0
@@ -829,6 +833,9 @@
#define ID_AA64DFR0_PMUVER_8_5 0x6
#define ID_AA64DFR0_PMUVER_IMP_DEF 0xf
+#define ID_AA64DFR0_PMSVER_8_2 0x1
+#define ID_AA64DFR0_PMSVER_8_3 0x2
+
#define ID_DFR0_PERFMON_SHIFT 24
#define ID_DFR0_PERFMON_8_10x4
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index cc00915ad6d1..515c51271d7f 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -54,7 +54,7 @@ struct arm_spe_pmu {
struct hlist_node hotplug_node;
int irq; /* PPI */
-
+ u16 pmsver;
u16 min_period;
u16 counter_sz;
@@ -93,6 +93,7 @@ enum arm_spe_pmu_capabilities {
SPE_PMU_CAP_FEAT_MAX,
SPE_PMU_CAP_CNT_SZ = SPE_PMU_CAP_FEAT_MAX,
SPE_PMU_CAP_MIN_IVAL,
+ SPE_PMU_CAP_PMSVER,
};
static int arm_spe_pmu_feat_caps[SPE_PMU_CAP_FEAT_MAX] = {
@@ -110,6 +111,8 @@ static u32 arm_spe_pmu_cap_get(struct arm_spe_pmu *spe_pmu,
int cap)
return spe_pmu->counter_sz;
case SPE_PMU_CAP_MIN_IVAL:
return spe_pmu->min_period;
+ case SPE_PMU_CAP_PMSVER:
+ return spe_pmu->pmsver;
default:
WARN(1, "unknown cap %d\n", cap);
}
@@ -143,6 +146,7 @@ static struct attribute *arm_spe_pmu_cap_attr[] = {
SPE_CAP_EXT_ATTR_ENTRY(ernd, SPE_PMU_CAP_ERND),
SPE_CAP_EXT_ATTR_ENTRY(count_size, SPE_PMU_CAP_CNT_SZ),
SPE_CAP_EXT_ATTR_ENTRY(min_interval, SPE_PMU_CAP_MIN_IVAL),
+ SPE_CAP_EXT_ATTR_ENTRY(pmsver, SPE_PMU_CAP_PMSVER),
NULL,
};
@@ -655,6 +659,18 @@ static irqreturn_t arm_spe_pmu_irq_handler(int irq, void
*dev)
return IRQ_HANDLED;
}
+static u64 arm_spe_pmsevfr_res0(u16 pmsver)
+{
+ switch (pmsver) {
+ case ID_AA64DFR0_PMSVER_8_2:
+ return SYS_PMSEVFR_EL1_RES0_8_2;
+ case ID_AA64DFR0_PMSVER_8_3:
+ return SYS_PMSEVFR_EL1_RES0_8_3;
+ default:
+ return -1;
+ }
+}
+
/* Perf callbacks */
static int arm_spe_pmu_event_init(struct perf_event *event)
{
@@ -670,7 +686,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
!cpumask_test_cpu(event->cpu, _pmu->supported_cpus))
return -ENOENT;
- if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0)
+ if (arm_spe_event_to_pmsevfr(event) &
arm_spe_pmsevfr_res0(spe_pmu->pmsver))
return -EOPNOTSUPP;
if (attr->exclude_idle)
@@ -937,6 +953,7 @@ static void __arm_spe_pmu_dev_probe(void *info)
fld, smp_processor_id());
return;
}
+ spe_pmu->pmsver = (u16)fld;
/* Read PMBIDR first to determine whether or not we have access */
reg = read_sysreg_s(SYS_PMBIDR_EL1);
--
2.17.1
Re: [PATCH v2] phy: mediatek: Make PHY_MTK_{XSPHY,TPHY} depend on HAS_IOMEM and OF_ADDRESS to fix build errors
On Wed, 2020-11-25 at 15:37 +0800, Tiezhu Yang wrote: > devm_ioremap_resource() will be not built in lib/devres.c if > CONFIG_HAS_IOMEM is not set, of_address_to_resource() will be > not built in drivers/of/address.c if CONFIG_OF_ADDRESS is not > set, and then there exists two build errors about undefined > reference to "devm_ioremap_resource" and "of_address_to_resource" > in phy-mtk-xsphy.c under COMPILE_TEST and CONFIG_PHY_MTK_XSPHY, > make PHY_MTK_XSPHY depend on HAS_IOMEM and OF_ADDRESS to fix it. > > The above issue is reported by kernel test robot , > through the discussion in the v1 patch, as Chunfeng said we need > also do this for config PHY_MTK_TPHY: > > drivers/phy/mediatek/phy-mtk-tphy.c:1157: retval = > of_address_to_resource(child_np, 0, ); > drivers/phy/mediatek/phy-mtk-tphy.c:1123: tphy->sif_base = > devm_ioremap_resource(dev, sif_res); > drivers/phy/mediatek/phy-mtk-tphy.c:1164: instance->port_base = > devm_ioremap_resource(>dev, ); > > Reported-by: kernel test robot > Signed-off-by: Tiezhu Yang > Acked-by: Randy Dunlap > --- The changes in v2 should be described after '---' Except that, it looks good to me, Acked-by: Chunfeng Yun Thanks a lot > drivers/phy/mediatek/Kconfig | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig > index 50c5e93..f44800b 100644 > --- a/drivers/phy/mediatek/Kconfig > +++ b/drivers/phy/mediatek/Kconfig > @@ -5,7 +5,8 @@ > config PHY_MTK_TPHY > tristate "MediaTek T-PHY Driver" > depends on ARCH_MEDIATEK || COMPILE_TEST > - depends on OF > + depends on OF && OF_ADDRESS > + depends on HAS_IOMEM > select GENERIC_PHY > help > Say 'Y' here to add support for MediaTek T-PHY driver, > @@ -29,7 +30,8 @@ config PHY_MTK_UFS > config PHY_MTK_XSPHY > tristate "MediaTek XS-PHY Driver" > depends on ARCH_MEDIATEK || COMPILE_TEST > - depends on OF > + depends on OF && OF_ADDRESS > + depends on HAS_IOMEM > select GENERIC_PHY > help > Enable this to support the SuperSpeedPlus XS-PHY transceiver for
Re: [PATCH v3 6/7] crypto: sun4i-ss: enabled stats via debugfs
On Mon, Nov 16, 2020 at 01:53:44PM +, Corentin Labbe wrote:
>
> +#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_DEBUG
> + /* Ignore error of debugfs */
> + ss->dbgfs_dir = debugfs_create_dir("sun4i-ss", NULL);
> + ss->dbgfs_stats = debugfs_create_file("stats", 0444, ss->dbgfs_dir, ss,
> + _ss_debugfs_fops);
> +#endif
Since you didn't use ifdefs in the struct, there is no need to
use ifdefs here either.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] mm: memcg/slab: fix obj_cgroup_charge() return value handling
On Thu, Nov 26, 2020 at 8:14 PM Roman Gushchin wrote:
>
> Commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches
> for all allocations") introduced a regression into the handling of the
> obj_cgroup_charge() return value. If a non-zero value is returned
> (indicating of exceeding one of memory.max limits), the allocation
> should fail, instead of falling back to non-accounted mode.
>
> To make the code more readable, move memcg_slab_pre_alloc_hook()
> and memcg_slab_post_alloc_hook() calling conditions into bodies
> of these hooks.
>
> Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all
> allocations")
> Signed-off-by: Roman Gushchin
> Cc: sta...@vger.kernel.org
> ---
> mm/slab.h | 40
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/mm/slab.h b/mm/slab.h
> index 59aeb0d9f11b..5dc89d8fb05e 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -257,22 +257,32 @@ static inline size_t obj_full_size(struct kmem_cache *s)
> return s->size + sizeof(struct obj_cgroup *);
> }
>
> -static inline struct obj_cgroup *memcg_slab_pre_alloc_hook(struct kmem_cache
> *s,
> - size_t objects,
> - gfp_t flags)
> +/*
> + * Returns true if the allocation should fail.
IMO returning false if the allocation should fail makes this more
clear. Otherwise the patch looks good to me.
> + */
> +static inline bool memcg_slab_pre_alloc_hook(struct kmem_cache *s,
> +struct obj_cgroup **objcgp,
> +size_t objects, gfp_t flags)
> {
> struct obj_cgroup *objcg;
>
> + if (!memcg_kmem_enabled())
> + return false;
> +
> + if (!(flags & __GFP_ACCOUNT) && !(s->flags & SLAB_ACCOUNT))
> + return false;
> +
> objcg = get_obj_cgroup_from_current();
> if (!objcg)
> - return NULL;
> + return false;
>
> if (obj_cgroup_charge(objcg, flags, objects * obj_full_size(s))) {
> obj_cgroup_put(objcg);
> - return NULL;
> + return true;
> }
>
> - return objcg;
> + *objcgp = objcg;
> + return false;
> }
Re: [RFC PATCH v0 03/19] x86/insn: Add an insn_decode() API
On Thu, 26 Nov 2020 18:50:11 +0100 Borislav Petkov wrote: > On Thu, Nov 26, 2020 at 10:37:09AM +0900, Masami Hiramatsu wrote: > > BTW, the instruction validation depends on who needs it, because to > > check the all invalid ops, we need more information in the > > x86-opcode-map.txt > > and it will bloat up the table size and consumes more time to analysis. > > Yes, the decoder is supposed to serve the kernel's needs, not be a > general purpose one. > > > (Moreover, it depends on the processor generation -- older processor will > > not support VEX prefix, those are invalid) > > Why does the processor VEX support matter? Isn't the decoder supposed to > decode any instruction it knows about, regardless of the CPU it runs on? Hm, you meant the "invalid" means "that can not be decoded" ? Then it is OK. I Thought "invalid" means "the processor can not execute (some exception will occur)". > > > OK, then could you use -1 instead of 1? It may allow us to expand it > > to return error code in the future. > > Ok, sure. Thanks! > > > I think insn_get_prefixes() can be used independently, because x86 > > perfix bytes is very complex. > > Yah, it all depends on what API interfaces we want to give to users and > make those other helpers internal. Time and usecases will tell. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette -- Masami Hiramatsu
[PATCH] tools: selftests: Add missing munmap() in check_error_paths()
Add the missing munmap(addr_ro, PAGE_SIZE) before return.
Signed-off-by: Youling Tang
---
tools/testing/selftests/ptrace/peeksiginfo.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/ptrace/peeksiginfo.c
b/tools/testing/selftests/ptrace/peeksiginfo.c
index 5490065..3d64be4 100644
--- a/tools/testing/selftests/ptrace/peeksiginfo.c
+++ b/tools/testing/selftests/ptrace/peeksiginfo.c
@@ -62,7 +62,7 @@ static int check_error_paths(pid_t child)
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
if (addr_ro == MAP_FAILED) {
err("mmap() failed: %m\n");
- goto out;
+ goto out_rw;
}
arg.nr = SIGNR;
@@ -75,7 +75,7 @@ static int check_error_paths(pid_t child)
err("sys_ptrace() returns %d (expected -1),"
" errno %d (expected %d): %m\n",
ret, errno, EINVAL);
- goto out;
+ goto out_ro;
}
arg.flags = 0;
@@ -84,7 +84,7 @@ static int check_error_paths(pid_t child)
addr_ro - sizeof(siginfo_t) * 2);
if (ret != 2) {
err("sys_ptrace() returns %d (expected 2): %m\n", ret);
- goto out;
+ goto out_ro;
}
/* Read-only buffer */
@@ -93,11 +93,13 @@ static int check_error_paths(pid_t child)
err("sys_ptrace() returns %d (expected -1),"
" errno %d (expected %d): %m\n",
ret, errno, EFAULT);
- goto out;
+ goto out_ro;
}
exit_code = 0;
-out:
+out_ro:
+ munmap(addr_ro, PAGE_SIZE);
+out_rw:
munmap(addr_rw, 2 * PAGE_SIZE);
return exit_code;
}
--
2.1.0
[PATCH] hwrng: ks-sa - Add dependency on IOMEM and OF
Resent with fixed Subject line. ---8<--- This patch adds a dependency for KEYSTONE on HAS_IOMEM and OF to prevent COMPILE_TEST build failures. Reported-by: kernel test robot Signed-off-by: Herbert Xu diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig index ab33a2e17cdf..9ff4fb3236f7 100644 --- a/drivers/char/hw_random/Kconfig +++ b/drivers/char/hw_random/Kconfig @@ -508,6 +508,7 @@ config HW_RANDOM_NPCM config HW_RANDOM_KEYSTONE depends on ARCH_KEYSTONE || COMPILE_TEST + depends on HAS_IOMEM && OF default HW_RANDOM tristate "TI Keystone NETCP SA Hardware random number generator" help -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH 2/2] perf-probe: Change function definition check due to broken dwarf
Since some gcc generates a broken DWARF which lacks DW_AT_declaration
attribute from the subprogram DIE of function prototype.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060)
So, in addition to the DW_AT_declaration check, we also check the
subprogram DIE has DW_AT_inline or actual entry pc.
Reported-by: Thomas Richter
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/dwarf-aux.c| 20 ++--
tools/perf/util/probe-finder.c |3 +--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c
index 03c1a39c312a..7b2d471a6419 100644
--- a/tools/perf/util/dwarf-aux.c
+++ b/tools/perf/util/dwarf-aux.c
@@ -356,9 +356,25 @@ bool die_is_signed_type(Dwarf_Die *tp_die)
bool die_is_func_def(Dwarf_Die *dw_die)
{
Dwarf_Attribute attr;
+ Dwarf_Addr addr = 0;
+
+ if (dwarf_tag(dw_die) != DW_TAG_subprogram)
+ return false;
+
+ if (dwarf_attr(dw_die, DW_AT_declaration, ))
+ return false;
- return (dwarf_tag(dw_die) == DW_TAG_subprogram &&
- dwarf_attr(dw_die, DW_AT_declaration, ) == NULL);
+ /*
+* DW_AT_declaration can be lost from function declaration
+* by gcc's bug #97060.
+* So we need to check this subprogram DIE has DW_AT_inline
+* or an entry address.
+*/
+ if (!dwarf_attr(dw_die, DW_AT_inline, ) &&
+ die_entrypc(dw_die, ) < 0)
+ return false;
+
+ return true;
}
/**
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 2c4061035f77..76dd349aa48d 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1885,8 +1885,7 @@ static int line_range_search_cb(Dwarf_Die *sp_die, void
*data)
if (lr->file && strtailcmp(lr->file, dwarf_decl_file(sp_die)))
return DWARF_CB_OK;
- if (die_is_func_def(sp_die) &&
- die_match_name(sp_die, lr->function)) {
+ if (die_match_name(sp_die, lr->function) && die_is_func_def(sp_die)) {
lf->fname = dwarf_decl_file(sp_die);
dwarf_decl_line(sp_die, >offset);
pr_debug("fname: %s, lineno:%d\n", lf->fname, lr->offset);
Re: ks-sa-rng.c:undefined reference to `devm_platform_ioremap_resource'
On Fri, Nov 13, 2020 at 11:02:13PM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba > commit: 90c4b29eb1e555fee66f8329a18cb8a070090ad6 hwrng: ks-sa - Enable > COMPILE_TEST > date: 12 months ago > config: s390-randconfig-r022-20201113 (attached as .config) > compiler: s390-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90c4b29eb1e555fee66f8329a18cb8a070090ad6 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout 90c4b29eb1e555fee66f8329a18cb8a070090ad6 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=s390 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): >s390-linux-ld: drivers/char/hw_random/ks-sa-rng.o: in function > `ks_sa_rng_probe': > >> ks-sa-rng.c:(.text+0x2fa): undefined reference to > >> `devm_platform_ioremap_resource' ---8<--- This patch adds a dependency for KEYSTONE on HAS_IOMEM and OF to prevent COMPILE_TEST build failures. Reported-by: kernel test robot Signed-off-by: Herbert Xu diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig index ab33a2e17cdf..9ff4fb3236f7 100644 --- a/drivers/char/hw_random/Kconfig +++ b/drivers/char/hw_random/Kconfig @@ -508,6 +508,7 @@ config HW_RANDOM_NPCM config HW_RANDOM_KEYSTONE depends on ARCH_KEYSTONE || COMPILE_TEST + depends on HAS_IOMEM && OF default HW_RANDOM tristate "TI Keystone NETCP SA Hardware random number generator" help -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH 1/2] perf-probe: Fix to die_entrypc() returns error correctly
Fix die_entrypc() to return error correctly if the DIE has no
DW_AT_ranges attribute. Since dwarf_ranges() will treat the case
as an empty ranges and return 0, we have to check it by ourselves.
Fixes: 91e2f539eeda ("perf probe: Fix to show function entry line as
probe-able")
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/dwarf-aux.c |8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c
index aa898014ad12..03c1a39c312a 100644
--- a/tools/perf/util/dwarf-aux.c
+++ b/tools/perf/util/dwarf-aux.c
@@ -373,6 +373,7 @@ bool die_is_func_def(Dwarf_Die *dw_die)
int die_entrypc(Dwarf_Die *dw_die, Dwarf_Addr *addr)
{
Dwarf_Addr base, end;
+ Dwarf_Attribute attr;
if (!addr)
return -EINVAL;
@@ -380,6 +381,13 @@ int die_entrypc(Dwarf_Die *dw_die, Dwarf_Addr *addr)
if (dwarf_entrypc(dw_die, addr) == 0)
return 0;
+ /*
+* Since the dwarf_ranges() will return 0 if there is no
+* DW_AT_ranges attribute, we should check it first.
+*/
+ if (!dwarf_attr(dw_die, DW_AT_ranges, ))
+ return -ENOENT;
+
return dwarf_ranges(dw_die, 0, , addr, ) < 0 ? -ENOENT : 0;
}
[PATCH] perf record: Synthesize cgroup events only if needed
It didn't check the tool->cgroup_events bit which is set when
the --all-cgroups option is given. Without it, samples will not have
cgroup info so no reason to synthesize.
We can check the PERF_RECORD_CGROUP records after running perf record
*WITHOUT* the --all-cgroups option:
Before:
$ perf report -D | grep CGROUP
0 0 0x8430 [0x38]: PERF_RECORD_CGROUP cgroup: 1 /
CGROUP events: 1
CGROUP events: 0
CGROUP events: 0
After:
$ perf report -D | grep CGROUP
CGROUP events: 0
CGROUP events: 0
CGROUP events: 0
Fixes: 8fb4b67939e16 ("perf record: Add --all-cgroups option")
Signed-off-by: Namhyung Kim
---
tools/perf/util/synthetic-events.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/util/synthetic-events.c
b/tools/perf/util/synthetic-events.c
index 8a23391558cf..d9c624377da7 100644
--- a/tools/perf/util/synthetic-events.c
+++ b/tools/perf/util/synthetic-events.c
@@ -563,6 +563,9 @@ int perf_event__synthesize_cgroups(struct perf_tool *tool,
char cgrp_root[PATH_MAX];
size_t mount_len; /* length of mount point in the path */
+ if (!tool || !tool->cgroup_events)
+ return 0;
+
if (cgroupfs_find_mountpoint(cgrp_root, PATH_MAX, "perf_event") < 0) {
pr_debug("cannot find cgroup mount point\n");
return -1;
--
2.29.2.454.gaff20da3a2-goog
[v2 PATCH] crypto: lib/blake2s - Move selftest prototype into header file
v2
Actually include the header file.
---8<---
This patch fixes a missing prototype warning on blake2s_selftest.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/include/crypto/internal/blake2s.h
b/include/crypto/internal/blake2s.h
index 74ff77032e52..6e376ae6b6b5 100644
--- a/include/crypto/internal/blake2s.h
+++ b/include/crypto/internal/blake2s.h
@@ -16,6 +16,8 @@ void blake2s_compress_generic(struct blake2s_state
*state,const u8 *block,
void blake2s_compress_arch(struct blake2s_state *state,const u8 *block,
size_t nblocks, const u32 inc);
+bool blake2s_selftest(void);
+
static inline void blake2s_set_lastblock(struct blake2s_state *state)
{
state->f[0] = -1;
diff --git a/lib/crypto/blake2s-selftest.c b/lib/crypto/blake2s-selftest.c
index 79ef404a990d..5d9ea53be973 100644
--- a/lib/crypto/blake2s-selftest.c
+++ b/lib/crypto/blake2s-selftest.c
@@ -3,7 +3,7 @@
* Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights
Reserved.
*/
-#include
+#include
#include
/*
diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
index 41025a30c524..6a4b6b78d630 100644
--- a/lib/crypto/blake2s.c
+++ b/lib/crypto/blake2s.c
@@ -17,8 +17,6 @@
#include
#include
-bool blake2s_selftest(void);
-
void blake2s_update(struct blake2s_state *state, const u8 *in, size_t inlen)
{
const size_t fill = BLAKE2S_BLOCK_SIZE - state->buflen;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH] crypto: lib/blake2s - Move selftest prototype into header file
On Fri, Nov 13, 2020 at 04:02:28PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 585e5b17b92dead8a3aca4e3c9876fbca5f7e0ba
> commit: 66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28 crypto: blake2s - generic C
> library implementation and selftest
> date: 12 months ago
> config: parisc-randconfig-r003-20201113 (attached as .config)
> compiler: hppa-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28
> git remote add linus
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout 66d7fb94e4ffe5acc589e0b2b4710aecc1f07a28
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=parisc
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All warnings (new ones prefixed by >>):
>
> >> lib/crypto/blake2s-selftest.c:566:13: warning: no previous prototype for
> >> 'blake2s_selftest' [-Wmissing-prototypes]
> 566 | bool __init blake2s_selftest(void)
> | ^~~~
>
> vim +/blake2s_selftest +566 lib/crypto/blake2s-selftest.c
>
>565
> > 566bool __init blake2s_selftest(void)
---8<---
This patch fixes a missing prototype warning on blake2s_selftest.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/include/crypto/internal/blake2s.h
b/include/crypto/internal/blake2s.h
index 74ff77032e52..6e376ae6b6b5 100644
--- a/include/crypto/internal/blake2s.h
+++ b/include/crypto/internal/blake2s.h
@@ -16,6 +16,8 @@ void blake2s_compress_generic(struct blake2s_state
*state,const u8 *block,
void blake2s_compress_arch(struct blake2s_state *state,const u8 *block,
size_t nblocks, const u32 inc);
+bool blake2s_selftest(void);
+
static inline void blake2s_set_lastblock(struct blake2s_state *state)
{
state->f[0] = -1;
diff --git a/lib/crypto/blake2s.c b/lib/crypto/blake2s.c
index 41025a30c524..6a4b6b78d630 100644
--- a/lib/crypto/blake2s.c
+++ b/lib/crypto/blake2s.c
@@ -17,8 +17,6 @@
#include
#include
-bool blake2s_selftest(void);
-
void blake2s_update(struct blake2s_state *state, const u8 *in, size_t inlen)
{
const size_t fill = BLAKE2S_BLOCK_SIZE - state->buflen;
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH net-next 1/3] nfc: s3fwrn5: use signed integer for parsing GPIO numbers
On 11/27/20, Bongsu Jeon wrote:
> On Fri, Nov 27, 2020 at 2:06 AM Krzysztof Kozlowski
> wrote:
>>
>> On Fri, Nov 27, 2020 at 12:33:37AM +0900, bongsu.je...@gmail.com wrote:
>> > From: Krzysztof Kozlowski
>> >
>> > GPIOs - as returned by of_get_named_gpio() and used by the gpiolib -
>> > are
>> > signed integers, where negative number indicates error. The return
>> > value of of_get_named_gpio() should not be assigned to an unsigned int
>> > because in case of !CONFIG_GPIOLIB such number would be a valid GPIO.
>> >
>> > Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC
>> > Chip")
>> > Cc:
>> > Signed-off-by: Krzysztof Kozlowski
>>
>> Why do you send my patch?
>>
>
> I think that your patch should be applied before refactoring for this
> driver.
> So, I applied your patch to net-next branch and included your patch at
> my patch list.
> Is this the wrong process?
>
Sorry to confuse you.
I found your patch when i updated my workspace using git pull.
>> Best regards,
>> Krzysztof
>
[PATCH 1/2] ASoC: dt-bindings: imx-hdmi: Add binding doc for hdmi machine driver
Imx-hdmi is a new added machine driver for supporting hdmi devices
on i.MX platforms. There is HDMI IP or external HDMI modules connect
with SAI or AUD2HTX interface.
Signed-off-by: Shengjiu Wang
---
.../bindings/sound/imx-audio-hdmi.yaml| 52 +++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml
b/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml
new file mode 100644
index ..d5474f83ac2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-hdmi.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/imx-audio-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX audio complex with HDMI
+
+maintainers:
+ - Shengjiu Wang
+
+properties:
+ compatible:
+enum:
+ - fsl,imx-audio-hdmi
+ - fsl,imx-audio-sii902x
+
+ model:
+$ref: /schemas/types.yaml#/definitions/string
+description: User specified audio sound card name
+
+ audio-cpu:
+description: The phandle of an CPU DAI controller
+
+ hdmi-out:
+description: |
+ This is a boolean property. If present, the transmitting function
+ of HDMI will be enabled, indicating there's a physical HDMI out
+ connector or jack on the board or it's connecting to some other IP
+ block, such as an HDMI encoder or display-controller.
+
+ hdmi-in:
+description: |
+ This is a boolean property. If present, the receiving function of
+ HDMI will be enabled, indicating there is a physical HDMI in
+ connector/jack on the board.
+
+required:
+ - compatible
+ - model
+ - audio-cpu
+
+additionalProperties: false
+
+examples:
+ - |
+sound-hdmi {
+compatible = "fsl,imx-audio-hdmi";
+model = "audio-hdmi";
+audio-cpu = <>;
+hdmi-out;
+};
--
2.27.0
[PATCH 2/2] ASoC: fsl: Add imx-hdmi machine driver
The driver is initially designed for sound card using HDMI
interface on i.MX platform. There is internal HDMI IP or
external HDMI modules connect with SAI or AUD2HTX interface.
It supports both transmitter and receiver devices.
Signed-off-by: Shengjiu Wang
---
sound/soc/fsl/Kconfig| 12 ++
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/imx-hdmi.c | 235 +++
3 files changed, 249 insertions(+)
create mode 100644 sound/soc/fsl/imx-hdmi.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
index 24710decd38a..84db0b7b9d59 100644
--- a/sound/soc/fsl/Kconfig
+++ b/sound/soc/fsl/Kconfig
@@ -305,6 +305,18 @@ config SND_SOC_IMX_AUDMIX
Say Y if you want to add support for SoC audio on an i.MX board with
an Audio Mixer.
+config SND_SOC_IMX_HDMI
+ tristate "SoC Audio support for i.MX boards with HDMI port"
+ select SND_SOC_FSL_SAI
+ select SND_SOC_FSL_AUD2HTX
+ select SND_SOC_HDMI_CODEC
+ help
+ ALSA SoC Audio support with HDMI feature for Freescale SoCs that have
+ SAI/AUD2HTX and connect with internal HDMI IP or external module
+ SII902X.
+ Say Y if you want to add support for SoC audio on an i.MX board with
+ IMX HDMI.
+
endif # SND_IMX_SOC
endmenu
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
index 0b20e038b65b..8c5fa8a859c0 100644
--- a/sound/soc/fsl/Makefile
+++ b/sound/soc/fsl/Makefile
@@ -65,9 +65,11 @@ snd-soc-imx-es8328-objs := imx-es8328.o
snd-soc-imx-sgtl5000-objs := imx-sgtl5000.o
snd-soc-imx-spdif-objs := imx-spdif.o
snd-soc-imx-audmix-objs := imx-audmix.o
+snd-soc-imx-hdmi-objs := imx-hdmi.o
obj-$(CONFIG_SND_SOC_EUKREA_TLV320) += snd-soc-eukrea-tlv320.o
obj-$(CONFIG_SND_SOC_IMX_ES8328) += snd-soc-imx-es8328.o
obj-$(CONFIG_SND_SOC_IMX_SGTL5000) += snd-soc-imx-sgtl5000.o
obj-$(CONFIG_SND_SOC_IMX_SPDIF) += snd-soc-imx-spdif.o
obj-$(CONFIG_SND_SOC_IMX_AUDMIX) += snd-soc-imx-audmix.o
+obj-$(CONFIG_SND_SOC_IMX_HDMI) += snd-soc-imx-hdmi.o
diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
new file mode 100644
index ..ac164514b1b2
--- /dev/null
+++ b/sound/soc/fsl/imx-hdmi.c
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2017-2020 NXP
+
+#include
+#include
+#include
+#include
+#include
+#include "fsl_sai.h"
+
+/**
+ * struct cpu_priv - CPU private data
+ * @sysclk_freq: SYSCLK rates for set_sysclk()
+ * @sysclk_dir: SYSCLK directions for set_sysclk()
+ * @sysclk_id: SYSCLK ids for set_sysclk()
+ * @slot_width: Slot width of each frame
+ *
+ * Note: [1] for tx and [0] for rx
+ */
+struct cpu_priv {
+ unsigned long sysclk_freq[2];
+ u32 sysclk_dir[2];
+ u32 sysclk_id[2];
+ u32 slot_width;
+};
+
+struct imx_hdmi_data {
+ struct snd_soc_dai_link dai;
+ struct snd_soc_card card;
+ struct snd_soc_jack hdmi_jack;
+ struct snd_soc_jack_pin hdmi_jack_pin;
+ struct cpu_priv cpu_priv;
+ u32 dai_fmt;
+};
+
+static int imx_hdmi_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct imx_hdmi_data *data = snd_soc_card_get_drvdata(rtd->card);
+ bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
+ struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
+ struct snd_soc_card *card = rtd->card;
+ struct device *dev = card->dev;
+ int ret;
+
+ /* set cpu DAI configuration */
+ ret = snd_soc_dai_set_sysclk(cpu_dai, data->cpu_priv.sysclk_id[tx],
+8 * data->cpu_priv.slot_width *
params_rate(params),
+tx ? SND_SOC_CLOCK_OUT : SND_SOC_CLOCK_IN);
+ if (ret && ret != -ENOTSUPP) {
+ dev_err(dev, "failed to set cpu sysclk: %d\n", ret);
+ return ret;
+ }
+
+ ret = snd_soc_dai_set_tdm_slot(cpu_dai, 0, 0, 2,
data->cpu_priv.slot_width);
+ if (ret && ret != -ENOTSUPP) {
+ dev_err(dev, "failed to set cpu dai tdm slot: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct snd_soc_ops imx_hdmi_ops = {
+ .hw_params = imx_hdmi_hw_params,
+};
+
+static const struct snd_soc_dapm_widget imx_hdmi_widgets[] = {
+ SND_SOC_DAPM_LINE("HDMI Jack", NULL),
+};
+
+static int imx_hdmi_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_card *card = rtd->card;
+ struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+ struct snd_soc_component *component = codec_dai->component;
+ struct imx_hdmi_data *data = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ data->hdmi_jack_pin.pin = "HDMI Jack";
+ data->hdmi_jack_pin.mask = SND_JACK_LINEOUT;
+ /* enable jack detection */
+ ret = snd_soc_card_jack_new(card, "HDMI Jack", SND_JACK_LINEOUT,
+
[PATCH] add amlogic gpio to irq
From: Lin shenghuan
---
drivers/pinctrl/meson/pinctrl-meson.c | 36 +++
drivers/pinctrl/meson/pinctrl-meson.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
b/drivers/pinctrl/meson/pinctrl-meson.c
index 20683cd..b91ff2c 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include "../core.h"
#include "../pinctrl-utils.h"
@@ -598,6 +599,34 @@ static int meson_gpio_get(struct gpio_chip *chip, unsigned
gpio)
return !!(val & BIT(bit));
}
+static int meson_gpio_to_irq(struct gpio_chip *chip, unsigned int gpio)
+{
+ struct meson_pinctrl *pc = gpiochip_get_data(chip);
+ struct meson_bank *bank;
+ struct irq_fwspec fwspec;
+ int hwirq;
+
+ if (meson_get_bank(pc, gpio, ))
+ return -EINVAL;
+
+ if (bank->irq_first < 0) {
+ dev_warn(pc->dev, "no support irq for pin[%d]\n", gpio);
+ return -EINVAL;
+ }
+ if (!pc->of_irq) {
+ dev_err(pc->dev, "invalid device node of gpio INTC\n");
+ return -EINVAL;
+ }
+
+ hwirq = gpio - bank->first + bank->irq_first;
+ fwspec.fwnode = of_node_to_fwnode(pc->of_irq);
+ fwspec.param_count = 2;
+ fwspec.param[0] = hwirq;
+ fwspec.param[1] = IRQ_TYPE_NONE;
+
+ return irq_create_fwspec_mapping();
+}
+
static int meson_gpiolib_register(struct meson_pinctrl *pc)
{
int ret;
@@ -612,6 +641,7 @@ static int meson_gpiolib_register(struct meson_pinctrl *pc)
pc->chip.direction_output = meson_gpio_direction_output;
pc->chip.get = meson_gpio_get;
pc->chip.set = meson_gpio_set;
+ pc->chip.to_irq = meson_gpio_to_irq;
pc->chip.base = -1;
pc->chip.ngpio = pc->data->num_pins;
pc->chip.can_sleep = false;
@@ -682,6 +712,12 @@ static int meson_pinctrl_parse_dt(struct meson_pinctrl *pc,
pc->of_node = gpio_np;
+ pc->of_irq = of_find_compatible_node(NULL,
+ NULL, "amlogic,meson-gpio-intc");
+ if (!pc->of_irq)
+ pc->of_irq = of_find_compatible_node(NULL,
+ NULL, "amlogic,meson-gpio-intc-ext");
+
pc->reg_mux = meson_map_resource(pc, gpio_np, "mux");
if (IS_ERR_OR_NULL(pc->reg_mux)) {
dev_err(pc->dev, "mux registers not found\n");
diff --git a/drivers/pinctrl/meson/pinctrl-meson.h
b/drivers/pinctrl/meson/pinctrl-meson.h
index f8b0ff9..0f808bb 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.h
+++ b/drivers/pinctrl/meson/pinctrl-meson.h
@@ -131,6 +131,7 @@ struct meson_pinctrl {
struct regmap *reg_ds;
struct gpio_chip chip;
struct device_node *of_node;
+ struct device_node *of_irq;
};
#define FUNCTION(fn) \
--
2.7.4
[PATCH] add amlogic gpio to irq
From: Lin shenghuan
---
drivers/pinctrl/meson/pinctrl-meson.c | 36 +++
drivers/pinctrl/meson/pinctrl-meson.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
b/drivers/pinctrl/meson/pinctrl-meson.c
index 20683cd..b91ff2c 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include "../core.h"
#include "../pinctrl-utils.h"
@@ -598,6 +599,34 @@ static int meson_gpio_get(struct gpio_chip *chip, unsigned
gpio)
return !!(val & BIT(bit));
}
+static int meson_gpio_to_irq(struct gpio_chip *chip, unsigned int gpio)
+{
+ struct meson_pinctrl *pc = gpiochip_get_data(chip);
+ struct meson_bank *bank;
+ struct irq_fwspec fwspec;
+ int hwirq;
+
+ if (meson_get_bank(pc, gpio, ))
+ return -EINVAL;
+
+ if (bank->irq_first < 0) {
+ dev_warn(pc->dev, "no support irq for pin[%d]\n", gpio);
+ return -EINVAL;
+ }
+ if (!pc->of_irq) {
+ dev_err(pc->dev, "invalid device node of gpio INTC\n");
+ return -EINVAL;
+ }
+
+ hwirq = gpio - bank->first + bank->irq_first;
+ fwspec.fwnode = of_node_to_fwnode(pc->of_irq);
+ fwspec.param_count = 2;
+ fwspec.param[0] = hwirq;
+ fwspec.param[1] = IRQ_TYPE_NONE;
+
+ return irq_create_fwspec_mapping();
+}
+
static int meson_gpiolib_register(struct meson_pinctrl *pc)
{
int ret;
@@ -612,6 +641,7 @@ static int meson_gpiolib_register(struct meson_pinctrl *pc)
pc->chip.direction_output = meson_gpio_direction_output;
pc->chip.get = meson_gpio_get;
pc->chip.set = meson_gpio_set;
+ pc->chip.to_irq = meson_gpio_to_irq;
pc->chip.base = -1;
pc->chip.ngpio = pc->data->num_pins;
pc->chip.can_sleep = false;
@@ -682,6 +712,12 @@ static int meson_pinctrl_parse_dt(struct meson_pinctrl *pc,
pc->of_node = gpio_np;
+ pc->of_irq = of_find_compatible_node(NULL,
+ NULL, "amlogic,meson-gpio-intc");
+ if (!pc->of_irq)
+ pc->of_irq = of_find_compatible_node(NULL,
+ NULL, "amlogic,meson-gpio-intc-ext");
+
pc->reg_mux = meson_map_resource(pc, gpio_np, "mux");
if (IS_ERR_OR_NULL(pc->reg_mux)) {
dev_err(pc->dev, "mux registers not found\n");
diff --git a/drivers/pinctrl/meson/pinctrl-meson.h
b/drivers/pinctrl/meson/pinctrl-meson.h
index f8b0ff9..0f808bb 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.h
+++ b/drivers/pinctrl/meson/pinctrl-meson.h
@@ -131,6 +131,7 @@ struct meson_pinctrl {
struct regmap *reg_ds;
struct gpio_chip chip;
struct device_node *of_node;
+ struct device_node *of_irq;
};
#define FUNCTION(fn) \
--
2.7.4
[PATCH] add amlogic gpio to irq
From: Lin shenghuan
---
drivers/pinctrl/meson/pinctrl-meson.c | 36 +++
drivers/pinctrl/meson/pinctrl-meson.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
b/drivers/pinctrl/meson/pinctrl-meson.c
index 20683cd..b91ff2c 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include "../core.h"
#include "../pinctrl-utils.h"
@@ -598,6 +599,34 @@ static int meson_gpio_get(struct gpio_chip *chip, unsigned
gpio)
return !!(val & BIT(bit));
}
+static int meson_gpio_to_irq(struct gpio_chip *chip, unsigned int gpio)
+{
+ struct meson_pinctrl *pc = gpiochip_get_data(chip);
+ struct meson_bank *bank;
+ struct irq_fwspec fwspec;
+ int hwirq;
+
+ if (meson_get_bank(pc, gpio, ))
+ return -EINVAL;
+
+ if (bank->irq_first < 0) {
+ dev_warn(pc->dev, "no support irq for pin[%d]\n", gpio);
+ return -EINVAL;
+ }
+ if (!pc->of_irq) {
+ dev_err(pc->dev, "invalid device node of gpio INTC\n");
+ return -EINVAL;
+ }
+
+ hwirq = gpio - bank->first + bank->irq_first;
+ fwspec.fwnode = of_node_to_fwnode(pc->of_irq);
+ fwspec.param_count = 2;
+ fwspec.param[0] = hwirq;
+ fwspec.param[1] = IRQ_TYPE_NONE;
+
+ return irq_create_fwspec_mapping();
+}
+
static int meson_gpiolib_register(struct meson_pinctrl *pc)
{
int ret;
@@ -612,6 +641,7 @@ static int meson_gpiolib_register(struct meson_pinctrl *pc)
pc->chip.direction_output = meson_gpio_direction_output;
pc->chip.get = meson_gpio_get;
pc->chip.set = meson_gpio_set;
+ pc->chip.to_irq = meson_gpio_to_irq;
pc->chip.base = -1;
pc->chip.ngpio = pc->data->num_pins;
pc->chip.can_sleep = false;
@@ -682,6 +712,12 @@ static int meson_pinctrl_parse_dt(struct meson_pinctrl *pc,
pc->of_node = gpio_np;
+ pc->of_irq = of_find_compatible_node(NULL,
+ NULL, "amlogic,meson-gpio-intc");
+ if (!pc->of_irq)
+ pc->of_irq = of_find_compatible_node(NULL,
+ NULL, "amlogic,meson-gpio-intc-ext");
+
pc->reg_mux = meson_map_resource(pc, gpio_np, "mux");
if (IS_ERR_OR_NULL(pc->reg_mux)) {
dev_err(pc->dev, "mux registers not found\n");
diff --git a/drivers/pinctrl/meson/pinctrl-meson.h
b/drivers/pinctrl/meson/pinctrl-meson.h
index f8b0ff9..0f808bb 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.h
+++ b/drivers/pinctrl/meson/pinctrl-meson.h
@@ -131,6 +131,7 @@ struct meson_pinctrl {
struct regmap *reg_ds;
struct gpio_chip chip;
struct device_node *of_node;
+ struct device_node *of_irq;
};
#define FUNCTION(fn) \
--
2.7.4
Re: [RFC][PATCH 00/18] crypto: Add generic Kerberos library
On Thu, Nov 26, 2020 at 08:19:41AM +, David Howells wrote: > > I haven't done that yet. Sorry, I should've been more explicit with what I > was after. I was wanting to find out if the nfs/nfsd people are okay with > this (and if there are any gotchas I should know about - it turns out, if I > understand it correctly, the relevant code may being being rewritten a bit > anyway). > > And from you, I was wanting to find out if you're okay with an interface of > this kind in crypto/ where the code is just used directly - or whether I'll > be required to wrap it up in the autoloading, module-handling mechanisms. I don't have any problems with it living under crypto. However, I'd like to see what the sunrpc code looks like before going one way or another. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH 2/2] mm/debug_vm_pgtable/basic: Iterate over entire protection_map[]
Currently the basic tests just validate various page table transformations
after starting with vm_get_page_prot(VM_READ|VM_WRITE|VM_EXEC) protection.
Instead scan over the entire protection_map[] for better coverage. It also
makes sure that all these basic page table tranformations checks hold true
irrespective of the starting protection value for the page table entry.
There is also a slight change in the debug print format for basic tests to
capture the protection value it is being tested with. The modified output
looks something like
[pte_basic_tests ]: Validating PTE basic ()
[pte_basic_tests ]: Validating PTE basic (read)
[pte_basic_tests ]: Validating PTE basic (write)
[pte_basic_tests ]: Validating PTE basic (read|write)
[pte_basic_tests ]: Validating PTE basic (exec)
[pte_basic_tests ]: Validating PTE basic (read|exec)
[pte_basic_tests ]: Validating PTE basic (write|exec)
[pte_basic_tests ]: Validating PTE basic (read|write|exec)
[pte_basic_tests ]: Validating PTE basic (shared)
[pte_basic_tests ]: Validating PTE basic (read|shared)
[pte_basic_tests ]: Validating PTE basic (write|shared)
[pte_basic_tests ]: Validating PTE basic (read|write|shared)
[pte_basic_tests ]: Validating PTE basic (exec|shared)
[pte_basic_tests ]: Validating PTE basic (read|exec|shared)
[pte_basic_tests ]: Validating PTE basic (write|exec|shared)
[pte_basic_tests ]: Validating PTE basic (read|write|exec|shared)
This adds a missing argument 'struct mm_struct *' in pud_basic_tests() test
. This never got exposed before as PUD based THP is available only on X86
platform where mm_pmd_folded(mm) call gets macro replaced without requiring
the mm_struct i.e __is_defined(__PAGETABLE_PMD_FOLDED).
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Suggested-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
---
mm/debug_vm_pgtable.c | 47 ---
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c
index a5be11210597..92b4a53d622b 100644
--- a/mm/debug_vm_pgtable.c
+++ b/mm/debug_vm_pgtable.c
@@ -58,11 +58,13 @@
#define RANDOM_ORVALUE (GENMASK(BITS_PER_LONG - 1, 0) & ~ARCH_SKIP_MASK)
#define RANDOM_NZVALUE GENMASK(7, 0)
-static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot)
+static void __init pte_basic_tests(unsigned long pfn, int idx)
{
+ pgprot_t prot = protection_map[idx];
pte_t pte = pfn_pte(pfn, prot);
+ unsigned long val = idx, *ptr =
- pr_debug("Validating PTE basic\n");
+ pr_debug("Validating PTE basic (%pGv)\n", ptr);
WARN_ON(!pte_same(pte, pte));
WARN_ON(!pte_young(pte_mkyoung(pte_mkold(pte;
WARN_ON(!pte_dirty(pte_mkdirty(pte_mkclean(pte;
@@ -130,14 +132,16 @@ static void __init pte_savedwrite_tests(unsigned long
pfn, pgprot_t prot)
}
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot)
+static void __init pmd_basic_tests(unsigned long pfn, int idx)
{
+ pgprot_t prot = protection_map[idx];
pmd_t pmd = pfn_pmd(pfn, prot);
+ unsigned long val = idx, *ptr =
if (!has_transparent_hugepage())
return;
- pr_debug("Validating PMD basic\n");
+ pr_debug("Validating PMD basic (%pGv)\n", ptr);
WARN_ON(!pmd_same(pmd, pmd));
WARN_ON(!pmd_young(pmd_mkyoung(pmd_mkold(pmd;
WARN_ON(!pmd_dirty(pmd_mkdirty(pmd_mkclean(pmd;
@@ -251,14 +255,16 @@ static void __init pmd_savedwrite_tests(unsigned long
pfn, pgprot_t prot)
}
#ifdef CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD
-static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot)
+static void __init pud_basic_tests(struct mm_struct *mm, unsigned long pfn,
int idx)
{
+ pgprot_t prot = protection_map[idx];
pud_t pud = pfn_pud(pfn, prot);
+ unsigned long val = idx, *ptr =
if (!has_transparent_hugepage())
return;
- pr_debug("Validating PUD basic\n");
+ pr_debug("Validating PUD basic (%pGv)\n", ptr);
WARN_ON(!pud_same(pud, pud));
WARN_ON(!pud_young(pud_mkyoung(pud_mkold(pud;
WARN_ON(!pud_write(pud_mkwrite(pud_wrprotect(pud;
@@ -362,7 +368,7 @@ static void __init pud_huge_tests(pud_t *pudp, unsigned
long pfn, pgprot_t prot)
#endif /* !CONFIG_HAVE_ARCH_HUGE_VMAP */
#else /* !CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD */
-static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) { }
+static void __init pud_basic_tests(struct mm_struct *mm, unsigned long pfn,
int idx) { }
static void __init pud_advanced_tests(struct mm_struct *mm,
struct vm_area_struct *vma, pud_t *pudp,
unsigned long pfn, unsigned long vaddr,
[PATCH 1/2] mm/debug_vm_pgtable/basic: Add validation for dirtiness after write protect
This adds validation tests for dirtiness after write protect conversion for each page table level. This is important for platforms such as arm64 that removes the hardware dirty bit while making it an write protected one. This also fixes pxx_wrprotect() related typos in the documentation file. Cc: Andrew Morton Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org Suggested-by: Catalin Marinas Signed-off-by: Anshuman Khandual --- Documentation/vm/arch_pgtable_helpers.rst | 8 mm/debug_vm_pgtable.c | 3 +++ 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/Documentation/vm/arch_pgtable_helpers.rst b/Documentation/vm/arch_pgtable_helpers.rst index f3591ee3aaa8..552567d863b8 100644 --- a/Documentation/vm/arch_pgtable_helpers.rst +++ b/Documentation/vm/arch_pgtable_helpers.rst @@ -50,7 +50,7 @@ PTE Page Table Helpers +---+--+ | pte_mkwrite | Creates a writable PTE | +---+--+ -| pte_mkwrprotect | Creates a write protected PTE | +| pte_wrprotect | Creates a write protected PTE | +---+--+ | pte_mkspecial | Creates a special PTE | +---+--+ @@ -120,7 +120,7 @@ PMD Page Table Helpers +---+--+ | pmd_mkwrite | Creates a writable PMD | +---+--+ -| pmd_mkwrprotect | Creates a write protected PMD | +| pmd_wrprotect | Creates a write protected PMD | +---+--+ | pmd_mkspecial | Creates a special PMD | +---+--+ @@ -186,7 +186,7 @@ PUD Page Table Helpers +---+--+ | pud_mkwrite | Creates a writable PUD | +---+--+ -| pud_mkwrprotect | Creates a write protected PUD | +| pud_wrprotect | Creates a write protected PUD | +---+--+ | pud_mkdevmap | Creates a ZONE_DEVICE mapped PUD | +---+--+ @@ -224,7 +224,7 @@ HugeTLB Page Table Helpers +---+--+ | huge_pte_mkwrite | Creates a writable HugeTLB | +---+--+ -| huge_pte_mkwrprotect | Creates a write protected HugeTLB | +| huge_pte_wrprotect| Creates a write protected HugeTLB | +---+--+ | huge_ptep_get_and_clear | Clears a HugeTLB | +---+--+ diff --git a/mm/debug_vm_pgtable.c b/mm/debug_vm_pgtable.c index c05d9dcf7891..a5be11210597 100644 --- a/mm/debug_vm_pgtable.c +++ b/mm/debug_vm_pgtable.c @@ -70,6 +70,7 @@ static void __init pte_basic_tests(unsigned long pfn, pgprot_t prot) WARN_ON(pte_young(pte_mkold(pte_mkyoung(pte; WARN_ON(pte_dirty(pte_mkclean(pte_mkdirty(pte; WARN_ON(pte_write(pte_wrprotect(pte_mkwrite(pte; + WARN_ON(pte_dirty(pte_wrprotect(pte))); } static void __init pte_advanced_tests(struct mm_struct *mm, @@ -144,6 +145,7 @@ static void __init pmd_basic_tests(unsigned long pfn, pgprot_t prot) WARN_ON(pmd_young(pmd_mkold(pmd_mkyoung(pmd; WARN_ON(pmd_dirty(pmd_mkclean(pmd_mkdirty(pmd; WARN_ON(pmd_write(pmd_wrprotect(pmd_mkwrite(pmd; + WARN_ON(pmd_dirty(pmd_wrprotect(pmd))); /* * A huge page does not point to next level page table * entry. Hence this must qualify as pmd_bad(). @@ -262,6 +264,7 @@ static void __init pud_basic_tests(unsigned long pfn, pgprot_t prot) WARN_ON(!pud_write(pud_mkwrite(pud_wrprotect(pud; WARN_ON(pud_write(pud_wrprotect(pud_mkwrite(pud; WARN_ON(pud_young(pud_mkold(pud_mkyoung(pud; + WARN_ON(pud_dirty(pud_wrprotect(pud))); if (mm_pmd_folded(mm))
[PATCH v2] proc: use untagged_addr() for pagemap_read addresses
When we try to visit the pagemap of a tagged userspace pointer, we find
that the start_vaddr is not correct because of the tag.
To fix it, we should untag the usespace pointers in pagemap_read().
I tested with 5.10-rc4 and the issue remains.
Explaination from Catalin in [1]:
"
Arguably, that's a user-space bug since tagged file offsets were never
supported. In this case it's not even a tag at bit 56 as per the arm64
tagged address ABI but rather down to bit 47. You could say that the
problem is caused by the C library (malloc()) or whoever created the
tagged vaddr and passed it to this function. It's not a kernel
regression as we've never supported it.
Now, pagemap is a special case where the offset is usually not generated
as a classic file offset but rather derived by shifting a user virtual
address. I guess we can make a concession for pagemap (only) and allow
such offset with the tag at bit (56 - PAGE_SHIFT + 3).
"
My test code is baed on [2]:
A userspace pointer which has been tagged by 0xb4: 0xb47662f541c8
=== userspace program ===
uint64 OsLayer::VirtualToPhysical(void *vaddr) {
uint64 frame, paddr, pfnmask, pagemask;
int pagesize = sysconf(_SC_PAGESIZE);
off64_t off = ((uintptr_t)vaddr) / pagesize * 8; // off =
0xb47662f541c8 / pagesize * 8 = 0x5a3b317aa0
int fd = open(kPagemapPath, O_RDONLY);
...
if (lseek64(fd, off, SEEK_SET) != off || read(fd, , 8) != 8) {
int err = errno;
string errtxt = ErrorString(err);
if (fd >= 0)
close(fd);
return 0;
}
...
}
=== kernel fs/proc/task_mmu.c ===
static ssize_t pagemap_read(struct file *file, char __user *buf,
size_t count, loff_t *ppos)
{
...
src = *ppos;
svpfn = src / PM_ENTRY_BYTES; // svpfn == 0xb47662f54
start_vaddr = svpfn << PAGE_SHIFT; // start_vaddr == 0xb47662f54000
end_vaddr = mm->task_size;
/* watch out for wraparound */
// svpfn == 0xb47662f54
// (mm->task_size >> PAGE) == 0x800
if (svpfn > mm->task_size >> PAGE_SHIFT) // the condition is true
because of the tag 0xb4
start_vaddr = end_vaddr;
ret = 0;
while (count && (start_vaddr < end_vaddr)) { // we cannot visit correct
entry because start_vaddr is set to end_vaddr
int len;
unsigned long end;
...
}
...
}
[1] https://lore.kernel.org/patchwork/patch/1343258/
[2] https://github.com/stressapptest/stressapptest/blob/master/src/os.cc#L158
Cc: Andrew Morton
Cc: Alexey Dobriyan
Cc: Andrey Konovalov
Cc: Alexander Potapenko
Cc: Vincenzo Frascino
Cc: Andrey Ryabinin
Cc: Catalin Marinas
Cc: Dmitry Vyukov
Cc: Marco Elver
Cc: Will Deacon
Cc: Eric W. Biederman
Cc: Song Bao Hua (Barry Song)
Cc: sta...@vger.kernel.org # v5.4-
Signed-off-by: Miles Chen
---
Change since v1:
1. Follow Eirc's and Catalin's suggestion to avoid overflow
2. Cc to stable v5.4-
3. add explaination from Catalin to the commit message
---
fs/proc/task_mmu.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 217aa2705d5d..92b277388f05 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1599,11 +1599,15 @@ static ssize_t pagemap_read(struct file *file, char
__user *buf,
src = *ppos;
svpfn = src / PM_ENTRY_BYTES;
- start_vaddr = svpfn << PAGE_SHIFT;
end_vaddr = mm->task_size;
/* watch out for wraparound */
- if (svpfn > mm->task_size >> PAGE_SHIFT)
+ start_vaddr = end_vaddr;
+ if (svpfn < (ULONG_MAX >> PAGE_SHIFT))
+ start_vaddr = untagged_addr(svpfn << PAGE_SHIFT);
+
+ /* Ensure the address is inside the task */
+ if (start_vaddr > mm->task_size)
start_vaddr = end_vaddr;
/*
--
2.18.0
[PATCH 0/2] mm/debug_vm_pgtable: Some minor updates
This series contains some cleanups and new test suggestions from Catalin from an earlier discussion. https://lore.kernel.org/linux-mm/20201123142237.GF17833@gaia/ This series is based on v5.10-rc5 and has been tested on arm64 and x86 but has only been build tested on riscv, s390, arc etc. It would be great if folks could test this on these platforms as well. Thank you. Cc: Christophe Leroy Cc: Gerald Schaefer Cc: Vineet Gupta Cc: Catalin Marinas Cc: Paul Walmsley Cc: Andrew Morton Anshuman Khandual (2): mm/debug_vm_pgtable/basic: Add validation for dirtiness after write protect mm/debug_vm_pgtable/basic: Iterate over entire protection_map[] Documentation/vm/arch_pgtable_helpers.rst | 8 ++-- mm/debug_vm_pgtable.c | 50 +-- 2 files changed, 42 insertions(+), 16 deletions(-) -- 2.20.1
[PATCH v3] media: rc: add keymap for pine64 remote
From: Jonas Karlman
Add a keymap for the pine64 IR remote [0]. The mouse key has been mapped to
KEY_EPG to provide a more useful remote.
[0] http://files.pine64.org/doc/Pine%20A64%20Schematic/remote-wit-logo.jpg
Signed-off-by: Jonas Karlman
Signed-off-by: Christian Hewitt
---
Changes since v2:
- added missing rc-map.h change
Changes since v1 [1]:
- reorder code to match the physical layout
- assign KEY_EPG instead of KEY_CONTEXT_MENU
KEY_CONTEXT_MENU duplicates KEY_MENU, and while Seans suggestion of BTN_LEFT
visually matches the key, this duplicates KEY_OK in most GUI's designed for
remote naviagation, e.g. Kodi and Plex. I've chosen to map KEY_EPG as this
is a common tweak in user forums to extend IR remote functionality.
[1]
https://patchwork.kernel.org/project/linux-media/patch/am3pr03mb09661a45feb90ffc3cb44508ac...@am3pr03mb0966.eurprd03.prod.outlook.com/
.../devicetree/bindings/media/rc.yaml | 1 +
drivers/media/rc/keymaps/Makefile | 1 +
drivers/media/rc/keymaps/rc-pine64.c | 65 +++
include/media/rc-map.h| 1 +
4 files changed, 68 insertions(+)
create mode 100644 drivers/media/rc/keymaps/rc-pine64.c
diff --git a/Documentation/devicetree/bindings/media/rc.yaml
b/Documentation/devicetree/bindings/media/rc.yaml
index 03cf40f91d6c..946441b4e1a5 100644
--- a/Documentation/devicetree/bindings/media/rc.yaml
+++ b/Documentation/devicetree/bindings/media/rc.yaml
@@ -103,6 +103,7 @@ properties:
- rc-npgtech
- rc-odroid
- rc-pctv-sedna
+ - rc-pine64
- rc-pinnacle-color
- rc-pinnacle-grey
- rc-pinnacle-pctv-hd
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index 1c4d6bec0ae4..b252a1d2ebd6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-npgtech.o \
rc-odroid.o \
rc-pctv-sedna.o \
+ rc-pine64.o \
rc-pinnacle-color.o \
rc-pinnacle-grey.o \
rc-pinnacle-pctv-hd.o \
diff --git a/drivers/media/rc/keymaps/rc-pine64.c
b/drivers/media/rc/keymaps/rc-pine64.c
new file mode 100644
index ..9b2bdbbce04e
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-pine64.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+// Keytable for the Pine64 IR Remote Controller
+// Copyright (c) 2017 Jonas Karlman
+
+#include
+#include
+
+static struct rc_map_table pine64[] = {
+ { 0x40404d, KEY_POWER },
+ { 0x40401f, KEY_WWW },
+ { 0x40400a, KEY_MUTE },
+
+ { 0x404017, KEY_VOLUMEDOWN },
+ { 0x404018, KEY_VOLUMEUP },
+
+ { 0x404010, KEY_LEFT },
+ { 0x404011, KEY_RIGHT },
+ { 0x40400b, KEY_UP },
+ { 0x40400e, KEY_DOWN },
+ { 0x40400d, KEY_OK },
+
+ { 0x40401d, KEY_MENU },
+ { 0x40401a, KEY_HOME },
+
+ { 0x404045, KEY_BACK },
+
+ { 0x404001, KEY_NUMERIC_1 },
+ { 0x404002, KEY_NUMERIC_2 },
+ { 0x404003, KEY_NUMERIC_3 },
+ { 0x404004, KEY_NUMERIC_4 },
+ { 0x404005, KEY_NUMERIC_5 },
+ { 0x404006, KEY_NUMERIC_6 },
+ { 0x404007, KEY_NUMERIC_7 },
+ { 0x404008, KEY_NUMERIC_8 },
+ { 0x404009, KEY_NUMERIC_9 },
+ { 0x40400c, KEY_BACKSPACE },
+ { 0x404000, KEY_NUMERIC_0 },
+ { 0x404047, KEY_EPG }, // mouse
+};
+
+static struct rc_map_list pine64_map = {
+ .map = {
+ .scan = pine64,
+ .size = ARRAY_SIZE(pine64),
+ .rc_proto = RC_PROTO_NECX,
+ .name = RC_MAP_PINE64,
+ }
+};
+
+static int __init init_rc_map_pine64(void)
+{
+ return rc_map_register(_map);
+}
+
+static void __exit exit_rc_map_pine64(void)
+{
+ rc_map_unregister(_map);
+}
+
+module_init(init_rc_map_pine64)
+module_exit(exit_rc_map_pine64)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jonas Karlman");
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index fa270f16a97b..999b750bc6b8 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -283,6 +283,7 @@ struct rc_map *rc_map_get(const char *name);
#define RC_MAP_NPGTECH "rc-npgtech"
#define RC_MAP_ODROID"rc-odroid"
#define RC_MAP_PCTV_SEDNA"rc-pctv-sedna"
+#define RC_MAP_PINE64"rc-pine64"
#define RC_MAP_PINNACLE_COLOR"rc-pinnacle-color"
#define RC_MAP_PINNACLE_GREY "rc-pinnacle-grey"
#define RC_MAP_PINNACLE_PCTV_HD "rc-pinnacle-pctv-hd"
--
2.17.1
Re: [PATCH v2 tip/core/rcu 5/6] srcu: Provide polling interfaces for Tree SRCU grace periods
On 11/21/2020 6:29 AM, paul...@kernel.org wrote:
From: "Paul E. McKenney"
There is a need for a polling interface for SRCU grace
periods, so this commit supplies get_state_synchronize_srcu(),
start_poll_synchronize_srcu(), and poll_state_synchronize_srcu() for this
purpose. The first can be used if future grace periods are inevitable
(perhaps due to a later call_srcu() invocation), the second if future
grace periods might not otherwise happen, and the third to check if a
grace period has elapsed since the corresponding call to either of the
first two.
As with get_state_synchronize_rcu() and cond_synchronize_rcu(),
the return value from either get_state_synchronize_srcu() or
start_poll_synchronize_srcu() must be passed in to a later call to
poll_state_synchronize_srcu().
Link: https://lore.kernel.org/rcu/20201112201547.gf3365...@moria.home.lan/
Reported-by: Kent Overstreet
[ paulmck: Add EXPORT_SYMBOL_GPL() per kernel test robot feedback. ]
[ paulmck: Apply feedback from Neeraj Upadhyay. ]
Link: https://lore.kernel.org/lkml/20201117004017.GA7444@paulmck-ThinkPad-P72/
Signed-off-by: Paul E. McKenney
---
For version in -rcu dev
Reviewed-by: Neeraj Upadhyay
Thanks
Neeraj
kernel/rcu/srcutiny.c | 2 +-
kernel/rcu/srcutree.c | 67 ---
2 files changed, 64 insertions(+), 5 deletions(-)
diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
index b073175..c8f4202 100644
--- a/kernel/rcu/srcutiny.c
+++ b/kernel/rcu/srcutiny.c
@@ -148,7 +148,7 @@ void srcu_drive_gp(struct work_struct *wp)
* straighten that out.
*/
WRITE_ONCE(ssp->srcu_gp_running, false);
- if (USHORT_CMP_GE(ssp->srcu_idx, READ_ONCE(ssp->srcu_idx_max)))
+ if (USHORT_CMP_LT(ssp->srcu_idx, READ_ONCE(ssp->srcu_idx_max)))
schedule_work(>srcu_work);
}
EXPORT_SYMBOL_GPL(srcu_drive_gp);
diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c
index d930ece..945c047 100644
--- a/kernel/rcu/srcutree.c
+++ b/kernel/rcu/srcutree.c
@@ -810,7 +810,8 @@ static void srcu_leak_callback(struct rcu_head *rhp)
/*
* Start an SRCU grace period, and also queue the callback if non-NULL.
*/
-static void srcu_gp_start_if_needed(struct srcu_struct *ssp, struct rcu_head
*rhp, bool do_norm)
+static unsigned long srcu_gp_start_if_needed(struct srcu_struct *ssp,
+struct rcu_head *rhp, bool do_norm)
{
unsigned long flags;
int idx;
@@ -819,10 +820,12 @@ static void srcu_gp_start_if_needed(struct srcu_struct
*ssp, struct rcu_head *rh
unsigned long s;
struct srcu_data *sdp;
+ check_init_srcu_struct(ssp);
idx = srcu_read_lock(ssp);
sdp = raw_cpu_ptr(ssp->sda);
spin_lock_irqsave_rcu_node(sdp, flags);
- rcu_segcblist_enqueue(>srcu_cblist, rhp);
+ if (rhp)
+ rcu_segcblist_enqueue(>srcu_cblist, rhp);
rcu_segcblist_advance(>srcu_cblist,
rcu_seq_current(>srcu_gp_seq));
s = rcu_seq_snap(>srcu_gp_seq);
@@ -841,6 +844,7 @@ static void srcu_gp_start_if_needed(struct srcu_struct
*ssp, struct rcu_head *rh
else if (needexp)
srcu_funnel_exp_start(ssp, sdp->mynode, s);
srcu_read_unlock(ssp, idx);
+ return s;
}
/*
@@ -874,7 +878,6 @@ static void srcu_gp_start_if_needed(struct srcu_struct
*ssp, struct rcu_head *rh
static void __call_srcu(struct srcu_struct *ssp, struct rcu_head *rhp,
rcu_callback_t func, bool do_norm)
{
- check_init_srcu_struct(ssp);
if (debug_rcu_head_queue(rhp)) {
/* Probable double call_srcu(), so leak the callback. */
WRITE_ONCE(rhp->func, srcu_leak_callback);
@@ -882,7 +885,7 @@ static void __call_srcu(struct srcu_struct *ssp, struct
rcu_head *rhp,
return;
}
rhp->func = func;
- srcu_gp_start_if_needed(ssp, rhp, do_norm);
+ (void)srcu_gp_start_if_needed(ssp, rhp, do_norm);
}
/**
@@ -1011,6 +1014,62 @@ void synchronize_srcu(struct srcu_struct *ssp)
}
EXPORT_SYMBOL_GPL(synchronize_srcu);
+/**
+ * get_state_synchronize_srcu - Provide an end-of-grace-period cookie
+ * @ssp: srcu_struct to provide cookie for.
+ *
+ * This function returns a cookie that can be passed to
+ * poll_state_synchronize_srcu(), which will return true if a full grace
+ * period has elapsed in the meantime. It is the caller's responsibility
+ * to make sure that grace period happens, for example, by invoking
+ * call_srcu() after return from get_state_synchronize_srcu().
+ */
+unsigned long get_state_synchronize_srcu(struct srcu_struct *ssp)
+{
+ // Any prior manipulation of SRCU-protected data must happen
+ // before the load from ->srcu_gp_seq.
+ smp_mb();
+ return rcu_seq_snap(>srcu_gp_seq);
+}
+EXPORT_SYMBOL_GPL(get_state_synchronize_srcu);
+
+/**
+ * start_poll_synchronize_srcu -
Re: [PATCH 131/141] tpm: Fix fall-through warnings for Clang
On Tue, 2020-11-24 at 08:40 -0600, Gustavo A. R. Silva wrote: > On Tue, Nov 24, 2020 at 12:53:22AM +0200, Jarkko Sakkinen wrote: > > On Tue, Nov 24, 2020 at 12:52:31AM +0200, Jarkko Sakkinen wrote: > > > On Fri, Nov 20, 2020 at 12:40:14PM -0600, Gustavo A. R. Silva wrote: > > > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > > > > by explicitly adding a break statement instead of letting the code fall > > > > through to the next case. > > > > > > > > Link: https://github.com/KSPP/linux/issues/115 > > > > Signed-off-by: Gustavo A. R. Silva > > > > --- > > > > drivers/char/tpm/eventlog/tpm1.c | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/drivers/char/tpm/eventlog/tpm1.c > > > > b/drivers/char/tpm/eventlog/tpm1.c > > > > index 2c96977ad080..8aa9057601d6 100644 > > > > --- a/drivers/char/tpm/eventlog/tpm1.c > > > > +++ b/drivers/char/tpm/eventlog/tpm1.c > > > > @@ -210,6 +210,7 @@ static int get_event_name(char *dest, struct > > > > tcpa_event *event, > > > > default: > > > > break; > > > > } > > > > + break; > > > > default: > > > > break; > > > > } > > > > -- > > > > 2.27.0 > > > > > > > > > > > > > > Reviewed-by: Jarkko Sakkinen > > > > > > Who is picking these patches? > > I can take it in my tree for 5.11 if people are OK with that. :) > > > > > > > /Jarkko > > > > I mean > > > > Reviewed-by: Jarkko Sakkinen > > Thanks, Jarkko. > -- > Gustavo keyring: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=a49bdffa9db63a54a6ac56cdcdef8cc8f404f4b6 TPM: https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/commit/?id=1ce46c91fdfe5ebf27a6d328b108c630406d1c8c Looks good? /Jarkko
Re: [PATCHv4 00/25] perf: Add mmap2 build id support
Hi Jiri, On Fri, Nov 27, 2020 at 2:00 AM Jiri Olsa wrote: > > hi, > adding the support to have buildid stored in mmap2 event, > so we can bypass the final perf record hunt on build ids. > > This patchset allows perf to record build ID in mmap2 event, > and adds perf tooling to store/download binaries to .debug > cache based on these build IDs. > > Note that the build id retrieval code is stolen from bpf > code, where it's been used (together with file offsets) > to replace IPs in user space stack traces. It's now added > under lib directory. For the series: Acked-by: Namhyung Kim Thanks, Namhyung > > v4 changes: > - fixed typo in changelog [Namhyung] > - removed force_download bool from struct dso_store_data, > because it's not used [Namhyung] > > v3 changes: > - added acks > - removed forgotten debug code [Arnaldo] > - fixed readlink termination [Ian] > - fixed doc for --debuginfod=URLs [Ian] > - adopted kernel's memchr_inv function and used > it in build_id__is_defined function [Arnaldo] > > On recording server: > > - on the recording server we can run record with --buildid-mmap > option to store build ids in mmap2 events: > > # perf record --buildid-mmap > ^C[ perf record: Woken up 2 times to write data ] > [ perf record: Captured and wrote 0.836 MB perf.data ] > > - it stores nothing to ~/.debug cache: > > # find ~/.debug > find: ‘/root/.debug’: No such file or directory > > - and still reports properly: > > # perf report --stdio > ... > 99.82% swapper [kernel.kallsyms] [k] native_safe_halt > 0.03% swapper [kernel.kallsyms] [k] finish_task_switch > 0.02% swapper [kernel.kallsyms] [k] __softirqentry_text_start > 0.01% kcompactd0 [kernel.kallsyms] [k] > _raw_spin_unlock_irqrestore > 0.01% ksoftirqd/6 [kernel.kallsyms] [k] slab_free_freelist_hook > 0.01% kworker/17:1H-x [kernel.kallsyms] [k] slab_free_freelist_hook > > - display used/hit build ids: > > # perf buildid-list | head -5 > 5dcec522abf136fcfd3128f47e131f2365834dd7 /proc/kcore > 589e403a34f55486bcac848a45e00bcdeedd1ca8 /usr/lib64/libcrypto.so.1.1.1g > 94569566d4eac7e9c87ba029d43d4e2158f9527e /usr/lib64/libpthread-2.30.so > 559b9702bebe31c6d132c8dc5cc887673d65d5b5 /usr/lib64/libc-2.30.so > 40da7abe89f631f60538a17686a7d65c6a02ed31 /usr/lib64/ld-2.30.so > > - store build id binaries into build id cache: > > # perf buildid-cache -a perf.data > OK 5dcec522abf136fcfd3128f47e131f2365834dd7 /proc/kcore > OK 589e403a34f55486bcac848a45e00bcdeedd1ca8 > /usr/lib64/libcrypto.so.1.1.1g > OK 94569566d4eac7e9c87ba029d43d4e2158f9527e > /usr/lib64/libpthread-2.30.so > OK 559b9702bebe31c6d132c8dc5cc887673d65d5b5 /usr/lib64/libc-2.30.so > OK 40da7abe89f631f60538a17686a7d65c6a02ed31 /usr/lib64/ld-2.30.so > OK a674f7a47c78e35a088104647b9640710277b489 /usr/sbin/sshd > OK e5cb4ca25f46485bdbc691c3a92e7e111dac3ef2 /usr/bin/bash > OK 9bc8589108223c944b452f0819298a0c3cba6215 /usr/bin/find > > # find ~/.debug | head -5 > /root/.debug > /root/.debug/proc > /root/.debug/proc/kcore > /root/.debug/proc/kcore/5dcec522abf136fcfd3128f47e131f2365834dd7 > /root/.debug/proc/kcore/5dcec522abf136fcfd3128f47e131f2365834dd7/kallsyms > > - run debuginfod daemon to provide binaries to another server (below) > (the initialization could take some time) > > # debuginfod -F / > > > On another server: > > - copy perf.data from 'record' server and run: > > $ find ~/.debug/ > find: ‘/home/jolsa/.debug/’: No such file or directory > > $ perf buildid-list | head -5 > No kallsyms or vmlinux with build-id > 5dcec522abf136fcfd3128f47e131f2365834dd7 was found > 5dcec522abf136fcfd3128f47e131f2365834dd7 [kernel.kallsyms] > 5784f813b727a50cfd3363234aef9fcbab685cc4 > /lib/modules/5.10.0-rc2speed+/kernel/fs/xfs/xfs.ko > 589e403a34f55486bcac848a45e00bcdeedd1ca8 /usr/lib64/libcrypto.so.1.1.1g > 94569566d4eac7e9c87ba029d43d4e2158f9527e /usr/lib64/libpthread-2.30.so > 559b9702bebe31c6d132c8dc5cc887673d65d5b5 /usr/lib64/libc-2.30.so > > - report does not show anything (kernel build id does not match): > >$ perf report --stdio >... > 76.73% swapper [kernel.kallsyms][k] 0x81aa8ebe > 1.89% find [kernel.kallsyms][k] 0x810f2167 > 0.93% sshd [kernel.kallsyms][k] 0x8153380c > 0.83% swapper [kernel.kallsyms][k] 0x81104b0b > 0.71% kworker/u40:2-e [kernel.kallsyms][k] 0x810f3850 > 0.70% kworker/u40:0-e [kernel.kallsyms][k] 0x810f3850 > 0.64% find [kernel.kallsyms][k] 0x81a9ba0a > 0.63% find [kernel.kallsyms][k] 0x81aa93b0 > > - add build ids does not work, because existing binaries (on another server) >
[PATCH] mmc: core: MMC_CAP2_HS200_1_8V_SDR with mmc-hs400-1_8v
This patch remove the MMC_CAP2_HS200_1_8V_SDR capacity from host->cap2 when the dt property mmc-hs400-1v8 set. It cause error and occasionally hang on boot and reboot. Board with this issue: rk3399 with SanDisk DG4008 eMMC. This patch did not change the mmc-hs400-1_2v host->cap2 added the MMC_CAP2_HS200_1_2V_SDR. Log shows a boot process with a HS400 5.1 capable SanDisk 8G with mmc-hs400-1_8v dt property and the MMC_CAP2_HS200_1_8V_SDR append to the host->cap2. [1.775721] mmc1: CQHCI version 5.10 [1.802342] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] using ADMA [2.007581] mmc1: mmc_select_hs200 failed, error -110 [2.007589] mmc1: error -110 whilst initialising MMC card [2.413559] mmc1: mmc_select_hs200 failed, error -110 [2.413562] mmc1: error -110 whilst initialising MMC card [3.183343] mmc1: Command Queue Engine enabled [3.183355] mmc1: new HS400 MMC card at address 0001 [3.197163] mmcblk1: mmc1:0001 DG4008 7.28 GiB [3.197256] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB [3.197360] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB [3.197479] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev (242:0) after patch applied [1.746691] mmc1: CQHCI version 5.10 [1.773316] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] using ADMA [1.858410] mmc1: Command Queue Engine enabled [1.858418] mmc1: new HS400 MMC card at address 0001 [1.858897] mmcblk1: mmc1:0001 DG4008 7.28 GiB [1.859002] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB [1.859097] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB [1.859182] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev (242:0) Fixes: c373eb489b27b mmc: core: add DT bindings for eMMC HS400 1.8/1.2V Signed-off-by: Chris Ruehl --- drivers/mmc/core/host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index 96b2ca1f1b06..f55113e24c68 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -295,7 +295,7 @@ int mmc_of_parse(struct mmc_host *host) if (device_property_read_bool(dev, "mmc-hs200-1_2v")) host->caps2 |= MMC_CAP2_HS200_1_2V_SDR; if (device_property_read_bool(dev, "mmc-hs400-1_8v")) - host->caps2 |= MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR; + host->caps2 |= MMC_CAP2_HS400_1_8V; if (device_property_read_bool(dev, "mmc-hs400-1_2v")) host->caps2 |= MMC_CAP2_HS400_1_2V | MMC_CAP2_HS200_1_2V_SDR; if (device_property_read_bool(dev, "mmc-hs400-enhanced-strobe")) -- 2.20.1
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c:1916:23: warning: Uninitialized variable: vlevel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 85a2c56cb4454c73f56d3099d96942e7919b292f
commit: 16a8cb7cc557f980aae19d1b7140713939fa9644 drm/amd/display: fix dcn3
p_state_change_support validation (v2)
date: 5 months ago
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"cppcheck warnings: (new ones prefixed by >>)"
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:
>> drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c:1916:23: warning:
>> Uninitialized variable: vlevel [uninitvar]
if (fast_validate || vlevel == context->bw_ctx.dml.soc.num_states ||
^
cppcheck possible warnings: (new ones prefixed by >>, may not real problems)
In file included from
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_resource.c:
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c:2362:26: warning:
Array index 'i' is used before limits check. [arrayIndexThenCheck]
if (dcfclk_sta_targets[i] < optimal_dcfclk_for_uclk[j] && i <
num_dcfclk_sta_targets) {
^
vim +1916 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c
1873
1874 static bool dcn30_internal_validate_bw(
1875 struct dc *dc,
1876 struct dc_state *context,
1877 display_e2e_pipe_params_st *pipes,
1878 int *pipe_cnt_out,
1879 int *vlevel_out,
1880 bool fast_validate)
1881 {
1882 bool out = false;
1883 bool repopulate_pipes = false;
1884 int split[MAX_PIPES] = { 0 };
1885 bool merge[MAX_PIPES] = { false };
1886 bool newly_split[MAX_PIPES] = { false };
1887 int pipe_cnt, i, pipe_idx, vlevel;
1888 struct vba_vars_st *vba = >bw_ctx.dml.vba;
1889
1890 ASSERT(pipes);
1891 if (!pipes)
1892 return false;
1893
1894 pipe_cnt = dc->res_pool->funcs->populate_dml_pipes(dc, context,
pipes);
1895
1896 if (!pipe_cnt) {
1897 out = true;
1898 goto validate_out;
1899 }
1900
1901 dml_log_pipe_params(>bw_ctx.dml, pipes, pipe_cnt);
1902
1903 if (!fast_validate) {
1904 /*
1905 * DML favors voltage over p-state, but we're more
interested in
1906 * supporting p-state over voltage. We can't support
p-state in
1907 * prefetch mode > 0 so try capping the prefetch mode
to start.
1908 */
1909
context->bw_ctx.dml.soc.allow_dram_self_refresh_or_dram_clock_change_in_vblank =
1910 dm_allow_self_refresh_and_mclk_switch;
1911 vlevel = dml_get_voltage_level(>bw_ctx.dml,
pipes, pipe_cnt);
1912 /* This may adjust vlevel and maxMpcComb */
1913 if (vlevel < context->bw_ctx.dml.soc.num_states)
1914 vlevel =
dcn20_validate_apply_pipe_split_flags(dc, context, vlevel, split, merge);
1915 }
> 1916 if (fast_validate || vlevel ==
> context->bw_ctx.dml.soc.num_states ||
1917
vba->DRAMClockChangeSupport[vlevel][vba->maxMpcComb] ==
dm_dram_clock_change_unsupported) {
1918 /*
1919 * If mode is unsupported or there's still no p-state
support then
1920 * fall back to favoring voltage.
1921 *
1922 * We don't actually support prefetch mode 2, so
require that we
1923 * at least support prefetch mode 1.
1924 */
1925
context->bw_ctx.dml.soc.allow_dram_self_refresh_or_dram_clock_change_in_vblank =
1926 dm_allow_self_refresh;
1927
1928 vlevel = dml_get_voltage_level(>bw_ctx.dml,
pipes, pipe_cnt);
1929 if (vlevel < context->bw_ctx.dml.soc.num_states) {
1930 memset(split, 0, sizeof(split));
1931 memset(merge, 0, sizeof(merge));
1932 vlevel =
dcn20_validate_apply_pipe_split_flags(dc, context, vlevel, split, merge);
1933 }
1934 }
1935
1936 dml_log_mode_support_params(>bw_ctx.dml);
1937
1938 /* TODO: Need to check calculated vlevel why that fails
validation of below resolutions */
1939 if (context->res_ctx.pipe_ctx[0].stream != NULL) {
1940 if
(context->res_ctx.pipe_ctx[0].stream->timing.h_addressable == 640 &&
context->res_ctx.pipe_ctx[0].stream->timing.v_addressable == 480)
1941 vlevel = 0;
1942 if
Re: [PATCH v2] media: rc: add keymap for pine64 remote
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v5.10-rc5 next-20201126]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-Hewitt/media-rc-add-keymap-for-pine64-remote/20201127-110954
base: git://linuxtv.org/media_tree.git master
config: mips-randconfig-r005-20201127 (attached as .config)
compiler: mipsel-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/f91c9e789bb50680477d0af197fc4d3ccb806c3d
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-Hewitt/media-rc-add-keymap-for-pine64-remote/20201127-110954
git checkout f91c9e789bb50680477d0af197fc4d3ccb806c3d
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/media/rc/keymaps/rc-pine64.c:47:15: error: 'RC_MAP_PINE64'
>> undeclared here (not in a function); did you mean 'RC_MAP_CINERGY'?
47 | .name = RC_MAP_PINE64,
| ^
| RC_MAP_CINERGY
vim +47 drivers/media/rc/keymaps/rc-pine64.c
41
42 static struct rc_map_list pine64_map = {
43 .map = {
44 .scan = pine64,
45 .size = ARRAY_SIZE(pine64),
46 .rc_proto = RC_PROTO_NECX,
> 47 .name = RC_MAP_PINE64,
48 }
49 };
50
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH bpf-next v3 3/3] bpf: Add a selftest for bpf_ima_inode_hash
On Tue, Nov 24, 2020 at 7:16 AM KP Singh wrote:
>
> From: KP Singh
>
> The test does the following:
>
> - Mounts a loopback filesystem and appends the IMA policy to measure
> executions only on this file-system. Restricting the IMA policy to a
> particular filesystem prevents a system-wide IMA policy change.
> - Executes an executable copied to this loopback filesystem.
> - Calls the bpf_ima_inode_hash in the bprm_committed_creds hook and
> checks if the call succeeded and checks if a hash was calculated.
>
> The test shells out to the added ima_setup.sh script as the setup is
> better handled in a shell script and is more complicated to do in the
> test program or even shelling out individual commands from C.
>
> The list of required configs (i.e. IMA, SECURITYFS,
> IMA_{WRITE,READ}_POLICY) for running this test are also updated.
>
> Signed-off-by: KP Singh
> ---
> tools/testing/selftests/bpf/config| 4 +
> tools/testing/selftests/bpf/ima_setup.sh | 80 +++
> .../selftests/bpf/prog_tests/test_ima.c | 74 +
> tools/testing/selftests/bpf/progs/ima.c | 28 +++
> 4 files changed, 186 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/ima_setup.sh
> create mode 100644 tools/testing/selftests/bpf/prog_tests/test_ima.c
> create mode 100644 tools/testing/selftests/bpf/progs/ima.c
>
[...]
> +cleanup() {
> +local tmp_dir="$1"
> +local mount_img="${tmp_dir}/test.img"
> +local mount_dir="${tmp_dir}/mnt"
> +
> +local loop_devices=$(losetup -j ${mount_img} -O NAME --noheadings)
libbpf and kernel-patches CIs are using BusyBox environment which has
losetup that doesn't support -j option. Is there some way to work
around that? What we have is this:
BusyBox v1.31.1 () multi-call binary.
Usage: losetup [-rP] [-o OFS] {-f|LOOPDEV} FILE: associate loop devices
losetup -c LOOPDEV: reread file size
losetup -d LOOPDEV: disassociate
losetup -a: show status
losetup -f: show next free loop device
-o OFSStart OFS bytes into FILE
-PScan for partitions
-rRead-only
-fShow/use next free loop device
> +for loop_dev in "${loop_devices}"; do
> +losetup -d $loop_dev
> +done
> +
> +umount ${mount_dir}
> +rm -rf ${tmp_dir}
> +}
> +
[...]
[PATCH v2 2/2] perf test: Add shadow stat test
It calculates IPC from the cycles and instruction counts and compares
it with the shadow stat for both global aggregation (default) and no
aggregation mode.
$ perf stat -a -A -e cycles,instructions sleep 1
Performance counter stats for 'system wide':
CPU0 39,580,880 cycles
CPU1 45,426,945 cycles
CPU2 31,151,685 cycles
CPU3 55,167,421 cycles
CPU0 17,073,564 instructions #0.43 insn per cycle
CPU1 34,955,764 instructions #0.77 insn per cycle
CPU2 15,688,459 instructions #0.50 insn per cycle
CPU3 34,699,217 instructions #0.63 insn per cycle
1.003275495 seconds time elapsed
In this example, the 'insn per cycle' should be matched to the number
for each cpu. For CPU2, 0.50 = 15,688,459 / 31,151,685 .
Signed-off-by: Namhyung Kim
---
tools/perf/tests/shell/stat+shadow_stat.sh | 80 ++
1 file changed, 80 insertions(+)
create mode 100755 tools/perf/tests/shell/stat+shadow_stat.sh
diff --git a/tools/perf/tests/shell/stat+shadow_stat.sh
b/tools/perf/tests/shell/stat+shadow_stat.sh
new file mode 100755
index ..249dfe48cf6a
--- /dev/null
+++ b/tools/perf/tests/shell/stat+shadow_stat.sh
@@ -0,0 +1,80 @@
+#!/bin/sh
+# perf stat metrics (shadow stat) test
+# SPDX-License-Identifier: GPL-2.0
+
+set -e
+
+# skip if system-wide mode is forbidden
+perf stat -a true > /dev/null 2>&1 || exit 2
+
+test_global_aggr()
+{
+ local cyc
+
+ perf stat -a --no-big-num -e cycles,instructions sleep 1 2>&1 | \
+ grep -e cycles -e instructions | \
+ while read num evt hash ipc rest
+ do
+ # skip not counted events
+ if [[ $num == "&1 | \
+ grep ^CPU | \
+ while read cpu num evt hash ipc rest
+ do
+ # skip not counted events
+ if [[ $num == "
[PATCH] mm: memcg/slab: fix obj_cgroup_charge() return value handling
Commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches
for all allocations") introduced a regression into the handling of the
obj_cgroup_charge() return value. If a non-zero value is returned
(indicating of exceeding one of memory.max limits), the allocation
should fail, instead of falling back to non-accounted mode.
To make the code more readable, move memcg_slab_pre_alloc_hook()
and memcg_slab_post_alloc_hook() calling conditions into bodies
of these hooks.
Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all
allocations")
Signed-off-by: Roman Gushchin
Cc: sta...@vger.kernel.org
---
mm/slab.h | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/mm/slab.h b/mm/slab.h
index 59aeb0d9f11b..5dc89d8fb05e 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -257,22 +257,32 @@ static inline size_t obj_full_size(struct kmem_cache *s)
return s->size + sizeof(struct obj_cgroup *);
}
-static inline struct obj_cgroup *memcg_slab_pre_alloc_hook(struct kmem_cache
*s,
- size_t objects,
- gfp_t flags)
+/*
+ * Returns true if the allocation should fail.
+ */
+static inline bool memcg_slab_pre_alloc_hook(struct kmem_cache *s,
+struct obj_cgroup **objcgp,
+size_t objects, gfp_t flags)
{
struct obj_cgroup *objcg;
+ if (!memcg_kmem_enabled())
+ return false;
+
+ if (!(flags & __GFP_ACCOUNT) && !(s->flags & SLAB_ACCOUNT))
+ return false;
+
objcg = get_obj_cgroup_from_current();
if (!objcg)
- return NULL;
+ return false;
if (obj_cgroup_charge(objcg, flags, objects * obj_full_size(s))) {
obj_cgroup_put(objcg);
- return NULL;
+ return true;
}
- return objcg;
+ *objcgp = objcg;
+ return false;
}
static inline void mod_objcg_state(struct obj_cgroup *objcg,
@@ -298,7 +308,7 @@ static inline void memcg_slab_post_alloc_hook(struct
kmem_cache *s,
unsigned long off;
size_t i;
- if (!objcg)
+ if (!memcg_kmem_enabled() || !objcg)
return;
flags &= ~__GFP_ACCOUNT;
@@ -382,11 +392,11 @@ static inline void memcg_free_page_obj_cgroups(struct
page *page)
{
}
-static inline struct obj_cgroup *memcg_slab_pre_alloc_hook(struct kmem_cache
*s,
- size_t objects,
- gfp_t flags)
+static inline bool memcg_slab_pre_alloc_hook(struct kmem_cache *s,
+struct obj_cgroup **objcgp,
+size_t objects, gfp_t flags)
{
- return NULL;
+ return false;
}
static inline void memcg_slab_post_alloc_hook(struct kmem_cache *s,
@@ -494,9 +504,8 @@ static inline struct kmem_cache *slab_pre_alloc_hook(struct
kmem_cache *s,
if (should_failslab(s, flags))
return NULL;
- if (memcg_kmem_enabled() &&
- ((flags & __GFP_ACCOUNT) || (s->flags & SLAB_ACCOUNT)))
- *objcgp = memcg_slab_pre_alloc_hook(s, size, flags);
+ if (memcg_slab_pre_alloc_hook(s, objcgp, size, flags))
+ return NULL;
return s;
}
@@ -515,8 +524,7 @@ static inline void slab_post_alloc_hook(struct kmem_cache
*s,
s->flags, flags);
}
- if (memcg_kmem_enabled())
- memcg_slab_post_alloc_hook(s, objcg, flags, size, p);
+ memcg_slab_post_alloc_hook(s, objcg, flags, size, p);
}
#ifndef CONFIG_SLOB
--
2.26.2
[PATCH v2 1/2] perf stat: Use proper cpu for shadow stats
Currently perf stat shows some metrics (like IPC) for defined events.
But when no aggregation mode is used (-A option), it shows incorrect
values since it used a value from a different cpu.
Before:
$ perf stat -aA -e cycles,instructions sleep 1
Performance counter stats for 'system wide':
CPU0 116,057,380 cycles
CPU1 86,084,722 cycles
CPU2 99,423,125 cycles
CPU3 98,272,994 cycles
CPU0 53,369,217 instructions #0.46 insn per cycle
CPU1 33,378,058 instructions #0.29 insn per cycle
CPU2 58,150,086 instructions #0.50 insn per cycle
CPU3 40,029,703 instructions #0.34 insn per cycle
1.001816971 seconds time elapsed
So the IPC for CPU1 should be 0.38 (= 33,378,058 / 86,084,722)
but it was 0.29 (= 33,378,058 / 116,057,380) and so on.
After:
$ perf stat -aA -e cycles,instructions sleep 1
Performance counter stats for 'system wide':
CPU0 109,621,384 cycles
CPU1 159,026,454 cycles
CPU2 99,460,366 cycles
CPU3 124,144,142 cycles
CPU0 44,396,706 instructions #0.41 insn per cycle
CPU1 120,195,425 instructions #0.76 insn per cycle
CPU2 44,763,978 instructions #0.45 insn per cycle
CPU3 69,049,079 instructions #0.56 insn per cycle
1.001910444 seconds time elapsed
Reported-by: Sam Xi
Fixes: 44d49a600259 ("perf stat: Support metrics in --per-core/socket mode")
Reviewed-by: Andi Kleen
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/util/stat-display.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c
index 4b57c0c07632..a963b5b8eb72 100644
--- a/tools/perf/util/stat-display.c
+++ b/tools/perf/util/stat-display.c
@@ -324,13 +324,10 @@ static int first_shadow_cpu(struct perf_stat_config
*config,
struct evlist *evlist = evsel->evlist;
int i;
- if (!config->aggr_get_id)
- return 0;
-
if (config->aggr_mode == AGGR_NONE)
return id;
- if (config->aggr_mode == AGGR_GLOBAL)
+ if (!config->aggr_get_id)
return 0;
for (i = 0; i < evsel__nr_cpus(evsel); i++) {
--
2.29.2.454.gaff20da3a2-goog
[PATCH] Asoc: qcom: Fix for problem in resume with CRAS
To support playback continuation after resume problem in chrome
audio server:
Prepare device in platform trigger callback.
Make I2s and DMA control registers as non volatile.
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
sound/soc/qcom/lpass-cpu.c | 8 ++--
sound/soc/qcom/lpass-platform.c | 5 +++--
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index af684fd..c99be03 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -454,20 +454,16 @@ static bool lpass_cpu_regmap_volatile(struct device *dev,
unsigned int reg)
struct lpass_variant *v = drvdata->variant;
int i;
- for (i = 0; i < v->i2s_ports; ++i)
- if (reg == LPAIF_I2SCTL_REG(v, i))
- return true;
for (i = 0; i < v->irq_ports; ++i)
if (reg == LPAIF_IRQSTAT_REG(v, i))
return true;
for (i = 0; i < v->rdma_channels; ++i)
- if (reg == LPAIF_RDMACURR_REG(v, i) || reg ==
LPAIF_RDMACTL_REG(v, i))
+ if (reg == LPAIF_RDMACURR_REG(v, i))
return true;
for (i = 0; i < v->wrdma_channels; ++i)
- if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start) ||
- reg == LPAIF_WRDMACTL_REG(v, i +
v->wrdma_channel_start))
+ if (reg == LPAIF_WRDMACURR_REG(v, i + v->wrdma_channel_start))
return true;
return false;
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index 80b09de..2b0a7c1 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -481,8 +481,9 @@ static int lpass_platform_pcmops_trigger(struct
snd_soc_component *component,
return -ENOTRECOVERABLE;
}
switch (cmd) {
- case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
+ lpass_platform_pcmops_prepare(component, substream);
+ case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
ret = regmap_fields_write(dmactl->enable, id,
LPAIF_DMACTL_ENABLE_ON);
@@ -592,7 +593,7 @@ static int lpass_platform_pcmops_trigger(struct
snd_soc_component *component,
break;
}
- return 0;
+ return ret;
}
static snd_pcm_uframes_t lpass_platform_pcmops_pointer(
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
kernel/smp.c: In function 'csd_lock_wait_getcpu':
kernel/smp.c:133:13: error: 'call_single_data_t' {aka 'struct
__call_single_data'} has no member named 'dst'
133 | return csd->dst; /* Other CSD_TYPE_ values might not have ->dst. */
| ^~
Caused by commit
545b8c8df41f ("smp: Cleanup smp_call_function*()")
[interacting with commit
35feb60474bf ("kernel/smp: Provide CSD lock timeout diagnostics")
from before v5.10-rc1]
I have applied the following patch for today:
From: Stephen Rothwell
Date: Fri, 27 Nov 2020 15:04:00 +1100
Subject: [PATCH] smp: fix up "smp: Cleanup smp_call_function*()"
An instance if "dst" was missed.
Fixes: 545b8c8df41f ("smp: Cleanup smp_call_function*()")
Signed-off-by: Stephen Rothwell
---
kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/smp.c b/kernel/smp.c
index faf1a3ace6a9..1b6070bf97bb 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -130,7 +130,7 @@ static __always_inline int
csd_lock_wait_getcpu(call_single_data_t *csd)
csd_type = CSD_TYPE(csd);
if (csd_type == CSD_TYPE_ASYNC || csd_type == CSD_TYPE_SYNC)
- return csd->dst; /* Other CSD_TYPE_ values might not have
->dst. */
+ return csd->node.dst; /* Other CSD_TYPE_ values might not have
->dst. */
return -1;
}
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpP4hilBFDk5.pgp
Description: OpenPGP digital signature
ll_temac_main.c:undefined reference to `devm_platform_ioremap_resource_byname'
Hi Wang, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 85a2c56cb4454c73f56d3099d96942e7919b292f commit: bd69058f50d5ffa659423bcfa6fe6280ce9c760a net: ll_temac: Use devm_platform_ioremap_resource_byname() date: 4 months ago config: s390-randconfig-p001-20201127 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd69058f50d5ffa659423bcfa6fe6280ce9c760a git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout bd69058f50d5ffa659423bcfa6fe6280ce9c760a # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): s390-linux-ld: drivers/scsi/ufs/ufshcd-pltfrm.o: in function `ufshcd_pltfrm_init': ufshcd-pltfrm.c:(.text+0xb66): undefined reference to `devm_platform_ioremap_resource' s390-linux-ld: drivers/net/ethernet/altera/altera_tse_main.o: in function `request_and_map': altera_tse_main.c:(.text+0x392): undefined reference to `devm_ioremap' s390-linux-ld: drivers/net/ethernet/xilinx/ll_temac_main.o: in function `temac_probe': >> ll_temac_main.c:(.text+0x6eb0): undefined reference to >> `devm_platform_ioremap_resource_byname' s390-linux-ld: ll_temac_main.c:(.text+0x6f8c): undefined reference to `devm_platform_ioremap_resource_byname' s390-linux-ld: ll_temac_main.c:(.text+0x7ee2): undefined reference to `devm_ioremap' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] sparc: Removes code duplication between arch_ptrace and compat_arch_ptrace
The patch removes code duplication between arch_ptrace and
compat_arch_ptrace, in large part by having the former call
into the later for all requests that don't need any special
"compat" treatment.
Signed-off-by: Youling Tang
---
arch/sparc/kernel/ptrace_64.c | 71 +++
1 file changed, 17 insertions(+), 54 deletions(-)
diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
index 2b92155d..4fd8c33 100644
--- a/arch/sparc/kernel/ptrace_64.c
+++ b/arch/sparc/kernel/ptrace_64.c
@@ -929,78 +929,51 @@ struct compat_fps {
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
{
- compat_ulong_t caddr2 = task_pt_regs(current)->u_regs[UREG_I4];
struct pt_regs32 __user *pregs;
struct compat_fps __user *fps;
- unsigned long addr2 = caddr2;
unsigned long addr = caddr;
unsigned long data = cdata;
- int ret;
pregs = (struct pt_regs32 __user *) addr;
fps = (struct compat_fps __user *) addr;
switch (request) {
- case PTRACE_PEEKUSR:
- ret = (addr != 0) ? -EIO : 0;
- break;
-
case PTRACE_GETREGS:
- ret = copy_regset_to_user(child, _view,
+ return copy_regset_to_user(child, _view,
REGSET_GENERAL, 0,
19 * sizeof(u32),
pregs);
- break;
case PTRACE_SETREGS:
- ret = copy_regset_from_user(child, _view,
+ return copy_regset_from_user(child, _view,
REGSET_GENERAL, 0,
19 * sizeof(u32),
pregs);
- break;
case PTRACE_GETFPREGS:
- ret = copy_regset_to_user(child, _view,
+ return copy_regset_to_user(child, _view,
REGSET_FP, 0,
68 * sizeof(u32),
fps);
- break;
case PTRACE_SETFPREGS:
- ret = copy_regset_from_user(child, _view,
+ return copy_regset_from_user(child, _view,
REGSET_FP, 0,
33 * sizeof(u32),
fps);
- break;
+ case PTRACE_PEEKUSR:
case PTRACE_READTEXT:
case PTRACE_READDATA:
- ret = ptrace_readdata(child, addr,
- (char __user *)addr2, data);
- if (ret == data)
- ret = 0;
- else if (ret >= 0)
- ret = -EIO;
- break;
-
case PTRACE_WRITETEXT:
case PTRACE_WRITEDATA:
- ret = ptrace_writedata(child, (char __user *) addr2,
- addr, data);
- if (ret == data)
- ret = 0;
- else if (ret >= 0)
- ret = -EIO;
- break;
+ return arch_ptrace(child, request, addr, data);
default:
if (request == PTRACE_SPARC_DETACH)
request = PTRACE_DETACH;
- ret = compat_ptrace_request(child, request, addr, data);
- break;
+ return compat_ptrace_request(child, request, addr, data);
}
-
- return ret;
}
#endif /* CONFIG_COMPAT */
@@ -1025,63 +998,53 @@ long arch_ptrace(struct task_struct *child, long request,
switch (request) {
case PTRACE_PEEKUSR:
- ret = (addr != 0) ? -EIO : 0;
- break;
+ return ((addr != 0) ? -EIO : 0);
case PTRACE_GETREGS64:
- ret = copy_regset_to_user(child, _view,
+ return copy_regset_to_user(child, _view,
REGSET_GENERAL, 0,
19 * sizeof(u64),
pregs);
- break;
case PTRACE_SETREGS64:
- ret = copy_regset_from_user(child, _view,
+ return copy_regset_from_user(child, _view,
REGSET_GENERAL, 0,
19 * sizeof(u64),
pregs);
- break;
case PTRACE_GETFPREGS64:
- ret = copy_regset_to_user(child, view, REGSET_FP,
+ return copy_regset_to_user(child, view, REGSET_FP,
0 * sizeof(u64),
33 * sizeof(u64),
fps);
-
[PATCH] alpha: ptrace generic requests
This removes duplicated code by calling the generic ptrace_request
function for the things they already handle.
Signed-off-by: Youling Tang
---
arch/alpha/kernel/ptrace.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/alpha/kernel/ptrace.c b/arch/alpha/kernel/ptrace.c
index 8c43212..eb4d566 100644
--- a/arch/alpha/kernel/ptrace.c
+++ b/arch/alpha/kernel/ptrace.c
@@ -301,12 +301,6 @@ long arch_ptrace(struct task_struct *child, long request,
DBG(DBG_MEM, ("peek $%lu->%#lx\n", addr, ret));
break;
- /* When I and D space are separate, this will have to be fixed. */
- case PTRACE_POKETEXT: /* write the word at location addr. */
- case PTRACE_POKEDATA:
- ret = generic_ptrace_pokedata(child, addr, data);
- break;
-
case PTRACE_POKEUSR: /* write the specified register */
DBG(DBG_MEM, ("poke $%lu<-%#lx\n", addr, data));
ret = put_reg(child, addr, data);
--
2.1.0
Re: [RFC PATCH] vfio/pci: Allow force needs_pm_restore as specified by device:vendor
On 11/25/20 11:53 PM, Alex Williamson wrote:
On Wed, 25 Nov 2020 10:18:24 +0800
Colin Xu wrote:
Force specific device listed in params pm_restore_ids to follow
device state save/restore as needs_pm_restore.
Some device has NoSoftRst so will skip current state save/restore enabled
by needs_pm_restore. However once the device experienced power state
D3<->D0 transition, either by idle_d3 or the guest driver changes PM_CTL,
the guest driver won't get correct devie state although the configure
space doesn't change.
It sounds like you're describing a device that incorrectly exposes
NoSoftRst when there is in fact some sort of internal reset that
requires reprogramming config space. What device requires this? How
is a user to know when this option is required? It seems like this
would be better handled via a quirk in PCI core that sets a device flag
that the NoSoftRst value is incorrect for the specific affected
devices. Thanks,
Alex
Thanks for the feedback.
The device found are: Comet Lake PCH Serial IO I2C Controller
[8086:06e8]
[8086:06e9]
Yes you're right, there is no straight way for user to know the device.
The above device I found is during pass through them to VM. Although
adding such param may help in certain scenario, it still too
device-specific but not common in most cases.
I'll try the pci quirk way.
Colin
Cc: Swee Yee Fonn
Signed-off-by: Colin Xu
---
drivers/vfio/pci/vfio_pci.c | 66 -
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index e6190173482c..50a4141c9e1d 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -34,6 +34,15 @@
#define DRIVER_AUTHOR "Alex Williamson "
#define DRIVER_DESC "VFIO PCI - User Level meta-driver"
+#define VFIO_MAX_PM_DEV 32
+struct vfio_pm_devs {
+ struct {
+ unsigned short vendor;
+ unsigned short device;
+ } ids[VFIO_MAX_PM_DEV];
+ u32 count;
+};
+
static char ids[1024] __initdata;
module_param_string(ids, ids, sizeof(ids), 0);
MODULE_PARM_DESC(ids, "Initial PCI IDs to add to the vfio driver, format is
\"vendor:device[:subvendor[:subdevice[:class[:class_mask\" and multiple comma
separated entries can be specified");
@@ -64,6 +73,10 @@ static bool disable_denylist;
module_param(disable_denylist, bool, 0444);
MODULE_PARM_DESC(disable_denylist, "Disable use of device denylist. Disabling the
denylist allows binding to devices with known errata that may lead to exploitable
stability or security issues when accessed by untrusted users.");
+static char pm_restore_ids[1024] __initdata;
+module_param_string(pm_restore_ids, pm_restore_ids, sizeof(pm_restore_ids), 0);
+MODULE_PARM_DESC(pm_restore_ids, "comma separated device in format of
\"vendor:device\"");
+
static inline bool vfio_vga_disabled(void)
{
#ifdef CONFIG_VFIO_PCI_VGA
@@ -260,10 +273,50 @@ static bool vfio_pci_nointx(struct pci_dev *pdev)
return false;
}
+static struct vfio_pm_devs pm_devs = {0};
+static void __init vfio_pci_fill_pm_ids(void)
+{
+ char *p, *id;
+ int idx = 0;
+
+ /* no ids passed actually */
+ if (pm_restore_ids[0] == '\0')
+ return;
+
+ /* add ids specified in the module parameter */
+ p = pm_restore_ids;
+ while ((id = strsep(, ","))) {
+ unsigned int vendor, device = PCI_ANY_ID;
+ int fields;
+
+ if (!strlen(id))
+ continue;
+
+ fields = sscanf(id, "%x:%x", , );
+
+ if (fields != 2) {
+ pr_warn("invalid vendor:device string \"%s\"\n", id);
+ continue;
+ }
+
+ if (idx < VFIO_MAX_PM_DEV) {
+ pm_devs.ids[idx].vendor = vendor;
+ pm_devs.ids[idx].device = device;
+ pm_devs.count++;
+ idx++;
+ pr_info("add [%04x:%04x] for needs_pm_restore\n",
+ vendor, device);
+ } else {
+ pr_warn("Exceed maximum %d, skip adding [%04x:%04x] for
needs_pm_restore\n",
+ VFIO_MAX_PM_DEV, vendor, device);
+ }
+ }
+}
+
static void vfio_pci_probe_power_state(struct vfio_pci_device *vdev)
{
struct pci_dev *pdev = vdev->pdev;
- u16 pmcsr;
+ u16 pmcsr, idx;
if (!pdev->pm_cap)
return;
@@ -271,6 +324,16 @@ static void vfio_pci_probe_power_state(struct
vfio_pci_device *vdev)
pci_read_config_word(pdev, pdev->pm_cap + PCI_PM_CTRL, );
vdev->needs_pm_restore = !(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET);
+
+ for (idx = 0; idx < pm_devs.count; idx++) {
+ if (vdev->pdev->vendor == pm_devs.ids[idx].vendor &&
+ vdev->pdev->device ==
[tip:master] BUILD SUCCESS 94908c81576bf30b2e0c8276444f589d3504216f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 94908c81576bf30b2e0c8276444f589d3504216f Merge branch 'core/entry' elapsed time: 727m configs tested: 138 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arc axs101_defconfig mips pic32mzda_defconfig arm imx_v6_v7_defconfig powerpc64alldefconfig sh sh7724_generic_defconfig m68km5307c3_defconfig csky alldefconfig xtensa iss_defconfig powerpc ep88xc_defconfig powerpcfsp2_defconfig powerpc acadia_defconfig arc allyesconfig powerpc mpc8313_rdb_defconfig powerpc mpc83xx_defconfig arm viper_defconfig s390defconfig xtensaxip_kc705_defconfig pariscgeneric-32bit_defconfig armmagician_defconfig arm moxart_defconfig sh alldefconfig armdove_defconfig sh rts7751r2dplus_defconfig powerpc mpc836x_mds_defconfig powerpc mpc5200_defconfig powerpc chrp32_defconfig arm tct_hammer_defconfig powerpc rainier_defconfig m68kmvme147_defconfig c6x defconfig powerpc katmai_defconfig arm assabet_defconfig c6xevmc6474_defconfig mipsnlm_xlp_defconfig powerpc akebono_defconfig arm davinci_all_defconfig powerpc bluestone_defconfig mips rb532_defconfig mips ip32_defconfig h8300 h8s-sim_defconfig arm hackkit_defconfig sh r7780mp_defconfig m68km5407c3_defconfig arm lubbock_defconfig powerpc arches_defconfig x86_64 alldefconfig sh shx3_defconfig powerpccell_defconfig mips decstation_r4k_defconfig powerpc mpc8315_rdb_defconfig arm pxa3xx_defconfig mips rbtx49xx_defconfig powerpc tqm8540_defconfig powerpc skiroot_defconfig armtrizeps4_defconfig arm nhk8815_defconfig powerpc mpc8272_ads_defconfig xtensa defconfig mips lemote2f_defconfig xtensa cadence_csp_defconfig mips decstation_defconfig archsdk_defconfig powerpc ppc40x_defconfig shdreamcast_defconfig arm spear13xx_defconfig umkunit_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386
[PATCH 2/2] mmc: core: MMC_CAP2_HS200_1_8V_SDR with mmc-hs400-1_8v
This patch remove the MMC_CAP2_HS200_1_8V_SDR capacity from host->cap2 when the dt property mmc-hs400-1v8 set. It cause error and occasionally hang on boot and reboot. Board with this issue: rk3399 with SanDisk DG4008 eMMC. This patch did not change the mmc-hs400-1_2v host->cap2 added the MMC_CAP2_HS200_1_2V_SDR. Log shows a boot process with a HS400 5.1 capable SanDisk 8G with mmc-hs400-1_8v dt property and the MMC_CAP2_HS200_1_8V_SDR append to the host->cap2. [1.775721] mmc1: CQHCI version 5.10 [1.802342] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] using ADMA [2.007581] mmc1: mmc_select_hs200 failed, error -110 [2.007589] mmc1: error -110 whilst initialising MMC card [2.413559] mmc1: mmc_select_hs200 failed, error -110 [2.413562] mmc1: error -110 whilst initialising MMC card [3.183343] mmc1: Command Queue Engine enabled [3.183355] mmc1: new HS400 MMC card at address 0001 [3.197163] mmcblk1: mmc1:0001 DG4008 7.28 GiB [3.197256] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB [3.197360] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB [3.197479] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev (242:0) after patch applied [1.746691] mmc1: CQHCI version 5.10 [1.773316] mmc1: SDHCI controller on fe33.sdhci [fe33.sdhci] using ADMA [1.858410] mmc1: Command Queue Engine enabled [1.858418] mmc1: new HS400 MMC card at address 0001 [1.858897] mmcblk1: mmc1:0001 DG4008 7.28 GiB [1.859002] mmcblk1boot0: mmc1:0001 DG4008 partition 1 4.00 MiB [1.859097] mmcblk1boot1: mmc1:0001 DG4008 partition 2 4.00 MiB [1.859182] mmcblk1rpmb: mmc1:0001 DG4008 partition 3 4.00 MiB, chardev (242:0) Fixes: c373eb489b27b mmc: core: add DT bindings for eMMC HS400 1.8/1.2V Signed-off-by: Chris Ruehl --- drivers/mmc/core/host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c index 96b2ca1f1b06..f55113e24c68 100644 --- a/drivers/mmc/core/host.c +++ b/drivers/mmc/core/host.c @@ -295,7 +295,7 @@ int mmc_of_parse(struct mmc_host *host) if (device_property_read_bool(dev, "mmc-hs200-1_2v")) host->caps2 |= MMC_CAP2_HS200_1_2V_SDR; if (device_property_read_bool(dev, "mmc-hs400-1_8v")) - host->caps2 |= MMC_CAP2_HS400_1_8V | MMC_CAP2_HS200_1_8V_SDR; + host->caps2 |= MMC_CAP2_HS400_1_8V; if (device_property_read_bool(dev, "mmc-hs400-1_2v")) host->caps2 |= MMC_CAP2_HS400_1_2V | MMC_CAP2_HS200_1_2V_SDR; if (device_property_read_bool(dev, "mmc-hs400-enhanced-strobe")) -- 2.20.1
[PATCH 1/2] phy: rockchip: set pulldown for strobe line in dts
This patch add support to set the internal pulldown via dt property
and allow simplify the board design for the trace from emmc-phy to
the eMMC chipset.
Default to not set the pull-down.
This patch was inspired from the 4.4 tree of the
Rockchip SDK, where it is enabled unconditional.
The patch had been tested with our rk3399 customized board.
Signed-off-by: Chris Ruehl
---
drivers/phy/rockchip/phy-rockchip-emmc.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c
b/drivers/phy/rockchip/phy-rockchip-emmc.c
index 2dc19ddd120f..d9bc45828f74 100644
--- a/drivers/phy/rockchip/phy-rockchip-emmc.c
+++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
@@ -67,6 +67,10 @@
#define PHYCTRL_OTAPDLYENA_SHIFT 0xb
#define PHYCTRL_OTAPDLYSEL_MASK0xf
#define PHYCTRL_OTAPDLYSEL_SHIFT 0x7
+#define PHYCTRL_REN_STRB_DISABLE 0x0
+#define PHYCTRL_REN_STRB_ENABLE0x1
+#define PHYCTRL_REN_STRB_MASK 0x1
+#define PHYCTRL_REN_STRB_SHIFT 0x9
#define PHYCTRL_IS_CALDONE(x) \
x) >> PHYCTRL_CALDONE_SHIFT) & \
@@ -80,6 +84,7 @@ struct rockchip_emmc_phy {
struct regmap *reg_base;
struct clk *emmcclk;
unsigned int drive_impedance;
+ unsigned int enable_strobe_pulldown;
};
static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
@@ -295,6 +300,13 @@ static int rockchip_emmc_phy_power_on(struct phy *phy)
PHYCTRL_OTAPDLYSEL_MASK,
PHYCTRL_OTAPDLYSEL_SHIFT));
+ /* Internal pull-down for strobe line */
+ regmap_write(rk_phy->reg_base,
+ rk_phy->reg_offset + GRF_EMMCPHY_CON2,
+ HIWORD_UPDATE(rk_phy->enable_strobe_pulldown,
+ PHYCTRL_REN_STRB_MASK,
+ PHYCTRL_REN_STRB_SHIFT));
+
/* Power up emmc phy analog blocks */
return rockchip_emmc_phy_power(phy, PHYCTRL_PDB_PWR_ON);
}
@@ -359,10 +371,14 @@ static int rockchip_emmc_phy_probe(struct platform_device
*pdev)
rk_phy->reg_offset = reg_offset;
rk_phy->reg_base = grf;
rk_phy->drive_impedance = PHYCTRL_DR_50OHM;
+ rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_DISABLE;
if (!of_property_read_u32(dev->of_node, "drive-impedance-ohm", ))
rk_phy->drive_impedance = convert_drive_impedance_ohm(pdev,
val);
+ if (of_property_read_bool(dev->of_node, "enable-strobe-pulldown"))
+ rk_phy->enable_strobe_pulldown = PHYCTRL_REN_STRB_ENABLE;
+
generic_phy = devm_phy_create(dev, dev->of_node, );
if (IS_ERR(generic_phy)) {
dev_err(dev, "failed to create PHY\n");
--
2.20.1
Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown
The subject prefix doesn't need 'realtek:'; use 'rtw88:'.
On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote:
> Also strip out other duplicates from driver specific headers.
>
> Ensure 'main.h' is explicitly included in 'pci.h' since the latter
> uses some defines from the former. It avoids issues like:
>
> from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5:
> drivers/net/wireless/realtek/rtw88/pci.h:209:28: error:
> ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean
> ‘RTK_MAX_RX_DESC_NUM’?
> 209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM);
> | ^~~~
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous
> prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes]
> 1488 | int rtw_pci_probe(struct pci_dev *pdev,
> | ^
> drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous
> prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes]
> 1568 | void rtw_pci_remove(struct pci_dev *pdev)
> | ^~
> drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous
> prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes]
> 1590 | void rtw_pci_shutdown(struct pci_dev *pdev)
> | ^~~~
>
> Cc: Yan-Hsuan Chuang
> Cc: Kalle Valo
> Cc: "David S. Miller"
> Cc: Jakub Kicinski
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> drivers/net/wireless/realtek/rtw88/pci.h | 8
> drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 +
> drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4
> drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 +
> drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4
> drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 +
> drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4
> drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 +
> drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4
> 9 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.h
> b/drivers/net/wireless/realtek/rtw88/pci.h
> index ca17aa9cf7dc7..cda56919a5f0f 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.h
> +++ b/drivers/net/wireless/realtek/rtw88/pci.h
> @@ -5,6 +5,8 @@
> #ifndef __RTK_PCI_H_
> #define __RTK_PCI_H_
>
> +#include "main.h"
> +
Please #include "main.h" ahead of "pci.h" in each of rtw8e.c.
> #define RTK_DEFAULT_TX_DESC_NUM 128
> #define RTK_BEQ_TX_DESC_NUM 256
>
> @@ -212,6 +214,12 @@ struct rtw_pci {
> void __iomem *mmap;
> };
>
> +const struct dev_pm_ops rtw_pm_ops;
> +
> +int rtw_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id);
> +void rtw_pci_remove(struct pci_dev *pdev);
> +void rtw_pci_shutdown(struct pci_dev *pdev);
> +
> static inline u32 max_num_of_tx_queue(u8 queue)
> {
> u32 max_num;
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> b/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> index c81eb4c336425..2dd689441e8dc 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> @@ -4,6 +4,7 @@
>
> #include
> #include
I mean here:
#include "main.h"
> +#include "pci.h"
> #include "rtw8723de.h"
>
> static const struct pci_device_id rtw_8723de_id_table[] = {
>
[snip]
---
Ping-Ke
[PATCH v10 1/6] leds: flash: Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH
From: Gene Chen
Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH,
and reuse same registration functions no matter flash class exist or not.
Signed-off-by: Gene Chen
---
include/linux/led-class-flash.h | 42 -
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/include/linux/led-class-flash.h b/include/linux/led-class-flash.h
index 21a3358..612b4ca 100644
--- a/include/linux/led-class-flash.h
+++ b/include/linux/led-class-flash.h
@@ -85,6 +85,7 @@ static inline struct led_classdev_flash *lcdev_to_flcdev(
return container_of(lcdev, struct led_classdev_flash, led_cdev);
}
+#if IS_ENABLED(CONFIG_LEDS_CLASS_FLASH)
/**
* led_classdev_flash_register_ext - register a new object of LED class with
* init data and with support for flash LEDs
@@ -98,12 +99,6 @@ int led_classdev_flash_register_ext(struct device *parent,
struct led_classdev_flash *fled_cdev,
struct led_init_data *init_data);
-static inline int led_classdev_flash_register(struct device *parent,
- struct led_classdev_flash *fled_cdev)
-{
- return led_classdev_flash_register_ext(parent, fled_cdev, NULL);
-}
-
/**
* led_classdev_flash_unregister - unregisters an object of led_classdev class
*with support for flash LEDs
@@ -118,15 +113,44 @@ int devm_led_classdev_flash_register_ext(struct device
*parent,
struct led_init_data *init_data);
+void devm_led_classdev_flash_unregister(struct device *parent,
+ struct led_classdev_flash *fled_cdev);
+
+#else
+
+static inline int led_classdev_flash_register_ext(struct device *parent,
+ struct led_classdev_flash *fled_cdev,
+ struct led_init_data *init_data)
+{
+ return 0;
+}
+
+static inline void led_classdev_flash_unregister(struct led_classdev_flash
*fled_cdev) {};
+static inline int devm_led_classdev_flash_register_ext(struct device *parent,
+struct led_classdev_flash *fled_cdev,
+struct led_init_data *init_data)
+{
+ return 0;
+}
+
+static inline void devm_led_classdev_flash_unregister(struct device *parent,
+ struct led_classdev_flash *fled_cdev)
+{};
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_FLASH) */
+
+static inline int led_classdev_flash_register(struct device *parent,
+ struct led_classdev_flash *fled_cdev)
+{
+ return led_classdev_flash_register_ext(parent, fled_cdev, NULL);
+}
+
static inline int devm_led_classdev_flash_register(struct device *parent,
struct led_classdev_flash *fled_cdev)
{
return devm_led_classdev_flash_register_ext(parent, fled_cdev, NULL);
}
-void devm_led_classdev_flash_unregister(struct device *parent,
- struct led_classdev_flash *fled_cdev);
-
/**
* led_set_flash_strobe - setup flash strobe
* @fled_cdev: the flash LED to set strobe on
--
2.7.4
[PATCH v10 6/6] leds: mt6360: Add LED driver for MT6360
From: Gene Chen
Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
3-channel RGB LED support Register/Flash/Breath Mode, and 1-channel for
moonlight LED.
Signed-off-by: Gene Chen
Acked-by: Jacek Anaszewski
---
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-mt6360.c | 811 +
3 files changed, 825 insertions(+)
create mode 100644 drivers/leds/leds-mt6360.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c181df..4f533bc 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -271,6 +271,19 @@ config LEDS_MT6323
This option enables support for on-chip LED drivers found on
Mediatek MT6323 PMIC.
+config LEDS_MT6360
+ tristate "LED Support for Mediatek MT6360 PMIC"
+ depends on LEDS_CLASS && OF
+ depends on LEDS_CLASS_FLASH || !LEDS_CLASS_FLASH
+ depends on LEDS_CLASS_MULTICOLOR || !LEDS_CLASS_MULTICOLOR
+ depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
+ depends on MFD_MT6360
+ help
+ This option enables support for dual Flash LED drivers found on
+ Mediatek MT6360 PMIC.
+ Independent current sources supply for each flash LED support torch
+ and strobe mode.
+
config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index c2c7d7a..5596427 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_LEDS_MIKROTIK_RB532) += leds-rb532.o
obj-$(CONFIG_LEDS_MLXCPLD) += leds-mlxcpld.o
obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
+obj-$(CONFIG_LEDS_MT6360) += leds-mt6360.o
obj-$(CONFIG_LEDS_NET48XX) += leds-net48xx.o
obj-$(CONFIG_LEDS_NETXBIG) += leds-netxbig.o
obj-$(CONFIG_LEDS_NIC78BX) += leds-nic78bx.o
diff --git a/drivers/leds/leds-mt6360.c b/drivers/leds/leds-mt6360.c
new file mode 100644
index 000..94836bb
--- /dev/null
+++ b/drivers/leds/leds-mt6360.c
@@ -0,0 +1,811 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ MT6360_LED_ISNK1 = 0,
+ MT6360_LED_ISNK2,
+ MT6360_LED_ISNK3,
+ MT6360_LED_ISNKML,
+ MT6360_LED_FLASH1,
+ MT6360_LED_FLASH2,
+ MT6360_LED_MULTICOLOR,
+ MT6360_MAX_LEDS = MT6360_LED_MULTICOLOR
+};
+
+#define MT6360_REG_RGBEN 0x380
+#define MT6360_REG_ISNK(_led_no) (0x381 + (_led_no))
+#define MT6360_ISNK_ENMASK(_led_no)BIT(7 - (_led_no))
+#define MT6360_ISNK_MASK GENMASK(4, 0)
+#define MT6360_CHRINDSEL_MASK BIT(3)
+
+#define MULTICOLOR_NUM_CHANNELS3
+
+#define MT6360_REG_FLEDEN 0x37E
+#define MT6360_REG_STRBTO 0x373
+#define MT6360_REG_FLEDBASE(_id) (0x372 + 4 * (_id - MT6360_LED_FLASH1))
+#define MT6360_REG_FLEDISTRB(_id) (MT6360_REG_FLEDBASE(_id) + 2)
+#define MT6360_REG_FLEDITOR(_id) (MT6360_REG_FLEDBASE(_id) + 3)
+#define MT6360_REG_CHGSTAT20x3E1
+#define MT6360_REG_FLEDSTAT1 0x3E9
+#define MT6360_ITORCH_MASK GENMASK(4, 0)
+#define MT6360_ISTROBE_MASKGENMASK(6, 0)
+#define MT6360_STRBTO_MASK GENMASK(6, 0)
+#define MT6360_TORCHEN_MASKBIT(3)
+#define MT6360_STROBEN_MASKBIT(2)
+#define MT6360_FLCSEN_MASK(_id)BIT(MT6360_LED_FLASH2 - _id)
+#define MT6360_FLEDCHGVINOVP_MASK BIT(3)
+#define MT6360_FLED1STRBTO_MASKBIT(11)
+#define MT6360_FLED2STRBTO_MASKBIT(10)
+#define MT6360_FLED1STRB_MASK BIT(9)
+#define MT6360_FLED2STRB_MASK BIT(8)
+#define MT6360_FLED1SHORT_MASK BIT(7)
+#define MT6360_FLED2SHORT_MASK BIT(6)
+#define MT6360_FLEDLVF_MASKBIT(3)
+
+#define MT6360_ISNKRGB_STEPUA 2000
+#define MT6360_ISNKRGB_MAXUA 24000
+#define MT6360_ISNKML_STEPUA 5000
+#define MT6360_ISNKML_MAXUA15
+
+#define MT6360_ITORCH_MINUA25000
+#define MT6360_ITORCH_STEPUA 12500
+#define MT6360_ITORCH_MAXUA40
+#define MT6360_ISTRB_MINUA 5
+#define MT6360_ISTRB_STEPUA12500
+#define MT6360_ISTRB_MAXUA 150
+#define MT6360_STRBTO_MINUS64000
+#define MT6360_STRBTO_STEPUS 32000
+#define MT6360_STRBTO_MAXUS2432000
+
+#define STATE_OFF 0
+#define STATE_KEEP 1
+#define STATE_ON 2
+
+struct mt6360_led {
+ union {
+ struct led_classdev isnk;
+ struct led_classdev_mc mc;
+
