| Message ID | 20180706201415.1930-3-daniel@zonque.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/3] mtd: rawnand: marvell: remove bogus comment in marvell_nfc_select_chip() | expand |
On Fri, 6 Jul 2018 22:14:15 +0200 Daniel Mack <daniel@zonque.org> wrote: > This patch restores the suspend and resume hooks that the old driver used > to have. Apart from stopping and starting the clocks, the resume callback > also nullifies the selected_chip pointer, so the next command that is issued > will re-select the chip and thereby restore the timing registers. > > Without this patch, a PXA3xx based system would cough up an error similar to > the one below after resume. > > [ 44.660162] marvell-nfc 43100000.nand-controller: Timeout waiting for RB signal > [ 44.671492] ubi0 error: ubi_io_write: error -110 while writing 2048 bytes to PEB 102:38912, written 0 bytes > [ 44.682887] CPU: 0 PID: 1417 Comm: remote-control Not tainted 4.18.0-rc2+ #344 > [ 44.691197] Hardware name: Marvell PXA3xx (Device Tree Support) > [ 44.697111] Backtrace: > [ 44.699593] [<c0106458>] (dump_backtrace) from [<c0106718>] (show_stack+0x18/0x1c) > [ 44.708931] r7:00000800 r6:00009800 r5:00000066 r4:c6139000 > [ 44.715833] [<c0106700>] (show_stack) from [<c0678a60>] (dump_stack+0x20/0x28) > [ 44.724206] [<c0678a40>] (dump_stack) from [<c0456cbc>] (ubi_io_write+0x3d4/0x630) > [ 44.732925] [<c04568e8>] (ubi_io_write) from [<c0454428>] (ubi_eba_write_leb+0x690/0x6fc) > ... > > Signed-off-by: Daniel Mack <daniel@zonque.org> You probably want patch 2 and 3 backported to stable. Would be better if we don't need patch 2 though, since this is not exactly a fix. Maybe you can re-order things and add IS_ERR() tests in the suspend/resume funcs, which you'll then remove but this time, the cleanup patch won't be flagged "for stable". > --- > drivers/mtd/nand/raw/marvell_nand.c | 47 +++++++++++++++++++++++++++++ > 1 file changed, 47 insertions(+) > > diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c > index 0511d0979cc6..9246c3ea6ebc 100644 > --- a/drivers/mtd/nand/raw/marvell_nand.c > +++ b/drivers/mtd/nand/raw/marvell_nand.c > @@ -2824,6 +2824,52 @@ static int marvell_nfc_remove(struct platform_device *pdev) > return 0; > } > > +static int __maybe_unused marvell_nfc_suspend(struct device *dev) > +{ > + struct marvell_nfc *nfc = dev_get_drvdata(dev); > + struct marvell_nand_chip *chip; > + > + list_for_each_entry(chip, &nfc->chips, node) > + marvell_nfc_wait_ndrun(&chip->chip); > + > + clk_disable_unprepare(nfc->reg_clk); > + clk_disable_unprepare(nfc->core_clk); > + > + return 0; > +} > + > +static int __maybe_unused marvell_nfc_resume(struct device *dev) > +{ > + struct marvell_nfc *nfc = dev_get_drvdata(dev); > + int ret; > + > + ret = clk_prepare_enable(nfc->core_clk); > + if (ret < 0) > + return ret; > + > + ret = clk_prepare_enable(nfc->reg_clk); > + if (ret < 0) > + return ret; > + > + /* > + * Reset nfc->selected_chip so the next command will cause the timing > + * registers to be restored in marvell_nfc_select_chip(). > + */ > + nfc->selected_chip = NULL; > + > + /* Reset registers that have lots its contents */ > + writel_relaxed(NDCR_ALL_INT | NDCR_ND_ARB_EN | NDCR_SPARE_EN | > + NDCR_RD_ID_CNT(NFCV1_READID_LEN), nfc->regs + NDCR); > + writel_relaxed(0xFFFFFFFF, nfc->regs + NDSR); > + writel_relaxed(0, nfc->regs + NDECCCTRL); > + > + return 0; > +} > + > +static const struct dev_pm_ops marvell_nfc_pm_ops = { > + SET_SYSTEM_SLEEP_PM_OPS(marvell_nfc_suspend, marvell_nfc_resume) > +}; > + > static const struct marvell_nfc_caps marvell_armada_8k_nfc_caps = { > .max_cs_nb = 4, > .max_rb_nb = 2, > @@ -2908,6 +2954,7 @@ static struct platform_driver marvell_nfc_driver = { > .driver = { > .name = "marvell-nfc", > .of_match_table = marvell_nfc_of_ids, > + .pm = &marvell_nfc_pm_ops, > }, > .id_table = marvell_nfc_platform_ids, > .probe = marvell_nfc_probe,
Hi, On 07/06/2018 11:22 PM, Boris Brezillon wrote: > On Fri, 6 Jul 2018 22:14:15 +0200 > Daniel Mack <daniel@zonque.org> wrote: > >> This patch restores the suspend and resume hooks that the old driver used >> to have. Apart from stopping and starting the clocks, the resume callback >> also nullifies the selected_chip pointer, so the next command that is issued >> will re-select the chip and thereby restore the timing registers. >> >> Without this patch, a PXA3xx based system would cough up an error similar to >> the one below after resume. >> >> [ 44.660162] marvell-nfc 43100000.nand-controller: Timeout waiting for RB signal >> [ 44.671492] ubi0 error: ubi_io_write: error -110 while writing 2048 bytes to PEB 102:38912, written 0 bytes >> [ 44.682887] CPU: 0 PID: 1417 Comm: remote-control Not tainted 4.18.0-rc2+ #344 >> [ 44.691197] Hardware name: Marvell PXA3xx (Device Tree Support) >> [ 44.697111] Backtrace: >> [ 44.699593] [<c0106458>] (dump_backtrace) from [<c0106718>] (show_stack+0x18/0x1c) >> [ 44.708931] r7:00000800 r6:00009800 r5:00000066 r4:c6139000 >> [ 44.715833] [<c0106700>] (show_stack) from [<c0678a60>] (dump_stack+0x20/0x28) >> [ 44.724206] [<c0678a40>] (dump_stack) from [<c0456cbc>] (ubi_io_write+0x3d4/0x630) >> [ 44.732925] [<c04568e8>] (ubi_io_write) from [<c0454428>] (ubi_eba_write_leb+0x690/0x6fc) >> ... >> >> Signed-off-by: Daniel Mack <daniel@zonque.org> > > You probably want patch 2 and 3 backported to stable. Given that nobody has cared so far and the only board that depends on proper PM that seems to be using this driver has bitrot quite badly in the past and is undergoing a major rewrite currently, I'm not sure whether it's worth it really. I can do it if you insist though. Thanks, Daniel
On Saturday, July 07, 2018 12:15 AM, Daniel Mack wrote: > Hi, > > On 07/06/2018 11:22 PM, Boris Brezillon wrote: >> On Fri, 6 Jul 2018 22:14:15 +0200 >> Daniel Mack <daniel@zonque.org> wrote: >> >>> This patch restores the suspend and resume hooks that the old driver used >>> to have. Apart from stopping and starting the clocks, the resume callback >>> also nullifies the selected_chip pointer, so the next command that is issued >>> will re-select the chip and thereby restore the timing registers. >>> >>> Without this patch, a PXA3xx based system would cough up an error similar to >>> the one below after resume. >>> >>> [ 44.660162] marvell-nfc 43100000.nand-controller: Timeout waiting for RB signal >>> [ 44.671492] ubi0 error: ubi_io_write: error -110 while writing 2048 bytes to PEB 102:38912, written 0 bytes >>> [ 44.682887] CPU: 0 PID: 1417 Comm: remote-control Not tainted 4.18.0-rc2+ #344 >>> [ 44.691197] Hardware name: Marvell PXA3xx (Device Tree Support) >>> [ 44.697111] Backtrace: >>> [ 44.699593] [<c0106458>] (dump_backtrace) from [<c0106718>] (show_stack+0x18/0x1c) >>> [ 44.708931] r7:00000800 r6:00009800 r5:00000066 r4:c6139000 >>> [ 44.715833] [<c0106700>] (show_stack) from [<c0678a60>] (dump_stack+0x20/0x28) >>> [ 44.724206] [<c0678a40>] (dump_stack) from [<c0456cbc>] (ubi_io_write+0x3d4/0x630) >>> [ 44.732925] [<c04568e8>] (ubi_io_write) from [<c0454428>] (ubi_eba_write_leb+0x690/0x6fc) >>> ... >>> >>> Signed-off-by: Daniel Mack <daniel@zonque.org> >> >> You probably want patch 2 and 3 backported to stable. > > Given that nobody has cared so far and the only board that depends on > proper PM that seems to be using this driver has bitrot quite badly in > the past and is undergoing a major rewrite currently, I'm not sure > whether it's worth it really. Ah, I only see this now, but patch 2 also fixes a problem with the .remove() callback of this driver which also blindly grabs ->reg_clk without further checks. Hence the entire series actually qualifies for stable@ I figure? Thanks, Daniel
Hi Daniel, On Sat, 7 Jul 2018 00:26:22 +0200 Daniel Mack <daniel@zonque.org> wrote: > On Saturday, July 07, 2018 12:15 AM, Daniel Mack wrote: > > Hi, > > > > On 07/06/2018 11:22 PM, Boris Brezillon wrote: > >> On Fri, 6 Jul 2018 22:14:15 +0200 > >> Daniel Mack <daniel@zonque.org> wrote: > >> > >>> This patch restores the suspend and resume hooks that the old driver used > >>> to have. Apart from stopping and starting the clocks, the resume callback > >>> also nullifies the selected_chip pointer, so the next command that is issued > >>> will re-select the chip and thereby restore the timing registers. > >>> > >>> Without this patch, a PXA3xx based system would cough up an error similar to > >>> the one below after resume. > >>> > >>> [ 44.660162] marvell-nfc 43100000.nand-controller: Timeout waiting for RB signal > >>> [ 44.671492] ubi0 error: ubi_io_write: error -110 while writing 2048 bytes to PEB 102:38912, written 0 bytes > >>> [ 44.682887] CPU: 0 PID: 1417 Comm: remote-control Not tainted 4.18.0-rc2+ #344 > >>> [ 44.691197] Hardware name: Marvell PXA3xx (Device Tree Support) > >>> [ 44.697111] Backtrace: > >>> [ 44.699593] [<c0106458>] (dump_backtrace) from [<c0106718>] (show_stack+0x18/0x1c) > >>> [ 44.708931] r7:00000800 r6:00009800 r5:00000066 r4:c6139000 > >>> [ 44.715833] [<c0106700>] (show_stack) from [<c0678a60>] (dump_stack+0x20/0x28) > >>> [ 44.724206] [<c0678a40>] (dump_stack) from [<c0456cbc>] (ubi_io_write+0x3d4/0x630) > >>> [ 44.732925] [<c04568e8>] (ubi_io_write) from [<c0454428>] (ubi_eba_write_leb+0x690/0x6fc) > >>> ... > >>> > >>> Signed-off-by: Daniel Mack <daniel@zonque.org> > >> > >> You probably want patch 2 and 3 backported to stable. > > > > Given that nobody has cared so far and the only board that depends on > > proper PM that seems to be using this driver has bitrot quite badly in > > the past and is undergoing a major rewrite currently, I'm not sure > > whether it's worth it really. > > Ah, I only see this now, but patch 2 also fixes a problem with the > .remove() callback of this driver which also blindly grabs ->reg_clk > without further checks. Nope, because the clk framework checks for both ERR and NULL (see [1]). I'm definitely not arguing that patch 2 is not needed (actually I pushed for this solution when Greg initially added these new clks [2]), just that it should not be flagged as stable. > > Hence the entire series actually qualifies for stable@ I figure? I'd really prefer to have a single patch go into stable. Patch 1 is clearly not a bug fix, and patch 2 is just a dependency of patch 3, so let's remove this dependency by either squashing both patches into a single one or by reordering the changes. Regards, Boris [1]https://elixir.bootlin.com/linux/v4.18-rc3/source/drivers/clk/clk.c#L858 [2]https://www.spinics.net/lists/arm-kernel/msg639312.html
On Sat, 7 Jul 2018 08:07:13 +0200 Boris Brezillon <boris.brezillon@bootlin.com> wrote: > Hi Daniel, > > On Sat, 7 Jul 2018 00:26:22 +0200 > Daniel Mack <daniel@zonque.org> wrote: > > > On Saturday, July 07, 2018 12:15 AM, Daniel Mack wrote: > > > Hi, > > > > > > On 07/06/2018 11:22 PM, Boris Brezillon wrote: > > >> On Fri, 6 Jul 2018 22:14:15 +0200 > > >> Daniel Mack <daniel@zonque.org> wrote: > > >> > > >>> This patch restores the suspend and resume hooks that the old driver used > > >>> to have. Apart from stopping and starting the clocks, the resume callback > > >>> also nullifies the selected_chip pointer, so the next command that is issued > > >>> will re-select the chip and thereby restore the timing registers. > > >>> > > >>> Without this patch, a PXA3xx based system would cough up an error similar to > > >>> the one below after resume. > > >>> > > >>> [ 44.660162] marvell-nfc 43100000.nand-controller: Timeout waiting for RB signal > > >>> [ 44.671492] ubi0 error: ubi_io_write: error -110 while writing 2048 bytes to PEB 102:38912, written 0 bytes > > >>> [ 44.682887] CPU: 0 PID: 1417 Comm: remote-control Not tainted 4.18.0-rc2+ #344 > > >>> [ 44.691197] Hardware name: Marvell PXA3xx (Device Tree Support) > > >>> [ 44.697111] Backtrace: > > >>> [ 44.699593] [<c0106458>] (dump_backtrace) from [<c0106718>] (show_stack+0x18/0x1c) > > >>> [ 44.708931] r7:00000800 r6:00009800 r5:00000066 r4:c6139000 > > >>> [ 44.715833] [<c0106700>] (show_stack) from [<c0678a60>] (dump_stack+0x20/0x28) > > >>> [ 44.724206] [<c0678a40>] (dump_stack) from [<c0456cbc>] (ubi_io_write+0x3d4/0x630) > > >>> [ 44.732925] [<c04568e8>] (ubi_io_write) from [<c0454428>] (ubi_eba_write_leb+0x690/0x6fc) > > >>> ... > > >>> > > >>> Signed-off-by: Daniel Mack <daniel@zonque.org> > > >> > > >> You probably want patch 2 and 3 backported to stable. > > > > > > Given that nobody has cared so far and the only board that depends on > > > proper PM that seems to be using this driver has bitrot quite badly in > > > the past and is undergoing a major rewrite currently, I'm not sure > > > whether it's worth it really. > > > > Ah, I only see this now, but patch 2 also fixes a problem with the > > .remove() callback of this driver which also blindly grabs ->reg_clk > > without further checks. > > Nope, because the clk framework checks for both ERR and NULL (see > [1]). I'm definitely not arguing that patch 2 is not needed (actually I > pushed for this solution when Greg initially added these new clks [2]), > just that it should not be flagged as stable. > > > > > Hence the entire series actually qualifies for stable@ I figure? > > I'd really prefer to have a single patch go into stable. Patch 1 is > clearly not a bug fix, and patch 2 is just a dependency of patch 3, so > let's remove this dependency by either squashing both patches into a > single one or by reordering the changes. Forgot to mention that you should also add Fixes: 02f26ecf8c77 ("mtd: nand: add reworked Marvell NAND controller driver")
Hi Boris, On Saturday, July 07, 2018 08:07 AM, Boris Brezillon wrote: > On Sat, 7 Jul 2018 00:26:22 +0200 > Daniel Mack <daniel@zonque.org> wrote: >> Ah, I only see this now, but patch 2 also fixes a problem with the >> .remove() callback of this driver which also blindly grabs ->reg_clk >> without further checks. > > Nope, because the clk framework checks for both ERR and NULL (see > [1]). I'm definitely not arguing that patch 2 is not needed (actually I > pushed for this solution when Greg initially added these new clks [2]), > just that it should not be flagged as stable. Ah, I missed that! Sorry. >> Hence the entire series actually qualifies for stable@ I figure? > > I'd really prefer to have a single patch go into stable. Patch 1 is > clearly not a bug fix, and patch 2 is just a dependency of patch 3, so > let's remove this dependency by either squashing both patches into a > single one or by reordering the changes. Okay then. Hang on, I'll send a v2. Thanks, Daniel
diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c index 0511d0979cc6..9246c3ea6ebc 100644 --- a/drivers/mtd/nand/raw/marvell_nand.c +++ b/drivers/mtd/nand/raw/marvell_nand.c @@ -2824,6 +2824,52 @@ static int marvell_nfc_remove(struct platform_device *pdev) return 0; } +static int __maybe_unused marvell_nfc_suspend(struct device *dev) +{ + struct marvell_nfc *nfc = dev_get_drvdata(dev); + struct marvell_nand_chip *chip; + + list_for_each_entry(chip, &nfc->chips, node) + marvell_nfc_wait_ndrun(&chip->chip); + + clk_disable_unprepare(nfc->reg_clk); + clk_disable_unprepare(nfc->core_clk); + + return 0; +} + +static int __maybe_unused marvell_nfc_resume(struct device *dev) +{ + struct marvell_nfc *nfc = dev_get_drvdata(dev); + int ret; + + ret = clk_prepare_enable(nfc->core_clk); + if (ret < 0) + return ret; + + ret = clk_prepare_enable(nfc->reg_clk); + if (ret < 0) + return ret; + + /* + * Reset nfc->selected_chip so the next command will cause the timing + * registers to be restored in marvell_nfc_select_chip(). + */ + nfc->selected_chip = NULL; + + /* Reset registers that have lots its contents */ + writel_relaxed(NDCR_ALL_INT | NDCR_ND_ARB_EN | NDCR_SPARE_EN | + NDCR_RD_ID_CNT(NFCV1_READID_LEN), nfc->regs + NDCR); + writel_relaxed(0xFFFFFFFF, nfc->regs + NDSR); + writel_relaxed(0, nfc->regs + NDECCCTRL); + + return 0; +} + +static const struct dev_pm_ops marvell_nfc_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(marvell_nfc_suspend, marvell_nfc_resume) +}; + static const struct marvell_nfc_caps marvell_armada_8k_nfc_caps = { .max_cs_nb = 4, .max_rb_nb = 2, @@ -2908,6 +2954,7 @@ static struct platform_driver marvell_nfc_driver = { .driver = { .name = "marvell-nfc", .of_match_table = marvell_nfc_of_ids, + .pm = &marvell_nfc_pm_ops, }, .id_table = marvell_nfc_platform_ids, .probe = marvell_nfc_probe,
This patch restores the suspend and resume hooks that the old driver used to have. Apart from stopping and starting the clocks, the resume callback also nullifies the selected_chip pointer, so the next command that is issued will re-select the chip and thereby restore the timing registers. Without this patch, a PXA3xx based system would cough up an error similar to the one below after resume. [ 44.660162] marvell-nfc 43100000.nand-controller: Timeout waiting for RB signal [ 44.671492] ubi0 error: ubi_io_write: error -110 while writing 2048 bytes to PEB 102:38912, written 0 bytes [ 44.682887] CPU: 0 PID: 1417 Comm: remote-control Not tainted 4.18.0-rc2+ #344 [ 44.691197] Hardware name: Marvell PXA3xx (Device Tree Support) [ 44.697111] Backtrace: [ 44.699593] [<c0106458>] (dump_backtrace) from [<c0106718>] (show_stack+0x18/0x1c) [ 44.708931] r7:00000800 r6:00009800 r5:00000066 r4:c6139000 [ 44.715833] [<c0106700>] (show_stack) from [<c0678a60>] (dump_stack+0x20/0x28) [ 44.724206] [<c0678a40>] (dump_stack) from [<c0456cbc>] (ubi_io_write+0x3d4/0x630) [ 44.732925] [<c04568e8>] (ubi_io_write) from [<c0454428>] (ubi_eba_write_leb+0x690/0x6fc) ... Signed-off-by: Daniel Mack <daniel@zonque.org> --- drivers/mtd/nand/raw/marvell_nand.c | 47 +++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+)