Re: [PATCH 0/4] MAINTAINERS: update BCM SoC entries

[Scott Branden]

Patch series looks good.

Acked-by: Scott Branden 

On 16-06-20 02:07 PM, Jon Mason wrote:

An overall clean-up to the MAINTAINER entries for a few Broadcom SoCs.

Jon Mason (4):
   MAINTAINERS: Fix nsp false-positives
   MAINTAINERS: Add NS2 entry
   MAINTAINERS: Update BCM63XX entry
   MAINTAINERS: Update BCM281XX/BCM11XXX/BCM216XX entry

  MAINTAINERS | 19 +--
  1 file changed, 9 insertions(+), 10 deletions(-)

Re: [PATCH v3 2/3] pwm: iproc: Add support for Broadcom iproc pwm controller

[Scott Branden]

Hi Dhananjaya,

One minor comment inline.

On 16-06-20 07:14 AM, Yendapally Reddy Dhananjaya Reddy wrote:

Add support for the PWM controller present in Broadcom's iProc
family of SoCs. This driver is derived from the pwm-bcm-kona
driver, with changes to the register offsets and bit positions.
It has been tested on the  Northstar+ bcm958625HR board.

Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
---
  drivers/pwm/Kconfig |  10 ++
  drivers/pwm/Makefile|   1 +
  drivers/pwm/pwm-bcm-iproc.c | 327 
  3 files changed, 338 insertions(+)
  create mode 100644 drivers/pwm/pwm-bcm-iproc.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c182efc..d298ebd 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -74,6 +74,16 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.

+config PWM_BCM_IPROC
+   tristate "iProc PWM support"
+   depends on ARCH_BCM_IPROC

depends on ARCH_BCM_IPROC || COMPILE_TEST

+   help
+ Generic PWM framework driver for Broadcom iProc PWM block. This
+ block is used in Broadcom iProc SoC's.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm-iproc.
+
  config PWM_BCM_KONA
tristate "Kona PWM support"
depends on ARCH_BCM_MOBILE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index dd35bc1..a196d79 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_PWM_AB8500)+= pwm-ab8500.o
  obj-$(CONFIG_PWM_ATMEL)   += pwm-atmel.o
  obj-$(CONFIG_PWM_ATMEL_HLCDC_PWM) += pwm-atmel-hlcdc.o
  obj-$(CONFIG_PWM_ATMEL_TCB)   += pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM_IPROC)+= pwm-bcm-iproc.o
  obj-$(CONFIG_PWM_BCM_KONA)+= pwm-bcm-kona.o
  obj-$(CONFIG_PWM_BCM2835) += pwm-bcm2835.o
  obj-$(CONFIG_PWM_BERLIN)  += pwm-berlin.o
