On Thu, 8 Aug 2019, Matthew Garrett wrote:
> On Thu, Aug 8, 2019 at 3:01 AM Jessica Yu wrote:
> > If you're confident that a hard dependency is not the right approach,
> > then perhaps we could add a comment in the Kconfig (You could take a
> > look at the comment under MODULE_SIG_ALL in
On Thu, Aug 08, 2019 at 06:34:15PM -0400, Joel Fernandes wrote:
> On Thu, Aug 08, 2019 at 01:51:29PM -0700, Paul E. McKenney wrote:
> [snip]
> > > Also, I am thinking that whenever we do per-slab optimization, then the
> > > kmem_cache_free_bulk() can be optimized further. If all pointers are on
On Thu, Aug 08, 2019 at 01:51:29PM -0700, Paul E. McKenney wrote:
[snip]
> > Also, I am thinking that whenever we do per-slab optimization, then the
> > kmem_cache_free_bulk() can be optimized further. If all pointers are on the
> > same slab, then we can just do virt_to_cache on the first pointer
On 8/8/19 3:11 PM, Heiner Kallweit wrote:
> On 08.08.2019 23:47, Tao Ren wrote:
>> Hi Heiner,
>>
>> On 8/7/19 9:24 PM, Tao Ren wrote:
>>> Hi Heiner,
>>>
>>> On 8/7/19 12:18 PM, Heiner Kallweit wrote:
On 06.08.2019 23:42, Tao Ren wrote:
> Hi Andrew / Heiner / Vladimir,
>
> On
Hi all,
Commit
b214b2d8f277 ("rxrpc: Don't use skb_cow_data() in rxkad")
is missing a Signed-off-by from its author and committer.
--
Cheers,
Stephen Rothwell
pgpXCeR9J6c4m.pgp
Description: OpenPGP digital signature
Binderfs was created to help provide private binder devices to
containers in their own IPC namespace. Currently, every time a new binderfs
instance is mounted, its private binder devices need to be created via
IOCTL calls. This patch series eliminates the effort for creating
the default binder
Currently, since each binderfs instance needs its own
private binder devices, every time a binderfs instance is
mounted, all the default binder devices need to be created
via the BINDER_CTL_ADD IOCTL. This patch aims to
add a solution to automatically create the default binder
devices for each
Length of a binderfs device name cannot exceed BINDERFS_MAX_NAME.
This patch adds a check in binderfs_init() to ensure the same
for the default binder devices that will be created in every
binderfs instance.
Co-developed-by: Christian Brauner
Signed-off-by: Christian Brauner
Signed-off-by:
On 8/8/19 2:16 PM, Andrew Lunn wrote:
> On Thu, Aug 08, 2019 at 07:02:54PM +, Tao Ren wrote:
>> Hi Andrew,
>>
>> On 8/8/19 6:32 AM, Andrew Lunn wrote:
Let me prepare patch v2 using device tree. I'm not sure if standard
"mac-address" fits this situation because all we need is an
The WRITE_PROTECT bit is always in a "protected mode" on Tegra and
WP-GPIO state need to be used instead. In a case of the GPIO absence,
write-enable should be assumed. External SD is writable once again as
a result of this patch because the offending commit changed behaviour for
the case of a
On Thu, Aug 08, 2019 at 11:22:16PM +0200, Arnd Bergmann wrote:
> The driver has always had a FIXME about this, and it seems
> like this trivial code move avoids a mach header inclusion,
> so just do it.
This appears to be part of a series but I've no cover letter or anything
else from it. What's
On Fri, Aug 09, 2019 at 07:43:25AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> c42d8cbee4c7 ("Merge branches from Takashi to ease Skylake development.")
>
> is missing a Signed-off-by from its author and committer.
>
> Despite what the commit message says, this is not a merge
Remove the now-obsolete riscv/cpus.txt DT binding document, since we
are using YAML binding documentation instead.
While doing so, transfer the explanatory text about 'harts' (with some
edits) into the YAML file, at Rob's request.
Link:
On 8/8/19 11:56 PM, Christoph Hellwig wrote:
On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
Note that both Thomas and Steven have series touching this area pending,
and there are a couple consumer in flux too - the hmm tree already
conflicts with this series, and I have
On Thu, Aug 08, 2019 at 11:46:45PM +0200, Arnd Bergmann wrote:
> On Thu, Aug 8, 2019 at 11:43 PM Dmitry Torokhov
> wrote:
> >
> > Hi Arnd,
> >
> > On Thu, Aug 08, 2019 at 11:22:22PM +0200, Arnd Bergmann wrote:
> > > By using the new linux/soc/ti/omap1-io.h header instead,
> > > compile-testing
> On Aug 8, 2019, at 6:38 AM, Mark Rutland wrote:
>
> On Wed, Aug 07, 2019 at 11:29:16PM -0400, Qian Cai wrote:
>> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
>> VIVT I-caches") introduced some compiation warnings from GCC (and
>> Clang) with
The v3 series looks good to me.
Reviewed-by: Keith Busch
Bjorn,
If you're okay with the series, we can either take it through nvme,
or you can feel free to apply through pci, whichever you prefer.
Thanks,
Keith
In our experience far more (99.9%+) OOM events are not kernel issues,
they're user task memory issues.
Properly maintained Linux kernel only rarely have issues.
So useful information about the killed task, displayed in a manner
that can be quickly digested, is very helpful.
But it turns out the
On Thu, 8 Aug 2019, Bjorn Helgaas wrote:
> Indeed, sorry I missed it. I generally work based on -rc1, and it
> looks like 251a44888183 was merged after -rc1.
>
> Since we're after the merge window, the default target would be v5.4,
> but I see some post-rc1 pull requests from you, so if you
On Fri, Aug 09, 2019 at 07:43:25AM +1000, Stephen Rothwell wrote:
> Commit
> c42d8cbee4c7 ("Merge branches from Takashi to ease Skylake development.")
> is missing a Signed-off-by from its author and committer.
> Despite what the commit message says, this is not a merge commit.
Ugh, that's
On 08.08.2019 23:47, Tao Ren wrote:
> Hi Heiner,
>
> On 8/7/19 9:24 PM, Tao Ren wrote:
>> Hi Heiner,
>>
>> On 8/7/19 12:18 PM, Heiner Kallweit wrote:
>>> On 06.08.2019 23:42, Tao Ren wrote:
Hi Andrew / Heiner / Vladimir,
On 8/6/19 2:09 PM, Tao Ren wrote:
> The BCM54616S PHY
On Thu, 08 Aug 2019 22:32:38 +0200, Thomas Gleixner said:
> Care to resend the last few with fixed subject lines, so I don't have to
> clean them up?
Will do that later this evening...
> The right thing to do is to have a cpu_offline callback which clears the
> umwait MSR. That covers also the
Hi Zeng,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3-rc3 next-20190808]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Intel Cherry Trail Whiskey Cove extcon driver connect USB data lines to
PMIC at driver probing for further charger detection. This causes reset of
USB data sessions and removing all devices from bus. If system was
booted from Live CD or USB dongle, this makes system unusable.
Check if USB ID pin
Hi Sakari,
Thanks for your review, just some comments/questions below:
On 8/7/19 12:27 PM, Sakari Ailus wrote:
> Hi Helen,
>
> On Tue, Jul 30, 2019 at 03:42:51PM -0300, Helen Koike wrote:
>> From: Jacob Chen
>>
>> Add the core driver for rockchip isp1.
>>
>> Signed-off-by: Jacob Chen
>>
On 08/08/2019 19:59, Michal Hocko wrote:
Well, I am afraid that implementing anything like that in the kernel
will lead to many regressions and bug reports. People tend to have very
different opinions on when it is suitable to kill a potentially
important part of a workload just because memory
Hi All,
> This series is equivalent to the following patch:
>
> https://patchwork.kernel.org/patch/11083551/
>
> posted earlier today.
>
> It addresses review comments from Christoph by splitting the PCI/PCIe ASPM
> part off to a separate patch (patch [1/2]) and fixing a few defects.
Sending
From: Rafael J. Wysocki
One of the modifications made by commit d916b1be94b6 ("nvme-pci: use
host managed power state for suspend") was adding a pci_save_state()
call to nvme_suspend() so as to instruct the PCI bus type to leave
devices handled by the nvme driver in D0 during suspend-to-idle.
From: Rafael J. Wysocki
Add a function checking whether or not PCIe ASPM has been enabled for
a given device.
It will be used by the NVMe driver to decide how to handle the
device during system suspend.
Signed-off-by: Rafael J. Wysocki
---
v2 -> v3:
* Make the new function return bool.
*
On Thu, 8 Aug 2019, Chris Wilson wrote:
> + * By creating our own shmemfs mountpoint, we can pass in
> + * mount flags that better match our usecase.
> + *
> + * One example, although it is probably better with a per-file
> + * control, is selecting huge page allocations
On Thu, Aug 08, 2019 at 10:50:37AM -0700, Linus Torvalds wrote:
> > Note that both Thomas and Steven have series touching this area pending,
> > and there are a couple consumer in flux too - the hmm tree already
> > conflicts with this series, and I have potential dma changes on top of
> > the
On Thu, 2019-08-08 at 18:08 +0200, Julia Lawall wrote:
> Hello,
>
> Is it guaranteed that the loop starting on line 7056 will eventually
> take
> the break? If not, line 7089 will be performing an invalid
> dereference of
> ch.
Good catch Julia, I have talked with Harshitha and if after
With all the header files out of the way, and the clock driver
converted to drivers/clk/, nothing stops us from building
OMAP together with the other platforms.
As usual, the decompressor support is a victim here, and is
only available when CONFIG_DEBUG_LL is configured for the
particular board.
Hi Heiner,
On 8/7/19 9:24 PM, Tao Ren wrote:
> Hi Heiner,
>
> On 8/7/19 12:18 PM, Heiner Kallweit wrote:
>> On 06.08.2019 23:42, Tao Ren wrote:
>>> Hi Andrew / Heiner / Vladimir,
>>>
>>> On 8/6/19 2:09 PM, Tao Ren wrote:
The BCM54616S PHY cannot work properly in RGMII->1000Base-KX mode (for
On Thu, Aug 08, 2019 at 01:51:50PM -0700, Paul Walmsley wrote:
> On Thu, 8 Aug 2019, Bjorn Helgaas wrote:
> > On Thu, Jul 25, 2019 at 02:28:07PM -0700, Paul Walmsley wrote:
> > > From: Wesley Terpstra
> > >
> > > This is part of adding support for RISC-V systems with PCIe host
> > > controllers
On Thu, Aug 08, 2019 at 02:21:46PM -0700, Andrew Morton wrote:
> On Thu, 8 Aug 2019 13:36:04 -0700 Roman Gushchin wrote:
>
> > I've noticed that the "slab" value in memory.stat is sometimes 0,
> > even if some children memory cgroups have a non-zero "slab" value.
> > The following investigation
On Thu, Aug 8, 2019 at 11:43 PM Dmitry Torokhov
wrote:
>
> Hi Arnd,
>
> On Thu, Aug 08, 2019 at 11:22:22PM +0200, Arnd Bergmann wrote:
> > By using the new linux/soc/ti/omap1-io.h header instead,
> > compile-testing can be enabled, and a CONFIG_ARCH_MULTIPLATFORM
> > conversion of omap1 may
The omap1 clock driver now uses types and calling conventions
that are compatible with the common clk core.
Turn on CONFIG_COMMON_CLK and remove all the code that is
now duplicated.
Note: if this previous steps didn't already break it, this one
most likely will, because the interfaces are very
The common_clk layer requires common data to be passed
as clk_init_data, so mimic this here.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/clock.c | 266 ++--
1 file changed, 99 insertions(+), 167 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c
To get closer to the way the common_clk code works, rename
the omap1 struct clk to 'omap1_clk', and add trivial 'clk_hw'
and 'clk' wrapper to work like the generic counterparts.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/clock.c | 364
1 file
Mark all internal functions as 'static', remove forward declarations
and those functions that have no caller, as well as any unused
macros or struct fields.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/clock.c | 409 +---
1 file changed, 96 insertions(+),
The omap1 clock support is traditionally split into the clock.c,
clock_data.c and opp_data.c files. As a preparation for cleaning
this up, move everything into one file.
No functional change, each added line comes from an existing file.
Signed-off-by: Arnd Bergmann
---
The callbacks for clocks are almost the same as those used
on common_clk, now reduce the number of remaining differences:
- make .recalc_rate and .round_rate take a parent_rate argument
- move .recalc_rate/.set_rate/.round_rate/.init from
'struct clk_hw' into 'struct clk_ops'.
Signed-off-by:
Hi all,
Commit
c42d8cbee4c7 ("Merge branches from Takashi to ease Skylake development.")
is missing a Signed-off-by from its author and committer.
Despite what the commit message says, this is not a merge commit.
--
Cheers,
Stephen Rothwell
pgp8Cv82EnogF.pgp
Description: OpenPGP digital
Hi Arnd,
On Thu, Aug 08, 2019 at 11:22:22PM +0200, Arnd Bergmann wrote:
> By using the new linux/soc/ti/omap1-io.h header instead,
> compile-testing can be enabled, and a CONFIG_ARCH_MULTIPLATFORM
> conversion of omap1 may eventually be possible.
>
> The warning in the header file gets removed
On 8/8/19 10:27 AM, Tim Chen wrote:
> On 8/7/19 11:47 PM, Aaron Lu wrote:
>> On Tue, Aug 06, 2019 at 02:19:57PM -0700, Tim Chen wrote:
>>> +void account_core_idletime(struct task_struct *p, u64 exec)
>>> +{
>>> + const struct cpumask *smt_mask;
>>> + struct rq *rq;
>>> + bool force_idle,
Hi Thomas,
On 8/8/19 4:08 PM, Thomas Gleixner wrote:
> Tom,
>
> On Thu, 8 Aug 2019, Lendacky, Thomas wrote:
>> On 8/8/19 3:36 PM, Thomas Gleixner wrote:
>>> On Thu, 1 Aug 2019, Lendacky, Thomas wrote:
On 8/1/19 5:13 AM, Thomas Gleixner wrote:
> 2.1.9 Timers
>
> Each
By using the new linux/soc/ti/omap1-io.h header instead,
compile-testing can be enabled, and a CONFIG_ARCH_MULTIPLATFORM
conversion of omap1 may eventually be possible.
The warning in the header file gets removed in order to
allow CONFIG_COMPILE_TEST.
Signed-off-by: Arnd Bergmann
---
As a preparation for cleaning up the omap1 headers, start
including linux/soc/ti/omap1-soc.h directly so we can
keep calling cpu_is_omap1510().
Signed-off-by: Arnd Bergmann
---
drivers/tty/serial/8250/8250.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/8250.h
The ISA I/O space handling in omap_cf is incompatible with
PCI drivers in a multiplatform kernel, and requires a custom
mach/io.h.
Change the driver to use pci_ioremap_io() like PCI drivers do,
so the generic ioport access can work across platforms.
To actually use that code, we have to select
As a preparation for future omap1 multiplatform support, stop
using mach/hardware.h and instead include the omap1-io.h
for low-level register access to MOD_CONF_CTRL_1.
Signed-off-by: Arnd Bergmann
---
drivers/clocksource/timer-ti-dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
On Thu, Aug 08, 2019 at 01:35:41PM -0700, Paul E. McKenney wrote:
> On Wed, Aug 07, 2019 at 02:41:31PM -0700, Paul E. McKenney wrote:
> > On Tue, Aug 06, 2019 at 11:08:24AM -0700, Paul E. McKenney wrote:
> > > On Mon, Aug 05, 2019 at 10:48:00AM -0700, Paul E. McKenney wrote:
> > > > On Mon, Aug
There is only one board that uses the omap_cf driver, so
moving the chipselect configuration there does not lead
to code duplication but avoids the use of mach/tc.h
in drivers.
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-omap1/board-osk.c | 38 -
The driver has always had a FIXME about this, and it seems
like this trivial code move avoids a mach header inclusion,
so just do it.
With that out of the way, and the header file inclusions
changed to global files, the driver can also be compile-tested
on other platforms.
Signed-off-by: Arnd
On Thu, Aug 8, 2019 at 1:23 PM shuah wrote:
>
> On 8/8/19 1:40 PM, Mina Almasry wrote:
> > Problem:
> > Currently tasks attempting to allocate more hugetlb memory than is
> > available get
> > a failure at mmap/shmget time. This is thanks to Hugetlbfs Reservations [1].
> > However, if a task
There are three remaining header files that are used by omap1
specific device drivers:
- mach/soc.h provides cpu_is_omapXXX abstractions
- mach/hardware.h provides omap_read/omap_write functions
and physical addresses
- mach/mux.h provides an omap specific pinctrl abstraction
This is generally
Hi Linus,
The following changes since commit e21a712a9685488f5ce80495b37b9fdbe96c230d:
Linux 5.3-rc3 (2019-08-04 18:40:12 -0700)
are available in the Git repository at:
git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.3-2
for you to fetch changes up to
This tests clone3() with and without set_tid to see if all desired PIDs
are working as expected. The test tries to clone3() with a set_tid of
-1, 1, pid_max, a PID which is already in use and an unused PID. The
same tests are also running in PID namespace.
Signed-off-by: Adrian Reber
---
The main motivation to add set_tid to clone3() is CRIU.
To restore a process with the same PID/TID CRIU currently uses
/proc/sys/kernel/ns_last_pid. It writes the desired (PID - 1) to
ns_last_pid and then (quickly) does a clone(). This works most of the
time, but it is racy. It is also slow as it
On Thu, 8 Aug 2019 13:36:04 -0700 Roman Gushchin wrote:
> I've noticed that the "slab" value in memory.stat is sometimes 0,
> even if some children memory cgroups have a non-zero "slab" value.
> The following investigation showed that this is the result
> of the kmem_cache reparenting in
Neil Armstrong writes:
> The G12A/G12B Socs embeds a specific clock tree for each CPU cluster :
> cpu_clk / cpub_clk
> | \- cpu_clk_dyn
> | | \- cpu_clk_premux0
> | ||- cpu_clk_postmux0
> | |||- cpu_clk_dyn0_div
> | ||\-
On Thu, Aug 08, 2019 at 07:02:54PM +, Tao Ren wrote:
> Hi Andrew,
>
> On 8/8/19 6:32 AM, Andrew Lunn wrote:
> >> Let me prepare patch v2 using device tree. I'm not sure if standard
> >> "mac-address" fits this situation because all we need is an offset
> >> (integer) and BMC MAC is calculated
Hi Christophe,
On Thu, 2019-08-08 at 12:48 +, Christophe Leroy wrote:
> Santa commit ebb9d30a6a74 ("powerpc/mm: any thread in one core can be
> the first to setup TLB1") removed the need to know the cpu_id in
> early_init_this_mmu(), but the call to smp_processor_id() which was
> marked
Tom,
On Thu, 8 Aug 2019, Lendacky, Thomas wrote:
> On 8/8/19 3:36 PM, Thomas Gleixner wrote:
> > On Thu, 1 Aug 2019, Lendacky, Thomas wrote:
> >> On 8/1/19 5:13 AM, Thomas Gleixner wrote:
> >>>2.1.9 Timers
> >>>
> >>> Each core includes the following timers. These timers do not vary in
>
- base = ioremap((resource_size_t)addr, 0x1);
+ base = ioremap((resource_size_t)addr, 0x8000);
Changing one magic value for another. :-(
Do different BIOS do different things? I don't recall seeing this error
(but perhaps I missed it, or perhaps the kernel has
Hi Thomas,
On 8/8/19 3:36 PM, Thomas Gleixner wrote:
> Tom,
>
> On Thu, 1 Aug 2019, Lendacky, Thomas wrote:
>> On 8/1/19 5:13 AM, Thomas Gleixner wrote:
>>>2.1.9 Timers
>>>
>>> Each core includes the following timers. These timers do not vary in
>>> frequency regardless of the
Hi,
First thanks for posting this!
I ran this on our DAWN platform and it does what it says. Its a pretty
reasonable start, but I get -1's in the command row rather than "dd" (or
similar) and this also results in [unknown] for the shared object and
most userspace addresses. This is quite
The QBMan frame descriptor enqueuing is changed from array
mode (a single frame enqueue at a time) to bulk ring mode.
This new mode allows the enqueuing of multiple frames in one operation.
The original interface is kept but use the bulk enqueue of one frame
Signed-off-by: Youri Querry
---
On Thu, Aug 8, 2019 at 12:25 AM kernel test robot wrote:
>
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/gregkh/driver-core.git
> driver-core-testing
>
> commit
Quoting Sylwester Nawrocki (2019-08-08 07:49:29)
> This patch fixes broken sound on Exynos5422/5800 platforms after
> system/suspend resume cycle in cases where the audio root clock
> is derived from MAU_EPLL_CLK.
>
> In order to preserve state of the USER_MUX_MAU_EPLL_CLK clock mux
> during
BIOS has marked the 32K MCHBAR window as reserved, so when dnv_rd_reg()
tries to ioremap() a 64KB region you get warnings like:
resource sanity check: requesting [mem 0xfed1-0xfed1], which spans more
than reserved [mem 0xfed1-0xfed17fff]
caller dnv_rd_reg+0xc8/0x240 [pnd2_edac]
Hi Bjorn,
On Thu, 8 Aug 2019, Bjorn Helgaas wrote:
> On Thu, Jul 25, 2019 at 02:28:07PM -0700, Paul Walmsley wrote:
> > From: Wesley Terpstra
> >
> > This is part of adding support for RISC-V systems with PCIe host
> > controllers that support message-signaled interrupts.
> >
> >
On Thu, Aug 08, 2019 at 04:13:33PM -0400, Joel Fernandes wrote:
> On Thu, Aug 08, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 08, 2019 at 07:26:10PM +0900, Byungchul Park wrote:
> > > On Wed, Aug 07, 2019 at 05:45:04AM -0400, Joel Fernandes wrote:
> > > > On Tue, Aug 06, 2019
On Fri, Jul 26, 2019 at 03:48:47AM +0530, Amit Kucheria wrote:
> Register upper-lower interrupt for the tsens controller.
>
> Signed-off-by: Amit Kucheria
Tested-by: Brian Masney
On Fri, Jul 26, 2019 at 03:48:40AM +0530, Amit Kucheria wrote:
> msm8974 has 11 sensors connected to a single TSENS IP. Define a thermal
> zone for each of those sensors to expose the temperature of each zone.
>
> Signed-off-by: Amit Kucheria
Tested-by: Brian Masney # msm8974
On Thu, Aug 8, 2019 at 9:06 PM kbuild test robot wrote:
>
> tree:
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/arnd/playground.git
> randconfig-5.3-rc2
> head: bfe9aede7372c8310a9bf31963460c9dd11d1f82
> commit: 97919a3ec80e9841c4bbac14a80e8b9d482666d4 [32/347] [SUBMITTED
>
Hi,
David Miller writes:
> From: YueHaibing
> Date: Thu, 8 Aug 2019 22:26:23 +0800
>
>> net/sched/sch_taprio.c:680:32: warning:
>> entry_list_policy defined but not used [-Wunused-const-variable=]
>>
>> It is not used since commit a3d43c0d56f1 ("taprio: Add
>> support adding an admin
On Thu, Aug 8, 2019, 20:39 Bjorn Helgaas wrote:
>
> On Thu, Aug 08, 2019 at 04:47:45PM +0200, Rafael J. Wysocki wrote:
> > On Thu, Aug 8, 2019 at 3:43 PM Bjorn Helgaas wrote:
> > > On Thu, Aug 08, 2019 at 12:10:06PM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki
> > > >
> > > >
On Thu, Aug 8, 2019 at 9:53 PM Vaittinen, Matti
wrote:
> On Thu, 2019-08-08 at 10:29 +0800, Yuehaibing wrote:
> > On 2019/7/9 13:25, Vaittinen, Matti wrote:
> > > awkward at first sight but indeed - depends on BD70528_WATCHDOG
> > > disallows BD70528_WATCHDOG=m with RTC_DRV_BD70528=y while
> > >
On Thu, Aug 08, 2019 at 09:38:40PM +0200, Heiner Kallweit wrote:
> On 08.08.2019 14:30, Alexandru Ardelean wrote:
> > Down-speed auto-negotiation may not always be enabled, in which case the
> > PHY won't down-shift to 100 or 10 during auto-negotiation.
> >
> > This change enables downshift and
Tom,
On Thu, 1 Aug 2019, Lendacky, Thomas wrote:
> On 8/1/19 5:13 AM, Thomas Gleixner wrote:
> > 2.1.9 Timers
> >
> >Each core includes the following timers. These timers do not vary in
> >frequency regardless of the current P-state or C-state.
> >
> >* Core::X86::Msr::TSC; the
I've noticed that the "slab" value in memory.stat is sometimes 0,
even if some children memory cgroups have a non-zero "slab" value.
The following investigation showed that this is the result
of the kmem_cache reparenting in combination with the per-cpu
batching of slab vmstats.
At the offlining
On Wed, Aug 07, 2019 at 02:41:31PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 06, 2019 at 11:08:24AM -0700, Paul E. McKenney wrote:
> > On Mon, Aug 05, 2019 at 10:48:00AM -0700, Paul E. McKenney wrote:
> > > On Mon, Aug 05, 2019 at 05:50:24PM +0200, Peter Zijlstra wrote:
> > > > On Mon, Aug 05,
On Fri, Aug 02, 2019 at 06:33:28PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 02, 2019 at 06:20:15PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 02, 2019 at 02:33:41PM +, Lendacky, Thomas wrote:
>
> > > Talking to the hardware folks, they say setting CR8 is a serializing
> > > instruction
On Thu, Aug 08, 2019 at 10:01:39PM +0200, Heiner Kallweit wrote:
> On 08.08.2019 21:40, Andrew Lunn wrote:
> >> @@ -568,6 +568,11 @@ int phy_start_aneg(struct phy_device *phydev)
> >>if (err < 0)
> >>goto out_unlock;
> >>
> >> + /* The PHY may not yet have cleared aneg-completed
The patch
regulator: act8865: Fix build error without CONFIG_POWER_SUPPLY
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually
The patch
ASoC: tscs454: remove unused variable 'PLL_48K_RATE'
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
On 8/8/19 5:42 PM, Christoph Hellwig wrote:
The mm_walk structure currently mixed data and code. Split out the
operations vectors into a new mm_walk_ops structure, and while we
are changing the API also declare the mm_walk structure inside the
walk_page_range and walk_page_vma functions.
Based
The patch
regulator: slg51000: Fix a couple NULL vs IS_ERR() checks
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.3
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator: qcom-rpmh: Add support for SM8150
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: dt-bindings: Add PM8150x compatibles
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
Valdis,
On Thu, 8 Aug 2019, Valdis Klētnieks wrote:
> On Thu, 08 Aug 2019 22:04:03 +0200, Thomas Gleixner said:
>
> > I really appreciate your work, but can you please refrain from using file
> > names as prefixes?
>
> OK, will do so going forward..
Care to resend the last few with fixed
On Thu, 08 Aug 2019 22:04:03 +0200, Thomas Gleixner said:
> I really appreciate your work, but can you please refrain from using file
> names as prefixes?
OK, will do so going forward..
> > We get a warning when building with W=1:
>
> Please avoid 'We/I' in changelogs.
OK..
> > CC
Intel moved the PCS register from 0x92 to 0x94 on Denverton for some
reason, so now we get to check the device ID before poking it on reset.
Signed-off-by: Stephen Douthit
---
drivers/ata/ahci.c | 42 +++---
1 file changed, 39 insertions(+), 3 deletions(-)
Commit-ID: 8e6e5bea2e34c61291d00cb3f47560341aa84bc3
Gitweb: https://git.kernel.org/tip/8e6e5bea2e34c61291d00cb3f47560341aa84bc3
Author: Jin Yao
AuthorDate: Mon, 29 Jul 2019 15:27:55 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 8 Aug 2019 15:41:37 -0300
perf pmu-events:
Quoting Sylwester Nawrocki (2019-08-08 07:49:28)
> In order to make it easier in subsequent patch to create different subcmu
> lists for exynos5420 and exynos5800 SoCs the code is rewritten so we pass
> an array of pointers to the subcmus initialization function.
>
> Fixes: b06a532bf1fa ("clk:
On 8/8/19 1:40 PM, Mina Almasry wrote:
Problem:
Currently tasks attempting to allocate more hugetlb memory than is available get
a failure at mmap/shmget time. This is thanks to Hugetlbfs Reservations [1].
However, if a task attempts to allocate hugetlb memory only more than its
hugetlb_cgroup
Commit-ID: b9c0a64901d5bdec6eafd38d1dc8fa0e2974fccb
Gitweb: https://git.kernel.org/tip/b9c0a64901d5bdec6eafd38d1dc8fa0e2974fccb
Author: Thomas Richter
AuthorDate: Wed, 24 Jul 2019 14:27:03 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 8 Aug 2019 15:41:25 -0300
perf
Commit-ID: 12a6d2940b5f02b4b9f71ce098e3bb02bc24a9ea
Gitweb: https://git.kernel.org/tip/12a6d2940b5f02b4b9f71ce098e3bb02bc24a9ea
Author: Thomas Richter
AuthorDate: Wed, 24 Jul 2019 14:27:02 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 8 Aug 2019 15:41:11 -0300
perf
Commit-ID: fa37bab6d7154658d8a35920513f9396587754cc
Gitweb: https://git.kernel.org/tip/fa37bab6d7154658d8a35920513f9396587754cc
Author: Ian Rogers
AuthorDate: Wed, 31 Jul 2019 15:54:41 -0700
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 8 Aug 2019 15:41:11 -0300
perf tools: Fix
201 - 300 of 1111 matches
Mail list logo
