Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1507634 > unrolled thread

[PATCH v1 0/3] Add support for Broadcom OTP controller

Started byJonathan Richardson <jonathan.richardson@broadcom.com>
First post2016-10-24 21:20 +0200
Last post2016-10-25 00:50 +0200
Articles 10 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v1 0/3] Add support for Broadcom OTP controller Jonathan Richardson <jonathan.richardson@broadcom.com> - 2016-10-24 21:20 +0200
    [PATCH v1 1/3] dt-bindings: Document Broadcom OTP controller driver Jonathan Richardson <jonathan.richardson@broadcom.com> - 2016-10-24 21:20 +0200
    [PATCH v1 3/3] ARM: dts: Add node for Broadcom OTP controller driver Jonathan Richardson <jonathan.richardson@broadcom.com> - 2016-10-24 21:20 +0200
    [PATCH v1 2/3] nvmem: Add the Broadcom OTP controller driver Jonathan Richardson <jonathan.richardson@broadcom.com> - 2016-10-24 21:20 +0200
    Re: [PATCH v1 0/3] Add support for Broadcom OTP controller Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-24 21:40 +0200
      Re: [PATCH v1 0/3] Add support for Broadcom OTP controller Florian Fainelli <f.fainelli@gmail.com> - 2016-10-24 22:00 +0200
        Re: [PATCH v1 0/3] Add support for Broadcom OTP controller Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-24 22:20 +0200
          Re: [PATCH v1 0/3] Add support for Broadcom OTP controller Florian Fainelli <f.fainelli@gmail.com> - 2016-10-24 23:30 +0200
            Re: [PATCH v1 0/3] Add support for Broadcom OTP controller Linus Torvalds <torvalds@linux-foundation.org> - 2016-10-25 00:00 +0200
              Re: [PATCH v1 0/3] Add support for Broadcom OTP controller Markus Mayer <markus.mayer@broadcom.com> - 2016-10-25 00:50 +0200

#1507634 — [PATCH v1 0/3] Add support for Broadcom OTP controller

FromJonathan Richardson <jonathan.richardson@broadcom.com>
Date2016-10-24 21:20 +0200
Subject[PATCH v1 0/3] Add support for Broadcom OTP controller
Message-ID<svSWR-3rd-11@gated-at.bofh.it>
This patch set adds support for Broadcom's OTP controller found on chips such
as Cygnus and Stingray. A node has been added to the Cygnus dts.


Jonathan Richardson (3):
  dt-bindings: Document Broadcom OTP controller driver
  nvmem: Add the Broadcom OTP controller driver
  ARM: dts: Add node for Broadcom OTP controller driver

 .../devicetree/bindings/nvmem/brcm,ocotp.txt       |  17 ++
 arch/arm/boot/dts/bcm-cygnus.dtsi                  |   7 +
 drivers/nvmem/Kconfig                              |  12 +
 drivers/nvmem/Makefile                             |   2 +
 drivers/nvmem/bcm-ocotp.c                          | 335 +++++++++++++++++++++
 5 files changed, 373 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
 create mode 100644 drivers/nvmem/bcm-ocotp.c

-- 
1.9.1

[toc] | [next] | [standalone]


#1507640 — [PATCH v1 1/3] dt-bindings: Document Broadcom OTP controller driver

FromJonathan Richardson <jonathan.richardson@broadcom.com>
Date2016-10-24 21:20 +0200
Subject[PATCH v1 1/3] dt-bindings: Document Broadcom OTP controller driver
Message-ID<svSWR-3rd-9@gated-at.bofh.it>
In reply to#1507634
From: Jonathan Richardson <jonathar@broadcom.com>

Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Oza Pawandeep <oza@broadcom.com>
Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
---
 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt

