The atomic_long_cmpxchg_acquire() in rwsem_try_read_lock_unqueued() is
replaced by atomic_long_try_cmpxchg_acquire() to simpify the code and
generate slightly better assembly code. There is no functional change.
Signed-off-by: Waiman Long
Acked-by: Will Deacon
Acked-by: Davidlohr Bueso
---
Add lock event counting calls so that we can track the number of lock
events happening in the rwsem code.
With CONFIG_LOCK_EVENT_COUNTS on and booting a 4-socket 112-thread x86-64
system, the rwsem counts after system bootup were as follows:
rwsem_opt_fail=261
rwsem_opt_wlock=50636
The rwsem_down_read_failed*() functions were relocated from above the
optimistic spinning section to below that section. This enables the
reader functions to use optimisitic spinning in future patches. There
is no code change.
Signed-off-by: Waiman Long
Acked-by: Will Deacon
Acked-by: Davidlohr
We don't need to expose rwsem internal functions which are not supposed
to be called directly from other kernel code.
Signed-off-by: Waiman Long
Acked-by: Will Deacon
Acked-by: Davidlohr Bueso
---
include/linux/rwsem.h | 7 ---
kernel/locking/rwsem.h | 7 +++
2 files changed, 7
Currently, the DEBUG_RWSEMS_WARN_ON() macro just dumps a stack trace
when the rwsem isn't in the right state. It does not show the actual
states of the rwsem. This may not be that helpful in the debugging
process.
Enhance the DEBUG_RWSEMS_WARN_ON() macro to also show the current
content of the
On Thu, Apr 4, 2019 at 10:36 AM Guenter Roeck wrote:
>
> On Thu, Apr 4, 2019 at 10:11 AM Nick Crews wrote:
> >
> > We want all backlights for the system keyboard to
> > use a common name, so the name "platform::kbd_backlight"
> > would be better than the current "chromeos::kbd_backlight"
> >
On Tue, Apr 02, 2019 at 10:03:52PM +0200, Daniel Bristot de Oliveira wrote:
> Note: do not take it too seriously, it is just a proof of concept.
>
> Some time ago, while using perf to check the automaton model, I noticed
> that perf was losing events. The same was reproducible with ftrace.
>
>
On Thu, Apr 04, 2019 at 05:08:55PM +, Song Liu wrote:
>
>
> > On Apr 4, 2019, at 5:25 AM, Jiri Olsa wrote:
> >
> > On Thu, Apr 04, 2019 at 11:14:38AM +0200, Jiri Olsa wrote:
> >
> > SNIP
> >
> >> Program received signal SIGABRT, Aborted.
> >> 0x775e60f5 in raise () from
On Thu, Apr 4, 2019 at 10:11 AM Nick Crews wrote:
>
> We want all backlights for the system keyboard to
> use a common name, so the name "platform::kbd_backlight"
> would be better than the current "chromeos::kbd_backlight"
> name. Normally this wouldn't be worth changing, but the new
> Wilco
On Thu, Apr 04, 2019 at 04:16:57PM +, Slavomir Kaslev wrote:
> On Thu, 2019-04-04 at 10:45 +0200, Greg Kroah-Hartman wrote:
> > 5.0-stable review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > [ Upstream commit
Currently perf callchain is not working properly with ORC unwinder,
we'll get useless in kernel callchain like this:
perf 6429 [000]22.498450: kmem:mm_page_alloc: page=0x176a17
pfn=1534487 order=0 migratetype=0 gfp_flags=GFP_KERNEL
be23e32e
Signed-off-by: Michal Suchanek
---
drivers/dma/bcm2835-dma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index ec8a291d62ba..e38b19dd2895 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -891,7 +891,6 @@ static
Hi,
On 4/4/19 12:04 PM, Will Deacon wrote:
On Tue, Mar 26, 2019 at 05:39:38PM -0500, Jeremy Linton wrote:
Lets add the MODULE_TABLE and platform id_table entries so that
the SPE driver can attach to the ACPI platform device created by
the core pmu code.
Signed-off-by: Jeremy Linton
This patch ASV (Adaptive Supply Voltage) table entries for
Exynos5422/5800 SoC.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos5.dtsi| 2 +-
arch/arm/boot/dts/exynos5800.dtsi | 207 ++
2 files changed, 208 insertions(+), 1 deletion(-)
diff --git
Enable exynos-asv driver for Exynos 32-bit SoCs.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/mach-exynos/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index e3e63aa5d60a..fe306a85228c 100644
---
From: Pankaj Dubey
This patch enables exynos_chipid driver for ARCH_EXYNOS
based SoC.
Signed-off-by: Pankaj Dubey
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm64/Kconfig.platforms | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig.platforms
From: Pankaj Dubey
As now we have chipid driver to initialize SoC related information
let's include it in build by default.
Signed-off-by: Pankaj Dubey
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/mach-exynos/Kconfig | 1 +
1 file changed, 1
The Adaptive Supply Voltage (ASV) on Exynos SoCs is a technique of adjusting
operating points of devices in order to better match actual capabilities
of the hardware and optimize power consumption.
This patch adds common code for parsing the ASV tables from devicetree
and updating CPU OPPs.
Also
This patch adds documentation of the Exynos ASV (Adaptive Voltage Supply)
tables DT binding.
Signed-off-by: Sylwester Nawrocki
---
.../devicetree/bindings/arm/samsung/asv.txt | 76 +++
1 file changed, 76 insertions(+)
create mode 100644
The Adaptive Supply Voltage (ASV) on Exynos SoCs is a technique of adjusting
subsystem operating points, i.e. power supply voltage for given clock
frequency, in order to better match actual capabilities of the hardware
and optimize power consumption. This applies to subsystems of the SoC like:
This patch adds definition of selected CHIP ID register offsets
and register bit field definitions for Exynos5422 SoC.
exynos_chipid_read() helper function is added to allow reading
the CHIP ID block registers.
Signed-off-by: Sylwester Nawrocki
---
drivers/soc/samsung/exynos-chipid.c | 16
From: Pankaj Dubey
Exynos SoCs have Chipid, for identification of product IDs and SoC
revisions. This patch intends to provide initialization code for all
these functionalities, at the same time it provides some sysfs entries
for accessing these information to user-space.
This driver uses
> > >
> > > Do we need this change?
> > >
> > This patch does not tend to refactor the code. I have removed extra empty
> > lines because i touched the code around. I can either keep that change or
> > remove it. What is your opinion?
>
> Usually it's better to separate cosmetic changes from
Fix checkpatch error: "ERROR: space required after that close brace '}'".
Signed-off-by: Gabriel Siqueira
---
drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
This fixes the following warning seen on GCC 7.3:
arch/x86/kernel/dumpstack.o: warning: objtool: oops_end() falls through to
next function show_regs()
Reported-by: kbuild test robot
Signed-off-by: Josh Poimboeuf
---
tools/objtool/check.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Wed, Apr 03, 2019 at 03:29:17PM -0700, Randy Dunlap wrote:
> On 4/3/19 1:53 PM, Josh Poimboeuf wrote:
> > On Wed, Apr 03, 2019 at 08:02:43AM -0700, Randy Dunlap wrote:
> >> On 4/3/19 1:24 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20190402:
> >>>
> >>
> >> on x86_64:
>
On Thu, 4 Apr 2019, Jesse Hathaway wrote:
> On Tue, Apr 2, 2019 at 9:29 AM Alan Stern wrote:
> > Most likely the problem occurs somewhere inside
> > quirk_usb_handoff_xhci(). Can Jesse add debugging statements to that
> > routine in order to pin down exactly where the problem lies?
>
> Alan,
>
Hi Gerd.
On Thu, Apr 04, 2019 at 05:24:27PM +0200, Gerd Hoffmann wrote:
> Also rename to drm_fb_xrgb_to_rgb565().
> Pure code motion, no functional change.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Sam Ravnborg
We want all backlights for the system keyboard to
use a common name, so the name "platform::kbd_backlight"
would be better than the current "chromeos::kbd_backlight"
name. Normally this wouldn't be worth changing, but the new
Wilco keyboard backlight driver uses the "platform" name.
We want to
The EC is in charge of controlling the keyboard backlight on
the Wilco platform. We expose a standard LED class device at
/sys/class/leds/platform::kbd_backlight. This driver is modeled
after the standard Chrome OS keyboard backlight driver at
drivers/platform/chrome/cros_kbd_led_backlight.c
Some
The current API for the wilco EC mailbox interface is bad.
It assumes that most messages sent to the EC follow a similar structure,
with a command byte in MBOX[0], followed by a junk byte, followed by
actual data. This doesn't happen in several cases, such as setting the
RTC time, using the raw
> On Apr 4, 2019, at 5:25 AM, Jiri Olsa wrote:
>
> On Thu, Apr 04, 2019 at 11:14:38AM +0200, Jiri Olsa wrote:
>
> SNIP
>
>> Program received signal SIGABRT, Aborted.
>> 0x775e60f5 in raise () from /lib64/libc.so.6
>> Missing separate debuginfos, use: dnf debuginfo-install
>>
The per-CPU variable batched_entropy_uXX is protected by get_cpu_var().
This is just a preempt_disable() which ensures that the variable is only
protected against other CPUs. It does not protect against users from
interrupt context. It possible that a preemptible context read slot 0
and an
On Tue, Mar 26, 2019 at 05:39:38PM -0500, Jeremy Linton wrote:
> Lets add the MODULE_TABLE and platform id_table entries so that
> the SPE driver can attach to the ACPI platform device created by
> the core pmu code.
>
> Signed-off-by: Jeremy Linton
> Reviewed-by: Sudeep Holla
> ---
>
The device tree binding already lists compatible strings for H6
SoC, so add a device node for it.
Signed-off-by: Yangtao Li
---
fix typo:
iy->it
0x3006000->0x03006000
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git
Add SID's support for H6.
Yangtao Li (2):
nvmem: sunxi_sid: Support SID on H6
arm64: dts: sunxi: h6: Add device node for SID
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 5 +
drivers/nvmem/sunxi_sid.c| 6 ++
2 files changed, 11 insertions(+)
--
2.17.0
The device tree binding already lists compatible strings for H6
SoCs, so add a device node for iy.
Signed-off-by: Yangtao Li
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
Add support for H6's SID controller. It supports 4K-bit
EFUSE, bigger than before.
Signed-off-by: Yangtao Li
---
drivers/nvmem/sunxi_sid.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/nvmem/sunxi_sid.c b/drivers/nvmem/sunxi_sid.c
index 7013f9cc43c7..a079a80ddf2c 100644
---
> > On Apr 4, 2019, at 1:23 AM, Huang Shijie wrote:
> >
> >
> > + * This function is different from the get_user_pages_unlocked():
> > + * The @pages may has different page order with the result
> > + * got by get_user_pages_unlocked().
> > + *
>
> I suggest a slight rewrite of the
On Thu, Apr 04, 2019 at 05:43:20PM +0200, Uladzislau Rezki wrote:
> Hello, Roman!
>
> >
> > The patch looks really good to me! I've tried hard, but didn't find
> > any serious issues/bugs. Some small nits below.
> >
> > Thank you for working on it!
> >
> I try my best, thank you for your
On 04/04/2019 17:41, Guenter Roeck wrote:
On Fri, Apr 05, 2019 at 12:00:01AM +0800, John Garry wrote:
Currently when accessing logical indirect PIO addresses in
logic_{in, out}{,s}, we first ensure that the region is registered.
However, no such check exists for CPU MMIO regions. The CPU MMIO
On Mon, Apr 1, 2019 at 4:10 PM Jan Kotas wrote:
> During my regression testing I noticed the cadence GPIO driver
> fails on the latest gpio for-next tree.
>
> I think the reason is this patch:
> commit 96cd559817f2 ("Merge branch 'devel' into for-next")
>
> Here is a part of the test log:
>
>
On 04/04/2019 12:44 PM, Josh Poimboeuf wrote:
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users. It's getting more and more
> complicated to decide which mitigations are needed for a given
> architecture. Complicating matters
On 04.04.19 17:40, Oscar Salvador wrote:
> On Thu, Apr 04, 2019 at 04:47:43PM +0200, David Hildenbrand wrote:
>> On 04.04.19 15:25, Oscar Salvador wrote:
>>> On Thu, Apr 04, 2019 at 03:18:00PM +0200, David Hildenbrand wrote:
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index
On Thu, Apr 04, 2019 at 03:23:47PM +0800, Huang Shijie wrote:
> When CONFIG_HAVE_GENERIC_GUP is defined, the kernel will use its own
> get_user_pages_fast().
>
> In the following scenario, we will may meet the bug in the DMA case:
> .
>
On Sun, Mar 31, 2019 at 1:25 PM Rushikesh S Kadam
wrote:
>
> Add ChromeOS EC ISHTP driver.
>
> Sends host commands over ISHTP to ISH firmware.
>
> Signed-off-by: Rushikesh S Kadam
> ---
> drivers/platform/chrome/Kconfig | 13 +
> drivers/platform/chrome/Makefile| 1 +
>
On Thu, Apr 04, 2019 at 06:31:37PM +0200, Jann Horn wrote:
> Uuuh. I *definitely* tested this. I ran this yesterday evening on my
> home machine, on top of commit
> 14c741de93861749dfb60b4964028541f5c506ca from Linus' tree, plus two
> cherry-picked fixes for drm/ttm. I specifically made sure that
On Thu, Apr 04, 2019 at 12:37:18PM -0400, Vince Weaver wrote:
> On Thu, 4 Apr 2019, Cyrill Gorcunov wrote:
>
> > On Thu, Apr 04, 2019 at 09:25:47AM -0400, Vince Weaver wrote:
> > >
> > > It looks like there are at least two bugs here, one that's a full
> > > hardlockup with nothing on serial
Keeping track of the number of mitigations for all the CPU speculation
bugs has become overwhelming for many users. It's getting more and more
complicated to decide which mitigations are needed for a given
architecture. Complicating matters is the fact that each arch tends to
it own custom way
stable-rc/linux-4.9.y boot: 101 boots: 0 failed, 82 passed with 18 offline, 1
untried/unknown (v4.9.167-92-gea283005c82d)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.167-92-gea283005c82d/
Full Build Summary:
On Fri, Apr 05, 2019 at 12:00:01AM +0800, John Garry wrote:
> Currently when accessing logical indirect PIO addresses in
> logic_{in, out}{,s}, we first ensure that the region is registered.
>
> However, no such check exists for CPU MMIO regions. The CPU MMIO regions
> would be registered by the
On Thu, 4 Apr 2019, Vlastimil Babka wrote:
> Some debugging checks in SLUB are not hidden behind kmem_cache_debug() check.
> Add the check so that those places can also benefit from reduced overhead
> thanks to the the static key added by the previous patch.
Hmmm... I would not expect too much
Hi Akira,
On Fri, Apr 05, 2019 at 12:58:36AM +0900, Akira Yokosawa wrote:
> On Tue, 2 Apr 2019 14:03:46 +0100, Will Deacon wrote:
> > On Tue, Mar 26, 2019 at 04:41:16PM -0700, Paul E. McKenney wrote:
> >> From: Will Deacon
> >>
> >> The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt
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
> for judging the refault period of each page, which is not precised as
> eviction of other files will be affect a lot on current cache.
> We
On Thu, 4 Apr 2019, Cyrill Gorcunov wrote:
> On Thu, Apr 04, 2019 at 09:25:47AM -0400, Vince Weaver wrote:
> >
> > It looks like there are at least two bugs here, one that's a full
> > hardlockup with nothing on serial console. The other is the NULL
> > dereference.
OK, it turns out the
Microphone detection provides the button detection features on the
Arizona CODECs as such it will be running if the jack is currently
inserted. If the driver is unbound whilst the jack is still inserted
this will cause warnings from the regulator framework as the MICVDD
regulator is put but was
The mei/hdcp module have its own Makefile
so naturally it should have associated Kconfig
in the same directory.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/Kconfig | 10 +-
drivers/misc/mei/hdcp/Kconfig | 13 +
2 files changed, 14 insertions(+), 9 deletions(-)
On Thu, Apr 4, 2019 at 6:28 PM Borislav Petkov wrote:
>
> On Thu, Apr 04, 2019 at 01:11:28PM +0200, Jann Horn wrote:
> > This changes generic_load_microcode() to use the iov_iter API instead of
> > an open-coded version. This allows us to avoid explicitly casting between
> > user and kernel
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: 04 April 2019 16:47
> To: Shameerali Kolothum Thodi
> Cc: lorenzo.pieral...@arm.com; robin.mur...@arm.com;
> andrew.mur...@arm.com; jean-philippe.bruc...@arm.com;
> mark.rutl...@arm.com; Guohanjun (Hanjun
On 4/3/19 11:16 PM, Wolfram Sang wrote:
> On Wed, Apr 03, 2019 at 03:20:14PM -0700, Florian Fainelli wrote:
>> On 4/3/19 1:44 PM, Wolfram Sang wrote:
>>> On Tue, Apr 02, 2019 at 06:18:21PM -0700, Ray Jui wrote:
This patch series adds the following support to the iProc I2C driver:
-
On 4/2/19 6:18 PM, Ray Jui wrote:
> From: Rayagonda Kokatanur
>
> Add NIC i2c device node.
>
> Signed-off-by: Rayagonda Kokatanur
> Signed-off-by: Ray Jui
Applied to devicetree-arm64/next, thanks!
--
Florian
On Thu, Apr 04, 2019 at 01:11:28PM +0200, Jann Horn wrote:
> This changes generic_load_microcode() to use the iov_iter API instead of
> an open-coded version. This allows us to avoid explicitly casting between
> user and kernel pointers.
>
> Because the iov_iter API makes it hard to read the same
On Thu, Apr 04, 2019 at 01:01:07AM +0530, Nilesh Hase wrote:
> Signed-off-by: Nilesh Hase
> ---
> drivers/staging/mt7621-spi/spi-mt7621.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I can't take patches without any changelog content, sorry.
On Thu, 2019-04-04 at 10:45 +0200, Greg Kroah-Hartman wrote:
> 5.0-stable review patch. If anyone has any objections, please let me
> know.
>
> --
>
> [ Upstream commit ee5e001196d1345b8fee25925ff5f1d67936081e ]
>
> The current implementation of splice() and tee() ignores
Hello Xiang,
On 4/3/19 2:47 PM, xiang xiao wrote:
> On Thu, Mar 21, 2019 at 11:48 PM Fabien Dessenne
> wrote:
>>
>> This driver exposes a standard tty interface on top of the rpmsg
>> framework through the "rpmsg-tty-channel" rpmsg service.
>>
>> This driver supports multi-instances, offering
;
> Yeah, well, we not let the cros_kbd_led_backlight.c use chromeos:: in
> the first place. But it happened. We want all backlights for the
> system keyboard to use common name, and "chromeos" is not really
> suitable for that. "platform" is.
Pavel, who exactly wants
Signed-off-by: Nilesh Hase
---
drivers/staging/mt7621-spi/spi-mt7621.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
b/drivers/staging/mt7621-spi/spi-mt7621.c
index b509f9fe3346..6fa9876f5a92 100644
---
On Thu, Apr 4, 2019 at 5:51 PM Enrico Weigelt, metux IT consult
wrote:
> On 03.04.19 06:13, Linus Walleij wrote:
>
> > But the chardev on the other hand will protect you from all this.
> > If the program crashes, the lines will be free:ed.
> > If two scripts try to access the same GPIO, they will
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 over do_timer again temporarily or allowing nohz full
>>
On Thu, 4 Apr 2019, Paul E. McKenney wrote:
> On Mon, Apr 01, 2019 at 05:11:39PM -0400, Joel Fernandes wrote:
> > > > So I would have expected the following litmus to result in Never, but it
> > > > doesn't with Alan's patch:
> > > >
> > > > P0(int *x, int *y)
> > > > {
> > > > *x = 1;
Currently when accessing logical indirect PIO addresses in
logic_{in, out}{,s}, we first ensure that the region is registered.
However, no such check exists for CPU MMIO regions. The CPU MMIO regions
would be registered by the PCI host - when PCI_IOBASE is defined - in
pci_register_io_range().
Currently we only use logical PIO low-level accessors for when
CONFIG_INDIRECT_PIO is enabled.
Otherwise we just use inb/out et all directly.
It is useful to now use logical PIO accessors for all cases, so we can add
legality checks to accesses. Such a check would be for ensuring that the
PCI IO
Currently request_region() requests an IO port region directly from the
top resource, ioport_resource.
There is an issue here, in that drivers may successfully request an IO
port region even if the IO port region has not even been mapped in
(in pci_remap_iospace()).
This may lead to crashes when
A print in find_io_range() is for a hex number, but doesn't prefix "0x".
Add the prefix, as is the norm.
In the case of the print in logic_pio_trans_cpuaddr(), don't cast the
value to unsigned long long, and just print the resource_size_t type
directly.
Signed-off-by: John Garry
---
It was reported some time ago that arm64 systems will crash if a driver
attempts to access IO port addresses when the PCI IO port region has not
been mapped [1].
More recently, a similar crash is where the system PCI host probe fails,
and the IPMI driver crashes the system while attempting to do
Reviewed-by: Jett Rink
On Wed, Apr 3, 2019 at 4:40 PM wrote:
>
> From: Enrico Granata
>
> As new transfer mechanisms are added to the EC codebase, they may
> not support v2 of the EC protocol.
>
> If the v3 initial handshake transfer fails, the kernel will try
> and call cmd_xfer as a
Hi Will,
On Tue, 2 Apr 2019 14:03:46 +0100, Will Deacon wrote:
> On Tue, Mar 26, 2019 at 04:41:16PM -0700, Paul E. McKenney wrote:
>> From: Will Deacon
>>
>> The "KERNEL I/O BARRIER EFFECTS" section of memory-barriers.txt is vague,
>> x86-centric, out-of-date, incomplete and demonstrably
On Mon, Mar 18 2019 at 11:54 -0600, Marc Zyngier wrote:
On Wed, 13 Mar 2019 15:18:37 -0600
Lina Iyer wrote:
Please do Cc Rob when posting DT related patches.
Some interrupt controllers in a SoC, are always powered on and have a
select interrupts routed to them, so that they can wakeup the
On Thu, 4 Apr 2019, Vlastimil Babka wrote:
> I looked a bit at SLUB debugging capabilities and first thing I noticed is
> there's no static key guarding the runtime enablement as is common for similar
> debugging functionalities, so here's a RFC to add it. Can be further improved
> if there's
04.04.2019 18:32, Charles Keepax пишет:
> Lockdep reports the following issue on my setup:
>
> Possible unsafe locking scenario:
>
> CPU0CPU1
>
> lock((work_completion)(&(>disable_work)->work));
>
> > +#if DEBUG_AUGMENT_PROPAGATE_CHECK
> > +static void
> > +augment_tree_propagate_do_check(struct rb_node *n)
> > +{
> > + struct vmap_area *va;
> > + struct rb_node *node;
> > + unsigned long size;
> > + bool found = false;
> > +
> > + if (n == NULL)
> > + return;
> > +
> >
On Tue, Mar 26, 2019 at 03:17:53PM +, Shameer Kolothum wrote:
> HiSilicon erratum 162001800 describes the limitation of
> SMMUv3 PMCG implementation on HiSilicon Hip08 platforms.
>
> On these platforms, the PMCG event counter registers
> (SMMU_PMCG_EVCNTRn) are read only and as a result it
>
On Wed, 3 Apr 2019, Al Viro wrote:
> > This is an RFC and we want to know how to do this right.
>
> If by "how to do it right" you mean "expedit kicking out something with
> non-zero refcount" - there's no way to do that. Nothing even remotely
> sane.
Sure we know that.
> If you mean "kick out
Hello, Roman!
>
> The patch looks really good to me! I've tried hard, but didn't find
> any serious issues/bugs. Some small nits below.
>
> Thank you for working on it!
>
I try my best, thank you for your review!
> BTW, when sending a new iteration, please use "[PATCH vX]" subject prefix,
>
On Thu, Apr 04, 2019 at 04:47:43PM +0200, David Hildenbrand wrote:
> On 04.04.19 15:25, Oscar Salvador wrote:
> > On Thu, Apr 04, 2019 at 03:18:00PM +0200, David Hildenbrand wrote:
> >>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> >>> index f206b8b66af1..d8a3e9554aec 100644
> >>> ---
Lockdep reports the following issue on my setup:
Possible unsafe locking scenario:
CPU0CPU1
lock((work_completion)(&(>disable_work)->work));
lock(regulator_list_mutex);
On Tue, Mar 26, 2019 at 03:17:51PM +, Shameer Kolothum wrote:
> From: Neil Leeder
>
> Adds a new driver to support the SMMUv3 PMU and add it into the
> perf events framework.
>
> Each SMMU node may have multiple PMUs associated with it, each of
> which may support different events.
>
>
On Thu, Mar 21, 2019 at 10:09 PM Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warnings:
>
> drivers/pinctrl/pinctrl-artpec6.c:691:5: warning:
> symbol 'artpec6_pmx_enable' was not declared. Should it be static?
> drivers/pinctrl/pinctrl-artpec6.c:705:6: warning:
> symbol
The ASPEED AST2400, and AST2500 in some configurations include a
PCI-to-AHB MMIO bridge. This bridge allows a server to read and write
in the BMC's physical address space. This feature is especially useful
when using this bridge to send large files to the BMC.
The host may use this to send down
Document the ast2400, ast2500 PCI-to-AHB bridge control driver bindings.
Signed-off-by: Patrick Venture
Reviewed-by: Rob Herring
---
Changes for v9:
- Added missing details about syscon parent
Changes for v8:
- None
Changes for v7:
- Moved node under the syscon node it requires
Changes for v6:
On Mon, Apr 01, 2019 at 05:11:39PM -0400, Joel Fernandes wrote:
> Thanks a lot Alan and Paul for the replies. I replied inline.
>
> On Sun, Mar 31, 2019 at 02:55:31PM -0700, Paul E. McKenney wrote:
> > On Fri, Mar 29, 2019 at 10:36:39PM -0400, Joel Fernandes wrote:
> > > On Thu, Mar 28, 2019 at
On Thu, Apr 04, 2019 at 06:33:09PM +0530, Anshuman Khandual wrote:
> Sure. Will remove them from the proposed functions next time around.
Just need to make sure that the function is not calling directly or indirectly
another __meminit function, then it is safe to remove it.
E.g:
When the bootloader passes arguments to linux kernel through device tree,
it passes the address of initrd_start and initrd_stop, which are in kseg0.
But when linux kernel reads these addresses from device tree, it converts
them to virtual addresses inside the function
Dear Sir
We are interested in your product, please can you send us your product
clarification/specification and your price list it is a bulk order.
Mr. Kofi Quaye.
[Trim recipients to minimize noise]
On 01/02/2019 01:53, Sai Prakash Ranjan wrote:
> This patch series adds support for coresight on SDM845, MSM8998, and MSM8996.
>
> * Patch 1 adds device tree nodes for SDM845 coresight components.
>
> * Patch 2 adds device tree nodes for MSM8998 coresight
From: Sebastian Andrzej Siewior
> From: Andy Lutomirski [mailto:l...@kernel.org]
> Sent: 04 April 2019 15:27
>
> On Thu, Apr 4, 2019 at 7:14 AM Sebastian Andrzej Siewior
> wrote:
> >
> > On 2019-04-04 14:01:43 [+], David Laight wrote:
> > > From: Sebastian Andrzej Siewior
> > > > Sent: 03
Use regulator core's simplified DT parsing code to simply the driver
implementation.
Signed-off-by: Axel Lin
---
drivers/regulator/s2mpa01.c | 39 ++---
1 file changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/regulator/s2mpa01.c
Add compatible for the Amlogic G12B (S922X) SoC based Odroid-N2 SBC
from HardKernel.
Signed-off-by: Neil Armstrong
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/arm/amlogic.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
Add compatible for the Amlogic G12B SoC, sharing most of the
features and architecture with the G12A SoC.
Signed-off-by: Neil Armstrong
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/arm/amlogic.txt | 4
1 file changed, 4 insertions(+)
diff --git
This patch adds basic support for :
- Amlogic G12B, which is very similar to G12A
- The HardKernel Odroid-N2 based on the S922X SoC
The Amlogic G12B SoC is very similar with the G12A SoC, sharing
most of the features and architecture, but with these differences :
- The first CPU cluster only has
301 - 400 of 1406 matches
Mail list logo
