Re: [tip: x86/sgx] selftests/sgx: Improve error detection and messages

On 3/19/21 7:58 AM, Borislav Petkov wrote: > On Fri, Mar 19, 2021 at 11:38:44AM -, tip-bot2 for Dave Hansen wrote: >> tools/testing/selftests/sgx/load.c | 66 ++--- >> tools/testing/selftests/sgx/main.c | 2 +- >> 2 files changed, 53 insertions(+), 15 deletions(-) > An

Re: [RFC] btrfs: Allow read-only mount with corrupted extent tree

ceturtd., 2021. g. 18. marts, plkst. 01:49 — lietotājs Qu Wenruo () rakstīja: > > > > On 2021/3/18 上午5:03, Dāvis Mosāns wrote: > > trešd., 2021. g. 17. marts, plkst. 12:28 — lietotājs Qu Wenruo > > () rakstīja: > >> > >> > >> > >> On 2021/3/17 上午9:29, Dāvis Mosāns wrote: > >>> trešd., 2021. g. 17.

Re: [PATCH v2 0/3] perf-stat: share hardware PMCs with BPF

Em Fri, Mar 19, 2021 at 09:54:59AM +0900, Namhyung Kim escreveu: > On Fri, Mar 19, 2021 at 9:22 AM Song Liu wrote: > > > On Mar 18, 2021, at 5:09 PM, Arnaldo wrote: > > > On March 18, 2021 6:14:34 PM GMT-03:00, Jiri Olsa > > > wrote: > > >> On Thu, Mar 18, 2021 at 03:52:51AM +, Song Liu wro

[PATCH] MAINTAINERS: Add co-maintainer for Qualcomm tsens thermal drivers

Add myself as the maintainer for Qualcomm tsens drivers so that I can help Daniel by taking care of/reviewing changes to these drivers. Signed-off-by: Thara Gopinath --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index aa84121c5611..ab66ab9a628e 100

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

On Fri, Mar 19, 2021 at 08:53:17PM +0530, Amey Narkhede wrote: > On 21/03/19 03:05PM, Leon Romanovsky wrote: <...> > > > > It was exactly the reason why I think that VM usecase presented by > > > > you is not viable. > > > > > > > Well I didn't present it as new use case. I just gave existing > >

Re: [PATCH v4] mm: cma: support sysfs

19.03.2021 17:27, Greg Kroah-Hartman пишет: > On Fri, Mar 19, 2021 at 05:19:47PM +0300, Dmitry Osipenko wrote: >> 19.03.2021 16:51, Dmitry Osipenko пишет: >>> 19.03.2021 16:47, Greg Kroah-Hartman пишет: On Fri, Mar 19, 2021 at 04:45:21PM +0300, Dmitry Osipenko wrote: > 19.03.2021 16:42, Gr

Re: [PATCH v2 08/14] objtool: Add elf_create_reloc() helper