diff --git a/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
new file mode 100644
index 0000000..6462e12
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/brcm,ocotp.txt
@@ -0,0 +1,17 @@
+Broadcom OTP memory controller
+
+Required Properties:
+- compatible: "brcm,ocotp" for the first generation Broadcom OTPC which is used
+  in Cygnus and supports 32 bit read/write. Use "brcm,ocotp-v2" for the second
+  generation Broadcom OTPC which is used in SoC's such as Stingray and supports
+  64-bit read/write.
+- reg: Base address of the OTP controller.
+- brcm,ocotp-size: Amount of memory available, in 32 bit words
+
+Example:
+
+otp: otp@0301c800 {
+	compatible = "brcm,ocotp";
+	reg = <0x0301c800 0x2c>;
+	brcm,ocotp-size = <2048>;
+};
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]


#1507643 — [PATCH v1 3/3] ARM: dts: Add node for Broadcom OTP controller driver

FromJonathan Richardson <jonathan.richardson@broadcom.com>
Date2016-10-24 21:20 +0200
Subject[PATCH v1 3/3] ARM: dts: Add node for Broadcom OTP controller driver
Message-ID<svSWS-3rd-39@gated-at.bofh.it>
In reply to#1507634
From: Jonathan Richardson <jonathar@broadcom.com>

Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Oza Pawandeep <oza@broadcom.com>
Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index fabc9f3..a74a430 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -91,6 +91,13 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 
+		otp: otp@0301c800 {
+			compatible = "brcm,ocotp";
+			reg = <0x0301c800 0x2c>;
+			brcm,ocotp-size = <2048>;
+			status = "disabled";
+		};
+
 		pcie_phy: phy@0301d0a0 {
 			compatible = "brcm,cygnus-pcie-phy";
 			reg = <0x0301d0a0 0x14>;
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]


#1507649 — [PATCH v1 2/3] nvmem: Add the Broadcom OTP controller driver

FromJonathan Richardson <jonathan.richardson@broadcom.com>
Date2016-10-24 21:20 +0200
Subject[PATCH v1 2/3] nvmem: Add the Broadcom OTP controller driver
Message-ID<svSWS-3rd-35@gated-at.bofh.it>
In reply to#1507634
From: Jonathan Richardson <jonathar@broadcom.com>

Add support for 32 and 64-bit versions of Broadcom's On-Chip OTP
controller. These controllers are used on SoC's such as Cygnus and
Stingray.

Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Tested-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Oza Pawandeep <oza@broadcom.com>
Signed-off-by: Jonathan Richardson <jonathan.richardson@broadcom.com>
---
 drivers/nvmem/Kconfig     |  12 ++
 drivers/nvmem/Makefile    |   2 +
 drivers/nvmem/bcm-ocotp.c | 335 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 349 insertions(+)
 create mode 100644 drivers/nvmem/bcm-ocotp.c

diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index ba140ea..06935a7 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -80,6 +80,18 @@ config ROCKCHIP_EFUSE
 	  This driver can also be built as a module. If so, the module
 	  will be called nvmem_rockchip_efuse.
 
+config NVMEM_BCM_OCOTP
+	tristate "Broadcom On-Chip OTP Controller support"
+	depends on ARCH_BCM_IPROC || COMPILE_TEST
+	depends on HAS_IOMEM
+	default ARCH_BCM_IPROC
+	help
+	  Say y here to enable read/write access to the Broadcom OTP
+	  controller.
+
+	  This driver can also be built as a module. If so, the module
+	  will be called nvmem-bcm-ocotp.
+
 config NVMEM_SUNXI_SID
 	tristate "Allwinner SoCs SID support"
 	depends on ARCH_SUNXI
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 8f942a0..71781ca 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -6,6 +6,8 @@ obj-$(CONFIG_NVMEM)		+= nvmem_core.o
 nvmem_core-y			:= core.o
 
 # Devices
