Re: none

Re: none

[Eric W. Biederman]

>>>>> "leiyin" == root  <root@ns.senbell.com.cn> writes:

leiyin> I am leiyin, a software engineer in china, beijing. I am interested
leiyin> in Linux memory management these day. Since I find an ordinary user
leiyin> can easily occupy all the memory available. Though I don't think this is 
leiyin> a bug. I wonder whether I can control how much memory a user can occup
leiyin> ,including swap space, or not.

yes.

The kernel interface is setrlimit, the user interface is usually
through the shell ulimit command.
The only per user limit I know of is number of processes.
The rest of the limits, stack size, virtual memory size etc, are per processs.

leiyin> Especially in AS400 OS/400 one can distribute a fixed size physical memory
leiyin> (pool) for a subsystem. If Linux can do this( I mean a fixed size memory for
leiyin> a user not subsystem), I think linux will become more lovely.


leiyin> Address:leiyin_linux@163.net
Your might want to set this in your reply to header.

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: none

[Chmouel Boudjnah]

"Sergey Volkoff" <sve@raiden.bancorp.ru> writes:

> I installed the latest kernel ( 2.4.0-test11-pre5 ). On boot with new kernel, system hangup before booting is completed.
> 
> I don't know where, but I think this occurs when system is attempt to mount filesystems.

do you have devfsd installed if you have compiled in ? it's included
with your mdk7.2

-- 
MandrakeSoft Inc                     http://www.chmouel.org
                      --Chmouel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: None

[irfan_hamid]

On Wednesday 17 July 2002 13:35, Bloch, Jack wrote:
> I load my own device driver into a 2.4.18-3 Kernel and get the following
> message. 
>
> "Warning Loading Icdeva0s.o will taint the Kernel : No Licence" 
>
> How do you stop this

Plz read FAQ #18, Section 1 of linux-kernel archives:
www.tux.org/lkml 

Irfan Hamid

RE: None

[Bloch, Jack]

Thanks for the answer.

Jack Bloch
Siemens Carrier Networks
e-mail    : jack.bloch@icn.siemens.com
phone     : (561) 923-6550


-----Original Message-----
From: irfan_hamid@softhome.net [mailto:irfan_hamid@softhome.net]
Sent: Wednesday, July 17, 2002 10:15 AM
To: linux-kernel@vger.kernel.org
Cc: Bloch, Jack
Subject: Re: None


On Wednesday 17 July 2002 13:35, Bloch, Jack wrote:
> I load my own device driver into a 2.4.18-3 Kernel and get the following
> message. 
>
> "Warning Loading Icdeva0s.o will taint the Kernel : No Licence" 
>
> How do you stop this

Plz read FAQ #18, Section 1 of linux-kernel archives:
www.tux.org/lkml 

Irfan Hamid

None

[Владимир Сорокин]

Hi, all.

First of all, sorry for bad english (There is a first practice).

I have some problem with writing on DiskOnChip. 
I'll be grateful for your help.

The full story:
I use linux as embaded system on DiskOnChip. System must be reliable and 
therefore it has a WhatchDog timer, that reboots the system if was not 
refreshed in 1,6 sec.
At the begining I didn't know about MTD project, and
successfully used TrueFFS driver from M-System and minix fs. But now there is a task
to write on DiskOnChip some emergency protocol.
If I try to make mount or write operations on DiskOnChip,
the program which making refresh WatchDog is stops 
(I think that at this time TrueFFS driver working in kernel mode) 
and system is rebooting. 
This situation is take place only in case of large amount of logically 
filled sectors (amount of logically free sectors is near zero).

So I try to find some alternative driver to compare perfomance.
May you can tell me if there is the same problem with MTD driver?
If there is, just write here and do not read further.


I desided to make comparison of performance by myself but that is
not as easy as I thought. :)

Currently I use 2.2.11 kernel so I desided do not pass to 2.4.x and download 2.2.18
kernel and patch for it from ftp://ftp.infradead.org/pub/mtd/patches.

Firstly under new kernel, that correctly determine my DiskOnChip Millenium 8M, I try nftl.
But after nftl_format and rebooting DiskOnChip silently die and kernel don't 
determine this DiskOnChip at all. Utility from M-System (DFORMAT) didn't working to.

May be there is some way to bring this DoC back to life?

Secondly I take DiskOnChip 2000 4M and try jffs. 
All actions were done according to jffs-HOWTO.
Resoults of mounting are below:

jffs_scan_flash: Found a JFFS node with dsize (0x11c0) > max_chunk_size (0x1000)
jffs_scan_flash: Found a JFFS node with dsize (0x8000) > max_chunk_size (0x1000)
jffs_scan_flash: Found a JFFS node with dsize (0x41ec) > max_chunk_size (0x1000)
jffs_scan_flash: Found a JFFS node with dsize (0x4600) > max_chunk_size (0x1000)
jffs_scan_flash: Found a JFFS node with dsize (0x1230) > max_chunk_size (0x1000)
jffs_scan_flash: Found a JFFS node with dsize (0x2200) > max_chunk_size (0x1000)
jffs_scan_flash: Found a JFFS node with dsize (0x8000) > max_chunk_size (0x1000)
last message repeated 5 times
Kernel panic: Didn't read all bytes in flash_safe_read(). Returned 0 

