On Tue, Aug 05, 2025 at 08:21:23PM +0100, Lorenzo Stoakes wrote:
> +cc Pedro
>
> On Tue, Aug 05, 2025 at 03:09:54PM -0400, Zi Yan wrote:
> > On 5 Aug 2025, at 15:00, Lorenzo Stoakes wrote:
> >
> > > On Tue, Aug 05, 2025 at 01:51:40PM -0400, Zi Yan wrote:
>
one we're
inserting? Isn't that a correctness problem?
>
> At some point, we should likely unify the two pte handling paths,
> similar to how we did it for pmds/puds.
>
> Signed-off-by: David Hildenbrand
Nice little cleanup, thanks.
Reviewed-by: Pedro Falcato
--
Pedro
On Tue, Jun 17, 2025 at 05:43:33PM +0200, David Hildenbrand wrote:
> Now unused, so let's drop it.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Pedro Falcato
--
Pedro
> > skip hugevm tests, which reads kernel config to get page table level
> > information.
> >
> > Signed-off-by: Zi Yan
>
> Looks generally reasonable to me, but I'm not so familiar with this so,
>
> Acked-by: Lorenzo Stoakes
Acked-by: Pedro Falcato
Same
On Thu, May 15, 2025 at 02:23:32PM -0400, Zi Yan wrote:
> When userfaultfd is not compiled into kernel, userfaultfd() returns -1,
> causing uffd tests in madv_guard fail. Skip the tests instead.
>
> Signed-off-by: Zi Yan
Reviewed-by: Pedro Falcato
Thanks!
--
Pedro
his to be useful.
It's also nice to add that people on the libc/allocator side should
also appreciate skipping pidfd_open's reliability concerns (mostly,
that RLIMIT_NOFILE Should Not(tm) ever affect thread spawning or a
malloc[1]). Besides the big syscall reduction and nice speedup, that
is.
[1] whether this is the already case is an exercise left to the
reader, but at the very least we should not add onto existing problems
--
Pedro
sc.
- The third test checks if everything works if ingress is active.
Acked-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
.../tc-testing/tc-tests/infra/qdiscs.json | 98 +++
1 file changed, 98 insertions(+)
create mode 100644
tools/testing/selftests/tc-testing/tc-tes
On Fri, Oct 25, 2024 at 6:41 PM John Hubbard wrote:
>
> On 10/25/24 5:50 AM, Pedro Falcato wrote:
> > On Fri, Oct 25, 2024 at 10:41 AM Lorenzo Stoakes
> > wrote:
> ...
> >> +static inline int pidfd_is_self_sentinel(pid_t pid)
> >> +{
> >>
+ struct pid *pid = *task_pid_ptr(current, type);
> +
> + /* The caller expects an elevated reference count. */
> + get_pid(pid);
It would be really really nice to avoid the get here, but I imagine
it'll take some refactoring around put_pid's?
> + return pid;
> +}
> +
> struct pid *__pidfd_get_pid(unsigned int pidfd, bool allow_proc,
> unsigned int *flags)
> {
> - struct pid *pid;
> - struct fd f = fdget(pidfd);
> - struct file *file = fd_file(f);
> + if (pidfd_is_self_sentinel(pidfd)) {
> + return pidfd_get_pid_self(pidfd, flags);
> + } else {
Skipping the else here might make the rest of the code more legible
(since the sentinel branch returns anyway...).
--
Pedro
into KUnit, while
the second one applies the naming style conventions.
We appreciate any feedback and suggestions. :)
[1] https://lkcamp.dev/about/
Co-developed-by: Pedro Orlando
Co-developed-by: Danilo Pereira
Signed-off-by: Pedro Orlando
Signed-off-by: Danilo Pereira
Signed-off-by: Gabriela
On 24/06/2024 12:43, Yunseong Kim wrote:
Hi Pedro,
On 6/25/24 12:12 오전, Pedro Tammela wrote:
On 22/06/2024 01:57, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
[ 5301.595872] KASAN: null-
On 22/06/2024 01:57, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop
On 21/06/2024 08:45, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to noop
Em dom., 18 de abr. de 2021 às 19:56, Alexei Starovoitov
escreveu:
>
> On Sun, Apr 18, 2021 at 1:03 PM Pedro Tammela wrote:
> >
> > ENOTSUPP is not a valid userland errno[1], which is annoying for
> > userland applications that implement a fallback to iterative, report
In older kernels, pre batched ops, it returns EINVAL as the arguments
are not supported in the syscall.
[1] https://lore.kernel.org/netdev/20200511165319.2251678-1-k...@kernel.org/
Signed-off-by: Pedro Tammela
---
kernel/bpf/syscall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
Signed-off-by: Pedro Tammela
---
tools/testing/selftests/bpf/bpf_util.h| 7 --
.../bpf/map_tests/htab_map_batch_ops.c| 87 +--
.../selftests/bpf/prog_tests/map_init.c | 9 +-
tools/testing/selftests/bpf/test_maps.c | 84 +++---
4 files changed
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 104 +-
1 file changed, 75 insertions(+), 29 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
i Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6 +698,8 @@ const str
pu macros
v1 -> v2:
- Amended a more descriptive commit message
Pedro Tammela (3):
bpf: add batched ops support for percpu array
bpf: selftests: remove percpu macros from bpf_util.h
bpf: selftests: update array map tests for per-cpu batched ops
kernel/bpf/arraymap.c
Signed-off-by: Pedro Tammela
---
tools/testing/selftests/bpf/bpf_util.h| 7 --
.../bpf/map_tests/htab_map_batch_ops.c| 71
.../selftests/bpf/prog_tests/map_init.c | 9 +-
tools/testing/selftests/bpf/test_maps.c | 84 +++
4 files changed, 89
i Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6 +698,8 @@ const str
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 110 +-
1 file changed, 80 insertions(+), 30 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
v3:
- Remove percpu macros as suggested by Andrii
- Update tests that used the per cpu macros
v1 -> v2:
- Amended a more descriptive commit message
Pedro Tammela (3):
bpf: add batched ops support for percpu array
bpf: selftests: remove percpu macros from bpf_util.h
bpf: selftests: update arr
In 'bpf_ringbuf_reserve()' we require the flag to '0' at the moment.
For 'bpf_ringbuf_{discard,submit,output}' a flag of '0' might send a
notification to the process if needed.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 16
Em qua., 7 de abr. de 2021 às 16:51, Andrii Nakryiko
escreveu:
>
> On Wed, Apr 7, 2021 at 12:30 PM Pedro Tammela wrote:
> >
> > Em qua., 7 de abr. de 2021 às 15:31, Andrii Nakryiko
> > escreveu:
> > >
> > > On Tue, Apr 6, 2021 at 11:55 AM Pedro Tamm
Em qua., 7 de abr. de 2021 às 16:58, Andrii Nakryiko
escreveu:
>
> On Wed, Apr 7, 2021 at 11:43 AM Joe Stringer wrote:
> >
> > Hi Pedro,
> >
> > On Tue, Apr 6, 2021 at 11:58 AM Pedro Tammela wrote:
> > >
> > > In 'bpf_ringbuf_reserve()'
Em qua., 7 de abr. de 2021 às 15:31, Andrii Nakryiko
escreveu:
>
> On Tue, Apr 6, 2021 at 11:55 AM Pedro Tammela wrote:
> >
> > This macro was refactored out of the bpf selftests.
> >
> > Since percpu values are rounded up to '8' in the kernel, a carele
In 'bpf_ringbuf_reserve()' we require the flag to '0' at the moment.
For 'bpf_ringbuf_{discard,submit,output}' a flag of '0' might send a
notification to the process if needed.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 7 +++
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 114 +-
1 file changed, 85 insertions(+), 29 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
i Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6 +698,8 @@ const str
ops in the
percpu variant, let's provide a convenient macro to declare percpu map
value types.
Updates the tests to a "reference" usage of the new macro.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/bpf.h | 10
tools/testing/selftests/bpf/bpf_util.h
refactored
out to libbpf, with some simplifications for reuse.
The tests were updated to reflect all the new changes.
v1 -> v2:
- Amended a more descriptive commit message
Pedro Tammela (3):
bpf: add batched ops support for percpu array
libbpf: selftests: refactor 'BPF_PERCPU_TYPE(
Follows the same logic as the hashtable tests.
Signed-off-by: Pedro Tammela
---
.../bpf/map_tests/array_map_batch_ops.c | 114 +-
1 file changed, 85 insertions(+), 29 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing
ops in the
percpu variant, let's provide a convenient macro to declare percpu map
value types.
Updates the tests to a "reference" usage of the new macro.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/bpf.h | 10
tools/testing/selftests/bpf/bpf_util.h
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/arraymap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index 463d25e1e67e..3c4105603f9d 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -698,6
refactored
out to libbpf, with some simplifications for reuse.
The tests were updated to reflect all the new changes.
Pedro Tammela (3):
bpf: add batched ops support for percpu array
libbpf: selftests: refactor 'BPF_PERCPU_TYPE()' and 'bpf_percpu()'
macros
bpf: selftes
Em qua., 31 de mar. de 2021 às 03:54, Andrii Nakryiko
escreveu:
>
> On Sun, Mar 28, 2021 at 9:11 AM Pedro Tammela wrote:
> >
> > The current way to provide a no-op flag to 'bpf_ringbuf_submit()',
> > 'bpf_ringbuf_discard()' and 'bpf_ringbuf_outp
Em qua., 31 de mar. de 2021 às 04:02, Andrii Nakryiko
escreveu:
>
> On Tue, Mar 30, 2021 at 4:16 PM Alexei Starovoitov
> wrote:
> >
> > On Tue, Mar 30, 2021 at 3:54 PM Pedro Tammela wrote:
> > >
> > > BPF_CALL_2(bpf_ringbuf_submit, void *, sample
The current code only checks flags in 'bpf_ringbuf_output()'.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 8
kernel/bpf/ringbuf.c | 13 +++--
tools/include/uapi/linux/bpf.h | 8
3 files changed, 19 insertions(+), 10 deletion
Em seg., 29 de mar. de 2021 às 13:10, Song Liu escreveu:
>
>
>
> > On Mar 28, 2021, at 9:10 AM, Pedro Tammela wrote:
> >
> > The current code only checks flags in 'bpf_ringbuf_output()'.
> >
> > Signed-off-by: Pedro Tammela
> > ---
> >
'bpf_ring_buffer__poll()' abstracts the polling method, so abstract the
constants that make the implementation don't wait or wait indefinetly
for data.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/libbpf.h | 3 +++
tools/testing/selft
The current code only checks flags in 'bpf_ringbuf_output()'.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 8
kernel/bpf/ringbuf.c | 13 +++--
tools/include/uapi/linux/bpf.h | 8
3 files changed, 19 insertions(+), 10 deletion
ore descriptive notation for this value.
Signed-off-by: Pedro Tammela
---
include/uapi/linux/bpf.h | 8
tools/include/uapi/linux/bpf.h | 8
tools/testing/selftests/bpf/progs/ima.c| 2 +-
tools/testing/selftes
patch makes positive returns from the callback a no-op.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/ringbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/ringbuf.c b/tools/lib/bpf/ringbuf.c
index 8caaafe7e312..e7a8d847161f 100644
--- a/tools/lib/bpf/ringbuf.c
From: Pedro Tammela
Uses the already existing infrastructure for testing batched ops.
The testing code is essentially the same, with minor tweaks for this use
case.
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
.../map_tests/lpm_trie_map_batch_ops.c (new) | 158
From: Pedro Tammela
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/lpm_trie.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
index cec792a17e5f..1b7b8a6f34ee 100644
--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf
The patch itself is straightforward thanks to the infrastructure that is
already in-place.
The tests follows the other '*_map_batch_ops' tests with minor tweaks.
v1 -> v2:
Fixes for checkpatch warnings
Pedro Tammela (2):
bpf: add support for batched operations in LPM tr
From: Pedro Tammela
Uses the already existing infrastructure for testing batched ops.
The testing code is essentially the same, with minor tweaks for this use
case.
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
.../map_tests/lpm_trie_map_batch_ops.c (new) | 158
From: Pedro Tammela
Suggested-by: Jamal Hadi Salim
Signed-off-by: Pedro Tammela
---
kernel/bpf/lpm_trie.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
index cec792a17e5f..1b7b8a6f34ee 100644
--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf
The patch itself is straightforward thanks to the infrastructure that is
already in-place.
The tests follows the other '*_map_batch_ops' tests with minor tweaks.
Pedro Tammela (2):
bpf: add support for batched operations in LPM trie maps
bpf: selftests: add tests for batched ops i
This seems to be a reminiscent from the hashmap tests.
Signed-off-by: Pedro Tammela
---
tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/tools/testing/selftests/bpf/map_tests/array_map_batch_ops.c
b/tools/testing/selftests/bpf
t hints inline to clang.
This change now enforces the proper definition for BPF programs
regardless of the include order.
Signed-off-by: Pedro Tammela
---
tools/lib/bpf/bpf_helpers.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tools/lib/bpf/bpf_helpers.h b/too
gi?id=26754
I've went through GDB's code looking for potential issues with the change and
whether
it would affect GDBs already in the wild. Tricky corner cases abound, but I
think
we're good. Feel free to add my ack:
Acked-by: Pedro Alves
Thanks,
Pedro Alves
--
Aufgrund der Covid-19-Pandämie wurden Ihnen von PEDRO 2 Millionen
US-Dollar gespendet. Dies ist Real For More Info Wenden Sie sich
umgehend an PEDRO. Diese E-Mail: pedrohi...@outlook.es Kontakt WhatsApp
Telefonnummer +34632232897 Senden Sie Ihre Antwort an:
pedrohi...@outlook.es
--
$2 Million Has Been Donated To You,By PEDRO this is Real For More Info
Contact PEDRO immediately for your clame This Email:
pedrohi...@outlook.es
Contact phone number +34632232897
Send Your Response To: pedrohi...@outlook.es
2 Millionen US-Dollar wurden an Sie gespendet. Von PEDRO
-v info -f rawvideo -pixel_format rgb24 \
-video_size "300x700" test.raw
Co-developed-by: Gabriela Bittencourt
Signed-off-by: Gabriela Bittencourt
Co-developed-by: Gabriel Francisco Mandaji
Signed-off-by: Gabriel Francisco Mandaji
Signed-off-by: Pedro "pirate" Terra
Dearest one.
Good day to you. I am using this medium to request for your assistance
in transferring ownership of the sum of $12.5m I discovered during
auditing in my bank. I'm Mrs Juliana Pedro Audit and Account manager
of my Bank Branch in Ouagadougou-Burkina Faso, Please if you are
inter
nfo -f rawvideo -pixel_format rgb24 \
-video_size "300x700" test.raw
Co-developed-by: Gabriela Bittencourt
Signed-off-by: Gabriela Bittencourt
Co-developed-by: Gabriel Francisco Mandaji
Signed-off-by: Gabriel Francisco Mandaji
Signed-off-by: Pedro "pirate" Terra
--
On 9/9/19 8:00 AM, Filipe Laíns wrote:
On Sat, 2019-08-31 at 13:56 -0400, Pedro Vanzella wrote:
+static int hidpp20_battery_map_status_voltage(u8 data[3], int
*voltage)
+{
+ int status;
+
+ switch (data[2]) {
+ case 0x00: /* discharging */
+ status
Fix following checkpath warnings in multiple lines:
CHECK: Please don't use multiple blank lines
Signed-off-by: Pedro Chinen
---
drivers/staging/greybus/tools/loopback_test.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/greybus/tools/loopback_test.c
b/drivers/st
ff-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 141 ++-
1 file changed, 137 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 0179f7ed77e5..2f215e5be001 100644
--- a/drivers/hid/hid-log
vices, refresh the battery status and notify the power supply
subsystem of the changes in voltage and status.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 140 ++-
1 file changed, 138 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-log
On 8/23/19 10:32 AM, Benjamin Tissoires wrote:
On Fri, Aug 23, 2019 at 4:22 PM Pedro Vanzella wrote:
Hi Benjamin,
On 8/23/19 4:25 AM, Benjamin Tissoires wrote:
Hi Pedro,
On Thu, Aug 22, 2019 at 10:19 PM Pedro Vanzella wrote:
Resumitting this after having rebased it against the latest
Hi Benjamin,
On 8/23/19 4:25 AM, Benjamin Tissoires wrote:
Hi Pedro,
On Thu, Aug 22, 2019 at 10:19 PM Pedro Vanzella wrote:
Resumitting this after having rebased it against the latest changes.
thanks for resubmitting. Sorry I wasn't able to provide feedback on
the last revision
If we know the device supports reading its voltage, report that.
Note that the protocol only gives us the current voltage in millivolts.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/hid
Like we do for other ways of interacting with the battery for other
devices, refresh the battery status and notify the power supply
subsystem of the changes in voltage and status.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 32
1 file
This quirk allows us to pick which devices support the 0x1001 hidpp
feature to read the battery voltage.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b
Resumitting this after having rebased it against the latest changes.
The gaming line of Logitech devices doesn't use the old hidpp20
feature for battery level reporting. Instead, they report the
current voltage of the battery, in millivolts.
This patch set handles this case by adding a quirk to
When the device is brought up, if it's one of the devices we know
supports battery voltage checking, figure out the feature index
and get the battery voltage and status.
If everything went correctly, record the fact that we're capable
of querying battery voltage.
Signed-off-by: Pedr
DX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> /*
> * UFS Transport SGIO v4 BSG Message Support
> *
> --
> 1.9.1
Hi Avri,
I don't see any issue.
Thanks
Reviewed-by: Pedro Sousa
wird.Ich werde anfangen, indem
ich mich anständig vorstelle. Es wird Ihnen sicherlich überraschen diesen Brief
zu erhalten, da wir vorher keine Absprache hatte. Mein name ist Pedro Moreira,
die Berater des verstorbenen Herr Richard aus Deutschland.
Meine Absicht Sie zu kontaktieren geht darum, Ihre
> On Jun 5, 2019, at 6:24 PM, Filipe Laíns wrote:
>
>> On Wed, 2019-06-05 at 15:45 -0400, Pedro Vanzella wrote:
>> The gaming line of Logitech devices doesn't use the old hidpp20
>> feature
>> for battery level reporting. Instead, they report the cu
When the device is brought up, if it's one of the devices we know
supports battery voltage checking, figure out the feature index
and get the battery voltage and status.
If everything went correctly, record the fact that we're capable
of querying battery voltage.
Signed-off-by: Pedr
If we know the device supports reading its voltage, report that.
Note that the protocol only gives us the current voltage in millivolts.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/hid
Like we do for other ways of interacting with the battery for other
devices, refresh the battery status and notify the power supply
subsystem of the changes in voltage and status.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 33
1 file
By adding this quirk we're able to handle battery voltage for devices
in both wired and wireless modes.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidp
d and wireless mode.
This version of the patch set is better split, as well as adding the
quirk to make sure we don't needlessly probe every device connected.
Pedro Vanzella (4):
HID: hid-logitech-hidpp: add quirk to handle battery voltage
HID: hid-logitech-hidpp: add function to query batte
Sorry for littering the list, but please ignore this patch set. I'll
have one that uses a quirk to detect the right devices in a little
while.
On 06/04, Pedro Vanzella wrote:
> Same as with the other ways of reporting battery status,
> fetch the battery voltage on raw hidpp events.
Same as with the other ways of reporting battery status,
fetch the battery voltage on raw hidpp events.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b
Newer devices have a feature with id 0x1001 that reports the battery
voltage instead of the old feature with id 0x1000 that reports a
percentage.
This patch fetches and decodes this data for all devices that
support it.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 108
On 05/28, Benjamin Tissoires wrote:
> On Tue, May 28, 2019 at 6:30 PM Pedro Vanzella
> wrote:
> >
> > Send a low device index when the device is connected via the lightspeed
> > receiver so that the receiver will pass the message along to the device
> > instead of r
ces.
This will enable correct detection of the following models:
G603, GPro, G305, G613, G900 and G903, and possibly others.
Signed-off-by: Pedro Vanzella
---
drivers/hid/hid-logitech-hidpp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-logitech
I am Pedro Lite,System Operation manager in charge of the Euro Millions Draws.I
have a confidential deal to discuss with you if only you will be interested in
the deal.
Thanks,
Pedro Lite
This patch fixes the problem and passes my tests on the CS.DB field,
this includes the "push es" and the "high 16-bits of ESP" test cases.
Tested-by: Pedro Fonseca
On 10/27/17 1:36 AM, Wanpeng Li wrote:
From: Wanpeng Li
Pedro reported:
During tests that we conducte
On 06/21/2016 05:32 PM, Andy Lutomirski wrote:
> On Jun 21, 2016 5:40 AM, "Pedro Alves" wrote:
> I didn't try that particular experiment. But, from that email:
>
>> After that, GDB can control the stopped inferior. To call function "func1()"
>&g
198) exited with code 01]
(gdb) q
Is this expected?
This is the same testcase as before:
https://sourceware.org/ml/gdb/2014-05/msg4.html
Thanks,
Pedro Alves
y problem: seccomp is currently entirely insecure if a
>> malicious ptracer is attached.) As a minimal fix, this patch adds a
>> new flag TS_I386_REGS_POKED that handles the ptrace special case.
>>
>> Cc: Pedro Alves
>> Cc: Oleg Nesterov
>> Cc: Kees Cook
>>
sg4.html
still fails for me on Fedora 23 with git master gdb.
Nevermind the misleading URL, that's a kernel patch.
$ gcc -g -m32 interrupt.c -o interrupt.32
...
(gdb) r
Starting program: /home/pedro/tmp/interrupt.32
talk to me baby
^C
Program received signal SIGINT, Interrup
https://www.sourceware.org/ml/gdb-patches/2015-11/msg00076.html
https://www.sourceware.org/ml/gdb-patches/2015-11/msg00077.html
Guess that makes fs_base/gs_base user-writable, if the kernel allows it.
Thanks,
Pedro Alves
On 06/18/2016 02:55 PM, Pedro Alves wrote:
> This hunk being mentioned in this thread a couple years ago too:
>
> https://www.sourceware.org/ml/gdb/2014-04/msg00095.html
>
> Please don't break this use case ( and fix the one reported in
> that thread :-) ).
BTW, there w
ior, with:
(gdb) print foo()
Some background here:
http://linux-kernel.vger.kernel.narkive.com/fqrh4xKK/patch-x86-ptrace-sign-extend-eax-with-orig-eax-0
This hunk being mentioned in this thread a couple years ago too:
https://www.sourceware.org/ml/gdb/2014-04/msg00095.html
Please don't break this use case ( and fix the one reported in
that thread :-) ).
Thanks,
Pedro Alves
You are a recipient to Mr Pedro Quezada Donation of 2M USD. Contact
(qpedro...@gmail.com) for claims.
You are a recipient to Mr Pedro Quezada Donation of 2M USD. Contact
(qpedro...@gmail.com) for claims.
You are a recipient to Mr Pedro Quezada Donation of 2M USD. Contact
(qpedro...@gmail.com) for claims.
From: PedroNieto
Fixed a coding style issue.
Signed-off-by: Pedro Nieto
---
drivers/staging/comedi/drivers/das16.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers/das16.c
b/drivers/staging/comedi/drivers/das16.c
index fd8e0b7..ef345dc
Wife and I Pedro Quezada won 338 Million USD in a Powerball lottery 6-49
in March, 2013 and I have decided to donate the sum of 2M USD to you.
Contact me via my personal email for more details (qpedro...@gmail.com)
You can verify our story by visiting the web page below.
http://www.dailymail.co.uk
value.
This patch does a double inversion when the GPIO is active high
to make sure either 0 or 1 is returned by these functions.
Signed-off-by: Jose Diaz de Grenu de Pedro
Signed-off-by: Hector Palacios
---
change in v2:
- add missing semicolon
---
drivers/gpio/gpiolib.c | 12 ++--
1
value.
This patch does a double inversion when the GPIO is active high
to make sure either a 0 or 1 is returned by these functions.
Signed-off-by: Jose Diaz de Grenu de Pedro
Signed-off-by: Hector Palacios
---
drivers/gpio/gpiolib.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
On 11/19/2015 05:47 PM, Oleg Nesterov wrote:
> Thanks Pedro for your email,
>
>> 918 /* We need to wait for SIGSTOP before being able to make the next
>> 919 ptrace call on this LWP. */
>> 920 new_lwp->must_set_ptrace_flags = 1;
>> 921
>> 922
ptrace(PTRACE_ATTACH-OR-PTRACE_SEIZE, pid, 0,0);
>>>
>>> assert(ptrace(PTRACE_DETACH, pid, 0,0) == 0);
>>> }
>>>
>>> Yes, it will fail if we remove JOBCTL_TRAPPING. But it can equally fail
>>> if SIGCONT comes before ATTAC
1 - 100 of 198 matches
Mail list logo
