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: <0efa70c3-dee4-4d0d-b106-d7083b5e68c3@kernel.org>
Date: Sun, 9 Feb 2025 11:19:22 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Viken Dadhaniya <quic_vdadhani@...cinc.com>, neil.armstrong@...aro.org,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: andi.shyti@...nel.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, gregkh@...uxfoundation.org, jirislaby@...nel.org,
 broonie@...nel.or, andersson@...nel.org, konradybcio@...nel.org,
 johan+linaro@...nel.org, dianders@...omium.org, agross@...nel.org,
 linux-arm-msm@...r.kernel.org, linux-i2c@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-serial@...r.kernel.org, linux-spi@...r.kernel.org,
 quic_msavaliy@...cinc.com, quic_anupkulk@...cinc.com
Subject: Re: [PATCH v2 4/8] dt-bindings: serial: Add support for selecting
 data transfer mode

On 09/02/2025 11:11, Viken Dadhaniya wrote:
>>>>>>
>>>>>> Just one blank line, but anyway, this property should not be in three
>>>>>> places. Do you really expect that each of serial engines within one
>>>>>> GeniQUP will be configured differently by TZ?
>>>>>
>>>>> Yes, each SE is configured separately and it's quite frequent when
>>>>> different SEs have different DMA configuration.
>>>>
>>>> Well, I checked at sm8550 and sm8650 and each pair of SE - which shares
>>>> resources - has the same DMAs, so I would not call it frequent. Care to
>>>> bring an example where same serial engines have different DMAs and
>>>> different TZ? We do not talk about single QUP.
>>>
>>> Well, I don't have access to the latest sm8550 / sm8650 devcfg sources.
>>> I checked the RB5 ones. As far as I understand out of 14 enabled SEs
>>> only two are configured for the GSI DMA, others should use FIFO / SE
>>> DMA. Same applies to the SM8250 MTP devices. Checking the RB1 / RB2
>>> setup also shows 3 out of 6 SEs being set for GSI.
>>
>> I think selecting GSI DMA is only for devices needs high speed streaming 
>> to the
>> device, like the touch screen, using GSI DMA for random small access is 
>> a non-sense.
>>
>> But the thing is, in the TZ world the configuration was static so we had 
>> no choice
>> of using GSI DMA when configured, but now we have the choice so we could 
>> totally
>> reconfigure the SE with the transfer type (FIFO, SE DMA or GSI DMA) as 
>> runtime and
>> drop this attribute.
>>
>> So instead of hardcoding this, add a way to dynamically select either of 
>> the 3
>> transfer types when firmware can be loaded from HLOS.
>>
>> Neil
>>
> 
> Yes, GSI DMA mode is required for specific use cases only.
> 
> Dynamically switching from GSI mode to non-GSI mode is neither possible 
> nor useful. For each SE, the use case is fixed, and based on the use 
> case, the developer can choose the mode via the device tree property.

No, it cannot. Do not describe downstream as something set in stone.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