Conor Dooley
Posts
461Following
145Followers
149I like cycling, powerlifting, bad video games and metal.
Otherwise, I occupy my time with various bits in RISC-V land.
~useless, placeholder, website: https://www.conchuod.ie/
Conor Dooley
conor
Heh, this would've been nice to have attended year ago:
https://fosdem.org/2023/schedule/event/pwm/
"The audience learns the general concept of PWMs, about the corner cases in their usage and driver design, and how to avoid the common pitfalls often pointed out to authors of new PWM drivers during the review process."
https://fosdem.org/2023/schedule/event/pwm/
"The audience learns the general concept of PWMs, about the corner cases in their usage and driver design, and how to avoid the common pitfalls often pointed out to authors of new PWM drivers during the review process."
0
1
1
@gmarkall You running mainline + patches, or the tree they ship? Either way, yell if something that should work doesn't? I figure stuff ship works for but probably hasn't see diverse use.
They sent me over some docs, so I was able to look a bit more closely at the power management unit patchset - there's not a lot of drivers to compare against there so that one is mainly what worried me.
They sent me over some docs, so I was able to look a bit more closely at the power management unit patchset - there's not a lot of drivers to compare against there so that one is mainly what worried me.
1
0
0
@gmarkall Ahh, figured. My internal gauge of LLVM build times comes from running https://github.com/ClangBuiltLinux/tc-build/build-llvm.py which builds all archs by default. 2 hours (with headroom to improve) for the single target build sounds promising in terms of being able to do native building of things.
0
0
0
Conor Dooley
conor
Listening to a podcast for the first time, where the hosts do not introduce themselves before bringing in their guest is *super* disconcerting.
Now I got 3 voices that I cannot tell apart, rather than having some time to acclimatise to the hosts...
Now I got 3 voices that I cannot tell apart, rather than having some time to acclimatise to the hosts...
1
0
1
@gmarkall I suppose you can add:
hwrng:
https://lore.kernel.org/all/20221221090819.1259443-1-jiajie.ho@starfivetech.com/
crypto:
https://lore.kernel.org/all/20221130055214.2416888-1-jiajie.ho@starfivetech.com/
pinctrl:
https://lore.kernel.org/all/20221220005529.34744-1-hal.feng@starfivetech.com/
emmc:
https://lore.kernel.org/all/20221227122227.460921-1-william.qiu@starfivetech.com/
watchdog:
https://lore.kernel.org/all/20221219094233.179153-1-xingyu.wu@starfivetech.com/
That's all I could see in my inbox.
hwrng:
https://lore.kernel.org/all/20221221090819.1259443-1-jiajie.ho@starfivetech.com/
crypto:
https://lore.kernel.org/all/20221130055214.2416888-1-jiajie.ho@starfivetech.com/
pinctrl:
https://lore.kernel.org/all/20221220005529.34744-1-hal.feng@starfivetech.com/
emmc:
https://lore.kernel.org/all/20221227122227.460921-1-william.qiu@starfivetech.com/
watchdog:
https://lore.kernel.org/all/20221219094233.179153-1-xingyu.wu@starfivetech.com/
That's all I could see in my inbox.
0
1
2
Conor Dooley
conor
re: kernel.org, protonmail & wkd: incompatibility
Show content
@monsieuricon bad it may be, but automagical encryption like that to people who are not even protonmail users is not really what would be expected. If I was a drive-by contributor, I would expect my proton account to just work.
0
0
0
re: kernel.org, protonmail & wkd: incompatibility
Show content
@broonie
> it’s a lot of hassle to arrange to view the encrypted message
If that fella replies to me, I'll probably have to go configure my mailer properly to be able to read it.
> mail-clients seems like the right place?
I felt that it may not be the right spot since the issue is not client specific, but an issue with the provider full-stop. I'd expect people to stop reading after "General Preferences" if they intend using git send-email.
I checked the docs again, and the new styling that was applied for v6.2-rc1 does actually enumerate all of the page headings, so the per client documentation is harder to overlook now. With v6.1.y and prior, it'd be very easy to overlook.
I guess I'll add a comment there & CC the users list...
> it’s a lot of hassle to arrange to view the encrypted message
If that fella replies to me, I'll probably have to go configure my mailer properly to be able to read it.
> mail-clients seems like the right place?
I felt that it may not be the right spot since the issue is not client specific, but an issue with the provider full-stop. I'd expect people to stop reading after "General Preferences" if they intend using git send-email.
I checked the docs again, and the new styling that was applied for v6.2-rc1 does actually enumerate all of the page headings, so the per client documentation is harder to overlook now. With v6.1.y and prior, it'd be very easy to overlook.
I guess I'll add a comment there & CC the users list...
0
0
0
Conor Dooley
conor
kernel.org, protonmail & wkd: incompatibility
Show content
I ran afoul of this about a year ago, and have since noticed others having the same issue a few times since.
Kernel.org publishes the WKD for all developers who have kernel.org accounts, which is grand - but protonmail has a feature where it will automagically check for WKD and use it to encrypt messags.
Mailing lists & recipients without WKD will get the regular old copy of the mail.
To quote one of the other people that ran into this:
"they told me then that it's a super-pro
builtin feature that I can't disable 🤡"
That's the same answer I got & for both of us, the solution was just to leave protonmail.
Maintainers don't know about this & get "annoyed" with patch submitters & it is equally frustrating on the other side trying to figure out why your patchset has been encrypted...
The most recent occurance of this is here:
https://lore.kernel.org/all/Y6slQLto568WfmfZ@spud/
I feel like it should be documented somewhere that this issue exists, process/email-clients.txt doesn't seem quite right. Perhaps the patches documenting it should be CC the users@linux.kernel.org ML?
Kernel.org publishes the WKD for all developers who have kernel.org accounts, which is grand - but protonmail has a feature where it will automagically check for WKD and use it to encrypt messags.
Mailing lists & recipients without WKD will get the regular old copy of the mail.
To quote one of the other people that ran into this:
"they told me then that it's a super-pro
builtin feature that I can't disable 🤡"
That's the same answer I got & for both of us, the solution was just to leave protonmail.
Maintainers don't know about this & get "annoyed" with patch submitters & it is equally frustrating on the other side trying to figure out why your patchset has been encrypted...
The most recent occurance of this is here:
https://lore.kernel.org/all/Y6slQLto568WfmfZ@spud/
I feel like it should be documented somewhere that this issue exists, process/email-clients.txt doesn't seem quite right. Perhaps the patches documenting it should be CC the users@linux.kernel.org ML?
1
7
6
@kernellogger
i dunno if i can edit here, but:
(As an aside, it bugs me when people* report a bug & then don't push the backports through where they need to be rebased)
should have been s/report a bug/fix a bug/
i dunno if i can edit here, but:
(As an aside, it bugs me when people* report a bug & then don't push the backports through where they need to be rebased)
should have been s/report a bug/fix a bug/
0
0
1
@kernellogger Oh yeah, I know. It may very well have been fixed and not backported. (As an aside, it bugs me when people* report a bug & then don't push the backports through where they need to be rebased)
I empathise with Greg pushing back on people, as it's far from good use of maintainer time to go figure it out, when the reporter has the environment needed to test a more recently kernel sitting in front of them.
I do at the same time get the flip side of it being frustrating to deal with the gap between a vendor tree & mainline - 5.15 being a pretty good choice as they go..
*by people, I mean active kernel developers
I empathise with Greg pushing back on people, as it's far from good use of maintainer time to go figure it out, when the reporter has the environment needed to test a more recently kernel sitting in front of them.
I do at the same time get the flip side of it being frustrating to deal with the gap between a vendor tree & mainline - 5.15 being a pretty good choice as they go..
*by people, I mean active kernel developers
1
0
1
@kernellogger I think I interpret this differently - he's pushing the onus on checking if the bug has been fixed onto the reporter, no?
0
0
0
@monsieuricon
One super minor thought:
If I was really new to b4, I would likely see:
"Created the default cover letter, you can edit with --edit-cover."
and be not all too sure what to do with --edit-cover. Maybe it's just me, but I never see the harm in being overly verbose with things like this. I see in some other helper text you do use the full `b4 prep --whatever`, e.g. the template cover letter.
Got some co-workers who are rare (or soon-to-be new) contributors that would benefit from not having to ask for my help sort out changelogs, figure out cc lists etc that I will have to point at this post to try out.
Also, the integration between the blog site and fediverse is super handy - no need to click off of my tab to read it!
One super minor thought:
If I was really new to b4, I would likely see:
"Created the default cover letter, you can edit with --edit-cover."
and be not all too sure what to do with --edit-cover. Maybe it's just me, but I never see the harm in being overly verbose with things like this. I see in some other helper text you do use the full `b4 prep --whatever`, e.g. the template cover letter.
Got some co-workers who are rare (or soon-to-be new) contributors that would benefit from not having to ask for my help sort out changelogs, figure out cc lists etc that I will have to point at this post to try out.
Also, the integration between the blog site and fediverse is super handy - no need to click off of my tab to read it!
0
0
1