Now DFORMAT didn'n correctly work with this DiskOnChip too.

What am I doing wrong?

How can I make whis two DiskOnChips work with M-System driver now? If it possible of course.

Sincerely yours,
Sorokin Vladimir
Programmer
NPF Krug
mail:Vavanchick38@mail.ru

None

[@ 2003-06-30 16:11 UTC (permalink / raw)]

 =?GB2312?B?46Gj?= <fsddsf@21cn.com>
Subject:
 =?GB2312?B?xPq5wrbAwvCjrMfrvNPI68WuyfrD2MPcuavJ56Osw7/M7MavwcFNTbXI18XE?=

 =?GB2312?B?4w==?=
To: mtd@infradead.org
Content-Type: text/html;charset="GB2312"
Reply-To: fs33rrw@21cn.com
Date: Tue, 1 Jul 2003 00:10:52 +0800
X-Priority: 3
X-Mailer: Microsoft Outlook Express 5.00.2615.200

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>GO173</title>
</head>

<body bgcolor="#F3460C">

<div align="center">
  <center>
  <table border="0" cellpadding="0" cellspacing="0" width="80%">
    <tr>
      <td width="100%">
        <p align="center"><iframe MARGINWIDTH=0 MARGINHEIGHT=0 HSPACE=0 VSPACE=0 FRAMEBORDER=0 SCROLLING=no src=http://mysms2.163.com/mb/101.html?username=huanqiu3636&type=101 height=300 width=300></iframe></td>
    </tr>
  </table>
  </center>
</div>

</body>

</html>

none

[kartikey bhatt]

_________________________________________________________________
Over 6,70,000 brides and grooms. 
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Click here to join 
for free.

none

[Gerald Turner]

Great.  I already use lmsensors, it doesn't work on HP 4150 laptops
though :(

Who are you?!

-- 
Gerald Turner
360-906-9779

Re: none

[Kalle Valo]

Larry Finger <Larry.Finger@lwfinger.net> writes:

> From: Clyde McPherson <ccmcphe@verizon.net>
>
> Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The 
> 4318E can do 802.11A/B/G, only B and G mode are supported in b43.

Subject missing.

-- 
Kalle Valo

Re: none

[Kalle Valo]

Larry Finger <Larry.Finger@lwfinger.net> writes:

> From: Clyde McPherson <ccmcphe@verizon.net>
>
> Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The 
> 4318E can do 802.11A/B/G, only B and G mode are supported in b43.

Subject missing from this one as well.

-- 
Kalle Valo

none

[Bjørn Mork]

Valdis.Kletnieks at vt.edu writes:
> On Fri, 29 Aug 2014 16:58:26 +0200, Ravi Raj said:
>> so first step is to find an imx6 Arm a9 board and port linux to it
>
> Why not get an imx6 board that already *HAS* Linux for it?

Where do you get one which *hasn't*?


Bj?rn

Re: none

[Matthieu Moy]

miwilliams@google.com writes:

> From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
> From: Mike Williams <miwilliams@google.com>
> Date: Mon, 11 Apr 2016 14:18:39 -0400
> Subject: [PATCH 1/1] wt-status: Remove '!!' from
> wt_status_collect_changed_cb
>
> The wt_status_collect_changed_cb function uses an extraneous double
> negation (!!)
> when determining whether or not a submodule has new commits.

It's not just a double negation, it's a way to ensure that the value is
0 or 1 (it's a relatively common idiom in C at least in Git's codebase).

new_submodule_commits is a 1-bit bitfield, and you don't want to assign
anything other than 1 or 0 (or you'll get modulo 2^n semantics, with
n==1).

So the old code is correct and your patch would introduce a bug.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: none

[Junio C Hamano]

Mihir Mehta <mihir@cs.utexas.edu> writes:

> Thanks, Junio. Instead of removing that part of the patch, I opted to
> expand it to make it a little clearer (in my opinion) than it was
> before. Let me know if this works.

I am mildly negative on that change.  "Omitting both would give an
empty diff" would be understandable to anybody who understands that
an omitted end of dot-dot is substituted with HEAD *and* thinks what
range HEAD..HEAD means, so it is just an additional noise to them,
and to those who do not want to waste time on thinking, it is a
statement that reads as if "it will be an error" without saying why
it is an error.  So overall, it seems, at least to me, that the
additional text adds negative value.

So, I dunno.

Re: none

[Junio C Hamano]

Rohit Ashiwal <rohit.ashiwal265@gmail.com> writes:

> Just to be clear of what caused the error:
> 	1. Path not being file, or
> 	2. File not being empty
> I am checking for both.

test -s <path> makes sure <path> is file; if it is not a file, then
it won't yield true.

So why do you need to say test_path_is_file yourself, if you are
asking "test -s"?

Re: none

[Junio C Hamano]

Han-Wen Nienhuys <hanwen@google.com> writes:

> I spent the last few weeks cobbling together an implementation of the
> reftable format in C and in Go. I thought this would be cool to add to
> git-core, but I doubt whether I will have enough time to see such an
> effort through. Maybe some of you would want to try integrating it
> into the Git-core code base?  Example code is here:
>
>   https://github.com/google/reftable/blob/master/c/api.h#L153
>
> cheers!

My initial impression was that the API overuses typedef.  We tend to
avoid doing

	struct _foo { ... };
	typedef struct _foo foo;

and instead write "struct foo" explicitly to make us well aware of
what we are talking about.  That lets us see that we are passing or
returning a structure by value (which we would like authors to think
thrice before doing in C) like so quite easily:

	foo some_function(foo arg1, ...) { ... }

because it would be clear if it were written like so

	struct foo some_function(struct foo arg1, ...) { ... }

without hiding the structure behind a typedef (it also lets us avoid
names with leading underscore, which is frowned upon by some people
for different reasons).

But the set of operations defined in the header file seemed at the
right granularity in order to interface with the refs.h & refs/* API
we have.  It however was unclear to me how transactional ref updates
would work with it.

Thanks.

Re: none

[Han-Wen Nienhuys]

On Tue, Nov 19, 2019 at 8:53 PM Junio C Hamano <gitster@pobox.com> wrote:
> My initial impression was that the API overuses typedef.  We tend to
> avoid doing
>
>         struct _foo { ... };
>         typedef struct _foo foo;
>
> and instead write "struct foo" explicitly to make us well aware of
> what we are talking about.

Thanks, i'll have a look at changing it. I use typedef mainly for
ergonomics, but now that the code is written, I can introduce more
verbosity.

> But the set of operations defined in the header file seemed at the
> right granularity in order to interface with the refs.h & refs/* API
> we have.  It however was unclear to me how transactional ref updates
> would work with it.

Transactions have to interface with the file system. I imagine that
different libraries (libgit vs. cgit) would have different primitives
for dealing with the file system, hence I haven't implemented that
part. Do you have an idea of how I could implement it in a way that is
agnostic of libgit2 vs. cgit?

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Re: none

[Junio C Hamano]

Dorcas Litunya <anonolitunya@gmail.com> writes:

> Bcc: 
> Subject: Re: [PATCH] t/t7601: Modernize test scripts using functions
> Reply-To: 
> In-Reply-To: <xmqq1qdumrto.fsf@gitster.g>

What are these lines doing here?

> So should I replace this in the next version or leave this as is?

Perhaps I was not clear enough, but I found the commit title and
description need to be updated to clearly record the intent of the
change with a handful of points, so I will not be accepting the
patch as-is.

These two sections may be of help.

Documentation/MyFirstContribution.txt::now-what
Documentation/MyFirstContribution.txt::reviewing

Thanks.

[PATCH BlueZ 1/2] input: Reset report map state on detach

[Giuseppe Piscitelli]

From: Giuseppe Piscitelli <35407790+ooonea@users.noreply.github.com>

read_report_map() leaves report_map_id set after a failed read. Detach
cancels queued GATT operations but retains that ID, so a later attach
cannot request the report map again and never creates the UHID device.

Clear the ID when cancelling GATT operations on detach. This also lets
a reconnect retry a read that was still pending at disconnection.

A socketpair reproducer fails to read the map after either an ATT error
or cancellation before this change; both cases create UHID afterwards.
The existing HoG and UHID unit tests also pass.

Assisted-by: OpenAI Codex:gpt-6
---
 profiles/input/hog-lib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/profiles/input/hog-lib.c b/profiles/input/hog-lib.c
index 6c75c60..2b6dcae 100644
--- a/profiles/input/hog-lib.c
+++ b/profiles/input/hog-lib.c
@@ -1908,6 +1908,7 @@ void bt_hog_detach(struct bt_hog *hog, bool force)
 	}

 	queue_remove_all(hog->gatt_op, cancel_gatt_req, hog, destroy_gatt_req);
+	hog->report_map_id = 0;
 	g_attrib_unref(hog->attrib);
 	hog->attrib = NULL;

[PATCH BlueZ 2/2] unit: Test HoG report map reads after reconnect

[Giuseppe Piscitelli]

From: Giuseppe Piscitelli <35407790+ooonea@users.noreply.github.com>

Exercise reconnect after an ATT error and after cancelling a pending
Report Map read. Require a fresh read and validate the resulting
UHID_CREATE2 descriptor on a simulated transport.

Stub Bluetooth address lookup for the Unix socketpair fixture. Both
cases fail without resetting report_map_id on detach.

Assisted-by: OpenAI Codex:gpt-6
---
 Makefile.am     |   2 +-
 unit/test-hog.c | 139 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 140 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 1d46b9b..1621794 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -767,7 +767,7 @@ unit_test_gatt_LDADD = src/libshared-glib.la \
 unit_tests += unit/test-hog

 unit_test_hog_SOURCES = unit/test-hog.c \
-			$(btio_sources) \
+			btio/btio.h \
 			profiles/input/hog-lib.h profiles/input/hog-lib.c \
 			profiles/scanparam/scpp.h profiles/scanparam/scpp.c \
 			profiles/battery/bas.h profiles/battery/bas.c \
diff --git a/unit/test-hog.c b/unit/test-hog.c
index 45ffe71..405af8a 100644
--- a/unit/test-hog.c
+++ b/unit/test-hog.c
@@ -17,6 +17,8 @@
 #include <string.h>
 #include <sys/socket.h>
 #include <fcntl.h>
+#include <stdarg.h>
+#include <linux/uhid.h>

 #include <glib.h>

@@ -30,9 +32,28 @@
 #include "src/shared/gatt-db.h"

 #include "attrib/gattrib.h"
+#include "btio/btio.h"

 #include "profiles/input/hog-lib.h"

+gboolean bt_io_get(GIOChannel *io, GError **error, BtIOOption opt, ...)
+{
+	va_list args;
+
+	va_start(args, opt);
+
+	while (opt != BT_IO_OPT_INVALID) {
+		g_assert(opt == BT_IO_OPT_SOURCE_BDADDR ||
+					opt == BT_IO_OPT_DEST_BDADDR);
+		memset(va_arg(args, bdaddr_t *), 0, sizeof(bdaddr_t));
+		opt = va_arg(args, int);
+	}
+
+	va_end(args);
+
+	return TRUE;
+}
+
 struct test_pdu {
 	bool valid;
 	const uint8_t *data;
@@ -211,10 +232,128 @@ static void test_hog(gconstpointer data)
 	g_assert(bt_hog_attach(context->hog, context->attrib));
 }

+static ssize_t receive(int fd, void *buf, size_t size)
+{
+	gint64 deadline = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND;
+	ssize_t len;
+
+	do {
+		while (g_main_context_iteration(NULL, FALSE))
+			;
+
+		len = recv(fd, buf, size, MSG_DONTWAIT);
+		if (len >= 0)
+			return len;
+
+		g_usleep(1000);
+	} while (g_get_monotonic_time() < deadline);
+
+	return -1;
+}
+
+static void expect_read(int fd, uint8_t handle)
+{
+	uint8_t buf[32];
+	ssize_t len = receive(fd, buf, sizeof(buf));
+
+	g_assert_cmpint(len, ==, 3);
+	g_assert_cmpuint(buf[0], ==, BT_ATT_OP_READ_REQ);
+	g_assert_cmpuint(buf[1], ==, handle);
+	g_assert_cmpuint(buf[2], ==, 0);
+}
+
+static void respond(int fd, const void *buf, size_t size)
+{
+	g_assert_cmpint(send(fd, buf, size, 0), ==, size);
+}
+
+static void test_reconnect(gconstpointer data)
+{
+	const uint8_t info[] = { 0x0b, 0x11, 0x01, 0x00, 0x00 };
+	const uint8_t error[] = { 0x01, 0x0a, 0x05, 0x00, 0x0e };
+	const uint8_t map[] = { 0x0b, 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01,
+				0x09, 0x30, 0x15, 0x81, 0x25, 0x7f, 0x75,
+				0x08, 0x95, 0x01, 0x81, 0x06, 0xc0 };
+	struct gatt_db *db = gatt_db_new();
+	struct gatt_db_attribute *service;
+	struct bt_hog *hog;
+	struct uhid_event ev;
+	GIOChannel *channel;
+	GAttrib *attrib;
+	bt_uuid_t uuid;
+	int att[2], uhid[2];
+	bool cancel = GPOINTER_TO_INT(data);
+
+	g_assert_cmpint(socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK,
+							0, att), ==, 0);
+	g_assert_cmpint(socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK,
+							0, uhid), ==, 0);
+	bt_uuid16_create(&uuid, 0x1812);
+	service = gatt_db_add_service(db, &uuid, true, 5);
+	g_assert(service);
+	bt_uuid16_create(&uuid, 0x2a4a);
+	g_assert(gatt_db_service_add_characteristic(service, &uuid,
+				BT_ATT_PERM_READ, 0x02, NULL, NULL, NULL));
+	bt_uuid16_create(&uuid, 0x2a4b);
+	g_assert(gatt_db_service_add_characteristic(service, &uuid,
+				BT_ATT_PERM_READ, 0x02, NULL, NULL, NULL));
+	gatt_db_service_set_active(service, true);
+	channel = g_io_channel_unix_new(att[0]);
+	g_io_channel_set_close_on_unref(channel, TRUE);
+	attrib = g_attrib_new(channel, 23, false);
+	g_io_channel_unref(channel);
+	hog = bt_hog_new(uhid[0], "report-map-test", 1, 1, 1, 0, db);
+	g_assert(hog);
+	g_assert(bt_hog_attach(hog, attrib));
+	expect_read(att[1], 3);
+	respond(att[1], info, sizeof(info));
+	expect_read(att[1], 5);
+
+	if (!cancel) {
+		respond(att[1], error, sizeof(error));
+
+		while (g_main_context_iteration(NULL, FALSE))
+			;
+	}
+
+	bt_hog_detach(hog, false);
+	g_attrib_unref(attrib);
+	close(att[1]);
+	g_assert_cmpint(socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK,
+							0, att), ==, 0);
+	channel = g_io_channel_unix_new(att[0]);
+	g_io_channel_set_close_on_unref(channel, TRUE);
+	attrib = g_attrib_new(channel, 23, false);
+	g_io_channel_unref(channel);
+	g_assert(bt_hog_attach(hog, attrib));
+	expect_read(att[1], 3);
+	respond(att[1], info, sizeof(info));
+	expect_read(att[1], 5);
+	respond(att[1], map, sizeof(map));
+	g_assert_cmpint(receive(uhid[1], &ev, sizeof(ev)), ==, sizeof(ev));
+	g_assert_cmpuint(ev.type, ==, UHID_CREATE2);
+	g_assert_cmpuint(ev.u.create2.rd_size, ==, sizeof(map) - 1);
+	g_assert_cmpmem(ev.u.create2.rd_data, ev.u.create2.rd_size,
+						map + 1, sizeof(map) - 1);
+	bt_hog_detach(hog, true);
+	bt_hog_unref(hog);
+	g_attrib_unref(attrib);
+	gatt_db_unref(db);
+	close(att[1]);
+	close(uhid[0]);
+	close(uhid[1]);
+	tester_test_passed();
+}
+
 int main(int argc, char *argv[])
 {
 	tester_init(&argc, &argv);

+	tester_add("/hog/report-map/error-reconnect", GINT_TO_POINTER(false),
+					NULL, test_reconnect, NULL);
+	tester_add("/hog/report-map/cancel-reconnect", GINT_TO_POINTER(true),
+					NULL, test_reconnect, NULL);
+
 	define_test("/TP/HGRF/RH/BV-01-I", test_hog,
 		raw_pdu(0x10, 0x01, 0x00, 0xff, 0xff, 0x00, 0x28),
 		raw_pdu(0x11, 0x06, 0x01, 0x00, 0x04, 0x00, 0x12,


On Fri, 25 Sep 2026 12:42:44 -0500, Giuseppe Piscitelli
<ooonea@gmail.com> wrote:
> From: Giuseppe Piscitelli <35407790+ooonea@users.noreply.github.com>
>
> read_report_map() leaves report_map_id set after a failed read. Detach
> cancels queued GATT operations but retains that ID, so a later attach
> cannot request the report map again and never creates the UHID device.
>
> Clear the ID when cancelling GATT operations on detach. This also lets
> a reconnect retry a read that was still pending at disconnection.
>
> A socketpair reproducer fails to read the map after either an ATT error
> or cancellation before this change; both cases create UHID afterwards.
> The existing HoG and UHID unit tests also pass.
>
> Assisted-by: OpenAI Codex:gpt-6
> ---
>  profiles/input/hog-lib.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/profiles/input/hog-lib.c b/profiles/input/hog-lib.c
> index 6c75c60..2b6dcae 100644
> --- a/profiles/input/hog-lib.c
> +++ b/profiles/input/hog-lib.c
> @@ -1908,6 +1908,7 @@ void bt_hog_detach(struct bt_hog *hog, bool force)
>  	}
>
>  	queue_remove_all(hog->gatt_op, cancel_gatt_req, hog, destroy_gatt_req);
> +	hog->report_map_id = 0;
>  	g_attrib_unref(hog->attrib);
>  	hog->attrib = NULL;

RE: [BlueZ,1/2] input: Reset report map state on detach

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1173956/

---Test result---

Test Summary:
CheckPatch                    PASS      6.93 seconds
GitLint                       FAIL      0.73 seconds
BuildEll                      PASS      20.05 seconds
BluezMake                     PASS      389.15 seconds
MakeCheck                     PASS      14.40 seconds
MakeDistcheck                 PASS      148.33 seconds
CheckValgrind                 PASS      238.68 seconds
CheckSmatch                   PASS      293.29 seconds
bluezmakeextell               PASS      97.60 seconds
TestFunctional                PASS      1109.69 seconds
IncrementalBuild              PASS      397.03 seconds
ScanBuild                     PASS      1146.09 seconds

Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,2/2] unit: Test HoG report map reads after reconnect

45: B3 Line contains hard tab characters (\t): ">  	}"
47: B3 Line contains hard tab characters (\t): ">  	queue_remove_all(hog->gatt_op, cancel_gatt_req, hog, destroy_gatt_req);"
48: B3 Line contains hard tab characters (\t): "> +	hog->report_map_id = 0;"
49: B3 Line contains hard tab characters (\t): ">  	g_attrib_unref(hog->attrib);"
50: B3 Line contains hard tab characters (\t): ">  	hog->attrib = NULL;"


https://github.com/bluez/bluez/pull/2590

---
Regards,
Linux Bluetooth

[PATCH BlueZ v2 1/2] input: Reset report map state on detach

[Giuseppe Piscitelli]

From: Giuseppe Piscitelli <35407790+ooonea@users.noreply.github.com>

read_report_map() leaves report_map_id set after a failed read. Detach
cancels queued GATT operations but retains that ID, so a later attach
cannot request the report map again and never creates the UHID device.

Clear the ID when cancelling GATT operations on detach. This also lets
a reconnect retry a read that was still pending at disconnection.

A socketpair reproducer fails to read the map after either an ATT error
or cancellation before this change; both cases create UHID afterwards.
The existing HoG and UHID unit tests also pass.

Assisted-by: OpenAI Codex:gpt-6
---
v2: Resend without quoted email history; code unchanged.

 profiles/input/hog-lib.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/profiles/input/hog-lib.c b/profiles/input/hog-lib.c
index 6c75c60..2b6dcae 100644
--- a/profiles/input/hog-lib.c
+++ b/profiles/input/hog-lib.c
@@ -1908,6 +1908,7 @@ void bt_hog_detach(struct bt_hog *hog, bool force)
 	}

 	queue_remove_all(hog->gatt_op, cancel_gatt_req, hog, destroy_gatt_req);
+	hog->report_map_id = 0;
 	g_attrib_unref(hog->attrib);
 	hog->attrib = NULL;

[PATCH BlueZ v2 2/2] unit: Test HoG report map reads after reconnect

[Giuseppe Piscitelli]

From: Giuseppe Piscitelli <35407790+ooonea@users.noreply.github.com>

Exercise reconnect after an ATT error and after cancelling a pending
Report Map read. Require a fresh read and validate the resulting
UHID_CREATE2 descriptor on a simulated transport.

Stub Bluetooth address lookup for the Unix socketpair fixture. Both
cases fail without resetting report_map_id on detach.

Assisted-by: OpenAI Codex:gpt-6
---
v2: Resend without quoted email history; code unchanged.

 Makefile.am     |   2 +-
 unit/test-hog.c | 139 ++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 140 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 1d46b9b..1621794 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -767,7 +767,7 @@ unit_test_gatt_LDADD = src/libshared-glib.la \
 unit_tests += unit/test-hog

 unit_test_hog_SOURCES = unit/test-hog.c \
-			$(btio_sources) \
+			btio/btio.h \
 			profiles/input/hog-lib.h profiles/input/hog-lib.c \
 			profiles/scanparam/scpp.h profiles/scanparam/scpp.c \
 			profiles/battery/bas.h profiles/battery/bas.c \
diff --git a/unit/test-hog.c b/unit/test-hog.c
index 45ffe71..405af8a 100644
--- a/unit/test-hog.c
+++ b/unit/test-hog.c
@@ -17,6 +17,8 @@
 #include <string.h>
 #include <sys/socket.h>
 #include <fcntl.h>
+#include <stdarg.h>
+#include <linux/uhid.h>

 #include <glib.h>

@@ -30,9 +32,28 @@
 #include "src/shared/gatt-db.h"

 #include "attrib/gattrib.h"
+#include "btio/btio.h"

 #include "profiles/input/hog-lib.h"

+gboolean bt_io_get(GIOChannel *io, GError **error, BtIOOption opt, ...)
+{
+	va_list args;
+
+	va_start(args, opt);
+
+	while (opt != BT_IO_OPT_INVALID) {
+		g_assert(opt == BT_IO_OPT_SOURCE_BDADDR ||
+					opt == BT_IO_OPT_DEST_BDADDR);
+		memset(va_arg(args, bdaddr_t *), 0, sizeof(bdaddr_t));
+		opt = va_arg(args, int);
+	}
+
+	va_end(args);
+
+	return TRUE;
+}
+
 struct test_pdu {
 	bool valid;
 	const uint8_t *data;
@@ -211,10 +232,128 @@ static void test_hog(gconstpointer data)
 	g_assert(bt_hog_attach(context->hog, context->attrib));
 }

+static ssize_t receive(int fd, void *buf, size_t size)
+{
+	gint64 deadline = g_get_monotonic_time() + 5 * G_TIME_SPAN_SECOND;
+	ssize_t len;
+
+	do {
+		while (g_main_context_iteration(NULL, FALSE))
+			;
+
+		len = recv(fd, buf, size, MSG_DONTWAIT);
+		if (len >= 0)
+			return len;
+
+		g_usleep(1000);
+	} while (g_get_monotonic_time() < deadline);
+
+	return -1;
+}
+
+static void expect_read(int fd, uint8_t handle)
+{
+	uint8_t buf[32];
+	ssize_t len = receive(fd, buf, sizeof(buf));
+
+	g_assert_cmpint(len, ==, 3);
+	g_assert_cmpuint(buf[0], ==, BT_ATT_OP_READ_REQ);
+	g_assert_cmpuint(buf[1], ==, handle);
+	g_assert_cmpuint(buf[2], ==, 0);
+}
+
+static void respond(int fd, const void *buf, size_t size)
+{
+	g_assert_cmpint(send(fd, buf, size, 0), ==, size);
+}
+
+static void test_reconnect(gconstpointer data)
+{
+	const uint8_t info[] = { 0x0b, 0x11, 0x01, 0x00, 0x00 };
+	const uint8_t error[] = { 0x01, 0x0a, 0x05, 0x00, 0x0e };
+	const uint8_t map[] = { 0x0b, 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01,
+				0x09, 0x30, 0x15, 0x81, 0x25, 0x7f, 0x75,
+				0x08, 0x95, 0x01, 0x81, 0x06, 0xc0 };
+	struct gatt_db *db = gatt_db_new();
+	struct gatt_db_attribute *service;
+	struct bt_hog *hog;
+	struct uhid_event ev;
+	GIOChannel *channel;
+	GAttrib *attrib;
+	bt_uuid_t uuid;
+	int att[2], uhid[2];
+	bool cancel = GPOINTER_TO_INT(data);
+
+	g_assert_cmpint(socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK,
+							0, att), ==, 0);
+	g_assert_cmpint(socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK,
+							0, uhid), ==, 0);
+	bt_uuid16_create(&uuid, 0x1812);
+	service = gatt_db_add_service(db, &uuid, true, 5);
+	g_assert(service);
+	bt_uuid16_create(&uuid, 0x2a4a);
+	g_assert(gatt_db_service_add_characteristic(service, &uuid,
+				BT_ATT_PERM_READ, 0x02, NULL, NULL, NULL));
+	bt_uuid16_create(&uuid, 0x2a4b);
+	g_assert(gatt_db_service_add_characteristic(service, &uuid,
+				BT_ATT_PERM_READ, 0x02, NULL, NULL, NULL));
+	gatt_db_service_set_active(service, true);
+	channel = g_io_channel_unix_new(att[0]);
+	g_io_channel_set_close_on_unref(channel, TRUE);
+	attrib = g_attrib_new(channel, 23, false);
+	g_io_channel_unref(channel);
+	hog = bt_hog_new(uhid[0], "report-map-test", 1, 1, 1, 0, db);
+	g_assert(hog);
+	g_assert(bt_hog_attach(hog, attrib));
+	expect_read(att[1], 3);
+	respond(att[1], info, sizeof(info));
+	expect_read(att[1], 5);
+
+	if (!cancel) {
+		respond(att[1], error, sizeof(error));
+
+		while (g_main_context_iteration(NULL, FALSE))
+			;
+	}
+
+	bt_hog_detach(hog, false);
+	g_attrib_unref(attrib);
+	close(att[1]);
+	g_assert_cmpint(socketpair(AF_UNIX, SOCK_SEQPACKET | SOCK_NONBLOCK,
+							0, att), ==, 0);
+	channel = g_io_channel_unix_new(att[0]);
+	g_io_channel_set_close_on_unref(channel, TRUE);
+	attrib = g_attrib_new(channel, 23, false);
+	g_io_channel_unref(channel);
+	g_assert(bt_hog_attach(hog, attrib));
+	expect_read(att[1], 3);
+	respond(att[1], info, sizeof(info));
+	expect_read(att[1], 5);
+	respond(att[1], map, sizeof(map));
+	g_assert_cmpint(receive(uhid[1], &ev, sizeof(ev)), ==, sizeof(ev));
+	g_assert_cmpuint(ev.type, ==, UHID_CREATE2);
+	g_assert_cmpuint(ev.u.create2.rd_size, ==, sizeof(map) - 1);
+	g_assert_cmpmem(ev.u.create2.rd_data, ev.u.create2.rd_size,
+						map + 1, sizeof(map) - 1);
+	bt_hog_detach(hog, true);
+	bt_hog_unref(hog);
+	g_attrib_unref(attrib);
+	gatt_db_unref(db);
+	close(att[1]);
+	close(uhid[0]);
+	close(uhid[1]);
+	tester_test_passed();
+}
+
 int main(int argc, char *argv[])
 {
 	tester_init(&argc, &argv);

+	tester_add("/hog/report-map/error-reconnect", GINT_TO_POINTER(false),
+					NULL, test_reconnect, NULL);
+	tester_add("/hog/report-map/cancel-reconnect", GINT_TO_POINTER(true),
+					NULL, test_reconnect, NULL);
+
 	define_test("/TP/HGRF/RH/BV-01-I", test_hog,
 		raw_pdu(0x10, 0x01, 0x00, 0xff, 0xff, 0x00, 0x28),
 		raw_pdu(0x11, 0x06, 0x01, 0x00, 0x04, 0x00, 0x12,

RE: [BlueZ,v2,1/2] input: Reset report map state on detach

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/series/1174115/

---Test result---

Test Summary:
CheckPatch                    PASS      0.37 seconds
GitLint                       PASS      0.26 seconds
BuildEll                      PASS      17.11 seconds
BluezMake                     PASS      303.54 seconds
MakeCheck                     PASS      0.85 seconds
MakeDistcheck                 PASS      127.51 seconds
CheckValgrind                 PASS      131.50 seconds
CheckSmatch                   PASS      222.20 seconds
bluezmakeextell               PASS      83.48 seconds
TestFunctional                PASS      964.15 seconds
IncrementalBuild              PASS      305.70 seconds
ScanBuild                     PASS      881.88 seconds



https://github.com/bluez/bluez/pull/2592

---
Regards,
Linux Bluetooth

Re: [PATCH BlueZ 1/2] input: Reset report map state on detach

[Luiz Augusto von Dentz]

Hi Giuseppe,

On Fri, Sep 25, 2026 at 1:42 PM Giuseppe Piscitelli <ooonea@gmail.com> wrote:
>
> From: Giuseppe Piscitelli <35407790+ooonea@users.noreply.github.com>
>
> read_report_map() leaves report_map_id set after a failed read. Detach
> cancels queued GATT operations but retains that ID, so a later attach
> cannot request the report map again and never creates the UHID device.
>
> Clear the ID when cancelling GATT operations on detach. This also lets
> a reconnect retry a read that was still pending at disconnection.
>
> A socketpair reproducer fails to read the map after either an ATT error
> or cancellation before this change; both cases create UHID afterwards.
> The existing HoG and UHID unit tests also pass.
>
> Assisted-by: OpenAI Codex:gpt-6
> ---
>  profiles/input/hog-lib.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/profiles/input/hog-lib.c b/profiles/input/hog-lib.c
> index 6c75c60..2b6dcae 100644
> --- a/profiles/input/hog-lib.c
> +++ b/profiles/input/hog-lib.c
> @@ -1908,6 +1908,7 @@ void bt_hog_detach(struct bt_hog *hog, bool force)
>         }
>
>         queue_remove_all(hog->gatt_op, cancel_gatt_req, hog, destroy_gatt_req);
> +       hog->report_map_id = 0;
>         g_attrib_unref(hog->attrib);
>         hog->attrib = NULL;

There is a set rewriting hog-lib with
src/shared/gatt-client.c:bt_gatt_client:
https://patchwork.kernel.org/project/bluetooth/patch/20260928173243.1073509-14-luiz.dentz@gmail.com/,
it is probably worth checking if that fixes this issue for you. (hmm,
that seem to not be the case because there is no use of
bt_gatt_client_clone to track HoG operations and then cancel it
properly on unref).

-- 
Luiz Augusto von Dentz

Re: [PATCH BlueZ 1/2] input: Reset report map state on detach

[Giuseppe Piscitelli]

Hi Luiz,

I tested the linked v5 series with both reconnect cases using simulated
ATT/UHID transports: an ATT error during the Report Map read, and detach
while that read is pending. Both request the map again and create UHID
after reconnect. A late response after cancellation is also ignored.

In patch 13/21 [1], report_map_read_cb() clears the ID on completion,
and bt_hog_detach() explicitly cancels and clears it. These paths cover
both cases without cloning the client. My one-line fix targets the
existing hog-lib.c; v5 already handles these two cases.

[1] https://patchwork.kernel.org/project/bluetooth/patch/20260928173243.1073509-14-luiz.dentz@gmail.com/

Assisted-by: OpenAI Codex:gpt-6

RE: [BlueZ,1/2] input: Reset report map state on detach

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

This series was picked up by the CI more than 2 weeks ago and the pull
request created for it is still open, which means the series was never
applied to the tree.

   Series:       [BlueZ,1/2] input: Reset report map state on detach
   Pull Request: https://github.com/bluez/bluez/pull/2590
   Created:      2026-09-25 18:59:32+00:00

The pull request has been closed and no further action is taken on this
series.

If the change should still be considered, it must be resent to the Linux
Bluetooth mailing list (linux-bluetooth@vger.kernel.org) so that it is
picked up again.

---
Regards,
Linux Bluetooth

RE: None

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

This series was picked up by the CI more than 2 weeks ago and the pull
request created for it is still open, which means the series was never
applied to the tree.

   Series:       None
   Pull Request: https://github.com/bluez/bluez/pull/2593
   Created:      2026-09-26 00:38:20+00:00

The pull request has been closed and no further action is taken on this
series.

If the change should still be considered, it must be resent to the Linux
Bluetooth mailing list (linux-bluetooth@vger.kernel.org) so that it is
picked up again.

---
Regards,
Linux Bluetooth

RE: [BlueZ,v2,1/2] input: Reset report map state on detach

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

This is an automated email and please do not reply to this email.

Dear Submitter,

This series was picked up by the CI more than 2 weeks ago and the pull
request created for it is still open, which means the series was never
applied to the tree.

   Series:       [BlueZ,v2,1/2] input: Reset report map state on detach
   Pull Request: https://github.com/bluez/bluez/pull/2592
   Created:      2026-09-26 00:38:16+00:00

The pull request has been closed and no further action is taken on this
series.

If the change should still be considered, it must be resent to the Linux
Bluetooth mailing list (linux-bluetooth@vger.kernel.org) so that it is
picked up again.

---
Regards,
Linux Bluetooth