From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20AA035A398 for ; Tue, 12 May 2026 23:29:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778628592; cv=none; b=lGSr2yvE3/hClhzpb3NmYH7pDFXg18worPGZ0E3V0lvWNUOO58r+uoNr25I2hA4H1ATbtXpXDRAEjpGyMaxOIccx6SmPGT5+GXBa1TAJIDJH2Pad/X0ioDJdntJGNhLrCccw5VREkJhtHc7hQH5vInZw9X6Mu/wGRo6+rCvnlrc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778628592; c=relaxed/simple; bh=UbHYA9GF4XxAF0tQu8MZ7ADSQ5JVALZSiUl2AVdrCi8=; h=From:Subject:To:Cc:In-Reply-To:References:Content-Type:Date: Message-Id; b=dtMLtSynhLzMjTmtHkaFyRTSIwQuLSxWXEkksZgh29m00GbG7iOjgCu64+wEoaL7tcVosGoyO9OUQd4vj6q6xiHKgFY62/YBunshSAJS/d+WY6wfD5QWYMyGB5/wiHaWmKI+9xKw5Okicz8DtrK5ar1SSrQM5GXtoRSSeH45Ujo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OB539B8r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OB539B8r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03398C4AF0B; Tue, 12 May 2026 23:29:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778628591; bh=UbHYA9GF4XxAF0tQu8MZ7ADSQ5JVALZSiUl2AVdrCi8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=OB539B8rLZzgSLh8knYFJhUJFUu07XvVlxg9AH3JbfYCza4YexsOBhrQ7AFhg7kJb CFr6ZOQZ+FBe56terU9SkeN2dyFUbA5HaJYUO9dGQwjqu23HGjovKlCeKdwf7YSKTa hmI7Uzy2jkIxMR9KtcdjgqZVyyKvCks7PCJpKjshQDo9Auvf312UUzM6ZeUwzR3uNZ yHPKPVjGz+qAhZjYKnz2CbOTmfZVLXPKWNbsJqePa+H6ZVElLNPY0T9v7oJaYo6XzX Fn7Yy7MfyAaJ9gis5ora15u0vvLeeywXWYIipGGjniMemNDrhqQBCOfxg+dy7c5K2a cTkTEw3p0F2zg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v1 4/6] net: usb: Add Infineon XMM6260 Baseband modem support Reply-To: sashiko-reviews@lists.linux.dev To: "Svyatoslav Ryhel" Cc: neil.armstrong@linaro.org, robh@kernel.org, linux-phy@lists.infradead.org, olteanv@gmail.com, krzk+dt@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org, conor+dt@kernel.org In-Reply-To: <20260511135703.62470-5-clamor95@gmail.com> References: <20260511135703.62470-5-clamor95@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 12 May 2026 23:29:50 +0000 Message-Id: <20260512232951.03398C4AF0B@smtp.kernel.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Thank you for your contribution! Sashiko AI review found 8 potential issue(= s) to consider: - [High] Type confusion and out-of-bounds read in USB notifier callback. - [High] Hardware teardown in `remove()` races with devres-managed IRQ and = delayed work. - [High] Missing synchronization for driver state variables across multiple= contexts. - [High] Delayed work bypasses intended timeout due to incorrect rescheduli= ng logic. - [High] Missing Kconfig dependency on RFKILL causes linker errors. - [Medium] Incorrect error handling for `rfkill_alloc` causes `probe()` to = succeed on memory allocation failure. - [Medium] Unbalanced PHY and regulator calls in `remove()` and `set_block(= )`. - [Medium] Missing USB disconnect handling stalls the modem's state machine. -- commit 0ae4ba7bc0acd1df4aeeb4a594adcd61b86ea4a4 Author: Svyatoslav Ryhel net: usb: Add Infineon XMM6260 Baseband modem support The Infineon/Intel XMM6260 is a 3G-focused, slim modem platform designed for smartphones, data cards, and Machine-to-Machine (M2M) applications. > diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig > index 52a5c0922c79f..503f24a3cfa69 100644 > --- a/drivers/net/usb/Kconfig > +++ b/drivers/net/usb/Kconfig [ ... ] > @@ -642,4 +642,19 @@ config USB_RTL8153_ECM > CONFIG_USB_RTL8152 is not set, or the RTL8153 device is not > supported by r8152 driver. > =20 > +config USB_NET_XMM6260 > + tristate "Infineon XMM626X Baseband HSPA/HSUPA modem" > + depends on GPIOLIB && OF && USB_CHIPIDEA Should this configuration also depend on RFKILL || RFKILL=3Dn? Since the driver calls exported RFKILL functions like rfkill_alloc and rfkill_register unconditionally, building this driver as built-in while RFKILL is built as a module might cause linker errors. > + help > + Select this if you want to use an Infineon XMM626X modem, found in [ ... ] > diff --git a/drivers/net/usb/baseband-xmm6260.c b/drivers/net/usb/baseban= d-xmm6260.c > new file mode 100644 > index 0000000000000..658f5351fab7e > --- /dev/null > +++ b/drivers/net/usb/baseband-xmm6260.c [ ... ] > +static int baseband_xmm_usb_notifier_call(struct notifier_block *nb, > + unsigned long action, void *data) > +{ > + struct baseband_xmm_data *priv =3D > + container_of(nb, struct baseband_xmm_data, nb); > + struct usb_device *udev =3D data; > + u16 product =3D le16_to_cpu(udev->descriptor.idProduct); > + u16 vendor =3D le16_to_cpu(udev->descriptor.idVendor); Does this safely handle all USB notifier events? The global usb_notifier_li= st broadcasts events for both devices and buses. For bus events (like USB_BUS_ADD), the data parameter is a struct usb_bus pointer. By unconditionally casting data to a struct usb_device pointer and dereferencing udev->descriptor.idProduct before checking the action switch, could this cause an out-of-bounds memory read when a bus event is received? > + > + switch (action) { > + case USB_DEVICE_ADD: > + /* Infineon XMM6260 ID 1519:0020 */ > + if (vendor =3D=3D BASEBAND_VENDOR_ID_COMNEON && > + product =3D=3D BASEBAND_PRODUCT_ID_XMM6260) { > + cancel_delayed_work_sync(&priv->modem_work); > + priv->inited =3D true; > + } > + break; > + } What happens if the USB device is removed? There doesn't appear to be a handler for USB_DEVICE_REMOVE. If the modem drops off the bus, priv->inited remains true and priv->ap_state stays stuck in IPC_AP_WAKE_INIT2. Will the interrupt handler ignore all subsequent wake attempts, leaving the modem unresponsive until the module is reloaded? > + > + return NOTIFY_OK; > +} [ ... ] > +static int baseband_xmm_set_block(void *data, bool blocked) > +{ > + struct baseband_xmm_data *priv =3D data; > + > + if (blocked) { > + if (priv->inited && priv->powered) { [ ... ] > + regulator_disable(priv->vbat_supply); > + > + priv->powered =3D false; > + priv->inited =3D false; > + } > + } else { > + if (priv->inited) > + return 0; > + > + priv->ap_state =3D IPC_AP_WAKE_IRQ_READY; > + baseband_xmm_reset(priv); If the RFKill switch is repeatedly toggled before the USB device enumerates, could this leak regulator enable counts indefinitely? When blocking the device, regulator_disable is only called if priv->inited is true. However, unblocking the device sets priv->inited to false and calls baseband_xmm_reset which calls regulator_enable unconditionally. > + > + priv->powered =3D false; > + priv->inited =3D false; > + } > + > + return 0; > +} [ ... ] > +static void baseband_xmm_work(struct work_struct *work) > +{ > + struct baseband_xmm_data *priv =3D > + container_of(work, struct baseband_xmm_data, modem_work.work); > + > + switch (priv->ap_state) { > + case IPC_AP_WAKE_INIT1: > + if (priv->powered) > + return; > + > + phy_power_on(priv->mphy); > + priv->powered =3D true; Is there any synchronization protecting these state variables (priv->powere= d, priv->inited, priv->ap_state)? They appear to be accessed and modified concurrently by the delayed workque= ue, the threaded IRQ handler, the RFKill callback, and the USB notifier without any locking. For example, could the RFKill callback and this delayed workqueue both see priv->powered as true and simultaneously execute phy_power_off, corrupting the PHY framework's internal power count? > + break; [ ... ] > +static irqreturn_t baseband_hostwake_interrupt(int irq, void *dev_id) > +{ > + struct baseband_xmm_data *priv =3D dev_id; > + int state =3D gpiod_get_value(priv->ipc_ap_gpio); > + > + switch (priv->ap_state) { > + case IPC_AP_WAKE_IRQ_READY: > + if (!state) { > + priv->ap_state =3D IPC_AP_WAKE_INIT1; > + schedule_delayed_work(&priv->modem_work, 0); > + } > + > + break; > + > + case IPC_AP_WAKE_INIT1: > + if (state) { > + priv->ap_state =3D IPC_AP_WAKE_INIT2; > + schedule_delayed_work(&priv->modem_work, > + msecs_to_jiffies(BASEBAND_XMM_INIT_DELAY)); Will this properly delay the work if it is already pending? If the work is already pending from the IPC_AP_WAKE_IRQ_READY state (which queued it with a 0 delay), schedule_delayed_work will return false and won't update the timer. The work would then execute immediately, observe IPC_AP_WAKE_INIT2, and shut down the PHY, bypassing the 5-second delay. Would mod_delayed_work be more appropriate here to update the timeout? > + } > + > + break; [ ... ] > +static int baseband_xmm_probe(struct platform_device *pdev) > +{ [ ... ] > + priv->rfkill_dev =3D rfkill_alloc("xmm-modem", dev, RFKILL_TYPE_WWAN, > + &baseband_xmm_rfkill_ops, priv); > + if (priv->rfkill_dev) { > + ret =3D rfkill_register(priv->rfkill_dev); > + if (ret < 0) { > + rfkill_destroy(priv->rfkill_dev); > + return dev_err_probe(dev, ret, > + "failed to register WWAN rfkill\n"); > + } > + } else { > + return dev_err_probe(dev, PTR_ERR(priv->rfkill_dev), > + "failed to allocate WWAN rfkill\n"); Does this error path correctly return a negative error code? Since rfkill_alloc returns NULL on allocation failure, PTR_ERR(NULL) evaluates to 0. This causes probe to succeed and return 0 instead of -ENOME= M. Could this leave the driver bound in a partially initialized state? > + } > + > + priv->nb.notifier_call =3D baseband_xmm_usb_notifier_call; > + usb_register_notify(&priv->nb); > + > + baseband_xmm_reset(priv); > + priv->powered =3D false; > + > + return 0; > +} > + > +static void baseband_xmm_remove(struct platform_device *pdev) > +{ > + struct baseband_xmm_data *priv =3D platform_get_drvdata(pdev); > + > + rfkill_unregister(priv->rfkill_dev); > + rfkill_destroy(priv->rfkill_dev); > + > + usb_unregister_notify(&priv->nb); > + phy_power_off(priv->mphy); > + > + gpiod_set_value_cansleep(priv->reset_gpio, 1); > + regulator_disable(priv->vbat_supply); Does this removal sequence race with the devres-managed IRQ and workqueue? The threaded IRQ and delayed workqueue were allocated with devm_request_threaded_irq and devm_delayed_work_autocancel, so they are only canceled after baseband_xmm_remove returns. If the IRQ fires or the workqueue executes concurrently with or just after this function, could they interact with the powered-off hardware or call phy_power_on after the PHY is already disabled here? Also, are these teardown calls always balanced? If the device was already blocked via RFKill, or if the initialization workqueue never ran to power on the PHY and regulator, unconditionally calling phy_power_off and regulator_disable here might trigger negative reference count warnings in their respective frameworks. > +} --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260511135703.6247= 0-1-clamor95@gmail.com?part=3D4 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AFBFECD4F24 for ; Tue, 12 May 2026 23:29:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: References:In-Reply-To:Cc:To:Subject:From:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=xCel83ln33nxtMG3ggY5QLmvR1PnJ1EpyKtHA7WBKUw=; b=ofuqcYWAwBe3X3 f4HwH/Lvc/eTi+P3V9+B0yeJQv6bfxefZLBjmcsHhkv4m9T36hBAlVCXQighW0vg+a+HCpCTPVX2r mTMAYb/kENjyj5d1kyNh7NN3wm6Y7dT3pwTd6Q4GDpA9XiHzTmQjb7SA8DAIngRhlF9/hAxkETSdg R6rDDmRf8r1/uC8yAYp7shfPqviWFXRCD4LznG22Z9P96RXR8I22wxOChCdIGNxMYqmCaoiSIYmnm sBp6yiHOZ7OyMlgIFJ1CNwDDQ3l25dUnhsVYuvqJNIgdRE0vUyL9IbvLY2yJTlEhegYo1kl2x0Zy9 EPjWYe/V9rrNiF0j4qig==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wMwXy-00000000hGQ-1wwI; Tue, 12 May 2026 23:29:54 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wMwXw-00000000hEa-0Uqk for linux-phy@lists.infradead.org; Tue, 12 May 2026 23:29:53 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 8A7AA44045; Tue, 12 May 2026 23:29:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 03398C4AF0B; Tue, 12 May 2026 23:29:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778628591; bh=UbHYA9GF4XxAF0tQu8MZ7ADSQ5JVALZSiUl2AVdrCi8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date:From; b=OB539B8rLZzgSLh8knYFJhUJFUu07XvVlxg9AH3JbfYCza4YexsOBhrQ7AFhg7kJb CFr6ZOQZ+FBe56terU9SkeN2dyFUbA5HaJYUO9dGQwjqu23HGjovKlCeKdwf7YSKTa hmI7Uzy2jkIxMR9KtcdjgqZVyyKvCks7PCJpKjshQDo9Auvf312UUzM6ZeUwzR3uNZ yHPKPVjGz+qAhZjYKnz2CbOTmfZVLXPKWNbsJqePa+H6ZVElLNPY0T9v7oJaYo6XzX Fn7Yy7MfyAaJ9gis5ora15u0vvLeeywXWYIipGGjniMemNDrhqQBCOfxg+dy7c5K2a cTkTEw3p0F2zg== From: sashiko-bot@kernel.org Subject: Re: [PATCH v1 4/6] net: usb: Add Infineon XMM6260 Baseband modem support To: "Svyatoslav Ryhel" Cc: neil.armstrong@linaro.org, robh@kernel.org, linux-phy@lists.infradead.org, olteanv@gmail.com, krzk+dt@kernel.org, devicetree@vger.kernel.org, vkoul@kernel.org, conor+dt@kernel.org In-Reply-To: <20260511135703.62470-5-clamor95@gmail.com> References: <20260511135703.62470-5-clamor95@gmail.com> Date: Tue, 12 May 2026 23:29:50 +0000 Message-Id: <20260512232951.03398C4AF0B@smtp.kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260512_162952_206232_1C1310D6 X-CRM114-Status: GOOD ( 30.65 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg OCBwb3RlbnRpYWwgaXNzdWUocykgdG8gY29uc2lkZXI6Ci0gW0hpZ2hdIFR5cGUgY29uZnVzaW9u IGFuZCBvdXQtb2YtYm91bmRzIHJlYWQgaW4gVVNCIG5vdGlmaWVyIGNhbGxiYWNrLgotIFtIaWdo XSBIYXJkd2FyZSB0ZWFyZG93biBpbiBgcmVtb3ZlKClgIHJhY2VzIHdpdGggZGV2cmVzLW1hbmFn ZWQgSVJRIGFuZCBkZWxheWVkIHdvcmsuCi0gW0hpZ2hdIE1pc3Npbmcgc3luY2hyb25pemF0aW9u IGZvciBkcml2ZXIgc3RhdGUgdmFyaWFibGVzIGFjcm9zcyBtdWx0aXBsZSBjb250ZXh0cy4KLSBb SGlnaF0gRGVsYXllZCB3b3JrIGJ5cGFzc2VzIGludGVuZGVkIHRpbWVvdXQgZHVlIHRvIGluY29y cmVjdCByZXNjaGVkdWxpbmcgbG9naWMuCi0gW0hpZ2hdIE1pc3NpbmcgS2NvbmZpZyBkZXBlbmRl bmN5IG9uIFJGS0lMTCBjYXVzZXMgbGlua2VyIGVycm9ycy4KLSBbTWVkaXVtXSBJbmNvcnJlY3Qg ZXJyb3IgaGFuZGxpbmcgZm9yIGByZmtpbGxfYWxsb2NgIGNhdXNlcyBgcHJvYmUoKWAgdG8gc3Vj Y2VlZCBvbiBtZW1vcnkgYWxsb2NhdGlvbiBmYWlsdXJlLgotIFtNZWRpdW1dIFVuYmFsYW5jZWQg UEhZIGFuZCByZWd1bGF0b3IgY2FsbHMgaW4gYHJlbW92ZSgpYCBhbmQgYHNldF9ibG9jaygpYC4K LSBbTWVkaXVtXSBNaXNzaW5nIFVTQiBkaXNjb25uZWN0IGhhbmRsaW5nIHN0YWxscyB0aGUgbW9k ZW0ncyBzdGF0ZSBtYWNoaW5lLgotLQoKY29tbWl0IDBhZTRiYTdiYzBhY2QxZGY0YWVlYjRhNTk0 YWRjZDYxYjg2ZWE0YTQKQXV0aG9yOiBTdnlhdG9zbGF2IFJ5aGVsIDxjbGFtb3I5NUBnbWFpbC5j b20+CgpuZXQ6IHVzYjogQWRkIEluZmluZW9uIFhNTTYyNjAgQmFzZWJhbmQgbW9kZW0gc3VwcG9y dAoKVGhlIEluZmluZW9uL0ludGVsIFhNTTYyNjAgaXMgYSAzRy1mb2N1c2VkLCBzbGltIG1vZGVt IHBsYXRmb3JtIGRlc2lnbmVkCmZvciBzbWFydHBob25lcywgZGF0YSBjYXJkcywgYW5kIE1hY2hp bmUtdG8tTWFjaGluZSAoTTJNKSBhcHBsaWNhdGlvbnMuCgo+IGRpZmYgLS1naXQgYS9kcml2ZXJz L25ldC91c2IvS2NvbmZpZyBiL2RyaXZlcnMvbmV0L3VzYi9LY29uZmlnCj4gaW5kZXggNTJhNWMw OTIyYzc5Zi4uNTAzZjI0YTNjZmE2OSAxMDA2NDQKPiAtLS0gYS9kcml2ZXJzL25ldC91c2IvS2Nv bmZpZwo+ICsrKyBiL2RyaXZlcnMvbmV0L3VzYi9LY29uZmlnClsgLi4uIF0KPiBAQCAtNjQyLDQg KzY0MiwxOSBAQCBjb25maWcgVVNCX1JUTDgxNTNfRUNNCj4gIAkgIENPTkZJR19VU0JfUlRMODE1 MiBpcyBub3Qgc2V0LCBvciB0aGUgUlRMODE1MyBkZXZpY2UgaXMgbm90Cj4gIAkgIHN1cHBvcnRl ZCBieSByODE1MiBkcml2ZXIuCj4gIAo+ICtjb25maWcgVVNCX05FVF9YTU02MjYwCj4gKwl0cmlz dGF0ZSAiSW5maW5lb24gWE1NNjI2WCBCYXNlYmFuZCBIU1BBL0hTVVBBIG1vZGVtIgo+ICsJZGVw ZW5kcyBvbiBHUElPTElCICYmIE9GICYmIFVTQl9DSElQSURFQQoKU2hvdWxkIHRoaXMgY29uZmln dXJhdGlvbiBhbHNvIGRlcGVuZCBvbiBSRktJTEwgfHwgUkZLSUxMPW4/CgpTaW5jZSB0aGUgZHJp dmVyIGNhbGxzIGV4cG9ydGVkIFJGS0lMTCBmdW5jdGlvbnMgbGlrZSByZmtpbGxfYWxsb2MgYW5k CnJma2lsbF9yZWdpc3RlciB1bmNvbmRpdGlvbmFsbHksIGJ1aWxkaW5nIHRoaXMgZHJpdmVyIGFz IGJ1aWx0LWluIHdoaWxlClJGS0lMTCBpcyBidWlsdCBhcyBhIG1vZHVsZSBtaWdodCBjYXVzZSBs aW5rZXIgZXJyb3JzLgoKPiArCWhlbHAKPiArCSAgU2VsZWN0IHRoaXMgaWYgeW91IHdhbnQgdG8g dXNlIGFuIEluZmluZW9uIFhNTTYyNlggbW9kZW0sIGZvdW5kIGluClsgLi4uIF0KPiBkaWZmIC0t Z2l0IGEvZHJpdmVycy9uZXQvdXNiL2Jhc2ViYW5kLXhtbTYyNjAuYyBiL2RyaXZlcnMvbmV0L3Vz Yi9iYXNlYmFuZC14bW02MjYwLmMKPiBuZXcgZmlsZSBtb2RlIDEwMDY0NAo+IGluZGV4IDAwMDAw MDAwMDAwMDAuLjY1OGY1MzUxZmFiN2UKPiAtLS0gL2Rldi9udWxsCj4gKysrIGIvZHJpdmVycy9u ZXQvdXNiL2Jhc2ViYW5kLXhtbTYyNjAuYwpbIC4uLiBdCj4gK3N0YXRpYyBpbnQgYmFzZWJhbmRf eG1tX3VzYl9ub3RpZmllcl9jYWxsKHN0cnVjdCBub3RpZmllcl9ibG9jayAqbmIsCj4gKwkJCQkJ ICB1bnNpZ25lZCBsb25nIGFjdGlvbiwgdm9pZCAqZGF0YSkKPiArewo+ICsJc3RydWN0IGJhc2Vi YW5kX3htbV9kYXRhICpwcml2ID0KPiArCQljb250YWluZXJfb2YobmIsIHN0cnVjdCBiYXNlYmFu ZF94bW1fZGF0YSwgbmIpOwo+ICsJc3RydWN0IHVzYl9kZXZpY2UgKnVkZXYgPSBkYXRhOwo+ICsJ dTE2IHByb2R1Y3QgPSBsZTE2X3RvX2NwdSh1ZGV2LT5kZXNjcmlwdG9yLmlkUHJvZHVjdCk7Cj4g Kwl1MTYgdmVuZG9yID0gbGUxNl90b19jcHUodWRldi0+ZGVzY3JpcHRvci5pZFZlbmRvcik7CgpE b2VzIHRoaXMgc2FmZWx5IGhhbmRsZSBhbGwgVVNCIG5vdGlmaWVyIGV2ZW50cz8gVGhlIGdsb2Jh bCB1c2Jfbm90aWZpZXJfbGlzdApicm9hZGNhc3RzIGV2ZW50cyBmb3IgYm90aCBkZXZpY2VzIGFu ZCBidXNlcy4gRm9yIGJ1cyBldmVudHMgKGxpa2UKVVNCX0JVU19BREQpLCB0aGUgZGF0YSBwYXJh bWV0ZXIgaXMgYSBzdHJ1Y3QgdXNiX2J1cyBwb2ludGVyLgoKQnkgdW5jb25kaXRpb25hbGx5IGNh c3RpbmcgZGF0YSB0byBhIHN0cnVjdCB1c2JfZGV2aWNlIHBvaW50ZXIgYW5kCmRlcmVmZXJlbmNp bmcgdWRldi0+ZGVzY3JpcHRvci5pZFByb2R1Y3QgYmVmb3JlIGNoZWNraW5nIHRoZSBhY3Rpb24g c3dpdGNoLApjb3VsZCB0aGlzIGNhdXNlIGFuIG91dC1vZi1ib3VuZHMgbWVtb3J5IHJlYWQgd2hl biBhIGJ1cyBldmVudCBpcyByZWNlaXZlZD8KCj4gKwo+ICsJc3dpdGNoIChhY3Rpb24pIHsKPiAr CWNhc2UgVVNCX0RFVklDRV9BREQ6Cj4gKwkJLyogSW5maW5lb24gWE1NNjI2MCBJRCAxNTE5OjAw MjAgKi8KPiArCQlpZiAodmVuZG9yID09IEJBU0VCQU5EX1ZFTkRPUl9JRF9DT01ORU9OICYmCj4g KwkJICAgIHByb2R1Y3QgPT0gQkFTRUJBTkRfUFJPRFVDVF9JRF9YTU02MjYwKSB7Cj4gKwkJCWNh bmNlbF9kZWxheWVkX3dvcmtfc3luYygmcHJpdi0+bW9kZW1fd29yayk7Cj4gKwkJCXByaXYtPmlu aXRlZCA9IHRydWU7Cj4gKwkJfQo+ICsJCWJyZWFrOwo+ICsJfQoKV2hhdCBoYXBwZW5zIGlmIHRo ZSBVU0IgZGV2aWNlIGlzIHJlbW92ZWQ/CgpUaGVyZSBkb2Vzbid0IGFwcGVhciB0byBiZSBhIGhh bmRsZXIgZm9yIFVTQl9ERVZJQ0VfUkVNT1ZFLiBJZiB0aGUgbW9kZW0KZHJvcHMgb2ZmIHRoZSBi dXMsIHByaXYtPmluaXRlZCByZW1haW5zIHRydWUgYW5kIHByaXYtPmFwX3N0YXRlIHN0YXlzIHN0 dWNrCmluIElQQ19BUF9XQUtFX0lOSVQyLgoKV2lsbCB0aGUgaW50ZXJydXB0IGhhbmRsZXIgaWdu b3JlIGFsbCBzdWJzZXF1ZW50IHdha2UgYXR0ZW1wdHMsIGxlYXZpbmcgdGhlCm1vZGVtIHVucmVz cG9uc2l2ZSB1bnRpbCB0aGUgbW9kdWxlIGlzIHJlbG9hZGVkPwoKPiArCj4gKwlyZXR1cm4gTk9U SUZZX09LOwo+ICt9ClsgLi4uIF0KPiArc3RhdGljIGludCBiYXNlYmFuZF94bW1fc2V0X2Jsb2Nr KHZvaWQgKmRhdGEsIGJvb2wgYmxvY2tlZCkKPiArewo+ICsJc3RydWN0IGJhc2ViYW5kX3htbV9k YXRhICpwcml2ID0gZGF0YTsKPiArCj4gKwlpZiAoYmxvY2tlZCkgewo+ICsJCWlmIChwcml2LT5p bml0ZWQgJiYgcHJpdi0+cG93ZXJlZCkgewpbIC4uLiBdCj4gKwkJCXJlZ3VsYXRvcl9kaXNhYmxl KHByaXYtPnZiYXRfc3VwcGx5KTsKPiArCj4gKwkJCXByaXYtPnBvd2VyZWQgPSBmYWxzZTsKPiAr CQkJcHJpdi0+aW5pdGVkID0gZmFsc2U7Cj4gKwkJfQo+ICsJfSBlbHNlIHsKPiArCQlpZiAocHJp di0+aW5pdGVkKQo+ICsJCQlyZXR1cm4gMDsKPiArCj4gKwkJcHJpdi0+YXBfc3RhdGUgPSBJUENf QVBfV0FLRV9JUlFfUkVBRFk7Cj4gKwkJYmFzZWJhbmRfeG1tX3Jlc2V0KHByaXYpOwoKSWYgdGhl IFJGS2lsbCBzd2l0Y2ggaXMgcmVwZWF0ZWRseSB0b2dnbGVkIGJlZm9yZSB0aGUgVVNCIGRldmlj ZSBlbnVtZXJhdGVzLApjb3VsZCB0aGlzIGxlYWsgcmVndWxhdG9yIGVuYWJsZSBjb3VudHMgaW5k ZWZpbml0ZWx5PwoKV2hlbiBibG9ja2luZyB0aGUgZGV2aWNlLCByZWd1bGF0b3JfZGlzYWJsZSBp cyBvbmx5IGNhbGxlZCBpZiBwcml2LT5pbml0ZWQKaXMgdHJ1ZS4gSG93ZXZlciwgdW5ibG9ja2lu ZyB0aGUgZGV2aWNlIHNldHMgcHJpdi0+aW5pdGVkIHRvIGZhbHNlIGFuZCBjYWxscwpiYXNlYmFu ZF94bW1fcmVzZXQgd2hpY2ggY2FsbHMgcmVndWxhdG9yX2VuYWJsZSB1bmNvbmRpdGlvbmFsbHku Cgo+ICsKPiArCQlwcml2LT5wb3dlcmVkID0gZmFsc2U7Cj4gKwkJcHJpdi0+aW5pdGVkID0gZmFs c2U7Cj4gKwl9Cj4gKwo+ICsJcmV0dXJuIDA7Cj4gK30KWyAuLi4gXQo+ICtzdGF0aWMgdm9pZCBi YXNlYmFuZF94bW1fd29yayhzdHJ1Y3Qgd29ya19zdHJ1Y3QgKndvcmspCj4gK3sKPiArCXN0cnVj dCBiYXNlYmFuZF94bW1fZGF0YSAqcHJpdiA9Cj4gKwkJY29udGFpbmVyX29mKHdvcmssIHN0cnVj dCBiYXNlYmFuZF94bW1fZGF0YSwgbW9kZW1fd29yay53b3JrKTsKPiArCj4gKwlzd2l0Y2ggKHBy aXYtPmFwX3N0YXRlKSB7Cj4gKwljYXNlIElQQ19BUF9XQUtFX0lOSVQxOgo+ICsJCWlmIChwcml2 LT5wb3dlcmVkKQo+ICsJCQlyZXR1cm47Cj4gKwo+ICsJCXBoeV9wb3dlcl9vbihwcml2LT5tcGh5 KTsKPiArCQlwcml2LT5wb3dlcmVkID0gdHJ1ZTsKCklzIHRoZXJlIGFueSBzeW5jaHJvbml6YXRp b24gcHJvdGVjdGluZyB0aGVzZSBzdGF0ZSB2YXJpYWJsZXMgKHByaXYtPnBvd2VyZWQsCnByaXYt PmluaXRlZCwgcHJpdi0+YXBfc3RhdGUpPwoKVGhleSBhcHBlYXIgdG8gYmUgYWNjZXNzZWQgYW5k IG1vZGlmaWVkIGNvbmN1cnJlbnRseSBieSB0aGUgZGVsYXllZCB3b3JrcXVldWUsCnRoZSB0aHJl YWRlZCBJUlEgaGFuZGxlciwgdGhlIFJGS2lsbCBjYWxsYmFjaywgYW5kIHRoZSBVU0Igbm90aWZp ZXIgd2l0aG91dAphbnkgbG9ja2luZy4KCkZvciBleGFtcGxlLCBjb3VsZCB0aGUgUkZLaWxsIGNh bGxiYWNrIGFuZCB0aGlzIGRlbGF5ZWQgd29ya3F1ZXVlIGJvdGggc2VlCnByaXYtPnBvd2VyZWQg YXMgdHJ1ZSBhbmQgc2ltdWx0YW5lb3VzbHkgZXhlY3V0ZSBwaHlfcG93ZXJfb2ZmLCBjb3JydXB0 aW5nCnRoZSBQSFkgZnJhbWV3b3JrJ3MgaW50ZXJuYWwgcG93ZXIgY291bnQ/Cgo+ICsJCWJyZWFr OwpbIC4uLiBdCj4gK3N0YXRpYyBpcnFyZXR1cm5fdCBiYXNlYmFuZF9ob3N0d2FrZV9pbnRlcnJ1 cHQoaW50IGlycSwgdm9pZCAqZGV2X2lkKQo+ICt7Cj4gKwlzdHJ1Y3QgYmFzZWJhbmRfeG1tX2Rh dGEgKnByaXYgPSBkZXZfaWQ7Cj4gKwlpbnQgc3RhdGUgPSBncGlvZF9nZXRfdmFsdWUocHJpdi0+ aXBjX2FwX2dwaW8pOwo+ICsKPiArCXN3aXRjaCAocHJpdi0+YXBfc3RhdGUpIHsKPiArCWNhc2Ug SVBDX0FQX1dBS0VfSVJRX1JFQURZOgo+ICsJCWlmICghc3RhdGUpIHsKPiArCQkJcHJpdi0+YXBf c3RhdGUgPSBJUENfQVBfV0FLRV9JTklUMTsKPiArCQkJc2NoZWR1bGVfZGVsYXllZF93b3JrKCZw cml2LT5tb2RlbV93b3JrLCAwKTsKPiArCQl9Cj4gKwo+ICsJCWJyZWFrOwo+ICsKPiArCWNhc2Ug SVBDX0FQX1dBS0VfSU5JVDE6Cj4gKwkJaWYgKHN0YXRlKSB7Cj4gKwkJCXByaXYtPmFwX3N0YXRl ID0gSVBDX0FQX1dBS0VfSU5JVDI7Cj4gKwkJCXNjaGVkdWxlX2RlbGF5ZWRfd29yaygmcHJpdi0+ bW9kZW1fd29yaywKPiArCQkJCQkgICAgICBtc2Vjc190b19qaWZmaWVzKEJBU0VCQU5EX1hNTV9J TklUX0RFTEFZKSk7CgpXaWxsIHRoaXMgcHJvcGVybHkgZGVsYXkgdGhlIHdvcmsgaWYgaXQgaXMg YWxyZWFkeSBwZW5kaW5nPwoKSWYgdGhlIHdvcmsgaXMgYWxyZWFkeSBwZW5kaW5nIGZyb20gdGhl IElQQ19BUF9XQUtFX0lSUV9SRUFEWSBzdGF0ZSAod2hpY2gKcXVldWVkIGl0IHdpdGggYSAwIGRl bGF5KSwgc2NoZWR1bGVfZGVsYXllZF93b3JrIHdpbGwgcmV0dXJuIGZhbHNlIGFuZCB3b24ndAp1 cGRhdGUgdGhlIHRpbWVyLiBUaGUgd29yayB3b3VsZCB0aGVuIGV4ZWN1dGUgaW1tZWRpYXRlbHks IG9ic2VydmUKSVBDX0FQX1dBS0VfSU5JVDIsIGFuZCBzaHV0IGRvd24gdGhlIFBIWSwgYnlwYXNz aW5nIHRoZSA1LXNlY29uZCBkZWxheS4KCldvdWxkIG1vZF9kZWxheWVkX3dvcmsgYmUgbW9yZSBh cHByb3ByaWF0ZSBoZXJlIHRvIHVwZGF0ZSB0aGUgdGltZW91dD8KCj4gKwkJfQo+ICsKPiArCQli cmVhazsKWyAuLi4gXQo+ICtzdGF0aWMgaW50IGJhc2ViYW5kX3htbV9wcm9iZShzdHJ1Y3QgcGxh dGZvcm1fZGV2aWNlICpwZGV2KQo+ICt7ClsgLi4uIF0KPiArCXByaXYtPnJma2lsbF9kZXYgPSBy ZmtpbGxfYWxsb2MoInhtbS1tb2RlbSIsIGRldiwgUkZLSUxMX1RZUEVfV1dBTiwKPiArCQkJCQkm YmFzZWJhbmRfeG1tX3Jma2lsbF9vcHMsIHByaXYpOwo+ICsJaWYgKHByaXYtPnJma2lsbF9kZXYp IHsKPiArCQlyZXQgPSByZmtpbGxfcmVnaXN0ZXIocHJpdi0+cmZraWxsX2Rldik7Cj4gKwkJaWYg KHJldCA8IDApIHsKPiArCQkJcmZraWxsX2Rlc3Ryb3kocHJpdi0+cmZraWxsX2Rldik7Cj4gKwkJ CXJldHVybiBkZXZfZXJyX3Byb2JlKGRldiwgcmV0LAo+ICsJCQkJCSAgICAgImZhaWxlZCB0byBy ZWdpc3RlciBXV0FOIHJma2lsbFxuIik7Cj4gKwkJfQo+ICsJfSBlbHNlIHsKPiArCQlyZXR1cm4g ZGV2X2Vycl9wcm9iZShkZXYsIFBUUl9FUlIocHJpdi0+cmZraWxsX2RldiksCj4gKwkJCQkgICAg ICJmYWlsZWQgdG8gYWxsb2NhdGUgV1dBTiByZmtpbGxcbiIpOwoKRG9lcyB0aGlzIGVycm9yIHBh dGggY29ycmVjdGx5IHJldHVybiBhIG5lZ2F0aXZlIGVycm9yIGNvZGU/CgpTaW5jZSByZmtpbGxf YWxsb2MgcmV0dXJucyBOVUxMIG9uIGFsbG9jYXRpb24gZmFpbHVyZSwgUFRSX0VSUihOVUxMKQpl dmFsdWF0ZXMgdG8gMC4gVGhpcyBjYXVzZXMgcHJvYmUgdG8gc3VjY2VlZCBhbmQgcmV0dXJuIDAg aW5zdGVhZCBvZiAtRU5PTUVNLgpDb3VsZCB0aGlzIGxlYXZlIHRoZSBkcml2ZXIgYm91bmQgaW4g YSBwYXJ0aWFsbHkgaW5pdGlhbGl6ZWQgc3RhdGU/Cgo+ICsJfQo+ICsKPiArCXByaXYtPm5iLm5v dGlmaWVyX2NhbGwgPSBiYXNlYmFuZF94bW1fdXNiX25vdGlmaWVyX2NhbGw7Cj4gKwl1c2JfcmVn aXN0ZXJfbm90aWZ5KCZwcml2LT5uYik7Cj4gKwo+ICsJYmFzZWJhbmRfeG1tX3Jlc2V0KHByaXYp Owo+ICsJcHJpdi0+cG93ZXJlZCA9IGZhbHNlOwo+ICsKPiArCXJldHVybiAwOwo+ICt9Cj4gKwo+ ICtzdGF0aWMgdm9pZCBiYXNlYmFuZF94bW1fcmVtb3ZlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2Ug KnBkZXYpCj4gK3sKPiArCXN0cnVjdCBiYXNlYmFuZF94bW1fZGF0YSAqcHJpdiA9IHBsYXRmb3Jt X2dldF9kcnZkYXRhKHBkZXYpOwo+ICsKPiArCXJma2lsbF91bnJlZ2lzdGVyKHByaXYtPnJma2ls bF9kZXYpOwo+ICsJcmZraWxsX2Rlc3Ryb3kocHJpdi0+cmZraWxsX2Rldik7Cj4gKwo+ICsJdXNi X3VucmVnaXN0ZXJfbm90aWZ5KCZwcml2LT5uYik7Cj4gKwlwaHlfcG93ZXJfb2ZmKHByaXYtPm1w aHkpOwo+ICsKPiArCWdwaW9kX3NldF92YWx1ZV9jYW5zbGVlcChwcml2LT5yZXNldF9ncGlvLCAx KTsKPiArCXJlZ3VsYXRvcl9kaXNhYmxlKHByaXYtPnZiYXRfc3VwcGx5KTsKCkRvZXMgdGhpcyBy ZW1vdmFsIHNlcXVlbmNlIHJhY2Ugd2l0aCB0aGUgZGV2cmVzLW1hbmFnZWQgSVJRIGFuZCB3b3Jr cXVldWU/CgpUaGUgdGhyZWFkZWQgSVJRIGFuZCBkZWxheWVkIHdvcmtxdWV1ZSB3ZXJlIGFsbG9j YXRlZCB3aXRoCmRldm1fcmVxdWVzdF90aHJlYWRlZF9pcnEgYW5kIGRldm1fZGVsYXllZF93b3Jr X2F1dG9jYW5jZWwsIHNvIHRoZXkgYXJlIG9ubHkKY2FuY2VsZWQgYWZ0ZXIgYmFzZWJhbmRfeG1t X3JlbW92ZSByZXR1cm5zLgoKSWYgdGhlIElSUSBmaXJlcyBvciB0aGUgd29ya3F1ZXVlIGV4ZWN1 dGVzIGNvbmN1cnJlbnRseSB3aXRoIG9yIGp1c3QgYWZ0ZXIKdGhpcyBmdW5jdGlvbiwgY291bGQg dGhleSBpbnRlcmFjdCB3aXRoIHRoZSBwb3dlcmVkLW9mZiBoYXJkd2FyZSBvciBjYWxsCnBoeV9w b3dlcl9vbiBhZnRlciB0aGUgUEhZIGlzIGFscmVhZHkgZGlzYWJsZWQgaGVyZT8KCkFsc28sIGFy ZSB0aGVzZSB0ZWFyZG93biBjYWxscyBhbHdheXMgYmFsYW5jZWQ/CgpJZiB0aGUgZGV2aWNlIHdh cyBhbHJlYWR5IGJsb2NrZWQgdmlhIFJGS2lsbCwgb3IgaWYgdGhlIGluaXRpYWxpemF0aW9uCndv cmtxdWV1ZSBuZXZlciByYW4gdG8gcG93ZXIgb24gdGhlIFBIWSBhbmQgcmVndWxhdG9yLCB1bmNv bmRpdGlvbmFsbHkKY2FsbGluZyBwaHlfcG93ZXJfb2ZmIGFuZCByZWd1bGF0b3JfZGlzYWJsZSBo ZXJlIG1pZ2h0IHRyaWdnZXIgbmVnYXRpdmUKcmVmZXJlbmNlIGNvdW50IHdhcm5pbmdzIGluIHRo ZWlyIHJlc3BlY3RpdmUgZnJhbWV3b3Jrcy4KCj4gK30KCi0tIApTYXNoaWtvIEFJIHJldmlldyDC tyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjA1MTExMzU3MDMuNjI0NzAtMS1j bGFtb3I5NUBnbWFpbC5jb20/cGFydD00CgotLSAKbGludXgtcGh5IG1haWxpbmcgbGlzdApsaW51 eC1waHlAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwczovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFp bG1hbi9saXN0aW5mby9saW51eC1waHkK