diff --git a/drivers/pwm/pwm-bcm-iproc.c b/drivers/pwm/pwm-bcm-iproc.c
new file mode 100644
index 000..952c457
--- /dev/null
+++ b/drivers/pwm/pwm-bcm-iproc.c
@@ -0,0 +1,327 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IPROC_PWM_CTRL_OFFSET  (0x00)
+#define IPROC_PWM_CTRL_TYPE_SHIFT(chan)(15 + (chan))
+#define IPROC_PWM_CTRL_POLARITY_SHIFT(chan)(8 + (chan))
+#define IPROC_PWM_CTRL_EN_SHIFT(chan)  (chan)
+
+#define IPROC_PWM_PERIOD_OFFSET(chan)  (0x04 + ((chan) << 3))
+#define IPROC_PWM_PERIOD_MIN   (0x02)
+#define IPROC_PWM_PERIOD_MAX   (0x)
+
+#define IPROC_PWM_DUTY_CYCLE_OFFSET(chan)  (0x08 + ((chan) << 3))
+#define IPROC_PWM_DUTY_CYCLE_MIN   (0x00)
+#define IPROC_PWM_DUTY_CYCLE_MAX   (0x)
+
+#define IPROC_PWM_PRESCALE_OFFSET  (0x24)
+#define IPROC_PWM_PRESCALE_BITS(0x06)
+#define IPROC_PWM_PRESCALE_SHIFT(chan) ((3 - (chan)) * \
+   IPROC_PWM_PRESCALE_BITS)
+#define IPROC_PWM_PRESCALE_MASK(chan)  (IPROC_PWM_PRESCALE_MAX << \
+   IPROC_PWM_PRESCALE_SHIFT(chan))
+#define IPROC_PWM_PRESCALE_MIN (0x00)
+#define IPROC_PWM_PRESCALE_MAX (0x3f)
+
+#define IPROC_PWM_CHANNEL_COUNT(0x04)
+
+struct iproc_pwmc {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct iproc_pwmc *to_iproc_pwmc(struct pwm_chip *_chip)
+{
+   return container_of(_chip, struct iproc_pwmc, chip);
+}
+
+static void iproc_pwmc_unset_enable_bit(struct iproc_pwmc *ip, u32 chan)
+{
+   unsigned int value = readl(ip->base + IPROC_PWM_CTRL_OFFSET);
+
+   value &= ~(1 << IPROC_PWM_CTRL_EN_SHIFT(chan));
+   writel(value, ip->base + IPROC_PWM_CTRL_OFFSET);
+
+   /*
+* There must be a min 400ns delay between clearing trigger and setting
+* it. Failing to do this may result in no PWM signal.
+*/
+   ndelay(400);
+}
+
+static void iproc_pwmc_set_enable_bit(struct iproc_pwmc *ip, unsigned int chan)
+{
+   unsigned int value = readl(ip->base + IPROC_PWM_CTRL_OFFSET);
+
+   /* Set trigger bit to apply new settings */
+   value |= 1 << IPROC_PWM_CTRL_EN_SHIFT(chan);
+   writel(value, ip->base + IPROC_PWM_CTRL_OFF

Re: [PATCH 4/8] ARM: dts: bcm283x: Add a new EMMC pin group from the downstream tree.

[Scott Branden]

Hi Gerd/Eric

On 16-09-08 12:44 AM, Gerd Hoffmann wrote:

On Mi, 2016-09-07 at 20:13 +0200, Stefan Wahren wrote:

Gerd Hoffmann  hat am 7. September 2016 um 12:31
geschrieben:


From: Eric Anholt 

This will be used for having EMMC (sdhci-bcm2835.c) drive the
wireless.


sdhci-bcm2835.c has been replaced by sdhci-iproc.c


Ah, right, I'll update the commit msg for v2.


Should we entirely remove sdhci-bcm2835.c to reduce confusion going forward?


How about adding pull defines to include/dt-bindings/pinctrl/bcm2835.h?


Already there (or do you mean something other than '#define
BCM2835_FSEL_*' ?)

cheers,
  Gerd



Thanks,
 Scott

Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only

[Scott Branden]

Hi Bjorn,

Ray is off this week and will likely have some comments next week.

On 16-08-24 10:54 AM, Bjorn Helgaas wrote:

[+cc Ray, Scott, Jon, bcm-kernel-feedback-list]

On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote:

On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas  wrote:

On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote:

Altera PCIe IP can be configured as rootport or device and they might have
same vendor ID. It will cause the system hang issue if Altera PCIe is in
endpoint mode and work with other PCIe rootport that from other vendors.
So, add the rootport mode checking in link retrain fixup function.

Signed-off-by: Ley Foon Tan 
---
v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT
---
 drivers/pci/host/pcie-altera.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
index 58eef99..33b6968 100644
--- a/drivers/pci/host/pcie-altera.c
+++ b/drivers/pci/host/pcie-altera.c
@@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev)
  u16 linkcap, linkstat;
  struct altera_pcie *pcie = dev->bus->sysdata;

+ if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
+ return;
+
  if (!altera_pcie_link_is_up(pcie))
  return;


Instead of making this a PCI fixup, can you make an
altera_pcie_host_init() function, call it from altera_pcie_probe(),
and do the link retrain there?  Then you wouldn't need to worry about
whether this is a Root Port or an Endpoint, plus it would make the
altera driver structure more like the other drivers.

You would call altera_pcie_host_init() before pci_scan_root_bus(), so
you wouldn't have a pci_dev yet, so you wouldn't be able to use
pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit.  But I
assume there's some device-dependent way to access it using
cra_writel()?

We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit.


Why not?  I don't mean it has to be cra_write(), but isn't there some
way you can write that bit before we scan the root bus?  It doesn't
make sense that we have to scan the bus before we can train the link.

We want to be able to tell the PCI core "all the device-specific root
complex initialization has been done, here are the config accessors
you need, please scan for devices."  I want to keep device-specific
things like this quirk directly in the driver and out of the
enumeration process.


We can use
pci_bus_find_capability() and pci_bus_read_config_word() with struct
pci_bus instead.
But this only can be called after pci_scan_root_bus().



Found
iproc_pcie_check_link() have similar implementation.


You're right, and I don't like iproc_pcie_check_link() either, for the
same reasons.

The iproc_pcie_check_link() is a little better because it's called
before enumeration:

  pci_create_root_bus()
  iproc_pcie_check_link()
  pci_scan_child_bus()

But it would be a lot better if iproc_pcie_check_link() were done
first, before pci_create_root_bus().  Then it would be more like the
structure of other drivers, and we could use pci_scan_root_bus()
instead.

Comments, iproc folks?

Bjorn



Regards,
 Scott

[PATCH 2/3] w1: d1w: Provide callback for ds1wm read/write

[Scott Branden]

From: Shreesha Rajashekar 

DS1WM core registers are accessed by reading from and writing to a group of
registers in iproc SOC's.

By default the read and write function uses
__raw_readb() and __raw_writeb(), which wouldnt work for iproc.
hence modifying to provide callbacks for read and write functions.

Signed-off-by: Shreesha Rajashekar 
Signed-off-by: Scott Branden 
---
 drivers/w1/masters/ds1wm.c | 18 --
 include/linux/mfd/ds1wm.h  |  2 ++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/w1/masters/ds1wm.c b/drivers/w1/masters/ds1wm.c
index fd2e9da..9fadc39 100644
--- a/drivers/w1/masters/ds1wm.c
+++ b/drivers/w1/masters/ds1wm.c
@@ -115,12 +115,26 @@ struct ds1wm_data {
 static inline void ds1wm_write_register(struct ds1wm_data *ds1wm_data, u32 reg,
u8 val)
 {
-   __raw_writeb(val, ds1wm_data->map + (reg << ds1wm_data->bus_shift));
+   struct device *dev = &ds1wm_data->pdev->dev;
+   struct ds1wm_driver_data *pdata = dev_get_platdata(dev);
+
+   if (pdata->write)
+   pdata->write(ds1wm_data->map, reg, val);
+   else
+   __raw_writeb(val, ds1wm_data->map +
+   (reg << ds1wm_data->bus_shift));
 }
 
 static inline u8 ds1wm_read_register(struct ds1wm_data *ds1wm_data, u32 reg)
 {
-   return __raw_readb(ds1wm_data->map + (reg << ds1wm_data->bus_shift));
+   struct device *dev = &ds1wm_data->pdev->dev;
+   struct ds1wm_driver_data *pdata = dev_get_platdata(dev);
+
+   if (pdata->read)
+   return pdata->read(ds1wm_data->map, reg);
+   else
+   return __raw_readb(ds1wm_data->map +
+   (reg << ds1wm_data->bus_shift));
 }
 
 
diff --git a/include/linux/mfd/ds1wm.h b/include/linux/mfd/ds1wm.h
index 38a372a..c2d41d3 100644
--- a/include/linux/mfd/ds1wm.h
+++ b/include/linux/mfd/ds1wm.h
@@ -10,4 +10,6 @@ struct ds1wm_driver_data {
/* ds1wm implements the precise timings of*/
/* a reset pulse/presence detect sequence.*/
unsigned int reset_recover_delay;
+   void (*write)(void __iomem *map, u32 reg, u8 val);
+   u8 (*read)(void __iomem *map, u32 reg);
 };
-- 
2.5.0

[PATCH 1/3] dt-bindings: mfd: d1w: iproc: Documentation for d1w driver

[Scott Branden]

From: Shreesha Rajashekar 

Adding document for IPROC d1w driver.

Signed-off-by: Shreesha Rajashekar 
Signed-off-by: Scott Branden 
---
 .../devicetree/bindings/mfd/brcm,iproc-d1w.txt | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt

diff --git a/Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt 
b/Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt
new file mode 100644
index 000..2bb99c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt
@@ -0,0 +1,27 @@
+* Broadcom Dallas One wire (D1W) bus master controller
+
+Required properties:
+- compatible : should be "brcm,iproc-d1w"
+- reg : Address and length of the register set for the device
+- interrupts : IRQ number of D1W controller
+
+Optional properties:
+- clocks : phandle of clock that supplies the module (required if platform
+   clock bindings use device tree)
+- clock-names : name for the clock
+- clock-frequency : D1W divisor clock rate
+- reset-recover-delay : Delay while reset D1W in milliseconds.
+
+Example:
+
+- From bcm-cygnus.dtsi:
+iproc_d1w: d1w@180ab000 {
+   compatible = "brcm,iproc_d1w";
+   reg = <0x180ab000 0x0f>;
+   interrupts = ;
+   clocks = <&axi81_clk>;
+   clock-names = "iproc_d1w_clk";
+   clock-frequency = <1>;
+   reset-recover-delay = <1>;
+};
+
-- 
2.5.0

[PATCH 0/3] Add Support for Broadcom D1W controller

[Scott Branden]

Add support for Broadcom Dallas One wire (D1W) bus master controller.

This patch series adds a callback for the ds1wm read/write functions
to the common DS1W driver code and the Broadcom specific DS1W controller.

Shreesha Rajashekar (3):
  dt-bindings: mfd: d1w: iproc: Documentation for d1w driver
  w1: d1w: Provide callback for ds1wm read/write
  mfd: d1w: iproc: Add d1w driver

 .../devicetree/bindings/mfd/brcm,iproc-d1w.txt |  27 +++
 drivers/mfd/Kconfig|  11 ++
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/bcm-iproc-d1w.c| 202 +
 drivers/w1/masters/ds1wm.c |  18 +-
 include/linux/mfd/ds1wm.h  |   2 +
 6 files changed, 259 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt
 create mode 100644 drivers/mfd/bcm-iproc-d1w.c

-- 
2.5.0

[PATCH 3/3] mfd: d1w: iproc: Add d1w driver

[Scott Branden]

From: Shreesha Rajashekar 

d1w bus master controller is added as a mfd node.
ds1wm driver is hooked to this node through the mfd framework.

Signed-off-by: Shreesha Rajashekar 
Signed-off-by: Scott Branden 
---
 drivers/mfd/Kconfig |  11 +++
 drivers/mfd/Makefile|   1 +
 drivers/mfd/bcm-iproc-d1w.c | 202 
 3 files changed, 214 insertions(+)
 create mode 100644 drivers/mfd/bcm-iproc-d1w.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1..a7d9335 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -216,6 +216,17 @@ config MFD_ASIC3
  This driver supports the ASIC3 multifunction chip found on many
  PDAs (mainly iPAQ and HTC based ones)
 
+config MFD_IPROC_D1W
+   bool "IPROC DS1WM one wire interface"
+   depends on (ARCH_BCM_IPROC || COMPILE_TEST)
+   select MFD_CORE
+   default ARCH_BCM_IPROC
+   help
+ This driver provides support to the Dallas One Wire (D1W).This block
+ is found in various Broadcom iProc family of SoCs.
+ The Cygnus Dallas 1-Wire Interface provides complete
+ control of the 1-Wire bus through 8-bit commands.
+
 config PMIC_DA903X
bool "Dialog Semiconductor DA9030/DA9034 PMIC Support"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b..2f39fdd 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -217,6 +217,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o
 obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o
 obj-$(CONFIG_MFD_MT6397)   += mt6397-core.o
+obj-$(CONFIG_MFD_IPROC_D1W)+= bcm-iproc-d1w.o
 
 obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
 obj-$(CONFIG_MFD_SUN4I_GPADC)  += sun4i-gpadc.o
diff --git a/drivers/mfd/bcm-iproc-d1w.c b/drivers/mfd/bcm-iproc-d1w.c
new file mode 100644
index 000..d439060
--- /dev/null
+++ b/drivers/mfd/bcm-iproc-d1w.c
@@ -0,0 +1,202 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define D1W_DIN_OFFSET  0x00
+#define D1W_DOUT_OFFSET 0x04
+#define D1W_ADDR_OFFSET 0x08
+#define D1W_CTRL_OFFSET 0x0C
+
+#define WRITE_CMD 0x3
+#define READ_CMD 0x2
+
+#define DEFAULT_RESET_RECOVERY_DELAY   1
+/* CLOCK_RATE programmed in the IP divisor register DS1WM_CLKDIV*/
+#define DEFAULT_CLOCK_RATE 1
+
+struct iproc_ds1wm_core {
+   struct ds1wm_driver_data plat_data;
+   struct clk *ds1wm_clk;
+};
+
+static void iproc_d1w_write_register(void __iomem *base, u32 reg,
+   u8 val)
+{
+   writel(val, base + D1W_DIN_OFFSET);
+   writel(reg, base + D1W_ADDR_OFFSET);
+   writel(WRITE_CMD, base + D1W_CTRL_OFFSET);
+}
+
+static u8 iproc_d1w_read_register(void __iomem *base, u32 reg)
+{
+   writel(reg, base + D1W_ADDR_OFFSET);
+   writel(READ_CMD, base + D1W_CTRL_OFFSET);
+   return readb(base + D1W_DOUT_OFFSET);
+}
+
+static int iproc_ds1wm_enable(struct platform_device *pdev)
+{
+   struct iproc_ds1wm_core *ds1wm_core;
+
+   ds1wm_core = dev_get_drvdata(pdev->dev.parent);
+   dev_dbg(&pdev->dev, "%s\n", __func__);
+
+   if (ds1wm_core->ds1wm_clk)
+   return clk_prepare_enable(ds1wm_core->ds1wm_clk);
+
+   return 0;
+}
+
+static int iproc_ds1wm_disable(struct platform_device *pdev)
+{
+   struct iproc_ds1wm_core *ds1wm_core;
+
+   ds1wm_core = dev_get_drvdata(pdev->dev.parent);
+   dev_dbg(&pdev->dev, "%s\n", __func__);
+   if (ds1wm_core->ds1wm_clk)
+   clk_disable_unprepare(ds1wm_core->ds1wm_clk);
+
+   return 0;
+}
+
+static struct resource iproc_ds1wm_resources[] = {
+   [0] = {
+   .flags = IORESOURCE_MEM,
+   },
+   [1] = {
+   .flags = IORESOURCE_IRQ,
+   }
+};
+
+static struct mfd_cell iproc_ds1wm_mfd_cell = {
+   .name  = "ds1wm",
+   .enable= iproc_ds1wm_enable,
+   .disable   = iproc_ds1wm_disable,
+   .num_resources = ARRAY_SIZE(iproc_ds1wm_resources),
+   .resources = iproc_ds1wm_resources,
+};
+
+static int iproc_d1w_dt_binding(struct platform_device *pdev,
+   struct iproc_ds1wm_core *ds1wm_core)
+{
+   int ret;
+
+   ret = of_property_read_u32(pdev->dev.of_node,
+ 

Re: [PATCH 3/3] mfd: d1w: iproc: Add d1w driver

[Scott Branden]

Hi Lee,


On 17-08-17 03:02 AM, Lee Jones wrote:

On Wed, 16 Aug 2017, Scott Branden wrote:


From: Shreesha Rajashekar 

d1w bus master controller is added as a mfd node.

Why?


ds1wm driver is hooked to this node through the mfd framework.

Why?

It looks like it was added under mfd as htc-pasic3.c is there
(other than htc-pasic3.c is and mfd due to gpio nodes).

Yes, bcm-iproc-d1w should move under w1 directory.


What makes this an MFD device?


Signed-off-by: Shreesha Rajashekar 
Signed-off-by: Scott Branden 
---
  drivers/mfd/Kconfig |  11 +++
  drivers/mfd/Makefile|   1 +
  drivers/mfd/bcm-iproc-d1w.c | 202 
  3 files changed, 214 insertions(+)
  create mode 100644 drivers/mfd/bcm-iproc-d1w.c

Re: [PATCH 1/3] dt-bindings: mfd: d1w: iproc: Documentation for d1w driver

[Scott Branden]

Thanks for review Rob


On 17-08-16 01:45 PM, Rob Herring wrote:

On Wed, Aug 16, 2017 at 12:45 PM, Scott Branden
 wrote:

From: Shreesha Rajashekar 

Adding document for IPROC d1w driver.

Signed-off-by: Shreesha Rajashekar 
Signed-off-by: Scott Branden 
---
  .../devicetree/bindings/mfd/brcm,iproc-d1w.txt | 27 ++
  1 file changed, 27 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt

How is this an MFD? Should be bindings/w1/...


diff --git a/Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt 
b/Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt
new file mode 100644
index 000..2bb99c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/brcm,iproc-d1w.txt
@@ -0,0 +1,27 @@
+* Broadcom Dallas One wire (D1W) bus master controller
+
+Required properties:
+- compatible : should be "brcm,iproc-d1w"
+- reg : Address and length of the register set for the device
+- interrupts : IRQ number of D1W controller
+
+Optional properties:
+- clocks : phandle of clock that supplies the module (required if platform
+   clock bindings use device tree)
+- clock-names : name for the clock
+- clock-frequency : D1W divisor clock rate

This should be bus-frequency. We messed up on I2C.


+- reset-recover-delay : Delay while reset D1W in milliseconds.

Is this a standard 1-wire bus operation? I'm guessing so, but if not
needs a vendor prefix.

Also, needs unit suffix as defined in property-units.txt.


+
+Example:
+
+- From bcm-cygnus.dtsi:
+iproc_d1w: d1w@180ab000 {

Should be a generic name. So far in bindings/w1/ we have 3 different
ones in 3 bindings. Lets go with "onewire".


+   compatible = "brcm,iproc_d1w";

Doesn't match the doc.
We have some cleanup work to do.  Need to move to mfd and address your 
comments.



+   reg = <0x180ab000 0x0f>;
+   interrupts = ;
+   clocks = <&axi81_clk>;
+   clock-names = "iproc_d1w_clk";
+   clock-frequency = <1>;
+   reset-recover-delay = <1>;
+};
+
--
2.5.0

Re: [PATCH v1 1/2] dt-binding: ptp: add bindings document for dte based ptp clock

[Scott Branden]

Hi Rob,


On 17-06-18 07:04 AM, Rob Herring wrote:

On Mon, Jun 12, 2017 at 01:26:00PM -0700, Arun Parameswaran wrote:

Add device tree binding documentation for the Broadcom DTE
PTP clock driver.

Signed-off-by: Arun Parameswaran 
---
  Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt | 13 +
  1 file changed, 13 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt

diff --git a/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt 
b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
new file mode 100644
index 000..07590bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/ptp/brcm,ptp-dte.txt
@@ -0,0 +1,13 @@
+* Broadcom Digital Timing Engine(DTE) based PTP clock driver

Bindings describe h/w, not drivers.


+
+Required properties:
+- compatible: should be "brcm,ptp-dte"

Looks too generic. You need SoC specific compatible strings.


Rob, could you please help me understand the use of adding SoC specific 
compatible strings.

I still don't get it.

It's my understanding that the SoC compatibility string is to future 
proof against bugs/incompatibilities
between different versions of the hardware block due to integration 
issues or any other reason.
You can then compare in your driver because the strings were already 
used in the dtb.


That would make sense if you can't already differentiate what SoC you 
are running on.
But the SoC is already specified in the root of the device tree in the 
compatible string?
Why can't you just use of_machine_is_compatible inside your driver when 
needed?


Please explain what I'm missing.  I see other drivers already following 
the of_machine_is_compatible
approach and it makes more sense to me than adding SoC specific 
compatible strings into every

driver.

Regards,
 Scott

Re: [PATCH v3 2/3] thermal: broadcom: ns-thermal: default on iProc SoCs

[Scott Branden]

Hi Jon,


On 17-04-28 01:50 PM, Jon Mason wrote:

On Fri, Apr 28, 2017 at 4:36 PM, Scott Branden
 wrote:


On 17-04-28 01:11 PM, Jon Mason wrote:

Tweak the Kconfig description to mention support for NSP and make the
default on for iProc based platforms.

Signed-off-by: Jon Mason 
---
  drivers/thermal/broadcom/Kconfig | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/thermal/broadcom/Kconfig
b/drivers/thermal/broadcom/Kconfig
index f0dea8a..b6f4b85 100644
--- a/drivers/thermal/broadcom/Kconfig
+++ b/drivers/thermal/broadcom/Kconfig
@@ -1,8 +1,9 @@
  config BCM_NS_THERMAL
 tristate "Northstar thermal driver"
 depends on ARCH_BCM_IPROC || COMPILE_TEST

If this driver is used on these SoCs then it:
depends on ARCH_BCM_NSP || ARCH_BCM_5301X || COMPILE_TEST
?

The code referenced is outside of this patch, as that code was already
existing from when the driver was submitted.

I did some checking and NS2 and Cygnus do not have the registers in
use by this driver.  So, you are correct in that this driver will
never be used for them.  So, this is slightly over-permissive in
allowing a driver to be selected that could not ever be used on
non-NS/NSP hardware.  But barring an incorrect DT string, it would
only result in an slightly larger kernel than necessary.

I'll do a follow-on patch to correct this with your suggestion above,
and push it separately (unless a v4 is needed on this series).


Please submit the follow on patch.



Thanks,
Jon

Thanks,
 Scott

Re: [PATCH 3/3] pinctrl: bcm: clean up modular vs. non-modular distinctions

[Scott Branden]

Hi Linus,


On 17-05-29 01:31 AM, Linus Walleij wrote:

On Mon, May 22, 2017 at 10:56 PM, Paul Gortmaker
 wrote:


Fixups here tend to be more of a conglomerate of some of the other
repeated/systematic ones we've seen in the earlier pinctrl cleanups.

We remove module.h from code that isn't doing anything modular at
all;  if they have __init sections, then replace it with init.h

One driver has a .remove that would be dispatched on module_exit,
and as that code is essentially orphaned, so we remove it.  In case
anyone was previously doing the (pointless) unbind to get to that
function, we disable unbind for this one driver as well.

A couple bool drivers (hence non-modular) are converted over to
to builtin_platform_driver().

Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.

We also delete the MODULE_LICENSE tag etc. since all that information
was (or is now) contained at the top of the file in the comments.

Cc: Eric Anholt 
Cc: Florian Fainelli 
Cc: Jon Mason 
Cc: Linus Walleij 
Cc: Ray Jui 
Cc: Scott Branden 
Cc: Stefan Wahren 
Cc: Sherman Yin 
Cc: bcm-kernel-feedback-l...@broadcom.com
Cc: linux-g...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Signed-off-by: Paul Gortmaker 

Patch applied with Stefan Wahren's Tested-by tag.

I can't take header standardization into account, header files are not
ABI, further see
Documentation/process/stable-api-nonsense.rst
It is a simple ask to place the new information in a new comment after 
the legal header.


An aim at consistency helps reduce confusion (internal and external)
of what license header template to apply to files.  Modifying these 
headers and placing

information in the middle of them does not help in this effort.


Yours,
Linus Walleij

Regards,
Scott

Re: [RFC PATCH v2] pci: Concurrency issue in NVMe Init through PCIe switch

[Scott Branden]

Hi Srinath,


On 17-05-30 02:08 AM, Srinath Mannam wrote:

We found a concurrency issue in NVMe Init when we initialize
multiple NVMe connected over PCIe switch.

Setup details:
  - SMP system with 8 ARMv8 cores running Linux kernel(4.11).
  - Two NVMe cards are connected to PCIe RC through bridge as shown
in the below figure.

[RC]
 |
  [BRIDGE]
 |
---
   |   |
 [NVMe]  [NVMe]

Issue description:
After PCIe enumeration completed NVMe driver probe function called
for both the devices from two CPUS simultaneously.
 From nvme_probe, pci_enable_device_mem called for both the EPs. This
function called pci_enable_bridge enable recursively until RC.

Inside pci_enable_bridge function, at two places concurrency issue is
observed.

Place 1:
   CPU 0:
 1. Done Atomic increment dev->enable_cnt
in pci_enable_device_flags
 2. Inside pci_enable_resources
 3. Completed pci_read_config_word(dev, PCI_COMMAND, &cmd)
 4. Ready to set PCI_COMMAND_MEMORY (0x2) in
pci_write_config_word(dev, PCI_COMMAND, cmd)
   CPU 1:
 1. Check pci_is_enabled in function pci_enable_bridge
and it is true
 2. Check (!dev->is_busmaster) also true
 3. Gone into pci_set_master
 4. Completed pci_read_config_word(dev, PCI_COMMAND, &old_cmd)
 5. Ready to set PCI_COMMAND_MASTER (0x4) in
pci_write_config_word(dev, PCI_COMMAND, cmd)

By the time of last point for both the CPUs are read value 0 and
ready to write 2 and 4.
After last point final value in PCI_COMMAND register is 4 instead of 6.

Place 2:
   CPU 0:
 1. Done Atomic increment dev->enable_cnt in
pci_enable_device_flags

Signed-off-by: Srinath Mannam 
---
Changes since v1:
  - Used mutex to syncronize pci_enable_bridge

  drivers/pci/pci.c   | 4 
  drivers/pci/probe.c | 1 +
  include/linux/pci.h | 1 +
  3 files changed, 6 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b01bd5b..5bff3e7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1347,7 +1347,9 @@ static void pci_enable_bridge(struct pci_dev *dev)
  {
struct pci_dev *bridge;
int retval;
+   struct mutex *lock = &dev->bridge_lock;
  
+	mutex_lock(lock);

bridge = pci_upstream_bridge(dev);
if (bridge)
pci_enable_bridge(bridge);
@@ -1355,6 +1357,7 @@ static void pci_enable_bridge(struct pci_dev *dev)
if (pci_is_enabled(dev)) {
if (!dev->is_busmaster)
pci_set_master(dev);
+   mutex_unlock(lock);
return;
}
  
@@ -1363,6 +1366,7 @@ static void pci_enable_bridge(struct pci_dev *dev)

dev_err(&dev->dev, "Error enabling bridge (%d), continuing\n",
retval);
pci_set_master(dev);
+   mutex_unlock(lock);
  }
Looking at above function I think it should be restructured so that 
mute_unlock only needs to be called in one place.

How about below to make things more clear?

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 563901c..82c232e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1347,22 +1347,29 @@ static void pci_enable_bridge(struct pci_dev *dev)
 {
struct pci_dev *bridge;
int retval;
+   struct mutex *lock = &dev->bridge_lock;
+
+   /*
+* Add comment here explaining what needs concurrency protection
+*/
+   mutex_lock(lock);

bridge = pci_upstream_bridge(dev);
if (bridge)
pci_enable_bridge(bridge);

-   if (pci_is_enabled(dev)) {
-   if (!dev->is_busmaster)
-   pci_set_master(dev);
-   return;
+   if (!pci_is_enabled(dev)) {
+   retval = pci_enable_device(dev);
+   if (retval)
+   dev_err(&dev->dev,
+   "Error enabling bridge (%d), continuing\n",
+   retval);
}

-   retval = pci_enable_device(dev);
-   if (retval)
-   dev_err(&dev->dev, "Error enabling bridge (%d), 
continuing\n",

-   retval);
-   pci_set_master(dev);
+   if (!dev->is_busmaster)
+   pci_set_master(dev);
+
+   mutex_unlock(lock);
 }

  
  static int pci_enable_device_flags(struct pci_dev *dev, unsigned long flags)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 19c8950..1c25d1c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -880,6 +880,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus 
*parent,
child->dev.parent = child->bridge;
pci_set_bus_of_node(child);
pci_set_bus_speed(child);
+   mutex_init(&bridge->bridge_lock);
  
  	/* Set up default resource pointers and names.. */

for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; i++) {
diff --git a/include/linux/pci.h

Re: [RFC PATCH v2] pci: Concurrency issue in NVMe Init through PCIe switch

[Scott Branden]

Hi Ray,


On 17-05-30 10:04 AM, Ray Jui wrote:

Hi Srinath and Scott,

On 5/30/17 8:44 AM, Scott Branden wrote:

Hi Srinath,


On 17-05-30 02:08 AM, Srinath Mannam wrote:

We found a concurrency issue in NVMe Init when we initialize
multiple NVMe connected over PCIe switch.

Setup details:
   - SMP system with 8 ARMv8 cores running Linux kernel(4.11).
   - Two NVMe cards are connected to PCIe RC through bridge as shown
 in the below figure.

 [RC]
  |
   [BRIDGE]
  |
 ---
|   |
  [NVMe]  [NVMe]

Issue description:
After PCIe enumeration completed NVMe driver probe function called
for both the devices from two CPUS simultaneously.
  From nvme_probe, pci_enable_device_mem called for both the EPs. This
function called pci_enable_bridge enable recursively until RC.

Inside pci_enable_bridge function, at two places concurrency issue is
observed.

Place 1:
CPU 0:
  1. Done Atomic increment dev->enable_cnt
 in pci_enable_device_flags
  2. Inside pci_enable_resources
  3. Completed pci_read_config_word(dev, PCI_COMMAND, &cmd)
  4. Ready to set PCI_COMMAND_MEMORY (0x2) in
 pci_write_config_word(dev, PCI_COMMAND, cmd)
CPU 1:
  1. Check pci_is_enabled in function pci_enable_bridge
 and it is true
  2. Check (!dev->is_busmaster) also true
  3. Gone into pci_set_master
  4. Completed pci_read_config_word(dev, PCI_COMMAND, &old_cmd)
  5. Ready to set PCI_COMMAND_MASTER (0x4) in
 pci_write_config_word(dev, PCI_COMMAND, cmd)

By the time of last point for both the CPUs are read value 0 and
ready to write 2 and 4.
After last point final value in PCI_COMMAND register is 4 instead of 6.

Place 2:
CPU 0:
  1. Done Atomic increment dev->enable_cnt in
 pci_enable_device_flags

Signed-off-by: Srinath Mannam 
---
Changes since v1:
   - Used mutex to syncronize pci_enable_bridge

   drivers/pci/pci.c   | 4 
   drivers/pci/probe.c | 1 +
   include/linux/pci.h | 1 +
   3 files changed, 6 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b01bd5b..5bff3e7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1347,7 +1347,9 @@ static void pci_enable_bridge(struct pci_dev *dev)
   {
   struct pci_dev *bridge;
   int retval;
+struct mutex *lock = &dev->bridge_lock;
   +mutex_lock(lock);
   bridge = pci_upstream_bridge(dev);
   if (bridge)
   pci_enable_bridge(bridge);
@@ -1355,6 +1357,7 @@ static void pci_enable_bridge(struct pci_dev *dev)
   if (pci_is_enabled(dev)) {
   if (!dev->is_busmaster)
   pci_set_master(dev);
+mutex_unlock(lock);
   return;
   }
   @@ -1363,6 +1366,7 @@ static void pci_enable_bridge(struct pci_dev
*dev)
   dev_err(&dev->dev, "Error enabling bridge (%d), continuing\n",
   retval);
   pci_set_master(dev);
+mutex_unlock(lock);
   }

Looking at above function I think it should be restructured so that
mute_unlock only needs to be called in one place.
How about below to make things more clear?

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 563901c..82c232e 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1347,22 +1347,29 @@ static void pci_enable_bridge(struct pci_dev *dev)
  {
 struct pci_dev *bridge;
 int retval;
+   struct mutex *lock = &dev->bridge_lock;

First of all, using a proper lock for this was proposed during the
internal review. The idea was dismissed with concern that a dead lock
can happen since the call to pci_enable_bridge is recursive.

I'm glad that we are now still using the lock to properly fix the
problem by realizing that the lock is specific to the bridge itself and
the recursive call to upstream bridge does not cause a deadlock since a
different lock is used.


+
+   /*
+* Add comment here explaining what needs concurrency protection
+*/
+   mutex_lock(lock);

 bridge = pci_upstream_bridge(dev);
 if (bridge)
 pci_enable_bridge(bridge);

-   if (pci_is_enabled(dev)) {
-   if (!dev->is_busmaster)
-   pci_set_master(dev);
-   return;
+   if (!pci_is_enabled(dev)) {
+   retval = pci_enable_device(dev);
+   if (retval)
+   dev_err(&dev->dev,
+   "Error enabling bridge (%d), continuing\n",
+   retval);
 }

-   retval = pci_enable_device(dev);
-   if (retval)
-   dev_err(&dev->dev, "Error enabling bridge (%d),
continuing\n",
-   retval);
-   pci_set_master(dev);
+   if (!dev->is_busmaster)
+   pci_set_master(dev);
+
+   

Re: [PATCH 0/2] hwrng: iproc-rng200: Add support for BCM7278

[Scott Branden]

Patch series looks fine.


On 17-11-01 04:20 PM, Florian Fainelli wrote:

Hi,

This patch series adds support for the RNG200 block found on the BCM7278 SoC.
This requires us to update the compatible string (and associated binding
document) as well as the Kconfig option to make that driver selectable with
ARCH_BRCMSTB gating the enabling of such SoCs.

Thank you

Florian Fainelli (2):
   dt-bindings: rng: Document BCM7278 RNG200 compatible
   hwrng: iproc-rng200: Add support for BCM7278

  Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt | 4 +++-
  drivers/char/hw_random/Kconfig  | 6 +++---
  drivers/char/hw_random/iproc-rng200.c   | 1 +
  3 files changed, 7 insertions(+), 4 deletions(-)


Acked-by: Scott Branden 

Re: [PATCH 6/8] PCI: host: brcmstb: add MSI capability

[Scott Branden]

Hi Bjorn,


On 17-10-25 10:23 AM, Bjorn Helgaas wrote:

[+cc Ray, Scott, Jon]

On Wed, Oct 25, 2017 at 11:28:07AM -0400, Jim Quinlan wrote:

On Tue, Oct 24, 2017 at 2:57 PM, Florian Fainelli  wrote:

Hi Jim,

On 10/24/2017 11:15 AM, Jim Quinlan wrote:

This commit adds MSI to the Broadcom STB PCIe host controller. It does
not add MSIX since that functionality is not in the HW.  The MSI
controller is physically located within the PCIe block, however, there
is no reason why the MSI controller could not be moved elsewhere in
the future.

Since the internal Brcmstb MSI controller is intertwined with the PCIe
controller, it is not its own platform device but rather part of the
PCIe platform device.

Signed-off-by: Jim Quinlan 
---
  drivers/pci/host/Kconfig   |  12 ++
  drivers/pci/host/Makefile  |   1 +
  drivers/pci/host/pci-brcmstb-msi.c | 318 +
  drivers/pci/host/pci-brcmstb.c |  72 +++--
  drivers/pci/host/pci-brcmstb.h |  26 +++
  5 files changed, 419 insertions(+), 10 deletions(-)
  create mode 100644 drivers/pci/host/pci-brcmstb-msi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index b9b4f11..54aa5d2 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -228,4 +228,16 @@ config PCI_BRCMSTB
   default ARCH_BRCMSTB || BMIPS_GENERIC
   help
 Adds support for Broadcom Settop Box PCIe host controller.
+   To compile this driver as a module, choose m here.
+
+config PCI_BRCMSTB_MSI
+ bool "Broadcom Brcmstb PCIe MSI support"
+ depends on ARCH_BRCMSTB || BMIPS_GENERIC

This could probably be depends on PCI_BRCMSTB, which would imply these
two conditions. PCI_BRCMSTB_MSI on its own is probably not very useful
without the parent RC driver.


+ depends on OF
+ depends on PCI_MSI
+ default PCI_BRCMSTB
+ help
+   Say Y here if you want to enable MSI support for Broadcom's iProc
+   PCIe controller
+
  endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index c283321..1026d6f 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
  obj-$(CONFIG_VMD) += vmd.o
  obj-$(CONFIG_PCI_BRCMSTB) += brcmstb-pci.o
  brcmstb-pci-objs := pci-brcmstb.o pci-brcmstb-dma.o
+obj-$(CONFIG_PCI_BRCMSTB_MSI) += pci-brcmstb-msi.o

Should we combine this file with the brcmstb-pci.o? There is probably no
functional difference, except that pci-brcmstb-msi.ko needs to be loaded
first, right?
--
Florian

If you look at the pci/host/Kconfig you will see that other drivers
also have a separate MSI config (eg iproc, altera, xgene) so there is
precedent.  The reason that pci-brcmstb-msi.c is its own file is
because it depends on an irq function that is not exported.  That is
why CONFIG_PCI_BRCMSTB_MSI is bool, and CONFIG_PCI_BRCMSTB is
tristate.  -- Jim

There is precedent, but that doesn't mean I like it :)
I would strongly prefer one file per driver when possible.

Take iproc for example.  iproc-msi.c is enabled by a Kconfig bool.  It
contains a bunch of code with the only external entry points being
iproc_msi_init() and iproc_msi_exit().  These are only called via
iproc_pcie_bcma_probe() or iproc_pcie_pltfm_probe(), both of which are
tristate.  So iproc-msi.c is only compiled if CONFIG_IPROC_BCMA or
CONFIG_IPROC_PLATFORM are enabled, but all that text is loaded even if
neither module is loaded, which seems suboptimal.

I don't care if you have several config options to enable the BCMA
probe and the platform probe (although these could probably be
replaced in the code by a simple "#ifdef CONFIG_BCMA" and "#ifdef
CONFIG_OF"), and making CONFIG_PCIE_IPROC tristate so it can be a
module makes sense.  But I think it would be better to put all the
code in one file instead of five, and probably remove
CONFIG_PCIE_IPROC_MSI.  Maybe this requires exporting some IRQ
function that currently isn't exported.  But that seems like a simpler
solution than what we currently have.
Placing pcie-iproc-bcma.c in its own file is useful in being able to 
read the code that is actually used.  BCMA is really unnecessary if a 
few platforms stopped using BCMA and declared everything via devicetree 
or ACPI.  Same with pcie-iproc-platform.c.  Both keep the mess out of 
pcie-iproc.c.


It looks like pcie-iproc-msi.c followed existing pci drivers in place.  
So if msi was cleaned up through the entire pci drivers then yes it 
would make sense to remove CONFIG_PCIE_IPROC_MSI and combine code in 
pcie-iproc.c.  But I think leaving the bcma and platform code in their 
own files makes it easier for us to work with the code rather than 
placing unused code in ifdefs in the same file.


Bjorn

Regards,
Scott

[PATCH 0/1] net: ethtool: add SmartNIC reset support

[Scott Branden]

Ethtool provides support for resetting other internal portions of the
NIC already.  Seems appropriate to use one of the bits for resetting
the application processor (AP) for SmartNICs.
If we are not able to use ethtool to reset such portions of the NIC we
will need to create some other API that allows us to do so.  Please
suggest alternatives.
See patch for proposed bit define using ethtool.

Please comment on the best way to add reset support for Next-gen
NIC devices that contain an application processor (AP).

Scott Branden (1):
  net: ethtool: add support for reset of AP inside NIC interface.

 include/uapi/linux/ethtool.h | 1 +
 1 file changed, 1 insertion(+)

-- 
2.5.0

[PATCH 1/1] net: ethtool: add support for reset of AP inside NIC interface.

[Scott Branden]

Add ETH_RESET_AP to reset the application processor inside the NIC
interface.

Signed-off-by: Scott Branden 
---
 include/uapi/linux/ethtool.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 5bd1b1d..f927ab7 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1685,6 +1685,7 @@ enum ethtool_reset_flags {
ETH_RESET_PHY   = 1 << 6,   /* Transceiver/PHY */
ETH_RESET_RAM   = 1 << 7,   /* RAM shared between
 * multiple components */
+   ETH_RESET_AP= 1 << 8,   /* Application processor */
 
ETH_RESET_DEDICATED = 0x,   /* All components dedicated to
 * this interface */
-- 
2.5.0

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

[Scott Branden]

Hi Andrew,


On 17-10-18 09:28 AM, Andrew Lunn wrote:

On Wed, Oct 18, 2017 at 09:01:35AM -0700, Scott Branden wrote:

Ethtool provides support for resetting other internal portions of the
NIC already.  Seems appropriate to use one of the bits for resetting
the application processor (AP) for SmartNICs.

Hi Scott

Do you also have a management processor on the NIC?

Or is the Application Processor just the Marketing Departments name
for the management processor?

Yes, there is also a management processor.
In our next gen SmartNIC the "Application processor" may actually
have 8 very powerful cores.
But, if they need to be reset, we reset them all.


   Andrew

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

[Scott Branden]

Hi Andrew,


On 17-10-18 12:16 PM, Andrew Lunn wrote:

Yes, there is also a management processor.

O.K.

Maybe it would be nice to add some more text to the commit message to
make this clear. Define what an application processor is, and how it
differs from a management processor. But othersize:
OK -will add more description to differentiate management processor vs. 
application processor(s).


Reviewed-by: Andrew Lunn 

I assume you have another kernel patch to actually make use of this?
It is normal to post the user of a new API in the same series as the
API.
I actually wanted to get agreement that the bit define could be added to 
ethtool before implementing it in driver.
If this direction approved we'll implement in driver and submit with 
this patch series.


 Andrew

Thanks,
 Scott

Re: [PATCH 0/1] net: ethtool: add SmartNIC reset support

[Scott Branden]

+net...@vger.kernel.org


On 17-10-18 02:30 PM, Andy Gospodarek wrote:

On Wed, Oct 18, 2017 at 12:31:28PM -0700, Scott Branden wrote:

Hi Andrew,


On 17-10-18 12:16 PM, Andrew Lunn wrote:

Yes, there is also a management processor.

O.K.

Maybe it would be nice to add some more text to the commit message to
make this clear. Define what an application processor is, and how it
differs from a management processor. But othersize:

OK -will add more description to differentiate management processor vs.
application processor(s).

Reviewed-by: Andrew Lunn 

I assume you have another kernel patch to actually make use of this?
It is normal to post the user of a new API in the same series as the
API.

I actually wanted to get agreement that the bit define could be added to
ethtool before implementing it in driver.
If this direction approved we'll implement in driver and submit with this
patch series.

I just noticed that you did not also post this to net...@vger.kernel.org.  I
suspect you are more likely to get review and acceptance if that list is cc'd.

I'm not positive that Linus will take networking patches off this list.


  Andrew

Thanks,
  Scott

Re: [PATCH 1/1] net: ethtool: add support for reset of AP inside NIC interface.

[Scott Branden]

+net...@vger.kernel.org


On 17-10-18 09:01 AM, Scott Branden wrote:

Add ETH_RESET_AP to reset the application processor inside the NIC
interface.

Signed-off-by: Scott Branden 
---
  include/uapi/linux/ethtool.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index 5bd1b1d..f927ab7 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1685,6 +1685,7 @@ enum ethtool_reset_flags {
ETH_RESET_PHY   = 1 << 6, /* Transceiver/PHY */
ETH_RESET_RAM   = 1 << 7, /* RAM shared between
 * multiple components */
+   ETH_RESET_AP= 1 << 8, /* Application processor */
  
  	ETH_RESET_DEDICATED	= 0x,	/* All components dedicated to

 * this interface */

Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Scott Branden]

Hi Brian,

On 15-10-06 06:41 AM, Brian Norris wrote:



Is there a reason not to do this reset unconditionally? I recall this came up in
discussion previously, when the OpenWRT folks were trying to integrate with
BCMA, where this reset was one of the few differences between the platform-
device-based driver (i.e., this one) and the BCMA based driver. Might it help
simplify things a bit if we just did the same thing everywhere?


This driver is currently shared by Cygnus and NS2.

We had similar suggestion when this patch was reviewed
internally in Broadcom.

The rationale for adding optional DT flag is as follows:
1. The NAND controller reset is currently required for NS2 only so
that it is in sane state before any NAND commands are issued. We
are not sure if Cygnus and all future iProc SoCs will require NAND
controller reset.


I'm not sure this is a very strong reason. It seems fairly reasonable in
general to reset a HW block before using it.


Efficient Boot time is a very strong reason for needing this actually. 
We use the NAND controller in the bootROM, boot1/BL1, u-boot/UEFI, and 
then Kernel stage.  By properly initializing the controller once we do 
not need to reset it 4 different times.





2. The NAND controller reset in probe would certainly increase
Linux boot time so for certain iProc SoCs we might choose avoid
NAND controller reset to reduce boot time if possible.


I recall this reason being mentioned before. I believe this only happens
because the brcmnand driver doesn't yet handle configuring the timing
registers, so iProc is implicitly relying on the bootloader to configure
the NAND timings. Perhaps it's time that we fix that. I'd rather not add
extra DT properties unless we actually need to [1]. And having proper
timing configuration in the Linux driver will help improve speeds for
all users (whose timings may not be configured in the bootloader).


This is the very reason we need the optional reset property.  We need to 
have timings configured by the linux driver or not.  Yes, in some cases 
we will be relying on earlier boot stages to configure some of the hardware.




I actually had some preliminary work to do some timing configuration
according to the new timing information from nand_base.c/nand_timing.c.
Unfortunately, I didn't complete this, and I'm no longer working at
Broadcom, so I don't exactly have access to the HW docs for all the NAND
controller revisions, nor do I have access to as much HW for testing...

Brian

[1] If we really do need a device tree differentiation, perhaps it would
be better to just differentiate the compatible string than to have
individual boolean properties. e.g.:

compatible = "brcm,iproc-nand-ns2", ...;

As described above - the option is not SoC specific.  It is system 
specific.  In some systems we may wish to reset the NAND controller in 
linux.  In some we may wish to rely on initialization that has already 
been done to speed up boot times.




Regards,
 Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/5] Add Broadcom Northstar Plus Support

[Scott Branden]

Patchset all look good.
Acked-by: Scott Branden 

On 15-08-26 03:35 PM, Jon Mason wrote:


Changes in version 2 incorporate Olof's comments regarding:
* the removal of all "Reviewed-by" lines not occurring on external
   mailing lists
* reordering of s-o-b lines
* modification of the device tree file to use labels when enabling
* increated description of the modification to the MAINTAINERS entry

Also, modifying the "to" and "cc" recepients so that everyone is
receving all of the patches.

--

This patch series adds support for the Broadcom Northstar Plus family of
SoCs.  NSP is a Cortex A9 based SoC under the Broadcom iProc family.

Jon Mason (5):
   dt-bindings: Create Documentation for NSP DT bindings
   ARM: NSP: add minimal Northstar Plus device tree
   ARM: NSP: Add basic support for Broadcom Northstar Plus SoC
   ARM: multi_v7_defconfig: Add NSP to defconfig
   MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs

  .../devicetree/bindings/arm/bcm/brcm,nsp.txt   |  34 +++
  MAINTAINERS|  12 ++-
  arch/arm/boot/dts/Makefile |   2 +
  arch/arm/boot/dts/bcm-nsp.dtsi | 105 +
  arch/arm/boot/dts/bcm958625k.dts   |  57 +++
  arch/arm/configs/multi_v7_defconfig|   1 +
  arch/arm/mach-bcm/Kconfig  |  14 +++
  arch/arm/mach-bcm/Makefile |   5 +-
  arch/arm/mach-bcm/bcm_nsp.c|  25 +
  9 files changed, 252 insertions(+), 3 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
  create mode 100644 arch/arm/boot/dts/bcm-nsp.dtsi
  create mode 100644 arch/arm/boot/dts/bcm958625k.dts
  create mode 100644 arch/arm/mach-bcm/bcm_nsp.c



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/1] usb: dwc2: gadget: parity fix in isochronous mode

[Scott Branden]

From: Roman Bacik 

USB OTG driver in isochronous mode has to set the parity of the receiving
microframe. The parity is set to even by default. This causes problems for
an audio gadget, if the host starts transmitting on odd microframes.

This fix uses Incomplete Periodic Transfer interrupt to toggle between
even and odd parity until the Transfer Complete interrupt is received.

Signed-off-by: Roman Bacik 
Reviewed-by: Abhinav Ratna 
Reviewed-by: Srinath Mannam 
Signed-off-by: Scott Branden 
---
 drivers/usb/dwc2/core.h   |  1 +
 drivers/usb/dwc2/gadget.c | 51 ++-
 drivers/usb/dwc2/hw.h |  1 +
 3 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0ed87620..a5634fd 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
unsigned intperiodic:1;
unsigned intisochronous:1;
unsigned intsend_zlp:1;
+   unsigned inthas_correct_parity:1;
 
charname[10];
 };
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4d47b7c..fac3e2f 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1954,6 +1954,7 @@ static void s3c_hsotg_epint(struct dwc2_hsotg *hsotg, 
unsigned int idx,
ints &= ~DXEPINT_XFERCOMPL;
 
if (ints & DXEPINT_XFERCOMPL) {
+   hs_ep->has_correct_parity = 1;
if (hs_ep->isochronous && hs_ep->interval == 1) {
if (ctrl & DXEPCTL_EOFRNUM)
ctrl |= DXEPCTL_SETEVENFR;
@@ -2316,7 +2317,8 @@ void s3c_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
GINTSTS_RESETDET | GINTSTS_ENUMDONE |
GINTSTS_OTGINT | GINTSTS_USBSUSP |
-   GINTSTS_WKUPINT,
+   GINTSTS_WKUPINT |
+   GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
hsotg->regs + GINTMSK);
 
if (using_dma(hsotg))
@@ -2581,6 +2583,52 @@ irq_retry:
s3c_hsotg_dump(hsotg);
}
 
+   if (gintsts & GINTSTS_INCOMPL_SOIN) {
+   u32 idx, epctl_reg, ctrl;
+   struct s3c_hsotg_ep *hs_ep;
+
+   dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOIN\n", __func__);
+   for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
+   hs_ep = hsotg->eps_in[idx];
+
+   if (!hs_ep->isochronous || hs_ep->has_correct_parity)
+   continue;
+
+   epctl_reg = DIEPCTL(idx);
+   ctrl = readl(hsotg->regs + epctl_reg);
+
+   if (ctrl & DXEPCTL_EOFRNUM)
+   ctrl |= DXEPCTL_SETEVENFR;
+   else
+   ctrl |= DXEPCTL_SETODDFR;
+   writel(ctrl, hsotg->regs + epctl_reg);
+   }
+   writel(GINTSTS_INCOMPL_SOIN, hsotg->regs + GINTSTS);
+   }
+
+   if (gintsts & GINTSTS_INCOMPL_SOOUT) {
+   u32 idx, epctl_reg, ctrl;
+   struct s3c_hsotg_ep *hs_ep;
+
+   dev_dbg(hsotg->dev, "%s: GINTSTS_INCOMPL_SOOUT\n", __func__);
+   for (idx = 1; idx < MAX_EPS_CHANNELS; idx++) {
+   hs_ep = hsotg->eps_out[idx];
+
+   if (!hs_ep->isochronous || hs_ep->has_correct_parity)
+   continue;
+
+   epctl_reg = DOEPCTL(idx);
+   ctrl = readl(hsotg->regs + epctl_reg);
+
+   if (ctrl & DXEPCTL_EOFRNUM)
+   ctrl |= DXEPCTL_SETEVENFR;
+   else
+   ctrl |= DXEPCTL_SETODDFR;
+   writel(ctrl, hsotg->regs + epctl_reg);
+   }
+   writel(GINTSTS_INCOMPL_SOOUT, hsotg->regs + GINTSTS);
+   }
+
/*
 * if we've had fifo events, we should try and go around the
 * loop again to see if there's any point in returning yet.
@@ -2667,6 +2715,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
hs_ep->periodic = 0;
hs_ep->halted = 0;
hs_ep->interval = desc->bInterval;
+   hs_ep->has_correct_parity = 0;
 
if (hs_ep->interval > 1 && hs_ep->mc > 1)
dev_err(hsotg->dev, "MC > 1 when interval is not 1\n");
diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
index d0a5ed8..553f246 100644
--- a/drivers/usb/dwc2/hw.h
+++ b/drivers/usb/dwc2/hw.h
@@ -142,6 +142,7 @@
 #define GINTSTS_RESETDET   (1 << 23)
 #define GINTSTS_FET_SUSP

[PATCH v2 0/1] USB DWC2 parity fix in isochronous mode

[Scott Branden]

This patch contains a fix for a real world interop problem found
when using the Synopsis DWC2 USB controller with isochronous audio as
detailed in the commit message.

Changes from v1:
 - Address code review comments as per previous responses:
 - renamed parity_set to has_correct_parity and reorder some logic


Roman Bacik (1):
  usb: dwc2: gadget: parity fix in isochronous mode

 drivers/usb/dwc2/core.h   |  1 +
 drivers/usb/dwc2/gadget.c | 51 ++-
 drivers/usb/dwc2/hw.h |  1 +
 3 files changed, 52 insertions(+), 1 deletion(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

Hi Jon,

Comment below.

On 15-10-12 11:19 AM, Jon Mason wrote:

On Fri, Oct 09, 2015 at 05:33:52PM -0700, Stephen Boyd wrote:

On 10/02, Jon Mason wrote:

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 23800a1..2790f21 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -2,6 +2,7 @@ menu "Platform selection"

  config ARCH_BCM_IPROC
bool "Broadcom iProc SoC Family"
+   select COMMON_CLK_IPROC


Given that this is a visible option, I'd expect the defconfig to
enable this.


After looking at this again, it is completely unnecessary.  Removed.




help
  This enables support for Broadcom iProc based SoCs

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d08b3e5..ea81eaa 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -47,7 +47,8 @@ obj-$(CONFIG_COMMON_CLK_WM831X)   += clk-wm831x.o
  obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
  obj-$(CONFIG_COMMON_CLK_PWM)  += clk-pwm.o
  obj-$(CONFIG_COMMON_CLK_AT91) += at91/
-obj-$(CONFIG_ARCH_BCM) += bcm/
+obj-$(CONFIG_CLK_BCM_KONA) += bcm/
+obj-$(CONFIG_COMMON_CLK_IPROC) += bcm/


Also, perhaps we need some sort of Kconfig thing for overall bcm
clock drivers, so that we don't have duplicate Makefile rules.

config COMMON_CLK_BCM
bool "Support for Broadcom clocks"


Will do.


Is that really necessary at all  I think something like this work instead?

-obj-$(CONFIG_ARCH_BCM) += bcm/
+obj-y  += bcm/





Thanks,
Jon




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] dt-bindings: Add new boards to bcm4708 DT bindings

[Scott Branden]

Hi Jon,

One question below.

On 15-10-10 07:42 AM, Hauke Mehrtens wrote:

On 10/03/2015 12:22 AM, Jon Mason wrote:

Add the 4708, 4709, and 953012k SVKs to the the documentation for the
Broadcom Northstar device tree bindings.

Signed-off-by: Jon Mason 
---
  Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
index 6b0f49f..bdf4c06 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt


What should be documented in this file? This is more a question to the
guys more familiar with arm in Linux. Currently the Linux kernel only
supports brcm,bcm4708 and all goes back to that one.


@@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
properties:

  Required root node property:

+bcm94709
  compatible = "brcm,bcm4708";
+
+bcm94709
+compatible = "brcm,bcm4709", "brcm,bcm4708";
+
+bcm953012k
+compatible = "brcm,bcm5301k", "brcm,bcm4708";


Why are you adding a "k" on the string here?  bcm5301k is not an SoC 
part number?






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: Allow drivers to build if COMPILE_TEST is enabled

[Scott Branden]

For BCM portion:

Acked-by: Scott Branden 

On 15-10-13 07:18 AM, Javier Martinez Canillas wrote:

These drivers only have runtime but no build time dependencies so can be
built for testing purposes if the Kconfig COMPILE_TEST option is enabled.

This is useful to have more build coverage and make sure that drivers are
not affected by changes that could cause build regressions.

Signed-off-by: Javier Martinez Canillas 

---

  drivers/clk/Kconfig   | 8 
  drivers/clk/bcm/Kconfig   | 4 ++--
  drivers/clk/versatile/Kconfig | 2 +-
  3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 573517151976..57316528e924 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -124,7 +124,7 @@ config CLK_TWL6040

  config COMMON_CLK_AXI_CLKGEN
tristate "AXI clkgen driver"
-   depends on ARCH_ZYNQ || MICROBLAZE
+   depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST
help
---help---
  Support for the Analog Devices axi-clkgen pcore clock generator for 
Xilinx
@@ -132,7 +132,7 @@ config COMMON_CLK_AXI_CLKGEN

  config CLK_QORIQ
bool "Clock driver for Freescale QorIQ platforms"
-   depends on (PPC_E500MC || ARM) && OF
+   depends on (PPC_E500MC || ARM || COMPILE_TEST) && OF
---help---
  This adds the clock driver support for Freescale QorIQ platforms
  using common clock framework.
@@ -140,13 +140,13 @@ config CLK_QORIQ
  config COMMON_CLK_XGENE
bool "Clock driver for APM XGene SoC"
default y
-   depends on ARM64
+   depends on ARM64 || COMPILE_TEST
---help---
  Sypport for the APM X-Gene SoC reference, PLL, and device clocks.

  config COMMON_CLK_KEYSTONE
tristate "Clock drivers for Keystone based SOCs"
-   depends on ARCH_KEYSTONE && OF
+   depends on (ARCH_KEYSTONE || COMPILE_TEST) && OF
---help---
Supports clock drivers for Keystone based SOCs. These SOCs have 
local
  a power sleep control module that gate the clock to the IPs and PLLs.
diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 88febf53b276..561e9dc6d40d 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -1,6 +1,6 @@
  config CLK_BCM_KONA
bool "Broadcom Kona CCU clock support"
-   depends on ARCH_BCM_MOBILE
+   depends on ARCH_BCM_MOBILE || COMPILE_TEST
depends on COMMON_CLK
default y
help
@@ -10,7 +10,7 @@ config CLK_BCM_KONA

  config COMMON_CLK_IPROC
bool "Broadcom iProc clock support"
-   depends on ARCH_BCM_IPROC
+   depends on ARCH_BCM_IPROC || COMPILE_TEST
depends on COMMON_CLK
default ARCH_BCM_IPROC
help
diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
index 1530c9352a76..fc50b6264bed 100644
--- a/drivers/clk/versatile/Kconfig
+++ b/drivers/clk/versatile/Kconfig
@@ -1,6 +1,6 @@
  config COMMON_CLK_VERSATILE
bool "Clock driver for ARM Reference designs"
-   depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64
+   depends on ARCH_INTEGRATOR || ARCH_REALVIEW || ARCH_VEXPRESS || ARM64 
|| COMPILE_TEST
---help---
Supports clocking on ARM Reference designs:
  - Integrator/AP and Integrator/CP



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] dt-bindings: Add new boards to bcm4708 DT bindings

[Scott Branden]

Hi Jon,

Yes, please only add SoC part number compatible strings, not board 
compatible strings.


On 15-10-14 08:34 AM, Jon Mason wrote:

On Tue, Oct 13, 2015 at 03:37:49PM -0700, Florian Fainelli wrote:

On 13/10/15 14:40, Jon Mason wrote:

On Sat, Oct 10, 2015 at 04:42:04PM +0200, Hauke Mehrtens wrote:

On 10/03/2015 12:22 AM, Jon Mason wrote:

Add the 4708, 4709, and 953012k SVKs to the the documentation for the
Broadcom Northstar device tree bindings.

Signed-off-by: Jon Mason 
---
  Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
index 6b0f49f..bdf4c06 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt


What should be documented in this file? This is more a question to the
guys more familiar with arm in Linux. Currently the Linux kernel only
supports brcm,bcm4708 and all goes back to that one.


I was under the impression that all boards should be added to these
files.  We have been doing so for Cygnus and NSP.


Tracking exactly which boards are supported by the brcm,bcm4708
compatible string might be tedious, I tend to agree with just listing
the supported SoCs, and leaving the specific board compatibles to the
individual DTS files instead.


Ok, I'll simply add entries for NS and 4709 to this.
Good - we have only been adding SoC compatible strings for Cygnus and 
NSP - not board compatibles.




Thanks,
Jon





Thanks,
Jon




@@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
properties:

  Required root node property:

+bcm94709
  compatible = "brcm,bcm4708";
+
+bcm94709
+compatible = "brcm,bcm4709", "brcm,bcm4708";
+
+bcm953012k
+compatible = "brcm,bcm5301k", "brcm,bcm4708";






--
Florian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

On 15-10-13 03:23 PM, Arnd Bergmann wrote:

On Tuesday 13 October 2015 18:04:50 Jon Mason wrote:



On a related note, I'm seeing problems when CONFIG_CYGNUS is set but
CONFIG_COMMON_CLK_IPROC is disabled, as that currently leads to a link
failure.


I can double check, but it should be on by default when Cygnus is
enabled.  If you send me the error, I'll be happy to fix it.



The problem is not that it's off by default but that it can be
disabled, so it breaks some 'make randconfig' builds with this
message:

drivers/built-in.o: In function `cygnus_armpll_init':
:(.init.text+0x1d290): undefined reference to `iproc_armpll_setup'
drivers/built-in.o: In function `cygnus_genpll_clk_init':
:(.init.text+0x1d2c4): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_lcpll0_clk_init':
:(.init.text+0x1d304): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_mipipll_clk_init':
:(.init.text+0x1d344): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_asiu_init':
:(.init.text+0x1d370): undefined reference to `iproc_asiu_setup'

My patch fixes it by always selecting COMMON_CLK_IPROC from
ARCH_BCM_CYGNUS. I wasn't sure whether you want COMMON_CLK_IPROC
to still be user-selectable, so I left that in place. Normally
I'd expect it to be a silent option though, that just gets
implicitly enabled whenever a platform that needs it is built
into the kernel.

COMMON_CLK_IPROC can be a silent option and selected as Arnd has done below.


Signed-off-by: Arnd Bergmann 

Acked-by: Scott Branden 



diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 1319c3c14327..35234e563cd8 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -29,6 +29,7 @@ config ARCH_BCM_IPROC
  config ARCH_BCM_CYGNUS
bool "Broadcom Cygnus Support" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+   select COMMON_CLK_IPROC
help
  Enable support for the Cygnus family,
  which includes the following variants:



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] ARM: BCM: Add SMP support for Broadcom 4708

[Scott Branden]

Looks good.

On 15-10-15 11:14 AM, Jon Mason wrote:

ARM: BCM: Add SMP support for Broadcom 4708

Add SMP support for Broadcom's 4708 SoCs.

Signed-off-by: Jon Mason 

Acked-by: Scott Branden 

---
  arch/arm/boot/dts/bcm4708.dtsi | 2 ++
  arch/arm/boot/dts/bcm94708.dts | 2 +-
  arch/arm/mach-bcm/Kconfig  | 1 +
  arch/arm/mach-bcm/Makefile | 3 +++
  4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
index 31141e8..22a41df 100644
--- a/arch/arm/boot/dts/bcm4708.dtsi
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -15,6 +15,8 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+   enable-method = "brcm,bcm-nsp-smp";
+   secondary-boot-reg = <0x0400>;

cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
index f60bb1d..49682d6 100644
--- a/arch/arm/boot/dts/bcm94708.dts
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -32,7 +32,7 @@

  /dts-v1/;

-#include "bcm5301x.dtsi"
+#include "bcm4708.dtsi"

  / {
model = "NorthStar SVK (BCM94708)";
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 2e9dbb5..4fc8fa3 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -54,6 +54,7 @@ config ARCH_BCM_NSP
  config ARCH_BCM_5301X
bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+   select HAVE_SMP
help
  Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.

diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 36a4ca30..3ca1cf1 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -43,6 +43,9 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o

  # BCM5301X
  obj-$(CONFIG_ARCH_BCM_5301X)  += bcm_5301x.o
+ifeq ($(CONFIG_ARCH_BCM_5301X),y)
+obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
+endif

  # BCM63XXx
  ifeq ($(CONFIG_ARCH_BCM_63XX),y)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

Jon,

Can you add this to your patchset and change COMMON_CLK_IPROC to a 
silent option?


On 15-10-14 01:16 PM, Arnd Bergmann wrote:

On Wednesday 14 October 2015 12:46:19 Scott Branden wrote:


My patch fixes it by always selecting COMMON_CLK_IPROC from
ARCH_BCM_CYGNUS. I wasn't sure whether you want COMMON_CLK_IPROC
to still be user-selectable, so I left that in place. Normally
I'd expect it to be a silent option though, that just gets
implicitly enabled whenever a platform that needs it is built
into the kernel.

COMMON_CLK_IPROC can be a silent option and selected as Arnd has done below.


Ok, please do that then. If you want to apply my patch directly,
you can remove that last paragraph from the description.


Signed-off-by: Arnd Bergmann 

Acked-by: Scott Branden 


Thanks for taking a look!

Arnd



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 01/10] ARM: cygnus: fix link failures when CONFIG_COMMON_CLK_IPROC is disabled

[Scott Branden]

Jon,

One question below for others to comment on.

On 15-10-15 12:48 PM, Jon Mason wrote:

From: Arnd Bergmann 

When CONFIG_CYGNUS is set but CONFIG_COMMON_CLK_IPROC is disabled, the
following link failures are caused:

drivers/built-in.o: In function `cygnus_armpll_init':
:(.init.text+0x1d290): undefined reference to `iproc_armpll_setup'
drivers/built-in.o: In function `cygnus_genpll_clk_init':
:(.init.text+0x1d2c4): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_lcpll0_clk_init':
:(.init.text+0x1d304): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_mipipll_clk_init':
:(.init.text+0x1d344): undefined reference to `iproc_pll_clk_setup'
drivers/built-in.o: In function `cygnus_asiu_init':
:(.init.text+0x1d370): undefined reference to `iproc_asiu_setup'

It is fixed it by always selecting COMMON_CLK_IPROC from
ARCH_BCM_IPROC, and making COMMON_CLK_IPROC a silent option (thus
preventing it from being erroneously disabled by a user).

Signed-off-by: Arnd Bergmann 
Signed-off-by: Jon Mason 
---
  arch/arm/mach-bcm/Kconfig | 2 +-
  drivers/clk/bcm/Kconfig   | 4 +---
  2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 1319c3c..84bd265 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -14,7 +14,7 @@ config ARCH_BCM_IPROC
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select ARM_GLOBAL_TIMER
-
+   select COMMON_CLK_IPROC
select CLKSRC_MMIO
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 88febf5..46ee475 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -9,10 +9,8 @@ config CLK_BCM_KONA
  in the BCM281xx and BCM21664 families.

  config COMMON_CLK_IPROC
-   bool "Broadcom iProc clock support"
-   depends on ARCH_BCM_IPROC
+   bool
depends on COMMON_CLK
Should these depends on remain?  I think COMMON_CLK_IPROC won't work 
without them.

-   default ARCH_BCM_IPROC
help
  Enable common clock framework support for Broadcom SoCs
  based on the iProc architecture



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

We need some sort of kconfig option to differentiate NS2 clock driver 
from being pulled in all the time.


On 15-10-15 12:48 PM, Jon Mason wrote:

The Broadcom Northstar 2 SoC is architected under the iProc
architecture. It has the following PLLs: GENPLL SCR, GENPLL SW,
LCPLL DDR, LCPLL Ports, all derived from an onboard crystal.

Signed-off-by: Jon Mason 
---
  drivers/clk/Makefile|   2 +-
  drivers/clk/bcm/Makefile|   1 +
  drivers/clk/bcm/clk-ns2.c   | 288 
  include/dt-bindings/clock/bcm-ns2.h |  72 +
  4 files changed, 362 insertions(+), 1 deletion(-)
  create mode 100644 drivers/clk/bcm/clk-ns2.c
  create mode 100644 include/dt-bindings/clock/bcm-ns2.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d08b3e5..6124bd3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -47,7 +47,7 @@ obj-$(CONFIG_COMMON_CLK_WM831X)   += clk-wm831x.o
  obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
  obj-$(CONFIG_COMMON_CLK_PWM)  += clk-pwm.o
  obj-$(CONFIG_COMMON_CLK_AT91) += at91/
-obj-$(CONFIG_ARCH_BCM) += bcm/
+obj-y  += bcm/
  obj-$(CONFIG_ARCH_BERLIN) += berlin/
  obj-$(CONFIG_ARCH_HISI)   += hisilicon/
  obj-$(CONFIG_ARCH_MXC)+= imx/
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index e258b28..2d1cbc5 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_CLK_BCM_KONA)  += clk-kona-setup.o
  obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm281xx.o
  obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
  obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-iproc-armpll.o clk-iproc-pll.o 
clk-iproc-asiu.o
+obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o


NS2 code is dragged in for all IPROC SoCs.  We need a config option for 
NS2 (CONFIG_ARCH_BCM_NS2) to avoid this (if Arnd allows this for ARMv8 
processors... ?).


You can see below ARMv7 processors don't have this problem.

If not we need to add CONFIG_CLK_NS2.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 04/10] clk: nsp: add clock support for Broadcom Northstar Plus SoC

[Scott Branden]

Jon,

Review below.

On 15-10-15 12:48 PM, Jon Mason wrote:

The Broadcom Northstar Plus SoC is architected under the iProc


Based on changes in Makefile below - should this be for Northstar and 
Northstar Plus?



architecture. It has the following PLLs: ARMPLL, GENPLL, LCPLL0, all
derived from an onboard crystal.

Signed-off-by: Jon Mason 
---
  drivers/clk/bcm/Makefile|   2 +
  drivers/clk/bcm/clk-nsp.c   | 135 
  include/dt-bindings/clock/bcm-nsp.h |  51 ++
  3 files changed, 188 insertions(+)
  create mode 100644 drivers/clk/bcm/clk-nsp.c
  create mode 100644 include/dt-bindings/clock/bcm-nsp.h

diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 8a7a477..e258b28 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -4,3 +4,5 @@ obj-$(CONFIG_CLK_BCM_KONA)  += clk-bcm281xx.o
  obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
  obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-iproc-armpll.o clk-iproc-pll.o 
clk-iproc-asiu.o
  obj-$(CONFIG_ARCH_BCM_CYGNUS) += clk-cygnus.o
+obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o
+obj-$(CONFIG_ARCH_BCM_5301X)   += clk-nsp.o


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] dt-bindings: Add new boards to bcm4708 DT bindings

[Scott Branden]

On 15-10-15 01:52 PM, Hauke Mehrtens wrote:

On 10/15/2015 12:14 AM, Jon Mason wrote:

Add the 4708, 4709, and 953012k SVKs to the the documentation for the
Broadcom Northstar device tree bindings.

Signed-off-by: Jon Mason 
---
  Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
index 6b0f49f..b9cc308 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
@@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
properties:

  Required root node property:

+bcm94708

this should be bcm4708


I thought we wanted to add the SoC names here, isn't bcm94708 a board
the bcm4708, the SoC ion this board? I do not really care about this
file, has anyone found the documentation what should be listed here?


Yes - the 9 infront indicates its some type of board.  The SoC part 
numbers should be listed here.  The SoCs are all variants of 
Northstar/Northstar plus family.  Some have different io, packaging, 
speed grades, etc.




Hauke


  compatible = "brcm,bcm4708";
+
+bcm94709

This should be bcm4709

+compatible = "brcm,bcm4709";
+
+bcm953012

This should be bcm53012

+compatible = "brcm,bcm53012";





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

Hi Ray,

Comment at near end.

On 15-10-15 01:55 PM, Ray Jui wrote:



On 10/15/2015 1:40 PM, Scott Branden wrote:

We need some sort of kconfig option to differentiate NS2 clock driver
from being pulled in all the time.

On 15-10-15 12:48 PM, Jon Mason wrote:

The Broadcom Northstar 2 SoC is architected under the iProc
architecture. It has the following PLLs: GENPLL SCR, GENPLL SW,
LCPLL DDR, LCPLL Ports, all derived from an onboard crystal.

Signed-off-by: Jon Mason 
---
   drivers/clk/Makefile|   2 +-
   drivers/clk/bcm/Makefile|   1 +
   drivers/clk/bcm/clk-ns2.c   | 288

   include/dt-bindings/clock/bcm-ns2.h |  72 +
   4 files changed, 362 insertions(+), 1 deletion(-)
   create mode 100644 drivers/clk/bcm/clk-ns2.c
   create mode 100644 include/dt-bindings/clock/bcm-ns2.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d08b3e5..6124bd3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -47,7 +47,7 @@ obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o
   obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
   obj-$(CONFIG_COMMON_CLK_PWM)+= clk-pwm.o
   obj-$(CONFIG_COMMON_CLK_AT91)+= at91/
-obj-$(CONFIG_ARCH_BCM)+= bcm/
+obj-y+= bcm/
   obj-$(CONFIG_ARCH_BERLIN)+= berlin/
   obj-$(CONFIG_ARCH_HISI)+= hisilicon/
   obj-$(CONFIG_ARCH_MXC)+= imx/
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index e258b28..2d1cbc5 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_CLK_BCM_KONA)+= clk-kona-setup.o
   obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm281xx.o
   obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
   obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-iproc-armpll.o
clk-iproc-pll.o clk-iproc-asiu.o
+obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-ns2.o


NS2 code is dragged in for all IPROC SoCs.  We need a config option for
NS2 (CONFIG_ARCH_BCM_NS2) to avoid this (if Arnd allows this for ARMv8
processors... ?).

You can see below ARMv7 processors don't have this problem.



The arm64 maintainers (Catalin, Mark, and etc.) stated they only want
one ARCH options per chip family.


If not we need to add CONFIG_CLK_NS2.


If using CONFIG_CLK_NS2, how is it going to be enabled/selected?


Since CONFIG_ARCH_BCM_NS2 isn't "allowed" to be introduced we will need 
to create and select a CONFIG_CLK_BCM_NS2 in the defconfig instead.


Ray



Regards,
 Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 08/10] clk: ns2: add clock support for Broadcom Northstar 2 SoC

[Scott Branden]

On 15-10-15 02:15 PM, Ray Jui wrote:



On 10/15/2015 2:10 PM, Jon Mason wrote:

On Thu, Oct 15, 2015 at 02:04:09PM -0700, Scott Branden wrote:

Hi Ray,

Comment at near end.

On 15-10-15 01:55 PM, Ray Jui wrote:



On 10/15/2015 1:40 PM, Scott Branden wrote:

We need some sort of kconfig option to differentiate NS2 clock driver

>from being pulled in all the time.


On 15-10-15 12:48 PM, Jon Mason wrote:

The Broadcom Northstar 2 SoC is architected under the iProc
architecture. It has the following PLLs: GENPLL SCR, GENPLL SW,
LCPLL DDR, LCPLL Ports, all derived from an onboard crystal.

Signed-off-by: Jon Mason 
---
   drivers/clk/Makefile|   2 +-
   drivers/clk/bcm/Makefile|   1 +
   drivers/clk/bcm/clk-ns2.c   | 288

   include/dt-bindings/clock/bcm-ns2.h |  72 +
   4 files changed, 362 insertions(+), 1 deletion(-)
   create mode 100644 drivers/clk/bcm/clk-ns2.c
   create mode 100644 include/dt-bindings/clock/bcm-ns2.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d08b3e5..6124bd3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -47,7 +47,7 @@ obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o
   obj-$(CONFIG_COMMON_CLK_XGENE)+= clk-xgene.o
   obj-$(CONFIG_COMMON_CLK_PWM)+= clk-pwm.o
   obj-$(CONFIG_COMMON_CLK_AT91)+= at91/
-obj-$(CONFIG_ARCH_BCM)+= bcm/
+obj-y+= bcm/
   obj-$(CONFIG_ARCH_BERLIN)+= berlin/
   obj-$(CONFIG_ARCH_HISI)+= hisilicon/
   obj-$(CONFIG_ARCH_MXC)+= imx/
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index e258b28..2d1cbc5 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_CLK_BCM_KONA)+= clk-kona-setup.o
   obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm281xx.o
   obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
   obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-iproc-armpll.o
clk-iproc-pll.o clk-iproc-asiu.o
+obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-ns2.o


NS2 code is dragged in for all IPROC SoCs.  We need a config option for
NS2 (CONFIG_ARCH_BCM_NS2) to avoid this (if Arnd allows this for ARMv8
processors... ?).

You can see below ARMv7 processors don't have this problem.



The arm64 maintainers (Catalin, Mark, and etc.) stated they only want
one ARCH options per chip family.


If not we need to add CONFIG_CLK_NS2.


If using CONFIG_CLK_NS2, how is it going to be enabled/selected?


Since CONFIG_ARCH_BCM_NS2 isn't "allowed" to be introduced we will
need to create and select a CONFIG_CLK_BCM_NS2 in the defconfig
instead.


Is this better than the binary becoming slightly bigger?  I thought
the extra complexity was worse than having an unused chunk of clk code
(and Kona is already doing the same thing above).  I believe Ray was
in agreement with me during the internal review of this code.

Thanks,
Jon



Yes, I'm okay with leaving it as it is. I even prefer changing the
current Makefile to make all iProc based core clock drivers and SoC
specific clock tables under CONFIG_COMMON_CLK_IPROC, which is what some
of the other vendors do.

I'd leave it exactly as is then rather than pulling in more dead code 
when not needed.  This ns2 clock code is very minor compared to other 
code bloat in the kernel and drivers.


Ray



Regards,
  Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files

[Scott Branden]

Hi Jon,

No need for the board in the compatible string.

On 15-10-16 02:41 PM, Hauke Mehrtens wrote:

On 10/16/2015 12:24 AM, Jon Mason wrote:

Add device tree files for Broadcom Northstar based SVKs.  Since the
bcm5301x.dtsi already exists, all that is necessary is the dts files to
enable the UARTs.  With these files, the SVKs are able to boot to shell.

Signed-off-by: Jon Mason 


Acked-by: Hauke Mehrtens 


---
  arch/arm/boot/dts/Makefile   |  5 +++-
  arch/arm/boot/dts/bcm94708.dts   | 56 +++
  arch/arm/boot/dts/bcm94709.dts   | 56 +++
  arch/arm/boot/dts/bcm953012k.dts | 63 
  4 files changed, 179 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/boot/dts/bcm94708.dts
  create mode 100644 arch/arm/boot/dts/bcm94709.dts
  create mode 100644 arch/arm/boot/dts/bcm953012k.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..96a1b58 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
bcm47081-buffalo-wzr-900dhp.dtb \
bcm4709-asus-rt-ac87u.dtb \
bcm4709-buffalo-wxr-1900dhp.dtb \
-   bcm4709-netgear-r8000.dtb
+   bcm4709-netgear-r8000.dtb \
+   bcm94708.dtb \
+   bcm94709.dtb \
+   bcm953012k.dtb
  dtb-$(CONFIG_ARCH_BCM_63XX) += \
bcm963138dvt.dtb
  dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
diff --git a/arch/arm/boot/dts/bcm94708.dts b/arch/arm/boot/dts/bcm94708.dts
new file mode 100644
index 000..49682d6
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -0,0 +1,56 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "bcm4708.dtsi"
+
+/ {
+   model = "NorthStar SVK (BCM94708)";
+   compatible = "brcm,bcm94708", "brcm,bcm4708";

no need for brcm,bcm94708

+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,115200";
+   };
+
+   memory {
+   reg = <0x 0x0800>;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm94709.dts b/arch/arm/boot/dts/bcm94709.dts
new file mode 100644
index 000..4ab19c0
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94709.dts
@@ -0,0 +1,56 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE

Re: [PATCH v3 1/2] dt-bindings: Add new SoCs to bcm4708 DT bindings

[Scott Branden]

On 15-10-16 02:42 PM, Hauke Mehrtens wrote:

On 10/16/2015 12:24 AM, Jon Mason wrote:

Add the 4708, 4709, and 53012 SoCs to the the documentation for the
Broadcom Northstar device tree bindings.

Signed-off-by: Jon Mason 

Acked-by: Hauke Mehrtens 

Acked-by: Scott Branden 




---
  Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
index 6b0f49f..8608a77 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
@@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
properties:

  Required root node property:

+bcm4708
  compatible = "brcm,bcm4708";
+
+bcm4709
+compatible = "brcm,bcm4709";
+
+bcm53012
+compatible = "brcm,bcm53012";





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] ARM: dts: bcm5301x: Add BCM SVK DT files

[Scott Branden]

Hi Hauke,


On 15-10-16 03:42 PM, Hauke Mehrtens wrote:



On 10/17/2015 12:38 AM, Scott Branden wrote:

Hi Jon,

No need for the board in the compatible string.


I think the board should be named here, so we could take some code
branches based on the board, if it would have bad wiring for example.

The device tree wiki says:
"The first string in the list specifies the exact device that the node
represents"
http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property

The exact device here is the board not the SoC.


Thanks for link to understand this compatible string more.



Hauke



On 15-10-16 02:41 PM, Hauke Mehrtens wrote:

On 10/16/2015 12:24 AM, Jon Mason wrote:

Add device tree files for Broadcom Northstar based SVKs.  Since the
bcm5301x.dtsi already exists, all that is necessary is the dts files to
enable the UARTs.  With these files, the SVKs are able to boot to shell.

Signed-off-by: Jon Mason 


Acked-by: Hauke Mehrtens 

Acked-by: Scott Branden 




---
   arch/arm/boot/dts/Makefile   |  5 +++-
   arch/arm/boot/dts/bcm94708.dts   | 56
+++
   arch/arm/boot/dts/bcm94709.dts   | 56
+++
   arch/arm/boot/dts/bcm953012k.dts | 63

   4 files changed, 179 insertions(+), 1 deletion(-)
   create mode 100644 arch/arm/boot/dts/bcm94708.dts
   create mode 100644 arch/arm/boot/dts/bcm94709.dts
   create mode 100644 arch/arm/boot/dts/bcm953012k.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..96a1b58 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -72,7 +72,10 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
   bcm47081-buffalo-wzr-900dhp.dtb \
   bcm4709-asus-rt-ac87u.dtb \
   bcm4709-buffalo-wxr-1900dhp.dtb \
-bcm4709-netgear-r8000.dtb
+bcm4709-netgear-r8000.dtb \
+bcm94708.dtb \
+bcm94709.dtb \
+bcm953012k.dtb
   dtb-$(CONFIG_ARCH_BCM_63XX) += \
   bcm963138dvt.dtb
   dtb-$(CONFIG_ARCH_BCM_CYGNUS) += \
diff --git a/arch/arm/boot/dts/bcm94708.dts
b/arch/arm/boot/dts/bcm94708.dts
new file mode 100644
index 000..49682d6
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94708.dts
@@ -0,0 +1,56 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above
copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE
+ *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "bcm4708.dtsi"
+
+/ {
+model = "NorthStar SVK (BCM94708)";
+compatible = "brcm,bcm94708", "brcm,bcm4708";

no need for brcm,bcm94708

+
+aliases {
+serial0 = &uart0;
+};
+
+chosen {
+bootargs = "console=ttyS0,115200";
+};
+
+memory {
+reg = <0x 0x0800>;
+};
+};
+
+&uart0 {
+status = "okay";
+};
diff --git a/arch/arm/boot/dts/bcm94709.dts
b/arch/arm/boot/dts/bcm94709.dts
new file mode 100644
index 000..4ab19c0
--- /dev/null
+++ b/arch/arm/boot/dts/bcm94709.dts
@@ -0,0 +1,56 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ 

Re: [PATCH] clk: iproc: Make clocks visible options

[Scott Branden]

Hi Jon,

comments inline.

On 15-10-22 12:25 PM, Jon Mason wrote:

Make the clocks visible options that can be selected by anyone.  This
avoids the problems of:
  1) Select is a reverse dependency and is hard for people to understand
 and can sometimes be a pain to track down
This doesn't make any sense to me - there are many selects in the system 
and this is one of them.

  2) Build coverage goes down because configs are hidden
  3) Code bloat

Patch suggested by Stephen Boyd

Signed-off-by: Jon Mason 
---
  arch/arm/mach-bcm/Kconfig |  1 -
  drivers/clk/bcm/Kconfig   | 35 ++-
  drivers/clk/bcm/Makefile  |  7 +++
  3 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 679798b..cacaaec 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -14,7 +14,6 @@ config ARCH_BCM_IPROC
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select ARM_GLOBAL_TIMER
-   select COMMON_CLK_IPROC

Please leave as is

select CLKSRC_MMIO
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 46ee475..0352ccf 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -9,8 +9,41 @@ config CLK_BCM_KONA
  in the BCM281xx and BCM21664 families.

  config COMMON_CLK_IPROC
-   bool
+   bool "Broadcom iProc clock support"

Please leave as is

+   depends on ARCH_BCM_IPROC
depends on COMMON_CLK
+   default ARCH_BCM_IPROC
help
  Enable common clock framework support for Broadcom SoCs
  based on the iProc architecture
+
+if COMMON_CLK_IPROC
+
+comment "Broadcom iProc clocks"
+
+config CLK_BCM_CYGNUS

not needed

+   bool "Broadcom Cygnus clock support"
+   depends on COMMON_CLK_IPROC
+   depends on ARCH_BCM_CYGNUS
+   default ARCH_BCM_CYGNUS
+   help
+ Enable common clock framework support for the Broadcom Cygnus SoC
+
+config CLK_BCM_NSP

not needed

+   bool "Broadcom Northstar/Northstar Plus clock support"
+   depends on COMMON_CLK_IPROC
+   depends on ARCH_BCM_5301X || ARCH_BCM_NSP
+   default ARCH_BCM_5301X || ARCH_BCM_NSP
+   help
+ Enable common clock framework support for the Broadcom Northstar and
+ Northstar Plus SoCs
+
+config CLK_BCM_NS2
+   bool "Broadcom Northstar 2 clock support"
+   depends on ARM64

|| COMPILE_TEST

+   depends on COMMON_CLK_IPROC

select COMMON_CLK_IPROC

+   default ARCH_BCM_IPROC
+   help
+ Enable common clock framework support for the Broadcom Northstar 2 SoC
+
+endif
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 2d1cbc5..05d5830 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_CLK_BCM_KONA)  += clk-kona-setup.o
  obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm281xx.o
  obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
  obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-iproc-armpll.o clk-iproc-pll.o 
clk-iproc-asiu.o
-obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o

yes, change this one

-obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o

you can leave this

-obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o

you can leave this

-obj-$(CONFIG_ARCH_BCM_5301X)   += clk-nsp.o

and this

+obj-$(CONFIG_CLK_BCM_CYGNUS)   += clk-cygnus.o

no

+obj-$(CONFIG_CLK_BCM_NSP)  += clk-nsp.o

no

+obj-$(CONFIG_CLK_BCM_NS2)  += clk-ns2.o

yes needed




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: iproc: Make clocks visible options

[Scott Branden]

Hi Jon,


On 15-10-22 01:14 PM, Jon Mason wrote:

On Thu, Oct 22, 2015 at 12:46:46PM -0700, Scott Branden wrote:

Hi Jon,

comments inline.

On 15-10-22 12:25 PM, Jon Mason wrote:

Make the clocks visible options that can be selected by anyone.  This
avoids the problems of:
  1) Select is a reverse dependency and is hard for people to understand
 and can sometimes be a pain to track down

This doesn't make any sense to me - there are many selects in the
system and this is one of them.


This was specifically requested by Stephen Boyd, and the above are
his words verbatum
https://lkml.org/lkml/2015/10/21/956

Yes, thanks.  Not all of the comments are needed.  If you look closer 
COMMON_CLK_IPROC should be a non-visible option.  It is just an internal 
config option used in the Makefile only.  There's no benefit to exposing 
an option here and adding another layer to the Kconfig hierarchy.


See my proposed (revised) changes below which remove the code bloat and 
allow build coverage to be increased.  Even if you expose it there are 
additional changes you need to make to your patchset dealing with 
COMPILE_TEST



Thanks,
Jon


  2) Build coverage goes down because configs are hidden
  3) Code bloat

Patch suggested by Stephen Boyd

Signed-off-by: Jon Mason 
---
  arch/arm/mach-bcm/Kconfig |  1 -
  drivers/clk/bcm/Kconfig   | 35 ++-
  drivers/clk/bcm/Makefile  |  7 +++
  3 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 679798b..cacaaec 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -14,7 +14,6 @@ config ARCH_BCM_IPROC
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select ARM_GLOBAL_TIMER
-   select COMMON_CLK_IPROC
select CLKSRC_MMIO
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 46ee475..0352ccf 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -9,8 +9,41 @@ config CLK_BCM_KONA

>  in the BCM281xx and BCM21664 families.
>
>  config COMMON_CLK_IPROC
> -  bool
> +  bool "Broadcom iProc clock support"
Please leave as is
> +  depends on ARCH_BCM_IPROC
>depends on COMMON_CLK
> +  default ARCH_BCM_IPROC
>help
>  Enable common clock framework support for Broadcom SoCs
>  based on the iProc architecture
> +
> +if COMMON_CLK_IPROC
Remove all the changes above from patchset - not needed.


+config CLK_BCM_CYGNUS
+   bool "Broadcom Cygnus clock support"
+   depends on COMMON_CLK_IPROC

not needed - keep hidden and do this instead
select COMMON_CLK_IPROC

+   depends on ARCH_BCM_CYGNUS

|| COMPILE_TEST

+   default ARCH_BCM_CYGNUS
+   help
+ Enable common clock framework support for the Broadcom Cygnus SoC
+
+config CLK_BCM_NSP

not needed

+   bool "Broadcom Northstar/Northstar Plus clock support"
+   depends on COMMON_CLK_IPROC

not needed - keep hidden and do this instead
select COMMON_CLK_IPROC

+   depends on ARCH_BCM_5301X || ARCH_BCM_NSP

|| COMPILE_TEST

+   default ARCH_BCM_5301X || ARCH_BCM_NSP
+   help
+ Enable common clock framework support for the Broadcom Northstar and
+ Northstar Plus SoCs
+
+config CLK_BCM_NS2
+   bool "Broadcom Northstar 2 clock support"
+   depends on ARM64

|| COMPILE_TEST

+   depends on COMMON_CLK_IPROC

not needed - keep hidden and do this instead
select COMMON_CLK_IPROC

+   default ARCH_BCM_IPROC
+   help
+ Enable common clock framework support for the Broadcom Northstar 2 SoC
+
+endif

remove endif

diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 2d1cbc5..05d5830 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_CLK_BCM_KONA)  += clk-kona-setup.o
  obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm281xx.o
  obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
  obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-iproc-armpll.o clk-iproc-pll.o 
clk-iproc-asiu.o
-obj-$(CONFIG_COMMON_CLK_IPROC) += clk-ns2.o

yes, change this one

-obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o

you can leave this

-obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o

you can leave this

-obj-$(CONFIG_ARCH_BCM_5301X)   += clk-nsp.o

and this

+obj-$(CONFIG_CLK_BCM_CYGNUS)   += clk-cygnus.o

no

+obj-$(CONFIG_CLK_BCM_NSP)  += clk-nsp.o

no

+obj-$(CONFIG_CLK_BCM_NS2)  += clk-ns2.o

yes needed






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] PCI: controller: Move PCI_DOMAINS selection to arch Kconfig

[Scott Branden]

On 18-06-21 09:54 AM, Lorenzo Pieralisi wrote:

On Wed, Jun 20, 2018 at 10:07:33AM +0200, Jan Kiszka wrote:

On 2018-06-19 13:21, Lorenzo Pieralisi wrote:

Commit 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
added configuration options to allow PCI host controller drivers to be
compile tested on all architectures.

Some host controller drivers (eg PCIE_ALTERA) config entries select
the PCI_DOMAINS config option to enable PCI domains management in
the kernel. Now that host controller drivers can be compiled on
all architectures, this triggers build regressions on arches that
do not implement the PCI_DOMAINS required API (ie pci_domain_nr()):

drivers/ata/pata_ali.c: In function 'ali_init_chipset':
drivers/ata/pata_ali.c:469:38: error:
 implicit declaration of function 'pci_domain_nr';
   did you mean 'pci_iomap_wc'?

Furthemore, some software configurations (ie Jailhouse) require a
PCI_DOMAINS enabled kernel to configure multiple host controllers
without having an explicit dependency on the ARM platform on which
they run.

Make PCI_DOMAINS a visible configuration option on ARM so that software
configurations that need it can manually select it and move the
PCI_DOMAINS selection from PCI controllers configuration file to ARM
sub-arch config entries that currently require it, fixing the issue.

Fixes: 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
Link: https://lkml.kernel.org/r/20180612170229.ga10...@roeck-us.net
Reported-by: Guenter Roeck 
Signed-off-by: Lorenzo Pieralisi 
Cc: Scott Branden 
Cc: Will Deacon 
Cc: Bjorn Helgaas 
Cc: Rob Herring 
Cc: Russell King 
Cc: Jan Kiszka 
Cc: Guenter Roeck 
Cc: Ley Foon Tan 
---
v1 -> v2
- Removed ARCH_VIRT PCI_DOMAINS selection
- Added PCI_DOMAINS visible config option

v1: https://marc.info/?l=linux-pci&m=152932092612352&w=2

  arch/arm/Kconfig   | 8 +++-
  arch/arm/mach-bcm/Kconfig  | 1 +
  arch/arm/mach-socfpga/Kconfig  | 1 +
  drivers/pci/controller/Kconfig | 3 ---
  4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54eeb8d00bc6..843edfd000be 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1245,8 +1245,14 @@ config PCI
  VESA. If you have PCI, say Y, otherwise N.
  
  config PCI_DOMAINS

-   bool
+   bool "Support for multiple PCI domains"
depends on PCI
+   help
+ Enable PCI domains kernel management. Say Y if your machine
+ has a PCI bus hierarchy that requires more than one PCI
+ domain (aka segment) to be correctly managed. Say N otherwise.
+
+ If you don't know what to do here, say N.
  
  config PCI_DOMAINS_GENERIC

def_bool PCI_DOMAINS
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index c46a728df44e..25aac6ee2ab1 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -20,6 +20,7 @@ config ARCH_BCM_IPROC
select GPIOLIB
select ARM_AMBA
select PINCTRL
+   select PCI_DOMAINS if PCI
help
  This enables support for systems based on Broadcom IPROC architected 
SoCs.
  The IPROC complex contains one or more ARM CPUs along with common
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index d0f62eacf59d..4adb901dd5eb 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -10,6 +10,7 @@ menuconfig ARCH_SOCFPGA
select HAVE_ARM_SCU
select HAVE_ARM_TWD if SMP
select MFD_SYSCON
+   select PCI_DOMAINS if PCI
  
  if ARCH_SOCFPGA

  config SOCFPGA_SUSPEND
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 18fa09b3ac8f..cc9fa02d32a0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -96,7 +96,6 @@ config PCI_HOST_GENERIC
depends on OF
select PCI_HOST_COMMON
select IRQ_DOMAIN
-   select PCI_DOMAINS
help
  Say Y here if you want to support a simple generic PCI host
  controller, such as the one emulated by kvmtool.
@@ -138,7 +137,6 @@ config PCI_VERSATILE
  
  config PCIE_IPROC

tristate
-   select PCI_DOMAINS
help
  This enables the iProc PCIe core controller support for Broadcom's
  iProc family of SoCs. An appropriate bus interface driver needs
@@ -176,7 +174,6 @@ config PCIE_IPROC_MSI
  config PCIE_ALTERA
bool "Altera PCIe controller"
depends on ARM || NIOS2 || COMPILE_TEST
-   select PCI_DOMAINS
help
  Say Y here if you want to enable PCIe controller support on Altera
  FPGA.


Acked-by: Jan Kiszka 

Thanks a lot. Scott, Ley Foon, does it work for you ? I would like
to ask Bjorn to send it asap since the build on sparc is still broken.

Change will have to be made for arm64 for ARCH_BCM_IPROC as well.


Thanks,
Lorenzo

[PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Scott Branden]

Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
parameter to function with efi loader.

Required to boot on existing bootloaders that do not support devicetree
provided by the platform or by the bootloader.

Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for the DTB 
loader")
Signed-off-by: Scott Branden 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f67e8d5..157cac9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -114,6 +114,7 @@ CONFIG_ARM_ARMADA_37XX_CPUFREQ=y
 CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
 CONFIG_ARM_SCPI_CPUFREQ=y
 CONFIG_ARM_TEGRA186_CPUFREQ=y
+CONFIG_EFI_ARMSTUB_DTB_LOADER=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
-- 
2.5.0

Re: [PATCH] arm64: defconfig: enable EFI_ARMSTUB_DTB_LOADER

[Scott Branden]

Hi Olof,


On 18-08-29 11:44 AM, Olof Johansson wrote:

Hi,

On Wed, Aug 29, 2018 at 10:21 AM, Scott Branden
 wrote:

Enable EFI_ARMSTUB_DTB_LOADER to add support for the dtb= command line
parameter to function with efi loader.

Required to boot on existing bootloaders that do not support devicetree
provided by the platform or by the bootloader.

Fixes: 3d7ee348aa41 ("efi/libstub/arm: Add opt-in Kconfig option for the DTB 
loader")
Signed-off-by: Scott Branden 

Why did Ard create an option for this if it's just going be turned on
in default configs? Doesn't make sense to me.

It would help to know what firmware still is crippled and how common
it is, since it's been a few years that this has been a requirement by
now.
Broadcom NS2 and Stingray in current development and production need 
this option in the kernel enabled in order to boot.



-Olof

Re: [PATCH] ASoC: cygnus: remove redundant assignment to pointer 'res'

[Scott Branden]

Looks good.


On 18-03-08 05:32 AM, Colin King wrote:

From: Colin Ian King 

The pointer res is being initialized with a value that is never read
and re-assigned immediately after, hence the initialization is redundant
and can be removed.

Cleans up clang warning:
sound/soc/bcm/cygnus-ssp.c:1284:19: warning: Value stored to 'res'
during its initialization is never read

Signed-off-by: Colin Ian King 

Acked-by: Scott Branden 

---
  sound/soc/bcm/cygnus-ssp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/bcm/cygnus-ssp.c b/sound/soc/bcm/cygnus-ssp.c
index abafadc0b534..b733f1446353 100644
--- a/sound/soc/bcm/cygnus-ssp.c
+++ b/sound/soc/bcm/cygnus-ssp.c
@@ -1281,7 +1281,7 @@ static int cygnus_ssp_probe(struct platform_device *pdev)
  {
struct device *dev = &pdev->dev;
struct device_node *child_node;
-   struct resource *res = pdev->resource;
+   struct resource *res;
struct cygnus_audio *cygaud;
int err = -EINVAL;
int node_count;

Re: [PATCH v4 1/3] dt-bindings: thermal: Add binding document for SR thermal

[Scott Branden]

On 18-09-27 10:31 AM, Florian Fainelli wrote:

On 09/27/2018 10:27 AM, Rob Herring wrote:

On Thu, Sep 27, 2018 at 09:06:41PM +0530, Srinath Mannam wrote:

From: Pramod Kumar 

Add binding document for supported thermal implementation
in Stingray.

Signed-off-by: Pramod Kumar 
Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
  .../bindings/thermal/brcm,sr-thermal.txt   | 25 ++
  1 file changed, 25 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt 
b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
new file mode 100644
index 000..717617b
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
@@ -0,0 +1,25 @@
+* Broadcom Stingray Thermal
+
+This binding describes thermal sensors that is part of Stingray SoCs.
+
+Required properties:
+- compatible : Must be "brcm,sr-thermal"
+- reg : memory where tmon data will be available.
+- brcm,tmon-mask: A one cell bit mask of valid TMON sources.
+  Each bit represents single TMON source.
+- brcm,max-crit-temp: Maximum supported critical temperature.

We already have a defined binding for setting trip points.

Indeed, and if you have multiple TMONs, they would in premise possibly
each have a different critical trip point.
Which may be a good reason to go back to our original bindings which 
were generic and had each sensor in its own node?

+
+Example:
+   tmons {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x0 0x8f10 0x100>;
+
+   tmon: thermal@0 {
+   compatible = "brcm,sr-thermal";
+   reg = <0 0x40>;
+   brcm,tmon-mask = <0x3f>;
+   brcm,max-crit-temp = <105000>;
+   };
+   };
--
2.7.4

Re: [PATCH v4 1/3] dt-bindings: thermal: Add binding document for SR thermal

[Scott Branden]

On 18-09-27 11:59 AM, Rob Herring wrote:

On Thu, Sep 27, 2018 at 11:00:33AM -0700, Scott Branden wrote:


On 18-09-27 10:31 AM, Florian Fainelli wrote:

On 09/27/2018 10:27 AM, Rob Herring wrote:

On Thu, Sep 27, 2018 at 09:06:41PM +0530, Srinath Mannam wrote:

From: Pramod Kumar 

Add binding document for supported thermal implementation
in Stingray.

Signed-off-by: Pramod Kumar 
Signed-off-by: Srinath Mannam 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
   .../bindings/thermal/brcm,sr-thermal.txt   | 25 
++
   1 file changed, 25 insertions(+)
   create mode 100644 
Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt

diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt 
b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
new file mode 100644
index 000..717617b
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
@@ -0,0 +1,25 @@
+* Broadcom Stingray Thermal
+
+This binding describes thermal sensors that is part of Stingray SoCs.
+
+Required properties:
+- compatible : Must be "brcm,sr-thermal"
+- reg : memory where tmon data will be available.
+- brcm,tmon-mask: A one cell bit mask of valid TMON sources.
+  Each bit represents single TMON source.
+- brcm,max-crit-temp: Maximum supported critical temperature.

We already have a defined binding for setting trip points.

Indeed, and if you have multiple TMONs, they would in premise possibly
each have a different critical trip point.

Which may be a good reason to go back to our original bindings which were
generic and had each sensor in its own node?

Perhaps. I wouldn't call it going back to your original, but rather
defining a complete binding. Of course, if you don't need different trip
points, then again that is just unnecessary bloat. But I can't argue
whether you do or don't.
We currently do not need different trip points as detailed analysis of 
each sensor's trip point has not been needed.  If we do add different 
trip points per sensor the node per sensor approach looks very 
flexible.  Call it what you like: Srinath's original driver.


Rob

Re: [PATCH v2] pwm: kconfig: enable kona pwm to be built for cygnus arch

[Scott Branden]

On 2018-11-21 11:00 a.m., Florian Fainelli wrote:


On 11/21/2018 4:35 AM, Clément Péron wrote:

The Cygnus architecture use a Kona PWM. This is already present
in the device tree but can't be built actually. Hence, allow the
Kona PWM to be built for Cygnus arch.

Signed-off-by: Clément Péron 

Reviewed-by: Florian Fainelli 


Reviewed-by: Scott Branden 



The "default ARCH_BCM_CYGNUS" could arguably cover ARCH_BCM_MOBILE as
well, but this is not probably worth a respin just to address that.

Yes, it's fine as is.



---
  drivers/pwm/Kconfig | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 27e5dd47a01f..982f4059f4e8 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -88,7 +88,9 @@ config PWM_BCM_IPROC
  
  config PWM_BCM_KONA

tristate "Kona PWM support"
-   depends on ARCH_BCM_MOBILE
+   depends on ARCH_BCM_MOBILE || ARCH_BCM_CYGNUS || COMPILE_TEST
+   depends on HAVE_CLK && HAS_IOMEM
+   default ARCH_BCM_CYGNUS
help
  Generic PWM framework driver for Broadcom Kona PWM block.
  

Re: [PATCH v2] PCI: controller: Move PCI_DOMAINS selection to arch Kconfig

[Scott Branden]

Hi Lorenzo,


On 18-06-25 02:27 AM, Lorenzo Pieralisi wrote:

On Fri, Jun 22, 2018 at 11:59:08PM +0800, Ley Foon Tan wrote:

On Thu, 2018-06-21 at 22:08 -0700, Scott Branden wrote:


On 18-06-21 09:54 AM, Lorenzo Pieralisi wrote:


On Wed, Jun 20, 2018 at 10:07:33AM +0200, Jan Kiszka wrote:


On 2018-06-19 13:21, Lorenzo Pieralisi wrote:


Commit 51bc085d6454 ("PCI: Improve host drivers compile test
coverage")
added configuration options to allow PCI host controller
drivers to be
compile tested on all architectures.

Some host controller drivers (eg PCIE_ALTERA) config entries
select
the PCI_DOMAINS config option to enable PCI domains management
in
the kernel. Now that host controller drivers can be compiled on
all architectures, this triggers build regressions on arches
that
do not implement the PCI_DOMAINS required API (ie
pci_domain_nr()):

drivers/ata/pata_ali.c: In function 'ali_init_chipset':
drivers/ata/pata_ali.c:469:38: error:
  implicit declaration of function 'pci_domain_nr';
    did you mean
'pci_iomap_wc'?

Furthemore, some software configurations (ie Jailhouse) require
a
PCI_DOMAINS enabled kernel to configure multiple host
controllers
without having an explicit dependency on the ARM platform on
which
they run.

Make PCI_DOMAINS a visible configuration option on ARM so that
software
configurations that need it can manually select it and move the
PCI_DOMAINS selection from PCI controllers configuration file
to ARM
sub-arch config entries that currently require it, fixing the
issue.

Fixes: 51bc085d6454 ("PCI: Improve host drivers compile test
coverage")
Link: https://lkml.kernel.org/r/20180612170229.GA10141@roeck-us
.net
Reported-by: Guenter Roeck 
Signed-off-by: Lorenzo Pieralisi 
Cc: Scott Branden 
Cc: Will Deacon 
Cc: Bjorn Helgaas 
Cc: Rob Herring 
Cc: Russell King 
Cc: Jan Kiszka 
Cc: Guenter Roeck 
Cc: Ley Foon Tan 
---
v1 -> v2
 - Removed ARCH_VIRT PCI_DOMAINS selection
 - Added PCI_DOMAINS visible config option

v1: https://marc.info/?l=linux-pci&m=152932092612352&w=2

   arch/arm/Kconfig   | 8 +++-
   arch/arm/mach-bcm/Kconfig  | 1 +
   arch/arm/mach-socfpga/Kconfig  | 1 +
   drivers/pci/controller/Kconfig | 3 ---
   4 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54eeb8d00bc6..843edfd000be 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1245,8 +1245,14 @@ config PCI
   VESA. If you have PCI, say Y, otherwise N.

   config PCI_DOMAINS
-   bool
+   bool "Support for multiple PCI domains"
 depends on PCI
+   help
+ Enable PCI domains kernel management. Say Y if your
machine
+ has a PCI bus hierarchy that requires more than one PCI
+ domain (aka segment) to be correctly managed. Say N
otherwise.
+
+ If you don't know what to do here, say N.

   config PCI_DOMAINS_GENERIC
 def_bool PCI_DOMAINS
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-
bcm/Kconfig
index c46a728df44e..25aac6ee2ab1 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -20,6 +20,7 @@ config ARCH_BCM_IPROC
 select GPIOLIB
 select ARM_AMBA
 select PINCTRL
+   select PCI_DOMAINS if PCI
 help
   This enables support for systems based on Broadcom IPROC
architected SoCs.
   The IPROC complex contains one or more ARM CPUs along
with common
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-
socfpga/Kconfig
index d0f62eacf59d..4adb901dd5eb 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -10,6 +10,7 @@ menuconfig ARCH_SOCFPGA
 select HAVE_ARM_SCU
 select HAVE_ARM_TWD if SMP
 select MFD_SYSCON
+   select PCI_DOMAINS if PCI

   if ARCH_SOCFPGA
   config SOCFPGA_SUSPEND
diff --git a/drivers/pci/controller/Kconfig
b/drivers/pci/controller/Kconfig
index 18fa09b3ac8f..cc9fa02d32a0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -96,7 +96,6 @@ config PCI_HOST_GENERIC
 depends on OF
 select PCI_HOST_COMMON
 select IRQ_DOMAIN
-   select PCI_DOMAINS
 help
   Say Y here if you want to support a simple generic PCI
host
   controller, such as the one emulated by kvmtool.
@@ -138,7 +137,6 @@ config PCI_VERSATILE

   config PCIE_IPROC
 tristate
-   select PCI_DOMAINS
 help
   This enables the iProc PCIe core controller support for
Broadcom's
   iProc family of SoCs. An appropriate bus interface driver
needs
@@ -176,7 +174,6 @@ config PCIE_IPROC_MSI
   config PCIE_ALTERA
 bool "Altera PCIe controller"
 depends on ARM || NIOS2 || COMPILE_TEST
-   select PCI_DOMAINS
 help
   Say Y here if you want to enable PCIe controller support
on Altera
   FPGA.


Acked-by: Jan Kiszka 

Thanks a lot. Scott, Ley Foon, does it work for you ? I would like
to ask Bjorn to send it asap since the build on spa

Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports

[Scott Branden]

Hi Rob,

Thanks for comment - reply inline.


On 18-06-13 12:31 PM, Florian Fainelli wrote:

On 06/12/2018 03:54 PM, Rob Herring wrote:

On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
 wrote:

Hi Rob,

Could you please kindly comment on change below.

It allows board variants to be added easily via a simple define for
different number of SATA ports.



On 18-06-04 09:22 AM, Florian Fainelli wrote:

On 05/18/2018 11:34 AM, Scott Branden wrote:

Move remaining sata configuration to stingray-sata.dtsi and enable
ports based on NUM_SATA defined.
Now, all that needs to be done is define NUM_SATA per board.

Rob could you review this and let us know if this approach is okay or
not? Thank you!


Signed-off-by: Scott Branden 
---
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
index 8c68e0c..7f6d176 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -43,7 +43,11 @@
 interrupts = ;
 #address-cells = <1>;
 #size-cells = <0>;
+#if (NUM_SATA > 0)
+   status = "okay";
+#else
 status = "disabled";
+#endif

This only works if ports are contiguously enabled (0-N). You might not
care, but it is not a pattern that works in general.
Correct - all board designs that include this dtsi file follow such 
commonality (ie. design with SATA0 first, etc).  By having common board 
designs it allows for commonality in dts files rather than duplicating 
information everywhere.  If somebody designs a bizarro board they are 
free to create their own dts file of course.

  And I'm not a fan
of C preprocessing in DT files in general beyond just defines for
single numbers.
The use of a define to specify the number of SATA ports in the board 
design meets our requirements of being able to maintain many boards.  We 
need a method to specify the number of ports in the board design rather 
than copying and pasting the information in many dts files.  If you have 
an alternative upstreamable mechanism to manage the configuration of 
many boards without copy and paste that would be ideal?

Should we interpret this as a formal NAK?

Re: [PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports

[Scott Branden]

On 18-06-13 03:06 PM, Rob Herring wrote:

On Wed, Jun 13, 2018 at 2:18 PM, Scott Branden
 wrote:

Hi Rob,

Thanks for comment - reply inline.



On 18-06-13 12:31 PM, Florian Fainelli wrote:

On 06/12/2018 03:54 PM, Rob Herring wrote:

On Thu, Jun 7, 2018 at 12:53 PM, Scott Branden
 wrote:

Hi Rob,

Could you please kindly comment on change below.

It allows board variants to be added easily via a simple define for
different number of SATA ports.



On 18-06-04 09:22 AM, Florian Fainelli wrote:

On 05/18/2018 11:34 AM, Scott Branden wrote:

Move remaining sata configuration to stingray-sata.dtsi and enable
ports based on NUM_SATA defined.
Now, all that needs to be done is define NUM_SATA per board.

Rob could you review this and let us know if this approach is okay or
not? Thank you!


Signed-off-by: Scott Branden 
---
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
index 8c68e0c..7f6d176 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -43,7 +43,11 @@
  interrupts = ;
  #address-cells = <1>;
  #size-cells = <0>;
+#if (NUM_SATA > 0)
+   status = "okay";
+#else
  status = "disabled";
+#endif

This only works if ports are contiguously enabled (0-N). You might not
care, but it is not a pattern that works in general.

Correct - all board designs that include this dtsi file follow such
commonality (ie. design with SATA0 first, etc).  By having common board
designs it allows for commonality in dts files rather than duplicating
information everywhere.  If somebody designs a bizarro board they are free
to create their own dts file of course.

   And I'm not a fan
of C preprocessing in DT files in general beyond just defines for
single numbers.

The use of a define to specify the number of SATA ports in the board design
meets our requirements of being able to maintain many boards.  We need a
method to specify the number of ports in the board design rather than
copying and pasting the information in many dts files.  If you have an
alternative upstreamable mechanism to manage the configuration of many
boards without copy and paste that would be ideal?

Is this really the only problem with maintaining lots of boards? What
about all the other nodes that are conditionally enabled? Really, I
don't see the problem with 3 lines per node.
Yes - the problem with maintaining lots of boards is having to copy and 
paste duplicated lines per nodes in many files which can be maintained 
with a single define.


Does having an unused port enabled cause problems? If not, you could
handle it all at run-time and just shutdown ports which have no link.
You'd want to do that anyway for boards with a port, but is not
connected to a drive (except for hotplug capable ports).
SATA is not the only place we use defines.  This is one change for 
review to see if there are any "real" problems with doing it upstream 
and get comment.  All the board variations simply add a few defines and 
don't need to do anything else using my approach.  No out-of-tree 
special tools or scripts required to generate dts files, no run-time 
bootloader or kernel changes necessary.


Maybe we could add a property in /chosen that is a list of nodes to
enable and either the bootloader or kernel could update their
'status'. Or It could even be done in dtc perhaps with some
/directive/.
Sure, if it is a single line change needed through a "chosen" or 
"directive" instead of a "define" that sounds fine.  How would I do that 
in the SATA example?
I am looking for an in-tree solution to managing the boards in a simpler 
manner than what is available by cutting and pasting nodes in many files.
The use of the defines allows such without any special script or tool or 
repo needing to be maintained out of tree.


Rob

[PATCH] arm64: dts: specify 1.8V EMMC capabilities for bcm958742k

[Scott Branden]

Specify 1.8V EMMC capabilities for bcm958742k board to indicate support
for UHS mode.

Fixes: d4b4aba6be8a ("arm64: dts: Initial DTS files for Broadcom Stingray SOC")
Signed-off-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index eb6f08c..77efa28 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -43,6 +43,10 @@
enet-phy-lane-swap;
 };
 
+&sdio0 {
+   mmc-ddr-1_8v;
+};
+
 &uart2 {
status = "okay";
 };
-- 
2.5.0

[PATCH] arm64: dts: stingray: use NUM_SATA to configure number of sata ports

[Scott Branden]

Move remaining sata configuration to stingray-sata.dtsi and enable
ports based on NUM_SATA defined.
Now, all that needs to be done is define NUM_SATA per board.

Signed-off-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 64 
 .../boot/dts/broadcom/stingray/bcm958742k.dts  |  2 +
 .../boot/dts/broadcom/stingray/bcm958742t.dts  |  2 +
 .../boot/dts/broadcom/stingray/stingray-sata.dtsi  | 68 ++
 4 files changed, 72 insertions(+), 64 deletions(-)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index 8862ec9..cacc25e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -72,70 +72,6 @@
  <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
 };
 
-&sata0 {
-   status = "okay";
-};
-
-&sata_phy0{
-   status = "okay";
-};
-
-&sata1 {
-   status = "okay";
-};
-
-&sata_phy1{
-   status = "okay";
-};
-
-&sata2 {
-   status = "okay";
-};
-
-&sata_phy2{
-   status = "okay";
-};
-
-&sata3 {
-   status = "okay";
-};
-
-&sata_phy3{
-   status = "okay";
-};
-
-&sata4 {
-   status = "okay";
-};
-
-&sata_phy4{
-   status = "okay";
-};
-
-&sata5 {
-   status = "okay";
-};
-
-&sata_phy5{
-   status = "okay";
-};
-
-&sata6 {
-   status = "okay";
-};
-
-&sata_phy6{
-   status = "okay";
-};
-
-&sata7 {
-   status = "okay";
-};
-
-&sata_phy7{
-   status = "okay";
-};
-
 &mdio_mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
index 77efa28..a515346 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts
@@ -32,6 +32,8 @@
 
 /dts-v1/;
 
+#define NUM_SATA   8
+
 #include "bcm958742-base.dtsi"
 
 / {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
index 5084b03..6a4d19e 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
@@ -32,6 +32,8 @@
 
 /dts-v1/;
 
+#define NUM_SATA   8
+
 #include "bcm958742-base.dtsi"
 
 / {
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
index 8c68e0c..7f6d176 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-sata.dtsi
@@ -43,7 +43,11 @@
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+   status = "okay";
+#else
status = "disabled";
+#endif
 
sata0_port0: sata-port@0 {
reg = <0>;
@@ -58,7 +62,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 0)
+   status = "okay";
+#else
status = "disabled";
+#endif
 
sata0_phy0: sata-phy@0 {
reg = <0>;
@@ -73,7 +81,11 @@
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+   status = "okay";
+#else
status = "disabled";
+#endif
 
sata1_port0: sata-port@0 {
reg = <0>;
@@ -88,7 +100,11 @@
reg-names = "phy";
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 1)
+   status = "okay";
+#else
status = "disabled";
+#endif
 
sata1_phy0: sata-phy@0 {
reg = <0>;
@@ -103,7 +119,11 @@
interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
+#if (NUM_SATA > 2)
+   status = "okay";
+#else
status = "disabled";
+#endif
 
sata2_port0: sata-port@0 {
reg = <

[PATCH 2/3] mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

[Scott Branden]

From: Corneliu Doban 

When the host controller accepts only 32bit writes, the value of the
16bit TRANSFER_MODE register, that has the same 32bit address as the
16bit COMMAND register, needs to be saved and it will be written
in a 32bit write together with the command as this will trigger the
host to send the command on the SD interface.
When sending the tuning command, TRANSFER_MODE is written and then
sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
write it again resulting in wrong value to be written because the
initial write value was saved in a shadow and the read-back returned
a wrong value, from the register.
Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
when a saved value exist.
Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
saved for a different reason, although a scenario that will cause the
mentioned problem on this registers is not probable.

Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
Signed-off-by: Corneliu Doban 
Signed-off-by: Scott Branden 
---
 drivers/mmc/host/sdhci-iproc.c | 30 +-
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 6f430da..1f0ab08 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -33,6 +33,8 @@ struct sdhci_iproc_host {
const struct sdhci_iproc_data *data;
u32 shadow_cmd;
u32 shadow_blk;
+   bool is_cmd_shadowed;
+   bool is_blk_shadowed;
 };
 
 #define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)
@@ -48,8 +50,22 @@ static inline u32 sdhci_iproc_readl(struct sdhci_host *host, 
int reg)
 
 static u16 sdhci_iproc_readw(struct sdhci_host *host, int reg)
 {
-   u32 val = sdhci_iproc_readl(host, (reg & ~3));
-   u16 word = val >> REG_OFFSET_IN_BITS(reg) & 0x;
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_iproc_host *iproc_host = sdhci_pltfm_priv(pltfm_host);
+   u32 val;
+   u16 word;
+
+   if ((reg == SDHCI_TRANSFER_MODE) && iproc_host->is_cmd_shadowed) {
+   /* Get the saved transfer mode */
+   val = iproc_host->shadow_cmd;
+   } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+  iproc_host->is_blk_shadowed) {
+   /* Get the saved block info */
+   val = iproc_host->shadow_blk;
+   } else {
+   val = sdhci_iproc_readl(host, (reg & ~3));
+   }
+   word = val >> REG_OFFSET_IN_BITS(reg) & 0x;
return word;
 }
 
@@ -105,13 +121,15 @@ static void sdhci_iproc_writew(struct sdhci_host *host, 
u16 val, int reg)
 
if (reg == SDHCI_COMMAND) {
/* Write the block now as we are issuing a command */
-   if (iproc_host->shadow_blk != 0) {
+   if (iproc_host->is_blk_shadowed) {
sdhci_iproc_writel(host, iproc_host->shadow_blk,
SDHCI_BLOCK_SIZE);
-   iproc_host->shadow_blk = 0;
+   iproc_host->is_blk_shadowed = false;
}
oldval = iproc_host->shadow_cmd;
-   } else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
+   iproc_host->is_cmd_shadowed = false;
+   } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+  iproc_host->is_blk_shadowed) {
/* Block size and count are stored in shadow reg */
oldval = iproc_host->shadow_blk;
} else {
@@ -123,9 +141,11 @@ static void sdhci_iproc_writew(struct sdhci_host *host, 
u16 val, int reg)
if (reg == SDHCI_TRANSFER_MODE) {
/* Save the transfer mode until the command is issued */
iproc_host->shadow_cmd = newval;
+   iproc_host->is_cmd_shadowed = true;
} else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
/* Save the block info until the command is issued */
iproc_host->shadow_blk = newval;
+   iproc_host->is_blk_shadowed = true;
} else {
/* Command or other regular 32-bit write */
sdhci_iproc_writel(host, newval, reg & ~3);
-- 
2.5.0

[PATCH 0/3] mmc: sdhci-iproc: UHS and 32bit access fixes

[Scott Branden]

Collection of bug fixes for sdhci-iproc driver.
- fix for 32bit writes for TRANSFER_MODE register by correcting shadow
register logic
- fix for deep sleep mode by adding SDHCI_QUIRK2_HOST_OFF_CARD_ON
- remove hard coded mmc capability of 1.8V to allow boards to be supported
that do support 1.8V.


Corneliu Doban (2):
  mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register
  mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus

Srinath Mannam (1):
  mmc: sdhci-iproc: remove hard coded mmc cap 1.8v

 drivers/mmc/host/sdhci-iproc.c | 33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

-- 
2.5.0

[PATCH 1/3] mmc: sdhci-iproc: remove hard coded mmc cap 1.8v

[Scott Branden]

From: Srinath Mannam 

Remove hard coded mmc cap 1.8v from platform data as it is board specific.
The 1.8v DDR mmc caps can be enabled using DTS property for those
boards that support it.

Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data")
Signed-off-by: Srinath Mannam 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 drivers/mmc/host/sdhci-iproc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 0ef741b..6f430da 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -206,7 +206,6 @@ static const struct sdhci_iproc_data iproc_data = {
.caps1 = SDHCI_DRIVER_TYPE_C |
 SDHCI_DRIVER_TYPE_D |
 SDHCI_SUPPORT_DDR50,
-   .mmc_caps = MMC_CAP_1_8V_DDR,
 };
 
 static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
-- 
2.5.0

[PATCH 3/3] mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus

[Scott Branden]

From: Corneliu Doban 

The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to
properly reset the host controller (reset all) on initialization
after exiting deep sleep.

Signed-off-by: Corneliu Doban 
Signed-off-by: Scott Branden 
Reviewed-by: Ray Jui 
Reviewed-by: Srinath Mannam 
---
 drivers/mmc/host/sdhci-iproc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 1f0ab08..d0e83db 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -186,7 +186,7 @@ static const struct sdhci_ops sdhci_iproc_32only_ops = {
 
 static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
.quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
-   .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
+   .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN | SDHCI_QUIRK2_HOST_OFF_CARD_ON,
.ops = &sdhci_iproc_32only_ops,
 };
 
-- 
2.5.0

Re: [PATCH v3 04/19] mailbox: bcm-flexrm: Use device-managed registration API

[Scott Branden]

Looks fine - thanks.

On 2018-12-20 9:19 a.m., Thierry Reding wrote:

From: Thierry Reding 

Get rid of some boilerplate driver removal code by using the newly added
device-managed registration API.

Cc: Vikram Prakash 
Cc: Scott Branden 
Cc: Florian Fainelli 
Cc: Ray Jui 
Signed-off-by: Thierry Reding 

Acked-by: Scott Branden 

---
  drivers/mailbox/bcm-flexrm-mailbox.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mailbox/bcm-flexrm-mailbox.c 
b/drivers/mailbox/bcm-flexrm-mailbox.c
index d7a8ed7d8097..d713271ebf7c 100644
--- a/drivers/mailbox/bcm-flexrm-mailbox.c
+++ b/drivers/mailbox/bcm-flexrm-mailbox.c
@@ -1665,7 +1665,7 @@ static int flexrm_mbox_probe(struct platform_device *pdev)
mbox->controller.chans[index].con_priv = &mbox->rings[index];
  
  	/* Register mailbox controller */

-   ret = mbox_controller_register(&mbox->controller);
+   ret = devm_mbox_controller_register(dev, &mbox->controller);
if (ret)
goto fail_free_debugfs_root;
  
@@ -1691,8 +1691,6 @@ static int flexrm_mbox_remove(struct platform_device *pdev)

struct device *dev = &pdev->dev;
struct flexrm_mbox *mbox = platform_get_drvdata(pdev);
  
-	mbox_controller_unregister(&mbox->controller);

-
debugfs_remove_recursive(mbox->root);
  
  	platform_msi_domain_free_irqs(dev);

Re: [PATCH] nvmem: bcm-ocotp: Add ACPI support to BCM OCOTP

[Scott Branden]

On 2018-12-26 7:39 p.m., Srinath Mannam wrote:

Add ACPI support to bcm ocotp driver

This patch is based on Linux-4.20-rc7.

Signed-off-by: Srinath Mannam 

Acked-by: Scott Branden 

---
  drivers/nvmem/bcm-ocotp.c | 37 -
  1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
index 4159b3f..a809751 100644
--- a/drivers/nvmem/bcm-ocotp.c
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -11,13 +11,14 @@
   * GNU General Public License for more details.
   */
  
+#include 

  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  
  /*

@@ -78,9 +79,9 @@ static struct otpc_map otp_map_v2 = {
  };
  
  struct otpc_priv {

-   struct device   *dev;
-   void __iomem*base;
-   struct otpc_map *map;
+   struct device *dev;
+   void __iomem *base;
+   const struct otpc_map *map;
struct nvmem_config *config;
  };
  
@@ -237,16 +238,22 @@ static struct nvmem_config bcm_otpc_nvmem_config = {

  };
  
  static const struct of_device_id bcm_otpc_dt_ids[] = {

-   { .compatible = "brcm,ocotp" },
-   { .compatible = "brcm,ocotp-v2" },
+   { .compatible = "brcm,ocotp", .data = &otp_map },
+   { .compatible = "brcm,ocotp-v2", .data = &otp_map_v2 },
{ },
  };
  MODULE_DEVICE_TABLE(of, bcm_otpc_dt_ids);
  
+static const struct acpi_device_id bcm_otpc_acpi_ids[] = {

+   { .id = "BRCM0700", .driver_data = (kernel_ulong_t)&otp_map },
+   { .id = "BRCM0701", .driver_data = (kernel_ulong_t)&otp_map_v2 },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(acpi, bcm_otpc_acpi_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;
@@ -257,14 +264,9 @@ static int bcm_otpc_probe(struct platform_device *pdev)
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(dev, "%s otpc config map not defined\n", __func__);
-   return -EINVAL;
-   }
+   priv->map = device_get_match_data(dev);
+   if (!priv->map)
+   return -ENODEV;
  
  	/* Get OTP base address register. */

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -281,7 +283,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
reset_start_bit(priv->base);
  
  	/* Read size of memory in words. */

-   err = of_property_read_u32(dn, "brcm,ocotp-size", &num_words);
+   err = device_property_read_u32(dev, "brcm,ocotp-size", &num_words);
if (err) {
dev_err(dev, "size parameter not specified\n");
return -EINVAL;
@@ -294,7 +296,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
bcm_otpc_nvmem_config.dev = dev;
bcm_otpc_nvmem_config.priv = priv;
  
-	if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2")) {

+   if (priv->map == &otp_map_v2) {
bcm_otpc_nvmem_config.word_size = 8;
bcm_otpc_nvmem_config.stride = 8;
}
@@ -315,6 +317,7 @@ static struct platform_driver bcm_otpc_driver = {
.driver = {
.name   = "brcm-otpc",
.of_match_table = bcm_otpc_dt_ids,
+   .acpi_match_table = ACPI_PTR(bcm_otpc_acpi_ids),
},
  };
  module_platform_driver(bcm_otpc_driver);

Re: [PATCH 1/2] dt-bindings: reset: Add document for Broadcom STB reset controller

[Scott Branden]

On 2018-12-20 5:34 p.m., Florian Fainelli wrote:

Add a binding document for the Broadcom STB reset controller, also known
as SW_INIT-style reset controller.

Signed-off-by: Florian Fainelli 
---
  .../devicetree/bindings/reset/brcm,reset.txt  | 27 +++
  1 file changed, 27 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/reset/brcm,reset.txt

diff --git a/Documentation/devicetree/bindings/reset/brcm,reset.txt 
b/Documentation/devicetree/bindings/reset/brcm,reset.txt
new file mode 100644
index ..6e5341b4f891
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/brcm,reset.txt

This is brcmstb-reset specific.  File should be brcm, brcmstb-reset.txt

@@ -0,0 +1,27 @@
+Broadcom STB SW_INIT-style reset controller
+===
+
+Broadcom STB SoCs have a SW_INIT-style reset controller with separate
+SET/CLEAR/STATUS registers and possibly multiple banks, each of 32 bit
+reset lines.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: should be brcm,brcmstb-reset
+- reg: register base and length
+- #reset-cells: must be set to 1
+
+Example:
+
+   reset: reset-controller@8404318 {
+   compatible = "brcm,brcmstb-reset";
+   reg = <0x8404318 0x30>;
+   #reset-cells = <1>;
+   };
+
+   ðernet_switch {
+   resets = <&reset>;
+   reset-names = "switch";
+   };

Re: [PATCH 1/2] pwm: kconfig: enable kona pwm to be built for cygnus arch

[Scott Branden]

On 2018-11-07 8:12 a.m., Uwe Kleine-König wrote:

On Wed, Nov 07, 2018 at 10:36:12AM +0100, Clément Péron wrote:

The Cygnus architecture use a Kona PWM. This is already present
in the device tree but can't be built actually. Hence, allow the
Kona PWM to be built for Cygnus arch.

Signed-off-by: Clément Péron 
---
  drivers/pwm/Kconfig | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50ea57d..76d56fc8b1b7 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -88,7 +88,8 @@ config PWM_BCM_IPROC
  
  config PWM_BCM_KONA

tristate "Kona PWM support"
-   depends on ARCH_BCM_MOBILE
+   depends on ARCH_BCM_MOBILE || ARCH_BCM_CYGNUS
+   default ARCH_BCM_CYGNUS

Is it possible to build this driver also on other arches? Then you might
want to consider

depends on ARCH_BCM_MOBILE || ARCH_BCM_CYGNUS || COMPILE_TEST

good idea to add the COMPILE_TEST just to increase compile coverage


Best regards
Uwe

Re: [PATCH v5 0/3] Stingray thermal driver support

[Scott Branden]

All Acked-by: Scott Branden 

On 2018-10-16 8:11 a.m., Srinath Mannam wrote:

These patches adds the stingray thermal driver and its
corresponding DT nodes with documentation.

Changes from v4
   - Addressed Rob Herring comments on DT parameters and
 thermal driver architecture.
   - Removed brcm,max-crit-temp DT parameter
   - Changed driver to thermal sensor registration model.
   - Added trip DT properties.

Changes from v3
   - Addressed Daniel lezcano comments.
   - Elaborated commit description of thermal driver patch.
   - Added brcm,max-crit-temp DT parameter.

Changes from v2:
   - All stingray TMON DT nodes are combine together into single.
 Temperature registers are combined into one mem resource.
 brcm,tmon-mask parameter has available TMONs mask value.
   - All available TMONs are initialized together in single
 instance of driver probe call.

Changes from v1:
   - Fixed auto build sparce warning.

Pramod Kumar (3):
   dt-bindings: thermal: Add binding document for SR thermal
   thermal: broadcom: Add Stingray thermal driver
   arm64: dts: stingray: Add Stingray Thermal DT support.

  .../bindings/thermal/brcm,sr-thermal.txt   | 105 
  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |  89 +
  drivers/thermal/Kconfig|   3 +-
  drivers/thermal/broadcom/Kconfig   |   9 ++
  drivers/thermal/broadcom/Makefile  |   1 +
  drivers/thermal/broadcom/sr-thermal.c  | 138 +
  6 files changed, 344 insertions(+), 1 deletion(-)
  create mode 100644 
Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
  create mode 100644 drivers/thermal/broadcom/sr-thermal.c

[PATCH] mmc: add quirk to disable eMMC cache for Micron eMMC v5.0 cards

[Scott Branden]

From: Vladimir Olovyannikov 

In certain rare combination of operations, Micron eMMC v5.0 cards
may experience data errors if internal cache is enabled.
This may lead to eMMC related data errors.
Introduce a quirk to disable cache on these eMMC cards.

Signed-off-by: Vladimir Olovyannikov 
Signed-off-by: Scott Branden 
---
 drivers/mmc/core/card.h   | 5 +
 drivers/mmc/core/mmc.c| 4 ++--
 drivers/mmc/core/quirks.h | 8 
 include/linux/mmc/card.h  | 1 +
 4 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/card.h b/drivers/mmc/core/card.h
index 7bd392d55cfa..22cea63ac359 100644
--- a/drivers/mmc/core/card.h
+++ b/drivers/mmc/core/card.h
@@ -222,4 +222,9 @@ static inline int mmc_card_broken_hpi(const struct mmc_card 
*c)
return c->quirks & MMC_QUIRK_BROKEN_HPI;
 }
 
+static inline int mmc_card_broken_cache(const struct mmc_card *c)
+{
+   return c->quirks & MMC_QUIRK_BROKEN_CACHE;
+}
+
 #endif
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 8741271d3971..cd83b7f0e59c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1820,12 +1820,12 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 * sudden power failure tests. Let's extend the timeout to a minimum of
 * DEFAULT_CACHE_EN_TIMEOUT_MS and do it for all cards.
 */
-   if (card->ext_csd.cache_size > 0) {
+   if (!mmc_card_broken_cache(card) && card->ext_csd.cache_size > 0) {
unsigned int timeout_ms = MIN_CACHE_EN_TIMEOUT_MS;
 
timeout_ms = max(card->ext_csd.generic_cmd6_time, timeout_ms);
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-   EXT_CSD_CACHE_CTRL, 1, timeout_ms);
+EXT_CSD_CACHE_CTRL, 1, timeout_ms);
if (err && err != -EBADMSG)
goto free_card;
 
diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
index d68e6e513a4f..23972d87c82a 100644
--- a/drivers/mmc/core/quirks.h
+++ b/drivers/mmc/core/quirks.h
@@ -116,6 +116,14 @@ static const struct mmc_fixup __maybe_unused 
mmc_ext_csd_fixups[] = {
MMC_FIXUP_EXT_CSD_REV(CID_NAME_ANY, CID_MANFID_NUMONYX,
  0x014e, add_quirk, MMC_QUIRK_BROKEN_HPI, 6),
 
+   /*
+* In certain rare combination of operations, Micron eMMC v5.0 cards
+* may experience data errors if internal cache is enabled.
+* Disabling cache for these cards eliminates the issue.
+*/
+   MMC_FIXUP_EXT_CSD_REV(CID_NAME_ANY, CID_MANFID_MICRON,
+ 0x014e, add_quirk, MMC_QUIRK_BROKEN_CACHE, 7),
+
END_FIXUP
 };
 
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index f9ad35dd6012..22f256a4e54e 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -270,6 +270,7 @@ struct mmc_card {
 #define MMC_QUIRK_BROKEN_IRQ_POLLING   (1<<11) /* Polling SDIO_CCCR_INTx could 
create a fake interrupt */
 #define MMC_QUIRK_TRIM_BROKEN  (1<<12) /* Skip trim */
 #define MMC_QUIRK_BROKEN_HPI   (1<<13) /* Disable broken HPI support */
+#define MMC_QUIRK_BROKEN_CACHE (1<<14) /* Disable broken cache */
 
boolreenable_cmdq;  /* Re-enable Command Queue */
 
-- 
2.17.1

Re: [PATCH 2/4] PCI: iproc: Add Broadcom iProc PCIe driver

[Scott Branden]

On 14-12-10 03:31 AM, Arnd Bergmann wrote:

On Tuesday 09 December 2014 16:04:29 Ray Jui wrote:

Add initial version of the Broadcom iProc PCIe driver. This driver
has been tested on NSP and Cygnus and is expected to work on all iProc
family of SoCs that deploys the same PCIe host controller

The driver also supports MSI

Signed-off-by: Ray Jui 
Reviewed-by: Scott Branden 


The driver looks suspiciously like the one that Hauke already submitted a
while ago for bcm53xx. Please come up with a merged driver that works for
both.
Could you please be a little more specific.  What driver did "Hauke 
already submitted"?  I do not see any driver in the kernel you are 
talking about.


Are you sure that iProc isn't based on the BCMA bus infrastructure after
all? Even the physical address of your PCI host falls into the address
range that is used for the internal BCMA bus on the other chips!
BCMA seems to be for MIPS architectures.  It seems to be quite specific 
to those architectures using BCMA.  I see no use of it in bcm53xx code?


Arnd



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mtd: add reboot notifier to mtdcore and register nand_shutdown with notifier

[Scott Branden]

add (optional) reboot notifier field to struct mtd_info, and use it to
register a system reboot notifier on behalf of the lower layers.

Add nand_shutdown to wait for current nand operations to finish and prevent
further operations by changing the nand flash state to FL_SHUTDOWN.
Register the nand_shutdown with the reboot notifier in nand_base.c

This is addressing a problem observed during reboot tests using UBIFS
root file system: NAND erase operations that are in progress during
system reboot/shutdown are causing partial erased blocks. Although UBI should
be able to detect and recover from this error, this change will avoid
the creation of partial erased blocks on reboot in the middle of a NAND erase
operation.

Signed-off-by: Brian Norris 
Signed-off-by: Corneliu Doban 
Signed-off-by: Scott Branden 
---
 drivers/mtd/mtdcore.c| 20 
 drivers/mtd/nand/nand_base.c | 11 +++
 include/linux/mtd/mtd.h  |  1 +
 3 files changed, 32 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 4c61187..b80d44f 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -365,6 +366,17 @@ static struct device_type mtd_devtype = {
.release= mtd_release,
 };
 
+static int mtd_reboot_notifier(struct notifier_block *n, unsigned long state,
+  void *cmd)
+{
+   struct mtd_info *mtd;
+
+   mtd = container_of(n, struct mtd_info, reboot_notifier);
+   mtd->_reboot(mtd);
+
+   return NOTIFY_DONE;
+}
+
 /**
  * add_mtd_device - register an MTD device
  * @mtd: pointer to new MTD device info structure
@@ -565,6 +577,11 @@ int mtd_device_parse_register(struct mtd_info *mtd, const 
char * const *types,
err = -ENODEV;
}
 
+   if (mtd->_reboot) {
+   mtd->reboot_notifier.notifier_call = mtd_reboot_notifier;
+   register_reboot_notifier(&mtd->reboot_notifier);
+   }
+
return err;
 }
 EXPORT_SYMBOL_GPL(mtd_device_parse_register);
@@ -579,6 +596,9 @@ int mtd_device_unregister(struct mtd_info *master)
 {
int err;
 
+   if (master->_reboot)
+   unregister_reboot_notifier(&master->reboot_notifier);
+
err = del_mtd_partitions(master);
if (err)
return err;
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5b5c627..e18165b 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2944,6 +2944,16 @@ static void nand_resume(struct mtd_info *mtd)
__func__);
 }
 
+/**
+ * nand_shutdown - [MTD Interface] Finish the current NAND operation and
+ * prevent further operations
+ * @mtd: MTD device structure
+ */
+static void nand_shutdown(struct mtd_info *mtd)
+{
+   nand_get_device(mtd, FL_SHUTDOWN);
+}
+
 /* Set default functions */
 static void nand_set_defaults(struct nand_chip *chip, int busw)
 {
@@ -4146,6 +4156,7 @@ int nand_scan_tail(struct mtd_info *mtd)
mtd->_unlock = NULL;
mtd->_suspend = nand_suspend;
mtd->_resume = nand_resume;
+   mtd->_reboot = nand_shutdown;
mtd->_block_isreserved = nand_block_isreserved;
mtd->_block_isbad = nand_block_isbad;
mtd->_block_markbad = nand_block_markbad;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 031ff3a..c06f537 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -227,6 +227,7 @@ struct mtd_info {
int (*_block_markbad) (struct mtd_info *mtd, loff_t ofs);
int (*_suspend) (struct mtd_info *mtd);
void (*_resume) (struct mtd_info *mtd);
+   void (*_reboot) (struct mtd_info *mtd);
/*
 * If the driver is something smart, like UBI, it may need to maintain
 * its own reference counting. The below functions are only for driver.
-- 
2.2.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mtd: nand: added nand_shutdown

[Scott Branden]

Hi Brian,

I just sent out a new patch with your changes incorporated.

Thanks,
 Scott


On 14-11-26 01:10 AM, Brian Norris wrote:

On Thu, Nov 20, 2014 at 11:18:05AM -0800, Scott Branden wrote:

Add nand_shutdown to wait for current nand operations to finish and prevent
further operations by changing the nand flash state to FL_SHUTDOWN.

This is addressing a problem observed during reboot tests using UBIFS
root file system: NAND erase operations that are in progress during
system reboot/shutdown are causing partial erased blocks. Although UBI should
be able to detect and recover from this error, this change will avoid
the creation of partial erased blocks on reboot in the middle of a NAND erase
operation.

[...]

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index e4d451e..80e4367 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -48,6 +48,13 @@ extern int nand_lock(struct mtd_info *mtd, loff_t ofs, 
uint64_t len);
  /* unlocks specified locked blocks */
  extern int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len);

+/*
+ * Internal helper for board drivers which need to make sure that the current
+ * nand operation is finished and further operations are prevented before
+ * rebooting the system.
+ */
+extern int nand_shutdown(struct mtd_info *mtd);


I don't think we should push this out to the board drivers. And I
definitely don't want to merge this function without any user. It'd turn
out like our useless nand_lock() and nand_unlock() functions.


+
  /* The maximum number of NAND chips in an array */
  #define NAND_MAX_CHIPS8



So, to do this right, I think maybe we should add an (optional)
reboot_notifier field to struct mtd_info, and use it to register a
system reboot notifier on behalf of the lower layers. We can do the
registration in mtd_device_parse_register(), I think, and any
unregistration in mtd_device_unregister().

With this approach, we can actually move the cfi_cmdset_000{1,2}.c
reboot notifiers over to the same common code. They just will have to
fill out their mtd->reboot_notifier field.

How about the following two untested patches?

From: Brian Norris 

cfi_cmdset_000{1,2}.c already implement their own reboot notifiers, and
we're going to add one for NAND. Let's put the boilerplate in one place.

Signed-off-by: Brian Norris 
---
  drivers/mtd/mtdcore.c   | 20 
  include/linux/mtd/mtd.h |  1 +
  2 files changed, 21 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 4c611871d7e6..b80d44f9751d 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
@@ -365,6 +366,17 @@ static struct device_type mtd_devtype = {
.release= mtd_release,
  };

+static int mtd_reboot_notifier(struct notifier_block *n, unsigned long state,
+  void *cmd)
+{
+   struct mtd_info *mtd;
+
+   mtd = container_of(n, struct mtd_info, reboot_notifier);
+   mtd->_reboot(mtd);
+
+   return NOTIFY_DONE;
+}
+
  /**
   *add_mtd_device - register an MTD device
   *@mtd: pointer to new MTD device info structure
@@ -565,6 +577,11 @@ int mtd_device_parse_register(struct mtd_info *mtd, const 
char * const *types,
err = -ENODEV;
}

+   if (mtd->_reboot) {
+   mtd->reboot_notifier.notifier_call = mtd_reboot_notifier;
+   register_reboot_notifier(&mtd->reboot_notifier);
+   }
+
return err;
  }
  EXPORT_SYMBOL_GPL(mtd_device_parse_register);
@@ -579,6 +596,9 @@ int mtd_device_unregister(struct mtd_info *master)
  {
int err;

+   if (master->_reboot)
+   unregister_reboot_notifier(&master->reboot_notifier);
+
err = del_mtd_partitions(master);
if (err)
return err;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 031ff3a9a0bd..c06f5373d870 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -227,6 +227,7 @@ struct mtd_info {
int (*_block_markbad) (struct mtd_info *mtd, loff_t ofs);
int (*_suspend) (struct mtd_info *mtd);
void (*_resume) (struct mtd_info *mtd);
+   void (*_reboot) (struct mtd_info *mtd);
/*
 * If the driver is something smart, like UBI, it may need to maintain
 * its own reference counting. The below functions are only for driver.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: sdhci: add quirk for ACMD23 broken

[Scott Branden]

Add quick to handle broken auto-CMD23
Some controllers do not respond after the first auto-CMD23 is issued.

This allows CMD23 to still work (mandatory for the faster UHS-I mode)
rather than disabling CMD23 entirely via SDHCI_QUIRK2_HOST_NO_CMD23.

Signed-off by: Corneliu Doban 
Signed-off-by: Scott Branden 
---
 drivers/mmc/host/sdhci.c  | 3 ++-
 include/linux/mmc/sdhci.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ada1a3e..b37331f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2985,7 +2985,8 @@ int sdhci_add_host(struct sdhci_host *host)
/* Auto-CMD23 stuff only works in ADMA or PIO. */
if ((host->version >= SDHCI_SPEC_300) &&
((host->flags & SDHCI_USE_ADMA) ||
-!(host->flags & SDHCI_USE_SDMA))) {
+!(host->flags & SDHCI_USE_SDMA)) &&
+!(host->quirks2 & SDHCI_QUIRK2_ACMD23_BROKEN)) {
host->flags |= SDHCI_AUTO_CMD23;
DBG("%s: Auto-CMD23 available\n", mmc_hostname(mmc));
} else {
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index dba793e..d979cf9 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -100,6 +100,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_BROKEN_DDR50  (1<<7)
 /* Stop command (CMD12) can set Transfer Complete when not using MMC_RSP_BUSY 
*/
 #define SDHCI_QUIRK2_STOP_WITH_TC  (1<<8)
+/* Controller broken with using ACMD23 */
+#define SDHCI_QUIRK2_ACMD23_BROKEN (1<<9)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
2.2.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mtd: add reboot notifier to mtdcore and register nand_shutdown with notifier

[Scott Branden]

Apologies:  patch fails checkpatch due to spaces instead of tabs during 
cut and paste.


But, please comment on this patch before I create a new version.

On 14-12-04 02:37 PM, Scott Branden wrote:

add (optional) reboot notifier field to struct mtd_info, and use it to
register a system reboot notifier on behalf of the lower layers.

Add nand_shutdown to wait for current nand operations to finish and prevent
further operations by changing the nand flash state to FL_SHUTDOWN.
Register the nand_shutdown with the reboot notifier in nand_base.c

This is addressing a problem observed during reboot tests using UBIFS
root file system: NAND erase operations that are in progress during
system reboot/shutdown are causing partial erased blocks. Although UBI should
be able to detect and recover from this error, this change will avoid
the creation of partial erased blocks on reboot in the middle of a NAND erase
operation.

Signed-off-by: Brian Norris 
Signed-off-by: Corneliu Doban 
Signed-off-by: Scott Branden 
---
  drivers/mtd/mtdcore.c| 20 
  drivers/mtd/nand/nand_base.c | 11 +++
  include/linux/mtd/mtd.h  |  1 +
  3 files changed, 32 insertions(+)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 4c61187..b80d44f 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -37,6 +37,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
@@ -365,6 +366,17 @@ static struct device_type mtd_devtype = {
.release= mtd_release,
  };

+static int mtd_reboot_notifier(struct notifier_block *n, unsigned long state,
+  void *cmd)
+{
+   struct mtd_info *mtd;
+
+   mtd = container_of(n, struct mtd_info, reboot_notifier);
+   mtd->_reboot(mtd);
+
+   return NOTIFY_DONE;
+}
+
  /**
   *add_mtd_device - register an MTD device
   *@mtd: pointer to new MTD device info structure
@@ -565,6 +577,11 @@ int mtd_device_parse_register(struct mtd_info *mtd, const 
char * const *types,
err = -ENODEV;
}

+   if (mtd->_reboot) {
+   mtd->reboot_notifier.notifier_call = mtd_reboot_notifier;
+   register_reboot_notifier(&mtd->reboot_notifier);
+   }
+
return err;
  }
  EXPORT_SYMBOL_GPL(mtd_device_parse_register);
@@ -579,6 +596,9 @@ int mtd_device_unregister(struct mtd_info *master)
  {
int err;

+   if (master->_reboot)
+   unregister_reboot_notifier(&master->reboot_notifier);
+
err = del_mtd_partitions(master);
if (err)
return err;
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5b5c627..e18165b 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2944,6 +2944,16 @@ static void nand_resume(struct mtd_info *mtd)
__func__);
  }

+/**
+ * nand_shutdown - [MTD Interface] Finish the current NAND operation and
+ * prevent further operations
+ * @mtd: MTD device structure
+ */
+static void nand_shutdown(struct mtd_info *mtd)
+{
+   nand_get_device(mtd, FL_SHUTDOWN);
+}
+
  /* Set default functions */
  static void nand_set_defaults(struct nand_chip *chip, int busw)
  {
@@ -4146,6 +4156,7 @@ int nand_scan_tail(struct mtd_info *mtd)
mtd->_unlock = NULL;
mtd->_suspend = nand_suspend;
mtd->_resume = nand_resume;
+   mtd->_reboot = nand_shutdown;
mtd->_block_isreserved = nand_block_isreserved;
mtd->_block_isbad = nand_block_isbad;
mtd->_block_markbad = nand_block_markbad;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 031ff3a..c06f537 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -227,6 +227,7 @@ struct mtd_info {
int (*_block_markbad) (struct mtd_info *mtd, loff_t ofs);
int (*_suspend) (struct mtd_info *mtd);
void (*_resume) (struct mtd_info *mtd);
+   void (*_reboot) (struct mtd_info *mtd);
/*
 * If the driver is something smart, like UBI, it may need to maintain
 * its own reference counting. The below functions are only for driver.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: sdhci: add quirk for ACMD23 broken

[Scott Branden]

Add quirk to handle broken auto-CMD23.
Some controllers do not respond after the first auto-CMD23 is issued.

This allows CMD23 to still work (mandatory for the faster UHS-I mode)
rather than disabling CMD23 entirely via SDHCI_QUIRK2_HOST_NO_CMD23.

Signed-off by: Corneliu Doban 
Signed-off-by: Scott Branden 
---
 drivers/mmc/host/sdhci.c  | 3 ++-
 include/linux/mmc/sdhci.h | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ada1a3e..b37331f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2985,7 +2985,8 @@ int sdhci_add_host(struct sdhci_host *host)
/* Auto-CMD23 stuff only works in ADMA or PIO. */
if ((host->version >= SDHCI_SPEC_300) &&
((host->flags & SDHCI_USE_ADMA) ||
-!(host->flags & SDHCI_USE_SDMA))) {
+!(host->flags & SDHCI_USE_SDMA)) &&
+!(host->quirks2 & SDHCI_QUIRK2_ACMD23_BROKEN)) {
host->flags |= SDHCI_AUTO_CMD23;
DBG("%s: Auto-CMD23 available\n", mmc_hostname(mmc));
} else {
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index dba793e..d979cf9 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -100,6 +100,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_BROKEN_DDR50  (1<<7)
 /* Stop command (CMD12) can set Transfer Complete when not using MMC_RSP_BUSY 
*/
 #define SDHCI_QUIRK2_STOP_WITH_TC  (1<<8)
+/* Controller broken with using ACMD23 */
+#define SDHCI_QUIRK2_ACMD23_BROKEN (1<<9)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
2.2.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] drivers: pwm: core: Add pwmchip_add_inversed

[Scott Branden]

Patchset looks good.

On 15-01-04 05:12 PM, Tim Kryger wrote:

Add a new function to register a PWM chip with channels that have their
initial polarity as inversed.  This benefits drivers of controllers that
by default operate with inversed polarity by removing the need to modify
the polarity during initialization.

Signed-off-by: Tim Kryger 

Acked-by: Scott Branden 


---
  drivers/pwm/core.c  | 36 
  include/linux/pwm.h |  6 ++
  2 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 966497d..f28c4ce 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -222,14 +222,8 @@ void *pwm_get_chip_data(struct pwm_device *pwm)
  }
  EXPORT_SYMBOL_GPL(pwm_get_chip_data);

-/**
- * pwmchip_add() - register a new PWM chip
- * @chip: the PWM chip to add
- *
- * Register a new PWM chip. If chip->base < 0 then a dynamically assigned base
- * will be used.
- */
-int pwmchip_add(struct pwm_chip *chip)
+static int pwmchip_add_with_polarity(struct pwm_chip *chip,
+enum pwm_polarity polarity)
  {
struct pwm_device *pwm;
unsigned int i;
@@ -259,6 +253,7 @@ int pwmchip_add(struct pwm_chip *chip)
pwm->chip = chip;
pwm->pwm = chip->base + i;
pwm->hwpwm = i;
+   pwm->polarity = polarity;

radix_tree_insert(&pwm_tree, pwm->pwm, pwm);
}
@@ -279,9 +274,34 @@ out:
mutex_unlock(&pwm_lock);
return ret;
  }
+
+/**
+ * pwmchip_add() - register a new PWM chip
+ * @chip: the PWM chip to add
+ *
+ * Register a new PWM chip. If chip->base < 0 then a dynamically assigned base
+ * will be used.  The initial polarity for all channels is normal.
+ */
+int pwmchip_add(struct pwm_chip *chip)
+{
+   return pwmchip_add_with_polarity(chip, PWM_POLARITY_NORMAL);
+}
  EXPORT_SYMBOL_GPL(pwmchip_add);

  /**
+ * pwmchip_add_inversed() - register a new PWM chip
+ * @chip: the PWM chip to add
+ *
+ * Register a new PWM chip. If chip->base < 0 then a dynamically assigned base
+ * will be used.  The initial polarity for all channels is inversed.
+ */
+int pwmchip_add_inversed(struct pwm_chip *chip)
+{
+   return pwmchip_add_with_polarity(chip, PWM_POLARITY_INVERSED);
+}
+EXPORT_SYMBOL_GPL(pwmchip_add_inversed);
+
+/**
   * pwmchip_remove() - remove a PWM chip
   * @chip: the PWM chip to remove
   *
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index e90628c..358547f 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -183,6 +183,7 @@ int pwm_set_chip_data(struct pwm_device *pwm, void *data);
  void *pwm_get_chip_data(struct pwm_device *pwm);

  int pwmchip_add(struct pwm_chip *chip);
+int pwmchip_add_inversed(struct pwm_chip *chip);
  int pwmchip_remove(struct pwm_chip *chip);
  struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip,
 unsigned int index,
@@ -217,6 +218,11 @@ static inline int pwmchip_add(struct pwm_chip *chip)
return -EINVAL;
  }

+static inline int pwmchip_add_inversed(struct pwm_chip *chip)
+{
+   return -EINVAL;
+}
+
  static inline int pwmchip_remove(struct pwm_chip *chip)
  {
return -EINVAL;



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

[Scott Branden]

On 15-01-14 05:02 PM, Dmitry Torokhov wrote:

Hi Jonathan,

On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:

+   if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
+   if (val < 1 || val > 256) {
+   dev_err(dev, "scanning_period must be [1-256]\n");
+   return -EINVAL;
+   }
+   priv->cfg_params.scanning_period = val;
+   }
+
+   if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
+   if (val < 0 || val > 255) {
+   dev_err(dev, "debounce_timeout must be [0-255]\n");
+   return -EINVAL;
+   }
+   priv->cfg_params.debounce_timeout = val;
+   }
+
+   if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
+   if (val < 0 || val > 11) {
+   dev_err(dev, "settling_timeout must be [0-11]\n");
+   return -EINVAL;
+   }
+   priv->cfg_params.settling_timeout = val;
+   }
+
+   if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
+   if (val < 0 || val > 255) {
+   dev_err(dev, "touch_timeout must be [0-255]\n");
+   return -EINVAL;
+   }
+   priv->cfg_params.touch_timeout = val;
+   }
+
+   if (of_property_read_u32(np, "average_data", &val) >= 0) {
+   if (val < 0 || val > 8) {
+   dev_err(dev, "average_data must be [0-8]\n");
+   return -EINVAL;
+   }
+   priv->cfg_params.average_data = val;
+   }
+
+   if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
+   if (val < 0 || val > 31) {
+   dev_err(dev, "fifo_threshold must be [0-31]\n");
+   return -EINVAL;
+   }
+   priv->cfg_params.fifo_threshold = val;
+   }


I think these are dveice specific and thus should have "brcm," prefix.
I'm confused as to why we need the brcm prefix?  Other device tree 
bindings we have for other drivers do not need such prefix.  Is this 
convention documented somewhere?



+
+   priv->ts_rotation = TS_ROTATION_0;
+   if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
+   priv->ts_rotation = val;
+   dev_dbg(dev, "ts rotation [%d] degrees\n",
+   90 * priv->ts_rotation);
+   }


This I am not quite sure about - if we want rotation or swap+invert. You
are CCed on another email (tsc2007) that talks about need of generic
touchscreen transforms in input core/of bindings.
Does such generic binding exist today?  If not, I would like to go with 
this implementation and update to the new binding if/when it exists?


Thanks.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] dt-bindings: brcm: rationalize Broadcom documentation naming

[Scott Branden]

This patchset attempts to standardize the naming of dt-bindings
documents based on the Broadcom vendor prefix of brcm.

Although there are no guidelines currently present for how to name
the dt-bindings document the "vendor,binding.txt" style is in use by
some of the other vendors.

Acked-by: Lee Jones 
Acked-by: Florian Fainelli 
Acked-by: Gregory Fong 
Acked-by: Stephen Warren 
Signed-off-by: Scott Branden 
---
 .../arm/bcm/{brcm,bcm11351-cpu-method => brcm,bcm11351-cpu-method.txt}| 0
 .../devicetree/bindings/arm/bcm/{bcm11351.txt => brcm,bcm11351.txt}   | 0
 .../devicetree/bindings/arm/bcm/{bcm21664.txt => brcm,bcm21664.txt}   | 0
 .../devicetree/bindings/arm/{bcm2835.txt => bcm/brcm,bcm2835.txt} | 0
 .../devicetree/bindings/arm/{bcm4708.txt => bcm/brcm,bcm4708.txt} | 0
 .../devicetree/bindings/arm/bcm/{bcm63138.txt => brcm,bcm63138.txt}   | 0
 .../devicetree/bindings/arm/{brcm-brcmstb.txt => bcm/brcm,brcmstb.txt}| 0
 Documentation/devicetree/bindings/arm/bcm/{cygnus.txt => brcm,cygnus.txt} | 0
 Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt}  | 0
 .../devicetree/bindings/clock/{bcm-kona-clock.txt => brcm,kona-ccu.txt}   | 0
 .../devicetree/bindings/dma/{bcm2835-dma.txt => brcm,bcm2835-dma.txt} | 0
 .../devicetree/bindings/gpio/{gpio-bcm-kona.txt => brcm,kona-gpio.txt}| 0
 .../devicetree/bindings/i2c/{i2c-bcm-kona.txt => brcm,kona-i2c.txt}   | 0
 Documentation/devicetree/bindings/mfd/{bcm590xx.txt => brcm,bcm59056.txt} | 0
 .../bindings/mips/brcm/{bcm3384-intc.txt => brcm,bcm3384-intc.txt}| 0
 Documentation/devicetree/bindings/mips/brcm/{bmips.txt => brcm,bmips.txt} | 0
 .../devicetree/bindings/mips/brcm/{cm-dsl.txt => brcm,cm-dsl.txt} | 0
 Documentation/devicetree/bindings/misc/{smc.txt => brcm,kona-smc.txt} | 0
 .../devicetree/bindings/mmc/{kona-sdhci.txt => brcm,kona-sdhci.txt}   | 0
 .../bindings/net/{broadcom-sf2.txt => brcm,bcm7445-switch-v4.0.txt}   | 0
 .../devicetree/bindings/net/{broadcom-bcmgenet.txt => brcm,bcmgenet.txt}  | 0
 .../bindings/net/{broadcom-systemport.txt => brcm,systemport.txt} | 0
 .../bindings/net/{broadcom-mdio-unimac.txt => brcm,unimac-mdio.txt}   | 0
 .../devicetree/bindings/phy/{bcm-phy.txt => brcm,kona-usb2-phy.txt}   | 0
 .../devicetree/bindings/pwm/{bcm-kona-pwm.txt => brcm,kona-pwm.txt}   | 0
 .../{arm/bcm/kona-resetmgr.txt => reset/brcm,bcm21664-resetmgr.txt}   | 0
 .../bindings/serial/{bcm63xx-uart.txt => brcm,bcm6345-uart.txt}   | 0
 .../devicetree/bindings/sound/{bcm2835-i2s.txt => brcm,bcm2835-i2s.txt}   | 0
 .../bindings/{arm/bcm/kona-timer.txt => timer/brcm,kona-timer.txt}| 0
 .../devicetree/bindings/{mips/brcm/usb.txt => usb/brcm,bcm3384-usb.txt}   | 0
 .../bindings/{arm/bcm/kona-wdt.txt => watchdog/brcm,kona-wdt.txt} | 0
 31 files changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/arm/bcm/{brcm,bcm11351-cpu-method => 
brcm,bcm11351-cpu-method.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{bcm11351.txt => 
brcm,bcm11351.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{bcm21664.txt => 
brcm,bcm21664.txt} (100%)
 rename Documentation/devicetree/bindings/arm/{bcm2835.txt => 
bcm/brcm,bcm2835.txt} (100%)
 rename Documentation/devicetree/bindings/arm/{bcm4708.txt => 
bcm/brcm,bcm4708.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{bcm63138.txt => 
brcm,bcm63138.txt} (100%)
 rename Documentation/devicetree/bindings/arm/{brcm-brcmstb.txt => 
bcm/brcm,brcmstb.txt} (100%)
 rename Documentation/devicetree/bindings/arm/bcm/{cygnus.txt => 
brcm,cygnus.txt} (100%)
 rename Documentation/devicetree/bindings/bus/{bcma.txt => brcm,bus-axi.txt} 
(100%)
 rename Documentation/devicetree/bindings/clock/{bcm-kona-clock.txt => 
brcm,kona-ccu.txt} (100%)
 rename Documentation/devicetree/bindings/dma/{bcm2835-dma.txt => 
brcm,bcm2835-dma.txt} (100%)
 rename Documentation/devicetree/bindings/gpio/{gpio-bcm-kona.txt => 
brcm,kona-gpio.txt} (100%)
 rename Documentation/devicetree/bindings/i2c/{i2c-bcm-kona.txt => 
brcm,kona-i2c.txt} (100%)
 rename Documentation/devicetree/bindings/mfd/{bcm590xx.txt => 
brcm,bcm59056.txt} (100%)
 rename Documentation/devicetree/bindings/mips/brcm/{bcm3384-intc.txt => 
brcm,bcm3384-intc.txt} (100%)
 rename Documentation/devicetree/bindings/mips/brcm/{bmips.txt => 
brcm,bmips.txt} (100%)
 rename Documentation/devicetree/bindings/mips/brcm/{cm-dsl.txt => 
brcm,cm-dsl.txt} (100%)
 rename Documentation/devicetree/bindings/misc/{smc.txt => brcm,kona-smc.txt} 
(100%)
 rename Documentation/devicetree/bindings/mmc/{kona-sdhci.txt => 
brcm,kona-sdhci.txt} (100%)
 rename Documentation/devicetree/bindings/net/{broadcom-sf2.txt => 
brcm,bcm7445-switch-v4.0.txt} (100%)
 rename Documen

Re: [PATCH 0/2] Cygnus Audio Driver

[Scott Branden]

Hi Mark,


On 15-03-30 11:43 PM, Mark Brown wrote:

On Mon, Mar 30, 2015 at 08:16:22PM -0700, Scott Branden wrote:


The audio PLL is embedded in the audio block and only used
by the audio block. The audio PLL registers are also in the middle of
the audio register map.


When you say it's only used by the audio block do you mean to say that
the audio block exposes no clock signals other than the bit and frame
clocks?


The audio block exposes the MCLK in addition to the bit and frame clock.

Regards,
 Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ASoC: cygnus-audio: adding device tree bindings

[Scott Branden]

From: Lori Hikichi 

Add device tree binding documentation for the Cygnus SOC audio block

Reviewed-by: Jonathan Richardson 
Reviewed-by: Ray Jui 
Signed-off-by: Scott Branden 
Signed-off-by: Lori Hikichi 
---
 .../bindings/sound/brcm,cygnus-audio.txt   | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt

diff --git a/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt 
b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
new file mode 100644
index 000..5358cc3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
@@ -0,0 +1,68 @@
+BROADCOM Cygnus Audio I2S/TDM/SPDIF controller
+
+Required properties:
+   - compatible : "brcm,cygnus-audio"
+   - #address-cells: 32bit valued, 1 cell. <1>
+   - #size-cells:  32bit valued, 1 cell. <1>
+   - reg : Should contain audio registers location and length
+   - interrupts: audio DMA interrupt number
+
+SSP Subnode properties:
+- dai-name: The name of the DAI registered with ASOC
+- ssp-port-id: The ssp port interface to use
+   Valid value are 0, 1, 2, or 3 (for spdif)
+- mode: Controls if this port should be configured as I2S or TDM mode.
+   Valid values are: "tdm" or "i2s"
+- tdm-bits-per-frame:  only if mode is "tdm" then this property must set.
+   Valid values are (128/256/512)
+- port-status: Controls if port is enabled or not
+   Valid values "enabled" or "disabled"
+- channel-group: Control grouping of serial port
+   Valid values are "2_0", "3_1", or "5_1"
+
+Example:
+   cygnus_audio: audio@0x180ae000 {
+   compatible = "brcm,cygnus-audio";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x180ae000 0x1000>;
+
+   interrupts = ;
+
+   ssp0: ssp_port@0 {
+   dai-name = "cygnus-ssp0";
+   ssp-port-id = <0>;
+
+   mode = "i2s"; /* "i2s" or "tdm" */
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "enabled";
+   };
+
+   ssp1: ssp_port@1 {
+   dai-name = "cygnus-ssp1";
+   ssp-port-id = <1>;
+
+   mode = "i2s"; /* "i2s" or "tdm" */
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "disabled";
+   };
+
+   ssp2: ssp_port@2 {
+   dai-name = "cygnus-ssp2";
+   ssp-port-id = <2>;
+
+   mode = "tdm"; /* "i2s" or "tdm" */
+   tdm-bits-per-frame = <256>;
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "disabled";
+   };
+
+   spdif: spdif_port@3 {
+   dai-name = "cygnus-spdif";
+   ssp-port-id = <3>;
+
+   mode = "i2s"; /* "i2s" or "tdm" */
+   channel-group = "2_0"; /* Use 2_0, 3_1, 5_1 */
+   port-status = "disabled";
+   };
+   };
-- 
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] Cygnus Audio Driver

[Scott Branden]

Please provide comments on the initial version of this driver.

This patchset contains the devicetree bindings and core audio driver
for the Cygnus SoC.

There is an open question on how to fit this driver into the clock
framework (if at all).

The audio PLL is embedded in the audio block and only used
by the audio block. The audio PLL registers are also in the middle of 
the audio register map.

In addition, the audio PLL is adjustable to less than 1 Hz.
The existing clock driver framework does not provide a mechanism to take
advantage of the resolution of the hardware.

Can the audio PLL remain within the audio driver and/or any modifications
required?

Lori Hikichi (2):
  ASoC: cygnus-audio: adding device tree bindings
  ASoC: add core audio driver for Broadcom Cygnus SOC.

 .../bindings/sound/brcm,cygnus-audio.txt   |   68 +
 sound/soc/bcm/Kconfig  |   11 +
 sound/soc/bcm/Makefile |5 +-
 sound/soc/bcm/cygnus-pcm.c |  918 +++
 sound/soc/bcm/cygnus-pcm.h |   45 +
 sound/soc/bcm/cygnus-ssp.c | 1613 
 sound/soc/bcm/cygnus-ssp.h |   84 +
 7 files changed, 2743 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/sound/brcm,cygnus-audio.txt
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-pcm.h
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

-- 
2.3.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] ASoC: add core audio driver for Broadcom Cygnus SOC.

[Scott Branden]

From: Lori Hikichi 

The audio block has 4 serial ports.  3 ports are configurable as
either I2S or TDM.  The 4th port is for SPDIF transmit.

This audio block is found on the bcm958305, bcm958300, and bcm911360.

Reviewed-by: Jonathan Richardson 
Signed-off-by: Lori Hikichi 
Signed-off-by: Scott Branden 
---
 sound/soc/bcm/Kconfig  |   11 +
 sound/soc/bcm/Makefile |5 +-
 sound/soc/bcm/cygnus-pcm.c |  918 +
 sound/soc/bcm/cygnus-pcm.h |   45 ++
 sound/soc/bcm/cygnus-ssp.c | 1613 
 sound/soc/bcm/cygnus-ssp.h |   84 +++
 6 files changed, 2675 insertions(+), 1 deletion(-)
 create mode 100644 sound/soc/bcm/cygnus-pcm.c
 create mode 100644 sound/soc/bcm/cygnus-pcm.h
 create mode 100644 sound/soc/bcm/cygnus-ssp.c
 create mode 100644 sound/soc/bcm/cygnus-ssp.h

diff --git a/sound/soc/bcm/Kconfig b/sound/soc/bcm/Kconfig
index 6a834e1..2c5ff37 100644
--- a/sound/soc/bcm/Kconfig
+++ b/sound/soc/bcm/Kconfig
@@ -7,3 +7,14 @@ config SND_BCM2835_SOC_I2S
  Say Y or M if you want to add support for codecs attached to
  the BCM2835 I2S interface. You will also need
  to select the audio interfaces to support below.
+
+config SND_SOC_CYGNUS
+   tristate "SoC platform audio for Broadcom Cygnus chips"
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   default ARCH_BCM_CYGNUS
+   help
+ Say Y if you want to add support for ASoC audio on Broadcom
+ Cygnus chips (bcm958300, bcm958305, bcm911360)
+
+ If you don't know what to do here, say N.
+
diff --git a/sound/soc/bcm/Makefile b/sound/soc/bcm/Makefile
index bc816b7..5c39790 100644
--- a/sound/soc/bcm/Makefile
+++ b/sound/soc/bcm/Makefile
@@ -1,5 +1,8 @@
 # BCM2835 Platform Support
 snd-soc-bcm2835-i2s-objs := bcm2835-i2s.o
 
-obj-$(CONFIG_SND_BCM2835_SOC_I2S) += snd-soc-bcm2835-i2s.o
+# CYGNUS Platform Support
+snd-soc-cygnus-objs := cygnus-pcm.o cygnus-ssp.o
 
+obj-$(CONFIG_SND_BCM2835_SOC_I2S) += snd-soc-bcm2835-i2s.o
+obj-$(CONFIG_SND_SOC_CYGNUS) += snd-soc-cygnus.o
diff --git a/sound/soc/bcm/cygnus-pcm.c b/sound/soc/bcm/cygnus-pcm.c
new file mode 100644
index 000..3a4106b
--- /dev/null
+++ b/sound/soc/bcm/cygnus-pcm.c
@@ -0,0 +1,918 @@
+/*
+ * Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cygnus-ssp.h"
+#include "cygnus-pcm.h"
+
+/* Register offset needed for ASoC PCM module */
+
+#define INTH_R5F_STATUS_OFFSET 0x040
+#define INTH_R5F_CLEAR_OFFSET  0x048
+#define INTH_R5F_MASK_SET_OFFSET   0x050
+#define INTH_R5F_MASK_CLEAR_OFFSET 0x054
+
+#define BF_REARM_FREE_MARK_OFFSET 0x344
+#define BF_REARM_FULL_MARK_OFFSET 0x348
+
+/* Ring Buffer Ctrl Regs --- Start */
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_RDADDR_REG_BASE */
+#define SRC_RBUF_0_RDADDR_OFFSET 0x500
+#define SRC_RBUF_1_RDADDR_OFFSET 0x518
+#define SRC_RBUF_2_RDADDR_OFFSET 0x530
+#define SRC_RBUF_3_RDADDR_OFFSET 0x548
+#define SRC_RBUF_4_RDADDR_OFFSET 0x560
+#define SRC_RBUF_5_RDADDR_OFFSET 0x578
+#define SRC_RBUF_6_RDADDR_OFFSET 0x590
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_WRADDR_REG_BASE */
+#define SRC_RBUF_0_WRADDR_OFFSET 0x504
+#define SRC_RBUF_1_WRADDR_OFFSET 0x51c
+#define SRC_RBUF_2_WRADDR_OFFSET 0x534
+#define SRC_RBUF_3_WRADDR_OFFSET 0x54c
+#define SRC_RBUF_4_WRADDR_OFFSET 0x564
+#define SRC_RBUF_5_WRADDR_OFFSET 0x57c
+#define SRC_RBUF_6_WRADDR_OFFSET 0x594
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_BASEADDR_REG_BASE */
+#define SRC_RBUF_0_BASEADDR_OFFSET 0x508
+#define SRC_RBUF_1_BASEADDR_OFFSET 0x520
+#define SRC_RBUF_2_BASEADDR_OFFSET 0x538
+#define SRC_RBUF_3_BASEADDR_OFFSET 0x550
+#define SRC_RBUF_4_BASEADDR_OFFSET 0x568
+#define SRC_RBUF_5_BASEADDR_OFFSET 0x580
+#define SRC_RBUF_6_BASEADDR_OFFSET 0x598
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_ENDADDR_REG_BASE */
+#define SRC_RBUF_0_ENDADDR_OFFSET 0x50c
+#define SRC_RBUF_1_ENDADDR_OFFSET 0x524
+#define SRC_RBUF_2_ENDADDR_OFFSET 0x53c
+#define SRC_RBUF_3_ENDADDR_OFFSET 0x554
+#define SRC_RBUF_4_ENDADDR_OFFSET 0x56c
+#define SRC_RBUF_5_ENDADDR_OFFSET 0x584
+#define SRC_RBUF_6_ENDADDR_OFFSET 0x59c
+
+/* AUD_FMM_BF_CTRL_SOURCECH_RINGBUF_X_FREE_MARK_REG_BASE */
+#define SRC_RBUF_0_FREE_MARK_OFFSET 0x510
+#define SRC_RBUF_1_FREE_MARK_OFFSET 0x528
+#define SRC_RBUF_2_FREE_MARK_OFFSET 0x540
+#define SRC_RBUF_3_FREE_MARK_OFFSET 0x558
+#defi

Re: [PATCH] dmaengine: pl330: fix the race condition in pl330 driver.

[Scott Branden]

Hi Vinod, Jassi,

Some details on the problem encountered.

On 15-03-30 10:25 AM, Vinod Koul wrote:

On Mon, Mar 30, 2015 at 10:17:17PM +0530, Jassi Brar wrote:

On Fri, Mar 27, 2015 at 5:25 AM, Scott Branden  wrote:

From: ismail 

Update the thread running index before issuing the
GO command to the DMAC.

Tested-by: Mohamed Ismail Abdul Packir Mohamed 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
Signed-off-by: Scott Branden 
Signed-off-by: Mohamed Ismail Abdul Packir Mohamed 
---
  drivers/dma/pl330.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 0e1f567..631642d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1072,11 +1072,11 @@ static bool _trigger(struct pl330_thread *thrd)
 /* Set to generate interrupts for SEV */
 writel(readl(regs + INTEN) | (1 << thrd->ev), regs + INTEN);

+   thrd->req_running = idx;
+
 /* Only manager can execute GO */
 _execute_DBGINSN(thrd, insn, true);

-   thrd->req_running = idx;
-

It would help to know what the behavior looks like before and after
the patch. If anything we should look at locking rather the
reordering.

Yes that ia fair request, looking at changelog it is hard to understand the
issue seen?

We encountered this problem as we modified the driver to make SMC calls 
to a TZ handler.  This slowed down the driver to the point where DMA 
transactions easily failed.  I believe the same could be accomplished by 
adding a delay between the GOCMD and update of the req_running and 
running the built in dmatest.


The DMA transaction is broken if the interrupt occurs before the 
thrd->req_running is updated.


The pl330 issues a GOCMD (in _trigger function) to start a new transfer.

The issue of GOCMD generates an interrupt and the IRQ handler will call 
the pl330_update function to process the interrupt.


The pl330_update function will verify the thread running index and break 
the transaction, if the thread running index is not set.


Regards,
 Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dmaengine: pl330: fix the race condition in pl330 driver.

[Scott Branden]

Hi Jassi,

Thanks for taking the time to comment on this patch and provide 
additional solution.


We have went back to reproduce the problem using the dmatest.  I am glad 
you asked for more info as we discovered the problem does not happen in 
the current code.  The problem only happens when we make additional 
modifications to the existing driver to perform some SMC calls.  Somehow 
the SMC must reenable interrupts without checking the IRQ context.  And, 
looking at the pl330 code further there are spinlock's protecting large 
chunks of code.  You have to trace up a number of functions to find 
this.  As such, this patch is not required with the current codebase.


Do you still think the new code you provided is needed to solve another 
problem?


For reference, we run in the 3.10 kernel and modify dmatest.c as follows:

--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -615,6 +615,8 @@ static int dmatest_func(void *data)
else if (thread->type == DMA_PQ)
align = dev->pq_align;

+   align = 8;
+
if (1 << align > params->buf_size) {
pr_err("%u-byte buffer too small for %d-byte 
alignment\n",
   params->buf_size, 1 << align);


And then launch dmatest:

insmod /tmp/dmatest.ko
echo 10 > /sys/kernel/debug/dmatest/iterations
echo 1 > /sys/kernel/debug/dmatest/max_channels
echo 1 > /sys/kernel/debug/dmatest/run

Next, in pl330.c add an mdelay in the _trigger function.

/* Only manager can execute GO */
_execute_DBGINSN(thrd, insn, true);

+   mdelay(1000);

thrd->req_running = idx;




On 15-03-30 10:20 PM, Jassi Brar wrote:

On Tue, Mar 31, 2015 at 9:10 AM, Scott Branden  wrote:

Hi Vinod, Jassi,

Some details on the problem encountered.


On 15-03-30 10:25 AM, Vinod Koul wrote:


On Mon, Mar 30, 2015 at 10:17:17PM +0530, Jassi Brar wrote:


On Fri, Mar 27, 2015 at 5:25 AM, Scott Branden 
wrote:


From: ismail 

Update the thread running index before issuing the
GO command to the DMAC.

Tested-by: Mohamed Ismail Abdul Packir Mohamed 
Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Reviewed-by: Scott Branden 
Signed-off-by: Scott Branden 
Signed-off-by: Mohamed Ismail Abdul Packir Mohamed 
---
   drivers/dma/pl330.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 0e1f567..631642d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1072,11 +1072,11 @@ static bool _trigger(struct pl330_thread *thrd)
  /* Set to generate interrupts for SEV */
  writel(readl(regs + INTEN) | (1 << thrd->ev), regs + INTEN);

+   thrd->req_running = idx;
+
  /* Only manager can execute GO */
  _execute_DBGINSN(thrd, insn, true);

-   thrd->req_running = idx;
-


It would help to know what the behavior looks like before and after
the patch. If anything we should look at locking rather the
reordering.


Yes that ia fair request, looking at changelog it is hard to understand
the
issue seen?


We encountered this problem as we modified the driver to make SMC calls to a
TZ handler.  This slowed down the driver to the point where DMA transactions
easily failed.  I believe the same could be accomplished by adding a delay
between the GOCMD and update of the req_running and running the built in
dmatest.

The DMA transaction is broken if the interrupt occurs before the
thrd->req_running is updated.

The pl330 issues a GOCMD (in _trigger function) to start a new transfer.

The issue of GOCMD generates an interrupt and the IRQ handler will call the
pl330_update function to process the interrupt.

The pl330_update function will verify the thread running index and break the
transaction, if the thread running index is not set.


As I suspected the locking seems screwed up. The following patch
should fix the race properly. Can you please test the attached patches
instead?

Thanks.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 0/4] Fix bugs in kona pwm driver and pwm core

[Scott Branden]

Hi Jonathan,

Patcheset looks good.
Acked-by: Scott Branden 


On 15-04-10 11:58 AM, Jonathan Richardson wrote:

This patchset fixes a number of bugs in the Broadcom Kona pwm driver. It also
fixes a bug in the pwm core where the enabled state was incorrect on failed
calls to enable. Also, a new function was added to the pwm core to add pwm chips
with inversed polarity for chips that have a different default polarity than the
core. The prevents incorrect polarity being reported.

These changes are required for the Kona pwm driver to work on Cygnus and the
same pwm IP is being used.

Changes from v5:
   - Address Dmitry's comment on code cleanup of pwm_enable() in pwm core.
   - Including all patches from different contributors in this patchset. Some
were left out in v4.

Changes from v4:
   - Rebased to Tim Kryger's patch that adds support in pwm core to add driver
 with inversed polarity.
   - Removed patch 2 that resolved difference between hardware default polarity
 and pwm framework default polarity. The default polarity is set properly 
now
 when the pwm driver is registered with the pwm framework.

Arun Ramamurthy (1):
   drivers: pwm: bcm-kona: Dont set polarity in probe

Jonathan Richardson (2):
   pwm: kona: Fix incorrect config, disable, and polarity procedures
   pwm: core: Set enable state properly on failed call to enable

Tim Kryger (1):
   drivers: pwm: core: Add pwmchip_add_inversed

  drivers/pwm/core.c |   52 +--
  drivers/pwm/pwm-bcm-kona.c |   84 +---
  include/linux/pwm.h|6 
  3 files changed, 110 insertions(+), 32 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm64: dts: specify 1.8V EMMC capabilities for bcm958742t

[Scott Branden]

Specify 1.8V EMMC capabilities for bcm958742t board to indicate support
for UHS mode.

Fixes: d4b4aba6be8a ("arm64: dts: Initial DTS files for Broadcom Stingray SOC")
Signed-off-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
index 6a4d19e..dd9de6b 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts
@@ -44,3 +44,7 @@
 &gphy0 {
enet-phy-lane-swap;
 };
+
+&sdio0 {
+   mmc-ddr-1_8v;
+};
-- 
2.5.0

[PATCH] arm64: dts: stingray: move common board components to stingray-board-base

[Scott Branden]

Move common board components from base bcm958742 dtsi file to new
stingray-board-base dtsi file so they can be shared between many stingray
boards following common design.

Signed-off-by: Scott Branden 
---
 .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 35 +--
 .../dts/broadcom/stingray/stingray-board-base.dtsi | 51 ++
 2 files changed, 52 insertions(+), 34 deletions(-)
 create mode 100644 
arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index cacc25e..d74f6df 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -30,20 +30,9 @@
  *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include "stingray.dtsi"
+#include "stingray-board-base.dtsi"
 
 / {
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
-   aliases {
-   serial0 = &uart1;
-   serial1 = &uart0;
-   serial2 = &uart2;
-   serial3 = &uart3;
-   };
-
sdio0_vddo_ctrl_reg: sdio0_vddo_ctrl {
compatible = "regulator-gpio";
regulator-name = "sdio0_vddo_ctrl_reg";
@@ -67,23 +56,6 @@
};
 };
 
-&memory { /* Default DRAM banks */
-   reg = <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
- <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
-};
-
-&mdio_mux_iproc {
-   mdio@10 {
-   gphy0: eth-phy@10 {
-   reg = <0x10>;
-   };
-   };
-};
-
-&uart1 {
-   status = "okay";
-};
-
 &pwm {
status = "okay";
 };
@@ -111,8 +83,6 @@
 };
 
 &enet {
-   phy-mode = "rgmii-id";
-   phy-handle = <&gphy0>;
status = "okay";
 };
 
@@ -133,13 +103,10 @@
 
 &sdio0 {
vqmmc-supply = <&sdio0_vddo_ctrl_reg>;
-   non-removable;
-   full-pwr-cycle;
status = "okay";
 };
 
 &sdio1 {
vqmmc-supply = <&sdio1_vddo_ctrl_reg>;
-   full-pwr-cycle;
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
new file mode 100644
index 000..82a2471
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *  Copyright(c) 2016-2018 Broadcom
+ */
+
+#include "stingray.dtsi"
+#include 
+
+/ {
+   aliases {
+   serial0 = &uart1;
+   serial1 = &uart0;
+   serial2 = &uart2;
+   serial3 = &uart3;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&memory { /* Default DRAM banks */
+   reg = <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
+ <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
+};
+
+&enet {
+   phy-mode = "rgmii-id";
+   phy-handle = <&gphy0>;
+};
+
+&uart1 {
+   status = "okay";
+};
+
+&sdio0 {
+   non-removable;
+   full-pwr-cycle;
+};
+
+&sdio1 {
+   full-pwr-cycle;
+};
+
+&mdio_mux_iproc {
+   mdio@10 {
+   gphy0: eth-phy@10 {
+   reg = <0x10>;
+   };
+   };
+};
-- 
2.5.0

Re: [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate

[Scott Branden]

On 18-05-22 04:24 PM, Ray Jui wrote:

Hi Guenter,

On 5/22/2018 1:54 PM, Guenter Roeck wrote:

On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:

If the watchdog hardware is already enabled during the boot process,
when the Linux watchdog driver loads, it should reset the watchdog and
tell the watchdog framework. As a result, ping can be generated from
the watchdog framework, until the userspace watchdog daemon takes over
control

Signed-off-by: Ray Jui 
Reviewed-by: Vladimir Olovyannikov 
Reviewed-by: Scott Branden 
---
  drivers/watchdog/sp805_wdt.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/drivers/watchdog/sp805_wdt.c 
b/drivers/watchdog/sp805_wdt.c

index 1484609..408ffbe 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -42,6 +42,7 @@
  /* control register masks */
  #define    INT_ENABLE    (1 << 0)
  #define    RESET_ENABLE    (1 << 1)
+    #define    ENABLE_MASK    (INT_ENABLE | RESET_ENABLE)
  #define WDTINTCLR    0x00C
  #define WDTRIS    0x010
  #define WDTMIS    0x014
@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
  MODULE_PARM_DESC(nowayout,
  "Set to 1 to keep watchdog running after device release");
  +/* returns true if wdt is running; otherwise returns false */
+static bool wdt_is_running(struct watchdog_device *wdd)
+{
+    struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
+
+    if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
+    ENABLE_MASK)
+    return true;
+    else
+    return false;


return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));



Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE); 
therefore, a simple !!(expression) would not work? That is, the masked 
result needs to be compared against the mask again to ensure both bits 
are set, right?
Ray - your original code looks correct to me.  Easier to read and less 
prone to errors as shown in the attempted translation to a single statement.


Thanks,

Ray

Re: [PATCH 3/5] watchdog: sp805: set WDOG_HW_RUNNING when appropriate

[Scott Branden]

Raym


On 18-05-23 09:29 AM, Ray Jui wrote:

Hi Robin,

On 5/23/2018 4:48 AM, Robin Murphy wrote:

On 23/05/18 08:52, Scott Branden wrote:



On 18-05-22 04:24 PM, Ray Jui wrote:

Hi Guenter,

On 5/22/2018 1:54 PM, Guenter Roeck wrote:

On Tue, May 22, 2018 at 11:47:18AM -0700, Ray Jui wrote:

If the watchdog hardware is already enabled during the boot process,
when the Linux watchdog driver loads, it should reset the 
watchdog and

tell the watchdog framework. As a result, ping can be generated from
the watchdog framework, until the userspace watchdog daemon takes 
over

control

Signed-off-by: Ray Jui 
Reviewed-by: Vladimir Olovyannikov 


Reviewed-by: Scott Branden 
---
  drivers/watchdog/sp805_wdt.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/drivers/watchdog/sp805_wdt.c 
b/drivers/watchdog/sp805_wdt.c

index 1484609..408ffbe 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -42,6 +42,7 @@
  /* control register masks */
  #define    INT_ENABLE    (1 << 0)
  #define    RESET_ENABLE    (1 << 1)
+    #define    ENABLE_MASK    (INT_ENABLE | RESET_ENABLE)
  #define WDTINTCLR    0x00C
  #define WDTRIS    0x010
  #define WDTMIS    0x014
@@ -74,6 +75,18 @@ module_param(nowayout, bool, 0);
  MODULE_PARM_DESC(nowayout,
  "Set to 1 to keep watchdog running after device release");
  +/* returns true if wdt is running; otherwise returns false */
+static bool wdt_is_running(struct watchdog_device *wdd)
+{
+    struct sp805_wdt *wdt = watchdog_get_drvdata(wdd);
+
+    if ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) ==
+    ENABLE_MASK)
+    return true;
+    else
+    return false;


return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));



