Re: [bug report] staging: add bcm2708 vchiq driver

2016-11-16 Thread Phil Elwell
On 16/11/2016 10:21, Dan Carpenter wrote: > On Tue, Nov 15, 2016 at 10:04:05PM -0500, Vince Weaver wrote: >> On Tue, 15 Nov 2016, Michael Zoran wrote: >> >>> I'm still interested to know more about the MMU statement. I would >>> think at least some of the RPI models have one because swapping

Re: [PATCH] staging: bcm2835-audio: Fix memory corruption

2017-08-10 Thread Phil Elwell
On 10/08/2017 12:24, Dan Carpenter wrote: > On Thu, Aug 10, 2017 at 11:52:42AM +0100, Phil Elwell wrote: >> On 10/08/2017 11:21, Dan Carpenter wrote: >>> The original patch did not go through the normal review process... >>> >>> On Tue, Aug 08, 2017 at

[PATCH] staging: bcm2835-audio: Fix memory corruption

2017-08-11 Thread Phil Elwell
connections. Simplifying the code by removing a bunch of gotos and returning errors directly. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Fixes: 0adbfd4694c2 ("staging: bcm2835-audio: fix memory leak in bcm2835_audio_open_connection()") --- v2: Simplified following feedback fr

[PATCH v2] staging: bcm2835-audio: Fix memory corruption

2017-08-11 Thread Phil Elwell
connections. Simplifying the code by removing a bunch of gotos and returning errors directly. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Fixes: 0adbfd4694c2 ("staging: bcm2835-audio: fix memory leak in bcm2835_audio_open_connection()") --- [Resend with v2 in subject] v2: Simp

Re: [PATCH] staging: bcm2835-audio: Fix memory corruption

2017-08-10 Thread Phil Elwell
On 10/08/2017 11:21, Dan Carpenter wrote: > The original patch did not go through the normal review process... > > On Tue, Aug 08, 2017 at 01:05:02PM +0100, Phil Elwell wrote: >> I'm all for fixing memory leaks, but freeing a block while it is still >> being used is a rec

[PATCH] staging: bcm2835-audio: Fix memory corruption

2017-08-08 Thread Phil Elwell
I'm all for fixing memory leaks, but freeing a block while it is still being used is a recipe for hard-to-debug kernel exceptions. 1) There is already a vchi method for freeing the instance, so use it. 2) Only call it on error, and then only before initted is false. Signed-off-by: Phil Elwell &l

Re: [PATCH] staging: vc04_services: Fix bulk cache maintenance

2017-05-10 Thread Phil Elwell
On 10/05/2017 10:06, Greg Kroah-Hartman wrote: > On Wed, May 10, 2017 at 09:42:43AM +0100, Phil Elwell wrote: >> On 04/05/2017 18:51, Stefan Wahren wrote: >>> >>>> Phil Elwell <p...@raspberrypi.org> hat am 4. Mai 2017 um 11:58 geschrieben: >>>> >

Re: [PATCH] staging: vc04_services: Fix bulk cache maintenance

2017-05-10 Thread Phil Elwell
On 04/05/2017 18:51, Stefan Wahren wrote: > >> Phil Elwell <p...@raspberrypi.org> hat am 4. Mai 2017 um 11:58 geschrieben: >> >> >> vchiq_arm supports transfers less than one page and at arbitrary >> alignment, using the dma-mapping API to perform its ca

Re: [Bug] VCHIQ functional test broken

2017-05-15 Thread Phil Elwell
On 13/05/2017 10:30, Russell King - ARM Linux wrote: > On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote: >> In the meantime this issue has been fixed by Phil [1]. > > Right - definitely a driver bug. Mapping more memory for DMA than is > actually going to be DMA'd to and expecting

Re: [Bug] VCHIQ functional test broken

2017-05-15 Thread Phil Elwell
On 15/05/2017 15:54, Stefan Wahren wrote: > Am 15.05.2017 um 16:29 schrieb Phil Elwell: >> On 13/05/2017 10:30, Russell King - ARM Linux wrote: >>> On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote: >>>> In the meantime this issue has been fixed by Ph

[PATCH] staging: vc04_services: Fix bulk cache maintenance

2017-05-04 Thread Phil Elwell
) will be invalidated. This bug was masked until the disabling of the cache flush in flush_dcache_page(). Honouring the requested transfer start- and end-points prevents the corruption. Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg") Signed-off-by: Phil

