On Sun, Aug 2, 2020 at 6:40 PM Mike Rapoport wrote:
>
> .clang-format| 2 +-
The .clang-format bit:
Acked-by: Miguel Ojeda
Cheers,
Miguel
Since this is a modern-only device,
tag config space fields as having little endian-ness.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
include/uapi/linux/virtio_pmem.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/virtio_pmem.h
balloon uses virtio32_to_cpu instead of cpu_to_virtio32
to convert a native endian number to virtio.
No practical difference but makes sparse warn.
Fix it up.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
Acked-by: David Hildenbrand
Reviewed-by: Cornelia Huck
---
Hi!
As much as it's worth the changes looks good to me.
@Jan: I guess that we can as well fix this in LTP first then we can try
to get the kernel version fixed...
--
Cyril Hrubis
chru...@suse.cz
For new helpers handling legacy features to be effective,
vhost needs to invoke them. Tie them in.
Signed-off-by: Michael S. Tsirkin
---
drivers/vhost/vdpa.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index
Hi Bartosz,
On Tue, 17 Mar 2020 15:32:56 +0100, Bartosz Golaszewski wrote:
> wt., 17 mar 2020 o 15:14 Jean Delvare napisał(a):
> > Before I start implementing the idea above, I would like to know if
> > anyone objects to it, or has a better idea?
>
> Sounds good to me in general but isn't it
James Bottomley wrote:
> It sort of petered out into a long winding thread about why not use
> sysfs instead, which really doesn't look like a good idea to me.
It seemed to turn into a set of procfs symlinks that pointed at a bunch of
sysfs stuff - or possibly some special filesystem.
> Could
Hello!
On Wed, 5 Aug 2020 at 13:37, Linus Torvalds
wrote:
> On Wed, Aug 5, 2020 at 11:24 AM Guenter Roeck wrote:
> >
> > Same with older versions of gcc. I don't see the problem with the
> > mainline kernel.
>
> https://www.youtube.com/watch?v=-b5aW08ivHU
>
> > I think this is caused by more
Dear friend,
Please accept my apologies, I didn't mean to invade your privacy, but
I wrote you an email already, but I'm not sure you have it, so I'm
resending it to you. I pray that this letter reaches you in good
health. I am Barrister Dossou Patrick. I have a US $ 10 million
business
VDPA sim accesses config space as native endian - this is
wrong since it's a modern device and actually uses LE.
It only supports modern guests so we could punt and
just force LE, but let's use the full virtio APIs since people
tend to copy/paste code, and this is not data path anyway.
Virtio mem is modern-only. Use LE accessors for config space.
Signed-off-by: Michael S. Tsirkin
---
drivers/virtio/virtio_mem.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
index
From: Marc Zyngier
With the backport of f227e3ec3b5c ("random32: update the net random
state on interrupt and activity") and its associated fixes, the
arm64 build explodes early:
In file included from ../include/linux/smp.h:67,
from ../include/linux/percpu.h:7,
On 8/5/20 11:37 AM, Linus Torvalds wrote:
> On Wed, Aug 5, 2020 at 11:24 AM Guenter Roeck wrote:
>>
>> Same with older versions of gcc. I don't see the problem with the
>> mainline kernel.
>
> https://www.youtube.com/watch?v=-b5aW08ivHU
>
>> I think this is caused by more recursive includes.
From: Willy Tarreau
commit 1c9df907da83812e4f33b59d3d142c864d9da57f upstream.
Daniel Díaz and Kees Cook independently reported that commit
f227e3ec3b5c ("random32: update the net random state on interrupt and
activity") broke arm64 due to a circular dependency on include files
since the
_nfs4_get_security_label() and decode_attr_security_label() run severe
risks with memory management and do not fully implement their
functionality. In the case that the buffer and length are both NULL, which
according to the getxattr man page should simply return the length of the
attribute,
> > Well, until the user of this new API is ready, we will not accept the
> > patch.
> OK, but once we submit the change in the driver, is it good to go?
No. You really do need to explain why it is needed, and why it is
safe.
> > You also need to explain "For HW performance reasons". Why is this
On Thu, Jul 16, 2020 at 7:18 PM Lad Prabhakar
wrote:
> Add PCIe{0,1} device nodes for R8A774E1 SoC.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.10.
Gr{oetje,eeting}s,
On Wed, Aug 5, 2020 at 4:14 PM David Howells wrote:
> However, looking up that identifier requires some sort of structure for doing
> this and it's kind of worst case for the IDR tree as the keys are gradually
> going to spread out, causing it to eat more memory. It may be a tradeoff
> worth
From: Grygorii Strashko
commit aa54ea903abb02303bf55855fb51e3fcee135d70 upstream.
Fix build error for the case:
defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
config: keystone_defconfig
CC arch/arm/kernel/signal.o
In file included from ../include/linux/random.h:14,
Move the buffer size check to decode_attr_security_label() before memcpy()
Only call memcpy() if the buffer is large enough
Signed-off-by: Jeffrey Mitchell
---
fs/nfs/nfs4proc.c | 2 --
fs/nfs/nfs4xdr.c | 5 -
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/nfs/nfs4proc.c
This is the start of the stable review cycle for the 5.7.14 release.
There are 6 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 should be made by Fri, 07 Aug 2020 15:34:53 +.
Anything
From: Po-Hsu Lin
Date: Tue, 4 Aug 2020 18:18:01 +0800
> This patchset will address the false-negative return value issue
> caused by the following:
> 1. The return value "ret" in this script will be reset to 0 from
> the beginning of each sub-test in rtnetlink.sh, therefore this
>
On 8/4/20 6:27 PM, Florian Fainelli wrote:
On 7/29/2020 8:12 AM, Lukasz Luba wrote:
Hi all,
The existing CPUFreq framework does not tracks the statistics when the
'fast switch' is used or when firmware changes the frequency independently
due to e.g. thermal reasons. However, the firmware
On 8/5/20 10:04 AM, Sowjanya Komatineni wrote:
On 8/5/20 9:57 AM, Dmitry Osipenko wrote:
05.08.2020 19:50, Sowjanya Komatineni пишет:
On 8/5/20 9:47 AM, Dmitry Osipenko wrote:
05.08.2020 19:33, Sowjanya Komatineni пишет:
On 8/5/20 7:19 AM, Dmitry Osipenko wrote:
05.08.2020 17:05, Dmitry
Hi!
> Rationale:
> 50 already merged patches of mine.
I don't believe anyone really maintains (or uses) CREDITS these days. Maybe
akpm would be willing
to take it?
Best regards,
Pavel
> diff --git a/CREDITS b/CREDITS
>
On Wed, 5 Aug 2020 at 21:22, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.7.14 release.
> There are 6 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.
>
>
Miklos Szeredi wrote:
> > +#ifdef CONFIG_FSINFO
> > + u64 mnt_unique_id; /* ID unique over lifetime of kernel */
> > +#endif
>
> Not sure if it's worth making conditional.
You can't get at it without CONFIG_FSINFO=y as it stands, but making it
unconditional might be reasonable.
On Wed, 5 Aug 2020 at 16:36, Marco Elver wrote:
>
> On Wed, 5 Aug 2020 at 16:17, wrote:
> >
> > On Wed, Aug 05, 2020 at 04:12:37PM +0200, pet...@infradead.org wrote:
> > > On Wed, Aug 05, 2020 at 03:59:40PM +0200, Marco Elver wrote:
> > > > On Wed, Aug 05, 2020 at 03:42PM +0200,
The pull request you sent on Tue, 4 Aug 2020 14:59:29 -0600:
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
> tags/linux-kselftest-kunit-5.9-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/53e5504bdbdb16548e39a4834c97742693964197
Thank you!
On Wed, Aug 05, 2020 at 02:21:07PM +0800, Jason Wang wrote:
>
> On 2020/8/4 上午5:00, Michael S. Tsirkin wrote:
> > VDPA sim accesses config space as native endian - this is
> > wrong since it's a modern device and actually uses LE.
> >
> > It only supports modern guests so we could punt and
> >
Hi Prashant,
> -Original Message-
> From: Prashant Malani
> Sent: Thursday, July 30, 2020 4:25 PM
> To: Shaikh, Azhar
> Cc: ble...@chromium.org; enric.balle...@collabora.com;
> gro...@chromium.org; linux-kernel@vger.kernel.org;
> heikki.kroge...@linux.intel.com; Patel, Utkarsh H
> ;
On 8/5/20 7:23 AM, Colin King wrote:
> From: Colin Ian King
>
> There are various spelling mistakes in comments and error messages.
> Fix these.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/staging/wfx/data_rx.c | 2 +-
> drivers/staging/wfx/data_tx.c | 2 +-
>
On Wed, Aug 05, 2020 at 08:00:55AM -0400, Michael S. Tsirkin wrote:
> On Tue, Aug 04, 2020 at 07:20:36PM +0300, Eli Cohen wrote:
> > Hi Michael,
> > please note that this series depends on mlx5 core device driver patches
> > in mlx5-next branch in
> >
syzbot has revealed that the "phylink" keyword exists in non-phylink
related contexts in the bluetooth stack. To avoid receiving
inappropriate notifications, change the keyword matching regexp to
something which avoids this, while still allowing changes to networking
drivers that make use of
Hi Tom,
Thanks for your patch!
On Tue, Jul 28, 2020 at 3:42 PM wrote:
> From: Tom Rix
>
> Clang static analysis reports this error
>
> gpiolib-of.c:664:9: warning: 2nd function call argument
> is an uninitialized value [core.CallAndMessage]
> ret = gpiod_hog(desc, name, lflags,
On Wed, Aug 05, 2020 at 12:19:58PM +0100, Marc Zyngier wrote:
> On 2020-08-05 10:54, Greg Kroah-Hartman wrote:
> > On Tue, Aug 04, 2020 at 10:23:06PM +0100, Marc Zyngier wrote:
> > > On 2020-08-04 19:33, Linus Torvalds wrote:
> > > > On Tue, Aug 4, 2020 at 1:21 AM Greg Kroah-Hartman
> > > >
On 04-08-20, 22:14, Mark Brown wrote:
> On Fri, Jul 31, 2020 at 03:59:54PM +0300, Serge Semin wrote:
> > On Fri, Jul 31, 2020 at 12:26:12PM +0300, Andy Shevchenko wrote:
> > > On Fri, Jul 31, 2020 at 10:59:45AM +0300, Serge Semin wrote:
>
> > > > Note since the DMA-engine subsystem in kernel
On 5 Aug 2020, at 9:19, xiangxia.m@gmail.com wrote:
From: Tonghao Zhang
ovs_flow_tbl_destroy always is called from RCU callback
or error path. It is no need to check if rcu_read_lock
or lockdep_ovsl_is_held was held.
ovs_dp_cmd_fill_info always is called with ovs_mutex,
So use the
On Wed, Aug 05, 2020 at 09:02:08AM +0200, Alain Volmat wrote:
> From: Amelie Delaunay
>
> The rx dma is completed "after" the last data is received
> from spi. Thus, to avoid loss of rx data, it's mandatory to
> wait for the dma callback before tearing down the rx dma in
> stm32_spi_disable().
On Tue, 4 Aug 2020 12:40:49 -0700
Sean V Kelley wrote:
> From: Qiuxu Zhuo
>
> When attempting error recovery for an RCiEP associated with an RCEC device,
> there needs to be a way to update the Root Error Status, the Uncorrectable
> Error Status and the Uncorrectable Error Severity of the
From: Steffen Klassert
Date: Tue, 4 Aug 2020 07:53:10 +0200
> On Mon, Aug 03, 2020 at 03:13:49PM -0700, David Miller wrote:
>> From: YueHaibing
>> Date: Fri, 31 Jul 2020 14:49:52 +0800
>>
>> > If CONFIG_INET_XFRM_TUNNEL is set but CONFIG_IPV6 is n,
>> >
>> > net/ipv4/ip_vti.c:493:27: warning:
On Wed, Aug 05, 2020 at 09:31:13AM -0400, Boris Ostrovsky wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 8/4/20 7:42 PM, Anchal Agarwal wrote:
> >
>
On 8/5/2020 9:32 AM, Tyler Hicks wrote:
> On 2020-08-05 09:21:24, Lakshmi Ramasubramanian wrote:
>> On 8/5/20 9:14 AM, Tyler Hicks wrote:
>>> On 2020-08-05 09:07:48, Lakshmi Ramasubramanian wrote:
On 8/5/20 8:45 AM, Tyler Hicks wrote:
> On 2020-08-05 08:36:40, Casey Schaufler wrote:
On Wed, Aug 05, 2020 at 09:02:04AM +0200, Alain Volmat wrote:
> From: Antonio Borneo
>
> The caller of stm32_spi_transfer_one(), spi_transfer_one_message(),
> is waiting for us to call spi_finalize_current_transfer() and will
> eventually schedule a new transfer, if available.
> We should
On Tue, 4 Aug 2020 12:40:45 -0700
Sean V Kelley wrote:
> From: Qiuxu Zhuo
>
> If a Root Complex Integrated Endpoint (RCiEP) is implemented, errors may
> optionally be sent to a corresponding Root Complex Event Collector (RCEC).
> Each RCiEP must be associated with no more than one RCEC.
On 8/5/20 10:34 AM, Dmitry Osipenko wrote:
05.08.2020 20:29, Sowjanya Komatineni пишет:
...
UART_FST_MIPI_CAL is the clock used for calibration logic which is FSM
that goes thru sequence codes and when done waits for pads to be in
LP-11 to apply results.
MIPI_CLK is controller gate clock
On Wed, Aug 05, 2020 at 10:27:28AM -0700, Andrii Nakryiko wrote:
> On Wed, Aug 5, 2020 at 10:16 AM Alexei Starovoitov
> wrote:
> >
> > On Wed, Aug 05, 2020 at 04:47:30AM +, Song Liu wrote:
> > >
> > > Being able to trigger BPF program on a different CPU could enable many
> > > use cases and
On 5 Aug 2020, at 10:40, Jonathan Cameron wrote:
On Tue, 4 Aug 2020 12:40:49 -0700
Sean V Kelley wrote:
From: Qiuxu Zhuo
When attempting error recovery for an RCiEP associated with an RCEC
device,
there needs to be a way to update the Root Error Status, the
Uncorrectable
Error Status
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 2324d50d051ec0f14a548e78554fb02513d6dcef
commit: 58b09919626bf9067345289212ec030c61eb1034 mptcp: create msk early
date: 5 months ago
config: powerpc64-randconfig-s031-20200805 (attached as .config
On Wed, Aug 5, 2020 at 7:19 AM Kent Gibson wrote:
>
[snip]
> > >
> > > +/*
> > > + * Maximum number of requested lines.
> > > + *
> > > + * Must be a multiple of 8 to ensure 32/64-bit alignment of structs.
> > > + */
> > > +#define GPIOLINES_MAX 64
> > > +
> > > +/* The number of __u64 required
Hi Jason,
> -Original Message-
> From: Jason Gunthorpe
> Sent: Wednesday, July 22, 2020 12:59 PM
> To: Marc Zyngier
> Cc: Jiang, Dave ; vk...@kernel.org; Dey, Megha
> ; bhelg...@google.com; raf...@kernel.org;
> gre...@linuxfoundation.org; t...@linutronix.de; h...@zytor.com;
>
On Thu, Jul 30, 2020 at 3:37 PM Nick Desaulniers
wrote:
>
> On Mon, Jul 20, 2020 at 4:35 PM David Miller wrote:
> >
> > From: Nick Desaulniers
> > Date: Mon, 20 Jul 2020 12:48:38 -0700
> >
> > > Hi David, bumping for review.
> >
> > If it's not active in my networking patchwork you can't just
From: Colin Ian King
There are various spelling mistakes in comments and error messages.
Fix these.
Signed-off-by: Colin Ian King
---
drivers/staging/wfx/data_rx.c | 2 +-
drivers/staging/wfx/data_tx.c | 2 +-
drivers/staging/wfx/debug.c | 4 ++--
drivers/staging/wfx/hif_rx.c | 2 +-
From: Colin Ian King
There a handful of spelling mistakes. fix them.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 4 ++--
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
On Wed, Aug 5, 2020 at 10:45 AM Alexei Starovoitov
wrote:
>
> On Wed, Aug 05, 2020 at 10:27:28AM -0700, Andrii Nakryiko wrote:
> > On Wed, Aug 5, 2020 at 10:16 AM Alexei Starovoitov
> > wrote:
> > >
> > > On Wed, Aug 05, 2020 at 04:47:30AM +, Song Liu wrote:
> > > >
> > > > Being able to
On 8/5/2020 10:25 AM, Lakshmi Ramasubramanian wrote:
> On 8/5/20 10:03 AM, Mimi Zohar wrote:
>> On Wed, 2020-08-05 at 10:45 -0500, Tyler Hicks wrote:
>>
>>> In addition to SELINUX_STATE and SELINUX_POLICY, we should also consider
>>> the proposed LSM_STATE and LSM_POLICY func values but require an
On 8/5/20 11:32 AM, Linus Torvalds wrote:
On Wed, Aug 5, 2020 at 7:13 AM Shuah Khan wrote:
Please pull the following Kselftest update for Linux 5.9-rc1.
Ok, it worked fine this time, although now you lost the note about the
conflict ;)
Sorry about that. I should have included that as
From: Colin Ian King
There is a spelling mistake in a dev_dbg message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/power/supply/pm2301_charger.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/pm2301_charger.c
On Wed, Aug 5, 2020 at 11:19 AM Sami Tolvanen wrote:
>
> Commit 7c78f67e9bd9 ("arm64: enable tlbi range instructions") breaks
> LLVM's integrated assembler, because -Wa,-march is only passed to
> external assemblers and therefore, the new instructions are not enabled
> when IAS is used.
>
> As
Host dtc may not support the same flags as kernel's copy of dtc. Test
if dtc supports each flag when the dtc comes from host.
Signed-off-by: Elliot Berman
---
scripts/Makefile.lib | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git
From: xiangxia.m@gmail.com
Date: Wed, 5 Aug 2020 15:19:11 +0800
> From: Tonghao Zhang
>
> ovs_flow_tbl_destroy always is called from RCU callback
> or error path. It is no need to check if rcu_read_lock
> or lockdep_ovsl_is_held was held.
>
> ovs_dp_cmd_fill_info always is called with
From: Colin Ian King
There is a spelling mistake in a literal string. Fix it.
Signed-off-by: Colin Ian King
---
drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
On Tue, Aug 04, 2020 at 12:40:43PM -0700, Sean V Kelley wrote:
> From: Sean V Kelley
>
> On the use of FLR on RCiEPs for the fatal case, still interested in more
> feedback from the earlier discussion here [1]:
>
> [1]
>
IPQ8074 has A53 cores, so lets use the corresponding PMU compatible.
Signed-off-by: Kathiravan T
---
arch/arm64/boot/dts/qcom/ipq8074.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index
From: Colin Ian King
There is a spelling mistake in a dev_dbg message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
On 8/4/20 9:40 PM, Guoyu Huang wrote:
> when ctx->sqo_mm is zero, io_sq_wq_submit_work() frees 'req'
> without deleting it from 'task_list'. After that, 'req' is
> accessed in io_ring_ctx_wait_and_kill() which lead to
> a use-after-free.
This looks like an old one, that affects 5.4 only. I've
On 8/5/20 10:57 AM, Casey Schaufler wrote:
On 8/5/2020 10:25 AM, Lakshmi Ramasubramanian wrote:
On 8/5/20 10:03 AM, Mimi Zohar wrote:
On Wed, 2020-08-05 at 10:45 -0500, Tyler Hicks wrote:
In addition to SELINUX_STATE and SELINUX_POLICY, we should also consider
the proposed LSM_STATE and
On 8/4/20 7:42 PM, Anchal Agarwal wrote:
>
> I think this could be done. PM_HIBERNATION_PREPARE could return -ENOTSUPP
> for arm and pvh dom0 when the notifier call chain is invoked for this case
> in hibernate(). This will then be an empty notifier just for checking two
> usecases.
> Also, for
On 5 Aug 2020, at 10:43, Bjorn Helgaas wrote:
On Tue, Aug 04, 2020 at 12:40:46PM -0700, Sean V Kelley wrote:
From: Qiuxu Zhuo
When an RCEC device signals error(s) to a CPU core, the CPU core
needs to walk all the RCiEPs associated with that RCEC to check
errors. So add the function
On Wed, Aug 05, 2020 at 11:28:31AM -0700, Andy Lutomirski wrote:
> On Wed, Aug 5, 2020 at 10:07 AM Ricardo Neri
> wrote:
> >
> > On Wed, Aug 05, 2020 at 07:08:08AM +0200, Borislav Petkov wrote:
> > > On Tue, Aug 04, 2020 at 09:58:25PM -0700, h...@zytor.com wrote:
> > > > Because why use an
On 8/5/2020 11:08 AM, Lakshmi Ramasubramanian wrote:
> On 8/5/20 10:57 AM, Casey Schaufler wrote:
>> On 8/5/2020 10:25 AM, Lakshmi Ramasubramanian wrote:
>>> On 8/5/20 10:03 AM, Mimi Zohar wrote:
On Wed, 2020-08-05 at 10:45 -0500, Tyler Hicks wrote:
> In addition to SELINUX_STATE and
On 8/5/20 10:39 AM, Naresh Kamboju wrote:
> On Wed, 5 Aug 2020 at 21:22, Greg Kroah-Hartman
> wrote:
>>
>> This is the start of the stable review cycle for the 5.7.14 release.
>> There are 6 patches in this series, all will be posted as a response
>> to this one. If anyone has any issues with
Are these likely to get merged into 5.9?
On Wed, Jun 3, 2020 at 3:14 PM Ashish Kalra wrote:
>
> Hello Steve,
>
> On Mon, Jun 01, 2020 at 01:02:23PM -0700, Steve Rutherford wrote:
> > On Mon, May 18, 2020 at 12:07 PM Ashish Kalra wrote:
> > >
> > > Hello All,
> > >
> > > Any other feedback,
On Wed, Aug 5, 2020 at 10:07 AM Ricardo Neri
wrote:
>
> On Wed, Aug 05, 2020 at 07:08:08AM +0200, Borislav Petkov wrote:
> > On Tue, Aug 04, 2020 at 09:58:25PM -0700, h...@zytor.com wrote:
> > > Because why use an alternative to jump over one instruction?
> > >
> > > I personally would prefer to
Linus,
The following changes since commit 8038a922cf9af5266eaff29ce996a0d1b788fc0d:
Merge tag 'kvmarm-fixes-5.8-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
(2020-07-06 13:05:38 -0400)
are available in the Git repository at:
On Wed, Aug 5, 2020 at 7:27 PM Pavel Machek wrote:
> > 2. In the past few merge windows we have seen an increase in (usually
> >older) Android phones and tablets gaining mainline kernel support.
> >This time we get a total of eight Snapdragon phones and two Tegra
> >tablets. To me
On Wed, 2020-08-05 at 19:22 +0100, Russell King - ARM Linux admin wrote:
> On Wed, Aug 05, 2020 at 11:11:28AM -0700, Linus Torvalds wrote:
> > On Wed, Aug 5, 2020 at 7:34 AM Russell King
> > wrote:
> > > Is this something you're willing to merge directly please?
> >
> > Done.
> >
> > That
On Wed, 2020-08-05 at 19:22 +0100, Russell King - ARM Linux admin wrote:
> On Wed, Aug 05, 2020 at 11:11:28AM -0700, Linus Torvalds wrote:
> > On Wed, Aug 5, 2020 at 7:34 AM Russell King
> > wrote:
> > > Is this something you're willing to merge directly please?
> >
> > Done.
> >
> > That
On Wed, 2020-08-05 at 09:12 -0400, Michael S. Tsirkin wrote:
> On Wed, Aug 05, 2020 at 04:01:58PM +0300, Eli Cohen wrote:
> > On Wed, Aug 05, 2020 at 08:48:52AM -0400, Michael S. Tsirkin wrote:
> > > > Did you merge this?:
> > > > git pull
> > > >
Hi Thomas,
> -Original Message-
> From: Thomas Gleixner
> Sent: Wednesday, July 22, 2020 1:45 PM
> To: Jiang, Dave ; vk...@kernel.org; Dey, Megha
> ; m...@kernel.org; bhelg...@google.com;
> raf...@kernel.org; gre...@linuxfoundation.org; h...@zytor.com;
> alex.william...@redhat.com; Pan,
Hi!
On Wed, Aug 05, 2020 at 04:40:16PM +, Christophe Leroy wrote:
> >It cannot optimise it because it does not know shift < 32. The code
> >below is incorrect for shift equal to 32, fwiw.
>
> Is there a way to tell it ?
Sure, for example the &31 should work (but it doesn't, with the GCC
Hi Pavel,
On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek wrote:
> > I have submitted the below as a topic for the linux/arch/* MC that Mike
> > and I run, but I suppose it also makes sense to discuss it on the
> > ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as well
> > even
Hi Marc,
> -Original Message-
> From: Marc Zyngier
> Sent: Wednesday, July 22, 2020 11:53 AM
> To: Jiang, Dave
> Cc: vk...@kernel.org; Dey, Megha ;
> bhelg...@google.com; raf...@kernel.org; gre...@linuxfoundation.org;
> t...@linutronix.de; h...@zytor.com; alex.william...@redhat.com;
> On Aug 5, 2020, at 10:16 AM, Alexei Starovoitov
> wrote:
>
> On Wed, Aug 05, 2020 at 04:47:30AM +, Song Liu wrote:
>>
>> Being able to trigger BPF program on a different CPU could enable many
>> use cases and optimizations. The use case I am looking at is to access
>> perf_event and
On 05/08/20 19:10, Ben Gardon wrote:
>>
>> Alternatively, what about moving this logic into mmu_page_zap_pte()? That
>> can be done with a little massaging of FNAME(invlpg) and would avoid what is
>> effectively redundant checks on is_shadow_present_pte() and is_last_spte().
>> Patches attached
On Wed, Aug 5, 2020 at 11:24 AM Guenter Roeck wrote:
>
> Same with older versions of gcc. I don't see the problem with the
> mainline kernel.
https://www.youtube.com/watch?v=-b5aW08ivHU
> I think this is caused by more recursive includes.
> arch/arm64/include/asm/archrandom.h includes
On 8/5/20 11:01 AM, Linus Torvalds wrote:
> On Wed, Aug 5, 2020 at 10:39 AM Naresh Kamboju
> wrote:
>>
>> [ sorry if it is not interesting ! ]
>
> It's a bit interesting only because it is so odd.
>
>> While building with old gcc-7.3.0 the build breaks for arm64
>> whereas build PASS on gcc-8,
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
On 05/08/2020 19:14, Joe Perches wrote:
> Found when Colin King fixed a typo for falied/failed
> and a git grep showed 2 entries in this file.
>
> Signed-off-by: Joe Perches
> ---
>
> scripts/spelling.txt | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/scripts/spelling.txt
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Hi Ingo, Joerg,
On Mon, Aug 03, 2020 at 09:03:54PM +0200, Ingo Molnar wrote:
> Linus,
>
> Please pull the latest x86/mm git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-2020-08-03
>
># HEAD: 2b32ab031e82a109e2c5b0d30ce563db0fe286b4 x86/mm/64: Make
>
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
On Wed, Aug 05, 2020 at 11:11:28AM -0700, Linus Torvalds wrote:
> On Wed, Aug 5, 2020 at 7:34 AM Russell King
> wrote:
> >
> > Is this something you're willing to merge directly please?
>
> Done.
>
> That said:
>
> > -K: phylink
> > +K:
> >
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
Drivers using legacy power management .suspen()/.resume() callbacks
have to manage PCI states and device's PM states themselves. They also
need to take care of standard configuration registers.
Switch to generic power management framework using a single
"struct dev_pm_ops" variable to take the
On Wed, Aug 5, 2020 at 7:34 AM Russell King wrote:
>
> Is this something you're willing to merge directly please?
Done.
That said:
> -K: phylink
> +K:
>
501 - 600 of 1106 matches
Mail list logo
