Srinivas, On Fri, Jul 10, 2020 at 7:35 AM Douglas Anderson <dianders@xxxxxxxxxxxx> 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
