vgic_uaccess() takes a struct vgic_io_device argument, converts it
to a struct kvm_io_device and passes it to the read/write accessor
functions, which convert it back to a struct vgic_io_device.
Avoid the indirection by passing the struct vgic_io_device argument
directly to vgic_uaccess_{read,write
The tests exercise the VGIC_V3 device creation including the
associated KVM_DEV_ARM_VGIC_GRP_ADDR group attributes:
- KVM_VGIC_V3_ADDR_TYPE_DIST/REDIST
- KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION
Some other tests dedicate to KVM_DEV_ARM_VGIC_GRP_REDIST_REGS group
and especially the GICR_TYPER read. The
Commit 23bde34771f1 ("KVM: arm64: vgic-v3: Drop the
reporting of GICR_TYPER.Last for userspace") temporarily fixed
a bug identified when attempting to access the GICR_TYPER
register before the redistributor region setting, but dropped
the support of the LAST bit.
Emulating the GICR_TYPER.Last bit
On Wed, Mar 31, 2021 at 12:08 AM Peter Zijlstra wrote:
>
> On Tue, Mar 30, 2021 at 11:13:55AM +0800, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> > > > u32 a = 0x55aa66bb;
> > > > u16 *ptr = &a;
> >
This series enables future IP trace features Embedded Trace Extension
(ETE) and Trace Buffer Extension (TRBE). This series applies on
kvmarm/fixes tree. A standalone tree is also available here [0].
The queued patches (almost there) are included in this posting for
the sake of constructing a tree f
Allocate a byte for advertising the PMU specific format type
of the given AUX record. A PMU could end up providing hardware
trace data in multiple format in a single session.
e.g, The format of hardware buffer produced by CoreSight ETM
PMU depends on the type of the "sink" device used for collecti
CoreSight PMU supports aux-buffer for the ETM tracing. The trace
generated by the ETM (associated with individual CPUs, like Intel PT)
is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
The TMC-ETR applies formatting of the raw ETM trace data, as it
can collect traces from multiple ET
tsb csync synchronizes the trace operation of instructions.
The instruction is a nop when FEAT_TRF is not implemented.
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Catalin Marinas
Cc: Will Deacon
Acked-by: Catalin Marinas
Signed-off-by: Suzuki K Poulose
---
arch/arm64/include/asm/barrier.h | 1 +
At the moment, we check the availability of SPE on the given
CPU (i.e, SPE is implemented and is allowed at the host) during
every guest entry. This can be optimized a bit by moving the
check to vcpu_load time and recording the availability of the
feature on the current CPU via a new flag. This wil
Rather than falling to an "unhandled access", inject add an explicit
"undefined access" for TRFCR_EL1 access from the guest.
Cc: Marc Zyngier
Cc: Will Deacon
Cc: Mathieu Poirier
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kvm/sys_regs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/a
From: Anshuman Khandual
This adds TRBE related registers and corresponding feature macros.
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Suzuki K Poulose
Reviewed-by: Suzuki K Poulose
Reviewed-by: Mike Leach
Reviewed-by: Mathieu Poirier
Acked-by: Catalin Marinas
Signed-off-by: Anshuman Khandual
When a sink is not specified by the user, the etm perf driver
finds a suitable sink automatically, based on the first ETM
where this event could be scheduled. Then we allocate the
sink buffer based on the selected sink. This is fine for a
CPU bound event as the "sink" is always guaranteed to be
rea
For a nvhe host, the EL2 must allow the EL1&0 translation
regime for TraceBuffer (MDCR_EL2.E2TB == 0b11). This must
be saved/restored over a trip to the guest. Also, before
entering the guest, we must flush any trace data if the
TRBE was enabled. And we must prohibit the generation
of trace while w
ETE may not implement the OS lock and instead could rely on
the PE OS Lock for the trace unit access. This is indicated
by the TRCOLSR.OSM == 0b100. Add support for handling the
PE OS lock
Cc: Mike Leach
Reviewed-by: mike.leach
Reviewed-by: Mathieu Poirier
Signed-off-by: Suzuki K Poulose
---
Add support for handling the system registers for Embedded Trace
Extensions (ETE). ETE shares most of the registers with ETMv4 except
for some and also adds some new registers. Re-arrange the ETMv4x list
to share the common definitions and add the ETE sysreg support.
Cc: Mike Leach
Reviewed-by: M
If a graph node is not found for a given node, of_get_next_endpoint()
will emit the following error message :
OF: graph: no port node found in /
If the given component doesn't have any explicit connections (e.g,
ETE) we could simply ignore the graph parsing. As for any legacy
component where thi
If the CPU implements Arm v8.4 Trace filter controls (FEAT_TRF),
move the ETM to trace prohibited region using TRFCR, while disabling.
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Anshuman Khandual
Reviewed-by: Mike Leach
Reviewed-by: Mathieu Poirier
Signed-off-by: Suzuki K Poulose
---
.../coresi
Document the device tree bindings for Embedded Trace Extensions.
ETE can be connected to legacy coresight components and thus
could optionally contain a connection graph as described by
the CoreSight bindings.
Cc: devicet...@vger.kernel.org
Cc: Mathieu Poirier
Cc: Mike Leach
Reviewed-by: Rob Her
From: Anshuman Khandual
Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
accessible via the system registers. The TRBE supports different addressing
modes including CPU virtual address and buffer modes including the circular
buffer mode. The TRBE buffer is addressed by a b
The context associated with an ETM for a given perf event
includes :
- handle -> the perf output handle for the AUX buffer.
- the path for the trace components
- the buffer config for the sink.
The path and the buffer config are part of the "aux_priv" data
(etm_event_data) setup by the setup
From: Anshuman Khandual
Add support for dedicated sinks that are bound to individual CPUs. (e.g,
TRBE). To allow quicker access to the sink for a given CPU bound source,
keep a percpu array of the sink devices. Also, add support for building
a path to the CPU local sink from the ETM.
This adds a
Document the device tree bindings for Trace Buffer Extension (TRBE).
Cc: Anshuman Khandual
Cc: Mathieu Poirier
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring
Signed-off-by: Suzuki K Poulose
---
.../devicetree/bindings/arm/trbe.yaml | 49 +++
M
From: Anshuman Khandual
Add documentation for the TRBE under trace/coresight.
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Reviewed-by: Mathieu Poirier
Signed-off-by: Anshuman Khandual
[ Split from the TRBE driver patch ]
Signed-off-by: Suzuki K Poulose
---
.../trace/coresight/coresig
Add ETE as one of the supported device types we support
with ETM4x driver. The devices are named following the
existing convention as ete.
ETE mandates that the trace resource status register is programmed
before the tracing is turned on. For the moment simply write to
it indicating TraceActive.
From: Anshuman Khandual
Add sysfs ABI documentation for the TRBE devices.
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Reviewed-by: Mathieu Poirier
Signed-off-by: Anshuman Khandual
[ Split from the TRBE driver patch ]
Signed-off-by: Suzuki K Poulose
On Tue, Mar 30, 2021 at 10:09 PM Waiman Long wrote:
>
> On 3/29/21 11:13 PM, Guo Ren wrote:
> > On Mon, Mar 29, 2021 at 8:50 PM Peter Zijlstra wrote:
> >> On Mon, Mar 29, 2021 at 08:01:41PM +0800, Guo Ren wrote:
> >>> u32 a = 0x55aa66bb;
> >>> u16 *ptr = &a;
> >>>
> >>> CPU0
of_get_mac_address() is commonly used to fetch the MAC address
from the device tree. It also supports reading it from a NVMEM
provider. But the latter is only possible for platform devices,
because only platform devices are searched for a matching device
node.
Add a second method to fetch the NVME
of_get_mac_address() returns a "const void*" pointer to a MAC address.
Lately, support to fetch the MAC address by an NVMEM provider was added.
But this will only work with platform devices. It will not work with
PCI devices (e.g. of an integrated root complex) and esp. not with DSA
ports.
There i
of_get_mac_address() already supports fetching the MAC address by an
nvmem provider. But until now, it was just working for platform devices.
Esp. it was not working for DSA ports and PCI devices. It gets more
common that PCI devices have a device tree binding since SoCs contain
integrated root com
This patchset removes all RT_TRACE usages left and definitions
The whole private tracing system is not tied to a configuration
symbol and the default behaviour is _trace nothing_. It's verbose
and relies on a private log level tracing doomed to be
removed.
The patchset consist on a first patch ap
Remove all of the RT_TRACE logs in hal/ and os_dep/ files as they
currently do nothing as they require the code to be modified by
hand in order to be turned on. This obviously has not happened
since the code was merged. Moreover it relies on an unneeded
private log level tracing which overrides the
remove RT_TRACE log definitions.
Remove all of the RT_TRACE logs in hal/ and os_dep/ file as they
currently do nothing as they require the code to be modified by
hand in order to be turned on. This obviously has not happened
since the code was merged. Moreover it relies on an unneeded
private log
Remove all commented out TR_TRACE calls.
Remove all of the RT_TRACE logs in hal/ and os_dep/ file as they
currently do nothing as they require the code to be modified by
hand in order to be turned on. This obviously has not happened
since the code was merged. Moreover it relies on an unneeded
priv
Remove all if, else if, else blocks left empty after
RT_TRACE macro deletion.
Suggested-by: Joe Perches
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 15 ---
drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c | 7 ---
drivers/staging/rtl8723b
Remove all empty #ifdef blocks left empty after
RT_TRACE macro deletion.
Suggested-by: Joe Perches
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
b/driver
Remove all unnecessary bracks in if blocks, after RT_TRACE macro
deletion
Suggested-by: Joe Perches
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 3 +--
drivers/staging/rtl8723bs/hal/rtl8723bs_xmit.c| 9 +++--
drivers/staging/rtl8723bs/hal/sdio_hal
fix the following post-commit hook checkpatch issues:
CHECK: Comparison to NULL could be written "!pwep"
147: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:442:
+ if (pwep == NULL)
CHECK: Comparison to NULL could be written "!skb"
226: FILE: drivers/staging/rtl8723bs/
fix following post-hook checkpatch issue:
WARNING: Comparisons should place the constant on the right side of the test
85: FILE: drivers/staging/rtl8723bs/hal/sdio_halinit.c:676:
+ if (_FAIL == ret)
Suggested-by: Joe Perches
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/sd
remove commented 5G code block in hal/hal_com_phycfg.c
which contained removed RT_TRACE log
as reported in the driver's TODO file:
- find and remove remaining code valid only for 5 GHz.
Most of the obvious ones have been removed,
but things like channel > 14 still exist.
so just
remove for-cycles left empty after RT_TRACE deletion
and unused index variables
Suggested-by: Joe Perches
Signed-off-by: Fabio Aiuto
---
drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c
On 4/5/2021 1:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.110 release.
> There are 74 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses s
InterfaceNumber und NumInterfaces in struct dvobj_priv are not used.
Signed-off-by: Martin Kaiser
---
drivers/staging/rtl8723bs/include/drv_types.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/drv_types.h
b/drivers/staging/rtl8723bs/include/drv_types.
Alexey Gladkov writes:
> The rlimit counter is tied to uid in the user_namespace. This allows
> rlimit values to be specified in userns even if they are already
> globally exceeded by the user. However, the value of the previous
> user_namespaces cannot be exceeded.
>
> To illustrate the impact o
A small bug below.
Eric
> diff --git a/kernel/signal.c b/kernel/signal.c
> index f2a1b898da29..1b537d9de447 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -413,49 +413,44 @@ void task_join_group_stop(struct task_struct *task)
> static struct sigqueue *
> __sigqueue_alloc(int sig
Alexey Gladkov writes:
> The current implementation of the ucounts reference counter requires the
> use of spin_lock. We're going to use get_ucounts() in more performance
> critical areas like a handling of RLIMIT_SIGPENDING.
>
> Now we need to use spin_lock only if we want to change the hashtabl
On Thu, Apr 01, 2021, Maxim Levitsky wrote:
> if new KVM_*_SREGS2 ioctls are used, the PDPTRs are
> part of the migration state and thus are loaded
> by those ioctls.
>
> Signed-off-by: Maxim Levitsky
> ---
> arch/x86/kvm/svm/nested.c | 15 +--
> 1 file changed, 13 insertions(+), 2 d
On Sun, Apr 04, 2021 at 10:28:45PM -0500, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> fdt_get_name() returns error values via a parameter pointer
> instead of in function return. Fix check for this error value
> in populate_node() and callers of populate_node().
>
> Chasing up the ca
Alexey Gladkov writes:
> Preface
> ---
> These patches are for binding the rlimit counters to a user in user namespace.
> This patch set can be applied on top of:
>
> git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git v5.12-rc4
>
> Problem
> ---
> The RLIMIT_NPROC, RLIMIT_MEMLOCK,
On Thu, Apr 01, 2021, Maxim Levitsky wrote:
> Small refactoring that will be used in the next patch.
>
> Signed-off-by: Maxim Levitsky
> ---
> arch/x86/kvm/kvm_cache_regs.h | 7 +++
> arch/x86/kvm/svm/svm.c| 6 ++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git
On Thu, Apr 01, 2021 at 11:59:25PM +, Luis Chamberlain wrote:
> On Mon, Mar 22, 2021 at 03:12:01PM -0700, Minchan Kim wrote:
> > On Mon, Mar 22, 2021 at 08:41:56PM +, Luis Chamberlain wrote:
> > >
> > > I would not call it *every* syfs knob as not all deal with things which
> > > are relat
On Mon, Apr 05, 2021 at 04:18:58PM +, Al Viro wrote:
> On Mon, Apr 05, 2021 at 01:44:37PM +0200, Christian Brauner wrote:
> > On Sun, Apr 04, 2021 at 08:17:21PM +, Al Viro wrote:
> > > On Sun, Apr 04, 2021 at 06:50:10PM +, Al Viro wrote:
> > >
> > > > > Yeah, I have at least namei.o
>
Fixes for the miscellaneous problems found during the review of the code.
Change Summary:
Patch 1/2, Change V1->V2:
[1] Fixed comments from Leon Romanovsky
Link: https://lkml.org/lkml/2021/4/4/14
Patch 2/2, Change V1->V2:
None
Salil Mehta (2):
net: hns3: Remove the left over redu
This removes the left over check and assignment which is no longer used
anywhere in the function and should have been removed as part of the
below mentioned patch.
Fixes: 012fcb52f67c ("net: hns3: activate reset timer when calling reset_event")
Signed-off-by: Salil Mehta
--
V1->V2:
[1] Fixed comm
Code to defer the reset(which caps the frequency of the reset) schedules the
timer and returns. Hence, following 'else-if' looks un-necessary.
Fixes: 9de0b86f6444 ("net: hns3: Prevent to request reset frequently")
Signed-off-by: Salil Mehta
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_ma
On Sun, Apr 04, 2021 at 02:30:58PM -0700, Linus Torvalds wrote:
> Well, if rc5 was bigger than usual, and I worried about what that
> meant for this release, rc6 is positively tiny.
>
> So I think it was just due to the usual random timing fluctuations,
> probably mainly networking updates (which
On 4/5/2021 1:52 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.28 release.
> There are 126 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 4/5/21 9:56 AM, Madhavan T. Venkataraman wrote:
>
>
> On 4/5/21 8:24 AM, Masami Hiramatsu wrote:
>> Hi Madhaven,
>>
>> On Sat, 3 Apr 2021 22:29:12 -0500
>> "Madhavan T. Venkataraman" wrote:
>>
>>
> Check for kretprobe
> ===
>
> For functions with a kretprobe
Hi
If you wanted to get some feedback regarding the code, then I added some
comments;
otherwise please disregard this email.
I think the two most important things are:
* consider using `devm_hwmon_device_register_with_info()` instead of manually
specifying the attributes;
* consider getti
On Mon, Apr 5, 2021 at 10:10 AM Guenter Roeck wrote:
>
> No change in test results since last week [..]
Let's ping Frank for the alignment issue. If that promised patch
isn't timely (and trivial), I really think that removing the alignment
check is by now the way forward for that libftd failure.
On Fri, Mar 19, 2021 at 03:34:50PM +0100, David Hildenbrand wrote:
> Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug and
> memory ballooning, I started questioning the existance of /dev/kmem.
>
> Comparing it with the /proc/kcore implementation, it does not seem to be
> able
Previously, the continue implementation in shmem_mcopy_atomic_pte was
incorrect for two main reasons:
- It didn't correctly skip some sections of code which make sense for
newly allocated pages, but absolutely don't make sense for
pre-existing page cache pages.
- Because shmem_mcopy_continue_
On Mon, Mar 29, 2021 at 6:34 PM John Stultz wrote:
>
> Commit 7bf168c8fe8c ("drm/msm: Fix speed-bin support not to
> access outside valid memory"), reworked the nvmem reading of
> "speed_bin", but in doing so dropped handling of the -ENOENT
> case which was previously documented as "fine".
>
> Th
On Fri, Apr 2, 2021 at 8:27 AM Kumar Kartikeya Dwivedi wrote:
>
> On Fri, Apr 02, 2021 at 05:49:29AM IST, Daniel Borkmann wrote:
> > On 3/31/21 11:44 AM, Kumar Kartikeya Dwivedi wrote:
> > > On Wed, Mar 31, 2021 at 02:55:47AM IST, Daniel Borkmann wrote:
> > > > Do we even need the _block variant?
On Mon, 5 Apr 2021 at 14:43, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.11.12 release.
> There are 152 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Res
From: Krzysztof Kozlowski
Include the generic serial.yaml dtschema so the child node like
"bluetooh" will be properly matched:
arch/arm/boot/dts/exynos4210-universal_c210.dt.yaml:
serial@1380: 'bluetooth' does not match any of the regexes:
'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Ko
On Fri, Mar 26, 2021 at 07:52:07PM +0100, Jonathan Neuschäfer wrote:
> On Wed, Mar 24, 2021 at 05:16:35PM +, Marc Zyngier wrote:
> > On Sat, 20 Mar 2021 18:16:04 +, Jonathan Neuschäfer
> > wrote:
[...]
> > > + /* Disable (mask) all interrupts */
> > > + writel(0x, aic->regs + AIC_
The pull request you sent on Mon, 5 Apr 2021 05:59:11 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-5.12-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0a50438c84363bd37fe18fe432888ae9a074dcab
Thank you!
--
Deet-doot-dot, I am a bot.
htt
On Sat, Apr 3, 2021 at 10:47 AM Alexei Starovoitov
wrote:
>
> On Sat, Apr 03, 2021 at 12:38:06AM +0530, Kumar Kartikeya Dwivedi wrote:
> > On Sat, Apr 03, 2021 at 12:02:14AM IST, Alexei Starovoitov wrote:
> > > On Fri, Apr 2, 2021 at 8:27 AM Kumar Kartikeya Dwivedi
> > > wrote:
> > > > [...]
> >
On 4/5/2021 1:53 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.265 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses s
On Mon, Apr 05, 2021 at 01:23:30PM +0800, Boqun Feng wrote:
> On Sun, Apr 04, 2021 at 09:30:38PM -0700, Paul E. McKenney wrote:
> > On Sun, Apr 04, 2021 at 09:01:25PM -0700, Paul E. McKenney wrote:
> > > On Mon, Apr 05, 2021 at 04:08:55AM +0100, Matthew Wilcox wrote:
> > > > On Sun, Apr 04, 2021 at
On 4/5/21 10:14 AM, Linus Torvalds wrote:
> On Mon, Apr 5, 2021 at 10:10 AM Guenter Roeck wrote:
>>
>> No change in test results since last week [..]
>
> Let's ping Frank for the alignment issue. If that promised patch
> isn't timely (and trivial), I really think that removing the alignment
> ch
Patchset of cleans up checks of "Blank lines aren't necessary before a close
brace '}'", "Lines should not end with a '('", "line over 100 characters",
and "Alignment should match open parenthesis" in file rtw_ap.c.
Beatriz Martins de Carvalho (4):
staging: rtl8723bs: core: Removed extra blank
Clean up check of "Blank lines aren't necessary before a close brace '}'"
in rtw_ap.c
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c
b/drivers/staging/rtl8723bs/cor
Cleans up checks of "Lines should not end with a '('"
with argument present in next line in file rtw_ap.c
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 98 ++---
1 file changed, 40 insertions(+), 58 deletions(-)
diff --git a/drivers
Cleans up checks of "Alignment should match open parenthesis"
in file rtw_ap.c
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c
b/dr
Cleans up warnings of "line over 100 characters" but avoinding
more than 90 characters in file rtw_ap.c
Signed-off-by: Beatriz Martins de Carvalho
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/stagi
Limiting the scope of the variable vector_ring_chain to the block where it
is used.
Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08
SoC")
Signed-off-by: Salil Mehta
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 ++-
1 file changed, 2 insertions(+), 1 de
Add support for the MT8167 power domains.
Signed-off-by: Fabien Parent
---
arch/arm64/boot/dts/mediatek/mt8167.dtsi | 68
1 file changed, 68 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8167.dtsi
b/arch/arm64/boot/dts/mediatek/mt8167.dtsi
index 1c5639ead62
syzbot has found a reproducer for the following issue on:
HEAD commit:e49d033b Linux 5.12-rc6
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12579f11d0
kernel config: https://syzkaller.appspot.com/x/.config?x=b8dbd3c72fdc
dashboard link: https://syz
On Thu 25 Feb 12:27 CST 2021, Thara Gopinath wrote:
> MAC_FAILED gets set in the status register if authenthication fails
> for ccm algorithms(during decryption). Add support to catch and flag
> this error.
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/common.c | 11 ---
>
From: Rob Clark
One would normally hope not to be under enough memory pressure to need
to swap GEM objects to disk backed swap. But memory backed zram swap
(as enabled on chromebooks, for example) can actually be quite fast
and useful on devices with less RAM. On a 4GB device, opening up ~4
mem
From: Rob Clark
If you mess something up, you don't really need to see the same warn on
splat 4000 times pumped out a slow debug UART port..
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 66 +--
drivers/gpu/drm/msm/msm_gem.h | 19 ++
2 fil
From: Rob Clark
So we don't have to duplicate the boilerplate for eviction.
This also lets us re-use the main scan loop for vmap shrinker.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 94 +-
1 file changed, 46 insertions(+), 48 deletions(-)
di
From: Rob Clark
Currently these always go together, either when we purge MADV_WONTNEED
objects or when the object is freed. But for unpin, we want to be able
to purge (unmap from iommu) the vma, while keeping the iova range
allocated (so we can remap back to the same GPU virtual address when the
From: Rob Clark
Currently this doesn't matter since we keep the pages pinned until the
object is destroyed. But when we start unpinning pages to allow objects
to be evicted to swap, it will.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 1 +
1 file changed, 1 insertion(+)
diff
From: Rob Clark
Currently nearly everything, other than newly allocated objects which
are not yet backed by pages, is pinned and resident in RAM. But it will
be nice to have some stats on what is unpinned once that is supported.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 7 +
From: Rob Clark
Objects that are potential for swapping out are (1) willneed (ie. if
they are purgable/MADV_WONTNEED we can just free the pages without them
having to land in swap), (2) not on an active list, (3) not dma-buf
imported or exported, and (4) not vmap'd. This repurposes the purged
li
From: Rob Clark
Shoot down any mmap's *first* before put_pages(). Also add a WARN_ON
that the object is locked (to make it clear that this doesn't race with
msm_gem_fault()) and remove a redundant WARN_ON (since is_purgable()
already covers that case).
Fixes: 68209390f116 ("drm/msm: shrinker su
From: Rob Clark
Now that tracking is wired up for potentially evictable GEM objects,
wire up shrinker and the remaining GEM bits for unpinning backing pages
of inactive objects.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 23
drivers/gpu/drm/msm/msm_g
How are you? I'm Vanina. I picked interest in you and I would like to know more
about you and establish relationship with you. i will wait for your response.
thank you.
From: Michael Kelley
> Sent: Wednesday, March 24, 2021 8:55 AM
> To: w...@kernel.org; catalin.mari...@arm.com; Mark Rutland
> ;
> lorenzo.pieral...@arm.com; sudeep.ho...@arm.com
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> hyp...@vger.kernel.org; linux-...@vg
On Mon, Apr 05, 2021 at 10:53:34AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.265 release.
> There are 28 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On 4/5/2021 10:08 AM, Leon Romanovsky wrote:
On Mon, Apr 05, 2021 at 03:41:15PM +0200, Christoph Hellwig wrote:
On Mon, Apr 05, 2021 at 08:23:54AM +0300, Leon Romanovsky wrote:
From: Leon Romanovsky
>From Avihai,
Relaxed Ordering is a PCIe mechanism that relaxes the strict ordering
imposed o
On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.265 release.
> There are 35 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On Mon, Apr 05, 2021 at 10:53:26AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.229 release.
> There are 52 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
On Mon, Apr 05, 2021 at 10:53:31AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.185 release.
> There are 56 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
On Mon, Apr 05, 2021 at 10:53:24AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.110 release.
> There are 74 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
On Mon, Apr 05, 2021 at 10:52:42AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.28 release.
> There are 126 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
If you update the timestamp of KCONFIG_CONFIG without actually changing
anything, config_data.gz is re-generated and causes vmlinux to re-link.
When Link Time Optimization is enabled, unnecessary re-linking of
vmlinux is highly desirable since it adds several minutes to build time.
Avoid touching
On Mon, Apr 05, 2021 at 10:52:29AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.11.12 release.
> There are 152 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me kno
901 - 1000 of 1443 matches
Mail list logo
