Re: [PATCH v2 4/4] mmc: renesas_sdhi: skip SCC error check when retuning
On Thu, Jul 05, 2018 at 04:18:41PM +0200, Niklas Söderlund wrote: > From: Masaharu Hayakawa > > Checking for SCC error during retuning is unnecessary. > > Signed-off-by: Masaharu Hayakawa > [Niklas: fix small style issue] > Signed-off-by: Niklas Söderlund Tested-by: Wolfram Sang Reviewed-by: Wolfram Sang
Re: [PATCH v2 2/4] mmc: tmio: Fix SCC error detection
On Thu, Jul 05, 2018 at 04:18:39PM +0200, Niklas Söderlund wrote: > From: Masaharu Hayakawa > > SDR104 and HS200 need to check for SCC error. If SCC error is detected, > retuning is necessary. > > Signed-off-by: Masaharu Hayakawa > [Niklas: update commit message] > Signed-off-by: Niklas Söderlund Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang
Re: [PATCH v2 1/4] mmc: tmio: Fix tuning flow
On Thu, Jul 05, 2018 at 04:18:38PM +0200, Niklas Söderlund wrote: > From: Masaharu Hayakawa > > If the return value of mmc_send_tuning() is error other than -EILSEQ, > the tuning fails and process goes out of for_loop. The correct > processing is to judge their TAP as not good (NG) and continue. > > Signed-off-by: Masaharu Hayakawa > [Niklas: update commit message] > Signed-off-by: Niklas Söderlund I tend to agree with Geert, but it is a minor issue for me, so Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang
Re: [PATCH v2 0/4] mmc: {tmio,renesas_sdhi}: fix tuning behavior
> Tuning failed on my R-Car H3 ES2.0 board using latest mmc/next while the > Renesas BSP kernel worked. After some digging I found patches in the BSP > which remedied this and whit these applied tuning now works for me. > > I have done small fixes, updated commit messages and rebased on latest > mmc/next but Hayakawa-san did all the real work. Thanks, Niklas. Did you also test some SD card accesses? It helped with your "stubborn" card, too, or?
Re: [PATCH v2 3/4] mmc: renesas_sdhi: Fix sampling clock position selecting
On Thu, Jul 05, 2018 at 04:18:40PM +0200, Niklas Söderlund wrote:
> From: Masaharu Hayakawa
>
> When tuning each tap is issued CMD19 twice and the result of both runs
> recorded in host->taps. If the result is different between the two runs
> the wrong sampling clock position was selected. Fix this by merging the
> two runs and only keep the result for each tap if it was good in both
> sets.
>
> Signed-off-by: Masaharu Hayakawa
> [Niklas: update commit message]
> Signed-off-by: Niklas Söderlund
Much better commit message.
> + for (i = 0; i < host->tap_num * 2; i++) {
> + if (!test_bit(i, host->taps)) {
> + clear_bit(i % host->tap_num, host->taps);
> + clear_bit((i % host->tap_num) + host->tap_num,
> + host->taps);
> + }
> + }
I just think the code is a bit clumsy maybe?
a) it clears the bit which is already cleared
b) if a bit in the first half clears a bit in the second half,
they will both be cleared again when the loop processes the
second half
One idea I have is to let the loop iterate only over tap_num and then
use a mask 'BIT(i) | BIT(i+tap_num)' and work with binary operators
then. But maybe there are also macros to test and clear bit patterns?
And Geert's comment.
[PATCH 2/8] PCI: of: Fix I/O space page leak
When testing the R-Car PCIe driver on the Condor board, I noticed that if
I left the PCIe PHY driver disabled, the kernel crashed with this BUG:
[1.225819] kernel BUG at lib/ioremap.c:72!
[1.230007] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[1.235496] Modules linked in:
[1.238561] CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092
[1.245526] Hardware name: Renesas Condor board based on r8a77980 (DT)
[1.252075] Workqueue: events deferred_probe_work_func
[1.257220] pstate: 8005 (Nzcv daif -PAN -UAO)
[1.262024] pc : ioremap_page_range+0x370/0x3c8
[1.266558] lr : ioremap_page_range+0x40/0x3c8
[1.271002] sp : 08da39e0
[1.274317] x29: 08da39e0 x28: 00e80f07
[1.279636] x27: 7dfffee0 x26: 0140
[1.284954] x25: 7dfffef0 x24: 000fe100
[1.290272] x23: 80007b906000 x22: 08ab8000
[1.295590] x21: 08bb1d58 x20: 7dfffef0
[1.300909] x19: 89c30fb8 x18: 0001
[1.306226] x17: 000152d0 x16: 014012d0
[1.311544] x15: x14: 0720072007200720
[1.316862] x13: 0720072007200720 x12: 0720072007200720
[1.322180] x11: 0720072007300730 x10: 00ae
[1.327498] x9 : x8 : 7d00
[1.332816] x7 : x6 : 0100
[1.338134] x5 : x4 : 7b906000
[1.343452] x3 : 80007c61a880 x2 : 7dfffeef
[1.348770] x1 : 4000 x0 : 00e8fe100f07
[1.354090] Process kworker/0:1 (pid: 39, stack limit = 0x(ptrval))
[1.361056] Call trace:
[1.363504] ioremap_page_range+0x370/0x3c8
[1.367695] pci_remap_iospace+0x7c/0xac
[1.371624] pci_parse_request_of_pci_ranges+0x13c/0x190
[1.376945] rcar_pcie_probe+0x4c/0xb04
[1.380786] platform_drv_probe+0x50/0xbc
[1.384799] driver_probe_device+0x21c/0x308
[1.389072] __device_attach_driver+0x98/0xc8
[1.393431] bus_for_each_drv+0x54/0x94
[1.397269] __device_attach+0xc4/0x12c
[1.401107] device_initial_probe+0x10/0x18
[1.405292] bus_probe_device+0x90/0x98
[1.409130] deferred_probe_work_func+0xb0/0x150
[1.413756] process_one_work+0x12c/0x29c
[1.417768] worker_thread+0x200/0x3fc
[1.421522] kthread+0x108/0x134
[1.424755] ret_from_fork+0x10/0x18
[1.428334] Code: f9004ba2 5480 aa0003fb 1748 (d421)
It turned out that pci_remap_iospace() wasn't undone when the driver's
probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
the probe was retried, finally causing the BUG due to trying to remap
already remapped pages.
The most feasible solution seemed to introduce devm_pci_remap_iospace() --
which was done in the XGene PCIe driver patch posted earlier...
Fixes: dbf9826d5797 ("PCI: generic: Convert to DT resource parsing API")
Signed-off-by: Sergei Shtylyov
Reviewed-by: Linus Walleij
Acked-by: Bjorn Helgaas
---
drivers/pci/of.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: pci/drivers/pci/of.c
===
--- pci.orig/drivers/pci/of.c
+++ pci/drivers/pci/of.c
@@ -612,7 +612,7 @@ int pci_parse_request_of_pci_ranges(stru
switch (resource_type(res)) {
case IORESOURCE_IO:
- err = pci_remap_iospace(res, iobase);
+ err = devm_pci_remap_iospace(dev, res, iobase);
if (err) {
dev_warn(dev, "error %d: failed to map resource
%pR\n",
err, res);
[PATCH 0/8] Fix PCI I/O space page leaks
Hello! Here's a set of 8 patches against the 'pci/controller-fixes' branch of Lorenzo Pieralisi's 'pci.git' repo. They are the fixes for the PCI I/O space page leaks (and the kernel BUG caused by them on deferred probe); those were 1st found testing the R-Car PCIe driver. The patches are in the chronological order (considering the date/time of the commits specified in the Fixes: tag), patches #2..#8 depend on the patch #1 in order to build/work as it introduces the managed device API that they all use... [1/8] PCI: xgene: Fix I/O space page leak [2/8] PCI: of: Fix I/O space page leak [3/8] PCI: versatile: Fix I/O space page leak [4/8] PCI: designware: Fix I/O space page leak [5/8] PCI: aardvark: Fix I/O space page leak [6/8] PCI: faraday: Fix I/O space page leak [7/8] PCI: mediatek: Fix I/O space page leak [8/8] PCI: v3-semi: Fix I/O space page leak MBR, Sergei
