On 2019/2/28 16:04, Greg KH wrote:
> On Wed, Feb 27, 2019 at 11:33:22AM +0800, Mao Wenan wrote:
>> repeat_times is a static variable, but each time when it enters
>> r8712_efuse_pg_packet_write(), it is set to zero,
>> this value is not consistent with last calling, so next behavior
>> is not
The current randomization granularity of 5-level is 512 GB. Improve
it to 1 GB. This can add more randomness to memory region KASLR in
5-level paging mode
Signed-off-by: Baoquan He
---
v2->v3:
The v2 was based on another patchset. Rebase it on the latest linus's
tree.
arch/x86/mm/kaslr.c |
On Thu, Feb 28, 2019 at 10:46:20AM +0200, Oded Gabbay wrote:
> Signed-off-by: Oded Gabbay
I can't take patches without any changelog text :(
On Thu, Feb 28, 2019 at 8:59 AM Eric Biggers wrote:
>
> On Thu, Feb 28, 2019 at 07:53:09AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
> wrote:
> > On Wed, Feb 27, 2019 at 9:53 PM Eric Biggers wrote:
> > >
> > > On Tue, Feb 26, 2019 at 10:21:30AM -0800, Eric Biggers wrote:
> > > > On Wed, Feb 13,
This code has been commented out since commit b7000adef17a
("Don't set the INITRD_COMPRESS environment variable automatically").
Clean it up now.
Signed-off-by: Masahiro Yamada
---
Makefile | 13 -
1 file changed, 13 deletions(-)
diff --git a/Makefile b/Makefile
index
On Wed, Feb 27, 2019 at 10:58 PM Theodore Y. Ts'o wrote:
>
> On Wed, Feb 27, 2019 at 10:58:50AM +0100, Dmitry Vyukov wrote:
> > Peter, Ingo, do you have any updates on the
> > perf_event_open/sched_setattr stalls? This bug cause assorted hangs
> > throughout kernel and so is nasty.
> >
> >
On Wed, Feb 27, 2019 at 07:58:14PM +0100, Gerhard Wiesinger wrote:
> On 27.02.2019 10:20, Maxime Ripard wrote:
> > On Sun, Feb 24, 2019 at 09:04:57AM +0100, Gerhard Wiesinger wrote:
> > > Hello,
> > >
> > > I've 3 Banana Pi R1, one running with self compiled kernel
> > >
On Wed, Feb 27, 2019 at 06:47:32PM +0100, Marcin Wojtas wrote:
> Current version of the driver was configuring XLG MAC
> in a way to wait 3 IDLE frames before allowing for the
> link-up interrupt to be triggered. This resulted in an
> issue, preventing to detect the link change during RX
> traffic
A gentle ping on this whole patch series.
Regards,
Lars
On Fri, Jan 11, 2019 at 05:18:04PM +0100, Lars Poeschel wrote:
> It is favourable to have one unified compatible string for devices that
> have multiple interfaces. So this adds simply "pn532" as the devicetree
> binding compatible string
On Thu 28-02-19 14:05:22, Aneesh Kumar K.V wrote:
> Add a flag to indicate the ability to do huge page dax mapping. On
> architecture
> like ppc64, the hypervisor can disable huge page support in the guest. In
> such a case, we should not enable huge page dax mapping. This patch adds
> a flag
On Wed, Feb 27, 2019 at 06:28:16PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 27, 2019 at 04:40:28PM +0100, Dmitry Vyukov wrote:
> > On Wed, Feb 27, 2019 at 3:33 PM Peter Zijlstra wrote:
>
> > > Urgh, kasan_report() is definitely unsafe. Now, admitedly we should
> > > 'never' hit that, but it
On Thu, Feb 28, 2019 at 7:35 PM Aneesh Kumar K.V
wrote:
>
> Add a flag to indicate the ability to do huge page dax mapping. On
> architecture
> like ppc64, the hypervisor can disable huge page support in the guest. In
> such a case, we should not enable huge page dax mapping. This patch adds
> a
On Thu, Feb 28, 2019 at 10:21:54AM +0100, Michal Hocko wrote:
> On Thu 21-02-19 10:42:12, Oscar Salvador wrote:
> [...]
> > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > index d5f7afda67db..04f6695b648c 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1337,8
The coverity tool has detected this issue as an unused value, since
the code assigns the value to utime variable and then after the jump, the
value of utime again gets updated, hence the previous value is not at all
useful and this patch removes that first assignment.
On 27/02/19 4:02 PM,
On 27.02.2019 19:00, Tony Krowiak wrote:
> On 2/27/19 3:09 AM, Pierre Morel wrote:
>> On 26/02/2019 16:47, Tony Krowiak wrote:
>>> On 2/26/19 6:47 AM, Pierre Morel wrote:
On 25/02/2019 19:36, Tony Krowiak wrote:
> On 2/22/19 10:29 AM, Pierre Morel wrote:
>> We prepare the
Üdvözlöm!
2019-től a legtöbb kiegészítő juttatás jövedelemként fog adózni (kivételt képez
a SZÉP kártya).
Juttatási kártyáinknak köszönhetően könnyebben nyerhet meg új tehetségeket,
könnyebben tarthatja meg dolgozóit, és növelheti motivációjukat.
Kártyáink tetszőleges célokra használhatók
> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 28 February 2019 02:03
> To: xen-de...@lists.xenproject.org; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Cc: Wei Liu ; Paul Durrant ;
> da...@davemloft.net; Igor
> Druzhinin
> Subject:
Hello Thiago,
On Fri, Feb 22, 2019 at 07:57:52PM -0300, Thiago Jung Bauermann wrote:
> When testing DLPAR CPU add/remove on a system under stress,
> pseries_cpu_die() doesn't wait long enough for a CPU to die:
>
> [ 446.983944] cpu 148 (hwid 148) Ready to die...
> [ 446.984062] cpu 149 (hwid
On Thu, Feb 28, 2019 at 11:31 AM Greg KH wrote:
>
> On Thu, Feb 28, 2019 at 10:46:20AM +0200, Oded Gabbay wrote:
> > Signed-off-by: Oded Gabbay
>
> I can't take patches without any changelog text :(
>
ah, didn't know it was required for even this trivial change.
I'll resend this and another
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
On Thu, Feb 28, 2019 at 03:12:13PM +0530, Ketan Patil wrote:
> The coverity tool has detected this issue as an unused
On 28/02/2019 02:03, Igor Druzhinin wrote:
> Zero-copy callback flag is not yet set on frag list skb at the moment
> xenvif_handle_frag_list() returns -ENOMEM. This eventually results in
> leaking grant ref mappings since xenvif_zerocopy_callback() is never
> called for these fragments. Those
Hi Shilpa,
On Thu, Feb 28, 2019 at 11:25:25AM +0530, Shilpasri G Bhat wrote:
> Hi,
>
> On 02/28/2019 10:14 AM, Daniel Axtens wrote:
> > Shilpasri G Bhat writes:
> >
> >> In POWER9, OCC(On-Chip-Controller) provides for hard and soft system
> >> powercapping range. The hard powercap range is
[Sorry for a late reply]
On Fri 01-02-19 11:12:33, Johannes Weiner wrote:
> On Fri, Feb 01, 2019 at 08:17:57AM +0100, Michal Hocko wrote:
> > On Thu 31-01-19 20:13:52, Chris Down wrote:
> > [...]
> > > The current situation goes against both the expectations of users of
> > > memory.high, and our
On Thu, Feb 28, 2019 at 05:23:46PM +0800, Baoquan He wrote:
> On 02/28/19 at 12:10pm, Kirill A. Shutemov wrote:
> > On Thu, Feb 28, 2019 at 08:35:20AM +0800, Baoquan He wrote:
> > > arch/x86/mm/kaslr.c | 92 -
> > > 1 file changed, 40 insertions(+), 52
On Thu 28-02-19 10:41:08, Oscar Salvador wrote:
> On Thu, Feb 28, 2019 at 10:21:54AM +0100, Michal Hocko wrote:
> > On Thu 21-02-19 10:42:12, Oscar Salvador wrote:
> > [...]
> > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > > index d5f7afda67db..04f6695b648c 100644
> > > ---
Add comment about minimum and maximum size of command buffer.
Add some text about the expected input of CS IOCTL.
Signed-off-by: Oded Gabbay
---
Changes in v2:
- Add changelog in the commit message
include/uapi/misc/habanalabs.h | 10 +-
1 file changed, 9 insertions(+), 1
Don't cast pointer to u64 to print it. Instead, print the pointer using
%p.
Signed-off-by: Oded Gabbay
---
Changes in v2:
- Add changelog in the commit message
drivers/misc/habanalabs/goya/goya.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Hi Elie,
On 2/26/2019 10:20 PM, Wolfram Sang wrote:
> Hi Elie,
>
>> My apologies for the time it took to apply those changes.
>
> No worries. I am super happy that you are still around and willing to
> continue the work!
>
>> I will also start working on an alternate (v17?) version with only
On Thu, Feb 28, 2019 at 10:40 AM Peter Zijlstra wrote:
>
> On Wed, Feb 27, 2019 at 06:28:16PM +0100, Peter Zijlstra wrote:
> > On Wed, Feb 27, 2019 at 04:40:28PM +0100, Dmitry Vyukov wrote:
> > > On Wed, Feb 27, 2019 at 3:33 PM Peter Zijlstra
> > > wrote:
> >
> > > > Urgh, kasan_report() is
Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> On 2019-02-12 17:28:57 [+0100], To linux-kernel@vger.kernel.org wrote:
> > The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> > timer callback requires this flag at all. Its sole purpose is to ensure
> >
On Wed, Feb 27, 2019 at 04:36:06PM -0800, Hyun Kwon wrote:
> Hi Daniel,
>
> On Wed, 2019-02-27 at 06:13:45 -0800, Daniel Vetter wrote:
> > On Tue, Feb 26, 2019 at 11:20 PM Hyun Kwon wrote:
> > >
> > > Hi Daniel,
> > >
> > > Thanks for the comment.
> > >
> > > On Tue, 2019-02-26 at 04:06:13
On Wed, Feb 27, 2019 at 05:51:46PM -0600, Bjorn Helgaas wrote:
> On Wed, Feb 27, 2019 at 3:01 PM Stephen Rothwell
> wrote:
> >
> > Hi Bjorn,
> >
> > Commit
> >
> > a048671aa0c8 ("PCI: qcom: Don't deassert reset GPIO during probe")
> >
> > is missing a Signed-off-by from its committer.
>
>
On 02/28/19 at 12:55pm, Kirill A. Shutemov wrote:
> I cannot apply the first patch too. Hm?
It's weird. I use 'git cherry-pick' and it can be cleanly applied.
And git formatted patch can be applied too. Could you try below one?
git am works for me with it, based on this commit on linus's tree.
On Wed, Feb 27, 2019 at 08:58:36AM -0500, Michael S. Tsirkin wrote:
> Even though it's not going into 5.1 I feel it's helpful to keep it in
> the vhost tree until the next cycle, it helps make sure unrelated
> changes don't break it.
It is not going to 5.1, so it shouldn't be in linux-next, no?
On Thu, Feb 28, 2019 at 10:59 AM Dmitry Vyukov wrote:
>
> On Thu, Feb 28, 2019 at 10:40 AM Peter Zijlstra wrote:
> >
> > On Wed, Feb 27, 2019 at 06:28:16PM +0100, Peter Zijlstra wrote:
> > > On Wed, Feb 27, 2019 at 04:40:28PM +0100, Dmitry Vyukov wrote:
> > > > On Wed, Feb 27, 2019 at 3:33 PM
Hi Stuart,
On 2019-02-12 22:40, Stuart Menefy wrote:
> The Exynos 5260, like the 5433, appears to require baud clock as
> well as pclk to be running before accessing any of the registers,
> otherwise an external abort is raised.
>
> The serial driver already enables baud clock when required, but
On Thu, 28 Feb 2019, Chris Wilson wrote:
> Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> > On 2019-02-12 17:28:57 [+0100], To linux-kernel@vger.kernel.org wrote:
> > > The timer is initialized with TIMER_IRQSAFE flag. It does look like the
> > > timer callback requires this flag at
On Thu, Feb 28, 2019 at 02:35:06AM +, Maya Nakamura wrote:
> Remove a duplicate definition of VP set (hv_vp_set) and use the common
> definition (hv_vpset) that is used in other places.
>
> Change the order of the members in struct hv_pcibus_device so that the
> declaration of
On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
> vkms_crc_work_handle needs the value of the actual frame to
> schedule the workqueue that calls periodically the vblank
> handler and the destroy state functions. However, the frame
> value returned from vkms_vblank_simulate is
On 2019/02/28 15:42, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7b827ff9af88 Add linux-next specific files for 20190227
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f71894c0
> kernel config:
On Thu, Feb 28, 2019 at 09:56:16AM +, Shah, Nehal-bakulchandra wrote:
> Hi Elie,
>
> On 2/26/2019 10:20 PM, Wolfram Sang wrote:
> > Hi Elie,
> >
> >> My apologies for the time it took to apply those changes.
> >
> > No worries. I am super happy that you are still around and willing to
> >
On 27. 02. 19 18:26, p...@cmp.felk.cvut.cz wrote:
From: Pavel Pisa
Ahoj Pavle,
I can not comment on the content of the binding but it is a good
practice to add at least a short description to each commit even
if it should be the subject said differently.
Anyway, hats off to all of you,
On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote:
> On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote:
> > vkms_crc_work_handle needs the value of the actual frame to
> > schedule the workqueue that calls periodically the vblank
> > handler and the destroy state
On Wed, Feb 27, 2019 at 10:54:02PM +0800, lantianyu1...@gmail.com wrote:
> Lan Tianyu (3):
> x86/Hyper-V: Set x2apic destination mode to physical when x2apic is
> available
> HYPERV/IOMMU: Add Hyper-V stub IOMMU driver
> MAINTAINERS: Add Hyper-V IOMMU driver into Hyper-V CORE AND
On 2/26/19 4:33 AM, Alexandre Courbot wrote:
> Hi, sorry for the delayed reply!
>
> On Wed, Feb 13, 2019 at 8:04 PM Paul Kocialkowski
> wrote:
>>
>> Hi,
>>
>> On Wed, 2019-02-13 at 10:57 +0100, Hans Verkuil wrote:
>>> On 2/13/19 10:20 AM, Paul Kocialkowski wrote:
Hi,
On Wed,
On Thu, Feb 28, 2019 at 11:11 AM Tetsuo Handa
wrote:
>
> On 2019/02/28 15:42, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:7b827ff9af88 Add linux-next specific files for 20190227
> > git tree: linux-next
> > console output:
Quoting Thomas Gleixner (2019-02-28 10:09:26)
> On Thu, 28 Feb 2019, Chris Wilson wrote:
>
> > Quoting Sebastian Andrzej Siewior (2019-02-26 16:00:38)
> > > On 2019-02-12 17:28:57 [+0100], To linux-kernel@vger.kernel.org wrote:
> > > > The timer is initialized with TIMER_IRQSAFE flag. It does
On Thu, Feb 28, 2019 at 10:55:35AM +0100, Michal Hocko wrote:
> You seemed to miss my point or I am wrong here. If scan_movable_pages
> skips over a hugetlb page then there is nothing to migrate it and it
> will stay in the pfn range and the range will not become idle.
I might be misunterstanding
On 2019/02/28 15:51, Dmitry Vyukov wrote:
> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
>>
>> Thank you. The LSM stacking seems to be working as expected.
>> But this one should not be considered as a bug.
>>
>> If something went wrong before loading access control rules,
>> it is pointless to
Add a read only nvmem driver for STM32 factory-programmed memory area
(on-chip non-volatile storage).
Signed-off-by: Fabrice Gasnier
---
Changes in v2:
- update "st,stm32f4-otp" compatible as discussed with Rob
---
drivers/nvmem/Kconfig | 10 ++
drivers/nvmem/Makefile | 2 ++
On STM32MP15, OTP area may be read/written by using BSEC (boot, security
and OTP control). BSEC registers set is composed of various regions, among
which control registers and OTP shadow registers.
Secure monitor calls are involved in this process to allow (or deny)
access to the full range of OTP
Add documentation for STMicroelectronics STM32 Factory-programmed
read only memory area.
Signed-off-by: Fabrice Gasnier
---
Changes in v2:
- update "st,stm32f4-otp" compatible as discussed with Rob
---
.../devicetree/bindings/nvmem/st,stm32-romem.txt | 31 ++
1 file
Add & enable stm32 factory-programmed memory. Describe temperature sensor
calibration cells. Non-volatile calibration data is made available by
stm32mp157c bootrom in bsec_dataX registers.
Signed-off-by: Fabrice Gasnier
---
arch/arm/boot/dts/stm32mp157c.dtsi | 13 +
1 file changed,
Add & enable stm32 factory-programmed memory. Describe temperature sensor
calibration cells.
Signed-off-by: Fabrice Gasnier
---
arch/arm/boot/dts/stm32f429.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
Add nvmem_cell_read_u16() helper to ease read of an u16 value on consumer
side. This is inspired by nvmem_cell_read_u32() function.
This helper is useful on stm32 that has 16 bits data cells stored in non
volatile memory.
Signed-off-by: Fabrice Gasnier
---
drivers/nvmem/core.c | 37
Commit-ID: fe99a4f4d6022ec92f9b52a5528cb9b77513e7d1
Gitweb: https://git.kernel.org/tip/fe99a4f4d6022ec92f9b52a5528cb9b77513e7d1
Author: Julia Cartwright
AuthorDate: Tue, 12 Feb 2019 17:25:53 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 28 Feb 2019 11:18:38 +0100
kthread: Convert
Non volatile memory area is available on STM32. It contains various
factory programmed information such as unique device ID, analog calibration...
This patchset adds:
- NVMEM support to access stm32 data cells
- helper to read 16 bits cells.
---
Changes in v2:
- update "st,stm32f4-otp" compatible
Commit-ID: ad01423aedaa7c6dd62d560b73a3cb39e6da3901
Gitweb: https://git.kernel.org/tip/ad01423aedaa7c6dd62d560b73a3cb39e6da3901
Author: Sebastian Andrzej Siewior
AuthorDate: Tue, 12 Feb 2019 17:25:54 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 28 Feb 2019 11:18:38 +0100
kthread:
On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
wrote:
>
> On 2019/02/28 15:51, Dmitry Vyukov wrote:
> > On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
> >>
> >> Thank you. The LSM stacking seems to be working as expected.
> >> But this one should not be considered as a bug.
> >>
> >> If something
This is what I have in mind for a fsl,qe-snums property. The second
patch in the series has the side effect of making it very easy to
introduce that, since the of_property_read_variable_u8_array helper
does exactly what we need in terms of verifying the array length and
copying out the values to
The local variable snum_init has no reason to have static storage duration.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 2ef6fc6487c1..4b6aa6b3b685 100644
On Thu, Feb 28, 2019 at 06:04:19PM +0800, Baoquan He wrote:
> On 02/28/19 at 12:55pm, Kirill A. Shutemov wrote:
> > I cannot apply the first patch too. Hm?
>
> It's weird. I use 'git cherry-pick' and it can be cleanly applied.
>
> And git formatted patch can be applied too. Could you try below
The 'try of_find_compatible_node(NULL, NULL, "fsl,qe"), fall back to
of_find_node_by_type(NULL, "qe")' pattern is repeated five
times. Factor it into a common helper.
Signed-off-by: Rasmus Villemoes
---
drivers/soc/fsl/qe/qe.c | 71 +
1 file changed, 29
The current array of struct qe_snum use 256*4 bytes for just keeping
track of the free/used state of each index, and the struct layout
means there's another 768 bytes of padding. If we just unzip that
structure, the array of snum values just use 256 bytes, while the
free/inuse state can be tracked
Hello,
syzbot found the following crash on:
HEAD commit:42fd8df9d1d9 Add linux-next specific files for 20190228
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=179ba9e0c0
kernel config: https://syzkaller.appspot.com/x/.config?x=c0f38652d28b522f
The current code assumes that the set of snum _values_ to populate the
snums[] array with is a function of the _number_ of snums
alone. However, reading table 4-30, and its footnotes, of the QUICC
Engine Block Reference Manual shows that that is a bit too naive.
As an alternative, this introduces
On Thu, Feb 28, 2019 at 05:01:25PM +0800, Herbert Xu wrote:
> On Thu, Feb 28, 2019 at 11:28:01AM +0300, Vitaly Chikunov wrote:
> > On Thu, Feb 28, 2019 at 03:51:41PM +0800, Herbert Xu wrote:
> > > On Thu, Feb 28, 2019 at 10:04:49AM +0300, Vitaly Chikunov wrote:
> > > >
> > > > It seems that you
On Thu, 28 Feb 2019, Arnd Bergmann wrote:
> On Thu, Feb 28, 2019 at 5:25 AM Deepa Dinamani wrote:
> >
> > On Tue, Feb 26, 2019 at 11:52 PM Xiongfeng Wang
> > wrote:
> > >
> > > +++ b/kernel/time/posix-timers.c
> > > @@ -853,8 +853,8 @@ static int do_timer_settime(timer_t timer_id, int
> > >
On Thu, Feb 28, 2019 at 11:32 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:42fd8df9d1d9 Add linux-next specific files for 20190228
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=179ba9
On Thu, Feb 28, 2019 at 01:33:37PM +0300, Vitaly Chikunov wrote:
>
> To make the same for set_{pub,priv}_key it will require patching RSA
> drivers anyway, since length of the key is stored just once as keylen
> argument.
No we don't need to use the same format for different algorithms.
RSA
On Thu, Feb 28, 2019 at 10:04:12AM +0100, Stanislaw Gruszka wrote:
> On Tue, Feb 26, 2019 at 12:24:08PM +0100, Stanislaw Gruszka wrote:
> > On Tue, Feb 26, 2019 at 11:44:13AM +0100, Joerg Roedel wrote:
> > > On Tue, Feb 26, 2019 at 11:34:51AM +0100, Stanislaw Gruszka wrote:
> > > > On Tue, Feb 26,
Add support for suspend/resume and runtime PM to stm32-vrefbuf driver.
Signed-off-by: Fabrice Gasnier
---
drivers/regulator/stm32-vrefbuf.c | 121 +++---
1 file changed, 114 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/stm32-vrefbuf.c
On Thu, 28 Feb 2019, Chris Wilson wrote:
> Quoting Thomas Gleixner (2019-02-28 10:09:26)
> > On Thu, 28 Feb 2019, Chris Wilson wrote:
> > > It may not be the best of api, but it's the only one available for the
> > > driver to use...
> >
> > The comment in the header files says clearly:
> >
> >
On Thu, Feb 28, 2019 at 11:05:10AM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 10:59 AM Dmitry Vyukov wrote:
> > I guess this warning originated for user-space where programmer does
> > not define them and does not generally know about them and signature
> > is not a public contract
Support for "%pCr" was removed, but a reference in a comment was
forgotten.
Fixes: 666902e42fd8344b ("lib/vsprintf: Remove atomic-unsafe support for %pCr")
Signed-off-by: Geert Uytterhoeven
---
lib/vsprintf.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
Maya Nakamura writes:
> This patchset removes a duplicate definition of VP set (hv_vp_set) and
> uses the common definition (hv_vpset) that is used in other places. It
> changes the order of the members in struct hv_pcibus_device due to
> flexible array in hv_vpset.
>
> It also removes the
On Thu, Feb 28, 2019 at 06:52:50PM +0800, Ley Foon Tan wrote:
[...]
> +static int s10_tlp_read_packet(struct altera_pcie *pcie, u32 *value)
> +{
> + int i;
> + u32 ctrl;
> + u32 comp_status;
> + u32 dw[4];
> + u32 count;
> +
> + for (i = 0; i < TLP_LOOP; i++) {
> +
The handler for the debug exception will call is_valid_bugaddr(bugaddr) to
check if the instruction in bugaddr is a real debug instruction. However,
the expected instruction, ebreak, is possibly translated to c.ebreak by
assmebler when C extension is supported. This patchset will add c.ebreak
This can help developers to analyze the cause of WARN() because the
control will be transferred to debugging environment if the debugger is
connected.
Signed-off-by: Vincent Chen
---
arch/riscv/include/asm/bug.h | 27 ++-
arch/riscv/kernel/traps.c| 19
The kernel module is loaded into vmalloc region which is located below
to the PAGE_OFFSET. Hence the condition, pc < PAGE_OFFSET, in the
is_valid_bugaddr() will filter out all trap exceptions triggered
by kernel module. To support BUG() in kernel module, the condition is
changed to pc <
Since the removal of FS_RECLAIM annotations, lockdep states contain six
characters, not four.
Fixes: e5684bbfc3f03480 ("Documentation/locking/lockdep: Update info about
states")
Fixes: d92a8cfcb37ecd13 ("locking/lockdep: Rework FS_RECLAIM annotation")
Signed-off-by: Geert Uytterhoeven
---
The is_valid_bugaddr() function compares the instruction pointed to by
$sepc with macro __BUG_INSN to check whether the current trap exception
is caused by an "ebreak" instruction. Hence the macro __BUG_INSN is
defined as "ebreak". However, this check flow is possibly erroneous
because the
On 2019/02/28 19:23, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
> wrote:
>>
>> On 2019/02/28 15:51, Dmitry Vyukov wrote:
>>> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
Thank you. The LSM stacking seems to be working as expected.
But this one should not
Suspicious RCU usage messages are reported as warnings.
Fixes: a5dd63efda3d07b5 ("lockdep: Use "WARNING" tag on lockdep splats")
Signed-off-by: Geert Uytterhoeven
---
And before that, they were printed as errors, which was also never
reflected in the documentation...
---
On Thu, Feb 28, 2019 at 09:46:57AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> > Sent: 28 February 2019 02:03
> > To: xen-de...@lists.xenproject.org; net...@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Cc: Wei
On 28.02.2019 10:42, Christian Borntraeger wrote:
[...]
>> Okay, let's go back to the genesis of this discussion; namely, my
>> suggestion about moving the fc == 0x03 check into the hook code. If
>> the vfio_ap module is not loaded, there will be no hook code. In that
>> case, the check for the
On Thu, Feb 28, 2019 at 3:29 AM Brian Norris wrote:
>
> Hi Rafael,
>
> On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki wrote:
> > On Wed, Feb 27, 2019 at 9:58 PM Brian Norris
> > wrote:
> > > On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> > > > So I'd argue that we should
Commit-ID: 9cd05ad2910b55238e3c720c99ad896dc538301b
Gitweb: https://git.kernel.org/tip/9cd05ad2910b55238e3c720c99ad896dc538301b
Author: Lan Tianyu
AuthorDate: Mon, 25 Feb 2019 22:31:14 +0800
Committer: Thomas Gleixner
CommitDate: Thu, 28 Feb 2019 11:58:29 +0100
x86/hyper-v: Fix
On Thu, Feb 28, 2019 at 03:17:51PM +0800, kernel test robot wrote:
> Greeting,
>
> FYI, we noticed a -41.4% regression of pft.faults_per_sec_per_cpu due to
> commit:
>
>
> commit: 2c83362734dad8e48ccc0710b5cd2436a0323893 ("sched/fair: Consider
> SD_NUMA when selecting the most idle group to
Commit-ID: ce02ef06fcf7a399a6276adb83f37373d10cbbe1
Gitweb: https://git.kernel.org/tip/ce02ef06fcf7a399a6276adb83f37373d10cbbe1
Author: Daniel Borkmann
AuthorDate: Thu, 21 Feb 2019 23:19:41 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 28 Feb 2019 12:10:31 +0100
x86, retpolines:
Hi Julia,
On Sat, Feb 23, 2019 at 2:58 PM Julia Lawall wrote:
>
> Add an of_node_put when a tested device node is not available.
>
> The semantic patch that fixes this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @@
> identifier f;
> local idexpression e;
> expression x;
> @@
>
In order for devicetree nodes to be correctly associated with attached
devices, the controller node needs to be propagated to the glue device.
Signed-off-by: Mans Rullgard
---
This depends on 2c1ea6abde88 ("platform: set of_node in
platform_device_register_full()") which is currently winding its
On Fri, 15 Feb 2019, Andy Shevchenko wrote:
> Driver data can be a plain integer and we have such users.
> For now they are implementing a custom macro to accept this.
It would be nice to actually see the conversions as well.
Thanks,
tglx
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 28 February 2019 11:02
> To: Paul Durrant
> Cc: Igor Druzhinin ;
> xen-de...@lists.xenproject.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org; Wei Liu
> ;
> da...@davemloft.net
> Subject: Re: [PATCH]
On Thu, 28 Feb 2019 12:03:38 +0100
Christian Borntraeger wrote:
> On 28.02.2019 10:42, Christian Borntraeger wrote:
> [...]
> >> Okay, let's go back to the genesis of this discussion; namely, my
> >> suggestion about moving the fc == 0x03 check into the hook code. If
> >> the vfio_ap module is
On Thu, Feb 28, 2019 at 11:33:26AM +0300, Andrey Ryabinin wrote:
> workingset_eviction() doesn't use and never did use the @mapping argument.
> Remove it.
>
> Signed-off-by: Andrey Ryabinin
> Acked-by: Johannes Weiner
> Acked-by: Rik van Riel
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc:
On Thu, 2019-02-28 at 03:12 -0800, tip-bot for Daniel Borkmann wrote:
> Commit-ID: ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> Gitweb:
> https://git.kernel.org/tip/ce02ef06fcf7a399a6276adb83f37373d10cbbe1
> Author: Daniel Borkmann
> AuthorDate: Thu, 21 Feb 2019 23:19:41 +0100
>
On 27/02/2019 17:38, Dave Hansen wrote:
> On 2/27/19 9:06 AM, Steven Price wrote:
>> #ifdef CONFIG_SHMEM
>> static int smaps_pte_hole(unsigned long addr, unsigned long end,
>> -struct mm_walk *walk)
>> + __always_unused int depth, struct mm_walk *walk)
>> {
>
>
Commit-ID: 6f913de3231e1d70a871135b38219da7810df218
Gitweb: https://git.kernel.org/tip/6f913de3231e1d70a871135b38219da7810df218
Author: Kirill A. Shutemov
AuthorDate: Tue, 19 Feb 2019 10:52:24 +0300
Committer: Thomas Gleixner
CommitDate: Thu, 28 Feb 2019 12:25:05 +0100
On Thu, Feb 28, 2019 at 05:20:03PM +0800, Wei Li wrote:
> Since commit 1fb87b8e9599 ("perf machine: Don't search for active kernel
> start in __machine__create_kernel_maps"), the __machine__create_kernel_maps()
> just create a map what start and end are both zero. Though the address will be
>
101 - 200 of 1382 matches
Mail list logo
