lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 24 Mar 2015 12:22:18 -0500
From:	Mario Limonciello <mario_limonciello@...l.com>
To:	Matt Fleming <matt@...eblueprint.co.uk>
CC:	Jason Ekstrand <jason@...kstrand.net>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Bard Liao <bardliao@...ltek.com>,
	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH] ACPI: Adjust the return value of _REV on x86


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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