Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3146152pxm; Mon, 28 Feb 2022 13:03:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJyD2YUpljUuEmgjSHWPQikDIpGTFyMmSI9OL/64HENufQJHcI4c+G3YBz0SodkP/LhhRYJe X-Received: by 2002:a17:903:2489:b0:14f:fe0b:554b with SMTP id p9-20020a170903248900b0014ffe0b554bmr22408327plw.113.1646082225337; Mon, 28 Feb 2022 13:03:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646082225; cv=none; d=google.com; s=arc-20160816; b=tkA2pFJkLJ+6a/O7AE5kG21errXtLYnXH+v6VxVk9Exz5/3B7dGBz0yRewXm4lPCdb 34zeSPSQ3EVcgOEtowJUYBwrGzGby0R7eYHgUwcsNNwXkPxVWLJHxFpGXFBuAEa0Zp8v jAfFTtICq4yTD3N6svPX49JKclhMKMMwJ9ncTk2Q7T8Eo96NlypRqY+HCfdHb5BvGi8T t2KU/EwHenzdCXV7RalBkbCMtpNJLiyqHxgeLj1Jy6gDMJCFvPxxJCVTEmi6Br7BW4H0 Et+y8VvGE5hnfhT6jqlYX9IuHgPhtQgedWJ9m+h9/Dke7BsYZBEV4PWNBxnaz5tOczO8 oDRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=VZBP/n5mMCzFS82LeGWNgCwBAvcayN+a60oyEM3zI10=; b=AvVjTKqOPIFM/LmHfUjjxkewPhdXZIHr6hP7WNce66YzwiyYOj91OlchnadK+fpr3F rd8ReguYZ02S9yDENRGoQDLHHCh5wyPvBPlkFOeZ5Ja+odxw2bUCWy1pmX8LeR/GPpT4 Uht8UkEPBOG4i05t1iQfQqKRKmgog7+xTg9Ee/25Ux8Yv2AtOhjKHn2WnLP8bwjqEpIj PXoEC+BtFRMBSI5NtZow1Lg9qUJ4OrSnfwB6eAWBf2M/XOwsH4deJJu3t8oyPGEWblTK vNl4IG7iDqMht76l7nVGoOFeP7ImF4eQRY1ld6IFMqCiODoAKjoxA/p8goqmh7LZtUY7 UGLA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZScFoXS0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 11-20020a630e4b000000b0037476073f86si10182597pgo.831.2022.02.28.13.03.28; Mon, 28 Feb 2022 13:03:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ZScFoXS0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229985AbiB1VDh (ORCPT + 99 others); Mon, 28 Feb 2022 16:03:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229661AbiB1VDf (ORCPT ); Mon, 28 Feb 2022 16:03:35 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7FF062B240; Mon, 28 Feb 2022 13:02:56 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2483A60FB8; Mon, 28 Feb 2022 21:02:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7EF2FC340F4; Mon, 28 Feb 2022 21:02:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1646082175; bh=VZBP/n5mMCzFS82LeGWNgCwBAvcayN+a60oyEM3zI10=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZScFoXS0ZyN/43hbUGvbiPcAUOzmZi17c9MzKnstPv2k/5GjsIHX81yt+BHSK80kM 0JA1hog7ZgzwN78vY0+opHr9tplO8MdbIHddXTwg8r3oq9rrC5Gqd1duEefR1L2N52 nqc9zz8HUkP+8Id/LVYArq6uf6X0eB2pwUjH0NHBmF0ovunS4yeo/15IfmWkqhJHsZ 1XBMBx/1tVHBjIecW//SL/vgZJEy1alnHfPHZkQsr+aaUOgIknivBYKesIY9aqg2oP Y5toxly29HkwNkVkjoF3AKoatR5ns2tG1BmAqJlwmYTwjYogBFS6J02A23hsLtgiiH GJTtG/cEeLl/Q== Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-2dbd97f9bfcso5236557b3.9; Mon, 28 Feb 2022 13:02:55 -0800 (PST) X-Gm-Message-State: AOAM5311jtiVwFC/SG+P4K0O8avlNKBUGkVs56Z+dZYWvZLEZ8yKVA6Z aO5JPbOtDh8syW7XpTWSyXCBFFQSjpnC4MfL66Q= X-Received: by 2002:a81:84d5:0:b0:2d1:e85:bf04 with SMTP id u204-20020a8184d5000000b002d10e85bf04mr22378323ywf.465.1646082174505; Mon, 28 Feb 2022 13:02:54 -0800 (PST) MIME-Version: 1.0 References: <20220228183355.9090-1-Jason@zx2c4.com> In-Reply-To: From: Ard Biesheuvel Date: Mon, 28 Feb 2022 22:02:43 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/3 v6] ACPI: allow longer device IDs To: Andy Shevchenko Cc: "Jason A. Donenfeld" , "Rafael J. Wysocki" , Linux Kernel Mailing List , linux-crypto , ACPI Devel Maling List , Alexander Graf , Mika Westerberg , Andy Shevchenko , Hans de Goede , Len Brown , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 28 Feb 2022 at 21:47, Andy Shevchenko wrote: > > On Mon, Feb 28, 2022 at 9:28 PM Jason A. Donenfeld wrote: > > > > From: Alexander Graf > > > > We create a list of ACPI "PNP" IDs which contains _HID, _CID, and CLS > > entries of the respective devices. However, when making structs for > > matching, we squeeze those IDs into acpi_device_id, which only has 9 > > bytes space to store the identifier. The subsystem actually captures the > > full length of the IDs, and the modalias has the full length, but this > > struct we use for matching is limited. It originally had 16 bytes, but > > was changed to only have 9 in 6543becf26ff ("mod/file2alias: make > > modalias generation safe for cross compiling"), presumably on the theory > > that it would match the ACPI spec so it didn't matter. > > > Unfortunately, while most people adhere to the ACPI specs, Microsoft > > decided that its VM Generation Counter device [1] should only be > > identifiable by _CID with a value of "VM_Gen_Counter", which is longer > > than 9 characters. > > Then why do we not see the ECR from somebody to update the spec or to > fix MS' abuse of it? > I believe _this_ should be the prerequisite to the proposed change. > What exactly are you suggesting here? That the contributor of this patch joins the UEFI forum as an individual adopter in order to get the ACPI spec updated before we can advance with this patch? Or that he works with Microsoft to get them to refrain from violating it? I don't think that is reasonable or realistic. The kernel is already riddled with UEFI and ACPI quirks that are only there because some teams at MS don't take the ACPI spec too literally (which is why they have their own AML compiler, for one), and PC vendors only care about the Windows sticker, so they don't care about the ACPI spec either. So I don't think this is the right time to get pedantic about this. Our ACPI subsystem already deals with CIDs that are longer than 8 characters (which are btw permitted by the ACPI spec for bus topology related metadata), the only thing being changed here is the ability to actually match against such identifiers.