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, 15 May 2012 00:10:03 +0200
From:	Jean-Louis Dupond <jean-louis@...ond.be>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	Mario Limonciello <mario_limonciello@...l.com>,
	Kamal Mostafa <kamal@...onical.com>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dell-laptop: rfkill blacklist Dell XPS 13z, 15z

Hi

I'm the owner of a XPS 15, which has this issue.
The best solution would indeed be to solve the real bug, and not work
around it in Linux.

But still, if we can fix it with rather small impact/code on linux, I
think we should just do it.
It makes linux more user friendly this way.

A small remark also:
Is it really possible to disable bluetooth without killing wifi in
Windows on the XPS?
Not that I use windows alot, but it doesn't seem to work perfectly in
windows neither.
This bug is prolly not very common, as default XPS doesn't have a
bluetooth chip.


Thanks
Jean-Louis

Op 14-05-12 23:55, Matthew Garrett schreef:
> On Mon, May 14, 2012 at 04:48:24PM -0500, Mario Limonciello wrote:
>
>> The problems were exposed on newer XPS laptops because those platforms 
>> were not tested during platform development.  There really isn't a 
>> scalable way to represent whether a platform was or wasn't tested 
>> during development.  In a lot of situation things just work.  I would 
>> like to do the right thing for the users with what information and 
>> resources are available right now to put them in a better state.  An 
>> aggressive approach of not taking patches to cover a broken interface 
>> won't fix the problem of not testing machines already in the market, 
>> it will just put end users of the kernel module at a disadvantage.
> That's why it's better to just remove the interface. Providing a feature 
> when we know it's broken on some unknown subset of hardware doesn't 
> benefit anyone. If even Dell don't have any idea which set of machines 
> it works on then how are we ever expected to make sure it's correct?
>
>> 1) Don't blacklist any Latitude or Vostro.  These are tested during platform development.
>> 2) Leave those compal_laptop supported ones blacklisted.
>> 3) Blacklist 2010-2012 XPS.  These are currently not tested during platform development.
>> 4) If problems start to show up on Inspiron, blacklist them invidually.  These platforms are currently tested during platform development though, so hopefully issues don't crop up.
> Is this the set of criteria that the Windows tools use? If so, I'll 
> implement it. If not, then either provide the set of criteria that the 
> Windows tools use or I'll remove the interface.
--
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