- 10 Dec, 2020 1 commit
-
-
Vidya Sagar authored
Set DMA mask to 32-bit while allocating the MSI target address so that the address is usable for both 32-bit and 64-bit MSI capable devices. Throw a warning if it fails to set the mask to 32-bit to alert that devices that are only 32-bit MSI capable may not work properly. Link: https://lore.kernel.org/r/20201117165312.25847-1-vidyas@nvidia.comSigned-off-by:
Vidya Sagar <vidyas@nvidia.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Robin Murphy <robin.murphy@arm.com>
-
- 09 Dec, 2020 1 commit
-
-
Manivannan Sadhasivam authored
For SM8250, we need to write the BDF to SID mapping in PCIe controller register space for proper working. This is accomplished by extracting the BDF and SID values from "iommu-map" property in DT and writing those in the register address calculated from the hash value of BDF. In case of collisions, the index of the next entry will also be written. For the sake of it, let's introduce a "config_sid" callback and do it conditionally for SM8250. Link: https://lore.kernel.org/r/20201208121402.178011-4-mani@kernel.orgSigned-off-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org>
-
- 08 Dec, 2020 2 commits
-
-
Manivannan Sadhasivam authored
The PCIe IP (rev 1.9.0) on SM8250 SoC is similar to the one used on SDM845. Hence the support is added reusing the members of ops_2_7_0. The key difference between ops_2_7_0 and ops_1_9_0 is the config_sid callback, which will be added in successive commit. Link: https://lore.kernel.org/r/20201208121402.178011-3-mani@kernel.orgSigned-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Manivannan Sadhasivam authored
Document the PCIe DT bindings for SM8250 SoC. The PCIe IP is similar to the one used on SDM845, hence just add the compatible along with the optional "atu" register region. Link: https://lore.kernel.org/r/20201208121402.178011-2-mani@kernel.orgSigned-off-by:
-
- 07 Dec, 2020 5 commits
-
-
Vidya Sagar authored
PCIe cards like Marvell SATA controller and some of the Samsung NVMe drives don't support taking the link to L2 state. When the link doesn't go to L2 state, Tegra194 requires the LTSSM to be disabled to allow PHY to start the next link up process cleanly during suspend/resume sequence. Failing to disable LTSSM results in the PCIe link not coming up in the next resume cycle. Link: https://lore.kernel.org/r/20201203133451.17716-6-vidyas@nvidia.comTested-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Vidya Sagar authored
The return value of tegra_pcie_init_controller() must be checked before PCIe link up check and registering debugfs entries subsequently as it doesn't make sense to do these when the controller initialization itself has failed. Link: https://lore.kernel.org/r/20201203133451.17716-5-vidyas@nvidia.comTested-by:
-
Vidya Sagar authored
Currently the driver checks for error value of different APIs during the uninitialization sequence. It just returns from there if there is any error observed for one of those calls. Comparatively it is better to continue the uninitialization sequence irrespective of whether some of them are returning error. That way, it is more closer to complete uninitialization. Link: https://lore.kernel.org/r/20201203133451.17716-4-vidyas@nvidia.comTested-by:
-
Vidya Sagar authored
Set the DesignWare IP version for Tegra194 to 0x490A. This would be used by the DesigWare sub-system to do any version specific configuration (Ex:- TD bit programming for ECRC). Link: https://lore.kernel.org/r/20201203133451.17716-3-vidyas@nvidia.comTested-by:
-
Vidya Sagar authored
If the absence of CLKREQ# signal is indicated by the absence of "supports-clkreq" in the device-tree node, current driver is disabling the advertisement of ASPM-L1 Sub-States *before* the ASPM-L1 Sub-States offset is correctly initialized. Since default value of the ASPM-L1SS offset is zero, this is causing the Vendor-ID wrongly programmed to 0x10d2 instead of Nvidia's 0x10de thereby the quirks applicable for Tegra194 are not being applied. This patch fixes this issue by refactoring the code that disables the ASPM-L1SS advertisement. Link: https://lore.kernel.org/r/20201203133451.17716-2-vidyas@nvidia.com Fixes: 56e15a23 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by:
-
- 01 Dec, 2020 3 commits
-
-
Vidya Sagar authored
PCIe controller in Tegra194 requires the "dbi" region base address to be programmed in one of the application logic registers to enable CPU access to the "dbi" region. But, commit a0fd361d ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code") moved the code that reads the whereabouts of "dbi" region to the common code causing the existing code in pcie-tegra194.c file to program NULL in the application logic registers. This is causing null pointer dereference when the "dbi" registers are accessed. This issue is fixed by explicitly reading the "dbi" base address from DT node. Link: https://lore.kernel.org/r/20201125192554.5401-1-vidyas@nvidia.com Fixes: a0fd361d ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code") Tested-by:
-
Vidya Sagar authored
commit a0fd361d ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code") moved the code that sets up dbi_base to DWC common code thereby creating a requirement to not access the "dbi" region before calling common DWC initialization code. But, Tegra194 already had some code that programs some of the "dbi" registers resulting in system crash. This patch addresses that issue by refactoring the code to have accesses to the "dbi" region only after common DWC initialization. Link: https://lore.kernel.org/r/20201125192234.2270-1-vidyas@nvidia.com Fixes: a0fd361d ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code") Tested-by:
-
Jaehoon Chung authored
Exynos5440 SoC support has been dropped since commit 8c83315d ("ARM: dts: exynos: Remove Exynos5440"). Rework this driver to support DWC PCIe variant found in the Exynos5433 SoCs. The main difference in Exynos5433 variant is lack of the MSI support (the MSI interrupt is not even routed to the CPU). [mszyprow: reworked the driver to support only Exynos5433 variant, simplified code, rebased onto current kernel code, added regulator support, converted to the regular platform driver, removed MSI related code, rewrote commit message, added help] Link: https://lore.kernel.org/r/20201113170139.29956-6-m.szyprowski@samsung.comSigned-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
Jingoo Han <jingoohan1@gmail.com>
-
- 23 Nov, 2020 4 commits
-
-
Jaehoon Chung authored
Exynos5440 SoC support has been dropped since commit 8c83315d ("ARM: dts: exynos: Remove Exynos5440"). Rework this driver to support PCIe PHY variant found in the Exynos5433 SoCs. [mszyprow: reworked the driver to support only Exynos5433 variant, rebased onto current kernel code, rewrote commit message] Acked-By:
Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20201113170139.29956-5-m.szyprowski@samsung.comSigned-off-by:
-
Marek Szyprowski authored
Add dt-bindings for the Samsung Exynos PCIe PHY controller (Exynos5433 variant). Based on the text dt-binding posted by Jaehoon Chung. Link: https://lore.kernel.org/r/20201113170139.29956-4-m.szyprowski@samsung.comSigned-off-by:
-
Marek Szyprowski authored
Add dt-bindings for the Samsung Exynos PCIe controller (Exynos5433 variant). Based on the text dt-binding posted by Jaehoon Chung. Link: https://lore.kernel.org/r/20201113170139.29956-3-m.szyprowski@samsung.comSigned-off-by:
-
Marek Szyprowski authored
Exynos5440 SoC support has been dropped since commit 8c83315d ("ARM: dts: exynos: Remove Exynos5440"). Drop the obsolete bindings for exynos5440-pcie. Link: https://lore.kernel.org/r/20201113170139.29956-2-m.szyprowski@samsung.comSigned-off-by:
-
- 19 Nov, 2020 15 commits
-
-
Rob Herring authored
Currently the number of inbound and outbound iATU windows are determined from DT properties. Unfortunately, there's 'num-viewport' for RC mode and 'num-ib-windows' and 'num-ob-windows' for EP mode, yet the number of windows is not mode dependent. Also, 'num-viewport' is not clear whether that's inbound, outbound or both. We can probably assume it's outbound windows as that's all RC mode uses. However, using DT properties isn't really needed as the number of regions can be detected at runtime by poking the iATU registers. The basic algorithm is just writing a target address and reading back what we wrote. In the unrolled ATU case, we have to take care not to go past the mapped region. With this, we can drop num_viewport in favor of num_ob_windows instead. Link: https://lore.kernel.org/r/20201105211159.1814485-17-robh@kernel.orgTested-by:
-
Rob Herring authored
The number of inbound and outbound windows are defined by the h/w and apply to both RC and EP modes, so move them to the appropriate struct. Link: https://lore.kernel.org/r/20201105211159.1814485-16-robh@kernel.orgTested-by:
-
Rob Herring authored
This reverts commit 421063ef. In preparation to detect the number of iATU regions instead of using DT properties, we need to keep reading 'num-viewport' for the Keystone driver which doesn't use the iATU in older versions of the IP. However, note that Keystone has been broken for some time with upstream dts files which don't set 'num-viewports'. The reverted commit did make the property optional, but now it's mandatory again. Link: https://lore.kernel.org/r/20201105211159.1814485-15-robh@kernel.orgTested-by:
-
Rob Herring authored
Many calls to dw_pcie_host_init() are in a wrapper function with nothing else now. Let's remove the pointless extra layer. Link: https://lore.kernel.org/r/20201105211159.1814485-14-robh@kernel.orgTested-by:
-
Rob Herring authored
All RC complex drivers must call dw_pcie_setup_rc(). The ordering of the call shouldn't be too important other than being after any RC resets. There's a few calls of dw_pcie_setup_rc() left as drivers implementing suspend/resume need it. Link: https://lore.kernel.org/r/20201105211159.1814485-13-robh@kernel.orgTested-by:
-
Rob Herring authored
The host drivers which call dw_pcie_msi_init() are all the ones using the built-in MSI controller, so let's move it into the common DWC code. Link: https://lore.kernel.org/r/20201105211159.1814485-12-robh@kernel.orgTested-by:
-
Rob Herring authored
All the DWC drivers do link setup and checks at roughly the same time. Let's use the existing .start_link() hook (currently only used in EP mode) and move the link handling to the core code. The behavior for a link down was inconsistent as some drivers would fail probe in that case while others succeed. Let's standardize this to succeed as there are usecases where devices (and the link) appear later even without hotplug. For example, a reconfigured FPGA device. Link: https://lore.kernel.org/r/20201105211159.1814485-11-robh@kernel.orgTested-by:
-
Rob Herring authored
There are 3 possible MSI implementations for the DWC host. The first is using the built-in DWC MSI controller. The 2nd is a custom MSI controller as part of the PCI host (keystone only). The 3rd is an external MSI controller (typically GICv3 ITS). Currently, the last 2 are distinguished with a .msi_host_init() hook with the 3rd option using an empty function. However we can detect the 3rd case with the presence of 'msi-parent' or 'msi-map' properties, so let's do that instead and remove the empty functions. Link: https://lore.kernel.org/r/20201105211159.1814485-10-robh@kernel.orgTested-by:
-
Rob Herring authored
Platforms using the built-in DWC MSI controller all have a dedicated interrupt with "msi" name or at index 0, so let's move setting up the interrupt to the common DWC code. spear13xx and dra7xx are the 2 oddballs with muxed interrupts, so we need to prevent configuring the MSI interrupt by setting msi_irq to negative. Link: https://lore.kernel.org/r/20201105211159.1814485-9-robh@kernel.orgTested-by:
-
Rob Herring authored
There's no reason for the .set_num_vectors() host op. Drivers needing a non-default value can just initialize pcie_port.num_vectors directly. Link: https://lore.kernel.org/r/20201105211159.1814485-8-robh@kernel.orgTested-by:
-
Rob Herring authored
The dra7xx MSI irq_chip implementation is identical to the default DWC one. The only difference is the interrupt handler as the MSI interrupt is muxed with other interrupts, but that doesn't affect the irq_chip part of it. Link: https://lore.kernel.org/r/20201105211159.1814485-7-robh@kernel.orgTested-by:
-
Rob Herring authored
The Layerscape driver clears the ATU registers which may have been configured by the bootloader. Any driver could have the same issue and doing it for all drivers doesn't hurt, so let's move it into the common DWC code. Link: https://lore.kernel.org/r/20201105211159.1814485-6-robh@kernel.orgTested-by:
-
Rob Herring authored
Remove some of the pointless levels of functions that just wrap or group a series of other functions. Link: https://lore.kernel.org/r/20201105211159.1814485-5-robh@kernel.orgTested-by:
-
Rob Herring authored
Most DWC drivers use the common register resource names "dbi", "dbi2", and "addr_space", so let's move their setup into the DWC common code. This means 'dbi_base' in particular is setup later, but it looks like no drivers touch DBI registers before dw_pcie_host_init or dw_pcie_ep_init. Link: https://lore.kernel.org/r/20201105211159.1814485-4-robh@kernel.orgTested-by:
-
Rob Herring authored
The ATU offset should be a register range in DT called 'atu', not driver match data. Any future platforms with a different ATU offset should add it to their DT. This is also in preparation to do DBI resource setup in the core DWC code, so let's move setting atu_base later in intel_pcie_rc_setup(). Link: https://lore.kernel.org/r/20201105211159.1814485-3-robh@kernel.orgTested-by:
-
- 18 Nov, 2020 3 commits
-
-
Vidya Sagar authored
Add support to program the ATU to enable translations for >4GB sizes of the prefetchable memory apertures. Link: https://lore.kernel.org/r/20201118144626.32189-3-vidyas@nvidia.comTested-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Vidya Sagar authored
As per PCIe spec r5.0, sec 7.5.1.3.8 only 32-bit BAR registers are defined for non-prefetchable memory and hence a warning should be reported when the size of them go beyond 32-bits. Link: https://lore.kernel.org/r/20201118144626.32189-2-vidyas@nvidia.comTested-by:
-
Rob Herring authored
The current ATU setup only supports a single memory resource which isn't sufficient if there are also prefetchable memory regions. In order to support multiple memory regions, we need to move away from fixed ATU slots and rework the assignment. As there's always an ATU entry for config space, let's assign index 0 to config space. Then we assign memory resources to index 1 and up. Finally, if we have an I/O region and slots remaining, we assign the I/O region last. If there aren't remaining slots, we keep the same config and I/O space sharing. Link: https://lore.kernel.org/r/20201026181652.418729-1-robh@kernel.orgTested-by:
-
- 09 Nov, 2020 1 commit
-
-
Linus Torvalds authored
-
- 08 Nov, 2020 5 commits
-
-
Linus Torvalds authored
Merge tag 'driver-core-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core documentation fixes from Greg KH: "Some small Documentation fixes that were fallout from the larger documentation update we did in 5.10-rc2. Nothing major here at all, but all of these have been in linux-next and resolve build warnings when building the documentation files" * tag 'driver-core-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: Documentation: remove mic/index from misc-devices/index.rst scripts: get_api.pl: Add sub-titles to ABI output scripts: get_abi.pl: Don't let ABI files to create subtitles docs: leds: index.rst: add a missing file docs: ABI: sysfs-class-net: fix a typo docs: ABI: sysfs-driver-dma-ioatdma: what starts with /sys
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty/serial fixes from Greg KH: "Here are a small number of small tty and serial fixes for some reported problems for the tty core, vt code, and some serial drivers. They include fixes for: - a buggy and obsolete vt font ioctl removal - 8250_mtk serial baudrate runtime warnings - imx serial earlycon build configuration fix - txx9 serial driver error path cleanup issues - tty core fix in release_tty that can be triggered by trying to bind an invalid serial port name to a speakup console device Almost all of these have been in linux-next without any problems, the only one that hasn't, just deletes code :)" * tag 'tty-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: vt: Disable KD_FONT_OP_COPY tty: fix crash in release_tty if tty->port is not set serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init tty: serial: imx: enable earlycon by default if IMX_SERIAL_CONSOLE is enabled serial: 8250_mtk: Fix uart_get_baud_rate warning -
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are some small USB fixes and new device ids: - USB gadget fixes for some reported issues - Fixes for the ever-troublesome apple fastcharge driver, hopefully we finally have it right. - More USB core quirks for odd devices - USB serial driver fixes for some long-standing issues that were recently found - some new USB serial driver device ids All have been in linux-next with no reported issues" * tag 'usb-5.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: USB: apple-mfi-fastcharge: fix reference leak in apple_mfi_fc_set_property usb: mtu3: fix panic in mtu3_gadget_stop() USB: serial: option: add Telit FN980 composition 0x1055 USB: serial: option: add LE910Cx compositions 0x1203, 0x1230, 0x1231 USB: serial: cyberjack: fix write-URB completion race USB: Add NO_LPM quirk for Kingston flash drive USB: serial: option: add Quectel EC200T module support usb: raw-gadget: fix memory leak in gadget_setup usb: dwc2: Avoid leaving the error_debugfs label unused usb: dwc3: ep0: Fix delay status handling usb: gadget: fsl: fix null pointer checking usb: gadget: goku_udc: fix potential crashes in probe usb: dwc3: pci: add support for the Intel Alder Lake-S -
Eddy Wu authored
current->group_leader->exit_signal may change during copy_process() if current->real_parent exits. Move the assignment inside tasklist_lock to avoid the race. Signed-off-by:
Eddy Wu <eddy_wu@trendmicro.com> Acked-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Daniel Vetter authored
It's buggy: On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote: > We recently discovered a slab-out-of-bounds read in fbcon in the latest > kernel ( v5.10-rc2 for now ). The root cause of this vulnerability is that > "fbcon_do_set_font" did not handle "vc->vc_font.data" and > "vc->vc_font.height" correctly, and the patch > <https://lkml.org/lkml/2020/9/27/223> for VT_RESIZEX can't handle this > issue. > > Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and > use KD_FONT_OP_SET again to set a large font.height for tty1. After that, > we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data > in "fbcon_do_set_font", while tty1 retains the original larger > height. Obviously, this will cause an out-of-bounds read, because we can > access a smaller vc_font.data with a larger vc_font.height. Further there was only one user ever. - Android's loadfont, busybox and console-tools only ever use OP_GET and OP_SET - fbset documentation only mentions the kernel cmdline font: option, not anything else. - systemd used OP_COPY before release 232 published in Nov 2016 Now unfortunately the crucial report seems to have gone down with gmane, and the commit message doesn't say much. But the pull request hints at OP_COPY being broken https://github.com/systemd/systemd/pull/3651 So in other words, this never worked, and the only project which foolishly every tried to use it, realized that rather quickly too. Instead of trying to fix security issues here on dead code by adding missing checks, fix the entire thing by removing the functionality. Note that systemd code using the OP_COPY function ignored the return value, so it doesn't matter what we're doing here really - just in case a lone server somewhere happens to be extremely unlucky and running an affected old version of systemd. The relevant code from font_copy_to_all_vcs() in systemd was: /* copy font from active VT, where the font was uploaded to */ cfo.op = KD_FONT_OP_COPY; cfo.height = vcs.v_active-1; /* tty1 == index 0 */ (void) ioctl(vcfd, KDFONTOP, &cfo); Note this just disables the ioctl, garbage collecting the now unused callbacks is left for -next. v2: Tetsuo found the old mail, which allowed me to find it on another archive. Add the link too. Acked-by:
Peilin Ye <yepeilin.cs@gmail.com> Reported-by:
Minh Yuan <yuanmingbuaa@gmail.com> References: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html References: https://github.com/systemd/systemd/pull/3651 Cc: Greg KH <greg@kroah.com> Cc: Peilin Ye <yepeilin.cs@gmail.com> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://lore.kernel.org/r/20201108153806.3140315-1-daniel.vetter@ffwll.chSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
