On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The external memory arbitration configuration is getting reset after
> memory entering into self-refresh mode, it shall be restored on the
> exit. Note that MC_EMEM_ARB_CFG register is shadowed and latching
> happens on the EMC timing update. This
On 19/11/2018 21:27, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> The memory interface configuration and re-calibration interval are left
>> unassigned on resume from LP1 because these registers are shadowed and
>> require latching after being adjusted.
>>
>>
Hello,
syzbot found the following crash on:
HEAD commit:cddaf02bcb73 tg3: optionally use eth_platform_get_mac_addr..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15810d3340
kernel config: https://syzkaller.appspot.com/x/.config?x=d86f24333880b605
On Mon, Nov 19, 2018 at 11:32:39AM +0100, Christian Brauner wrote:
>
> +/**
> + * sys_procfd_signal - send a signal to a process through a process file
> + * descriptor
> + * @fd: the file descriptor of the process
> + * @sig: signal to be sent
> + * @info: the signal info
On 20.11.2018 0:26, Jon Hunter wrote:
>
> On 19/11/2018 17:05, Dmitry Osipenko wrote:
>> On 19.11.2018 18:42, Jon Hunter wrote:
>>>
>>> On 18/11/2018 22:06, Dmitry Osipenko wrote:
On 30.08.2018 21:54, Dmitry Osipenko wrote:
> Hello,
>
> This patch series fixes couple bugs in the
On 11/19/2018 12:55 PM, Jiri Kosina wrote:
> On Mon, 19 Nov 2018, Thomas Gleixner wrote:
>
>>
>> So before that change IBPB was usable without STIBP, now not longer. What's
>> the rationale?
>>
>> This patch changes a gazillion things at once and is completely
>> unreviewable.
>
> The patchset
On Mon, 2018-11-19 at 14:17 -0800, Andy Lutomirski wrote:
> On Mon, Nov 19, 2018 at 1:55 PM Yu-cheng Yu wrote:
> >
> > From: "H.J. Lu"
> >
> > When Intel indirect branch tracking is enabled, functions in vDSO which
> > may be called indirectly must have endbr32 or endbr64 as the first
> >
On 11/19/18 3:16 PM, Andrea Arcangeli wrote:
> So you may want to ask why it wasn't written as your "any" vs "any" email:
Presumably because the authors really and truly meant what they said. I
was not being as careful in my wording as they were. :)
There is nothing in the spec that says that
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.138 release.
There are 83 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
syscall_get_arch() is required to be implemented on all architectures
in order to extend the generic ptrace API with PTRACE_GET_SYSCALL_INFO
request.
Signed-off-by: Dmitry V. Levin
---
v2: unchanged since [PATCH 10/13 v2]
arch/nds32/include/asm/syscall.h | 8
On Mon, Nov 19, 2018 at 3:07 PM Tycho Andersen wrote:
> > These tools also care about ioctls. Adding a system call is a pain,
> > but the solution is to make adding system calls less of a pain, not to
> > permanently make the Linux ABI worse.
>
> For user-defined values of "worse" :)
>
I tend to
Hello,
My name is ms. Reem Al-Hashimi. The UAE minister of state for international
cooparation. I got your contact from a certain email database from your country
while i was looking for someone to handle a huge financial transaction for me
in confidence. Can you receive and invest on behalf
stable-rc/linux-4.19.y boot: 120 boots: 0 failed, 101 passed with 18 offline, 1
conflict (v4.19.2-206-g857962e4c7ee)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.2-206-g857962e4c7ee/
Full Build Summary:
Hi Kees:
I want to listen to you.
--Yangtao
On Tue, Nov 20, 2018 at 8:49 AM Frank Lee wrote:
>
> Hi Dava:
>
> How about just change the ptdump_fops and ptdump_open?
>
> Yours,
> Yangtao
> On Tue, Nov 20, 2018 at 1:06 AM Dave Hansen wrote:
> >
> > On 11/19/18 7:43 AM, Yangtao Li wrote:
> >
stable-rc/linux-4.14.y boot: 77 boots: 0 failed, 59 passed with 18 offline
(v4.14.81-125-g43bb46eb6e2e)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.81-125-g43bb46eb6e2e/
Full Build Summary:
On Mon, Nov 19, 2018 at 9:35 PM Luc Van Oostenryck
wrote:
>
> On Mon, Nov 19, 2018 at 07:31:41PM +0900, Masahiro Yamada wrote:
> > When I tried to delete BUILD_BUG_ON stubs for sparse, the kbuild test
> > robot reported lots of Sparse warnings from container_of(), which
> > seem false positive.
>
Reported by syzkaller:
BUG: unable to handle kernel NULL pointer dereference at 0014
PGD 80040410c067 P4D 80040410c067 PUD 40410d067 PMD 0
Oops: [#1] PREEMPT SMP PTI
CPU: 3 PID: 2567 Comm: poc Tainted: G OE 4.19.0-rc5 #16
RIP:
On 2018/11/17 9:33, Wengang Wang wrote:
> The this_cpu_cmpxchg makes the do-while loop pass as long as the
> s->cpu_slab->partial as the same value. It doesn't care what happened to
> that slab. Interrupt is not disabled, and new alloc/free can happen in the
> interrupt handlers. Theoretically,
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The DRAM refresh-interval is getting erroneously set to "1" on exiting
> from memory self-refreshing mode. The clobbered interval causes the
> "refresh request overflow timeout" error raised by the External Memory
> Controller on exiting from LP1 on
On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
> On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
> wrote:
> > That can be done without a loop by comparing the level counter for the
> > two pid namespaces.
> >
> >>
> >> And you can rewrite pidns_get_parent to use it. So you
On Thu, 15 Nov 2018, Michal Hocko wrote:
> > The userspace had a single way to determine if thp had been disabled for a
> > specific vma and that was broken with your commit. We have since fixed
> > it. Modifying our software stack to start looking for some field
> > somewhere else will not
show_regs() shows the CS in the CPU register instead of the value in
regs. This means that we'll probably print "CS: 0010" almost all
the time regardless of what was actually in CS when the kernel
malfunctioned. This gives a particularly confusing result if we
OOPSed due to an implicit
This avoids a situation in which we attempt to apply various fixups
that are not intended to handle implicit supervisor accesses from
user mode if we screw up in away that causes this type of fault.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 10 ++
1 file changed, 10
The fault handling code tries to validate that a page fault from
user mode that would extend the stack is within a certain range of
the user SP. regs->sp is only equal to the user SP if
user_mode(regs). In the extremely unlikely event that that
sw_error_code had the USER bit set but the faulting
smap_violation() has a single caller, and the contents are a bit
nonsensical. I'm going to fix it, but first let's fold it into its
caller for ease of comprehension.
In this particular case, the user_mode(regs) check is incorrect --
it will cause false positives in the case of a user-initiated
One of Linus' favorite hobbies seems to be looking at OOPSes and
decoding the error code in his head. This is not one of my favorite
hobbies :)
Teach the page fault OOPS hander to decode the error code. If it's
a !USER fault from user mode, print an explicit note to that effect
and print out
The fault-handling code that takes mmap_sem needs to avoid a
deadlock that could occur if the kernel took a bad (OOPS-worthy)
page fault on a user address while holding mmap_sem. This can only
happen if the faulting instruction was in the kernel
(i.e. user_mode(regs)). Rather than checking the
__bad_area_nosemaphore() currently checks the X86_PF_USER bit in the
error code to decide whether to send a signal or to treat the fault
as a kernel error. This can cause somewhat erratic behavior. The
straightforward cases where the CPL agrees with the hardware USER
bit are all correct, but the
The fault handling code sets the cr2, trap_nr, and error_code fields
in thread_struct before OOPSing. No one reads those fields during
an OOPS, so remove the code to set them.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 8
1 file changed, 8 deletions(-)
diff --git
Add X86_FEATURE_SMAP to the disabled features mask as appropriate
and use cpu_feature_enabled() in the fault code. This lets us get
rid of a redundant IS_ENABLED(CONFIG_X86_SMAP).
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/disabled-features.h | 8 +++-
arch/x86/mm/fault.c
Since v2.6.22 or so there has been reports [1] about OMAP MMC being
broken on OMAP15XX based hardware (OMAP5910 and OMAP310). The breakage
seems to have been caused by commit 46a6730e3ff9 ("mmc-omap: Fix
omap to use MMC_POWER_ON") that changed clock enabling to be done
on MMC_POWER_ON. This can
Commit f77084d96355 "x86/mm/pat: Disable preemption around
__flush_tlb_all()" addressed a case where __flush_tlb_all() is called
without preemption being disabled. It also left a warning to catch other
cases where preemption is not disabled. That warning triggers for the
memory hotplug path which
stable-rc/linux-4.18.y boot: 125 boots: 0 failed, 105 passed with 18 offline, 1
untried/unknown, 1 conflict (v4.18.19-172-gc15e70be568b)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.18.y/kernel/v4.18.19-172-gc15e70be568b/
Full Build Summary:
stable-rc/linux-4.9.y boot: 59 boots: 0 failed, 43 passed with 16 offline
(v4.9.137-83-g4ca3f6d71162)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.137-83-g4ca3f6d71162/
Full Build Summary:
On Tue, Nov 20, 2018 at 07:37:58AM +0800, kbuild test robot wrote:
> Hi Christian,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.20-rc3]
> [cannot apply to next-20181119]
> [if your patch
On Mon, Nov 19, 2018 at 03:25:41PM -0800, Dave Hansen wrote:
> On 11/19/18 3:16 PM, Andrea Arcangeli wrote:
> > So you may want to ask why it wasn't written as your "any" vs "any" email:
>
> Presumably because the authors really and truly meant what they said. I
> was not being as careful in my
On 11/19/18 3:19 PM, Dan Williams wrote:
> Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
> and Dave confirmed the expectation for TLB flush is for modifying /
> invalidating existing pte entries, but not initial population [2].
I _think_ this is OK.
But, could we
On 11/19/18 9:27 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.164 release.
There are 160 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 Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> wrote:
> ...
> >
> > A number of us have talked about this in the plumbers Android track, and
> > a different proposal for how to solve this has been made that should be
> >
On Mon, 19 Nov 2018, Andrea Arcangeli wrote:
> On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> > Here's the current description:
> >
> > > Setting ... STIBP ... on a logical processor prevents the predicted
> > > targets of indirect branches on any logical processor of that core
>
Hi all-
We currently have some giant turds in the way that syscalls are
numbered. We have the x86_32 table, which is totally sane other than
some legacy multiplexers. Then we have the x86_64 table, which is,
um, demented:
- The numbers don't match x86_32. I have no idea why.
- We use bit
Geert,
Please consider cherry-picking this patch. It isn't particularly relevant
to the API conversion so I'd better not to include it in v3, when I submit
v3.
--
On Mon, 19 Nov 2018, Finn Thain wrote:
> Signed-off-by: Finn Thain
> ---
> arch/m68k/include/asm/macints.h | 3 ---
> 1 file
The filechk macro in scripts/Kbuild.include already sets 'set -e'.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
arch/um/Makefile | 2 +-
scripts/Makefile.lib | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/um/Makefile b/arch/um/Makefile
index
As a Kbuild maintainer, I always struggle to keep the core makefiles
clean because people tend to squeeze more and more clutter code into
the kbuild core in order to do what they want to do.
The biggest step forward in this series is to re-implement
the build trick of CONFIG_TRIM_UNUSED_KSYMS in
On Sat, 2018-11-17 at 10:12 -0800, Andrey Smirnov wrote:
> PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
> so none of the code in current implementation of imx6_pcie_reset_phy()
> is applicable.
Tested on IMX7d, still appears to work.
Note that your patches will collide
Best Regards,
liujian
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: Tuesday, November 13, 2018 3:49 AM
> To: liujian (CE)
> Cc: linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] driver: input: fix UBSAN warning
On 11/19/18 at 09:59pm, Michal Hocko wrote:
> On Mon 19-11-18 12:34:09, Hugh Dickins wrote:
> > I'm glad that I delayed, what I had then (migration_waitqueue instead
> > of using page_waitqueue) was not wrong, but what I've been using the
> > last couple of months is rather better (and can be put
Hi John,
Thanks for your review.
John Stultz 于2018年11月20日周二 上午2:16写道：
>
> On Mon, Nov 19, 2018 at 6:10 AM, Muchun Song wrote:
> > The elements of the heads array are a linked list of timer events that
> > expire at the current time. And it can contain up to LVL_DEPTH levels
> > and the lower
Hello,
On (11/16/18 16:20), Minchan Kim wrote:
[..]
> +static ssize_t idle_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + struct zram *zram = dev_to_zram(dev);
> + unsigned long nr_pages = zram->disksize >> PAGE_SHIFT;
> +
Hello
How are you? Am SARAH MONGAR. For an Export Business am, writing
to inform you, concerning business proposer in Agriculture raw
materials export supply to Germany. If you are good in Business kindly
write me on my mail I'D sarahmor1...@gmail.com
SARAH MONGAR
E-mail:
Hi Daniel,
On Mon, 2018-11-19 at 22:50 +0100, Daniel Lezcano wrote:
> On 19/11/2018 12:29, Alexey Brodkin wrote:
> > It turned out we used to use default implementation of sched_clock()
> > from kernel/sched/clock.c which was as precise as 1/HZ, i.e.
> > by default we had 10 msec granularity of
On 20.11.2018 0:34, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> The DRAM refresh-interval is getting erroneously set to "1" on exiting
>> from memory self-refreshing mode. The clobbered interval causes the
>> "refresh request overflow timeout" error raised by the External
On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
As I noted when this patch was originally proposed and when I nacked it[*]
because it causes a 13.9% increase in remote memory access latency and up
to 40% increase
On 20.11.2018 1:00, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> Two interrupts are raised on resume from LP1 on Tegra30+: first is the
>> clock change completed interrupt which is set after updating timing
>> configuration, second is DLL alarm interrupt which is set when
On Mon, Nov 19, 2018 at 2:40 PM Tycho Andersen wrote:
> Can I just register an objection here that I think using a syscall
> just for this is silly?
Yes, you can argue that the bikeshed should be ioctl-colored and not
syscall-colored.
> My understanding is that the concern is that some code
On Mon, 19 Nov 2018, Tim Chen wrote:
> On 11/19/2018 12:55 PM, Jiri Kosina wrote:
> > On Mon, 19 Nov 2018, Thomas Gleixner wrote:
> >
> >>
> >> So before that change IBPB was usable without STIBP, now not longer. What's
> >> the rationale?
> >>
> >> This patch changes a gazillion things at once
On Mon, Nov 19, 2018 at 01:33:08PM -0800, Dave Hansen wrote:
> On 11/19/18 11:32 AM, Andrea Arcangeli wrote:
> > The specs don't say if by making it immune from BTB mistraining, it
> > also could prevent to mistrain the BTB in order to attack what's
> > outside the SECCOMP jail. Probably it won't
Hi Christian,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc3]
[cannot apply to next-20181119]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
On Mon, Nov 19, 2018 at 11:31:21AM -0800, Randy Dunlap wrote:
>
> Yes, all of that.
> Having some kind of pstore on x86 would be wonderful.
>
> kexec/kdump used to be an option also. I haven't tried it lately.
Sure, but kexec/kdump won't work to debug a boot failure during early
boot. You
On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.18.126 release.
There are 90 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 11/19/2018 05:32 AM, Thomas Gleixner wrote:
> Tim,
>
> On Fri, 16 Nov 2018, Tim Chen wrote:
>
>> Add new protection modes for Spectre v2 mitigations against
>> Spectre v2 attacks on user processes. There are three modes:
>>
>> strict mode:
>> In this mode, IBPB and STIBP are
On 11/19/2018 04:00 PM, Thomas Gleixner wrote:
> On Tue, 20 Nov 2018, Jiri Kosina wrote:
>
>> On Tue, 20 Nov 2018, Thomas Gleixner wrote:
>>
>>> What? IBPB makes tons of sense even without STIBP.
>>
>> On non-SMT, yes. But this patchset ties those two the other (sensible) way
>> around AFAICS
On 20.11.2018 3:26, Douglas Anderson wrote:
> In regulator_force_disable() there was a strange loop that looked like:
>
> while (rdev->open_count--)
> regulator_disable(rdev->supply);
>
> I'm not totally sure what the goal was for this loop, but it seems
> wrong to me. If anything I think
On 11/12/18 3:37 PM, Rob Herring wrote:
On Wed, Nov 07, 2018 at 05:13:44PM +, Sudeep Holla wrote:
The current ARM DT topology description provides the operating system
with a topological view of the system that is based on leaf nodes
representing either cores or threads (in an SMT system)
On Mon, 2018-11-19 at 10:41 +0100, Stefan Agner wrote:
>
>
> +static const struct imx6_pcie_drvdata imx6q_pcie_drvdata = {
> + .variant = IMX6Q,
> + .dbi_length = 0x15c,
> +};
> +
> +static const struct imx6_pcie_drvdata imx6sx_pcie_drvdata = {
> + .variant = IMX6SX,
> +};
> +
>
Current imx7d-sdb.dts has some incorrect settings about
Rev-A and Rev-B boards, some of the settings are based on
Rev-A board but some are based on Rev-B board, clean up it
by adding i.MX7D SDB Rev-A board support, make default
imx7d-sdb.dts for Rev-B board as usual, and introduce
On Mon, Nov 19, 2018 at 1:41 AM Heiko Stübner wrote:
>
> Am Freitag, 16. November 2018, 19:23:59 CET schrieb Doug Anderson:
> > Hi,
> >
> > On Fri, Nov 16, 2018 at 9:39 AM dbasehore . wrote:
> > > On Fri, Nov 16, 2018 at 8:01 AM Doug Anderson
> wrote:
> > > > Hi,
> > > >
> > > > On Thu, Nov 15,
Hi,
On Mon, Nov 19, 2018 at 4:58 PM Dmitry Osipenko wrote:
>
> On 20.11.2018 3:26, Douglas Anderson wrote:
> > In regulator_force_disable() there was a strange loop that looked like:
> >
> > while (rdev->open_count--)
> > regulator_disable(rdev->supply);
> >
> > I'm not totally sure what
On Sun, Nov 11, 2018 at 4:22 AM Pavel Machek wrote:
>
> On Sun 2018-11-11 12:57:12, Hans de Goede wrote:
> > Hi,
> >
> > On 11/7/18 5:53 AM, Daniel Drake wrote:
> > >On Mon, Nov 5, 2018 at 1:19 AM Pavel Machek wrote:
> > >>Plus, I don't think "100% charge" is right test for "battery full". At
>
Hi Jirka,
On Mon, Nov 19, 2018 at 01:20:04PM +0100, Jiri Olsa wrote:
> hi,
> David reported issues with perf top loosing side band events
> so we moved mmap reading and hists processing into separated
> threads.
>
> This patchset also adds dropping sample logic when the processing
> falls behind
Hi Marc,
Thanks for the quick review!
On Mon, Nov 19, 2018 at 05:36:49PM +, Marc Zyngier wrote:
> Manivannan,
>
> On 19/11/2018 17:09, Manivannan Sadhasivam wrote:
> > Add interrupt driver for RDA Micro RDA8810PL SoC.
> >
> > Signed-off-by: Andreas Färber
> > Signed-off-by: Manivannan
> On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> > On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> > wrote:
> > ...
> > >
> > > A number of us have talked about this in the plumbers Android track, and
> > > a different proposal for how to solve this has been made that
A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
where we don't need to modify core VFS structures to get the same
behavior of the seal. This solves several side-effects pointed out by
Andy [2].
[1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/
[2]
Modify the tests for F_SEAL_FUTURE_WRITE based on the changes
introduced in previous patch.
Also add a test to make sure the reopen issue pointed by Jann Horn [1]
is fixed.
[1]
https://lore.kernel.org/lkml/CAG48ez1h=v-JYnDw81HaYJzOfrNhwYksxmc2r=cjvdqvgym...@mail.gmail.com/
Cc: Jann Horn
We appreciate your comments.
We refine source code according to your comments.
>> This is an interesting idea, and an evolution since the initial
>> approach which was submitted based upon xattr attributes. I still
>> find the idea of using attributes simpler to manage though, since
>> they're
Hi all,
Do you have any comments on this serial?
Thanks.
Wei.
On 13/11/2018 6:06 PM, Wei Ni wrote:
> This series fixed some issues for Tegra soctherm
>
> Main changes from v1:
> 1. Acked by Thierry Reding for the patch
> "thermal: tegra: fix memory allocation".
> 2. Print out the sensor name
* Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um, demented:
>
> - The numbers don't match
On 19/11/2018 18.19, Tony Lindgren wrote:
> * Peter Ujfalusi [181119 10:16]:
>> On 2018-11-13 20:06, Tony Lindgren wrote:
>>> Looks like the IRQ_TYPE_NONE issue still is there for omap5 and
>>> should be fixed with IRQ_TYPE_HIGH.
>>>
>>> No idea about why palmas interrupts would stop working
On Mon, Nov 19, 2018 at 05:09:38PM -0700, shuah wrote:
> On 11/19/18 9:28 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.126 release.
> > There are 90 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues
On Tue, 2018-11-13 at 08:18 -0800, Nicolas Boichat wrote:
> On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu wrote:
> >
> > From: Owen Chen
> >
> > 1. pcwibits: The integer bits of pcw for plls is extend to 8 bits,
> >add a variable to indicate this change and
> >backward-compatible.
> > 2.
On Mon, Nov 19, 2018 at 01:39:02PM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:bae4e109837b mlxsw: spectrum: Expose discard counters via ..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=11b5e77b40
>
On 19/11/18 4:46 PM, Faiz Abbas wrote:
The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids
assertion of data reset while tuning is happening. Implement a
platform specific callback that takes care of this condition.
[1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4
Daniel Colascione writes:
> On Mon, Nov 19, 2018 at 1:37 PM Christian Brauner
> wrote:
>>
>> On Mon, Nov 19, 2018 at 01:26:22PM -0800, Daniel Colascione wrote:
>> > On Mon, Nov 19, 2018 at 1:21 PM, Christian Brauner
>> > wrote:
>> > > That can be done without a loop by comparing the level
On Tue, 2018-11-13 at 08:00 -0800, Nicolas Boichat wrote:
> On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
> >
> > From: Owen Chen
> >
> > On both MT8183 & MT6765, there add "set/clr" register for
> > each clkmux setting, and one update register to trigger value change.
> > It is designed to
Hello Linus
Signed-off-by: Florian Eckert
This is looking better and better! Thanks to everyone helping out
and thanks for your perseverance Florian!
I have to thanks for reviewing my driver.
This is the way opensource works.
Thanks for the feedback i will update the driver with your
On 19 November 2018 9:55:07 PM IST, Greg Kroah-Hartman
wrote:
>This is the start of the stable review cycle for the 4.19.3 release.
>There are 205 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.
>
On Mon 19-11-18 14:05:34, David Rientjes wrote:
> On Thu, 15 Nov 2018, Michal Hocko wrote:
>
> > > The userspace had a single way to determine if thp had been disabled for
> > > a
> > > specific vma and that was broken with your commit. We have since fixed
> > > it. Modifying our software
CPUID Fn8000_0007_EDX[CPB] is wrongly 0 on some newer F17h
procssors but their revision guide has not been released.
For example,Tesed on AMD "Ryzen 7 2700U with Radeon Vega Mobile Gfx"
and "AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx",
their CPUID Fn_0001_EAX is 0x00810f10 and should have
Hi all,
Changes since 20181119:
The regulator tree gained a build failure so I used the version from
next-20181119.
The tip tree still had its build failure for which I applied a fix patch.
The staging tree gained a conflict against the drm tree.
Non-merge commits (relative to Linus' tree
On 19/11/18 4:46 PM, Faiz Abbas wrote:
The sdhci_execute_tuning() function has assignment of
private pointers multiple times. Remove the redundant assignment.
Signed-off-by: Faiz Abbas
Acked-by: Kishon Vijay Abraham I
---
drivers/mmc/host/sdhci-omap.c | 4
1 file changed, 4
Hi Rob,
On 17/11/18 1:50 AM, Rob Herring wrote:
On Thu, Oct 18, 2018 at 8:31 AM Rob Herring wrote:
DT bindings normally go in via subsystem maintainers, so add PHY
bindings under generic PHY framework.
Reported-by: Gustavo A. R. Silva
Cc: Kishon Vijay Abraham I
Signed-off-by: Rob Herring
On Sat, Nov 17, 2018 at 3:03 PM, Bruce Fields wrote:
> On Sat, Nov 17, 2018 at 08:33:27AM -0500, Jeff Layton wrote:
>> Thanks for the explanation, Dmitry. I've added the tag to the patch in
>> my tree. It should show up in linux-next soon.
>>
>> I still find it a little misleading to say that
Hi Uffe
On 19/11/18 6:48 PM, Ulf Hansson wrote:
> On 19 November 2018 at 12:16, Faiz Abbas wrote:
>> Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
>> disabled DCRC interrupts during tuning. This write to the interrupt
>> enable register gets overwritten in
In case the RSDP address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
arch/x86/include/uapi/asm/bootparam.h | 3 ++-
arch/x86/kernel/acpi/boot.c | 2 +-
2 files
On Tue, 20 Nov 2018, Masahiro Yamada wrote:
> My main motivation of this commit is to clean up scripts/Kbuild.include
> and scripts/Makefile.build.
>
> Currently, CONFIG_TRIM_UNUSED_KSYMS works with a tricky gimmick;
> possibly exported symbols are detected by letting $(CPP) replace
>
On 11/9/2018 10:09 PM, Niklas Cassel wrote:
On Mon, Nov 05, 2018 at 05:17:45PM -0600, Rob Herring wrote:
On Mon, Oct 15, 2018 at 02:47:49PM +0200, Niklas Cassel wrote:
Extend qcom-opp bindings with properties needed for Core Power Reduction
(CPR).
CPR is included in a great variety of
On 19-11-18, 14:18, Quentin Perret wrote:
> @@ -223,20 +222,33 @@ static unsigned long sugov_get_util(struct sugov_cpu
> *sg_cpu)
> - if ((util + cpu_util_dl(rq)) >= max)
> - return max;
> + if (type == FREQUENCY_UTIL) {
> + /*
> + * For frequency
On 11/20/2018 2:22 AM, Sekhar Nori wrote:
On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board
On Tue, Nov 20, 2018 at 12:44:31PM +0530, Harsh Shandilya wrote:
> On 19 November 2018 9:55:07 PM IST, Greg Kroah-Hartman
> wrote:
> >This is the start of the stable review cycle for the 4.19.3 release.
> >There are 205 patches in this series, all will be posted as a response
> >to this one. If
From: Andi Kleen
This is a fix for another instance of the skid problem Milian
recently found [1]
The LBRs don't freeze at the exact same time as the PMI is triggered.
The perf script brstackinsn code that dumps LBR assembler
assumes that the last branch in the LBR leads to the sample point.
101 - 200 of 3448 matches
Mail list logo