+obj-$(CONFIG_NVMEM_BCM_OCOTP)	+= nvmem-bcm-ocotp.o
+nvmem-bcm-ocotp-y		:= bcm-ocotp.o
 obj-$(CONFIG_NVMEM_IMX_OCOTP)	+= nvmem-imx-ocotp.o
 nvmem-imx-ocotp-y		:= imx-ocotp.o
 obj-$(CONFIG_NVMEM_LPC18XX_EEPROM)	+= nvmem_lpc18xx_eeprom.o
diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
new file mode 100644
index 0000000..646cadb
--- /dev/null
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -0,0 +1,335 @@
+/*
+ * Copyright (C) 2016 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+/*
+ * # of tries for OTP Status. The time to execute a command varies. The slowest
+ * commands are writes which also vary based on the # of bits turned on. Writing
+ * 0xffffffff takes ~3800 us.
+ */
+#define OTPC_RETRIES                 5000
+
+/* Sequence to enable OTP program */
+#define OTPC_PROG_EN_SEQ             { 0xf, 0x4, 0x8, 0xd }
+
+/* OTPC Commands */
+#define OTPC_CMD_READ                0x0
+#define OTPC_CMD_OTP_PROG_ENABLE     0x2
+#define OTPC_CMD_OTP_PROG_DISABLE    0x3
+#define OTPC_CMD_PROGRAM             0xA
+
+/* OTPC Status Bits */
+#define OTPC_STAT_CMD_DONE           BIT(1)
+#define OTPC_STAT_PROG_OK            BIT(2)
+
+/* OTPC register definition */
+#define OTPC_MODE_REG_OFFSET         0x0
+#define OTPC_MODE_REG_OTPC_MODE      0
+#define OTPC_COMMAND_OFFSET          0x4
+#define OTPC_COMMAND_COMMAND_WIDTH   6
+#define OTPC_CMD_START_OFFSET        0x8
+#define OTPC_CMD_START_START         0
+#define OTPC_CPU_STATUS_OFFSET       0xc
+#define OTPC_CPUADDR_REG_OFFSET      0x28
+#define OTPC_CPUADDR_REG_OTPC_CPU_ADDRESS_WIDTH 16
+#define OTPC_CPU_WRITE_REG_OFFSET    0x2c
+
+#define OTPC_CMD_MASK  (BIT(OTPC_COMMAND_COMMAND_WIDTH) - 1)
+#define OTPC_ADDR_MASK (BIT(OTPC_CPUADDR_REG_OTPC_CPU_ADDRESS_WIDTH) - 1)
+
+
+struct otpc_map {
+	/* in words. */
+	u32 otpc_row_size;
+	/* 128 bit row / 4 words support. */
+	u16 data_r_offset[4];
+	/* 128 bit row / 4 words support. */
+	u16 data_w_offset[4];
+};
+
+static struct otpc_map otp_map = {
+	.otpc_row_size = 1,
+	.data_r_offset = {0x10},
+	.data_w_offset = {0x2c},
+};
+
+static struct otpc_map otp_map_v2 = {
+	.otpc_row_size = 2,
+	.data_r_offset = {0x10, 0x5c},
+	.data_w_offset = {0x2c, 0x64},
+};
+
+struct otpc_priv {
+	struct device       *dev;
+	void __iomem        *base;
+	struct otpc_map     *map;
+	struct nvmem_config *config;
+};
+
+static inline void set_command(void __iomem *base, u32 command)
+{
+	writel(command & OTPC_CMD_MASK, base + OTPC_COMMAND_OFFSET);
+}
+
+static inline void set_cpu_address(void __iomem *base, u32 addr)
+{
+	writel(addr & OTPC_ADDR_MASK, base + OTPC_CPUADDR_REG_OFFSET);
+}
+
+static inline void set_start_bit(void __iomem *base)
+{
+	writel(1 << OTPC_CMD_START_START, base + OTPC_CMD_START_OFFSET);
+}
+
+static inline void reset_start_bit(void __iomem *base)
+{
+	writel(0, base + OTPC_CMD_START_OFFSET);
+}
+
+static inline void write_cpu_data(void __iomem *base, u32 value)
+{
+	writel(value, base + OTPC_CPU_WRITE_REG_OFFSET);
+}
+
+static int poll_cpu_status(void __iomem *base, u32 value)
+{
+	u32 status;
+	u32 retries;
+
+	for (retries = 0; retries < OTPC_RETRIES; retries++) {
+		status = readl(base + OTPC_CPU_STATUS_OFFSET);
+		if (status & value)
+			break;
+		udelay(1);
+	}
+	if (retries == OTPC_RETRIES)
+		return -EAGAIN;
+
+	return 0;
+}
+
+static int enable_ocotp_program(void __iomem *base)
+{
+	static const u32 vals[] = OTPC_PROG_EN_SEQ;
+	int i;
+	int ret;
+
+	/* Write the magic sequence to enable programming */
+	set_command(base, OTPC_CMD_OTP_PROG_ENABLE);
+	for (i = 0; i < ARRAY_SIZE(vals); i++) {
+		write_cpu_data(base, vals[i]);
+		set_start_bit(base);
+		ret = poll_cpu_status(base, OTPC_STAT_CMD_DONE);
+		reset_start_bit(base);
+		if (ret)
+			return ret;
+	}
+
+	return poll_cpu_status(base, OTPC_STAT_PROG_OK);
+}
+
+static int disable_ocotp_program(void __iomem *base)
+{
+	int ret;
+
+	set_command(base, OTPC_CMD_OTP_PROG_DISABLE);
+	set_start_bit(base);
+	ret = poll_cpu_status(base, OTPC_STAT_PROG_OK);
+	reset_start_bit(base);
+
+	return ret;
+}
+
+static int bcm_otpc_read(void *context, unsigned int offset, void *val,
+	size_t bytes)
+{
+	struct otpc_priv *priv = context;
+	u32 *buf = val;
+	u32 bytes_read;
+	u32 address = offset / priv->config->word_size;
+	int i, ret;
+
+	for (bytes_read = 0; bytes_read < bytes;) {
+		set_command(priv->base, OTPC_CMD_READ);
+		set_cpu_address(priv->base, address++);
+		set_start_bit(priv->base);
+		ret = poll_cpu_status(priv->base, OTPC_STAT_CMD_DONE);
+		if (ret) {
+			dev_err(priv->dev, "otp read error: 0x%x", ret);
+			return -EIO;
+		}
+
+		for (i = 0; i < priv->map->otpc_row_size; i++) {
+			*buf++ = readl(priv->base +
+					priv->map->data_r_offset[i]);
+			bytes_read += sizeof(*buf);
+		}
+
+		reset_start_bit(priv->base);
+	}
+
+	return 0;
+}
+
+static int bcm_otpc_write(void *context, unsigned int offset, void *val,
+	size_t bytes)
+{
+	struct otpc_priv *priv = context;
+	u32 *buf = val;
+	u32 bytes_written;
+	u32 address = offset / priv->config->word_size;
+	int i, ret;
+
+	if (offset % priv->config->word_size)
+		return -EINVAL;
+
+	ret = enable_ocotp_program(priv->base);
+	if (ret)
+		return -EIO;
+
+	for (bytes_written = 0; bytes_written < bytes;) {
+		set_command(priv->base, OTPC_CMD_PROGRAM);
+		set_cpu_address(priv->base, address++);
+		for (i = 0; i < priv->map->otpc_row_size; i++) {
+			writel(*buf, priv->base + priv->map->data_r_offset[i]);
+			buf++;
+			bytes_written += sizeof(*buf);
+		}
+		set_start_bit(priv->base);
+		ret = poll_cpu_status(priv->base, OTPC_STAT_CMD_DONE);
+		reset_start_bit(priv->base);
+		if (ret) {
+			dev_err(priv->dev, "otp write error: 0x%x", ret);
+			return -EIO;
+		}
+	}
+
+	disable_ocotp_program(priv->base);
+
+	return 0;
+}
+
+static struct nvmem_config bcm_otpc_nvmem_config = {
+	.name = "bcm-ocotp",
+	.read_only = false,
+	.word_size = 4,
+	.stride = 4,
+	.owner = THIS_MODULE,
+	.reg_read = bcm_otpc_read,
+	.reg_write = bcm_otpc_write,
+};
+
+static const struct of_device_id bcm_otpc_dt_ids[] = {
+	{ .compatible = "brcm,ocotp" },
+	{ .compatible = "brcm,ocotp-v2" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, bcm_otpc_dt_ids);
+
+static int bcm_otpc_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct device_node *dn = dev->of_node;
+	struct resource *res;
+	struct otpc_priv *priv;
+	struct nvmem_device *nvmem;
+	int err;
+	u32 num_words;
+
+	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	if (of_device_is_compatible(dev->of_node, "brcm,ocotp"))
+		priv->map = &otp_map;
+	else if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2"))
+		priv->map = &otp_map_v2;
+	else {
+		dev_err(&pdev->dev,
+			"%s otpc config map not defined\n", __func__);
+		return -EINVAL;
+	}
+
+	/* Get OTP base address register. */
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->base = devm_ioremap_resource(dev, res);
+	if (IS_ERR(priv->base)) {
+		dev_err(dev, "unable to map I/O memory\n");
+		return PTR_ERR(priv->base);
+	}
+
+	/* Enable CPU access to OTPC. */
+	writel(readl(priv->base + OTPC_MODE_REG_OFFSET) |
+		BIT(OTPC_MODE_REG_OTPC_MODE),
+		priv->base + OTPC_MODE_REG_OFFSET);
+	reset_start_bit(priv->base);
+
+	/* Read size of memory in words. */
+	err = of_property_read_u32(dn, "brcm,ocotp-size", &num_words);
+	if (err) {
+		dev_err(dev, "size parameter not specified\n");
+		return -EINVAL;
+	} else if (num_words == 0) {
+		dev_err(dev, "size must be > 0\n");
+		return -EINVAL;
+	}
+
+	bcm_otpc_nvmem_config.size = 4 * num_words;
+	bcm_otpc_nvmem_config.dev = dev;
+	bcm_otpc_nvmem_config.priv = priv;
+
+	if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2")) {
+		bcm_otpc_nvmem_config.word_size = 8;
+		bcm_otpc_nvmem_config.stride = 8;
+	}
+
+	priv->config = &bcm_otpc_nvmem_config;
+
+	nvmem = nvmem_register(&bcm_otpc_nvmem_config);
+	if (IS_ERR(nvmem)) {
+		dev_err(dev, "error registering nvmem config\n");
+		return PTR_ERR(nvmem);
+	}
+
+	platform_set_drvdata(pdev, nvmem);
+
+	return 0;
+}
+
+static int bcm_otpc_remove(struct platform_device *pdev)
+{
+	struct nvmem_device *nvmem = platform_get_drvdata(pdev);
+
+	return nvmem_unregister(nvmem);
+}
+
+static struct platform_driver bcm_otpc_driver = {
+	.probe	= bcm_otpc_probe,
+	.remove	= bcm_otpc_remove,
+	.driver = {
+		.name	= "brcm-otpc",
+		.of_match_table = bcm_otpc_dt_ids,
+	},
+};
+module_platform_driver(bcm_otpc_driver);
+
+MODULE_DESCRIPTION("Broadcom OTPC driver");
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]


