linux-kernel - Re: [PATCH 2/3] ASoC: dt-bindings: xmos,xvf3500: add bindings for XMOS XVF3500

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: <5db4b898-93d5-446f-bfed-b57847f9967a@wolfvision.net>
Date: Mon, 15 Jan 2024 16:59:00 +0100
From: Javier Carrasco <javier.carrasco@...fvision.net>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
 Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
 Mark Brown <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>
Cc: Rob Herring <robh@...nel.org>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org
Subject: Re: [PATCH 2/3] ASoC: dt-bindings: xmos,xvf3500: add bindings for
 XMOS XVF3500

On 15.01.24 15:35, Krzysztof Kozlowski wrote:
> On 15/01/2024 14:58, Javier Carrasco wrote:
>> On 15.01.24 14:02, Krzysztof Kozlowski wrote:
>>> On 15/01/2024 10:16, Javier Carrasco wrote:
>>>> The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit
>>>> multicore controller for voice processing.
>>>>
>>>> Add new bindings to define the device properties.
>>>
>>> I don't see any bus, so how does it work? How do you get the voice data
>>> from it? I also do not see any DAI: neither here nor in the driver...
>>>
>> The voice data and any other information can be retrieved directly via
>> USB from userspace. Once in normal operation, the device acts as a
>> regular "onboard" USB device and the driver does not need to do any
>> further management.
> 
> So is this an USB device? If yes, then shouldn't be just auto-discovered
> and you add here some bindings for other device? This looks like coding
> power sequence not in USB node, but in some other, new node.
> 
> Best regards,
> Krzysztof
> 
It is an USB device that requires two power supplies and a reset to
boot. Afterwards it is auto-discovered and functions normally as a
regular USB device. In that sense it works like the onboard USB HUBs:

https://github.com/torvalds/linux/blob/master/drivers/usb/misc/onboard_usb_hub.c

The onboard USB HUB driver is of course more complex because it has to
support other features, but the idea of enabling the power supplies and
toggling the reset signal is essentially the same.

Best regards,
Javier Carrasco