Claude review: drm/amd/ras: Fix type size of remainder argument

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

Patch Review

**Problem analysis:** The original code at line 70-72 of `ras_core.c` declares:
```c
int days, remaining_seconds;
...
days = div64_u64_rem(timestamp, seconds_per_day, (uint64_t *)&remaining_seconds);
```

`div64_u64_rem()` has the signature (from `include/linux/math64.h:54`):
```c
static inline u64 div64_u64_rem(u64 dividend, u64 divisor, u64 *remainder)
```

Writing a `u64` (8 bytes) through a pointer to a 4-byte `int` is an out-of-bounds stack write. On little-endian x86 this happens to work by luck (the low 4 bytes land correctly, and the high 4 bytes overflow into adjacent stack space), but it's undefined behavior and would produce wrong results on big-endian architectures.

**Fix review:** The patch changes `remaining_seconds` from `int` to `uint64_t` and removes the cast:
```c
+	uint64_t remaining_seconds;
...
+	days = div64_u64_rem(timestamp, seconds_per_day, &remaining_seconds);
```

This is the correct fix. The value stored in `remaining_seconds` (seconds within a day, range 0–86399) fits comfortably in any integer type, so the widening has no functional impact on the subsequent arithmetic at lines 97-100 where `remaining_seconds` is used for division/modulo to compute hours, minutes, and seconds.

**Minor observations (not blocking):**

1. The return type of `div64_u64_rem()` is `u64`, but `days` remains `int`. For timestamp values representable by a `u64`, the number of days could theoretically exceed `INT_MAX` (~5.8 million years), but practically this is fine since the function processes realistic Unix timestamps. Not something this patch needs to address.

2. The `seconds_per_day`, `seconds_per_hour`, and `seconds_per_minute` variables are `int`, and they are passed as the `u64 divisor` argument to `div64_u64_rem()` — this is an implicit widening conversion which is safe and correct. No issue here.

**Reviewed-by: Looks correct.** The fix is minimal, targeted, and solves both the `-Warray-bounds` warning and the underlying type-safety/endianness bug.

---
Generated by Claude Code Patch Reviewer