* Dynamic ftrace self test broken on ARM
From: Stefan Agner @ 2018-06-20 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7904ed3fe9f59a54526d64f366915b43@agner.ch>
On 20.06.2018 21:06, Stefan Agner wrote:
> On 20.06.2018 16:13, Steven Rostedt wrote:
>> On Wed, 20 Jun 2018 15:51:55 +0200
>> Stefan Agner <stefan@agner.ch> wrote:
>>
>>
>>> v4.9 seems to work, so I started bisecting. It turned out that commit
>>> 6f05d0761af6 ("ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA
>>> and !FRAME_POINTER") broke it, introduced during the v4.12 merge window.
>>
>> That patch doesn't appear to be the cause. It could have been a failed
>> bisect. Does the commit before that commit work? Does that commit fail?
>
> Pretty sure it is that one. Reverting it on top of v4.18-rc1 fixes it...
>
>>
>> It may be due to some other RODATA change though. That is actually one
>> of my thoughts when looking at the bug.
>
> CONFIG_STRICT_KERNEL_RWX=y is set, will test without.
Compiling without CONFIG_STRICT_KERNEL_RWX fixes the issue too. So seems
to be a RODATA issue...
--
Stefan
^ permalink raw reply
* [PATCH v3 02/17] khwasan: move common kasan and khwasan code to common.c
From: kbuild test robot @ 2018-06-20 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <687f2c3ce27015abb6bc412646894ae40051d8af.1529515183.git.andreyknvl@google.com>
Hi Andrey,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mmotm/master]
[also build test ERROR on v4.18-rc1 next-20180620]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andrey-Konovalov/khwasan-kernel-hardware-assisted-address-sanitizer/20180621-035912
base: git://git.cmpxchg.org/linux-mmotm.git master
config: x86_64-randconfig-x011-201824 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the linux-review/Andrey-Konovalov/khwasan-kernel-hardware-assisted-address-sanitizer/20180621-035912 HEAD 0e30ed7118e854b38bb6ab96365e7c74a2518290 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> mm//kasan/report.c:42:20: error: conflicting types for 'find_first_bad_addr'
static const void *find_first_bad_addr(const void *addr, size_t size)
^~~~~~~~~~~~~~~~~~~
In file included from mm//kasan/report.c:33:0:
mm//kasan/kasan.h:130:7: note: previous declaration of 'find_first_bad_addr' was here
void *find_first_bad_addr(void *addr, size_t size);
^~~~~~~~~~~~~~~~~~~
>> mm//kasan/report.c:54:13: error: conflicting types for 'addr_has_shadow'
static bool addr_has_shadow(struct kasan_access_info *info)
^~~~~~~~~~~~~~~
In file included from mm//kasan/report.c:33:0:
mm//kasan/kasan.h:120:20: note: previous definition of 'addr_has_shadow' was here
static inline bool addr_has_shadow(const void *addr)
^~~~~~~~~~~~~~~
mm//kasan/report.c: In function 'get_shadow_bug_type':
mm//kasan/report.c:86:2: error: duplicate case value
case KASAN_KMALLOC_REDZONE:
^~~~
mm//kasan/report.c:85:2: note: previously used here
case KASAN_PAGE_REDZONE:
^~~~
mm//kasan/report.c:98:2: error: duplicate case value
case KASAN_FREE_PAGE:
^~~~
mm//kasan/report.c:85:2: note: previously used here
case KASAN_PAGE_REDZONE:
^~~~
mm//kasan/report.c:99:2: error: duplicate case value
case KASAN_KMALLOC_FREE:
^~~~
mm//kasan/report.c:85:2: note: previously used here
case KASAN_PAGE_REDZONE:
^~~~
mm//kasan/report.c: At top level:
>> mm//kasan/report.c:128:20: error: static declaration of 'get_bug_type' follows non-static declaration
static const char *get_bug_type(struct kasan_access_info *info)
^~~~~~~~~~~~
In file included from mm//kasan/report.c:33:0:
mm//kasan/kasan.h:131:13: note: previous declaration of 'get_bug_type' was here
const char *get_bug_type(struct kasan_access_info *info);
^~~~~~~~~~~~
vim +/find_first_bad_addr +42 mm//kasan/report.c
0b24becc Andrey Ryabinin 2015-02-13 41
0b24becc Andrey Ryabinin 2015-02-13 @42 static const void *find_first_bad_addr(const void *addr, size_t size)
0b24becc Andrey Ryabinin 2015-02-13 43 {
0b24becc Andrey Ryabinin 2015-02-13 44 u8 shadow_val = *(u8 *)kasan_mem_to_shadow(addr);
0b24becc Andrey Ryabinin 2015-02-13 45 const void *first_bad_addr = addr;
0b24becc Andrey Ryabinin 2015-02-13 46
0b24becc Andrey Ryabinin 2015-02-13 47 while (!shadow_val && first_bad_addr < addr + size) {
0b24becc Andrey Ryabinin 2015-02-13 48 first_bad_addr += KASAN_SHADOW_SCALE_SIZE;
0b24becc Andrey Ryabinin 2015-02-13 49 shadow_val = *(u8 *)kasan_mem_to_shadow(first_bad_addr);
0b24becc Andrey Ryabinin 2015-02-13 50 }
0b24becc Andrey Ryabinin 2015-02-13 51 return first_bad_addr;
0b24becc Andrey Ryabinin 2015-02-13 52 }
0b24becc Andrey Ryabinin 2015-02-13 53
5e82cd12 Andrey Konovalov 2017-05-03 @54 static bool addr_has_shadow(struct kasan_access_info *info)
5e82cd12 Andrey Konovalov 2017-05-03 55 {
5e82cd12 Andrey Konovalov 2017-05-03 56 return (info->access_addr >=
5e82cd12 Andrey Konovalov 2017-05-03 57 kasan_shadow_to_mem((void *)KASAN_SHADOW_START));
5e82cd12 Andrey Konovalov 2017-05-03 58 }
5e82cd12 Andrey Konovalov 2017-05-03 59
5e82cd12 Andrey Konovalov 2017-05-03 60 static const char *get_shadow_bug_type(struct kasan_access_info *info)
0b24becc Andrey Ryabinin 2015-02-13 61 {
0952d87f Andrey Konovalov 2015-11-05 62 const char *bug_type = "unknown-crash";
cdf6a273 Andrey Konovalov 2015-11-05 63 u8 *shadow_addr;
0b24becc Andrey Ryabinin 2015-02-13 64
0b24becc Andrey Ryabinin 2015-02-13 65 info->first_bad_addr = find_first_bad_addr(info->access_addr,
0b24becc Andrey Ryabinin 2015-02-13 66 info->access_size);
0b24becc Andrey Ryabinin 2015-02-13 67
cdf6a273 Andrey Konovalov 2015-11-05 68 shadow_addr = (u8 *)kasan_mem_to_shadow(info->first_bad_addr);
0b24becc Andrey Ryabinin 2015-02-13 69
cdf6a273 Andrey Konovalov 2015-11-05 70 /*
cdf6a273 Andrey Konovalov 2015-11-05 71 * If shadow byte value is in [0, KASAN_SHADOW_SCALE_SIZE) we can look
cdf6a273 Andrey Konovalov 2015-11-05 72 * at the next shadow byte to determine the type of the bad access.
cdf6a273 Andrey Konovalov 2015-11-05 73 */
cdf6a273 Andrey Konovalov 2015-11-05 74 if (*shadow_addr > 0 && *shadow_addr <= KASAN_SHADOW_SCALE_SIZE - 1)
cdf6a273 Andrey Konovalov 2015-11-05 75 shadow_addr++;
cdf6a273 Andrey Konovalov 2015-11-05 76
cdf6a273 Andrey Konovalov 2015-11-05 77 switch (*shadow_addr) {
0952d87f Andrey Konovalov 2015-11-05 78 case 0 ... KASAN_SHADOW_SCALE_SIZE - 1:
cdf6a273 Andrey Konovalov 2015-11-05 79 /*
cdf6a273 Andrey Konovalov 2015-11-05 80 * In theory it's still possible to see these shadow values
cdf6a273 Andrey Konovalov 2015-11-05 81 * due to a data race in the kernel code.
cdf6a273 Andrey Konovalov 2015-11-05 82 */
0952d87f Andrey Konovalov 2015-11-05 83 bug_type = "out-of-bounds";
b8c73fc2 Andrey Ryabinin 2015-02-13 84 break;
0316bec2 Andrey Ryabinin 2015-02-13 85 case KASAN_PAGE_REDZONE:
0316bec2 Andrey Ryabinin 2015-02-13 86 case KASAN_KMALLOC_REDZONE:
0952d87f Andrey Konovalov 2015-11-05 87 bug_type = "slab-out-of-bounds";
0952d87f Andrey Konovalov 2015-11-05 88 break;
bebf56a1 Andrey Ryabinin 2015-02-13 89 case KASAN_GLOBAL_REDZONE:
0952d87f Andrey Konovalov 2015-11-05 90 bug_type = "global-out-of-bounds";
0b24becc Andrey Ryabinin 2015-02-13 91 break;
c420f167 Andrey Ryabinin 2015-02-13 92 case KASAN_STACK_LEFT:
c420f167 Andrey Ryabinin 2015-02-13 93 case KASAN_STACK_MID:
c420f167 Andrey Ryabinin 2015-02-13 94 case KASAN_STACK_RIGHT:
c420f167 Andrey Ryabinin 2015-02-13 95 case KASAN_STACK_PARTIAL:
0952d87f Andrey Konovalov 2015-11-05 96 bug_type = "stack-out-of-bounds";
0952d87f Andrey Konovalov 2015-11-05 97 break;
0952d87f Andrey Konovalov 2015-11-05 98 case KASAN_FREE_PAGE:
0952d87f Andrey Konovalov 2015-11-05 @99 case KASAN_KMALLOC_FREE:
0952d87f Andrey Konovalov 2015-11-05 100 bug_type = "use-after-free";
c420f167 Andrey Ryabinin 2015-02-13 101 break;
828347f8 Dmitry Vyukov 2016-11-30 102 case KASAN_USE_AFTER_SCOPE:
828347f8 Dmitry Vyukov 2016-11-30 103 bug_type = "use-after-scope";
828347f8 Dmitry Vyukov 2016-11-30 104 break;
342061ee Paul Lawrence 2018-02-06 105 case KASAN_ALLOCA_LEFT:
342061ee Paul Lawrence 2018-02-06 106 case KASAN_ALLOCA_RIGHT:
342061ee Paul Lawrence 2018-02-06 107 bug_type = "alloca-out-of-bounds";
342061ee Paul Lawrence 2018-02-06 108 break;
0b24becc Andrey Ryabinin 2015-02-13 109 }
0b24becc Andrey Ryabinin 2015-02-13 110
5e82cd12 Andrey Konovalov 2017-05-03 111 return bug_type;
5e82cd12 Andrey Konovalov 2017-05-03 112 }
5e82cd12 Andrey Konovalov 2017-05-03 113
822d5ec2 Colin Ian King 2017-07-10 114 static const char *get_wild_bug_type(struct kasan_access_info *info)
5e82cd12 Andrey Konovalov 2017-05-03 115 {
5e82cd12 Andrey Konovalov 2017-05-03 116 const char *bug_type = "unknown-crash";
5e82cd12 Andrey Konovalov 2017-05-03 117
5e82cd12 Andrey Konovalov 2017-05-03 118 if ((unsigned long)info->access_addr < PAGE_SIZE)
5e82cd12 Andrey Konovalov 2017-05-03 119 bug_type = "null-ptr-deref";
5e82cd12 Andrey Konovalov 2017-05-03 120 else if ((unsigned long)info->access_addr < TASK_SIZE)
5e82cd12 Andrey Konovalov 2017-05-03 121 bug_type = "user-memory-access";
5e82cd12 Andrey Konovalov 2017-05-03 122 else
5e82cd12 Andrey Konovalov 2017-05-03 123 bug_type = "wild-memory-access";
5e82cd12 Andrey Konovalov 2017-05-03 124
5e82cd12 Andrey Konovalov 2017-05-03 125 return bug_type;
5e82cd12 Andrey Konovalov 2017-05-03 126 }
5e82cd12 Andrey Konovalov 2017-05-03 127
7d418f7b Andrey Konovalov 2017-05-03 @128 static const char *get_bug_type(struct kasan_access_info *info)
7d418f7b Andrey Konovalov 2017-05-03 129 {
7d418f7b Andrey Konovalov 2017-05-03 130 if (addr_has_shadow(info))
7d418f7b Andrey Konovalov 2017-05-03 131 return get_shadow_bug_type(info);
7d418f7b Andrey Konovalov 2017-05-03 132 return get_wild_bug_type(info);
7d418f7b Andrey Konovalov 2017-05-03 133 }
7d418f7b Andrey Konovalov 2017-05-03 134
:::::: The code at line 42 was first introduced by commit
:::::: 0b24becc810dc3be6e3f94103a866f214c282394 kasan: add kernel address sanitizer infrastructure
:::::: TO: Andrey Ryabinin <a.ryabinin@samsung.com>
:::::: CC: Linus Torvalds <torvalds@linux-foundation.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 35183 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180621/2afd5535/attachment-0001.gz>
^ permalink raw reply
* [PATCH v4] ARM: dts: imx51-zii-rdu1: fix touchscreen pinctrl
From: Nick Dyer @ 2018-06-20 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BTMRJmrjM7X3-7Qi1wuciOnLZhAUuWN27Dtoc0cZXVSA@mail.gmail.com>
The pinctrl settings were incorrect for the touchscreen interrupt line, causing
an interrupt storm. This change has been tested with both the atmel_mxt_ts and
RMI4 drivers on the RDU1 units.
The value 0x4 comes from the value of register IOMUXC_SW_PAD_CTL_PAD_CSI1_D8
from the old vendor kernel.
Signed-off-by: Nick Dyer <nick@shmanahar.org>
Fixes: ceef0396f367 ("ARM: dts: imx: add ZII RDU1 board")
Cc: <stable@vger.kernel.org> # 4.15+
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes in v4:
- Add reviewed by Fabio
Changes in v3:
- Update commit message to add source of 0x4 value, fixes tag and CC stable
Changes in v2:
- Use hex, only alter IRQ line config
arch/arm/boot/dts/imx51-zii-rdu1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index df9eca94d812..8a878687197b 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -770,7 +770,7 @@
pinctrl_ts: tsgrp {
fsl,pins = <
- MX51_PAD_CSI1_D8__GPIO3_12 0x85
+ MX51_PAD_CSI1_D8__GPIO3_12 0x04
MX51_PAD_CSI1_D9__GPIO3_13 0x85
>;
};
--
2.17.1
^ permalink raw reply related
* [PATCH v3] ARM: dts: imx51-zii-rdu1: fix touchscreen pinctrl
From: Fabio Estevam @ 2018-06-20 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620202045.27965-1-nick@shmanahar.org>
On Wed, Jun 20, 2018 at 5:20 PM, Nick Dyer <nick@shmanahar.org> wrote:
> The pinctrl settings were incorrect for the touchscreen interrupt line, causing
> an interrupt storm. This change has been tested with both the atmel_mxt_ts and
> RMI4 drivers on the RDU1 units.
>
> The value 0x4 comes from the value of register IOMUXC_SW_PAD_CTL_PAD_CSI1_D8
> from the old vendor kernel.
>
> Signed-off-by: Nick Dyer <nick@shmanahar.org>
> Fixes: ceef0396f367 ("ARM: dts: imx: add ZII RDU1 board")
> Cc: <stable@vger.kernel.org> # 4.15+
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v2 03/10] input: rohm_bu21023: switch to i2c_lock_bus(..., I2C_LOCK_SEGMENT)
From: Dmitry Torokhov @ 2018-06-20 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620051803.12206-4-peda@axentia.se>
On Wed, Jun 20, 2018 at 07:17:56AM +0200, Peter Rosin wrote:
> Locking the root adapter for __i2c_transfer will deadlock if the
> device sits behind a mux-locked I2C mux. Switch to the finer-grained
> i2c_lock_bus with the I2C_LOCK_SEGMENT flag. If the device does not
> sit behind a mux-locked mux, the two locking variants are equivalent.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Still
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Feel free to merge through I2C tree.
> ---
> drivers/input/touchscreen/rohm_bu21023.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/rohm_bu21023.c b/drivers/input/touchscreen/rohm_bu21023.c
> index bda0500c9b57..714affdd742f 100644
> --- a/drivers/input/touchscreen/rohm_bu21023.c
> +++ b/drivers/input/touchscreen/rohm_bu21023.c
> @@ -304,7 +304,7 @@ static int rohm_i2c_burst_read(struct i2c_client *client, u8 start, void *buf,
> msg[1].len = len;
> msg[1].buf = buf;
>
> - i2c_lock_adapter(adap);
> + i2c_lock_bus(adap, I2C_LOCK_SEGMENT);
>
> for (i = 0; i < 2; i++) {
> if (__i2c_transfer(adap, &msg[i], 1) < 0) {
> @@ -313,7 +313,7 @@ static int rohm_i2c_burst_read(struct i2c_client *client, u8 start, void *buf,
> }
> }
>
> - i2c_unlock_adapter(adap);
> + i2c_unlock_bus(adap, I2C_LOCK_SEGMENT);
>
> return ret;
> }
> --
> 2.11.0
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH] ARM: pxa: zylonite: use the new ac97 bus support
From: Robert Jarzmik @ 2018-06-20 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180603201702.15919-1-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> Now the PXA is converted to new ac97 bus support, the wm9713 is
> automatically detected and probed. Remove it from the platform bus.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> arch/arm/mach-pxa/zylonite.c | 11 -----------
> 1 file changed, 11 deletions(-)
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: add the missing AC97 clocks
From: Robert Jarzmik @ 2018-06-20 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180603201539.15704-1-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> The AC97 bit clock is added as the pxa internally generated 13MHz
> clock. This is a consequence of the new ac97 framework.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> arch/arm/mach-pxa/devices.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: mioa701 convert to the new AC97 bus
From: Robert Jarzmik @ 2018-06-20 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180527192338.21606-1-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> This migration implies :
> - wm9713 device is removed, it will be auto-probed
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
> ---
> arch/arm/mach-pxa/mioa701.c | 2 --
> 1 file changed, 2 deletions(-)
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: hx4700: fix the usb client
From: Robert Jarzmik @ 2018-06-20 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180526093834.21277-1-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> The usb client of the hx4700 is not working because no platform data is
> declared. Fix it by adding the missing call.
>
> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Queued to pxa/for-next.
--
Robert
^ permalink raw reply
* [PATCH v3] ARM: dts: imx51-zii-rdu1: fix touchscreen pinctrl
From: Nick Dyer @ 2018-06-20 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180620194239.2730-1-nick@shmanahar.org>
The pinctrl settings were incorrect for the touchscreen interrupt line, causing
an interrupt storm. This change has been tested with both the atmel_mxt_ts and
RMI4 drivers on the RDU1 units.
The value 0x4 comes from the value of register IOMUXC_SW_PAD_CTL_PAD_CSI1_D8
from the old vendor kernel.
Signed-off-by: Nick Dyer <nick@shmanahar.org>
Fixes: ceef0396f367 ("ARM: dts: imx: add ZII RDU1 board")
Cc: <stable@vger.kernel.org> # 4.15+
---
Changes in v3:
- Update commit message to add source of 0x4 value, fixes tag and CC stable
Changes in v2:
- Use hex, only alter IRQ line config
arch/arm/boot/dts/imx51-zii-rdu1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index df9eca94d812..8a878687197b 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -770,7 +770,7 @@
pinctrl_ts: tsgrp {
fsl,pins = <
- MX51_PAD_CSI1_D8__GPIO3_12 0x85
+ MX51_PAD_CSI1_D8__GPIO3_12 0x04
MX51_PAD_CSI1_D9__GPIO3_13 0x85
>;
};
--
2.17.1
^ permalink raw reply related
* [PATCH 1/1] arm64: dts: rockchip: correct voltage selector Firefly-RK3399
From: Heinrich Schuchardt @ 2018-06-20 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6592028.l3WmXB2ndK@diego>
On 06/20/2018 11:15 AM, Heiko St?bner wrote:
> Hi Heinrich,
>
> Am Mittwoch, 20. Juni 2018, 07:59:34 CEST schrieb Heinrich Schuchardt:
>> On 06/20/2018 01:21 AM, Heiko Stuebner wrote:
>>> Am Donnerstag, 14. Juni 2018, 14:55:27 CEST schrieb Heiko Stuebner:
>>>> Am Montag, 4. Juni 2018, 19:15:23 CEST schrieb Heinrich Schuchardt:
>>>>> Without this patch the Firefly-RK3399 board boot process hangs after
>>>>> these
>>>>>
>>>>> lines:
>>>>> fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
>>>>> fan53555-reg: supplied by vcc_sys
>>>>> vcc1v8_s3: supplied by vcc_1v8
>>>>>
>>>>> Blacklisting driver fan53555 allows booting.
>>>>>
>>>>> The device tree uses a value of fcs,suspend-voltage-selector different
>>>>> to
>>>>> any other board.
>>>>>
>>>>> Changing this setting to the usual value is sufficient to enable
>>>>> booting.
>>>>>
>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>
>>>> applied for 4.19.
>>>
>>> and dropped again.
>>>
>>> Sadly it looks like the patch causes conflicts with at least one firefly
>>> board in a kernelci lab. My own is currently not ready to use, so I cannot
>>> look myself right now.
>>>
>>> The issue kernelci people described sounded quite a lot like the one
>>> in your commit message, so my current theory is that the
>>> suspend-voltage-selector must in some form corespond to the
>>> cpu_b_sleep_h gpio setting we're currently not handling at all, which
>>> would therefore depend on how the bootloader sets this up.
>>
>> please, provide a link to the log displaying the issue and the contact
>> who can provide the exact setup.
>>
>> I have been testing with U-Boot as boot loader.
>
> failing boot can be found on
> https://kernelci.org/boot/id/5b2a053d59b514569079a872/
>
> As this board is sitting in the "lab-baylibre-seattle", I guess
> Kevin Hilman (Cc'ed now) is the one that can say a bit more about the
> board setup.
>
>
> The more interesting question would be how to make sure we don't
> die with possible different bootloader versions. As I don't really thing
> "upgrade your bootloader" is an always valid option.
>
>
> Heiko
>
Hi Kevin,
the RK3399-Firefly was booted on lab-baylibre-seattle with
U-Boot 2017.05-rc3-00131-gf79fd58d5f5c-dirty
f79fd58d5f5c is not a commit in U-Boot master.
The version number tells us it is 131 patches ahead of U-Boot 2017.05-rc3.
Dirty means the source contained uncommitted changes.
Unfortunately this is not a reproducible test environment.
Could you, please, provide the build recipe to reproduce the U-Boot
BayLibre is using?
Would it be possible to use mainline U-Boot in kernelci for this board?
Best regards
Heinrich
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: misc: Aspeed coprocessor interrupt controller
From: Rob Herring @ 2018-06-20 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618045902.11453-3-benh@kernel.crashing.org>
On Mon, Jun 18, 2018 at 02:59:00PM +1000, Benjamin Herrenschmidt wrote:
> Add the device-tree binding definition for the AST2400
> and AST2500 coprocessor interrupt controller
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> .../devicetree/bindings/misc/aspeed,cvic.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/aspeed,cvic.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/aspeed,cvic.txt b/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
> new file mode 100644
> index 000000000000..2562e2991e4d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
> @@ -0,0 +1,35 @@
> +* Aspeed AST2400 and AST2500 coprocessor interrupt controller
> +
> +This file describes the bindings for the interrupt controller present
> +in the AST2400 and AST2500 BMC SoCs which provides interrupt to the
> +ColdFire coprocessor.
> +
> +It is not a normal interrupt controller and it would be rather
> +inconvenient to create an interrupt tree for it as it somewhat shares
> +some of the same sources as the main ARM interrupt controller but with
> +different numbers.
> +
> +The AST2500 supports a SW generated interrupt
> +
> +Required properties:
> +- reg: address and length of the register for the device.
> +- compatible: "aspeed,cvic" and one of:
> + "aspeed,ast2400-cvic"
> + or
> + "aspeed,ast2500-cvic"
> +
> +- valid-sources: One cell, bitmap of supported sources for the implementation
aspeed,valid-sources
This could use a better description. I thought this was which bits to
use for s/w irq, but then I read the next property...
Alternatively, why can't this be implied by the compatible?
> +
> +Optional properties;
> +- copro-sw-interrupts: List of interrupt numbers that can be used as
> + SW interrupts from the ARM to the coprocessor.
> + (AST2500 only)
> +
> +Example:
> +
> + cvic: copro-interrupt-controller at 1e6c2000 {
> + compatible = "aspeed,ast2500-cvic";
> + valid-sources = <0xffffffff>;
> + copro-sw-interrupts = <1>;
> + reg = <0x1e6c2000 0x80>;
> + };
> --
> 2.17.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 3/4] dt-bindings: arm: fsl: add scu binding doc
From: Rob Herring @ 2018-06-20 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529239789-26849-4-git-send-email-aisheng.dong@nxp.com>
On Sun, Jun 17, 2018 at 08:49:48PM +0800, Dong Aisheng wrote:
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
> resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> (QM, QP), and i.MX8QX (QXP, DX).
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> v1->v2:
> * remove status
> * changed to mu1
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> new file mode 100644
> index 0000000..9b7c9fe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -0,0 +1,38 @@
> +NXP i.MX System Controller Firmware (SCFW)
> +--------------------------------------------------------------------
> +
> +The System Controller Firmware (SCFW) is a low-level system function
> +which runs on a dedicated Cortex-M core to provide power, clock, and
> +resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> +(QM, QP), and i.MX8QX (QXP, DX).
> +
> +The AP communicates with the SC using a multi-ported MU module found
> +in the LSIO subsystem. The current definition of this MU module provides
> +5 remote AP connections to the SC to support up to 5 execution environments
> +(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
> +with the LSIO DSC IP bus. The SC firmware will communicate with this MU
> +using the MSI bus.
> +
> +System Controller Device Node:
> +=============================
> +
> +Required properties:
> +-------------------
> +- compatible: should be "fsl,imx8qxp-scu" or "fsl,imx8qm-scu"
> +- fsl,mu: a phandle to the Message Unit used by SCU. Should be
> + one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
> + to make sure not use the one which is conflict with
> + other execution environments. e.g. ATF.
Use the mailbox binding even if you don't use the mailbox subsystem.
> +
> +Examples:
> +--------
> +lsio_mu1: mu at 5d1c0000 {
> + compatible = "fsl,imx8qxp-mu";
> + reg = <0x0 0x5d1c0000 0x0 0x10000>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> +};
> +
> +scu {
> + compatible = "fsl,imx8qxp-scu";
> + fsl,mu = <&lsio_mu1>;
> +};
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 17/17] kasan: add SPDX-License-Identifier mark to source files
From: Fabio Estevam @ 2018-06-20 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAeHK+zJgSAxiHHfzhrm7N7iey7CbW42WfWvUN+FnZMPP3FXrA@mail.gmail.com>
On Wed, Jun 20, 2018 at 4:41 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> I used mm/slub.c as a reference, which uses //. Bu I can change it to
> /* */ in the next version, no problem.
C source files should use //. C header files should use /* */
This is documented at Documentation/process/license-rules.rst
^ permalink raw reply
* [PATCH V2 2/4] dt-bindings: arm: fsl: add mu binding doc
From: Rob Herring @ 2018-06-20 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529239789-26849-3-git-send-email-aisheng.dong@nxp.com>
On Sun, Jun 17, 2018 at 08:49:47PM +0800, Dong Aisheng wrote:
> The Messaging Unit module enables two processors within
> the SoC to communicate and coordinate by passing messages
> (e.g. data, status and control) through the MU interface.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> v1->v2:
> * typo fixes
> * remove status property
> * remove imx6&7 compatible string which may be added later for
> the generic mailbox binding
>
> Note: Because MU used by SCU is not implemented as a mailbox driver,
> Instead, they're provided in library calls to gain higher performance.
Using a binding doesn't mean you have to use an OS's subsystem.
What needs higher performance? What's the performance difference? Why
can't the mailbox framework be improved?
> Futhermore, SCU MU has only one channel. But the binding doc claims
> (Change to allow 0?)
> So we did not follow the mailbox binding.
>
> For the generic mailbox driver binding way, it may be added later.
The h/w isn't changing later, so no.
> ---
> .../devicetree/bindings/arm/freescale/fsl,mu.txt | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,mu.txt
^ permalink raw reply
* [PATCH v2] ARM: dts: imx51-zii-rdu1: fix touchscreen pinctrl
From: Nick Dyer @ 2018-06-20 19:42 UTC (permalink / raw)
To: linux-arm-kernel
The pinctrl settings were incorrect for the touchscreen interrupt line, causing
an interrupt storm. This change has been tested with both the atmel_mxt_ts and
RMI4 drivers on the RDU1 units.
[v2: Use hex, only alter IRQ line config]
Signed-off-by: Nick Dyer <nick@shmanahar.org>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index df9eca94d812..8a878687197b 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -770,7 +770,7 @@
pinctrl_ts: tsgrp {
fsl,pins = <
- MX51_PAD_CSI1_D8__GPIO3_12 0x85
+ MX51_PAD_CSI1_D8__GPIO3_12 0x04
MX51_PAD_CSI1_D9__GPIO3_13 0x85
>;
};
--
2.17.1
^ permalink raw reply related
* [PATCH v3 17/17] kasan: add SPDX-License-Identifier mark to source files
From: Andrey Konovalov @ 2018-06-20 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BgPaMsmx_3AJvMTKCFjhusfH=kH26U_PQCSD5TcUDA+w@mail.gmail.com>
On Wed, Jun 20, 2018 at 9:15 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Wed, Jun 20, 2018 at 2:40 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>
>> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
>> index 6f4f2ebf5f57..3feacd889e24 100644
>> --- a/mm/kasan/kasan.h
>> +++ b/mm/kasan/kasan.h
>> @@ -1,4 +1,4 @@
>> -/* SPDX-License-Identifier: GPL-2.0 */
>> +// SPDX-License-Identifier: GPL-2.0
>
> The original notation is correct: /* */ style is used for header files.
I used mm/slub.c as a reference, which uses //. Bu I can change it to
/* */ in the next version, no problem.
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
From: Jernej Škrabec @ 2018-06-20 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66Tv7876_heSve0zb+vWfz9kbwbrU8NjnpTwUHm6xOKJQ@mail.gmail.com>
Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec <jernej.skrabec@siol.net>
wrote:
> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
> >>
> >> <jernej.skrabec@siol.net> wrote:
> >> > Hi,
> >> >
> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> >> Hi,
> >> >>
> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> > order
> >> >> > to work.
> >> >> >
> >> >> > Add support for such TCONs.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> > ---
> >> >> >
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > 2 files changed, 15 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > 100644
> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> >> > *dev,
> >> >> >
> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> > return PTR_ERR(tcon->clk);
> >> >> >
> >> >> > }
> >> >> >
> >> >> > +
> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> > clock\n");
> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > + }
> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > + }
> >> >> > +
> >> >>
> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> functional?
> >> >>
> >> >> I find it quite odd to have a clock that isn't meant for a particular
> >> >> device to actually be wired to another device. I'm not saying this
> >> >> isn't the case, but it would be a first.
> >> >
> >> > Documentation doesn't say much about that gate. I did few tests and
> >> > TCON
> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> > disabled. However, there is no image, as expected.
> >>
> >> The R40 manual does include it in the diagram, on page 504. There's also
> >> a
> >> mux to select whether the clock comes directly from the CCU or the TV
> >> encoder (a feedback mode?). I assume this is the gate you are referring
> >> to
> >> here, in which case it is not a bus clock, but rather the TCON module or
> >> channel clock, strangely routed.
> >>
> >> > More interestingly, I enabled test pattern directly in TCON to
> >> > eliminate
> >> > influence of the mixer. As soon as I disabled that gate, test pattern
> >> > on
> >> > HDMI screen was gone, which suggest that this gate influences something
> >> > inside TCON.
> >> >
> >> > Another test I did was that I moved enable/disable gate code to
> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >
> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
> >> > I
> >> > would say that most appropriate location to enable/disable TCON TOP TV
> >> > TCON
> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
> >> > TV
> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
> >> > right to me for some reason.
> >>
> >> If what I said above it true, then yes, the appropriate location to
> >> enable
> >> it is the TCON driver, but moreover, the representation of the clock tree
> >> should be fixed such that the TCON takes the clock from the TCON TOP as
> >> its
> >> channel/ module clock instead. That way you don't need this patch, but
> >> you'd add another for all the clock routing.
> >
> > Can you be more specific? I not sure what you mean here.
>
> For clock related properties in the device tree:
>
> &tcon_top {
> clocks = <&ccu CLK_BUS_TCON_TOP>,
> <&ccu CLK_TCON_TV0>,
> <&tve0>,
> <&ccu CLK_TCON_TV1>,
> <&tve1>;
> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> };
>
> &tcon_tv0 {
> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> clock-names = "ahb", "tcon-ch1";
> };
>
> A diagram would look like:
> | This part is TCON TOP |
>
> v v
> CCU CLK_TCON_TV0 --|----\ |
>
> | mux ---- gate ----|-- TCON_TV0
>
> TVE0 --------------|----/ |
>
> And the same goes for TCON_TV1 and TVE1.
>
> The user manual is a bit lacking on how TVE outputs a clock though.
I didn't yet received any response on HW details from AW till now, but I would
like to post new version of patches soon.
While chaining like you described could be implemented easily, I don't think
it really represents HW as it is. Tests showed that these two clocks are
independent, otherwise register writes/reads wouldn't be possible with tcon-
top gate disabled. I chose tcon-top bus clock as a parent becase if it is not
enabled, it simply won't work.
However, if everyone feels chaining is the best way to implement it, I'll do
it.
Best regards,
Jernej
^ permalink raw reply
* [PATCH] pci: fix I/O space page leak
From: Jingoo Han @ 2018-06-20 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1ca6adde-a91e-84d0-c7dc-fd01bfd9edcc@cogentembedded.com>
On Wednesday, June 20, 2018 1:52 PM, Sergei Shtylyov wrote:
>
> When testing the R-Car PCIe driver on the Condor board, I noticed that iff
> 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: 80000005 (Nzcv daif -PAN -UAO)
> [ 1.262024] pc : ioremap_page_range+0x370/0x3c8
> [ 1.266558] lr : ioremap_page_range+0x40/0x3c8
> [ 1.271002] sp : ffff000008da39e0
> [ 1.274317] x29: ffff000008da39e0 x28: 00e8000000000f07
> [ 1.279636] x27: ffff7dfffee00000 x26: 0140000000000000
> [ 1.284954] x25: ffff7dfffef00000 x24: 00000000000fe100
> [ 1.290272] x23: ffff80007b906000 x22: ffff000008ab8000
> [ 1.295590] x21: ffff000008bb1d58 x20: ffff7dfffef00000
> [ 1.300909] x19: ffff800009c30fb8 x18: 0000000000000001
> [ 1.306226] x17: 00000000000152d0 x16: 00000000014012d0
> [ 1.311544] x15: 0000000000000000 x14: 0720072007200720
> [ 1.316862] x13: 0720072007200720 x12: 0720072007200720
> [ 1.322180] x11: 0720072007300730 x10: 00000000000000ae
> [ 1.327498] x9 : 0000000000000000 x8 : ffff7dffff000000
> [ 1.332816] x7 : 0000000000000000 x6 : 0000000000000100
> [ 1.338134] x5 : 0000000000000000 x4 : 000000007b906000
> [ 1.343452] x3 : ffff80007c61a880 x2 : ffff7dfffeefffff
> [ 1.348770] x1 : 0000000040000000 x0 : 00e80000fe100f07
> [ 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 54000080 aa0003fb 17ffff48 (d4210000)
>
> 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 seems to introduce devm_pci_remap_iospace()
> and call it instead of pci_remap_iospace(), so that the pages get unmapped
> automagically on any probe failure.
>
> And while fixing pci_parse_request_of_pci_ranges(), aslo fix the other
> drivers that have probably copied the bad example...
>
> Fixes: 4e64dbe226e7 ("PCI: generic: Expose pci_host_common_probe() for use
> by other drivers")
> Fixes: cbce7900598c ("PCI: designware: Make driver arch-agnostic")
> Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller
> driver")
> Fixes: d3c68e0a7e34 ("PCI: faraday: Add Faraday Technology FTPCI100 PCI
> Host Bridge driver")
> Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver")
> Fixes: b7e78170efd4 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe
> host driver")
> Fixes: 5f6b6ccdbe1c ("PCI: xgene: Add APM X-Gene PCIe driver")
> Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller
> support")
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: stable at vger.kernel.org
It looks good!
For drivers/pci/controller/dwc/pcie-designware-host.c,
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
>
> ---
> The patch is against the 'master' branch of Bjorn Helgaas' 'pci.git'
> repo...
> It has only been tested with the R-Car PCIe driver...
>
> drivers/pci/controller/dwc/pcie-designware-host.c | 3 +
> drivers/pci/controller/pci-aardvark.c | 2 -
> drivers/pci/controller/pci-ftpci100.c | 2 -
> drivers/pci/controller/pci-v3-semi.c | 2 -
> drivers/pci/controller/pci-versatile.c | 2 -
> drivers/pci/controller/pci-xgene.c | 2 -
> drivers/pci/controller/pcie-mediatek.c | 2 -
> drivers/pci/of.c | 2 -
> drivers/pci/pci.c | 38 ++++++++++++++++++++++
> include/linux/pci.h | 2 +
> 10 files changed, 49 insertions(+), 8 deletions(-)
>
> Index: pci/drivers/pci/controller/dwc/pcie-designware-host.c
> ===================================================================
> --- pci.orig/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ pci/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -363,7 +363,8 @@ int dw_pcie_host_init(struct pcie_port *
> resource_list_for_each_entry_safe(win, tmp, &bridge->windows) {
> switch (resource_type(win->res)) {
> case IORESOURCE_IO:
> - ret = pci_remap_iospace(win->res, pp->io_base);
> + ret = devm_pci_remap_iospace(dev, win->res,
> + pp->io_base);
> if (ret) {
> dev_warn(dev, "Error %d: failed to map
> resource %pR\n",
> ret, win->res);
> Index: pci/drivers/pci/controller/pci-aardvark.c
> ===================================================================
> --- pci.orig/drivers/pci/controller/pci-aardvark.c
> +++ pci/drivers/pci/controller/pci-aardvark.c
> @@ -849,7 +849,7 @@ static int advk_pcie_parse_request_of_pc
> 0, 0xF8000000, 0,
> lower_32_bits(res->start),
> OB_PCIE_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);
> Index: pci/drivers/pci/controller/pci-ftpci100.c
> ===================================================================
> --- pci.orig/drivers/pci/controller/pci-ftpci100.c
> +++ pci/drivers/pci/controller/pci-ftpci100.c
> @@ -501,7 +501,7 @@ static int faraday_pci_probe(struct plat
> dev_err(dev, "illegal IO mem size\n");
> return -EINVAL;
> }
> - ret = pci_remap_iospace(io, io_base);
> + ret = devm_pci_remap_iospace(dev, io, io_base);
> if (ret) {
> dev_warn(dev, "error %d: failed to map
> resource %pR\n",
> ret, io);
> Index: pci/drivers/pci/controller/pci-v3-semi.c
> ===================================================================
> --- pci.orig/drivers/pci/controller/pci-v3-semi.c
> +++ pci/drivers/pci/controller/pci-v3-semi.c
> @@ -537,7 +537,7 @@ static int v3_pci_setup_resource(struct
> v3->io_bus_addr = io->start - win->offset;
> dev_dbg(dev, "I/O window %pR, bus addr %pap\n",
> io, &v3->io_bus_addr);
> - ret = pci_remap_iospace(io, io_base);
> + ret = devm_pci_remap_iospace(dev, io, io_base);
> if (ret) {
> dev_warn(dev,
> "error %d: failed to map resource %pR\n",
> Index: pci/drivers/pci/controller/pci-versatile.c
> ===================================================================
> --- pci.orig/drivers/pci/controller/pci-versatile.c
> +++ pci/drivers/pci/controller/pci-versatile.c
> @@ -82,7 +82,7 @@ static int versatile_pci_parse_request_o
>
> 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);
> Index: pci/drivers/pci/controller/pci-xgene.c
> ===================================================================
> --- pci.orig/drivers/pci/controller/pci-xgene.c
> +++ pci/drivers/pci/controller/pci-xgene.c
> @@ -423,7 +423,7 @@ static int xgene_pcie_map_ranges(struct
> case IORESOURCE_IO:
> xgene_pcie_setup_ob_reg(port, res, OMR3BARL, io_base,
> res->start - window->offset);
> - ret = pci_remap_iospace(res, io_base);
> + ret = devm_pci_remap_iospace(dev, res, io_base);
> if (ret < 0)
> return ret;
> break;
> Index: pci/drivers/pci/controller/pcie-mediatek.c
> ===================================================================
> --- pci.orig/drivers/pci/controller/pcie-mediatek.c
> +++ pci/drivers/pci/controller/pcie-mediatek.c
> @@ -1109,7 +1109,7 @@ static int mtk_pcie_request_resources(st
> if (err < 0)
> return err;
>
> - pci_remap_iospace(&pcie->pio, pcie->io.start);
> + devm_pci_remap_iospace(dev, &pcie->pio, pcie->io.start);
>
> return 0;
> }
> 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);
> Index: pci/drivers/pci/pci.c
> ===================================================================
> --- pci.orig/drivers/pci/pci.c
> +++ pci/drivers/pci/pci.c
> @@ -3579,6 +3579,44 @@ void pci_unmap_iospace(struct resource *
> }
> EXPORT_SYMBOL(pci_unmap_iospace);
>
> +static void devm_pci_unmap_iospace(struct device *dev, void *ptr)
> +{
> + struct resource **res = ptr;
> +
> + pci_unmap_iospace(*res);
> +}
> +
> +/**
> + * devm_pci_remap_iospace - Managed pci_remap_iospace()
> + * @dev: Generic device to remap IO address for
> + * @res: Resource describing the I/O space
> + * @phys_addr: physical address of range to be mapped
> + *
> + * Managed pci_remap_iospace(). Map is automatically unmapped on driver
> + * detach.
> + */
> +int devm_pci_remap_iospace(struct device *dev, const struct resource *res,
> + phys_addr_t phys_addr)
> +{
> + const struct resource **ptr;
> + int error;
> +
> + ptr = devres_alloc(devm_pci_unmap_iospace, sizeof(*ptr),
> GFP_KERNEL);
> + if (!ptr)
> + return -ENOMEM;
> +
> + error = pci_remap_iospace(res, phys_addr);
> + if (error) {
> + devres_free(ptr);
> + } else {
> + *ptr = res;
> + devres_add(dev, ptr);
> + }
> +
> + return error;
> +}
> +EXPORT_SYMBOL(devm_pci_remap_iospace);
> +
> /**
> * devm_pci_remap_cfgspace - Managed pci_remap_cfgspace()
> * @dev: Generic device to remap IO address for
> Index: pci/include/linux/pci.h
> ===================================================================
> --- pci.orig/include/linux/pci.h
> +++ pci/include/linux/pci.h
> @@ -1240,6 +1240,8 @@ int pci_register_io_range(struct fwnode_
> unsigned long pci_address_to_pio(phys_addr_t addr);
> phys_addr_t pci_pio_to_address(unsigned long pio);
> int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> +int devm_pci_remap_iospace(struct device *dev, const struct resource *res,
> + phys_addr_t phys_addr);
> void pci_unmap_iospace(struct resource *res);
> void __iomem *devm_pci_remap_cfgspace(struct device *dev,
> resource_size_t offset,
^ permalink raw reply
* [PATCH v2 1/6] dt-bindings: add laird and giantec vendor prefix
From: Rob Herring @ 2018-06-20 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529070055-18701-1-git-send-email-ben.whitten@lairdtech.com>
On Fri, Jun 15, 2018 at 02:40:50PM +0100, Ben Whitten wrote:
> This adds a vendor prefix "laird" for Laird PLC who make
> CPU modules and system on chips.
> Also adds "giantec" for Giantec Semiconductor, Inc. who
> make eeprom memory used on Laird designs.
>
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-20 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPeCT3CkqqNowEZaeTw7goJd6=Nbd2S61QzTFW-nGr5AKg@mail.gmail.com>
On Tue, Jun 19, 2018 at 09:59:04AM +0200, Krzysztof Kozlowski wrote:
> On 19 June 2018 at 09:26, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> > Hi Krzysztof,
> >
> > On 2018-06-18 19:42, Krzysztof Kozlowski wrote:
> >> The decon, decon_tv and dsi nodes have only one child port so
> >> address/size mappings are not necessary. This fixes DTC warnings like:
> >>
> >> Warning (graph_child_address): /soc/decon at 13800000/ports:
> >> graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > Works fine with current Exynos DRM Decon/MIC/DSI drivers.
> >
> > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> Thanks for review and testing!
I have second thoughs whether this patch is correct. AFAIU, the drivers
get the remote endpoints by reg==0 (for example the
of_graph_get_remote_node() in exynos_dsi_parse_dt()). If the port shall
be ignored, then reg==-1 should be passed.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
From: Rob Herring @ 2018-06-20 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-19-jernej.skrabec@siol.net>
On Tue, Jun 12, 2018 at 10:00:27PM +0200, Jernej Skrabec wrote:
> A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
> clock parents. It is compatible to other HDMI PHYs, like that found in
> R40.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
From: Rob Herring @ 2018-06-20 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-17-jernej.skrabec@siol.net>
On Tue, Jun 12, 2018 at 10:00:25PM +0200, Jernej Skrabec wrote:
> R40 DE2 mixers are similar to those found in A83T, except it needs
> different clock settings.
>
> Add a compatibles for them.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
From: Rob Herring @ 2018-06-20 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612200036.21483-11-jernej.skrabec@siol.net>
On Tue, Jun 12, 2018 at 10:00:19PM +0200, Jernej Skrabec wrote:
> TCON description is expanded with R40 TV TCON compatibles. TV TCONs,
> which are connected to TCON TOP muxes, such as those on R40 SoC, also
> needs additional clock gate to be specified.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 17/17] kasan: add SPDX-License-Identifier mark to source files
From: Fabio Estevam @ 2018-06-20 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f76d3070776e0038eda3cd76d471d1bfeae18480.1529515183.git.andreyknvl@google.com>
On Wed, Jun 20, 2018 at 2:40 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index 6f4f2ebf5f57..3feacd889e24 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -1,4 +1,4 @@
> -/* SPDX-License-Identifier: GPL-2.0 */
> +// SPDX-License-Identifier: GPL-2.0
The original notation is correct: /* */ style is used for header files.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox