aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-09-20drm/i915/dg2: configure TRANS_DP2_CTL for DP 2.0Jani Nikula1-1/+16
Set the DP 2.0 128b/132b channel encoding for UHBR rates. v2: Fix UHBR port clock check, use intel_dp_is_uhbr() Bspec: 54128 Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c88b08d80a96d1229ae941b296590633be4d8711.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dp: select 128b/132b channel encoding for UHBR ratesJani Nikula1-1/+2
UHBR rates and 128b/132b channel encoding go hand in hand. v2: Fix check for >= UHBR rates using intel_dp_is_uhbr() (Ville) Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b4ffd0187b306c0abaa08b89ed35c993ad8145c7.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dp: use 128b/132b TPS2 for UHBR+ link ratesJani Nikula1-3/+7
128b/132b channel encoding has separate TPS1 and TPS2, although the DPCD register values coincide with 8b/10b TPS1 and TPS2 values. Use 128b/132b TPS2 for channel equalization. v2: Use intel_dp_is_uhbr Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> # v1 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/723b29223dc570c8b63c3c6fe5fb772d9db06c0d.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dp: add helper for checking for UHBR link rateJani Nikula2-0/+7
Helpful abstraction to avoid duplication. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fe9a222ad900da797c989de9f7fa13928d2c9861.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/dg2: add DG2+ TRANS_DDI_FUNC_CTL DP 2.0 128b/132b modeJani Nikula2-4/+4
Unfortunately, the DP 2.0 128b/132b DDI mode selection in the register conflicts with FDI. Since we have to deal with both meanings in the same code, for different platforms, clarify the macro name so we don't forget. Bspec: 50493 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/260e4da302d47ae50122eb8d517be6ac3ccb15f2.1631191763.git.jani.nikula@intel.com
2021-09-20drm/dp: add helper for extracting adjust 128b/132b TX FFE presetJani Nikula1-0/+14
The DP 2.0 128b/132b channel coding uses TX FFE presets instead of vswing and pre-emphasis. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4ba129c51aeb01a5f210de7026abe704a554a178.1631191763.git.jani.nikula@intel.com
2021-09-20drm/dp: use more of the extended receiver capJani Nikula1-1/+1
Extend the use of extended receiver cap at 0x2200 to cover MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides the DP 2.0 128b/132b channel encoding cap. v2: Extend to DP_RECEIVER_CAP_SIZE (Ville) Cc: Lyude Paul <lyude@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/649051cb896821147feee91aab1f2abc523c1353.1631191763.git.jani.nikula@intel.com
2021-09-20drm/dp: add DP 2.0 UHBR link rate and bw code conversionsJani Nikula1-4/+22
The bw code equals link_rate / 0.27 Gbps only for 8b/10b link rates. Handle DP 2.0 UHBR rates as special cases, though this is not pretty. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cab4edda8834d6b4db610fabb5e1f1f18ae33c2c.1631191763.git.jani.nikula@intel.com
2021-09-20drm/i915/gt: Add "intel_" as prefix in set_mocs_index()Ayaz A Siddiqui3-3/+3
Adding missing "intel_" prefix in set_mocs_index(). Fixes: b62aa57e3c78 ("drm/i915/gt: Add support of mocs propagation") Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210916062736.1733587-1-ayaz.siddiqui@intel.com
2021-09-20ASoC: Drop mistakenly applied SPI patchMark Brown1-2/+3
Revert 6e8cc4ddce828 ("spi: tegra20-slink: Declare runtime suspend and resume functions conditionally") which was mistakenly applied to the ASoC tree not the SPI tree (where it was also applied. Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-20drm/i915: Make wa list per-gtVenkata Sandeep Dhanalakota8-75/+81
Support for multiple GT's within a single i915 device will be arriving soon. Since each GT may have its own fusing and require different workarounds, we need to make the GT workaround functions and multicast steering setup per-gt. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210917170845.836358-1-matthew.d.roper@intel.com
2021-09-20swiotlb-xen: this is PV-only on x86Jan Beulich1-0/+1
The code is unreachable for HVM or PVH, and it also makes little sense in auto-translated environments. On Arm, with xen_{create,destroy}_contiguous_region() both being stubs, I have a hard time seeing what good the Xen specific variant does - the generic one ought to be fine for all purposes there. Still Arm code explicitly references symbols here, so the code will continue to be included there. Instead of making PCI_XEN's "select" conditional, simply drop it - SWIOTLB_XEN will be available unconditionally in the PV case anyway, and is - as explained above - dead code in non-PV environments. This in turn allows dropping the stubs for xen_{create,destroy}_contiguous_region(), the former of which was broken anyway - it failed to set the DMA handle output. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/5947b8ae-fdc7-225c-4838-84712265fc1e@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-20PCI: only build xen-pcifront in PV-enabled environmentsJan Beulich1-1/+1
The driver's module init function, pcifront_init(), invokes xen_pv_domain() first thing. That construct produces constant "false" when !CONFIG_XEN_PV. Hence there's no point building the driver in non-PV configurations. Drop the (now implicit and generally wrong) X86 dependency: At present, XEN_PV can only be set when X86 is also enabled. In general an architecture supporting Xen PV (and PCI) would want to have this driver built. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/3a7f6c9b-215d-b593-8056-b5fe605dafd7@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-20swiotlb-xen: ensure to issue well-formed XENMEM_exchange requestsJan Beulich1-3/+4
While the hypervisor hasn't been enforcing this, we would still better avoid issuing requests with GFNs not aligned to the requested order. Instead of altering the value also in the call to panic(), drop it there for being static and hence easy to determine without being part of the panic message. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Link: https://lore.kernel.org/r/7b3998e3-1233-4e5a-89ec-d740e77eb166@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-20Xen/gntdev: don't ignore kernel unmapping errorJan Beulich1-0/+8
While working on XSA-361 and its follow-ups, I failed to spot another place where the kernel mapping part of an operation was not treated the same as the user space part. Detect and propagate errors and add a 2nd pr_debug(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/c2513395-74dc-aea3-9192-fd265aa44e35@suse.com Signed-off-by: Juergen Gross <jgross@suse.com>
2021-09-20drm/panfrost: simplify getting .driver_dataWolfram Sang1-4/+2
We should get 'driver_data' from 'struct device' directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210920090522.23784-6-wsa+renesas@sang-engineering.com
2021-09-20panfrost: make mediatek_mt8183_supplies and mediatek_mt8183_pm_domains staticJiapeng Chong1-2/+2
This symbol is not used outside of panfrost_drv.c, so marks it static. Fix the following sparse warning: drivers/gpu/drm/panfrost/panfrost_drv.c:641:12: warning: symbol 'mediatek_mt8183_supplies' was not declared. Should it be static? drivers/gpu/drm/panfrost/panfrost_drv.c:642:12: warning: symbol 'mediatek_mt8183_pm_domains' was not declared. Should it be static? Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/1631956414-85412-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-09-20clk: rockchip: rk3399: expose PCLK_COREDBG_{B,L}Brian Norris1-2/+2
We have DT IDs for PCLK_COREDBG_L and PCLK_COREDBG_B, but we don't actually expose them. Note that this requires the previous patch (making "armclkl" and "armclkb" into "critical" clocks) to prevent these clocks from taking down the CPU. Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210908111337.v2.2.If29cd838efbcee4450a62b8d84a99b23c86e0a3f@changeid Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20clk: rockchip: rk3399: make CPU clocks criticalBrian Norris1-4/+7
The CPU clocks don't currently have any owner (e.g., cpufreq-dt doesn't enable() them -- and even if it did, it's not early enough compared to other consumers -- nor does arch/arm64/kernel/smp.c), and instead are simply assumed to be "on" all the time. They are also parents of a few other clocks which haven't been previously exposed for other devices to consume. If we want to expose those clocks, then the common clock framework may eventually choose to disable their parents (including the CPU PLLs) -- which is no fun for anyone. Thus, mark the CPU clocks as critical, to prevent them from being disabled implicitly. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20210908111337.v2.1.I006bb36063555079b1a88f01d20e38d7e4705ae0@changeid Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-20Merge remote-tracking branch 'tip/locking/wwmutex' into drm-intel-gt-nextJoonas Lahtinen2-2/+2
Needed by Maarten's series "drm/i915: Short-term pinning and async eviction". Link: https://lists.freedesktop.org/archives/intel-gfx/2021-September/277870.html Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2021-09-20spi: Fixed division by zero warningYoshitaka Ikeda4-4/+5
The reason for dividing by zero is because the dummy bus width is zero, but if the dummy n bytes is zero, it indicates that there is no data transfer, so there is no need for calculation. Fixes: 7512eaf54190 ("spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1") Signed-off-by: Yoshitaka Ikeda <ikeda@nskint.co.jp> Acked-by: Pratyush Yadav <p.yadav@ti.com> Link: https://lore.kernel.org/r/OSZPR01MB70049C8F56ED8902852DF97B8BD49@OSZPR01MB7004.jpnprd01.prod.outlook.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-20regulator: fix typo in Kconfig and max8973-regulatorRamona Alexandra Nechita2-4/+4
MAX8973 is supposed to be MAX8973A. Kconfig and the initial comment of max8973-regulator.c were modified accordingly. Signed-off-by: Ramona Alexandra Nechita <ramona.nechita@analog.com> Link: https://lore.kernel.org/r/20210920061137.10884-1-ramona.nechita@analog.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-20drm/v3d: Make use of the helper function devm_platform_ioremap_resource_byname()Cai Huoqing1-4/+1
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210901112941.31320-1-caihuoqing@baidu.com
2021-09-20net: hns3: fix a return value error in hclge_get_reset_status()Yufeng Mo1-4/+11
hclge_get_reset_status() should return the tqp reset status. However, if the CMDQ fails, the caller will take it as tqp reset success status by mistake. Therefore, uses a parameters to get the tqp reset status instead. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-20net: hns3: check vlan id before using itliaoguojia1-0/+3
The input parameters may not be reliable, so check the vlan id before using it, otherwise may set wrong vlan id into hardware. Fixes: dc8131d846d4 ("net: hns3: Fix for packet loss due wrong filter config in VLAN tbls") Signed-off-by: liaoguojia <liaoguojia@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-20net: hns3: check queue id range before usingYufeng Mo1-0/+8
The input parameters may not be reliable. Before using the queue id, we should check this parameter. Otherwise, memory overwriting may occur. Fixes: d34100184685 ("net: hns3: refactor the mailbox message between PF and VF") Signed-off-by: Yufeng Mo <moyufeng@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-20net: hns3: fix misuse vf id and vport id in some logsJiaran Zhang4-10/+12
vport_id include PF and VFs, vport_id = 0 means PF, other values mean VFs. So the actual vf id is equal to vport_id minus 1. Some VF print logs are actually vport, and logs of vf id actually use vport id, so this patch fixes them. Fixes: ac887be5b0fe ("net: hns3: change print level of RAS error log from warning to error") Fixes: adcf738b804b ("net: hns3: cleanup some print format warning") Signed-off-by: Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-20net: hns3: fix inconsistent vf id printJian Shen1-2/+5
The vf id from ethtool is added 1 before configured to driver. So it's necessary to minus 1 when printing it, in order to keep consistent with user's configuration. Fixes: dd74f815dd41 ("net: hns3: Add support for rule add/delete for flow director") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-20net: hns3: fix change RSS 'hfunc' ineffective issueJian Shen2-33/+64
When user change rss 'hfunc' without set rss 'hkey' by ethtool -X command, the driver will ignore the 'hfunc' for the hkey is NULL. It's unreasonable. So fix it. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Fixes: 374ad291762a ("net: hns3: Add RSS general configuration support for VF") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-20staging: r8188eu: remove unnecessary space in usbctrl_vendorreq()Fabio M. De Francesco1-1/+1
Remove unnecessary extra space in usbctrl_vendorreq(). Co-developed-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20210919235356.4151-7-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove unnedeed parentheses in usbctrl_vendorreq()Fabio M. De Francesco1-1/+1
Remove unneeded parentheses around a test for -ESHUTDOWN in usbctrl_vendorreq(). Co-developed-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com> Link: https://lore.kernel.org/r/20210919235356.4151-6-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20KVM: arm64: Fix PMU probe orderingMarc Zyngier1-0/+2
Russell reported that since 5.13, KVM's probing of the PMU has started to fail on his HW. As it turns out, there is an implicit ordering dependency between the architectural PMU probing code and and KVM's own probing. If, due to probe ordering reasons, KVM probes before the PMU driver, it will fail to detect the PMU and prevent it from being advertised to guests as well as the VMM. Obviously, this is one probing too many, and we should be able to deal with any ordering. Add a callback from the PMU code into KVM to advertise the registration of a host CPU PMU, allowing for any probing order. Fixes: 5421db1be3b1 ("KVM: arm64: Divorce the perf code from oprofile helpers") Reported-by: "Russell King (Oracle)" <linux@armlinux.org.uk> Tested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/YUYRKVflRtUytzy5@shell.armlinux.org.uk Cc: stable@vger.kernel.org
2021-09-20staging: r8188eu: remove ODM_SingleDualAntennaDetection()Michael Straube2-225/+0
Function ODM_SingleDualAntennaDetection() is not used, remove it. It is the only user of odm_PHY_SaveAFERegisters() and odm_PHY_ReloadAFERegisters() so remove these functions as well. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918211046.6865-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: clean up indentation in odm_RegDefine11N.hMichael Straube1-8/+8
Clean up indentation in odm_RegDefine11N.h. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-15-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove unused defines from odm_RegDefine11N.hMichael Straube1-96/+0
Remove unused defines from odm_RegDefine11N.h. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-14-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove header file odm_RegDefine11AC.hMichael Straube2-30/+0
Finally the header odm_RegDefine11AC.h is unused now. Remove it. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-13-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove macros ODM_IC_11{N,AC}_SERIESMichael Straube1-5/+0
The macros ODM_IC_11N_SERIES and ODM_IC_11AC_SERIES are unused now. Remove them. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-12-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove dead code from odm.cMichael Straube1-68/+54
(pDM_Odm->SupportICType & ODM_IC_11N_SERIES) is true in this driver. There is an if statement that checks this. Remove it and its never executed else arm. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-11-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove unnecessary if statementsMichael Straube1-23/+16
(pDM_Odm->SupportICType & ODM_IC_11AC_SERIES) is always false and (pDM_Odm->SupportICType & ODM_IC_11N_SERIES) is always true since SupportICType is ODM_RTL8188E in this driver. Remove unnecessary if statements that check for this. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-10-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove macro ODM_BITMichael Straube2-8/+2
Replace and remove the macro ODM_BIT to make the code cleaner. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-9-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove macro ODM_REGMichael Straube2-5/+3
Replace and remove the macro ODM_REG to make the code cleaner. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-8-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove more dead code from ODM_Write_DIG()Michael Straube1-4/+0
SupportICType is ODM_RTL8188E in this driver. Remove code that is never executed. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-7-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove unnecessary if statementMichael Straube1-5/+4
SupportPlatform is ODM_CE in this driver. Remove an unnecessary if statement that checks the SupportPlatform value. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-6-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove dead code from ODM_Write_DIG()Michael Straube1-34/+0
In this driver SupportPlatform is ODM_CE, so code in the "else if (pDM_Odm->SupportPlatform & (ODM_AP | ODM_ADSL))" is never executed. Remove it. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-5-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove _ic_type from macro _cat in odm_interface.hMichael Straube1-9/+3
((_ic_type) & ODM_IC_11N_SERIES) is always true since SupportICType is ODM_RTL8188E in this driver. Remove it from the _cat macro. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-4-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove unused macros from odm_interface.hMichael Straube1-5/+0
Remove unused macros from odm_interface.h. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-3-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove comments from odm_interface.hMichael Straube1-22/+0
In order to make further cleanup easier to review remove some unnecessary comments from odm_interface.h Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918181904.12000-2-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: do not write past the end of an arrayMartin Kaiser1-5/+4
Commit f7b687d6b67e ("staging: r8188eu: remove NumTotalRFPath from struct hal_data_8188e") removed a for loop around a block of code that is executed only once when i == 0. However, without the for loop, i will never be set to 0 before the code block is executed. i remains at 2, which is the final value after the previous loop. This results in a write past the end of the powerlevel and MCSBase arrays. [ 28.480809] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: rtl8188e_PHY_RF6052SetOFDMTxPower+0x124/0x128 [r8188eu] [ 28.493752] ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: rtl8188e_PHY_RF6052SetOFDMTxPower+0x124/0x128 [r8188eu] ]--- Fix this by replacing i with 0 in the code block that used to be the body of the loop. While at it, remove the powerlevel array that was just holding a temporary value. Tested with Edimax EW-7811Un V2 on an ARM32 embedded system. Fixes: f7b687d6b67e ("staging: r8188eu: remove NumTotalRFPath from struct hal_data_8188e") Acked-by: Michael Straube <straube.linux@gmail.com> Signed-off-by: Martin Kaiser <martin@kaiser.cx> Link: https://lore.kernel.org/r/20210918134024.23837-1-martin@kaiser.cx Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove EFUSE_Read1Byte()Michael Straube2-59/+0
Function EFUSE_Read1Byte() is not used, remove it. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918095727.13591-9-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-20staging: r8188eu: remove rtl8188e_set_rssi_cmd()Michael Straube2-16/+0
Function rtl8188e_set_rssi_cmd() is not used, remove it. Signed-off-by: Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20210918095727.13591-8-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.