In Part 1 of this series, we took a crypto driver from working code to something the Linux kernel community can take seriously — clean builds, zero static analysis warnings, a validated DT binding, and checkpatch errors at zero. Now the work shifts. This second and final part covers the entire outward journey: packaging your code into a patch series, writing a cover letter, using get_maintainer.pl to find the right people, sending with git send-email, responding to review feedback, tracking your patch on Patchwork, understanding realistic timelines, and adding your MAINTAINERS entry. From the first send to the mainline — this is how it works.

Step 5: Generating the Patch Series

Structuring Your Git History

Each patch in your series must be a clean, focused git commit. The commit message IS the patch description that appears in git log forever:

Generating the Patch Files

The Cover Letter

The cover letter (0000-cover-letter.patch) introduces the entire series. Reviewers read this first. Invest time in it:

Step 6: Finding Maintainers and Sending

get_maintainer.pl — Never Skip This
The get_maintainer.pl script reads MAINTAINERS file and the git history to determine exactly who should receive your patches. Never manually guess the recipients:

Key Crypto Subsystem Maintainers (as of 2025)

Note: This maintainers list can be different in the future.

Sending with git send-email

Step 7: The Review Process

What Happens After You Send

1. Your email arrives at the mailing list and is immediately visible at lore.kernel.org
2. Patchwork automatically picks it up and creates a patch series entry
3. CI systems (0-day, kernel-test-robot) run automated tests within hours
4. Reviewers and maintainers read and respond within days to weeks
5. You receive review feedback as replies to your patch emails
6. You send a revised version (v2, v3…) addressing all feedback
7. Once the maintainer is satisfied, they apply it to their subsystem tree

Types of Reviewer Tags

Responding to Review Feedback
Every review comment needs a response — either you fix it, or you explain why you disagree (politely, with technical justification):

How Many Iterations to Expect

Step 8: Tracking Your Patch Status

Patchwork: Your Patch Dashboard

Patchwork is the web interface that tracks all patches sent to kernel mailing lists. It’s where you watch your patch status:

• Linux kernel Patchwork: https://patchwork.kernel.org/project/linux-crypto/list/
• Patches are automatically detected from mailing list traffic
• Status changes: New → Under Review → Accepted / Rejected / Superseded
• You can see which patches are in maintainer queues
• b4 tool integrates directly with Patchwork for easy patch management

The Kernel Testing Robot (0-day)

The kernel-test-robot (also called 0-day) automatically tests patches sent to mailing lists. Within hours of your submission, you may get an automated reply like:

These automated reports are extremely useful — they catch compilation failures on architectures you didn’t test. Always fix everything the test robot reports before sending v2.

The Crypto Subsystem Git Trees

Step 9: Realistic Timelines

One of the most common questions from developers new to upstreaming: how long does this take? The honest answer: it varies enormously, but here are realistic expectations based on actual crypto driver upstream experiences:

The Linux Kernel Release Cycle

Understanding the kernel release cycle is critical for setting timeline expectations:

Step 10: MAINTAINERS Entry

Every new driver needs a MAINTAINERS file entry. This tells git who to notify for future patches touching your driver and where the code lives:

The Complete Workflow Checklist

Use this checklist every time you prepare a patch series for submission:

Pre-submission (Driver Quality)

1. Compiles cleanly: arm, arm64, x86_64, with W=1
2. make C=2 CHECK=sparse M=drivers/crypto/vendor/<driver_name>/ — zero warnings
3. make C=1 CHECK=scripts/coccicheck M=drivers/crypto/vendor/<driver_name>/ — addressed
4. smatch kchecker drivers/crypto/vendor/<driver_name>/<driver_name>.c — no error: severity
5. scripts/checkpatch.pl –strict — zero ERRORs, all WARNINGs justified
6. tcrypt module passes all test vectors for your algorithms
7. DT binding validates: make dt_binding_check && make dtbs_check

Patch Preparation

1. git log is clean: each commit compiles, has good message
2. Subject format: ‘subsystem: component: Description’ imperative mood
3. Signed-off-by matches git user.email on every commit
4. Cover letter written: explains WHY, hardware capability, test results
5. If v2+: cover letter documents all changes since previous version
6. git format-patch -N –cover-letter -vN generated

Recipients

1. scripts/get_maintainer.pl run on ALL patches
2. Herbert Xu in To: for crypto patches
3. linux-crypto@vger.kernel.org in To:
4. devicetree@vger.kernel.org in Cc: if DT binding patch present
5. ARM list in Cc: if ARM-specific hardware

Sending

1. git send-email –dry-run first — verify recipients and format
2. Confirm chainreplyto = false in .gitconfig
3. Send with git send-email or b4
4. Verify patches appear correctly at lore.kernel.org within minutes
5. Check Patchwork to confirm the series was detected
6. Monitor for kernel-test-robot feedback within 24 hours

Conclusion: Patience, Persistence, and Polish

Upstreaming a crypto driver is a marathon, not a sprint. The kernel community’s high standards exist because this code runs on millions of devices handling real cryptographic operations. Security matters, and maintainers take it seriously.

The most important things to remember:

• Patience: Review takes time. A week without response is normal. Follow up after 2-3 weeks.
• Polish: Clean code and clean patches get faster review. Messy submissions get pushed to the back.
• Persistence: Almost every driver goes through multiple revisions. v3 is normal. v6 happens.
• Community: The crypto maintainers — Herbert Xu, Ard Biesheuvel — are genuinely helpful once you show you’ve done your homework.
• Lurk first: Read the mailing list for a few weeks before sending. Understand the culture.

When your patch finally appears in Linus’s tree, it’s genuinely one of the most satisfying moments in embedded software development. Your code, reviewed by some of the best systems programmers in the world, running on kernels everywhere.

Start today. Run checkpatch.pl on your driver. Fix every warning. Run sparse. Subscribe to linux-crypto. Read a few patch threads. Then send your v1.

Essential References