Skip to content

fix: advertise cPhyEnhance only when 1394a enhancements are enabled - #7

Merged
mrmidi merged 1 commit into
mrmidi:mainfrom
gly11:fix/config-rom-1394a-capabilities
Apr 17, 2026
Merged

mrmidi merged 1 commit into
mrmidi:mainfrom
gly11:fix/config-rom-1394a-capabilities

Conversation

@gly11

@gly11 gly11 commented Apr 15, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • Derive the local Config ROM node capabilities from active controller state instead of a fixed constant
  • Advertise cPhyEnhance only when 1394a PHY/link enhancements were actually enabled successfully
  • Add host tests covering both the enabled and disabled capability cases

Why

The driver currently serializes a fixed node capability value into the local Config ROM even when 1394a enhancements are skipped or fail to initialize.

Peers see cPhyEnhance advertised even though the controller did not actually enable the corresponding enhancement path. In that fallback case, the Config ROM no longer matches the driver's effective runtime state.

This change keeps the advertised local node capabilities aligned with the hardware state that was successfully brought up.

What changed

  • Replaced the fixed kDefaultNodeCapabilities constant with MakeNodeCapabilities(bool phyEnhanceEnabled) in OHCIConstants.hpp
  • Updated StageConfigROM() to pass phyConfigOk_ into the helper
  • Added 2 tests: disabled and enabled cPhyEnhance cases

Scope

Only changes local Config ROM capability advertisement.

Does not change:

  • Bus-management policy
  • The successful 1394a-enhanced path beyond making the advertisement conditional

Test Plan

  • cmake -S tests -B build/tests_build && cmake --build build/tests_build --target ASFWConfigROMTests
  • ./build/tests_build/ASFWConfigROMTests --gtest_filter="ConfigROMBuilderTests.NodeCapabilities*" — 2/2 passed
  • ./build.sh — full Xcode build succeeded (0 errors, no new warnings)

🤖 Generated with Claude Code

@gly11
gly11 marked this pull request as ready for review April 15, 2026 11:01
@mrmidi

mrmidi commented Apr 17, 2026

Copy link
Copy Markdown
Owner

Looks good for me. I've didn't even bothered with phyEnhanceEnabled (for mid 2000 devices is always enabled I guess). Just curious what kind of bizarre hardware do you working with :)

@mrmidi
mrmidi merged commit 6976a87 into mrmidi:main Apr 17, 2026
1 of 2 checks passed
@gly11

gly11 commented Apr 22, 2026

Copy link
Copy Markdown
Contributor Author

Looks good for me. I've didn't even bothered with phyEnhanceEnabled (for mid 2000 devices is always enabled I guess). Just curious what kind of bizarre hardware do you working with :)

Hi mrmidi, I’ve actually been working with some vintage film scanners that use FireWire. Not exactly the original use case for this project, but the low-level stuff maps surprisingly well. Still figuring out some quirks on my side 😄

@gly11
gly11 deleted the fix/config-rom-1394a-capabilities branch April 22, 2026 17:39
mrmidi added a commit that referenced this pull request Jun 12, 2026
fix: advertise cPhyEnhance only when 1394a enhancements are enabled
forkt69 pushed a commit to forkt69/ASFireWire that referenced this pull request Aug 28, 2026
fix: advertise cPhyEnhance only when 1394a enhancements are enabled
mrmidi pushed a commit that referenced this pull request Sep 15, 2026
…eardown

FCPTransportTests.RejectsResponseForInvalidatedRouteAfterRebind and
RejectsWriteCompletionFromInvalidatedRoute crashed with SEGFAULT.

Diagnosed with AddressSanitizer as stack-use-after-return, not the stack
overflow the fault address and unwind failure first suggested:

  ERROR: AddressSanitizer: stack-use-after-return
    #0 ...TestBody()::$_0::operator()   FCPTransportTests.cpp:129
    #7 FCPTransport::Shutdown()          FCPTransport.cpp:301
    #8 FCPTransportTests::TearDown()     FCPTransportTests.cpp:74

Both tests invalidate the route on purpose, so their command never completes and
is still pending when TearDown() runs Shutdown(). Shutdown() then completes
every pending and queued command with kTransportError -- correct behaviour, it
must not leak outstanding work -- which invokes a completion that captured
`&completionCount`, a TestBody() local whose frame is already gone.

The driver is not at fault and is unchanged. The other tests in this file are
safe only incidentally: their commands complete inside the test body, so
Shutdown() finds nothing pending.

Fix: own the counter on the fixture, so its lifetime spans TearDown.

Verified: both tests pass under ASan with no sanitizer findings, and the full
host suite is 1653/1653 (previously 1651/1653 with these two failing on
unmodified origin/main).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
(cherry picked from commit 171e4afe510114d4b8e152fc5687513f042969c2)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants