Re: [PATCH v3 04/18] soc: qcom: Add Qualcomm minidump kernel driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/8/2023 12:10 AM, 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 fail the other probe if it is already initialized with proper logging..e.g

Another way to think here is what if you have chiplets? Two SOCs looks like one as a product? How does your driver will behave in those cases?

---Trilok Soni



[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux