On Wed, 8 Aug 2018 12:13:37 -0700, Matthias Kaehlcke wrote:
> The documentation of Qualcomm's SPMI PMIC voltage ADC claims that the
> 'reg' property consists of two values, the SPMI address and the length
> of the controller's registers. However the SPMI bus to which it is added
> specifies
On Wed, 8 Aug 2018 12:13:37 -0700, Matthias Kaehlcke wrote:
> The documentation of Qualcomm's SPMI PMIC voltage ADC claims that the
> 'reg' property consists of two values, the SPMI address and the length
> of the controller's registers. However the SPMI bus to which it is added
> specifies
On Tue, Aug 14, 2018 at 10:16 AM, Paolo Bonzini wrote:
> Is there anything that was changed in syzkaller and is causing it to
> find all these bugs?
Nothing has changed on syzkaller side as far as I can tell.
> On 14/08/2018 14:46, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash
On Tue, Aug 14, 2018 at 10:16 AM, Paolo Bonzini wrote:
> Is there anything that was changed in syzkaller and is causing it to
> find all these bugs?
Nothing has changed on syzkaller side as far as I can tell.
> On 14/08/2018 14:46, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash
On Tue, 7 Aug 2018 18:18:25 +0200, Krzysztof Kozlowski wrote:
> Replace GPL v2.0 and v2.0+ license statements with SPDX license
> identifiers.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/regulator/max14577-regulator.c | 22 +
>
On Tue, 7 Aug 2018 18:18:25 +0200, Krzysztof Kozlowski wrote:
> Replace GPL v2.0 and v2.0+ license statements with SPDX license
> identifiers.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/regulator/max14577-regulator.c | 22 +
>
On Tue, 7 Aug 2018 18:17:12 +0200, Krzysztof Kozlowski wrote:
> Replace GPL v2.0 and v2.0+ license statements with SPDX license
> identifiers.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/clk/clk-s2mps11.c | 21 +
>
On Tue, 7 Aug 2018 18:17:12 +0200, Krzysztof Kozlowski wrote:
> Replace GPL v2.0 and v2.0+ license statements with SPDX license
> identifiers.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/clk/clk-s2mps11.c | 21 +
>
On Tue, 7 Aug 2018 18:17:13 +0200, Krzysztof Kozlowski wrote:
> The clock IDs must match between DeviceTree bindings and the driver.
> There is already a header file used by DeviceTree sources so include it
> in the driver to remove duplicated symbols.
>
> Signed-off-by: Krzysztof Kozlowski
>
On Tue, 7 Aug 2018 18:17:13 +0200, Krzysztof Kozlowski wrote:
> The clock IDs must match between DeviceTree bindings and the driver.
> There is already a header file used by DeviceTree sources so include it
> in the driver to remove duplicated symbols.
>
> Signed-off-by: Krzysztof Kozlowski
>
On Thu, Aug 09, 2018 at 11:03:11AM +0800, Baolin Wang wrote:
> Hi Trent,
>
> On 9 August 2018 at 02:57, Trent Piepho wrote:
> > On Wed, 2018-08-08 at 11:54 +0100, Mark Brown wrote:
> >> On Wed, Aug 08, 2018 at 06:35:28PM +0800, Baolin Wang wrote:
> >> > On 8 August 2018 at 17:50, Mark Brown
On Thu, Aug 09, 2018 at 11:03:11AM +0800, Baolin Wang wrote:
> Hi Trent,
>
> On 9 August 2018 at 02:57, Trent Piepho wrote:
> > On Wed, 2018-08-08 at 11:54 +0100, Mark Brown wrote:
> >> On Wed, Aug 08, 2018 at 06:35:28PM +0800, Baolin Wang wrote:
> >> > On 8 August 2018 at 17:50, Mark Brown
> -Original Message-
> From: Michael Jin
> Sent: Friday, August 10, 2018 2:36 PM
> To: Borislav Petkov ; Ghannam, Yazen
> ; Mauro Carvalho Chehab
>
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Jin
>
> Subject: [PATCH] EDAC, amd64: Add Family 17h Model 11h
> -Original Message-
> From: Michael Jin
> Sent: Friday, August 10, 2018 2:36 PM
> To: Borislav Petkov ; Ghannam, Yazen
> ; Mauro Carvalho Chehab
>
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Michael Jin
>
> Subject: [PATCH] EDAC, amd64: Add Family 17h Model 11h
On Tue, Aug 07, 2018 at 06:43:37PM +0800, Baolin Wang wrote:
> From: Lanqing Liu
>
> This patch adds the binding documentation for Spreadtrum SPI
> controller device.
>
> Signed-off-by: Lanqing Liu
> Signed-off-by: Baolin Wang
> ---
> Documentation/devicetree/bindings/spi/spi-sprd.txt | 31
On Tue, Aug 07, 2018 at 06:43:37PM +0800, Baolin Wang wrote:
> From: Lanqing Liu
>
> This patch adds the binding documentation for Spreadtrum SPI
> controller device.
>
> Signed-off-by: Lanqing Liu
> Signed-off-by: Baolin Wang
> ---
> Documentation/devicetree/bindings/spi/spi-sprd.txt | 31
On Tue, Aug 14, 2018 at 11:02 AM Guenter Roeck wrote:
>
> On Tue, Aug 14, 2018 at 10:20:32AM -0700, Linus Torvalds wrote:
> > On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck wrote:
> > >
> > > Does that mean that gcc 4.5 and older are now officially no longer
> > > supported for compiling the
On Tue, Aug 14, 2018 at 11:02 AM Guenter Roeck wrote:
>
> On Tue, Aug 14, 2018 at 10:20:32AM -0700, Linus Torvalds wrote:
> > On Tue, Aug 14, 2018 at 10:09 AM Guenter Roeck wrote:
> > >
> > > Does that mean that gcc 4.5 and older are now officially no longer
> > > supported for compiling the
On Mon, 6 Aug 2018 22:14:12 -0700, Douglas Anderson
wrote:
> After the commit 8b1087fa3a27 ("phy: qcom-qmp: Fix dts bindings to
> reflect reality") landed there was some review feedback that 'reg'
> should have been documented differently. Fix it as per review
> feedback.
>
> As per that
On Mon, 6 Aug 2018 22:14:12 -0700, Douglas Anderson
wrote:
> After the commit 8b1087fa3a27 ("phy: qcom-qmp: Fix dts bindings to
> reflect reality") landed there was some review feedback that 'reg'
> should have been documented differently. Fix it as per review
> feedback.
>
> As per that
On Tue, Aug 14, 2018 at 11:19 AM, Rob Herring wrote:
Hi Nava,
I didn't see this posting because it wasn't sent to my current email
address or to the linux-fpga mailing list. People's email address
change at random times, so the easiest way to keep up is to always
check out the linux-next
On Tue, Aug 14, 2018 at 11:19 AM, Rob Herring wrote:
Hi Nava,
I didn't see this posting because it wasn't sent to my current email
address or to the linux-fpga mailing list. People's email address
change at random times, so the easiest way to keep up is to always
check out the linux-next
Hi,
On Tue, Aug 14, 2018 at 11:30 AM, David Collins wrote:
> The behavior introduced by this patch seems like an undesirable hack to
> me. It goes against the general philosophy within the regulator framework
> of taking no action unless directed to do so by an explicit consumer
> request (or
Hi,
On Tue, Aug 14, 2018 at 11:30 AM, David Collins wrote:
> The behavior introduced by this patch seems like an undesirable hack to
> me. It goes against the general philosophy within the regulator framework
> of taking no action unless directed to do so by an explicit consumer
> request (or
Under high IO activity (storage or network), the kernel is not
accounting some cpu cycles, comparing sar vs emon (tool that accesses hw
pmu directly). The difference is higher on cores that spend most time on
idle state and are constantly waking up to handle interrupts. It happens
even with fine
Under high IO activity (storage or network), the kernel is not
accounting some cpu cycles, comparing sar vs emon (tool that accesses hw
pmu directly). The difference is higher on cores that spend most time on
idle state and are constantly waking up to handle interrupts. It happens
even with fine
On Tue, 14 Aug 2018 at 11:09, Kim Phillips wrote:
>
> On Tue, 14 Aug 2018 10:15:56 -0600
> Mathieu Poirier wrote:
>
> > On Mon, 13 Aug 2018 at 11:46, Kim Phillips wrote:
> > > It yields success for the --per-thread case..:
> > >
> > > $ sudo taskset -c 0 ./perf record -e cs_etm/@2001.etf/
On Tue, 14 Aug 2018 at 11:09, Kim Phillips wrote:
>
> On Tue, 14 Aug 2018 10:15:56 -0600
> Mathieu Poirier wrote:
>
> > On Mon, 13 Aug 2018 at 11:46, Kim Phillips wrote:
> > > It yields success for the --per-thread case..:
> > >
> > > $ sudo taskset -c 0 ./perf record -e cs_etm/@2001.etf/
Tried to compile current git (v4.18-1934-gbe718b524d8d) with AMD KVM and
got the following linking error:
MODPOST vmlinux.o
ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities':
x86.c:(.text+0x5132): undefined reference to `l1tf_vmx_mitigation'
#
# Automatically generated file; DO
Tried to compile current git (v4.18-1934-gbe718b524d8d) with AMD KVM and
got the following linking error:
MODPOST vmlinux.o
ld: arch/x86/kvm/x86.o: in function `kvm_get_arch_capabilities':
x86.c:(.text+0x5132): undefined reference to `l1tf_vmx_mitigation'
#
# Automatically generated file; DO
Let gcc know it is not meant to be NUL-terminated by annotating with
the new __nonstring variable attribute; and remove the comment since it
conveys the same information.
Cc: Willy Tarreau
Cc: Ingo Molnar
Cc: Josh Poimboeuf
Cc: Kees Cook
Cc: Geert Uytterhoeven
Cc: Will Deacon
Cc: David
Let gcc know it is not meant to be NUL-terminated by annotating with
the new __nonstring variable attribute; and remove the comment since it
conveys the same information.
Cc: Willy Tarreau
Cc: Ingo Molnar
Cc: Josh Poimboeuf
Cc: Kees Cook
Cc: Geert Uytterhoeven
Cc: Will Deacon
Cc: David
>From the GCC manual:
The nonstring variable attribute specifies that an object or member
declaration with type array of char, signed char, or unsigned char,
or pointer to such a type is intended to store character arrays that
do not necessarily contain a terminating NUL. This is useful
>From the GCC manual:
The nonstring variable attribute specifies that an object or member
declaration with type array of char, signed char, or unsigned char,
or pointer to such a type is intended to store character arrays that
do not necessarily contain a terminating NUL. This is useful
Daniel Díaz wrote on Tue, Aug 14, 2018:
> I can't get cpupower to compile anymore now that it made its way to
> linux-next:
> [/linux/tools/power/cpupower]$ make
> CC lib/cpufreq.o
> [...]
> make[1]: Entering directory '/linux/tools/power/cpupower/bench'
> CC main.o
>
Daniel Díaz wrote on Tue, Aug 14, 2018:
> I can't get cpupower to compile anymore now that it made its way to
> linux-next:
> [/linux/tools/power/cpupower]$ make
> CC lib/cpufreq.o
> [...]
> make[1]: Entering directory '/linux/tools/power/cpupower/bench'
> CC main.o
>
On Sat, Aug 04, 2018 at 09:03:49AM +0200, Emmanuel Vadot wrote:
> This patch adds documentation for Device-Tree bindings for the Allwinner
> Thermal Sensor Controller found on the H3, H5 and A64 SoCs
>
> Signed-off-by: Emmanuel Vadot
> ---
> .../bindings/thermal/allwinner-thermal.txt| 41
On Sat, Aug 04, 2018 at 09:03:49AM +0200, Emmanuel Vadot wrote:
> This patch adds documentation for Device-Tree bindings for the Allwinner
> Thermal Sensor Controller found on the H3, H5 and A64 SoCs
>
> Signed-off-by: Emmanuel Vadot
> ---
> .../bindings/thermal/allwinner-thermal.txt| 41
Hi Linus,
[Jason Gunthorpe (author of the patch in this set) and I discussed
in which tree this file should be. Since anyway I will maintain it
and there is no specific tree (that we know of) for this, I just
created a branch in my github account.]
Please pick this improvement for the
Hi Linus,
[Jason Gunthorpe (author of the patch in this set) and I discussed
in which tree this file should be. Since anyway I will maintain it
and there is no specific tree (that we know of) for this, I just
created a branch in my github account.]
Please pick this improvement for the
From: Stephen Hemminger Sent: Tuesday, August 14,
2018 9:35 AM
> On Mon, 13 Aug 2018 19:30:50 +
> "Michael Kelley (EOSG)" wrote:
>
> > > +/*
> > > + * Return a matching hv_vmbus_device_id pointer.
> > > + * If there is no match, return NULL.
> > > + */
> > > +static const struct
From: Stephen Hemminger Sent: Tuesday, August 14,
2018 9:35 AM
> On Mon, 13 Aug 2018 19:30:50 +
> "Michael Kelley (EOSG)" wrote:
>
> > > +/*
> > > + * Return a matching hv_vmbus_device_id pointer.
> > > + * If there is no match, return NULL.
> > > + */
> > > +static const struct
On Tue, 2018-08-14 at 14:41 -0400, J. Bruce Fields wrote:
> This version looks correct to me, and simpler. I'll be curious to hear
> whatever you learn from testing!
>
> --b.
>
Agreed. I'll go ahead and put this in linux-next with an eye toward
merging in v4.20 if we don't hit any major
On Tue, 2018-08-14 at 14:41 -0400, J. Bruce Fields wrote:
> This version looks correct to me, and simpler. I'll be curious to hear
> whatever you learn from testing!
>
> --b.
>
Agreed. I'll go ahead and put this in linux-next with an eye toward
merging in v4.20 if we don't hit any major
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
> git tree: linux-next
I fetched linux-next but don't have 5ed5da74de9e.
I'm also not sure why
On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following crash on:
>
> HEAD commit:5ed5da74de9e Add linux-next specific files for 20180813
> git tree: linux-next
I fetched linux-next but don't have 5ed5da74de9e.
I'm also not sure why
Hi Linus,
Please pull these two small auxdisplay cleanups for 4.19.
Cheers,
Miguel Ojeda
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
are available in the Git repository at:
https://github.com/ojeda/linux.git
Hi Linus,
Please pull these two small auxdisplay cleanups for 4.19.
Cheers,
Miguel Ojeda
The following changes since commit acb1872577b346bd15ab3a3f8dff780d6cca4b70:
Linux 4.18-rc7 (2018-07-29 14:44:52 -0700)
are available in the Git repository at:
https://github.com/ojeda/linux.git
Hi Peter,
A QA tester here has noticed that he can regularly provoke a
"rq->clock_update_flags & RQCF_UPDATED" warning when echo'ing into the
debugfs sched_features file:
% echo WARN_DOUBLE_CLOCK > /sys/kernel/debug/sched_features
...
[ cut here ]
rq->clock_update_flags
Hi Peter,
A QA tester here has noticed that he can regularly provoke a
"rq->clock_update_flags & RQCF_UPDATED" warning when echo'ing into the
debugfs sched_features file:
% echo WARN_DOUBLE_CLOCK > /sys/kernel/debug/sched_features
...
[ cut here ]
rq->clock_update_flags
On Tue, Aug 14, 2018 at 11:51 AM Vlastimil Babka wrote:
>
> The introduction of generic_max_swapfile_size and arch-specific versions has
> broken linking on x86 with CONFIG_SWAP=n due to undefined reference to
> 'generic_max_swapfile_size'. Fix it by compiling the x86-specific
>
On Tue, Aug 14, 2018 at 11:51 AM Vlastimil Babka wrote:
>
> The introduction of generic_max_swapfile_size and arch-specific versions has
> broken linking on x86 with CONFIG_SWAP=n due to undefined reference to
> 'generic_max_swapfile_size'. Fix it by compiling the x86-specific
>
On 8/14/18 1:45 PM, Sean Wang wrote:
> Hi, Gustavo
>
> thanks for the catch up
Glad to help. :)
>
> Acked-by: Sean Wang
>
Thanks
--
Gustavo
On 8/14/18 1:45 PM, Sean Wang wrote:
> Hi, Gustavo
>
> thanks for the catch up
Glad to help. :)
>
> Acked-by: Sean Wang
>
Thanks
--
Gustavo
On Tue, Aug 14, 2018 at 07:16:23PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.120 release.
> There are 107 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, Aug 14, 2018 at 07:16:23PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.120 release.
> There are 107 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
(Please use contextual quoting in replies... mixing contextual with
top-posting becomes very hard to read...)
On Tue, Aug 14, 2018 at 6:02 AM, Yuanxiaofeng (XiAn)
wrote:
> On Tue, Aug 14, 2018 at 8:35PM Matthew Wilcox wrote:
>> On Tue, Aug 14, 2018 at 08:17:31PM +0800, Xiaofeng Yuan wrote:
>>>
(Please use contextual quoting in replies... mixing contextual with
top-posting becomes very hard to read...)
On Tue, Aug 14, 2018 at 6:02 AM, Yuanxiaofeng (XiAn)
wrote:
> On Tue, Aug 14, 2018 at 8:35PM Matthew Wilcox wrote:
>> On Tue, Aug 14, 2018 at 08:17:31PM +0800, Xiaofeng Yuan wrote:
>>>
The introduction of generic_max_swapfile_size and arch-specific versions has
broken linking on x86 with CONFIG_SWAP=n due to undefined reference to
'generic_max_swapfile_size'. Fix it by compiling the x86-specific
max_swapfile_size() only with CONFIG_SWAP=y.
Reported-by: Tomas Pruzina
Fixes:
Hi,
I just wanted to check if you would be interested in a list of Managed
Service Providers (MSPs) and Managed Security Service Providers (MSSPs)?
We also have the data intelligence of:
• Managed Service Providers (MSP’s)
• Managed Security Service Providers (MSSP’s)
• IT
The introduction of generic_max_swapfile_size and arch-specific versions has
broken linking on x86 with CONFIG_SWAP=n due to undefined reference to
'generic_max_swapfile_size'. Fix it by compiling the x86-specific
max_swapfile_size() only with CONFIG_SWAP=y.
Reported-by: Tomas Pruzina
Fixes:
Hi,
I just wanted to check if you would be interested in a list of Managed
Service Providers (MSPs) and Managed Security Service Providers (MSSPs)?
We also have the data intelligence of:
• Managed Service Providers (MSP’s)
• Managed Security Service Providers (MSSP’s)
• IT
Yes, I can confirm that patch. It is the same change I already compiled
and installed and is running on my system successfully.
> On Mon, Aug 13, 2018 at 02:41:23PM -0500, Bjorn Helgaas wrote:
>> Hi,
>>
>> Thanks a lot for your new report
>>
Yes, I can confirm that patch. It is the same change I already compiled
and installed and is running on my system successfully.
> On Mon, Aug 13, 2018 at 02:41:23PM -0500, Bjorn Helgaas wrote:
>> Hi,
>>
>> Thanks a lot for your new report
>>
Hi, Gustavo
thanks for the catch up
Acked-by: Sean Wang
On Tue, 2018-08-14 at 10:10 -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were allocated, release them before
> return.
>
> Addresses-Coverity-ID: 1472611 ("Resource leak")
> Fixes: 7237c4c9ec92 ("Bluetooth:
Hi, Gustavo
thanks for the catch up
Acked-by: Sean Wang
On Tue, 2018-08-14 at 10:10 -0500, Gustavo A. R. Silva wrote:
> In case memory resources for *fw* were allocated, release them before
> return.
>
> Addresses-Coverity-ID: 1472611 ("Resource leak")
> Fixes: 7237c4c9ec92 ("Bluetooth:
This version looks correct to me, and simpler. I'll be curious to hear
whatever you learn from testing!
--b.
On Tue, Aug 14, 2018 at 01:56:51PM +1000, NeilBrown wrote:
>
> V2, which added wake_non_conflicts() was more broken than V1 - as
> Bruce explained there is no transitivity in the
This version looks correct to me, and simpler. I'll be curious to hear
whatever you learn from testing!
--b.
On Tue, Aug 14, 2018 at 01:56:51PM +1000, NeilBrown wrote:
>
> V2, which added wake_non_conflicts() was more broken than V1 - as
> Bruce explained there is no transitivity in the
On Tue, Aug 14, 2018 at 02:34:51PM -0400, Steven Rostedt wrote:
> On Tue, 14 Aug 2018 10:44:43 -0700
> "Paul E. McKenney" wrote:
>
> > > > If I recall correctly, this subterfuge suppresses compiler complaints
> > > > about initializing an unsigned long with a negative number. :-/
> > >
> > >
On Tue, Aug 14, 2018 at 02:34:51PM -0400, Steven Rostedt wrote:
> On Tue, 14 Aug 2018 10:44:43 -0700
> "Paul E. McKenney" wrote:
>
> > > > If I recall correctly, this subterfuge suppresses compiler complaints
> > > > about initializing an unsigned long with a negative number. :-/
> > >
> > >
On Tue, 14 Aug 2018 10:44:43 -0700
"Paul E. McKenney" wrote:
> > > If I recall correctly, this subterfuge suppresses compiler complaints
> > > about initializing an unsigned long with a negative number. :-/
> >
> > Did you try:
> >
> > .srcu_gp_seq_needed = -1UL,
> >
> > ?
>
> Works
On Tue, 14 Aug 2018 10:44:43 -0700
"Paul E. McKenney" wrote:
> > > If I recall correctly, this subterfuge suppresses compiler complaints
> > > about initializing an unsigned long with a negative number. :-/
> >
> > Did you try:
> >
> > .srcu_gp_seq_needed = -1UL,
> >
> > ?
>
> Works
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2018.08.05a
head: 4ad5aae97b17143dae19dcef5984c5e47417064a
commit: 411ec41811aa1c759a8c717edf917f9f00ca731e [251/252] srcu: Make
call_srcu() available during very early boot
config: ia64-allnoconfig (attached as
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2018.08.05a
head: 4ad5aae97b17143dae19dcef5984c5e47417064a
commit: 411ec41811aa1c759a8c717edf917f9f00ca731e [251/252] srcu: Make
call_srcu() available during very early boot
config: ia64-allnoconfig (attached as
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C contollers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
Any feedback would be appreciated.
v3 -> v2:
- fix dt binding: compatible name: ommit "bus"
v2 -> v1:
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C contollers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
Any feedback would be appreciated.
v3 -> v2:
- fix dt binding: compatible name: ommit "bus"
v2 -> v1:
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C contollers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
Any feedback would be appreciated.
v3 -> v2:
- fix dt binding: compatible name: ommit "bus"
v2 -> v1:
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C contollers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
Any feedback would be appreciated.
v3 -> v2:
- fix dt binding: compatible name: ommit "bus"
v2 -> v1:
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C contollers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
Any feedback would be appreciated.
v3 -> v2:
- fix dt binding: compatible name: ommit "bus"
v2 -> v1:
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C contollers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
Any feedback would be appreciated.
v3 -> v2:
- fix dt binding: compatible name: ommit "bus"
v2 -> v1:
Hello Doug,
On 08/14/2018 10:06 AM, Douglas Anderson wrote:
> Not all regulator consumers call regulator_set_load(). On some
> regulators (like on RPMh-regulator) this could be bad since the
> regulator framework will treat this as if consumer needs no load.
> It's much better to assume that a
Hello Doug,
On 08/14/2018 10:06 AM, Douglas Anderson wrote:
> Not all regulator consumers call regulator_set_load(). On some
> regulators (like on RPMh-regulator) this could be bad since the
> regulator framework will treat this as if consumer needs no load.
> It's much better to assume that a
On 08/14/2018 11:17 AM, Petr Machata wrote:
> Florian Fainelli writes:
>
>> On 06/25/2018 02:17 AM, Ilias Apalodimas wrote:
>>> On Mon, Jun 25, 2018 at 12:13:10PM +0300, Petr Machata wrote:
Florian Fainelli writes:
> if (netif_is_bridge_master(vlan->obj.orig_dev))
> -
On 08/14/2018 11:17 AM, Petr Machata wrote:
> Florian Fainelli writes:
>
>> On 06/25/2018 02:17 AM, Ilias Apalodimas wrote:
>>> On Mon, Jun 25, 2018 at 12:13:10PM +0300, Petr Machata wrote:
Florian Fainelli writes:
> if (netif_is_bridge_master(vlan->obj.orig_dev))
> -
On Tue, 14 Aug 2018, David Jacobson wrote:
> This patchset introduces evmtest — a stand alone tool for regression
> testing IMA.
Nice!
I usually run the SELinux testsuite as a general sanity check of LSM
before pushing to Linus, and I'll also run this once it's merged.
--
James Morris
On Tue, 14 Aug 2018, David Jacobson wrote:
> This patchset introduces evmtest — a stand alone tool for regression
> testing IMA.
Nice!
I usually run the SELinux testsuite as a general sanity check of LSM
before pushing to Linus, and I'll also run this once it's merged.
--
James Morris
On Wed, Jul 25, 2018 at 05:02:59PM -0600, Jon Derrick wrote:
> Currently, a hotplug bridge will be given hpmemsize additional memory if
> available, in order to satisfy any future hotplug allocation
> requirements.
>
> These calculations don't consider the current memory size of the hotplug
>
On Wed, Jul 25, 2018 at 05:02:59PM -0600, Jon Derrick wrote:
> Currently, a hotplug bridge will be given hpmemsize additional memory if
> available, in order to satisfy any future hotplug allocation
> requirements.
>
> These calculations don't consider the current memory size of the hotplug
>
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Gleixner
Avoid the conditional in the L1D flush control path.
Signed-off-by: Thomas Gleixner
Tested-by: Jiri Kosina
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Josh Poimboeuf
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Gleixner
Avoid the conditional in the L1D flush control path.
Signed-off-by: Thomas Gleixner
Tested-by: Jiri Kosina
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Josh Poimboeuf
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Nicolai Stange
The vmx_l1d_flush_always static key is only ever evaluated if
vmx_l1d_should_flush is enabled. In that case however, there are only two
L1d flushing modes possible: "always" and
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Nicolai Stange
The vmx_l1d_flush_always static key is only ever evaluated if
vmx_l1d_should_flush is enabled. In that case however, there are only two
L1d flushing modes possible: "always" and
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit 119e1ef80ecfe0d1deb6378d4ab41f5b71519de1 upstream.
__legitimize_mnt() has two problems - one is that in case of success
the check of mount_lock is not ordered wrt preceding
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Al Viro
commit 119e1ef80ecfe0d1deb6378d4ab41f5b71519de1 upstream.
__legitimize_mnt() has two problems - one is that in case of success
the check of mount_lock is not ordered wrt preceding
Em Tue, Aug 14, 2018 at 09:27:26AM +0200, Jiri Olsa escreveu:
> On Tue, Aug 14, 2018 at 11:47:39AM +1000, Michael Ellerman wrote:
> > Jiri Olsa writes:
> > > diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
> > > index ea48aa6f8d19..9d466e853aec 100755
> > > ---
Em Tue, Aug 14, 2018 at 09:27:26AM +0200, Jiri Olsa escreveu:
> On Tue, Aug 14, 2018 at 11:47:39AM +1000, Michael Ellerman wrote:
> > Jiri Olsa writes:
> > > diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
> > > index ea48aa6f8d19..9d466e853aec 100755
> > > ---
evmtest tests functionality of different IMA-Appraisal policies.
To simplify testing, this patch defines an evmtest config file. This
allows for running all tests at once, rather than invoking each test
individually. Variables can be set once rather than specifying
parameters at runtime on the
With secure boot enabled, the bootloader verifies the kernel image's
signature before transferring control to it. With Linux as the
bootloader running with secure boot enabled, kexec needs to verify the
kernel image's signature.
This patch defined a new test named "kexec_sig", which first
The first record in the IMA runtime measurement list is the boot
aggregate - a hash of PCRs 0-7. This test calculates the boot aggregate
based off the PCRs and compares it to IMA's boot aggregate.
Dependencies: a TPM, IBMTSS2.
Signed-off-by: David Jacobson
---
With secure boot enabled, the bootloader verifies the kernel image's
signature before transferring control to it. With Linux as the
bootloader running with secure boot enabled, kexec needs to verify the
kernel image's signature.
This patch defined a new test named "kexec_sig", which first
201 - 300 of 1640 matches
Mail list logo