#1507660

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-10-24 21:40 +0200
Message-ID<svTge-3ya-15@gated-at.bofh.it>
In reply to#1507634
On Mon, Oct 24, 2016 at 12:12 PM, Jonathan Richardson
<jonathan.richardson@broadcom.com> wrote:
> This patch set adds support for Broadcom's OTP controller found on chips such
> as Cygnus and Stingray. A node has been added to the Cygnus dts.

These patches fail DKIM and will thus be marked as spam for a lot of people.

The usual reason tends to be that you use the wrong smtp server that
doesn't add the right signature. That's happened before with
broadcom.com addresses.

               Linus

[toc] | [prev] | [next] | [standalone]


#1507676

FromFlorian Fainelli <f.fainelli@gmail.com>
Date2016-10-24 22:00 +0200
Message-ID<svTzz-3Fg-31@gated-at.bofh.it>
In reply to#1507660
On 10/24/2016 12:39 PM, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 12:12 PM, Jonathan Richardson
> <jonathan.richardson@broadcom.com> wrote:
>> This patch set adds support for Broadcom's OTP controller found on chips such
>> as Cygnus and Stingray. A node has been added to the Cygnus dts.
> 
> These patches fail DKIM and will thus be marked as spam for a lot of people.
> 
> The usual reason tends to be that you use the wrong smtp server that
> doesn't add the right signature. That's happened before with
> broadcom.com addresses.