Note ENABLE_MASK contains two bits (INT_ENABLE and RESET_ENABLE); 
therefore, a simple !!(expression) would not work? That is, the 
masked result needs to be compared against the mask again to ensure 
both bits are set, right?
Ray - your original code looks correct to me.  Easier to read and 
less prone to errors as shown in the attempted translation to a 
single statement.


 if ()
 return true;
 else
 return false;

still looks really dumb, though, and IMO is actually harder to read 
than just "return ;" because it forces you to stop 
and double-check that the logic is, in fact, only doing the obvious 
thing.


If you can propose a way to modify my original code above to make it 
more readable, I'm fine to make the change.


As I mentioned, I don't think the following change proposed by Guenter 
will work due to the reason I pointed out:


return !!(readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK));

What they are looking for is:
return ((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) == 
ENABLE_MASK);


or maybe:
return !!((readl_relaxed(wdt->base + WDTCONTROL) & ENABLE_MASK) == 
ENABLE_MASK);




Robin.



p.s. No thanks for making me remember the mind-boggling horror of 
briefly maintaining part of this legacy codebase... :P


$ grep -r '? true : false' --include=*.cpp . | wc -l
951

[PATCH] arm64: dts: stingray: Add otp device node

[Scott Branden]

Add otp device node for Stingray SOC.

Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
Signed-off-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index 99aaff0..6013478 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -258,6 +258,13 @@
 
