From linus.walleij at linaro.org  Sat Jan  1 22:54:52 2022
From: linus.walleij at linaro.org (Linus Walleij)
Date: Sun, 2 Jan 2022 07:54:52 +0100
Subject: [PATCH v2 1/2] pinctrl: bcm2835: Change init order for gpio hogs
In-Reply-To: <95851343-2887-1e04-9598-e8c8ae74a99a@i2se.com>
References: <20211206092237.4105895-1-phil@raspberrypi.com>
 <20211206092237.4105895-2-phil@raspberrypi.com>
 <CACRpkdZ95bCJVDo4tCXsMnsXax4+ZydoLS7AsM-yzMjXbONk=w@mail.gmail.com>
 <95851343-2887-1e04-9598-e8c8ae74a99a@i2se.com>
Message-ID: <CACRpkdbnqq+hwXt1oUWZfyxFjdd4aSAz0MzhzYVWuqqVAe4Eig@mail.gmail.com>

On Wed, Dec 29, 2021 at 8:07 PM Stefan Wahren <stefan.wahren at i2se.com> wrote:
> Am 10.12.21 um 00:24 schrieb Linus Walleij:
> > On Mon, Dec 6, 2021 at 10:22 AM Phil Elwell <phil at raspberrypi.com> wrote:
> >
> >> ...and gpio-ranges
> >>
> >> pinctrl-bcm2835 is a combined pinctrl/gpio driver. Currently the gpio
> >> side is registered first, but this breaks gpio hogs (which are
> >> configured during gpiochip_add_data). Part of the hog initialisation
> >> is a call to pinctrl_gpio_request, and since the pinctrl driver hasn't
> >> yet been registered this results in an -EPROBE_DEFER from which it can
> >> never recover.
> >>
> >> Change the initialisation sequence to register the pinctrl driver
> >> first.
> >>
> >> This also solves a similar problem with the gpio-ranges property, which
> >> is required in order for released pins to be returned to inputs.
> >>
> >> Fixes: 73345a18d464b ("pinctrl: bcm2835: Pass irqchip when adding gpiochip")
> >> Signed-off-by: Phil Elwell <phil at raspberrypi.com>
> > This patch (1/2) applied for fixes.
>
> Unfortunately this change breaks all GPIO LEDs at least on the Raspberry
> Pi 3 Plus (Linux 5.16-rc7, multi_v7_defconfig). The ACT LED for instance
> stays in the last state instead of the configured heartbeat behavior.
> Also there are no GPIO LEDs in /sys/class/leds/ directory.
>
> After reverting this change everything is back to normal.

Oh what a mess. OK I reverted the fix.

Yours,
Linus Walleij


From ryutaroh at ict.e.titech.ac.jp  Wed Jan  5 07:55:41 2022
From: ryutaroh at ict.e.titech.ac.jp (Ryutaroh Matsumoto)
Date: Thu, 06 Jan 2022 00:55:41 +0900 (JST)
Subject: /sys/class/leds/PWR disappered in 5.15.12
Message-ID: <20220106.005541.1484711037304469462.ryutaroh@ict.e.titech.ac.jp>

Hi RPi kernel users,

Until kernel 5.15.11, there existed /sys/class/leds/{PWR,ACT},
but in 5.15.12 they do not show up.

Does anyone observe the same issue?
I build the kernel by Debian clang 13 in Debian unstable.

Best regards, Ryutaroh Matsumoto


From ahalaney at redhat.com  Wed Jan  5 08:32:20 2022
From: ahalaney at redhat.com (Andrew Halaney)
Date: Wed, 5 Jan 2022 10:32:20 -0600
Subject: /sys/class/leds/PWR disappered in 5.15.12
In-Reply-To: <20220106.005541.1484711037304469462.ryutaroh@ict.e.titech.ac.jp>
References: <20220106.005541.1484711037304469462.ryutaroh@ict.e.titech.ac.jp>
Message-ID: <20220105163220.wwqesn5nziuga6ma@halaneylaptop>

