Re: [PATCH 1/4] thunderbolt: add platform nhi driver

[Sven Peter <sven@kernel.org>]

On 11/9/26 14:56, Konrad Dybcio wrote:
> On 11/7/26 8:04 PM, Sven Peter wrote:
>>> Add a new file plat.c to register platform NHI driver for MediaTek
>>> mt8901/mt8992 SoCs.
>>>
>>> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
>>>
>> [...]
>>
>>> +
>>> +static void nhi_plat_shutdown(struct platform_device *pdev)
>>> +{
>>> +	nhi_plat_do_remove(pdev, true);
>>> +}
>>> +
>>> +
>>> +#ifdef CONFIG_OF
>>> +static const struct of_device_id nhi_plat_of_match[] = {
>>> +	{ .compatible = "thunderbolt-platform" },
>> Do you already have hardware that probes via device tree? You'll have to
>> write bindings and get them reviewed before adding any compatible here.
>> Generic ones like you used here aren't usually allowed.
>>
>> If you don't have a dts based platform I'd probably drop this, not much of
>> this code here is e.g. re-usable for Apple since they like to think very
>> different, see my series in [1] that I can pick up again now that we
>> made progress on how to represent connections between the NHI and the
>> protocol adapters.
>>
>> Not sure about qualcom since I haven't seen a series for the NHI yet but
>> I'm sure Konrad can comment there. I kinda expect that it won't have
>> much shared code either.
> We're in the same boat regarding thinking different. This driver is
fun!

> for implementations where the underlying hardware is abstracted away
> (be it through architecture or intermediate firmware) and the TBT
> layer writes are enough to e.g. power sequence the connected buses,
> just like on Intel.
>
> For the OF compatible, we definitely do need bindings and I too would
> like to know if this is actually exercised - if not, we should cut it
> out and trivially bring it back when/if the need comes around.
Yeah, agreed, and ideally directly with a vendor,XXXX-thunderbolt 
compatible (or similar) only with the generic one (assuming the dt 
maintainers agree) as a fallback.



Sven