On 9/5/2024 11:42 AM, Dikshita Agarwal wrote:
>
>
> On 8/29/2024 2:43 PM, Dmitry Baryshkov wrote:
>> On Tue, Aug 27, 2024 at 03:08:03PM GMT, Bryan O'Donoghue wrote:
>>> On 27/08/2024 11:05, Dikshita Agarwal via B4 Relay wrote:
>>>> +static const struct of_device_id iris_dt_match[] = {
>>>> + { .compatible = "qcom,sm8550-iris", },
>>>> + { .compatible = "qcom,sm8250-venus", },
>>>> + { },
>>>> +};
>>>> +MODULE_DEVICE_TABLE(of, iris_dt_match);
>>>
>>> The enabling patch for the compat strings should come last - if its first
>>> then the time between the compat add and the last patch is a dead zone where
>>> things are bound to break on a booting board.
>>
>> But then it's impossible to test the driver in the interim state.
>> Moreover enabling it at the end only makes it hard to follow platform
>> data changes. What about adding sm8550 at this point and adding sm8250
>> at the end? Or enabling qcom,sm8550-iris and the fake qcom,sm8250-iris
>> now (and clearly documenting it as fake) and as the last patch change it
>> to qcom,sm8250-venus.
>
> Sure, we will add qcom,sm8250-iris at this point so that it enables the
> testing of the driver, and will add one patch at the last to add
> qcom,sm8250-venus.
Sorry fixing the typos. what I meant was,
we will add qcom,sm8550-iris at this point so that it enables the
testing of the driver, and will add one patch at the last to add
qcom,sm8250-venus.
>
> Thanks,
> Dikshita
>>
>
