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: <785fb4be-22b2-4881-8900-e7001945f929@kernel.org>
Date: Thu, 4 Dec 2025 11:42:51 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Pavel Machek <pavel@....cz>
Cc: Jingyi Wang <jingyi.wang@....qualcomm.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 aiqun.yu@....qualcomm.com, tingwei.zhang@....qualcomm.com,
 trilok.soni@....qualcomm.com, yijie.yang@....qualcomm.com,
 Tengfei Fan <tengfei.fan@....qualcomm.com>,
 Qiang Yu <qiang.yu@....qualcomm.com>,
 Manish Pandey <manish.pandey@....qualcomm.com>,
 Ronak Raheja <ronak.raheja@....qualcomm.com>,
 Jishnu Prakash <jishnu.prakash@....qualcomm.com>,
 Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>,
 Jyothi Kumar Seerapu <jyothi.seerapu@....qualcomm.com>,
 Prasad Kumpatla <prasad.kumpatla@....qualcomm.com>,
 Hangxiang Ma <hangxiang.ma@....qualcomm.com>,
 Vikash Garodia <vikash.garodia@....qualcomm.com>
Subject: Re: [PATCH 00/20] arm64: dts: qcom: Introduce Kaanapali platform
 device tree

On 04/12/2025 10:14, Pavel Machek wrote:
> On Wed 2025-12-03 19:40:20, Krzysztof Kozlowski wrote:
>> On 03/12/2025 19:10, Pavel Machek wrote:
>>> On Wed 2025-12-03 18:31:11, Krzysztof Kozlowski wrote:
>>>> On 02/12/2025 19:21, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>>> Introduce the Device Tree for the recently announced Snapdragon SoC from Qualcomm:
>>>>>> https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-8-series-mobile-platforms/snapdragon-8-elite-gen-5
>>>>>>
>>>>>> Bindings and base Device Tree for the Kaanapali SoC, MTP (Mobile Test Platform)
>>>>>> and QRD (Qualcommm Reference Device) are splited in three:
>>>>>>
>>>>>> - 1-3: MTP board boot-to-shell with basic function.
>>>>>> - 4-16: More feature including PCIE, sdcard, usb, DSPs, PMIC related, tsense, bus, crypto etc. Add QRD board support.
>>>>>> - 17-20: Multimedia features including audio, video and camss.
>>>>>
>>>>> Thanks for doing this. I assume there devices available with this are
>>>>> quite expensive/hard to get at this point?
>>>>>
>>>>> Please cc phone-devel@...r.kernel.org with phone related patches.
>>>>
>>>> That's not even a phone, anyway contributors should not cc lists which
>>>> are not relevant to the posting and not pointed out by maintainers. You
>>>
>>> People should Cc relevant lists, and yes, if it is called "Mobile Test
>>> Platform", it is relevant to phone development.
>>
>>
>> Almost everything in ARM64 is then relevant for "phone development".
> 
> No.
> 
>> People should use tools, not invent or try to guess whom to Cc. It's
> 
> No. People should cc relevant people / lists. Tools are tools,
> submitter is responsible for getting the cc right. I believe you
> should be capable of reading our patch submission guidelines yourself,
> but I can find it for you if you are not.
> 
>> impossible to btw keep guessing them - you will request phone-devel,
>> someone else will request desktop-devel, laptop-devel or
> 
> Desktop-devel is not kernel-related list. But yes, if
> cat-picture-devel was somehow relevant because now interface to
> cat-pictures changeed, it would be your responsibility to cc it.

Maintainers decide what is relevant, not you. Just because you wanted
phone-devel list does not grant you ability to impose such rule and
claim it is relevant and people should Cc it.

No, there is no rule of Cc-ing phone-devel. No one has to do it and you
need to stop coming with the impression that it is sanctioned rule by
any platform or architecture maintainer.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