#include "stingray-clock.dtsi"
 
+   otp: otp@1c400 {
+   compatible = "brcm,ocotp-v2";
+   reg = <0x0001c400 0x68>;
+   brcm,ocotp-size = <2048>;
+   status = "okay";
+   };
+
gpio_crmu: gpio@24800 {
compatible = "brcm,iproc-gpio";
reg = <0x00024800 0x4c>;
-- 
2.5.0

Re: [PATCH] arm64: dts: stingray: Add otp device node

[Scott Branden]

Hi Florian,


On 18-06-04 02:24 PM, Florian Fainelli wrote:

On 05/23/2018 01:17 PM, Scott Branden wrote:

Add otp device node for Stingray SOC.

Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
Signed-off-by: Scott Branden 

Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
line since that is not a bug fix AFAICT.

It fixes the issue that OTP is not active as it is missing the device node?


Thank you

Re: [PATCH] arm64: dts: stingray: move common board components to stingray-board-base

[Scott Branden]

Hi Florian,


On 18-06-04 02:09 PM, Florian Fainelli wrote:

On 05/22/2018 11:55 AM, Scott Branden wrote:

Move common board components from base bcm958742 dtsi file to new
stingray-board-base dtsi file so they can be shared between many stingray
boards following common design.

Signed-off-by: Scott Branden 


Applied to devicetree-arm64/next, though this did not apply cleanly,
please check the results at:

https://github.com/Broadcom/stblinux/commit/0b2cf5a855cd235fa95fbdfedfc524a97a71a7fe

It's looks fine.



---
  .../boot/dts/broadcom/stingray/bcm958742-base.dtsi | 35 +--
  .../dts/broadcom/stingray/stingray-board-base.dtsi | 51 ++
  2 files changed, 52 insertions(+), 34 deletions(-)
  create mode 100644 
arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
index cacc25e..d74f6df 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/bcm958742-base.dtsi
@@ -30,20 +30,9 @@
   *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   */
  
-#include "stingray.dtsi"

+#include "stingray-board-base.dtsi"
  
  / {

-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
-   aliases {
-   serial0 = &uart1;
-   serial1 = &uart0;
-   serial2 = &uart2;
-   serial3 = &uart3;
-   };
-
sdio0_vddo_ctrl_reg: sdio0_vddo_ctrl {
compatible = "regulator-gpio";
regulator-name = "sdio0_vddo_ctrl_reg";
@@ -67,23 +56,6 @@
};
  };
  
-&memory { /* Default DRAM banks */

-   reg = <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
- <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
-};
-
-&mdio_mux_iproc {
-   mdio@10 {
-   gphy0: eth-phy@10 {
-   reg = <0x10>;
-   };
-   };
-};
-
-&uart1 {
-   status = "okay";
-};
-
  &pwm {
status = "okay";
  };
@@ -111,8 +83,6 @@
  };
  
  &enet {

-   phy-mode = "rgmii-id";
-   phy-handle = <&gphy0>;
status = "okay";
  };
  
