On Wed, Apr 3, 2019 at 2:52 AM Rushikesh S Kadam
wrote:
>
> Add ChromeOS EC ISHTP driver.
>
> Sends ChromeOS EC host commands over ISHTP to ISH firmware.
>
> Signed-off-by: Rushikesh S Kadam
> ---
>
> v2
> - Dropped unused "reset" parameter in function cros_ec_init()
> - Change driver name to
On Fri, Apr 05, 2019 at 07:23:46AM +0800, Zhaoyang Huang wrote:
> On Fri, Apr 5, 2019 at 12:39 AM Johannes Weiner wrote:
> >
> > On Thu, Apr 04, 2019 at 11:30:17AM +0800, Zhaoyang Huang wrote:
> > > From: Zhaoyang Huang
> > >
> > > In previous implementation, the number of refault pages is used
On Sun, 24 Feb 2019, Aubrey Li wrote:
> The architecture specific information of the running processes could
> be useful to the userland. Add support to examine process architecture
> specific information externally.
>
> Signed-off-by: Aubrey Li
> Cc: Peter Zijlstra
> Cc: Andi Kleen
> Cc: Tim
Use WARN_ON() instead of BUG_ON(), as the WARN_ON() produces a backtrace
without crashing the kernel.
Issue found by checkpatch.pl.
Signed-off-by: Madhumitha Prabakaran
---
drivers/staging/olpc_dcon/olpc_dcon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Apr 05, 2019 at 05:07:06PM +0200, Thomas Gleixner wrote:
> No point in retrieving the entry area pointer over and over. Do it once and
> use unsigned int for 'cpu' consistently.
>
> Signed-off-by: Thomas Gleixner
> ---
"consistent" might be a bit of a stretch for 'unsigned int cpu' vs
Because of writer lock stealing, it is possible that a constant
stream of incoming writers will cause a waiting writer or reader to
wait indefinitely leading to lock starvation.
The mutex code has a lock handoff mechanism to prevent lock starvation.
This patch implements a similar lock handoff
The upper bits of the count field is used as reader count. When
sufficient number of active readers are present, the most significant
bit will be set and the count becomes negative. If the number of active
readers keep on piling up, we may eventually overflow the reader counts.
This is not likely
Before combining owner and count, we are adding two new helpers for
accessing the owner value in the rwsem.
1) struct task_struct *rwsem_get_owner(struct rw_semaphore *sem)
2) bool is_rwsem_reader_owned(struct rw_semaphore *sem)
Signed-off-by: Waiman Long
---
kernel/locking/rwsem-xadd.c | 15
With separate count and owner, there are timing windows where the two
values are inconsistent. That can cause problem when trying to figure
out the exact state of the rwsem. For instance, a RT task will stop
optimistic spinning if the lock is acquired by a writer but the owner
field isn't set yet.
On 64-bit architectures, each rwsem writer will have its unique lock
word for acquiring the lock. Right now, the writer code recomputes the
lock word every time it tries to acquire the lock. This is a waste of
time. The lock word is now cached and reused when it is needed.
On 32-bit
When the rwsem is owned by reader, writers stop optimistic spinning
simply because there is no easy way to figure out if all the readers
are actively running or not. However, there are scenarios where
the readers are unlikely to sleep and optimistic spinning can help
performance.
This patch
This patch enables readers to optimistically spin on a
rwsem when it is owned by a writer instead of going to sleep
directly. The rwsem_can_spin_on_owner() function is extracted
out of rwsem_optimistic_spin() and is called directly by
__rwsem_down_read_failed_common() and
An RT task can do optimistic spinning only if the lock holder is
actually running. If the state of the lock holder isn't known, there
is a possibility that high priority of the RT task may block forward
progress of the lock holder if it happens to reside on the same CPU.
This will lead to
The current way of using various reader, writer and waiting biases
in the rwsem code are confusing and hard to understand. I have to
reread the rwsem count guide in the rwsem-xadd.c file from time to
time to remind myself how this whole thing works. It also makes the
rwsem code harder to be
v2:
- Move the negative reader count checking patch (patch 12->10)
forward to before the merge owner to count patch as suggested by
Linus & expand the comment.
- Change the reader-owned rwsem spinning from count based to time
based to have better control of the max time allowed.
When the front of the wait queue is a reader, other readers
immediately following the first reader will also be woken up at the
same time. However, if there is a writer in between. Those readers
behind the writer will not be woken up.
Because of optimistic spinning, the lock acquisition order is
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can help performance by avoiding
spinning on the
This patch modifies rwsem_spin_on_owner() to return four possible
values to better reflect the state of lock holder which enables us to
make a better decision of what to do next.
In the special case that there is no active lock and the handoff bit
is set, optimistic spinning has to be stopped.
On Tue, 26 Mar 2019, Zhao Yakui wrote:
> When acrn_hypervisor is detected, the hypercall is needed so that the
> acrn guest can query/config some settings. For example: it can be used
> to query the resources in hypervisor and manage the CPU/memory/device/
> interrupt for Guest system.
>
> So
Thanks Andy! I'll address the comments in v14.
Some question for the comment below:
> > + size = vring_size(vring->num, vring->align);
> > + va = dma_alloc_coherent(dev->parent, size, ,
> > GFP_KERNEL);
> > + if (!va) {
>
> > +
On Tue, 26 Mar 2019, Zhao Yakui wrote:
> diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
> index d9069bb..a8f4d08 100644
> --- a/arch/x86/include/asm/hardirq.h
> +++ b/arch/x86/include/asm/hardirq.h
> @@ -37,7 +37,8 @@ typedef struct {
> #ifdef CONFIG_X86_MCE_AMD
>
Zhao,
On Tue, 26 Mar 2019, Zhao Yakui wrote:
Vs. the Subject line: arch/x86: add the support of ACRN guest
The proper prefix for x86 is surprisingly 'x86:' not 'arch/x86:'. Also
please start the first word after the colon with an upper case letter.
> ACRN is one open-source hypervisour, which
On Fri, Apr 05, 2019 at 05:07:05PM +0200, Thomas Gleixner wrote:
> The defines for the exception stack (IST) array in the TSS are using the
> SDM convention IST1 - IST7. That causes all sorts of code to subtract 1 for
> array indices related to IST. That's confusing at best and does not provide
>
On Fri, Apr 05, 2019 at 01:23:51AM +0530, Vidya Sagar wrote:
> On 4/3/2019 11:06 PM, Bjorn Helgaas wrote:
> > On Wed, Apr 03, 2019 at 03:13:09PM +0530, Vidya Sagar wrote:
> > > On 4/3/2019 12:01 AM, Bjorn Helgaas wrote:
> > > > On Tue, Apr 02, 2019 at 12:47:48PM +0530, Vidya Sagar wrote:
> > > > >
On Sat, Apr 6, 2019 at 1:27 AM Josh Poimboeuf wrote:
>
> On Sat, Apr 06, 2019 at 01:05:55AM +0800, Kairui Song wrote:
> > On Sat, Apr 6, 2019 at 12:57 AM Josh Poimboeuf wrote:
> > >
> > > On Fri, Apr 05, 2019 at 11:13:02PM +0800, Kairui Song wrote:
> > > > Hi Josh, thanks for the review, I tried
Len,
On Fri, 5 Apr 2019, Brown, Len wrote:
> > please add a new helper function topology_max_dies() and retrieve it from
> > that.
>
> I'll do this for Rui -- since his patch is in my x86 branch,
> and it is already (very early) Saturday morning for him:-)
>
> FYI, there were a couple of other
On 25/03/19 19:47, David Rientjes wrote:
> This ensures that the address and length provided to DBG_DECRYPT and
> DBG_ENCRYPT do not cause an overflow.
>
> At the same time, pass the actual number of pages pinned in memory to
> sev_unpin_memory() as a cleanup.
>
> Reported-by: Cfir Cohen
>
On 19/03/19 23:19, David Rientjes wrote:
> get_num_contig_pages() could potentially overflow int so make its type
> consistent with its usage.
>
> Reported-by: Cfir Cohen
> Signed-off-by: David Rientjes
> ---
> arch/x86/kvm/svm.c | 10 +-
> 1 file changed, 5 insertions(+), 5
> please add a new helper function topology_max_dies() and retrieve it from
> that.
I'll do this for Rui -- since his patch is in my x86 branch,
and it is already (very early) Saturday morning for him:-)
FYI, there were a couple of other small changes I made to that branch
in response to list
On Thu, Apr 4, 2019 at 2:12 AM Daniel Lezcano wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > Expose thermal readings as a HWMON device, so that it could be
> > accessed using lm-sensors.
> >
> > Signed-off-by: Andrey Smirnov
> > Cc: Chris Healy
> > Cc: Lucas Stach
> > Cc: Zhang Rui
On Thu, 7 Mar 2019, Morten Rasmussen wrote:
> On Tue, Feb 26, 2019 at 07:53:58PM +0100, Peter Zijlstra wrote:
> > On Tue, Feb 26, 2019 at 01:19:58AM -0500, Len Brown wrote:
> > > Added sysfs core_threads, core_threads_list
> > >
> > > Added this attribute to show which threads siblings in a
On Tue, 26 Feb 2019, Len Brown wrote:
> This patch series does 4 things.
>
> 1. Parses the new CPUID.1F leaf to discover multi-die/package topology
>
> 2. Export multi-die topology inside the kernel
>
> 3. Update 3 places (coretemp, pkgtemp, rapl) that that need to know
>the difference
On Thu, Apr 04, 2019 at 10:45:00AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.0.7 release.
> There are 246 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
On Thu, Apr 04, 2019 at 10:45:37AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.34 release.
> There are 187 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
On Thu, Apr 04, 2019 at 10:46:28AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.111 release.
> There are 121 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
On Thu, Apr 4, 2019 at 2:05 AM Daniel Lezcano wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > Before returning measured temperature data to upper layer we need to
> > make sure that the reading was marked as "valid" to avoid reporting
> > bogus data.
>
> Is it possible to add a comment
On Thu, Apr 04, 2019 at 10:46:44AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.168 release.
> There are 91 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, 26 Feb 2019, Len Brown wrote:
> static int __init pkg_temp_thermal_init(void)
> {
> int ret;
> + struct cpuinfo_x86 *c = _data(0);
>
> if (!x86_match_cpu(pkg_temp_thermal_ids))
> return -ENODEV;
>
> - max_packages = topology_max_packages();
> +
On 05/04/2019 19:14, Leonidas P. Papadakos wrote:
Seems like snps,txpbl = <0x20> gives me better performance
What's your overall setup? So far with my RK3328 box I've found that
with an IPv4 link and an MTU of 2000 I have to dial PBL right down to 1
or 2 (with no-pbl-x8 as well) to prevent
On Fri, Apr 05, 2019 at 01:06:15PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 05, 2019 at 09:10:27AM +0100, John Garry wrote:
> > On 04/04/2019 19:58, Bjorn Helgaas wrote:
> > > On Thu, Apr 04, 2019 at 10:43:36AM -0700, Guenter Roeck wrote:
> > > > On Thu, Apr 04, 2019 at 05:52:35PM +0100, John
On Tue, 26 Feb 2019, Len Brown wrote:
> From: Zhang Rui
>
> On the new dual-die/package systems, the RAPL MSR becomes die-scope.
> Thus instead of one powercap device per physical package, now there
> should be one powercap device for each unique die on these systems.
>
> This patch introduces
On Thu, Apr 4, 2019 at 1:47 AM Daniel Lezcano wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > Convert driver to use regmap API, drop custom LE/BE IO helpers and
> > simplify bit manipulation using regmap_update_bits(). This also allows
> > us to convert some register initialization to
On Thu, Apr 4, 2019 at 1:23 AM Daniel Lezcano wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > Convert driver to use devm_ioremap() to simplify memory deallocation
> > and error handling code. No functional change intended.
> >
> > Signed-off-by: Andrey Smirnov
> > Cc: Chris Healy
> >
On Fri, Apr 05, 2019 at 09:10:27AM +0100, John Garry wrote:
> On 04/04/2019 19:58, Bjorn Helgaas wrote:
> > On Thu, Apr 04, 2019 at 10:43:36AM -0700, Guenter Roeck wrote:
> > > On Thu, Apr 04, 2019 at 05:52:35PM +0100, John Garry wrote:
> > > > > > Note that the f71805f driver does not call
> > >
On Thu, Apr 4, 2019 at 1:12 AM Daniel Lezcano wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > We can simplify error cleanup code if instead of passing a "struct
> > platform_device *" to qoriq_tmu_calibration() and deriving a bunch of
> > pointers from it, we pass those pointers
Hi all,
Friendly ping:
Who can take this?
Thanks
--
Gustavo
On 3/20/19 7:15 PM, Gustavo A. R. Silva wrote:
>
>
> On 3/20/19 7:12 PM, Guenter Roeck wrote:
>> On 3/20/19 11:16 AM, Gustavo A. R. Silva wrote:
>>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>>> cases where we
On Thu, Apr 4, 2019 at 12:57 AM Daniel Lezcano
wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > Embed per-sensor data into struct qoriq_tmu_data so we can drop the
> > code allocating it. This also allows us to get rid of per-sensor back
> > reference to struct qoriq_tmu_data since now
On 04/02/2019 10:01 PM, Guenter Roeck wrote:
> Use devm_platform_ioremap_resource to reduce source code size,
> improve readability, and reduce the likelyhood of bugs.
>
> The conversion was done automatically with coccinelle using the
> following semantic patch.
>
> @r@
> identifier res, pdev;
On Wed, Apr 3, 2019 at 8:28 PM Daniel Lezcano wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > Add local struct qoriq_sensor pointer in qoriq_tmu_register_tmu_zone()
> > for brevity.
> >
> > Signed-off-by: Andrey Smirnov
> > Cc: Chris Healy
> > Cc: Lucas Stach
> > Cc: Zhang Rui
> >
On Fri, 5 Apr 2019, Nicholas Piggin wrote:
> Thomas Gleixner's on April 5, 2019 12:36 am:
> > On Thu, 4 Apr 2019, Nicholas Piggin wrote:
> >
> >> I've been looking at ways to fix suspend breakage with CPU0 as a
> >> nohz CPU. I started looking at various things like allowing CPU0
> >> to take
On Fri, Apr 5, 2019 at 12:28 AM Rajneesh Bhardwaj
wrote:
>
> On Mon, Apr 01, 2019 at 11:05:04AM -0700, Evan Green wrote:
> > The PMC driver performs a 32-bit read on the sleep s0 residency counter,
> > followed by a hard-coded multiplication to convert into microseconds.
> > The maximum value
On Wed, Apr 3, 2019 at 8:21 PM Daniel Lezcano wrote:
>
> On 01/04/2019 06:14, Andrey Smirnov wrote:
> > This driver is meant to be used with Device Tree and there's no
> > use-case where device's DT node is going to be NULL. Remove code
> > protecting against that.
>
> May be elaborate why is
Freezer.c will contain an implementation of cgroup v2 freezer,
so let's rename the v1 freezer to avoid naming conflicts.
Signed-off-by: Roman Gushchin
Cc: Tejun Heo
Cc: kernel-t...@fb.com
---
kernel/cgroup/Makefile| 2 +-
kernel/cgroup/{freezer.c => legacy_freezer.c} |
If the cgroup destruction races with an exit() of a belonging
process(es), cg_kill_all() may fail. It's not a good reason to make
cg_destroy() fail and leave the cgroup in place, potentially causing
next test runs to fail.
Signed-off-by: Roman Gushchin
Cc: Shuah Khan
Cc: Tejun Heo
Cc:
The number of descendant cgroups and the number of dying
descendant cgroups are currently synchronized using the cgroup_mutex.
The number of descendant cgroups will be required by the cgroup v2
freezer, which will use it to determine if a cgroup is frozen
(depending on total number of descendants
The helper is identical to the existing cgroup_task_count()
except it doesn't take the css_set_lock by itself, assuming
that the caller does.
Also, move cgroup_task_count() implementation into
kernel/cgroup/cgroup.c, as there is nothing specific to cgroup v1.
Signed-off-by: Roman Gushchin
Cc:
Add cgroup:cgroup_freeze and cgroup:cgroup_unfreeze events,
which are using the existing cgroup tracing infrastructure.
Add the cgroup_event event class, which is similar to the cgroup
class, but contains an additional integer field to store a new
value (the level field is dropped).
Also add two
This patch implements 9 tests for the freezer controller for
cgroup v2:
1) a simple test, which aims to freeze and unfreeze a cgroup with 100
processes
2) a more complicated tree test, which creates a hierarchy of cgroups,
puts some processes in some cgroups, and tries to freeze and unfreeze
To use the TRACE_CGROUP_PATH() macro with css_set_lock
locked, let's make the macro irq-safe.
It's necessary in order to trace cgroup freezer state
transitions (frozen/not frozen), which are happening
with css_set_lock locked.
Signed-off-by: Roman Gushchin
---
kernel/cgroup/cgroup-internal.h |
Cgroup v1 implements the freezer controller, which provides an ability
to stop the workload in a cgroup and temporarily free up some
resources (cpu, io, network bandwidth and, potentially, memory)
for some other tasks. Cgroup v2 lacks this functionality.
This patch implements freezer for cgroup
On Fri, 5 Apr 2019, Josh Poimboeuf wrote:
> On Fri, Apr 05, 2019 at 09:37:27AM -0700, Sean Christopherson wrote:
> > On Fri, Apr 05, 2019 at 05:07:01PM +0200, Thomas Gleixner wrote:
> > > - irq_stack_top = (u64)this_cpu_ptr(irq_stack_union.irq_stack) +
> > > - STACK_TOP_MARGIN;
> >
This patchset implements freezer for cgroup v2.
It provides similar functionality as v1 freezer, but the interface
conforms to the cgroup v2 interface design principles, and it
provides a better user experience: tasks can be killed, ptrace works,
there is no separate controller, which has to be
Support Fingerprint MCU as a special of CrOS EC devices. The current FP
MCU uses the same EC SPI protocol v3 as other CrOS EC devices on a SPI
bus.
When a MCU has fingerprint support (aka EC_FEATURE_FINGERPRINT), it is
instantiated as a special CrOS EC device with device name 'cros_fp'. So
From: Rushikesh S Kadam
Integrated Sensor Hub (ISH) is also a MCU running EC
having feature bit EC_FEATURE_ISH. Instantiate it as
a special CrOS EC device with device name 'cros_ish'.
Signed-off-by: Rushikesh S Kadam
Reviewed-by: Gwendal Grignou
Reviewed-by: Andy Shevchenko
Signed-off-by:
Update the feature enum for the Chromebook Embedded Controller to the
latest version. Some of these enums are still not used in the kernel but
we might be also interested on have these enums up to date. Userspace
can use them to query the features to the EC via the cros-ec character
device.
While
Support Touchpad MCU as a special of CrOS EC devices. The current
Touchpad MCU is used on Eve Chromebook and used the same protocol as
other CrOS EC devices.
When a MCU has touchpad support (aka EC_FEATURE_TOUCHPAD), it is
instantiated as a special CrOS EC device with device name 'cros_tp'. So
Hi Lee,
The reason I'm sending this patch series is to clarify the build
dependencies of the following patches:
[PATCH 1/2] mfd: cros_ec: instantiate properly CrOS FP MCU device
[PATCH 2/2] mfd: cros_ec: instantiate properly CrOS Touchpad MCU device
and I also included this patch in the series:
Propagate existing bitmap_parselist() tests to bitmap_parselist_user().
Signed-off-by: Yury Norov
Reviewed-by: Andy Shevchenko
---
lib/test_bitmap.c | 46 --
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/lib/test_bitmap.c
Remove __bitmap_parselist helper and split the function to logical
parts.
Signed-off-by: Yury Norov
---
lib/bitmap.c | 258 +--
1 file changed, 145 insertions(+), 113 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index
test_bitmap_parselist currently uses get_cycles which is not
implemented on some platforms, so use ktime_get() instead.
Signed-off-by: Yury Norov
Reviewed-by: Andy Shevchenko
---
lib/test_bitmap.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/test_bitmap.c
Add tests for non-number character, empty regions, integer overflow.
Signed-off-by: Yury Norov
Reviewed-by: Andy Shevchenko
---
lib/test_bitmap.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index
Currently we parse user data byte after byte which leads to
overcomplification of parsing algorithm. The only user of
bitmap_parselist_user() is not performance-critical, and so we
can duplicate user data to kernel buffer and simply call
bitmap_parselist(). This rework lets us unify and simplify
bitmap_parselist has been evolved from a pretty simple idea for long and
now lacks for refactoring. It is not structured, has nested loops and a
set of opaque-named variables.
Things are more complicated because bitmap_parselist() is a part of user
interface, and its behavior should not change.
Add a node for reset controller IP block found on i.MX8MQ.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Reviewed-by: Fabio Estevam
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: Chris Healy
Cc: Lucas Stach
Cc: Leonard Crestez
Cc: "A.s. Dong"
Cc: Richard Zhu
Cc: linux-...@nxp.com
Cc:
Everyone:
This series contains all of the i.MX Device Tree changes I made to
enable support of PCIe on i.MX8MQ EVK.
Feedback is welcome!
Changes since [v4]:
- Fixed "src" -> "reset-controller" in "arm64: dts: imx8mq: Add a
node for SRC IP block"
- Collected Reviewed-by for
Add nodes for two PCIe controllers found on i.MX8MQ.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Reviewed-by: Fabio Estevam
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: Chris Healy
Cc: Lucas Stach
Cc: Leonard Crestez
Cc: "A.s. Dong"
Cc: Richard Zhu
Cc: linux-...@nxp.com
Cc:
Mark iomuxc_gpr as compatible with "fsl,imx6q-iomuxc-gpr" in order for
to allow i.MX6 PCIe driver to use it.
Signed-off-by: Andrey Smirnov
Acked-by: Lucas Stach
Reviewed-by: Fabio Estevam
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: Chris Healy
Cc: Lucas Stach
Cc: Leonard Crestez
Cc: "A.s. Dong"
Enable PCIE0 interface connected to BCM4356 WiFi/Bluetooth module.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Reviewed-by: Fabio Estevam
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: Chris Healy
Cc: Lucas Stach
Cc: Leonard Crestez
Cc: "A.s. Dong"
Cc: Richard Zhu
Cc: linux-...@nxp.com
According to NXP's FAE feedback and a comment in ATF firmware, PCIE1
and PCIE2 power domains can't really be used independently. Due to
shared reset line both power domains have to be turned on at the same
time. Account for that quirk by combining PCIE power domains into a
single 'pgc_pcie' power
On Sat, Apr 06, 2019 at 01:05:55AM +0800, Kairui Song wrote:
> On Sat, Apr 6, 2019 at 12:57 AM Josh Poimboeuf wrote:
> >
> > On Fri, Apr 05, 2019 at 11:13:02PM +0800, Kairui Song wrote:
> > > Hi Josh, thanks for the review, I tried again, using latest upstream
> > > kernel commit
On Wed, Mar 27, 2019 at 11:12 PM Uwe Kleine-König
wrote:
> It happened a few times to me since this patch was merged (in 4.4-rc1)
> that I worked on a system with tracing enabled but
> /sys/kernel/debug/tracing/events/gpio were missing because of
> CONFIG_TRACING_EVENTS_GPIO=n. This is annoying
On Fri, 5 Apr 2019, Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 10:03:13AM +0800, Baoquan He wrote:
> > In memory region KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate
>
> What is "memory region KASLR"?
>
> > the initial size of the direct mapping region. This is correct in
> > the old
On Fri, Apr 05, 2019 at 05:17:15PM +, David Laight wrote:
> > Hm, I don't see that in cmd_objtool, or any commits from you in
> > scripts/Makefile.build.
>
> Not sure I remember actually committing them.
> Maybe 'git diff' isn't doing what I expect :-)
> I hate git.
Do you see it here?
>> Infrequent page list update problem
>>
>>
>> Current page lists are updated by calling shrink_list() when memory pressure
>> comes, which might not be frequent enough to keep track of hot and cold
>> pages.
>> Because all pages are on active lists at the first time shrink_list() is
>>
On Fri, Apr 05, 2019 at 09:37:27AM -0700, Sean Christopherson wrote:
> On Fri, Apr 05, 2019 at 05:07:01PM +0200, Thomas Gleixner wrote:
> > From: Andy Lutomirski
> >
> > stack_overflow_check() is using both irq_stack_ptr and irq_stack_union to
> > find the IRQ stack. That's going to break when
On Wed, Apr 3, 2019 at 8:27 AM Matthew Wilcox wrote:
>
> On Tue, Apr 02, 2019 at 10:09:56AM +0700, tr...@android.com wrote:
> > From: Tri Vo
> >
> > Fixes: 8c3d220cb6b5 ("gcov: clang support")
>
> I think this is the wrong fix. Why not simply:
I spoke with Tri quickly about this proposal and
Hi Linus,
Please pull the arm64 fix below.
The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6:
Linux 5.1-rc3 (2019-03-31 14:39:29 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to
> Hm, I don't see that in cmd_objtool, or any commits from you in
> scripts/Makefile.build.
Not sure I remember actually committing them.
Maybe 'git diff' isn't doing what I expect :-)
I hate git.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
On Fri, Apr 05, 2019 at 04:35:50PM +, David Laight wrote:
> From: Josh Poimboeuf
> > Sent: 05 April 2019 17:21
> ..
> > > FWIW I had to update libelf.so from version 0.153 to 0.165 in
> > > order for the amd64 orc unwinder code in objtool to not generate
> > > corrupt output files.
> > > That
On Sat, Apr 6, 2019 at 12:57 AM Josh Poimboeuf wrote:
>
> On Fri, Apr 05, 2019 at 11:13:02PM +0800, Kairui Song wrote:
> > Hi Josh, thanks for the review, I tried again, using latest upstream
> > kernel commit ea2cec24c8d429ee6f99040e4eb6c7ad627fe777:
> > # uname -a
> > Linux
On 02/04/2019 09:43, Daniel Walter wrote:
Return error instead of trying to unlock a mutex that is not hold.
Signed-off-by: Daniel Walter
---
arch/um/drivers/ubd_kern.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/um/drivers/ubd_kern.c
On Fri, Apr 5, 2019 at 12:13 AM Peter Zijlstra wrote:
>
> On Thu, Apr 04, 2019 at 11:32:19AM -0700, Stephane Eranian wrote:
> > diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> > index a4b7711ef0ee..8d356c2096bc 100644
> > --- a/arch/x86/events/intel/core.c
> > +++
On Thu, Apr 04, 2019 at 10:03:13AM +0800, Baoquan He wrote:
> In memory region KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate
What is "memory region KASLR"?
> the initial size of the direct mapping region. This is correct in
> the old code where __PHYSICAL_MASK_SHIFT was equal to
On Fri, Apr 05, 2019 at 11:13:02PM +0800, Kairui Song wrote:
> Hi Josh, thanks for the review, I tried again, using latest upstream
> kernel commit ea2cec24c8d429ee6f99040e4eb6c7ad627fe777:
> # uname -a
> Linux localhost.localdomain 5.1.0-rc3+ #29 SMP Fri Apr 5 22:53:05 CST
> 2019 x86_64 x86_64
On Fri, Apr 05, 2019 at 05:07:02PM +0200, Thomas Gleixner wrote:
> On x86 stacks go top to bottom, but the stack overflow check uses it the
> other way round, which is just confusing. Clean it up and sanitize the
> warning string a bit.
>
> Signed-off-by: Thomas Gleixner
> ---
Reviewed-by: Sean
On Fri, Apr 5, 2019 at 9:11 AM Kees Cook wrote:
>
> On Fri, Apr 5, 2019 at 3:17 AM Masahiro Yamada
> wrote:
> > I want to propose alternative solution.
> > Please check the attached patches.
```
My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption.
```
I agree with
Broadcom's Brahma-B53 CPUs support the same type of events that the
Cortex-A53 supports, recognize its CPUID and map it to the cortex-a53
events.
Signed-off-by: Florian Fainelli
---
tools/perf/pmu-events/arch/arm64/mapfile.csv | 1 +
1 file changed, 1 insertion(+)
diff --git
Jeffrin Jose T wrote:
> A test for the basic NAT functionality uses ip command which
> needs veth device.There is a condition where the kernel support
> for veth is not compiled into the kernel and the test script
> breaks.This patch contains code for reasonable error display
> and correct code
On Mon, Apr 01, 2019 at 10:12:01PM +0200, Michal Hocko wrote:
> On Fri 29-03-19 16:16:38, Catalin Marinas wrote:
> > On Fri, Mar 29, 2019 at 01:02:37PM +0100, Michal Hocko wrote:
> > > On Thu 28-03-19 14:59:17, Catalin Marinas wrote:
> > > [...]
> > > > >From
On Fri, Apr 05, 2019 at 09:37:27AM -0700, Sean Christopherson wrote:
> On Fri, Apr 05, 2019 at 05:07:01PM +0200, Thomas Gleixner wrote:
> > From: Andy Lutomirski
> >
> > stack_overflow_check() is using both irq_stack_ptr and irq_stack_union to
> > find the IRQ stack. That's going to break when
101 - 200 of 587 matches
Mail list logo
