September 2024 - Linux-stable-mirror

FAILED: patch "[PATCH] usb: dwc3: Avoid waking up gadget during startxfer" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 00dcf2fa449f23a263343d7fe051741bdde65d0b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090924-crescent-edging-00be@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: 00dcf2fa449f ("usb: dwc3: Avoid waking up gadget during startxfer") 047161686b81 ("usb: dwc3: Add remote wakeup handling") a02a26eb0aea ("usb: dwc3: gadget: Ignore Update Transfer cmd params") 63c4c320ccf7 ("usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer") 40edb52298df ("usb: dwc3: avoid NULL access of usb_gadget_driver") c560e76319a9 ("usb: dwc3: gadget: Fix START_TRANSFER link state check") 475e8be53d04 ("usb: dwc3: gadget: Check for disabled LPM quirk") 82c46b8ed9dc ("usb: dwc3: gadget: Introduce a DWC3 VBUS draw callback") f580170f135a ("usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc") e81a7018d93a ("usb: dwc3: allocate gadget structure dynamically") c5a7092f4015 ("usb: dwc3: gadget: make starting isoc transfers more robust") 9af21dd6faeb ("usb: dwc3: Add support for DWC_usb32 IP") 8bb14308a869 ("usb: dwc3: core: Use role-switch default dr_mode") d0550cd20e52 ("usb: dwc3: gadget: Do link recovery for SS and SSP") d94ea5319813 ("usb: dwc3: gadget: Properly set maxpacket limit") 586f4335700f ("usb: dwc3: Fix GTXFIFOSIZ.TXFDEP macro name") 5eb5afb07853 ("usb: dwc3: use proper initializers for property entries") 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 00dcf2fa449f23a263343d7fe051741bdde65d0b Mon Sep 17 00:00:00 2001 From: Prashanth K <quic_prashk(a)quicinc.com> Date: Wed, 28 Aug 2024 12:13:02 +0530 Subject: [PATCH] usb: dwc3: Avoid waking up gadget during startxfer When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't update link state immediately after receiving the wakeup interrupt. Since wakeup event handler calls the resume callbacks, there is a chance that function drivers can perform an ep queue, which in turn tries to perform remote wakeup from send_gadget_ep_cmd(STARTXFER). This happens because DSTS[[21:18] wasn't updated to U0 yet, it's observed that the latency of DSTS can be in order of milli-seconds. Hence avoid calling gadget_wakeup during startxfer to prevent unnecessarily issuing remote wakeup to host. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: stable(a)vger.kernel.org Suggested-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/20240828064302.3796315-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..291bc549935b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -287,6 +287,23 @@ static int __dwc3_gadget_wakeup(struct dwc3 *dwc, bool async); * * Caller should handle locking. This function will issue @cmd with given * @params to @dep and wait for its completion. + * + * According to the programming guide, if the link state is in L1/L2/U3, + * then sending the Start Transfer command may not complete. The + * programming guide suggested to bring the link state back to ON/U0 by + * performing remote wakeup prior to sending the command. However, don't + * initiate remote wakeup when the user/function does not send wakeup + * request via wakeup ops. Send the command when it's allowed. + * + * Notes: + * For L1 link state, issuing a command requires the clearing of + * GUSB2PHYCFG.SUSPENDUSB2, which turns on the signal required to complete + * the given command (usually within 50us). This should happen within the + * command timeout set by driver. No additional step is needed. + * + * For L2 or U3 link state, the gadget is in USB suspend. Care should be + * taken when sending Start Transfer command to ensure that it's done after + * USB resume. */ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, struct dwc3_gadget_ep_cmd_params *params) @@ -327,30 +344,6 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); } - if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) { - int link_state; - - /* - * Initiate remote wakeup if the link state is in U3 when - * operating in SS/SSP or L1/L2 when operating in HS/FS. If the - * link state is in U1/U2, no remote wakeup is needed. The Start - * Transfer command will initiate the link recovery. - */ - link_state = dwc3_gadget_get_link_state(dwc); - switch (link_state) { - case DWC3_LINK_STATE_U2: - if (dwc->gadget->speed >= USB_SPEED_SUPER) - break; - - fallthrough; - case DWC3_LINK_STATE_U3: - ret = __dwc3_gadget_wakeup(dwc, false); - dev_WARN_ONCE(dwc->dev, ret, "wakeup failed --> %d\n", - ret); - break; - } - } - /* * For some commands such as Update Transfer command, DEPCMDPARn * registers are reserved. Since the driver often sends Update Transfer

1 week, 4 days

1
0
0 0

FAILED: patch "[PATCH] usb: dwc3: Avoid waking up gadget during startxfer" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 00dcf2fa449f23a263343d7fe051741bdde65d0b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090923-trustful-helium-3f09@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 00dcf2fa449f ("usb: dwc3: Avoid waking up gadget during startxfer") 047161686b81 ("usb: dwc3: Add remote wakeup handling") a02a26eb0aea ("usb: dwc3: gadget: Ignore Update Transfer cmd params") 63c4c320ccf7 ("usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer") 40edb52298df ("usb: dwc3: avoid NULL access of usb_gadget_driver") c560e76319a9 ("usb: dwc3: gadget: Fix START_TRANSFER link state check") 475e8be53d04 ("usb: dwc3: gadget: Check for disabled LPM quirk") 82c46b8ed9dc ("usb: dwc3: gadget: Introduce a DWC3 VBUS draw callback") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 00dcf2fa449f23a263343d7fe051741bdde65d0b Mon Sep 17 00:00:00 2001 From: Prashanth K <quic_prashk(a)quicinc.com> Date: Wed, 28 Aug 2024 12:13:02 +0530 Subject: [PATCH] usb: dwc3: Avoid waking up gadget during startxfer When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't update link state immediately after receiving the wakeup interrupt. Since wakeup event handler calls the resume callbacks, there is a chance that function drivers can perform an ep queue, which in turn tries to perform remote wakeup from send_gadget_ep_cmd(STARTXFER). This happens because DSTS[[21:18] wasn't updated to U0 yet, it's observed that the latency of DSTS can be in order of milli-seconds. Hence avoid calling gadget_wakeup during startxfer to prevent unnecessarily issuing remote wakeup to host. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: stable(a)vger.kernel.org Suggested-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/20240828064302.3796315-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..291bc549935b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -287,6 +287,23 @@ static int __dwc3_gadget_wakeup(struct dwc3 *dwc, bool async); * * Caller should handle locking. This function will issue @cmd with given * @params to @dep and wait for its completion. + * + * According to the programming guide, if the link state is in L1/L2/U3, + * then sending the Start Transfer command may not complete. The + * programming guide suggested to bring the link state back to ON/U0 by + * performing remote wakeup prior to sending the command. However, don't + * initiate remote wakeup when the user/function does not send wakeup + * request via wakeup ops. Send the command when it's allowed. + * + * Notes: + * For L1 link state, issuing a command requires the clearing of + * GUSB2PHYCFG.SUSPENDUSB2, which turns on the signal required to complete + * the given command (usually within 50us). This should happen within the + * command timeout set by driver. No additional step is needed. + * + * For L2 or U3 link state, the gadget is in USB suspend. Care should be + * taken when sending Start Transfer command to ensure that it's done after + * USB resume. */ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, struct dwc3_gadget_ep_cmd_params *params) @@ -327,30 +344,6 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); } - if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) { - int link_state; - - /* - * Initiate remote wakeup if the link state is in U3 when - * operating in SS/SSP or L1/L2 when operating in HS/FS. If the - * link state is in U1/U2, no remote wakeup is needed. The Start - * Transfer command will initiate the link recovery. - */ - link_state = dwc3_gadget_get_link_state(dwc); - switch (link_state) { - case DWC3_LINK_STATE_U2: - if (dwc->gadget->speed >= USB_SPEED_SUPER) - break; - - fallthrough; - case DWC3_LINK_STATE_U3: - ret = __dwc3_gadget_wakeup(dwc, false); - dev_WARN_ONCE(dwc->dev, ret, "wakeup failed --> %d\n", - ret); - break; - } - } - /* * For some commands such as Update Transfer command, DEPCMDPARn * registers are reserved. Since the driver often sends Update Transfer

1 week, 4 days

1
0
0 0

FAILED: patch "[PATCH] usb: dwc3: Avoid waking up gadget during startxfer" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 00dcf2fa449f23a263343d7fe051741bdde65d0b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090922-shrewdly-bright-07e5@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 00dcf2fa449f ("usb: dwc3: Avoid waking up gadget during startxfer") 047161686b81 ("usb: dwc3: Add remote wakeup handling") a02a26eb0aea ("usb: dwc3: gadget: Ignore Update Transfer cmd params") 63c4c320ccf7 ("usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 00dcf2fa449f23a263343d7fe051741bdde65d0b Mon Sep 17 00:00:00 2001 From: Prashanth K <quic_prashk(a)quicinc.com> Date: Wed, 28 Aug 2024 12:13:02 +0530 Subject: [PATCH] usb: dwc3: Avoid waking up gadget during startxfer When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't update link state immediately after receiving the wakeup interrupt. Since wakeup event handler calls the resume callbacks, there is a chance that function drivers can perform an ep queue, which in turn tries to perform remote wakeup from send_gadget_ep_cmd(STARTXFER). This happens because DSTS[[21:18] wasn't updated to U0 yet, it's observed that the latency of DSTS can be in order of milli-seconds. Hence avoid calling gadget_wakeup during startxfer to prevent unnecessarily issuing remote wakeup to host. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: stable(a)vger.kernel.org Suggested-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/20240828064302.3796315-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..291bc549935b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -287,6 +287,23 @@ static int __dwc3_gadget_wakeup(struct dwc3 *dwc, bool async); * * Caller should handle locking. This function will issue @cmd with given * @params to @dep and wait for its completion. + * + * According to the programming guide, if the link state is in L1/L2/U3, + * then sending the Start Transfer command may not complete. The + * programming guide suggested to bring the link state back to ON/U0 by + * performing remote wakeup prior to sending the command. However, don't + * initiate remote wakeup when the user/function does not send wakeup + * request via wakeup ops. Send the command when it's allowed. + * + * Notes: + * For L1 link state, issuing a command requires the clearing of + * GUSB2PHYCFG.SUSPENDUSB2, which turns on the signal required to complete + * the given command (usually within 50us). This should happen within the + * command timeout set by driver. No additional step is needed. + * + * For L2 or U3 link state, the gadget is in USB suspend. Care should be + * taken when sending Start Transfer command to ensure that it's done after + * USB resume. */ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, struct dwc3_gadget_ep_cmd_params *params) @@ -327,30 +344,6 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); } - if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) { - int link_state; - - /* - * Initiate remote wakeup if the link state is in U3 when - * operating in SS/SSP or L1/L2 when operating in HS/FS. If the - * link state is in U1/U2, no remote wakeup is needed. The Start - * Transfer command will initiate the link recovery. - */ - link_state = dwc3_gadget_get_link_state(dwc); - switch (link_state) { - case DWC3_LINK_STATE_U2: - if (dwc->gadget->speed >= USB_SPEED_SUPER) - break; - - fallthrough; - case DWC3_LINK_STATE_U3: - ret = __dwc3_gadget_wakeup(dwc, false); - dev_WARN_ONCE(dwc->dev, ret, "wakeup failed --> %d\n", - ret); - break; - } - } - /* * For some commands such as Update Transfer command, DEPCMDPARn * registers are reserved. Since the driver often sends Update Transfer

1 week, 4 days

1
0
0 0

FAILED: patch "[PATCH] usb: dwc3: Avoid waking up gadget during startxfer" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 00dcf2fa449f23a263343d7fe051741bdde65d0b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090921-chastity-calzone-c81f@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 00dcf2fa449f ("usb: dwc3: Avoid waking up gadget during startxfer") 047161686b81 ("usb: dwc3: Add remote wakeup handling") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 00dcf2fa449f23a263343d7fe051741bdde65d0b Mon Sep 17 00:00:00 2001 From: Prashanth K <quic_prashk(a)quicinc.com> Date: Wed, 28 Aug 2024 12:13:02 +0530 Subject: [PATCH] usb: dwc3: Avoid waking up gadget during startxfer When operating in High-Speed, it is observed that DSTS[USBLNKST] doesn't update link state immediately after receiving the wakeup interrupt. Since wakeup event handler calls the resume callbacks, there is a chance that function drivers can perform an ep queue, which in turn tries to perform remote wakeup from send_gadget_ep_cmd(STARTXFER). This happens because DSTS[[21:18] wasn't updated to U0 yet, it's observed that the latency of DSTS can be in order of milli-seconds. Hence avoid calling gadget_wakeup during startxfer to prevent unnecessarily issuing remote wakeup to host. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: stable(a)vger.kernel.org Suggested-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Signed-off-by: Prashanth K <quic_prashk(a)quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Link: https://lore.kernel.org/r/20240828064302.3796315-1-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 89fc690fdf34..291bc549935b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -287,6 +287,23 @@ static int __dwc3_gadget_wakeup(struct dwc3 *dwc, bool async); * * Caller should handle locking. This function will issue @cmd with given * @params to @dep and wait for its completion. + * + * According to the programming guide, if the link state is in L1/L2/U3, + * then sending the Start Transfer command may not complete. The + * programming guide suggested to bring the link state back to ON/U0 by + * performing remote wakeup prior to sending the command. However, don't + * initiate remote wakeup when the user/function does not send wakeup + * request via wakeup ops. Send the command when it's allowed. + * + * Notes: + * For L1 link state, issuing a command requires the clearing of + * GUSB2PHYCFG.SUSPENDUSB2, which turns on the signal required to complete + * the given command (usually within 50us). This should happen within the + * command timeout set by driver. No additional step is needed. + * + * For L2 or U3 link state, the gadget is in USB suspend. Care should be + * taken when sending Start Transfer command to ensure that it's done after + * USB resume. */ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, struct dwc3_gadget_ep_cmd_params *params) @@ -327,30 +344,6 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned int cmd, dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg); } - if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) { - int link_state; - - /* - * Initiate remote wakeup if the link state is in U3 when - * operating in SS/SSP or L1/L2 when operating in HS/FS. If the - * link state is in U1/U2, no remote wakeup is needed. The Start - * Transfer command will initiate the link recovery. - */ - link_state = dwc3_gadget_get_link_state(dwc); - switch (link_state) { - case DWC3_LINK_STATE_U2: - if (dwc->gadget->speed >= USB_SPEED_SUPER) - break; - - fallthrough; - case DWC3_LINK_STATE_U3: - ret = __dwc3_gadget_wakeup(dwc, false); - dev_WARN_ONCE(dwc->dev, ret, "wakeup failed --> %d\n", - ret); - break; - } - } - /* * For some commands such as Update Transfer command, DEPCMDPARn * registers are reserved. Since the driver often sends Update Transfer

1 week, 4 days

1
0
0 0

FAILED: patch "[PATCH] iio: adc: ad7124: fix DT configuration parsing" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 61cbfb5368dd50ed0d65ce21d305aa923581db2b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090916-dazzling-showman-af36@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 61cbfb5368dd ("iio: adc: ad7124: fix DT configuration parsing") a6eaf02b8274 ("iio: adc: ad7124: Switch from of specific to fwnode based property handling") 1240c94ce819 ("iio: adc: Explicitly include correct DT includes") 4c077429b422 ("iio: mlx90614: Sort headers") a99544c6c883 ("iio: adc: palmas: add support for iio threshold events") 2d48dbdfc7d4 ("iio: adc: palmas: move eventX_enable into palmas_adc_event") 7501a3a97e4f ("iio: adc: palmas: use iio_event_direction for threshold polarity") d2ab4eea732d ("iio: adc: palmas: replace "wakeup" with "event"") 79d9622d622d ("iio: adc: palmas: remove adc_wakeupX_data") 6d52b0e70698 ("iio: adc: palmas: Take probe fully device managed.") 49f76c499d38 ("iio: adc: palmas_gpadc: fix NULL dereference on rmmod") 3a258747a01f ("iio: adc: ad7124: Silence no spi_device_id warnings") 5cfe8a1c2577 ("iio: adc: ad7124: add sequencer support") fd5ba89e4cd4 ("iio: adc: ad7124: Add update_scan_mode") 3f1a9c392d69 ("iio:adc:palmas_gpadc: Switch from CONFIG_PM_SLEEP guards to pm_sleep_ptr()") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 61cbfb5368dd50ed0d65ce21d305aa923581db2b Mon Sep 17 00:00:00 2001 From: Dumitru Ceclan <mitrutzceclan(a)gmail.com> Date: Tue, 6 Aug 2024 11:51:33 +0300 Subject: [PATCH] iio: adc: ad7124: fix DT configuration parsing The cfg pointer is set before reading the channel number that the configuration should point to. This causes configurations to be shifted by one channel. For example setting bipolar to the first channel defined in the DT will cause bipolar mode to be active on the second defined channel. Fix by moving the cfg pointer setting after reading the channel number. Fixes: 7b8d045e497a ("iio: adc: ad7124: allow more than 8 channels") Signed-off-by: Dumitru Ceclan <dumitru.ceclan(a)analog.com> Reviewed-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20240806085133.114547-1-dumitru.ceclan@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c index afb5f4d741e6..108e9ccab1ef 100644 --- a/drivers/iio/adc/ad7124.c +++ b/drivers/iio/adc/ad7124.c @@ -844,8 +844,6 @@ static int ad7124_parse_channel_config(struct iio_dev *indio_dev, st->channels = channels; device_for_each_child_node_scoped(dev, child) { - cfg = &st->channels[channel].cfg; - ret = fwnode_property_read_u32(child, "reg", &channel); if (ret) return ret; @@ -863,6 +861,7 @@ static int ad7124_parse_channel_config(struct iio_dev *indio_dev, st->channels[channel].ain = AD7124_CHANNEL_AINP(ain[0]) | AD7124_CHANNEL_AINM(ain[1]); + cfg = &st->channels[channel].cfg; cfg->bipolar = fwnode_property_read_bool(child, "bipolar"); ret = fwnode_property_read_u32(child, "adi,reference-select", &tmp);

1 week, 4 days

1
0
0 0

FAILED: patch "[PATCH] iio: adc: ad7124: fix DT configuration parsing" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 61cbfb5368dd50ed0d65ce21d305aa923581db2b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090915-luridness-parameter-3447@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 61cbfb5368dd ("iio: adc: ad7124: fix DT configuration parsing") a6eaf02b8274 ("iio: adc: ad7124: Switch from of specific to fwnode based property handling") 1240c94ce819 ("iio: adc: Explicitly include correct DT includes") 4c077429b422 ("iio: mlx90614: Sort headers") a99544c6c883 ("iio: adc: palmas: add support for iio threshold events") 2d48dbdfc7d4 ("iio: adc: palmas: move eventX_enable into palmas_adc_event") 7501a3a97e4f ("iio: adc: palmas: use iio_event_direction for threshold polarity") d2ab4eea732d ("iio: adc: palmas: replace "wakeup" with "event"") 79d9622d622d ("iio: adc: palmas: remove adc_wakeupX_data") 6d52b0e70698 ("iio: adc: palmas: Take probe fully device managed.") 49f76c499d38 ("iio: adc: palmas_gpadc: fix NULL dereference on rmmod") 3a258747a01f ("iio: adc: ad7124: Silence no spi_device_id warnings") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 61cbfb5368dd50ed0d65ce21d305aa923581db2b Mon Sep 17 00:00:00 2001 From: Dumitru Ceclan <mitrutzceclan(a)gmail.com> Date: Tue, 6 Aug 2024 11:51:33 +0300 Subject: [PATCH] iio: adc: ad7124: fix DT configuration parsing The cfg pointer is set before reading the channel number that the configuration should point to. This causes configurations to be shifted by one channel. For example setting bipolar to the first channel defined in the DT will cause bipolar mode to be active on the second defined channel. Fix by moving the cfg pointer setting after reading the channel number. Fixes: 7b8d045e497a ("iio: adc: ad7124: allow more than 8 channels") Signed-off-by: Dumitru Ceclan <dumitru.ceclan(a)analog.com> Reviewed-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20240806085133.114547-1-dumitru.ceclan@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c index afb5f4d741e6..108e9ccab1ef 100644 --- a/drivers/iio/adc/ad7124.c +++ b/drivers/iio/adc/ad7124.c @@ -844,8 +844,6 @@ static int ad7124_parse_channel_config(struct iio_dev *indio_dev, st->channels = channels; device_for_each_child_node_scoped(dev, child) { - cfg = &st->channels[channel].cfg; - ret = fwnode_property_read_u32(child, "reg", &channel); if (ret) return ret; @@ -863,6 +861,7 @@ static int ad7124_parse_channel_config(struct iio_dev *indio_dev, st->channels[channel].ain = AD7124_CHANNEL_AINP(ain[0]) | AD7124_CHANNEL_AINM(ain[1]); + cfg = &st->channels[channel].cfg; cfg->bipolar = fwnode_property_read_bool(child, "bipolar"); ret = fwnode_property_read_u32(child, "adi,reference-select", &tmp);

1 week, 4 days

1
0
0 0

FAILED: patch "[PATCH] iio: adc: ad7606: remove frstdata check for serial mode" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x 90826e08468ba7fb35d8b39645b22d9e80004afe # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090946-heading-mortality-97cb@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: 90826e08468b ("iio: adc: ad7606: remove frstdata check for serial mode") 7989b4bb23fe ("iio: adc: ad7616: Add support for AD7616 ADC") 6bf229abce75 ("iio: adc: ad7606: Move oversampling options in chip info and rework *_avail attributes") 2985a5d88455 ("staging: iio: adc: ad7606: Move out of staging") 54160ae3b2d3 ("staging: iio: adc: ad7606: Misc style fixes (no functional change)") cc49bd1652a4 ("staging: iio: adc: ad7606: Add support for threaded irq") 2bbf53e3e506 ("staging: iio: adc: ad7606: Simplify the Kconfing menu") 43f9b204edf0 ("staging: iio: adc: ad7606: Add OF device ID table") 41f71e5e7daf ("staging: iio: adc: ad7606: Use find_closest() macro") c0683bfd3772 ("staging: iio: adc: ad7606: Use devm functions in probe") 557e585c3fdb ("staging: iio: adc: ad7606: Use wait-for-completion handler") 7c0bc65c8403 ("Merge tag 'iio-for-4.21a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-testing") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 90826e08468ba7fb35d8b39645b22d9e80004afe Mon Sep 17 00:00:00 2001 From: Guillaume Stols <gstols(a)baylibre.com> Date: Tue, 2 Jul 2024 12:52:51 +0000 Subject: [PATCH] iio: adc: ad7606: remove frstdata check for serial mode The current implementation attempts to recover from an eventual glitch in the clock by checking frstdata state after reading the first channel's sample: If frstdata is low, it will reset the chip and return -EIO. This will only work in parallel mode, where frstdata pin is set low after the 2nd sample read starts. For the serial mode, according to the datasheet, "The FRSTDATA output returns to a logic low following the 16th SCLK falling edge.", thus after the Xth pulse, X being the number of bits in a sample, the check will always be true, and the driver will not work at all in serial mode if frstdata(optional) is defined in the devicetree as it will reset the chip, and return -EIO every time read_sample is called. Hence, this check must be removed for serial mode. Fixes: b9618c0cacd7 ("staging: IIO: ADC: New driver for AD7606/AD7606-6/AD7606-4") Signed-off-by: Guillaume Stols <gstols(a)baylibre.com> Reviewed-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20240702-cleanup-ad7606-v3-1-18d5ea18770e@baylibre… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c index 3a417595294f..c321c6ef48df 100644 --- a/drivers/iio/adc/ad7606.c +++ b/drivers/iio/adc/ad7606.c @@ -49,7 +49,7 @@ static const unsigned int ad7616_oversampling_avail[8] = { 1, 2, 4, 8, 16, 32, 64, 128, }; -static int ad7606_reset(struct ad7606_state *st) +int ad7606_reset(struct ad7606_state *st) { if (st->gpio_reset) { gpiod_set_value(st->gpio_reset, 1); @@ -60,6 +60,7 @@ static int ad7606_reset(struct ad7606_state *st) return -ENODEV; } +EXPORT_SYMBOL_NS_GPL(ad7606_reset, IIO_AD7606); static int ad7606_reg_access(struct iio_dev *indio_dev, unsigned int reg, @@ -88,31 +89,6 @@ static int ad7606_read_samples(struct ad7606_state *st) { unsigned int num = st->chip_info->num_channels - 1; u16 *data = st->data; - int ret; - - /* - * The frstdata signal is set to high while and after reading the sample - * of the first channel and low for all other channels. This can be used - * to check that the incoming data is correctly aligned. During normal - * operation the data should never become unaligned, but some glitch or - * electrostatic discharge might cause an extra read or clock cycle. - * Monitoring the frstdata signal allows to recover from such failure - * situations. - */ - - if (st->gpio_frstdata) { - ret = st->bops->read_block(st->dev, 1, data); - if (ret) - return ret; - - if (!gpiod_get_value(st->gpio_frstdata)) { - ad7606_reset(st); - return -EIO; - } - - data++; - num--; - } return st->bops->read_block(st->dev, num, data); } diff --git a/drivers/iio/adc/ad7606.h b/drivers/iio/adc/ad7606.h index 0c6a88cc4695..6649e84d25de 100644 --- a/drivers/iio/adc/ad7606.h +++ b/drivers/iio/adc/ad7606.h @@ -151,6 +151,8 @@ int ad7606_probe(struct device *dev, int irq, void __iomem *base_address, const char *name, unsigned int id, const struct ad7606_bus_ops *bops); +int ad7606_reset(struct ad7606_state *st); + enum ad7606_supported_device_ids { ID_AD7605_4, ID_AD7606_8, diff --git a/drivers/iio/adc/ad7606_par.c b/drivers/iio/adc/ad7606_par.c index d8408052262e..6bc587b20f05 100644 --- a/drivers/iio/adc/ad7606_par.c +++ b/drivers/iio/adc/ad7606_par.c @@ -7,6 +7,7 @@ #include <linux/mod_devicetable.h> #include <linux/module.h> +#include <linux/gpio/consumer.h> #include <linux/platform_device.h> #include <linux/types.h> #include <linux/err.h> @@ -21,8 +22,29 @@ static int ad7606_par16_read_block(struct device *dev, struct iio_dev *indio_dev = dev_get_drvdata(dev); struct ad7606_state *st = iio_priv(indio_dev); - insw((unsigned long)st->base_address, buf, count); + /* + * On the parallel interface, the frstdata signal is set to high while + * and after reading the sample of the first channel and low for all + * other channels. This can be used to check that the incoming data is + * correctly aligned. During normal operation the data should never + * become unaligned, but some glitch or electrostatic discharge might + * cause an extra read or clock cycle. Monitoring the frstdata signal + * allows to recover from such failure situations. + */ + int num = count; + u16 *_buf = buf; + + if (st->gpio_frstdata) { + insw((unsigned long)st->base_address, _buf, 1); + if (!gpiod_get_value(st->gpio_frstdata)) { + ad7606_reset(st); + return -EIO; + } + _buf++; + num--; + } + insw((unsigned long)st->base_address, _buf, num); return 0; } @@ -35,8 +57,28 @@ static int ad7606_par8_read_block(struct device *dev, { struct iio_dev *indio_dev = dev_get_drvdata(dev); struct ad7606_state *st = iio_priv(indio_dev); + /* + * On the parallel interface, the frstdata signal is set to high while + * and after reading the sample of the first channel and low for all + * other channels. This can be used to check that the incoming data is + * correctly aligned. During normal operation the data should never + * become unaligned, but some glitch or electrostatic discharge might + * cause an extra read or clock cycle. Monitoring the frstdata signal + * allows to recover from such failure situations. + */ + int num = count; + u16 *_buf = buf; - insb((unsigned long)st->base_address, buf, count * 2); + if (st->gpio_frstdata) { + insb((unsigned long)st->base_address, _buf, 2); + if (!gpiod_get_value(st->gpio_frstdata)) { + ad7606_reset(st); + return -EIO; + } + _buf++; + num--; + } + insb((unsigned long)st->base_address, _buf, num * 2); return 0; }

1 week, 4 days

1
0
0 0

FAILED: patch "[PATCH] staging: iio: frequency: ad9834: Validate frequency parameter" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y git checkout FETCH_HEAD git cherry-pick -x b48aa991758999d4e8f9296c5bbe388f293ef465 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024090940-shale-handcart-eb5d@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^.. Possible dependencies: b48aa9917589 ("staging: iio: frequency: ad9834: Validate frequency parameter value") 8e8040c52e63 ("staging: iio: frequency: ad9833: Load clock using clock framework") 80109c32348d ("staging: iio: frequency: ad9833: Get frequency value statically") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b48aa991758999d4e8f9296c5bbe388f293ef465 Mon Sep 17 00:00:00 2001 From: Aleksandr Mishin <amishin(a)t-argos.ru> Date: Wed, 3 Jul 2024 18:45:06 +0300 Subject: [PATCH] staging: iio: frequency: ad9834: Validate frequency parameter value In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 12b9d5bf76bf ("Staging: IIO: DDS: AD9833 / AD9834 driver") Suggested-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Dan Carpenter <dan.carpenter(a)linaro.org> Link: https://patch.msgid.link/20240703154506.25584-1-amishin@t-argos.ru Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/staging/iio/frequency/ad9834.c b/drivers/staging/iio/frequency/ad9834.c index a7a5cdcc6590..47e7d7e6d920 100644 --- a/drivers/staging/iio/frequency/ad9834.c +++ b/drivers/staging/iio/frequency/ad9834.c @@ -114,7 +114,7 @@ static int ad9834_write_frequency(struct ad9834_state *st, clk_freq = clk_get_rate(st->mclk); - if (fout > (clk_freq / 2)) + if (!clk_freq || fout > (clk_freq / 2)) return -EINVAL; regval = ad9834_calc_freqreg(clk_freq, fout);

1 week, 4 days

1
0
0 0

[PATCH RESEND] drm/nouveau: fix a possible null pointer dereference

by Ma Ke

In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate() is used directly in drm_mode_probed_add(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable(a)vger.kernel.org Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/i2c/ch7006_drv.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c index 131512a5f3bd..48bf6e4e8bdb 100644 --- a/drivers/gpu/drm/i2c/ch7006_drv.c +++ b/drivers/gpu/drm/i2c/ch7006_drv.c @@ -229,6 +229,7 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, { struct ch7006_priv *priv = to_ch7006_priv(encoder); const struct ch7006_mode *mode; + struct drm_display_mode *encoder_mode = NULL; int n = 0; for (mode = ch7006_modes; mode->mode.clock; mode++) { @@ -236,8 +237,11 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, ~mode->valid_norms & 1<<priv->norm) continue; - drm_mode_probed_add(connector, - drm_mode_duplicate(encoder->dev, &mode->mode)); + encoder_mode = drm_mode_duplicate(encoder->dev, &mode->mode); + if (!encoder_mode) + return 0; + + drm_mode_probed_add(connector, encoder_mode); n++; } -- 2.25.1

1 week, 4 days

1
0
0 0

[PATCH v2 1/2] ufs: core: fix the issue of ICU failure

by peter.wang＠mediatek.com

From: Peter Wang <peter.wang(a)mediatek.com> When setting the ICU bit without using read-modify-write, SQRTCy will restart SQ again and receive an RTC return error code 2 (Failure - SQ not stopped). Additionally, the error log has been modified so that this type of error can be observed. Fixes: ab248643d3d6 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable(a)vger.kernel.org Signed-off-by: Peter Wang <peter.wang(a)mediatek.com> --- drivers/ufs/core/ufs-mcq.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c index 5891cdacd0b3..afd9541f4bd8 100644 --- a/drivers/ufs/core/ufs-mcq.c +++ b/drivers/ufs/core/ufs-mcq.c @@ -570,15 +570,16 @@ int ufshcd_mcq_sq_cleanup(struct ufs_hba *hba, int task_tag) writel(nexus, opr_sqd_base + REG_SQCTI); /* SQRTCy.ICU = 1 */ - writel(SQ_ICU, opr_sqd_base + REG_SQRTC); + writel(readl(opr_sqd_base + REG_SQRTC) | SQ_ICU, + opr_sqd_base + REG_SQRTC); /* Poll SQRTSy.CUS = 1. Return result from SQRTSy.RTC */ reg = opr_sqd_base + REG_SQRTS; err = read_poll_timeout(readl, val, val & SQ_CUS, 20, MCQ_POLL_US, false, reg); - if (err) - dev_err(hba->dev, "%s: failed. hwq=%d, tag=%d err=%ld\n", - __func__, id, task_tag, + if (err || FIELD_GET(SQ_ICU_ERR_CODE_MASK, readl(reg))) + dev_err(hba->dev, "%s: failed. hwq=%d, tag=%d err=%d RTC=%ld\n", + __func__, id, task_tag, err, FIELD_GET(SQ_ICU_ERR_CODE_MASK, readl(reg))); if (ufshcd_mcq_sq_start(hba, hwq)) -- 2.45.2

1 week, 4 days

4
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2024