On Sat, May 9, 2020 at 10:52 AM Joerg Roedel wrote:
>
> On Fri, May 08, 2020 at 04:49:17PM -0700, Andy Lutomirski wrote:
> > On Fri, May 8, 2020 at 2:36 PM Joerg Roedel wrote:
> > >
> > > On Fri, May 08, 2020 at 02:33:19PM -0700, Andy Lutomirski wrote:
> > > > On Fri, May 8, 2020 at 7:40 AM
Hi Nava,
On Mon, May 04, 2020 at 11:55:23AM +, Nava kishore Manne wrote:
> Hi Mortiz,
>
> Thanks for proving the comments.
> Please find my response inline.
>
> > -Original Message-
> > From: Moritz Fischer [mailto:m...@kernel.org]
> > Sent: Thursday, April 23, 2020 8:59 AM
> > To:
On 05/09, Chao Yu wrote:
> On 2020/5/9 0:10, Jaegeuk Kim wrote:
> > Hi Sayali,
> >
> > In order to address the perf regression, how about this?
> >
> >>From 48418af635884803ffb35972df7958a2e6649322 Mon Sep 17 00:00:00 2001
> > From: Jaegeuk Kim
> > Date: Fri, 8 May 2020 09:08:37 -0700
> >
On Sat, May 09, 2020 at 09:57:37AM -0400, Rafael Aquini wrote:
> Analogously to the introduction of panic_on_warn, this patch
> introduces a kernel option named panic_on_taint in order to
> provide a simple and generic way to stop execution and catch
> a coredump when the kernel gets tainted by
On Tue, May 05, 2020 at 04:00:11PM +0200, Arnd Bergmann wrote:
> Two symbols need to be exported to allow the zynqmp-fpga module
> to get loaded dynamically:
>
> ERROR: modpost: "zynqmp_pm_fpga_load" [drivers/fpga/zynqmp-fpga.ko] undefined!
> ERROR: modpost: "zynqmp_pm_fpga_get_status"
My Dear in the lord
My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina
Faso, I am married to Mr. Brunel Patrice, a politician who owns a small gold
company in Burkina Faso; He died of Leprosy and Radesyge, in the year February
2010, During his lifetime he
Le 09/05/2020 à 17:54, Christophe Leroy a écrit :
Le 28/04/2020 à 18:05, Arnd Bergmann a écrit :
On Tue, Apr 28, 2020 at 3:16 PM Christophe Leroy
wrote:
Provides __kernel_clock_gettime64() on vdso32. This is the
64 bits version of __kernel_clock_gettime() which is
y2038 compliant.
Hi Greg
Yea, thanks for the feedback.
Will fix and resend...
John
On Sat, 9 May 2020 at 18:11, Greg KH wrote:
>
> On Sat, May 09, 2020 at 02:07:14PM +0100, John Oldman wrote:
> > Coding style issue
>
> Your subject line needs to be much shorter, don't you think?
>
> Please fix up and resend.
On Sat, 9 May 2020 04:35:37 + Luis Chamberlain wrote:
> Device driver firmware can crash, and sometimes, this can leave your
> system in a state which makes the device or subsystem completely
> useless. Detecting this by inspecting /proc/sys/kernel/tainted instead
> of scraping some magical
> Oh, and... u-b...@linux.nxdi.nxp.com bounces because that domain is
> not resolvable - I guess that is internal to NXP, and this patch
> should have remained within NXP and not been posted publically.
Yeah, realized it just after sending my reply. It is for internal NXP list.
Had it been for
On Sat, May 09, 2020 at 07:18:45PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, May 09, 2020 at 11:34:59PM +0530, Amit Tomer wrote:
> > > From what I can tell, these patches are not for the kernel. The
> > > filenames don't match th kernel layout.
> >
> > These files looks to be from
On Sat, May 09, 2020 at 11:34:59PM +0530, Amit Tomer wrote:
> > From what I can tell, these patches are not for the kernel. The
> > filenames don't match th kernel layout.
>
> These files looks to be from U-boot, and must be intended for U-boot
> as I see U-boot mailing address in recipient's
On Sat, 9 May 2020 18:47:08 +0200 Christophe JAILLET wrote:
> Le 09/05/2020 à 03:54, Jakub Kicinski a écrit :
> > On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
> >> @@ -527,8 +531,9 @@ static int mac_sonic_platform_remove(struct
> >> platform_device *pdev)
> >>struct
> From what I can tell, these patches are not for the kernel. The
> filenames don't match th kernel layout.
These files looks to be from U-boot, and must be intended for U-boot
as I see U-boot mailing
address in recipient's address?
On Sat, 9 May 2020 10:13:22 +0200 Stephen Kitt wrote:
> Hi,
>
> Thanks for taking the time to review my patch.
>
> On Fri, 8 May 2020 20:50:25 -0700, Jakub Kicinski wrote:
> > On Fri, 8 May 2020 14:04:57 +0200 Stephen Kitt wrote:
> > > Commit c7228317441f ("net: Use a more standard macro for
On Sat, May 09, 2020 at 11:25:16AM +0200, Peter Zijlstra wrote:
> Right; it's just that the moment you do trigger it, it'll iterate that
> pgd_list and that is potentially huge. Then again, that's not a new
> problem.
>
> I suppose we can deal with it if/when it becomes an actual problem.
>
> I
Gorące pozdrowienia,
Wysłałem ci ten list miesiąc temu, ale nie jestem pewien, czy go
otrzymałeś, ponieważ nie otrzymałem od ciebie żadnej odpowiedzi, dlatego
ponownie go wysyłam.
Jestem adwokatem Chan Leap Phala, osobistym prawnikiem mojego zmarłego
klienta przed jego przedwczesną śmiercią
On Fri, May 08, 2020 at 04:49:17PM -0700, Andy Lutomirski wrote:
> On Fri, May 8, 2020 at 2:36 PM Joerg Roedel wrote:
> >
> > On Fri, May 08, 2020 at 02:33:19PM -0700, Andy Lutomirski wrote:
> > > On Fri, May 8, 2020 at 7:40 AM Joerg Roedel wrote:
> >
> > > What's the maximum on other system
S5PV210 can be trivially supported by this driver. Only one of
its FIMC devices (#2) supports the same scaling values as Exynos4, and
it is marked by mainscaler-ext in the DTS (as it is for all of the
Exynos4 devices). It's limits are the same as that of id's 0-2 of
Exynos4 so we don't even need
Greeting,
My Name is Regina Daniel am a Business Consultant and I represent a group of
company based in Gulf Region that wish to invest between US$10,000,000.00 TO
US$550,000,000. 00 in foreign investment depending on your investment capacity
based on the amount you can invest and manage. We
Hi,
On 5/9/20 2:20 AM, syzbot wrote:
Hello,
syzbot found the following crash on:
HEAD commit:d5eeab8d Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1509363210
kernel config:
* Masahiro Yamada :
> Hi Helge,
>
> On Sat, May 9, 2020 at 6:46 AM Helge Deller wrote:
> >
> > * Masahiro Yamada :
> > > On Sat, Apr 25, 2020 at 2:47 PM Masahiro Yamada
> > > wrote:
> > > >
> > > > 'make ARCH=parisc clean' emits a tons of error messages as follows:
> > > >
> > > > $ make
From: Andy Lutomirski
All that paranoid exit needs to do is to disable IRQs, handle IRQ tracing,
then restore CR3, and restore GS base. Simply do those actions in that
order. Cleaning up the spaghetti code.
Signed-off-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Signed-off-by: Sasha Levin
From: "Chang S. Bae"
Add CPU feature conditional FS/GS base access to the relevant helper
functions. That allows accelerating certain FS/GS base operations in
subsequent changes.
Note, that while possible, the user space entry/exit GS base operations are
not going to use the new FSGSBASE
From: Andy Lutomirski
Now that FSGSBASE is fully supported, remove unsafe_fsgsbase, enable
FSGSBASE by default, and add nofsgsbase to disable it.
While this changes userspace visible ABI, we could not find a project
that would be affected by this. Few projects were contacted for input
and ack:
Given copy_thread_tls() is now shared between 32 and 64 bit and we need
to use save_fsgs() there, move it to a header file.
Signed-off-by: Sasha Levin
---
arch/x86/kernel/process.h| 68
arch/x86/kernel/process_64.c | 68
From: "Chang S. Bae"
When FSGSBASE is enabled, copying threads and reading FS/GS base using
ptrace must read the actual values.
When copying a thread, use fsgs_save() and copy the saved values. For
ptrace, the bases must be read from memory regardless of the selector
if FSGSBASE is enabled.
From: Tony Luck
Before enabling FSGSBASE the kernel could safely assume that the content
of GS base was a user address. Thus any speculative access as the result
of a mispredicted branch controlling the execution of SWAPGS would be to
a user address. So systems with speculation-proof SMAP did
From: "Chang S. Bae"
When FSGSBASE is enabled, the GS base handling in paranoid entry will need
to retrieve the kernel GS base which requires that the kernel page table is
active.
As the CR3 switch to the kernel page tables (PTI is active) does not depend
on kernel GS base, move the CR3 switch
From: Andi Kleen
[ luto: Rename the variables from FS and GS to FSBASE and GSBASE and
make safe to include on 32-bit kernels. ]
Signed-off-by: Andi Kleen
Signed-off-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Signed-off-by: Thomas Gleixner
Signed-off-by: Sasha Levin
Reviewed-by:
From: "Chang S. Bae"
On FSGSBASE systems, the way to handle GS base in the paranoid path is
different from the existing SWAPGS-based entry/exit path handling. Document
the reason and what has to be done for FSGSBASE enabled systems.
Signed-off-by: Chang S. Bae
Signed-off-by: Sasha Levin
From: "Chang S. Bae"
Without FSGSBASE, user space cannot change GS base other than through a
PRCTL. The kernel enforces that the user space GS base value is positive
as negative values are used for detecting the kernel space GS base value
in the paranoid entry code.
If FSGSBASE is enabled, user
From: "Chang S. Bae"
This validates that GS selector and base are independently preserved in
ptrace commands.
Suggested-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Signed-off-by: Sasha Levin
Reviewed-by: Tony Luck
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Andy Lutomirski
Cc: H.
From: Andy Lutomirski
With the new FSGSBASE instructions, FS/GS base can be efficiently read
and written in __switch_to(). Use that capability to preserve the full
state.
This will enable user code to do whatever it wants with the new
instructions without any kernel-induced gotchas. (There can
From: Andi Kleen
The kernel needs to explicitly enable FSGSBASE. So, the application needs
to know if it can safely use these instructions. Just looking at the CPUID
bit is not enough because it may be running in a kernel that does not
enable the instructions.
One way for the application would
From: Thomas Gleixner
Explain how the GS/FS based addressing can be utilized in user space
applications along with the differences between the generic prctl() based
GS/FS base control and the FSGSBASE version available on newer CPUs.
Originally-by: Andi Kleen
Signed-off-by: Thomas Gleixner
From: "Chang S. Bae"
GS base is used to find per-CPU data in the kernel. But when GS base is
unknown, the per-CPU base can be found from the per_cpu_offset table with a
CPU NR. The CPU NR is extracted from the limit field of the CPUNODE entry
in GDT, or by the RDPID instruction. This is a
From: "Chang S. Bae"
The test validates that the selector is not changed when a ptracer writes
the ptracee's GS base.
Originally-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Signed-off-by: Sasha Levin
Reviewed-by: Tony Luck
Cc: Thomas Gleixner
Cc: Borislav Petkov
Cc: Andy Lutomirski
From: "Chang S. Bae"
When a ptracer writes a ptracee's FS/GS base with a different value, the
selector is also cleared. While this behavior is incorrect as the selector
should be preserved, most userspace applications did not notice that as
they do not use non-zero segments to begin with.
From: Andy Lutomirski
This is temporary. It will allow the next few patches to be tested
incrementally.
Setting unsafe_fsgsbase is a root hole. Don't do it.
Signed-off-by: Andy Lutomirski
Signed-off-by: Chang S. Bae
Signed-off-by: Sasha Levin
Reviewed-by: Tony Luck
Cc: Thomas Gleixner
Benefits:
Currently a user process that wishes to read or write the FS/GS base must
make a system call. But recent X86 processors have added new instructions
for use in 64-bit mode that allow direct access to the FS and GS segment
base addresses. The operating system controls whether applications
On Sat, May 09, 2020 at 05:33:15PM +0200, Andrew Lunn wrote:
> On Sat, May 09, 2020 at 06:39:55PM +0800, Hui Song wrote:
> > From: "hui.song"
> >
> > add one struct mpc8xxx_gpio_plat to enable gpio feature.
> >
> > Signed-off-by: hui.song
> > ---
> > .../include/asm/arch-fsl-layerscape/gpio.h
On 5/9/2020 12:38 AM, Geert Uytterhoeven wrote:
Hi Florian,
Thanks for your patch!
On Sat, May 9, 2020 at 12:32 AM Florian Fainelli wrote:
The GENET controller on the Raspberry Pi 4 (2711) is typically
interfaced with an external Broadcom PHY via a RGMII electrical
interface. To make sure
On Sat, May 09, 2020 at 02:07:14PM +0100, John Oldman wrote:
> Coding style issue
Your subject line needs to be much shorter, don't you think?
Please fix up and resend.
greg k-h
On Sat, May 09, 2020 at 11:02:13AM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Andrey Konovalov writes:
> >> here you're changing userspace ABI. Aren't we going to possibly break
> >> some existing applications?
> >
> > Hi Felipe,
> >
> > I've been working on tests for Raw Gadget for the last few
On Sat, May 09, 2020 at 11:07:27AM +0200, Matej Dujava wrote:
> This patch is removing CFLAGS that are defining flags that are not used.
You are also modifying the indentation and moving lines around for no
reason :(
Please only do one thing for a patch, and always describe everything you
do in
On Sat, May 09, 2020 at 03:37:16PM +0530, Harshal Chaudhari wrote:
> From: Harshal
>
> For simple module that contain a single platform_driver without any
> additional setup code then ends up being a block
> of duplicated boilerplate.
>
> This patch add a new micro, module_platform_driver(),
When CONFIG_VIRT_CPU_ACCOUNTING is selected, system call exception
handler doesn't fit below 0xd00 and build fails.
As exception 0xd00 doesn't exist and is never generated by 40x,
comment it out in order to get more space for system call exception.
Reported-by: kbuild test robot
Fixes:
> On May 9, 2020, at 12:12 PM, Paul E. McKenney wrote:
>
> Ah, and I forgot to ask. Why "if (data_race(prev->next == node)" instead
> of "if (data_race(prev->next) == node"?
I think the one you suggested is slightly better to point out the exact race.
Do you want me to resend or you could
Le 09/05/2020 à 03:54, Jakub Kicinski a écrit :
On Fri, 8 May 2020 19:25:57 +0200 Christophe JAILLET wrote:
@@ -527,8 +531,9 @@ static int mac_sonic_platform_remove(struct platform_device
*pdev)
struct sonic_local* lp = netdev_priv(dev);
unregister_netdev(dev);
-
On Sat, May 09, 2020 at 11:18:29AM -0400, Rafael Aquini wrote:
> We are still missing the documentation bits for this
> new flag, though.
Ah yeah sorry about that.
> How about having a blurb similar to:
>
> diff --git a/Documentation/admin-guide/tainted-kernels.rst
>
On Sat, May 09, 2020 at 09:32:51AM +0300, Igor Russkikh wrote:
>
> > This makes use of the new module_firmware_crashed() to help
> > annotate when firmware for device drivers crash. When firmware
> > crashes devices can sometimes become unresponsive, and recovery
> > sometimes requires a driver
On 09/05/2020 04:24, Wen Yang wrote:
在 2020/5/9 上午12:29, Bryan O'Donoghue 写道:
Right now we don't report to user-space a role switch when doing a
usb_role_switch_set_role() despite having registered the uevent
callbacks.
This patch switches on the notifications allowing user-space to see
On Tue, May 5, 2020 at 8:24 PM William Breathitt Gray
wrote:
>
> On Tue, May 05, 2020 at 04:51:56PM +0300, Andy Shevchenko wrote:
> > On Mon, May 4, 2020 at 5:41 PM William Breathitt Gray
> > wrote:
> > > On Mon, May 04, 2020 at 02:41:09PM +0300, Andy Shevchenko wrote:
> > > > On Sun, May 03,
On Fri, 2020-05-08 at 12:57 +0300, Andy Shevchenko wrote:
> On Fri, May 8, 2020 at 5:18 AM David E. Box <
> david.e@linux.intel.com> wrote:
> > PMT Telemetry is a capability of the Intel Platform Monitoring
> > Technology.
> > The Telemetry capability provides access to device telemetry
> >
Hi Steven,
On Thu, 7 May 2020 at 16:30, Steven Price wrote:
>
> On 02/05/2020 23:07, Clément Péron wrote:
> > Hi Steven,
> >
> > On Tue, 14 Apr 2020 at 15:10, Steven Price wrote:
> >>
> >> Hi Clément,
> >>
> >> On 13/04/2020 18:28, Clément Péron wrote:
> >>> Hi Steven,
> >>>
> >
>
> Since
On 5/9/20 10:07 AM, Pavel Begunkov wrote:
> On 04/05/2020 23:00, Pavel Begunkov wrote:
>> do_splice() doesn't expect len to be 0. Just always return 0 in this
>> case as splice(2) do.
>>
>
> If it was missed, may you take a look? I reattached the patch btw killing
> reported warnings.
Thanks for
On Sat, May 09, 2020 at 09:01:53AM -0400, Qian Cai wrote:
>
>
> > On May 9, 2020, at 12:33 AM, Paul E. McKenney wrote:
> >
> > On Fri, May 08, 2020 at 04:59:05PM -0400, Qian Cai wrote:
> >>
> >>
> >>> On Feb 11, 2020, at 8:54 AM, Qian Cai wrote:
> >>>
> >>> prev->next could be accessed
On 04/05/2020 23:00, Pavel Begunkov wrote:
> do_splice() doesn't expect len to be 0. Just always return 0 in this
> case as splice(2) do.
>
If it was missed, may you take a look? I reattached the patch btw killing
reported warnings.
---
From: Pavel Begunkov
Subject: [PATCH] io_uring: fix zero
On Sat, May 09, 2020 at 11:54:40AM +0300, Konstantin Khlebnikov wrote:
> On 08/05/2020 17.46, Paul E. McKenney wrote:
> > On Fri, May 08, 2020 at 12:00:28PM +0300, Konstantin Khlebnikov wrote:
> > > On 07/05/2020 22.09, Paul E. McKenney wrote:
> > > > On Thu, May 07, 2020 at 02:31:02PM -0400,
On 09/05/2020 17:42, Jens Axboe wrote:
> On 5/9/20 2:46 AM, Pavel Begunkov wrote:
>> When len=0, splice() and tee() return 0 even if specified fds are
>> invalid, hiding errors from users. Move len=0 optimisation later after
>> basic validity checks.
>>
>> before:
>> splice(len=0, fd_in=-1, ...)
Le 28/04/2020 à 18:05, Arnd Bergmann a écrit :
On Tue, Apr 28, 2020 at 3:16 PM Christophe Leroy
wrote:
Provides __kernel_clock_gettime64() on vdso32. This is the
64 bits version of __kernel_clock_gettime() which is
y2038 compliant.
Signed-off-by: Christophe Leroy
Looks good to me
FROM MR.SÉBASTIEN TONI
AUDIT& ACCOUNT MANAGER
BANK OF AFRICA (B.O.A)
OUAGADOUGOU BURKINA FASO
WEST AFRICA.
Dear Friend,
With due respect, I have decided to contact you on
abusinesstransaction that will be beneficial to both of us. At the
bank last account and auditing evaluation, my staffs
Le 08/05/2020 à 19:41, Qian Cai a écrit :
On May 8, 2020, at 10:39 AM, Qian Cai wrote:
Booting POWER9 PowerNV has this message,
"ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
early_ioremap() instead”
but use the patch below will result in leaks because it will
Arnd,
On Sat, May 09, 2020 at 02:06:32PM +0200, Arnd Bergmann wrote:
> gcc-10 started warning about out-of-bounds access for zero-length
> arrays:
>
> In file included from drivers/net/wireless/ath/ath10k/core.h:18,
> from drivers/net/wireless/ath/ath10k/htt_rx.c:8:
>
On Sat, May 9, 2020 at 8:20 AM Andy Shevchenko
wrote:
>
> On Fri, May 8, 2020 at 9:35 PM Nick Desaulniers
> wrote:
> >
> > This is easily reproducible via CC=clang+CONFIG_STAGING=y+CONFIG_VT6656=m.
> >
> > It turns out that if your config tickles __builtin_constant_p via
> > differences in
> On May 9, 2020, at 4:38 AM, Nicholas Piggin wrote:
>
> Your patch to use early_ioremap is faulting? I wonder why?
Yes, I don’t know the reasons either. I suppose not many places in other parts
of the kernel which keep using those addresses from early_ioremap() after
system booted.
On Sat, May 09, 2020 at 06:39:55PM +0800, Hui Song wrote:
> From: "hui.song"
>
> add one struct mpc8xxx_gpio_plat to enable gpio feature.
>
> Signed-off-by: hui.song
> ---
> .../include/asm/arch-fsl-layerscape/gpio.h| 22 +++
> 1 file changed, 22 insertions(+)
> create
On Sat, May 9, 2020 at 4:49 PM Russell King - ARM Linux admin
wrote:
>
> On Sat, May 09, 2020 at 02:51:05PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Sat, May 09, 2020 at 03:14:05PM +0200, Matteo Croce wrote:
> > > On Sat, May 9, 2020 at 1:45 PM Russell King - ARM Linux admin
> > >
On Sat, May 09, 2020 at 06:39:54PM +0800, Hui Song wrote:
> From: "hui.song"
>
> Make the MPC8XXX gpio driver to support the fsl-layerscape.
>
> Signed-off-by: hui.song
> ---
> drivers/gpio/mpc8xxx_gpio.c | 59 +
> 1 file changed, 59 insertions(+)
>
> diff
On Sat, May 09, 2020 at 04:54:57PM +0800, joe_zhu...@126.com wrote:
> From: Joe Zhu
>
> If mailbox uses IRQ method, it already notified framework with
> mbox_chan_txdone() in ISR.
>
> Signed-off-by: Joe Zhu
> ---
> drivers/firmware/arm_scmi/mailbox.c | 4 +++-
> 1 file changed, 3
On Sat, May 09, 2020 at 04:35:38AM +, Luis Chamberlain wrote:
> Device driver firmware can crash, and sometimes, this can leave your
> system in a state which makes the device or subsystem completely
> useless. Detecting this by inspecting /proc/sys/kernel/tainted instead
> of scraping some
On Fri, 2020-05-08 at 18:17 +0100, Mark Brown wrote:
> On Fri, May 08, 2020 at 06:40:43PM +0300, Matti Vaittinen wrote:
> > Add a KUnit test for the linear_ranges helper.
> >
> > Signed-off-by: Matti Vaittinen
> > Reviewed-by: Brendan Higgins
>
> This now generates:
>
> WARNING: modpost:
When linear_ranges is compiled as module we get warning
about missing MODULE_LICENSE(). Fix it by adding
MODULE_LICENSE("GPL") as is suggested by SPDX and EXPORTs.
Signed-off-by: Matti Vaittinen
---
I saw Mark applied the linear-ranges patch. So I sent this fix as
incremental patch - but I
On Sat, May 9, 2020 at 1:24 AM Christoph Hellwig wrote:
>
> On Fri, May 08, 2020 at 11:04:45AM -0700, Dan Williams wrote:
> > On Fri, May 8, 2020 at 9:16 AM Christoph Hellwig wrote:
> > >
> > > Hi all,
> > >
> > > various bio based drivers use queue->queuedata despite already having
> > > set up
在 2020/5/9 14:36, Randy Dunlap 写道:
On 5/8/20 11:30 PM, Jason Yan wrote:
Fix the following build warning:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/panel/panel-visionox-rm69299.o
see include/linux/module.h for more information
Signed-off-by: Jason Yan
---
On Sat, May 09, 2020 at 03:48:54AM +, Luis Chamberlain wrote:
> On Fri, May 08, 2020 at 08:47:19AM -0400, Rafael Aquini wrote:
> > On Thu, May 07, 2020 at 10:25:58PM +, Luis Chamberlain wrote:
> > > On Thu, May 07, 2020 at 06:06:06PM -0400, Rafael Aquini wrote:
> > > > On Thu, May 07, 2020
On Sat, May 09, 2020 at 02:51:05PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, May 09, 2020 at 03:14:05PM +0200, Matteo Croce wrote:
> > On Sat, May 9, 2020 at 1:45 PM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Sat, May 09, 2020 at 11:15:58AM +, Stefan Chulski wrote:
On Sat, May 9, 2020 at 10:06 PM Shakeel Butt wrote:
>
> On Fri, May 8, 2020 at 2:44 PM Johannes Weiner wrote:
> >
> > On Fri, May 08, 2020 at 10:06:30AM -0700, Shakeel Butt wrote:
> > > One way to measure the efficiency of memory reclaim is to look at the
> > > ratio (pgscan+pfrefill)/pgsteal.
On 5/9/20 2:46 AM, Pavel Begunkov wrote:
> When len=0, splice() and tee() return 0 even if specified fds are
> invalid, hiding errors from users. Move len=0 optimisation later after
> basic validity checks.
>
> before:
> splice(len=0, fd_in=-1, ...) == 0;
>
> after:
> splice(len=0, fd_in=-1,
On Tue, 2020-04-14 at 16:21 +0200, Peter Zijlstra wrote:
> On Wed, Mar 04, 2020 at 04:59:50PM +, vpillai wrote:
> >
> > - Investigate the source of the overhead even when no tasks are
> > tagged:
> > https://lkml.org/lkml/2019/10/29/242
>
> - explain why we're all still doing this
>
* Pavel Machek [200508 10:03]:
> I pushed new version of ofono: I'm still not sure about those incoming
> sms (but _some_ sms are received). Rest should be better.
Please check that you have applied commit 738b150ecefb ("ARM: dts:
omap4-droid4: Fix occasional lost wakeirq for uart1"), otherwise
Kees Cook writes:
> $ git grep exec_mm_release
> fs/exec.c: exec_mm_release(tsk, old_mm);
> include/linux/sched/mm.h:extern void exec_mm_release(struct task_struct *,
> struct mm_struct *);
> kernel/fork.c:void exec_mm_release(struct task_struct *tsk, struct mm_struct
> *mm)
>
>
From: Johannes Weiner
Currently, THP are counted as single pages until they are split right
before being swapped out. However, at that point the VM is already in
the middle of reclaim, and adjusting the LRU balance then is useless.
Always account THP by the number of basepages, and remove the
Currently rxhash only works on the first port of the CP (Communication
Processor). Enabling it on other ports completely blocks packet reception.
This patch only adds rxhash as supported feature to the first port,
so rxhash can't be enabled on other ports:
# ethtool -K eth0 rxhash on
From: Bartosz Golaszewski
Currently we emit the REQUESTED line state event after the line is
requested but before the flags are configured. This is obviously wrong
as we want to pass the updated lineinfo to user-space together with the
event.
Since the flags can be configured in different ways
I think the problem is the select of CONFIG_DEVICE_PRIVATE. Jason is
looking into it already.
On 09/05/2020 18:19, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 02:18:37PM +1000, Alexey Kardashevskiy wrote:
>>
>>
>> On 17/04/2020 17:58, Christoph Hellwig wrote:
>>> On Wed, Apr 15, 2020 at 09:21:37PM +1000, Alexey Kardashevskiy wrote:
And the fact they were exported leaves
On Fri, May 8, 2020 at 2:44 PM Johannes Weiner wrote:
>
> On Fri, May 08, 2020 at 10:06:30AM -0700, Shakeel Butt wrote:
> > One way to measure the efficiency of memory reclaim is to look at the
> > ratio (pgscan+pfrefill)/pgsteal. However at the moment these stats are
> > not updated consistently
On Fri, May 8, 2020 at 2:51 PM Johannes Weiner wrote:
>
> On Fri, May 08, 2020 at 02:22:15PM -0700, Shakeel Butt wrote:
> > Currently update_page_reclaim_stat() updates the lruvec.reclaim_stats
> > just once for a page irrespective if a page is huge or not. Fix that by
> > passing the
* H. Nikolaus Schaller [200509 11:48]:
> I have found another small bug and a dev_dbg format weakness
> and now it seems to work well even if I remove or reinsert the
> battery while read operations are ongoing.
OK great.
> Still I need more time to fix up the patch(es).
Well it's ready when
Analogously to the introduction of panic_on_warn, this patch
introduces a kernel option named panic_on_taint in order to
provide a simple and generic way to stop execution and catch
a coredump when the kernel gets tainted by any given taint flag.
This is useful for debugging sessions as it avoids
* Pavel Machek [200508 10:03]:
> Hi!
>
> > > But I might be confused. I recall some audio patches were needed for
> > > basic phone calls (setting up mixers to connect gsm<->audio), but
> > > those worked before gsmux support was enabled. (Maybe some hardcoded
> > > commands were needed to be
On Sat, May 09, 2020 at 03:14:05PM +0200, Matteo Croce wrote:
> On Sat, May 9, 2020 at 1:45 PM Russell King - ARM Linux admin
> wrote:
> >
> > On Sat, May 09, 2020 at 11:15:58AM +, Stefan Chulski wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Matteo Croce
> > > > Sent:
This patch set is to fix several issues of single-step debugging
in kgdb/kdb on arm64.
It seems that these issues have been shelved a very long time,
but i still hope to solve them, as the single-step debugging
is an useful feature.
Note:
Based on patch "arm64: cacheflush: Fix KGDB trap
PSTATE.I and PSTATE.D are very important for single-step working.
Without disabling interrupt on local CPU, there is a chance of
interrupt occurrence in the period of exception return and start of
out-of-line single-step, that result in wrongly single stepping
into the interrupt handler. And if D
After the single-step exception handling oops is fixed, when we execute
single-step in kdb/kgdb, we may see it jumps to the irq_handler (where
PSTATE.D is cleared) instead of the next instruction.
Add the prepare and cleanup work for single-step when enabling and
disabling to maintain the
After fixing wrongly single-stepping into the irq handler, when we execute
single-step in kdb/kgdb, we can see only the first step can work.
Refer to the ARM Architecture Reference Manual (ARM DDI 0487E.a) D2.12,
i think PSTATE.SS=1 should be set each step for transferring the PE to the
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It's because the reason gotten in kdb_stub() is not as expected, and it
seems that the ex_vector for
Hi Richard,
Thank you for the patch.
On Sat, May 09, 2020 at 01:17:32PM +0200, s...@48.io wrote:
> From: Marek Vasut
>
> Add driver for the ITE IT6251 LVDS-to-eDP bridge.
>
> Signed-off-by: Marek Vasut
> Signed-off-by: Richard Marko
> Cc: Daniel Vetter
> Cc: Sean Cross
> To:
201 - 300 of 548 matches
Mail list logo
