Conor Dooley
Posts
467Following
143Followers
151I 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
Reading some patch discussion today (between two experienced developers/maintainers) and one cracked out a "I believe the kids these days would say '"Say you don't understand the
code without saying you don't understand the code."'
lmao, good one chief
code without saying you don't understand the code."'
lmao, good one chief
0
1
4
Conor Dooley
repeated
repeated
Krzysztof Kozlowski
krzk
I announced it before on social.kernel.org, mailing lists and finally in the Linux kernel (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25223cba5aa9a536392933782d4a7df71d9093b). So one more time, same announcement:
None of the Samsung and Samsung Foundry platforms can bring any new `dtbs_check W=1` warning.
Contributor can easily test it, so sending code which introduces such warnings is considered close to sending code which does not compile. Fast step to get your maintainer grumpy.
None of the Samsung and Samsung Foundry platforms can bring any new `dtbs_check W=1` warning.
Contributor can easily test it, so sending code which introduces such warnings is considered close to sending code which does not compile. Fast step to get your maintainer grumpy.
0
1
6
Conor Dooley
repeated
repeated
Christian Brauner 🦊🐺
brauner@mastodon.social@vegard @marcan @CyReVolt @lschuermann @monsieuricon imho, anyone who's getting into kernel development or who is open to changing their workflow should use b4 right away and avoid using git-send-email
1
6
1
Conor Dooley
conor
"Detection of individual cryptography extensions uses the unified software-based RISC-V discovery method.
At the time of writing, these discovery mechanisms are still a work in progress."
...from the documentation for ratified extensions :)
At the time of writing, these discovery mechanisms are still a work in progress."
...from the documentation for ratified extensions :)
1
0
4
Conor Dooley
conor
@sima @nicofee @marcan @nicolas17 unfortunately I know how things work for dt-bindings, and drag may be an apt word ;)
0
0
1
Conor Dooley
conor
@sima @nicofee @marcan @nicolas17 it'd be nice of the email fallback was automated via get_maintainer and hooked into a b4-relay type thing, so that contributors don't need to give a shit about what is and what isn't cross forge.
Also, since I'm not a DRM contributor, is drm-misc where the dt based stuff for arm etc ends up? That's probably quite a big chunk of where your cross subsystem/forge stuff is, given there's very often bindings & devicetree changes mixed in with drivers?
Also, since I'm not a DRM contributor, is drm-misc where the dt based stuff for arm etc ends up? That's probably quite a big chunk of where your cross subsystem/forge stuff is, given there's very often bindings & devicetree changes mixed in with drivers?
1
0
1
Conor Dooley
conor
@marcan @sima @nicofee @nicolas17 What I mean is, if you have some changes that affect both drivers/soc/apple and, idk, drivers/dma, how do you interact with the relevant maintainers for that code?
1
0
0
Conor Dooley
conor
I see today is iteration N of hating email based workflows. My 0.02 € is that I hate both, clunky aul email and clunky new UIs :)
1
0
2
Conor Dooley
conor
@sima @nicofee @marcan @nicolas17 If you switch to those, how would you interact with the rest of the kernel?
1
0
1
@jarkko cos of the experimental SBI extension? FWIW, the patch acceptance policy for standard extensions is that you either need to be a frozen extension from RVI or actually available to people for vendor stuff. See
<https://docs.kernel.org/riscv/patch-acceptance.html#submit-checklist-addendum>.
I don't know which of the two your keystone work is intended to be though.
<https://docs.kernel.org/riscv/patch-acceptance.html#submit-checklist-addendum>.
I don't know which of the two your keystone work is intended to be though.
1
0
0
@jarkko kinda random thought of no real merit at this stage of your develop, why's the code in arch/riscv? It seems as if it would be better off in drivers/firmware?
Obv. that doesn't matter at this remove, since you're using experimental SBI extension IDs etc so nothing here is mergeable, but I am curious :)
Obv. that doesn't matter at this remove, since you're using experimental SBI extension IDs etc so nothing here is mergeable, but I am curious :)
1
0
0