From: Mario Limonciello <mario_limonciello@dell.com>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Jason Ekstrand <jason@jlekstrand.net>,
LKML <linux-kernel@vger.kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Bard Liao <bardliao@realtek.com>,
Liam Girdwood <liam.r.girdwood@linux.intel.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"lenb@kernel.org" <lenb@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH] ACPI: Adjust the return value of _REV on x86
Date: Tue, 24 Mar 2015 12:22:18 -0500 [thread overview]
Message-ID: <55119D4A.5050809@dell.com> (raw)
In-Reply-To: <20150324152412.GA4706@codeblueprint.co.uk>
On 03/24/2015 10:24 AM, Matt Fleming wrote:
> On Tue, 24 Mar, at 12:50:47AM, Mario Limonciello wrote:
> Running a recent kernel is the tradeoff to be paid for using brand new
> hardware. I certainly don't expect to be able to install a 4-year old
> version of Fedora on a laptop released this year and have it work
> flawlessly.
Yes, of course older kernels won't include everything, but there are plenty of people out there that don't use (or know how to use) a newer kernel in their distro. There's enough customers that our support staff will deal with mandate particular (older) kernel versions or particular distros. Some stuff can certainly be backported into stable and come in the form of updates to those older kernels, but it is indeed a tradeoff.
> Besides, distributions aggressively backport patches for new hardware
> support anyway and you should work with the distribution developers to
> ensure that happens for your hardware. Preferably before it gets
> released.
With the XPS 13 (2015) in particular, we've been working with Canonical for a very long time in planning and development. Long enough that when the plans w/ our IHV's for the audio to be HDA in Linux were made before this commit even landed:
https://github.com/torvalds/linux/commit/faae404ebdc6bba744919d82e64c16448eb24a36#diff-aa93b5317c200560767b97a9d9301bd8
At that time rt286 I2S wasn't even in the kernel. Bard didn't start to land it until later that year (https://github.com/torvalds/linux/commit/07cf7cbadb4d97a78be61119a406de8fe446467e). Was it really that crazy to plan Linux to take HDA mode?
> Because, fundamentally, when you make these decisions about Linux in the
> BIOS you're pitting the BIOS and kernel development models against each
> other. What is going to happen when i2s/i2c finally works correctly in
> the kernel and distros? It would seem unlikely that a BIOS update would
> be available to switch everyone to that mode.
>
Once all this I2S development spun up specific to the XPS 13, that's exactly the plan that we had discussed. Try to get the major distros on board with all the patches that were needed and issue a BIOS update to adjust the behavior.
> I'm sure the audio folks would love to hear about them.
Liam is aware of the details here. Other than one issue, it optimistically sounds like a majority of the issues will be sorted in the next few weeks on both the kernel and user-space side.
>
> Unless the patch gets backported to stable kernel versions older than
> 4.x. Which is likely.
>
I would like to respectfully ask that this patch not be added to older stable kernel versions. It will knowingly cause a regression with hardware in the field. If this isn't an appropriate criteria for avoiding to backport a patch to stable, what is?
next prev parent reply other threads:[~2015-03-24 17:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 8:50 [PATCH] ACPI: Adjust the return value of _REV on x86 Matthew Garrett
2015-03-14 19:58 ` Jason Ekstrand
2015-03-16 23:21 ` Jason Ekstrand
2015-03-23 12:04 ` Matt Fleming
2015-03-24 5:50 ` Mario Limonciello
2015-03-24 9:17 ` Liam Girdwood
2015-03-24 14:41 ` Mario Limonciello
2015-03-24 15:24 ` Matt Fleming
2015-03-24 17:22 ` Mario Limonciello [this message]
2015-03-24 18:01 ` Matthew Garrett
2015-03-24 19:53 ` Mario Limonciello
2015-03-24 20:00 ` Matthew Garrett
2015-03-24 20:02 ` Rafael J. Wysocki
2015-03-24 20:21 ` Mario Limonciello
2015-03-26 2:40 ` Yuhong Bao
2015-03-16 20:34 ` Al Stone
2015-03-16 21:01 ` Matthew Garrett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55119D4A.5050809@dell.com \
--to=mario_limonciello@dell.com \
--cc=bardliao@realtek.com \
--cc=jason@jlekstrand.net \
--cc=lenb@kernel.org \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mjg59@srcf.ucam.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.