Searched hist:970 (Results 201 - 225 of 377) sorted by relevance
/linux-master/drivers/net/ethernet/socionext/ | ||
H A D | netsec.c | diff 54f7bf72 Sat Jan 13 14:13:44 MST 2018 Arnd Bergmann <arnd@arndb.de> net: netsec: use dma_addr_t for storing dma address On targets that have different sizes for phys_addr_t and dma_addr_t, we get a type mismatch error: drivers/net/ethernet/socionext/netsec.c: In function 'netsec_alloc_dring': drivers/net/ethernet/socionext/netsec.c:970:9: error: passing argument 3 of 'dma_zalloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] The code is otherwise correct, as the address is never actually used as a physical address but only passed into a DMA register. For consistently, I'm changing the variable name as well, to clarify that this is a DMA address. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/drivers/gpu/drm/exynos/ | ||
H A D | exynos7_drm_decon.c | diff 970dc5ed Wed Dec 22 12:01:30 MST 2021 Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the interrupt platform_get_resource_byname(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypassed the hierarchical setup and messed up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq_byname(). Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> |
/linux-master/arch/powerpc/include/asm/ | ||
H A D | rtas.h | diff 970e453e Mon Dec 07 14:51:34 MST 2020 Nathan Lynch <nathanl@linux.ibm.com> powerpc/rtas: complete ibm,suspend-me status codes We don't completely account for the possible return codes for ibm,suspend-me. Add definitions for these. Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201207215200.1785968-3-nathanl@linux.ibm.com |
H A D | kvm_book3s.h | diff ca7f4203 Wed Mar 24 14:48:28 MDT 2010 Alexander Graf <agraf@suse.de> KVM: PPC: Implement alignment interrupt Mac OS X has some applications - namely the Finder - that require alignment interrupts to work properly. So we need to implement them. But the spec for 970 and 750 also looks different. While 750 requires the DSISR and DAR fields to reflect some instruction bits (DSISR) and the fault address (DAR), the 970 declares this as an optional feature. So we need to reconstruct DSISR and DAR manually. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Avi Kivity <avi@redhat.com> diff ca7f4203 Wed Mar 24 14:48:28 MDT 2010 Alexander Graf <agraf@suse.de> KVM: PPC: Implement alignment interrupt Mac OS X has some applications - namely the Finder - that require alignment interrupts to work properly. So we need to implement them. But the spec for 970 and 750 also looks different. While 750 requires the DSISR and DAR fields to reflect some instruction bits (DSISR) and the fault address (DAR), the 970 declares this as an optional feature. So we need to reconstruct DSISR and DAR manually. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Avi Kivity <avi@redhat.com> |
/linux-master/block/ | ||
H A D | blk-iolatency.c | diff aa1b46dc Mon Mar 14 01:15:02 MDT 2022 Tejun Heo <tj@kernel.org> block: fix rq-qos breakage from skipping rq_qos_done_bio() a647a524a467 ("block: don't call rq_qos_ops->done_bio if the bio isn't tracked") made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set. While this fixed a potential oops, it also broke blk-iocost by skipping the done_bio callback for merged bios. Before, whether a bio goes through rq_qos_throttle() or rq_qos_merge(), rq_qos_done_bio() would be called on the bio on completion with BIO_TRACKED distinguishing the former from the latter. rq_qos_done_bio() is not called for bios which wenth through rq_qos_merge(). This royally confuses blk-iocost as the merged bios never finish and are considered perpetually in-flight. One reliably reproducible failure mode is an intermediate cgroup geting stuck active preventing its children from being activated due to the leaf-only rule, leading to loss of control. The following is from resctl-bench protection scenario which emulates isolating a web server like workload from a memory bomb run on an iocost configuration which should yield a reasonable level of protection. # cat /sys/block/nvme2n1/device/model Samsung SSD 970 PRO 512GB # cat /sys/fs/cgroup/io.cost.model 259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025 # cat /sys/fs/cgroup/io.cost.qos 259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00 # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ================== IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m Isolation and Request Latency Impact Distributions: min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev isol% 15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82 lat-imp% 0 0 0 0 0 4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6 Result: isol=58.12:15.82% lat_imp=53.88%:143.6 work_csv=100.0% missing=3.96% The isolation result of 58.12% is close to what this device would show without any IO control. Fix it by introducing a new flag BIO_QOS_MERGED to mark merged bios and calling rq_qos_done_bio() on them too. For consistency and clarity, rename BIO_TRACKED to BIO_QOS_THROTTLED. The flag checks are moved into rq_qos_done_bio() so that it's next to the code paths that set the flags. With the patch applied, the above same benchmark shows: # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1 ... Memory Hog Summary ================== IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m Isolation and Request Latency Impact Distributions: min p01 p05 p10 p25 p50 p75 p90 p95 p99 max mean stdev isol% 84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42 2.81 lat-imp% 0 0 0 0 0 2.81 5.73 11.11 13.92 17.53 22.61 4.10 4.68 Result: isol=94.42:2.81% lat_imp=4.10%:4.68 work_csv=58.34% missing=0% Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: a647a524a467 ("block: don't call rq_qos_ops->done_bio if the bio isn't tracked") Cc: stable@vger.kernel.org # v5.15+ Cc: Ming Lei <ming.lei@redhat.com> Cc: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Link: https://lore.kernel.org/r/Yi7rdrzQEHjJLGKB@slm.duckdns.org Signed-off-by: Jens Axboe <axboe@kernel.dk> |
/linux-master/drivers/block/zram/ | ||
H A D | zcomp.h | diff da9556a2 Fri May 20 17:59:51 MDT 2016 Sergey Senozhatsky <sergey.senozhatsky@gmail.com> zram: user per-cpu compression streams Remove idle streams list and keep compression streams in per-cpu data. This removes two contented spin_lock()/spin_unlock() calls from write path and also prevent write OP from being preempted while holding the compression stream, which can cause slow downs. For instance, let's assume that we have N cpus and N-2 max_comp_streams.TASK1 owns the last idle stream, TASK2-TASK3 come in with the write requests: TASK1 TASK2 TASK3 zram_bvec_write() spin_lock find stream spin_unlock compress <<preempted>> zram_bvec_write() spin_lock find stream spin_unlock no_stream schedule zram_bvec_write() spin_lock find_stream spin_unlock no_stream schedule spin_lock release stream spin_unlock wake up TASK2 not only TASK2 and TASK3 will not get the stream, TASK1 will be preempted in the middle of its operation; while we would prefer it to finish compression and release the stream. Test environment: x86_64, 4 CPU box, 3G zram, lzo The following fio tests were executed: read, randread, write, randwrite, rw, randrw with the increasing number of jobs from 1 to 10. 4 streams 8 streams per-cpu =========================================================== jobs1 READ: 2520.1MB/s 2566.5MB/s 2491.5MB/s READ: 2102.7MB/s 2104.2MB/s 2091.3MB/s WRITE: 1355.1MB/s 1320.2MB/s 1378.9MB/s WRITE: 1103.5MB/s 1097.2MB/s 1122.5MB/s READ: 434013KB/s 435153KB/s 439961KB/s WRITE: 433969KB/s 435109KB/s 439917KB/s READ: 403166KB/s 405139KB/s 403373KB/s WRITE: 403223KB/s 405197KB/s 403430KB/s jobs2 READ: 7958.6MB/s 8105.6MB/s 8073.7MB/s READ: 6864.9MB/s 6989.8MB/s 7021.8MB/s WRITE: 2438.1MB/s 2346.9MB/s 3400.2MB/s WRITE: 1994.2MB/s 1990.3MB/s 2941.2MB/s READ: 981504KB/s 973906KB/s 1018.8MB/s WRITE: 981659KB/s 974060KB/s 1018.1MB/s READ: 937021KB/s 938976KB/s 987250KB/s WRITE: 934878KB/s 936830KB/s 984993KB/s jobs3 READ: 13280MB/s 13553MB/s 13553MB/s READ: 11534MB/s 11785MB/s 11755MB/s WRITE: 3456.9MB/s 3469.9MB/s 4810.3MB/s WRITE: 3029.6MB/s 3031.6MB/s 4264.8MB/s READ: 1363.8MB/s 1362.6MB/s 1448.9MB/s WRITE: 1361.9MB/s 1360.7MB/s 1446.9MB/s READ: 1309.4MB/s 1310.6MB/s 1397.5MB/s WRITE: 1307.4MB/s 1308.5MB/s 1395.3MB/s jobs4 READ: 20244MB/s 20177MB/s 20344MB/s READ: 17886MB/s 17913MB/s 17835MB/s WRITE: 4071.6MB/s 4046.1MB/s 6370.2MB/s WRITE: 3608.9MB/s 3576.3MB/s 5785.4MB/s READ: 1824.3MB/s 1821.6MB/s 1997.5MB/s WRITE: 1819.8MB/s 1817.4MB/s 1992.5MB/s READ: 1765.7MB/s 1768.3MB/s 1937.3MB/s WRITE: 1767.5MB/s 1769.1MB/s 1939.2MB/s jobs5 READ: 18663MB/s 18986MB/s 18823MB/s READ: 16659MB/s 16605MB/s 16954MB/s WRITE: 3912.4MB/s 3888.7MB/s 6126.9MB/s WRITE: 3506.4MB/s 3442.5MB/s 5519.3MB/s READ: 1798.2MB/s 1746.5MB/s 1935.8MB/s WRITE: 1792.7MB/s 1740.7MB/s 1929.1MB/s READ: 1727.6MB/s 1658.2MB/s 1917.3MB/s WRITE: 1726.5MB/s 1657.2MB/s 1916.6MB/s jobs6 READ: 21017MB/s 20922MB/s 21162MB/s READ: 19022MB/s 19140MB/s 18770MB/s WRITE: 3968.2MB/s 4037.7MB/s 6620.8MB/s WRITE: 3643.5MB/s 3590.2MB/s 6027.5MB/s READ: 1871.8MB/s 1880.5MB/s 2049.9MB/s WRITE: 1867.8MB/s 1877.2MB/s 2046.2MB/s READ: 1755.8MB/s 1710.3MB/s 1964.7MB/s WRITE: 1750.5MB/s 1705.9MB/s 1958.8MB/s jobs7 READ: 21103MB/s 20677MB/s 21482MB/s READ: 18522MB/s 18379MB/s 19443MB/s WRITE: 4022.5MB/s 4067.4MB/s 6755.9MB/s WRITE: 3691.7MB/s 3695.5MB/s 5925.6MB/s READ: 1841.5MB/s 1933.9MB/s 2090.5MB/s WRITE: 1842.7MB/s 1935.3MB/s 2091.9MB/s READ: 1832.4MB/s 1856.4MB/s 1971.5MB/s WRITE: 1822.3MB/s 1846.2MB/s 1960.6MB/s jobs8 READ: 20463MB/s 20194MB/s 20862MB/s READ: 18178MB/s 17978MB/s 18299MB/s WRITE: 4085.9MB/s 4060.2MB/s 7023.8MB/s WRITE: 3776.3MB/s 3737.9MB/s 6278.2MB/s READ: 1957.6MB/s 1944.4MB/s 2109.5MB/s WRITE: 1959.2MB/s 1946.2MB/s 2111.4MB/s READ: 1900.6MB/s 1885.7MB/s 2082.1MB/s WRITE: 1896.2MB/s 1881.4MB/s 2078.3MB/s jobs9 READ: 19692MB/s 19734MB/s 19334MB/s READ: 17678MB/s 18249MB/s 17666MB/s WRITE: 4004.7MB/s 4064.8MB/s 6990.7MB/s WRITE: 3724.7MB/s 3772.1MB/s 6193.6MB/s READ: 1953.7MB/s 1967.3MB/s 2105.6MB/s WRITE: 1953.4MB/s 1966.7MB/s 2104.1MB/s READ: 1860.4MB/s 1897.4MB/s 2068.5MB/s WRITE: 1858.9MB/s 1895.9MB/s 2066.8MB/s jobs10 READ: 19730MB/s 19579MB/s 19492MB/s READ: 18028MB/s 18018MB/s 18221MB/s WRITE: 4027.3MB/s 4090.6MB/s 7020.1MB/s WRITE: 3810.5MB/s 3846.8MB/s 6426.8MB/s READ: 1956.1MB/s 1994.6MB/s 2145.2MB/s WRITE: 1955.9MB/s 1993.5MB/s 2144.8MB/s READ: 1852.8MB/s 1911.6MB/s 2075.8MB/s WRITE: 1855.7MB/s 1914.6MB/s 2078.1MB/s perf stat 4 streams 8 streams per-cpu ==================================================================================================================== jobs1 stalled-cycles-frontend 23,174,811,209 ( 38.21%) 23,220,254,188 ( 38.25%) 23,061,406,918 ( 38.34%) stalled-cycles-backend 11,514,174,638 ( 18.98%) 11,696,722,657 ( 19.27%) 11,370,852,810 ( 18.90%) instructions 73,925,005,782 ( 1.22) 73,903,177,632 ( 1.22) 73,507,201,037 ( 1.22) branches 14,455,124,835 ( 756.063) 14,455,184,779 ( 755.281) 14,378,599,509 ( 758.546) branch-misses 69,801,336 ( 0.48%) 80,225,529 ( 0.55%) 72,044,726 ( 0.50%) jobs2 stalled-cycles-frontend 49,912,741,782 ( 46.11%) 50,101,189,290 ( 45.95%) 32,874,195,633 ( 35.11%) stalled-cycles-backend 27,080,366,230 ( 25.02%) 27,949,970,232 ( 25.63%) 16,461,222,706 ( 17.58%) instructions 122,831,629,690 ( 1.13) 122,919,846,419 ( 1.13) 121,924,786,775 ( 1.30) branches 23,725,889,239 ( 692.663) 23,733,547,140 ( 688.062) 23,553,950,311 ( 794.794) branch-misses 90,733,041 ( 0.38%) 96,320,895 ( 0.41%) 84,561,092 ( 0.36%) jobs3 stalled-cycles-frontend 66,437,834,608 ( 45.58%) 63,534,923,344 ( 43.69%) 42,101,478,505 ( 33.19%) stalled-cycles-backend 34,940,799,661 ( 23.97%) 34,774,043,148 ( 23.91%) 21,163,324,388 ( 16.68%) instructions 171,692,121,862 ( 1.18) 171,775,373,044 ( 1.18) 170,353,542,261 ( 1.34) branches 32,968,962,622 ( 628.723) 32,987,739,894 ( 630.512) 32,729,463,918 ( 717.027) branch-misses 111,522,732 ( 0.34%) 110,472,894 ( 0.33%) 99,791,291 ( 0.30%) jobs4 stalled-cycles-frontend 98,741,701,675 ( 49.72%) 94,797,349,965 ( 47.59%) 54,535,655,381 ( 33.53%) stalled-cycles-backend 54,642,609,615 ( 27.51%) 55,233,554,408 ( 27.73%) 27,882,323,541 ( 17.14%) instructions 220,884,807,851 ( 1.11) 220,930,887,273 ( 1.11) 218,926,845,851 ( 1.35) branches 42,354,518,180 ( 592.105) 42,362,770,587 ( 590.452) 41,955,552,870 ( 716.154) branch-misses 138,093,449 ( 0.33%) 131,295,286 ( 0.31%) 121,794,771 ( 0.29%) jobs5 stalled-cycles-frontend 116,219,747,212 ( 48.14%) 110,310,397,012 ( 46.29%) 66,373,082,723 ( 33.70%) stalled-cycles-backend 66,325,434,776 ( 27.48%) 64,157,087,914 ( 26.92%) 32,999,097,299 ( 16.76%) instructions 270,615,008,466 ( 1.12) 270,546,409,525 ( 1.14) 268,439,910,948 ( 1.36) branches 51,834,046,557 ( 599.108) 51,811,867,722 ( 608.883) 51,412,576,077 ( 729.213) branch-misses 158,197,086 ( 0.31%) 142,639,805 ( 0.28%) 133,425,455 ( 0.26%) jobs6 stalled-cycles-frontend 138,009,414,492 ( 48.23%) 139,063,571,254 ( 48.80%) 75,278,568,278 ( 32.80%) stalled-cycles-backend 79,211,949,650 ( 27.68%) 79,077,241,028 ( 27.75%) 37,735,797,899 ( 16.44%) instructions 319,763,993,731 ( 1.12) 319,937,782,834 ( 1.12) 316,663,600,784 ( 1.38) branches 61,219,433,294 ( 595.056) 61,250,355,540 ( 598.215) 60,523,446,617 ( 733.706) branch-misses 169,257,123 ( 0.28%) 154,898,028 ( 0.25%) 141,180,587 ( 0.23%) jobs7 stalled-cycles-frontend 162,974,812,119 ( 49.20%) 159,290,061,987 ( 48.43%) 88,046,641,169 ( 33.21%) stalled-cycles-backend 92,223,151,661 ( 27.84%) 91,667,904,406 ( 27.87%) 44,068,454,971 ( 16.62%) instructions 369,516,432,430 ( 1.12) 369,361,799,063 ( 1.12) 365,290,380,661 ( 1.38) branches 70,795,673,950 ( 594.220) 70,743,136,124 ( 597.876) 69,803,996,038 ( 732.822) branch-misses 181,708,327 ( 0.26%) 165,767,821 ( 0.23%) 150,109,797 ( 0.22%) jobs8 stalled-cycles-frontend 185,000,017,027 ( 49.30%) 182,334,345,473 ( 48.37%) 99,980,147,041 ( 33.26%) stalled-cycles-backend 105,753,516,186 ( 28.18%) 107,937,830,322 ( 28.63%) 51,404,177,181 ( 17.10%) instructions 418,153,161,055 ( 1.11) 418,308,565,828 ( 1.11) 413,653,475,581 ( 1.38) branches 80,035,882,398 ( 592.296) 80,063,204,510 ( 589.843) 79,024,105,589 ( 730.530) branch-misses 199,764,528 ( 0.25%) 177,936,926 ( 0.22%) 160,525,449 ( 0.20%) jobs9 stalled-cycles-frontend 210,941,799,094 ( 49.63%) 204,714,679,254 ( 48.55%) 114,251,113,756 ( 33.96%) stalled-cycles-backend 122,640,849,067 ( 28.85%) 122,188,553,256 ( 28.98%) 58,360,041,127 ( 17.35%) instructions 468,151,025,415 ( 1.10) 467,354,869,323 ( 1.11) 462,665,165,216 ( 1.38) branches 89,657,067,510 ( 585.628) 89,411,550,407 ( 588.990) 88,360,523,943 ( 730.151) branch-misses 218,292,301 ( 0.24%) 191,701,247 ( 0.21%) 178,535,678 ( 0.20%) jobs10 stalled-cycles-frontend 233,595,958,008 ( 49.81%) 227,540,615,689 ( 49.11%) 160,341,979,938 ( 43.07%) stalled-cycles-backend 136,153,676,021 ( 29.03%) 133,635,240,742 ( 28.84%) 65,909,135,465 ( 17.70%) instructions 517,001,168,497 ( 1.10) 516,210,976,158 ( 1.11) 511,374,038,613 ( 1.37) branches 98,911,641,329 ( 585.796) 98,700,069,712 ( 591.583) 97,646,761,028 ( 728.712) branch-misses 232,341,823 ( 0.23%) 199,256,308 ( 0.20%) 183,135,268 ( 0.19%) per-cpu streams tend to cause significantly less stalled cycles; execute less branches and hit less branch-misses. perf stat reported execution time 4 streams 8 streams per-cpu ==================================================================== jobs1 seconds elapsed 20.909073870 20.875670495 20.817838540 jobs2 seconds elapsed 18.529488399 18.720566469 16.356103108 jobs3 seconds elapsed 18.991159531 18.991340812 16.766216066 jobs4 seconds elapsed 19.560643828 19.551323547 16.246621715 jobs5 seconds elapsed 24.746498464 25.221646740 20.696112444 jobs6 seconds elapsed 28.258181828 28.289765505 22.885688857 jobs7 seconds elapsed 32.632490241 31.909125381 26.272753738 jobs8 seconds elapsed 35.651403851 36.027596308 29.108024711 jobs9 seconds elapsed 40.569362365 40.024227989 32.898204012 jobs10 seconds elapsed 44.673112304 43.874898137 35.632952191 Please see Link: http://marc.info/?l=linux-kernel&m=146166970727530 Link: http://marc.info/?l=linux-kernel&m=146174716719650 for more test results (under low memory conditions). Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Suggested-by: Minchan Kim <minchan@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
/linux-master/sound/firewire/oxfw/ | ||
H A D | oxfw.c | diff 52592932 Sun Feb 18 00:41:28 MST 2024 Takashi Sakamoto <o-takashi@sakamocchi.jp> ALSA: oxfw: add support for Miglia Harmony Audio Miglia Technology ships Harmony Audio 2004. It uses Oxford Semiconductor OXFW970 for communication function in IEEE 1394 bus. This commit adds support for the model. In my opinion, the firmware of ASIC is really the initial stage, since it has the following quirks. * It skips several isochronous cycles to transmit isochronous packets when receiving any asynchronous transaction. * The value of dbc field in the transmitted packet is the number of accumulated quadlets in CIP payload, instead of the accumulated data blocks. Furthermore, the value includes the quadlets of CIP payload in the packet. * It neither supports AV/C Stream Format Information command nor AV/C Extended Stream Format Information command. * The vendor and model information in root directory of configuration ROM includes some mistakes. Additionally, when operating at 96.0 kHz, it often skips much isochronous cycles to transmit the isochronous packets. The issue is detected as cycle discontinuity and ALSA PCM application receives -EIO at any operation for PCM substream. I have never found any workaround yet. $ config-rom-pretty-printer < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ----------------------------------------------------------------- 1024 04249e04 bus_info_length 4, crc_length 36, crc 40452 1028 31333934 bus_name "1394" 1032 20ff5003 irmc 0, cmc 0, isc 1, bmc 0, cyc_clk_acc 255, max_rec 5 (64) 1036 0030e002 company_id 0030e0 | 1040 00454647 device_id 8594474567 | EUI-64 13757098081207879 root directory ----------------------------------------------------------------- 1044 00062d69 directory_length 6, crc 11625 1048 030030e0 vendor 1052 8100000a --> descriptor leaf at 1092 1056 1700f970 model 1060 81000011 --> descriptor leaf at 1128 1064 0c0083c0 node capabilities: per IEEE 1394 1068 d1000001 --> unit directory at 1072 unit directory at 1072 ----------------------------------------------------------------- 1072 00046ff9 directory_length 4, crc 28665 (should be 43676) 1076 1200a02d specifier id 1080 13010001 version 1084 1700f970 model 1088 8100000f --> descriptor leaf at 1148 descriptor leaf at 1092 ----------------------------------------------------------------- 1092 00085f8a leaf_length 8, crc 24458 1096 00000000 textual descriptor 1100 00000000 minimal ASCII 1104 4d69676c "Migl" 1108 69612054 "ia T" 1112 6563686e "echn" 1116 6f6c6f67 "olog" 1120 79204c74 "y Lt" 1124 642e0000 "d." descriptor leaf at 1128 ----------------------------------------------------------------- 1128 00040514 leaf_length 4, crc 1300 1132 00000000 textual descriptor 1136 00000000 minimal ASCII 1140 4f584657 "OXFW" 1144 20393730 " 970" descriptor leaf at 1148 ----------------------------------------------------------------- 1148 0005a1dc leaf_length 5, crc 41436 1152 00000000 textual descriptor 1156 00000000 minimal ASCII 1160 4861726d "Harm" 1164 6f6e7941 "onyA" 1168 7564696f "udio" Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Link: https://lore.kernel.org/r/20240218074128.95210-5-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai <tiwai@suse.de> |
/linux-master/drivers/scsi/device_handler/ | ||
H A D | scsi_dh_rdac.c | diff 970f3f47 Wed Oct 21 10:22:51 MDT 2009 Chandra Seetharaman <sekharan@us.ibm.com> [SCSI] scsi_dh: Make rdac hardware handler's activate() async Batch up MODE_SELECT in rdac device handler. LSI RDAC storage has the capability of handling mode selects for multiple luns in a same command. Make use of that ability to send as few MODE SELECTs as possible to the storage controller as possible. This patch creates a work queue and queues up activate requests when a MODE SELECT is sent down the wire. When that MODE SELECT completes, it compiles queued up activate requests for multiple luns into a single MODE SELECT. This reduces the time to do failover/failback of large number of LUNS. Signed-off-by: Babu Moger <babu.moger@lsi.com> Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> |
/linux-master/drivers/net/wireless/mediatek/mt76/mt7921/ | ||
H A D | pci.c | diff 970be1df Fri Sep 24 09:54:40 MDT 2021 Felix Fietkau <nbd@nbd.name> mt76: disable BH around napi_schedule() calls napi_schedule() can call __raise_softirq_irqoff(), which can perform softirq handling, so it must not be called in a pure process context with BH enabled. Signed-off-by: Felix Fietkau <nbd@nbd.name> |
/linux-master/include/acpi/ | ||
H A D | actbl1.h | diff 970d9c9e Thu Apr 10 09:06:42 MDT 2008 Bob Moore <robert.moore@intel.com> ACPICA: Include file support for new ACPI tables Implemented header file support for new ACPI tables - BERT, ERST, EINJ, HEST, IBFT, UEFI, WDAT. Disassembler support is forthcoming. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> |
/linux-master/fs/btrfs/ | ||
H A D | locking.c | diff 970e74d9 Tue Apr 03 18:11:50 MDT 2018 David Sterba <dsterba@suse.com> btrfs: simplify waiting loop in btrfs_tree_lock Currently, the number of readers and writers is checked and in case there are any, wait and redo the locks. There's some duplication before the branches go back to again label, eg. calling wait_event on blocking_readers twice. The sequence is transformed loop: * wait for readers * wait for writers * write_lock * check readers, unlock and wait for readers, loop * check writers, unlock and wait for writers, loop The new sequence is not exactly the same due to the simplification, for readers it's slightly faster. For the writers, original code does * wait for writers * (loop) wait for readers * wait for writers -- again while the new goes directly to the reader check. This should behave the same on a contended lock with multiple writers and readers, but can reduce number of times we're waiting on something. Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: David Sterba <dsterba@suse.com> |
/linux-master/net/sched/ | ||
H A D | sch_cake.c | 046f6fd5 Fri Jul 06 09:37:19 MDT 2018 Toke Høiland-Jørgensen <toke@toke.dk> sched: Add Common Applications Kept Enhanced (cake) qdisc sch_cake targets the home router use case and is intended to squeeze the most bandwidth and latency out of even the slowest ISP links and routers, while presenting an API simple enough that even an ISP can configure it. Example of use on a cable ISP uplink: tc qdisc add dev eth0 cake bandwidth 20Mbit nat docsis ack-filter To shape a cable download link (ifb and tc-mirred setup elided) tc qdisc add dev ifb0 cake bandwidth 200mbit nat docsis ingress wash CAKE is filled with: * A hybrid Codel/Blue AQM algorithm, "Cobalt", tied to an FQ_Codel derived Flow Queuing system, which autoconfigures based on the bandwidth. * A novel "triple-isolate" mode (the default) which balances per-host and per-flow FQ even through NAT. * An deficit based shaper, that can also be used in an unlimited mode. * 8 way set associative hashing to reduce flow collisions to a minimum. * A reasonable interpretation of various diffserv latency/loss tradeoffs. * Support for zeroing diffserv markings for entering and exiting traffic. * Support for interacting well with Docsis 3.0 shaper framing. * Extensive support for DSL framing types. * Support for ack filtering. * Extensive statistics for measuring, loss, ecn markings, latency variation. A paper describing the design of CAKE is available at https://arxiv.org/abs/1804.07617, and will be published at the 2018 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN). This patch adds the base shaper and packet scheduler, while subsequent commits add the optional (configurable) features. The full userspace API and most data structures are included in this commit, but options not understood in the base version will be ignored. Various versions baking have been available as an out of tree build for kernel versions going back to 3.10, as the embedded router world has been running a few years behind mainline Linux. A stable version has been generally available on lede-17.01 and later. sch_cake replaces a combination of iptables, tc filter, htb and fq_codel in the sqm-scripts, with sane defaults and vastly simpler configuration. CAKE's principal author is Jonathan Morton, with contributions from Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moeller, Ryan Mounce, Tony Ambardar, Dean Scarff, Nils Andreas Svee, Dave Täht, and Loganaden Velvindron. Testing from Pete Heist, Georgios Amanakis, and the many other members of the cake@lists.bufferbloat.net mailing list. tc -s qdisc show dev eth2 qdisc cake 8017: root refcnt 2 bandwidth 1Gbit diffserv3 triple-isolate split-gso rtt 100.0ms noatm overhead 38 mpu 84 Sent 51504294511 bytes 37724591 pkt (dropped 6, overlimits 64958695 requeues 12) backlog 0b 0p requeues 12 memory used: 1053008b of 15140Kb capacity estimate: 970Mbit min/max network layer size: 28 / 1500 min/max overhead-adjusted size: 84 / 1538 average network hdr offset: 14 Bulk Best Effort Voice thresh 62500Kbit 1Gbit 250Mbit target 5.0ms 5.0ms 5.0ms interval 100.0ms 100.0ms 100.0ms pk_delay 5us 5us 6us av_delay 3us 2us 2us sp_delay 2us 1us 1us backlog 0b 0b 0b pkts 3164050 25030267 9530280 bytes 3227519915 35396974782 12879808898 way_inds 0 8 0 way_miss 21 366 25 way_cols 0 0 0 drops 5 0 1 marks 0 0 0 ack_drop 0 0 0 sp_flows 1 3 0 bk_flows 0 1 1 un_flows 0 0 0 max_len 68130 68130 68130 Tested-by: Pete Heist <peteheist@gmail.com> Tested-by: Georgios Amanakis <gamanakis@gmail.com> Signed-off-by: Dave Taht <dave.taht@gmail.com> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/arch/powerpc/lib/ | ||
H A D | feature-fixups.c | diff aa8a5e00 Tue Jan 09 09:07:15 MST 2018 Michael Ellerman <mpe@ellerman.id.au> powerpc/64s: Add support for RFI flush of L1-D cache On some CPUs we can prevent the Meltdown vulnerability by flushing the L1-D cache on exit from kernel to user mode, and from hypervisor to guest. This is known to be the case on at least Power7, Power8 and Power9. At this time we do not know the status of the vulnerability on other CPUs such as the 970 (Apple G5), pasemi CPUs (AmigaOne X1000) or Freescale CPUs. As more information comes to light we can enable this, or other mechanisms on those CPUs. The vulnerability occurs when the load of an architecturally inaccessible memory region (eg. userspace load of kernel memory) is speculatively executed to the point where its result can influence the address of a subsequent speculatively executed load. In order for that to happen, the first load must hit in the L1, because before the load is sent to the L2 the permission check is performed. Therefore if no kernel addresses hit in the L1 the vulnerability can not occur. We can ensure that is the case by flushing the L1 whenever we return to userspace. Similarly for hypervisor vs guest. In order to flush the L1-D cache on exit, we add a section of nops at each (h)rfi location that returns to a lower privileged context, and patch that with some sequence. Newer firmwares are able to advertise to us that there is a special nop instruction that flushes the L1-D. If we do not see that advertised, we fall back to doing a displacement flush in software. For guest kernels we support migration between some CPU versions, and different CPUs may use different flush instructions. So that we are prepared to migrate to a machine with a different flush instruction activated, we may have to patch more than one flush instruction at boot if the hypervisor tells us to. In the end this patch is mostly the work of Nicholas Piggin and Michael Ellerman. However a cast of thousands contributed to analysis of the issue, earlier versions of the patch, back ports testing etc. Many thanks to all of them. Tested-by: Jon Masters <jcm@redhat.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> |
/linux-master/drivers/gpu/drm/amd/amdgpu/ | ||
H A D | amdgpu_ras_eeprom.c | diff 970fd197 Wed Mar 10 04:10:11 MST 2021 Stanley.Yang <Stanley.Yang@amd.com> drm/amdgpu: fix send ras disable cmd when asic not support ras cause: It is necessary to send ras disable command to ras-ta during gfx block ras later init, because the ras capability is disable read from vbios for vega20 gaming, but the ras context is released during ras init process, this will cause send ras disable command to ras-to failed. how: Delay releasing ras context, the ras context will be released after gfx block later init done. Changed from V1: move release_ras_context into ras_resume Changed from V2: check BIT(UMC) is more reasonable before access eeprom table Signed-off-by: Stanley.Yang <Stanley.Yang@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> |
/linux-master/arch/mips/mm/ | ||
H A D | tlb-r4k.c | diff 970d032f Thu Oct 18 05:54:15 MDT 2012 Ralf Baechle <ralf@linux-mips.org> MIPS: Transparent Huge Pages support Signed-off-by: Ralf Baechle <ralf@linux-mips.org> |
/linux-master/kernel/ | ||
H A D | ucount.c | diff d7c9e99a Thu Apr 22 06:27:14 MDT 2021 Alexey Gladkov <legion@kernel.org> Reimplement RLIMIT_MEMLOCK on top of ucounts The rlimit counter is tied to uid in the user_namespace. This allows rlimit values to be specified in userns even if they are already globally exceeded by the user. However, the value of the previous user_namespaces cannot be exceeded. Changelog v11: * Fix issue found by lkp robot. v8: * Fix issues found by lkp-tests project. v7: * Keep only ucounts for RLIMIT_MEMLOCK checks instead of struct cred. v6: * Fix bug in hugetlb_file_setup() detected by trinity. Reported-by: kernel test robot <oliver.sang@intel.com> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexey Gladkov <legion@kernel.org> Link: https://lkml.kernel.org/r/970d50c70c71bfd4496e0e8d2a0a32feebebb350.1619094428.git.legion@kernel.org Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> |
/linux-master/drivers/i2c/busses/ | ||
H A D | i2c-ocores.c | diff 970d494c Wed Aug 08 00:54:32 MDT 2012 Thierry Reding <thierry.reding@avionic-design.de> i2c: ocores: Use devm_request_and_ioremap() Replacing the devm_request_mem_region() and devm_ioremap_nocache() calls by a single call to devm_request_and_ioremap() simplifies the code. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> |
/linux-master/drivers/staging/rtl8192e/ | ||
H A D | rtllib_tx.c | diff a65552cf Tue Oct 03 13:33:12 MDT 2023 Philipp Hortmann <philipp.g.hortmann@gmail.com> staging: rtl8192e: Remove equation in function rtllib_xmit_inter() Remove equation with raw_tx in function rtllib_xmit_inter() as it is always true. Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com> Link: https://lore.kernel.org/r/970cd327eaecab8565e7486bbf62e1440a3b44b7.1696360403.git.philipp.g.hortmann@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
/linux-master/drivers/staging/greybus/ | ||
H A D | arche-platform.c | diff 970dc85b Sun Jun 05 07:03:26 MDT 2016 Bryan O'Donoghue <bryan.odonoghue@linaro.org> greybus: timesync: Add timesync core driver This patch adds the core timesync functionality. 0. arche-platform.c/arche-apb-ctrl.c Modifies the platform layer to hook the incoming TIME_SYNC signal up to the timesync strobe IRQ handler. If the arche-platform driver can't satisfy the request for the wake-detect line, it will return -EAGAIN and the calling work-queue must reschedule the attempt to get exclusive access to the wake-detect pin logic. A private data field is added to the arche-platform driver to enable passing of a timesync pointer to the ISR responsible for synchronizing time. 1. timesync.c A new file added which contains all of the logic associated with sending greybus commands to SVC, APBx or Interfaces to enable, disable and disseminate timing information. 2. timesync_platform.c Any platform/arch specific code goes into timesync_platform.c. Originally the idea was to keep the x86 and ARM arch dependencies in a timesync_platform_arch.c file - however with further refinement that's currently not necessary however just-in-case it becomes necessary to resuscitate arch or platform specific methods for accessing timer resources that access shouldn't be part of the core timesync.c logic and so for the moment we access these timer resources through a thin access layer in timesync_platform.c. Expect this to go away long term ideally. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Acked-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> |
H A D | Makefile | diff 970dc85b Sun Jun 05 07:03:26 MDT 2016 Bryan O'Donoghue <bryan.odonoghue@linaro.org> greybus: timesync: Add timesync core driver This patch adds the core timesync functionality. 0. arche-platform.c/arche-apb-ctrl.c Modifies the platform layer to hook the incoming TIME_SYNC signal up to the timesync strobe IRQ handler. If the arche-platform driver can't satisfy the request for the wake-detect line, it will return -EAGAIN and the calling work-queue must reschedule the attempt to get exclusive access to the wake-detect pin logic. A private data field is added to the arche-platform driver to enable passing of a timesync pointer to the ISR responsible for synchronizing time. 1. timesync.c A new file added which contains all of the logic associated with sending greybus commands to SVC, APBx or Interfaces to enable, disable and disseminate timing information. 2. timesync_platform.c Any platform/arch specific code goes into timesync_platform.c. Originally the idea was to keep the x86 and ARM arch dependencies in a timesync_platform_arch.c file - however with further refinement that's currently not necessary however just-in-case it becomes necessary to resuscitate arch or platform specific methods for accessing timer resources that access shouldn't be part of the core timesync.c logic and so for the moment we access these timer resources through a thin access layer in timesync_platform.c. Expect this to go away long term ideally. Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Acked-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> |
/linux-master/drivers/spi/ | ||
H A D | spi-stm32.c | diff 970e8eaa Mon Jan 04 05:31:14 MST 2021 Marek Vasut <marex@denx.de> spi: stm32: Simplify stm32h7_spi_prepare_fthlv() Simplify stm32h7_spi_prepare_fthlv() function implementation, no functional change intended. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alain Volmat <alain.volmat@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Amelie Delaunay <amelie.delaunay@st.com> Cc: Antonio Borneo <antonio.borneo@st.com> Cc: Mark Brown <broonie@kernel.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Roman Guskov <rguskov@dh-electronics.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-spi@vger.kernel.org Link: https://lore.kernel.org/r/20210104123114.261596-1-marex@denx.de Signed-off-by: Mark Brown <broonie@kernel.org> |
/linux-master/arch/powerpc/kvm/ | ||
H A D | book3s.c | diff ca7f4203 Wed Mar 24 14:48:28 MDT 2010 Alexander Graf <agraf@suse.de> KVM: PPC: Implement alignment interrupt Mac OS X has some applications - namely the Finder - that require alignment interrupts to work properly. So we need to implement them. But the spec for 970 and 750 also looks different. While 750 requires the DSISR and DAR fields to reflect some instruction bits (DSISR) and the fault address (DAR), the 970 declares this as an optional feature. So we need to reconstruct DSISR and DAR manually. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Avi Kivity <avi@redhat.com> diff ca7f4203 Wed Mar 24 14:48:28 MDT 2010 Alexander Graf <agraf@suse.de> KVM: PPC: Implement alignment interrupt Mac OS X has some applications - namely the Finder - that require alignment interrupts to work properly. So we need to implement them. But the spec for 970 and 750 also looks different. While 750 requires the DSISR and DAR fields to reflect some instruction bits (DSISR) and the fault address (DAR), the 970 declares this as an optional feature. So we need to reconstruct DSISR and DAR manually. Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Avi Kivity <avi@redhat.com> |
/linux-master/drivers/cpufreq/ | ||
H A D | acpi-cpufreq.c | diff cab75e1c Tue Nov 08 10:01:03 MST 2022 Nathan Chancellor <nathan@kernel.org> cpufreq: ACPI: Remove unused variables 'acpi_cpufreq_online' and 'ret' Clang warns: drivers/cpufreq/acpi-cpufreq.c:970:24: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] acpi_cpufreq_online = ret; ^~~ drivers/cpufreq/acpi-cpufreq.c:960:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 1 error generated. Both ret and acpi_cpufreq_online are now unused so they can be safely removed, clearing up the warning. Fixes: 13fdbc8b8da6 ("cpufreq: ACPI: Defer setting boost MSRs") Link: https://github.com/ClangBuiltLinux/linux/issues/1757 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> diff cab75e1c Tue Nov 08 10:01:03 MST 2022 Nathan Chancellor <nathan@kernel.org> cpufreq: ACPI: Remove unused variables 'acpi_cpufreq_online' and 'ret' Clang warns: drivers/cpufreq/acpi-cpufreq.c:970:24: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] acpi_cpufreq_online = ret; ^~~ drivers/cpufreq/acpi-cpufreq.c:960:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 1 error generated. Both ret and acpi_cpufreq_online are now unused so they can be safely removed, clearing up the warning. Fixes: 13fdbc8b8da6 ("cpufreq: ACPI: Defer setting boost MSRs") Link: https://github.com/ClangBuiltLinux/linux/issues/1757 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
/linux-master/arch/powerpc/perf/ | ||
H A D | core-book3s.c | diff 1ce447b9 Mon Mar 26 14:47:34 MDT 2012 Benjamin Herrenschmidt <benh@kernel.crashing.org> powerpc/perf: Fix instruction address sampling on 970 and Power4 970 and Power4 don't support "continuous sampling" which means that when we aren't in marked instruction sampling mode (marked events), SIAR isn't updated with the last instruction sampled before the perf interrupt. On those processors, we must thus use the exception SRR0 value as the sampled instruction pointer. Those processors also don't support the SIPR and SIHV bits in MMCRA which means we need some kind of heuristic to decide if SIAR values represent kernel or user addresses. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> diff 1ce447b9 Mon Mar 26 14:47:34 MDT 2012 Benjamin Herrenschmidt <benh@kernel.crashing.org> powerpc/perf: Fix instruction address sampling on 970 and Power4 970 and Power4 don't support "continuous sampling" which means that when we aren't in marked instruction sampling mode (marked events), SIAR isn't updated with the last instruction sampled before the perf interrupt. On those processors, we must thus use the exception SRR0 value as the sampled instruction pointer. Those processors also don't support the SIPR and SIHV bits in MMCRA which means we need some kind of heuristic to decide if SIAR values represent kernel or user addresses. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> |
/linux-master/drivers/misc/ | ||
H A D | Kconfig | diff d210a002 Thu Sep 10 00:00:13 MDT 2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> misc: hisi_hikey_usb: add support for Hikey 970 The HiKey 970 board is similar to Hikey 960 with regards to its USB configutation: it also relies on a USB HUB that is used when DWC3 is at host mode. However, it requires a few extra DT settings, as it uses a voltage regulator and GPIO reset pin. Add support for them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/62843df9927b4d8dac5dc7c4a189567fa52ab2bb.1599717402.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> diff d210a002 Thu Sep 10 00:00:13 MDT 2020 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> misc: hisi_hikey_usb: add support for Hikey 970 The HiKey 970 board is similar to Hikey 960 with regards to its USB configutation: it also relies on a USB HUB that is used when DWC3 is at host mode. However, it requires a few extra DT settings, as it uses a voltage regulator and GPIO reset pin. Add support for them. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/62843df9927b4d8dac5dc7c4a189567fa52ab2bb.1599717402.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
Completed in 1111 milliseconds