Hello,
syzbot found the following issue on:
HEAD commit:e93fac3b drivers: net: xen-netfront: Simplify the calculat..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=160930c4d0
kernel config: https://syzkaller.appspot.com/x/.config?x=9804f8fe1c4e3869
On Fri, Feb 5, 2021 at 10:28 AM Johannes Weiner wrote:
>
> Replace the memory controller's custom hierarchical stats code with
> the generic rstat infrastructure provided by the cgroup core.
>
> The current implementation does batched upward propagation from the
> write side (i.e. as stats
On Mon, Feb 8, 2021 at 12:25 AM Kyle Huey wrote:
>
> On Sun, Feb 7, 2021 at 3:09 PM Sedat Dilek wrote:
> >
> > Hi,
> >
> > congrats to Linux v5.11-rc7.
> >
> > after commit 6342adcaa683 ("entry: Ensure trap after single-step on
> > system call return"):
> >
> > $ git grep '\_TIF_SINGLESTEP'
On Mon, Feb 8, 2021 at 12:27 AM Bhaskar Chowdhury wrote:
>
> On 00:08 Mon 08 Feb 2021, Sedat Dilek wrote:
> >Hi,
> >
> >congrats to Linux v5.11-rc7.
> >
> >after commit 6342adcaa683 ("entry: Ensure trap after single-step on
> >system call return"):
> >
> >$ git grep '\_TIF_SINGLESTEP' arch/x86/
>
On Sun, 7 Feb 2021, Song Bao Hua (Barry Song) wrote:
> NUMA balancer is just one of many reasons for page migration. Even one
> simple alloc_pages() can cause memory migration in just single NUMA
> node or UMA system.
>
> The other reasons for page migration include but are not limited to:
> *
Hi Lorenzo, Rob,
On 12/01/21 12:45 pm, Kishon Vijay Abraham I wrote:
>
>
> On 30/12/20 5:35 pm, Nadeem Athani wrote:
>> Cadence controller will not initiate autonomous speed change if strapped
>> as Gen2. The Retrain Link bit is set as quirk to enable this speed change.
>> Adding a quirk flag
On Wed, Feb 03, 2021 at 04:03:06PM +0100, Miklos Szeredi wrote:
> On Wed, Feb 3, 2021 at 3:56 PM Matthew Wilcox wrote:
>
> > But let's talk specifics. What does CIFS need to contact the server for?
> > Could it be cached earlier?
>
> I don't understand what CIFS is doing, and I don't really
The cs cannot change back to 'high' when the count is
TPM_RETRY. So the TPM chips thought this communication
is not over. And next times communication cannot be
effective because the communications mixed up with the
last time.
v1 -> v2:
- fix spi_xfer.cs_change to spi_xfer->cs_change
Hi, John
> > > Apart from that, I think that we're a bit uncertain about patch 3/4
> > What are your concerns?
> > I think it's okay for perf to read a new event code with a number at the
> beginning.
>
> The impact of this fix is on {name} and later rules.
> parse_events.l uses {name} only in
Add compatible "mediatek,mt8192-dpi" for the mt8192 dpi.
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
Add per-platform max clock rate check in mtk_dpi_bridge_mode_valid.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index ffa4a0f1989f..f6f71eb67ff1 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++
Changes since v2:
- add const struct drm_display_info *info in mtk_dpi_bridge_mode_valid
Jitao Shi (3):
drm/mediatek: mtk_dpi: Add check for max clock rate in mode_valid
drm/mediatek: mtk_dpi: Add dpi config for mt8192
dt-bindings: mediatek,dpi: add mt8192 to mediatek,dpi
On Sun, Feb 07, 2021 at 10:24:28PM +, Song Bao Hua (Barry Song) wrote:
> > > In high-performance I/O cases, accelerators might want to perform
> > > I/O on a memory without IO page faults which can result in dramatically
> > > increased latency. Current memory related APIs could not achieve
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index ffa4a0f1989f..f6f71eb67ff1 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++
Add per-platform max clock rate check in mtk_dpi_bridge_mode_valid.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index
Changes since v1:
- fix build err.
Jitao Shi (3):
drm/mediatek: mtk_dpi: Add check for max clock rate in mode_valid
drm/mediatek: mtk_dpi: Add dpi config for mt8192
dt-bindings: mediatek,dpi: add mt8192 to mediatek,dpi
.../display/mediatek/mediatek,dpi.yaml| 1 +
Add compatible "mediatek,mt8192-dpi" for the mt8192 dpi.
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
On 2021/2/5 3:52, Robin Murphy wrote:
> On 2021-01-28 15:17, Keqian Zhu wrote:
>> From: jiangkunkun
>>
>> During dirty log tracking, user will try to retrieve dirty log from
>> iommu if it supports hardware dirty log. This adds a new interface
[...]
>> static void
kernel test robot writes:
All errors (new ones prefixed by >>):
/usr/bin/ld: arch/um/drivers/xterm.o: in function `xterm_open':
xterm.c:(.text+0x16b): undefined reference to `printk'
/usr/bin/ld: xterm.c:(.text+0x1a8): undefined reference to `printk'
/usr/bin/ld: xterm.c:(.text+0x1f4):
On 02/08/2021 05:31 AM, Maciej W. Rozycki wrote:
On Thu, 21 Jan 2021, Jinyang He wrote:
mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by
The minor opcode extension field is comprised of bits
Hi all,
The problem can't be reproduced after test environment changed,
there's no regression found on this patch now, we don't know yet
why it caused a regression in September 2020, but we'll continue
to root cause.
Best Regards,
Rong Chen
On Thu, Jan 21, 2021 at 02:18:25PM +, Chiou,
On Fri, Feb 05, 2021 at 09:20:22PM +0100, Dirk Gouders wrote:
> tpm_tis does not consider -EPROBE_DEFER in tpm_tis_plat_probe().
> Instead, without notification it falls back to polling mode if
> platform_get_irq_optional() returns a negative value.
>
> This could lead to different behavior
And for good measure: reverting that commit
20bf2b378729c4a0366a53e2018a0b70ace94bcd
flagged by the bisect right on top of the current tree compiles fine.
On Sun, Feb 07, 2021 at 07:26:01PM -0500, Stuart Little wrote:
> The result of the bisect on the issue reported in the previous message:
>
Hi all,
After merging the v4l-dvb tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: drivers/media/i2c/rdacm21-camera_module:
'max9271_set_serial_link' exported twice. Previous export was in
drivers/media/i2c/rdacm20-camera_module.ko
WARNING: modpost:
Hello Steve,
On Sat, Feb 06, 2021 at 01:56:46PM +, Ashish Kalra wrote:
> Hello Steve,
>
> On Sat, Feb 06, 2021 at 05:46:17AM +, Ashish Kalra wrote:
> > Hello Steve,
> >
> > Continued response to your queries, especially related to userspace
> > control of SEV live migration feature :
The result of the bisect on the issue reported in the previous message:
--- cut ---
20bf2b378729c4a0366a53e2018a0b70ace94bcd is the first bad commit
commit 20bf2b378729c4a0366a53e2018a0b70ace94bcd
Author: Josh Poimboeuf
Date: Thu Jan 28 15:52:19 2021 -0600
x86/build: Disable CET
Hi "Uwe,
I love your patch! Yet something to improve:
[auto build test ERROR on 5c8fe583cce542aa0b84adc939ce85293de36e5e]
url:
https://github.com/0day-ci/linux/commits/Uwe-Kleine-K-nig/mei-bus-simplify-mei_cl_device_remove/20210208-062551
base: 5c8fe583cce542aa0b84adc939ce85293de36e5e
Hi "Uwe,
I love your patch! Yet something to improve:
[auto build test ERROR on 5c8fe583cce542aa0b84adc939ce85293de36e5e]
url:
https://github.com/0day-ci/linux/commits/Uwe-Kleine-K-nig/mei-bus-simplify-mei_cl_device_remove/20210208-062551
base: 5c8fe583cce542aa0b84adc939ce85293de36e5e
Hi "Uwe,
I love your patch! Yet something to improve:
[auto build test ERROR on 5c8fe583cce542aa0b84adc939ce85293de36e5e]
url:
https://github.com/0day-ci/linux/commits/Uwe-Kleine-K-nig/mei-bus-simplify-mei_cl_device_remove/20210208-062551
base: 5c8fe583cce542aa0b84adc939ce85293de36e5e
On Fri, Feb 05, 2021 at 11:37:46PM +0100, Richard Weinberger wrote:
> On Fri, Feb 5, 2021 at 11:26 PM Amy Parker wrote:
> >
> > On Fri, Feb 5, 2021 at 5:1 AM David Sterba wrote:
> > >
> > > On Thu, Feb 04, 2021 at 08:52:14PM -0800, Amy Parker wrote:
> > > > As the EFS driver is old and
On Fri, Feb 05, 2021 at 02:06:18PM -0800, Amy Parker wrote:
> Some statements do not have proper spacing between their C
> keywords (commonly if and for) throughout files in the ia64 tree.
> This patch corrects this to follow the kernel code style guide.
>
> Signed-off-by: Amy Parker
> ---
>
On Fri, Feb 05, 2021 at 08:25:35AM +, David Howells wrote:
> Jarkko Sakkinen wrote:
>
> > > + * init_ns_common - Initialise the common part of a namespace
> >
> > Nit: init_ns_common()
>
> Interesting. The majority of code doesn't put the brackets in.
>
> > I've used lately (e.g.
On 2/7/21 2:22 PM, Uwe Kleine-König wrote:
> The driver core ignores the return value of mei_cl_device_remove() so
> passing an error value doesn't solve any problem. As most mei drivers'
> remove callbacks return 0 unconditionally and returning a different value
> doesn't have any effect, change
On Fri, Feb 05, 2021 at 02:42:05PM +0800, wanghongzhe wrote:
> when i reach TPM_RETRY, the cs cannot change back to 'high'.
> So the TPM chips thinks this communication is not over.
> And next times communication cannot be effective because
> the communications mixed up with the last time.
>
>
> > @@ -12,7 +13,7 @@ Required properties:
> > - common controller registers
> > - LMS registers
> > - one register area per Ethernet port
> > - For "marvell,armada-7k-pp2", must contain the following register
> > + For "marvell,armada-7k-pp2" used by 7K/8K and CN913X, must contain
>
Hi all,
Today's linux-next merge of the xfs tree got a conflict in:
fs/xfs/xfs_ioctl.c
between commit:
f736d93d76d3 ("xfs: support idmapped mounts")
from the pidfd tree and commit:
7317a03df703 ("xfs: refactor inode ownership change transaction/inode/quota
allocation idiom")
from the
I am trying to compile on an x86_64 host for a 32-bit system; my config is at
https://termbin.com/v8jl
I am getting numerous errors of the form
./include/linux/kasan-checks.h:17:1: error: ‘-mindirect-branch’ and
‘-fcf-protection’ are not compatible
and
./include/linux/kcsan-checks.h:143:6:
On 00:08 Mon 08 Feb 2021, Sedat Dilek wrote:
Hi,
congrats to Linux v5.11-rc7.
after commit 6342adcaa683 ("entry: Ensure trap after single-step on
system call return"):
$ git grep '\_TIF_SINGLESTEP' arch/x86/
arch/x86/include/asm/thread_info.h:#define _TIF_SINGLESTEP
(1 << TIF_SINGLESTEP)
On Sun, Feb 7, 2021 at 3:09 PM Sedat Dilek wrote:
>
> Hi,
>
> congrats to Linux v5.11-rc7.
>
> after commit 6342adcaa683 ("entry: Ensure trap after single-step on
> system call return"):
>
> $ git grep '\_TIF_SINGLESTEP' arch/x86/
> arch/x86/include/asm/thread_info.h:#define _TIF_SINGLESTEP
> (1
On 14:32 Sun 07 Feb 2021, Linus Torvalds wrote:
and hopefully life goes on with the weekly celebration involving
compiling and testing new kernels instead.
Right?
Yup, that's the standard ritual! Now, time to spin this RC fellow too side by
side :)
~Bhaskar
Linus
---
Ahmed
From: Vladimir Oltean
The ocelot switches are a bit odd in that they do not have an STP state
to put the ports into. Instead, the forwarding configuration is delayed
from the typical port_bridge_join into stp_state_set, when the port enters
the BR_STATE_FORWARDING state.
I can only guess that
From: Vladimir Oltean
We should not be unconditionally enabling address learning, since doing
that is actively detrimential when a port is standalone and not offloading
a bridge. Namely, if a port in the switch is standalone and others are
offloading the bridge, then we could enter a situation
From: Vladimir Oltean
In preparation of offloading the bridge port flags which have
independent settings for unknown multicast and for broadcast, we should
also start reserving one destination Port Group ID for the flooding of
broadcast packets, to allow configuring it individually.
From: Vladimir Oltean
It is customary to return -EOPNOTSUPP when an operation is not supported.
Sometimes the fact that an operation is not supported is irrelevant to
upper layers, and in that case the return code is ignored.
However, in the case of br_switchdev_set_port_flag, it took it upon
From: Vladimir Oltean
There does not appear to be any strong reason why
br_switchdev_set_port_flag issues a separate notification for checking
the supported brport flags rather than just attempting to apply them and
propagating the error if that fails.
However, there is a reason why this
From: Vladimir Oltean
The bridge offloads the port flags through a single bit mask using
switchdev, which among others, contains learning and flooding settings.
The commit 57652796aa97 ("net: dsa: add support for bridge flags")
missed one crucial aspect of the
From: Vladimir Oltean
Currently br_switchdev_set_port_flag has two options for error handling
and neither is good:
- The driver returns -EOPNOTSUPP in PRE_BRIDGE_FLAGS if it doesn't
support offloading that flag, and this gets silently ignored and
converted to an errno of 0. Nobody does this.
From: Vladimir Oltean
With the bridge driver doing that for us now, we can simplify our
mid-layer logic a little bit, which would have otherwise needed some
tuning for the disabling of address learning that is necessary in
standalone mode.
Signed-off-by: Vladimir Oltean
---
net/dsa/port.c |
From: Vladimir Oltean
It must first be admitted that switchdev device drivers have a life
beyond the bridge, and when they aren't offloading the bridge driver
they are operating with forwarding disabled between ports, emulating as
closely as possible N standalone network interfaces.
Now it must
From: Vladimir Oltean
The initial goal of this series was to have better support for
standalone ports mode and multiple bridges on the Ocelot/Felix DSA
driver. Proper support for standalone mode requires disabling address
learning, which in turn requires interaction with the switchdev notifier,
From: Colin Ian King
Shifting the integer value 1 is evaluated using 32-bit rithmetic
and then used in an expression that expects a 64-bit value, so
there is potentially an integer overflow. Fix this by using th
BIT_ULL macro to perform the shift and avoid the overflow.
Addresses-Coverity:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 61556703b610a104de324e4f061dc6cf7b218b46
commit: 453f26822844bf08991616b9d5def122deba8514 iwlwifi: scan: support scan
req cmd ver 14
date: 11 months ago
config: x86_64-randconfig-m001-20210208 (attached
From: Colin Ian King
The left shift of int 32 bit integer constant 1 is evaluated using 32
bit arithmetic and then assigned to an unsigned 64 bit integer. In the
case where *frag is 32 or more this can lead to an oveflow. Avoid this
by shifting 1ULL.
Addresses-Coverity: ("Unintentional integer
Hi,
congrats to Linux v5.11-rc7.
after commit 6342adcaa683 ("entry: Ensure trap after single-step on
system call return"):
$ git grep '\_TIF_SINGLESTEP' arch/x86/
arch/x86/include/asm/thread_info.h:#define _TIF_SINGLESTEP
(1 << TIF_SINGLESTEP)
Is this a leftover and can be removed (now)?
This removes the braces from the if statement that checks the
wps_ie_len and ieee->wps_ie values in rtllib_association_req of
rtllib_softmac.c as this block contains only one statement.
Fixes a checkpatch warning.
Signed-off-by: Phillip Potter
---
drivers/staging/rtl8192e/rtllib_softmac.c | 3
> On Feb 7, 2021, at 2:31 PM, Dave Hansen wrote:
>
> On 2/7/21 12:29 PM, Kirill A. Shutemov wrote:
>>> Couldn't you just have one big helper that takes *all* the registers
>>> that get used in any TDVMCALL and sets all the rcx bits? The users
>>> could just pass 0's for the things they don't
On Sun, Feb 07, 2021 at 10:15:49AM -0800, Linus Torvalds wrote:
> On Sun, Feb 7, 2021 at 9:58 AM Borislav Petkov wrote:
> >
> > It probably is an item on some Intel manager's to-enable list. So far,
> > the CET enablement concentrates only on userspace but dhansen might know
> > more about future
From: Colin Ian King
There are three occurrances of u32 variables being multiplied by
1000 using 32 bit multiplies and the result being assigned to a
64 bit signed integer. These can potentially lead to a 32 bit
overflows, so fix this by casting 1000 to a UL first to force
a 64 bit multiply
On Fri, Feb 05 2021, Andrew Morton wrote:
> On Fri, 05 Feb 2021 11:36:30 +1100 NeilBrown wrote:
>
>> A recent change to seq_file broke some users which were using seq_file
>> in a non-"standard" way ... though the "standard" isn't documented, so
>> they can be excused. The result is a possible
> This has been shown in tests:
>
> [ +0.08] WARNING: CPU: 3 PID: 7620 at kernel/rcu/srcutree.c:374
> cleanup_srcu_struct+0xed/0x100
>
> This is essentially a use-after free, although SRCU notices it as
> an SRCU cleanup in an invalid context.
...
Acked-by: Dave Hansen
On 2/7/21 12:44 PM, Alexei Starovoitov wrote:
>>> It probably is an item on some Intel manager's to-enable list. So far,
>>> the CET enablement concentrates only on userspace but dhansen might know
>>> more about future plans. CCed.
>> It's definitely on our radar to look at after CET userspace.
>
So it's the biggest sporting day of the year here in the US, when
everybody is getting ready to watch the yearly top TV commercials,
occasionally interrupted by some odd handegg carrying competition that
I still haven't figured out the rules for after twenty-odd years here.
It's kind of a more
On 2/7/21 12:29 PM, Kirill A. Shutemov wrote:
>> Couldn't you just have one big helper that takes *all* the registers
>> that get used in any TDVMCALL and sets all the rcx bits? The users
>> could just pass 0's for the things they don't use.
>>
>> Then you've got the ugly inline asm in one place.
The driver core ignores the return value of mei_cl_device_remove() so
passing an error value doesn't solve any problem. As most mei drivers'
remove callbacks return 0 unconditionally and returning a different value
doesn't have any effect, change this prototype to return void and return 0
> -Original Message-
> From: Matthew Wilcox [mailto:wi...@infradead.org]
> Sent: Monday, February 8, 2021 10:34 AM
> To: Wangzhou (B)
> Cc: linux-kernel@vger.kernel.org; io...@lists.linux-foundation.org;
> linux...@kvack.org; linux-arm-ker...@lists.infradead.org;
>
The driver core only calls a bus' remove function when there is actually
a driver and a device. So drop the needless check and assign cldrv earlier.
(Side note: The check for cldev being non-NULL is broken anyhow, because
to_mei_cl_device() is a wrapper around container_of() for a member that is
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on jeyu/modules-next]
[also build test ERROR on linux/master soc/for-next openrisc/for-next
powerpc/next asm-generic/master linus/master v5.11-rc6 next-20210125]
[cannot apply to tip/x86/core]
[If your patch is
The only usage of them is to assign their address to the 'ops' field in
the pcie_port and the dw_pcie_ep structs, both which are pointers to
const. Make them const to allow the compiler to put them in read-only
memory.
Signed-off-by: Rikard Falkeborn
---
This has been shown in tests:
[ +0.08] WARNING: CPU: 3 PID: 7620 at kernel/rcu/srcutree.c:374
cleanup_srcu_struct+0xed/0x100
This is essentially a use-after free, although SRCU notices it as
an SRCU cleanup in an invalid context.
== Background ==
SGX has a data structure (struct
> On Feb 7, 2021, at 12:31 AM, Zhou Wang wrote:
>
> SVA(share virtual address) offers a way for device to share process virtual
> address space safely, which makes more convenient for user space device
> driver coding. However, IO page faults may happen when doing DMA
> operations. As the
A driver without a probe function isn't useful as it can never be used.
Let registering such a driver fail already instead of failing every
binding.
This is only cosmetic as there is no ipack driver without a probe function.
Signed-off-by: Uwe Kleine-König
---
drivers/ipack/ipack.c | 6 +++---
A driver that only consumes devm-managed resources might well have no
remove callback. Additionally given that the device core ignores the return
value of ipack_bus_remove() stop returning an error code.
Signed-off-by: Uwe Kleine-König
---
drivers/ipack/ipack.c | 5 ++---
1 file changed, 2
On Sun, Feb 7, 2021 at 9:18 AM Zhou Wang wrote:
> diff --git a/arch/arm64/include/asm/unistd32.h
> b/arch/arm64/include/asm/unistd32.h
> index cccfbbe..3f49529 100644
> --- a/arch/arm64/include/asm/unistd32.h
> +++ b/arch/arm64/include/asm/unistd32.h
> @@ -891,6 +891,8 @@
On Sun, Feb 07, 2021 at 04:18:03PM +0800, Zhou Wang wrote:
> SVA(share virtual address) offers a way for device to share process virtual
> address space safely, which makes more convenient for user space device
> driver coding. However, IO page faults may happen when doing DMA
> operations. As the
> +static int mvpp2_get_sram(struct platform_device *pdev,
> + struct mvpp2 *priv)
> +{
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + if (!res) {
> + if (has_acpi_companion(>dev))
> +
On Sun, Feb 07, 2021 at 11:29:49PM +0200, Jarkko Sakkinen wrote:
> On Fri, Feb 05, 2021 at 11:36:57AM -0800, Dave Hansen wrote:
> > On 2/5/21 10:28 AM, Jarkko Sakkinen wrote:
> > > This has been shown in tests:
> > >
> > > [ +0.08] WARNING: CPU: 3 PID: 7620 at kernel/rcu/srcutree.c:374
> >
On Thu, 21 Jan 2021, Jinyang He wrote:
> mm16_r5_format.rt is 5 bits, so directly judge the value if equal or not.
> mm_jalr_op requires 7th to 16th bits. These 10 which bits generated by
The minor opcode extension field is comprised of bits 15:6, not 16:7 as
your description suggests. Please
On Sun, Feb 07, 2021 at 08:38:43PM +0200, stef...@marvell.com wrote:
> From: Stefan Chulski
>
> Patch adds CM3 address space PPv2.3 description.
>
> Signed-off-by: Stefan Chulski
> ---
> Documentation/devicetree/bindings/net/marvell-pp2.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2
On Fri, Feb 05, 2021 at 11:36:57AM -0800, Dave Hansen wrote:
> On 2/5/21 10:28 AM, Jarkko Sakkinen wrote:
> > This has been shown in tests:
> >
> > [ +0.08] WARNING: CPU: 3 PID: 7620 at kernel/rcu/srcutree.c:374
> > cleanup_srcu_struct+0xed/0x100
> >
> > There are two functions that drain
On Fri, Feb 05, 2021 at 09:00:30AM -0800, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> kmap is inefficient and we are trying to reduce the usage in the kernel.
> There is no readily apparent reason why initp_page needs to be allocated
> and kmap'ed() but sigstruct needs to be page aligned
On Fri, Feb 05, 2021 at 08:43:24AM +0100, Daniel Vetter wrote:
> On Fri, Feb 5, 2021 at 3:26 AM Jarkko Sakkinen wrote:
> >
> > On Thu, Feb 04, 2021 at 07:45:19PM +0100, Daniel Vetter wrote:
> > > References:
> > > https://lore.kernel.org/dri-devel/20201127164131.2244124-1-daniel.vet...@ffwll.ch/
The driver core ignores the return value of a bus' remove callback. However
a driver returning an error code is a hint that there is a problem,
probably a driver author who expects that returning e.g. -EBUSY has any
effect.
The right thing to do would be to make struct platform_driver::remove()
On Sat, 6 Feb 2021 14:29:24 -0800 Jakub Kicinski wrote:
> On Fri, 5 Feb 2021 14:35:50 -0800 Andrew Morton wrote:
> > On Fri, 05 Feb 2021 11:36:30 +1100 NeilBrown wrote:
> >
> > > A recent change to seq_file broke some users which were using seq_file
> > > in a non-"standard" way ... though
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 61556703b610a104de324e4f061dc6cf7b218b46
commit: 34f2653686fecc9bd5a4ee16724768c72953fb57 remoteproc: k3-r5: Initialize
TCM memories for ECC
date: 4 months ago
config: arm64-randconfig-s031-20210208
On Sat, Feb 6, 2021 at 12:07 PM Jakub Kicinski wrote:
>
> On Fri, 5 Feb 2021 16:01:43 -0800 Amy Parker wrote:
> > This patchset updates atarilance.c and sun3lance.c to follow the kernel
> > style guide. Each patch tackles a different issue in the style guide.
>
> These are very, very old
On Sun, Feb 7, 2021 at 10:21 AM Dave Hansen wrote:
>
> On 2/7/21 9:58 AM, Borislav Petkov wrote:
> > On Sun, Feb 07, 2021 at 09:49:18AM -0800, Linus Torvalds wrote:
> >> On Sun, Feb 7, 2021 at 2:40 AM Borislav Petkov wrote:
> >>> - Disable CET instrumentation in the kernel so that gcc doesn't
From: Dmitrii Wolf
Hello, developers!
Sorry for the late answer. As you know - i am a newbie and it is my first
kernel patch.
After reading kernelnewbies.or, ./Documentation/process/ files and viewing
FOSDEM's videpo
"Write and Submit your first Linux kernel Patch", i took a decision to
On Sun, Feb 07, 2021 at 08:01:50AM -0800, Dave Hansen wrote:
> On 2/7/21 6:13 AM, Kirill A. Shutemov wrote:
> >>> + /* Allow to pass R10, R11, R12, R13, R14 and R15 down to the VMM
> >>> */
> >>> + rcx = BIT(10) | BIT(11) | BIT(12) | BIT(13) | BIT(14) | BIT(15);
> >>> +
> >>> +
Constify two static structs which are never modified, to allow the
compiler to put them in read-only memory.
The only usage of controller_attribute_group is to put its address in an
array of pointers to const struct attribute_group, and the only usage of
can_power_ops is to assign its address to
Is it possible that the issue is not due to this change?
This change is just to call different API to allocate memory, which is
equivalent to kzalloc()+vzalloc().
Before the change:
try kzalloc(sizeof(*vs), GFP_KERNEL | __GFP_NOWARN | __GFP_RETRY_MAYFAIL);
... and then below if the former is
Remove spaces preceding closing brace of one of the nested if statement
blocks inside the rtl92e_leisure_ps_leave function, and replace with a
tab, to align it properly with the start of the block. Fixes a
checkpatch warning.
Signed-off-by: Phillip Potter
---
)
date: 2 months ago
config: mips-randconfig-r032-20210207 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin
From: Vladimir Oltean
Looking through patchwork I don't see that there was any consensus to
use switchdev notifiers only in case of netlink provided port flags but
not sysfs (as a sort of deprecation, punishment or anything like that),
so we should probably keep the user interface consistent in
Hi Paolo,
On Fri, 5 Feb 2021 11:08:39 +0100 Paolo Bonzini wrote:
>
> On 05/02/21 06:02, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the kvm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > ERROR: modpost: ".follow_pte"
Hi Daniel,
On Thu, 4 Feb 2021 17:58:29 +0100 Daniel Vetter wrote:
>
> Hi all,
>
> This is a revised version of patch 12 from my series to lock down some
> follow_pfn vs VM_SPECIAL races:
>
> https://lore.kernel.org/dri-devel/cakwvodnsrsntgpeuqjyaotsktp2dr9208y66hqg_h1e2lkf...@mail.gmail.com/
The pull request you sent on Sun, 7 Feb 2021 09:37:21 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> tags/libnvdimm-fixes-5.11-rc7
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b75dba7f472ca6c2dd0b8ee41f5a4b5a45539306
Thank you!
--
The pull request you sent on Sun, 7 Feb 2021 17:26:05 +0100:
> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.11-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ff92acb220c506f14aea384a07b130b87ac1489a
Thank you!
--
Deet-doot-dot, I am a bot.
-s032-20210207 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-215
Hi Greg,
> On Sun, Feb 07, 2021 at 02:03:11PM +, Winkler, Tomas wrote:
> > >
> > > On Sat, Feb 06, 2021 at 03:04:34PM +, Winkler, Tomas wrote:
> > > > > On Sat, Feb 06, 2021 at 04:43:25PM +0200, Tomas Winkler wrote:
> > > > > > From: Alexander Usyskin
> > > > > >
> > > > > > Expose the
101 - 200 of 517 matches
Mail list logo
