[PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[srinivas.kandagatla]

From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>

Hi Greg,

Here are few nvmem patches for 6.15, Could you queue
these for 6.15.

patche include
	- updates to bindings to include MSM8960, X1E80100, MS8937,
	  IPQ5018
	- add support to bit offsets for register strides exceeding
	  single byte
	- add rockchip-otp variants.
	- Few enhancements in qfprom and rochchip nvmem providers.

Thanks,
Srini

Changes since v1:
 - Merged fixup "nvmem: make the misaligned raw_len non-fatal" into
  "nvmem: core: verify cell's raw_len"

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


Akhil P Oommen (1):
  dt-bindings: nvmem: qfprom: Add X1E80100 compatible

Barnabás Czémán (1):
  dt-bindings: nvmem: Add compatible for MS8937

Dmitry Baryshkov (5):
  dt-bindings: nvmem: fixed-cell: increase bits start value to 31
  nvmem: core: fix bit offsets of more than one byte
  nvmem: core: verify cell's raw_len
  nvmem: core: update raw_len if the bit reading is required
  nvmem: qfprom: switch to 4-byte aligned reads

Heiko Stuebner (4):
  nvmem: rockchip-otp: Move read-offset into variant-data
  dt-bindings: nvmem: rockchip,otp: add missing limits for clock-names
  dt-bindings: nvmem: rockchip,otp: Add compatible for RK3576
  nvmem: rockchip-otp: add rk3576 variant data

Rudraksha Gupta (1):
  dt-bindings: nvmem: Add compatible for MSM8960

Sricharan Ramabadhran (1):
  dt-bindings: nvmem: Add compatible for IPQ5018

 .../bindings/nvmem/layouts/fixed-cell.yaml    |  2 +-
 .../bindings/nvmem/qcom,qfprom.yaml           |  4 ++
 .../bindings/nvmem/rockchip,otp.yaml          | 25 ++++++++++++
 drivers/nvmem/core.c                          | 40 +++++++++++++++----
 drivers/nvmem/qfprom.c                        | 26 +++++++++---
 drivers/nvmem/rockchip-otp.c                  | 17 +++++++-
 6 files changed, 97 insertions(+), 17 deletions(-)

-- 
2.25.1

[PATCH v2 01/13] nvmem: rockchip-otp: Move read-offset into variant-data

[srinivas.kandagatla]

From: Heiko Stuebner <heiko@sntech.de>

The RK3588 has an offset into the OTP area where the readable area begins
and automatically adds this to the start address.
Other variants are very much similar to rk3588, just with a different
offset, so move that value into variant-data.

To match the size in bytes, store this value also in bytes and not in
number of blocks.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/nvmem/rockchip-otp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/nvmem/rockchip-otp.c b/drivers/nvmem/rockchip-otp.c
index ebc3f0b24166..3edfbfc2d722 100644
--- a/drivers/nvmem/rockchip-otp.c
+++ b/drivers/nvmem/rockchip-otp.c
@@ -59,7 +59,6 @@
 #define RK3588_OTPC_AUTO_EN		0x08
 #define RK3588_OTPC_INT_ST		0x84
 #define RK3588_OTPC_DOUT0		0x20
-#define RK3588_NO_SECURE_OFFSET		0x300
 #define RK3588_NBYTES			4
 #define RK3588_BURST_NUM		1
 #define RK3588_BURST_SHIFT		8
@@ -69,6 +68,7 @@
 
 struct rockchip_data {
 	int size;
+	int read_offset;
 	const char * const *clks;
 	int num_clks;
 	nvmem_reg_read_t reg_read;
@@ -196,7 +196,7 @@ static int rk3588_otp_read(void *context, unsigned int offset,
 	addr_start = round_down(offset, RK3588_NBYTES) / RK3588_NBYTES;
 	addr_end = round_up(offset + bytes, RK3588_NBYTES) / RK3588_NBYTES;
 	addr_len = addr_end - addr_start;
-	addr_start += RK3588_NO_SECURE_OFFSET;
+	addr_start += otp->data->read_offset / RK3588_NBYTES;
 
 	buf = kzalloc(array_size(addr_len, RK3588_NBYTES), GFP_KERNEL);
 	if (!buf)
@@ -280,6 +280,7 @@ static const char * const rk3588_otp_clocks[] = {
 
 static const struct rockchip_data rk3588_data = {
 	.size = 0x400,
+	.read_offset = 0xc00,
 	.clks = rk3588_otp_clocks,
 	.num_clks = ARRAY_SIZE(rk3588_otp_clocks),
 	.reg_read = rk3588_otp_read,
-- 
2.25.1

[PATCH v2 02/13] dt-bindings: nvmem: rockchip,otp: add missing limits for clock-names

[srinivas.kandagatla]

From: Heiko Stuebner <heiko@sntech.de>

The clocks property correctly declares minItems and maxItems for its
variants, but clock-names does not. Both properties are always used
together, so should declare the same limits.

Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
index a44d44b32809..3201ff8f9334 100644
--- a/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
@@ -62,6 +62,8 @@ allOf:
       properties:
         clocks:
           maxItems: 3
+        clock-names:
+          maxItems: 3
         resets:
           maxItems: 1
         reset-names:
@@ -78,6 +80,8 @@ allOf:
       properties:
         clocks:
           minItems: 4
+        clock-names:
+          minItems: 4
         resets:
           minItems: 3
         reset-names:
-- 
2.25.1

[PATCH v2 03/13] dt-bindings: nvmem: rockchip,otp: Add compatible for RK3576

[srinivas.kandagatla]

From: Heiko Stuebner <heiko@sntech.de>

Document the OTP memory found on Rockchip RK3576 SoC.

The RK3576 uses the same set of clocks as the px30/rk3308
but has one reset more, so adapt the binding to handle this
variant as well.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 .../bindings/nvmem/rockchip,otp.yaml          | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
index 3201ff8f9334..dc89020b0950 100644
--- a/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/rockchip,otp.yaml
@@ -14,6 +14,7 @@ properties:
     enum:
       - rockchip,px30-otp
       - rockchip,rk3308-otp
+      - rockchip,rk3576-otp
       - rockchip,rk3588-otp
 
   reg:
@@ -70,6 +71,26 @@ allOf:
           items:
             - const: phy
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - rockchip,rk3576-otp
+    then:
+      properties:
+        clocks:
+          maxItems: 3
+        clock-names:
+          maxItems: 3
+        resets:
+          minItems: 2
+          maxItems: 2
+        reset-names:
+          items:
+            - const: otp
+            - const: apb
+
   - if:
       properties:
         compatible:
-- 
2.25.1

[PATCH v2 04/13] nvmem: rockchip-otp: add rk3576 variant data

[srinivas.kandagatla]

From: Heiko Stuebner <heiko@sntech.de>

The variant works very similar to the rk3588, just with a different
read-offset and size.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/nvmem/rockchip-otp.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/nvmem/rockchip-otp.c b/drivers/nvmem/rockchip-otp.c
index 3edfbfc2d722..d88f12c53242 100644
--- a/drivers/nvmem/rockchip-otp.c
+++ b/drivers/nvmem/rockchip-otp.c
@@ -274,6 +274,14 @@ static const struct rockchip_data px30_data = {
 	.reg_read = px30_otp_read,
 };
 
+static const struct rockchip_data rk3576_data = {
+	.size = 0x100,
+	.read_offset = 0x700,
+	.clks = px30_otp_clocks,
+	.num_clks = ARRAY_SIZE(px30_otp_clocks),
+	.reg_read = rk3588_otp_read,
+};
+
 static const char * const rk3588_otp_clocks[] = {
 	"otp", "apb_pclk", "phy", "arb",
 };
@@ -295,6 +303,10 @@ static const struct of_device_id rockchip_otp_match[] = {
 		.compatible = "rockchip,rk3308-otp",
 		.data = &px30_data,
 	},
+	{
+		.compatible = "rockchip,rk3576-otp",
+		.data = &rk3576_data,
+	},
 	{
 		.compatible = "rockchip,rk3588-otp",
 		.data = &rk3588_data,
-- 
2.25.1

[PATCH v2 05/13] dt-bindings: nvmem: qfprom: Add X1E80100 compatible

[srinivas.kandagatla]

From: Akhil P Oommen <quic_akhilpo@quicinc.com>

Document compatible string for the QFPROM on X1E80100 platform.

Signed-off-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index d37f544ab8aa..a85f817b015d 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -50,6 +50,7 @@ properties:
           - qcom,sm8450-qfprom
           - qcom,sm8550-qfprom
           - qcom,sm8650-qfprom
+          - qcom,x1e80100-qfprom
       - const: qcom,qfprom
 
   reg:
-- 
2.25.1

[PATCH v2 06/13] dt-bindings: nvmem: Add compatible for MS8937

[srinivas.kandagatla]

From: Barnabás Czémán <barnabas.czeman@mainlining.org>

Document the QFPROM block found on MSM8937.

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index a85f817b015d..a9de635bf31e 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -28,6 +28,7 @@ properties:
           - qcom,msm8226-qfprom
           - qcom,msm8916-qfprom
           - qcom,msm8917-qfprom
+          - qcom,msm8937-qfprom
           - qcom,msm8974-qfprom
           - qcom,msm8976-qfprom
           - qcom,msm8996-qfprom
-- 
2.25.1

[PATCH v2 07/13] dt-bindings: nvmem: fixed-cell: increase bits start value to 31

[srinivas.kandagatla]

From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

If NVMEM uses a data stride bigger than a byte, the starting bit of the
cell might be bigger than a byte (e.g. if the data comes in the second
byte of the 4-byte word). Allow the staring bit to be 8 or greater to
reflect such usecases.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
index 8b3826243ddd..38e3ad50ff4f 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/fixed-cell.yaml
@@ -27,7 +27,7 @@ properties:
     $ref: /schemas/types.yaml#/definitions/uint32-array
     items:
       - minimum: 0
-        maximum: 7
+        maximum: 31
         description:
           Offset in bit within the address range specified by reg.
       - minimum: 1
-- 
2.25.1

[PATCH v2 08/13] nvmem: core: fix bit offsets of more than one byte

[srinivas.kandagatla]

From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

If the NVMEM specifies a stride to access data, reading particular cell
might require bit offset that is bigger than one byte. Rework NVMEM core
code to support bit offsets of more than 8 bits.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/nvmem/core.c | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index fff85bbf0ecd..7872903c08a1 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -837,7 +837,9 @@ static int nvmem_add_cells_from_dt(struct nvmem_device *nvmem, struct device_nod
 		if (addr && len == (2 * sizeof(u32))) {
 			info.bit_offset = be32_to_cpup(addr++);
 			info.nbits = be32_to_cpup(addr);
-			if (info.bit_offset >= BITS_PER_BYTE || info.nbits < 1) {
+			if (info.bit_offset >= BITS_PER_BYTE * info.bytes ||
+			    info.nbits < 1 ||
+			    info.bit_offset + info.nbits > BITS_PER_BYTE * info.bytes) {
 				dev_err(dev, "nvmem: invalid bits on %pOF\n", child);
 				of_node_put(child);
 				return -EINVAL;
@@ -1630,21 +1632,29 @@ EXPORT_SYMBOL_GPL(nvmem_cell_put);
 static void nvmem_shift_read_buffer_in_place(struct nvmem_cell_entry *cell, void *buf)
 {
 	u8 *p, *b;
-	int i, extra, bit_offset = cell->bit_offset;
+	int i, extra, bytes_offset;
+	int bit_offset = cell->bit_offset;
 
 	p = b = buf;
-	if (bit_offset) {
+
+	bytes_offset = bit_offset / BITS_PER_BYTE;
+	b += bytes_offset;
+	bit_offset %= BITS_PER_BYTE;
+
+	if (bit_offset % BITS_PER_BYTE) {
 		/* First shift */
-		*b++ >>= bit_offset;
+		*p = *b++ >> bit_offset;
 
 		/* setup rest of the bytes if any */
 		for (i = 1; i < cell->bytes; i++) {
 			/* Get bits from next byte and shift them towards msb */
-			*p |= *b << (BITS_PER_BYTE - bit_offset);
+			*p++ |= *b << (BITS_PER_BYTE - bit_offset);
 
-			p = b;
-			*b++ >>= bit_offset;
+			*p = *b++ >> bit_offset;
 		}
+	} else if (p != b) {
+		memmove(p, b, cell->bytes - bytes_offset);
+		p += cell->bytes - 1;
 	} else {
 		/* point to the msb */
 		p += cell->bytes - 1;
-- 
2.25.1

[PATCH v2 09/13] nvmem: core: verify cell's raw_len

[srinivas.kandagatla]

From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Check that the NVMEM cell's raw_len is a aligned to word_size. Otherwise
Otherwise drivers might face incomplete read while accessing the last
part of the NVMEM cell.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/nvmem/core.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 7872903c08a1..7b8c85f9e035 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -605,6 +605,18 @@ static int nvmem_cell_info_to_nvmem_cell_entry_nodup(struct nvmem_device *nvmem,
 		return -EINVAL;
 	}
 
+	if (!IS_ALIGNED(cell->raw_len, nvmem->word_size)) {
+		dev_err(&nvmem->dev,
+			"cell %s raw len %zd unaligned to nvmem word size %d\n",
+			cell->name ?: "<unknown>", cell->raw_len,
+			nvmem->word_size);
+
+		if (info->raw_len)
+			return -EINVAL;
+
+		cell->raw_len = ALIGN(cell->raw_len, nvmem->word_size);
+	}
+
 	return 0;
 }
 
-- 
2.25.1

[PATCH v2 10/13] nvmem: core: update raw_len if the bit reading is required

[srinivas.kandagatla]

From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

If NVMEM cell uses bit offset or specifies bit truncation, update
raw_len manually (following the cell->bytes update), ensuring that the
NVMEM access is still word-aligned.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/nvmem/core.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 7b8c85f9e035..e206efc29a00 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -594,9 +594,11 @@ static int nvmem_cell_info_to_nvmem_cell_entry_nodup(struct nvmem_device *nvmem,
 	cell->nbits = info->nbits;
 	cell->np = info->np;
 
-	if (cell->nbits)
+	if (cell->nbits) {
 		cell->bytes = DIV_ROUND_UP(cell->nbits + cell->bit_offset,
 					   BITS_PER_BYTE);
+		cell->raw_len = ALIGN(cell->bytes, nvmem->word_size);
+	}
 
 	if (!IS_ALIGNED(cell->offset, nvmem->stride)) {
 		dev_err(&nvmem->dev,
-- 
2.25.1

[PATCH v2 11/13] nvmem: qfprom: switch to 4-byte aligned reads

[srinivas.kandagatla]

From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

All platforms since Snapdragon 8 Gen1 (SM8450) require using 4-byte
reads to access QFPROM data. While older platforms were more than happy
with 1-byte reads, change the qfprom driver to use 4-byte reads for all
the platforms. Specify stride and word size of 4 bytes. To retain
compatibility with the existing DT and to simplify porting data from
vendor kernels, use fixup_dt_cell_info in order to bump alignment
requirements.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 drivers/nvmem/qfprom.c | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index 116a39e804c7..a872c640b8c5 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -321,19 +321,32 @@ static int qfprom_reg_read(void *context,
 			unsigned int reg, void *_val, size_t bytes)
 {
 	struct qfprom_priv *priv = context;
-	u8 *val = _val;
-	int i = 0, words = bytes;
+	u32 *val = _val;
 	void __iomem *base = priv->qfpcorrected;
+	int words = DIV_ROUND_UP(bytes, sizeof(u32));
+	int i;
 
 	if (read_raw_data && priv->qfpraw)
 		base = priv->qfpraw;
 
-	while (words--)
-		*val++ = readb(base + reg + i++);
+	for (i = 0; i < words; i++)
+		*val++ = readl(base + reg + i * sizeof(u32));
 
 	return 0;
 }
 
+/* Align reads to word boundary */
+static void qfprom_fixup_dt_cell_info(struct nvmem_device *nvmem,
+				      struct nvmem_cell_info *cell)
+{
+	unsigned int byte_offset = cell->offset % sizeof(u32);
+
+	cell->bit_offset += byte_offset * BITS_PER_BYTE;
+	cell->offset -= byte_offset;
+	if (byte_offset && !cell->nbits)
+		cell->nbits = cell->bytes * BITS_PER_BYTE;
+}
+
 static void qfprom_runtime_disable(void *data)
 {
 	pm_runtime_disable(data);
@@ -358,10 +371,11 @@ static int qfprom_probe(struct platform_device *pdev)
 	struct nvmem_config econfig = {
 		.name = "qfprom",
 		.add_legacy_fixed_of_cells = true,
-		.stride = 1,
-		.word_size = 1,
+		.stride = 4,
+		.word_size = 4,
 		.id = NVMEM_DEVID_AUTO,
 		.reg_read = qfprom_reg_read,
+		.fixup_dt_cell_info = qfprom_fixup_dt_cell_info,
 	};
 	struct device *dev = &pdev->dev;
 	struct resource *res;
-- 
2.25.1

[PATCH v2 12/13] dt-bindings: nvmem: Add compatible for IPQ5018

[srinivas.kandagatla]

From: Sricharan Ramabadhran <quic_srichara@quicinc.com>

Document the QFPROM block found on IPQ5018

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
Signed-off-by: George Moussalem <george.moussalem@outlook.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index a9de635bf31e..69e3669f8178 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -19,6 +19,7 @@ properties:
       - enum:
           - qcom,apq8064-qfprom
           - qcom,apq8084-qfprom
+          - qcom,ipq5018-qfprom
           - qcom,ipq5332-qfprom
           - qcom,ipq5424-qfprom
           - qcom,ipq6018-qfprom
-- 
2.25.1

[PATCH v2 13/13] dt-bindings: nvmem: Add compatible for MSM8960

[srinivas.kandagatla]

From: Rudraksha Gupta <guptarud@gmail.com>

Document the QFPROM on MSM8960.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
index 69e3669f8178..fb4dfb1bfb4f 100644
--- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
+++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml
@@ -30,6 +30,7 @@ properties:
           - qcom,msm8916-qfprom
           - qcom,msm8917-qfprom
           - qcom,msm8937-qfprom
+          - qcom,msm8960-qfprom
           - qcom,msm8974-qfprom
           - qcom,msm8976-qfprom
           - qcom,msm8996-qfprom
-- 
2.25.1

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Srinivas Kandagatla]

Hi Greg,

Just want to ping you incase these patches fell through the cracks.

Normally you pick nvmem series much earlier.

Pl, let me know if there is anything that I can do to help.

Thanks,
--srini

On 09/03/2025 14:56, srinivas.kandagatla@linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> 
> Hi Greg,
> 
> Here are few nvmem patches for 6.15, Could you queue
> these for 6.15.
> 
> patche include
> 	- updates to bindings to include MSM8960, X1E80100, MS8937,
> 	  IPQ5018
> 	- add support to bit offsets for register strides exceeding
> 	  single byte
> 	- add rockchip-otp variants.
> 	- Few enhancements in qfprom and rochchip nvmem providers.
> 
> Thanks,
> Srini
> 
> Changes since v1:
>   - Merged fixup "nvmem: make the misaligned raw_len non-fatal" into
>    "nvmem: core: verify cell's raw_len"
> 
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> 
> Akhil P Oommen (1):
>    dt-bindings: nvmem: qfprom: Add X1E80100 compatible
> 
> Barnabás Czémán (1):
>    dt-bindings: nvmem: Add compatible for MS8937
> 
> Dmitry Baryshkov (5):
>    dt-bindings: nvmem: fixed-cell: increase bits start value to 31
>    nvmem: core: fix bit offsets of more than one byte
>    nvmem: core: verify cell's raw_len
>    nvmem: core: update raw_len if the bit reading is required
>    nvmem: qfprom: switch to 4-byte aligned reads
> 
> Heiko Stuebner (4):
>    nvmem: rockchip-otp: Move read-offset into variant-data
>    dt-bindings: nvmem: rockchip,otp: add missing limits for clock-names
>    dt-bindings: nvmem: rockchip,otp: Add compatible for RK3576
>    nvmem: rockchip-otp: add rk3576 variant data
> 
> Rudraksha Gupta (1):
>    dt-bindings: nvmem: Add compatible for MSM8960
> 
> Sricharan Ramabadhran (1):
>    dt-bindings: nvmem: Add compatible for IPQ5018
> 
>   .../bindings/nvmem/layouts/fixed-cell.yaml    |  2 +-
>   .../bindings/nvmem/qcom,qfprom.yaml           |  4 ++
>   .../bindings/nvmem/rockchip,otp.yaml          | 25 ++++++++++++
>   drivers/nvmem/core.c                          | 40 +++++++++++++++----
>   drivers/nvmem/qfprom.c                        | 26 +++++++++---
>   drivers/nvmem/rockchip-otp.c                  | 17 +++++++-
>   6 files changed, 97 insertions(+), 17 deletions(-)
> 

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Greg KH]

On Tue, Mar 25, 2025 at 11:31:38AM +0000, Srinivas Kandagatla wrote:
> Hi Greg,
> 
> Just want to ping you incase these patches fell through the cracks.
> 
> Normally you pick nvmem series much earlier.
> 
> Pl, let me know if there is anything that I can do to help.

Crap, I missed these, so sorry about that.  Are these also in linux-next
from your development tree?  If so, I can suck them in next week and get
them to Linus for -rc1.

Again, my fault, sorry, I blame conference travel :(

greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Srinivas Kandagatla]

Hi Greg,

On 30/03/2025 19:30, Greg KH wrote:
> On Tue, Mar 25, 2025 at 11:31:38AM +0000, Srinivas Kandagatla wrote:
>> Hi Greg,
>>
>> Just want to ping you incase these patches fell through the cracks.
>>
>> Normally you pick nvmem series much earlier.
>>
>> Pl, let me know if there is anything that I can do to help.
> 
> Crap, I missed these, so sorry about that.  Are these also in linux-next
> from your development tree?  If so, I can suck them in next week and get
> them to Linus for -rc1.
Yes, these are in linux-next.

pulling it for next rc1 would really help,

> 
> Again, my fault, sorry, I blame conference travel :(

No worries, hope you had good conference.

--srini
> 
> greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Greg KH]

On Sun, Mar 30, 2025 at 10:03:39PM +0100, Srinivas Kandagatla wrote:
> Hi Greg,
> 
> On 30/03/2025 19:30, Greg KH wrote:
> > On Tue, Mar 25, 2025 at 11:31:38AM +0000, Srinivas Kandagatla wrote:
> > > Hi Greg,
> > > 
> > > Just want to ping you incase these patches fell through the cracks.
> > > 
> > > Normally you pick nvmem series much earlier.
> > > 
> > > Pl, let me know if there is anything that I can do to help.
> > 
> > Crap, I missed these, so sorry about that.  Are these also in linux-next
> > from your development tree?  If so, I can suck them in next week and get
> > them to Linus for -rc1.
> Yes, these are in linux-next.
> 
> pulling it for next rc1 would really help,

Ok, cool, after Linus takes this pull request I'll sync up with this and
send it to him as well.

thanks!

greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Greg KH]

On Sun, Mar 09, 2025 at 02:56:50PM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> 
> Hi Greg,
> 
> Here are few nvmem patches for 6.15, Could you queue
> these for 6.15.
> 
> patche include
> 	- updates to bindings to include MSM8960, X1E80100, MS8937,
> 	  IPQ5018
> 	- add support to bit offsets for register strides exceeding
> 	  single byte
> 	- add rockchip-otp variants.
> 	- Few enhancements in qfprom and rochchip nvmem providers.

Ok, I wanted to apply these, and tried to, but they fail horribly
because:

Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
	Has these problem(s):
		- Target SHA1 does not exist
Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit reading is required")
	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
	Has these problem(s):
		- Target SHA1 does not exist
Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than one byte")
	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
	Has these problem(s):
		- Target SHA1 does not exist

Why do we have 3 patches all fixing the original one here?  Why isn't
the original patch just "correct"?

And you can't send patches with git ids in them, that just doesn't work.

So please, go rework these to not introduce a bug and then fix it up,
that's just not ok when dealing with a patch series.

thanks,

greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Srinivas Kandagatla]

HI Greg,

On 01/04/2025 20:18, Greg KH wrote:
> On Sun, Mar 09, 2025 at 02:56:50PM +0000, srinivas.kandagatla@linaro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>
>> Hi Greg,
>>
>> Here are few nvmem patches for 6.15, Could you queue
>> these for 6.15.
>>
>> patche include
>> 	- updates to bindings to include MSM8960, X1E80100, MS8937,
>> 	  IPQ5018
>> 	- add support to bit offsets for register strides exceeding
>> 	  single byte
>> 	- add rockchip-otp variants.
>> 	- Few enhancements in qfprom and rochchip nvmem providers.
> 
> Ok, I wanted to apply these, and tried to, but they fail horribly
> because:
> 
> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> 	Has these problem(s):
> 		- Target SHA1 does not exist
> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit reading is required")
> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> 	Has these problem(s):
> 		- Target SHA1 does not exist
> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than one byte")
> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> 	Has these problem(s):
> 		- Target SHA1 does not exist

Looks some of your scripts or b4 is picking up older version v1 of the 
patchset

None of the above patches have Fixes tags in the V2 patches that I 
shared aswell as patches in linux-next.

Thanks,
Srini
> 
> Why do we have 3 patches all fixing the original one here?  Why isn't
> the original patch just "correct"?
> 
> And you can't send patches with git ids in them, that just doesn't work.
> 
> So please, go rework these to not introduce a bug and then fix it up,
> that's just not ok when dealing with a patch series.
> 
> thanks,
> 
> greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Greg KH]

On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
> HI Greg,
> 
> On 01/04/2025 20:18, Greg KH wrote:
> > On Sun, Mar 09, 2025 at 02:56:50PM +0000, srinivas.kandagatla@linaro.org wrote:
> > > From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > > 
> > > Hi Greg,
> > > 
> > > Here are few nvmem patches for 6.15, Could you queue
> > > these for 6.15.
> > > 
> > > patche include
> > > 	- updates to bindings to include MSM8960, X1E80100, MS8937,
> > > 	  IPQ5018
> > > 	- add support to bit offsets for register strides exceeding
> > > 	  single byte
> > > 	- add rockchip-otp variants.
> > > 	- Few enhancements in qfprom and rochchip nvmem providers.
> > 
> > Ok, I wanted to apply these, and tried to, but they fail horribly
> > because:
> > 
> > Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
> > 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> > 	Has these problem(s):
> > 		- Target SHA1 does not exist
> > Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit reading is required")
> > 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> > 	Has these problem(s):
> > 		- Target SHA1 does not exist
> > Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than one byte")
> > 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
> > 	Has these problem(s):
> > 		- Target SHA1 does not exist
> 
> Looks some of your scripts or b4 is picking up older version v1 of the
> patchset
> 
> None of the above patches have Fixes tags in the V2 patches that I shared
> aswell as patches in linux-next.

Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.

But, that's even worse.  Those "fixes" are now not actually marked as
fixes of the previous patch.  So that information is totally lost, and
again, the first commit here, "nvmem: core: verify cell's raw_len" is
broken so much that it took 3 other changes to fix it, which implies
that bisection would cause problems if you hit it in the middle here.

While fixing patches is great, and something we do in the tree all the
time, let's not purposefully break things and then fix them up in the
same exact patch series please.  That's just sloppy engineering.

Please redo this series completely.  I can take the "new device support"
patches at any time, and really, those should be marked with Cc: stable
to get backported, right?  The other ones are written as if they are
fixes, so again, I can take them any time, no need to wait for the -rc1
merge cycle.

thanks,

greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Srinivas Kandagatla]

On 02/04/2025 12:31, Greg KH wrote:
> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
>> HI Greg,
>>
>> On 01/04/2025 20:18, Greg KH wrote:
>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000, srinivas.kandagatla@linaro.org wrote:
>>>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>>
>>>> Hi Greg,
>>>>
>>>> Here are few nvmem patches for 6.15, Could you queue
>>>> these for 6.15.
>>>>
>>>> patche include
>>>> 	- updates to bindings to include MSM8960, X1E80100, MS8937,
>>>> 	  IPQ5018
>>>> 	- add support to bit offsets for register strides exceeding
>>>> 	  single byte
>>>> 	- add rockchip-otp variants.
>>>> 	- Few enhancements in qfprom and rochchip nvmem providers.
>>>
>>> Ok, I wanted to apply these, and tried to, but they fail horribly
>>> because:
>>>
>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
>>> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
>>> 	Has these problem(s):
>>> 		- Target SHA1 does not exist
>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit reading is required")
>>> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
>>> 	Has these problem(s):
>>> 		- Target SHA1 does not exist
>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than one byte")
>>> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
>>> 	Has these problem(s):
>>> 		- Target SHA1 does not exist
>>
>> Looks some of your scripts or b4 is picking up older version v1 of the
>> patchset
>>
>> None of the above patches have Fixes tags in the V2 patches that I shared
>> aswell as patches in linux-next.
> 
> Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.
> 

Even that looked incorrect, as the v1 series only had one patch("[PATCH 
12/14] nvmem: make the misaligned raw_len non-fatal") that had fixes 
tag. Not sure how these 3 patches are tagged as fixes.

> But, that's even worse.  Those "fixes" are now not actually marked as
> fixes of the previous patch.  So that information is totally lost, and

Its because this patch("PATCH 12/14] nvmem: make the misaligned raw_len 
non-fatal") is taken as fixup patch and wrapped into the original patch 
("nvmem: core: verify cell's raw_len"), Also the sha will not be valid 
for linus or char-misc tree.

> again, the first commit here, "nvmem: core: verify cell's raw_len" is
> broken so much that it took 3 other changes to fix it, which implies
> that bisection would cause problems if you hit it in the middle here.
> 

All the patches related to this are enhancements to nvmem core to allow 
specifying bit offsets for nvmem cell that have 4 bytes strides.

Specially this check is also an additional check in core to make sure 
that cell offsets are aligned to register strides.

> While fixing patches is great, and something we do in the tree all the
> time, let's not purposefully break things and then fix them up in the
> same exact patch series please.  That's just sloppy engineering.
> 
> Please redo this series completely.  I can take the "new device support"

I can send them but its going to be exactly same series, I dont think 
anything will change as all of these patches are enhancements and there 
are no fixes.

I hope this clarifies a bit, Please let me know if you still want me to 
resend this series, which is going to be exactly same.

--srini
> patches at any time, and really, those should be marked with Cc: stable
> to get backported, right?  The other ones are written as if they are
> fixes, so again, I can take them any time, no need to wait for the -rc1
> merge cycle.
> 
> thanks,
> 
> greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Dmitry Baryshkov]

On 03/04/2025 12:18, Srinivas Kandagatla wrote:
> 
> 
> On 02/04/2025 12:31, Greg KH wrote:
>> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
>>> HI Greg,
>>>
>>> On 01/04/2025 20:18, Greg KH wrote:
>>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000, 
>>>> srinivas.kandagatla@linaro.org wrote:
>>>>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>>>
>>>>> Hi Greg,
>>>>>
>>>>> Here are few nvmem patches for 6.15, Could you queue
>>>>> these for 6.15.
>>>>>
>>>>> patche include
>>>>>     - updates to bindings to include MSM8960, X1E80100, MS8937,
>>>>>       IPQ5018
>>>>>     - add support to bit offsets for register strides exceeding
>>>>>       single byte
>>>>>     - add rockchip-otp variants.
>>>>>     - Few enhancements in qfprom and rochchip nvmem providers.
>>>>
>>>> Ok, I wanted to apply these, and tried to, but they fail horribly
>>>> because:
>>>>
>>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's 
>>>> raw_len")
>>>>     Has these problem(s):
>>>>         - Target SHA1 does not exist
>>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit 
>>>> reading is required")
>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's 
>>>> raw_len")
>>>>     Has these problem(s):
>>>>         - Target SHA1 does not exist
>>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than one 
>>>> byte")
>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's 
>>>> raw_len")
>>>>     Has these problem(s):
>>>>         - Target SHA1 does not exist
>>>
>>> Looks some of your scripts or b4 is picking up older version v1 of the
>>> patchset
>>>
>>> None of the above patches have Fixes tags in the V2 patches that I 
>>> shared
>>> aswell as patches in linux-next.
>>
>> Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.
>>
> 
> Even that looked incorrect, as the v1 series only had one patch("[PATCH 
> 12/14] nvmem: make the misaligned raw_len non-fatal") that had fixes 
> tag. Not sure how these 3 patches are tagged as fixes.
> 
>> But, that's even worse.  Those "fixes" are now not actually marked as
>> fixes of the previous patch.  So that information is totally lost, and
> 
> Its because this patch("PATCH 12/14] nvmem: make the misaligned raw_len 
> non-fatal") is taken as fixup patch and wrapped into the original patch 
> ("nvmem: core: verify cell's raw_len"), Also the sha will not be valid 
> for linus or char-misc tree.
> 
>> again, the first commit here, "nvmem: core: verify cell's raw_len" is
>> broken so much that it took 3 other changes to fix it, which implies
>> that bisection would cause problems if you hit it in the middle here.
>>
> 
> All the patches related to this are enhancements to nvmem core to allow 
> specifying bit offsets for nvmem cell that have 4 bytes strides.
> 
> Specially this check is also an additional check in core to make sure 
> that cell offsets are aligned to register strides.
> 
>> While fixing patches is great, and something we do in the tree all the
>> time, let's not purposefully break things and then fix them up in the
>> same exact patch series please.  That's just sloppy engineering.
>>
>> Please redo this series completely.  I can take the "new device support"
> 
> I can send them but its going to be exactly same series, I dont think 
> anything will change as all of these patches are enhancements and there 
> are no fixes.
> 
> I hope this clarifies a bit, Please let me know if you still want me to 
> resend this series, which is going to be exactly same.

I think Greg is asking to squash the fixup into the relevant patch.

> 
> --srini
>> patches at any time, and really, those should be marked with Cc: stable
>> to get backported, right?  The other ones are written as if they are
>> fixes, so again, I can take them any time, no need to wait for the -rc1
>> merge cycle.
>>
>> thanks,
>>
>> greg k-h


-- 
With best wishes
Dmitry

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Srinivas Kandagatla]

On 03/04/2025 10:25, Dmitry Baryshkov wrote:
> On 03/04/2025 12:18, Srinivas Kandagatla wrote:
>>
>>
>> On 02/04/2025 12:31, Greg KH wrote:
>>> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
>>>> HI Greg,
>>>>
>>>> On 01/04/2025 20:18, Greg KH wrote:
>>>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000, 
>>>>> srinivas.kandagatla@linaro.org wrote:
>>>>>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> Here are few nvmem patches for 6.15, Could you queue
>>>>>> these for 6.15.
>>>>>>
>>>>>> patche include
>>>>>>     - updates to bindings to include MSM8960, X1E80100, MS8937,
>>>>>>       IPQ5018
>>>>>>     - add support to bit offsets for register strides exceeding
>>>>>>       single byte
>>>>>>     - add rockchip-otp variants.
>>>>>>     - Few enhancements in qfprom and rochchip nvmem providers.
>>>>>
>>>>> Ok, I wanted to apply these, and tried to, but they fail horribly
>>>>> because:
>>>>>
>>>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
>>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's 
>>>>> raw_len")
>>>>>     Has these problem(s):
>>>>>         - Target SHA1 does not exist
>>>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit 
>>>>> reading is required")
>>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's 
>>>>> raw_len")
>>>>>     Has these problem(s):
>>>>>         - Target SHA1 does not exist
>>>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than 
>>>>> one byte")
>>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's 
>>>>> raw_len")
>>>>>     Has these problem(s):
>>>>>         - Target SHA1 does not exist
>>>>
>>>> Looks some of your scripts or b4 is picking up older version v1 of the
>>>> patchset
>>>>
>>>> None of the above patches have Fixes tags in the V2 patches that I 
>>>> shared
>>>> aswell as patches in linux-next.
>>>
>>> Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.
>>>
>>
>> Even that looked incorrect, as the v1 series only had one 
>> patch("[PATCH 12/14] nvmem: make the misaligned raw_len non-fatal") 
>> that had fixes tag. Not sure how these 3 patches are tagged as fixes.
>>
>>> But, that's even worse.  Those "fixes" are now not actually marked as
>>> fixes of the previous patch.  So that information is totally lost, and
>>
>> Its because this patch("PATCH 12/14] nvmem: make the misaligned 
>> raw_len non-fatal") is taken as fixup patch and wrapped into the 
>> original patch ("nvmem: core: verify cell's raw_len"), Also the sha 
>> will not be valid for linus or char-misc tree.
>>
>>> again, the first commit here, "nvmem: core: verify cell's raw_len" is
>>> broken so much that it took 3 other changes to fix it, which implies
>>> that bisection would cause problems if you hit it in the middle here.
>>>
>>
>> All the patches related to this are enhancements to nvmem core to 
>> allow specifying bit offsets for nvmem cell that have 4 bytes strides.
>>
>> Specially this check is also an additional check in core to make sure 
>> that cell offsets are aligned to register strides.
>>
>>> While fixing patches is great, and something we do in the tree all the
>>> time, let's not purposefully break things and then fix them up in the
>>> same exact patch series please.  That's just sloppy engineering.
>>>
>>> Please redo this series completely.  I can take the "new device support"
>>
>> I can send them but its going to be exactly same series, I dont think 
>> anything will change as all of these patches are enhancements and 
>> there are no fixes.
>>
>> I hope this clarifies a bit, Please let me know if you still want me 
>> to resend this series, which is going to be exactly same.
> 
> I think Greg is asking to squash the fixup into the relevant patch.

Its already squashed up in v2.

thanks,
Srini
> 
>>
>> --srini
>>> patches at any time, and really, those should be marked with Cc: stable
>>> to get backported, right?  The other ones are written as if they are
>>> fixes, so again, I can take them any time, no need to wait for the -rc1
>>> merge cycle.
>>>
>>> thanks,
>>>
>>> greg k-h
> 
> 

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Dmitry Baryshkov]

On Thu, 3 Apr 2025 at 12:27, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
>
>
> On 03/04/2025 10:25, Dmitry Baryshkov wrote:
> > On 03/04/2025 12:18, Srinivas Kandagatla wrote:
> >>
> >>
> >> On 02/04/2025 12:31, Greg KH wrote:
> >>> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
> >>>> HI Greg,
> >>>>
> >>>> On 01/04/2025 20:18, Greg KH wrote:
> >>>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000,
> >>>>> srinivas.kandagatla@linaro.org wrote:
> >>>>>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> >>>>>>
> >>>>>> Hi Greg,
> >>>>>>
> >>>>>> Here are few nvmem patches for 6.15, Could you queue
> >>>>>> these for 6.15.
> >>>>>>
> >>>>>> patche include
> >>>>>>     - updates to bindings to include MSM8960, X1E80100, MS8937,
> >>>>>>       IPQ5018
> >>>>>>     - add support to bit offsets for register strides exceeding
> >>>>>>       single byte
> >>>>>>     - add rockchip-otp variants.
> >>>>>>     - Few enhancements in qfprom and rochchip nvmem providers.
> >>>>>
> >>>>> Ok, I wanted to apply these, and tried to, but they fail horribly
> >>>>> because:
> >>>>>
> >>>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
> >>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
> >>>>> raw_len")
> >>>>>     Has these problem(s):
> >>>>>         - Target SHA1 does not exist
> >>>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit
> >>>>> reading is required")
> >>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
> >>>>> raw_len")
> >>>>>     Has these problem(s):
> >>>>>         - Target SHA1 does not exist
> >>>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than
> >>>>> one byte")
> >>>>>     Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
> >>>>> raw_len")
> >>>>>     Has these problem(s):
> >>>>>         - Target SHA1 does not exist
> >>>>
> >>>> Looks some of your scripts or b4 is picking up older version v1 of the
> >>>> patchset
> >>>>
> >>>> None of the above patches have Fixes tags in the V2 patches that I
> >>>> shared
> >>>> aswell as patches in linux-next.
> >>>
> >>> Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.
> >>>
> >>
> >> Even that looked incorrect, as the v1 series only had one
> >> patch("[PATCH 12/14] nvmem: make the misaligned raw_len non-fatal")
> >> that had fixes tag. Not sure how these 3 patches are tagged as fixes.
> >>
> >>> But, that's even worse.  Those "fixes" are now not actually marked as
> >>> fixes of the previous patch.  So that information is totally lost, and
> >>
> >> Its because this patch("PATCH 12/14] nvmem: make the misaligned
> >> raw_len non-fatal") is taken as fixup patch and wrapped into the
> >> original patch ("nvmem: core: verify cell's raw_len"), Also the sha
> >> will not be valid for linus or char-misc tree.
> >>
> >>> again, the first commit here, "nvmem: core: verify cell's raw_len" is
> >>> broken so much that it took 3 other changes to fix it, which implies
> >>> that bisection would cause problems if you hit it in the middle here.
> >>>
> >>
> >> All the patches related to this are enhancements to nvmem core to
> >> allow specifying bit offsets for nvmem cell that have 4 bytes strides.
> >>
> >> Specially this check is also an additional check in core to make sure
> >> that cell offsets are aligned to register strides.
> >>
> >>> While fixing patches is great, and something we do in the tree all the
> >>> time, let's not purposefully break things and then fix them up in the
> >>> same exact patch series please.  That's just sloppy engineering.
> >>>
> >>> Please redo this series completely.  I can take the "new device support"
> >>
> >> I can send them but its going to be exactly same series, I dont think
> >> anything will change as all of these patches are enhancements and
> >> there are no fixes.
> >>
> >> I hope this clarifies a bit, Please let me know if you still want me
> >> to resend this series, which is going to be exactly same.
> >
> > I think Greg is asking to squash the fixup into the relevant patch.
>
> Its already squashed up in v2.

Then there should be no Fixes tags. Is the series that you are sending
visible somewhere?

>
> thanks,
> Srini
> >
> >>
> >> --srini
> >>> patches at any time, and really, those should be marked with Cc: stable
> >>> to get backported, right?  The other ones are written as if they are
> >>> fixes, so again, I can take them any time, no need to wait for the -rc1
> >>> merge cycle.
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >
> >



-- 
With best wishes
Dmitry

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Srinivas Kandagatla]

On 03/04/2025 10:31, Dmitry Baryshkov wrote:
> On Thu, 3 Apr 2025 at 12:27, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>>
>>
>>
>> On 03/04/2025 10:25, Dmitry Baryshkov wrote:
>>> On 03/04/2025 12:18, Srinivas Kandagatla wrote:
>>>>
>>>>
>>>> On 02/04/2025 12:31, Greg KH wrote:
>>>>> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
>>>>>> HI Greg,
>>>>>>
>>>>>> On 01/04/2025 20:18, Greg KH wrote:
>>>>>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000,
>>>>>>> srinivas.kandagatla@linaro.org wrote:
>>>>>>>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>>>>>>
>>>>>>>> Hi Greg,
>>>>>>>>
>>>>>>>> Here are few nvmem patches for 6.15, Could you queue
>>>>>>>> these for 6.15.
>>>>>>>>
>>>>>>>> patche include
>>>>>>>>      - updates to bindings to include MSM8960, X1E80100, MS8937,
>>>>>>>>        IPQ5018
>>>>>>>>      - add support to bit offsets for register strides exceeding
>>>>>>>>        single byte
>>>>>>>>      - add rockchip-otp variants.
>>>>>>>>      - Few enhancements in qfprom and rochchip nvmem providers.
>>>>>>>
>>>>>>> Ok, I wanted to apply these, and tried to, but they fail horribly
>>>>>>> because:
>>>>>>>
>>>>>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
>>>>>>>      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>> raw_len")
>>>>>>>      Has these problem(s):
>>>>>>>          - Target SHA1 does not exist
>>>>>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit
>>>>>>> reading is required")
>>>>>>>      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>> raw_len")
>>>>>>>      Has these problem(s):
>>>>>>>          - Target SHA1 does not exist
>>>>>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than
>>>>>>> one byte")
>>>>>>>      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>> raw_len")
>>>>>>>      Has these problem(s):
>>>>>>>          - Target SHA1 does not exist
>>>>>>
>>>>>> Looks some of your scripts or b4 is picking up older version v1 of the
>>>>>> patchset
>>>>>>
>>>>>> None of the above patches have Fixes tags in the V2 patches that I
>>>>>> shared
>>>>>> aswell as patches in linux-next.
>>>>>
>>>>> Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.
>>>>>
>>>>
>>>> Even that looked incorrect, as the v1 series only had one
>>>> patch("[PATCH 12/14] nvmem: make the misaligned raw_len non-fatal")
>>>> that had fixes tag. Not sure how these 3 patches are tagged as fixes.
>>>>
>>>>> But, that's even worse.  Those "fixes" are now not actually marked as
>>>>> fixes of the previous patch.  So that information is totally lost, and
>>>>
>>>> Its because this patch("PATCH 12/14] nvmem: make the misaligned
>>>> raw_len non-fatal") is taken as fixup patch and wrapped into the
>>>> original patch ("nvmem: core: verify cell's raw_len"), Also the sha
>>>> will not be valid for linus or char-misc tree.
>>>>
>>>>> again, the first commit here, "nvmem: core: verify cell's raw_len" is
>>>>> broken so much that it took 3 other changes to fix it, which implies
>>>>> that bisection would cause problems if you hit it in the middle here.
>>>>>
>>>>
>>>> All the patches related to this are enhancements to nvmem core to
>>>> allow specifying bit offsets for nvmem cell that have 4 bytes strides.
>>>>
>>>> Specially this check is also an additional check in core to make sure
>>>> that cell offsets are aligned to register strides.
>>>>
>>>>> While fixing patches is great, and something we do in the tree all the
>>>>> time, let's not purposefully break things and then fix them up in the
>>>>> same exact patch series please.  That's just sloppy engineering.
>>>>>
>>>>> Please redo this series completely.  I can take the "new device support"
>>>>
>>>> I can send them but its going to be exactly same series, I dont think
>>>> anything will change as all of these patches are enhancements and
>>>> there are no fixes.
>>>>
>>>> I hope this clarifies a bit, Please let me know if you still want me
>>>> to resend this series, which is going to be exactly same.
>>>
>>> I think Greg is asking to squash the fixup into the relevant patch.
>>
>> Its already squashed up in v2.
> 
> Then there should be no Fixes tags. Is the series that you are sending
> visible somewhere?

Yes, there is no fixes tags in v2 series,

Here is what is sent to as v2:
https://lore.kernel.org/lkml/47a3a851-f737-4772-87c6-98613347435c@linaro.org/T/#r01449e17cf6f9396967a822a0460ad4b1245e914


thanks,
Srini
> 
>>
>> thanks,
>> Srini
>>>
>>>>
>>>> --srini
>>>>> patches at any time, and really, those should be marked with Cc: stable
>>>>> to get backported, right?  The other ones are written as if they are
>>>>> fixes, so again, I can take them any time, no need to wait for the -rc1
>>>>> merge cycle.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>
>>>
> 
> 
> 

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Dmitry Baryshkov]

On 03/04/2025 12:35, Srinivas Kandagatla wrote:
> 
> 
> On 03/04/2025 10:31, Dmitry Baryshkov wrote:
>> On Thu, 3 Apr 2025 at 12:27, Srinivas Kandagatla
>> <srinivas.kandagatla@linaro.org> wrote:
>>>
>>>
>>>
>>> On 03/04/2025 10:25, Dmitry Baryshkov wrote:
>>>> On 03/04/2025 12:18, Srinivas Kandagatla wrote:
>>>>>
>>>>>
>>>>> On 02/04/2025 12:31, Greg KH wrote:
>>>>>> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
>>>>>>> HI Greg,
>>>>>>>
>>>>>>> On 01/04/2025 20:18, Greg KH wrote:
>>>>>>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000,
>>>>>>>> srinivas.kandagatla@linaro.org wrote:
>>>>>>>>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>>>>>>>
>>>>>>>>> Hi Greg,
>>>>>>>>>
>>>>>>>>> Here are few nvmem patches for 6.15, Could you queue
>>>>>>>>> these for 6.15.
>>>>>>>>>
>>>>>>>>> patche include
>>>>>>>>>      - updates to bindings to include MSM8960, X1E80100, MS8937,
>>>>>>>>>        IPQ5018
>>>>>>>>>      - add support to bit offsets for register strides exceeding
>>>>>>>>>        single byte
>>>>>>>>>      - add rockchip-otp variants.
>>>>>>>>>      - Few enhancements in qfprom and rochchip nvmem providers.
>>>>>>>>
>>>>>>>> Ok, I wanted to apply these, and tried to, but they fail horribly
>>>>>>>> because:
>>>>>>>>
>>>>>>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned 
>>>>>>>> reads")
>>>>>>>>      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>>> raw_len")
>>>>>>>>      Has these problem(s):
>>>>>>>>          - Target SHA1 does not exist
>>>>>>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit
>>>>>>>> reading is required")
>>>>>>>>      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>>> raw_len")
>>>>>>>>      Has these problem(s):
>>>>>>>>          - Target SHA1 does not exist
>>>>>>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than
>>>>>>>> one byte")
>>>>>>>>      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>>> raw_len")
>>>>>>>>      Has these problem(s):
>>>>>>>>          - Target SHA1 does not exist
>>>>>>>
>>>>>>> Looks some of your scripts or b4 is picking up older version v1 
>>>>>>> of the
>>>>>>> patchset
>>>>>>>
>>>>>>> None of the above patches have Fixes tags in the V2 patches that I
>>>>>>> shared
>>>>>>> aswell as patches in linux-next.
>>>>>>
>>>>>> Yes, that looks odd, it looks like b4 pulled in the wrong series, 
>>>>>> yes.
>>>>>>
>>>>>
>>>>> Even that looked incorrect, as the v1 series only had one
>>>>> patch("[PATCH 12/14] nvmem: make the misaligned raw_len non-fatal")
>>>>> that had fixes tag. Not sure how these 3 patches are tagged as fixes.
>>>>>
>>>>>> But, that's even worse.  Those "fixes" are now not actually marked as
>>>>>> fixes of the previous patch.  So that information is totally lost, 
>>>>>> and
>>>>>
>>>>> Its because this patch("PATCH 12/14] nvmem: make the misaligned
>>>>> raw_len non-fatal") is taken as fixup patch and wrapped into the
>>>>> original patch ("nvmem: core: verify cell's raw_len"), Also the sha
>>>>> will not be valid for linus or char-misc tree.
>>>>>
>>>>>> again, the first commit here, "nvmem: core: verify cell's raw_len" is
>>>>>> broken so much that it took 3 other changes to fix it, which implies
>>>>>> that bisection would cause problems if you hit it in the middle here.
>>>>>>
>>>>>
>>>>> All the patches related to this are enhancements to nvmem core to
>>>>> allow specifying bit offsets for nvmem cell that have 4 bytes strides.
>>>>>
>>>>> Specially this check is also an additional check in core to make sure
>>>>> that cell offsets are aligned to register strides.
>>>>>
>>>>>> While fixing patches is great, and something we do in the tree all 
>>>>>> the
>>>>>> time, let's not purposefully break things and then fix them up in the
>>>>>> same exact patch series please.  That's just sloppy engineering.
>>>>>>
>>>>>> Please redo this series completely.  I can take the "new device 
>>>>>> support"
>>>>>
>>>>> I can send them but its going to be exactly same series, I dont think
>>>>> anything will change as all of these patches are enhancements and
>>>>> there are no fixes.
>>>>>
>>>>> I hope this clarifies a bit, Please let me know if you still want me
>>>>> to resend this series, which is going to be exactly same.
>>>>
>>>> I think Greg is asking to squash the fixup into the relevant patch.
>>>
>>> Its already squashed up in v2.
>>
>> Then there should be no Fixes tags. Is the series that you are sending
>> visible somewhere?
> 
> Yes, there is no fixes tags in v2 series,
> 
> Here is what is sent to as v2:
> https://lore.kernel.org/lkml/47a3a851- 
> f737-4772-87c6-98613347435c@linaro.org/T/ 
> #r01449e17cf6f9396967a822a0460ad4b1245e914

LGTM, thanks. Then I don't understand what is causing the controversy 
from Greg's side. The only piece of information that got lost is that 
Mark has found an issue with the previous version of the patch (I'd have 
added that information between the tags as you've squashed the patches).

> 
> 
> thanks,
> Srini
>>
>>>
>>> thanks,
>>> Srini
>>>>
>>>>>
>>>>> --srini
>>>>>> patches at any time, and really, those should be marked with Cc: 
>>>>>> stable
>>>>>> to get backported, right?  The other ones are written as if they are
>>>>>> fixes, so again, I can take them any time, no need to wait for the 
>>>>>> -rc1
>>>>>> merge cycle.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> greg k-h
>>>>
>>>>
>>
>>
>>


-- 
With best wishes
Dmitry

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Greg KH]

On Thu, Apr 03, 2025 at 12:38:03PM +0300, Dmitry Baryshkov wrote:
> On 03/04/2025 12:35, Srinivas Kandagatla wrote:
> > 
> > 
> > On 03/04/2025 10:31, Dmitry Baryshkov wrote:
> > > On Thu, 3 Apr 2025 at 12:27, Srinivas Kandagatla
> > > <srinivas.kandagatla@linaro.org> wrote:
> > > > 
> > > > 
> > > > 
> > > > On 03/04/2025 10:25, Dmitry Baryshkov wrote:
> > > > > On 03/04/2025 12:18, Srinivas Kandagatla wrote:
> > > > > > 
> > > > > > 
> > > > > > On 02/04/2025 12:31, Greg KH wrote:
> > > > > > > On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
> > > > > > > > HI Greg,
> > > > > > > > 
> > > > > > > > On 01/04/2025 20:18, Greg KH wrote:
> > > > > > > > > On Sun, Mar 09, 2025 at 02:56:50PM +0000,
> > > > > > > > > srinivas.kandagatla@linaro.org wrote:
> > > > > > > > > > From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > > > > > > > > > 
> > > > > > > > > > Hi Greg,
> > > > > > > > > > 
> > > > > > > > > > Here are few nvmem patches for 6.15, Could you queue
> > > > > > > > > > these for 6.15.
> > > > > > > > > > 
> > > > > > > > > > patche include
> > > > > > > > > >      - updates to bindings to include MSM8960, X1E80100, MS8937,
> > > > > > > > > >        IPQ5018
> > > > > > > > > >      - add support to bit offsets for register strides exceeding
> > > > > > > > > >        single byte
> > > > > > > > > >      - add rockchip-otp variants.
> > > > > > > > > >      - Few enhancements in qfprom and rochchip nvmem providers.
> > > > > > > > > 
> > > > > > > > > Ok, I wanted to apply these, and tried to, but they fail horribly
> > > > > > > > > because:
> > > > > > > > > 
> > > > > > > > > Commit: 1b14625bd6d4 ("nvmem: qfprom: switch
> > > > > > > > > to 4-byte aligned reads")
> > > > > > > > >      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
> > > > > > > > > raw_len")
> > > > > > > > >      Has these problem(s):
> > > > > > > > >          - Target SHA1 does not exist
> > > > > > > > > Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit
> > > > > > > > > reading is required")
> > > > > > > > >      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
> > > > > > > > > raw_len")
> > > > > > > > >      Has these problem(s):
> > > > > > > > >          - Target SHA1 does not exist
> > > > > > > > > Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than
> > > > > > > > > one byte")
> > > > > > > > >      Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
> > > > > > > > > raw_len")
> > > > > > > > >      Has these problem(s):
> > > > > > > > >          - Target SHA1 does not exist
> > > > > > > > 
> > > > > > > > Looks some of your scripts or b4 is picking up
> > > > > > > > older version v1 of the
> > > > > > > > patchset
> > > > > > > > 
> > > > > > > > None of the above patches have Fixes tags in the V2 patches that I
> > > > > > > > shared
> > > > > > > > aswell as patches in linux-next.
> > > > > > > 
> > > > > > > Yes, that looks odd, it looks like b4 pulled in the
> > > > > > > wrong series, yes.
> > > > > > > 
> > > > > > 
> > > > > > Even that looked incorrect, as the v1 series only had one
> > > > > > patch("[PATCH 12/14] nvmem: make the misaligned raw_len non-fatal")
> > > > > > that had fixes tag. Not sure how these 3 patches are tagged as fixes.
> > > > > > 
> > > > > > > But, that's even worse.  Those "fixes" are now not actually marked as
> > > > > > > fixes of the previous patch.  So that information is
> > > > > > > totally lost, and
> > > > > > 
> > > > > > Its because this patch("PATCH 12/14] nvmem: make the misaligned
> > > > > > raw_len non-fatal") is taken as fixup patch and wrapped into the
> > > > > > original patch ("nvmem: core: verify cell's raw_len"), Also the sha
> > > > > > will not be valid for linus or char-misc tree.
> > > > > > 
> > > > > > > again, the first commit here, "nvmem: core: verify cell's raw_len" is
> > > > > > > broken so much that it took 3 other changes to fix it, which implies
> > > > > > > that bisection would cause problems if you hit it in the middle here.
> > > > > > > 
> > > > > > 
> > > > > > All the patches related to this are enhancements to nvmem core to
> > > > > > allow specifying bit offsets for nvmem cell that have 4 bytes strides.
> > > > > > 
> > > > > > Specially this check is also an additional check in core to make sure
> > > > > > that cell offsets are aligned to register strides.
> > > > > > 
> > > > > > > While fixing patches is great, and something we do
> > > > > > > in the tree all the
> > > > > > > time, let's not purposefully break things and then fix them up in the
> > > > > > > same exact patch series please.  That's just sloppy engineering.
> > > > > > > 
> > > > > > > Please redo this series completely.  I can take the
> > > > > > > "new device support"
> > > > > > 
> > > > > > I can send them but its going to be exactly same series, I dont think
> > > > > > anything will change as all of these patches are enhancements and
> > > > > > there are no fixes.
> > > > > > 
> > > > > > I hope this clarifies a bit, Please let me know if you still want me
> > > > > > to resend this series, which is going to be exactly same.
> > > > > 
> > > > > I think Greg is asking to squash the fixup into the relevant patch.
> > > > 
> > > > Its already squashed up in v2.
> > > 
> > > Then there should be no Fixes tags. Is the series that you are sending
> > > visible somewhere?
> > 
> > Yes, there is no fixes tags in v2 series,
> > 
> > Here is what is sent to as v2:
> > https://lore.kernel.org/lkml/47a3a851-
> > f737-4772-87c6-98613347435c@linaro.org/T/
> > #r01449e17cf6f9396967a822a0460ad4b1245e914
> 
> LGTM, thanks. Then I don't understand what is causing the controversy from
> Greg's side. The only piece of information that got lost is that Mark has
> found an issue with the previous version of the patch (I'd have added that
> information between the tags as you've squashed the patches).

Yeah, I'm confused here as well.  In v1, there were 3 patches that were
marked as "Fixes" for a previous patch in the series.  In v2, no Fixes
were marked at all, BUT the patches were still in the series.

So what went wrong?  Was the v2 version of the original patch changed so
that the 3 other ones were not needed somehow?  If so, why were they in
the list again?

Anyway, I'm confused...

Please send a v3 of this series, NOT in response to any email thread so
that b4 does NOT get confused in any way, and I'll be glad to review
them and apply them to the proper branch after -rc1 is out next week or
so.

And document the heck out of what has changed in the series in the
different patches please.

thanks,

greg k-h

Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

[Srinivas Kandagatla]

On 03/04/2025 14:52, Greg KH wrote:
> On Thu, Apr 03, 2025 at 12:38:03PM +0300, Dmitry Baryshkov wrote:
>> On 03/04/2025 12:35, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 03/04/2025 10:31, Dmitry Baryshkov wrote:
>>>> On Thu, 3 Apr 2025 at 12:27, Srinivas Kandagatla
>>>> <srinivas.kandagatla@linaro.org> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 03/04/2025 10:25, Dmitry Baryshkov wrote:
>>>>>> On 03/04/2025 12:18, Srinivas Kandagatla wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 02/04/2025 12:31, Greg KH wrote:
>>>>>>>> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
>>>>>>>>> HI Greg,
>>>>>>>>>
>>>>>>>>> On 01/04/2025 20:18, Greg KH wrote:
>>>>>>>>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000,
>>>>>>>>>> srinivas.kandagatla@linaro.org wrote:
>>>>>>>>>>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>>>>>>>>>
>>>>>>>>>>> Hi Greg,
>>>>>>>>>>>
>>>>>>>>>>> Here are few nvmem patches for 6.15, Could you queue
>>>>>>>>>>> these for 6.15.
>>>>>>>>>>>
>>>>>>>>>>> patche include
>>>>>>>>>>>       - updates to bindings to include MSM8960, X1E80100, MS8937,
>>>>>>>>>>>         IPQ5018
>>>>>>>>>>>       - add support to bit offsets for register strides exceeding
>>>>>>>>>>>         single byte
>>>>>>>>>>>       - add rockchip-otp variants.
>>>>>>>>>>>       - Few enhancements in qfprom and rochchip nvmem providers.
>>>>>>>>>>
>>>>>>>>>> Ok, I wanted to apply these, and tried to, but they fail horribly
>>>>>>>>>> because:
>>>>>>>>>>
>>>>>>>>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch
>>>>>>>>>> to 4-byte aligned reads")
>>>>>>>>>>       Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>>>>> raw_len")
>>>>>>>>>>       Has these problem(s):
>>>>>>>>>>           - Target SHA1 does not exist
>>>>>>>>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit
>>>>>>>>>> reading is required")
>>>>>>>>>>       Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>>>>> raw_len")
>>>>>>>>>>       Has these problem(s):
>>>>>>>>>>           - Target SHA1 does not exist
>>>>>>>>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than
>>>>>>>>>> one byte")
>>>>>>>>>>       Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's
>>>>>>>>>> raw_len")
>>>>>>>>>>       Has these problem(s):
>>>>>>>>>>           - Target SHA1 does not exist
>>>>>>>>>
>>>>>>>>> Looks some of your scripts or b4 is picking up
>>>>>>>>> older version v1 of the
>>>>>>>>> patchset
>>>>>>>>>
>>>>>>>>> None of the above patches have Fixes tags in the V2 patches that I
>>>>>>>>> shared
>>>>>>>>> aswell as patches in linux-next.
>>>>>>>>
>>>>>>>> Yes, that looks odd, it looks like b4 pulled in the
>>>>>>>> wrong series, yes.
>>>>>>>>
>>>>>>>
>>>>>>> Even that looked incorrect, as the v1 series only had one
>>>>>>> patch("[PATCH 12/14] nvmem: make the misaligned raw_len non-fatal")
>>>>>>> that had fixes tag. Not sure how these 3 patches are tagged as fixes.
>>>>>>>
>>>>>>>> But, that's even worse.  Those "fixes" are now not actually marked as
>>>>>>>> fixes of the previous patch.  So that information is
>>>>>>>> totally lost, and
>>>>>>>
>>>>>>> Its because this patch("PATCH 12/14] nvmem: make the misaligned
>>>>>>> raw_len non-fatal") is taken as fixup patch and wrapped into the
>>>>>>> original patch ("nvmem: core: verify cell's raw_len"), Also the sha
>>>>>>> will not be valid for linus or char-misc tree.
>>>>>>>
>>>>>>>> again, the first commit here, "nvmem: core: verify cell's raw_len" is
>>>>>>>> broken so much that it took 3 other changes to fix it, which implies
>>>>>>>> that bisection would cause problems if you hit it in the middle here.
>>>>>>>>
>>>>>>>
>>>>>>> All the patches related to this are enhancements to nvmem core to
>>>>>>> allow specifying bit offsets for nvmem cell that have 4 bytes strides.
>>>>>>>
>>>>>>> Specially this check is also an additional check in core to make sure
>>>>>>> that cell offsets are aligned to register strides.
>>>>>>>
>>>>>>>> While fixing patches is great, and something we do
>>>>>>>> in the tree all the
>>>>>>>> time, let's not purposefully break things and then fix them up in the
>>>>>>>> same exact patch series please.  That's just sloppy engineering.
>>>>>>>>
>>>>>>>> Please redo this series completely.  I can take the
>>>>>>>> "new device support"
>>>>>>>
>>>>>>> I can send them but its going to be exactly same series, I dont think
>>>>>>> anything will change as all of these patches are enhancements and
>>>>>>> there are no fixes.
>>>>>>>
>>>>>>> I hope this clarifies a bit, Please let me know if you still want me
>>>>>>> to resend this series, which is going to be exactly same.
>>>>>>
>>>>>> I think Greg is asking to squash the fixup into the relevant patch.
>>>>>
>>>>> Its already squashed up in v2.
>>>>
>>>> Then there should be no Fixes tags. Is the series that you are sending
>>>> visible somewhere?
>>>
>>> Yes, there is no fixes tags in v2 series,
>>>
>>> Here is what is sent to as v2:
>>> https://lore.kernel.org/lkml/47a3a851-
>>> f737-4772-87c6-98613347435c@linaro.org/T/
>>> #r01449e17cf6f9396967a822a0460ad4b1245e914
>>
>> LGTM, thanks. Then I don't understand what is causing the controversy from
>> Greg's side. The only piece of information that got lost is that Mark has
>> found an issue with the previous version of the patch (I'd have added that
>> information between the tags as you've squashed the patches).
> 
> Yeah, I'm confused here as well.  In v1, there were 3 patches that were
> marked as "Fixes" for a previous patch in the series.  In v2, no Fixes
> were marked at all, BUT the patches were still in the series.

In fact there was only one patch with fixes tag in v1, not sure if b4 
picked up 3 which is the part that confused me too.

> 
> So what went wrong?  Was the v2 version of the original patch changed so
> that the 3 other ones were not needed somehow?  If so, why were they in
> the list again?

I have captured that in cover letter:


Changes since v1:
  - Merged fixup "nvmem: make the misaligned raw_len non-fatal" into
   "nvmem: core: verify cell's raw_len"


> 
> Anyway, I'm confused...
> 
> Please send a v3 of this series, NOT in response to any email thread so
> that b4 does NOT get confused in any way, and I'll be glad to review
> them and apply them to the proper branch after -rc1 is out next week or
> so.

I will send v3.
thanks,
Srini
> 
> And document the heck out of what has changed in the series in the
> different patches please.
> 

> thanks,
> 
> greg k-h