From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: David Woodhouse <dwmw@amazon.co.uk>,
Babis Chalios <bchalios@amazon.es>,
Takahiro Itazuri <itazur@amazon.com>,
Jakub Kicinski <kuba@kernel.org>, Sasha Levin <sashal@kernel.org>,
dwmw2@infradead.org, richardcochran@gmail.com,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
pabeni@redhat.com, netdev@vger.kernel.org
Subject: [PATCH AUTOSEL 6.19-6.18] ptp: ptp_vmclock: add 'VMCLOCK' to ACPI device match
Date: Sat, 14 Feb 2026 16:23:44 -0500 [thread overview]
Message-ID: <20260214212452.782265-79-sashal@kernel.org> (raw)
In-Reply-To: <20260214212452.782265-1-sashal@kernel.org>
From: David Woodhouse <dwmw@amazon.co.uk>
[ Upstream commit ed4d23ed469ca14d47670c0384f6ae6c4ff060a5 ]
As we finalised the spec, we spotted that vmgenid actually says that the
_HID is supposed to be hypervisor-specific. Although in the 13 years
since the original vmgenid doc was published, nobody seems to have cared
about using _HID to distinguish between implementations on different
hypervisors, and we only ever use the _CID.
For consistency, match the _CID of "VMCLOCK" too.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Babis Chalios <bchalios@amazon.es>
Tested-by: Takahiro Itazuri <itazur@amazon.com>
Link: https://patch.msgid.link/20260130173704.12575-6-itazur@amazon.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Analysis
### Commit Message Analysis
The commit adds a new ACPI device ID `"VMCLOCK"` to the
`vmclock_acpi_ids` match table in the `ptp_vmclock` driver. The commit
message explains that this is for consistency with the spec - the `_CID`
(Compatible ID) of "VMCLOCK" should also be matched, in addition to the
existing hypervisor-specific `_HID` "AMZNC10C".
### Code Change Analysis
The change is a single line addition:
```c
{ "VMCLOCK", 0 },
```
This adds one more ACPI device ID to the `vmclock_acpi_ids[]` table.
This is the classic "add device ID to existing driver" pattern.
### Classification
This falls squarely into the **New Device IDs** exception category.
Adding an ACPI ID to an existing driver is one of the most common and
safest types of stable backports. The driver (`ptp_vmclock`) already
exists; only a new match ID is being added so the driver can bind to
devices presenting themselves with the `VMCLOCK` compatible ID.
### Scope and Risk Assessment
- **Lines changed**: 1 line added
- **Files touched**: 1 file
- **Risk**: Extremely low - this only adds one more entry to an ACPI
match table
- **Side effects**: None - this cannot break any existing functionality.
It only enables the driver to match against an additional ACPI device
identifier.
### User Impact
Without this patch, the vmclock driver will not bind to devices that
present with the `VMCLOCK` _CID instead of the `AMZNC10C` _HID. This
means virtual machines using the generic "VMCLOCK" compatible ID (as
intended by the spec) would not get vmclock functionality. This affects
users running Linux guests in hypervisor environments that use the
standard VMCLOCK ACPI identifier.
### Stability Indicators
- **Tested-by**: Takahiro Itazuri (Amazon)
- **Signed-off-by**: David Woodhouse (well-known kernel developer) and
Jakub Kicinski (networking maintainer)
- The change is trivially correct - it's adding an entry to a static
const table
### Dependency Check
The only dependency is that the `ptp_vmclock.c` driver must exist in the
stable tree. This driver was added relatively recently, so it may only
be present in newer stable trees. Let me check when this driver was
introduced.
Looking at the context: `ptp_vmclock.c` is a relatively new driver. If
it exists in the stable tree being targeted, this one-line device ID
addition applies trivially. If the driver doesn't exist in a particular
stable tree, the patch is simply not applicable (and not needed).
### Conclusion
This is a textbook device ID addition to an existing driver:
- One line, zero risk
- Enables hardware/virtual device support for users who need it
- Already tested
- Falls under the well-established "new device IDs" exception for stable
**YES**
drivers/ptp/ptp_vmclock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ptp/ptp_vmclock.c b/drivers/ptp/ptp_vmclock.c
index b3a83b03d9c14..cbbfc494680c7 100644
--- a/drivers/ptp/ptp_vmclock.c
+++ b/drivers/ptp/ptp_vmclock.c
@@ -591,6 +591,7 @@ static int vmclock_probe(struct platform_device *pdev)
static const struct acpi_device_id vmclock_acpi_ids[] = {
{ "AMZNC10C", 0 },
+ { "VMCLOCK", 0 },
{}
};
MODULE_DEVICE_TABLE(acpi, vmclock_acpi_ids);
--
2.51.0
next prev parent reply other threads:[~2026-02-14 21:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260214212452.782265-1-sashal@kernel.org>
2026-02-14 21:22 ` [PATCH AUTOSEL 6.19-5.10] myri10ge: avoid uninitialized variable use Sasha Levin
2026-02-14 21:22 ` [PATCH AUTOSEL 6.19-6.1] net: mctp-i2c: fix duplicate reception of old data Sasha Levin
2026-02-14 21:22 ` [PATCH AUTOSEL 6.19-6.12] net: wwan: mhi: Add network support for Foxconn T99W760 Sasha Levin
2026-02-14 21:22 ` [PATCH AUTOSEL 6.19-5.10] net/rds: Clear reconnect pending bit Sasha Levin
2026-02-14 21:22 ` [PATCH AUTOSEL 6.19-6.12] ipv6: annotate data-races over sysctl.flowlabel_reflect Sasha Levin
2026-02-14 21:22 ` [PATCH AUTOSEL 6.19-5.15] ipv6: exthdrs: annotate data-race over multiple sysctl Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-5.10] octeontx2-af: Workaround SQM/PSE stalls by disabling sticky Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-5.10] vmw_vsock: bypass false-positive Wnonnull warning with gcc-16 Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-5.15] ipv6: annotate data-races in ip6_multipath_hash_{policy,fields}() Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-6.6] ipv4: igmp: annotate data-races around idev->mr_maxdelay Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-5.10] net/rds: No shortcut out of RDS_CONN_ERROR Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-6.18] ipv6: annotate data-races in net/ipv6/route.c Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-6.12] bnxt_en: Allow ntuple filters for drops Sasha Levin
2026-02-14 21:23 ` Sasha Levin [this message]
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-5.10] ipv4: fib: Annotate access to struct fib_alias.fa_state Sasha Levin
2026-02-14 21:23 ` [PATCH AUTOSEL 6.19-6.12] net: sfp: add quirk for Lantech 8330-265D Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260214212452.782265-79-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bchalios@amazon.es \
--cc=davem@davemloft.net \
--cc=dwmw2@infradead.org \
--cc=dwmw@amazon.co.uk \
--cc=edumazet@google.com \
--cc=itazur@amazon.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=patches@lists.linux.dev \
--cc=richardcochran@gmail.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox