[PATCH for-3.18.y+] MIPS: BCM63XX: fix switch core reset on BCM6368

[PATCH for-3.18.y+] MIPS: BCM63XX: fix switch core reset on BCM6368

[Amit Pundir]

From: Jonas Gorski <jonas.gorski@gmail.com>

commit 8a38dacf87180738d42b058334c951eba15d2d47 upstream.

The Ethernet Switch core mask was set to 0, causing the switch core to
be not reset on BCM6368 on boot. Provide the proper mask so the switch
core gets reset to a known good state.

Fixes: 799faa626c71 ("MIPS: BCM63XX: add core reset helper")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@vger.kernel.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
---
Cherry-picked from lede tree https://git.lede-project.org/?p=source.git
and build tested for LTS trees up to v4.19.y for ARCH=mips bcm63xx_defconfig.

 arch/mips/bcm63xx/reset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/bcm63xx/reset.c b/arch/mips/bcm63xx/reset.c
index a2af38cf28a7..64574e74cb23 100644
--- a/arch/mips/bcm63xx/reset.c
+++ b/arch/mips/bcm63xx/reset.c
@@ -120,7 +120,7 @@
 #define BCM6368_RESET_DSL	0
 #define BCM6368_RESET_SAR	SOFTRESET_6368_SAR_MASK
 #define BCM6368_RESET_EPHY	SOFTRESET_6368_EPHY_MASK
-#define BCM6368_RESET_ENETSW	0
+#define BCM6368_RESET_ENETSW	SOFTRESET_6368_ENETSW_MASK
 #define BCM6368_RESET_PCM	SOFTRESET_6368_PCM_MASK
 #define BCM6368_RESET_MPI	SOFTRESET_6368_MPI_MASK
 #define BCM6368_RESET_PCIE	0
-- 
2.7.4

[PATCH for-3.18.y+] pinctrl: msm: fix gpio-hog related boot issues

[Amit Pundir]

From: Christian Lamparter <chunkeey@gmail.com>

commit a86caa9ba5d70696ceb35d1d39caa20d8b641387 upstream.

Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
Setting up any gpio-hog in the device-tree for his device would
"kill the bootup completely":