On Thu, Jan 06, 2022 at 12:55:41AM +0900, Ryutaroh Matsumoto wrote:
> Hi RPi kernel users,
> 
> Until kernel 5.15.11, there existed /sys/class/leds/{PWR,ACT},
> but in 5.15.12 they do not show up.

Just a quick guess, but I recall seeing this on list which I think
should explain that: https://lore.kernel.org/all/1df8425c-c1bb-3d1e-4a78-87b6d0967d57 at gmail.com/

Thanks,
Andrew



From stefan.wahren at i2se.com  Wed Jan  5 09:11:27 2022
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 5 Jan 2022 18:11:27 +0100
Subject: /sys/class/leds/PWR disappered in 5.15.12
In-Reply-To: <20220105163220.wwqesn5nziuga6ma@halaneylaptop>
References: <20220106.005541.1484711037304469462.ryutaroh@ict.e.titech.ac.jp>
 <20220105163220.wwqesn5nziuga6ma@halaneylaptop>
Message-ID: <1739f1c4-fe5e-1b46-eaf4-31880784e385@i2se.com>

Hi,

Am 05.01.22 um 17:32 schrieb Andrew Halaney:
> On Thu, Jan 06, 2022 at 12:55:41AM +0900, Ryutaroh Matsumoto wrote:
>> Hi RPi kernel users,
>>
>> Until kernel 5.15.11, there existed /sys/class/leds/{PWR,ACT},
>> but in 5.15.12 they do not show up.
> Just a quick guess, but I recall seeing this on list which I think
> should explain that: https://lore.kernel.org/all/1df8425c-c1bb-3d1e-4a78-87b6d0967d57 at gmail.com/

we hope that the depending change will be applied soon:

https://lore.kernel.org/linux-arm-kernel/6f42ceda-c000-7506-65ec-53534b5aef7d at gmail.com/T/

>
> Thanks,
> Andrew
>
>
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel


From stefan.wahren at i2se.com  Mon Jan 10 02:18:59 2022
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Mon, 10 Jan 2022 11:18:59 +0100
Subject: /sys/class/leds/PWR disappered in 5.15.12
In-Reply-To: <1739f1c4-fe5e-1b46-eaf4-31880784e385@i2se.com>
References: <20220106.005541.1484711037304469462.ryutaroh@ict.e.titech.ac.jp>
 <20220105163220.wwqesn5nziuga6ma@halaneylaptop>
 <1739f1c4-fe5e-1b46-eaf4-31880784e385@i2se.com>
Message-ID: <04ef1578-5e7e-5339-bc01-b3de1245c313@i2se.com>

Hi,

Am 05.01.22 um 18:11 schrieb Stefan Wahren:
> Hi,
>
> Am 05.01.22 um 17:32 schrieb Andrew Halaney:
>> On Thu, Jan 06, 2022 at 12:55:41AM +0900, Ryutaroh Matsumoto wrote:
>>> Hi RPi kernel users,
>>>
>>> Until kernel 5.15.11, there existed /sys/class/leds/{PWR,ACT},
>>> but in 5.15.12 they do not show up.
>> Just a quick guess, but I recall seeing this on list which I think
>> should explain that: https://lore.kernel.org/all/1df8425c-c1bb-3d1e-4a78-87b6d0967d57 at gmail.com/
> we hope that the depending change will be applied soon:
>
> https://lore.kernel.org/linux-arm-kernel/6f42ceda-c000-7506-65ec-53534b5aef7d at gmail.com/T/
i've good news: the fix has been applied to 5.16 and should land in
linux-stable (5.10.y/5.15.y) soon.
>
>> Thanks,
>> Andrew
>>
>>
>> _______________________________________________
>> linux-rpi-kernel mailing list
>> linux-rpi-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
> _______________________________________________
> linux-rpi-kernel mailing list
> linux-rpi-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel


