Message-ID: <CAD=FV=V-OUSO6E5+1SFZrFbWSxqzEYXKuE-CqCcjp++ytmL0ow@mail.gmail.com>
Date:   Tue, 14 Jul 2020 15:49:11 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>
Cc:     sparate@...eaurora.org,
        Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>,
        mturney@...eaurora.org,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Jeffrey Hugo <jhugo@...eaurora.org>, dhavalp@...eaurora.org,
        Rajendra Nayak <rnayak@...eaurora.org>,
        mkurumel@...eaurora.org, Ravi Kumar Bokka <rbokka@...eaurora.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 0/4] nvmem: qfprom: Patches for fuse blowing on
 Qualcomm SoCs

Srinivas,

On Fri, Jul 10, 2020 at 7:35 AM Douglas Anderson <dianders@...omium.org> wrote:
>
> This series enables blowing of fuses on Qualcomm SoCs by extending the
> existing qfprom driver with write support.
>
> A few notes:
> - Though I don't have any firsthand knowledge of it, it's my
>   understanding that these changes could be used on any Qualcomm SoC.
>   However, it's likely not very useful on most boards because the
>   bootloader protects against this.  Thus the write support here is
>   likely only useful with a cooperating bootloader.
> - Blowing fuses is truly a one-way process.  If you mess around with
>   this and do something wrong you could irreparably brick your chip.
>   You have been warned.
>
> Versions 1 and 2 of this series were posted by Ravi Kumar Bokka.  I
> posted version 3 containing my changes / fixups with his consent.  I
> have left authorship as Ravi but added my own Signed-off-by.
>
> Version 4 is a minor spin over version 3.
>
> Version 5 is an even more minor spin and just bumps up some timings to
> fix a failure reported by Ravi on one device.  I've collected Rob
> Herring's reviews and (as far as I know) this is ready to land.
>
> Changes in v5:
> - QFPROM_FUSE_BLOW_POLL_US 10 => 100
> - QFPROM_FUSE_BLOW_TIMEOUT_US 100 => 1000
>
> Changes in v4:
> - Maintainer now listed as Srinivas.
> - Example under "soc" to get #address-cells and #size-cells.
> - Clock name is "core", not "sec".
> - Example under "soc" to get #address-cells and #size-cells.
> - Only get clock/regulator if all address ranges are provided.
> - Don't use optional version of clk_get now.
> - Clock name is "core", not "sec".
> - Cleaned up error message if couldn't get clock.
> - Fixed up minor version mask.
> - Use GENMASK to generate masks.
> - Clock name is "core", not "sec".
>
> Changes in v3:
> - Split conversion to yaml into separate patch new in v3.
> - Use 'const' for compatible instead of a 1-entry enum.
> - Changed filename to match compatible string.
> - Add #address-cells and #size-cells to list of properties.
> - Fixed up example.
> - Add an extra reg range (at 0x6000 offset for SoCs checked)
> - Define two options for reg: 1 item or 4 items.
> - No reg-names.
> - Add "clocks" and "clock-names" to list of properties.
> - Clock is now "sec", not "secclk".
> - Add "vcc-supply" to list of properties.
> - Fixed up example.
> - Don't provide "reset" value for things; just save/restore.
> - Use the major/minor version read from 0x6000.
> - Reading should still read "corrected", not "raw".
> - Added a sysfs knob to allow you to read "raw" instead of "corrected"
> - Simplified the SoC data structure.
> - No need for quite so many levels of abstraction for clocks/regulator.
> - Don't set regulator voltage.  Rely on device tree to make sure it's right.
> - Properly undo things in the case of failure.
> - Don't just keep enabling the regulator over and over again.
> - Enable / disable the clock each time
> - Polling every 100 us but timing out in 10 us didn't make sense; swap.
> - No reason for 100 us to be SoC specific.
> - No need for reg-names.
> - We shouldn't be creating two separate nvmem devices.
> - Name is now 'efuse' to match what schema checker wants.
> - Reorganized ranges to match driver/bindings changes.
> - Added 4th range as per driver/binding changes.
> - No more reg-names as per driver/binding changes.
> - Clock name is now just "sec" as per driver/binding changes.
>
> Ravi Kumar Bokka (4):
>   dt-bindings: nvmem: qfprom: Convert to yaml
>   dt-bindings: nvmem: Add properties needed for blowing fuses
>   nvmem: qfprom: Add fuse blowing support
>   arm64: dts: qcom: sc7180: Add properties to qfprom for fuse blowing
>
>  .../bindings/nvmem/qcom,qfprom.yaml           |  96 ++++++
>  .../devicetree/bindings/nvmem/qfprom.txt      |  35 --
>  arch/arm64/boot/dts/qcom/sc7180-idp.dts       |   4 +
>  arch/arm64/boot/dts/qcom/sc7180.dtsi          |  10 +-
>  drivers/nvmem/qfprom.c                        | 314 +++++++++++++++++-
>  5 files changed, 411 insertions(+), 48 deletions(-)

I know it's a little early to ping and that folks are busy, but I'm
getting to a bit of a time crunch to land this driver in the Chrome OS
kernel tree.  I'd prefer for it to land upstream first so I can pick
exactly what landed but if not then I'll just pick what I posted to
the mailing list.

Any chance you can give an approximate timeline for when it might land
so I can either wait a little while longer or stop waiting and just
take what I posted to the lists?

Thanks!  :-)

-Doug

Powered by blists - more mailing lists