[PATCH v2 resend] staging: bcm2835-audio: Fix memory corruption

2017-09-24 Thread Phil Elwell
connections. Simplifying the code by removing a bunch of gotos and returning errors directly. Signed-off-by: Phil Elwell <p...@raspberrypi.org> Fixes: 0adbfd4694c2 ("staging: bcm2835-audio: fix memory leak in bcm2835_audio_open_connection()") --- v2: Simplified following feedback fr

[PATCH] staging: vchiq: Fix local event signalling

2019-01-11 Thread Phil Elwell
the armed flag was being cleared this lead to a deadlock. Fixes: 852b2876a8a8 ("staging: vchiq: rework remove_event handling") Signed-off-by: Phil Elwell --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drive

Re: [PATCH v2 1/4] staging/vc04_services: Use correct cache line size

2018-09-14 Thread Phil Elwell
On 14/09/2018 14:22, Phil Elwell wrote: Use the compatible string in the DTB to select the correct cache line size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837. Signed-off-by: Phil Elwell --- .../interface/vchiq_arm/vchiq_2835_arm.c | 4 ++- .../vc04_services

Re: [PATCH v2 1/4] staging/vc04_services: Use correct cache line size

2018-09-14 Thread Phil Elwell
On 14/09/2018 18:03, Florian Fainelli wrote: On 09/14/2018 06:22 AM, Phil Elwell wrote: Use the compatible string in the DTB to select the correct cache line size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837. Signed-off-by: Phil Elwell --- [snip] @@ -170,6 +170,14

Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling

2018-09-17 Thread Phil Elwell
On 17/09/2018 18:51, Florian Fainelli wrote: On 09/17/2018 04:47 AM, Phil Elwell wrote: Hi Stefan, On 17/09/2018 12:39, Stefan Wahren wrote: Hi Phil, Am 17.09.2018 um 10:22 schrieb Phil Elwell: Both sides of the VCHIQ communications mechanism need to agree on the cache line size. Using

