Re: [PATCH] Bluetooth: btusb: Use DECLARE_FLEX_ARRAY() for memdump segment data

[Hex Lindqvist <hex@freenixos.com>]

Hi Luiz, Zijun,

Thank you both for looking at this, and Paul for the review.

On Mon, Nov 9, 2026 at 10:39 AM Luiz Augusto von Dentz wrote:
> On Mon, Nov 9, 2026 at 10:35 AM Luiz Augusto von Dentz wrote:
>> While this maybe true if the above code does produce new warnings then
>> it needs to be fixed anyway, from the commit message it doesn't
>> mention any build warning but that perhaps is because it is enclosed
>> into a union which mask it or something, anyway trainling variable
>> length should be accompany with __counted_by; so the compiler can do
>> bounds checking.

There is no build warning, with or without the union; the patch was
only about the zero-length array being deprecated. __counted_by does
not fit here: the struct has no count field, and the segment length
comes from skb->len.

> Maybe not DECLARE_FLEX_ARRAY, but [0] is not recommended for vla see
> the Link tag, in fact the first_segdata[] does follow it so this needs
> to be fixed anyway.

As Zijun says, segdata is only an offsetof() anchor, so it can go
together with the union:

	struct qhci_vse_memdump {
		__le16 seqno;
		u8     subsys;
		__le32 dump_size;
		u8     first_segdata[];
	} __packed;

	#define QHCI_MEMDUMP_HDR_LEN	offsetof(struct qhci_vse_memdump, dump_size)

The header is pulled with QHCI_MEMDUMP_HDR_LEN, the first segment's
dump_size with sizeof(md_vse->dump_size), and the kernel-doc gains a
line saying that middle and last segments carry their payload right
after @subsys. The generated code does not change.

Zijun, would that work for you? If so, I will send it as v2.

Thanks,
Hex