On Thu, Aug 16, 2018 at 5:42 PM, Richard Weinberger
wrote:
> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote:
>>
>> Hi Linus,
>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>>
>> Then I saw Linu
On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
> Bart Massey reported what turned out to be a usercopy whitelist false
> positive in JFS when symlink contents exceeded 128 bytes. The inline
> inode data (i_inline) is actually designed to overflow into the "extended
So, this may be a stupi
Linus,
Please pull below to receive modules updates for the 4.19 merge window.
Details can be found in the signed tag.
Thanks,
Jessica
---
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the Git reposit
On Tue, Aug 14, 2018 at 11:18:45AM +0200, Arnd Bergmann wrote:
> A new build error appeared with CONFIG_PROC_FS disabled:
>
> arch/x86/kernel/apm_32.c:1643:12: error: 'proc_apm_show' defined but not used
> [-Werror=unused-function]
>
> This marks the function as __maybe_unused to let the compile
On Thu, Aug 16, 2018 at 09:05:18AM +0200, Tobias Klauser wrote:
> DEBUG_STACK_USAGE is already defined in lib/Kconfig.debug
>
> Signed-off-by: Tobias Klauser
Looks like some sort of merge error indeed:
Reviewed-by: Christoph Hellwig
Radhey,
On 2018-08-16 16:29, Radhey Shyam Pandey wrote:
>> +/**
>> + * enum dma_desc_metadata_mode - per descriptor metadata mode types
>> supported
>> + * @DESC_METADATA_CLIENT - the metadata buffer is allocated/provided by
>> the
>> + * client driver and it is attached (via the
>> dmaengine_de
On 2018/8/16 16:33, Jerome Brunet wrote:
> On Thu, 2018-08-16 at 11:05 +0800, Hanjie Lin wrote:
>>
>> On 2018/8/14 18:41, Jerome Brunet wrote:
>>> On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
From: Yue Wang
The Meson-PCIE-PHY controller supports the 5-Gbps data rate
From: Dominique Martinet
Ron Minnich has left Sandia in 2011, and has not been involved in any
9p commit in the recent years.
Signed-off-by: Dominique Martinet
Cc: Eric Van Hensbergen
Cc: Ron Minnich
Cc: Ronald G. Minnich
Cc: Latchesar Ionkov
To: Andrew Morton
---
v2: added CREDITS entry
This adds a pci_dev mutex which will be used to fix a number
of races related to the various state bits maintained in
that structure.
We call it "state_lock" with similarly named accessors to avoid
confusion with the pci_dev_lock() which uses the device_lock().
This is a low level mutex meant to
For the record, about the exactness of the patch description.
The patch mentions the regression by the commit c62ec4610c40, but it is not the
cause of the bug (https://bugzilla.kernel.org/show_bug.cgi?id=20067) reported
by me; I reverted c62ec4610c40 on linux-4.17.13, and the bug remained.
# So
Hi Pasha
Thanks for the comments
On 8/17/2018 9:35 AM, Pasha Tatashin Wrote:
>
>
> On 7/6/18 5:01 AM, Jia He wrote:
>> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
>> where possible") optimized the loop in memmap_init_zone(). But there is
>> still some room for improve
This wraps pci_set_master() and pci_clear_master() with the pci_dev
state lock. The clearing of is_busmaster in pci_disable_device()
is already covered.
This also adds a comment explaining why is_busmaster must not be
checked in pci_set_master() due to how the power management code
uses it.
Signe
This already represents whether a device is accessible or not,
creating a new flag isn't particularly helpful.
dev->error_state being an int, assigning it doesn't require
an atomic operation per-se. The existing atomic bitop only
protects the field, not anything else anyway.
Signed-off-by: Benjam
This already represents whether a device is accessible or not,
creating a new flag isn't particularly helpful.
dev->error_state being an int, assigning it doesn't require
an atomic operation per-se. The existing atomic bitop only
protects the field, not anything else anyway.
Signed-off-by: Benjam
This re-fixes the bug reported by Hari Vyas
after my revert of his commit but in a much simpler way.
The main issues is that is_added was being set after the driver
got bound and started, and thus setting it could race with other
changes to struct pci_dev.
This fixes it by setting the flag first
This protects enable/disable operations using the state mutex to
avoid races with, for example, concurrent enables on a bridge.
The bus hierarchy is walked first before taking the lock to
avoid lock nesting (though it would be ok if we ensured that
we always nest them bottom-up, it is better to ju
On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote:
> The second part aims at fixing the enable/disable/set_master races,
> and does so by providing a framework for future device state locking
> issues.
>
> It introduces a pci_dev->state_mutex which is used at a lower level
> than the
Hi all,
Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.
Changes since 20180816:
The ipvs tree gained a conflict against the netfilter tree.
The mfd tree gained a conflict against Linus' tree.
Non-merge commits (relati
s/device_add/device_attach .. ugh.
On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote:
> This re-fixes the bug reported by Hari Vyas
> after my revert of his commit but in a much simpler way.
>
> The main issues is that is_added was being set after the driver
> got bound and started
On Fri, 2018-08-17 at 14:48 +1000, Benjamin Herrenschmidt wrote:
> This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
>
> The new pci state mutex provides a simpler way of addressing
> this race and avoids the relative includes added to the powerpc
> code.
Ignore the cset comment, my "
This is really two series but since they conflict a bit separately
here they are in one:
First we undo the mess of those atomic priv_flags. The atomicity
doesn't provide any security since there's no locking against
the other state pertaining to those flags, it only protects the
flags themselves.
This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76.
The new pci state mutex provides a simpler way of addressing
this race and avoids the relative includes added to the powerpc
code.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/pci-common.c | 4 +---
arch/po
From: Randy Dunlap
Fix a source file reference location to the correct path name.
Signed-off-by: Randy Dunlap
Cc: Josh Poimboeuf
---
scripts/faddr2line |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-418.orig/scripts/faddr2line
+++ lnx-418/scripts/faddr2line
@@ -71,7 +71,7 @
On 2018/8/17 11:24, zhong jiang wrote:
> kfree has taken null pointer into account. so check the null pointer
> before kfree is meanless.
meanless/meaningless. will repost. please ignore the patch, thanks.
> Signed-off-by: zhong jiang
> ---
> drivers/misc/sgi-xp/xpc_partition.c | 3 +--
> 1 fil
kfree has taken null pointer into account. so check the null pointer
before kfree is meaningless.
Signed-off-by: zhong jiang
---
drivers/misc/sgi-xp/xpc_partition.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/sgi-xp/xpc_partition.c
b/drivers/misc/sgi-xp/xp
subect: drviers/drivers will repost, please ingore the patch. Thanks
On 2018/8/17 11:31, zhong jiang wrote:
> debugfs_remove_recursive has taken the null pointer into account.
> just remove the null check before debugfs_remove_recursive.
>
> Signed-off-by: zhong jiang
> ---
> drivers/platform/
debugfs_remove_recursive has taken null pointer into account. so
remove the unneeded check.
Signed-off-by: zhong jiang
---
drivers/media/usb/uvc/uvc_debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_debugfs.c
b/drivers/media/usb/uvc/uvc_de
debugfs_remove_recursive has taken the null pointer into account.
just remove the null check before debugfs_remove_recursive.
Signed-off-by: zhong jiang
---
drivers/platform/x86/intel_ips.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel_ips.c b/d
debugfs_remove_recursive has taken the null pointer into account.
just remove the null check before debugfs_remove_recursive.
Signed-off-by: zhong jiang
---
drivers/platform/x86/intel_ips.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/intel_ips.c b/d
On Thu, 2018-08-16 at 22:07 -0500, Bjorn Helgaas wrote:
> [+cc Srinath, Guenter, Jens, Lukas, Konstantin, Marta, Pierre-Yves]
>
> On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote:
> > [Note: This isn't meant to be merged, it need splitting at the very
> > least, see below]
>
kfree has taken null pointer into account. so check the null pointer
before kfree is meanless.
Signed-off-by: zhong jiang
---
drivers/misc/sgi-xp/xpc_partition.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/misc/sgi-xp/xpc_partition.c
b/drivers/misc/sgi-xp/xpc_p
On Fri, Aug 17, 2018 at 08:51:42AM +0530, Srikanth Korangala Hari wrote:
> > Thanks for the patch! Do you have a reproducer or is this theoretical?
> > This will affect if it should go to stable or not.
>
> Dear Luis, this is theoretical as I observed in most of the call's to api -
> "proc_mkdir"
> It is fine to crash because /proc is not modular.
Dear Alexey, this was theoretical solution. If you feel this should crash
instead if the call fail's then ignore the patch.
Regards,
Srikanth
> Thanks for the patch! Do you have a reproducer or is this theoretical?
> This will affect if it should go to stable or not.
Dear Luis, this is theoretical as I observed in most of the call's to api -
"proc_mkdir" the NULL check is being done. Hence I thought of adding one here.
Regards,
Srikan
On 17/08/2018 5:41 AM, Andy Lutomirski wrote:
Currently, if the vDSO ends up containing an indirect branch or
call, GCC will emit the "external thunk" style of retpoline, and it
will fail to link.
Fix it by building the vDSO with inline retpoline thunks.
I haven't seen any reports of this tr
[+cc Srinath, Guenter, Jens, Lukas, Konstantin, Marta, Pierre-Yves]
On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote:
> [Note: This isn't meant to be merged, it need splitting at the very
> least, see below]
>
> This is something I cooked up quickly today to test if that wou
--
Pozdravy,
Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl
dát soukromě a já bych ocenil vaši rychlou odpověď zde
(xu.shiq...@aol.com) pro další komunikaci.
Vyčkejte na rychlou odpověď.
Pozdravy,
--
Pozdravy,
Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl
dát soukromě a já bych ocenil vaši rychlou odpověď zde
(xu.shiq...@aol.com) pro další komunikaci.
Vyčkejte na rychlou odpověď.
Pozdravy,
On Tue, 2018-08-07 at 12:24 +0200, Joerg Roedel wrote:
> Hi,
>
> here is a small patch-set to fix two small issues in the
> PTI implementation for 32 bit x86. The issues are:
>
> 1) Fix the 32 bit PCID check. I used the wrong
> operator there and this caused false-positive
>
On Wed, 2018-08-08 at 13:16 +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The user page-table gets the updated kernel mappings in
> pti_finalize(), which runs after the RO+X permissions got
> applied to the kernel page-table in mark_readonly().
>
> But with CONFIG_DEBUG_WX enabled, the use
As commit ebaad7d36406 ("kbuild: rpm: prompt to use "rpm-pkg" if "rpm"
target is used") noticed, the "rpm" target is now removed.
I assume people have already migrated to "rpm-pkg".
Signed-off-by: Masahiro Yamada
---
Makefile | 4
1 file changed, 4 deletions(-)
diff --git a/Makefile b/Mak
Hi Stephen,
Do you want me to resend this series for review?
It seems have been pending for quite a long time.
Thor just pinged me for its status as he wants to use it.
Regards
Dong Aisheng
> -Original Message-
> From: A.s. Dong
> Sent: Wednesday, June 20, 2018 10:54 AM
> To: linux-...@
On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki wrote:
>> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get the
>> keyboard wake up the system as expected. We considered to work out a DMI
>> based quirk for this. But based on the information that EC would not signal
>> SC
On 2018/8/14 14:39, Daniel Lezcano wrote:
> On 09/08/2018 15:40, zhong jiang wrote:
>> Device node iterators will get the return node. Meawhile, It is
>> also put the previous device node. An explicit put will cause
>> a double put.
> What about:
>
> Subject: drivers/thermal/tegra: Fix a double fre
On Wed, Jul 04, 2018 at 11:17:38AM +0100, Morten Rasmussen wrote:
> On asymmetric cpu capacity systems (e.g. Arm big.LITTLE) it is crucial
> for performance that cpu intensive tasks are aggressively migrated to
> high capacity cpus as soon as those become available. The capacity
> awareness tweaks
2018-08-17 1:30 GMT+09:00 Randy Dunlap :
> On 08/15/2018 08:27 PM, Masahiro Yamada wrote:
>> 2018-08-15 9:36 GMT+09:00 Randy Dunlap :
>>> From: Randy Dunlap
>>>
>>> Add build-only targets for build_menuconfig, build_nconfig,
>>> build_xconfig, and build_gconfig.
>>> (targets must end in "config" t
On 08/16/2018 07:49 PM, Bjorn Andersson wrote:
> da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
> print of it to avoid a compile warning.
>
Thanks for the improvement,
Acked-by: Suman Anna
> Signed-off-by: Bjorn Andersson
> ---
> drivers/remoteproc/da8xx_remoteproc.c
From: Roy Im
This patch adds the da7280 bindings doc and driver to the Dialog
Semiconductor support list.
Signed-off-by: Roy Im
---
v2: No changes
MAINTAINERS |2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 544cac8..720f9fe 100644
--- a/MAINTAINERS
From: Roy Im
This patch adds support for the Dialog DA7280 Haptic driver IC.
In this patch set the following is provided:
[PATCH V2 1/3] MAINTAINERS file update for DA7280
[PATCH V2 2/3] DA7280 DT Binding
[PATCH V2 3/3] DA7280 Driver
This patch applies against linux-next and v4.18
Thank you,
from: Roy Im
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.
Signed-off-by: Roy Im
---
v2: Fixed kbuild error/warning
drivers/input/misc/Kconfig | 12 +
driver
from: Roy Im
Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.
Signed-off-by: Roy Im
---
v2: No changes
.../devicetree/bindings/input/dlg,da7280.txt | 91
1 file changed, 91 insertions(+)
create mode 100644 D
On 8/16/18 9:35 PM, Pasha Tatashin wrote:
>
>
> On 7/6/18 5:01 AM, Jia He wrote:
>> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
>> where possible") optimized the loop in memmap_init_zone(). But there is
>> still some room for improvement. E.g. in early_pfn_valid(),
On 7/6/18 5:01 AM, Jia He wrote:
> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
> where possible") optimized the loop in memmap_init_zone(). But there is
> still some room for improvement. E.g. in early_pfn_valid(), if pfn and
> pfn+1 are in the same memblock region, we
On 8/16/18 9:08 PM, Pavel Tatashin wrote:
>
>> Signed-off-by: Jia He
>> ---
>> mm/memblock.c | 37 +
>> 1 file changed, 29 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index ccad225..84f7fa7 100644
>> --- a/mm/memblock.c
> Signed-off-by: Jia He
> ---
> mm/memblock.c | 37 +
> 1 file changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index ccad225..84f7fa7 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1140,31 +1140,52 @@ int _
da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
print of it to avoid a compile warning.
Signed-off-by: Bjorn Andersson
---
drivers/remoteproc/da8xx_remoteproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/da8xx_remoteproc.c
b/dri
Hi all,
Today's linux-next merge of the mfd tree got a conflict in:
MAINTAINERS
between commit:
16b7db4c8150 ("MAINTAINERS: Add .clang-format entry")
from Linus' tree and commit:
97c2b5cba204 ("mfd: madera: Add register definitions for Cirrus Logic Madera
codecs")
from the mfd tree.
On Thu, 2018-08-16 at 21:31 +0100, David Howells wrote:
> James Bottomley wrote:
>
> > As a step by step process, I agree. However, I think we can
> > automate it to the point where you install a package and it says
> > "insert your yubikey" every time you upgrade the kernel
>
> That's a very b
Hi Linus,
Please pull these two VLA removals for v4.19-rc1. It didn't seem
sensible to me to wait to add these: they're both trivial and have been
sitting in -next while I tried to get them picked up by their respective
maintainers. Instead, I can just be that maintainer. :) After these,
only some
On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
wrote:
>
> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>
> The reverted commit introduces broken builds. Even though the cpio archive
> does contain all the specified files, it seems that the kernel, while
> populating rootfs, s
On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:
> Another way would be to add
>
> #include
> +#undef PCI_IOBASE
>
> in your asm/io.h. This is about as ugly as the your version, but
> it would be local to ia64 ;-)
Third way ...
Is "0" actually the right value for PCI_IOBASE for
Hi Rasmus,
On Wed, Aug 15, 2018 at 10:55:39AM +0200, Rasmus Villemoes wrote:
> Most of the inline bitmap functions are buggy if passed a compile-time
> constant nbits==0.
I think it's bad wording. Functions are OK. The problem is in users.
Also, run-time nbits==0 is buggy as well. On the other ha
On Fri, 17 Aug 2018 00:34:21 +0200
Daniel Borkmann wrote:
> On 08/17/2018 12:20 AM, Alexei Starovoitov wrote:
> > On Thu, Aug 16, 2018 at 03:48:17PM -0400, Steven Rostedt wrote:
> >> [ Alexei and/or Daniel, I'm adding SPDX headers to the tracing
> >> directory. Can you ack this patch? Thanks
On Thu, 16 Aug 2018 15:20:58 -0700
Alexei Starovoitov wrote:
> On Thu, Aug 16, 2018 at 03:48:17PM -0400, Steven Rostedt wrote:
> > [ Alexei and/or Daniel, I'm adding SPDX headers to the tracing
> > directory. Can you ack this patch? Thanks ]
> >
> > From: "Steven Rostedt (VMware)"
> >
> > Ad
On 18-07-06 17:01:11, Jia He wrote:
> From: Jia He
>
> Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
> where possible") optimized the loop in memmap_init_zone(). But it causes
> possible panic bug. So Daniel Vacek reverted it later.
>
> But as suggested by Daniel Vacek,
On 08/17/2018 12:20 AM, Alexei Starovoitov wrote:
> On Thu, Aug 16, 2018 at 03:48:17PM -0400, Steven Rostedt wrote:
>> [ Alexei and/or Daniel, I'm adding SPDX headers to the tracing
>> directory. Can you ack this patch? Thanks ]
>>
>> From: "Steven Rostedt (VMware)"
>>
>> Add the SPDX License he
On Thu, Aug 16, 2018 at 03:48:17PM -0400, Steven Rostedt wrote:
> [ Alexei and/or Daniel, I'm adding SPDX headers to the tracing
> directory. Can you ack this patch? Thanks ]
>
> From: "Steven Rostedt (VMware)"
>
> Add the SPDX License header to ease license compliance management.
>
> Cc: Ale
Hi Linus,
Here are the RDMA patches for 4.19.
This time there are many merge conflicts, all due to various tree-wide or RDMA
subystem wide changes done by various people. The resolution is tricky, as git
does not highlight two areas that need revision.
An overview of the conflicts:
- Mark Rutla
On 16/08/18 01:06 PM, Gustavo A. R. Silva wrote:
> p.port can is indirectly controlled by user-space, hence leading to
> a potential exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
>
> drivers/pci/switch/switchtec.c:912 ioctl_port_to_pf
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 17a0190bd88f..4452f8553301 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -306,6 +306,14 @@ static bool nvme_dbbuf_update_and_check_event(u16 value,
u32 *dbbuf_db,
old_value = *dbbuf_db;
On Thu, Aug 16, 2018 at 10:45 PM Luck, Tony wrote:
>
> Bjorn,
>
> Back in commit:
>
> 0a70abb38062 ("PCI/ACPI: Support I/O resources when parsing host bridge
> resources")
>
> we added acpi_pci_root_remap_iospace(). On ia64 this was a no-op because ia64
> didn't define PCI_IOBASE, so the entir
Hi,
On Thu, Aug 16, 2018 at 1:58 PM, David Collins wrote:
> Hello Doug,
>
> On 08/16/2018 01:07 PM, Doug Anderson wrote:
>> I'll work on either adding more regulator_set_load() calls to clients
>> or perhaps disabling the "regulator-allow-set-load" for a bunch of
>> rails. David: presumably if w
Hello Doug,
On 08/16/2018 01:07 PM, Doug Anderson wrote:
> I'll work on either adding more regulator_set_load() calls to clients
> or perhaps disabling the "regulator-allow-set-load" for a bunch of
> rails. David: presumably if we have a rail that we never need to be
> on-and-in-low-power-mode ca
Hi,
On Thu, Aug 16, 2018 at 1:06 PM, Stephen Boyd wrote:
> The interrupt controller hardware in this pin controller has two status
> enable bits. The first "normal" status enable bit enables or disables
> the summary interrupt line being raised when a gpio interrupt triggers
> and the "raw" statu
clear_page() does not undergo the XOR logic to invert the address
bits, i.e. PTE, PMD and PUD entries that have not been individually
written will have val=0 and so will trigger __pte_needs_invert().
As a result, {pte,pmd,pud}_pfn() will return the wrong PFN value,
i.e. all ones (adjusted by the ma
Bjorn,
Back in commit:
0a70abb38062 ("PCI/ACPI: Support I/O resources when parsing host bridge
resources")
we added acpi_pci_root_remap_iospace(). On ia64 this was a no-op because ia64
didn't define PCI_IOBASE, so the entire body of the function was skipped.
But in the current merge window
Jacek
On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
> Dan,
>
> Thank you for the patch.
>
> I didn't review DT parsing details in v3, but now I've produced
> diff between v3 and v4 to check what has changed.
>
> I'm quite surprised realizing that you're not validating
> HVLED and control bank
James Bottomley wrote:
> As a step by step process, I agree. However, I think we can automate
> it to the point where you install a package and it says "insert your
> yubikey" every time you upgrade the kernel
That's a very bad idea. You train people to unlock their private key on
request. It
vsa.console is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/tty/vt/vt_ioctl.c:711 vt_ioctl() warn: potential spectre issue
'vc_cons' [r]
Fix this by sanitizing vsa.c
It's handy to see the load requested by a regulator consumer in the
regulator_summary. Add it.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- No longer consider consumers that don't call regulator_set_load().
drivers/regulator/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
The first two patches in this series are useful for those who want to
see the load requested by regulator consumers and also what opmode
they're running in (these two concepts are sometimes linked).
The third patch adds some missing locking for regulator_summary.
All three patches could be applie
Most functions that access the rdev lock the rdev mutex before looking
at data. ...but not the code that implements the debugfs
regulator_summary. It probably should though, so let's do it.
Note: this fixes no known issues. The problem was found only by code
inspection.
Signed-off-by: Douglas
It's handy to know what opmode a regulator has been configured to in
the summary. Add it.
Signed-off-by: Douglas Anderson
---
Changes in v2: None
drivers/regulator/core.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/core.
Hello RT Folks!
I'm pleased to announce the 4.4.148-rt165 stable release.
This release is just an update to the new stable 4.4.148 version
and no RT specific changes have been made.
Known issues:
- 'stress-ng --ptrace 4' is able to trigger a latency spike of
several ms. Usually around 2 - 3m
On Thu, Aug 16, 2018 at 12:56:46PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Commit 26112ddc254c (PCI / ACPI / PM: Resume bridges w/o drivers on
> suspend-to-RAM) attempted to fix a functional regression resulting
> from commit c62ec4610c40 (PM / core: Fix direct_complete hand
Measurements of pseudo-locked regions were disabled because of their
incorrect usage of the performance monitoring hardware.
Cache pseudo-locking measurements are now done correctly with the
in-kernel perf API and its use can be re-enabled at this time.
The adjustment to the in-kernel perf API al
The success of a cache pseudo-locked region is measured using
performance monitoring events that are programmed directly at the time
the user requests a measurement.
Modifying the performance event registers directly is not appropriate
since it circumvents the in-kernel perf infrastructure that ex
In support of the most accurate measurements rdpmcl() is used instead of
the more elaborate perf_event_read_local(). rdpmcl() requires the index
of the performance counter used so a helper is introduced to determine
the index used by a provided performance event.
The index used by a performance ev
Dear Maintainers,
This is the second attempt at fixing the lack of coordination between the
pseudo-locking measurement code and perf. Thank you very much for your
feedback on the first version. The entire solution, including the cover
letter, has been reworked based on your feedback, while submitt
It is possible that a failure can occur during the scheduling of a
pinned event. The initial portion of perf_event_read_local() contains
the various error checks an event should pass before it can be
considered valid. Ensure that the potential scheduling failure
of a pinned event is checked for and
Local register variables were used in an effort to improve the
accuracy of the measurement of cache residency of a pseudo-locked
region. This was done to ensure that only the cache residency of
the memory is measured and not the cache residency of the variables
used to perform the measurement.
Whi
A perf event has many attributes that are maintained in a separate
structure that should be provided when a new perf_event is created.
In preparation for the transition to perf_events the required attribute
structures are created for all the events that may be used in the
measurements. Most attrib
On Fri, 2018-08-17 at 01:19 +0530, Nishad Kamdar wrote:
> Use the identifier __func__ instead of gcc specific __FUNCTION__
> in dbg.h. Limit these lines to 80 characters. Issues found by
> checkpatch.
It looks like there are 4 uses in -next
drivers/staging/mt7621-mmc/dbg.h:110:host->i
Hi,
On Wed, Aug 15, 2018 at 4:13 AM, Mark Brown wrote:
> On Tue, Aug 14, 2018 at 04:56:42PM -0700, Doug Anderson wrote:
>
>> IMO about the best we could hope to do would be to map "mode" from
>> children to parent. AKA: perhaps you could assume that if a child is
>> in a higher power mode that p
[
Jens, you want to take this one, or do you want me to?
]
From: "Steven Rostedt (VMware)"
Masami Hiramatsu reported:
Current trace-enable attribute in sysfs returns an error
if user writes the same setting value as current one,
e.g.
# cat /sys/block/sda/trace/enable
0
# ec
Here's a collection of pinctrl fixes for the qcom driver that
make things a little smoother for DT writers while also fixing
a problem seen with level triggered interrupts.
The first patch fixes an issue where we always see one extra level
triggered interrupt when the interrupt triggers. The secon
The interrupt controller hardware in this pin controller has two status
enable bits. The first "normal" status enable bit enables or disables
the summary interrupt line being raised when a gpio interrupt triggers
and the "raw" status enable bit allows or prevents the hardware from
latching an inter
When requesting a gpio as an interrupt, we should make sure to mux the
pin as the GPIO function and configure it to be an input so that various
functions or output signals don't affect the interrupt state of the pin.
So far, we've relied on pinmux configurations in DT to handle this, but
let's expl
We rely on devices to use pinmuxing configurations in DT to select the
GPIO function (function 0) if they're going to use the gpio in GPIO
mode. Let's simplify things for driver authors by implementing
gpio_request_enable() for this pinctrl driver to mux out the GPIO
function when the gpio is use f
Dan,
Thank you for the patch.
I didn't review DT parsing details in v3, but now I've produced
diff between v3 and v4 to check what has changed.
I'm quite surprised realizing that you're not validating
HVLED and control banks assignment, having in mind earlier
discussions and your concerns about
1 - 100 of 540 matches
Mail list logo