From ryutaroh at ict.e.titech.ac.jp  Mon Jan 10 15:05:58 2022
From: ryutaroh at ict.e.titech.ac.jp (Ryutaroh Matsumoto)
Date: Tue, 11 Jan 2022 08:05:58 +0900 (JST)
Subject: /sys/class/leds/PWR disappered in 5.15.12
In-Reply-To: <04ef1578-5e7e-5339-bc01-b3de1245c313@i2se.com>
References: <20220105163220.wwqesn5nziuga6ma@halaneylaptop>
 <1739f1c4-fe5e-1b46-eaf4-31880784e385@i2se.com>
 <04ef1578-5e7e-5339-bc01-b3de1245c313@i2se.com>
Message-ID: <20220111.080558.1234280538086764496.ryutaroh@ict.e.titech.ac.jp>

Hi everyone,

From: Stefan Wahren <stefan.wahren at i2se.com>
Subject: Re: /sys/class/leds/PWR disappered in 5.15.12
Date: Mon, 10 Jan 2022 11:18:59 +0100
> i've good news: the fix has been applied to 5.16 and should land in
> linux-stable (5.10.y/5.15.y) soon.

Yes, this symptom disappered and
/sys/class/leds/PWR re-appeared with 5.16!

Ryutaroh


From treasure4paddy at gmail.com  Mon Jan 17 16:51:26 2022
From: treasure4paddy at gmail.com (Padmanabha Srinivasaiah)
Date: Tue, 18 Jan 2022 01:51:26 +0100
Subject: [PATCH] drm/vc4: Fix deadlock on DSI device attach error
Message-ID: <20220118005127.29015-1-treasure4paddy@gmail.com>

DSI device attach to DSI host will be done with host device's lock
held.

Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.

Startup Call trace:
[   35.043036]  rt_mutex_slowlock.constprop.21+0x184/0x1b8
[   35.043048]  mutex_lock_nested+0x7c/0xc8
[   35.043060]  device_del+0x4c/0x3e8
[   35.043075]  device_unregister+0x20/0x40
[   35.043082]  mipi_dsi_remove_device_fn+0x18/0x28
[   35.043093]  device_for_each_child+0x68/0xb0
[   35.043105]  mipi_dsi_host_unregister+0x40/0x90
[   35.043115]  vc4_dsi_host_attach+0xf0/0x120 [vc4]
[   35.043199]  mipi_dsi_attach+0x30/0x48
[   35.043209]  tc358762_probe+0x128/0x164 [tc358762]
[   35.043225]  mipi_dsi_drv_probe+0x28/0x38
[   35.043234]  really_probe+0xc0/0x318
[   35.043244]  __driver_probe_device+0x80/0xe8
[   35.043254]  driver_probe_device+0xb8/0x118
[   35.043263]  __device_attach_driver+0x98/0xe8
[   35.043273]  bus_for_each_drv+0x84/0xd8
[   35.043281]  __device_attach+0xf0/0x150
[   35.043290]  device_initial_probe+0x1c/0x28
[   35.043300]  bus_probe_device+0xa4/0xb0
[   35.043308]  deferred_probe_work_func+0xa0/0xe0
[   35.043318]  process_one_work+0x254/0x700
[   35.043330]  worker_thread+0x4c/0x448
[   35.043339]  kthread+0x19c/0x1a8
[   35.043348]  ret_from_fork+0x10/0x20

Shutdown Call trace:
[  365.565417] Call trace:
[  365.565423]  __switch_to+0x148/0x200
[  365.565452]  __schedule+0x340/0x9c8
[  365.565467]  schedule+0x48/0x110
[  365.565479]  schedule_timeout+0x3b0/0x448
[  365.565496]  wait_for_completion+0xac/0x138
[  365.565509]  __flush_work+0x218/0x4e0
[  365.565523]  flush_work+0x1c/0x28
[  365.565536]  wait_for_device_probe+0x68/0x158
[  365.565550]  device_shutdown+0x24/0x348
[  365.565561]  kernel_restart_prepare+0x40/0x50
[  365.565578]  kernel_restart+0x20/0x70
[  365.565591]  __do_sys_reboot+0x10c/0x220
[  365.565605]  __arm64_sys_reboot+0x2c/0x38
[  365.565619]  invoke_syscall+0x4c/0x110
[  365.565634]  el0_svc_common.constprop.3+0xfc/0x120
[  365.565648]  do_el0_svc+0x2c/0x90
[  365.565661]  el0_svc+0x4c/0xf0
[  365.565671]  el0t_64_sync_handler+0x90/0xb8
[  365.565682]  el0t_64_sync+0x180/0x184

Signed-off-by: Padmanabha Srinivasaiah <treasure4paddy at gmail.com>
---
 drivers/gpu/drm/vc4/vc4_dsi.c | 14 ++++----------
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index a229da58962a..9300d3354c51 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.c
+++ b/drivers/gpu/drm/vc4/vc4_dsi.c
@@ -1262,7 +1262,6 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
 			       struct mipi_dsi_device *device)
 {
 	struct vc4_dsi *dsi = host_to_dsi(host);
-	int ret;
 
 	dsi->lanes = device->lanes;
 	dsi->channel = device->channel;
@@ -1297,18 +1296,15 @@ static int vc4_dsi_host_attach(struct mipi_dsi_host *host,
 		return 0;
 	}
 
-	ret = component_add(&dsi->pdev->dev, &vc4_dsi_ops);
-	if (ret) {
-		mipi_dsi_host_unregister(&dsi->dsi_host);
-		return ret;
-	}
-
-	return 0;
+	return component_add(&dsi->pdev->dev, &vc4_dsi_ops);
 }
 
 static int vc4_dsi_host_detach(struct mipi_dsi_host *host,
 			       struct mipi_dsi_device *device)
 {
+	struct vc4_dsi *dsi = host_to_dsi(host);
+
+	component_del(&dsi->pdev->dev, &vc4_dsi_ops);
 	return 0;
 }
 
@@ -1686,9 +1682,7 @@ static int vc4_dsi_dev_remove(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct vc4_dsi *dsi = dev_get_drvdata(dev);
 
-	component_del(&pdev->dev, &vc4_dsi_ops);
 	mipi_dsi_host_unregister(&dsi->dsi_host);
-
 	return 0;
 }
 
-- 
2.17.1



From maxime at cerno.tech  Wed Jan 19 01:11:05 2022
From: maxime at cerno.tech (Maxime Ripard)
Date: Wed, 19 Jan 2022 10:11:05 +0100
Subject: (subset) [PATCH] drm/vc4: Fix deadlock on DSI device attach error
In-Reply-To: <20220118005127.29015-1-treasure4paddy@gmail.com>
References: <20220118005127.29015-1-treasure4paddy@gmail.com>
Message-ID: <164258346063.31836.9424358467323476627.b4-ty@cerno.tech>

On Tue, 18 Jan 2022 01:51:26 +0100, Padmanabha Srinivasaiah wrote:
> DSI device attach to DSI host will be done with host device's lock
> held.
> 
> Un-registering host in "device attach" error path (ex: probe retry)
> will result in deadlock with below call trace and non operational
> DSI display.
> 
> [...]

Applied to drm/drm-misc (drm-misc-next-fixes).

Thanks!
Maxime


From phil at raspberrypi.com  Wed Jan 26 06:11:24 2022
From: phil at raspberrypi.com (Phil Elwell)
Date: Wed, 26 Jan 2022 14:11:24 +0000
Subject: [PATCH] serial: 8250: Fix ...console_fifo_write on BCM283x
Message-ID: <20220126141124.4086065-1-phil@raspberrypi.com>

The mini-UART on BCM283x is doubly crippled - it has 8-byte FIFOs and
the THRE bit indicates that the TX FIFO is not-full rather than empty.

The optimisation to enable the use of the FIFO assumes that it is safe
to write fifosize bytes whenever THRE is set, but the BCM283x quirk
(indicated by the presence of UART_CAP_MINI) makes it necessary to
check the FIFO state after each byte.

