This reverts commit 0157e2a8a71978c58a7d6cfb3616ab17d9726631.
The reverted commit was backported and applied twice on the stable branch:
- First as commit 15de2e4c90b7 ("drm/radeon/ci: disable mclk switching for
high refresh rates (v2)")
- Then as commit 0157e2a8a719 ("drm/radeon/ci: disable mclk switching for
high refresh rates (v2)")
Fixes: 0157e2a8a719 ("drm/radeon/ci: disable mclk switching for high refresh rates (v2)")
Signed-off-by: Guillaume Bertholon <guillaume.bertholon(a)ens.fr>
---
drivers/gpu/drm/radeon/ci_dpm.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 8e1bf9e..c8baa06 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -782,12 +782,6 @@ bool ci_dpm_vblank_too_short(struct radeon_device *rdev)
if (r600_dpm_get_vrefresh(rdev) > 120)
return true;
- /* disable mclk switching if the refresh is >120Hz, even if the
- * blanking period would allow it
- */
- if (r600_dpm_get_vrefresh(rdev) > 120)
- return true;
-
if (vblank_time < switch_limit)
return true;
else
--
2.7.4
I'm working on a tool for (reliably) transferring diffs across
versions of a given C code. To evaluate my tool, I have been comparing
the output of my tool against the manual backports in the stable
branch.
In the process, I have found some oddities in some backported patches
which, I believe, are incorrect. In all cases, the root cause seems to
be that `patch` was able to apply a backported diff after some fuzzy
matching but did so at a wrong location (IMHO). Below is an example. I
can report the others if there is indeed a problem.
On the branch stable/linux-4.4.y, the upstream patch
b560a208cda0297fef6ff85bbfd58a8f0a52a543
Bluetooth: MGMT: Fix not checking if BT_HS is enabled
is backported as commit
5abe9f99f5129bee5492072ff76b91ec4fad485b.
If we look at both commits we have:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Upstream
b560a208cda0297fef6ff85bbfd58a8f0a52a543
%%%%%%%%%
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 0b711ad..12d7b36 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
[...]
@@ -1817,6 +1818,10 @@ static int set_hs(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
bt_dev_dbg(hdev, "sock %p", sk);
+ if (!IS_ENABLED(CONFIG_BT_HS))
+ return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS,
+ MGMT_STATUS_NOT_SUPPORTED);
+
status = mgmt_bredr_support(hdev);
if (status)
return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, status);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Backported
5abe9f99f5129bee5492072ff76b91ec4fad485b
%%%%%%%%%
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index ecc3da6..ee761fb 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
[...]
@@ -2281,6 +2282,10 @@ static int set_link_security(struct sock *sk, struct hci_dev *hdev, void *data,
BT_DBG("request for %s", hdev->name);
+ if (!IS_ENABLED(CONFIG_BT_HS))
+ return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS,
+ MGMT_STATUS_NOT_SUPPORTED);
+
status = mgmt_bredr_support(hdev);
if (status)
return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_LINK_SECURITY,
I suspect that this does *not* reflect the intent of the orignal patch
(which was addressing an issue in `set_hs`) whereas, here, the
backported patch is somewhat arbitrarily modifying `set_link_security`
while `set_hs` remains as-is.
Is this indeed an issue? Should I report on the other cases as well?
- Guillaume Bertholon