Well, this is annoying. Somewhere between v6.9 and v6.10, one of the serial ports on the #beaglebone black stopped working properly. It has something to do with DMA. I guess the AM33xx has reached the stage of gradual deterioration in kernel support where little things keep breaking but nobody notices because all the developers have moved on to newer, shinier things.

@mansr A few weeks ago I dug out a PocketBeagle that I'd bought years ago w/o even opening up. Got it working with the latest OS image and fiddled with it a bit. There has been a lot of work on drivers since last I Beagled so that was nice, but compared to the newer RISC-V Linux SBCs I've been messing with it really felt kind of creaky and slow.

@emeb Slow or not, we have thousands of devices in the field using that chip, and they deserve a new kernel.

@mansr Oh absolutely, and I'd be cautious about inferring too much about overall quality from simple things like boot time. The Milk-V Duo board that has a stripped-down busybox OS and boots in 4 seconds is a far cry from the Debian-based Beagle OS loaded up with features that takes more than a minute to give me a log-on.

This is the offending commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1788cf6a91d9fa9aa61fc2917afe192c23d67f6a

@mansr Funny how the commit mentions that omap needed a bit more care.

@mansr FWIW they’re a backbone of the KernelCI arm32 coverage (and my own), mostly because I have a relatively large pile of them in my lab (and one more I should wire in).

@broonie I found the problem: https://lore.kernel.org/linux-serial/20250430163709.15850-1-mans@mansr.com/

Of course, the only reply is from Greg's snark bot.

@mansr @broonie
"You have marked a patch with a "Fixes:" tag for a commit that is in an older released kernel, yet you do not have a cc: stable line in the signed-off-by area at all, which means that the patch will not be applied to any older kernel releases."

ROTFL. About anything with a Fixes:-tag (and much more) will be backported.

@geert @broonie And why can't that bot just add the cc instead of being condescending? Much quicker for everyone.

@mansr @geert Like Geert was saying that’s effectively what happens with the other bots that pick things up for stable anyway. That form letter is kind of bitrot at this point, in days of yore it was a bit more useful to have the tag directly in the original mail.

@broonie @geert It's worse than bitrot. The tone of that response is extremely off-putting, and it makes me less likely to bother sending a patch at all the next time.

@mansr @geert I mean the fact that the mail is being sent is bitrot. Tone is tricky with form letters like that, you need something that is clear and direct enough to be comprehensible to people who don’t speak English well and to all experience levels. Polite often translates into optional request if you’re not careful

@geert @mansr @broonie No, it's not guaranteed to be backported at all, cc: stable is still required if you want it to show up AND want to be notified if it does not apply. We get to "Fixes:" only patches on a "when we have the spare cycles let's go look for things that people did not properly mark and attempt to do a backport if it works easily"

@mansr @broonie @geert It's a bot, and it is saying "next time, please properly mark this for stable backport as that is what you are saying you want to have happen, but yet that's not what is going to happen with the tags you provided".

If you can think of better wording for this, please let me know. Don't take bots personally please, they are trying to help.

@gregkh @broonie @mansr "not guaranteed" != "will not", so it's all in the gray area of wording...
So perhaps:
- the patch will not be applied to any older kernel releases
+ the patch may not be applied to any older kernel releases
?