Re: Patch "arm64: dts: qcom: Add support for Xiaomi Redmi Note 9S" has been added to the 6.8-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 11, 2024 at 09:34:39AM +0200, Greg KH wrote:
On Thu, Apr 11, 2024 at 09:27:28AM +0200, Krzysztof Kozlowski wrote:
On 11/04/2024 09:22, Greg KH wrote:
> On Wed, Apr 10, 2024 at 08:24:49PM +0200, Krzysztof Kozlowski wrote:
>> On 10/04/2024 20:02, Greg KH wrote:
>>> On Wed, Apr 10, 2024 at 07:58:40PM +0200, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 4/10/24 17:57, Sasha Levin wrote:
>>>>> This is a note to let you know that I've just added the patch titled
>>>>>
>>>>>      arm64: dts: qcom: Add support for Xiaomi Redmi Note 9S
>>>>
>>>> autosel has been reeaaaaaly going over the top lately, particularly
>>>> with dts patches.. I'm not sure adding support for a device is
>>>> something that should go to stable
>>>
>>> Simple device ids and quirks have always been stable material.
>>>
>>
>> That's true, but maybe DTS should have an exception. I guess you think
>> this is trivial device ID, because the patch contents is small. But it
>> is or it can be misleading. The patch adds new small DTS file which
>> includes another file:
>>
>> 	#include "sm7125-xiaomi-common.dtsi"
>>
>> Which includes another 7 files:
>>
>> 	#include <dt-bindings/arm/qcom,ids.h>
>> 	#include <dt-bindings/firmware/qcom,scm.h>
>> 	#include <dt-bindings/gpio/gpio.h>
>> 	#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>> 	#include "sm7125.dtsi"
>> 	#include "pm6150.dtsi"
>> 	#include "pm6150l.dtsi"
>>
>> Out of which last three are likely to be changing as well.
>>
>> This means that following workflow is reasonable and likely:
>> 1. Add sm7125.dtsi (or pm6150.dtsi or pm6150l.dtsi)
>> 2. Add some sm7125 board (out of scope here).
>> 3. Release new kernel, e.g. v6.7.
>> 4. Make more changes to sm7125.dtsi
>> 5. The patch discussed here, so one adding sm7125-xiaomi-curtana.dts.
>>
>> Now if you backport only (5) above, without (4), it won't work. Might
>> compile, might not. Even if it compiles, might not work.
>>
>> The step (4) here might be small, but might be big as well.
>
> Fair enough.  So should we drop this change?

I vote for dropping. Also, I think such DTS patches should not be picked
automatically via AUTOSEL. Manual backports or targetted Cc-stable,
assuming that backporter investigated it, seem ok.

Sasha now dropped this, thanks.

Sasha, want to add dts changes to the AUTOSEL "deny-list"?

Sure, this makes sense.

--
Thanks,
Sasha




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux