On Tue, Feb 16, 2016 at 10:04:02AM +0800, Ike Panhc wrote: > On 02/16/2016 01:32 AM, Bjørn Mork wrote: > > Ike Panhc <ike.pan@xxxxxxxxxxxxx> writes: > >> On 02/15/2016 08:08 PM, Bjørn Mork wrote: > >>> Ike Panhc <ike.pan@xxxxxxxxxxxxx> writes: > >>> > >>>> There are complains on few ideapads that wireless is always hard > >>>> blocked but there is no physical radio switch. For now, we need > >>>> each user to report its dmi information and ignore hard blocks > >>>> on their ideapad. With more and more ideapads available in market > >>>> to maintain the dmi table becomes never-ended job. > >>>> > >>>> I've checked lenovo website and for recent design none of the > >>>> ideapads has radio switch. I do not believe there will be in the > >>>> future. Therefore to disable hard block according to BIOS date is > >>>> reasonable approach. > >>>> > >>>> This patch will disable rfkill hardblock if BIOS year > 2015. > >>> > >>> Huh? And what happens when a user upgrades the BIOS on older hardware? > >>> > >> > >> That's why I believe > 2015 is a better choice, not > 2014. > >> > >> Ideapads in market now carries BIOS year 2015 and I found no radio switch > >> on them. And I don't believe anyone will receive or upgrade BIOS for more > >> then 1y old machine. In fact I haven't heard anyone upgrading BIOS for a > >> long time. > > > > Now I don't know this platform, but that assumption seems terribly > > fragile to me. > > Maybe I do not say why I propose this patch clearly. User can not use > wireless with network manager if hardblock reports yes faultily. For > now, more then half of ideapad models has no ethernet port and even > with ethernet, user will only find out wireless does not work. User > without ability to blacklist ideapad_laptop will consider Linux faulty > and choose other solution. > > > > > Do you own a crystal ball? Are BIOS updates for older machines so > > unlikely that you don't even have to consider the possibility? What > > about a security flaw affecting the BIOS of a large number of older > > machines? Has that never happened? > > Upgrading BIOS might brick the machine. Laptop seller likes that even > less. I'm going to have to concur with Bjørn Mork here. While vendors do not upgrade their firmware as frequently as they should or as we would like, we really should avoid penalizing them if they do choose to provide an update! > > > > > Sorry, but I don't think it's very nice to owners of older ideapads to > > just let their rfkill devices disappear silently if they ever upgrade > > their BIOS after 2015. Yes, that may not be possible right now. And it > > might never become possible. I don't know. But what exactly is your > > plan *if* it becomes possible? > > This is very close to impossible. In this case, I can introduce a new > dmi tables to whitelist those models. > The long list DMI whitelist is particularly tedious to generate and maintain. > > > > And are you sure there is no proper way to fix this issue? I know > > firmware engineers are evil ;) But it would be surprising if they didn't > > put some clue about the physical switch into the BIOS tables. I see > > that you check flags for wlan/bt/3g existence. Maybe there is another > > flag indicating the switch existence? Or maybe some other acpi method? > > Indeed. They are evil. > > I've asked acpidump for one of the ideapads[1] and find out those flags[2] > are from EC register[3] which is blackbox to us. > > [1] https://bugs.launchpad.net/bugs/1528299 > [2] http://pastebin.ubuntu.com/15088110/ > [3] http://pastebin.ubuntu.com/15088128/ > > > > > At the very least, I am convinced there are other hardware you can > > correlate the switch existence with. > > I believe so but I do not believe they are ideapads. I think his point is that you may be able to detect a newer ideapad by the presence or absence of another device. Heck, CPU ID would give a reasonable idea regarding date of manufacture if all else fails. -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
