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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <af926bd7-730c-4465-a206-4168bb93d01a@quicinc.com>
Date: Tue, 28 Jan 2025 14:46:27 +0530
From: Raj Kumar Bhagat <quic_rajkbhag@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, <ath12k@...ts.infradead.org>
CC: <linux-wireless@...r.kernel.org>, Kalle Valo <kvalo@...nel.org>,
        Rob
 Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor
 Dooley <conor+dt@...nel.org>,
        Jeff Johnson <jjohnson@...nel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v4 00/13] wifi: ath12k: add Ath12k AHB driver support for
 IPQ5332

On 12/10/2024 8:42 PM, Krzysztof Kozlowski wrote:
> On 10/12/2024 16:08, Krzysztof Kozlowski wrote:
>> On 10/12/2024 08:41, Raj Kumar Bhagat wrote:
>>> Currently, Ath12k driver only supports WiFi devices that are based on
>>> PCI bus. New Ath12k device IPQ5332 is based on AHB bus. Hence, add
>>> Ath12k AHB support for IPQ5332.
>>>
>>> IPQ5332 is IEEE802.11be 2 GHz 2x2 Wifi device. To bring-up IPQ5332
>>> device:
>>> - Add hardware parameters for IPQ5332.
>>> - CE register address space in IPQ5332 is separate from WCSS register
>>>   space. Hence, add logic to remap CE register address.
>>> - Add support for fixed QMI firmware memory for IPQ5332.
>>> - Support userPD handling for WCSS secure PIL driver to enable ath12k
>>>   AHB support.
>>>
>>> v4:
>>> - Missed to include some review list in v3. Hence sending v4 with
>>>   all review list as per - scripts/get_maintainers.pl
>>>
>> The amount of undocumented ABI you add here, points to the problem that
>> either your drivers don't work or your drivers would never work with
>> upstream. Why? Because either you would have wrong DTS or drivers not
>> matching DTS, thus not working.
>>
>> Please point us to your upstream DTS implementing (and working 100%)
>> this ABI, so we can review that you do not sneak more broken or
>> undocumented things. I will NAK also future submissions without above,
>> because I believe you usptream something which will not work.
> 
> 
> I dug a bit and I found your earlier v2:
> https://lore.kernel.org/all/20241015182637.955753-3-quic_rajkbhag@quicinc.com/
> 
> which confirms:
> 1. DTS not following coding style, so not possible to accept
> 2. Driver relying on that exact DTS, so not really working.
> 
> Please post in separate series updated DTS, after fixing all the issues
> pointed out by DTS coding style.
> 

To fix all the issues in DTS (including undocumented ABIs) we did changes in
dt-binding as well.

The dt-binding and working DTS are now posted as separate series -
https://lore.kernel.org/lkml/20250128091012.2574478-1-quic_rajkbhag@quicinc.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