From: Brendan Higgins
A lot of the expectation and assertion infrastructure prints out fairly
complicated test failure messages, so add a C++ style log library for
for logging test results called `struct kunit_stream`.
kunit_stream allows us to construct a message before we know whether we
want
From: Brendan Higgins
KUnit will soon add macros for generating mocks from types, the
generated mock types are named like `struct MOCK(foo)` (where the base
type is struct foo).
Add `struct MOCK(foo)` as a NonptrType so that it is recognized
correctly in declarations.
Signed-off-by: Brendan
From: Brendan Higgins
Introduce basic class mocking, the ability to automatically generate a
Linux C-style class implementation whose behavior is controlled by test
cases, which can also set expectations on when and how mocks are called.
Co-developed-by: Daniel Latypov
Signed-off-by: Daniel
This reverts commit 109fb06fdc6f6788df7dfbc235f7636a38e28fd4.
string-stream will be used by kunit mocking code to print messages about
mock expectations.
It makes the code signifcantly simpler if string-stream objects can be
part of structs declared in mocking headers.
Signed-off-by: Daniel
# Background
KUnit currently lacks any first-class support for mocking.
For an overview and discussion on the pros and cons, see
https://martinfowler.com/articles/mocksArentStubs.html
This patch set introduces the basic machinery needed for mocking:
setting and validating expectations, setting
On Thu, Oct 8, 2020 at 5:47 PM Arnd Bergmann wrote:
> When I created the patch removing CONFIG_ARCH_GETTIMEOFFSET,
> I also had a look at CONFIG_GENERIC_CLOCKEVENTS, which is
> selected by most, but not all, platforms today, each of the
> ones that lack it doing the timer tick slightly
Hi Linus,
Please pull these seccomp updates for v5.10-rc1. The bulk of the changes
are with the seccomp selftests to accommodate some powerpc-specific
behavioral characteristics. Additional cleanups, fixes, and improvements
are also included, noted in the tag description.
Thanks!
-Kees
The
On Mon, Oct 12 2020 at 21:20, David Woodhouse wrote:
> On Mon, 2020-10-12 at 20:38 +0200, Thomas Gleixner wrote:
>> Nasty, but way better than what we have now.
>
> Want me to send that out in email or is the git tree enough for now?
>
> I've cleaned it up a little and fixed a bug in the I/OAPIC
On Mon, 12 Oct 2020 15:18:08 -0500
Tom Zanussi wrote:
> @@ -630,8 +630,11 @@ static struct synth_field *parse_synth_field(int argc,
> const char **argv,
> if (field_type[0] == ';')
> field_type++;
> len = strlen(field_type) + 1;
> - if (array)
> + if (array) {
On Mon, Oct 12, 2020 at 2:53 AM Muchun Song wrote:
> We are not complaining about TCP using too much memory, but how do
> we know that TCP uses a lot of memory. When I firstly face this problem,
> I do not know who uses the 25GB memory and it is not shown in the
> /proc/meminfo.
> If we can know
A bug in USB/IP previously caused all syzkaller USB fuzzing instances to
return false positives when testing crash reproducers.
This patch reverts changes made in commit 03fb92a432ea which, due to
this bug, returned false positives when tested and introduced new
regressions.
Fixes: 03fb92a432ea
On Mon, Oct 12, 2020 at 10:24 AM Ingo Molnar wrote:
>
> Do not sync vmalloc/ioremap mappings on x86-64 kernels.
>
> Hopefully now without the bugs!
Let's hope so.
If this turns out to work this time, can we do a similar preallocation
of the page directories on 32-bit? Because I think now x86-32
On Mon, 12 Oct 2020 15:18:06 -0500
Tom Zanussi wrote:
> +static int cmdstr_append(char *buf, const char *str, int *remaining)
> +{
> + int len = strlen(str);
> +
> + if (len + 1 >= *remaining) {
> + synth_err(SYNTH_ERR_CMD_TOO_LONG, 0);
> + return -EINVAL;
> +
Hey Lukasz,
I think after all this discussion (in our own way of describing things)
we agree on how the current cpufreq based FIE implementation is affected
in systems that use hardware coordination.
What we don't agree on is the location where that implementation (that
uses the new mask and
On Sun, Oct 11, 2020 at 01:09:55PM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> Clang static analysis reports this representative problem
>
> ptp_clockmatrix.c:1852:2: warning: 5th function call argument
> is an uninitialized value
> snprintf(idtcm->version,
On Mon, Oct 12, 2020 at 2:44 PM Paul E. McKenney wrote:
>
> So that RCU can tell, even in CONFIG_PREEMPT_NONE=y kernels, whether it
> is safe to invoke the memory allocator.
So in what situation is RCU called from random contexts that it can't even tell?
> But either way, please let me know how
On 10/12/2020 2:56 PM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 02:46:10PM -0700, Linus Torvalds wrote:
At least "git grep" only shows two assignments to it.
Of course, that would miss any cases that play games with preprocessor
token pasting etc, so it's not entirely meaningful, but
Hi Steve,
On Mon, 2020-10-12 at 17:49 -0400, Steven Rostedt wrote:
> On Mon, 12 Oct 2020 17:42:40 -0400
> Steven Rostedt wrote:
>
> > On Mon, 12 Oct 2020 15:18:06 -0500
> > Tom Zanussi wrote:
> >
> > > +static char last_cmd[MAX_FILTER_STR_VAL];
> > > +
> > > +static int errpos(const char
On 10/12/2020 2:42 PM, Mike Travis wrote:
On 10/12/2020 2:27 PM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 02:15:55PM -0700, Mike Travis wrote:
Of course, it also looks like that 'uvh_nmi_mmrx_mask' thing is a
write-only variable so it doesn't matter, but can we _please_ get this
On Mon, Oct 12, 2020 at 02:46:10PM -0700, Linus Torvalds wrote:
> At least "git grep" only shows two assignments to it.
>
> Of course, that would miss any cases that play games with preprocessor
> token pasting etc, so it's not entirely meaningful, but it's certainly
> a hint..
>From a quick
On 10/12/20 10:52 PM, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages)
> wrote:
>>
>> [CC += Davide]
>
> I'm not sure how active Davide is any more..
Yep, I know. But just in case.
>> I don't think this is correct. The epoll(7) manual page
>> sill carries the
On Mon, 12 Oct 2020 17:42:40 -0400
Steven Rostedt wrote:
> On Mon, 12 Oct 2020 15:18:06 -0500
> Tom Zanussi wrote:
>
> > +static char last_cmd[MAX_FILTER_STR_VAL];
> > +
> > +static int errpos(const char *str)
> > +{
> > + return err_pos(last_cmd, str);
> > +}
> > +
> > +static void
On 13/10/20 12:24 am, Bernd Petrovitsch wrote:
> Hi all!
>
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 703b1c4f6d12..86d42a2d09cb 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -27,8 +27,8 @@ cflags-y := -pipe $(EXTRA) -ffixed-r13
On Mon, Oct 12, 2020 at 2:42 PM Mike Travis wrote:
>
> It should have been an unsigned long instead of an int as Linus
> suggested. I'm not sure it's a write only variable as I think the mask
> is used to check if the interrupt occurred (I'll have to look closer).
At least "git grep" only shows
On 10/12/20 2:05 PM, Raj, Ashok wrote:
On Sun, Oct 11, 2020 at 10:03:40PM -0700, sathyanarayanan.nkuppusw...@gmail.com
wrote:
From: Kuppuswamy Sathyanarayanan
Currently if report_error_detected() or report_mmio_enabled()
functions requests PCI_ERS_RESULT_NEED_RESET, current
On Sun, Oct 11, 2020 at 9:22 PM Muchun Song wrote:
>
> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang wrote:
> >
> > On Sat, Oct 10, 2020 at 3:39 AM Muchun Song
> > wrote:
> > >
> > > The amount of memory allocated to sockets buffer can become significant.
> > > However, we do not display the
The nfs4idmapper only needs access to the user namespace, and not the
entire cred struct. This replaces the struct cred* member with
struct user_namespace*. This is mostly hygiene, so we don't have to
hold onto the cred object, which has extraneous references to
things like user_struct. This also
On Mon, Oct 12, 2020 at 01:25:09PM -0700, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 7:14 AM Ingo Molnar wrote:
> >
> > Please pull the latest core/rcu git tree from:
> >
> > RCU changes for v5.10:
> >
> > - Debugging for smp_call_function()
> > - RT raw/non-raw lock ordering fixes
> > -
On 10/12/20 1:52 PM, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages)
>
> I'm busy merging, mind testing this odd patch out? It is _entirely_
> untested, but from the symptoms I think it's the obvious fix.
>
> I did the same thing for the "reader starting out
On Mon, 12 Oct 2020 15:18:06 -0500
Tom Zanussi wrote:
> +static char last_cmd[MAX_FILTER_STR_VAL];
> +
> +static int errpos(const char *str)
> +{
> + return err_pos(last_cmd, str);
> +}
> +
> +static void last_cmd_set(char *str)
> +{
> + if (!str)
> + return;
> +
> +
On 10/12/2020 2:27 PM, Borislav Petkov wrote:
On Mon, Oct 12, 2020 at 02:15:55PM -0700, Mike Travis wrote:
Of course, it also looks like that 'uvh_nmi_mmrx_mask' thing is a
write-only variable so it doesn't matter, but can we _please_ get this
code fixed ASAP?
Yes, I'll look at it right
On Mon, Oct 12 2020 at 17:13, J. Bruce Fields wrote:
> On Fri, Oct 09, 2020 at 10:08:15PM +0200, Thomas Gleixner wrote:
>> You wish. That's clearly wrong because that code is not guaranteed to
>> always run in a context which belongs to the root time namespace.
>
> Argh, right, thanks.
>
>>
On 10/12/20 4:11 PM, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Pavel Machek complained that the question about supporting deprecated
> XFS v4 comes up even when XFS is disabled. This clearly makes no sense,
> so fix Kconfig.
>
> Reported-by: Pavel Machek
> Signed-off-by: Darrick J.
Hi! Thanks for the catch, just one comment down below
On Fri, 2020-10-09 at 21:11 +0300, Alexander Kapshuk wrote:
> This oops manifests itself on the following hardware:
> 01:00.0 VGA compatible controller: NVIDIA Corporation G98M [GeForce G 103M]
> (rev a1)
>
> Oct 09 14:17:46 lp-sasha kernel:
On Wed, Oct 7, 2020 at 9:17 AM Dave Hansen wrote:
>
>
> Changes since (automigrate-20200818):
> * Fall back to normal reclaim when demotion fails
>
> The full series is also available here:
>
> https://github.com/hansendc/linux/tree/automigrate-20201007
>
> I really just want folks to
On 9/27/20 9:38 PM, Halil Pasic wrote:
On Fri, 21 Aug 2020 15:56:13 -0400
Tony Krowiak wrote:
Implements the driver callback invoked by the AP bus when the host
AP configuration has changed. Since this callback is invoked prior to
unbinding a device from its device driver, the vfio_ap
On Mon, Oct 12, 2020 at 11:11:10AM +0800, Boqun Feng wrote:
> Hi,
>
> On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> > On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > > The following commit has been merged into the locking/core branch of tip:
> > >
> > >
On Mon, Oct 12, 2020 at 02:15:55PM -0700, Mike Travis wrote:
> > Of course, it also looks like that 'uvh_nmi_mmrx_mask' thing is a
> > write-only variable so it doesn't matter, but can we _please_ get this
> > code fixed ASAP?
>
> Yes, I'll look at it right now. Thanks.
As this variable is
On Mon, Oct 12, 2020 at 02:22:03PM -0700, Fāng-ruì Sòng wrote:
> On Mon, Oct 12, 2020 at 2:11 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > On Mon, Sep 28, 2020 at 3:49 PM Nathan Chancellor
> > wrote:
> > >
> > > After turning on warnings for orphan section placement, enabling
> >
The pull request you sent on Mon, 12 Oct 2020 18:10:49 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3bff6112c80cecb76af5fe485506f96e8adb6122
Thank you!
--
Deet-doot-dot, I am
The pull request you sent on Mon, 12 Oct 2020 17:55:42 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core-static_call-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dd502a81077a5f3b3e19fa9a1accffdcab5ad5bc
Thank you!
--
The pull request you sent on Mon, 12 Oct 2020 17:21:19 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git efi-core-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e6412f9833db23740ee848ab3d6e7af18dff82a6
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Mon, 12 Oct 2020 15:58:00 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> locking-core-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ed016af52ee3035b4799ebd7d53f9ae59d5782c4
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 12 Oct 2020 17:34:30 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core-build-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/34eb62d868d729e9a252aa497277081fb652eeed
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Mon, 12 Oct 2020 15:37:01 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> sched-core-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/edaa5ddf3833669a25654d42c0fb653dfdd906df
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Mon, 12 Oct 2020 18:23:37 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> perf-kprobes-2020-10-12
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1c6890707eb1438b0fb4e0a10d4afe48a217628b
Thank you!
--
Deet-doot-dot,
On Mon, Oct 12, 2020 at 2:11 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Mon, Sep 28, 2020 at 3:49 PM Nathan Chancellor
> wrote:
> >
> > After turning on warnings for orphan section placement, enabling
> > CONFIG_UNWINDER_FRAME_POINTER instead of CONFIG_UNWINDER_ARM causes
> >
On Mon, Oct 12, 2020 at 05:41:50PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Oct 11, 2020 at 08:53:33PM +0300, Serge Semin wrote:
> > On Sun, Oct 11, 2020 at 04:42:36PM +0200, Greg Kroah-Hartman wrote:
> > > On Sun, Oct 11, 2020 at 01:41:05AM +0300, Serge Semin wrote:
> > > > It appears that the
On 10/12/2020 2:10 PM, Linus Torvalds wrote:
On Mon, Oct 12, 2020 at 3:10 AM Borislav Petkov wrote:
please pull the x86/platform queue.
Hmm. I didn't immediately notice this new warning, because it only
happens with the clang build that I don't do in between every pull.
But this pull
On Mon, Oct 12, 2020 at 10:46 AM Ralph Campbell wrote:
>
> ZONE_DEVICE struct pages have an extra reference count that complicates the
> code for put_page() and several places in the kernel that need to check the
> reference count to see that a page is not being used (gup, compaction,
>
This enables the TI eQEP counter driver that is used by BeagleBone Blue.
Signed-off-by: David Lechner
---
arch/arm/configs/omap2plus_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index
On Fri, Oct 09, 2020 at 10:08:15PM +0200, Thomas Gleixner wrote:
> On Fri, Oct 09 2020 at 09:55, J. Bruce Fields wrote:
> > Looking at how it's used in net/sunrpc/cache.c All it's doing is
> > comparing times which have all been calculated relative to the time
> > returned by getboottime64().
This adds new nodes for the Texas Instruments Enhanced Quadrature
Encoder Pulse (eQEP) module in the PWM subsystem on AM33XX.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/am33xx-l4.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git
This series adds device tree nodes for the eQEP portion of the PWMSS on AM33xx
and enables it on BeagleBone Blue.
I actually submitted these a year ago, but it looks like these patches never got
applied with the actual eQEP driver when it was merged.
For reference, there was some previous
This enables the Enhanced Quadrature Encoder Pulse (eQEP) module for
connectors E1, E2 and E3 on BeagleBone Blue.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/am335x-boneblue.dts | 54 +++
1 file changed, 54 insertions(+)
diff --git
From: Darrick J. Wong
Pavel Machek complained that the question about supporting deprecated
XFS v4 comes up even when XFS is disabled. This clearly makes no sense,
so fix Kconfig.
Reported-by: Pavel Machek
Signed-off-by: Darrick J. Wong
---
fs/xfs/Kconfig |1 +
1 file changed, 1
On Mon, Sep 28, 2020 at 3:49 PM Nathan Chancellor
wrote:
>
> After turning on warnings for orphan section placement, enabling
> CONFIG_UNWINDER_FRAME_POINTER instead of CONFIG_UNWINDER_ARM causes
> thousands of warnings when clang + ld.lld are used:
>
> $ scripts/config --file
On Mon, Oct 12, 2020 at 12:20:39PM +0200, Pavel Machek wrote:
> Hi!
>
> I don't have XFS enabled, yet I'm asked if I want to support its old
> format:
>
> +config XFS_SUPPORT_V4
> + bool "Support deprecated V4 (crc=0) format"
> + default y
>
> This needs to have dependence on
On Mon, Oct 12, 2020 at 3:10 AM Borislav Petkov wrote:
>
> please pull the x86/platform queue.
Hmm. I didn't immediately notice this new warning, because it only
happens with the clang build that I don't do in between every pull.
But this pull causes new warnings from clang:
On Sun, Oct 11, 2020 at 10:03:40PM -0700, sathyanarayanan.nkuppusw...@gmail.com
wrote:
> From: Kuppuswamy Sathyanarayanan
>
> Currently if report_error_detected() or report_mmio_enabled()
> functions requests PCI_ERS_RESULT_NEED_RESET, current
> pcie_do_recovery() implementation does not do the
On Mon, Oct 12, 2020 at 09:51:09PM +0100, Will Deacon wrote:
> On Mon, Oct 12, 2020 at 01:44:56PM -0700, Kees Cook wrote:
> > On Mon, Oct 12, 2020 at 09:31:16AM +0100, Will Deacon wrote:
> > > On Fri, Oct 09, 2020 at 09:13:34AM -0700, Sami Tolvanen wrote:
> > > > Allow CONFIG_LTO_CLANG and
On Tue, Aug 4, 2020 at 9:22 AM Vitor Massaru Iha wrote:
>
> Hi Peter,
>
> On Tue, Aug 4, 2020 at 11:23 AM wrote:
> >
> > On Tue, Aug 04, 2020 at 10:46:21AM -0300, Vitor Massaru Iha wrote:
> > > On Tue, Aug 4, 2020 at 10:25 AM wrote:
> > > > On Wed, Jul 29, 2020 at 06:57:17PM -0300, Vitor
On 20-10-12 12:11:18, Joe Perches wrote:
> On Mon, 2020-10-12 at 15:02 -0400, Sasha Levin wrote:
> > From: Anant Thazhemadam
> >
> > [ Upstream commit f45a4248ea4cc13ed50618ff066849f9587226b2 ]
> >
> > When get_registers() fails in set_ethernet_addr(),the uninitialized
> > value of node_id gets
On Fri, 9 Oct 2020 00:11:23 +0800 Voon Weifeng wrote:
> From: "Vineetha G. Jaya Kumaran"
>
> This patch enables the HW LPI Timer which controls the automatic entry
> and exit of the LPI state.
> The EEE LPI timer value is configured through ethtool. The driver will
> auto select the LPI HW
This is done to match the pre-regmap membarrier behaviour, ensuring
default regmap_write calls in _relaxed() are indeed relaxed while
the non-relaxed versions include an explicit mem-barrier call.
Signed-off-by: Adrian Ratiu
---
drivers/staging/media/hantro/hantro.h| 4
It is very useful to know the status of all the decoder configuration
registers right before starting a decode operation, so add an option
to print them if register debugging is enabled (debug bit 7 is set).
Signed-off-by: Adrian Ratiu
---
drivers/staging/media/hantro/hantro.h | 1 +
VC8000D decodes only to 4x4 tiled NV12 format and the attached PP
can be used to de-tile its output. This can bo done in two modes:
1. Pipeline mode, using the same decoder "done" irq
2. External mode, with a separate irq and input setup.
This adds the relevant postprocessor fields and support
The G1 and G2 cores on imx8mq share a common "control block" used
to reset and enable the core clocks as well as enable functioning
via ctrl FUSE registers (these are not the FUSEs on the VPU cores,
they are just used to enable/disable the cores and allow the real
VPU FUSE regs to become
Populate the regmap field API for G1 h264 decoding and convert the
G1 h264 decoder source to use the new API. This is done because we
will add support for the newer VC8000D core which will configure
the regmap API fields differently to match its own hwreg layout.
Signed-off-by: Adrian Ratiu
---
VC8000D is a newer core combining both previous G1 and G2 cores into
one chip. As a result of this register layouts took a hit but the HW
functions mostly the same, so we can use regmap fields to compensate.
Signed-off-by: Adrian Ratiu
---
.../staging/media/hantro/hantro_g1_h264_dec.c | 29
Even though these fields are currently unused it is still a good
idea to have them documented for future encoder implementations.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Adrian Ratiu
---
drivers/staging/media/hantro/hantro_regmap.c | 580 ++-
Postprocessing used the custom hantro_reg structure but now we have
regmap fields which are used for reg layouts which do the same thing,
so PP can be moved to regmap. In the future all hantro_reg references
can be removed, this is just a beginnig.
This converts only the existing G1 PP support,
The h264 decoder is now capable of decoding on both G1 and VC8000 and
other HW revisions can be added in the future by extending the hantro
regmap config, so we rename it to reflect the new status.
All other core-specific files like "hantro_g1_mpeg2_dec.c" should be
renamed as well after they
VPU cores starting with VC8000D feature a separate decoding mode named
"high10", capable of decoding both 8bit and 10bit streams, alongside the
previous (still supported) "normal / classic" h264 decoding mode.
The new kernel module param h264_high10 can be used to switch modes,
otherwise the
On some platforms (eg armv7 due to the CONFIG_ARM_DMA_MEM_BUFFERABLE)
MMIO R/W operations always add memory barriers which can increase load,
decrease battery life or in general reduce performance unnecessarily
on devices which access a lot of configuration registers and where
ordering does not
Hello. I hoped most of the nouveau video driver's problems would be
solved by 5.9.0. Sadly, no.
$ uname -a
Linux freedom 5.9.0 #1 SMP Sun Oct 11 20:28:07 MDT 2020 x86_64 x86_64
x86_64 GNU/Linux
$ dmesg
[12170.319495] nouveau :02:00.0: DRM: base-0: timeout
[12172.324280] nouveau
The fundamental idea is: clocks are prepared in the driver probe() then
each use-case will enable/disable them as needed.
Some variants like imx8mq need to have the clocks enabled during the
HW init phase, so they will benefit from having the clocks prepared
before the variant init callback to
This creates regmaps on top of the memory mapped regions for encoders
and decoders and converts the helpers in hantro.h to do their R/W via
these regmaps.
In itself this indirection layer is quite useless, but the key is the
field API also initialized using the regmaps which is currently empty.
This register is not documented in either the G1 or VC8000D register
maps and on VC8000D there is a conflict because at the same offset the
VPU IP defines another register with a very different meaning.
What likely happened is the HW integrator which uses only the G1 IP
core added some
Some SoCs might have a reset controller which disables clocks
by default in reset state which then drivers need to unreset
before being able to ungate a specific clock.
In this specific case, the hantro driver needs to ensure the
peripheral clock can be properly ungated otherwise MMIO reg
values
Now that we support two cores with different PP operations we need
to make the condition to enable PP a bit smarter based on what is
actually supported by each core.
While doing this also move the needs_postproc() test inside the
postproc .c file instead of cluttering the header.
Signed-off-by:
These do not all strictly belong to the g1 core and even the majority
of previously documented bits were not used (yet) by the driver irq
handlers, but it's still very useful to have an overview of all IRQs,
especially since starting with core versions vc8000 and later the irq
bits previously used
This header used a combination of direct hex offsets and decimal register
notation - via the G1_SWREG() macro - which is annoying when comparing with
the ref manuals which always use the equivalent of G1_SWREG(), so convert
the entire file to G1_SWREG() notation.
Signed-off-by: Adrian Ratiu
---
Dear all,
This series introduces a regmap infrastructure for the Hantro driver
which is used to compensate for different HW-revision register layouts.
To justify it h264 decoding capability is added for newer VC8000 chips.
This is a gradual conversion to the new infra - a complete conversion
On Mon, Oct 12, 2020 at 1:22 PM Uros Bizjak wrote:
>
> No, this fact is not documented, although there are close to zero
> chances it will ever change. High registers are independent from their
> 8bit lowparts, but they still clobber corresponding 16bit, 32bit and
> 64bit representations. I guess
On Thu, Oct 01, 2020 at 03:35:46PM +0200, David Sterba wrote:
> On Thu, Oct 01, 2020 at 03:08:34PM +0200, Dmitry Vyukov wrote:
> > On Thu, Oct 1, 2020 at 3:05 PM Dmitry Vyukov wrote:
> > >
> > > On Wed, Sep 30, 2020 at 8:06 PM David Sterba wrote:
> > > >
> > > > On Wed, Sep 30, 2020 at
On 9/27/20 9:38 PM, Halil Pasic wrote:
On Fri, 21 Aug 2020 15:56:13 -0400
Tony Krowiak wrote:
Implements the driver callback invoked by the AP bus when the host
AP configuration has changed. Since this callback is invoked prior to
unbinding a device from its device driver, the vfio_ap
Add node for the auxadc IP. The IP is compatible with the one found
in MT8173 SoC.
Signed-off-by: Fabien Parent
---
arch/arm64/boot/dts/mediatek/mt8516.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
On Mon, Oct 12, 2020 at 1:30 PM Michael Kerrisk (man-pages)
wrote:
>
> [CC += Davide]
I'm not sure how active Davide is any more..
> I don't think this is correct. The epoll(7) manual page
> sill carries the text written long ago by Davide Libenzi,
> the creator of epoll:
>
> Since even
Add documentation for the auxadc binding for MT8516 SoC.
Signed-off-by: Fabien Parent
---
Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt
On Mon, Oct 12, 2020 at 01:44:56PM -0700, Kees Cook wrote:
> On Mon, Oct 12, 2020 at 09:31:16AM +0100, Will Deacon wrote:
> > On Fri, Oct 09, 2020 at 09:13:34AM -0700, Sami Tolvanen wrote:
> > > Allow CONFIG_LTO_CLANG and CONFIG_THINLTO to be enabled.
> > >
> > > Signed-off-by: Sami Tolvanen
> >
On Mon, Oct 12, 2020 at 1:13 PM Brendan Higgins
wrote:
>
> On Fri, Aug 21, 2020 at 5:19 AM Rasmus Villemoes
> wrote:
>
> Sorry about the late reply. I saw activity on this before and thought
> it was under control. I only saw the unresolved state now looking
> through patchwork.
>
> > On
On 10/12/2020 12:58 PM, Cyrill Gorcunov wrote:
On Mon, Oct 12, 2020 at 08:38:27AM -0700, Yu-cheng Yu wrote:
...
/*
* x86-64 Task Priority Register, CR8
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 038e19c0019e..705fd9b94e31 100644
---
This is a preparatory commit for the upcoming addition of a new hardware
tag-based (MTE-based) KASAN mode.
Hardware tag-based KASAN won't be using shadow memory, but will reuse
this function. Rename "shadow" to implementation-neutral "metadata".
No functional changes.
Signed-off-by: Andrey
This is a preparatory commit for the upcoming addition of a new hardware
tag-based (MTE-based) KASAN mode.
Hardware tag-based KASAN won't be using shadow memory, but will reuse
this function. Rename "shadow" to implementation-neutral "metadata".
No functional changes.
Signed-off-by: Andrey
On Fri, Aug 21, 2020 at 03:28:49PM +0300, Andy Shevchenko wrote:
> On Fri, Aug 21, 2020 at 01:37:10PM +0200, Petr Mladek wrote:
> > On Mon 2020-08-17 09:06:32, Rasmus Villemoes wrote:
> > > On 17/08/2020 06.30, Arpitha Raghunandan wrote:
> > > > Converts test lib/test_printf.c to KUnit.
> > > >
Some #ifdef CONFIG_KASAN checks are only relevant for software KASAN
modes (either related to shadow memory or compiler instrumentation).
Expand those into CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS.
Signed-off-by: Andrey Konovalov
Signed-off-by: Vincenzo Frascino
Reviewed-by: Catalin Marinas
Kernel allocator code accesses metadata for slab objects, that may lie
out-of-bounds of the object itself, or be accessed when an object is freed.
Such accesses trigger tag faults and lead to false-positive reports with
hardware tag-based KASAN.
Software KASAN modes disable instrumentation for
Provide implementation of KASAN functions required for the hardware
tag-based mode. Those include core functions for memory and pointer
tagging (tags_hw.c) and bug reporting (report_tags_hw.c). Also adapt
common KASAN code to support the new mode.
Signed-off-by: Andrey Konovalov
Signed-off-by:
Add documentation for hardware tag-based KASAN mode and also add some
clarifications for software tag-based mode.
Signed-off-by: Andrey Konovalov
Signed-off-by: Vincenzo Frascino
Reviewed-by: Marco Elver
---
Change-Id: Ib46cb444cfdee44054628940a82f5139e10d0258
---
201 - 300 of 1792 matches
Mail list logo
