When pmu::setup_aux() is called the coresight PMU needs to know which
sink to use for the session by looking up the information in the
drv_config field of the hw_perf_event structure.
As such simply replace the cpu information by the complete perf_event
structure and change all affected customers.
This patch adds the mechanic needed for user space to send PMU specific
configuration to the kernel driver using an ioctl() command. That way
events can keep track of options that don't fit in the perf_event_attr
structure like the selection of a CoreSight sink to use for the session.
Signed-off-
Hi Bjorn,
Commits
27a6c9ebf29b ("PCI: v3-semi: Fix I/O space page leak")
db2aff16ea70 ("PCI: mediatek: Fix I/O space page leak")
52022fc6f6ad ("PCI: faraday: Fix I/O space page leak")
a9c0419ec92f ("PCI: aardvark: Fix I/O space page leak")
45cb32b4e8ea ("PCI: designware: Fix I/O space p
On HWP platforms with Turbo 3.0, the HWP capability max ratio shows the
maximum ratio of that core, which can be different than other cores. If
we show the correct maximum frequency in cpufreq sysfs via
cpuinfo_max_freq and scaling_max_freq then, user can know which cores
can run faster for pinning
[+cc Mike (hfi1)]
On Mon, Jul 16, 2018 at 10:28:35PM +, alex_gagn...@dellteam.com wrote:
> On 7/16/2018 4:17 PM, Bjorn Helgaas wrote:
> >> ...
> >> The easiest way to detect this is with pcie_print_link_status(),
> >> since the bottleneck is usually the link that is downtrained. It's not
> >>
On Fri, 6 Jul 2018 13:21:59 +0530
Abhishek Sahu wrote:
> Driver does not send the commands to NAND device for page
> read/write operations in ->cmdfunc(). It just does some
> minor variable initialization and rest of the things
> are being done in actual ->read/write_oob[_raw].
>
> The generic
On Tue, Jul 17, 2018 at 12:03:47PM +0200, Peter Zijlstra wrote:
> This is still a scary amount of accounting; not to mention you'll be
> adding O(cgroup-depth) to this in a later patch.
>
> Where are the performance numbers for all this?
I benchmarked it using our two most scheduling sensitive wo
Hi Jiri,
As far as I know, once you go into annotate mode, via perf report TUI
mode, the percentage you see per instruction is relative to the
function. I would like the option to display the total percentage,
i..e, the importance of the instruction for the entire run. Right now,
if I want that, I
On Wed, 2018-07-18 at 14:42 -0700, Andrew Morton wrote:
> On Wed, 18 Jul 2018 16:52:54 +0200 Geert Uytterhoeven
> wrote:
>
> > As PERL uses its own internal character encoding, always calling
> > encode("utf8", ...) on the author name may cause corruption, leading to
> > an author signoff mismat
On Wed, 18 Jul 2018 06:57:50 +0900,
Stephen Rothwell wrote:
>
> [1 ]
> Hi Yoshinori,
>
> On Tue, 17 Jul 2018 17:42:35 +0900 Yoshinori Sato
> wrote:
> >
> > On Tue, 17 Jul 2018 04:24:19 +0900, Stephen Rothwell wrote:
> > >
> > > Commit
> > >
> > > 39f077046d46 ("h8300: switch to NO_BOOTMEM"
On Tue, Jul 17, 2018 at 04:16:14PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> > +/* Tracked task states */
> > +enum psi_task_count {
> > + NR_RUNNING,
> > + NR_IOWAIT,
> > + NR_MEMSTALL,
> > + NR_PSI_TASK_COUNTS,
> > +};
>
> > +/* Res
On Tue, Jul 17, 2018 at 04:21:57PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> > diff --git a/include/linux/sched/stat.h b/include/linux/sched/stat.h
> > index 04f1321d14c4..ac39435d1521 100644
> > --- a/include/linux/sched/stat.h
> > +++ b/incl
On Tue, Jul 17, 2018 at 05:01:42PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> > +static bool psi_update_stats(struct psi_group *group)
> > +{
> > + u64 some[NR_PSI_RESOURCES] = { 0, };
> > + u64 full[NR_PSI_RESOURCES] = { 0, };
> > + unsi
On Wed, Jul 18, 2018 at 4:49 PM Stephen Rothwell wrote:
>
> Hi Bjorn,
>
> Commits
>
> 27a6c9ebf29b ("PCI: v3-semi: Fix I/O space page leak")
> db2aff16ea70 ("PCI: mediatek: Fix I/O space page leak")
> 52022fc6f6ad ("PCI: faraday: Fix I/O space page leak")
> a9c0419ec92f ("PCI: aardvark: Fi
On Tue, Jul 17, 2018 at 05:17:05PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> > @@ -457,6 +457,22 @@ config TASK_IO_ACCOUNTING
> >
> > Say N if unsure.
> >
> > +config PSI
> > + bool "Pressure stall information tracking"
> > + sel
On Wed, 18 Jul 2018 at 15:31, Suzuki K Poulose wrote:
>
> Hi Mathieu,
>
> On 07/18/2018 08:43 PM, Mathieu Poirier wrote:
> > When enabling the lockdep mechanic and working with CPU-wide scenarios we
> > get the following console output:
> >
>
> > This is fixed by working with the cpu_present_mask,
On 07/18/2018 02:22 PM, Jacek Anaszewski wrote:
On 07/18/2018 08:54 PM, Jacek Anaszewski wrote:
On 07/18/2018 09:56 AM, Pavel Machek wrote:
Hi!
I believe I meant "changing patterns from kernel in response to events
is probably overkill"... or something like that.
Anyway -- to clean up the c
Hi!
> >Please keep in mind that this is ABI documentation for the pattern file
> >to be exposed by LED core, and not by the pattern trigger, that, as we
> >agreed, will be implemented later. In this case, I'd go for
>
> Gosh, I got completely distracted by the recent discussion about
> pattern sy
On Tue, 17 Jul 2018, Kirill A. Shutemov wrote:
> Per-KeyID direct mappings require changes into how we find the right
> virtual address for a page and virt-to-phys address translations.
>
> page_to_virt() definition overwrites default macros provided by
> . We only overwrite the macros if MTKME i
Based on the documentation provided in AMD's Open-Source
Register Reference For AMD Family 17h Processors:
https://support.amd.com/TechDocs/56255_OSRR.pdf
I've added support for reading Cores and Package energy usage from AMD's
"RAPL" MSRs. In order to correctly detect the AMD processor generation
This fixes the reported family on modern AMD processors (e.g. Ryzen,
which is family 0x17). Previously these processors all showed up as
family 0xf.
See the document
https://support.amd.com/TechDocs/56255_OSRR.pdf
section CPUID_Fn0001_EAX for how to calculate the family
from the BaseFamily and
Based on the Open-Source Register Reference for AMD Family 17h
Processors Models 00h-2Fh:
https://support.amd.com/TechDocs/56255_OSRR.pdf
These processors report RAPL support in bit 14 of CPUID 0x8007 EDX,
and the following MSRs are present:
0xc0010299 (RAPL_PWR_UNIT), like Intel's RAPL_POWER_
On Mon, Jul 02, 2018 at 06:58:54PM -0400, Sinan Kaya wrote:
> pci_reset_bus() and pci_reset_slot() functions are not being used by
> any code. Remove them from the kernel in favor of pci_try_reset_bus()
> and pci_try_reset_slot() functions.
>
> Signed-off-by: Sinan Kaya
> ---
> drivers/pci/pci.c
On Wed, Jul 18, 2018 at 02:03:18PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 12, 2018 at 01:29:40PM -0400, Johannes Weiner wrote:
> > + /* Time in which tasks wait for the CPU */
> > + state = PSI_NONE;
> > + if (tasks[NR_RUNNING] > 1)
> > + state = PSI_SOME;
> > + time_state(&gr
On 7/18/2018 3:30 PM, Bjorn Helgaas wrote:
On Mon, Jul 02, 2018 at 06:58:54PM -0400, Sinan Kaya wrote:
pci_reset_bus() and pci_reset_slot() functions are not being used by
any code. Remove them from the kernel in favor of pci_try_reset_bus()
and pci_try_reset_slot() functions.
Signed-off-by:
On 18:57-20180718, Tony Lindgren wrote:
> * Nishanth Menon [180718 18:08]:
> > On 16:26-20180626, Nishanth Menon wrote:
> > > Hi,
> > >
> > > This is an minor update from V1 posted earlier:
> > > https://marc.info/?l=linux-kernel&m=152943745424
The vdso{32,64}.so can fail to link with CC=clang when clang tries to
find a suitable GCC toolchain to link these libraries with.
/usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o:
access beyond end of merged section (782)
This happens because the host environment leaked into the cross
compiler
Linus,
Please pull a couple of DT fixes. Details below.
Rob
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/dev
Hello Mylène,
On Wed, Jul 18, 2018 at 08:27:17PM +0200, Mylène Josserand wrote:
> Add the support of regulator to use it as VCC source.
>
> Signed-off-by: Mylène Josserand
> ---
> .../bindings/input/touchscreen/edt-ft5x06.txt | 1 +
> drivers/input/touchscreen/edt-ft5x06.c | 2
Hi Andrey,
On Tue, Jul 17, 2018 at 1:06 AM, Andrey Smirnov
wrote:
> +/dts-v1/;
> +#include "vf610.dtsi"
> +
> +/ {
> + model = "ZII VF610 SSMB SPU3 Board";
> + compatible = "zii,vf610spu3", "zii,vf610dev", "fsl,vf610";
Looks good to me.
Just a minor comment: Is " "zii,vf610dev" rea
Hi Phil,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.18-rc5 next-20180718]
[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
From: Omar Sandoval
The memory hotplug notifier kcore_callback() only needs kclist_lock to
prevent races with __kcore_update_ram(), but we can easily eliminate
that race by using an atomic xchg() in __kcore_update_ram(). This is
preparation for converting kclist_lock to an rwsem.
Signed-off-by:
From: Omar Sandoval
The vmcoreinfo information is useful for runtime debugging tools, not
just for crash dumps. A lot of this information can be determined by
other means, but this is much more convenient, and it only adds a page
at most to the file.
Signed-off-by: Omar Sandoval
---
fs/proc/Kc
From: Omar Sandoval
Now we only need kclist_lock from user context and at fs init time, and
the following changes need to sleep while holding the kclist_lock.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --g
From: Omar Sandoval
There's a theoretical race condition that will cause /proc/kcore to miss
a memory hotplug event:
CPU0 CPU1
// hotplug event 1
kcore_need_update = 1
open_kcore() open_kcore()
kcore_update_ram()kcore_update_
From: Omar Sandoval
Currently, the ELF file header, program headers, and note segment are
allocated all at once, in some icky code dating back to 2.3. Programs
tend to read the file header, then the program headers, then the note
segment, all separately, so this is a waste of effort. It's cleaner
From: Omar Sandoval
Now that we're using an rwsem, we can hold it during the entirety of
read_kcore() and have a common return path. This is preparation for the
next change.
Signed-off-by: Omar Sandoval
---
fs/proc/kcore.c | 70 -
1 file changed,
From: Omar Sandoval
The current code does a full search of the segment list every time for
every page. This is wasteful, since it's almost certain that the next
page will be in the same segment. Instead, check if the previous segment
covers the current page before doing the list search.
Signed-o
From: Omar Sandoval
Hi,
This series makes a few improvements to /proc/kcore. Patches 1, 2, and 3
are prep patches. Patch 4 is a fix/cleanup. Patch 5 is another prep
patch. Patches 6 and 7 are optimizations to ->read(). Patch 8 adds
vmcoreinfo to /proc/kcore.
Again, based on v4.18-rc4 + James' p
From: Omar Sandoval
kclist_add() is only called at init time, so there's no point in
grabbing any locks. We're also going to replace the rwlock with a rwsem,
which we don't want to try grabbing during early boot.
While we're here, mark kclist_add() with __init so that we'll get a
warning if it's
Hi Arnd, Olof,
Please pull UniPhier DT (32bit) updates for the v4.19 MW.
Thanks!
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/
Hi Arnd, Olof,
Please pull UniPhier DT (64bit) updates for the v4.19 MW.
Thanks!
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/
I asked about this before and it still isn't covered in the description:
You were specifically asked (maybe in person at LSF/MM?) not to modify
allocator to pass the keyid around. Please specifically mention how
this design addresses that feedback in the patch description.
You were told, "don't c
Hi Arnd, Olof,
Please pull UniPhier SoC changes for the v4.19 MW.
Thanks!
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/masahiro
On Wed, Jul 18, 2018 at 2:22 PM Al Viro wrote:
>
> Why is counter any better than LSB of a pointer?
Easier nesting, but if you do it with the "surround by a macro" model
I guess you can just save/restore instead (like you did in
call_with_creds).
Linus
2018-07-14 0:30 GMT+09:00 Olof Johansson :
> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
> in particular. So, probe for whether it's available and use the previous
> (linux) targets if it isn't.
>
> Reported-by: Laura Abbott
> Cc: Paul Kocialkowski
> Signed-off-by: Olof
On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> khugepaged allocates page in advance, before we found a VMA for
> collapse. We don't yet know which KeyID to use for the allocation.
That's not really true. We have the VMA and the address in the caller
(khugepaged_scan_pmd()), but we drop the l
> On Jul 18, 2018, at 10:58 AM, Rik van Riel wrote:
>
>
>
>> On Jul 17, 2018, at 4:04 PM, Andy Lutomirski wrote:
>>
>>
>> I think you've introduced a minor-ish performance regression due to
>> changing the old (admittedly terribly documented) control flow a bit.
>> Before, if real_prev ==
On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> + } else {
> + /*
> + * Reset __PHYSICAL_MASK.
> + * Maybe needed if there's inconsistent configuation
> + * between CPUs.
> + */
> + physical_mask = (1ULL << __PHYSIC
On Wed, Jul 18, 2018 at 2:28 PM David Howells wrote:
>
> Are network filesystems allowed to use f_cred at I/O time to determine the
> authentication/encryption parameters to commune with the server?
Absolutely. file->f_cred is very much "what was my ID at open time".
Of course, you may well have
2018-07-14 1:24 GMT+09:00 Olof Johansson :
> ARCH=vax isn't in mainline; it can be added back if/when it shows up.
>
> Signed-off-by: Olof Johansson
> ---
Applied to linux-kbuild. Thanks!
> scripts/package/buildtar | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/scripts/package/bui
2018-07-14 1:24 GMT+09:00 Olof Johansson :
> Make 'make tar-pkg' work on arm64.
>
> Cc: Will Deacon
> Cc: Catalin Marinas
> Signed-off-by: Olof Johansson
> ---
Applied to linux-kbuild. Thanks!
> scripts/package/buildtar | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/script
On Wed, Jul 18, 2018 at 2:27 PM David Howells wrote:
>
> As I may have said, I have tried modifying the kernel to pass the cred pointer
> down.
It should always be there in the 'struct file *'.
Now, we may have some broken stuff that passes only inodes down, but
they probably really should be fi
On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> mktme_nr_keyids holds number of KeyIDs available for MKTME, excluding
> KeyID zero which used by TME. MKTME KeyIDs start from 1.
>
> mktme_keyid_shift holds shift of KeyID within physical address.
I know what all these words mean, but the combin
2018-07-19 2:15 GMT+09:00 Major Hayden :
> Copy the architecture-specific compressed kernel image to the
> directory used to make the tar package.
>
> Signed-off-by: Major Hayden
> ---
Thanks for the patch,
but I applied Olof's one, which copy more files.
https://patchwork.kernel.org/patch/1052
Introduces three new helper functions:
* munmap_addr_sanity()
* munmap_lookup_vma()
* munmap_mlock_vma()
They will be used by do_munmap() and the new do_munmap with zapping
large mapping early in the later patch.
There is no functional change, just code refactor.
Signed-off-by: Yang Shi
-
Background:
Recently, when we ran some vm scalability tests on machines with large memory,
we ran into a couple of mmap_sem scalability issues when unmapping large memory
space, please refer to https://lkml.org/lkml/2017/12/14/733 and
https://lkml.org/lkml/2018/2/20/576.
History:
Then akpm sugg
When running some mmap/munmap scalability tests with large memory (i.e.
> 300GB), the below hung task issue may happen occasionally.
INFO: task ps:14018 blocked for more than 120 seconds.
Tainted: GE 4.9.79-009.ali3000.alios7.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeo
On Wed, Jul 18, 2018 at 03:36:29PM -0700, Sinan Kaya wrote:
> On 7/18/2018 3:30 PM, Bjorn Helgaas wrote:
> > On Mon, Jul 02, 2018 at 06:58:54PM -0400, Sinan Kaya wrote:
> > > pci_reset_bus() and pci_reset_slot() functions are not being used by
> > > any code. Remove them from the kernel in favor of
On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> An encrypted VMA will have KeyID stored in vma->vm_page_prot. This way
> we don't need to do anything special to setup encrypted page table
> entries
We don't do anything special for protection keys, either. They just
work too.
> diff --git a/a
On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> Store KeyID in bits 31:16 of extended page flags. These bits are unused.
I'd love a two sentence remind of what page_ext is and why you chose to
use it. Yes, you need this. No, not everybody that you want to review
this patch set knows what it
> --- a/arch/x86/mm/mktme.c
> +++ b/arch/x86/mm/mktme.c
> @@ -1,3 +1,4 @@
> +#include
> #include
>
> phys_addr_t mktme_keyid_mask;
> @@ -37,3 +38,14 @@ struct page_ext_operations page_mktme_ops = {
> .need = need_page_mktme,
> .init = init_page_mktme,
> };
> +
> +int vma_keyid(st
2018-07-12 23:05 GMT+09:00 Kirill A. Shutemov :
> On Thu, Jul 12, 2018 at 05:01:30PM +0900, Masahiro Yamada wrote:
>>
>> This series renames LDFLAGS to KBUILD_LDFLAGS
>> after some Makefile cleanups.
>>
>> Currently, the last patch does not apply to Linus' tree
>> due to missing pre-requisite patch
Hi Krzysztof,
On 2018년 07월 19일 05:02, Krzysztof Kozlowski wrote:
> Replace GPL license statements with SPDX license identifiers (GPL-2.0).
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> include/dt-bindings/clock/exynos3250.h| 5 +
> include/dt-bindings/clock/exynos4.h
The description doesn't mention the potential performance implications
of this patch. That's criminal at this point.
> --- a/arch/x86/mm/mktme.c
> +++ b/arch/x86/mm/mktme.c
> @@ -1,4 +1,5 @@
> #include
> +#include
> #include
>
> phys_addr_t mktme_keyid_mask;
> @@ -49,3 +50,51 @@ int vma_k
Implement the idea suggested by Artem Bityutskiy and Tony Lindgren
described in commit b027274d2e3a ("mtd: ams-delta: fix
request_mem_region() failure").
arch/arm/mach-omap1/board-ams-delta.c | 22 -
drivers/gpio/gpio-omap.c | 88 ++
drivers/mtd/nand/raw/ams-delta.c |
Introduce a driver private structure and allocate it on device probe.
Use it for storing nand_chip structure, GPIO descriptors prevoiusly
stored in static variables as well as io_base pointer previously passed
as nand controller data or platform driver data. Subsequent patches
may populate the str
Data port used by the driver is actually an OMAP MPUIO device, already
under control of gpio-omap driver. For that reason we used to not
request the memory region of the port as that would fail because the
region is already busy. Despite that, we are still accessing the port
by just ioremapping i
The plan is to replace data port readw()/writew() operations with GPIO
callbacks provided by gpio-omap driver. For acceptable performance the
GPIO chip must support get/set_multiple() GPIO callbacks.
In order to avoid data corruption, we require the array of data GPIO
descriptors obtained with gp
In its current shape, the driver sets data port direction before each
byte read/write operation, even during multi-byte transfers. Optimize
that by setting the port direction only on first byte of each transfer.
Signed-off-by: Janusz Krzysztofik
---
drivers/mtd/nand/raw/ams-delta.c | 42 +++
This should make applications utilizing whole banks work faster.
Signed-off-by: Janusz Krzysztofik
---
drivers/gpio/gpio-omap.c | 88 ++--
1 file changed, 86 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.
Initialize NWP GPIO pin low to protect the device from hazard during
probe. Release write protection as soon as the device is under
control.
Signed-off-by: Janusz Krzysztofik
---
drivers/mtd/nand/raw/ams-delta.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/driv
Don't readw()/writew() data directly from/to GPIO port which is under
control of gpio-omap driver, use GPIO chip callbacks instead.
Thanks to utilization of get/set_multiple() callbacks, performance
degrade is minor for typical data transfers.
The driver should now work with any 8+-bit bidirectio
Further optimize processing speed of read/write callback functions by
resolving private structure pointer only once per callback and passing
it to all subfunctions instead of mtd_info.
Signed-off-by: Janusz Krzysztofik
---
drivers/mtd/nand/raw/ams-delta.c | 44 +++
On Wed, 2018-07-18 at 13:50 -0600, Rob Herring wrote:
>
> > So Rob, I think that's precisely where the disconnect is.
> >
> > I think we all (well hopefully) agree that those few tunables don't fit
> > in any existing subystem and aren't likely to ever do (famous last
> > words...).
> >
> > Wher
On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> arch/x86/include/asm/mktme.h | 8 +
> arch/x86/mm/init_64.c| 10 +
> arch/x86/mm/mktme.c | 437 +++
> 3 files changed, 455 insertions(+)
I'm not the maintainer. But, NAK from me on this on the
Dear Greg,
This is extcon-next pull request for v4.19. I add detailed description of
this pull request on below. Please pull extcon with following updates.
Best Regards,
Chanwoo Choi
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04
On 2018-07-18 11:04, Douglas Anderson wrote:
Add both the interface and core clock.
Signed-off-by: Douglas Anderson
---
drivers/clk/qcom/gcc-sdm845.c | 73 +++
1 file changed, 73 insertions(+)
diff --git a/drivers/clk/qcom/gcc-sdm845.c
b/drivers/clk/qcom/gcc-
On 14 July 2018 at 00:30, Olof Johansson wrote:
> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
> in particular. So, probe for whether it's available and use the previous
> (linux) targets if it isn't.
>
> Reported-by: Laura Abbott
> Cc: Paul Kocialkowski
> Signed-off-by:
On Wed, Jul 18, 2018 at 01:17:00PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 18, 2018 at 09:41:05PM +0200, David Woodhouse wrote:
> >
> >
> > On Wed, 2018-07-18 at 09:37 -0700, Paul E. McKenney wrote:
> > > On Wed, Jul 18, 2018 at 06:01:51PM +0200, David Woodhouse wrote:
> > > >
> > > > On We
On Wed, Jul 11, 2018 at 06:03:42PM +0100, David Woodhouse wrote:
> On Wed, 2018-07-11 at 09:49 -0700, Paul E. McKenney wrote:
> > And here is an updated v4.15 patch with Marius's Reported-by and David's
> > fix to my lost exclamation point.
>
> Thanks. Are you sending the original version of that
On Wed, Jul 18, 2018 at 3:50 PM Fabio Estevam wrote:
>
> Hi Andrey,
>
> On Tue, Jul 17, 2018 at 1:06 AM, Andrey Smirnov
> wrote:
>
> > +/dts-v1/;
> > +#include "vf610.dtsi"
> > +
> > +/ {
> > + model = "ZII VF610 SSMB SPU3 Board";
> > + compatible = "zii,vf610spu3", "zii,vf610dev", "f
Hi Andrey,
On Wed, Jul 18, 2018 at 9:51 PM, Andrey Smirnov
wrote:
> It's not used in Linux, but I do rely on it in Barebox here:
>
> https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/zii-vf610-dev/board.c#n94
>
> and here:
>
> https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boar
Add support for the Zodiac Inflight Innovations CFU1
board (VF610-based).
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: cphe...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrew Lunn
Signed-off-by: Andrey Smirnov
---
Thanks, we will run the test with your patch, will update the test results in
24 Hours.
Current status is:
We can reproduce the issue in 3000 cycles stress S/R test, we can't reproduce
the kernel panic with our patch in 6000 cycles.
-Original Message-
From: Takashi Iwai
Sent: Wednesda
Hi There !
Is this email address correct?
Reply for important info .
Thank You
On Tue, Jul 17, 2018 at 05:59:27PM -0400, Waiman Long wrote:
> On a VM with only 1 vCPU, the locking fast path will always be
> successful. In this case, there is no need to use the the PV qspinlock
> code which has higher overhead on the unlock side than the native
> qspinlock code.
Why not make
Hi Todd,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20180718]
[cannot apply to v4.18-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
David Howells writes:
> Andy Lutomirski wrote:
>
>> > Also you can't currently directly create a bind mount from userspace as you
>> > can only bind from another path point - which you may not be able to access
>> > (either by permission failure or because it's not in your mount namespace).
>> >
On Thu, 19 Jul 2018, at 04:37, Rob Herring wrote:
> On Tue, Jul 17, 2018 at 5:28 PM Andrew Jeffery wrote:
> >
> > On Tue, 17 Jul 2018, at 14:26, Benjamin Herrenschmidt wrote:
> > > On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> > > > If that data is one set per SoC, then i'm not that conc
There is a potential execution path in which function
platform_get_resource() returns NULL. If this happens,
we will end up having a NULL pointer dereference.
Fix this by adding asanity check in order to avoid a
NULL pointer dereference.
This code was detected with the help of Coccinelle.
Cc: st
There is a potential execution path in which function
platform_get_resource() returns NULL. If this happens,
we will end up having a NULL pointer dereference.
Fix this by adding a sanity check in order to avoid a
NULL pointer dereference.
This code was detected with the help of Coccinelle.
Cc: s
On Wed, Jul 18, 2018 at 2:10 PM, Laura Abbott wrote:
>
> Implementation of stackleak based heavily on the x86 version
>
> Signed-off-by: Laura Abbott
> ---
> Since last time: Minor style cleanups. Re-wrote check_alloca to
> correctly handle all stack types. While doing that, I also realized
> cur
On Tue, Jul 17, 2018 at 11:28:46AM +0800, Anson Huang wrote:
> GPC registers are NOT continuous, some registers are
> reserved and accessing them from userspace will trigger
> external abort, add regmap register access table to
> avoid below abort:
>
> root@imx6slevk:~# cat /sys/kernel/debug/regma
Hi Dominique,
On 2018/7/18 17:54, Dominique Martinet wrote:
> piaojun wrote on Wed, Jul 18, 2018:
>> spin_lock is more effective for short time protection than mutex_lock, as
>> mutex lock may cause process sleep and wake up which consume much cpu
>> time.
>
> That's not a fast path operation, I
Hi Boris,
After merging the nand tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
In file included from include/linux/platform_device.h:14:0,
from drivers/mtd/nand/raw/jz4740_nand.c:19:
drivers/mtd/nand/raw/jz4740_nand.c: In function 'jz_nand_detect_ban
> > I agree
> > that not using /dev/mem is a good thing, but there are several ways
> > you could do that independent of any DT binding.
>
> Such as ? The only other option is to have one or more kernel drivers
> that have built-in the precise and complete list of those tunables that
> need to be
Hi,
This patch series adds a driver and DT binding using the interconnect (ICC)
framework [1] to describe the Qualcomm SDM845 platform's topology of its
interconnected buses and internal aggregation nodes known as
Bus Clock Managers(BCM). The SDM845 ICC provider driver would aggregate and
satisfy
Add RSC(Resource State Coordinator) provider
dictating network-on-chip interconnect bus performance
found on SDM845-based platforms.
Signed-off-by: David Dai
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/
Introduce Qualcomm SDM845 specific provider driver using the
interconnect framework.
Signed-off-by: David Dai
---
.../bindings/interconnect/qcom-sdm845.txt | 22 +
drivers/interconnect/qcom/Kconfig | 8 +
drivers/interconnect/qcom/Makefile | 1 +
dr
101 - 200 of 736 matches
Mail list logo
