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

[Zijun Hu <zijun.hu@oss.qualcomm.com>]

On 11/10/2026 6:56 AM, Hex Lindqvist wrote:
> 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.

Hi Luiz, Hex,

Let me give a unified reply here.

I'd prefer to keep it as-is, since:

1) The union maps the memdump layout: for the first segment, a __le32
 dump_size (the total memdump size) follows @subsys, then the data;
 for other segments, the data follows @subsys directly. Hex's
 flattened v2 is wrong for all non-first segments.

2) The current definition builds clean with W=1 and passes
 checkpatch.pl --strict, while changing segdata[0] to segdata[]
 causes build warnings.

3) The struct is the simplest and most straightforward form; it is
 only used to parse memdump frames, so it doesn't have the problem
 DECLARE_FLEX_ARRAY() solves.