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 72:
```c
int days, remaining_seconds;
days = div64_u64_rem(timestamp, seconds_per_day, (uint64_t *)&remaining_seconds);
```
`div64_u64_rem()` takes a `u64 *remainder` parameter (confirmed in `include/linux/math64.h:54`) and writes 8 bytes through it. But `remaining_seconds` is `int` (4 bytes). The cast `(uint64_t *)&remaining_seconds` silences the compiler but creates two real bugs:
1. **Stack corruption**: 4 bytes of adjacent stack are overwritten.
2. **Endianness bug**: On big-endian systems, the meaningful lower 32 bits of the remainder end up in the wrong half.

**Fix analysis:** The patch introduces a properly-typed `u64 remainder` temporary:
```c
uint64_t month = 0, day = 0, hour = 0, minute = 0, second = 0, remainder;
...
days = div64_u64_rem(timestamp, seconds_per_day, &remainder);
/* remainder will always be less than seconds_per_day. */
remaining_seconds = remainder;
```

This is the right approach for v2. The v1 presumably changed `remaining_seconds` itself to `u64`, which would then require `do_div()` or similar at the later division sites (lines 98-100). By using a temporary and assigning back to `int`, the subsequent arithmetic on `remaining_seconds` stays as native `int` division — no 64-bit division helpers needed.

**Comment on the comment:** The inline comment `/* remainder will always be less than seconds_per_day. */` is helpful — it justifies the narrowing assignment. `seconds_per_day` is 86400, well within `int` range, so the truncation is safe.

**One minor observation:** `days` is also `int` (32-bit) and receives the return value of `div64_u64_rem()`, which returns `u64`. For a Unix timestamp, this quotient is the number of days since epoch — currently ~20,500 and growing. An `int` can hold up to ~2.1 billion days, so this is safe in practice, but it's a preexisting issue and outside the scope of this patch.

**Verdict:** The fix is correct, well-motivated, and minimal. The Fixes tag correctly references the commit that introduced the buggy code. No issues found.

Reviewed-by quality: **Good to merge as-is.**

---
Generated by Claude Code Patch Reviewer