I don't think your link contains the evidence you think it does. I'm not seeing anything that looks like Qualcomm contributing device trees on behalf of system OEMs, for any of the Snapdragon X products, so I don't see how you can claim that they're being selective. It looks like the device trees are mostly being reverse-engineered by the community, adding new system support derived from device trees for systems that already have some support.
Do you have any clear instances of Qualcomm contributing something that's specific to Snapdragon X Elite parts and does not work for Snapdragon X Plus bins of the same silicon?
Or even for the more general issue: have you ever seen a Linux driver include arbitrary restrictions that make it refuse to work on identical hardware just because the marketing name for that bin of the same silicon was different?
> Do you have any clear instances of Qualcomm contributing something that's specific to Snapdragon X Elite parts and does not work for Snapdragon X Plus bins of the same silicon?
You're getting caught up by inconsistencies in an argument you brought up. Which suggests the argument itself is flawed.
My unchanged position is Snapdragon X Elite laptops have better Linux support than the Plus variants. You thought I was wrong on that count - but I wasn't (see the thread).
Qualcomm only ever pledged to support Elite processors, and perhaps not coincidentally all of the Plus laptops require reversing- this is enough for me to draw conclusions. If you need the technical root cause, feel free to delve into why the originally supported models with devicetres had Elite chips.
> Qualcomm only ever pledged to support Elite processors
Link, please.
> and perhaps not coincidentally all of the Plus laptops require reversing
You're still acting as though Qualcomm has made meaningful contributions to Linux support for Snapdragon X Elite in a way that has not also helped Snapdragon X Plus support. But you haven't specifically pointed to any Qualcomm contributions of any nature, let alone ones that were as narrow as you claim. All you've done is point to weak evidence that machines with Snapdragon X Elite bins reached a reasonable threshold of "supported" earlier than models with lesser parts, while ignoring that your evidence also points to the lower-tier processors coming to market later.
Can you point to any laptop device tree that was contributed by Qualcomm, and not merely reverse-engineered from the device tree for the reference design that was not offered for sale to consumers? Can you point to any driver contributed by Qualcomm that works for Snapdragon X Elite SoCs but requires further modification to work for Snapdragon X Plus SoCs?
You made a claim about a pattern in Qualcomm's public behavior, and have identified zero instances of that pattern.
Try the first Qualcomm link I sent upthread. I have trouble accepting you're arguing in good faith because you could have checked this for yourself. All the articles I can find pivlished by, or quoting Qualcomm concerning Snapdragon X and Linux consistently refer to the Elite version: I challenge you to find a single counterexample that mentions Plus.
You call my evidence weak, and yet you have provided no evidence to support your evolving argument thus far, so I hereby invoke Hitchen's razor, and will not engage with you beyond this comment. I refuse to spend any more of my time and energy trawling a 1200+ page Discord thread, Gthub, or the kernel mailing list searching for empirical evidence to counter your 10-second thought experiments, when you can't be bothered to open links I've already shared unprompted.
Do you have any clear instances of Qualcomm contributing something that's specific to Snapdragon X Elite parts and does not work for Snapdragon X Plus bins of the same silicon?
Or even for the more general issue: have you ever seen a Linux driver include arbitrary restrictions that make it refuse to work on identical hardware just because the marketing name for that bin of the same silicon was different?