I want to contribute a uledtriggers driver
I have written a uledtriggers driver -- a userspace LED triggers driver -- similar in concept to uleds but for LED triggers. I currently have it as an out-of-tree driver, targeting kernel v6.8: https://github.com/cmcqueen/linux-kernel-uledtriggers I am interested to contribute it to the mainline kernel. I have done drivers in the kernel tree before, within a company, so I know how to do the Kconfig and Makefile etc. But I don't know how to do the processes of liaising with the appropriate kernel maintainers to do a driver contribution. I know linux-leds mailing list exists. -- Craig McQueen
On Sun, Mar 02, 2025 at 11:48:18PM +1100, Craig McQueen wrote:
I have written a uledtriggers driver -- a userspace LED triggers driver -- similar in concept to uleds but for LED triggers. I currently have it as an out-of-tree driver, targeting kernel v6.8:
https://github.com/cmcqueen/linux-kernel-uledtriggers
I am interested to contribute it to the mainline kernel. I have done drivers in the kernel tree before, within a company, so I know how to do the Kconfig and Makefile etc. But I don't know how to do the processes of liaising with the appropriate kernel maintainers to do a driver contribution. I know linux-leds mailing list exists.
It's the same as for any other kernel change, make a patch, run it through 'scripts/get_maintainer.pl' to determine where to send it to, and then send it to them :) The kernel has loads of documentation on how to submit a patch, I recommend reading that and if you have specific questions afterward, please ask. hope this helps, greg k-h
Hi, When sending raw ethernet frames over an AF_PACKET/SOCK_RAW socket, "ss" always reports a empty send queue, even when it is obviously full of packets. The root cause is that packet_snd() never updates sk->sk_wmem_alloc, which is the counter used by "ss" for the send queue occupation. All other socket types end up calling something like: refcount_add(SOME_SIZE, &sk->sk_wmem_alloc) Unfortunately, the way it is done is extremely varied across socket families, so it is not immediately obvious to a newbie where to add this increment, and associated decrement on skb free. I'd appreciate any insight on (1) perhaps why it is deemed unimportant to do send queue accounting for AF_PACKET; and (2) if it is just a bug, where the incr/decr should take place. Additionally, an explanation of "tpacket_snd()" vs "packet_snd()" would be very welcome, as the former does proper send queue accounting, while the latter doesn't. Thanks in advance, -Alex
participants (3)
-
Alexandre Ferrieux -
Craig McQueen -
Greg KH