@@ -133,13 +103,10 @@
  
  &sdio0 {

vqmmc-supply = <&sdio0_vddo_ctrl_reg>;
-   non-removable;
-   full-pwr-cycle;
status = "okay";
  };
  
  &sdio1 {

vqmmc-supply = <&sdio1_vddo_ctrl_reg>;
-   full-pwr-cycle;
status = "okay";
  };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi 
b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
new file mode 100644
index 000..82a2471
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-board-base.dtsi
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *  Copyright(c) 2016-2018 Broadcom
+ */
+
+#include "stingray.dtsi"
+#include 
+
+/ {
+   aliases {
+   serial0 = &uart1;
+   serial1 = &uart0;
+   serial2 = &uart2;
+   serial3 = &uart3;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+&memory { /* Default DRAM banks */
+   reg = <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
+ <0x0008 0x8000 0x1 0x8000>; /* 6G @ 34G */
+};
+
+&enet {
+   phy-mode = "rgmii-id";
+   phy-handle = <&gphy0>;
+};
+
+&uart1 {
+   status = "okay";
+};
+
+&sdio0 {
+   non-removable;
+   full-pwr-cycle;
+};
+
+&sdio1 {
+   full-pwr-cycle;
+};
+
+&mdio_mux_iproc {
+   mdio@10 {
+   gphy0: eth-phy@10 {
+   reg = <0x10>;
+   };
+   };
+};

Re: [PATCH] arm64: dts: stingray: Add otp device node

[Scott Branden]

On 18-06-04 02:33 PM, Florian Fainelli wrote:

On 06/04/2018 02:30 PM, Scott Branden wrote:

Hi Florian,


On 18-06-04 02:24 PM, Florian Fainelli wrote:

On 05/23/2018 01:17 PM, Scott Branden wrote:

Add otp device node for Stingray SOC.

Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
Signed-off-by: Scott Branden 

Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
line since that is not a bug fix AFAICT.

It fixes the issue that OTP is not active as it is missing the device node?

By that token, any peripheral that is being added at some point in the
lifetime of this DTS would qualify as a bugfix when it is in fact
feature/peripheral enabling.

I could not see the relationship between the commit being provided in
the "Fixes:" tag and OTP, am I missing something?
The relationship is the fixes tag points was selected to the last tag 
when the commit applies directly against (and is far enough back that it 
covers any possible LTS kernels that would have needed it). In this case 
I don't care too much about whether this is fixed in LTS or not.  If 
needed I'll send a request for the commit be ported to stable.

Re: [PATCH] arm64: dts: stingray: Add otp device node

[Scott Branden]

On 18-06-04 03:41 PM, Florian Fainelli wrote:

On 06/04/2018 03:33 PM, Scott Branden wrote:


On 18-06-04 02:33 PM, Florian Fainelli wrote:

On 06/04/2018 02:30 PM, Scott Branden wrote:

Hi Florian,


On 18-06-04 02:24 PM, Florian Fainelli wrote:

On 05/23/2018 01:17 PM, Scott Branden wrote:

Add otp device node for Stingray SOC.

Fixes: 2fa9e9e29ea2 ("arm64: dts: Add GPIO DT nodes for Stingray SOC")
Signed-off-by: Scott Branden 

Applied to devicetree-arm64/next with s/otp/OTP/ and removing the Fixes
line since that is not a bug fix AFAICT.

It fixes the issue that OTP is not active as it is missing the device
node?

By that token, any peripheral that is being added at some point in the
lifetime of this DTS would qualify as a bugfix when it is in fact
feature/peripheral enabling.

I could not see the relationship between the commit being provided in
the "Fixes:" tag and OTP, am I missing something?

The relationship is the fixes tag points was selected to the last tag
when the commit applies directly against (and is far enough back that it
covers any possible LTS kernels that would have needed it).

I understand how ones gets to select an appropriate Fixes: tag, what I
don't understand is the relationship between the two changes, like why
would a GPIO Device Tree node influence the OTP peripheral here when
there is no pinmux or GPIO phandle of some sort linking the two. Also,
since you guys were very trigger happy with Fixes: tag lately (referring
to the internal review of Srinath's changes) this one looked a lot like
that.

The only thing I am questioning here is treating that particular
changeset as a bugfix proper. Yes it is technically a fix in that,
without this changeset the OTP node is not there and that is
functionality you want, but it is not preventing the platform from not
booting for instance, or having an incorrect behavior for an established
behavior before, right?


In this case
I don't care too much about whether this is fixed in LTS or not.  If
needed I'll send a request for the commit be ported to stable.

If this is a true fix, I don't mind taking it as-is and keeping the
Fixes: tag, keep in mind the following:

I always treat bug fixes with a higher priority than features, and I
will do my best to queue up fixes (separate branches, all ending in
/fixes) and submit those at any time in the release cycle so they can
land in Linus' tree and in the -stable trees as fast as possible.

Don't bypass the maintainer if you can convince me this is a proper fix,
then I will just move that patch into the appropriate branch, and you
will get those stable backports automatically.
For now, nobody needs it in the LTS.  The OTP driver hasn't actively 
been used by applications.
So not critical for backport right now.  It's in now so OTP won't be a 
problem going forward.

Thanks for reading me.

Re: [PATCH 1/1] net: dsa: b53: Fix for brcm tag issue in Cygnus SoC

[Scott Branden]

Clement,

Please test this works for your issue.


On 18-06-05 01:38 PM, Arun Parameswaran wrote:

In the Broadcom Cygnus SoC, the brcm tag needs to be inserted
in between the mac address and the ether type (should use
'DSA_PROTO_TAG_BRCM') for the packets sent to the internal
b53 switch.

Since the Cygnus was added with the BCM58XX device id and the
BCM58XX uses 'DSA_PROTO_TAG_BRCM_PREPEND', the data path is
broken, due to the incorrect brcm tag location.

Add a new b53 device id (BCM583XX) for Cygnus family to fix the
issue. Add the new device id to the BCM58XX family as Cygnus
is similar to the BCM58XX in most other functionalities.

Fixes: 11606039604c ("net: dsa: b53: Support prepended Broadcom tags")

Signed-off-by: Arun Parameswaran 

Acked-by: Scott Branden 

---
  drivers/net/dsa/b53/b53_common.c | 15 ++-
  drivers/net/dsa/b53/b53_priv.h   |  2 ++
  drivers/net/dsa/b53/b53_srab.c   |  4 ++--
  3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 3da5fca..bbc6cc6 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -684,7 +684,8 @@ static int b53_switch_reset(struct b53_device *dev)
 * still use this driver as a library and need to perform the reset
 * earlier.
 */
-   if (dev->chip_id == BCM58XX_DEVICE_ID) {
+   if (dev->chip_id == BCM58XX_DEVICE_ID ||
+   dev->chip_id == BCM583XX_DEVICE_ID) {
b53_read8(dev, B53_CTRL_PAGE, B53_SOFTRESET, ®);
reg |= SW_RST | EN_SW_RST | EN_CH_RST;
b53_write8(dev, B53_CTRL_PAGE, B53_SOFTRESET, reg);
@@ -1880,6 +1881,18 @@ struct b53_chip_data {
.jumbo_size_reg = B53_JUMBO_MAX_SIZE,
},
{
+   .chip_id = BCM583XX_DEVICE_ID,
+   .dev_name = "BCM583xx/11360",
+   .vlans = 4096,
+   .enabled_ports = 0x103,
+   .arl_entries = 4,
+   .cpu_port = B53_CPU_PORT,
+   .vta_regs = B53_VTA_REGS,
+   .duplex_reg = B53_DUPLEX_STAT_GE,
+   .jumbo_pm_reg = B53_JUMBO_PORT_MASK,
+   .jumbo_size_reg = B53_JUMBO_MAX_SIZE,
+   },
+   {
.chip_id = BCM7445_DEVICE_ID,
.dev_name = "BCM7445",
.vlans  = 4096,
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 3b57f47..b232aaa 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -62,6 +62,7 @@ enum {
BCM53018_DEVICE_ID = 0x53018,
BCM53019_DEVICE_ID = 0x53019,
BCM58XX_DEVICE_ID = 0x5800,
+   BCM583XX_DEVICE_ID = 0x58300,
BCM7445_DEVICE_ID = 0x7445,
BCM7278_DEVICE_ID = 0x7278,
  };
@@ -181,6 +182,7 @@ static inline int is5301x(struct b53_device *dev)
  static inline int is58xx(struct b53_device *dev)
  {
return dev->chip_id == BCM58XX_DEVICE_ID ||
+   dev->chip_id == BCM583XX_DEVICE_ID ||
dev->chip_id == BCM7445_DEVICE_ID ||
dev->chip_id == BCM7278_DEVICE_ID;
  }
diff --git a/drivers/net/dsa/b53/b53_srab.c b/drivers/net/dsa/b53/b53_srab.c
index c37ffd1..8247481 100644
--- a/drivers/net/dsa/b53/b53_srab.c
+++ b/drivers/net/dsa/b53/b53_srab.c
@@ -364,7 +364,7 @@ static int b53_srab_write64(struct b53_device *dev, u8 
page, u8 reg,
{ .compatible = "brcm,bcm53018-srab" },
{ .compatible = "brcm,bcm53019-srab" },
{ .compatible = "brcm,bcm5301x-srab" },
-   { .compatible = "brcm,bcm11360-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
+   { .compatible = "brcm,bcm11360-srab", .data = (void 
*)BCM583XX_DEVICE_ID },
{ .compatible = "brcm,bcm58522-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm58525-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm58535-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
@@ -372,7 +372,7 @@ static int b53_srab_write64(struct b53_device *dev, u8 
page, u8 reg,
{ .compatible = "brcm,bcm58623-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm58625-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
{ .compatible = "brcm,bcm88312-srab", .data = (void *)BCM58XX_DEVICE_ID 
},
-   { .compatible = "brcm,cygnus-srab", .data = (void *)BCM58XX_DEVICE_ID },
+   { .compatible = "brcm,cygnus-srab", .data = (void *)BCM583XX_DEVICE_ID 
},
{ .compatible = "brcm,nsp-srab", .data = (void *)BCM58XX_DEVICE_ID },
{ /* sentinel */ },
  };

Re: [PATCH] ARM: dts: cygnus: Add HWRNG node

[Scott Branden]

Hi Clement,


On 18-06-06 02:34 AM, Clément Péron wrote:

From: Clément Peron 

There is a HWRNG in Broadcom Cygnus SoC, so enable it.

Signed-off-by: Clément Peron 

Thanks for upstreaming some missing Cygnus components.

But, the problem is the tarball release from Broadcom you are extracting 
these changes from does not contain git history; so, you are missing the 
original authors and signed-off's.

I checked our internal git repository and for this commit the author is:
Mohamed Ismail Abdul Packir Mohamed 

Please adjust author and signed-off appropriately.  If there are other 
changes you are extracting from the source tarballs you have please 
contact me so we can construct patch appropriately.


Regards,
Scott

---
  arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 1cee40ac4613..b7178e84d56d 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -452,6 +452,11 @@
status = "disabled";
};
  
+		hwrng: hwrng@18032000 {

+   compatible = "brcm,iproc-rng200";
+   reg = <0x18032000 0x28>;
+   };
+
sdhci0: sdhci@18041000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x18041000 0x100>;

Re: [PATCH] ARM: dts: cygnus: Add HWRNG node

[Scott Branden]

On 18-06-06 09:47 AM, Florian Fainelli wrote:

On 06/06/2018 09:03 AM, Scott Branden wrote:

Hi Clement,


On 18-06-06 02:34 AM, Clément Péron wrote:

From: Clément Peron 

There is a HWRNG in Broadcom Cygnus SoC, so enable it.

Signed-off-by: Clément Peron 

Thanks for upstreaming some missing Cygnus components.

But, the problem is the tarball release from Broadcom you are extracting
these changes from does not contain git history; so, you are missing the
original authors and signed-off's.
I checked our internal git repository and for this commit the author is:
Mohamed Ismail Abdul Packir Mohamed 

Please adjust author and signed-off appropriately.  If there are other
changes you are extracting from the source tarballs you have please
contact me so we can construct patch appropriately.

If you want the original author's Signed-off-by to be preserved, why
don't you extract it from your internal git tree and submit the patch on
Mohamed's behalf?
Sure, I can submit the original patch to keep things simple and avoid 
finding a lawyer right now.


AFAICT what Clement is doing here is permissible given the Linux
developer certificate of origin though I am not a lawyer of course.
But, It would be great to get some guidance and clarification on this 
for sure.

I'm reading:
https://www.kernel.org/doc/html/v4.16/process/submitting-patches.html

The change was created entirely by Broadcom, so seems difficult for 
somebody else to upstream change without appropriate authorship and 
signed off from copyright holder.  Point a) and b) are not met in 
Developer's Certificate of Origin while point c) is being attempted 
(without a or b being certified).

Re: [PATCH] ARM: dts: cygnus: Add HWRNG node

[Scott Branden]

On 18-06-06 10:06 AM, Clément Péron wrote:

Hi Scott, Florian,

On Wed, 6 Jun 2018 at 18:47, Florian Fainelli  wrote:

On 06/06/201 8 09:03 AM, Scott Branden wrote:

Hi Clement,


On 18-06-06 02:34 AM, Clément Péron wrote:

From: Clément Peron 

There is a HWRNG in Broadcom Cygnus SoC, so enable it.

Signed-off-by: Clément Peron 

Thanks for upstreaming some missing Cygnus components.

But, the problem is the tarball release from Broadcom you are extracting
these changes from does not contain git history; so, you are missing the
original authors and signed-off's.
I checked our internal git repository and for this commit the author is:
Mohamed Ismail Abdul Packir Mohamed 

Please adjust author and signed-off appropriately.  If there are other
changes you are extracting from the source tarballs you have please
contact me so we can construct patch appropriately.

If you want the original author's Signed-off-by to be preserved, why
don't you extract it from your internal git tree and submit the patch on
Mohamed's behalf?

AFAICT what Clement is doing here is permissible given the Linux
developer certificate of origin though I am not a lawyer of course.
--
Florian

Totally not my goal to steal the author and agree to keep track of the
original author
as soon as it's possible. I didn't though it was important for this
patch as the same
code is available in the dt-bindings documentation.

Actually there are still some buggy components like DSA (Arun proposed
a patch this morning)
the PWM (config and delay aren't correct) and I2C. These are mainlined
but can't be used
and need a minimal effort to correctly work on Cygnus.
We have internal versions of most everything.  It's a matter of getting 
people to push the appropriate patches out for upstream version to work.
Please contact the bcm-kernel-feedback list with issues and we can work 
through common solution (or, likely already have a solution just not 
upstreamed).


Also there are some important components like USB Phy or Mailbox that
were proposed and
almost made it, but just need a small modification to be accepted.
Again - we may have internal solution already.  Yes, mailbox was 
submitted upstream a long time ago and I think got stalled being 
accepted upstream.  We can work through upstream solution by starting 
with sending to bcm-kernel-feedback-list to discuss details.


My idea was just to submit small patches that are trivial to review.
In order to avoid keeping
lots of patches in our kernel and also have something functional when
building a mainline kernel.
I understand the difficulty you would have if you're trying to work with 
a different kernel version in our release.  If you send me a list 
directly of the drivers you use in Cygnus that will help me get those 
changes prioritized to be pushed upstream.  And/or we can work together 
on that.


Regards,
Clement

Thanks,
 Scott

[PATCH v2 1/1] ARM: dts: cygnus: enable iproc-hwrng

[Scott Branden]

From: Mohamed Ismail Abdul Packir Mohamed 

Enable the HW rng driver "iproc-rng200" for all cygnus platforms.

Signed-off-by: Mohamed Ismail Abdul Packir Mohamed 

Reviewed-by: Ray Jui 
Signed-off-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 9fe4f5a..b0e38fa 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -417,6 +417,11 @@
status = "disabled";
};
 
+   rng: rng@18032000 {
+   compatible = "brcm,iproc-rng200";
+   reg = <0x18032000 0x28>;
+   };
+
sdhci0: sdhci@18041000 {
compatible = "brcm,sdhci-iproc-cygnus";
reg = <0x18041000 0x100>;
-- 
2.5.0

Re: [PATCH 1/2] dt-bindings: rng: bcm2835: document reset support

[Scott Branden]

On 2021-02-23 8:36 a.m., Florian Fainelli wrote:
> 
> 
> On 2/23/2021 8:01 AM, Álvaro Fernández Rojas wrote:
>> Some devices may need to perform a reset before using the RNG, such as the
>> BCM6368.
>>
>> Signed-off-by: Álvaro Fernández Rojas 
> 
> Since the reset is unique to the 6368, you may want to make the property
> mandatory for the 6368 compatible string and optional otherwise.
> 
Perhaps the reset could be done at an earlier boot stage as well and then the
reset would even be optional on 6368?


smime.p7s
Description: S/MIME Cryptographic Signature

Re: 5.10 LTS Kernel: 2 or 6 years?

[Scott Branden]

Hi Greg,

On 2021-02-17 1:40 a.m., Greg Kroah-Hartman wrote:
> On Tue, Jan 26, 2021 at 07:51:18PM +0100, Greg Kroah-Hartman wrote:
>> On Tue, Jan 26, 2021 at 10:30:16AM -0800, Scott Branden wrote:
>>> Hi Greg,
>>>
>>>
>>> On 2021-01-25 11:29 p.m., Greg Kroah-Hartman wrote:
>>>> On Mon, Jan 25, 2021 at 11:55:11AM -0800, Scott Branden wrote:
>>>>> Hi All,
>>>>>
>>>>> The 5.10 LTS kernel being officially LTS supported for 2 years presents a 
>>>>> problem:
>>>>> why would anyone select a 5.10 kernel with 2 year LTS when 5.4 kernel has 
>>>>> a 6 year LTS.
>>>> Because they want to use all of the latest stuff that 5.10 provides
>>>> them.  Don't you want faster and more secure kernels for your devices?
>>> Yes, 5.10 is a more secure and less buggy kernel than 5.4.
>>
>> Great, use it, ship it to your customers and we are all happy.  What do
>> you need me for any of this?  :)
>>
>>>>>   And AOSP has already declared the use
>>>>> of 5.10 kernel in their Android S and T releases.
>>>> Publically?  Where?  And is that really the name of the new Android
>>>> releases, I thought they switched to numbers now (hence the naming of
>>>> the current android-common kernel branches, marketing is fun...)
>>> https://source.android.com/devices/architecture/kernel/android-common
>>> Feature and launch kernels provides kernels supported per version.
>>
>> Oh nice, didn't know that.
>>
>> But note, Android kernels do not reflect the lifespan of LTS kernels.
>> If that were the case, I would still be supporting 3.18 as they are
>> doing that at the moment for their devices and customers, and will be
>> doing so for I think another full year.
>>
>> So while Android is nice to see here, remember that is what Google is
>> promising to support for their users.  You can do the same thing for
>> your users, what do you need me here for this?  You can do the same
>> thing that Google is doing for 3.18 right now, pick the stable fixes
>> from upstream, backport them, test them, and push them out to their
>> users.
>>
>> While Google is a great help to me in the LTS effort, providing huge
>> amounts of resources to enable my life easier with this (i.e. funding
>> Linaro's testing efforts), their promise to their customers/users does
>> not depend on me keeping LTS kernels alive, if I stopped tomorrow their
>> contracts are still in place and they know how to do this work
>> themselves (as is proof with 3.18).
>>
>> So you can provide the same kind of guarantee to support any kernel
>> version for any amount of time to any customer you like, it shouldn't
>> require me to do that work for you, right?
>>
>>>>> Is there some way we could make the LTS support more clear.
>>>>> A 2 year declaration is not LTS any more.
>>>> Not true at all, a "normal" stable kernel is dropped after the next
>>>> release happens, making their lifespan about 4 months long.  2 years is
>>>> much longer than 4 months, so it still is a "long term supported" kernel
>>>> in contrast, correct?
>>> Perhaps a new name needs to be made for "LTS" for 6 years to distinguish it 
>>> from 2 years.
>>> The timeframes are very different.
>>
>> At this point in time, anyone wanting a kernel longer than 2 years
>> should know how this all works.
>>
>> If not, please do some basic research, I have written whitepapers on
>> this and given numerous talks.  The information is out there...
>>
>>>>> If 5.10 is "actually" going to be supported for 6 years it would be quite 
>>>>> valuable to make such a declaration.
>>>>> https://www.kernel.org/category/releases.html
>>>> Why?  What would that change?
>>>>
>>>> Ok, seriously, this happens every year, and every year we go through the
>>>> same thing, it's not like this is somehow new, right?
>>> No, but why do we need to keep playing the same game every year now.
>>
>> Because, 5.4 almost did not become "6 years" of support from me.  That
>> was because in the beginning, no one said they were going to use it in
>> their devices and offer me help in testing and backporting.  Only when I
>> knew for sure that we had people helping this out did I change the date
>> on kernel.org.
>>
>> So far the jury is still out for 5.10, are you will

Re: 5.10 LTS Kernel: 2 or 6 years?

[Scott Branden]

On 2021-02-18 10:36 a.m., Greg Kroah-Hartman wrote:
> On Thu, Feb 18, 2021 at 07:20:50PM +0100, Willy Tarreau wrote:
>> On Thu, Feb 18, 2021 at 06:53:56PM +0100, Greg Kroah-Hartman wrote:
>>> On Thu, Feb 18, 2021 at 09:21:13AM -0800, Florian Fainelli wrote:
 As a company, we are most likely shooting ourselves in the foot by not
 having a point of coordination with the Linux Foundation and key people
 like you, Greg and other participants in the stable kernel.
>>>
>>> What does the LF have to do with this?
>>>
>>> We are here, on the mailing lists, working with everyone.  Just test the
>>> -rc releases we make and let us know if they work or not for you, it's
>>> not a lot of "coordination" needed at all.
>>>
>>> Otherwise, if no one is saying that they are going to need these for 6
>>> years and are willing to use it in their project (i.e. and test it),
>>> there's no need for us to maintain it for that long, right?
>>
>> Greg, please remember I expressed I really need them for slightly more than
>> 3 years (say 3.5-4) :-) I'm fine with helping a bit more as time permits if
>> this saves me from having to take over these kernels after you, like in the
>> past, but I cannot engage on the regularity of my availability.
> 
> Ok, great!
> 
> That's one person/company saying they can help out (along with what CIP
> has been stating.)
> 
> What about others?  Broadcom started this conversation, odd that they
> don't seem to want to help out :)
Greg, I'm sorry but I'm not in a position to provide such a commitment.

My original question arose because the 5.10 kernel is declared as 2 years LTS 
while older LTS kernels are now 6 years.
One problem this has created is requests to provide silicon support in an older 
kernel version (for a new project) rather than starting from a newer kernel 
version that more properly supports the (silicon and non-silicon) features.  

If all LTS kernels were declared as 3.5-4 years as Willy commented this would 
solve a few issues.
6 year LTS kernels would only have a maximum 1 year lifespan over the latest 
declared LTS kernel.
Also, many products take a year or more to develop, there isn't any life left 
in an LTS kernel if it is only 2 years.

After 1-3 years of kernel age the relevant parties that want to invest and care 
about supporting specific kernel versions longer should become apparent and 
could commit to longer support.  Perhaps you move the burden of 6 years LTS 
elsewhere to longer term projects.  But, I'm sure many are happy because you 
continue doing such a great job in a central location, especially those whose 
product lifespan is around 6 years.
> 
> thanks,
> 
> greg k-h
> 



smime.p7s
Description: S/MIME Cryptographic Signature