The older setup was using smtphost.broadcom.com which we have now
documented as being invalid, here Jonathan used gmail directly (since
that's our mail provider now):

Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
        by smtp.gmail.com with ESMTPSA id
s89sm8325746qkl.44.2016.10.24.12.12.00
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
        Mon, 24 Oct 2016 12:12:03 -0700 (PDT)

Is there something else we need to check? Here is what I read for the
cover-letter:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@broadcom.com;
       spf=pass (google.com: domain of
bcm-kernel-feedback-list.pdl+bncbdh5xfvr4ydrbbn2xhaakgqed7hz4rq@broadcom.com
designates 2607:f8b0:400c:c08::247 as permitted sender)
smtp.mailfrom=bcm-kernel-feedback-list.pdl+bncBDH5XFVR4YDRBBN2XHAAKGQED7HZ4RQ@broadcom.com;
       dmarc=pass (p=QUARANTINE dis=NONE) header.from=broadcom.com
-- 
Florian

[toc] | [prev] | [next] | [standalone]


#1507690

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-10-24 22:20 +0200
Message-ID<svTSW-43c-7@gated-at.bofh.it>
In reply to#1507676
On Mon, Oct 24, 2016 at 12:54 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> The older setup was using smtphost.broadcom.com which we have now
> documented as being invalid, here Jonathan used gmail directly (since
> that's our mail provider now):
>
> Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
>         by smtp.gmail.com with ESMTPSA id
> s89sm8325746qkl.44.2016.10.24.12.12.00
>         (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
>         Mon, 24 Oct 2016 12:12:03 -0700 (PDT)

Hmm. I get that too, so if that's the right thing for a broadcom.com
address, it's not the smtp server issue.

We had a few cases of the kernel mailing list itself messing up emails
sufficiently to fail dkim, but that shouldn't be an issue for the
relaxed/relaxed model that broadcom uses (the vger mailing list
software screws up whitespace, which "relaxed" ignores).

> Is there something else we need to check? Here is what I read for the
> cover-letter:
>
> Authentication-Results: mx.google.com;
>        dkim=pass header.i=@broadcom.com;
>        spf=pass (google.com: domain of ...

Hmm. I get:

  Authentication-Results: mx.google.com;
         dkim=fail header.i=@broadcom.com;

with the actual dkim signature looking like this:

  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=broadcom.com; s=google;
        h=from:to:cc:subject:date:message-id;
        bh=9zStGnsZQDQqP6cm1CHPk7EYVtLvDsm2wN5qy5Mgx7M=;
        b=Z/1QD+FwJogJY9D8Qd197Q+VJt7Tr9+WoHFeKYRL00yhvxrMg0P8jKj1FbucJTluvM
         agC2eq9qCpZcNAfridjExDRDCuUPAIJIXTr9Npkpqlk6gEMq2FysrGer2D9Z4HQ/atTX
         67VirFsQK0gK7impYMn9kW5Q9BIIw5bOg7OdI=

and those fields that it protects look like this:

  From: Jonathan Richardson <jonathan.richardson@broadcom.com>
  To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Maxime
Ripard <maxime.ripard@free-electrons.com>
  Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Mark Rutland
<mark.rutland@arm.com>, Rob Herring <robh+dt@kernel.org>, Scott
Branden <sbranden@broadcom.com>, Ray Jui <rjui@broadcom.com>,
bcm-kernel-feedback-list@broadcom.com, Jonathan Richardson
<jonathan.richardson@broadcom.com>
  Subject: [PATCH v1 0/3] Add support for Broadcom OTP controller
  Date: Mon, 24 Oct 2016 12:12:01 -0700
  Message-Id: <1477336324-10543-1-git-send-email-jonathan.richardson@broadcom.com>

and I don't see anything obviously wrong anywhere - except for that
"dkim=fail" thing, and the email being in my spam folder.

               Linus

[toc] | [prev] | [next] | [standalone]


#1507750

FromFlorian Fainelli <f.fainelli@gmail.com>
Date2016-10-24 23:30 +0200
Message-ID<svUYG-4HF-25@gated-at.bofh.it>
In reply to#1507690
On 10/24/2016 01:14 PM, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 12:54 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> The older setup was using smtphost.broadcom.com which we have now
>> documented as being invalid, here Jonathan used gmail directly (since
>> that's our mail provider now):
>>
>> Received: from lbrmn-lnxub108.corp.ad.broadcom.com ([216.31.219.19])
>>         by smtp.gmail.com with ESMTPSA id
>> s89sm8325746qkl.44.2016.10.24.12.12.00
>>         (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
>>         Mon, 24 Oct 2016 12:12:03 -0700 (PDT)
> 
> Hmm. I get that too, so if that's the right thing for a broadcom.com
> address, it's not the smtp server issue.
> 
> We had a few cases of the kernel mailing list itself messing up emails
> sufficiently to fail dkim, but that shouldn't be an issue for the
> relaxed/relaxed model that broadcom uses (the vger mailing list
> software screws up whitespace, which "relaxed" ignores).
> 
>> Is there something else we need to check? Here is what I read for the
>> cover-letter:
>>
>> Authentication-Results: mx.google.com;
>>        dkim=pass header.i=@broadcom.com;
>>        spf=pass (google.com: domain of ...
> 
> Hmm. I get:
> 
>   Authentication-Results: mx.google.com;
>          dkim=fail header.i=@broadcom.com;
> 
> with the actual dkim signature looking like this:
> 
>   DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=broadcom.com; s=google;
>         h=from:to:cc:subject:date:message-id;
>         bh=9zStGnsZQDQqP6cm1CHPk7EYVtLvDsm2wN5qy5Mgx7M=;
>         b=Z/1QD+FwJogJY9D8Qd197Q+VJt7Tr9+WoHFeKYRL00yhvxrMg0P8jKj1FbucJTluvM
>          agC2eq9qCpZcNAfridjExDRDCuUPAIJIXTr9Npkpqlk6gEMq2FysrGer2D9Z4HQ/atTX
>          67VirFsQK0gK7impYMn9kW5Q9BIIw5bOg7OdI=
> 
> and those fields that it protects look like this:
> 
>   From: Jonathan Richardson <jonathan.richardson@broadcom.com>
>   To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>, Maxime
> Ripard <maxime.ripard@free-electrons.com>
>   Cc: linux-arm-kernel@lists.infradead.org,
> linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Mark Rutland
> <mark.rutland@arm.com>, Rob Herring <robh+dt@kernel.org>, Scott
> Branden <sbranden@broadcom.com>, Ray Jui <rjui@broadcom.com>,
> bcm-kernel-feedback-list@broadcom.com, Jonathan Richardson
> <jonathan.richardson@broadcom.com>
>   Subject: [PATCH v1 0/3] Add support for Broadcom OTP controller
>   Date: Mon, 24 Oct 2016 12:12:01 -0700
>   Message-Id: <1477336324-10543-1-git-send-email-jonathan.richardson@broadcom.com>
> 
> and I don't see anything obviously wrong anywhere - except for that
> "dkim=fail" thing, and the email being in my spam folder.

Should we compare the headers added by lists.infradead.org and see what
could possibly go wrong here? I can see that by being delivered to
lists.infradead.org and then back to my personal gmail.com (not my other
broadcom.com account), there are a bunch of extra headers:

X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3
X-CRM114-CacheID: sfid-20161024_121226_013940_81319C20
X-CRM114-Status: GOOD (  13.05  )
X-Spam-Score: -2.7 (--)
X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary:
 Content analysis details:   (-2.7 points)
 pts rule name              description
 ---- ----------------------
--------------------------------------------------
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at
http://www.dnswl.org/, low
 trust [2607:f8b0:400d:c09:0:0:0:22f listed in] [list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
 [score: 0.0000]
 -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
 domain
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
 not necessarily valid
X-BeenThere: linux-arm-kernel@lists.infradead.org
X-Mailman-Version: 2.1.20
Precedence: list

Would those be used by your mail client to put this mail in spam, or was
that done by the linux-foundation.org (also gmail?) mail upon reception?
-- 
Florian

[toc] | [prev] | [next] | [standalone]


#1507762

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-10-25 00:00 +0200
Message-ID<svVrH-4RK-1@gated-at.bofh.it>
In reply to#1507750
On Mon, Oct 24, 2016 at 2:27 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> Should we compare the headers added by lists.infradead.org

So for me, it didn't go through infraded.org, but I got it through the
kernel mailing list.

I'll send you the raw email data in private, you can compare it
against your good one.

                 Linus

[toc] | [prev] | [next] | [standalone]


#1507811

FromMarkus Mayer <markus.mayer@broadcom.com>
Date2016-10-25 00:50 +0200
Message-ID<svWe6-5rW-15@gated-at.bofh.it>
In reply to#1507762
FWIW, this thread ends up in the spam folder for me also on my private
e-mail account. And it's not the only Broadcom thread. Quite a few
Broadcom e-mails end up there. The thread was sent to me via
infradead.org. My private e-mail is also hosted by Gmail.

I get this:

SPF: PASS with IP 2001:1868:205:0:0:0:0:9 Learn more
DKIM: NEUTRAL with domain null Learn more
DMARC: FAIL Learn more

So, it's not DKIM for me, but DMARC that's failing.

The actual headers:

Received: from bombadil.infradead.org (bombadil.infradead.org.
[2001:1868:205::9])
        by mx.google.com with ESMTPS id
r127si16944054pgr.251.2016.10.24.12.13.37
        for <mmayer at mmayer.net>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Mon, 24 Oct 2016 12:13:37 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of
linux-arm-kernel-bounces+mmayer=mmayer.net@lists.infradead.org
designates 2001:1868:205::9 as permitted sender)
client-ip=2001:1868:205::9;
Authentication-Results: mx.google.com;
       dkim=neutral (body hash did not verify) header.i=@broadcom.com;
       spf=pass (google.com: best guess record for domain of
linux-arm-kernel-bounces+mmayer=mmayer.net@lists.infradead.org
designates 2001:1868:205::9 as permitted sender)
smtp.mailfrom=linux-arm-kernel-bounces+mmayer=mmayer.net@lists.infradead.org;
       dmarc=fail (p=QUARANTINE dis=NONE) header.from=broadcom.com
Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by
bombadil.infradead.org

Regards,
-Markus

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web