lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ad50d65-9ce2-de4c-b14f-98c086b2d8c0@raspberrypi.com>
Date:   Tue, 24 Jan 2023 19:47:23 +0000
From:   Phil Elwell <phil@...pberrypi.com>
To:     Stefan Wahren <stefan.wahren@...e.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Umang Jain <umang.jain@...asonboard.com>
Cc:     linux-staging@...ts.linux.dev,
        linux-rpi-kernel@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Adrien Thierry <athierry@...hat.com>,
        Dan Carpenter <error27@...il.com>,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Paul Elder <paul.elder@...asonboard.com>
Subject: Re: [PATCH v6 0/6] staging: vc04_services: vchiq: Register devices
 with a custom bus_type

On 24/01/2023 8:41, Stefan Wahren wrote:
> Hi Phil,
> 
> Am 23.01.23 um 09:58 schrieb Laurent Pinchart:
>> On Mon, Jan 23, 2023 at 01:18:30PM +0530, Umang Jain wrote:
>>> Hi Stefan,
>>>
>>> Thank for the testing.
>>>
>>> On 1/23/23 5:04 AM, Stefan Wahren wrote:
>>>> Hi Umang,
>>>>
>>>> Am 20.01.23 um 21:10 schrieb Umang Jain:
>>>>> This series just introduces five extra patches for dropping include
>>>>> directives from Makefiles (suggested by Greg KH) and rebased.
>>>>>
>>>>> The main patch (6/6) removes platform device/driver abuse and moves
>>>>> things to standard device/driver model using a custom_bus. Specific
>>>>> details are elaborated in the commit message.
>>>>>
>>>>> The patch series is based on top of d514392f17fd (tag: next-20230120)
>>>>> of linux-next.
>>>> applied this series on top of linux-next and build it with
>>>> arm/multi_v7_defconfig plus the following:
>>>>
>>>> CONFIG_BCM_VIDEOCORE=y
>>>> CONFIG_BCM2835_VCHIQ=m
>>>> CONFIG_VCHIQ_CDEV=y
>>>> CONFIG_SND_BCM2835=m
>>>> CONFIG_VIDEO_BCM2835=m
>>>> CONFIG_BCM2835_VCHIQ_MMAL=m
>>>>
>>>> and the devices doesn't register on Raspberry Pi 3 B Plus:
>>>>
>>>> [   25.523337] vchiq: module is from the staging directory, the quality is unknown, you have been warned.
>>>> [   25.541647] bcm2835_vchiq 3f00b840.mailbox: Failed to register bcm2835_audio vchiq device
>>>> [   25.553692] bcm2835_vchiq 3f00b840.mailbox: Failed to register bcm2835-camera vchiq device
>>> I was able to reproduce and it seems the issue here is the change
>>> mentioned in the cover
>>>
>>> - drop dma_set_mask_and_coherent
>>>
>>> in V6.
>>>
>>> (I usually test patches on RPi 4B with vcsm-cma and bcm2835-isp applied
>>> so my branch has the DMA hunk included while I was testing V6)
>>>
>>> Below is the hunk which should resolve the issue.
>>>
>>> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
>>> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_device.c
>>> @@ -6,6 +6,7 @@
>>>     */
>>>
>>>    #include <linux/device/bus.h>
>>> +#include <linux/dma-mapping.h>
>>>    #include <linux/slab.h>
>>>    #include <linux/string.h>
>>>
>>> @@ -72,6 +73,12 @@ int vchiq_device_register(struct device *parent,
>>> const char *name)
>>>           device->dev.type = &vchiq_device_type;
>>>           device->dev.release = vchiq_device_release;
>>>
>>> +       ret = dma_set_mask_and_coherent(&device->dev, DMA_BIT_MASK(32));
>>> +       if (ret < 0) {
>>> +               vchiq_device_release(&device->dev);
>>> +               return ret;
>>> +       }
>>> +
>>>           ret = device_register(&device->dev);
>>>           if (ret) {
>>>                   put_device(&device->dev);
>>>
>>> It seems we need to include the dma_set_mask_and_coherent() even if
>>> bcm2835-audio, bcm2835-camera device doesn't do DMA? I need to look into
>>> why is that/
> 
> Do you have an answer for this?

That's because vchiq does use DMA for bulk transfers, it's just that the DMA hardware
is driven from the VPU side. And even though the VPU can only address 1GB, it uses the
upper address bits to determine cacheability of accesses, hence the need for 32-bit
DMA addresses.

Phil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