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

[Trilok Soni]

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