summaryrefslogtreecommitdiffstats
path: root/mmc-sunxi-remove-output-of-virtual-base-address.patch
blob: 52ef3c08caef636ce7fca26cb3f7d5824dcd8c55 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
From patchwork Mon Jul 23 15:34:31 2018
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Andre Przywara <andre.przywara@arm.com>
X-Patchwork-Id: 10540521
Return-Path: <linux-mmc-owner@kernel.org>
Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org
 [172.30.200.125])
	by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1B83B157A
	for <patchwork-linux-mmc@patchwork.kernel.org>;
 Mon, 23 Jul 2018 15:34:37 +0000 (UTC)
Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1])
	by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 08A2228B94
	for <patchwork-linux-mmc@patchwork.kernel.org>;
 Mon, 23 Jul 2018 15:34:37 +0000 (UTC)
Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486)
	id F046028C33; Mon, 23 Jul 2018 15:34:36 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	pdx-wl-mail.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 903BC28B94
	for <patchwork-linux-mmc@patchwork.kernel.org>;
 Mon, 23 Jul 2018 15:34:36 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2387995AbeGWQgV (ORCPT
        <rfc822;patchwork-linux-mmc@patchwork.kernel.org>);
        Mon, 23 Jul 2018 12:36:21 -0400
Received: from foss.arm.com ([217.140.101.70]:35828 "EHLO foss.arm.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S2387968AbeGWQgV (ORCPT <rfc822;linux-mmc@vger.kernel.org>);
        Mon, 23 Jul 2018 12:36:21 -0400
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249])
        by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3D7E580D;
        Mon, 23 Jul 2018 08:34:35 -0700 (PDT)
Received: from e104803-lin.Emea.Arm.com (e104803-lin.Emea.Arm.com
 [10.4.12.215])
        by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id
 B9BD43F237;
        Mon, 23 Jul 2018 08:34:33 -0700 (PDT)
From: Andre Przywara <andre.przywara@arm.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>,
        Chen-Yu Tsai <wens@csie.org>,
        Robin Murphy <robin.murphy@arm.com>, linux-mmc@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com
Subject: [PATCH v3] mmc: sunxi: remove output of virtual base address
Date: Mon, 23 Jul 2018 16:34:31 +0100
Message-Id: <20180723153431.8669-1-andre.przywara@arm.com>
X-Mailer: git-send-email 2.14.4
Sender: linux-mmc-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-mmc.vger.kernel.org>
X-Mailing-List: linux-mmc@vger.kernel.org
X-Virus-Scanned: ClamAV using ClamSMTP

Recent Linux versions refuse to print actual virtual kernel addresses,
to not give a hint about the location of the kernel in a randomized virtual
address space. This affects the output of the sunxi MMC controller
driver, which now produces the rather uninformative line:

[    1.482660] sunxi-mmc 1c0f000.mmc: base:0x(____ptrval____) irq:8

Since the virtual base address is not really interesting in the first
place, let's just drop this value. The same applies to Linux' notion of
the interrupt number, which is independent from the GIC SPI number.
We have the physical address as part of the DT node name, which is way
more useful for debugging purposes.
To keep a success message in the driver, we make this purpose explicit
with the word "initialized", plus print some information that is not too
obvious and that we learned while probing the device:
the maximum request size and whether it uses the new timing mode.
So the output turns into:
[    1.750626] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[    1.786699] sunxi-mmc 1c11000.mmc: initialized, max. request size: 2048 KB

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
---
 drivers/mmc/host/sunxi-mmc.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 8e7f3e35ee3d..c18cf035ac00 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1407,7 +1407,10 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
 	if (ret)
 		goto error_free_dma;
 
-	dev_info(&pdev->dev, "base:0x%p irq:%u\n", host->reg_base, host->irq);
+	dev_info(&pdev->dev, "initialized, max. request size: %u KB%s\n",
+		 mmc->max_req_size >> 10,
+		 host->use_new_timings ? ", uses new timings mode" : "");
+
 	return 0;
 
 error_free_dma: