Claude review: gpu: host1x: Fix device reference leak in device_add() error path

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

Patch Review

**Bug identification is correct.** In the original code at `bus.c:511-520` (pre-patch), when `device_add()` fails:
```c
if (list_empty(&device->subdevs)) {
    err = device_add(&device->dev);
    if (err < 0)
        dev_err(&device->dev, "failed to add device: %d\n", err);
    else
        device->registered = true;
}

return 0;
```
The function always returns 0, the device stays on `host1x->devices`, and the reference from `device_initialize()` is never dropped. This is indeed a leak.

**Critical bug in the fix — double list removal:**

The patch adds:
```c
if (err < 0) {
    dev_err(&device->dev, "failed to add device: %d\n", err);
    list_del(&device->list);       /* poisons prev/next */
    put_device(&device->dev);      /* triggers release callback */
    return err;
}
```

`put_device()` drops the last reference, triggering `host1x_device_release()` (set at `bus.c:479`):
```c
static void host1x_device_release(struct device *dev)
{
    struct host1x_device *device = to_host1x_device(dev);
    __host1x_device_del(device);
    kfree(device);
}
```

And `__host1x_device_del()` at line 443 does:
```c
list_del_init(&device->list);
```

Since `list_del()` already poisoned the pointers with `LIST_POISON1`/`LIST_POISON2`, this second removal dereferences those sentinel addresses. Without `CONFIG_DEBUG_LIST`, `__list_del_entry_valid()` returns `true` unconditionally and the kernel will oops trying to write through poisoned pointers.

**Fix:** Remove the `list_del(&device->list)` line entirely. The `put_device()` → `host1x_device_release` → `__host1x_device_del` path already handles list removal at line 443. So the error handling should be simply:
```c
if (err < 0) {
    dev_err(&device->dev, "failed to add device: %d\n", err);
    put_device(&device->dev);
    return err;
}
```

Alternatively, if the author wants to keep the explicit `list_del`, use `list_del_init()` instead so the entry points to itself and the subsequent `list_del_init()` in `__host1x_device_del` is a harmless no-op. But this is less clean since it duplicates logic already in the release path.

**Minor style issue:** The patch produces:
```c
    }
    else
        device->registered = true;
```
Per kernel coding style (Chapter 3), when the `if` branch uses braces, the `else` should be on the same line as the closing brace and should also use braces:
```c
    } else {
        device->registered = true;
    }
```
The original code had no braces on either branch so it was consistent; now it's mixed.

**Pre-existing issue (not this patch's fault):** The `host1x_device_parse_dt()` error path at line 487-489 uses `kfree(device)` directly after `device_initialize()`, which is technically incorrect (should use `put_device()`). However, it happens to be safe because the device isn't on any list at that point, and the release function's `list_del_init` on a self-pointing entry is benign. Mentioning this only for completeness — it shouldn't be addressed in this patch.

---
Generated by Claude Code Patch Reviewer