See: https://github.com/raspberrypi/linux/issues/4849

Fixes: 5021d709b31b ("tty: serial: Use fifo in 8250 console driver")
Signed-off-by: Phil Elwell <phil at raspberrypi.com>
---
 drivers/tty/serial/8250/8250_port.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 2abb3de11a48..8a2b462d363c 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -3357,6 +3357,13 @@ static void serial8250_console_fifo_write(struct uart_8250_port *up,
 				serial_out(up, UART_TX, *s++);
 				cr_sent = false;
 			}
+			/*
+			 * The BCM2835 MINI UART THRE bit is really a not-full
+			 * bit, so be prepared to bail out early.
+			 */
+			if ((up->capabilities & UART_CAP_MINI) &&
+			    !(serial_in(up, UART_LSR) & UART_LSR_THRE))
+				break;
 		}
 	}
 }
-- 
2.25.1



From gregkh at linuxfoundation.org  Wed Jan 26 06:21:29 2022
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Wed, 26 Jan 2022 15:21:29 +0100
Subject: [PATCH] serial: 8250: Fix ...console_fifo_write on BCM283x
In-Reply-To: <20220126141124.4086065-1-phil@raspberrypi.com>
References: <20220126141124.4086065-1-phil@raspberrypi.com>
Message-ID: <YfFY6Rnor85CE9yH@kroah.com>

On Wed, Jan 26, 2022 at 02:11:24PM +0000, Phil Elwell wrote:
> The mini-UART on BCM283x is doubly crippled - it has 8-byte FIFOs and
> the THRE bit indicates that the TX FIFO is not-full rather than empty.
> 
> The optimisation to enable the use of the FIFO assumes that it is safe
> to write fifosize bytes whenever THRE is set, but the BCM283x quirk
> (indicated by the presence of UART_CAP_MINI) makes it necessary to
> check the FIFO state after each byte.
> 
> See: https://github.com/raspberrypi/linux/issues/4849
> 
> Fixes: 5021d709b31b ("tty: serial: Use fifo in 8250 console driver")

I have just reverted this commit, it's broken for many platforms now,
not just yours.

So there shouldn't be a need for this change now, right?

thanks,

greg k-h


From phil at raspberrypi.com  Wed Jan 26 06:27:38 2022
From: phil at raspberrypi.com (Phil Elwell)
Date: Wed, 26 Jan 2022 14:27:38 +0000
Subject: [PATCH] serial: 8250: Fix ...console_fifo_write on BCM283x
In-Reply-To: <YfFY6Rnor85CE9yH@kroah.com>
References: <20220126141124.4086065-1-phil@raspberrypi.com>
 <YfFY6Rnor85CE9yH@kroah.com>
Message-ID: <e646b677-2497-1e6a-b347-8a7e6ada0209@raspberrypi.com>

Hi Greg,

On 26/01/2022 14:21, Greg Kroah-Hartman wrote:
> On Wed, Jan 26, 2022 at 02:11:24PM +0000, Phil Elwell wrote:
>> The mini-UART on BCM283x is doubly crippled - it has 8-byte FIFOs and
>> the THRE bit indicates that the TX FIFO is not-full rather than empty.
>>
>> The optimisation to enable the use of the FIFO assumes that it is safe
>> to write fifosize bytes whenever THRE is set, but the BCM283x quirk
>> (indicated by the presence of UART_CAP_MINI) makes it necessary to
>> check the FIFO state after each byte.
>>
>> See: https://github.com/raspberrypi/linux/issues/4849
>>
>> Fixes: 5021d709b31b ("tty: serial: Use fifo in 8250 console driver")
> 
> I have just reverted this commit, it's broken for many platforms now,
> not just yours.
> 
> So there shouldn't be a need for this change now, right?

This patch is sufficient on the BCM283x family of devices, but a Fix
for a non-existent patch is clearly superfluous. The author of the
original patch can consider this as a hint about the kind of issues that
need to be considered before resubmitting.

Thanks,

Phil


