[PATCH] clocksource/drivers/riscv: Refuse to probe on T-Head

[Palmer Dabbelt]

On Thu, 09 Feb 2023 15:40:45 PST (-0800), Conor Dooley wrote:
> Hey Palmer,
>
> On Thu, Feb 09, 2023 at 03:23:02PM -0800, Palmer Dabbelt wrote:
>> From: Palmer Dabbelt <palmer at rivosinc.com>
>> 
>> As of d9f15a9de44a ("Revert "clocksource/drivers/riscv: Events are
>> stopped during CPU suspend"") this driver no longer functions correctly
>> for the T-Head firmware.  That shouldn't impact any users, as we've got
>> a functioning driver that's higher priority, but let's just be safe and
>> ban it from probing at all.
>> 
>> Signed-off-by: Palmer Dabbelt <palmer at rivosinc.com>
>> ---
>> This feel super ugly to me, but I'm not sure how to do this more
>> cleanly.  I'm not even sure if it's necessary, but I just ran back into
>> the driver reviewing some other patches so I figured I'd say something.
>
> I'm not super sure what you're trying to fix here. That revert went
> through to restore behaviour for the SiFive stuff that do deliver events
> in suspend.

My worry was that we'd end up probing the SBI driver on T-Head systems, 
where it doesn't work (as the combination of SBI timer and SBI suspend 
depends on unspecified behavior).  So we'd be better off just failing 
early and obviously in the case, rather than letting users think they 
could get away with only the SBI drivers.

> Subsequently, we added a DT property (probably the wrong one tbh, but
> that's all said and done now) that communicates that a timer is
> incapable of waking the cpus. See commit 98ce3981716c ("dt-bindings:
> timer: Add bindings for the RISC-V timer device") & the full patchset is
> at:
> https://lore.kernel.org/linux-riscv/20230103141102.772228-1-apatel@ventanamicro.com/
>
> AFAIU, the binding for the T-HEAD clint was only accepted in the last
> week & there's nothing actually using this timer. IIRC, when I wanted to
> test the timer, Samuel cooked me up a WIP openSBI etc to enable it.

That makes sense.  I'd assumed these DTs just had the SBI timer in there 
(as a bunch of other stuff requires it), but from Samuel's reply it 
sounds like I was just wrong here.  I guess we're sort of in a grey area 
for DTs that aren't in the kernel source tree, but this code is ugly 
enough I'm OK just ignoring those.

> So ye, I don't think this is needed fortunately!

Ya, I think so too.

>
> Cheers,
> Conor.