summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-11-18scsi: megaraid_sas: Fix concurrent access to ISR between IRQ polling and ↵Sumit Saxena1-4/+7
real interrupt [ Upstream commit e7dcc514a49e74051b869697d5ab0370f6301d57 ] IRQ polling thread calls ISR after enable_irq() to handle any missed I/O completion. The atomic flag "in_used" was added to have the synchronization between the IRQ polling thread and the interrupt context. There is a bug around it leading to a race condition. Below is the sequence: - IRQ polling thread accesses ISR, fetches the reply descriptor. - Real interrupt arrives and pre-empts polling thread (enable_irq() is already called). - Interrupt context picks the same reply descriptor as fetched by polling thread, processes it, and exits. - Polling thread resumes and processes the descriptor which is already processed by interrupt thread leads to kernel crash. Setting the "in_used" flag before fetching the reply descriptor ensures synchronized access to ISR. Link: https://www.spinics.net/lists/linux-scsi/msg159440.html Link: https://lore.kernel.org/r/20210929124022.24605-2-sumit.saxena@broadcom.com Fixes: 9bedd36e9146 ("scsi: megaraid_sas: Handle missing interrupts while re-enabling IRQs") Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18scsi: ufs: core: Stop clearing UNIT ATTENTIONSBart Van Assche2-197/+1
[ Upstream commit edc0596cc04bf0ac3a69c66e994d3ff8b650ff71 ] Commit aa53f580e67b ("scsi: ufs: Minor adjustments to error handling") introduced a ufshcd_clear_ua_wluns() call in ufshcd_err_handling_unprepare(). As explained in detail by Adrian Hunter, this can trigger a deadlock. Avoid that deadlock by removing the code that clears the unit attention. This is safe because the only software that relies on clearing unit attentions is the Android Trusty software and because support for handling unit attentions has been added in the Trusty software. See also https://lore.kernel.org/linux-scsi/20210930124224.114031-2-adrian.hunter@intel.com/ Note that "scsi: ufs: Retry START_STOP on UNIT_ATTENTION" is a prerequisite for this commit. Link: https://lore.kernel.org/r/20211001182015.1347587-3-jaegeuk@kernel.org Fixes: aa53f580e67b ("scsi: ufs: Minor adjustments to error handling") Cc: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Bart Van Assche <bvanassche@google.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18scsi: ufs: core: Fix ufshcd_probe_hba() prototype to match the definitionBean Huo1-1/+1
[ Upstream commit 68444d73d6a5864ede12df6366bd6602e022ae5b ] Since commit 568dd9959611 ("scsi: ufs: Rename the second ufshcd_probe_hba() argument"), the second ufshcd_probe_hba() argument has been changed to init_dev_params. Link: https://lore.kernel.org/r/20210929200640.828611-3-huobean@gmail.com Fixes: 568dd9959611 ("scsi: ufs: Rename the second ufshcd_probe_hba() argument") Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18power: reset: at91-reset: check properly the return value of devm_of_iomapClaudiu Beznea1-2/+2
[ Upstream commit f558c8072c3461b65c12c0068b108f78cebc8246 ] devm_of_iomap() returns error code or valid pointer. Check its return value with IS_ERR(). Fixes: bd3127733f2c ("power: reset: at91-reset: use devm_of_iomap") Reported-by: Cristian Birsan <cristian.birsan@microchip.com> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18soundwire: debugfs: use controller id and link_id for debugfsSrinivas Kandagatla1-1/+1
[ Upstream commit 75eac387a2539aa6c6bbee3affa23435f2096396 ] link_id can be zero and if we have multiple controller instances in a system like Qualcomm debugfs will end-up with duplicate namespace resulting in incorrect debugfs entries. Using bus-id and link-id combination should give a unique debugfs directory entry and should fix below warning too. "debugfs: Directory 'master-0' with parent 'soundwire' already present!" Fixes: bf03473d5bcc ("soundwire: add debugfs support") Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210907105332.1257-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ALSA: usb-audio: Fix possible race at sync of urb completionsTakashi Iwai2-1/+7
[ Upstream commit 86a42ad07905110f82648853c0ea3434b4eab173 ] USB-audio driver tries to sync with the clear of all pending URBs in wait_clear_urbs(), and it waits for all bits in active_mask getting cleared. This works fine for the normal operations, but when a stream is managed in the implicit feedback mode, there is still a very thin race window: namely, in snd_complete_usb(), the active_mask bit for the current URB is once cleared before re-submitted in queue_pending_output_urbs(). If wait_clear_urbs() is called during that period, it may pass the test and go forward even though there may be a still pending URB. For covering it, this patch adds a new counter to each endpoint to keep the number of in-flight URBs, and changes wait_clear_urbs() checking this number instead. The counter is decremented at the end of URB complete, hence the reference is kept as long as the URB complete is in process. Link: https://lore.kernel.org/r/20210929080844.11583-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ALSA: hda: Use position buffer for SKL+ againTakashi Iwai1-22/+1
[ Upstream commit c4ca3871e21fa085096316f5f8d9975cf3dfde1d ] The commit f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+") changed the PCM position report for SKL+ chips to use DPIB, but according to Pierre, DPIB is no best choice for the accurate position reports and it often reports too early. The recommended method is rather the classical position buffer. This patch makes the PCM position reporting on SKL+ back to the position buffer again. Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+") Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210929072934.6809-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ALSA: hda: Reduce udelay() at SKL+ position reportingTakashi Iwai1-5/+23
[ Upstream commit 46243b85b0ec5d2cee7545e5ce18c015ce91957e ] The position reporting on Intel Skylake and later chips via azx_get_pos_skl() contains a udelay(20) call for the capture streams. A call for this alone doesn't sound too harmful. However, as the pointer PCM ops is one of the hottest path in the PCM operations -- especially for the timer-scheduled operations like PulseAudio -- such a delay hogs CPU usage significantly in the total performance. The code there was taken from the original code in ASoC SST Skylake driver blindly. The udelay() is a workaround for the case where the reported position is behind the period boundary at the timing triggered from interrupts; applications often expect that the full data is available for the whole period when returned (and also that's the definition of the ALSA PCM period). OTOH, HD-audio (legacy) driver has already some workarounds for the delayed position reporting due to its relatively large FIFO, such as the BDL position adjustment and the delayed period-elapsed call in the work. That said, the udelay() is almost superfluous for HD-audio driver unlike SST, and we can drop the udelay(). Though, the current code doesn't guarantee the full period readiness as mentioned in the above, but rather it checks the wallclock and detects the unexpected jump. That's one missing piece, and the drop of udelay() needs a bit more sanity checks for the delayed handling. This patch implements those: the drop of udelay() call in azx_get_pos_skl() and the more proper check of hwptr in azx_position_ok(). The latter change is applied only for the case where the stream is running in the normal mode without no_period_wakeup flag. When no_period_wakeup is set, it essentially ignores the period handling and rather concentrates only on the current position; which implies that we don't need to care about the period boundary at all. Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+") Reported-by: Jens Axboe <axboe@kernel.dk> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210929072934.6809-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iommu/dma: Fix arch_sync_dma for mapDavid Stevens1-9/+7
[ Upstream commit 06e620345d544e559b2961cb5a676ec9c80c8950 ] When calling arch_sync_dma, we need to pass it the memory that's actually being used for dma. When using swiotlb bounce buffers, this is the bounce buffer. Move arch_sync_dma into the __iommu_dma_map_swiotlb helper, so it can use the bounce buffer address if necessary. Now that iommu_dma_map_sg delegates to a function which takes care of architectural syncing in the untrusted device case, the call to iommu_dma_sync_sg_for_device can be moved so it only occurs for trusted devices. Doing the sync for untrusted devices before mapping never really worked, since it needs to be able to target swiotlb buffers. This also moves the architectural sync to before the call to __iommu_dma_map, to guarantee that untrusted devices can't see stale data they shouldn't see. Fixes: 82612d66d51d ("iommu: Allow the iommu/dma api to use bounce buffers") Signed-off-by: David Stevens <stevensd@chromium.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20210929023300.335969-3-stevensd@google.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iommu/dma: Fix sync_sg with swiotlbDavid Stevens1-20/+13
[ Upstream commit 08ae5d4a1ae96b72222e7b02d072bb997ff29dac ] The is_swiotlb_buffer function takes the physical address of the swiotlb buffer, not the physical address of the original buffer. The sglist contains the physical addresses of the original buffer, so for the sync_sg functions to work properly when a bounce buffer might have been used, we need to use iommu_iova_to_phys to look up the physical address. This is what sync_single does, so call that function on each sglist segment. The previous code mostly worked because swiotlb does the transfer on map and unmap. However, any callers which use DMA_ATTR_SKIP_CPU_SYNC with sglists or which call sync_sg would not have had anything copied to the bounce buffer. Fixes: 82612d66d51d ("iommu: Allow the iommu/dma api to use bounce buffers") Signed-off-by: David Stevens <stevensd@chromium.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20210929023300.335969-2-stevensd@google.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: qcom: pm8916: Remove wrong reg-names for rtc@6000Stephan Gerhold1-1/+0
[ Upstream commit 483de2b44cd3a168458f8f9ff237e78a434729bc ] While removing the size from the "reg" properties in pm8916.dtsi, commit bd6429e81010 ("ARM64: dts: qcom: Remove size elements from pmic reg properties") mistakenly also removed the second register address for the rtc@6000 device. That one did not represent the size of the register region but actually the address of the second "alarm" register region of the rtc@6000 device. Now there are "reg-names" for two "reg" elements, but there is actually only one "reg" listed. Since the DT schema for "qcom,pm8941-rtc" only expects one "reg" element anyway, just drop the "reg-names" entirely to fix this. Fixes: bd6429e81010 ("ARM64: dts: qcom: Remove size elements from pmic reg properties") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210928112945.25310-1-stephan@gerhold.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iommu/mediatek: Fix out-of-range warning with clangArnd Bergmann1-1/+3
[ Upstream commit f13efafc1a2cf30d4a74c00f40210d6de36db2d0 ] clang-14 notices that a comparison is never true when CONFIG_PHYS_ADDR_T_64BIT is disabled: drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of constant 5368709120 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE) ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add an explicit check for the type of the variable to skip the check and the warning in that case. Fixes: b4dad40e4f35 ("iommu/mediatek: Adjust the PA for the 4GB Mode") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20210927121857.941160-1-arnd@kernel.org Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: renesas: beacon: Fix Ethernet PHY modeGeert Uytterhoeven1-0/+1
[ Upstream commit 59a8bda062f8646d99ff8c4956adf37dee1cb75e ] While networking works fine in RGMII mode when using the Linux generic PHY driver, it fails when using the Atheros PHY driver. Fix this by correcting the Ethernet PHY mode to RGMII-RXID, which works fine with both drivers. Fixes: a5200e63af57d05e ("arm64: dts: renesas: rzg2: Convert EtherAVB to explicit delay handling") Reported-by: Adam Ford <aford173@gmail.com> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/2a4c15b2df23bb63f15abf9dfb88860477f4f523.1632465965.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: qcom: msm8916: Fix Secondary MI2S bit clockStephan Gerhold1-1/+7
[ Upstream commit 8199a0b31e76d158ac14841e7119890461f8c595 ] At the moment, playing audio on Secondary MI2S will just end up getting stuck, without actually playing any audio. This happens because the wrong bit clock is configured when playing audio on Secondary MI2S. The PRI_I2S_CLK (better name: SPKR_I2S_CLK) is used by the SPKR audio mux block that provides both Primary and Secondary MI2S. The SEC_I2S_CLK (better name: MIC_I2S_CLK) is used by the MIC audio mux block that provides Tertiary MI2S. Quaternary MI2S is also part of the MIC audio mux but has its own clock (AUX_I2S_CLK). This means that (quite confusingly) the SEC_I2S_CLK is not actually used for Secondary MI2S as the name would suggest. Secondary MI2S needs to have the same clock as Primary MI2S configured. Fix the clock list for the lpass node in the device tree and add a comment to clarify this confusing naming. With these changes, audio can be played correctly on Secondary MI2S. Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Fixes: 3761a3618f55 ("arm64: dts: qcom: add lpass node") Tested-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210816181810.2242-1-stephan@gerhold.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ASoC: wcd9335: Use correct version to initialize Class HYassine Oudjana1-1/+1
[ Upstream commit a270bd9abdc3cd04ec194f1f3164823cbb5a905c ] The versioning scheme was changed in an earlier patch, which caused the version being used to initialize WCD9335 to be interpreted as if it was WCD937X, which changed code paths causing broken headphones output. Pass WCD9335 instead of WCD9335_VERSION_2_0 to wcd_clsh_ctrl_alloc to fix it. Fixes: 19c5d1f6a0c3 ("ASoC: codecs: wcd-clsh: add new version support") Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20210925022339.786296-1-y.oudjana@protonmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18pinctrl: renesas: rzg2l: Fix missing port register 21hBiju Das1-1/+1
[ Upstream commit fcfb63148c241adad54ed99fc318167176d7254b ] Remove the duplicate port register 22h and replace it with missing port register 21h. Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20210922074140.22178-1-biju.das.jz@bp.renesas.com Fixes: c4c4637eb57f2a25 ("pinctrl: renesas: Add RZ/G2L pin and gpio controller driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18JFS: fix memleak in jfs_mountDongliang Mu1-29/+22
[ Upstream commit c48a14dca2cb57527dde6b960adbe69953935f10 ] In jfs_mount, when diMount(ipaimap2) fails, it goes to errout35. However, the following code does not free ipaimap2 allocated by diReadSpecial. Fix this by refactoring the error handling code of jfs_mount. To be specific, modify the lable name and free ipaimap2 when the above error ocurrs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18MIPS: loongson64: make CPU_LOONGSON64 depends on MIPS_FP_SUPPORTJackie Liu1-0/+1
[ Upstream commit 7f3b3c2bfa9c93ab9b5595543496f570983dc330 ] mach/loongson64 fails to build when the FPU support is disabled: arch/mips/loongson64/cop2-ex.c:45:15: error: implicit declaration of function ‘__is_fpu_owner’; did you mean ‘is_fpu_owner’? [-Werror=implicit-function-declaration] arch/mips/loongson64/cop2-ex.c:98:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:99:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:131:43: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:137:38: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:203:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:219:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:283:38: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:301:38: error: ‘struct thread_struct’ has no member named ‘fpu’ Fixes: ef2f826c8f2f ("MIPS: Loongson-3: Enable the COP2 usage") Suggested-by: Huacai Chen <chenhuacai@kernel.org> Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Reported-by: k2ci robot <kernel-bot@kylinos.cn> Signed-off-by: Jackie Liu <liuyun01@kylinos.cn> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18scsi: dc395: Fix error case unwindingTong Zhang1-0/+1
[ Upstream commit cbd9a3347c757383f3d2b50cf7cfd03eb479c481 ] dc395x_init_one()->adapter_init() might fail. In this case, the acb is already cleaned up by adapter_init(), no need to do that in adapter_uninit(acb) again. [ 1.252251] dc395x: adapter init failed [ 1.254900] RIP: 0010:adapter_uninit+0x94/0x170 [dc395x] [ 1.260307] Call Trace: [ 1.260442] dc395x_init_one.cold+0x72a/0x9bb [dc395x] Link: https://lore.kernel.org/r/20210907040702.1846409-1-ztong0001@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Finn Thain <fthain@linux-m68k.org> Signed-off-by: Tong Zhang <ztong0001@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: qcom: sc7280: fix display port phy reg propertyKuogee Hsieh1-6/+2
[ Upstream commit 425f30cc843c727bc7753a0d33710d1e4a999168 ] Existing display port phy reg property is derived from usb phy which map display port phy pcs to wrong address which cause aux init with wrong address and prevent both dpcd read and write from working. Fix this problem by assigning correct pcs address to display port phy reg property. Fixes: bb9efa59c665 ("arm64: dts: qcom: sc7280: Add USB related nodes") Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1631216998-10049-1-git-send-email-khsieh@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18soc: qcom: llcc: Disable MMUHWT retentionNaina Mehta1-1/+1
[ Upstream commit 3a461009e195c3c17f6af73da310b886991309fd ] Disable MMUHWT retention for SC7280 as done for other platforms to avoid more power burn. Fixes: f6a07be63301 ("soc: qcom: llcc: Add configuration data for SC7280") Signed-off-by: Naina Mehta <nainmeht@codeaurora.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210921055942.30600-1-saiprakash.ranjan@codeaurora.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: qcom: sc7180: Base dynamic CPU power coefficients in realityDouglas Anderson3-31/+31
[ Upstream commit 82ea7d411d43f60dce878252558e926f957109f0 ] The sc7180's dynamic-power-coefficient violates the device tree bindings. The bindings (arm/cpus.yaml) say that the units for the dynamic-power-coefficient are supposed to be "uW/MHz/V^2". The ones for sc7180 aren't this. Qualcomm arbitrarily picked 100 for the "little" CPUs and then picked a number for the big CPU based on this. At the time, there was a giant dicussion about this. Apparently Qualcomm Engineers were instructed not to share the actual numbers here. As part of the discussion, I pointed out [1] that these numbers shouldn't really be secret since once a device is shipping anyone can just run a script and produce them. This patch is the result of running the script I posted in that discussion on sc7180-trogdor-coachz, which is currently available for purchase by consumers. [1] https://lore.kernel.org/r/CAD=FV=U1FP0e3_AVHpauUUZtD-5X3XCwh5aT9fH_8S_FFML2Uw@mail.gmail.com/ I ran the script four times, measuring little, big, little, big. I used the 64-bit version of dhrystone 2.2 in my test. I got these results: 576 kHz, 596 mV, 20 mW, 88 Cx 768 kHz, 596 mV, 32 mW, 122 Cx 1017 kHz, 660 mV, 45 mW, 97 Cx 1248 kHz, 720 mV, 87 mW, 139 Cx 1324 kHz, 756 mV, 109 mW, 148 Cx 1516 kHz, 828 mV, 150 mW, 148 Cx 1612 kHz, 884 mV, 182 mW, 147 Cx 1708 kHz, 884 mV, 192 mW, 146 Cx 1804 kHz, 884 mV, 207 mW, 149 Cx Your dynamic-power-coefficient for cpu 0: 132 825 kHz, 596 mV, 142 mW, 401 Cx 979 kHz, 628 mV, 183 mW, 427 Cx 1113 kHz, 656 mV, 224 mW, 433 Cx 1267 kHz, 688 mV, 282 mW, 449 Cx 1555 kHz, 812 mV, 475 mW, 450 Cx 1708 kHz, 828 mV, 566 mW, 478 Cx 1843 kHz, 884 mV, 692 mW, 476 Cx 1900 kHz, 884 mV, 722 mW, 482 Cx 1996 kHz, 916 mV, 814 mW, 482 Cx 2112 kHz, 916 mV, 862 mW, 483 Cx 2208 kHz, 916 mV, 962 mW, 521 Cx 2323 kHz, 940 mV, 1060 mW, 517 Cx 2400 kHz, 956 mV, 1133 mW, 518 Cx Your dynamic-power-coefficient for cpu 6: 471 576 kHz, 596 mV, 26 mW, 103 Cx 768 kHz, 596 mV, 40 mW, 147 Cx 1017 kHz, 660 mV, 54 mW, 114 Cx 1248 kHz, 720 mV, 97 mW, 151 Cx 1324 kHz, 756 mV, 113 mW, 150 Cx 1516 kHz, 828 mV, 154 mW, 148 Cx 1612 kHz, 884 mV, 194 mW, 155 Cx 1708 kHz, 884 mV, 203 mW, 152 Cx 1804 kHz, 884 mV, 219 mW, 155 Cx Your dynamic-power-coefficient for cpu 0: 142 825 kHz, 596 mV, 148 mW, 530 Cx 979 kHz, 628 mV, 189 mW, 475 Cx 1113 kHz, 656 mV, 230 mW, 461 Cx 1267 kHz, 688 mV, 287 mW, 466 Cx 1555 kHz, 812 mV, 469 mW, 445 Cx 1708 kHz, 828 mV, 567 mW, 480 Cx 1843 kHz, 884 mV, 699 mW, 482 Cx 1900 kHz, 884 mV, 719 mW, 480 Cx 1996 kHz, 916 mV, 814 mW, 484 Cx 2112 kHz, 916 mV, 861 mW, 483 Cx 2208 kHz, 916 mV, 963 mW, 522 Cx 2323 kHz, 940 mV, 1063 mW, 520 Cx 2400 kHz, 956 mV, 1135 mW, 519 Cx Your dynamic-power-coefficient for cpu 6: 489 As you can see, the calculations aren't perfectly consistent but roughly you could say about 480 for big and 137 for little. The ratio between these numbers isn't quite the same as the ratio between the two numbers that Qualcomm used. Perhaps this is because Qualcomm measured something slightly different than the 64-bit version of dhrystone 2.2 or perhaps it's because they fudged these numbers a bit (and fudged the capacity-dmips-mhz). As per discussion [2], let's use the numbers I came up with and also un-fudge capacity-dmips-mhz. While unfudging capacity-dmips-mhz, let's scale it so that bigs are 1024 which seems to be the common practice. In general these numbers don't need to be perfectly exact. In fact, they can't be since the CPU power depends a lot on what's being run on the CPU and the big/little CPUs are each more or less efficient in different operations. Historically running the 32-bit vs. 64-bit versions of dhrystone produced notably different numbers, though I didn't test this time. We also need to scale all of the sustainable-power numbers by the same amount. I scale ones related to the big CPUs by the adjustment I made to the big dynamic-power-coefficient and the ones related to the little CPUs by the adjustment I made to the little dynamic-power-coefficient. [2] https://lore.kernel.org/r/0a865b6e-be34-6371-f9f2-9913ee1c5608@codeaurora.org/ Fixes: 71f873169a80 ("arm64: dts: qcom: sc7180: Add dynamic CPU power coefficients") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210902145127.v2.1.I049b30065f3c715234b6303f55d72c059c8625eb@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ARM: dts: at91: tse850: the emac<->phy interface is rmiiPeter Rosin1-1/+1
[ Upstream commit dcdbc335a91a26e022a803e1a6b837266989c032 ] This went unnoticed until commit 7897b071ac3b ("net: macb: convert to phylink") which tickled the problem. The sama5d3 emac has never been capable of rgmii, and it all just happened to work before that commit. Fixes: 21dd0ece34c2 ("ARM: dts: at91: add devicetree for the Axentia TSE-850") Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/ea781f5e-422f-6cbf-3cf4-d5a7bac9392d@axentia.se Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18bus: ti-sysc: Fix timekeeping_suspended warning on resumeTony Lindgren1-12/+53
[ Upstream commit b3e9431854e8f305385d5de225441c0477b936cb ] On resume we can get a warning at kernel/time/timekeeping.c:824 for timekeeping_suspended. Let's fix this by adding separate functions for sysc_poll_reset_sysstatus() and sysc_poll_reset_sysconfig() and have the new functions handle also timekeeping_suspended. If iopoll at some point supports timekeeping_suspended, we can just drop the custom handling from these functions. Fixes: d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit") Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: meson-sm1: Fix the pwm regulator supply propertiesAnand Moon4-4/+4
[ Upstream commit 0b26fa8a02c2834f1fa8a206a285b9f84c4ad764 ] After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VDDCPU pwm regulator to 12V regulator supply instead of dummy regulator. [ 11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property in node /regulator-vddcpu failed [ 11.602344] VDDCPU: supplied by regulator-dummy [ 11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT [ 11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled Fixes: 88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi") Fixes: 700ab8d83927 ("arm64: dts: khadas-vim3: add support for the SM1 based VIM3L") Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS") Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts") Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210919202918.3556-4-linux.amoon@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: meson-g12b: Fix the pwm regulator supply propertiesAnand Moon3-6/+6
[ Upstream commit 62183863f708c2464769e0d477c8ce9f3d326feb ] After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs. Changes help link VDDCP_A and VDDCPU_B pwm regulator to 12V regulator supply instead of dummy regulator. [ 4.147196] VDDCPU_A: will resolve supply early: pwm [ 4.147216] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply from device tree [ 4.147227] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply property in node /regulator-vddcpu-a failed [ 4.147258] VDDCPU_A: supplied by regulator-dummy [ 4.147288] regulator-dummy: could not add device link regulator.12: -ENOENT [ 4.147353] VDDCPU_A: 721 <--> 1022 mV at 871 mV, enabled [ 4.152014] VDDCPU_B: will resolve supply early: pwm [ 4.152035] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply from device tree [ 4.152047] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply property in node /regulator-vddcpu-b failed [ 4.152079] VDDCPU_B: supplied by regulator-dummy [ 4.152108] regulator-dummy: could not add device link regulator.13: -ENOENT Fixes: c6d29c66e582 ("arm64: dts: meson-g12b-khadas-vim3: add initial device-tree") Fixes: d14734a04a8a ("arm64: dts: meson-g12b-odroid-n2: enable DVFS") Fixes: 3cb74db9b256 ("arm64: dts: meson: convert ugoos-am6 to common w400 dtsi") Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210919202918.3556-3-linux.amoon@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: meson-g12a: Fix the pwm regulator supply propertiesAnand Moon3-3/+3
[ Upstream commit 085675117ecf5e02c4220698fd549024ec64ad2c ] After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VDDCPU pwm regulator to 12V regulator supply instead of dummy regulator. [ 11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property in node /regulator-vddcpu failed [ 11.602344] VDDCPU: supplied by regulator-dummy [ 11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT [ 11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled Fixes: e9bc0765cc12 ("arm64: dts: meson-g12a: enable DVFS on G12A boards") Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20210919202918.3556-2-linux.amoon@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: ti: j7200-main: Fix "bus-range" upto 256 bus number for PCIeKishon Vijay Abraham I1-1/+1
[ Upstream commit 8bb8429290c0043a78804ae48294b53f781ee426 ] commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added PCIe bus numbers from 0 to 15 (copy-paste from J721E node). Enable all the supported bus numbers from 0 to 255 defined in PCIe spec here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-5-kishon@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: ti: j7200-main: Fix "vendor-id"/"device-id" properties of pcie nodeKishon Vijay Abraham I1-2/+2
[ Upstream commit 0d553792726a61ced760422e74ea67552ac69cdb ] commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added "vendor-id" and "device-id" as 16-bit properties though both of them are 32-bit properties. Fix it here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-4-kishon@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: ti: k3-j721e-main: Fix "bus-range" upto 256 bus number for PCIeKishon Vijay Abraham I1-4/+4
[ Upstream commit 5f46633565b1c1e1840a927676065d72b442dac4 ] commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") restricted PCIe bus numbers from 0 to 15 (due to SMMU restriction in J721E). However since SMMU is not enabled, allow the full supported bus numbers from 0 to 255. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-3-kishon@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: ti: k3-j721e-main: Fix "max-virtual-functions" in PCIe EP nodesKishon Vijay Abraham I1-4/+4
[ Upstream commit 9af3ef954975c383eeb667aee207d9ce6fbef8c4 ] commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") added "max-virtual-functions" to have 16 bit values. Fix "max-virtual-functions" in PCIe endpoint (EP) nodes to have 8 bit values instead of 16. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20210915055358.19997-2-kishon@ti.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18RDMA/bnxt_re: Fix query SRQ failureSelvin Xavier1-1/+2
[ Upstream commit 598d16fa1bf93431ad35bbab3ed1affe4fb7b562 ] Fill the missing parameters for the FW command while querying SRQ. Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") Link: https://lore.kernel.org/r/1631709163-2287-8-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ARM: dts: qcom: msm8974: Add xo_board reference clock to DSI0 PHYMarijn Suijten1-2/+2
[ Upstream commit 8ccecf6c710b8c048eecc65709640642e5357d6e ] According to YAML validation, and for a future patchset putting this xo_board reference clock to use as VCO reference parent, add the missing clock to dsi_phy0. Fixes: 5a9fc531f6ec ("ARM: dts: msm8974: add display support") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210830175739.143401-1-marijn.suijten@somainline.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: rockchip: Fix GPU register width for RK3328Alex Bee1-1/+1
[ Upstream commit 932b4610f55b49f3a158b0db451137bab7ed0e1f ] As can be seen in RK3328's TRM the register range for the GPU is 0xff300000 to 0xff330000. It would (and does in vendor kernel) overlap with the registers of the HEVC encoder (node/driver do not exist yet in upstream kernel). See already existing h265e_mmu node. Fixes: 752fbc0c8da7 ("arm64: dts: rockchip: add rk3328 mali gpu node") Signed-off-by: Alex Bee <knaerzche@gmail.com> Link: https://lore.kernel.org/r/20210623115926.164861-1-knaerzche@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ARM: s3c: irq-s3c24xx: Fix return value check for s3c24xx_init_intc()Jackie Liu1-4/+18
[ Upstream commit 2aa717473ce96c93ae43a5dc8c23cedc8ce7dd9f ] The s3c24xx_init_intc() returns an error pointer upon failure, not NULL. let's add an error pointer check in s3c24xx_handle_irq. s3c_intc[0] is not NULL or ERR, we can simplify the code. Fixes: 1f629b7a3ced ("ARM: S3C24XX: transform irq handling into a declarative form") Signed-off-by: Jackie Liu <liuyun01@kylinos.cn> Link: https://lore.kernel.org/r/20210901123557.1043953-1-liu.yun@linux.dev Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18scsi: lpfc: Fix NVMe I/O failover to non-optimized pathJames Smart1-0/+1
[ Upstream commit b507357f79171fb4fb4e732ca43a1f30bc5aab1d ] Currently, we hold off unregistering with NVMe transport layer until GID_FT or ADISC completes upon receipt of RSCN. In the ADISC discovery routine, for nodes not found in the GID_FT response, the nodes are unregistered from the SCSI transport but not UNREG_RPI'd. Meaning outstanding WQEs continue to be outstanding and were not failed back to the OS. If an NVMe device, this mean there wasn't initial termination of the I/Os so they could be issued on a different NVMe path. Fix by unregistering the RPI so that I/O is cancelled. Link: https://lore.kernel.org/r/20210910233159.115896-8-jsmart2021@gmail.com Fixes: 0614568361b0 ("scsi: lpfc: Delay unregistering from transport until GIDFT or ADISC completes") Co-developed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: James Smart <jsmart2021@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18scsi: qla2xxx: edif: Use link event to wake up appQuinn Tran1-8/+7
[ Upstream commit 527d46e0b0147f2b32b78ba49c6a231835b24a41 ] Authentication application may be running and in the past tried to probe driver (app_start) but was unsuccessful. This could be due to the bsg layer not being ready to service the request. On a successful link up, driver will use the netlink Link Up event to notify the app to retry the app_start call. In another case, app does not poll for new NPIV host. This link up event would notify app of the presence of a new SCSI host. Link: https://lore.kernel.org/r/20210908164622.19240-6-njavali@marvell.com Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF") Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Quinn Tran <qutran@marvell.com> Signed-off-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18scsi: pm80xx: Fix lockup in outbound queue managementAjish Koshy2-11/+45
[ Upstream commit b27a40534ef76a22628a5c12f98ea489823a8ba5 ] Commit 1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue processing") introduced a lock per outbound queue. Prior to that change the driver was using a global lock for all outbound queues. While processing the I/O responses and events the driver takes the outbound queue spinlock and is supposed to release it in pm8001_ccb_task_free_done() before calling command done(). Since the older code was using a global lock, pm8001_ccb_task_free_done() was releasing the global spin lock. The change that split the lock per outbound queue did not consider this and pm8001_ccb_task_free_done() was still releasing the global lock. Link: https://lore.kernel.org/r/20210906170404.5682-3-Ajish.Koshy@microchip.com Fixes: 1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue processing") Acked-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Ajish Koshy <Ajish.Koshy@microchip.com> Signed-off-by: Viswas G <Viswas.G@microchip.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18clk: mvebu: ap-cpu-clk: Fix a memory leak in error handling pathsChristophe JAILLET1-3/+11
[ Upstream commit af9617b419f77cf0b99702a7b2b0519da0d27715 ] If we exit the for_each_of_cpu_node loop early, the reference on the current node must be decremented, otherwise there is a leak. Fixes: f756e362d938 ("clk: mvebu: add CPU clock driver for Armada 7K/8K") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/545df946044fc1fc05a4217cdf0054be7a79e49e.1619161112.git.christophe.jaillet@wanadoo.fr Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: broadcom: bcm4908: Fix UART clock nameRafał Miłecki1-1/+1
[ Upstream commit 6c38c39ab2141f53786d73e706675e8819a3f2cb ] According to the binding the correct clock name is "refclk". Fixes: 2961f69f151c ("arm64: dts: broadcom: add BCM4908 and Asus GT-AC5300 early DTS files") Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18ARM: dts: BCM5301X: Fix memory nodes namesRafał Miłecki11-11/+11
[ Upstream commit c5e1df3276d7a500678da9453be31a66ad115150 ] Thix fixes: arch/arm/boot/dts/bcm4708-netgear-r6250.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 402653184]]} arch/arm/boot/dts/bcm4709-linksys-ea9200.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-netgear-r7000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-netgear-r8000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]} arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 402653184]]} arch/arm/boot/dts/bcm53016-meraki-mr32.dt.yaml: /: memory: False schema does not allow {'reg': [[0, 134217728]], 'device_type': ['memory']} arch/arm/boot/dts/bcm94708.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]} arch/arm/boot/dts/bcm94709.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]} Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18RDMA/rxe: Fix wrong port_cap_flagsJunji Wei1-1/+1
[ Upstream commit dcd3f985b20ffcc375f82ca0ca9f241c7025eb5e ] The port->attr.port_cap_flags should be set to enum ib_port_capability_mask_bits in ib_mad.h, not RDMA_CORE_CAP_PROT_ROCE_UDP_ENCAP. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210831083223.65797-1-weijunji@bytedance.com Signed-off-by: Junji Wei <weijunji@bytedance.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18iio: st_sensors: disable regulators after device unregistrationAlexandru Ardelean8-16/+16
[ Upstream commit 9f0b3e0cc0c88618aa9e5cecef747b1337ae0a5d ] Up until commit ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") only the ST pressure driver seems to have had any regulator disable. After that commit, the regulator handling was moved into the common st_sensors logic. In all instances of this regulator handling, the regulators were disabled before unregistering the IIO device. This can cause issues where the device would be powered down and still be available to userspace, allowing it to send invalid/garbage data. This change moves the st_sensors_power_disable() after the common probe functions. These common probe functions also handle unregistering the IIO device. Fixes: 774487611c949 ("iio: pressure-core: st: Provide support for the Vdd power supply") Fixes: ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") Cc: Lee Jones <lee.jones@linaro.org> Cc: Denis CIOCCA <denis.ciocca@st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Alexandru Ardelean <aardelean@deviqon.com> Link: https://lore.kernel.org/r/20210823112204.243255-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18arm64: dts: meson: sm1: add Ethernet PHY reset line for ODROID-C4/HC4Dongjin Kim1-0/+4
[ Upstream commit 9d02214f8332d5dbbcce3d6c5c915e54d43a0c46 ] This patch is to fix an issue that the ethernet link doesn't come up when using ip link set down/up: [ 11.428114] meson8b-dwmac ff3f0000.ethernet eth0: Link is Down [ 14.428595] meson8b-dwmac ff3f0000.ethernet eth0: PHY [0.0:00] driver [RTL8211F Gigabit Ethernet] (irq=31) [ 14.428610] meson8b-dwmac ff3f0000.ethernet: Failed to reset the dma [ 14.428974] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed [ 14.711185] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_open: Hw setup failed This fix refers to two commits applied for ODROID-N2 (G12B). commit 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY reset line") commit 1c7412530d5d0 ("arm64: dts: meson: g12b: odroid-n2: fix PHY deassert timing requirements") Fixes: 88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi") Signed-off-by: Dongjin Kim <tobetter@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [narmstrong: added fixes tag and typo in commit log] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/YScKYFWlYymgGw3l@anyang-linuxfactory-or-kr Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18staging: r8188eu: fix memory leak in rtw_set_keyPavel Skripkin1-0/+2
[ Upstream commit 393db0f6827f96054a769ba3a38aa382d137d3c7 ] Before returning with an error we should free allocated buffers, since they are not assigned to anywhere. Fixes: 15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/ee783fbb71abb549505b84542223be7a7c905eea.1630692375.git.paskripkin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18cpufreq: Fix parameter in parse_perf_domain()Hector.Yuan1-1/+1
[ Upstream commit 4a08e3271c55f8b5d56906a8aa5bd041911cf897 ] Pass cpu to parse_perf_domain() instead of pcpu. Fixes: 8486a32dd484 ("cpufreq: Add of_perf_domain_get_sharing_cpumask") Signed-off-by: Hector.Yuan <hector.yuan@mediatek.com> [ Viresh: Massaged changelog ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18of: unittest: fix EXPECT text for gpio hog errorsFrank Rowand1-8/+8
[ Upstream commit e85860e5bc077865a04f0a88d0b0335d3200484a ] The console message text for gpio hog errors does not match what unittest expects. Fixes: f4056e705b2ef ("of: unittest: add overlay gpio test to catch gpio hog problem") Signed-off-by: Frank Rowand <frank.rowand@sony.com> Link: https://lore.kernel.org/r/20211029013225.2048695-1-frowand.list@gmail.com Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18bpf: Fix propagation of signed bounds from 64-bit min/max into 32-bit.Alexei Starovoitov1-1/+1
[ Upstream commit 388e2c0b978339dee9b0a81a2e546f8979e021e2 ] Similar to unsigned bounds propagation fix signed bounds. The 'Fixes' tag is a hint. There is no security bug here. The verifier was too conservative. Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20211101222153.78759-2-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18bpf: Fix propagation of bounds from 64-bit min/max into 32-bit and var_off.Alexei Starovoitov2-2/+2
[ Upstream commit b9979db8340154526d9ab38a1883d6f6ba9b6d47 ] Before this fix: 166: (b5) if r2 <= 0x1 goto pc+22 from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0xffffffff)) After this fix: 166: (b5) if r2 <= 0x1 goto pc+22 from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0x1)) While processing BPF_JLE the reg_set_min_max() would set true_reg->umax_value = 1 and call __reg_combine_64_into_32(true_reg). Without the fix it would not pass the condition: if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_value)) since umin_value == 0 at this point. Before commit 10bf4e83167c the umin was incorrectly ingored. The commit 10bf4e83167c fixed the correctness issue, but pessimized propagation of 64-bit min max into 32-bit min max and corresponding var_off. Fixes: 10bf4e83167c ("bpf: Fix propagation of 32 bit unsigned bounds from 64 bit bounds") Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20211101222153.78759-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-11-18cgroup: Fix rootcg cpu.stat guest double countingDan Schatzberg1-2/+0
[ Upstream commit 81c49d39aea8a10e6d05d3aa1cb65ceb721e19b0 ] In account_guest_time in kernel/sched/cputime.c guest time is attributed to both CPUTIME_NICE and CPUTIME_USER in addition to CPUTIME_GUEST_NICE and CPUTIME_GUEST respectively. Therefore, adding both to calculate usage results in double counting any guest time at the rootcg. Fixes: 936f2a70f207 ("cgroup: add cpu.stat file to root cgroup") Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-04 16:58:11 +0300