Claude review: fbdev: savage: fix probe-path EDID cleanup leaks

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Correctness: Good.** The patch adds the two missing cleanup calls in the right place:

```c
 failed:
#ifdef CONFIG_FB_SAVAGE_I2C
	savagefb_delete_i2c_busses(info);
+	fb_destroy_modelist(&info->modelist);
+	fb_destroy_modedb(info->monspecs.modedb);
#endif
```

Key points verified:

1. **All `goto failed` sites (lines 2265, 2281, 2310) occur after the EDID/I2C setup block (lines 2221–2228)**, so the allocations exist whenever we reach the `failed:` label. Earlier failures use distinct labels (`failed_video`, `failed_mmio`, `failed_init`, `failed_enable`).

2. **No double-free risk.** The one path that could cause trouble is line 2310 (`register_framebuffer` failure), which is reached after the success path already freed `monspecs.modedb` and set it to NULL at lines 2305–2306. But `fb_destroy_modedb` is just `kfree()` (line 697 of `fbmon.c`), which is a no-op on NULL. The modelist is NOT freed on the success path before `register_framebuffer`, so `fb_destroy_modelist` is also safe there.

3. **Placement inside `#ifdef CONFIG_FB_SAVAGE_I2C` is correct** since the allocations only happen under that same guard (lines 2221–2228).

**Minor observation (not a blocker):** The existing `savagefb_remove()` function (line 2342) also doesn't call `fb_destroy_modelist()`. On the success path, `monspecs.modedb` is freed at line 2305, but the modelist entries created at line 2226 are never freed during normal remove. This is a pre-existing leak unrelated to this patch — but the author may want to address it in a follow-up.

**Commit message:** Accurate and well-written. Clearly describes the problem, the root cause, and the fix.

---
Generated by Claude Code Patch Reviewer