This is a note to let you know that I've just added the patch titled
pinctrl: rockchip: enable clock when reading pin direction register
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-rockchip-enable-clock-when-reading-pin-direction-register.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Brian Norris <briannorris(a)chromium.org>
Date: Tue, 12 Dec 2017 09:43:43 -0800
Subject: pinctrl: rockchip: enable clock when reading pin direction register
From: Brian Norris <briannorris(a)chromium.org>
[ Upstream commit 5c9d8c4f6b8168738a26bcf288516cc3a0886810 ]
We generally leave the GPIO clock disabled, unless an interrupt is
requested or we're accessing IO registers. We forgot to do this for the
->get_direction() callback, which means we can sometimes [1] get
incorrect results [2] from, e.g., /sys/kernel/debug/gpio.
Enable the clock, so we get the right results!
[1] Sometimes, because many systems have 1 or mor interrupt requested on
each GPIO bank, so they always leave their clock on.
[2] Incorrect, meaning the register returns 0, and so we interpret that
as "input".
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
Reviewed-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/pinctrl-rockchip.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -1989,8 +1989,16 @@ static int rockchip_gpio_get_direction(s
{
struct rockchip_pin_bank *bank = gpiochip_get_data(chip);
u32 data;
+ int ret;
+ ret = clk_enable(bank->clk);
+ if (ret < 0) {
+ dev_err(bank->drvdata->dev,
+ "failed to enable clock for bank %s\n", bank->name);
+ return ret;
+ }
data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR);
+ clk_disable(bank->clk);
return !(data & BIT(offset));
}
Patches currently in stable-queue which might be from briannorris(a)chromium.org are
queue-4.14/pinctrl-rockchip-enable-clock-when-reading-pin-direction-register.patch
queue-4.14/platform-chrome-use-proper-protocol-transfer-function.patch
This is a note to let you know that I've just added the patch titled
pinctrl: Really force states during suspend/resume
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-really-force-states-during-suspend-resume.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Florian Fainelli <f.fainelli(a)gmail.com>
Date: Wed, 1 Mar 2017 10:32:57 -0800
Subject: pinctrl: Really force states during suspend/resume
From: Florian Fainelli <f.fainelli(a)gmail.com>
[ Upstream commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 ]
In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and resumes
in a way that the pin states are not preserved by the hardware, when we
resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
-> pinctrl_select_state() and the first thing we do is check that the
pins state is the same as before, and do nothing.
In order to fix this, decouple the actual state change from
pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
the p->state == state check in pinctrl_select_state() not to change the
caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
are updated to bypass the state check by calling pinctrl_commit_state().
[Linus Walleij]
The forced pin control states are currently only used in some pin
controller drivers that grab their own reference to their own pins.
This is equal to the pin control hogs: pins taken by pin control
devices since there are no corresponding device in the Linux device
hierarchy, such as memory controller lines or unused GPIO lines,
or GPIO lines that are used orthogonally from the GPIO subsystem
but pincontrol-wise managed as hogs (non-strict mode, allowing
simultaneous use by GPIO and pin control). For this case forcing
the state from the drivers' suspend()/resume() callbacks makes
sense and should semantically match the name of the function.
Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko(a)gmail.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pinctrl/core.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1189,19 +1189,16 @@ struct pinctrl_state *pinctrl_lookup_sta
EXPORT_SYMBOL_GPL(pinctrl_lookup_state);
/**
- * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * pinctrl_commit_state() - select/activate/program a pinctrl state to HW
* @p: the pinctrl handle for the device that requests configuration
* @state: the state handle to select/activate/program
*/
-int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
+static int pinctrl_commit_state(struct pinctrl *p, struct pinctrl_state *state)
{
struct pinctrl_setting *setting, *setting2;
struct pinctrl_state *old_state = p->state;
int ret;
- if (p->state == state)
- return 0;
-
if (p->state) {
/*
* For each pinmux setting in the old state, forget SW's record
@@ -1265,6 +1262,19 @@ unapply_new_state:
return ret;
}
+
+/**
+ * pinctrl_select_state() - select/activate/program a pinctrl state to HW
+ * @p: the pinctrl handle for the device that requests configuration
+ * @state: the state handle to select/activate/program
+ */
+int pinctrl_select_state(struct pinctrl *p, struct pinctrl_state *state)
+{
+ if (p->state == state)
+ return 0;
+
+ return pinctrl_commit_state(p, state);
+}
EXPORT_SYMBOL_GPL(pinctrl_select_state);
static void devm_pinctrl_release(struct device *dev, void *res)
@@ -1430,7 +1440,7 @@ void pinctrl_unregister_map(const struct
int pinctrl_force_sleep(struct pinctrl_dev *pctldev)
{
if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_sleep))
- return pinctrl_select_state(pctldev->p, pctldev->hog_sleep);
+ return pinctrl_commit_state(pctldev->p, pctldev->hog_sleep);
return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
@@ -1442,7 +1452,7 @@ EXPORT_SYMBOL_GPL(pinctrl_force_sleep);
int pinctrl_force_default(struct pinctrl_dev *pctldev)
{
if (!IS_ERR(pctldev->p) && !IS_ERR(pctldev->hog_default))
- return pinctrl_select_state(pctldev->p, pctldev->hog_default);
+ return pinctrl_commit_state(pctldev->p, pctldev->hog_default);
return 0;
}
EXPORT_SYMBOL_GPL(pinctrl_force_default);
Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are
queue-4.14/pinctrl-really-force-states-during-suspend-resume.patch
This is a note to let you know that I've just added the patch titled
PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Thu, 7 Dec 2017 11:15:20 +0100
Subject: PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit 83c75ddd816e979802bd244ad494139f28152921 ]
rcar_pcie_parse_request_of_pci_ranges() can fail and return an error
code, but this is not checked nor handled.
Fix this by adding the missing error handling.
Fixes: 5d2917d469faab72 ("PCI: rcar: Convert to DT resource parsing API")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pcie-rcar.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -1141,7 +1141,9 @@ static int rcar_pcie_probe(struct platfo
INIT_LIST_HEAD(&pcie->resources);
- rcar_pcie_parse_request_of_pci_ranges(pcie);
+ err = rcar_pcie_parse_request_of_pci_ranges(pcie);
+ if (err)
+ goto err_free_bridge;
err = rcar_pcie_get_resources(pcie);
if (err < 0) {
@@ -1196,6 +1198,7 @@ err_pm_disable:
err_free_resource_list:
pci_free_resource_list(&pcie->resources);
+err_free_bridge:
pci_free_host_bridge(bridge);
return err;
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.14/spi-sh-msiof-avoid-writing-to-registers-from-spi_master.setup.patch
queue-4.14/pci-rcar-handle-rcar_pcie_parse_request_of_pci_ranges-failures.patch
This is a note to let you know that I've just added the patch titled
PCI: endpoint: Fix find_first_zero_bit() usage
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-endpoint-fix-find_first_zero_bit-usage.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Niklas Cassel <niklas.cassel(a)axis.com>
Date: Thu, 14 Dec 2017 14:01:46 +0100
Subject: PCI: endpoint: Fix find_first_zero_bit() usage
From: Niklas Cassel <niklas.cassel(a)axis.com>
[ Upstream commit 35ad61921f495ee14915d185de79478c1737b4da ]
find_first_zero_bit()'s parameter 'size' is defined in bits,
not in bytes.
Calling find_first_zero_bit() with the wrong size unit
will lead to insidious bugs.
Fix this by calling find_first_zero_bit() with size BITS_PER_LONG,
rather than sizeof() and add missing find_first_zero_bit() return
handling.
Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring EP functions")
Signed-off-by: Niklas Cassel <niklas.cassel(a)axis.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Acked-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/endpoint/pci-ep-cfs.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -109,7 +109,10 @@ static int pci_epc_epf_link(struct confi
goto err_add_epf;
func_no = find_first_zero_bit(&epc_group->function_num_map,
- sizeof(epc_group->function_num_map));
+ BITS_PER_LONG);
+ if (func_no >= BITS_PER_LONG)
+ return -EINVAL;
+
set_bit(func_no, &epc_group->function_num_map);
epf->func_no = func_no;
Patches currently in stable-queue which might be from niklas.cassel(a)axis.com are
queue-4.14/pci-endpoint-fix-find_first_zero_bit-usage.patch
This is a note to let you know that I've just added the patch titled
PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-designware-ep-fix-get_msi-to-check-msi_en-bit.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Kishon Vijay Abraham I <kishon(a)ti.com>
Date: Tue, 19 Dec 2017 15:25:41 +0530
Subject: PCI: designware-ep: Fix ->get_msi() to check MSI_EN bit
From: Kishon Vijay Abraham I <kishon(a)ti.com>
[ Upstream commit a134a457ed985dca8cce7ac4ea66129ea70eba73 ]
->get_msi() now checks MSI_EN bit in the MSI CAPABILITY register to
find whether the host supports MSI instead of using the
MSI ADDRESS in the MSI CAPABILITY register.
This fixes the issue with the following sequence
'modprobe pci_endpoint_test' enables MSI
'rmmod pci_endpoint_test' disables MSI but MSI address (in EP's
capability register) has a valid value
'modprobe pci_endpoint_test no_msi=1' - Since MSI address (in EP's
capability register) has a valid value (set during the previous
insertion of the module), EP thinks host supports MSI.
Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/dwc/pcie-designware-ep.c | 12 +++---------
drivers/pci/dwc/pcie-designware.h | 1 +
2 files changed, 4 insertions(+), 9 deletions(-)
--- a/drivers/pci/dwc/pcie-designware-ep.c
+++ b/drivers/pci/dwc/pcie-designware-ep.c
@@ -197,20 +197,14 @@ static int dw_pcie_ep_map_addr(struct pc
static int dw_pcie_ep_get_msi(struct pci_epc *epc)
{
int val;
- u32 lower_addr;
- u32 upper_addr;
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
- val = dw_pcie_readb_dbi(pci, MSI_MESSAGE_CONTROL);
- val = (val & MSI_CAP_MME_MASK) >> MSI_CAP_MME_SHIFT;
-
- lower_addr = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32);
- upper_addr = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_U32);
-
- if (!(lower_addr || upper_addr))
+ val = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
+ if (!(val & MSI_CAP_MSI_EN_MASK))
return -EINVAL;
+ val = (val & MSI_CAP_MME_MASK) >> MSI_CAP_MME_SHIFT;
return val;
}
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -101,6 +101,7 @@
#define MSI_MESSAGE_CONTROL 0x52
#define MSI_CAP_MMC_SHIFT 1
#define MSI_CAP_MME_SHIFT 4
+#define MSI_CAP_MSI_EN_MASK 0x1
#define MSI_CAP_MME_MASK (7 << MSI_CAP_MME_SHIFT)
#define MSI_MESSAGE_ADDR_L32 0x54
#define MSI_MESSAGE_ADDR_U32 0x58
Patches currently in stable-queue which might be from kishon(a)ti.com are
queue-4.14/pci-endpoint-fix-find_first_zero_bit-usage.patch
queue-4.14/pci-designware-ep-fix-get_msi-to-check-msi_en-bit.patch
This is a note to let you know that I've just added the patch titled
nfsd4: permit layoutget of executable-only files
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfsd4-permit-layoutget-of-executable-only-files.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Benjamin Coddington <bcodding(a)redhat.com>
Date: Tue, 19 Dec 2017 09:35:25 -0500
Subject: nfsd4: permit layoutget of executable-only files
From: Benjamin Coddington <bcodding(a)redhat.com>
[ Upstream commit 66282ec1cf004c09083c29cb5e49019037937bbd ]
Clients must be able to read a file in order to execute it, and for pNFS
that means the client needs to be able to perform a LAYOUTGET on the file.
This behavior for executable-only files was added for OPEN in commit
a043226bc140 "nfsd4: permit read opens of executable-only files".
This fixes up xfstests generic/126 on block/scsi layouts.
Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfs4proc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -1372,14 +1372,14 @@ nfsd4_layoutget(struct svc_rqst *rqstp,
const struct nfsd4_layout_ops *ops;
struct nfs4_layout_stateid *ls;
__be32 nfserr;
- int accmode;
+ int accmode = NFSD_MAY_READ_IF_EXEC;
switch (lgp->lg_seg.iomode) {
case IOMODE_READ:
- accmode = NFSD_MAY_READ;
+ accmode |= NFSD_MAY_READ;
break;
case IOMODE_RW:
- accmode = NFSD_MAY_READ | NFSD_MAY_WRITE;
+ accmode |= NFSD_MAY_READ | NFSD_MAY_WRITE;
break;
default:
dprintk("%s: invalid iomode %d\n",
Patches currently in stable-queue which might be from bcodding(a)redhat.com are
queue-4.14/nfsd4-permit-layoutget-of-executable-only-files.patch
This is a note to let you know that I've just added the patch titled
net: phy: meson-gxl: check phy_write return value
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-phy-meson-gxl-check-phy_write-return-value.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Jerome Brunet <jbrunet(a)baylibre.com>
Date: Mon, 18 Dec 2017 10:44:40 +0100
Subject: net: phy: meson-gxl: check phy_write return value
From: Jerome Brunet <jbrunet(a)baylibre.com>
[ Upstream commit 9042b46eda33ef5db3cdfc9e12b3c8cabb196141 ]
Always check phy_write return values. Better to be safe than sorry
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/meson-gxl.c | 50 +++++++++++++++++++++++++++++++++-----------
1 file changed, 38 insertions(+), 12 deletions(-)
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -25,27 +25,53 @@
static int meson_gxl_config_init(struct phy_device *phydev)
{
+ int ret;
+
/* Enable Analog and DSP register Bank access by */
- phy_write(phydev, 0x14, 0x0000);
- phy_write(phydev, 0x14, 0x0400);
- phy_write(phydev, 0x14, 0x0000);
- phy_write(phydev, 0x14, 0x0400);
+ ret = phy_write(phydev, 0x14, 0x0000);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0400);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0000);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x0400);
+ if (ret)
+ return ret;
/* Write Analog register 23 */
- phy_write(phydev, 0x17, 0x8E0D);
- phy_write(phydev, 0x14, 0x4417);
+ ret = phy_write(phydev, 0x17, 0x8E0D);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x4417);
+ if (ret)
+ return ret;
/* Enable fractional PLL */
- phy_write(phydev, 0x17, 0x0005);
- phy_write(phydev, 0x14, 0x5C1B);
+ ret = phy_write(phydev, 0x17, 0x0005);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1B);
+ if (ret)
+ return ret;
/* Program fraction FR_PLL_DIV1 */
- phy_write(phydev, 0x17, 0x029A);
- phy_write(phydev, 0x14, 0x5C1D);
+ ret = phy_write(phydev, 0x17, 0x029A);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1D);
+ if (ret)
+ return ret;
/* Program fraction FR_PLL_DIV1 */
- phy_write(phydev, 0x17, 0xAAAA);
- phy_write(phydev, 0x14, 0x5C1C);
+ ret = phy_write(phydev, 0x17, 0xAAAA);
+ if (ret)
+ return ret;
+ ret = phy_write(phydev, 0x14, 0x5C1C);
+ if (ret)
+ return ret;
return 0;
}
Patches currently in stable-queue which might be from jbrunet(a)baylibre.com are
queue-4.14/net-phy-meson-gxl-check-phy_write-return-value.patch
This is a note to let you know that I've just added the patch titled
net: fec: add phy_reset_after_clk_enable() support
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-fec-add-phy_reset_after_clk_enable-support.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Richard Leitner <richard.leitner(a)skidata.com>
Date: Mon, 11 Dec 2017 13:17:00 +0100
Subject: net: fec: add phy_reset_after_clk_enable() support
From: Richard Leitner <richard.leitner(a)skidata.com>
[ Upstream commit 1b0a83ac04e383e3bed21332962b90710fcf2828 ]
Some PHYs (for example the SMSC LAN8710/LAN8720) doesn't allow turning
the refclk on and off again during operation (according to their
datasheet). Nonetheless exactly this behaviour was introduced for power
saving reasons by commit e8fcfcd5684a ("net: fec: optimize the clock management to save power").
Therefore add support for the phy_reset_after_clk_enable function from
phylib to mitigate this issue.
Generally speaking this issue is only relevant if the ref clk for the
PHY is generated by the SoC and therefore the PHY is configured to
"REF_CLK In Mode". In our specific case (PCB) this problem does occur at
about every 10th to 50th POR of an LAN8710 connected to an i.MX6SOLO
SoC. The typical symptom of this problem is a "swinging" ethernet link.
Similar issues were reported by users of the NXP forum:
https://community.nxp.com/thread/389902https://community.nxp.com/message/309354
With this patch applied the issue didn't occur for at least a few
hundret PORs of our board.
Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power")
Signed-off-by: Richard Leitner <richard.leitner(a)skidata.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/fec_main.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1872,6 +1872,8 @@ static int fec_enet_clk_enable(struct ne
ret = clk_prepare_enable(fep->clk_ref);
if (ret)
goto failed_clk_ref;
+
+ phy_reset_after_clk_enable(ndev->phydev);
} else {
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_enet_out);
@@ -2844,6 +2846,7 @@ fec_enet_open(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
int ret;
+ bool reset_again;
ret = pm_runtime_get_sync(&fep->pdev->dev);
if (ret < 0)
@@ -2854,6 +2857,17 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto clk_enable;
+ /* During the first fec_enet_open call the PHY isn't probed at this
+ * point. Therefore the phy_reset_after_clk_enable() call within
+ * fec_enet_clk_enable() fails. As we need this reset in order to be
+ * sure the PHY is working correctly we check if we need to reset again
+ * later when the PHY is probed
+ */
+ if (ndev->phydev && ndev->phydev->drv)
+ reset_again = false;
+ else
+ reset_again = true;
+
/* I should reset the ring buffers here, but I don't yet know
* a simple way to do that.
*/
@@ -2870,6 +2884,12 @@ fec_enet_open(struct net_device *ndev)
if (ret)
goto err_enet_mii_probe;
+ /* Call phy_reset_after_clk_enable() again if it failed during
+ * phy_reset_after_clk_enable() before because the PHY wasn't probed.
+ */
+ if (reset_again)
+ phy_reset_after_clk_enable(ndev->phydev);
+
if (fep->quirks & FEC_QUIRK_ERR006687)
imx6q_cpuidle_fec_irqs_used();
Patches currently in stable-queue which might be from richard.leitner(a)skidata.com are
queue-4.14/net-fec-add-phy_reset_after_clk_enable-support.patch
This is a note to let you know that I've just added the patch titled
mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
mmc-sdhci-xenon-wait-5ms-after-set-1.8v-signal-enable.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Thu Mar 22 14:26:48 CET 2018
From: Zhoujie Wu <zjwu(a)marvell.com>
Date: Mon, 18 Dec 2017 14:38:47 -0800
Subject: mmc: sdhci-xenon: wait 5ms after set 1.8V signal enable
From: Zhoujie Wu <zjwu(a)marvell.com>
[ Upstream commit 8d876bf472dba73c015cea9feea80dcb80626a7c ]
According to SD spec 3.00 3.6.1 signal voltage switch
procedure step 6~8,
(6) Set 1.8V Signal Enable in the Host Control 2 register.
(7) Wait 5ms. 1.8V voltage regulator shall be stable within this period.
(8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12).
Host should wait 5ms after set 1.8V signal enable bit in
Host Control 2 register and check if 1.8V is stable or not.
But current code checks this bit right after set it.
On some platforms with xenon controller found the bit is
cleared right away and host reports "1.8V regulator output
did not became stable" and 5ms delay can help.
Implement voltage_switch callback for xenon controller to add 5ms
delay to make sure the 1.8V signal enable bit is set by controller.
Signed-off-by: Zhoujie Wu <zjwu(a)marvell.com>
Acked-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mmc/host/sdhci-xenon.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -230,7 +230,14 @@ static void xenon_set_power(struct sdhci
mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, vdd);
}
+static void xenon_voltage_switch(struct sdhci_host *host)
+{
+ /* Wait for 5ms after set 1.8V signal enable bit */
+ usleep_range(5000, 5500);
+}
+
static const struct sdhci_ops sdhci_xenon_ops = {
+ .voltage_switch = xenon_voltage_switch,
.set_clock = sdhci_set_clock,
.set_power = xenon_set_power,
.set_bus_width = sdhci_set_bus_width,
Patches currently in stable-queue which might be from zjwu(a)marvell.com are
queue-4.14/mmc-sdhci-xenon-wait-5ms-after-set-1.8v-signal-enable.patch