summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-12-03mtd: rawnand: fsmc: Fix timing computationHerve Codina
Under certain circumstances, the timing settings calculated by the FSMC NAND controller driver were inaccurate. These settings led to incorrect data reads or fallback to timing mode 0 depending on the NAND chip used. The timing computation did not take into account the following constraint given in SPEAr3xx reference manual: twait >= tCEA - (tset * TCLK) + TOUTDEL + TINDEL Enhance the timings calculation by taking into account this additional constraint. This change has no impact on slow timing modes such as mode 0. Indeed, on mode 0, computed values are the same with and without the patch. NANDs which previously stayed in mode 0 because of fallback to mode 0 can now work at higher speeds and NANDs which were not working at all because of the corrupted data work at high speeds without troubles. Overall improvement on a Micron/MT29F1G08 (flash_speed tool): mode0 mode3 eraseblock write speed 3220 KiB/s 4511 KiB/s eraseblock read speed 4491 KiB/s 7529 KiB/s Fixes: d9fb079571833 ("mtd: nand: fsmc: add support for SDR timings") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-5-herve.codina@bootlin.com
2021-12-03mtd: rawnand: fsmc: Take instruction delay into accountHerve Codina
The FSMC NAND controller should apply a delay after the instruction has been issued on the bus. The FSMC NAND controller driver did not handle this delay. Add this waiting delay in the FSMC NAND controller driver. Fixes: 4da712e70294 ("mtd: nand: fsmc: use ->exec_op()") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-4-herve.codina@bootlin.com
2021-12-03mtd: rawnand: Fix nand_choose_best_timings() on unsupported interfaceHerve Codina
When the NV-DDR interface is not supported by the NAND chip, the value of onfi->nvddr_timing_modes is 0. In this case, the best_mode variable value in nand_choose_best_nvddr_timings() is -1. The last for-loop is skipped and the function returns an uninitialized value. If this returned value is 0, the nand_choose_best_sdr_timings() is not executed and no 'best timing' are set. This leads the host controller and the NAND chip working at default mode 0 timing even if a better timing can be used. Fix this uninitialized returned value. nand_choose_best_sdr_timings() is pretty similar to nand_choose_best_nvddr_timings(). Even if onfi->sdr_timing_modes should never be seen as 0, nand_choose_best_sdr_timings() returned value is fixed. Fixes: a9ecc8c814e9 ("mtd: rawnand: Choose the best timings, NV-DDR included") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-3-herve.codina@bootlin.com
2021-12-03mtd: rawnand: Fix nand_erase_op delayHerve Codina
NAND_OP_CMD() expects a delay parameter in nanoseconds. The delay value is wrongly given in milliseconds. Fix the conversion macro used in order to set this delay in nanoseconds. Fixes: d7a773e8812b ("mtd: rawnand: Access SDR and NV-DDR timings through a common macro") Signed-off-by: Herve Codina <herve.codina@bootlin.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211119150316.43080-2-herve.codina@bootlin.com
2021-12-03mtd: rawnand: denali: Add the dependency on HAS_IOMEMCai Huoqing
The helper function devm_platform_ioremap_resource_xxx() needs HAS_IOMEM enabled, so add the dependency on HAS_IOMEM. Fixes: 5f14a8ca1b49 ("mtd: rawnand: denali: Make use of the helper function devm_platform_ioremap_resource_byname()") Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20211109134758.417-1-caihuoqing@baidu.com
2021-12-03misc: rtsx: Avoid mangling IRQ during runtime PMKai-Heng Feng
After commit 5b4258f6721f ("misc: rtsx: rts5249 support runtime PM"), when the rtsx controller is runtime suspended, bring CPUs offline and back online, the runtime resume of the controller will fail: [ 47.319391] smpboot: CPU 1 is now offline [ 47.414140] x86: Booting SMP configuration: [ 47.414147] smpboot: Booting Node 0 Processor 1 APIC 0x2 [ 47.571334] smpboot: CPU 2 is now offline [ 47.686055] smpboot: Booting Node 0 Processor 2 APIC 0x4 [ 47.808174] smpboot: CPU 3 is now offline [ 47.878146] smpboot: Booting Node 0 Processor 3 APIC 0x6 [ 48.003679] smpboot: CPU 4 is now offline [ 48.086187] smpboot: Booting Node 0 Processor 4 APIC 0x1 [ 48.239627] smpboot: CPU 5 is now offline [ 48.326059] smpboot: Booting Node 0 Processor 5 APIC 0x3 [ 48.472193] smpboot: CPU 6 is now offline [ 48.574181] smpboot: Booting Node 0 Processor 6 APIC 0x5 [ 48.743375] smpboot: CPU 7 is now offline [ 48.838047] smpboot: Booting Node 0 Processor 7 APIC 0x7 [ 48.965447] __common_interrupt: 1.35 No irq handler for vector [ 51.174065] mmc0: error -110 doing runtime resume [ 54.978088] I/O error, dev mmcblk0, sector 21479 op 0x1:(WRITE) flags 0x0 phys_seg 11 prio class 0 [ 54.978108] Buffer I/O error on dev mmcblk0p1, logical block 19431, lost async page write [ 54.978129] Buffer I/O error on dev mmcblk0p1, logical block 19432, lost async page write [ 54.978134] Buffer I/O error on dev mmcblk0p1, logical block 19433, lost async page write [ 54.978137] Buffer I/O error on dev mmcblk0p1, logical block 19434, lost async page write [ 54.978141] Buffer I/O error on dev mmcblk0p1, logical block 19435, lost async page write [ 54.978145] Buffer I/O error on dev mmcblk0p1, logical block 19436, lost async page write [ 54.978148] Buffer I/O error on dev mmcblk0p1, logical block 19437, lost async page write [ 54.978152] Buffer I/O error on dev mmcblk0p1, logical block 19438, lost async page write [ 54.978155] Buffer I/O error on dev mmcblk0p1, logical block 19439, lost async page write [ 54.978160] Buffer I/O error on dev mmcblk0p1, logical block 19440, lost async page write [ 54.978244] mmc0: card aaaa removed [ 54.978452] FAT-fs (mmcblk0p1): FAT read failed (blocknr 4257) There's interrupt immediately raised on rtsx_pci_write_register() in runtime resume routine, but the IRQ handler hasn't registered yet. So we can either move rtsx_pci_write_register() after rtsx_pci_acquire_irq(), or just stop mangling IRQ on runtime PM. Choose the latter to save some CPU cycles. Fixes: 5b4258f6721f ("misc: rtsx: rts5249 support runtime PM") Cc: stable <stable@vger.kernel.org> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> BugLink: https://bugs.launchpad.net/bugs/1951784 Link: https://lore.kernel.org/r/20211126003246.1068770-1-kai.heng.feng@canonical.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03io-wq: don't retry task_work creation failure on fatal conditionsJens Axboe
We don't want to be retrying task_work creation failure if there's an actual signal pending for the parent task. If we do, then we can enter an infinite loop of perpetually retrying and each retry failing with -ERESTARTNOINTR because a signal is pending. Fixes: 3146cba99aa2 ("io-wq: make worker creation resilient against signals") Reported-by: Florian Fischer <florian.fl.fischer@fau.de> Link: https://lore.kernel.org/io-uring/20211202165606.mqryio4yzubl7ms5@pasture/ Tested-by: Florian Fischer <florian.fl.fischer@fau.de> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-12-03nvmem: eeprom: at25: fix FRAM byte_lenRalph Siemsen
Commit fd307a4ad332 ("nvmem: prepare basics for FRAM support") added support for FRAM devices such as the Cypress FM25V. During testing, it was found that the FRAM detects properly, however reads and writes fail. Upon further investigation, two problem were found in at25_probe() routine. 1) In the case of an FRAM device without platform data, eg. fram == true && spi->dev.platform_data == NULL the stack local variable "struct spi_eeprom chip" is not initialized fully, prior to being copied into at25->chip. The chip.flags field in particular can cause problems. 2) The byte_len of FRAM is computed from its ID register, and is stored into the stack local "struct spi_eeprom chip" structure. This happens after the same structure has been copied into at25->chip. As a result, at25->chip.byte_len does not contain the correct length of the device. In turn this can cause checks at beginning of at25_ee_read() to fail (or equally, it could allow reads beyond the end of the device length). Fix both of these issues by eliminating the on-stack struct spi_eeprom. Instead use the one inside at25_data structure, which starts of zeroed. Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support") Cc: stable <stable@vger.kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Link: https://lore.kernel.org/r/20211108181627.645638-1-ralph.siemsen@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03misc: fastrpc: fix improper packet size calculationJeya R
The buffer list is sorted and this is not being considered while calculating packet size. This would lead to improper copy length calculation for non-dmaheap buffers which would eventually cause sending improper buffers to DSP. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method") Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Jeya R <jeyr@codeaurora.org> Link: https://lore.kernel.org/r/1637771481-4299-1-git-send-email-jeyr@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03MAINTAINERS: add maintainer for Qualcomm FastRPC driverSrinivas Kandagatla
For some reason I forgot to add myself as maintainer when we upstreamed FastRPC patches. Add myself and Amol from Qualcomm as maintainers for Qualcomm FastRPC driver. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20211124142325.27108-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03serial: 8250_bcm7271: UART errors after resuming from S2Al Cooper
There is a small window in time during resume where the hardware flow control signal RTS can be asserted (which allows a sender to resume sending data to the UART) but the baud rate has not yet been restored. This will cause corrupted data and FRAMING, OVERRUN and BREAK errors. This is happening because the MCTRL register is shadowed in uart_port struct and is later used during resume to set the MCTRL register during both serial8250_do_startup() and uart_resume_port(). Unfortunately, serial8250_do_startup() happens before the UART baud rate is restored. The fix is to clear the shadowed mctrl value at the end of suspend and restore it at the end of resume. Fixes: 41a469482de2 ("serial: 8250: Add new 8250-core based Broadcom STB driver") Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Al Cooper <alcooperx@gmail.com> Link: https://lore.kernel.org/r/20211201201402.47446-1-alcooperx@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03drm/ttm: fix ttm_bo_swapoutChristian König
Commit 7120a447c7fe ("drm/ttm: Double check mem_type of BO while eviction") made ttm_bo_evict_swapout_allowable() function actually check the placement, but we always used a dummy placement in ttm_bo_swapout. Fix this by using the real placement instead. Signed-off-by: Christian König <christian.koenig@amd.com> Fixes: 7120a447c7fe ("drm/ttm: Double check mem_type of BO while eviction") Reviewed-by: Pan, Xinhui <Xinhui.Pan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211202103828.44573-1-christian.koenig@amd.com
2021-12-03usb: cdnsp: Fix a NULL pointer dereference in cdnsp_endpoint_init()Zhou Qingyang
In cdnsp_endpoint_init(), cdnsp_ring_alloc() is assigned to pep->ring and there is a dereference of it in cdnsp_endpoint_init(), which could lead to a NULL pointer dereference on failure of cdnsp_ring_alloc(). Fix this bug by adding a check of pep->ring. This bug was found by a static analyzer. The analysis employs differential checking to identify inconsistent security operations (e.g., checks or kfrees) between two code paths and confirms that the inconsistent operations are not recovered in the current function or the callers, so they constitute bugs. Note that, as a bug found by static analysis, it can be a false positive or hard to trigger. Multiple researchers have cross-reviewed the bug. Builds with CONFIG_USB_CDNSP_GADGET=y show no new warnings, and our static analyzer no longer warns about this code. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable <stable@vger.kernel.org> Acked-by: Pawel Laszczak <pawell@cadence.com> Acked-by: Peter Chen <peter.chen@kernel.org> Signed-off-by: Zhou Qingyang <zhou1615@umn.edu> Link: https://lore.kernel.org/r/20211130172700.206650-1-zhou1615@umn.edu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03usb: cdns3: gadget: fix new urb never complete if ep cancel previous requestsFrank Li
This issue was found at android12 MTP. 1. MTP submit many out urb request. 2. Cancel left requests (>20) when enough data get from host 3. Send ACK by IN endpoint. 4. MTP submit new out urb request. 5. 4's urb never complete. TRACE LOG: MtpServer-2157 [000] d..3 1287.150391: cdns3_ep_dequeue: ep1out: req: 00000000299e6836, req buff 000000009df42287, length: 0/16384 zsi, status: -115, trb: [start:87, end:87: virt addr 0x80004000ffd50420], flags:1 SID: 0 MtpServer-2157 [000] d..3 1287.150410: cdns3_gadget_giveback: ep1out: req: 00000000299e6836, req buff 000000009df42287, length: 0/16384 zsi, status: -104, trb: [start:87, end:87: virt addr 0x80004000ffd50420], flags:0 SID: 0 MtpServer-2157 [000] d..3 1287.150433: cdns3_ep_dequeue: ep1out: req: 0000000080b7bde6, req buff 000000009ed5c556, length: 0/16384 zsi, status: -115, trb: [start:88, end:88: virt addr 0x80004000ffd5042c], flags:1 SID: 0 MtpServer-2157 [000] d..3 1287.150446: cdns3_gadget_giveback: ep1out: req: 0000000080b7bde6, req buff 000000009ed5c556, length: 0/16384 zsi, status: -104, trb: [start:88, end:88: virt addr 0x80004000ffd5042c], flags:0 SID: 0 .... MtpServer-2157 [000] d..1 1293.630410: cdns3_alloc_request: ep1out: req: 00000000afbccb7d, req buff 0000000000000000, length: 0/0 zsi, status: 0, trb: [start:0, end:0: virt addr (null)], flags:0 SID: 0 MtpServer-2157 [000] d..2 1293.630421: cdns3_ep_queue: ep1out: req: 00000000afbccb7d, req buff 00000000871caf90, length: 0/512 zsi, status: -115, trb: [start:0, end:0: virt addr (null)], flags:0 SID: 0 MtpServer-2157 [000] d..2 1293.630445: cdns3_wa1: WA1: ep1out set guard MtpServer-2157 [000] d..2 1293.630450: cdns3_wa1: WA1: ep1out restore cycle bit MtpServer-2157 [000] d..2 1293.630453: cdns3_prepare_trb: ep1out: trb 000000007317b3ee, dma buf: 0xffd5bc00, size: 512, burst: 128 ctrl: 0x00000424 (C=0, T=0, ISP, IOC, Normal) SID:0 LAST_SID:0 MtpServer-2157 [000] d..2 1293.630460: cdns3_doorbell_epx: ep1out, ep_trbaddr ffd50414 .... irq/241-5b13000-2154 [000] d..1 1293.680849: cdns3_epx_irq: IRQ for ep1out: 01000408 ISP , ep_traddr: ffd508ac ep_last_sid: 00000000 use_streams: 0 irq/241-5b13000-2154 [000] d..1 1293.680858: cdns3_complete_trb: ep1out: trb 0000000021a11b54, dma buf: 0xffd50420, size: 16384, burst: 128 ctrl: 0x00001810 (C=0, T=0, CHAIN, LINK) SID:0 LAST_SID:0 irq/241-5b13000-2154 [000] d..1 1293.680865: cdns3_request_handled: Req: 00000000afbccb7d not handled, DMA pos: 185, ep deq: 88, ep enq: 185, start trb: 184, end trb: 184 Actually DMA pos already bigger than previous submit request afbccb7d's TRB (184-184). The reason of (not handled) is that deq position is wrong. The TRB link is below when irq happen. DEQ LINK LINK LINK LINK LINK .... TRB(afbccb7d):START DMA(EP_TRADDR). Original code check LINK TRB, but DEQ just move one step. LINK DEQ LINK LINK LINK LINK .... TRB(afbccb7d):START DMA(EP_TRADDR). This patch skip all LINK TRB and sync DEQ to trb's start. LINK LINK LINK LINK LINK .... DEQ = TRB(afbccb7d):START DMA(EP_TRADDR). Acked-by: Peter Chen <peter.chen@kernel.org> Cc: stable <stable@vger.kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Jun Li <jun.li@nxp.com> Link: https://lore.kernel.org/r/20211130154239.8029-1-Frank.Li@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03usb: typec: tcpm: Wait in SNK_DEBOUNCED until disconnectBadhri Jagan Sridharan
Stub from the spec: "4.5.2.2.4.2 Exiting from AttachWait.SNK State A Sink shall transition to Unattached.SNK when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce. A DRP shall transition to Unattached.SRC when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce." This change makes TCPM to wait in SNK_DEBOUNCED state until CC1 and CC2 pins is SNK.Open for at least tPDDebounce. Previously, TCPM resets the port if vbus is not present in PD_T_PS_SOURCE_ON. This causes TCPM to loop continuously when connected to a faulty power source that does not present vbus. Waiting in SNK_DEBOUNCED also ensures that TCPM is adherant to "4.5.2.2.4.2 Exiting from AttachWait.SNK State" requirements. [ 6169.280751] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 6169.280759] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS] [ 6169.280771] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS] [ 6169.282427] CC1: 0 -> 0, CC2: 5 -> 5 [state SNK_ATTACH_WAIT, polarity 0, connected] [ 6169.450825] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 6169.450834] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS] [ 6169.930892] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms] [ 6169.931296] disable vbus discharge ret:0 [ 6169.931301] Setting usb_comm capable false [ 6169.932783] Setting voltage/current limit 0 mV 0 mA [ 6169.932802] polarity 0 [ 6169.933706] Requesting mux state 0, usb-role 0, orientation 0 [ 6169.936689] cc:=0 [ 6169.936812] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS] [ 6169.937157] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected] [ 6170.036880] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [ 6170.036890] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev2 NONE_AMS] [ 6170.036896] Start toggling [ 6170.041412] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 6170.042973] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected] [ 6170.042976] state change TOGGLING -> SNK_ATTACH_WAIT [rev2 NONE_AMS] [ 6170.042981] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms [rev2 NONE_AMS] [ 6170.213014] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] [ 6170.213019] pending state change SNK_DEBOUNCED -> PORT_RESET @ 480 ms [rev2 NONE_AMS] [ 6170.693068] state change SNK_DEBOUNCED -> PORT_RESET [delayed 480 ms] [ 6170.693304] disable vbus discharge ret:0 [ 6170.693308] Setting usb_comm capable false [ 6170.695193] Setting voltage/current limit 0 mV 0 mA [ 6170.695210] polarity 0 [ 6170.695990] Requesting mux state 0, usb-role 0, orientation 0 [ 6170.701896] cc:=0 [ 6170.702181] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev2 NONE_AMS] [ 6170.703343] CC1: 0 -> 0, CC2: 5 -> 0 [state PORT_RESET, polarity 0, disconnected] Fixes: f0690a25a140b8 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable@vger.kernel.org Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20211130001825.3142830-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03USB: NO_LPM quirk Lenovo Powered USB-C Travel HubOle Ernst
This is another branded 8153 device that doesn't work well with LPM: r8152 2-2.1:1.0 enp0s13f0u2u1: Stop submitting intr, status -71 Disable LPM to resolve the issue. Signed-off-by: Ole Ernst <olebowle@gmx.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20211127090546.52072-1-olebowle@gmx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03xhci: Fix commad ring abort, write all 64 bits to CRCR register.Mathias Nyman
Turns out some xHC controllers require all 64 bits in the CRCR register to be written to execute a command abort. The lower 32 bits containing the command abort bit is written first. In case the command ring stops before we write the upper 32 bits then hardware may use these upper bits to set the commnd ring dequeue pointer. Solve this by making sure the upper 32 bits contain a valid command ring dequeue pointer. The original patch that only wrote the first 32 to stop the ring went to stable, so this fix should go there as well. Fixes: ff0e50d3564f ("xhci: Fix command ring pointer corruption while aborting a command") Cc: stable@vger.kernel.org Tested-by: Pavankumar Kondeti <quic_pkondeti@quicinc.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20211126122340.1193239-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03selftests/tc-testing: Fix cannot create /sys/bus/netdevsim/new_device: ↵Li Zhijian
Directory nonexistent Install netdevsim to provide /sys/bus/netdevsim/new_device interface. It helps to fix: # ok 97 9a7d - Change ETS strict band without quantum # skipped - skipped - previous setup failed 11 ce7d # # # -----> prepare stage *** Could not execute: "echo "1 1 4" > /sys/bus/netdevsim/new_device" # # -----> prepare stage *** Error message: "/bin/sh: 1: cannot create /sys/bus/netdevsim/new_device: Directory nonexistent # " # # -----> prepare stage *** Aborting test run. # # # <_io.BufferedReader name=5> *** stdout *** # Signed-off-by: Li Zhijian <zhijianx.li@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-03selftests/tc-testing: add missing configLi Zhijian
qdiscs/fq_pie requires CONFIG_NET_SCH_FQ_PIE, otherwise tc will fail to create a fq_pie qdisc. It fixes following issue: # not ok 57 83be - Create FQ-PIE with invalid number of flows # Command exited with 2, expected 0 # Error: Specified qdisc not found. Signed-off-by: Li Zhijian <zhijianx.li@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-03selftests/tc-testing: add exit codeLi Zhijian
Mark the summary result as FAIL to prevent from confusing the selftest framework if some of them are failed. Previously, the selftest framework always treats it as *ok* even though some of them are failed actually. That's because the script tdc.sh always return 0. # All test results: # # 1..97 # ok 1 83be - Create FQ-PIE with invalid number of flows # ok 2 8b6e - Create RED with no flags [...snip] # ok 6 5f15 - Create RED with flags ECN, harddrop # ok 7 53e8 - Create RED with flags ECN, nodrop # ok 8 d091 - Fail to create RED with only nodrop flag # ok 9 af8e - Create RED with flags ECN, nodrop, harddrop # not ok 10 ce7d - Add mq Qdisc to multi-queue device (4 queues) # Could not match regex pattern. Verify command output: # qdisc mq 1: root # qdisc fq_codel 0: parent 1:4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 # qdisc fq_codel 0: parent 1:3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 [...snip] # ok 96 6979 - Change quantum of a strict ETS band # ok 97 9a7d - Change ETS strict band without quantum # # # # ok 1 selftests: tc-testing: tdc.sh <<< summary result CC: Philip Li <philip.li@intel.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Li Zhijian <zhijianx.li@intel.com> Acked-by: Davide Caratti <dcaratti@redhat.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-12-03drm/i915/fbc: No FBC+double wide pipeVille Syrjälä
FBC and double wide pipe are mutually exclusive. Disable FBC when we have to resort to double wide. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-20-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: s/parms/fbc_state/Ville Syrjälä
Rename the 'params' to just fbc state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-19-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Move plane pointer into intel_fbc_stateVille Syrjälä
Currently we track the FBC plane as a pointer under intel_fbc and also as a i9xx_plane_id under intel_fbc_state. Just store the pointer once in the fbc state. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-18-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Nuke state_cacheVille Syrjälä
fbc->state_cache has now become useless. We can simply update the reg params directly from the plane/crtc states during __intel_fbc_enable(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-17-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Disable FBC fully on FIFO underrunVille Syrjälä
Currently a FIFO underrun just causes FBC to be deactivated, and later checks then prevent it from being reactivated. We can simpify our lives a bit by logically disabling FBC on FIFO underruns. This avoids the funny intermediate state where FBC is logically enabled but can't actually be activated. v2: intel_wait_for_vblank() is no more Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-16-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Move stuff from intel_fbc_can_enable() into ↵Ville Syrjälä
intel_fbc_check_plane() Don't really see a good reason why we can't just do the vgpu and modparam checks already in intel_fbc_check_plane(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-15-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Allocate intel_fbc dynamicallyVille Syrjälä
In the future we may have more than one FBC instance on some platforms. So let's just allocate it dynamically. This also lets us fully hide the implementation from prying eyes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-14-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Introduce intel_fbc_add_plane()Ville Syrjälä
In order to better encapsulate the FBC implementation introduce a small helper to do the plane<->FBC instance association. We'll also try to structure the plane init code such that introducing multiple FBC instances will be easier down the line. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-13-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Move FBC debugfs stuff into intel_fbc.cVille Syrjälä
In order to encapsulate FBC harder let's just move the debugfs stuff into intel_fbc.c. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-12-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2021-12-03drm/i915/fbc: Pass i915 instead of FBC instance to FBC underrun stuffVille Syrjälä
The underrun code doesn't need to know any details about FBC, so just pass in the whole device rather than a specific FBC instance. We could make this a bit more fine grained by also passing in the pipe to intel_fbc_handle_fifo_underrun_irq() and letting the FBC code figure which FBC instance (if any) is active on said pipe. But that seems a bit overkill for this so don't bother. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-11-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Flatten __intel_fbc_pre_update()Ville Syrjälä
Use an early return to flatten most of __intel_fbc_pre_update(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-10-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Track FBC usage per-planeVille Syrjälä
In the future we may have multiple planes on the same pipe capable of using FBC. Prepare for that by tracking FBC usage per-plane rather than per-crtc. v2: s/intel_get_crtc_for_pipe/intel_crtc_for_pipe/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-9-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Pass around FBC instance instead of crtcVille Syrjälä
Pass the FBC instance instead of the crtc to a bunch of places. We also adjust intel_fbc_post_update() to do the intel_fbc_get_reg_params() things instead of doing it from the lower level function (which also gets called for front buffer tracking). Nothing in there will change during front buffer updates. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-8-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Reuse the same struct for the cache and paramsVille Syrjälä
The FBC state cache and params are now nearly identical. Just use the same structure for both. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-7-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Nuke more FBC stateVille Syrjälä
There isn't a good reason why we'd have to cache all this plane state stuff in the FBC state. Instead we can just pre-calculate what FBC will really need. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-6-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Relocate intel_fbc_override_cfb_stride()Ville Syrjälä
Move intel_fbc_override_cfb_stride() next to its cousins. Helps with later patches. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cacheVille Syrjälä
There's no need to store all this stuff in intel_fbc_state_cache. Just check it all against the plane/crtc states and store only what we need. Probably more should get nuked still, but this is a start. So what we'll do is: - each plane will check its own state and update its local no_fbc_reason - the per-plane no_fbc_reason (if any) then gets propagated to the cache->no_fbc_reason while doing the actual update - fbc->no_fbc_reason gets updated in the end with either the value from the cache or directly from frontbuffer tracking It's still a bit messy, but should hopefuly get cleaned up more in the future. At least now we can observe each plane's reasons for rejecting FBC now more consistently, and we don't have so mcuh redundant state store all over the place. v2: store no_fbc_reason per-plane instead of per-pipe Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-4-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Pass whole plane state to intel_fbc_min_limit()Ville Syrjälä
No reason to burden the caller with the details on how the minimum compression limit is calculated, so just pass in the whole plane state instead of just the cpp value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-3-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915/fbc: Eliminate racy intel_fbc_is_active() usageVille Syrjälä
The ilk fbc watermark computation uses intel_fbc_is_active() which is racy since we don't know whether FBC will be enabled or not at some point. So let's just assume it will be if both HAS_FBC() and the modparam agree. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2021-12-03drm/i915: Rename PLANE_CUS_CTL Y plane bitsVille Syrjälä
Rename the PLANE_CUS_CTL Y plane selection bits to actually say "Y plane". Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-6-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-12-03drm/i915: Rename plane YUV order bitsVille Syrjälä
Rename the YUV byte order bits to be a bit more consistent. v2: Deal with gvt Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-3-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-12-03drm/i915: Get rid of the 64bit PLANE_CC_VAL mmioVille Syrjälä
Let's just stick to 32bit mmio accesses so we can get rid of the bare "uncore" reg access in display code. The register are defined as 32bit in the spec anyway. We could define a 64bit "de" variant I suppose, but doesn't really make much sense just for this one case, and when we start to use the DSB for this stuff we'd also need another 64bit variant for that. Just easier to do 32bit always. While at it we can reorder stuff a bit so that we write the registers in order of increasing offset (more or less). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-2-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2021-12-03bus: mhi: pci_generic: Fix device recovery failed issueSlark Xiao
For Foxconn T99W175 device(sdx55 platform) in some host platform, it would be unavailable once the host execute the err handler. After checking, it's caused by the delay time too short to get a successful reset. Please see my test evidence as bewlow(BTW, I add some extra test logs in function mhi_pci_reset_prepare and mhi_pci_reset_done): When MHI_POST_RESET_DELAY_MS equals to 500ms: Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222477] mhi mhi0: Device MHI is not in valid state Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222628] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare reset Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222631] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare mhi_soc_reset Nov 4 14:30:03 jbd-ThinkEdge kernel: [ 146.222632] mhi mhi0: mhi_soc_reset write soc to reset Nov 4 14:30:05 jbd-ThinkEdge kernel: [ 147.839993] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_done Nov 4 14:30:05 jbd-ThinkEdge kernel: [ 147.902063] mhi-pci-generic 0000:2d:00.0: reset failed When MHI_POST_RESET_DELAY_MS equals to 1000ms or 1500ms: Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.067857] mhi mhi0: Device MHI is not in valid state Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.068029] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare reset Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.068032] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare mhi_soc_reset Nov 4 19:07:26 jbd-ThinkEdge kernel: [ 157.068034] mhi mhi0: mhi_soc_reset write soc to reset Nov 4 19:07:29 jbd-ThinkEdge kernel: [ 159.607006] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_done Nov 4 19:07:29 jbd-ThinkEdge kernel: [ 159.607152] mhi mhi0: Requested to power ON Nov 4 19:07:51 jbd-ThinkEdge kernel: [ 181.302872] mhi mhi0: Failed to reset MHI due to syserr state Nov 4 19:07:51 jbd-ThinkEdge kernel: [ 181.303011] mhi-pci-generic 0000:2d:00.0: failed to power up MHI controller When MHI_POST_RESET_DELAY_MS equals to 2000ms: Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180527] mhi mhi0: Failed to transition from PM state: Linkdown or Error Fatal Detect to: SYS ERROR Process Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180535] mhi mhi0: Device MHI is not in valid state Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180722] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare reset Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180725] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_prepare mhi_soc_reset Nov 4 17:51:08 jbd-ThinkEdge kernel: [ 147.180727] mhi mhi0: mhi_soc_reset write soc to reset Nov 4 17:51:11 jbd-ThinkEdge kernel: [ 150.230787] mhi-pci-generic 0000:2d:00.0: mhi_pci_reset_done Nov 4 17:51:11 jbd-ThinkEdge kernel: [ 150.230928] mhi mhi0: Requested to power ON Nov 4 17:51:11 jbd-ThinkEdge kernel: [ 150.231173] mhi mhi0: Power on setup success Nov 4 17:51:14 jbd-ThinkEdge kernel: [ 153.254747] mhi mhi0: Wait for device to enter SBL or Mission mode I also tried big data like 3000, and it worked as well. 500ms may not be enough for all support mhi device. We shall increase it to 2000ms at least. Link: https://lore.kernel.org/r/20211108113127.3938-1-slark_xiao@163.com [mani: massaged commit message little bit, added Fixes tag and CCed stable] Fixes: 8ccc3279fcad ("mhi: pci_generic: Add support for reset") Cc: stable@vger.kernel.org Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Slark Xiao <slark_xiao@163.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20211126104951.35685-2-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-12-03Merge tag 'phy-fixes-5.16' of ↵Greg Kroah-Hartman
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy into char-misc-next Vinod writes: phy: fixes for 5.16 Fixes for: - kernel-doc warnings for various drivers - error handling fix for HiSilicon driver - name fix for zynqmp phy - property name fix in stm32 phy * tag 'phy-fixes-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: HiSilicon: Fix copy and paste bug in error handling dt-bindings: phy: zynqmp-psgtr: fix USB phy name phy: ti: omap-usb2: Fix the kernel-doc style phy: qualcomm: ipq806x-usb: Fix kernel-doc style phy: ti: tusb1210: Fix the kernel-doc warn phy: qualcomm: usb-hsic: Fix the kernel-doc warn phy: qualcomm: qmp: Add missing struct documentation phy: mvebu-cp110-utmi: Fix kernel-doc warns phy: ti: report 2 non-kernel-doc comments phy: stm32: fix st,slow-hs-slew-rate with st,decrease-hs-slew-rate
2021-12-03drm/i915/display: stop including i915_drv.h from intel_display_types.hJani Nikula
Break the dependency on i915_drv.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ee740f494e416d875e057c2eda585f4e66d65500.1638366969.git.jani.nikula@intel.com
2021-12-03drm/i915/display: convert dp_to_i915() to a macroJani Nikula
Avoid looking into the guts of struct drm_i915_private in headers. Again, converting an inline function to a macro is less than ideal, but avoids having to pull in i915_drv.h just for the to_i915() part. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ed6c43455d13c90ebfed442b196625af5e6ede88.1638366969.git.jani.nikula@intel.com
2021-12-03drm/i915: move enum hpd_pin to intel_display.hJani Nikula
It's not the ideal location, but a better alternative than i915_drv.h. The goal is to break the intel_display_types.h to i915_drv.h dependency. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9f882eff78cdc6b28c18e73f5e53f57e413240dc.1638366969.git.jani.nikula@intel.com
2021-12-03drm/i915: split out intel_pm_types.hJani Nikula
This is far from ideal, but it reduces the i915_drv.h dependency from intel_display_types.h. Maybe in the future we'll need a better split. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c6c60d9a8f6dcd1fa2f4b187000c5bb6843a1371.1638366969.git.jani.nikula@intel.com
2021-12-03drm/i915/fb: move intel_fb_uses_dpt to intel_fb.c and un-inlineJani Nikula
Move fb functions where they belong, and un-inline to avoid looking into struct drm_i915_private guts in header files. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4aa89f113ce6d840d62f50c989e2a1415483557c.1638366969.git.jani.nikula@intel.com
2021-12-03drm/i915/crtc: un-inline some crtc functions and move to intel_crtc.[ch]Jani Nikula
Move a number of crtc/pipe related functions to intel_crtc.[ch], and un-inline to avoid looking into struct drm_i915_private guts in header files. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c0be2adc4a7f7e72a47e12a57f742aaa42b813e6.1638366969.git.jani.nikula@intel.com
generated by cgit (git 2.34.1) at 2025-09-28 13:39:16 +0000