Only BOOK3S and FSL_BOOK3E have a usefull update_mmu_cache().
For the others, just define it static inline.
In the meantime, simplify the FSL_BOOK3E related ifdef as
book3e_hugetlb_preload() only exists when CONFIG_PPC_FSL_BOOK3E
is selected.
Signed-off-by: Christophe Leroy
---
update_mmu_cache() is only for BOOK3S, and can be simplified
for BOOK3S32.
Move it out of mem.c into respective BOOK3S32 and BOOK3S64
files containing hash utils.
BOOK3S64 version of hash_preload() is only used locally,
declare it static.
Remove the radix_enabled() stuff in BOOK3S32 version.
On BOOK3S32, hash_preload() neither use is_exec nor trap,
so drop those parameters and simplify update_mmu_cached().
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/book3s32/mmu.c | 29 +++--
arch/powerpc/mm/mmu_decl.h | 3 +--
arch/powerpc/mm/pgtable_32.c |
Move FSL_BOOK3E version of update_mmu_cache() at the same
place as book3e_hugetlb_preload() as update_mmu_cache() is
the only user of book3e_hugetlb_preload().
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/hugetlb.h | 3 ---
arch/powerpc/mm/mem.c |
On powerpc 603, there is no hash table so get out of
update_mmu_cache() early.
Signed-off-by: Christophe Leroy
---
arch/powerpc/mm/book3s32/mmu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c
index
Fintek F81504A/508A/512A is PCIE to 4/8/12 UARTs device. It's support
IO/MMIO/PCIE conf to access all functions. The old F81504/508/512 is
only support IO.
Signed-off-by: Ji-Ze Hong (Peter Hong)
---
drivers/tty/serial/8250/8250_pci.c | 121 +
1 file changed,
On Thu, Aug 15, 2019 at 7:42 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> scripts/link-vmlinux.sh
>
> between commit:
>
> e167191e4a8a ("kbuild: Parameterize kallsyms generation and correct
> reporting")
>
> from the kbuild
For i.MX6 SoloX, there is a mode of the SoC to shutdown all power
source of modules during system suspend and resume procedure.
Thus, AUDMUX needs to save all the values of registers before the
system suspend and restore them after the system resume.
Signed-off-by: Shengjiu Wang
---
From: Hayes Wang
Date: Fri, 16 Aug 2019 02:59:16 +
> David Miller [mailto:da...@davemloft.net]
>> Sent: Friday, August 16, 2019 4:59 AM
> [...]
>> Theoretically, yes.
>>
>> But do you have actual performance numbers showing this to be worth
>> the change?
>>
>> Always provide performance
In cm_write(), 'buf' is allocated through kzalloc(). In the following
execution, if an error occurs, 'buf' is not deallocated, leading to memory
leaks. To fix this issue, free 'buf' before returning the error.
Signed-off-by: Wenwen Wang
---
drivers/acpi/custom_method.c | 5 -
1 file
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-verity-verify-sig.c: In function 'verity_verify_get_sig_from_key':
drivers/md/dm-verity-verify-sig.c:38:8: error: too few arguments to function
'request_key'
key =
Will Deacon writes:
> On Tue, Aug 06, 2019 at 07:34:36PM -0700, Peter Collingbourne wrote:
>> On Tue, Aug 6, 2019 at 4:50 PM Stephen Rothwell
>> wrote:
>> > After merging the arm64 tree, today's linux-next build (powerpc
>> > ppc64_defconfig) was just spinning in make - it executing some
Hi Stephen.
On Fri, Aug 16, 2019 at 01:31:32PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> warning: same module names found:
>
Hi all,
Today's linux-next merge of the keys tree got a conflict in:
fs/crypto/keyinfo.c
between commit:
feed82586191 ("fscrypt: rename keyinfo.c to keysetup.c")
from the fscrypt tree and commit:
f802f2b3a991 ("keys: Replace uid/gid/perm permissions checking with an ACL")
from the
On 15-08-19, 21:25, Jassi Brar wrote:
> On Mon, Jun 24, 2019 at 1:47 AM Vinod Koul wrote:
> >
> > On 12-06-19, 19:52, jassisinghb...@gmail.com wrote:
> >
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > >
In acpi_pci_irq_enable(), 'entry' is allocated by invoking
acpi_pci_irq_lookup(). However, it is not deallocated if
acpi_pci_irq_valid() returns false, leading to a memory leak. To fix this
issue, free 'entry' before returning 0.
Signed-off-by: Wenwen Wang
---
drivers/acpi/pci_irq.c | 4 +++-
1
On 14-08-19, 10:19, Stephen Boyd wrote:
> Quoting Vinod Koul (2019-08-14 05:29:58)
> > Add support for rpmh clocks found in SM8150
> >
> > Signed-off-by: Vinod Koul
> > ---
>
> Patch looks OK, but can you convert this driver to use the new parent
> style and then update the binding to handle
On 08/15/2019 11:33 AM, Kelsey Skunberg wrote:
This series is designed to clean up device attributes and permissions in
pci-sysfs.c. Then move the sysfs SR-IOV functions from pci-sysfs.c to
iov.c for better organization.
Patch 1: Define device attributes with DEVICE_ATTR* instead of __ATTR*.
Hi Xiaowei,
> -Original Message-
> From: Xiaowei Bao
> Sent: 2019年8月6日 14:16
> To: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.com; a...@arndb.de; gre...@linuxfoundation.org;
> M.h. Lian ; Mingkai
I'm looking at my new dmesg log after logging out of my wifi and then
reactivating it and I find this error in my dmesg logs.
new
Description: Binary data
Hello Stephen,
Thanks for the patch, I have tested it on the device.
On 8/14/2019 3:11 AM, Stephen Boyd wrote:
Calls to clk_core_get() will return ERR_PTR(-EINVAL) if we've started
migrating a clk driver to use the DT based style of specifying parents
but we haven't made any DT updates yet.
In proc_BSSList_open(), 'file->private_data' is allocated through kzalloc()
and 'data->rbuffer' is allocated through kmalloc(). In the following
execution, if an error occurs, they are not deallocated, leading to memory
leaks. To fix this issue, free the allocated memory regions before
returning
Hi Andrea,
Thank you for reporting this bug.
On Mon, 12 Aug 2019 20:43:02 +0200
Andrea Righi wrote:
> lockdep reports the following:
>
> WARNING: possible circular locking dependency detected
>
> kworker/1:1/48 is trying to acquire lock:
> 8d7a62b2 (text_mutex){+.+.}, at:
In vfio_pci_enable(), save the device's initial configuration information
and then restore the configuration in vfio_pci_disable(). However, the
execution result is not the same. Since the pci_try_reset_function()
function saves the current state before resetting, the configuration
information
Hi ARM-SoC team,
Please consider to pull the following fixes.
Thanks!
Best Regards,
Wei
---
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
Hi Boris,
Well noted, will have Tony in loop from now on. Thanks.
Regards,
Rahul
On 15/8/2019 8:22 PM, Borislav Petkov wrote:
On Thu, Aug 15, 2019 at 05:46:46PM +0800, Rahul Tanwar wrote:
This patch adds a new variant of Intel Atom Airmont CPU model used in a
network processor SoC named
Hi Thomas,
Thanks for your comments.
On 15/8/2019 6:31 PM, Thomas Gleixner wrote:
Rahul,
On Thu, 15 Aug 2019, Rahul Tanwar wrote:
Please use the proper prefix for your patches. x86 uses
x86/subsystem: not x86: subsystem:
Well noted.
This patch replaces direct values usage with
[adding mailing lists etc. with Nathaniel's test info]
On 8/15/19 7:21 PM, Nathaniel Russell wrote:
> Well i surpressed the uvcvideo driver and you are right Randy it
> definitely is not the uvcvideo driver. There is something going on in
> the i915 driver.
>
>
> On 8/15/19, Randy Dunlap
Hi Saravana,
On 8/15/19 6:50 PM, Saravana Kannan wrote:
> On Fri, Aug 9, 2019 at 10:20 PM Frank Rowand wrote:
>>
>> On 8/9/19 10:00 PM, Saravana Kannan wrote:
>>> On Fri, Aug 9, 2019 at 7:57 PM Frank Rowand wrote:
Hi Saravana,
On 7/31/19 3:17 PM, Saravana Kannan wrote:
>
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月15日 20:51
> To: Xiaowei Bao
> Cc: jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.com;
David Miller [mailto:da...@davemloft.net]
> Sent: Friday, August 16, 2019 4:59 AM
[...]
> Theoretically, yes.
>
> But do you have actual performance numbers showing this to be worth
> the change?
>
> Always provide performance numbers with changes that are supposed to
> improve performance.
On
Sometimes I see rcu_urgent_qs is not set. This could be when the last
IPI was a long time ago, however, the grace period just started. Set
rcu_urgent_qs so the tick can indeed not be stopped.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 1 +
1 file changed, 1 insertion(+)
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月15日 19:54
> To: Xiaowei Bao
> Cc: jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.com;
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月15日 19:32
> To: Xiaowei Bao
> Cc: jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.com;
On Thu, Aug 15, 2019 at 10:53:10PM -0400, Joel Fernandes (Google) wrote:
> Sometimes I see rcu_urgent_qs is not set. This could be when the last
> IPI was a long time ago, however, the grace period just started. Set
> rcu_urgent_qs so the tick can indeed be stopped.
Here I meant:
Issue:
- # hwclock -w
hwclock: RTC_SET_TIME: Invalid argument
Why:
- Relative patch: https://lkml.org/lkml/2019/4/3/55 , this patch
will always check for unwritable registers, it will compare reg
with max_register in regmap_writeable.
- In
Sometimes I see rcu_urgent_qs is not set. This could be when the last
IPI was a long time ago, however, the grace period just started. Set
rcu_urgent_qs so the tick can indeed be stopped.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 1 +
1 file changed, 1 insertion(+)
diff
I really cannot explain this patch, but without it, the "else if" block
just doesn't execute thus causing the tick's dep mask to not be set and
causes the tick to be turned off.
I tried various _ONCE() macros but the only thing that works is this
patch.
Signed-off-by: Joel Fernandes (Google)
This commit fixes the issue.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0512de9ead20..322b1b57967c 100644
--- a/kernel/rcu/tree.c
+++
On 8/15/2019 9:30 PM, Stephen Boyd wrote:
These aren't useful and they reference the init structure name. Let's
just drop them.
Cc: Taniya Das
Signed-off-by: Stephen Boyd
---
Acked-by: Taniya Das
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code
On Sat, Jul 20, 2019 at 07:29:49AM +0800, Yin Fengwei wrote:
> syzbot reported general protection fault in kstrtouint:
> https://lkml.org/lkml/2019/7/18/328
>
> From the log, if the mount option is something like:
>fd,
>
> The default parameter (which has NULL
On Thu, 15 Aug 2019 at 20:25, Uwe Kleine-König
wrote:
>
> On Thu, Aug 15, 2019 at 07:05:53PM +0800, Baolin Wang wrote:
> > On Thu, 15 Aug 2019 at 18:11, Uwe Kleine-König
> > wrote:
> > >
> > > Hello,
> > >
> > > On Thu, Aug 15, 2019 at 05:34:02PM +0800, Baolin Wang wrote:
> > > > On Thu, 15 Aug
Hi Alex,
On Thu, 15 Aug 2019 21:52:19 -0400 Alex Deucher wrote:
>
> Yes, sorry, just pushed out now.
Excellent, thanks.
--
Cheers,
Stephen Rothwell
pgpO8j1uoiXrU.pgp
Description: OpenPGP digital signature
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2019.08.13a
head: 6526f1dba87b58de082c55f69fea5632213ebb65
commit: 6a534fc062a9e2e879021b2b038438eb8a479ac6 [35/60] rcutorture: Force on
tick for readers and callback flooders
config: x86_64-rhel
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
scripts/link-vmlinux.sh
between commit:
e167191e4a8a ("kbuild: Parameterize kallsyms generation and correct
reporting")
from the kbuild tree and commits:
341dfcf8d78e ("btf: expose BTF info through sysfs")
> > > > Subject: rtc: pcf85363/pcf85263: fix error that failed to run
> > > > hwclock -w
> > > >
> > > > Issue:
> > > > # hwclock -w
> > > > hwclock: RTC_SET_TIME: Invalid argument
> > > >
> > > > The patch fixes error when run command hwclock -w with rtc
> > > > pcf85363/pcf85263
> > >
>
On 8/14/19 11:00 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.139 release.
There are 69 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
Deliver the display refresh events to the user land. Userspace can use
the irq mask/unmask mechanism to disable or enable the event delivery.
As we know, delivering refresh event at each vblank safely avoids
tearing and unexpected event overwhelming, but there are still spaces
to optimize.
For
Gvt-g emulates and injects the vGPU's display interrupts in kernel
space. However the dma-buf based framebuffer consumer in the user
land (e.g. Qemu vfio/display) may also need to be notified by this
event.
Register the display irq as VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ to
each vGPU, so that the
Cap the number of irqs with fixed indexes and use capability chains
to chain device specific irqs.
Signed-off-by: Tina Zhang
Signed-off-by: Eric Auger
---
include/uapi/linux/vfio.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/vfio.h
From: Kechen Lu
This patch adds the cursor plane CURBASE reg update trap handler
in order to:
- Deliver the cursor refresh event at each vblank emulation,
the flip_done_event bit check is supposed to do here. If cursor
plane updates happen, deliver the cursor refresh events.
- Support the sync
Introduce vGPU specific irq type VFIO_IRQ_TYPE_GFX, and
VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ as the subtype for vGPU display.
Introduce vfio_irq_info_cap_display_plane_events capability to notify
user space with the vGPU's plane update events
v2:
- Add VFIO_IRQ_SUBTYPE_GFX_DISPLAY_IRQ description.
From: Kechen Lu
Only sync primary plane page flip events are checked and delivered
as the display refresh events before, this patch tries to deliver async
primary page flip events bounded by vblanks.
To deliver correct async page flip, the new async flip bitmap is
introduced and in vblank
This series tries to send the vGPU display refresh event to user land.
Instead of delivering page flip events only or vblank events only, we
choose to combine two of them, i.e. post display refresh event at vblanks
and skip some of them when no page flip happens. Vblanks as upper bound
are
Hi John,
On 2019/7/30 21:29, John Garry wrote:
As reported in [1], the hisi-lpc driver has certain issues in handling
logical PIO regions, specifically unregistering regions.
This series add a method to unregister a logical PIO region, and fixes up
the driver to use them.
RCU usage in logical
The ioventfd/irqfd based on eventfd is one mechanism that is widely used
to implement virtio kernel backend driver. After the ioreq is trigged from
virtio front driver, the eventfd_signal is called to notify the eventfd so
that the virtio kernel backend driver is waked up to handle the request.
The px/cx data is critical to support the power transition. DM will get
these data to build DSDT for UOS. With this DSDT, UOS would have the
capability on power control if acpi-cpufreq/idle driver is enabled in
kernel.
Add the PM ioctl that is used to obtain the info of power state
so that the DM
After lapic is switched from xapic to x2apic mode, it can use the APIC
MSR register to access local apic register in ACRN guest. This will
help to remove some traps of lapic access in ACRN guest.
Report the X2APIC so that the ACRN guest can be switched to x2apic mode.
Co-developed-by: Jason Chen
In order to assure that the ACRN module can work with the required ACRN
hypervisor, it needs to check whether the required version is consistent
with the queried version from ACRN ypervisor. If it is inconsistent, it
won't coninue the initialization of ACRN_HSM module.
Similarly the user-space
ACRN hypervisor service module is the important middle layer that allows
the Linux kernel to communicate with the ACRN hypervisor. It includes
the management of virtualized CPU/memory/device/interrupt for other ACRN
guest. The user-space applications can use the provided ACRN ioctls to
interact
Pass-through device plays an important role for guest OS when it is
accessed exclusively by guest OS. This is critical for the performance
scenario. After one PCI device is assigned to guest OS, it can be
accessed exclusively by guest system. It can avoid the device emulation
and provide the
On Thu, Aug 15, 2019 at 06:09:28PM +0200, Dario Faggioli wrote:
> On Wed, 2019-08-07 at 10:10 -0700, Tim Chen wrote:
> > On 8/7/19 1:58 AM, Dario Faggioli wrote:
> >
> > > Since I see that, in this thread, there are various patches being
> > > proposed and discussed... should I rerun my
After ACRN hypervisor captures the io_request(mmio, IO, PCI access) from
guest OS, it will send the IRQ interrupt to SOS system.
The HYPERVISOR_CALLBACK_VECTOR ISR handler will be executed and it
needs to call the driver-specific ISR handler to dispatch emulated
io_request.
After the emulation of
In order to launch the ACRN guest system, it needs to setup the mapping
between GPA (guest physical address) and HPA (host physical address).
This is based on memory virtualization and configured in EPT table.
The ioctl related with memory management is added and then the hypercall
is called so
After guest UOS is booted, the MMIO/IO access will cause that
it exits from VMX non-root env into ACRN hypervisor. Then the ACRN
hypervisor will inject virtual irq into the Linux guest with ACRN HSM
module. The ACRN_HSM handles this virtual irq (which is based on
HYPERVISOR_CALLBACK_VECTOR),
After ACRN devicemodel finishes the emulation of trapped MMIO/IO/PCICFG
access, it needs to inject one interrupt to notify that the guest can be
resumed.
IC_SET_IRQLINE: This is used to inject virtual IOAPIC gsi interrupt
IC_INJECT_MSI: Inject virtual MSI interrupt to guest OS
IC_VM_INTR_MONITOR:
When ACRN hypervisor is detected, the hypercall is needed so that the
ACRN guest can query/config some settings. For example: it can be used
to query the resources in hypervisor and manage the CPU/memory/device/
interrupt for guest operating system.
On x86 it is implemented with the VMCALL
The ACRN-hypervisor works in partition mode. In such case the guest OS
and domain0 kernel will run in the different CPUs. In course of booting
domain0 kernel, it can use all the available CPUs,which can accelerate
the booting. But after the booting is finished, it needs to offline the
other CPUs
After the ACRN hypervisor sends the upcall notify interrupt, the upcall ISR
handler will be served. Now almost nothing is handled in upcall ISR handler
except acking EOI.
The driver-specific ISR handler is registered by the driver, which helps to
handle the real notification from ACRN hypervisor.
ACRN is a flexible, lightweight reference hypervisor, built with real-time
and safety-criticality in mind, optimized to streamline embedded development
through an open source platform. It is built for embedded IOT with small
footprint and real-time features. More details can be found
in
After the user-space calls the ioctls, the module will then call the
defined hypercall so that the ACRN hypervisor can take the corresponding
action. It includes the management of creating vcpu, guest memory
management and interrupt injection, pass-through device management.
The available
The VM management is one important role of acrn module. It is used to
manage another VM based on the user-space ioctls. It includes the
following VM operation: CREATE/START/PAUSE/DESTROY VM, CREATE_VCPU,
IC_SET_VCPU_REGS.
acrn_ioctl is provided so that the user of /dev/acrn_hsm can manage
the VM
Now __irq_build_affinity_masks() spreads vectors evenly per node, and
all vectors may not be spread in case that each numa node has different
CPU number, then the warning in irq_build_affinity_masks() can
be triggered.
Improve current spreading algorithm by assigning vectors according to
the
Hi Thomas,
The 1st patch makes __irq_build_affinity_masks() more reliable, such as,
all nodes can be covered in the spread.
The 2nd patch spread vectors on node according to the ratio of this node's
CPU number to number of all remaining CPUs, then vectors assignment can
become more fair.
One invariant of __irq_build_affinity_masks() is that all CPUs in the
specified masks( cpu_mask AND node_to_cpumask for each node) should be
covered during the spread. Even though all requested vectors have been
reached, we still need to spread vectors among remained CPUs. The similar
policy has
On Mon, Jun 24, 2019 at 1:47 AM Vinod Koul wrote:
>
> On 12-06-19, 19:52, jassisinghb...@gmail.com wrote:
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Do we need both, IIRC of_dma.h does
This patch prints the stddev and hist for the cycles diff of
program block. It can help us to understand if the cycles
is noisy or not.
This patch is inspired by Andi Kleen's patch
https://lwn.net/Articles/600471/
We create new option '--cycles-hist'.
Example:
perf record -b ./div
perf record
On 8/15/19 10:41 AM, John Hubbard wrote:
> On 8/15/19 10:32 AM, Ira Weiny wrote:
>> On Thu, Aug 15, 2019 at 03:35:10PM +0200, Jan Kara wrote:
>>> On Thu 15-08-19 15:26:22, Jan Kara wrote:
On Wed 14-08-19 20:01:07, John Hubbard wrote:
> On 8/14/19 5:02 PM, John Hubbard wrote:
...
>> Ok
On Thu, Aug 15, 2019 at 02:26:03PM -0700, Andrew Morton wrote:
> On Thu, 15 Aug 2019 09:34:34 -0700 "Darrick J. Wong"
> wrote:
>
> > While active, the media backing a swap file is leased to the kernel.
> > Userspace has no business writing to it. Make sure we can't do this.
>
> I don't think
On 8/14/19 11:00 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.67 release.
There are 91 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
On 8/14/19 10:59 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.9 release.
There are 144 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
On Fri, Aug 16, 2019 at 12:20 AM Logan Gunthorpe wrote:
>
>
>
> On 2019-08-15 3:31 a.m., Greentime Hu wrote:
> > Hi Logan,
> >
> > On Thu, Aug 15, 2019 at 6:21 AM Logan Gunthorpe wrote:
> >>
> >> Hey,
> >>
> >> On 2019-08-14 7:35 a.m., Greentime Hu wrote:
> >>> How about this fix? Not sure if it
On Wed, Aug 14, 2019 at 4:41 PM Rob Herring wrote:
>
> On Tue, Aug 6, 2019 at 4:04 PM Saravana Kannan wrote:
> >
> > On Tue, Aug 6, 2019 at 2:27 PM Rob Herring wrote:
> > >
> > > On Tue, Aug 6, 2019 at 1:27 PM Saravana Kannan
> > > wrote:
> > > >
> > > > PowerPC platforms don't use the
On Thu, 2019-08-15 at 17:16 -0500, Bjorn Helgaas wrote:
> On Fri, Jul 26, 2019 at 02:43:11PM -0700,
> sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > From: Kuppuswamy Sathyanarayanan
> >
> >
> > Commit bdb5ac85777d ("PCI/ERR: Handle fatal error recovery") uses
> > reset_link() to recover
On Thu, Aug 15, 2019 at 9:19 AM Georgi Djakov wrote:
>
> Hi,
>
> On 8/8/19 01:31, Saravana Kannan wrote:
> > Interconnects and interconnect paths quantify their performance levels in
> > terms of bandwidth and not in terms of frequency. So similar to how we have
> > frequency based OPP tables in
Yes, sorry, just pushed out now.
Alex
On Thu, Aug 15, 2019 at 8:21 PM Stephen Rothwell wrote:
>
> Hi Alex,
>
> On Tue, 13 Aug 2019 10:01:07 -0400 Alex Deucher wrote:
> >
> > Applied. thanks!
>
> But not pushed out?
>
> --
> Cheers,
> Stephen Rothwell
On Wed, Aug 7, 2019 at 7:04 PM Frank Rowand wrote:
>
> > Date: Tue, 23 Jul 2019 17:10:54 -0700
> > Subject: [PATCH v7 1/7] driver core: Add support for linking devices during
> > device addition
> > From: Saravana Kannan
> >
> > When devices are added, the bus might want to create device links
On Wed, Aug 7, 2019 at 7:05 PM Frank Rowand wrote:
>
> > Date: Tue, 23 Jul 2019 17:10:55 -0700
> > Subject: [PATCH v7 2/7] driver core: Add edit_links() callback for drivers
> > From: Saravana Kannan
> >
> > The driver core/bus adding supplier-consumer dependencies by default
>
> > enables
On Wed, Aug 7, 2019 at 7:06 PM Frank Rowand wrote:
>
> On 7/23/19 5:10 PM, Saravana Kannan wrote:
> > Add device-links after the devices are created (but before they are
> > probed) by looking at common DT bindings like clocks and
> > interconnects.
> >
> > Automatically adding device-links for
On Fri, Aug 9, 2019 at 10:20 PM Frank Rowand wrote:
>
> On 8/9/19 10:00 PM, Saravana Kannan wrote:
> > On Fri, Aug 9, 2019 at 7:57 PM Frank Rowand wrote:
> >>
> >> Hi Saravana,
> >>
> >> On 7/31/19 3:17 PM, Saravana Kannan wrote:
> >>> Add device-links to track functional dependencies between
On Thu, 2019-08-15 at 09:36 +0200, christophe leroy wrote:
>
> Le 15/08/2019 à 06:10, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > When presented with large amounts of memory being hotplugged
> > (in my test case, ~890GB), the call to flush_dcache_range takes
> > a while (~50
Hi Adrian,
On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
[...]
> >> How come you cannot use kallsyms to get the information?
> >
> > Thanks for pointing out this. Sorry I skipped your comment "I don't
> > know how you intend to calculate ARM_PRE_START_SIZE" when you reviewed
On Thu, 2019-08-15 at 09:29 +0200, christophe leroy wrote:
>
> Le 15/08/2019 à 06:10, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > Similar to commit 22e9c88d486a
> > ("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
> > this patch converts flush_icache_range() to
Prior to this commit, removing the intel_pmc_core_pltdrv module
would cause the following warning:
[ cut here ]
Device 'intel_pmc_core.0' does not have a release() function, \
it is broken and must be fixed. See Documentation/kobject.txt.
WARNING: CPU: 0 PID:
Greg Kroah-Hartman writes:
> On Thu, Aug 15, 2019 at 02:55:42PM +1000, Alastair D'Silva wrote:
>> From: Alastair D'Silva
>>
>> Heads Up: This patch cannot be submitted to Linus's tree, as the affected
>> assembler functions have already been converted to C.
That was done in upstream commit:
On 8/15/19 12:51 AM, Will Deacon wrote:
Hi Bart,
On Sat, Aug 10, 2019 at 05:24:06PM -0700, syzbot wrote:
syzbot has found a reproducer for the following crash on:
HEAD commit:451577f3 Merge tag 'kbuild-fixes-v5.3-3' of git://git.kern..
git tree: upstream
console output:
On a Xen-based PVH virtual machine with more than 4 GiB of RAM,
intel_pmc_core fails initialization with the following warning message
from the kernel, indicating that the driver is attempting to ioremap
RAM:
[ cut here ]
ioremap on RAM at 0xfe00 -
On 8/15/19 4:36 PM, Florian Fainelli wrote:
> On 8/11/19 4:40 PM, Tao Ren wrote:
>> The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly
>> because genphy functions are designed for copper links, and 1000Base-X
>> (clause 37) auto negotiation needs to be handled differently.
>>
On 8/15/2019 9:23 PM, Jiri Olsa wrote:
On Tue, Aug 13, 2019 at 03:30:37PM +0800, Jin Yao wrote:
This patch prints the stddev and hist for the cycles diff of
program block. It can help us to understand if the cycles
is noisy or not.
This patch is inspired by Andi Kleen's patch
On Thu, Aug 15, 2019 at 12:04:30AM -0500, Bjorn Helgaas wrote:
> On Tue, Aug 13, 2019 at 03:19:58PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > On Mon, Aug 12, 2019 at 03:05:08PM -0500, Bjorn Helgaas wrote:
> > > On Thu, Aug 01, 2019 at 05:06:02PM -0700,
> > >
1 - 100 of 834 matches
Mail list logo
