[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20240126090349.GN74950@google.com>
Date: Fri, 26 Jan 2024 09:03:49 +0000
From: Lee Jones <lee@...nel.org>
To: alex vinarskis <alex.vinarskis@...il.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
linux-kernel@...r.kernel.org, Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v4 0/2] Fix LPSS clock divider for XPS 9530
Please don't drop the list. Other people may benefit from your questions.
I'm redacting some of the text which may cause conflict and adding back
the original recipient's list.
On Fri, 26 Jan 2024, alex vinarskis wrote:
> > On Thu, 21 Dec 2023 19:51:40 +0100, Aleksandrs Vinarskis wrote:
> > > Dell XPS 9530 (2023) uses spi-pxa2xx with clock-divider enabled from
> > > intel-lpss with the ratio of 1:32767 (Dell's firmware bug). This caps SPI
> > > controller's speed at very low value of 3051Hz, which makes the interface
> > > practically unusable. Since either spi-pxa2xx or intel-lpss should have
> > > clock divider enabled, not both, and SPI controller can have higher speed
> > > than requested by the device, it is preffered to disable intel-lpss
> > > clock-divider, and let SPI controller handle it.
> > >
> > > [...]
> >
> > Applied, thanks!
>
> Hi,
>
> I've got a quick question regarding the merging procedure, apologies
> if this was trivial,
> I am still rather new to this:
>
> I noticed that this series was staged for `for-mfd-next-next`, while
> only `for-mfd-next`
> was merged to 6.8-rc1. Does that imply that following series is not
> planned to be included
> in 6.8, but rather in 6.9?
Yes, that's correct. The `for-mfd-next-next` branch comes into play
when `for-mfd-next` gets locked down for inclusion and gets merged into
`for-mfd-next` once the merge window has closed.
> If yes, could I ask why? It was under the impression that it was
> submitted in time (at the late stage of 6.7 testing) to make it to 6.8
It was not. Most maintainers stop merging new patches in the mid to
late -rcs for inclusion into the next merge-window. I like to have
all new additions soak in Linux Next (-next) for at least 2 to 3 weeks
before sending to Linus.
> (sadly, not in time for LTS > 6.7).
I think you're confusing 2 different things. I assume you mean the
-rcs. LTS (Long Term Stable) is for fixes. Commits end up there
*after* they land in Mainline so long as they conform to the rules set
out in:
Documentation/process/stable-kernel-rules.rst
> Reason I am asking is
> because this is the last series required to fix audio on XPS 9530
> laptops: [1] was merged in
> 6.7, [2] was merged in 6.8-rc1 and backported to 6.7.1-rc1. Thus me
> and other XPS users
> are extremely eager to see this land in the next kernel release, as
> there was quite some
> community effort to get this done.
Adding support for new devices isn't usually a good enough reason to
submit to the -rcs. The -rcs are used to fix issues that broke during
the merge-window of the same release and for urgent bug fixes.
This set will be applied to v6.8-rc1. From there you can apply to have
it backported (or better still, backport and submit it yourself) to
Stable (a.k.a. LTS). Since it's the LTS' that you will usually find
running on your distro of choice, your audio will likely be fixed with
an upcoming `apt upgrade` or equivalent.
> Once again, apologies if this question is obvious,
> Thanks,
> Alex
>
> [1] https://lore.kernel.org/all/20231203233006.100558-1-alex.vinarskis@gmail.com/
> [2] https://lore.kernel.org/all/20231221132518.3213-1-sbinding@opensource.cirrus.com/
>
> >
> > [1/2] mfd: intel-lpss: Switch to generalized quirk table
> > commit: d43b5230c38ed6001f996eb9262b457713b31ef8
> > [2/2] mfd: intel-lpss: Introduce QUIRK_CLOCK_DIVIDER_UNITY for XPS 9530
> > commit: 106362167f49a0e83f4e6c26f9653f3061575229
> >
> > --
> > Lee Jones [李琼斯]
> >
--
Lee Jones [李琼斯]
Powered by blists - more mailing lists