On Thu, Apr 11, 2024 at 03:57:16AM -0400, Sasha Levin wrote: > 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. Does it? Seems like a rather big hammer to me. I totally understand blocking the addition of new dts files to stable, but there's a whole load of different people maintaining dts files with differing levels of remembering to cc stable explicitly. That said, often a dts backport depends on a driver (or binding) change too, so backporting one without the other may have no effect. I have no idea whether or not AUTOSEL is capable of picking out those sort of dependencies.
Attachment:
signature.asc
Description: PGP signature