| [    0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
| [    0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe
| [    1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517
| [    1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register
| [    1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip
| [    1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
| [    1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri

This was also verified on a RT-AC58U (IPQ4018) which would
no longer boot, if a gpio-hog was specified. (Tried forcing
the USB LED PIN (GPIO0) to high.).

The problem is that Pinctrl+GPIO registration is currently
peformed in the following order in pinctrl-msm.c:
	1. pinctrl_register()
	2. gpiochip_add()
	3. gpiochip_add_pin_range()

The actual error code -517 == -EPROBE_DEFER is coming from
pinctrl_get_device_gpio_range(), which is called through:
        gpiochip_add
            of_gpiochip_add
                of_gpiochip_scan_gpios
                    gpiod_hog
                        gpiochip_request_own_desc
                            __gpiod_request
                                chip->request
                                    gpiochip_generic_request
                                       pinctrl_gpio_request
                                          pinctrl_get_device_gpio_range

pinctrl_get_device_gpio_range() is unable to find any valid
pin ranges, since nothing has been added to the pinctrldev_list yet.
so the range can't be found, and the operation fails with -EPROBE_DEFER.

This patch fixes the issue by adding the "gpio-ranges" property to
the pinctrl device node of all upstream Qcom SoC. The pin ranges are
then added by the gpio core.

In order to remain compatible with older, existing DTs (and ACPI)
a check for the "gpio-ranges" property has been added to
msm_gpio_init(). This prevents the driver of adding the same entry
to the pinctrldev_list twice.

Reported-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019]
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[AmitP: Minor rebasing for Stable]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
---
Cherry-picked from lede tree https://git.lede-project.org/?p=source.git
and build tested for LTS trees up to v4.14.y for ARCH=arm/arm64 defconfig.

 drivers/pinctrl/qcom/pinctrl-msm.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index 31632c087504..8f0368330a04 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -839,11 +839,24 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
 		return ret;
 	}
 
-	ret = gpiochip_add_pin_range(&pctrl->chip, dev_name(pctrl->dev), 0, 0, chip->ngpio);
-	if (ret) {
-		dev_err(pctrl->dev, "Failed to add pin range\n");
-		gpiochip_remove(&pctrl->chip);
-		return ret;
+	/*
+	 * For DeviceTree-supported systems, the gpio core checks the
+	 * pinctrl's device node for the "gpio-ranges" property.
+	 * If it is present, it takes care of adding the pin ranges
+	 * for the driver. In this case the driver can skip ahead.
+	 *
+	 * In order to remain compatible with older, existing DeviceTree
+	 * files which don't set the "gpio-ranges" property or systems that
+	 * utilize ACPI the driver has to call gpiochip_add_pin_range().
+	 */
+	if (!of_property_read_bool(pctrl->dev->of_node, "gpio-ranges")) {
+		ret = gpiochip_add_pin_range(&pctrl->chip,
+			dev_name(pctrl->dev), 0, 0, chip->ngpio);
+		if (ret) {
+			dev_err(pctrl->dev, "Failed to add pin range\n");
+			gpiochip_remove(&pctrl->chip);
+			return ret;
+		}
 	}
 
 	ret = gpiochip_irqchip_add(chip,
-- 
2.7.4

Re: [PATCH for-3.18.y+] pinctrl: msm: fix gpio-hog related boot issues

[Greg KH]

On Mon, Feb 18, 2019 at 06:00:11PM +0530, Amit Pundir wrote:
> From: Christian Lamparter <chunkeey@gmail.com>
> 
> commit a86caa9ba5d70696ceb35d1d39caa20d8b641387 upstream.
> 
> Sven Eckelmann reported an issue with the current IPQ4019 pinctrl.
> Setting up any gpio-hog in the device-tree for his device would
> "kill the bootup completely":
> 
> | [    0.477838] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
> | [    0.499828] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferring probe
> | [    1.298883] requesting hog GPIO enable USB2 power (chip 1000000.pinctrl, offset 58) failed, -517
> | [    1.299609] gpiochip_add_data: GPIOs 0..99 (1000000.pinctrl) failed to register
> | [    1.308589] ipq4019-pinctrl 1000000.pinctrl: Failed register gpiochip
> | [    1.316586] msm_serial 78af000.serial: could not find pctldev for node /soc/pinctrl@1000000/serial_pinmux, deferring probe
> | [    1.322415] spi_qup 78b5000.spi: could not find pctldev for node /soc/pinctrl@1000000/spi_0_pinmux, deferri
> 
> This was also verified on a RT-AC58U (IPQ4018) which would
> no longer boot, if a gpio-hog was specified. (Tried forcing
> the USB LED PIN (GPIO0) to high.).
> 
> The problem is that Pinctrl+GPIO registration is currently
> peformed in the following order in pinctrl-msm.c:
> 	1. pinctrl_register()
> 	2. gpiochip_add()
> 	3. gpiochip_add_pin_range()
> 
> The actual error code -517 == -EPROBE_DEFER is coming from
> pinctrl_get_device_gpio_range(), which is called through:
>         gpiochip_add
>             of_gpiochip_add
>                 of_gpiochip_scan_gpios
>                     gpiod_hog
>                         gpiochip_request_own_desc
>                             __gpiod_request
>                                 chip->request
>                                     gpiochip_generic_request
>                                        pinctrl_gpio_request
>                                           pinctrl_get_device_gpio_range
> 
> pinctrl_get_device_gpio_range() is unable to find any valid
> pin ranges, since nothing has been added to the pinctrldev_list yet.
> so the range can't be found, and the operation fails with -EPROBE_DEFER.
> 
> This patch fixes the issue by adding the "gpio-ranges" property to
> the pinctrl device node of all upstream Qcom SoC. The pin ranges are
> then added by the gpio core.
> 
> In order to remain compatible with older, existing DTs (and ACPI)
> a check for the "gpio-ranges" property has been added to
> msm_gpio_init(). This prevents the driver of adding the same entry
> to the pinctrldev_list twice.
> 
> Reported-by: Sven Eckelmann <sven.eckelmann@openmesh.com>
> Tested-by: Sven Eckelmann <sven.eckelmann@openmesh.com> [ipq4019]
> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> [AmitP: Minor rebasing for Stable]
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> ---
> Cherry-picked from lede tree https://git.lede-project.org/?p=source.git
> and build tested for LTS trees up to v4.14.y for ARCH=arm/arm64 defconfig.

Now applied, thanks.

greg k-h

[PATCH for-4.14.y+] mtd: keep original flags for every struct mtd_info

[Amit Pundir]

From: Rafał Miłecki <rafal@milecki.pl>

commit 1186af457cc186c5ed01708da71b1ffbdf0a2638 upstream.

When allocating a new partition mtd subsystem runs internal tests in the
allocate_partition(). They may result in modifying specified flags (e.g.
dropping some /features/ like write access).

Those constraints don't have to be necessary true for subpartitions. It
may happen parent partition isn't block aligned (effectively disabling
write access) while subpartition may fit blocks nicely. In such case all
checks should be run again (starting with original flags value).

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
---
I understand that it doesn't exactly fit into Stable rules but I didn't
want to assume anything, so sending it up for review.
Cherry-picked from lede tree https://git.lede-project.org/?p=source.git
and build tested on v4.14.97 and v4.19.19 for ARCH=arm/arm64 defconfig.

 drivers/mtd/mtdcore.c   | 2 ++
 drivers/mtd/mtdpart.c   | 3 ++-
 include/linux/mtd/mtd.h | 1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 97ac219c082e..2d24701255e5 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -665,6 +665,8 @@ static void mtd_set_dev_defaults(struct mtd_info *mtd)
 	} else {
 		pr_debug("mtd device won't show a device symlink in sysfs\n");
 	}
+
+	mtd->orig_flags = mtd->flags;
 }
 
 /**
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 99c460facd5e..2b6e53af47da 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -346,7 +346,8 @@ static struct mtd_part *allocate_partition(struct mtd_info *parent,
 
 	/* set up the MTD object for this partition */
 	slave->mtd.type = parent->type;
-	slave->mtd.flags = parent->flags & ~part->mask_flags;
+	slave->mtd.flags = parent->orig_flags & ~part->mask_flags;
+	slave->mtd.orig_flags = slave->mtd.flags;
 	slave->mtd.size = part->size;
 	slave->mtd.writesize = parent->writesize;
 	slave->mtd.writebufsize = parent->writebufsize;
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index cd0be91bdefa..b491a08e87e5 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -207,6 +207,7 @@ struct mtd_debug_info {
 struct mtd_info {
 	u_char type;
 	uint32_t flags;
+	uint32_t orig_flags; /* Flags as before running mtd checks */
 	uint64_t size;	 // Total size of the MTD
 
 	/* "Major" erase size for the device. Naïve users may take this
-- 
2.7.4

Re: [PATCH for-4.14.y+] mtd: keep original flags for every struct mtd_info

[Rafał Miłecki]

On 2019-02-18 13:30, Amit Pundir wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> commit 1186af457cc186c5ed01708da71b1ffbdf0a2638 upstream.
> 
> When allocating a new partition mtd subsystem runs internal tests in 
> the
> allocate_partition(). They may result in modifying specified flags 
> (e.g.
> dropping some /features/ like write access).
> 
> Those constraints don't have to be necessary true for subpartitions. It
> may happen parent partition isn't block aligned (effectively disabling
> write access) while subpartition may fit blocks nicely. In such case 
> all
> checks should be run again (starting with original flags value).
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> ---
> I understand that it doesn't exactly fit into Stable rules but I didn't
> want to assume anything, so sending it up for review.
> Cherry-picked from lede tree https://git.lede-project.org/?p=source.git
> and build tested on v4.14.97 and v4.19.19 for ARCH=arm/arm64 defconfig.

This was a pre-requirement for some later-added *feature*. I see to
reason to pick this one for stable. We won't be picking that feature
(whatever it was), so what's the point?

Re: [PATCH for-4.14.y+] mtd: keep original flags for every struct mtd_info

[Amit Pundir]

On Mon, 18 Feb 2019 at 18:31, Rafał Miłecki <rafal@milecki.pl> wrote:
>
> On 2019-02-18 13:30, Amit Pundir wrote:
> > From: Rafał Miłecki <rafal@milecki.pl>
> >
> > commit 1186af457cc186c5ed01708da71b1ffbdf0a2638 upstream.
> >
> > When allocating a new partition mtd subsystem runs internal tests in
> > the
> > allocate_partition(). They may result in modifying specified flags
> > (e.g.
> > dropping some /features/ like write access).
> >
> > Those constraints don't have to be necessary true for subpartitions. It
> > may happen parent partition isn't block aligned (effectively disabling
> > write access) while subpartition may fit blocks nicely. In such case
> > all
> > checks should be run again (starting with original flags value).
> >
> > Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> > Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> > Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> > ---
> > I understand that it doesn't exactly fit into Stable rules but I didn't
> > want to assume anything, so sending it up for review.
> > Cherry-picked from lede tree https://git.lede-project.org/?p=source.git
> > and build tested on v4.14.97 and v4.19.19 for ARCH=arm/arm64 defconfig.
>
> This was a pre-requirement for some later-added *feature*. I see to
> reason to pick this one for stable. We won't be picking that feature
> (whatever it was), so what's the point?

Thank you for the review. I knew I was missing something. I sent it
out of curiosity based on commit log, which talks about re-running all
checks as a fix for internal tests likely dropping write access to new
partition. And I didn't read it is a pre-requisite for later-added
feature. I'm sure lede/openwrt would have picked/backported the whole
feature, but as you mentioned it doesn't make sense for Stable. Thank
you again for the feedback.

Regards,
Amit Pundir