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 :) Best regards, Krzysztof
