("KVM: selftests: Add basic selftest for guest_memfd()")
Signed-off-by: Patrick Roy
---
tools/testing/selftests/kvm/guest_memfd_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/guest_memfd_test.c
b/tools/testing/selftests/kvm/guest_me
On Fri, 2024-10-18 at 08:50 +0100, David Hildenbrand wrote:
> On 18.10.24 09:15, Patrick Roy wrote:
>>
>>
>> On Thu, 2024-10-17 at 20:18 +0100, Jason Gunthorpe wrote:
>>> On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
>>>> On Thu, Oct 17,
On Thu, 2024-10-17 at 20:18 +0100, Jason Gunthorpe wrote:
> On Thu, Oct 17, 2024 at 03:11:10PM -0400, Peter Xu wrote:
>> On Thu, Oct 17, 2024 at 02:10:10PM -0300, Jason Gunthorpe wrote:
If so, maybe that's a non-issue for non-CoCo, where the VM object /
gmemfd object (when created) can
On Fri, 2024-10-18 at 00:16 +0100, Ackerley Tng wrote:
> Patrick Roy writes:
>
>> On Tue, 2024-10-08 at 20:56 +0100, Sean Christopherson wrote:
>>> On Tue, Oct 08, 2024, Ackerley Tng wrote:
>>>> Patrick Roy writes:
>>>>> For the "non-CoC
On Tue, 2024-10-08 at 20:56 +0100, Sean Christopherson wrote:
> On Tue, Oct 08, 2024, Ackerley Tng wrote:
>> Patrick Roy writes:
>>> For the "non-CoCo with direct map entries removed" VMs that we at AWS
>>> are going for, we'd like a VM type with host
7;t use folio_zero_user(), can we relying on unmapping within core-mm
> to flush after shared use, and unmapping within KVM To flush after
> private use?
>
> Or should flush_dcache_folio() be explicitly called on kvm_gmem_fault()?
>
> clear_highpage(), used in the non-hugetlb (original) path, doesn't flush
> the dcache. Was that intended?
>
>> Thanks,
>> Elliot
>>
>>>
>>>
>
> [1] https://lore.kernel.org/all/20240726185157.72821-8-pbonz...@redhat.com/
> [2]
> https://lore.kernel.org/all/diqz34ldszp3@ackerleytng-ctop.c.googlers.com/
Best,
Patrick
The native pkg-config is always called which may result in incorrect
flags and paths being passed to the cross compiler. Implement
$(CROSS_COMPILE)pkg-config to avoid this issue.
Signed-off-by: Patrick Waterlander
---
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
34 kselftest.py:kselftest.test_membarrier
ok 35 kselftest.py:kselftest.test_sigaltstack
ok 36 kselftest.py:kselftest.test_tmpfs
ok 37 kselftest.py:kselftest.test_user
ok 38 kselftest.py:kselftest.test_sched
ok 39 kselftest.py:kselftest.test_timens
ok 40 kselftest.py:kselftest.test_timers
Tested-By: Patrick McCormick
commit/afc6744129448ae4333629fc0297808dd42e3530#e522710a8423075cfd1147ae6b7f44facac3ffb0_133_132
Best Regards,
Patrick Menschel
On 2020-12-10 10:05, Madalin Bucur wrote:
-Original Message-
From: Patrick Havelange
[snipped]
But then that change would not be compatible with the existing device
trees in already existing hardware. I'm not sure how to handle that case
properly.
One needs to be back
On 2020-12-09 19:55, Madalin Bucur wrote:
-Original Message-
From: Patrick Havelange
Sent: 09 December 2020 16:17
To: Madalin Bucur ; David S. Miller
; Jakub Kicinski ;
net...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 1/4] net: freescale/fman: Split the main
o it at all in the first place (the
devm_request_mem_region).
I'm not an expert in that part of the code so feel free to correct me if
I missed something.
BR,
Patrick H.
Hi, Patrick,
the DPAA entities are described in the device tree. Adding some hardcoding in
the driver is not really th
On 2020-12-03 16:47, Madalin Bucur wrote:
-Original Message-
From: Patrick Havelange
Sent: 03 December 2020 15:51
To: Madalin Bucur ; David S. Miller
; Jakub Kicinski ;
net...@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Patrick Havelange
Subject: [PATCH net 1/4] net: freescale
On 2020-12-03 09:44, Madalin Bucur wrote:
-Original Message-
From: Patrick Havelange
Sent: 02 December 2020 18:16
To: Madalin Bucur ; David S. Miller
; Jakub Kicinski ;
net...@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Patrick Havelange
Subject: [PATCH 2/4] net: freescale/fman
Since the main fman driver is no longer reserving the complete fman
memory region, it is no longer needed to use a custom call to
__devm_request_region, so replace it with devm_request_mem_region
Signed-off-by: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/mac.c | 8 +++-
1 file
same time.
Signed-off-by: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/fman_port.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c
b/drivers/net/ethernet/freescale/fman/fman_port.c
index d9baac0dbc7d..354974939d9d 10
This function is no longer used, so we can remove it.
The pointer to the resource that was kept inside
struct fman_state_struct can also be removed for the same reason.
Signed-off-by: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/fman.c | 17 -
drivers/net/ethernet
: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/fman.c | 103 +
drivers/net/ethernet/freescale/fman/fman.h | 9 +-
2 files changed, 69 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c
b/drivers/net/ethernet/freescale/fman/fman.c
ilar change, let's do it at the same time.
I think they all should be part of the same series.
Patrick Havelange (4):
net: freescale/fman: Split the main resource region reservation
net: freescale/fman-port: remove direct use of __devm_request_region
net: freescale/fman-mac: remove dire
This function is no longer used, so we can remove it.
The pointer to the resource that was kept inside
struct fman_state_struct can also be removed for the same reason.
Signed-off-by: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/fman.c | 17 -
drivers/net/ethernet
Since the main fman driver is no longer reserving the complete fman
memory region, it is no longer needed to use a custom call to
__devm_request_region, so replace it with devm_request_mem_region
Signed-off-by: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/mac.c | 8 +++-
1 file
same time.
Signed-off-by: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/fman_port.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman_port.c
b/drivers/net/ethernet/freescale/fman/fman_port.c
index d9baac0dbc7d..354974939d9d 10
: Patrick Havelange
---
drivers/net/ethernet/freescale/fman/fman.c | 103 +
drivers/net/ethernet/freescale/fman/fman.h | 9 +-
2 files changed, 69 insertions(+), 43 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/fman.c
b/drivers/net/ethernet/freescale/fman/fman.c
t; > Patch #4 adds the initial version of device tree for Facebook Galaxy100
> > BMC.
>
> Nice. They look good to me.
>
> Reviewed-by: Joel Stanley
>
> Is there another person familiar with the design you would like to
> review before I merge?
Also,
Reviewed-by: Patrick Williams
--
Patrick Williams
signature.asc
Description: PGP signature
Hi Yun,
thanks for keep improving this.
I'm replying here but still considering all other reviewers comments.
Best,
Patrick
On Tue, Nov 03, 2020 at 03:37:56 +0100, Yun Hsiang
wrote...
> If the user wants to stop controlling uclamp and let the task inherit
> the value from th
Dear Beneficiary, You have been selected to receive (£1,000,000.00 British
Pound) as charity donation/grant from Patrick and Frances Connolly. Therefore,
you are required to contact her through email for more details
patrickcon2...@gmail.com
--
This email has been checked for viruses
Dear Beneficiary, You have been selected to receive (£1,000,000.00 British
Pound) as charity donation/grant from Patrick and Frances Connolly. Therefore,
you are required to contact her through email for more details
patrickcon2...@gmail.com
--
This email has been checked for viruses
Hi Dietmar, Yun,
I hope I'm not too late before v4 posting ;)
I think the overall approach is sound, I just added in a couple of
cleanups and a possible fix (user_defined reset).
Best,
Patrick
On Tue, Oct 27, 2020 at 16:58:13 +0100, Yun Hsiang
wrote...
> Hi Diet mar,
> On
On Wed, Oct 28, 2020 at 12:39:43 +0100, Qais Yousef
wrote...
> On 10/28/20 11:11, Patrick Bellasi wrote:
>> >>
>> >> /*
>> >>* RT by default have a 100% boost value that could be modified
>> >>* at runtim
You have a donation of £2,000,000.00 GBP from Frances & Patrick Connolly
and Family. Reply to this email: (francespatrickconnol...@gmail.com) for
more details.
Please Note: This is the third time we have been trying to contact you.
Best Regards
Mrs. Mary Hamilton.
You have a donation of £2,000,000.00 GBP from Frances & Patrick Connolly
and Family. Reply to this email: (francespatrickconnol...@gmail.com) for
more details.
Please Note: This is the third time we have been trying to contact you.
Best Regards
Mrs. Mary Hamilton.
Move spi4 at the right alphabetical place within stm32mp15-pinctrl
Fixes: 4fe663890ac5 ("ARM: dts: stm32: Fix spi4 pins in stm32mp15-pinctrl")
Signed-off-by: Patrick Delaunay
---
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 28
1 file changed, 14 inserti
On Tue, Oct 13, 2020 at 22:25:48 +0200, Dietmar Eggemann
wrote...
Hi Dietmar,
> Hi Yun,
>
> On 12/10/2020 18:31, Yun Hsiang wrote:
>> If the user wants to stop controlling uclamp and let the task inherit
>> the value from the group, we need a method to reset.
>>
>> Add SCHED_FLAG_UTIL_CLAMP_
On Tue, Oct 13, 2020 at 15:32:46 +0200, Qais Yousef
wrote...
> On 10/13/20 13:46, Patrick Bellasi wrote:
>> > So IMO you just need a single SCHED_FLAG_UTIL_CLAMP_RESET that if set in
>> > the
>> > attr, you just execute that loop in __setscheduler_uclamp() +
On Tue, Oct 13, 2020 at 12:29:51 +0200, Qais Yousef
wrote...
> On 10/13/20 10:21, Patrick Bellasi wrote:
>>
[...]
>> > +#define SCHED_FLAG_UTIL_CLAMP_RESET (SCHED_FLAG_UTIL_CLAMP_RESET_MIN | \
>> > + SCHED_FLAG_UTIL_CLAMP_RESE
On Tue, Oct 13, 2020 at 07:31:14 +0200, Juri Lelli
wrote...
> Commit 765cc3a4b224e ("sched/core: Optimize sched_feat() for
> !CONFIG_SCHED_DEBUG builds") made sched features static for
> !CONFIG_SCHED_DEBUG configurations, but overlooked the CONFIG_
> SCHED_DEBUG enabled and !CONFIG_JUMP_LABEL
Hi Yun,
thanks for sharing this new implementation.
On Mon, Oct 12, 2020 at 18:31:40 +0200, Yun Hsiang
wrote...
> If the user wants to stop controlling uclamp and let the task inherit
> the value from the group, we need a method to reset.
>
> Add SCHED_FLAG_UTIL_CLAMP_RESET flag to allow the
Hi Yun, Dietmar,
On Mon, Oct 05, 2020 at 14:38:18 +0200, Dietmar Eggemann
wrote...
> + Patrick Bellasi
> + Qais Yousef
>
> On 02.10.20 07:38, Yun Hsiang wrote:
>> On Wed, Sep 30, 2020 at 03:12:51PM +0200, Dietmar Eggemann wrote:
>
> [...]
>
>>> O
; partition' size is updated to 4MB to be consistent
> with other Facebook OpenBMC platforms.
>
> Signed-off-by: Tao Ren
> ---
> .../boot/dts/aspeed-bmc-facebook-minipack.dts | 47 ++-
> 1 file changed, 45 insertions(+), 2 deletions(-)
>
Revi
> ---
> arch/arm/boot/dts/aspeed-bmc-facebook-yamp.dts | 17 +
> 1 file changed, 17 insertions(+)
>
Reviewed-by: Patrick Williams
--
Patrick Williams
signature.asc
Description: PGP signature
> ---
> arch/arm/boot/dts/aspeed-bmc-facebook-cmm.dts | 17 +
> 1 file changed, 17 insertions(+)
>
Reviewed-by: Patrick Williams
--
Patrick Williams
signature.asc
Description: PGP signature
en
> ---
> .../boot/dts/ast2500-facebook-netbmc-common.dtsi| 13 -
> 1 file changed, 13 deletions(-)
>
Reviewed-by: Patrick Williams
--
Patrick Williams
signature.asc
Description: PGP signature
From: Patrick Riphagen
The device added has an FTDI chip inside.
The device is used to connect Xsens USB Motion Trackers.
Cc: sta...@vger.kernel.org
Signed-off-by: Patrick Riphagen
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2
The device added has an FTDI chip inside.
The device is used to connect Xsens USB Motion Trackers.
Cc: sta...@vger.kernel.org
Signed-off-by: Patrick Riphagen
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a
The device added has an FTDI chip inside.
The device is used to connect Xsens USB Motion Trackers.
Signed-off-by: Patrick Riphagen
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b
Dear friend,
Please accept my apologies, I didn't mean to invade your privacy, but
I wrote you an email already, but I'm not sure you have it, so I'm
resending it to you. I pray that this letter reaches you in good
health. I am Barrister Dossou Patrick. I have a US $ 10 m
The device added has an FTDI chip inside.
The device is used to connect Xsens USB Motion Trackers.
Signed-off-by: Patrick Riphagen
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b
Hello,
We are Frances and Patrick Connolly the mega winner of £115m EuroMillions
lottery, if you get this email then your email was selected after a spin ball.
We have spread most of our wealth over several charities
and organizations. We have voluntarily decided to donate the sum
of £1 Million
On 7/21/20 10:27 AM, Mika Westerberg wrote:
> On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote:
>> Sure thing. Also, feel free to let me know if you'd like access to one of the
>> systems we saw breaking with this patch - I'm fairly sure I've got one of
>> them
>> locally at my apartment
Hi Vincent,
On Mon, Jul 13, 2020 at 14:59:51 +0200, Vincent Guittot
wrote...
> On Fri, 10 Jul 2020 at 21:59, Patrick Bellasi
> wrote:
>> On Fri, Jul 10, 2020 at 15:21:48 +0200, Vincent Guittot
>> wrote...
>>
>> [...]
>>
>> >>
On Fri, Jul 10, 2020 at 15:21:48 +0200, Vincent Guittot
wrote...
> Hi Patrick,
Hi Vincent,
[...]
>> > C) Existing control paths
>>
>> Assuming:
>>
>> C: CFS task currently running on CPUx
>> W: CFS task waking up on the same CPUx
>>
&g
Move spi4_pins_a nodes from pinctrl_z to pinctrl
as the associated pins are not in BANK Z.
Fixes: 498a7014989dfdd9a47864b55704dc829ed0dc90
Signed-off-by: Patrick Delaunay
---
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 28
1 file changed, 14 insertions(+), 14 deletions
On Tue, Jun 30, 2020 at 17:40:34 +0200, Qais Yousef
wrote...
> Hi Patrick
>
> On 06/30/20 16:55, Patrick Bellasi wrote:
>>
>> Hi Qais,
>> sorry for commenting on v5 with a v6 already posted, but...
>> ... I cannot keep up with your re-spinning rate ;)
>
Hi Qais,
sorry for commenting on v5 with a v6 already posted, but...
... I cannot keep up with your re-spinning rate ;)
More importantly, perhaps you missed to comment on one of my previous
points.
Will have a better look at the rest of v6 later today.
Cheers,
Patrick
On Tue, Jun 30, 2020 at
&sched_numa_balancing))
kernel/sched/fair.c:if (!static_branch_likely(&sched_numa_balancing))
kernel/sched/fair.c:if (!static_branch_likely(&sched_numa_balancing))
kernel/sched/fair.c:if (static_branch_unlikely(&sched_numa_balancing))
kernel/sched/sched.h:extern struct static_key_false sched_numa_balancing;
IOW: unconditionally define sched_uclamp_used as non static in core.c,
and use it directly on schedutil too.
> #else /* CONFIG_UCLAMP_TASK */
> static inline
> unsigned long uclamp_rq_util_with(struct rq *rq, unsigned long util,
> @@ -2378,6 +2408,11 @@ unsigned long uclamp_rq_util_with(struct rq *rq,
> unsigned long util,
> {
> return util;
> }
> +
> +static inline bool uclamp_is_enabled(void)
> +{
> + return false;
> +}
> #endif /* CONFIG_UCLAMP_TASK */
>
> #ifdef arch_scale_freq_capacity
Best,
Patrick
On Thu, Jun 25, 2020 at 17:43:52 +0200, Qais Yousef
wrote...
[...]
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 235b2cae00a0..e2f1fffa013c 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -794,6 +794,25 @@ unsigned int sysctl_sched_uclamp_util_max =
> S
On Thu, Jun 25, 2020 at 17:43:51 +0200, Qais Yousef
wrote...
> struct uclamp_rq was zeroed out entirely in assumption that in the first
> call to uclamp_rq_inc() they'd be initialized correctly in accordance to
> default settings.
Perhaps I was not clear in my previous comment:
https://lo
L_CLAMP)))
> return;
>
> + if (static_branch_unlikely(&sched_uclamp_unused))
> + static_branch_disable(&sched_uclamp_unused);
> +
> if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) {
> uclamp_se_set(&p->uclamp_req[UCLAMP_MIN],
> attr->sched_util_min, true);
> @@ -7315,6 +7362,9 @@ static ssize_t cpu_uclamp_write(struct kernfs_open_file
> *of, char *buf,
> if (req.ret)
> return req.ret;
>
> + if (static_branch_unlikely(&sched_uclamp_unused))
> + static_branch_disable(&sched_uclamp_unused);
> +
> mutex_lock(&uclamp_mutex);
> rcu_read_lock();
Best,
Patrick
e ("sched/uclamp: Add CPU's clamp buckets refcounting")
> Signed-off-by: Qais Yousef
> Cc: Juri Lelli
> Cc: Vincent Guittot
> Cc: Dietmar Eggemann
> Cc: Steven Rostedt
> Cc: Ben Segall
> Cc: Mel Gorman
> CC: Patrick Bellasi
> Cc: Chris R
On Tue, Jun 23, 2020 at 09:29:03 +0200, Patrick Bellasi
wrote...
> .:: Scheduler Wakeup Path Requirements Collection Template
> ==
>
> A) Name
Runtime tunable vruntime wakeup bonus.
> B) Target behavior
All SCHED_OTHE
l
be posted shortly after this message. This also will provide an example
for how to use the template.
NOTE: Whenever required, pseudo-code or simplified C can be used.
I hope this can drive a fruitful discussion in preparation for LPC!
Best,
Patrick
---8<--- For templates submissions:
Use tabs where possible and remove multiple blanks lines.
Signed-off-by: Patrick Delaunay
---
arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp15
On Fri, Jun 05, 2020 at 13:32:04 +0200, Qais Yousef
wrote...
> On 06/05/20 09:55, Patrick Bellasi wrote:
>> On Wed, Jun 03, 2020 at 18:52:00 +0200, Qais Yousef
>> wrote...
[...]
>> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> > index
Hi Qais,
On Wed, Jun 03, 2020 at 18:52:00 +0200, Qais Yousef
wrote...
> On 06/03/20 16:59, Vincent Guittot wrote:
>> When I want to stress the fast path i usually use "perf bench sched pipe -T "
>> The tip/sched/core on my arm octo core gives the following results for
>> 20 iterations of perf
Hi Dietmar,
thanks for sharing these numbers.
On Tue, Jun 02, 2020 at 18:46:00 +0200, Dietmar Eggemann
wrote...
[...]
> I ran these tests on 'Ubuntu 18.04 Desktop' on Intel E5-2690 v2
> (2 sockets * 10 cores * 2 threads) with powersave governor as:
>
> $ numactl -N 0 ./run-mmtests.sh XXX
Gr
US_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> > if (config & ADM1278_VIN_EN)
> > info->func[0] |= PMBUS_HAVE_VIN;
> > break;
> >
>
--
Patrick Williams
signature.asc
Description: PGP signature
ction logic here to know if TEMP1_EN *should*
be enabled. Do we need a device-tree entry for this?
> if (config & ADM1278_TEMP1_EN)
> info->func[0] |=
> PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP;
> --
> 2.7.4
>
--
Patrick Williams
signature.asc
Description: PGP signature
[+Giovanni]
On Thu, May 28, 2020 at 20:29:14 +0200, Peter Zijlstra
wrote...
> On Thu, May 28, 2020 at 05:51:31PM +0100, Qais Yousef wrote:
>> I had a humble try to catch the overhead but wasn't successful. The
>> observation
>> wasn't missed by us too then.
>
> Right, I remember us doing be
na be.
Otherwise, FWIW, feel free to consider this a LGTM.
Best,
Patrick
On Mon, May 11, 2020 at 17:40:52 +0200, Qais Yousef
wrote...
[...]
> +static inline void uclamp_sync_util_min_rt_default(struct task_struct *p,
> +enum uclamp_
On Wed, May 13, 2020 at 9:11 AM Al Viro wrote:
>
> On Wed, May 13, 2020 at 08:00:28AM -0700, Patrick Donnelly wrote:
> > In newer kernels (at least 5.6), it appears root is not able to write
> > to files owned by other users in a sticky directory:
>
> Yes. Co
Change: 2020-05-13 07:55:18.892599600 -0700
Birth: 2020-05-13 07:55:18.892599600 -0700
$ sudo strace -f -- /bin/sh -c 'echo 1 > gtmp/foo' |& grep foo
execve("/bin/sh", ["/bin/sh", "-c", "echo 1 > gtmp/foo"],
0x7fff588732f0 /* 15 vars */) = 0
openat(AT_FDCWD, "gtmp/foo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1
EACCES (Permission denied)
write(2, "/bin/sh: gtmp/foo: Permission de"..., 37/bin/sh: gtmp/foo:
Permission denied
--
Patrick Donnelly
]. This could happen for instance if a powersave mode will
> 994 restrict all boosts temporarily by modifying sched_util_clamp_min. As
> soon as
> 995 this restriction is lifted, the requested sched_util_clamp_min_rt_default
> 996 will take effect.
> 997
> 998 Any modification is applied lazily to currently running tasks and should
> be
> 999 visible by the next wakeup.
> """
That's better IMHO, would just slightly change the last sentence to:
Any modification is applied lazily to tasks and is effective
starting from their next wakeup.
Best,
Patrick
o specify that this value is going to be clamped by
the values above? Otherwise it's a bit ambiguous to know what happen
when it's bigger than schedu_util_clamp_min.
> +Any modification is applied lazily on the next opportunity the scheduler
> needs
> +to calculate the effective value of uclamp.min of the task.
^
This is also an implementation detail, I would remove it.
>
> seccomp
> ===
Best,
Patrick
ill do set this anyway at
each enqueue time.
No?
>
> uclamp_se_set(uc_se, clamp_value, false);
> }
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 8a176d8727a3..64117363c502 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -453,6 +453,13 @@ static struct ctl_table kern_table[] = {
> .mode = 0644,
> .proc_handler = sysctl_sched_uclamp_handler,
> },
> + {
> + .procname = "sched_util_clamp_min_rt_default",
> + .data = &sysctl_sched_uclamp_util_min_rt_default,
> + .maxlen = sizeof(unsigned int),
> + .mode = 0644,
> + .proc_handler = sysctl_sched_uclamp_handler,
> + },
> #endif
> #ifdef CONFIG_SCHED_AUTOGROUP
> {
Best,
Patrick
ot/dts/aspeed-bmc-opp-nicole.dts | 326
> 2 files changed, 327 insertions(+)
> create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-nicole.dts
>
Reviewed-by: Patrick Williams
--
Patrick Williams
signature.asc
Description: PGP signature
Hi Peter,
On 14-Oct 16:52, Peter Zijlstra wrote:
>
> The energy aware schedutil patches remimded me this was still pending.
>
> On Fri, Aug 02, 2019 at 10:47:25AM +0100, Patrick Bellasi wrote:
> > Hi Peter, Vincent,
> > is there anything different I can do on this?
>
On Wed, 2019-10-09 at 14:19 -0700, Julius Werner wrote:
> > Somehow we've gotten /sys/firmware/log to be the coreboot log, and
> > quite
> > frankly that blows my mind that this path was accepted upstream.
> > Userspace has to know it's running on coreboot firmware to know
> > that
> > /sys/firmwar
From: Patrick Rudolph
Expose coreboot's binary FMAP[1] to /sys/firmware/fmap.
coreboot copies the FMAP to a CBMEM buffer at boot since CB:35377[2],
allowing an architecture independ way of exposing the FMAP to userspace.
Will be used by fwupd[3] to determine the current firmware layout
From: Patrick Rudolph
Expose the name of the active CBFS partition under
/sys/firmware/cbfs_active_partition
In case of Google's VBOOT[1] that currently can be one of:
"FW_MAIN_A", "FW_MAIN_B" or "COREBOOT"
Will be used by fwupd[2] to determinde the active p
Thanks for the review Andy.
On Tue, Oct 01, 2019 at 07:29:13PM +0300, Andy Shevchenko wrote:
>
>
> On Tue, Oct 01, 2019 at 10:59:59AM -0500, Patrick Williams wrote:
> There are quite a few people in the Cc list. I'm not sure they all are
> interested in this. I deliberate
-byte addressable EEPROM.
Signed-off-by: Patrick Williams
---
drivers/i2c/i2c-slave-eeprom.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c-slave-eeprom.c b/drivers/i2c/i2c-slave-eeprom.c
index efee56106251..65419441313b 100644
--- a/drivers/i2
The i2c-slave-eeprom driver emulates at24 class eeprom devices,
which come initialized with all 1s. Do the same in the software
emulation.
Signed-off-by: Patrick Williams
---
drivers/i2c/i2c-slave-eeprom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/i2c/i2c-slave-eeprom.c b
With the i2c-pxa driver migrated to the standard i2c-slave
APIs, the custom APIs and structures are no longer needed
or used. Remove them.
Signed-off-by: Patrick Williams
---
drivers/i2c/busses/i2c-pxa.c | 1 -
include/linux/i2c-pxa.h | 18 --
include
-slave APIs so that
existing drivers, such as the i2c-slave-eeprom, can be used.
This has been tested with a Marvell EspressoBin, using i2c-pxa and
i2c-slave-eeprom, acting as a slave, and a RaspeberryPi 3, using the
at24 driver, acting as a master.
Signed-off-by: Patrick Williams
---
drivers
(ex. i2c-slave-eeprom).
Patrick Williams (2):
i2c: pxa: migrate to new i2c_slave APIs
i2c: pxa: remove unused i2c-slave APIs
drivers/i2c/busses/Kconfig| 1 +
drivers/i2c/busses/i2c-pxa.c | 75 +--
include/linux/i2c-pxa.h | 18
The configuration registers for the LED group have inverted
polarity, which puts the GPIO into open-drain state when used in
GPIO mode. Switch to '0' for GPIO and '1' for LED modes.
Fixes: 87466ccd9401 ("pinctrl: armada-37xx: Add pin controller support for
Armada 37xx
register / offset calculation to also adjust the offset.
Fixes: 5715092a458c ("pinctrl: armada-37xx: Add gpio support")
Signed-off-by: Patrick Williams
Acked-by: Gregory CLEMENT
Cc:
---
drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 18 +-
1 file changed, 9 insertions(+), 9
--
One million two hundred thousand euros (1,200,000 €) has been donated
to you by Frances and Patrick Connolly, we are from County Armagh in
Northern Ireland, We won the EuroMillions lottery jackpot of 115
million euros. Email us for more details: frances.connoll...@gmail.com
On Wed, Sep 18, 2019 at 16:22:32 +0100, Vincent Guittot wrote...
> On Wed, 18 Sep 2019 at 16:19, Patrick Bellasi wrote:
[...]
>> $> Wakeup path tunings
>> ==
>>
>> Some additional possible use-cases was already discussed in [3]:
>>
cy niceness of a task.
PeterZ thinks this is dangerous but that we can "(carefully) fumble a
bit there."
- bias the decisions we take in check_preempt_tick() still depending
on a relative comparison of the current and wakeup task latency
niceness values.
> References:
> ===
> [1]. https://lkml.org/lkml/2019/8/30/829
> [2]. https://lkml.org/lkml/2019/7/25/296
[3]. Message-ID: <20190905114709.gm2...@hirez.programming.kicks-ass.net>
https://lore.kernel.org/lkml/20190905114709.gm2...@hirez.programming.kicks-ass.net/
Best,
Patrick
--
#include
Patrick Bellasi
On Wed, Sep 18, 2019 at 07:05:53 +0100, Ingo Molnar wrote...
> * Randy Dunlap wrote:
>
>> On 9/17/19 6:38 AM, Patrick Bellasi wrote:
>> >
>> > On Tue, Sep 17, 2019 at 08:52:42 +0100, Ingo Molnar wrote...
>> >
>> >> * Randy Dunlap wrote
Dear Sir,
My name is Patrick Lewis, I am the Partnership Director of the famous
brand John Lewis Plc.
John Lewis Plc is is a UK's largest multi-channel retailer with over
50 shops furnished with European products.
Could you also send to us all information required to become one of
not reproduce this build failue: I took Linus's latest which has all
> the -next scheduler commits included (ad062195731b), and an x86-64 "make
> defconfig" and a disabling of CONFIG_CGROUPS still resuls in a kernel
> that builds fine.
Same here Ingo, I cannot reproduce on
On Thu, Sep 05, 2019 at 12:46:37 +0100, Valentin Schneider wrote...
> On 05/09/2019 12:18, Patrick Bellasi wrote:
>>> There's a few things wrong there; I really feel that if we call it nice,
>>> it should be like nice. Otherwise we should call it latency-bias and no
On Thu, Sep 05, 2019 at 12:40:30 +0100, Peter Zijlstra wrote...
> On Thu, Sep 05, 2019 at 12:18:55PM +0100, Patrick Bellasi wrote:
>
>> Right, we have this dualism to deal with and current mainline behaviour
>> is somehow in the middle.
>>
>> BTW, the FB requ
ng you mean >0, we want to lower the latency.
>
> Anyway; there were a number of things mentioned at OSPM that we could
> tie into this thing and finding sensible mappings is going to be a bit
> of trial and error I suppose.
>
> But as patrick said; we're very much export
On Thu, Sep 05, 2019 at 12:13:47 +0100, Qais Yousef wrote...
> On 09/05/19 12:46, Peter Zijlstra wrote:
>> On Thu, Sep 05, 2019 at 10:45:27AM +0100, Patrick Bellasi wrote:
>>
>> > > From just reading the above, I would expect it to have the range
>> &
On Thu, Sep 05, 2019 at 11:46:16 +0100, Peter Zijlstra wrote...
> On Thu, Sep 05, 2019 at 10:45:27AM +0100, Patrick Bellasi wrote:
>
>> > From just reading the above, I would expect it to have the range
>> > [-20,19] just like normal nice. Apparently this is not so.
&g
ncept which
progressively enables different "levels of biasing" both at wake-up time
and load-balance time.
Why it's not possible to have SIS_CORE/NO_SIS_CORE switch implemented
just as different threshold values for the latency-nice value of a task?
Best,
Patrick
--
#include
Patrick Bellasi
if ((unsigned)i < nr_cpumask_bits)
This looks like should be squashed with the previous one, or whatever
code you'll add to define when this "biasing" is to be used or not.
Best,
Patrick
--
#include
Patrick Bellasi
1 - 100 of 1223 matches
Mail list logo