From phind.uet at gmail.com  Sun Jan 30 23:10:06 2022
From: phind.uet at gmail.com (Nguyen Dinh Phi)
Date: Mon, 31 Jan 2022 15:10:06 +0800
Subject: [PATCH] staging: vc04_services: make a couple of functions static
Message-ID: <20220131071006.1764343-1-phind.uet@gmail.com>

Functions vchiq_platform_init and vchiq_platform_get_arm_state are used
locally in vchiq_arm.c file, so make them static.

Cleans up sparse warnings:
warning: symbol 'vchiq_platform_init' was not declared. Should it be
static?
warning: warning: symbol 'vchiq_platform_get_arm_state' was not declared.
Should it be static?

Signed-off-by: Nguyen Dinh Phi <phind.uet at gmail.com>
---
 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 54ab6208ddae..b1054550ed27 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -466,7 +466,7 @@ free_pagelist(struct vchiq_pagelist_info *pagelistinfo,
 	cleanup_pagelistinfo(pagelistinfo);
 }
 
-int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state *state)
+static int vchiq_platform_init(struct platform_device *pdev, struct vchiq_state *state)
 {
 	struct device *dev = &pdev->dev;
 	struct vchiq_drvdata *drvdata = platform_get_drvdata(pdev);
@@ -593,7 +593,7 @@ vchiq_platform_init_state(struct vchiq_state *state)
 	return 0;
 }
 
