Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753854AbdLICex (ORCPT ); Fri, 8 Dec 2017 21:34:53 -0500 Received: from esa2.dell-outbound.iphmx.com ([68.232.149.220]:57377 "EHLO esa2.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753157AbdLICer (ORCPT ); Fri, 8 Dec 2017 21:34:47 -0500 IronPort-PHdr: =?us-ascii?q?9a23=3Aft304RAXnLuLWMvMedqZUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPXzoMbcNUDSrc9gkEXOFd2CrakV26yO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iS?= =?us-ascii?q?cHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2pMRsZfWTJcDI2y?= =?us-ascii?q?bIUBCPEMMfpEo4Tnu1cDtweyCRWqCejyyjFInHj23agi3uomCw7Gxg0gH9UTu3?= =?us-ascii?q?rSrdX1MaASUeapw6nJ0zrDa/dW2TDg44XPdxAuu+uMXbN3ccbLzUkvFgbFjlKW?= =?us-ascii?q?qYP5PjOayOANs2yc7+d7SO2glWonqwVrrjezwccsj5DEi4QIwV7H7SV02Ic4KN?= =?us-ascii?q?6iREJlb9OoDoFcuzyaOoZ5WM8vQm9ltD4nxrAJt5O3ZjUGxZUmyhLFdvCKfIuF?= =?us-ascii?q?7gj9WOqPLzp1gm9udqiliBao60egz/XxVsyz0FlXsCVIisLMtnUR1xzL7ciHV+?= =?us-ascii?q?d98l+h2TmR0wDT7flJLl4vlaXBJZMt2KM/mYQXsUTHByP2n1j2jLONeUUj5+io?= =?us-ascii?q?7fnobqv8qp+dL490igT+M6s0lsOjBuQ4NxACX2md+euiyL3u5Uz0TbZQgvEonK?= =?us-ascii?q?TVrorWKdkbq6O2GQNY04gu5w66Dzi80dQYmXcHLEhCeBKCl4XpPkvBIOr5Dfe4?= =?us-ascii?q?mVislDZrx/XBPr3nHprNL2bMkLPlfbZ68ENT1RQ8zdRb555OFr4BJ/fzVlfrtN?= =?us-ascii?q?PEFh85LxC0w+H/BdV514MeX3+PA6CAPKPRr1CI/OQvLPeIZIIOpjb9JOYq5+T0?= =?us-ascii?q?gX86h1AdZ6+p0oUTaHyiGfRmOUqZa2L2gtgdCWcKohY+TOvyhV2aVT5cfWqyX6?= =?us-ascii?q?w75jEhDYKqFJrMRpqsgLyfwii7BIRaZ29FB12NCnroaYqEVOkWaC6IIc9ujCYE?= =?us-ascii?q?Vb6/RI8lzx2usxX6y7U0ZtbTryEGtZv5yPB04ePJnB0//DAyCN6SlymkSW1l1l?= =?us-ascii?q?gISiE93K15oks1nl6F3bk+mPxVC9dT6vVKVS81MJfdy6pxDNWkCSzbedLcbV+8?= =?us-ascii?q?Q9LuJTA0SdQ6wtIKZ0E1T9CrlBHEmS6rBrgTnL2GAJgz2q7R23y3LMF4nSWVnJ?= =?us-ascii?q?I9hkUrF5McfVatgbRyok2KX9bE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EnAgD7Sitahz+a6ERcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYUYnUiZCYIVCoU7hGFBFgEBAQEBAQEBAQECEAEBAQoLCQgoL4I4JAG?= =?us-ascii?q?DRk9vAS2KDaliix6DW4ILgVaBaY5CBYpFiFqPaYI5kmcCk1+WXIE7Jg6BdG9Pg?= =?us-ascii?q?iqCAQFPEAyCBoshAQEB?= X-IPAS-Result: =?us-ascii?q?A2EnAgD7Sitahz+a6ERcGgEBAQEBAgEBAQEIAQEBAYUYnUi?= =?us-ascii?q?ZCYIVCoU7hGFBFgEBAQEBAQEBAQECEAEBAQoLCQgoL4I4JAGDRk9vAS2KDalii?= =?us-ascii?q?x6DW4ILgVaBaY5CBYpFiFqPaYI5kmcCk1+WXIE7Jg6BdG9PgiqCAQFPEAyCBos?= =?us-ascii?q?hAQEB?= X-LoopCount0: from 10.208.86.39 X-IronPort-AV: E=Sophos;i="5.45,380,1508821200"; d="scan'208";a="98092404" X-DLP: DLP_GlobalPCIDSS From: Mario Limonciello To: dvhart@infradead.org, Andy Shevchenko Cc: LKML , platform-driver-x86@vger.kernel.org, Andy Lutomirski , Mario Limonciello Subject: [PATCH 0/2] Parse multiple duplicate WMI GUIDs Date: Fri, 8 Dec 2017 20:34:19 -0600 Message-Id: <1512786861-1014-1-git-send-email-mario.limonciello@dell.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1392 Lines: 33 I recently discovered that multiple instances of the WMI BMOF GUID are present on some machines with more advanced WMI implementations. Only the first found instance is parsed today with the rest ignored. The rest of the instances should be readable by the wmi-bmof driver (and userspace) to allow improving any parsing implementations. Andy L. indicated he thought fixing this should require changing the WMI driver to no longer track a block list of devices, but I don't think that's necessary. The only significant change is that the WMI bus will need to build the symlinks in /sys/bus/wmi/devices in a way to prevent clashes with multiple devices sharing the same GUID. The most obvious solution (and that which I implemented) is to include the ACPI device associated with the GUID. Since this is a symlink and the actual path remains stable I don't know if that's considered changing a userspace interface. If so, then an alternative would be to append a number when a second instance of a GUID has been discovered and keep the "old" symlink path for the first instance stable. Mario Limonciello (2): platform/x86: wmi: prefix sysfs files in /sys/bus/wmi with the ACPI device platform/x86: wmi: Allow creating WMI devices with the same GUID drivers/platform/x86/wmi.c | 34 ++-------------------------------- 1 file changed, 2 insertions(+), 32 deletions(-) -- 2.14.1