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:3.205 / U:0.580 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site