Hi,
> > Yeah, that does seem reasonable, especially if we're moving to bigger
> > messages anyway. If we do add something huge to each channel, we can
> > recover that code I suppose.
>
> So do you want me to drop the channel splitting logic and only allow
> this for bands? Or just keep this si
Hi Johannes,
On 9/11/19 10:28 AM, Johannes Berg wrote:
On Wed, 2019-09-11 at 07:41 -0500, Denis Kenzior wrote:
For my dual band cards the channel dump all fits into a ~1k attribute if
I recall correctly. So there may not really be a need for this. Or at
the very least we could keep things si
On Wed, 2019-09-11 at 07:41 -0500, Denis Kenzior wrote:
>
> For my dual band cards the channel dump all fits into a ~1k attribute if
> I recall correctly. So there may not really be a need for this. Or at
> the very least we could keep things simple(r) and only split at the band
> level, not
Hi Johannes,
On 9/11/19 4:44 AM, Johannes Berg wrote:
Hi,
The first patch looks good, couple of nits/comments on this one below.
On Fri, 2019-09-06 at 10:43 -0500, Denis Kenzior wrote:
For historical reasons, NEW_WIPHY messages generated by dumps or
GET_WIPHY commands were limited to 4096 byt
Hi,
The first patch looks good, couple of nits/comments on this one below.
On Fri, 2019-09-06 at 10:43 -0500, Denis Kenzior wrote:
> For historical reasons, NEW_WIPHY messages generated by dumps or
> GET_WIPHY commands were limited to 4096 bytes. This was due to the
> fact that the kernel only a
For historical reasons, NEW_WIPHY messages generated by dumps or
GET_WIPHY commands were limited to 4096 bytes. This was due to the
fact that the kernel only allocated 4k buffers prior to commit
9063e21fb026 ("netlink: autosize skb lengthes"). Once the sizes of
NEW_WIPHY messages exceeded these s