[PATCH v2 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq"

2018-09-14 Thread Phil Elwell
"brcm,bcm2836-vchiq" should be used on BCM2836 and BCM2837 to ensure correct operation. Signed-off-by: Phil Elwell --- Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindin

[PATCH v2 3/4] ARM: dts: bcm283x: Correct vchiq compatible string

2018-09-14 Thread Phil Elwell
To allow VCHIQ to determine the correct cache line size, use the new "brcm,bcm2836-vchiq" compatible string on BCM2836 and BCM2837. Signed-off-by: Phil Elwell --- arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 +- arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 2 +- arch/arm/boot/d

[PATCH v2 1/4] staging/vc04_services: Use correct cache line size

2018-09-14 Thread Phil Elwell
Use the compatible string in the DTB to select the correct cache line size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837. Signed-off-by: Phil Elwell --- .../interface/vchiq_arm/vchiq_2835_arm.c | 4 ++- .../vc04_services/interface/vchiq_arm/vchiq_arm.c | 36

Re: [PATCH v3 0/4] Improve VCHIQ cache line size handling

2018-09-17 Thread Phil Elwell
Hi Stefan, On 17/09/2018 12:39, Stefan Wahren wrote: > Hi Phil, > > Am 17.09.2018 um 10:22 schrieb Phil Elwell: >> Both sides of the VCHIQ communications mechanism need to agree on the cache >> line size. Using an incorrect value can lead to data corruption, but having >

[PATCH v3 2/4] dt-bindings: soc: Document "brcm,bcm2836-vchiq"

2018-09-17 Thread Phil Elwell
"brcm,bcm2836-vchiq" should be used on BCM2836 and BCM2837 to ensure correct operation. Signed-off-by: Phil Elwell Acked-by: Stefan Wahren --- Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Doc

[PATCH v3 4/4] ARM: dts: bcm283x: Correct mailbox register sizes

2018-09-17 Thread Phil Elwell
The size field in a Device Tree "reg" property is encoded in bytes, not words. Fixes: 614fa22119d6 ("ARM: dts: bcm2835: Add VCHIQ node to the Raspberry Pi boards. (v3)") Signed-off-by: Phil Elwell Acked-by: Stefan Wahren --- arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 +

[PATCH v3 0/4] Improve VCHIQ cache line size handling

2018-09-17 Thread Phil Elwell
ultiple Raspberry Pi models. v2: Replaced ARM-specific logic used to determine cache line size with a new compatible string for BCM2836 and BCM2837. Phil Elwell (4): staging/vc04_services: Use correct cache line size dt-bindings: soc: Document "brcm,bcm2836-vchiq" ARM: dts: bcm

[PATCH v3 1/4] staging/vc04_services: Use correct cache line size

2018-09-17 Thread Phil Elwell
Use the compatible string in the DTB to select the correct cache line size for the SoC - 32 for BCM2835, and 64 for BCM2836 and BCM2837. Signed-off-by: Phil Elwell --- .../interface/vchiq_arm/vchiq_2835_arm.c | 4 ++- .../vc04_services/interface/vchiq_arm/vchiq_arm.c | 35

[PATCH v3 3/4] ARM: dts: bcm283x: Correct vchiq compatible string

2018-09-17 Thread Phil Elwell
To allow VCHIQ to determine the correct cache line size, use the new "brcm,bcm2836-vchiq" compatible string on BCM2836 and BCM2837. Signed-off-by: Phil Elwell Acked-by: Stefan Wahren --- arch/arm/boot/dts/bcm2835-rpi.dtsi | 2 +- arch/arm/boot/dts/bcm2836-rpi-2-b.dts |

Re: [PATCH 1/2] staging: vchiq: Fix bulk userdata handling

2021-01-05 Thread Phil Elwell
On Tue, 5 Jan 2021 at 11:04, Dan Carpenter wrote: > > On Mon, Jan 04, 2021 at 07:26:42PM +, Phil Elwell wrote: > > On 04/01/2021 18:31, Dan Carpenter wrote: > > > On Mon, Jan 04, 2021 at 12:09:27PM +, Phil Elwell wrote: > > > > The additio

[PATCH v2 0/3] A trio of vchiq bulk transfer fixes

2021-01-05 Thread Phil Elwell
of those bugs, and adds a security-related note to the TODO file. Changes in v2: - Expand the commit message on patch 1 to clarify the impact of the bug, and add Tested-by. - Add commit 3 with an additional TODO item. - Change the name of the patch set to be numerically accurate. Phil Elwell (3

[PATCH v2 1/3] staging: vchiq: Fix bulk userdata handling

2021-01-05 Thread Phil Elwell
may cause the application to crash or otherwise malfunction. Fixes: 4184da4f316a ("staging: vchiq: fix __user annotations") Signed-off-by: Phil Elwell Tested-by: Stefan Wahren --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +++- 1 file changed, 3 insert

[PATCH v2 3/3] staging: vc04_services: Add a note to the TODO

2021-01-05 Thread Phil Elwell
Record in the TODO file that the address of ">bulk_waiter" should never be returned to userspace. Signed-off-by: Phil Elwell --- drivers/staging/vc04_services/interface/TODO | 4 1 file changed, 4 insertions(+) diff --git a/drivers/staging/vc04_services/interface/TODO b/dr

[PATCH v2 2/3] staging: vchiq: Fix bulk transfers on 64-bit builds

2021-01-05 Thread Phil Elwell
bulk transfer") Signed-off-by: Phil Elwell --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/v

[PATCH 1/2] staging: vchiq: Fix bulk userdata handling

2021-01-04 Thread Phil Elwell
Signed-off-by: Phil Elwell --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) 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 f5

[PATCH 0/2] A brace of vchiq bulk transfer fixes

2021-01-04 Thread Phil Elwell
of those bugs. Phil Elwell (2): staging: vchiq: Fix bulk userdata handling staging: vchiq: Fix bulk transfers on 64-bit builds .../staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.25.1

[PATCH 2/2] staging: vchiq: Fix bulk transfers on 64-bit builds

2021-01-04 Thread Phil Elwell
bulk transfer") Signed-off-by: Phil Elwell --- drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/v

Re: [PATCH 1/2] staging: vchiq: Fix bulk userdata handling

2021-01-04 Thread Phil Elwell
On 04/01/2021 18:31, Dan Carpenter wrote: On Mon, Jan 04, 2021 at 12:09:27PM +, Phil Elwell wrote: The addition of the local 'userdata' pointer to vchiq_irq_queue_bulk_tx_rx omitted the case where neither BLOCKING nor WAITING modes are used, in which case the value provided by the caller