- 24 May, 2022 1 commit
-
-
Martin Kepplinger authoredmarked as "hack" because we don't yet know what exactly broke the shutdown callback. For Linux v5.18-rc1 and later, the below regulator underflows happen when shutting down. Remove the shutdown callback from the driver to work around this. [ 1584.383268] ------------[ cut here ]------------ [ 1584.388285] unbalanced disables for LCD_AVEE [ 1584.392955] WARNING: CPU: 2 PID: 1 at drivers/regulator/core.c:2852 _regulator_disable+0xdc/0x194 [ 1584.619168] Call trace: [ 1584.621656] _regulator_disable+0xdc/0x194 [ 1584.625797] regulator_disable+0x48/0x8c [ 1584.629733] mantix_unprepare+0x50/0x94 [ 1584.633637] drm_panel_unprepare+0x34/0x50 [ 1584.637794] mantix_shutdown+0x2c/0x44 [ 1584.641579] mipi_dsi_drv_shutdown+0x2c/0x40 [ 1584.645895] device_shutdown+0x160/0x340 [ 1584.649881] __do_sys_reboot+0x1d8/0x25c [ 1584.653865] __arm64_sys_reboot+0x30/0x40 [ 1584.657937] invoke_syscall+0x50/0x120 [ 1584.661723] el0_svc_common.constprop.0+0x4c/0xf4 [ 1584.666494] do_el0_svc+0x28/0x3c [ 1584.669818] el0_svc+0x2c/0x84 [ 1584.672965] el0t_64_sync_handler+0x1a4/0x1b0 [ 1584.677331] el0t_64_sync+0x18c/0x190 [ 1584.681072] ---[ end trace 0000000000000000 ]--- [ 1584.685990] ------------[ cut here ]------------ [ 1584.690650] unbalanced disables for LCD_AVDD [ 1584.694990] WARNING: CPU: 2 PID: 1 at drivers/regulator/core.c:2852 _regulator_disable+0xdc/0x194 [ 1584.920444] Call trace: [ 1584.922922] _regulator_disable+0xdc/0x194 [ 1584.927054] regulator_disable+0x48/0x8c [ 1584.931013] mantix_unprepare+0x58/0x94 [ 1584.934912] drm_panel_unprepare+0x34/0x50 [ 1584.939021] mantix_shutdown+0x2c/0x44 [ 1584.942806] mipi_dsi_drv_shutdown+0x2c/0x40 [ 1584.947112] device_shutdown+0x160/0x340 [ 1584.951070] __do_sys_reboot+0x1d8/0x25c [ 1584.955029] __arm64_sys_reboot+0x30/0x40 [ 1584.959072] invoke_syscall+0x50/0x120 [ 1584.962859] el0_svc_common.constprop.0+0x4c/0xf4 [ 1584.967627] do_el0_svc+0x28/0x3c [ 1584.970952] el0_svc+0x2c/0x84 [ 1584.974042] el0t_64_sync_handler+0x1a4/0x1b0 [ 1584.978433] el0t_64_sync+0x18c/0x190 [ 1584.982130] ---[ end trace 0000000000000000 ]--- [ 1584.993964] LCD_1V8: Underflow of regulator enable count
-
- 17 May, 2022 1 commit
-
-
Martin Kepplinger authored
-
- 16 May, 2022 4 commits
-
-
Martin Kepplinger authored
This is the 5.17.8 stable release
-
The TLDR; version: We've assumed that when a device disconnects after a resume from device suspend, it was just a cheap, buggy device. It turns out that the USB core simply wasn't waiting long enough for the devices to transition from resume to U0, and it's actually been the USB core's fault all along... * * Please go test this patch with your "buggy" USB devices. * * Background ---------- The USB 2.0 specification, section 7.1.7.7, says that upon device remote wakeup signaling, the first active hub (which is often the roothub) must rebroadcast the resume signaling for at least 20 ms (TDRSMDN). After that's done, the hub's suspend status change bit will be set, and system software must not access the device for at least 10 ms (TRSMRCY). It turns out that TRSMRCY is a *minimum*, not a *maximum*, according to Table 7-14. That means the port can actually take longer than TRSMRCY to resume. Any attempt to communicate with the device, or reset the device, will result in a USB device disconnect. This discrepancy was found with the Intel xHCI host controller, because they handle USB 2.0 resume a little differently than EHCI. See the xHCI spec, Figure 34: USB2 Root Hub Port Enabled Substate Diagram for details. Under EHCI, the host controller driver receives an interrupt when the port suspend status change bit is set, and the USB core only has to time the 10ms TRSMRCY value. Under xHCI, the host receives an interrupt when the device remote wake is first signaled, and the port goes into the Resume state. The xHCI driver kicks khubd, but doesn't allow the suspend state change to be exposed until 20 ms (TDRSMDN) after the port status change event occurs. Then, when the USB core calls into get port status, it transitions the port from the Resume state to the RExit state by changing the port link state to U0. The xHCI driver will get a port status change event when that transition is complete, but that port status change event is currently ignored. What actually happens --------------------- By busy-waiting with xhci_handshake() after the Lynx Point LP host initiates the transition to U0, and printing out how long it took, it turns out that roughly 8% of the time, the host takes longer than 10 ms to transition from RExit to U0. Out of 227 remote wakeup events from a USB mouse and keyboard: - 163 transitions from RExit to U0 were immediate ( < 1 microsecond) - 47 transitions from RExit to U0 took under 10 ms - 17 transitions were over 10ms Those 17 transitions (in microseconds) took: 10140 10305 10650 10659 10677 10695 10819 10907 10998 11030 11234 11618 11656 11724 11898 12060 12162 12757 The end result of that is that on 8% of remote wake events, the USB core would attempt to communicate with the device before it was fully resumed, causing USB disconnects or transfer errors on the next control transfer to get the device status. This bug has been reproduced under ChromeOS, which is very aggressive about USB power management. It enables auto-suspend for all internal USB devices (wifi and bluetooth), and the disconnects wreck havoc on those devices, causing the ChromeOS GUIs to repeatedly flash the USB wifi setup screen on user login. ChromeOS sets the autosuspend_delay_ms to 100 milliseconds, and disables USB device persist. I can reproduce this bug with a vanilla 3.10.7 kernel under ChromeOS. Possible fixes -------------- The USB core obviously needs to be changed to check the port status after the TRSMRCY timeout, and continue to wait if the port is still in the resuming state. I will have to study the EHCI port status diagrams in detail to figure out how the USB core can do this. I can easily do this without the USB core being involved, by changing the xHCI driver to either: 1. Busy wait with xhci_handshake() in the xHCI get port status until the port is in U0. 2. Add a completion per xHCI port. In xHCI get port status, initiate U0 entry, and wait on the port's completion for up to 20 ms. In the port status change event code, complete that port's completion when the port is in U0 and the bus_state->resuming_ports bit is set. In the meantime, simply increasing TRSMRCY from 10 ms to 20 ms solves the resume issue on the Intel xHCI host. Please test this patch under other host controllers to see if it helps "fix" your buggy devices. Signed-off-by:Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@vger.kernel.org
-
Martin Kepplinger authored
40ms were suggested on the mainling lists even, see https://lore.kernel.org/linux-usb/a66bd7ff8356cc0d97073ae41d128eabb74cc94d.camel@puri.sm/ simply trying to work around this: Mär 18 08:41:00.006534 pureos kernel: xhci-hcd xhci-hcd.4.auto: HC died; cleaning up Mär 18 08:41:00.005594 pureos kernel: xhci-hcd xhci-hcd.4.auto: xHCI host controller not responding, as> Mär 18 08:41:00.003925 pureos kernel: xhci-hcd xhci-hcd.4.auto: Abort failed to stop command ring: -110 Mär 18 08:40:44.606136 pureos kernel: xhci-hcd xhci-hcd.4.auto: Port resume timed out, port 1-1: 0xfe3
-
Martin Kepplinger authored
This reduces the cases where the host controller is dying after "reset_resume" during runtime-resume has been being executed. Usually you'd see [ 1575.824244] usb 1-1.2: reset high-speed USB device number 4 using xhci-hcd [ 1575.904083] usb 1-1.2: device descriptor read/64, error -71 [ 1576.148256] usb 1-1.2: USB disconnect, device number 4 (...) [ 1653.948112] xhci-hcd xhci-hcd.4.auto: Port resume timed out, port 1-1: 0xfe3 [ 1664.284277] xhci-hcd xhci-hcd.4.auto: xHCI host not responding to stop endpoint command. [ 1664.284485] xhci-hcd xhci-hcd.4.auto: USBSTS: [ 1664.292619] xhci-hcd xhci-hcd.4.auto: xHCI host controller not responding, assume dead [ 1664.300906] xhci-hcd xhci-hcd.4.auto: HC died; cleaning up
-
- 15 May, 2022 13 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220513142228.651822943@linuxfoundation.org Tested-by:
-
Peter Xu authored
commit 7196040e upstream. Patch series "mm/gup: some cleanups", v5. This patch (of 5): Alex reported invalid page pointer returned with pin_user_pages_remote() from vfio after upstream commit 4b6c33b3 ("vfio/type1: Prepare for batched pinning with struct vfio_batch"). It turns out that it's not the fault of the vfio commit; however after vfio switches to a full page buffer to store the page pointers it starts to expose the problem easier. The problem is for VM_PFNMAP vmas we should normally fail with an -EFAULT then vfio will carry on to handle the MMIO regions. However when the bug triggered, follow_page_mask() returned -EEXIST for such a page, which will jump over the current page, leaving that entry in **pages untouched. However the caller is not aware of it, hence the caller will reference the page as usual even if the pointer data can be anything. We had that -EEXIST logic since commit 1027e443 ("mm: make GUP handle pfn mapping unless FOLL_GET is requested") which seems very reasonable. It could be that when we reworked GUP with FOLL_PIN we could have overlooked that special path in commit 3faa52c0 ("mm/gup: track FOLL_PIN pages"), even if that commit rightfully touched up follow_devmap_pud() on checking FOLL_PIN when it needs to return an -EEXIST. Attaching the Fixes to the FOLL_PIN rework commit, as it happened later than 1027e443. [jhubbard@nvidia.com: added some tags, removed a reference to an out of tree module.] Link: https://lkml.kernel.org/r/20220207062213.235127-1-jhubbard@nvidia.com Link: https://lkml.kernel.org/r/20220204020010.68930-1-jhubbard@nvidia.com Link: https://lkml.kernel.org/r/20220204020010.68930-2-jhubbard@nvidia.com Fixes: 3faa52c0 ("mm/gup: track FOLL_PIN pages") Signed-off-by:
-
Huang Ying authored
commit fc89213a upstream. In commit ac16ec83 ("mm: migrate: support multiple target nodes demotion"), after the first demotion target node is found, we will continue to check the next candidate obtained via find_next_best_node(). This is to find all demotion target nodes with same NUMA distance. But one side effect of find_next_best_node() is that the candidate node returned will be set in "used" parameter, even if the candidate node isn't passed in the following NUMA distance checking, the candidate node will not be used as demotion target node for the following nodes. For example, for system as follows, node distances: node 0 1 2 3 0: 10 21 17 28 1: 21 10 28 17 2: 17 28 10 28 3: 28 17 28 10 when we establish demotion target node for node 0, in the first round node 2 is added to the demotion target node set. Then in the second round, node 3 is checked and failed because distance(0, 3) > distance(0, 2). But node 3 is set in "used" nodemask too. When we establish demotion target node for node 1, there is no available node. This is wrong, node 3 should be set as the demotion target of node 1. To fix this, if the candidate node is failed to pass the distance checking, it will be cleared in "used" nodemask. So that it can be used for the following node. The bug can be reproduced and fixed with this patch on a 2 socket server machine with DRAM and PMEM. Link: https://lkml.kernel.org/r/20220128055940.1792614-1-ying.huang@intel.com Fixes: ac16ec83 ("mm: migrate: support multiple target nodes demotion") Signed-off-by:
-
Miaohe Lin authored
commit 5c2a956c upstream. user_shm_lock forgets to set allowed to 0 when get_ucounts fails. So the later user_shm_unlock might do the extra dec_rlimit_ucounts. Fix this by resetting allowed to 0. Link: https://lkml.kernel.org/r/20220310132417.41189-1-linmiaohe@huawei.com Fixes: d7c9e99a ("Reimplement RLIMIT_MEMLOCK on top of ucounts") Signed-off-by:
-
Naoya Horiguchi authored
commit 046545a6 upstream. When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. If the CMCI wins that race, the page is marked poisoned when uc_decode_notifier() calls memory_failure() and the machine check processing code finds the page already poisoned. It calls kill_accessing_process() to make sure a SIGBUS is sent. But returns the wrong error code. Console log looks like this: mce: Uncorrected hardware memory error in user-access at 3710b3400 Memory failure: 0x3710b3: recovery action for dirty LRU page: Recovered Memory failure: 0x3710b3: already hardware poisoned Memory failure: 0x3710b3: Sending SIGBUS to einj_mem_uc:361438 due to hardware memory corruption mce: Memory error not recovered kill_accessing_process() is supposed to return -EHWPOISON to notify that SIGBUS is already set to the process and kill_me_maybe() doesn't have to send it again. But current code simply fails to do this, so fix it to make sure to work as intended. This change avoids the noise message "Memory error not recovered" and skips duplicate SIGBUSs. [tony.luck@intel.com: reword some parts of commit message] Link: https://lkml.kernel.org/r/20220113231117.1021405-1-naoya.horiguchi@linux.dev Fixes: a3f5d80e ("mm,hwpoison: send SIGBUS with error virutal address") Signed-off-by:
-
Muchun Song authored
commit 7c25a0b8 upstream. userfaultfd calls mcopy_atomic_pte() and __mcopy_atomic() which do not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Fix this by insert flush_dcache_page() after copy_from_user() succeeds. Link: https://lkml.kernel.org/r/20220210123058.79206-7-songmuchun@bytedance.com Fixes: b6ebaedb ("userfaultfd: avoid mmap_sem read recursion in mcopy_atomic") Fixes: c1a4de99 ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation") Signed-off-by:
-
Muchun Song authored
commit 19b482c2 upstream. userfaultfd calls shmem_mfill_atomic_pte() which does not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Insert flush_dcache_page() in non-zero-page case. And replace clear_highpage() with clear_user_highpage() which already considers the cache maintenance. Link: https://lkml.kernel.org/r/20220210123058.79206-6-songmuchun@bytedance.com Fixes: 8d103963 ("userfaultfd: shmem: add shmem_mfill_zeropage_pte for userfaultfd support") Fixes: 4c27fe4c ("userfaultfd: shmem: add shmem_mcopy_atomic_pte for userfaultfd support") Signed-off-by:
-
Muchun Song authored
commit 34892366 upstream. folio_copy() will copy the data from one page to the target page, then the target page will be mapped to the user space address, which might have an alias issue with the kernel address used to copy the data from the page to. There are 2 ways to fix this issue. 1) insert flush_dcache_page() after folio_copy(). 2) replace folio_copy() with copy_user_huge_page() which already considers the cache maintenance. We chose 2) way to fix the issue since architectures can optimize this situation. It is also make backports easier. Link: https://lkml.kernel.org/r/20220210123058.79206-5-songmuchun@bytedance.com Fixes: 8cc5fcbb ("mm, hugetlb: fix racy resv_huge_pages underflow on UFFDIO_COPY") Signed-off-by:
-
Muchun Song authored
commit e763243c upstream. userfaultfd calls copy_huge_page_from_user() which does not do any cache flushing for the target page. Then the target page will be mapped to the user space with a different address (user address), which might have an alias issue with the kernel address used to copy the data from the user to. Fix this issue by flushing dcache in copy_huge_page_from_user(). Link: https://lkml.kernel.org/r/20220210123058.79206-4-songmuchun@bytedance.com Fixes: fa4d75c1 ("userfaultfd: hugetlbfs: add copy_huge_page_from_user for hugetlb userfaultfd support") Signed-off-by:
-
Muchun Song authored
commit 2771739a upstream. The D-cache maintenance inside move_to_new_page() only consider one page, there is still D-cache maintenance issue for tail pages of compound page (e.g. THP or HugeTLB). THP migration is only enabled on x86_64, ARM64 and powerpc, while powerpc and arm64 need to maintain the consistency between I-Cache and D-Cache, which depends on flush_dcache_page() to maintain the consistency between I-Cache and D-Cache. But there is no issues on arm64 and powerpc since they already considers the compound page cache flushing in their icache flush function. HugeTLB migration is enabled on arm, arm64, mips, parisc, powerpc, riscv, s390 and sh, while arm has handled the compound page cache flush in flush_dcache_page(), but most others do not. In theory, the issue exists on many architectures. Fix this by not using flush_dcache_folio() since it is not backportable. Link: https://lkml.kernel.org/r/20220210123058.79206-3-songmuchun@bytedance.com Fixes: 290408d4 ("hugetlb: hugepage migration core") Signed-off-by:
-
Jan Kara authored
commit c1ad35dd upstream. udf_write_fi() uses lengthOfImpUse of the entry it is writing to. However this field has not yet been initialized so it either contains completely bogus value or value from last directory entry at that place. In either case this is wrong and can lead to filesystem corruption or kernel crashes. Reported-by:
-
Gleb Fotengauer-Malinovskiy authored
commit a36e07df upstream. The definition of RFKILL_IOCTL_MAX_SIZE introduced by commit 54f586a9 ("rfkill: make new event layout opt-in") is unusable since it is based on RFKILL_IOC_EXT_SIZE which has not been defined. Fix that by replacing the undefined constant with the constant which is intended to be used in this definition. Fixes: 54f586a9 ("rfkill: make new event layout opt-in") Cc: stable@vger.kernel.org # 5.11+ Signed-off-by:
-
Itay Iellin authored
commit 103a2f32 upstream. Set a size limit of 8 bytes of the written buffer to "hdev->name" including the terminating null byte, as the size of "hdev->name" is 8 bytes. If an id value which is greater than 9999 is allocated, then the "snprintf(hdev->name, sizeof(hdev->name), "hci%d", id)" function call would lead to a truncation of the id value in decimal notation. Set an explicit maximum id parameter in the id allocation function call. The id allocation function defines the maximum allocated id value as the maximum id parameter value minus one. Therefore, HCI_MAX_ID is defined as 10000. Signed-off-by:
-
- 12 May, 2022 21 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20220510130741.600270947@linuxfoundation.org Tested-by:
-
Marek Behún authored
commit 92f4ffec upstream. Update the comment about what happens when link goes down after we have checked for link-up. If a PIO request is done while link-down, we have a serious problem. Link: https://lore.kernel.org/r/20220110015018.26359-23-kabel@kernel.org Signed-off-by:
-
Marek Behún authored
commit 0c36ab43 upstream. This function is now always used in driver remove method, drop the __maybe_unused attribute. Link: https://lore.kernel.org/r/20220110015018.26359-22-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit befa7100 upstream. By default, all Legacy INTx interrupts are masked, so there is no need to mask this interrupt during irq_map() callback. Link: https://lore.kernel.org/r/20220110015018.26359-21-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit b08e5b53 upstream. Callback for irq_mask_ack() is the same as for irq_mask(). As there is no special handling for irq_ack(), there is no need to define irq_mask_ack() too. Link: https://lore.kernel.org/r/20220110015018.26359-20-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 815bc313 upstream. Emulated root bridge currently provides only one Legacy INTA interrupt which is used for reporting PCIe PME and ERR events and handled by kernel PCIe PME and AER drivers. Aardvark HW reports these PME and ERR events separately, so there is no need to mix real INTA interrupt and emulated INTA interrupt for PCIe PME and AER drivers. Register a new advk-RP (as in Root Port) irq chip and a new irq domain for emulated root bridge and use this new separate irq domain for providing INTA interrupt from emulated root bridge for PME and ERR events. The real INTA interrupt from real devices is now separate. A custom map_irq callback function on PCI host bridge structure is used to allocate IRQ mapping for emulated root bridge from new irq domain. Original callback of_irq_parse_and_map_pci() is used for all other devices as before. Link: https://lore.kernel.org/r/20220110015018.26359-19-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 273ddd86 upstream. Enable aardvark PME interrupt unconditionally by unmasking it and read PME requester ID to emulated bridge config space immediately after receiving interrupt. PME requester ID is stored in the PCIE_MSG_LOG_REG register, which contains the last inbound message. So when new inbound message is received by HW (including non-PM), the content in PCIE_MSG_LOG_REG register is replaced by a new value. PCIe specification mandates that subsequent PMEs are kept pending until the PME Status Register bit is cleared by software by writing a 1b. Support for masking/unmasking PME interrupt on emulated bridge via PCI_EXP_RTCTL_PMEIE bit is now implemented only in emulated bridge config space, to ensure that we do not miss any aardvark PME interrupt. Reading of PCI_EXP_RTCAP and PCI_EXP_RTSTA registers is simplified as final value is now always stored into emulated bridge config space by the interrupt handler, so there is no need to implement support for these registers in read_pcie callback. Clearing of W1C bit PCI_EXP_RTSTA_PME is now also simplified as it is done by pci-bridge-emul.c code for emulated bridge config space. So there is no need to implement support for clearing this bit in write_pcie callback. Link: https://lore.kernel.org/r/20220110015018.26359-18-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 0fc75d87 upstream. Currently enabling PCI_EXP_RTSTA_PME bit in PCI_EXP_RTCTL register does nothing. This is because PCIe PME driver expects to receive PCIe interrupt defined in PCI_EXP_FLAGS_IRQ register, but aardvark hardware does not trigger PCIe INTx/MSI interrupt for PME event, rather it triggers custom aardvark interrupt which this driver is not processing yet. Fix this issue by handling PME interrupt in advk_pcie_handle_int() and chaining it to PCIe interrupt 0 with generic_handle_domain_irq() (since aardvark sets PCI_EXP_FLAGS_IRQ to zero). With this change PCIe PME driver finally starts receiving PME interrupt. Link: https://lore.kernel.org/r/20220110015018.26359-17-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 7122bcb3 upstream. To optimize advk_pci_bridge_emul_pcie_conf_write() code, touch PCIE_ISR0_REG and PCIE_ISR0_MASK_REG registers only when it is really needed, when processing PCI_EXP_RTCTL_PMEIE and PCI_EXP_RTSTA_PME bits. Link: https://lore.kernel.org/r/20220110015018.26359-16-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 3ebfefa3 upstream. ERR interrupt is triggered when corresponding bit is unmasked in both ISR0 and PCI_EXP_DEVCTL registers. Unmasking ERR bits in PCI_EXP_DEVCTL register is not enough. This means that currently the ERR interrupt is never triggered. Unmask ERR bits in ISR0 register at driver probe time. ERR interrupt is not triggered until ERR bits are unmasked also in PCI_EXP_DEVCTL register, which is done by AER driver. So it is safe to unconditionally unmask all ERR bits in aardvark probe. Aardvark HW sets PCI_ERR_ROOT_AER_IRQ to zero and when corresponding bits in ISR0 and PCI_EXP_DEVCTL are enabled, the HW triggers a generic interrupt on GIC. Chain this interrupt to PCIe interrupt 0 with generic_handle_domain_irq() to allow processing of ERR interrupts. Link: https://lore.kernel.org/r/20220110015018.26359-14-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 754e4498 upstream. According to PCI 3.0 specification, sending both MSI and MSI-X interrupts is done by DWORD memory write operation to doorbell message address. The write operation for MSI has zero upper 16 bits and the MSI interrupt number in the lower 16 bits, while the write operation for MSI-X contains a 32-bit value from MSI-X table. Since the driver only uses interrupt numbers from range 0..31, the upper 16 bits of the DWORD memory write operation to doorbell message address are zero even for MSI-X interrupts. Thus we can enable MSI-X interrupts. Testing proves that kernel can correctly receive MSI-X interrupts from PCIe cards which supports both MSI and MSI-X interrupts. Link: https://lore.kernel.org/r/20220110015018.26359-13-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 46ad3dc4 upstream. MSI address for receiving MSI interrupts needs to be correctly set before enabling processing of MSI interrupts. Move code for setting PCIE_MSI_ADDR_LOW_REG and PCIE_MSI_ADDR_HIGH_REG from advk_pcie_init_msi_irq_domain() to advk_pcie_setup_hw(), before enabling PCIE_CORE_CTRL2_MSI_ENABLE. After this we can remove the now unused member msi_msg, which was used only for MSI doorbell address. MSI address can be any address which cannot be used to DMA to. So change it to the address of the main struct advk_pcie. Link: https://lore.kernel.org/r/20220110015018.26359-12-kabel@kernel.org Fixes: 8c39d710 ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by:
-
Pali Rohár authored
commit e77d9c90 upstream. We should not unmask MSIs at setup, but only when kernel asks for them to be unmasked. At setup, mask all MSIs, and implement IRQ chip callbacks for masking and unmasking particular MSIs. Link: https://lore.kernel.org/r/20220110015018.26359-11-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 4689c091 upstream. Refactor the masking of ISR0/1 Sources and unmasking of summary MSI interrupt so that it corresponds to the comments: - first mask all ISR0/1 - then unmask all MSIs - then unmask summary MSI interrupt Link: https://lore.kernel.org/r/20220110015018.26359-10-kabel@kernel.org Signed-off-by:
-
Marek Behún authored
commit 222af785 upstream. Use simple dev_fwnode(dev) instead of struct device_node *node = dev->of_node; of_node_to_fwnode(node) especially since the node variable is not used elsewhere in the function. Link: https://lore.kernel.org/r/20220110015018.26359-9-kabel@kernel.org Signed-off-by:
-
Marek Behún authored
commit 26bcd54e upstream. Make Aardvark's msi_domain_info structure into a private driver structure. Domain info is same for every potential instatination of a controller. Link: https://lore.kernel.org/r/20220110015018.26359-8-kabel@kernel.org Signed-off-by:
-
Marek Behún authored
commit c3cb8e51 upstream. In [1] it was agreed that we should use struct irq_chip as a global static struct in the driver. Even though the structure currently contains a dynamic member (parent_device), In [2] the plans to kill it and make the structure completely static were set out. Convert Aardvark's priv->msi_bottom_irq_chip and priv->msi_irq_chip to static driver structure. [1] https://lore.kernel.org/linux-pci/877dbcvngf.wl-maz@kernel.org/ [2] https://lore.kernel.org/linux-pci/874k6gvkhz.wl-maz@kernel.org/ Link: https://lore.kernel.org/r/20220110015018.26359-7-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 51f96e28 upstream. It is possible that we receive spurious INTx interrupt. Check for the return value of generic_handle_domain_irq() when processing INTx IRQ. Link: https://lore.kernel.org/r/20220110015018.26359-6-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 1571d67d upstream. Rewrite the code to use irq_set_chained_handler_and_data() handler with chained_irq_enter() and chained_irq_exit() processing instead of using devm_request_irq(). advk_pcie_irq_handler() reads IRQ status bits and calls other functions based on which bits are set. These functions then read its own IRQ status bits and calls other aardvark functions based on these bits. Finally generic_handle_domain_irq() with translated linux IRQ numbers are called. Link: https://lore.kernel.org/r/20220110015018.26359-5-kabel@kernel.org Signed-off-by:
-
Pali Rohár authored
commit 1d86abf1 upstream. Header file linux/pci.h defines enum pci_interrupt_pin with corresponding PCI_INTERRUPT_* values. Link: https://lore.kernel.org/r/20220110015018.26359-2-kabel@kernel.org Signed-off-by:
-
Ricky WU authored
commit 1f311c94 upstream. SD spec definition: "Host provides at least 74 Clocks before issuing first command" After 1ms for the voltage stable then start issuing the Clock signals if POWER STATE is MMC_POWER_OFF to MMC_POWER_UP to issue Clock signal to card MMC_POWER_UP to MMC_POWER_ON to stop issuing signal to card Signed-off-by:
-
