lkml.org 
[lkml]   [2020]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
From
Date


On 01/06/2020 19:08, Doug Anderson wrote:
>> Am not 100% sure if "qcom,fuse-blow-frequency" is something integration
>> specific or SoC Specific, My idea was that this will give more
>> flexibility in future. As adding new SoC Support does not need driver
>> changes.
>>
>> Having said that, Am okay either way!
> Yeah, it's always a balance. I guess the question is: why do we think
> driver changes are worse than dts changes? The value still needs to
> be somewhere and having it in the driver isn't a terrible place.
>

TBH, its an overkill if we are using same IP version across multiple SoCs.

>
>> Incase we go compatible way, I would like to see compatible strings
>> having proper IP versions to have ip version rather than SoC names.
>>
>> Having SoC names in compatible string means both driver and bindings
>> need update for every new SoC which can be overhead very soon!
> Almost certainly the compatible strings should have SoC names in them.
> Yes it means a binding update every time a new SoC comes up but that
> is just how device tree works. Presumably there's enough chatter on
> this that Rob H has totally tuned it out at this point in time, but
> there are many other instances of this.
>
> NOTE: just because we have the SoC name in the compatible string
> _doesn't_ mean that the driver has to change. You already said that
> the IP version can be detected earlier in this thread, right? You
> said:
>
> I found out that there is a version register at offset of 0x6000 which
> can give MAJOR, MINOR and STEP numbers.
>
> So how about this:
>
> a) Compatible contains "SoC" version and the generic "qcom,qfrom", so:
>
> compatible = "qcom,sdm845-qfprom", "qcom,qfrom"
>
> b) Bindings will need to be updated for every new SoC, but that's
> normal and should be a trivial patch to just add a new SoC to the
> list.
>
> c) If the driver can be made to make its decisions about frequencies /
> timings completely by MAJOR/MINOR/STEP numbers then it can use those
> in its decision and it will never need to use the SoC-specific
> compatible string. The SoC-specific compatible string will only be
> present as a fallback "oops we have to workaround a bug that we didn't
> know about".

This makes more sense to me, I would still stay with MAJOR/MINOR/STEP
numbers mostly unless we are dealing with some corner cases.


thanks,
srini
>
>
>> Rob can help review once we have v2 bindings out!
> Sounds good. If you're still not convinced by my arguments we can see
> if we can get Rob to clarify once we have a v2.:-)
>
>

\
 
 \ /
  Last update: 2020-06-02 12:57    [W:0.201 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site