aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-08-30vt_kdsetmode: extend console lockingLinus Torvalds1-4/+6
As per the long-suffering comment. Reported-by: Minh Yuan <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Jiri Slaby <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-08-30console: consume APC, DM, DCSnick black1-4/+27
The Linux console's VT102 implementation already consumes OSC ("Operating System Command") sequences, probably because that's how palette changes are transmitted. In addition to OSC, there are three other major clases of ANSI control strings: APC ("Application Program Command"), PM ("Privacy Message"), and DCS ("Device Control String"). They are handled similarly to OSC in terms of termination. Source: vt100.net Add three new enumerated states, one for each of these types. All three are handled the same way right now--they simply consume input until terminated. I hope to expand upon this firmament in the future. Add new predicate ansi_control_string(), returning true for any of these states. Replace explicit checks against ESosc with calls to this function. Transition to these states appropriately from the escape initiation (ESesc) state. This was motivated by the following Notcurses bugs: https://github.com/dankamongmen/notcurses/issues/2050 https://github.com/dankamongmen/notcurses/issues/1828 https://github.com/dankamongmen/notcurses/issues/2069 where standard VT sequences are not consumed by the Linux console. It's not necessary that the Linux console *support* these sequences, but it ought *consume* these well-specified classes of sequences. Tested by sending a variety of escape sequences to the console, and verifying that they still worked, or were now properly consumed. Verified that the escapes were properly terminated at a generic level. Verified that the Notcurses tools continued to show expected output on the Linux console, except now without escape bleedthrough. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: nick black <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: Tetsuo Handa <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-08-30string: improve default out-of-line memcmp() implementationLinus Torvalds1-0/+16
This just does the "if the architecture does efficient unaligned handling, start the memcmp using 'unsigned long' accesses", since Nikolay Borisov found a load that cares. This is basically the minimal patch, and limited to architectures that are known to not have slow unaligned handling. We've had the stupid byte-at-a-time version forever, and nobody has ever even noticed before, so let's keep the fix minimal. A potential further improvement would be to align one of the sources in order to at least minimize unaligned cases, but the only real case of bigger memcmp() users seems to be the FIDEDUPERANGE ioctl(). As David Sterba says, the dedupe ioctl is typically called on ranges spanning many pages so the common case will all be page-aligned anyway. All the relevant architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS, so I'm not going to worry about the combination of a very rare use-case and a rare architecture until somebody actually hits it. Particularly since Nikolay also tested the more complex patch with extra alignment handling code, and it only added overhead. Link: https://lore.kernel.org/lkml/[email protected]/ Reported-by: Nikolay Borisov <[email protected]> Cc: David Sterba <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-08-30Merge branch 'rework/printk_safe-removal' into for-linusPetr Mladek14-544/+192
2021-08-30Merge branch 'rework/fixup-for-5.15' into for-linusPetr Mladek1-2/+5
2021-08-30io-wq: fix wakeup race when adding new workJens Axboe1-4/+4
When new work is added, io_wqe_enqueue() checks if we need to wake or create a new worker. But that check is done outside the lock that otherwise synchronizes us with a worker going to sleep, so we can end up in the following situation: CPU0 CPU1 lock insert work unlock atomic_read(nr_running) != 0 lock atomic_dec(nr_running) no wakeup needed Hold the wqe lock around the "need to wakeup" check. Then we can also get rid of the temporary work_flags variable, as we know the work will remain valid as long as we hold the lock. Cc: [email protected] Reported-by: Andres Freund <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-08-30io-wq: wqe and worker locks no longer need to be IRQ safeJens Axboe1-31/+28
io_uring no longer queues async work off completion handlers that run in hard or soft interrupt context, and that use case was the only reason that io-wq had to use IRQ safe locks for wqe and worker locks. Signed-off-by: Jens Axboe <[email protected]>
2021-08-30io-wq: check max_worker limits if a worker transitions bound stateJens Axboe1-3/+30
For the two places where new workers are created, we diligently check if we are allowed to create a new worker. If we're currently at the limit of how many workers of a given type we can have, then we don't create any new ones. If you have a mixed workload with various types of bound and unbounded work, then it can happen that a worker finishes one type of work and is then transitioned to the other type. For this case, we don't check if we are actually allowed to do so. This can cause io-wq to temporarily exceed the allowed number of workers for a given type. When retrieving work, check that the types match. If they don't, check if we are allowed to transition to the other type. If not, then don't handle the new work. Cc: [email protected] Reported-by: Johannes Lundberg <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-08-30Merge tag 'asoc-v5.15' of ↵Takashi Iwai1689-13189/+37688
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Updates for v5.15 Quite a quiet release this time, mostly a combination of cleanups and a good set of new drivers. - Lots of cleanups and improvements to the Intel drivers, including some new systems support. - New support for AMD Vangoh, CUI CMM-4030D-261, Mediatek Mt8195, Renesas RZ/G2L Mediatek Mt8195, RealTek RT101P, Renesas RZ/G2L,, Rockchip RK3568 S/PDIF.
2021-08-30Merge branch 'for-5.15-verbose-console' into for-linusPetr Mladek3-10/+22
2021-08-30Merge branch 'for-5.15-printk-index' into for-linusPetr Mladek10015-196617/+747351
2021-08-30dt-bindings: Use 'enum' instead of 'oneOf' plus 'const' entriesRob Herring20-75/+75
'enum' is equivalent to 'oneOf' with a list of 'const' entries, but 'enum' is more concise and yields better error messages. Cc: Maxime Ripard <[email protected]> Cc: Vignesh R <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Lee Jones <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Bjorn Helgaas <[email protected]> Cc: Kishon Vijay Abraham I <[email protected]> Cc: Daniel Lezcano <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Acked-by: Sakari Ailus <[email protected]> (mipi-ccs) Acked-by: Mark Brown <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Acked-By: Vinod Koul <[email protected]> Acked-by: Wolfram Sang <[email protected]> # for I2C Acked-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-08-30net: ipv4: Fix the warning for dereferenceYajun Deng1-1/+3
Add a if statements to avoid the warning. Dan Carpenter report: The patch faf482ca196a: "net: ipv4: Move ip_options_fragment() out of loop" from Aug 23, 2021, leads to the following Smatch complaint: net/ipv4/ip_output.c:833 ip_do_fragment() warn: variable dereferenced before check 'iter.frag' (see line 828) Reported-by: Dan Carpenter <[email protected]> Fixes: faf482ca196a ("net: ipv4: Move ip_options_fragment() out of loop") Link: https://lore.kernel.org/netdev/20210830073802.GR7722@kadam/T/#t Signed-off-by: Yajun Deng <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30Merge remote-tracking branch 'asoc/for-5.15' into asoc-linusMark Brown171-1282/+18985
2021-08-30Merge remote-tracking branch 'asoc/for-5.14' into asoc-linusMark Brown4-3/+4
2021-08-30net: qrtr: make checks in qrtr_endpoint_post() stricterDan Carpenter1-2/+6
These checks are still not strict enough. The main problem is that if "cb->type == QRTR_TYPE_NEW_SERVER" is true then "len - hdrlen" is guaranteed to be 4 but we need to be at least 16 bytes. In fact, we can reject everything smaller than sizeof(*pkt) which is 20 bytes. Also I don't like the ALIGN(size, 4). It's better to just insist that data is needs to be aligned at the start. Fixes: 0baa99ee353c ("net: qrtr: Allow non-immediate node routing") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30fix array-index-out-of-bounds in taprio_changeHaimin Zhang1-1/+3
syzbot report an array-index-out-of-bounds in taprio_change index 16 is out of range for type '__u16 [16]' that's because mqprio->num_tc is lager than TC_MAX_QUEUE,so we check the return value of netdev_set_num_tc. Reported-by: [email protected] Signed-off-by: Haimin Zhang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: fix NULL pointer reference in cipso_v4_doi_free王贇1-2/+2
In netlbl_cipsov4_add_std() when 'doi_def->map.std' alloc failed, we sometime observe panic: BUG: kernel NULL pointer dereference, address: ... RIP: 0010:cipso_v4_doi_free+0x3a/0x80 ... Call Trace: netlbl_cipsov4_add_std+0xf4/0x8c0 netlbl_cipsov4_add+0x13f/0x1b0 genl_family_rcv_msg_doit.isra.15+0x132/0x170 genl_rcv_msg+0x125/0x240 This is because in cipso_v4_doi_free() there is no check on 'doi_def->map.std' when doi_def->type got value 1, which is possibe, since netlbl_cipsov4_add_std() haven't initialize it before alloc 'doi_def->map.std'. This patch just add the check to prevent panic happen in similar cases. Reported-by: Abaci <[email protected]> Signed-off-by: Michael Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30Merge branch 'inet-exceptions-less-predictable'David S. Miller2-17/+34
Eric Dumazet says: ==================== inet: make exception handling less predictible This second round of patches is addressing Keyu Man recommendations to make linux hosts more robust against a class of brute force attacks. ==================== Signed-off-by: David S. Miller <[email protected]>
2021-08-30ipv4: make exception cache less predictibleEric Dumazet1-16/+30
Even after commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in fnhe_hashfun()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, by 50% in average, we do not expect this to be a problem. This patch is more complex than the prior one (IPv6 equivalent), because IPv4 was reusing the oldest entry. Since we need to be able to evict more than one entry per update_or_create_fnhe() call, I had to replace fnhe_oldest() with fnhe_remove_oldest(). Also note that we will queue extra kfree_rcu() calls under stress, which hopefully wont be a too big issue. Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Keyu Man <[email protected]> Cc: Willy Tarreau <[email protected]> Signed-off-by: David S. Miller <[email protected]> Reviewed-by: David Ahern <[email protected]> Tested-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30ipv6: make exception cache less predictibleEric Dumazet1-1/+4
Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"), an attacker can still use brute force to learn some secrets from a victim linux host. One way to defeat these attacks is to make the max depth of the hash table bucket a random value. Before this patch, each bucket of the hash table used to store exceptions could contain 6 items under attack. After the patch, each bucket would contains a random number of items, between 6 and 10. The attacker can no longer infer secrets. This is slightly increasing memory size used by the hash table, we do not expect this to be a problem. Following patch is dealing with the same issue in IPv4. Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: Keyu Man <[email protected]> Cc: Wei Wang <[email protected]> Cc: Martin KaFai Lau <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30ASoC: Revert PCM trigger changesMark Brown2-130/+23
These have turned up some issues in further testing. Signed-off-by: Mark Brown <[email protected]>
2021-08-30s390: remove SCHED_CORE from defconfigsHeiko Carstens2-2/+0
This causes too many problems. Enable it again when everything has been sorted out. Signed-off-by: Heiko Carstens <[email protected]>
2021-08-30x86: xen: platform-pci-unplug: use pr_err() and pr_warn() instead of raw ↵zhaoxiao1-7/+9
printk() Since we have the nice helpers pr_err() and pr_warn(), use them instead of raw printk(). [[email protected]] Move the "#define pr_fmt" above the #includes in order to avoid build warnings due to redefinition. Signed-off-by: zhaoxiao <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30drivers/xen/xenbus/xenbus_client.c: fix bugon.cocci warningsJing Yangyang1-6/+3
Use BUG_ON instead of a if condition followed by BUG. Generated by: scripts/coccinelle/misc/bugon.cocci Reported-by: Zeal Robot <[email protected]> Signed-off-by: Jing Yangyang <[email protected]> Reviewed-by: SeongJae Park <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30xen/blkfront: don't trust the backend response data blindlyJuergen Gross1-17/+53
Today blkfront will trust the backend to send only sane response data. In order to avoid privilege escalations or crashes in case of malicious backends verify the data to be within expected limits. Especially make sure that the response always references an outstanding request. Introduce a new state of the ring BLKIF_STATE_ERROR which will be switched to in case an inconsistency is being detected. Recovering from this state is possible only via removing and adding the virtual device again (e.g. via a suspend/resume cycle). Make all warning messages issued due to valid error responses rate limited in order to avoid message floods being triggered by a malicious backend. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30xen/blkfront: don't take local copy of a request from the ring pageJuergen Gross1-10/+15
In order to avoid a malicious backend being able to influence the local copy of a request build the request locally first and then copy it to the ring page instead of doing it the other way round as today. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30xen/blkfront: read response from backend only onceJuergen Gross1-17/+18
In order to avoid problems in case the backend is modifying a response on the ring page while the frontend has already seen it, just read the response into a local buffer in one go and then operate on that buffer only. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Acked-by: Roger Pau Monné <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller14-234/+345
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Clean up and consolidate ct ecache infrastructure by merging ct and expect notifiers, from Florian Westphal. 2) Missing counters and timestamp in nfnetlink_queue and _log conntrack information. 3) Missing error check for xt_register_template() in iptables mangle, as a incremental fix for the previous pull request, also from Florian Westphal. 4) Add netfilter hooks for the SRv6 lightweigh tunnel driver, from Ryoga Sato. The hooks are enabled via nf_hooks_lwtunnel sysctl to make sure existing netfilter rulesets do not break. There is a static key to disable the hooks by default. The pktgen_bench_xmit_mode_netif_receive.sh shows no noticeable impact in the seg6_input path for non-netfilter users: similar numbers with and without this patch. This is a sample of the perf report output: 11.67% kpktgend_0 [ipv6] [k] ipv6_get_saddr_eval 7.89% kpktgend_0 [ipv6] [k] __ipv6_addr_label 7.52% kpktgend_0 [ipv6] [k] __ipv6_dev_get_saddr 6.63% kpktgend_0 [kernel.vmlinux] [k] asm_exc_nmi 4.74% kpktgend_0 [ipv6] [k] fib6_node_lookup_1 3.48% kpktgend_0 [kernel.vmlinux] [k] pskb_expand_head 3.33% kpktgend_0 [ipv6] [k] ip6_rcv_core.isra.29 3.33% kpktgend_0 [ipv6] [k] seg6_do_srh_encap 2.53% kpktgend_0 [ipv6] [k] ipv6_dev_get_saddr 2.45% kpktgend_0 [ipv6] [k] fib6_table_lookup 2.24% kpktgend_0 [kernel.vmlinux] [k] ___cache_free 2.16% kpktgend_0 [ipv6] [k] ip6_pol_route 2.11% kpktgend_0 [kernel.vmlinux] [k] __ipv6_addr_type ==================== Signed-off-by: David S. Miller <[email protected]>
2021-08-30xen: assume XENFEAT_gnttab_map_avail_bits being set for pv guestsJuergen Gross1-34/+2
XENFEAT_gnttab_map_avail_bits is always set in Xen 4.0 and newer. Remove coding assuming it might be zero. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30xen: assume XENFEAT_mmu_pt_update_preserve_ad being set for pv guestsJuergen Gross2-12/+4
XENFEAT_mmu_pt_update_preserve_ad is always set in Xen 4.0 and newer. Remove coding assuming it might be zero. Signed-off-by: Juergen Gross <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30xen: check required Xen featuresJuergen Gross1-0/+18
Linux kernel is not supported to run on Xen versions older than 4.0. Add tests for required Xen features always being present in Xen 4.0 and newer. Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30xen: fix setting of max_pfn in shared_infoJuergen Gross1-2/+2
Xen PV guests are specifying the highest used PFN via the max_pfn field in shared_info. This value is used by the Xen tools when saving or migrating the guest. Unfortunately this field is misnamed, as in reality it is specifying the number of pages (including any memory holes) of the guest, so it is the highest used PFN + 1. Renaming isn't possible, as this is a public Xen hypervisor interface which needs to be kept stable. The kernel will set the value correctly initially at boot time, but when adding more pages (e.g. due to memory hotplug or ballooning) a real PFN number is stored in max_pfn. This is done when expanding the p2m array, and the PFN stored there is even possibly wrong, as it should be the last possible PFN of the just added P2M frame, and not one which led to the P2M expansion. Fix that by setting shared_info->max_pfn to the last possible PFN + 1. Fixes: 98dd166ea3a3c3 ("x86/xen/p2m: hint at the last populated P2M entry") Cc: [email protected] Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-08-30Merge branch 'IXP46x-PTP-Timer'David S. Miller7-77/+171
Linus Walleij says: ==================== IXP46x PTP Timer clean-up and DT ChangeLog v2->v3: - Dropped the patch enabling compile tests: we are still dependent on some machine-specific headers. The plan is to get rid of this after device tree conversion. We include one of the compile testing fixes anyway, because it is nice to have fixed. - Rebased on the latest net-next ==================== Signed-off-by: David S. Miller <[email protected]>
2021-08-30ixp4xx_eth: Probe the PTP module from the device treeLinus Walleij1-2/+13
This adds device tree probing support for the PTP module adjacent to the ethernet module. It is pretty straight forward, all resources are in the device tree as they come to the platform device. Cc: Arnd Bergmann <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30ixp4xx_eth: Add devicetree bindingsLinus Walleij1-0/+54
This adds device tree bindings for the IXP46x PTP Timer, a companion to the IXP4xx ethernet in newer platforms. Cc: [email protected] Cc: Arnd Bergmann <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30ixp4xx_eth: Stop referring to GPIOsLinus Walleij1-56/+28
The driver is being passed interrupts, then looking up the same interrupts as GPIOs a second time to convert them into interrupts and set properties on them. This is pointless: the GPIO and irqchip APIs of a GPIO chip are orthogonal. Just request the interrupts and be done with it, drop reliance on any GPIO functions or definitions. Use devres-managed functions and add a small devress quirk to unregister the clock as well and we can rely on devres to handle all the resources and cut down a bunch of boilerplate in the process. Cc: Arnd Bergmann <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30ixp4xx_eth: fix compile-testingArnd Bergmann1-4/+3
Change the driver to use portable integer types to avoid warnings during compile testing, including: drivers/net/ethernet/xscale/ixp4xx_eth.c:721:21: error: cast to 'u32 *' (aka 'unsigned int *') from smaller integer type 'int' [-Werror,-Wint-to-pointer-cast] memcpy_swab32(mem, (u32 *)((int)skb->data & ~3), bytes / 4); ^ drivers/net/ethernet/xscale/ixp4xx_eth.c:963:12: error: incompatible pointer types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'dma_addr_t *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types] &port->desc_tab_phys))) ^~~~~~~~~~~~~~~~~~~~ include/linux/dmapool.h:27:20: note: passing argument to parameter 'handle' here dma_addr_t *handle); ^ Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30ixp4xx_eth: make ptp support a platform driverArnd Bergmann6-34/+92
After the recent ixp4xx cleanups, the ptp driver has gained a build failure in some configurations: drivers/net/ethernet/xscale/ptp_ixp46x.c: In function 'ptp_ixp_init': drivers/net/ethernet/xscale/ptp_ixp46x.c:290:51: error: 'IXP4XX_TIMESYNC_BASE_VIRT' undeclared (first use in this function) Avoid the last bit of hardcoded constants from platform headers by turning the ptp driver bit into a platform driver and passing the IRQ and MMIO address as resources. This is a bit tricky: - The interface between the two drivers is now the new ixp46x_ptp_find() function, replacing the global ixp46x_phc_index variable. The call is done as late as possible, in hwtstamp_set(), to ensure that the ptp device is fully probed. - As the ptp driver is now called by the network driver, the link dependency is reversed, which in turn requires a small Makefile hack - The GPIO number is still left hardcoded. This is clearly not great, but it can be addressed later. Note that commit 98ac0cc270b7 ("ARM: ixp4xx: Convert to MULTI_IRQ_HANDLER") changed the IRQ number to something meaningless. Passing the correct IRQ in a resource fixes this. - When the PTP driver is disabled, ethtool .get_ts_info() now correctly lists only software timestamping regardless of the hardware. Signed-off-by: Arnd Bergmann <[email protected]> [Fix a missing include] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30Merge branch 'hns3-cleanups'David S. Miller7-630/+1260
Guangbin Huang says: ==================== net: hns3: add some cleanups This series includes some cleanups for the HNS3 ethernet driver. ==================== Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: hns3: uniform parameter name of hclge_ptp_clean_tx_hwts()Hao Chen1-1/+1
The parameter name of hclge_ptp_clean_tx_hwts() in declaration is "dev", but the definition of this function is used the common name "hdev" as other functions, so modify it. Signed-off-by: Hao Chen <[email protected]> Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: hnss3: use max() to simplify codeHao Chen1-2/+1
Replace the "? :" statement wich max() to simplify code. Signed-off-by: Hao Chen <[email protected]> Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: hns3: modify a print format of hns3_dbg_queue_map()Hao Chen1-1/+1
The type of tqp_vector->vector_irq is int, so modify its print format to "%d". Signed-off-by: Hao Chen <[email protected]> Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: hns3: refine function hclge_dbg_dump_tm_pri()Guangbin Huang1-28/+42
To improve flexibility, simplicity and maintainability to dump info of every element of tm priority, add a struct hclge_dbg_item array of tm priority and fill string of every data according to this array. Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: hns3: reconstruct function hclge_ets_validate()Guangbin Huang1-12/+35
This patch reconstructs function hclge_ets_validate() to reduce the code cycle complexity and make code more concise. Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: hns3: reconstruct function hns3_self_testPeng Li1-37/+64
This patch reconstructs function hns3_self_test to reduce the code cycle complexity and make code more concise. Signed-off-by: Peng Li <[email protected]> Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30net: hns3: initialize each member of structure array on a separate lineJiaran Zhang1-549/+1116
To make the format of each member initialization of structure array clearer, initialize each member on a separate line. Signed-off-by: Jiaran Zhang <[email protected]> Signed-off-by: Guangbin Huang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30Merge branch 'bnxt_en-fw-messages'David S. Miller13-1998/+2906
Michael Chan says: ==================== bnxt_en: Implement new driver APIs to send FW messages The current driver APIs to send messages to the firmware allow only one outstanding message in flight. There is only one buffer for the firmware response for each firmware channel. To send a firmware message, all callers must take a mutex and it is released after the firmware response has been read. This scheme does not allow multiple firmware messages in flight. Firmware may take a long time to respond to some messages (e.g. NVRAM related ones) and this causes the mutex to be held for a long time, blocking other callers. This patchset intoduces the new driver APIs to address the above shortcomings. The new APIs are compatible with new and old firmware. But the new deferred firmware response mechanism will require newer firmware in order to allow multiple outstanding firmware commands. All callers are updated to use the new APIs. v2: Patch 4 and patch 9 updated to fix issues reported by test robot ==================== Signed-off-by: David S. Miller <[email protected]>
2021-08-30bnxt_en: support multiple HWRM commands in flightEdwin Peer4-39/+113
Add infrastructure to maintain a pending list of HWRM commands awaiting completion and reduce the scope of the hwrm_cmd_lock mutex so that it protects only the request mailbox. The mailbox is free to use for one or more concurrent commands after receiving deferred response events. For uniformity and completeness, use the same pending list for collecting completions for commands that respond via a completion ring. These commands are only used for freeing rings and for IRQ test and we only support one such command in flight. Note deferred responses are also only supported on the main channel. The secondary channel (KONG) does not support deferred responses. Signed-off-by: Edwin Peer <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-08-30bnxt_en: remove legacy HWRM interfaceEdwin Peer4-106/+1
There are no longer any callers relying on the old API. Signed-off-by: Edwin Peer <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>