aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-08-03sfc_ef100: TX path for EF100 NICsEdward Cree5-5/+396
Includes checksum offload and TSO, so declare those in our netdev features. Signed-off-by: Edward Cree <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03sfc_ef100: read Design Parameters at probe timeEdward Cree2-0/+220
Several parts of the EF100 architecture are parameterised (to allow varying capabilities on FPGAs according to resource constraints), and these parameters are exposed to the driver through a TLV-encoded region of the BAR. For the most part we either don't care about these values at all or just need to sanity-check them against the driver's assumptions, but there are a number of TSO limits which we record so that we will be able to check against them in the TX path when handling GSO skbs. Signed-off-by: Edward Cree <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03sfc_ef100: fail the probe if NIC uses unsol_ev creditsEdward Cree1-0/+6
In the future, EF100 is planned to have a credit-based scheme for handling unsolicited events, which drivers will need to use in order to function correctly. However, current EF100 hardware does not yet generate unsolicited events and the credit scheme has not yet been implemented in firmware. To prevent compatibility problems later if the current driver is used with future firmware which does implement it, we check for the corresponding capability flag (which that future firmware will set), and if found, we refuse to probe. Signed-off-by: Edward Cree <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03sfc_ef100: check firmware version at start-of-dayEdward Cree1-0/+40
Early in EF100 development there was a different format of event descriptor; if the NIC is somehow running the very old firmware which will use that format, fail the probe. Signed-off-by: Edward Cree <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03enetc: use napi_schedule to be compatible with PREEMPT_RTJiafei Pan1-1/+1
The driver calls napi_schedule_irqoff() from a context where, in RT, hardirqs are not disabled, since the IRQ handler is force-threaded. In the call path of this function, __raise_softirq_irqoff() is modifying its per-CPU mask of pending softirqs that must be processed, using or_softirq_pending(). The or_softirq_pending() function is not atomic, but since interrupts are supposed to be disabled, nobody should be preempting it, and the operation should be safe. Nonetheless, when running with hardirqs on, as in the PREEMPT_RT case, it isn't safe, and the pending softirqs mask can get corrupted, resulting in softirqs being lost and never processed. To have common code that works with PREEMPT_RT and with mainline Linux, we can use plain napi_schedule() instead. The difference is that napi_schedule() (via __napi_schedule) also calls local_irq_save, which disables hardirqs if they aren't already. But, since they already are disabled in non-RT, this means that in practice we don't see any measurable difference in throughput or latency with this patch. Signed-off-by: Jiafei Pan <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03dpaa2-eth: use napi_schedule to be compatible with PREEMPT_RTJiafei Pan1-1/+1
The driver calls napi_schedule_irqoff() from a context where, in RT, hardirqs are not disabled, since the IRQ handler is force-threaded. In the call path of this function, __raise_softirq_irqoff() is modifying its per-CPU mask of pending softirqs that must be processed, using or_softirq_pending(). The or_softirq_pending() function is not atomic, but since interrupts are supposed to be disabled, nobody should be preempting it, and the operation should be safe. Nonetheless, when running with hardirqs on, as in the PREEMPT_RT case, it isn't safe, and the pending softirqs mask can get corrupted, resulting in softirqs being lost and never processed. To have common code that works with PREEMPT_RT and with mainline Linux, we can use plain napi_schedule() instead. The difference is that napi_schedule() (via __napi_schedule) also calls local_irq_save, which disables hardirqs if they aren't already. But, since they already are disabled in non-RT, this means that in practice we don't see any measurable difference in throughput or latency with this patch. Signed-off-by: Jiafei Pan <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: dsa: loop: Set correct number of portsFlorian Fainelli1-1/+1
We only support DSA_LOOP_NUM_PORTS in the switch, do not tell the DSA core to allocate up to DSA_MAX_PORTS which is nearly the double (6 vs. 11). Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: dsa: loop: Wire-up MTU callbacksFlorian Fainelli1-0/+17
For now we simply store the port MTU into a per-port member. Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: dsa: loop: Move data structures to headerFlorian Fainelli1-31/+1
In preparation for adding support for a mockup data path, move the driver data structures to include/linux/dsa/loop.h such that we can share them between net/dsa/ and drivers/net/dsa/ later on. Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: dsa: loop: Support 4K VLANsFlorian Fainelli1-4/+2
Allocate a 4K array of VLANs instead of limiting ourselves to just 5 which is arbitrary. Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: dsa: loop: PVID should be per-portFlorian Fainelli1-4/+4
The PVID should be per-port, this is a preliminary change to support a 802.1Q data path in the driver. Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03cxgb4: add TC-MATCHALL IPv6 supportRahul Lakkireddy3-26/+82
Matching IPv6 traffic require allocating their own individual slots in TCAM. So, fetch additional slots to insert IPv6 rules. Also, fetch the cumulative stats of all the slots occupied by the Matchall rule. Signed-off-by: Rahul Lakkireddy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: dsa: sja1105: poll for extts events from a timerVladimir Oltean2-34/+50
The current poll interval is enough to ensure that rising and falling edge events are not lost for a 1 PPS signal with 50% duty cycle. But when we deliver the events to user space, it will try to infer if they were corresponding to a rising or to a falling edge (the kernel driver doesn't know that either). User space will try to make that inference based on the time at which the PPS master had emitted the pulse (i.e. if it's a .0 time, it's rising edge, if it's .5 time, it's falling edge). But there is no in-kernel API for retrieving the precise timestamp corresponding to a PPS master (aka perout) pulse. So user space has to guess even that. It will read the PTP time on the PPS master right after we've delivered the extts event, and declare that the PPS master time was just the closest integer second, based on 2 thresholds (lower than .25, or higher than .75, and ignore anything else). Except that, if we poll for extts events (and our hardware doesn't really help us, by not providing an interrupt), then there is a risk that the poll period (and therefore the time at which the event is delivered) might confuse user space. Because we are always scheduling the next extts poll at SJA1105_EXTTS_INTERVAL "from now" (that's the only thing that the schedule_delayed_work() API gives us), it means that the start time of the next delayed workqueue will always be shifted to the right a little bit (shifted with the SPI access duration of this workqueue run). In turn, because user space sees extts events that are non-periodic compared to the PPS master's time, this means that it might start making wrong guesses about rising/falling edge. To understand the effect, here is the output of ts2phc currently. Notice the 'src' timestamps of the 'SKIP extts' events, and how they have a large wander. They keep increasing until the upper limit for the ignore threshold (.75 seconds), after which the application starts ignoring the _other_ edge. ts2phc[26.624]: /dev/ptp3 SKIP extts index 0 at 21.449898912 src 21.657784518 ts2phc[27.133]: adding tstamp 21.949894240 to clock /dev/ptp3 ts2phc[27.133]: adding tstamp 22.000000000 to clock /dev/ptp1 ts2phc[27.133]: /dev/ptp3 offset 640 s2 freq +5112 ts2phc[27.636]: /dev/ptp3 SKIP extts index 0 at 22.449889360 src 22.669398022 ts2phc[28.140]: adding tstamp 22.949884376 to clock /dev/ptp3 ts2phc[28.140]: adding tstamp 23.000000000 to clock /dev/ptp1 ts2phc[28.140]: /dev/ptp3 offset 96 s2 freq +4760 ts2phc[28.644]: /dev/ptp3 SKIP extts index 0 at 23.449879504 src 23.677420422 ts2phc[29.153]: adding tstamp 23.949874704 to clock /dev/ptp3 ts2phc[29.153]: adding tstamp 24.000000000 to clock /dev/ptp1 ts2phc[29.153]: /dev/ptp3 offset -264 s2 freq +4429 ts2phc[29.656]: /dev/ptp3 SKIP extts index 0 at 24.449870008 src 24.689407238 ts2phc[30.160]: adding tstamp 24.949865376 to clock /dev/ptp3 ts2phc[30.160]: adding tstamp 25.000000000 to clock /dev/ptp1 ts2phc[30.160]: /dev/ptp3 offset -280 s2 freq +4334 ts2phc[30.664]: /dev/ptp3 SKIP extts index 0 at 25.449860760 src 25.697449926 ts2phc[31.168]: adding tstamp 25.949856176 to clock /dev/ptp3 ts2phc[31.168]: adding tstamp 26.000000000 to clock /dev/ptp1 ts2phc[31.168]: /dev/ptp3 offset -176 s2 freq +4354 ts2phc[31.672]: /dev/ptp3 SKIP extts index 0 at 26.449851584 src 26.705433606 ts2phc[32.180]: adding tstamp 26.949846992 to clock /dev/ptp3 ts2phc[32.180]: adding tstamp 27.000000000 to clock /dev/ptp1 ts2phc[32.180]: /dev/ptp3 offset -80 s2 freq +4397 ts2phc[32.684]: /dev/ptp3 SKIP extts index 0 at 27.449842384 src 27.717415110 ts2phc[33.192]: adding tstamp 27.949837768 to clock /dev/ptp3 ts2phc[33.192]: adding tstamp 28.000000000 to clock /dev/ptp1 ts2phc[33.192]: /dev/ptp3 offset 0 s2 freq +4453 ts2phc[33.696]: /dev/ptp3 SKIP extts index 0 at 28.449833128 src 28.729412902 ts2phc[34.200]: adding tstamp 28.949828472 to clock /dev/ptp3 ts2phc[34.200]: adding tstamp 29.000000000 to clock /dev/ptp1 ts2phc[34.200]: /dev/ptp3 offset 8 s2 freq +4461 ts2phc[34.704]: /dev/ptp3 SKIP extts index 0 at 29.449823816 src 29.737416038 ts2phc[35.208]: adding tstamp 29.949819152 to clock /dev/ptp3 ts2phc[35.208]: adding tstamp 30.000000000 to clock /dev/ptp1 ts2phc[35.208]: /dev/ptp3 offset -8 s2 freq +4447 ts2phc[35.712]: /dev/ptp3 SKIP extts index 0 at 30.449814496 src 30.745554982 ts2phc[36.216]: adding tstamp 30.949809840 to clock /dev/ptp3 ts2phc[36.216]: adding tstamp 31.000000000 to clock /dev/ptp1 ts2phc[36.216]: /dev/ptp3 offset -8 s2 freq +4445 ts2phc[36.468]: /dev/ptp3 SKIP extts index 0 at 31.449805184 src 31.501109446 ts2phc[36.972]: adding tstamp 31.949800536 to clock /dev/ptp3 ts2phc[36.972]: adding tstamp 32.000000000 to clock /dev/ptp1 ts2phc[36.972]: /dev/ptp3 offset -8 s2 freq +4442 ts2phc[37.480]: /dev/ptp3 SKIP extts index 0 at 32.449795896 src 32.513320070 ts2phc[37.984]: adding tstamp 32.949791248 to clock /dev/ptp3 ts2phc[37.984]: adding tstamp 33.000000000 to clock /dev/ptp1 ts2phc[37.984]: /dev/ptp3 offset 0 s2 freq +4448 Fix that by taking the following measures: - Schedule the poll from a timer. Because we are really scheduling the timer periodically, the extts events delivered to user space are periodic too, and don't suffer from the "shift-to-the-right" effect. - Increase the poll period to 6 times a second. This imposes a smaller upper bound to the shift that can occur to the delivery time of extts events, and makes user space (ts2phc) to always interpret correctly which events should be skipped and which shouldn't. - Move the SPI readout itself to the main PTP kernel thread, instead of the generic workqueue. This is because the timer runs in atomic context, but is also better than before, because if needed, we can chrt & taskset this kernel thread, to ensure it gets enough priority under load. After this patch, one can notice that the wander is greatly reduced, and that the latencies of one extts poll are not propagated to the next. The 'src' timestamp that is skipped is never larger than .65 seconds (which means .15 seconds larger than the time at which the real event occurred at, and .10 seconds smaller than the .75 upper threshold for ignoring the falling edge): ts2phc[40.076]: adding tstamp 34.949261296 to clock /dev/ptp3 ts2phc[40.076]: adding tstamp 35.000000000 to clock /dev/ptp1 ts2phc[40.076]: /dev/ptp3 offset 48 s2 freq +4631 ts2phc[40.568]: /dev/ptp3 SKIP extts index 0 at 35.449256496 src 35.595791078 ts2phc[41.064]: adding tstamp 35.949251744 to clock /dev/ptp3 ts2phc[41.064]: adding tstamp 36.000000000 to clock /dev/ptp1 ts2phc[41.064]: /dev/ptp3 offset -224 s2 freq +4374 ts2phc[41.552]: /dev/ptp3 SKIP extts index 0 at 36.449247088 src 36.579825574 ts2phc[42.044]: adding tstamp 36.949242456 to clock /dev/ptp3 ts2phc[42.044]: adding tstamp 37.000000000 to clock /dev/ptp1 ts2phc[42.044]: /dev/ptp3 offset -240 s2 freq +4290 ts2phc[42.536]: /dev/ptp3 SKIP extts index 0 at 37.449237848 src 37.563828774 ts2phc[43.028]: adding tstamp 37.949233264 to clock /dev/ptp3 ts2phc[43.028]: adding tstamp 38.000000000 to clock /dev/ptp1 ts2phc[43.028]: /dev/ptp3 offset -144 s2 freq +4314 ts2phc[43.520]: /dev/ptp3 SKIP extts index 0 at 38.449228656 src 38.547823238 ts2phc[44.012]: adding tstamp 38.949224048 to clock /dev/ptp3 ts2phc[44.012]: adding tstamp 39.000000000 to clock /dev/ptp1 ts2phc[44.012]: /dev/ptp3 offset -80 s2 freq +4335 ts2phc[44.508]: /dev/ptp3 SKIP extts index 0 at 39.449219432 src 39.535846118 ts2phc[44.996]: adding tstamp 39.949214816 to clock /dev/ptp3 ts2phc[44.996]: adding tstamp 40.000000000 to clock /dev/ptp1 ts2phc[44.996]: /dev/ptp3 offset -32 s2 freq +4359 ts2phc[45.488]: /dev/ptp3 SKIP extts index 0 at 40.449210192 src 40.515824678 ts2phc[45.980]: adding tstamp 40.949205568 to clock /dev/ptp3 ts2phc[45.980]: adding tstamp 41.000000000 to clock /dev/ptp1 ts2phc[45.980]: /dev/ptp3 offset 8 s2 freq +4390 ts2phc[46.636]: /dev/ptp3 SKIP extts index 0 at 41.449200928 src 41.664176902 ts2phc[47.132]: adding tstamp 41.949196288 to clock /dev/ptp3 ts2phc[47.132]: adding tstamp 42.000000000 to clock /dev/ptp1 ts2phc[47.132]: /dev/ptp3 offset 0 s2 freq +4384 ts2phc[47.620]: /dev/ptp3 SKIP extts index 0 at 42.449191656 src 42.648117190 ts2phc[48.112]: adding tstamp 42.949187016 to clock /dev/ptp3 ts2phc[48.112]: adding tstamp 43.000000000 to clock /dev/ptp1 ts2phc[48.112]: /dev/ptp3 offset 0 s2 freq +4384 ts2phc[48.604]: /dev/ptp3 SKIP extts index 0 at 43.449182384 src 43.632112582 ts2phc[49.100]: adding tstamp 43.949177736 to clock /dev/ptp3 ts2phc[49.100]: adding tstamp 44.000000000 to clock /dev/ptp1 ts2phc[49.100]: /dev/ptp3 offset -8 s2 freq +4376 ts2phc[49.588]: /dev/ptp3 SKIP extts index 0 at 44.449173096 src 44.616136774 ts2phc[50.080]: adding tstamp 44.949168464 to clock /dev/ptp3 ts2phc[50.080]: adding tstamp 45.000000000 to clock /dev/ptp1 ts2phc[50.080]: /dev/ptp3 offset 8 s2 freq +4390 ts2phc[50.572]: /dev/ptp3 SKIP extts index 0 at 45.449163816 src 45.600134662 ts2phc[51.064]: adding tstamp 45.949159160 to clock /dev/ptp3 ts2phc[51.064]: adding tstamp 46.000000000 to clock /dev/ptp1 ts2phc[51.064]: /dev/ptp3 offset -8 s2 freq +4376 ts2phc[51.556]: /dev/ptp3 SKIP extts index 0 at 46.449154528 src 46.584588550 ts2phc[52.048]: adding tstamp 46.949149896 to clock /dev/ptp3 ts2phc[52.048]: adding tstamp 47.000000000 to clock /dev/ptp1 ts2phc[52.048]: /dev/ptp3 offset 0 s2 freq +4382 ts2phc[52.540]: /dev/ptp3 SKIP extts index 0 at 47.449145256 src 47.568132198 ts2phc[53.032]: adding tstamp 47.949140616 to clock /dev/ptp3 ts2phc[53.032]: adding tstamp 48.000000000 to clock /dev/ptp1 ts2phc[53.032]: /dev/ptp3 offset 0 s2 freq +4382 ts2phc[53.524]: /dev/ptp3 SKIP extts index 0 at 48.449135968 src 48.552121446 ts2phc[54.016]: adding tstamp 48.949131320 to clock /dev/ptp3 ts2phc[54.016]: adding tstamp 49.000000000 to clock /dev/ptp1 ts2phc[54.016]: /dev/ptp3 offset 0 s2 freq +4382 ts2phc[54.512]: /dev/ptp3 SKIP extts index 0 at 49.449126680 src 49.540147014 ts2phc[55.000]: adding tstamp 49.949122040 to clock /dev/ptp3 ts2phc[55.000]: adding tstamp 50.000000000 to clock /dev/ptp1 ts2phc[55.000]: /dev/ptp3 offset 0 s2 freq +4382 ts2phc[55.492]: /dev/ptp3 SKIP extts index 0 at 50.449117400 src 50.520119078 ts2phc[55.988]: adding tstamp 50.949112768 to clock /dev/ptp3 ts2phc[55.988]: adding tstamp 51.000000000 to clock /dev/ptp1 ts2phc[55.988]: /dev/ptp3 offset 8 s2 freq +4390 ts2phc[56.476]: /dev/ptp3 SKIP extts index 0 at 51.449108120 src 51.504175910 ts2phc[57.132]: adding tstamp 51.949103480 to clock /dev/ptp3 ts2phc[57.132]: adding tstamp 52.000000000 to clock /dev/ptp1 ts2phc[57.132]: /dev/ptp3 offset 0 s2 freq +4384 ts2phc[57.624]: /dev/ptp3 SKIP extts index 0 at 52.449098840 src 52.651833574 ts2phc[58.116]: adding tstamp 52.949094200 to clock /dev/ptp3 ts2phc[58.116]: adding tstamp 53.000000000 to clock /dev/ptp1 ts2phc[58.116]: /dev/ptp3 offset 8 s2 freq +4392 ts2phc[58.612]: /dev/ptp3 SKIP extts index 0 at 53.449089560 src 53.639826918 ts2phc[59.100]: adding tstamp 53.949084920 to clock /dev/ptp3 ts2phc[59.100]: adding tstamp 54.000000000 to clock /dev/ptp1 ts2phc[59.100]: /dev/ptp3 offset 8 s2 freq +4394 ts2phc[59.592]: /dev/ptp3 SKIP extts index 0 at 54.449080272 src 54.619842278 ts2phc[60.084]: adding tstamp 54.949075624 to clock /dev/ptp3 ts2phc[60.084]: adding tstamp 55.000000000 to clock /dev/ptp1 ts2phc[60.084]: /dev/ptp3 offset 8 s2 freq +4397 ts2phc[60.576]: /dev/ptp3 SKIP extts index 0 at 55.449070968 src 55.603885542 ts2phc[61.068]: adding tstamp 55.949066312 to clock /dev/ptp3 ts2phc[61.068]: adding tstamp 56.000000000 to clock /dev/ptp1 ts2phc[61.068]: /dev/ptp3 offset 0 s2 freq +4391 ts2phc[61.560]: /dev/ptp3 SKIP extts index 0 at 56.449061680 src 56.587885798 ts2phc[62.052]: adding tstamp 56.949057032 to clock /dev/ptp3 ts2phc[62.052]: adding tstamp 57.000000000 to clock /dev/ptp1 ts2phc[62.052]: /dev/ptp3 offset -8 s2 freq +4383 Signed-off-by: Vladimir Oltean <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03mlxsw: spectrum_qdisc: Offload action trap for qeventsPetr Machata3-13/+95
When offloading action trap on a qevent, pass to_dev of NULL to the SPAN module to trigger the mirror to the CPU port. Query the buffer drops policer and use it for policing of the trapped traffic. Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03mlxsw: spectrum_trap: Add early_drop trapIdo Schimmel3-3/+53
As previously explained, packets that are dropped due to buffer related reasons (e.g., tail drop, early drop) can be mirrored to the CPU port. These packets are then trapped with one of the "mirror session" traps and their CQE includes the reason for which the packet was mirrored. Register with devlink a new trap, early_drop, and initialize the corresponding Rx listener with the appropriate mirror reason. Return an error in case user tries to change the traps' action, as this is not supported. Since Spectrum-1 does not support these traps, the above is only done for Spectrum-2 onwards. Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03mlxsw: spectrum_trap: Allow for per-ASIC traps initializationIdo Schimmel2-9/+75
Subsequent patches will need to register different traps for Spectrum-1 and Spectrum-2 onwards. Enable that by invoking a per-ASIC operation during traps initialization. Reviewed-by: Petr Machata <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03mlxsw: spectrum_trap: Allow for per-ASIC trap groups initializationIdo Schimmel4-9/+93
Subsequent patches will need to register different trap groups for Spectrum-1 and Spectrum-2 onwards. Enable that by invoking a per-ASIC operation during trap groups initialization. Reviewed-by: Petr Machata <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03mlxsw: spectrum_span: On policer_id_base_ref_count, use dec_and_testPetr Machata1-1/+2
When unsetting policer base, the SPAN code currently uses refcount_dec(). However that function splats when the counter reaches zero, because reaching zero without actually testing is in general indicative of a missing cleanup. There is no cleanup to be done here, but nonetheless, use refcount_dec_and_test() as required. Signed-off-by: Petr Machata <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03mlxsw: spectrum_trap: Use 'size_t' for array sizesIdo Schimmel2-5/+5
Use 'size_t' instead of 'u64' for array sizes, as this this is correct type to use for expressions involving sizeof(). Suggested-by: Petr Machata <[email protected]> Reviewed-by: Petr Machata <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03devlink: Pass extack when setting trap's action and group's parametersIdo Schimmel5-15/+26
A later patch will refuse to set the action of certain traps in mlxsw and also to change the policer binding of certain groups. Pass extack so that failure could be communicated clearly to user space. Reviewed-by: Petr Machata <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: Ido Schimmel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03Merge tag 'platform-drivers-x86-v5.9-1' of ↵Linus Torvalds17-114/+643
git://git.infradead.org/linux-platform-drivers-x86 Pull x86 platform driver updates from Andy Shevchenko: - ASUS WMI driver honors BAT1 name of the battery (quite a few new laptops are using it) - Dell WMI driver supports new key codes and backlight events - ThinkPad ACPI driver now may use standard charge threshold interface, it also has been updated to provide Laptop or Desktop mode to the user - Intel Speed Select Technology gained support on Sapphire Rapids platform - Regular update of Speed Select Technology tools - Mellanox has been updated to support complex attributes - PMC core driver has been fixed to show correct names for LPM0 register - HTTP links were replaced by HTTPS ones where it applies - Miscellaneous fixes and cleanups here and there * tag 'platform-drivers-x86-v5.9-1' of git://git.infradead.org/linux-platform-drivers-x86: (42 commits) platform/x86: asus-nb-wmi: Drop duplicate DMI quirk structures platform/x86: thinkpad_acpi: Make some symbols static platform/x86: thinkpad_acpi: add documentation for battery charge control platform/x86: thinkpad_acpi: use standard charge control attribute names platform/x86: thinkpad_acpi: remove unused defines platform/x86: ISST: drop a duplicated word in isst_if.h tools/power/x86/intel-speed-select: Update version for v5.9 tools/power/x86/intel-speed-select: Add retries for mail box commands tools/power/x86/intel-speed-select: Add option to delay mbox commands tools/power/x86/intel-speed-select: Ignore -o option processing on error tools/power/x86/intel-speed-select: Change path for caching topology info platform/x86: acerhdf: Replace HTTP links with HTTPS ones platform/x86: apple-gmux: Replace HTTP links with HTTPS ones platform/x86: pcengines-apuv2: revert wiring up simswitch GPIO as LED platform/x86: mlx-platform: Extend FAN platform data description platform_data/mlxreg: Add presence register field for FAN devices Documentation/ABI: Add new attribute for mlxreg-io sysfs interfaces platform/mellanox: mlxreg-io: Add support for complex attributes platform/x86: mlx-platform: Add more definitions for system attributes platform_data/mlxreg: Add support for complex attributes ...
2020-08-03net: stmmac: fix failed to suspend if phy based WOL is enabledJisheng Zhang1-1/+1
With the latest net-next tree, if test suspend/resume after enabling WOL, we get error as below: [ 487.086365] dpm_run_callback(): mdio_bus_suspend+0x0/0x30 returns -16 [ 487.086375] PM: Device stmmac-0:00 failed to suspend: error -16 -16 means -EBUSY, this is because I didn't enable wakeup of the correct device when implementing phy based WOL feature. To be honest, I caught the issue when implementing phy based WOL and then fix it locally, but forgot to amend the phy based wol patch. Today, I found the issue by testing net-next tree. Signed-off-by: Jisheng Zhang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03libnvdimm/security: ensure sysfs poll thread woke up and fetch updated attrJane Chu1-3/+8
commit 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite support") adds a sysfs_notify_dirent() to wake up userspace poll thread when the "overwrite" operation has completed. But the notification is issued before the internal dimm security state and flags have been updated, so the userspace poll thread wakes up and fetches the not-yet-updated attr and falls back to sleep, forever. But if user from another terminal issue "ndctl wait-overwrite nmemX" again, the command returns instantly. Link: https://lore.kernel.org/r/[email protected] Fixes: 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite support") Cc: Dave Jiang <[email protected]> Cc: Dan Williams <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Signed-off-by: Jane Chu <[email protected]> Signed-off-by: Vishal Verma <[email protected]>
2020-08-03libnvdimm/security: the 'security' attr never show 'overwrite' stateJane Chu1-2/+2
'security' attribute displays the security state of an nvdimm. During normal operation, the nvdimm state maybe one of 'disabled', 'unlocked' or 'locked'. When an admin issues # ndctl sanitize-dimm nmem0 --overwrite the attribute is expected to change to 'overwrite' until the overwrite operation completes. But tests on our systems show that 'overwrite' is never shown during the overwrite operation. i.e. # cat /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/nmem0/security unlocked the attribute remain 'unlocked' through out the operation, consequently "ndctl wait-overwrite nmem0" command doesn't wait at all. The driver tracks the state in 'nvdimm->sec.flags': when the operation starts, it adds an overwrite bit to the flags; and when the operation completes, it removes the bit. Hence security_show() should check the 'overwrite' bit first, in order to indicate the actual state when multiple bits are set in the flags. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Dave Jiang <[email protected]> Signed-off-by: Jane Chu <[email protected]> Signed-off-by: Vishal Verma <[email protected]>
2020-08-03libnvdimm/security: fix a typoJane Chu1-1/+1
commit d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute") introduced a typo, causing a 'nvdimm->sec.flags' update being overwritten by the subsequent update meant for 'nvdimm->sec.ext_flags'. Link: https://lore.kernel.org/r/[email protected] Fixes: d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute") Cc: Dan Williams <[email protected]> Reviewed-by: Dave Jiang <[email protected]> Signed-off-by: Jane Chu <[email protected]> Signed-off-by: Vishal Verma <[email protected]>
2020-08-03Merge tag 'ras-core-2020-08-03' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 RAS updates from Ingo Molnar: "Boris is on vacation and he asked us to send you the pending RAS bits: - Print the PPIN field on CPUs that fill them out - Fix an MCE injection bug - Simplify a kzalloc in dev_mcelog_init_device()" * tag 'ras-core-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/mce, EDAC/mce_amd: Print PPIN in machine check records x86/mce/dev-mcelog: Use struct_size() helper in kzalloc() x86/mce/inject: Fix a wrong assignment of i_mce.status
2020-08-03Merge tag 'x86-cpu-2020-08-03' of ↵Linus Torvalds3-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 cpu updates from Ingo Molar: - prepare for Intel's new SERIALIZE instruction - enable split-lock debugging on more CPUs - add more Intel CPU models - optimize stack canary initialization a bit - simplify the Spectre logic a bit * tag 'x86-cpu-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/cpu: Refactor sync_core() for readability x86/cpu: Relocate sync_core() to sync_core.h x86/cpufeatures: Add enumeration for SERIALIZE instruction x86/split_lock: Enable the split lock feature on Sapphire Rapids and Alder Lake CPUs x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family x86/stackprotector: Pre-initialize canary for secondary CPUs x86/speculation: Merge one test in spectre_v2_user_select_mitigation()
2020-08-03Merge tag 'x86-cleanups-2020-08-03' of ↵Linus Torvalds1-4/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 cleanups from Ingo Molnar: "Misc cleanups all around the place" * tag 'x86-cleanups-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/ioperm: Initialize pointer bitmap with NULL rather than 0 x86: uv: uv_hub.h: Delete duplicated word x86: cmpxchg_32.h: Delete duplicated word x86: bootparam.h: Delete duplicated word x86/mm: Remove the unused mk_kernel_pgd() #define x86/tsc: Remove unused "US_SCALE" and "NS_SCALE" leftover macros x86/ioapic: Remove unused "IOAPIC_AUTO" define x86/mm: Drop unused MAX_PHYSADDR_BITS x86/msr: Move the F15h MSRs where they belong x86/idt: Make idt_descr static initrd: Remove erroneous comment x86/mm/32: Fix -Wmissing prototypes warnings for init.c cpu/speculation: Add prototype for cpu_show_srbds() x86/mm: Fix -Wmissing-prototypes warnings for arch/x86/mm/init.c x86/asm: Unify __ASSEMBLY__ blocks x86/cpufeatures: Mark two free bits in word 3 x86/msr: Lift AMD family 0x15 power-specific MSRs
2020-08-04pinctrl: stmfx: Use irqchip templateLinus Walleij1-15/+17
This makes the driver use the irqchip template to assign properties to the gpio_irq_chip instead of using the explicit calls to gpiochip_irqchip_add_nested() and gpiochip_set_nested_irqchip(). The irqchip is instead added while adding the gpiochip. Signed-off-by: Linus Walleij <[email protected]> Cc: Amelie Delaunay <[email protected]> Cc: Benjamin Gaignard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-08-04pinctrl: amd: Use irqchip templateLinus Walleij1-11/+10
This makes the driver use the irqchip template to assign properties to the gpio_irq_chip instead of using the explicit call to gpiochip_irqchip_add(). The irqchip is instead added while adding the gpiochip. Signed-off-by: Linus Walleij <[email protected]> Cc: Shyam Sundar S K <[email protected]> Cc: Sandeep Singh <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-08-04pinctrl: mediatek: fix build for tristate changesRandy Dunlap1-0/+1
Export mtk_is_virt_gpio() for the case when CONFIG_PINCTRL_MTK=y CONFIG_PINCTRL_MTK_V2=y CONFIG_PINCTRL_MTK_MOORE=y CONFIG_PINCTRL_MTK_PARIS=m to fix this build error: ERROR: modpost: "mtk_is_virt_gpio" [drivers/pinctrl/mediatek/pinctrl-paris.ko] undefined! Signed-off-by: Randy Dunlap <[email protected]> Cc: Sean Wang <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04pinctrl: samsung: Use bank name as irqchip nameMarek Szyprowski1-26/+32
Use the bank name as the irqchip name. This name is later visible in /proc/interrupts, what makes it possible to easily identify each GPIO interrupt. /proc/interrupts before this patch: 143: 0 exynos4210_wkup_irq_chip 7 Edge hdmi 144: 0 exynos4210_wkup_irq_chip 6 Level wm8994 145: 1 exynos4210_wkup_irq_chip 7 Edge max77686-pmic, max77686-rtc 146: 1 exynos_gpio_irq_chip 3 Edge 3-0048 /proc/interrupts after this patch: 143: 0 gpx3 7 Edge hdmi 144: 0 gpx3 6 Level wm8994 145: 1 gpx0 7 Edge max77686-pmic, max77686-rtc 146: 1 gpm2 3 Edge 3-0048 Handling of the eint_wake_mask_value has been reworked, because each bank has now its own exynos_irq_chip structure allocated. Signed-off-by: Marek Szyprowski <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04pinctrl: core: print gpio in pins debugfs fileDrew Fustini1-0/+21
If there is a gpio range mapping for the pin, then print out the gpio chip and line index for the pin in the debugfs 'pins' file with the format: "[line-index]:[gpio-label]" Here is example output on the BeagleBoard.org PocketBeagle (AM3358): /sys/kernel/debug/pinctrl/44e10800.pinmux-pinctrl-single/pins pin 25 (PIN25) 25:gpio-32-63 44e10864 00000037 pinctrl-single pin 26 (PIN26) 26:gpio-32-63 44e10868 00000037 pinctrl-single pin 27 (PIN27) 27:gpio-32-63 44e1086c 00000037 pinctrl-single pin 28 (PIN28) 0:? 44e10870 00000036 pinctrl-single pin 29 (PIN29) 0:? 44e10874 00000006 pinctrl-single pin 30 (PIN30) 28:gpio-32-63 44e10878 00000027 pinctrl-single pin 31 (PIN31) 29:gpio-32-63 44e1087c 00000037 pinctrl-single pin 32 (PIN32) 30:gpio-32-63 44e10880 00000037 pinctrl-single pin 33 (PIN33) 31:gpio-32-63 44e10884 00000037 pinctrl-single pin 34 (PIN34) 0:gpio-64-95 44e10888 00000037 pinctrl-single pin 35 (PIN35) 1:gpio-64-95 44e1088c 00000037 pinctrl-single Suggested-by: Andy Shevchenko <[email protected]> Suggested-by: Tony Lindgren <[email protected]> Signed-off-by: Drew Fustini <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04pinctrl: mediatek: add mt6779 eint supportHanks Chen1-0/+8
add driver setting to support mt6779 eint Signed-off-by: Mars Cheng <[email protected]> Signed-off-by: Hanks Chen <[email protected]> Acked-by: Sean Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04pinctrl: mediatek: add pinctrl support for MT6779 SoCHanks Chen4-0/+2875
This adds MT6779 pinctrl driver based on MediaTek pinctrl-paris core. Signed-off-by: Mars Cheng <[email protected]> Signed-off-by: Andy Teng <[email protected]> Signed-off-by: Hanks Chen <[email protected]> Acked-by: Sean Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04pinctrl: mediatek: avoid virtual gpio trying to set regHanks Chen3-0/+33
for virtual gpios, they should not do reg setting and should behave as expected for eint function. Signed-off-by: Mars Cheng <[email protected]> Signed-off-by: Hanks Chen <[email protected]> Acked-by: Sean Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04gpio: wcove: Request IRQ after all initialisation doneAndy Shevchenko1-7/+7
There is logically better to request IRQ when we initialise all structures. Align the driver with the rest on the same matter. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04gpio: crystalcove: Free IRQ on error pathAndy Shevchenko1-15/+3
It appears that all, but request_irq(), calls in the driver are device managed. In unlikely case of devm_gpiochip_add_data() failure the IRQ left requested. Free IRQ on error path by switching to devm_request_threaded_irq() API. Byproduct of this change is a drop of ->remove() callback completely. Fixes: 945e72db36bd ("gpio: crystalcove: Use irqchip template") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04gpio: pca953x: Request IRQ after all initialisation doneAndy Shevchenko1-11/+11
There is logically better to request IRQ when we initialise all structures. Align the driver with the rest on the same matter. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-04gpio: don't use same lockdep class for all devm_gpiochip_add_data usersAhmad Fatoum1-5/+8
Commit 959bc7b22bd2 ("gpio: Automatically add lockdep keys") documents in its commits message its intention to "create a unique class key for each driver". It does so by having gpiochip_add_data add in-place the definition of two static lockdep classes for LOCKDEP use. That way, every caller of the macro adds their gpiochip with unique lockdep classes. There are many indirect callers of gpiochip_add_data, however, via use of devm_gpiochip_add_data. devm_gpiochip_add_data has external linkage and all its users will share the same lockdep classes, which probably is not intended. Fix this by replicating the gpio_chip_add_data statics-in-macro for the devm_ version as well. Fixes: 959bc7b22bd2 ("gpio: Automatically add lockdep keys") Signed-off-by: Ahmad Fatoum <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
2020-08-03fsl/fman: fix eth hash table allocationFlorinel Iordache1-1/+1
Fix memory allocation for ethernet address hash table. The code was wrongly allocating an array for eth hash table which is incorrect because this is the main structure for eth hash table (struct eth_hash_t) that contains inside a number of elements. Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support") Signed-off-by: Florinel Iordache <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03fsl/fman: check dereferencing null pointerFlorinel Iordache3-4/+4
Add a safe check to avoid dereferencing null pointer Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support") Signed-off-by: Florinel Iordache <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03fsl/fman: fix unreachable codeFlorinel Iordache1-1/+0
The parameter 'priority' is incorrectly forced to zero which ultimately induces logically dead code in the subsequent lines. Fixes: 57ba4c9b56d8 ("fsl/fman: Add FMan MAC support") Signed-off-by: Florinel Iordache <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03fsl/fman: fix dereference null return valueFlorinel Iordache1-1/+8
Check before using returned value to avoid dereferencing null pointer. Fixes: 18a6c85fcc78 ("fsl/fman: Add FMan Port Support") Signed-off-by: Florinel Iordache <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03fsl/fman: use 32-bit unsigned integerFlorinel Iordache1-2/+1
Potentially overflowing expression (ts_freq << 16 and intgr << 16) declared as type u32 (32-bit unsigned) is evaluated using 32-bit arithmetic and then used in a context that expects an expression of type u64 (64-bit unsigned) which ultimately is used as 16-bit unsigned by typecasting to u16. Fixed by using an unsigned 32-bit integer since the value is truncated anyway in the end. Fixes: 414fd46e7762 ("fsl/fman: Add FMan support") Signed-off-by: Florinel Iordache <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-04gpio: max732x: Use irqchip templateLinus Walleij1-15/+15
This makes the driver use the irqchip template to assign properties to the gpio_irq_chip instead of using the explicit calls to gpiochip_irqchip_add_nested() and gpiochip_set_nested_irqchip(). The irqchip is instead added while adding the gpiochip. Signed-off-by: Linus Walleij <[email protected]> Tested-by: Sam Protsenko <[email protected]> Reviewed-by: Sam Protsenko <[email protected]> Cc: Sam Protsenko <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-08-04gpio: stmpe: Move chip registrationLinus Walleij1-6/+6
Make sure to register the GPIO chip after requesting the interrupt and setting up the IRQ members of the irqchip. Fixes: 9745079609df ("gpio: stmpe: Use irqchip template") Reported-by: Serge Semin <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Cc: Patrice Chotard <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-08-03net: spider_net: Remove a useless memsetChristophe JAILLET1-2/+0
Avoid a memset after a call to 'dma_alloc_coherent()'. This is useless since commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: spider_net: Fix the size used in a 'dma_free_coherent()' callChristophe JAILLET1-2/+2
Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()', in 'spider_net_init_chain()'. Fixes: d4ed8f8d1fb7 ("Spidernet DMA coalescing") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-08-03net: sgi: ioc3-eth: Fix the size used in some 'dma_free_coherent()' callsChristophe JAILLET1-2/+2
Update the size used in 'dma_free_coherent()' in order to match the one used in the corresponding 'dma_alloc_coherent()'. Fixes: 369a782af0f1 ("net: sgi: ioc3-eth: ensure tx ring is 16k aligned.") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.