Claude review: fbdev: goldfishfb: use devm_platform_ioremap_resource()

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

Patch Review

**Correctness of the core transformation: OK**

The replacement of `platform_get_resource()` + `ioremap()` with `devm_platform_ioremap_resource()`, and the corresponding `IS_ERR()` / `PTR_ERR()` error check, is textbook correct:

```c
-	r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (r == NULL) {
-		ret = -ENODEV;
-		goto err_no_io_base;
-	}
-	fb->reg_base = ioremap(r->start, PAGE_SIZE);
-	if (fb->reg_base == NULL) {
-		ret = -ENOMEM;
+	fb->reg_base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(fb->reg_base)) {
+		ret = PTR_ERR(fb->reg_base);
 		goto err_no_io_base;
 	}
```

**Removal of `iounmap()` calls: OK**

Both the error-path and remove-path `iounmap()` removals are correct since the devm infrastructure handles cleanup automatically — on both probe failure and device removal:

```c
 err_no_irq:
-	iounmap(fb->reg_base);
 err_no_io_base:
```

```c
-	iounmap(fb->reg_base);
 	kfree(fb);
```

**Subtle behavioral change #1 — mapping size**: The original code maps exactly `PAGE_SIZE`:
```c
fb->reg_base = ioremap(r->start, PAGE_SIZE);
```
`devm_platform_ioremap_resource()` maps `resource_size(r)`, i.e. the full resource region as described in the device tree / platform data. Since the highest register offset used is `FB_GET_PHYS_HEIGHT = 0x20`, both PAGE_SIZE and any reasonably-defined resource region will cover this — so this is fine in practice, but it's a behavioral change worth being aware of.

**Subtle behavioral change #2 — `request_mem_region()` is now called**: The original code never calls `request_mem_region()`. `devm_platform_ioremap_resource()` internally calls `devm_request_mem_region()` before mapping. This is actually an improvement (the original was technically sloppy), but it could theoretically cause probe to fail if another driver has already claimed the region. For goldfish, this is extremely unlikely.

**Mixed devm / manual allocation**: The `fb` struct is still allocated with `kzalloc()` and freed with `kfree()`, while the ioremap is now devm-managed. This mixed pattern works correctly here — the devm unmap happens after `goldfish_fb_remove()` returns, but the devm infrastructure stores the mapped address in its own devres entry rather than reading it back from `fb->reg_base`, so the `kfree(fb)` preceding the devm cleanup is safe. However, a follow-up patch converting `kzalloc`/`kfree` to `devm_kzalloc` would make the lifecycle management more consistent.

**Overall**: The patch is correct and a net improvement. No blocking issues.

---
Generated by Claude Code Patch Reviewer