-struct vchiq_arm_state*
+static struct vchiq_arm_state*
 vchiq_platform_get_arm_state(struct vchiq_state *state)
 {
 	struct vchiq_2835_state *platform_state;
-- 
2.25.1



From gregkh at linuxfoundation.org  Mon Jan 31 05:07:02 2022
From: gregkh at linuxfoundation.org (Greg Kroah-Hartman)
Date: Mon, 31 Jan 2022 14:07:02 +0100
Subject: [PATCH] staging: vc04_services: make a couple of functions static
In-Reply-To: <202201311901.HT4PtVja-lkp@intel.com>
References: <20220131071006.1764343-1-phind.uet@gmail.com>
 <202201311901.HT4PtVja-lkp@intel.com>
Message-ID: <Yffe9tO6rRyzod2F@kroah.com>

On Mon, Jan 31, 2022 at 07:16:01PM +0800, kernel test robot wrote:
> Hi Nguyen,
> 
> Thank you for the patch! Perhaps something to improve:
> 
> [auto build test WARNING on staging/staging-testing]
> 
> url:    https://github.com/0day-ci/linux/commits/Nguyen-Dinh-Phi/staging-vc04_services-make-a-couple-of-functions-static/20220131-151209
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 64b2d6ffff862c0e7278198b4229e42e1abb3bb1
> config: arm-randconfig-r002-20220130 (https://download.01.org/0day-ci/archive/20220131/202201311901.HT4PtVja-lkp at intel.com/config)
> compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
> reproduce (this is a W=1 build):
>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # https://github.com/0day-ci/linux/commit/1b64825a2b5b3312ae309c1714239df049b018ac
>         git remote add linux-review https://github.com/0day-ci/linux
>         git fetch --no-tags linux-review Nguyen-Dinh-Phi/staging-vc04_services-make-a-couple-of-functions-static/20220131-151209
>         git checkout 1b64825a2b5b3312ae309c1714239df049b018ac
>         # save the config file to linux build tree
>         mkdir build_dir
>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash drivers/staging/vc04_services/
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp at intel.com>
> 
> All warnings (new ones prefixed by >>):
> 
>    drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c: In function 'free_pagelist':
> >> drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:434:25: warning: argument 2 null where non-null expected [-Wnonnull]
>      434 |                         memcpy((char *)kmap(pages[0]) +
>          |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      435 |                                 pagelist->offset,
>          |                                 ~~~~~~~~~~~~~~~~~
>      436 |                                 fragments,
>          |                                 ~~~~~~~~~~
>      437 |                                 head_bytes);
>          |                                 ~~~~~~~~~~~
>    In file included from include/linux/string.h:20,
>                     from include/linux/bitmap.h:11,
>                     from include/linux/cpumask.h:12,
>                     from include/linux/mm_types_task.h:14,
>                     from include/linux/mm_types.h:5,
>                     from include/linux/buildid.h:5,
>                     from include/linux/module.h:14,
>                     from drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:8:
>    arch/arm/include/asm/string.h:20:15: note: in a call to function 'memcpy' declared 'nonnull'
>       20 | extern void * memcpy(void *, const void *, __kernel_size_t);
>          |               ^~~~~~
> 

Oddly, your patch caused these build errors to happen, which implies
that you did not test-build your patch?

I remember seeing this before and being confused as to why this type of
change would cause this error, but it must be for some reason, which
means we can't take this patch.

Always test-build your changes before sending them out.

thanks,

greg k-h


From f.fainelli at gmail.com  Mon Jan 31 16:24:07 2022
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 31 Jan 2022 16:24:07 -0800
Subject: [PATCH] ARM: dts: bcm2837: Add the missing L1/L2 cache information
In-Reply-To: <20211218200009.16856-1-rs@noreya.tech>
References: <20211218200009.16856-1-rs@noreya.tech>
Message-ID: <20220201002407.426327-1-f.fainelli@gmail.com>

On Sat, 18 Dec 2021 21:00:09 +0100, Richard Schleich <rs at noreya.tech> wrote:
> This patch fixes the kernel warning
> "cacheinfo: Unable to detect cache hierarchy for CPU 0"
> for the bcm2837 on newer kernel versions.
> 
> Signed-off-by: Richard Schleich <rs at noreya.tech>
> ---

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian


From f.fainelli at gmail.com  Mon Jan 31 16:29:11 2022
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 31 Jan 2022 16:29:11 -0800
Subject: [PATCH] ARM: dts: bcm2837: Add the missing L1/L2 cache information
In-Reply-To: <20220201002407.426327-1-f.fainelli@gmail.com>
References: <20211218200009.16856-1-rs@noreya.tech>
 <20220201002407.426327-1-f.fainelli@gmail.com>
Message-ID: <a449c627-c036-dc72-0e90-a14f5f1c4dfe@gmail.com>



On 1/31/2022 4:24 PM, Florian Fainelli wrote:
> On Sat, 18 Dec 2021 21:00:09 +0100, Richard Schleich <rs at noreya.tech> wrote:
>> This patch fixes the kernel warning
>> "cacheinfo: Unable to detect cache hierarchy for CPU 0"
>> for the bcm2837 on newer kernel versions.
>>
>> Signed-off-by: Richard Schleich <rs at noreya.tech>
>> ---
> 
> Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!

I did remove the comments that were not helpful for the 'd-cache-size', 
'd-cache-line-size', 'i-cache-size' and 'i-cache-line-size'  since they 
are self explanatory.

Thanks!
-- 
Florian


From f.fainelli at gmail.com  Mon Jan 31 16:36:49 2022
From: f.fainelli at gmail.com (Florian Fainelli)
Date: Mon, 31 Jan 2022 16:36:49 -0800
Subject: [PATCH] ARM: dts: bcm2711: Add the missing L1/L2 cache information
In-Reply-To: <20211221224830.16746-1-rs@noreya.tech>
References: <20211221224830.16746-1-rs@noreya.tech>
Message-ID: <269c289b-97af-2775-0404-b89b0d0cb7c4@gmail.com>



On 12/21/2021 2:48 PM, Richard Schleich wrote:
> This patch fixes the kernel warning
> "cacheinfo: Unable to detect cache hierarchy for CPU 0"
> for the bcm2711 on newer kernel versions.
> 
> Signed-off-by: Richard Schleich <rs at noreya.tech>

Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, 
thanks!

I did remove the comments that were not helpful for the 'd-cache-size', 
'd-cache-line-size', 'i-cache-size' and 'i-cache-line-size'  since they 
are self explanatory.
-- 
Florian


