On 23-03-10 10:37:42, Krzysztof Kozlowski wrote: > On 10/03/2023 10:34, Abel Vesa wrote: > >>> I assume you mean it breaks if someone is using old approach DTS with a > >>> kernel that would have ICE driver merged. Yes, that it does. And for > >>> that, in the v3, I'll make of_qcom_ice_get check if there is a reg entry > >>> with name "ice" and create an ICE instance but for the same dev as the > >>> consumer driver. OTOH, if there is no reg entry called "ice", it will > >>> look up a device based on phande of qcom,ice property. This will allow > >>> legacy style DTS to work fine, while using the unified driver as a > >>> library, in that case. For newer platforms, the recommended approach > >>> will be to add a new ICE node and use qcom,ice property. > >> > >> For the driver this sounds good. I still think that existing (older) DTS > >> should not have regs removed, because this affects other users of kernel > >> DTS. > > > > Yes, that's what I meant, the already supported platforms will remain > > with ice reg in the consumer node. > > ... unless you plan to add to them UFS ICE, which would be nice feature > thus justifying DTS re-shuffle :) By supported I meant the ones that have ICE support already :) > > Best regards, > Krzysztof >
