On 08/05/2023 09:10, Mukesh Ojha wrote:
>
>
> On 5/4/2023 10:04 PM, Krzysztof Kozlowski wrote:
>> On 04/05/2023 17:21, Krzysztof Kozlowski wrote:
>>>>>
>>>>>> + ret = qcom_minidump_init_apss_subsystem(md);
>>>>>> + if (ret) {
>>>>>> + dev_err(&pdev->dev, "apss minidump initialization failed: %d\n", ret);
>>>>>> + goto unlock;
>>>>>> + }
>>>>>> +
>>>>>> + __md = md;
>>>>>
>>>>> No. This is a platform device, so it can have multiple instances.
>>>>
>>>> It can have only one instance that is created from SMEM driver probe.
>>>
>>> Anyone can instantiate more of them.... how did you solve it?
>>
>> To clarify - sprinkling more of singletons makes everything tightly
>> coupled, difficult to debug and non-portable. You cannot have two
>> instances, you have to control concurrent initialization by yourself in
>> each of such singletons.
>>
>> I understand sometimes they are unavoidable, for example when this does
>> not map to hardware property. However here you have the parent - smem -
>> which can return you valid instance. Thus you avoid entire problem of
>> file-scope variables.
>
> I get your point, why one's should avoid file scope variables.
>
>
> This is infrastructure driver and will not have multiple instances and
> even if it happens could be avoided with with the help of global mutex
> and protect below function which i am already doing at the moment and
But we do not want global mutexes... so incorrect design is being
improved by more incorrect design.
> fail the other probe if it is already initialized with proper logging..e.g
>
> "already initialized..."
>
>
> ret = qcom_minidump_init_apss_subsystem(md);
>
>
> And this will be in-lined with
>
> /* Pointer to the one and only smem handle */
> static struct qcom_smem *__smem;
>
> Let me know if you still disagree...and have some other way ?
Why the parent - smem - cannot return every consumer the instance it
has? There will be one smem having only one minidump, so all problems
solved?
Best regards,
Krzysztof
