We don't want to expose page to fast gup running on a remote CPU
before all local non-atomic ops on page flags are visible first.
For anon page that isn't in swap cache, we need to make sure all
prior non-atomic ops, especially __SetPageSwapBacked() in
page_add_new_anon_rmap(), are order before se
From: Youquan Song
If the CPU package has the less logical CPU than topo_max_cpus, but un-present
CPU's punit_cpu_core will be initiated to 0 and they will be count to core 0
Like below, there are only 10 high priority cores (20 logical CPUs) in the CPU
package, but it count to 27 logic CPUs.
.
Fix wrong debug print for cpu, which is displayed as CLOS. Also
avoid printing clos id, when user is specify clos as parameter.
Signed-off-by: Srinivas Pandruvada
---
tools/power/x86/intel-speed-select/isst-config.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/powe
Format the get-assoc command output consistant with other commands.
For example:
Intel(R) Speed Select Technology
Executing on CPU model:142[0x8e]
package-0
die-0
cpu-0
get-assoc
clos:0
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 1
This series contains some minor fixes, when firmware mask is including
invalid CPU in the perf-profile mask. Also add some commands to
better manage core-power feature.
Srinivas Pandruvada (4):
tools/power/x86/intel-speed-select: Allow online/offline based on tdp
tools/power/x86/intel-speed-se
Using enable core mask, do online offline CPUs. There is a new option
--online|-o for set-config-level.
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 52 ++-
tools/power/x86/intel-speed-select/isst.h | 2 +
2 files changed, 52 inserti
Add additional command to get the clos enable and priority type. The
current info option is actually dumping per clos QOS config, so name
the command appropriately to get-config.
Signed-off-by: Srinivas Pandruvada
---
.../x86/intel-speed-select/isst-config.c | 36 ++-
.../po
Hi
On 2019-09-14, Greg Kroah-Hartman wrote:
> On Sat, Sep 14, 2019 at 02:54:11AM +0200, Stefan Lippers-Hollmann wrote:
> > On 2019-09-13, Greg Kroah-Hartman wrote:
> > > From: Michael S. Tsirkin
> > >
> > > commit a89db445fbd7f1f8457b03759aa7343fa530ef6b upstream.
> > >
> > > iovec addresses comi
Le 03/09/2019 à 07:23, Alastair D'Silva a écrit :
From: Alastair D'Silva
When calling flush_icache_range with a size >4GB, we were masking
off the upper 32 bits, so we would incorrectly flush a range smaller
than intended.
This patch replaces the 32 bit shifts with 64 bit ones, so that
the
On Sat, Sep 14, 2019 at 12:26:40AM -0400, Naresh Kamboju wrote:
> On Fri, 13 Sep 2019 at 09:21, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 5.2.15 release.
> > There are 37 patches in this series, all will be posted as a response
> > to this one. If an
Applied, thanks Teawater!
On Sat, Sep 14, 2019 at 11:07:18AM +0800, Hui Zhu wrote:
usemem will read memory again after access the memory with this option.
It can help test the speed that load page from swap to memory.
Signed-off-by: Hui Zhu
---
usemem.c | 46 +++
On Sat, Sep 14, 2019 at 09:15:48AM +0200, Stefan Lippers-Hollmann wrote:
> Hi
>
> On 2019-09-14, Greg Kroah-Hartman wrote:
> > On Sat, Sep 14, 2019 at 02:54:11AM +0200, Stefan Lippers-Hollmann wrote:
> > > On 2019-09-13, Greg Kroah-Hartman wrote:
> > > > From: Michael S. Tsirkin
> > > >
> > > > c
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.193 release.
There are 14 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 know.
Responses should be made
On Sat, Sep 14, 2019 at 01:28:39AM -0700, Guenter Roeck wrote:
> On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.193 release.
> > There are 14 patches in this series, all will be posted as a response
> > to this one. If anyone has any issu
Pierre-Louis Bossart 於
2019年9月14日 週六 上午1:28寫道：
>
> please don't top-post on public mailing lists, thanks.
>
> On 9/13/19 9:45 AM, Yu-Hsuan Hsu wrote:
> > Thanks for the review! If I'm not mistaken, the microphone is attached
> > to external codec(rt5514) instead of PCH on Kabylake platform. So the
On 9/14/19 1:31 AM, Greg Kroah-Hartman wrote:
On Sat, Sep 14, 2019 at 01:28:39AM -0700, Guenter Roeck wrote:
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.193 release.
There are 14 patches in this series, all will be posted as a response
Building vhost on 32-bit targets results in the following error.
drivers/vhost/vhost.c: In function 'translate_desc':
include/linux/compiler.h:549:38: error:
call to '__compiletime_assert_1879' declared with attribute error:
BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
Fixes: a8
> Am 13.09.2019 um 17:37 schrieb Adam Ford :
>
> The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
> depending on commercial or industrial temperature ratings. This
> patch expands the thermal information to the limits of 90 and 105
> for alert and critical.
>
> For boards wh
On Thu, Sep 12, 2019 at 04:25:30AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Sep 12, 2019 at 05:44:21AM +0200, Ahmed S. Darwish wrote:
[...]
>
> > 1. Cutting down the number of bits needed to initialize the CRNG
> >to 256 bits (CHACHA20 cipher)
>
> Does the attach patch (see below) hel
> Instead of calling memset:
>
> 8100cd8d: e8 0e 15 7a 00 callq 817ae2a0
> <__memset>
>
> and having a JMP inside it depending on the feature supported, let's simply
> have the REP; STOSB directly in the code:
>
> ...
> 81000442: 4c 89 d7
Hi Nikolauss,
On 13/
09/2019 22:34, H. Nikolaus Schaller wrote:
[ ... ]
>> The governor continues to read the temperature and see the temperature
>> decrease, it does nothing.
>
> Ah, I think our misunderstanding is that the govenor "enables" and
> "disables" a set of OPPs. Rather it goes do
Hi Benoit,
Thank you for the patch.
On Thu, Sep 12, 2019 at 1:58 PM Benoit Parrot wrote:
>
> Add powerdown-gpios to the list of optional properties for the OV2659
> camera sensor.
>
> Signed-off-by: Benoit Parrot
> ---
> Documentation/devicetree/bindings/media/i2c/ov2659.txt | 6 ++
> 1 fi
Hi Dave,
here's a pull request to net-next tree for v5.4, more info below. Please
let me know if there are any problems.
Kalle
The following changes since commit 172ca8308b0517ca2522a8c885755fd5c20294e7:
cxgb4: Fix spelling typos (2019-09-12 12:50:56 +0100)
are available in the git repositor
On Thu, Sep 12, 2019 at 02:23:54PM +0900, Masahiro Yamada wrote:
> This is unused.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/s390/Makefile | 3 ---
> 1 file changed, 3 deletions(-)
Applied, thanks.
On Tue, 03 Sep 2019 10:00:57 +1000
Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Mon, 02 Sep 2019 12:03:12 +1000
> > Michael Ellerman wrote:
> >
> >> Michal Suchanek writes:
> >> > On bigendian ppc64 it is common to have 32bit legacy binaries but much
> >> > less so on littleend
To improve the readability of raw slab trace points, print the call_site ip
using '%pS'. Then we can grep events with function names.
[002] 808.188897: kmem_cache_free: call_site=putname+0x47/0x50
ptr=cef40c80
[002] 808.188898: kfree: call_site=security_cred_free+0x42/0x50
Hi Benoit,
On Thu, Sep 12, 2019 at 1:58 PM Benoit Parrot wrote:
>
> On some board it is possible that the sensor 'powerdown'
> pin might be controlled with a gpio instead of being
> tied to always powered.
>
> This patch add support to specify an optional gpio
> which will be set at probe time an
Current memset() implementation does silly things:
* multiplication to get register-wide constant:
waste of cycles if filler is known at compile time,
* REP STOSQ followed by REP STOSB:
REP STOSB setup overhead is very high because trailing length
is very low (< 8)
* subop
Hi Thomas,
On Thu, Sep 12, 2019 at 04:09:12PM +0200, Thomas Bogendoerfer wrote:
> On Thu, Sep 12, 2019 at 03:55:39PM +0200, Thomas Bogendoerfer wrote:
> > - reserved[0xd] [0x00035bff8000-0x00035bff],
> > 0x8000 bytes flags: 0x0
> >
> > I have no idea which reservation
On 09/13/2019 03:54 AM, Ulf Hansson wrote:
> On Thu, 12 Sep 2019 at 22:18, Thara Gopinath
> wrote:
>>
>> On 09/12/2019 11:04 AM, Ulf Hansson wrote:
>>
>> Hi Ulf,
>>
>> Thanks for the review.
>>> On Tue, 10 Sep 2019 at 19:14, Thara Gopinath
>>> wrote:
Resources modeled as power domains
Now that the GPIO core has support for hierarchical IRQ chips, convert
Qualcomm's ssbi-gpio over to use these new helpers to reduce duplicated
code across drivers.
Signed-off-by: Brian Masney
---
Linus: I've only compile tested this driver. Hopefully you have time to
test this on your DragonBoard
On Sat, Sep 14, 2019 at 01:33:45PM +0300, Alexey Dobriyan wrote:
> --- a/arch/x86/include/asm/string_64.h
> +++ b/arch/x86/include/asm/string_64.h
> @@ -15,7 +15,111 @@ extern void *memcpy(void *to, const void *from, size_t
> len);
> extern void *__memcpy(void *to, const void *from, size_t len);
On Sat, Sep 14, 2019 at 12:29:15PM +0300, Alexey Dobriyan wrote:
> eh... I'd just drop it. These registers screw up everything.
The intent is to not touch memset_orig and let it die with its users. It
is irrelevant now anyway.
If it can be shown that the extended list of clobbered registers hurt
Remove unnecessary return statements from void functions reported by
checkpatch.
WARNING: void function return statements are not generally useful
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 5 -
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c |
On Fri, 13 Sep 2019 20:08:14 PDT (-0700), Paul Walmsley wrote:
Part of the intention during the definition of the RISC-V kernel image
header was to lay the groundwork for a future merge with the ARM64
image header. One error during my original review was not noticing
that the RISC-V header's "m
getrandom() has been created as a new and more secure interface for
pseudorandom data requests. Unlike /dev/urandom, it unconditionally
blocks until the entropy pool has been properly initialized.
While getrandom() has no guaranteed upper bound for its waiting time,
user-space has been abusing it
Add a count of the number of rcu users (currently 1) of the task
struct so that we can later add the scheduler case and get rid of the
very subtle task_rcu_dereference, and just use rcu_dereference.
As suggested by Oleg have the count overlap rcu_head so that no
additional space in task_struct i
In the ordinary case today the rcu grace period for a task_struct is
triggered when another process wait's for it's zombine and causes the
kernel to call release_task(). As the waiting task has to receive a
signal and then act upon it before this happens, typically this will
occur after the orig
Remove work arounds that were written before there was a grace period
after tasks left the runqueue in finish_task_switch.
In particular now that there tasks exiting the runqueue exprience
a rcu grace period none of the work performed by task_rcu_dereference
excpet the rcu_dereference is necessa
Add a count of the number of rcu users (currently 1) of the task
struct so that we can later add the scheduler case and get rid of the
very subtle task_rcu_dereference, and just use rcu_dereference.
As suggested by Oleg have the count overlap rcu_head so that no
additional space in task_struct i
In the ordinary case today the rcu grace period for a task_struct is
triggered when another process wait's for it's zombine and causes the
kernel to call release_task(). As the waiting task has to receive a
signal and then act upon it before this happens, typically this will
occur after the orig
Remove work arounds that were written before there was a grace period
after tasks left the runqueue in finish_task_switch.
In particular now that there tasks exiting the runqueue exprience
a rcu grace period none of the work performed by task_rcu_dereference
excpet the rcu_dereference is necessa
The current task on the runqueue is currently read with rcu_dereference().
To obtain ordinary rcu semantics for an rcu_dereference of rq->curr it needs
to be paird with rcu_assign_pointer of rq->curr. Which provides the
memory barrier necessary to order assignments to the task_struct
and the as
Hey Josh,
I'm seeing
arch/x86/kernel/cpu/mce/core.o: warning: objtool: mce_panic()+0x11b:
unreachable instruction
on a brand new debian install here with gcc9: gcc (Debian 9.2.1-4) 9.2.1
20190821
and thought should run it by you, you might've seen it already.
So mce_panic is at 8102f
Hi Christophe,
Thank you for the patch.
On Wed, Jul 24, 2019 at 06:56:12AM +0200, Christophe JAILLET wrote:
> It is likely that it should be UVC_METADATA_BUF_SIZE instead.
> Fix it and use it.
>
> Signed-off-by: Christophe JAILLET
Oops indeed. Applied to my tree for v5.5.
> ---
> drivers/med
On Fri, Sep 13, 2019 at 04:03:53PM +0100, David Howells wrote:
> Jarkko Sakkinen wrote:
>
> > Subject: [PATCH] MAINTAINERS: Add a git and a maintainer entry to keyring
> > subsystems
>
> I would recommend splitting the patch in two and putting something like:
>
> keys: Add Jarkko Sakkine
On Fri, Sep 13, 2019 at 10:36:15AM -0700, Joe Perches wrote:
> On Fri, 2019-09-13 at 16:03 +0100, David Howells wrote:
> > Jarkko Sakkinen wrote:
> >
> > > Subject: [PATCH] MAINTAINERS: Add a git and a maintainer entry to keyring
> > > subsystems
> >
> > I would recommend splitting the patch in
On Wed, 11 Sep 2019 05:54:07 PDT (-0700), m...@aurabindo.in wrote:
None of the available RiscV platforms that I’m aware of use compressed images,
unless there are some new bootloaders I haven’t seen yet.
I noticed that default build image is Image.gz, which is why I thought its a
good ide
Hi,
On Fri, Sep 13, 2019 at 03:09:19PM -0700, Tony Lindgren wrote:
> Also, we should not call prepare and unprepare except during init, and
> only call enable and disable during use.
Why? Usually clk_(un)prepare() is the part saving most power, so I
would expect the runtime resume handlers to cal
On Fri, Sep 13, 2019 at 08:51:36PM +0200, Roberto Sassu wrote:
> Commit 0b6cf6b97b7e ("tpm: pass an array of tpm_extend_digest structures to
> tpm_pcr_extend()") modifies tpm_pcr_extend() to accept a digest for each
> PCR bank. After modification, tpm_pcr_extend() expects that digests are
> passed
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Palmer Dabbelt
> Sent: Saturday, September 14, 2019 6:30 PM
> To: m...@aurabindo.in
> Cc: Troy Benjegerdes ; Paul Walmsley
> ; a...@eecs.berkeley.edu; linux-
> ri...@lists.infradead.org; l
From: Kalle Valo
Date: Sat, 14 Sep 2019 13:14:40 +0300
> here's a pull request to net-next tree for v5.4, more info below. Please
> let me know if there are any problems.
Pulled, thanks Kalle.
Hi.
I just noticed that this exfat-staging drivers are based on the old
Samsung's 1.x exFAT drivers.
I've been working to get the newer Samsung's driver(now named "sdFAT")
to fit better for general Linux users, and I believe it can provide a
better base for the community to work on(and hopeful
On Fri, Sep 13, 2019 at 01:38:18PM -0700, Dave Hansen wrote:
> On 9/3/19 7:26 AM, Jarkko Sakkinen wrote:
> > Not having LSM hooks does not cause any risk to other parts of the
> > kernel as the device can still be controlled by using DAC permissions.
> > The hooks just provide more granularity than
On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller wrote:
>
>
> > Am 13.09.2019 um 17:37 schrieb Adam Ford :
> >
> > The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
> > depending on commercial or industrial temperature ratings. This
> > patch expands the thermal information
On Sat, Sep 14, 2019 at 4:25 AM H. Nikolaus Schaller wrote:
>
>
> > Am 13.09.2019 um 17:37 schrieb Adam Ford :
> >
> > Because the omap34xx, omap36xx and am3517 SoC's have the same
> > thermal junction limits, there is no need to duplicate the entry
> > multiple times.
> >
> > This patch removes t
On Tue, Sep 10, 2019 at 02:50:39PM +0300, Denis Efremov wrote:
> Hi,
>
> On 8/16/19 9:58 PM, Jarkko Sakkinen wrote:
> > On Fri, Aug 16, 2019 at 01:12:00AM +0300, Denis Efremov wrote:
> >> Update MAINTAINERS record to reflect that trusted.h
> >> was moved to a different directory in commit 22447981
Audio devices needs exact clock rates in order to correctly reproduce
the sound. Until now, only integer factors were used to configure H6
audio PLL which resulted in inexact rates. Fix that by adding support
for fractional factors using sigma-delta modulation look-up table. It
contains values for
Linus,
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git
tags/riscv/for-v5.3
for you to fetch changes up to 474efecb65
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.4.193 release.
There are 9 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 know.
Responses should be made b
On Sat, 14 Sep 2019, Atish Patra wrote:
> Thanks for the quick fix. Is there a planned timeline when we can
> remove the deprecated magic ?
If Linus merges this patch, we should probably start the transition in the
bootloaders, QEMU, and user tools as quickly as possible. Probably the
key elem
Hi Tejun,
On Sat, Aug 31, 2019 at 6:01 AM Tejun Heo wrote:
>
> Hello,
>
> On Sat, Aug 31, 2019 at 12:03:26PM +0900, Namhyung Kim wrote:
> > Hmm.. it looks hard to use fhandle as the identifier since perf
> > sampling is done in NMI context. AFAICS the encode_fh part seems ok
> > but getting dent
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.144 release.
There are 21 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 know.
Responses should be made
On 9/13/19 6:04 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.73 release.
There are 190 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 know.
Responses should be made
On 9/13/19 6:07 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.2.15 release.
There are 37 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 know.
Responses should be made b
(resending without HTML this time, sorry for the duplicate)
14.09.2019 17:25, Ahmed S. Darwish пишет:
getrandom() has been created as a new and more secure interface for
pseudorandom data requests. Unlike /dev/urandom, it unconditionally
blocks until the entropy pool has been properly initialize
On Mon, Sep 09, 2019 at 01:49:06PM -0700, Tao Ren wrote:
> From: Heiner Kallweit
>
> This patch adds support for clause 37 1000Base-X auto-negotiation.
>
> Signed-off-by: Heiner Kallweit
> Signed-off-by: Tao Ren
> Tested-by: René van Dorst
Reviewed-by: Andrew Lunn
Andrew
On 9/13/19 6:06 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.193 release.
There are 14 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 know.
Responses should be made
There is an ongoing discussion on the choice of flag we want to care
about here. Therefore, please don't pull this patch until we reach an
agreement.
Thanks,
Mathieu
- On Sep 13, 2019, at 11:12 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> It has been reported by Google tha
On Tue, 2019-09-10 at 13:34 +0800, Jason Yan wrote:
> Hi Scott,
>
> On 2019/8/28 12:05, Scott Wood wrote:
> > On Fri, 2019-08-09 at 18:07 +0800, Jason Yan wrote:
> > > This series implements KASLR for powerpc/fsl_booke/32, as a security
> > > feature that deters exploit attempts relying on knowled
On Fri, 2019-08-23 at 12:50 +, Christophe Leroy wrote:
> On mpc83xx with a QE, IMMR is 2Mbytes.
> On mpc83xx without a QE, IMMR is 1Mbytes.
> Each driver will map a part of it to access the registers it needs.
> Some driver will map the same part of IMMR as other drivers.
>
> In order to reduc
> Am 14.09.2019 um 15:42 schrieb Adam Ford :
>
> On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> wrote:
>>
>>
>>> Am 13.09.2019 um 17:37 schrieb Adam Ford :
>>>
>>> The OMAP3530, AM3517 and DM3730 all show thresholds of 90C and 105C
>>> depending on commercial or industrial temperatu
On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
> On Thu, Sep 12, 2019 at 9:25 AM Theodore Y. Ts'o wrote:
> >
> > Hmm, one thought might be GRND_FAILSAFE, which will wait up to two
> > minutes before returning "best efforts" randomness and issuing a huge
> > massive warning if it i
On 9/10/19 2:59 PM, Dan Carpenter wrote:
On Sun, Sep 08, 2019 at 12:00:26PM +0300, Ivan Safonov wrote >> rtw_malloc
prevents the use of kmemdup/kzalloc and others.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/core/rtw_ap.c| 4 ++--
drivers/staging/rtl8188eu/core/rtw_m
On Sat, Sep 14, 2019 at 01:37:17PM +0200, Borislav Petkov wrote:
> On Sat, Sep 14, 2019 at 01:33:45PM +0300, Alexey Dobriyan wrote:
> > --- a/arch/x86/include/asm/string_64.h
> > +++ b/arch/x86/include/asm/string_64.h
> > @@ -15,7 +15,111 @@ extern void *memcpy(void *to, const void *from, size_t
>
On Fri, Sep 13, 2019 at 03:55:47PM -0700, Dmitry Torokhov wrote:
> The MDIO device reset line is optional and now that gpiod_get_optional()
> returns proper value when GPIO support is compiled out, there is no
> reason to use fwnode_get_named_gpiod() that I plan to hide away.
>
> Let's switch to u
On Thu, Sep 12, 2019 at 08:28:39PM -0700, Florian Fainelli wrote:
> Add support for configuring the per-port egress flooding control for
> both Unicast and Multicast traffic.
>
> Signed-off-by: Florian Fainelli
> ---
> Beneditk,
>
> Do you mind re-testing, or confirming that this patch that I se
The PCM draining behavior got broken since the recent refactoring, and
this turned out to be the incorrect expectation of the firmware
behavior regarding "draining". While I expected the "drain" flag at
the stop operation would do processing the queued samples, it seems
rather dropping the samples
On Mon, Jan 30, 2017 at 12:05:06PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Hi everyone,
>
> This small series is preparatory work for a series that I'm working on
> which attempts to establish a formal framework for system restart and
> power off.
>
> Guenter has done a lot of g
On Thu, Sep 12, 2019 at 07:28:11PM +0300, Alexandru Ardelean wrote:
> The `phy_tunable_id` has been named `ETHTOOL_PHY_EDPD` since it looks like
> this feature is common across other PHYs (like EEE), and defining
> `ETHTOOL_PHY_ENERGY_DETECT_POWER_DOWN` seems too long.
>
> The way EDPD works, is t
On Thu, Sep 12, 2019 at 07:28:12PM +0300, Alexandru Ardelean wrote:
> +static int adin_set_edpd(struct phy_device *phydev, u16 tx_interval)
> +{
> + u16 val;
> +
> + if (tx_interval == ETHTOOL_PHY_EDPD_DISABLE)
> + return phy_clear_bits(phydev, ADIN1300_PHY_CTRL_STATUS2,
> +
On 9/14/19 6:41 AM, Jarkko Sakkinen wrote:
>
> The proposed LSM hooks give the granularity to make yes/no decision
> based on the
>
> * The origin of the source of the source for the enclave.
> * The requested permissions for the added or mapped peage.
>
> The hooks to do these checks are provid
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> Update the libbpf library with functionality to load and
> attach a program type BPF_PROG_TYPE_KRSI.
>
> Since the bpf_prog_load does not allow the specification of an
> expected attach type, it's recommended to use bpf_prog_load_xattr
On Sat, Sep 14, 2019 at 9:38 AM H. Nikolaus Schaller wrote:
>
>
> > Am 14.09.2019 um 15:42 schrieb Adam Ford :
> >
> > On Sat, Sep 14, 2019 at 4:20 AM H. Nikolaus Schaller
> > wrote:
> >>
> >>
> >>> Am 13.09.2019 um 17:37 schrieb Adam Ford :
> >>>
> >>> The OMAP3530, AM3517 and DM3730 all show t
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> The LSM creates files in securityfs for each hook registered with the
> LSM.
>
> /sys/kernel/security/bpf/
>
> The initialization of the hooks is done collectively in an internal
> header "hooks.h" which results in:
>
> * Creatio
On Sat, Sep 14, 2019 at 11:25:09AM +0200, Ahmed S. Darwish wrote:
> Unfortunately, it only made the early fast init faster, but didn't fix
> the normal crng init blockage :-(
Yeah, I see why; the original goal was to do the fast init so that
using /dev/urandom, even before we were fully initialize
On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish wrote:
>
> On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
> >
> > An alternative might be to make getrandom() just return an error
> > instead of waiting. Sure, fill the buffer with "as random as we can"
> > stuff, but then return -
14.09.2019 21:30, Linus Torvalds пишет:
On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish wrote:
On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote:
An alternative might be to make getrandom() just return an error
instead of waiting. Sure, fill the buffer with "as random as we can
Le 14/09/2019 à 16:34, Scott Wood a écrit :
On Fri, 2019-08-23 at 12:50 +, Christophe Leroy wrote:
On mpc83xx with a QE, IMMR is 2Mbytes.
On mpc83xx without a QE, IMMR is 1Mbytes.
Each driver will map a part of it to access the registers it needs.
Some driver will map the same part of IMM
On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov
wrote:
>
> Let me repeat: not -EINVAL, please. Please find some other error code,
> so that the application could sensibly distinguish between this case
> (low quality entropy is in the buffer) and the "kernel is too dumb" case
> (and no entrop
Hi Giovanni
On Monday 09 Sep 2019 at 04:42:15 (+0200), Giovanni Gherdovich wrote:
> +static inline long arch_scale_freq_capacity(int cpu)
> +{
> + if (static_cpu_has(X86_FEATURE_APERFMPERF))
> + return per_cpu(arch_cpu_freq, cpu);
So, if this is conditional, perhaps you could also
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> A user space program can attach an eBPF program by:
>
>hook_fd = open("/sys/kernel/security/krsi/process_execution", O_RDWR)
>prog_fd = bpf(BPF_PROG_LOAD, ...)
>bpf(BPF_PROG_ATTACH, hook_fd, prog_fd)
>
> When such an attach
14.09.2019 21:52, Linus Torvalds пишет:
On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov
wrote:
Let me repeat: not -EINVAL, please. Please find some other error code,
so that the application could sensibly distinguish between this case
(low quality entropy is in the buffer) and the "kerne
On Fri, Sep 13, 2019 at 03:55:47PM -0700, Dmitry Torokhov wrote:
> The MDIO device reset line is optional and now that gpiod_get_optional()
> returns proper value when GPIO support is compiled out, there is no
> reason to use fwnode_get_named_gpiod() that I plan to hide away.
>
> Let's switch to u
On Sat, Sep 14, 2019 at 12:05:08AM -0700, Srinivas Pandruvada wrote:
> This series contains some minor fixes, when firmware mask is including
> invalid CPU in the perf-profile mask. Also add some commands to
> better manage core-power feature.
Hmm... 150+ LOCs doesn't count to me as minor fixes.
S
From: Ivan Lazeev
Bug link: https://bugzilla.kernel.org/show_bug.cgi?id=195657
cmd/rsp buffers are expected to be in the same ACPI region.
For Zen+ CPUs BIOS's might report two different regions, some of
them also report region sizes inconsistent with values from TPM
registers.
Memory configura
Hi Jianxin,
On Thu, Sep 12, 2019 at 10:20 AM Jianxin Pan wrote:
>
> A1 is an application processor designed for smart audio and IoT applications,
> with Dual core ARM Cortex-A35 CPU. Unlike the previous GXL and G12 series,
> there is no Cortex-M3 AO CPU in it.
it will be interesting to see which
Hi Christian,
my nit-picks below
On Fri, Sep 6, 2019 at 4:34 PM Christian Hewitt
wrote:
[...]
> + spdif_dit: audio-codec-1 {
> + #sound-dai-cells = <0>;
> + compatible = "linux,spdif-dit";
> + status = "okay";
> + sound-name-prefix =
On Sat, Sep 14, 2019 at 5:30 AM Eric W. Biederman wrote:
>
> I have reworked these patches one more time to make it clear that the
> first 3 patches only fix task_struct so that it experiences a rcu grace
> period after it leaves the runqueue for the last time.
I remain a fan of these patches, an
On 9/10/19 12:55 PM, KP Singh wrote:
> From: KP Singh
>
> This helper is mapped to the existing operation
> BPF_FUNC_perf_event_output.
>
> An example usage of this function would be:
>
> #define BUF_SIZE 64;
>
> struct bpf_map_def SEC("maps") perf_map = {
> .type = BPF_MAP_TYPE_PER
1 - 100 of 168 matches
Mail list logo