On Fri, Mar 19, 2021 at 04:24:40PM +0100, Peter Zijlstra wrote: > On Fri, Mar 19, 2021 at 10:12:59AM -0500, Josh Poimboeuf wrote: > > > > -void elf_add_reloc(struct elf *elf, struct reloc *reloc) > > > +int elf_add_reloc(struct elf *elf, struct section *sec, unsigned long > > > offset, > > > +

Re: linux-next: manual merge of the net-next tree with the net tree

On 3/19/21 4:33 PM, Alexei Starovoitov wrote: On Fri, Mar 19, 2021 at 8:17 AM Yonghong Song wrote: On 3/19/21 12:21 AM, Daniel Borkmann wrote: On 3/19/21 3:11 AM, Piotr Krysiuk wrote: Hi Daniel, On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell wrote: diff --cc kernel/bpf/verifier.c index

Re: [PATCH v1 2/2] mmc: cavium: Remove redundant if-statement checkup

On Fri, 2021-03-19 at 15:09 +0100, Ulf Hansson wrote: > On Fri, 19 Mar 2021 at 13:14, Bean Huo wrote: > > > From: Bean Huo > > Currently, we have two ways to issue multiple-block read/write the > > command to the eMMC. One is by normal IO request path fs->block- > > >mmc. > > Another one is that

Re: [PATCH 0/6] dma mapping/iommu: Allow IOMMU IOVA rcache range to be configured

On 19/03/2021 13:40, Christoph Hellwig wrote: On Fri, Mar 19, 2021 at 09:25:42PM +0800, John Garry wrote: For streaming DMA mappings involving an IOMMU and whose IOVA len regularly exceeds the IOVA rcache upper limit (meaning that they are not cached), performance can be reduced. This is much m

Re: [PATCH v3 1/1] arm64: mm: correct the inside linear map range during hotplug check

Hi Will, Could you please take this patch now that the dependencies landed in the mainline? Thank you, Pasha On Mon, Feb 22, 2021 at 9:17 AM Pavel Tatashin wrote: > > > Taking that won't help either though, because it will just explode when > > it meets 'mm' in Linus's tree. > > > > So here's w

Re: [PATCH v1 1/1] gpio: Support interrupts in gpio-mlxbf2.c

On Fri, Mar 19, 2021 at 3:24 PM Andrew Lunn wrote: > > > We cannot really pass it through the ACPI table because the ACPI > > table is common to all BlueField-2 boards. And each board may have > > a different GPIO pin associated with a particular function. This is > > why we use ACPI properties i

Re: [PATCH 2/3] static_call: Align static_call_is_init() patching condition

On 19/03/2021 15.40, Rasmus Villemoes wrote: > On 19/03/2021 15.13, Peter Zijlstra wrote: > >>> Dunno, probably overkill, but perhaps we could have an atomic_t (or >>> refcount, whatever) init_ref inited to 1, with init_ref_get() doing an >>> inc_unless_zero, and iff you get a ref, you're free to

Re: [External] Re: [PATCH v4 4/5] mm: memcontrol: use obj_cgroup APIs to charge kmem pages

On Fri, Mar 19, 2021 at 9:59 PM Shakeel Butt wrote: > > On Thu, Mar 18, 2021 at 9:05 PM Muchun Song wrote: > > > > On Fri, Mar 19, 2021 at 11:40 AM Shakeel Butt wrote: > > > > > > On Thu, Mar 18, 2021 at 4:08 AM Muchun Song > > > wrote: > > > > > > > [...] > > > > > > > > +static inline struct

[PATCH net-next] dsa: simplify Kconfig symbols and dependencies

1. Remove CONFIG_HAVE_NET_DSA. CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers should have selected CONFIG_NET_DSA manually. Currently, all drivers has explicit 'depends on NET_DSA', so this is no more needed. 2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones.

Re: [PATCH v4] mm: cma: support sysfs

On Fri, Mar 19, 2021 at 06:38:00PM +0300, Dmitry Osipenko wrote: > 19.03.2021 17:27, Greg Kroah-Hartman пишет: > > On Fri, Mar 19, 2021 at 05:19:47PM +0300, Dmitry Osipenko wrote: > >> 19.03.2021 16:51, Dmitry Osipenko пишет: > >>> 19.03.2021 16:47, Greg Kroah-Hartman пишет: > On Fri, Mar 19,

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

On Fri, Mar 19, 2021 at 02:48:12PM +0100, Enrico Weigelt, metux IT consult wrote: > On 19.03.21 13:59, Leon Romanovsky wrote: <...> > In any case, I still fail to see why giving operators an debug knob > should make anything worse. I see this patch as a workaround to stop and provide quirks for

Re: [PATCH v10 0/3] Charge loop device i/o to issuing cgroup

On Thu, Mar 18, 2021 at 05:56:28PM -0700, Shakeel Butt wrote: > > We need something similar for mem_cgroup_swapin_charge_page() as well. > > It is better to take this series in mm tree and Jens is ok with that [1]. > > [1] > https://lore.kernel.org/linux-next/4fea89a5-0e18-0791-18a8-4c5907b0d..

Re: [PATCH v2 2/2] gpio: Add Realtek Otto GPIO support

Hi Andy, Thanks for the review. I'll address the style comments in a v3. Some further comments and discussion below. On Wed, 2021-03-17 at 15:08 +0200, Andy Shevchenko wrote: > On Mon, Mar 15, 2021 at 11:11 PM Sander Vanheule < > san...@svanheule.net> wrote: > > +   depends on OF_GPIO > >

Re: [PATCH v30 00/12] Landlock LSM

On 19/03/2021 00:26, James Morris wrote: > I've queued this patchset here: > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > landlock_lsm > > and pulled it into next-testing, which will get it coverage in linux-next. > > All going well, I'll aim to push this to Li

Re: [PATCH][next] loop: Fix missing max_active argument in alloc_workqueue call

On Thu, Mar 18, 2021 at 02:12:10PM -0600, Jens Axboe wrote: > On 3/18/21 9:16 AM, Colin King wrote: > > From: Colin Ian King > > > > The 3rd argument to alloc_workqueue should be the max_active count, > > however currently it is the lo->lo_number that is intended for the > > loop%d number. Fix th

Re: [PATCH] x86/sgx: Avoid returning NULL in __sgx_alloc_epc_page()

On Fri, Mar 19, 2021 at 05:22:56PM +0200, Jarkko Sakkinen wrote: > I did misread it for the first time. > > So let's sanity: you *are* going to squash the patches together because > that way it's factors easier to backport the whole thing? > > Is this the correct understanding? I squashed Kai's

Re: [PATCH v5] Added AMS tsl2591 driver implementation

On Fri, Mar 19, 2021 at 2:45 AM Joe Sandom wrote: > O Sat, Mar 13, 2021 at 07:15:54PM +, Jonathan Cameron wrote: > > On Tue, 9 Mar 2021 01:17:15 + > > Joe Sandom wrote: > Thanks for the feedback Jonathan, glad to hear that we're nearly ready > to merge :). The changes for V6 are complet

Re: [PATCH] drm: bridge: adv7511: Support I2S IEC958 encoded PCM format

Hey Sia, Thanks for the patch, it looks good to me. Reviewed-by: Robert Foss On Fri, 12 Mar 2021 at 10:09, Sia Jee Heng wrote: > > Support IEC958 encoded PCM format for ADV7511 so that ADV7511 HDMI > audio driver can accept the IEC958 data from the I2S input. > > Signed-off-by: Sia Jee Heng >

Re: [PATCH][next] loop: Fix missing max_active argument in alloc_workqueue call

On Thu, Mar 18, 2021 at 03:16:26PM +, Colin King wrote: > From: Colin Ian King > > The 3rd argument to alloc_workqueue should be the max_active count, > however currently it is the lo->lo_number that is intended for the > loop%d number. Fix this by adding in the missing max_active count. >

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

On 21/03/19 05:37PM, Leon Romanovsky wrote: > On Fri, Mar 19, 2021 at 08:53:17PM +0530, Amey Narkhede wrote: > > On 21/03/19 03:05PM, Leon Romanovsky wrote: > > <...> > > > > > > It was exactly the reason why I think that VM usecase presented by > > > > > you is not viable. > > > > > > > > > Well I

Re: linux-next: manual merge of the net tree with Linus' tree

On Fri, Mar 19, 2021 at 08:29:39AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net tree got a conflict in: > > drivers/net/can/usb/peak_usb/pcan_usb_fd.c > > between commit: > > 6417f03132a6 ("module: remove never implemented MODULE_SUPPORTED_DEVICE") > > f

Re: [PATCH][next] loop: Fix missing max_active argument in alloc_workqueue call

On 19/03/2021 15:54, Dan Schatzberg wrote: > On Thu, Mar 18, 2021 at 03:16:26PM +, Colin King wrote: >> From: Colin Ian King >> >> The 3rd argument to alloc_workqueue should be the max_active count, >> however currently it is the lo->lo_number that is intended for the >> loop%d number. Fix thi

Re: [PATCH v2 14/14] objtool,x86: Rewrite retpoline thunk calls

On Fri, Mar 19, 2021 at 10:30:26AM -0500, Josh Poimboeuf wrote: > On Fri, Mar 19, 2021 at 09:06:44AM +0100, Peter Zijlstra wrote: > > > Also doesn't the alternative code already insert nops? > > > > Problem is that the {call,jmp} *%\reg thing is not fixed length. They're > > 2 or 3 bytes depending

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

On Fri, Mar 19, 2021 at 02:59:47PM +0200, Leon Romanovsky wrote: > On Thu, Mar 18, 2021 at 07:34:56PM +0100, Enrico Weigelt, metux IT consult > wrote: > > On 18.03.21 18:22, Leon Romanovsky wrote: > > > > > Which email client do you use? Your responses are grouped as > > > one huge block without

[GIT PULL] Power management fixes for v5.12-rc4

Hi Linus, Please pull from the tag git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-5.12-rc4 with top-most commit 49cb71a77ce760f20487c38f891aa3132bef782e Merge branch 'pm-core' on top of commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0 Linux 5.12-rc3 to receive powe

Re: [PATCH v2 0/3] perf-stat: share hardware PMCs with BPF

Hi Arnaldo, On Sat, Mar 20, 2021 at 12:35 AM Arnaldo Carvalho de Melo wrote: > > Em Fri, Mar 19, 2021 at 09:54:59AM +0900, Namhyung Kim escreveu: > > On Fri, Mar 19, 2021 at 9:22 AM Song Liu wrote: > > > > On Mar 18, 2021, at 5:09 PM, Arnaldo wrote: > > > > On March 18, 2021 6:14:34 PM GMT-03:0

Re: [PATCH] x86/sgx: Avoid returning NULL in __sgx_alloc_epc_page()

On 3/19/21 8:52 AM, Borislav Petkov wrote: > On Fri, Mar 19, 2021 at 05:22:56PM +0200, Jarkko Sakkinen wrote: >> I did misread it for the first time. >> >> So let's sanity: you *are* going to squash the patches together because >> that way it's factors easier to backport the whole thing? >> >> Is t

Re: [PATCH net-next 3/4] net: ipa: introduce ipa_assert()

On 3/19/21 10:32 AM, Leon Romanovsky wrote: +/* Verify the expression yields true, and fail at build time if possible */ +#define ipa_assert(dev, expr) \ + do { \ + if (__builtin_constant_p(expr)) \ + compiletime_assert(expr, __ipa_failure_msg(expr)); \ +

Re: [PATCH v6 resend 0/3] mm, vsprintf: dump full information of page flags in pGp

On Fri 2021-03-19 18:12:43, Yafang Shao wrote: > The existed pGp shows the names of page flags only, rather than the full > information including section, node, zone, last cpuipid and kasan tag. > While it is not easy to parse these information manually because there > are so many flavors. We'd bet

Re: [PATCH v4 3/9] x86/entry: Convert ret_from_fork to C

On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote: > ret_from_fork is written in asm, slightly differently, for x86_32 and > x86_64. Convert it to C. > +__visible void noinstr ret_from_fork(struct task_struct *prev, > + int (*kernel_thread_fn)(void *), > +

Re: [PATCH v2 2/2] driver core: add helper for deferred probe reason setting

Hello Andy, On 19.03.21 13:16, Andy Shevchenko wrote: > On Fri, Mar 19, 2021 at 1:46 PM Ahmad Fatoum wrote: >> On 19.03.21 12:13, Andy Shevchenko wrote: >>> On Fri, Mar 19, 2021 at 1:05 PM Ahmad Fatoum >>> wrote: We now have three places within the same file doing the same operation >

Re: [PATCH] x86/sgx: Avoid returning NULL in __sgx_alloc_epc_page()

On Fri, Mar 19, 2021 at 08:59:46AM -0700, Dave Hansen wrote: > It's probably best to squash my patch in. The uninitialized value could > *theoretically* cause the search to start at the wrong node and then end > before every node has been visited. That could cause premature > allocation failures.

Re: [PATCH v4 4/9] kentry: Simplify the common syscall API

On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote: > The new common syscall API had a large and confusing API surface. Simplify > it. Now there is exactly one way to use it. It's a bit more verbose than > the old way for the simple x86_64 native case, but it's much easier to use > right, and

Re: [PATCH 1/7] mm/page_alloc: Move gfp_allowed_mask enforcement to prepare_alloc_pages

On 3/12/21 4:43 PM, Mel Gorman wrote: > __alloc_pages updates GFP flags to enforce what flags are allowed > during a global context such as booting or suspend. This patch moves the > enforcement from __alloc_pages to prepare_alloc_pages so the code can be > shared between the single page allocator

Re: [PATCH 1/6] iommu: Move IOVA power-of-2 roundup into allocator

On 2021-03-19 13:25, John Garry wrote: Move the IOVA size power-of-2 rcache roundup into the IOVA allocator. This is to eventually make it possible to be able to configure the upper limit of the IOVA rcache range. Signed-off-by: John Garry --- drivers/iommu/dma-iommu.c | 8 -- drivers/

Re: [PATCH v2 0/3] perf-stat: share hardware PMCs with BPF

> On Mar 19, 2021, at 8:58 AM, Namhyung Kim wrote: > > Hi Arnaldo, > > On Sat, Mar 20, 2021 at 12:35 AM Arnaldo Carvalho de Melo > wrote: >> >> Em Fri, Mar 19, 2021 at 09:54:59AM +0900, Namhyung Kim escreveu: >>> On Fri, Mar 19, 2021 at 9:22 AM Song Liu wrote: > On Mar 18, 2021, at 5:0

Re: [PATCH] scsi: csiostor: Fix a typo

On Fri, 19 Mar 2021, Bhaskar Chowdhury wrote: s/boudaries/boundaries/ Signed-off-by: Bhaskar Chowdhury Acked-by: Randy Dunlap --- drivers/scsi/csiostor/csio_hw_t5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/csiostor/csio_hw_t5.c b/drivers/scsi/c

Re: [PATCH v2 01/17] add support for Clang CFI

On Fri, Mar 19, 2021 at 6:52 AM Paul E. McKenney wrote: > > On Fri, Mar 19, 2021 at 01:26:59PM +0100, Peter Zijlstra wrote: > > On Thu, Mar 18, 2021 at 04:48:43PM -0700, Sami Tolvanen wrote: > > > On Thu, Mar 18, 2021 at 3:29 PM Peter Zijlstra > > > wrote: > > > > > > > > On Thu, Mar 18, 2021 at

Re: [PATCH 8/9] vfio/pci: export nvlink2 support into vendor vfio_pci drivers

On Fri, Mar 19, 2021 at 09:23:41AM -0600, Alex Williamson wrote: > On Wed, 10 Mar 2021 14:57:57 +0200 > Max Gurtovoy wrote: > > On 3/10/2021 8:39 AM, Alexey Kardashevskiy wrote: > > > On 09/03/2021 19:33, Max Gurtovoy wrote: > > >> +static const struct pci_device_id nvlink2gpu_vfio_pci_table[] =

Re: [PATCH v4 7/9] kentry: Add debugging checks for proper kentry API usage

On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote: > + > +#define DEBUG_ENTRY_WARN_ONCE(condition, format...) do {} while (0) So we have a stub for !DEBUG > +static __always_inline void kentry_cpu_depth_add(unsigned int n) {} > +static void kentry_cpu_depth_check(unsigned int n) {} > +static __

[RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata

Currently, if an architecture selects CONFIG_PCI_DOMAINS_GENERIC, the ->sysdata in bus and bridge will be treated as struct pci_config_window, which is created by generic ECAM using the data from acpi. However, for a virtualized PCI bus, there might be no enough data in of or acpi table to create

Re: [RFC PATCH v2 2/8] arm64: Implement frame types

On Fri, Mar 19, 2021 at 10:02:52AM -0500, Madhavan T. Venkataraman wrote: > On 3/19/21 9:40 AM, Madhavan T. Venkataraman wrote: > > Actually now I look again it's just not adding anything on EL2 entries > > at all, they use a separate set of macros which aren't updated - this > > will only update

Re: [PATCH 8/9] vfio/pci: export nvlink2 support into vendor vfio_pci drivers

On Fri, Mar 19, 2021 at 01:17:22PM -0300, Jason Gunthorpe wrote: > I think we talked about this.. We still need a better way to control > binding of VFIO modules - now that we have device-specific modules we > must have these match tables to control what devices they connect > to. > > Previously t

Re: [PATCH v10 0/3] Charge loop device i/o to issuing cgroup

On Fri, Mar 19, 2021 at 8:51 AM Dan Schatzberg wrote: > > On Thu, Mar 18, 2021 at 05:56:28PM -0700, Shakeel Butt wrote: > > > > We need something similar for mem_cgroup_swapin_charge_page() as well. > > > > It is better to take this series in mm tree and Jens is ok with that [1]. > > > > [1] > >

[RFC 0/2] PCI: Introduce pci_ops::use_arch_sysdata

Hi Bjorn, I'm currently working on virtual PCI support for Hyper-V ARM64 guests. Similar to virtual PCI on x86 Hyper-V guests, the PCI root bus is not probed via ACPI (or of), it's probed from Hyper-V VMbus, therefore it doesn't have config window. Since ARM64 is a CONFIG_PCI_DOMAINS_GENERIC=y, P

[RFC 2/2] PCI: hv: Tell PCI core arch-specific sysdata is used

Use the newly introduced ->use_arch_sysdata to tell PCI core, we still use the arch-specific sysdata way to set up root PCI buses on CONFIG_PCI_DOMAINS_GENERIC=y architectures, this is preparation fo Hyper-V ARM64 guest virtual PCI support. Signed-off-by: Boqun Feng (Microsoft) --- drivers/pci/c

Re: [PATCH V6 4/4] cpufreq: CPPC: Add support for frequency invariance

On Wed, Mar 10, 2021 at 6:24 AM Viresh Kumar wrote: > > The Frequency Invariance Engine (FIE) is providing a frequency scaling > correction factor that helps achieve more accurate load-tracking. > > Normally, this scaling factor can be obtained directly with the help of > the cpufreq drivers as th

Re: [PATCH] MAINTAINERS: Add co-maintainer for Qualcomm tsens thermal drivers

On 19/03/2021 16:37, Thara Gopinath wrote: > Add myself as the maintainer for Qualcomm tsens drivers so that I > can help Daniel by taking care of/reviewing changes to these drivers. > > Signed-off-by: Thara Gopinath > --- Applied, thanks -- Linaro.org │ Open source s

Re: [PATCH 2/7] mm/page_alloc: Rename alloced to allocated

On 3/12/21 4:43 PM, Mel Gorman wrote: > Review feedback of the bulk allocator twice found problems with "alloced" > being a counter for pages allocated. The naming was based on the API name > "alloc" and was based on the idea that verbal communication about malloc > tends to use the fake word "mall

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

On Fri, 19 Mar 2021 14:59:47 +0200 Leon Romanovsky wrote: > On Thu, Mar 18, 2021 at 07:34:56PM +0100, Enrico Weigelt, metux IT consult > wrote: > > On 18.03.21 18:22, Leon Romanovsky wrote: > > > > > Which email client do you use? > > > Your responses are grouped as one huge block without any

Re: [PATCH][RESEND] Revert "PM: ACPI: reboot: Use S5 for reboot"

On Fri, Mar 19, 2021 at 3:02 AM Josef Bacik wrote: > > On 3/18/21 1:42 AM, Kai-Heng Feng wrote: > > On Thu, Mar 18, 2021 at 1:25 AM Josef Bacik wrote: > > [snipped] > >> "shutdown now" works fine with and without your patch. Thanks, > > > > Rafael, > > Please revert the patch while we are workin

Re: [PATCH v4] mm: cma: support sysfs

19.03.2021 18:50, Greg Kroah-Hartman пишет: >> Then initialization order won't be a problem. > I don't understand the problem here, what is wrong with the patch as-is? The cma->stat is NULL at the time when CMA is used on ARM because cma->stat is initialized at the subsys level. This is the proble

Re: [PATCH v23 00/28] Control-flow Enforcement: Shadow Stack

On 3/17/2021 2:18 AM, Ingo Molnar wrote: * Yu, Yu-cheng wrote: On 3/16/2021 2:15 PM, Peter Zijlstra wrote: On Tue, Mar 16, 2021 at 08:10:26AM -0700, Yu-cheng Yu wrote: Control-flow Enforcement (CET) is a new Intel processor feature that blocks return/jump-oriented programming attacks. Deta

Re: [PATCH 4/4] PCI/sysfs: Allow userspace to query and set device reset mechanism

On Fri, Mar 19, 2021 at 10:57:11AM -0500, Bjorn Helgaas wrote: > On Fri, Mar 19, 2021 at 02:59:47PM +0200, Leon Romanovsky wrote: > > On Thu, Mar 18, 2021 at 07:34:56PM +0100, Enrico Weigelt, metux IT consult > > wrote: > > > On 18.03.21 18:22, Leon Romanovsky wrote: > > > > > > > Which email cli

Re: [PATCH 3/6] iova: Allow rcache range upper limit to be configurable

On 2021-03-19 13:25, John Garry wrote: Some LLDs may request DMA mappings whose IOVA length exceeds that of the current rcache upper limit. This means that allocations for those IOVAs will never be cached, and always must be allocated and freed from the RB tree per DMA mapping cycle. This has a

Re: [PATCH V3] exit: trigger panic when global init has exited

On 03/18, Eric W. Biederman wrote: > > Oleg Nesterov writes: > > > On 03/18, qianli zhao wrote: > >> > >> In addition, the patch also protects the init process state to > >> successfully get usable init coredump. > > > > Could you spell please? > > > > Does this connect to SIGNAL_GROUP_EXIT check?

Re: [RFC PATCH v2 2/8] arm64: Implement frame types

On 3/19/21 11:20 AM, Mark Brown wrote: > On Fri, Mar 19, 2021 at 10:02:52AM -0500, Madhavan T. Venkataraman wrote: >> On 3/19/21 9:40 AM, Madhavan T. Venkataraman wrote: > >>> Actually now I look again it's just not adding anything on EL2 entries >>> at all, they use a separate set of macros wh

Re: [PATCH] ia64: fix format string for ia64-acpi-cpu-freq

On Mon, Mar 15, 2021 at 4:19 AM Viresh Kumar wrote: > > On 13-03-21, 10:42, Sergei Trofimovich wrote: > > Fix warning with %lx / s64 mismatch: > > > > CC [M] drivers/cpufreq/ia64-acpi-cpufreq.o > > drivers/cpufreq/ia64-acpi-cpufreq.c: In function 'processor_get_pstate': > > warning: f

Re: [PATCH v10 0/3] Charge loop device i/o to issuing cgroup

On Fri, Mar 19, 2021 at 09:20:16AM -0700, Shakeel Butt wrote: > One suggestion would be to make get_mem_cgroup_from_mm() more generic > (i.e. handle !mm && active_memcg() case) and avoid > get_mem_cgroup_from_current() as it might go away. Yeah, that occurred to me as well. I'll take a stab at doi

Re: [PATCH 8/9] vfio/pci: export nvlink2 support into vendor vfio_pci drivers

On Fri, Mar 19, 2021 at 05:20:33PM +0100, Christoph Hellwig wrote: > On Fri, Mar 19, 2021 at 01:17:22PM -0300, Jason Gunthorpe wrote: > > I think we talked about this.. We still need a better way to control > > binding of VFIO modules - now that we have device-specific modules we > > must have thes

[PATCH] powercap/drivers/dtpm: Add dtpm devfreq with energy model support

Currently the dtpm supports the CPUs via cpufreq and the energy model. This change provides the same for the device which supports devfreq. Each device supporting devfreq and having an energy model can register themselves in the list of supported devices. The concept is the same as the cpufreq dt

Re: [PATCH v4] mm: cma: support sysfs

On Fri, Mar 19, 2021 at 07:24:05PM +0300, Dmitry Osipenko wrote: > 19.03.2021 18:50, Greg Kroah-Hartman пишет: > >> Then initialization order won't be a problem. > > I don't understand the problem here, what is wrong with the patch as-is? > > The cma->stat is NULL at the time when CMA is used on A

Re: [PATCH 01/10] alpha: use libata instead of the legacy ide driver

Al Viro writes: > ... > > Do you have reports of libata variants of drivers actually tested on > those? PATA_CMD64X works fine on my 164LX for many years, last tested with 5.12-rc3. (with a caveat: in my setup with CF card DMA is broken, but it is broken with BLK_DEV_CMD64X as well).

Re: [PATCH V3] exit: trigger panic when global init has exited

On 03/19, qianli zhao wrote: > > > But then I don't understand the SIGNAL_GROUP_EXIT check added by your > > patch. Do we really need it if we want to avoid zap_pid_ns_processes() > > when the global init exits? > > I think check SIGNAL_GROUP_EXIT is necessary,or panic() will happen > after all ini

RE: [PATCH v2] usb: typec: tcpm: Invoke power_supply_changed for tcpm-source-psy-

On 18 March 2021 20:40, Badhri Jagan Sridharan wrote: > > Regarding selecting PDOs or PPS APDOs, surely we should only notify of a > change > > when we reach SNK_READY which means a new contract has been established? > Until > > that point it's possible any requested change could be rejected so wh

Re: [PATCH] include: acpi: A typo fix in the file cppc_acpi.h

On Wed, Mar 17, 2021 at 6:17 AM Randy Dunlap wrote: > > On 3/16/21 10:06 PM, Bhaskar Chowdhury wrote: > > > > s/folowing/following/ > > > > Signed-off-by: Bhaskar Chowdhury > > Acked-by: Randy Dunlap > > > --- > > include/acpi/cppc_acpi.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-

Re: [PATCH V3] exit: trigger panic when global init has exited

On 03/19, qianli zhao wrote: > > I will think about the risks of movement of the decrement of > signal->live before exit_signal(). > If is difficult to judge movement of the decrement of signal->live is > safe,how about only test 'signal->live==1' not use group_dead? > > Such as: > diff --git a/ker

Re: [PATCH 8/9] vfio/pci: export nvlink2 support into vendor vfio_pci drivers

On Fri, Mar 19, 2021 at 01:28:48PM -0300, Jason Gunthorpe wrote: > The wrinkle I don't yet have an easy answer to is how to load vfio_pci > as a universal "default" within the driver core lazy bind scheme and > still have working module autoloading... I'm hoping to get some > research into this..

Re: [PATCH v3 3/3] iio: adc: add ADC driver for the TI TSC2046 controller

Hi Oleksij, I love your patch! Perhaps something to improve: [auto build test WARNING on linux/master] [also build test WARNING on linus/master v5.12-rc3 next-20210319] [cannot apply to iio/togreg] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch

Re: [PATCH] spi: stm32: Fix use-after-free on unbind

On Thu, 18 Mar 2021 08:24:50 +0100, Alain Volmat wrote: > stm32_spi_remove() accesses the driver's private data after calling > spi_unregister_master() even though that function releases the last > reference on the spi_master and thereby frees the private data. > > Fix by switching over to the new

Re: [PATCH -next] ASoC: rt1019: make symbol 'rt1019_i2c_driver' static

On Fri, 19 Mar 2021 09:41:02 +, 'w00385741 wrote: > The sparse tool complains as follows: > > sound/soc/codecs/rt1019.c:927:19: warning: > symbol 'rt1019_i2c_driver' was not declared. Should it be static? > > This symbol is not used outside of rt1019.c, so this > commit marks it static. App

[PATCH v5 0/7] Use obj_cgroup APIs to charge kmem pages

Since Roman series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are s

[PATCH v5 3/7] mm: memcontrol: directly access page->memcg_data in mm/page_alloc.c

The page_memcg() is not suitable for use by page_expected_state() and page_bad_reason(). Because it can BUG_ON() for the slab pages when CONFIG_DEBUG_VM is enabled. As neither lru, nor kmem, nor slab page should have anything left in there by the time the page is freed, what we care about is whethe

[PATCH v5 2/7] mm: memcontrol: introduce obj_cgroup_{un}charge_pages

We know that the unit of slab object charging is bytes, the unit of kmem page charging is PAGE_SIZE. If we want to reuse obj_cgroup APIs to charge the kmem pages, we should pass PAGE_SIZE (as third parameter) to obj_cgroup_charge(). Because the size is already PAGE_SIZE, we can skip touch the objcg

[PATCH v5 1/7] mm: memcontrol: slab: fix obtain a reference to a freeing memcg

The rcu_read_lock/unlock only can guarantee that the memcg will not be freed, but it cannot guarantee the success of css_get (which is in the refill_stock when cached memcg changed) to memcg. rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg)

[PATCH v5 5/7] mm: memcontrol: use obj_cgroup APIs to charge kmem pages

Since Roman series "The new cgroup slab memory controller" applied. All slab objects are charged via the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are st

[PATCH v5 4/7] mm: memcontrol: change ug->dummy_page only if memcg changed

Just like assignment to ug->memcg, we only need to update ug->dummy_page if memcg changed. So move it to there. This is a very small optimization. Signed-off-by: Muchun Song Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt --- mm/memcontrol.c | 2 +- 1 file changed, 1 insertion(+), 1 deleti

[PATCH v5 6/7] mm: memcontrol: inline __memcg_kmem_{un}charge() into obj_cgroup_{un}charge_pages()

There is only one user of __memcg_kmem_charge(), so manually inline __memcg_kmem_charge() to obj_cgroup_charge_pages(). Similarly manually inline __memcg_kmem_uncharge() into obj_cgroup_uncharge_pages() and call obj_cgroup_uncharge_pages() in obj_cgroup_release(). This is just code cleanup without

[PATCH v5 7/7] mm: memcontrol: move PageMemcgKmem to the scope of CONFIG_MEMCG_KMEM

The page only can be marked as kmem when CONFIG_MEMCG_KMEM is enabled. So move PageMemcgKmem() to the scope of the CONFIG_MEMCG_KMEM. As a bonus, on !CONFIG_MEMCG_KMEM build some code can be compiled out. Signed-off-by: Muchun Song Acked-by: Roman Gushchin Reviewed-by: Shakeel Butt Acked-by: J

Re: [PATCH] MAINTAINERS: Add entry for the software nodes

On Thu, Mar 11, 2021 at 12:50 PM Andy Shevchenko wrote: > > On Thu, Mar 11, 2021 at 11:25:21AM +0300, Heikki Krogerus wrote: > > Making Andy and myself (Heikki) the designated reviewers of > > the thing. The software node mailing list shall be > > linux-a...@vger.kernel.org for now. > > Acked-by:

Re: [PATCHv2 3/3] media: uvcvideo: add UVC 1.5 ROI control

Hi Sergey On Fri, Mar 19, 2021 at 6:35 AM Sergey Senozhatsky wrote: > > On (21/03/18 22:19), Ricardo Ribalda wrote: > > > > > > May I please ask for more opinions on this? > > > > Could you try setting the roi in a loop in your device and verify that > > it accepts all the values with no modifica

[PATCH v3 00/19] media: gmsl: Reliability improvement

Hello, series following: https://patchwork.linuxtv.org/project/linux-media/list/?series=4650 https://patchwork.linuxtv.org/project/linux-media/list/?series=4861 Compared to the following iteration it seems RDACM21 is finally fixed \o/ I'll sum-up the issue here from the last email exchange: --

[PATCH v3 01/19] media: i2c: max9286: Adjust parameters indent

The parameters to max9286_i2c_mux_configure() fits on the previous line. Adjust it. Cosmetic change only. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/media/i2c/max9286.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --gi

[PATCH v3 02/19] media: i2c: max9286: Rename reverse_channel_mv

Rename the reverse_channel_mv variable to init_rev_chan_mv as the next patch will cache the reverse channel amplitude in a new driver variable. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/media/i2c/max9286.c | 11 ++- 1 file changed

[PATCH v3 03/19] media: i2c: max9286: Cache channel amplitude

Cache the current channel amplitude in a driver variable to skip updating it if the newly requested value is the same as the currently configured one. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/media/i2c/max9286.c | 13 ++--- 1 fil

[PATCH v3 05/19] media: v4l2-subdev: De-deprecate init() subdev op

The init() subdev core operation is deemed to be deprecated for new subdevice drivers. However it could prove useful for complex architectures to defer operation that require access to the communication bus if said bus is not available (or fully configured) at the time when the subdevice probe() fu

[PATCH v3 04/19] media: i2c: max9286: Define high channel amplitude

Provide a macro to define the reverse channel amplitude to be used to compensate the remote serializer noise immunity. While at it, update a comment. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/media/i2c/max9286.c | 5 +++-- 1 file changed

[PATCH v3 07/19] media: i2c: max9286: Rework comments in .bound()

Rephrase a comment in .bound() callback to make it clear we register a subdev notifier and remove a redundant comment about disabling i2c auto-ack. No functional changes intended. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/media/i2c/max92

[PATCH v3 06/19] media: gmsl: Reimplement initialization sequence

The current probe() procedure of the RDACM20 and RDACM20 GMSL cameras is performed with the embedded MAX9271 serializer's noise immunity threshold disabled. Once the camera has been initialized by probing the embedded chips, the threshold is enabled and then compensated on the deserializer's side b

[PATCH v3 09/19] media: i2c: max9271: Introduce wake_up() function

The MAX9271 chip manual prescribes a delay of 5 milliseconds after the chip exits from low power state. Add a new function to the max9271 library driver that wakes up the chip with a dummy i2c transaction and implements the correct delay of 5 milliseconds after the chip exits from low power state.

[PATCH v3 08/19] media: i2c: max9271: Check max9271_write() return

Check the return value of the max9271_write() function in the max9271 library driver. While at it, modify an existing condition to be made identical to other checks. Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Jacopo Mondi --- drivers/media/i2c/max9271.c | 30

[PATCH v3 10/19] media: i2c: rdamc21: Fix warning on u8 cast

Sparse reports a warning on a cast to u8 of a 16 bits constant. drivers/media/i2c/rdacm21.c:348:62: warning: cast truncates bits from constant value (300a becomes a) Even if the behaviour is intended, silence the sparse warning replacing the cast with a bitwise & operation. Fixes: a59f853b3b4b (

[PATCH v3 11/19] media: i2c: rdacm21: Add dealy after OV490 reset

Add a delay after the OV490 chip is put in reset state. The reset signal shall be held for at least 250 useconds. Signed-off-by: Jacopo Mondi --- drivers/media/i2c/rdacm21.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/r

[PATCH v3 12/19] media: i2c: rdacm21: Fix OV10640 powerup

The OV10640 image sensor powerdown signal is controlled by the first line of the OV490 GPIO pad #1, but the pad #0 identifier OV490_GPIO_OUTPUT_VALUE0 was erroneously used. As a result the image sensor powerdown signal was never asserted but was left floating and kept high by an internal pull-up re

<    4   5   6   7   8   9   10   11   12   13   >