summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-02-15Merge branch 'pm-opp' into pmRafael J. Wysocki
* pm-opp: (37 commits) PM / devfreq: Add required OPPs support to passive governor PM / devfreq: Cache OPP table reference in devfreq OPP: Add function to look up required OPP's for a given OPP opp: Replace ENOTSUPP with EOPNOTSUPP opp: Fix "foo * bar" should be "foo *bar" opp: Don't ignore clk_get() errors other than -ENOENT opp: Update bandwidth requirements based on scaling up/down opp: Allow lazy-linking of required-opps opp: Remove dev_pm_opp_set_bw() devfreq: tegra30: Migrate to dev_pm_opp_set_opp() drm: msm: Migrate to dev_pm_opp_set_opp() cpufreq: qcom: Migrate to dev_pm_opp_set_opp() opp: Implement dev_pm_opp_set_opp() opp: Update parameters of _set_opp_custom() opp: Allow _generic_set_opp_clk_only() to work for non-freq devices opp: Allow _generic_set_opp_regulator() to work for non-freq devices opp: Allow _set_opp() to work for non-freq devices opp: Split _set_opp() out of dev_pm_opp_set_rate() opp: Keep track of currently programmed OPP opp: No need to check clk for errors ...
2021-02-15Merge branches 'pm-sleep', 'pm-core', 'pm-domains' and 'pm-clk'Rafael J. Wysocki
* pm-sleep: PM: sleep: Constify static struct attribute_group PM: sleep: Use dev_printk() when possible PM: sleep: No need to check PF_WQ_WORKER in thaw_kernel_threads() * pm-core: PM: runtime: Fix typos and grammar PM: runtime: Fix resposible -> responsible in runtime.c * pm-domains: PM: domains: Simplify the calculation of variables PM: domains: Add "performance" column to debug summary PM: domains: Make of_genpd_add_subdomain() return -EPROBE_DEFER PM: domains: Make set_performance_state() callback optional PM: domains: use device's next wakeup to determine domain idle state PM: domains: inform PM domain of a device's next wakeup * pm-clk: PM: clk: make PM clock layer compatible with clocks that must sleep
2021-02-15Merge branches 'pm-cpuidle' and 'pm-cpufreq'Rafael J. Wysocki
* pm-cpuidle: MAINTAINERS: cpuidle: exynos: include header in file pattern intel_idle: remove definition of DEBUG * pm-cpufreq: cpufreq: Remove unused flag CPUFREQ_PM_NO_WARN cpufreq: Remove CPUFREQ_STICKY flag cpufreq: intel_pstate: Remove repeated word cpufreq: remove tango driver cpufreq: brcmstb-avs-cpufreq: Fix resource leaks in ->remove() cpufreq: brcmstb-avs-cpufreq: Free resources in error path cpufreq: qcom-hw: enable boost support cpufreq: tegra20: Use resource-managed API cpufreq: intel_pstate: Get per-CPU max freq via MSR_HWP_CAPABILITIES if available cpufreq: intel_pstate: Rename two functions cpufreq: intel_pstate: Change intel_pstate_get_hwp_max() argument cpufreq: intel_pstate: Always read hwp_cap_cached with READ_ONCE()
2021-02-15Merge tag 'irqchip-5.12' of ↵Thomas Gleixner
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates from Marc Zyngier - New driver for the MIPS-based Realtek RTL838x/RTL839x SoC - Conversion of the sun6i-r support code to a hierarchical setup - Fix wake-up interrupts for the ls-extirq driver - Fix MSI allocation for the loongson-pch-msi driver - Add compatible strings for new Qualcomm SoCs - Tidy up a few Kconfig entries (IMX, CSKY) - Spelling phyksiz - Remove the sirfsoc and tango drivers Link: https://lore.kernel.org/r/20210214124015.3333457-1-maz@kernel.org
2021-02-15Merge branch 'edac-misc' into edac-updates-for-v5.12Borislav Petkov
2021-02-14lightnvm: pblk: Replace guid_copy() with export_guid()/import_guid()Andy Shevchenko
There is a specific API to treat raw data as GUID, i.e. export_guid() and import_guid(). Use them instead of guid_copy() with explicit casting. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Matias Bjørling <matias.bjorling@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-02-14lightnvm: fix unnecessary NULL check warningsTian Tao
Remove NULL checks before vfree() to fix these warnings: ./drivers/lightnvm/pblk-gc.c:27:2-7: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Signed-off-by: Matias Bjørling <matias.bjorling@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-02-14net: mvpp2: improve Networking Complex Control register namingStefan Chulski
GENCONF_CTRL0_PORTX naming improved. Non functional change. Signed-off-by: Stefan Chulski <stefanc@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mvpp2: improve mvpp2_get_sram returnStefan Chulski
Use PTR_ERR_OR_ZERO instead of IS_ERR and PTR_ERR. Non functional change. Signed-off-by: Stefan Chulski <stefanc@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mvpp2: improve Packet Processor version checkStefan Chulski
Use >= MVPP22 instead of != MVPP21. Non functional change. Signed-off-by: Stefan Chulski <stefanc@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mvpp2: simplify PPv2 version ID readStefan Chulski
PPv2.1 contain 0 in Version ID register, priv->hw_version check can be removed. Signed-off-by: Stefan Chulski <stefanc@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: dsa: propagate extack to .port_vlan_filteringVladimir Oltean
Some drivers can't dynamically change the VLAN filtering option, or impose some restrictions, it would be nice to propagate this info through netlink instead of printing it to a kernel log that might never be read. Also netlink extack includes the module that emitted the message, which means that it's easier to figure out which ones are driver-generated errors as opposed to command misuse. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: dsa: propagate extack to .port_vlan_addVladimir Oltean
Allow drivers to communicate their restrictions to user space directly, instead of printing to the kernel log. Where the conversion would have been lossy and things like VLAN ID could no longer be conveyed (due to the lack of support for printf format specifier in netlink extack), I chose to keep the messages in full form to the kernel log only, and leave it up to individual driver maintainers to move more messages to extack. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: dsa: tag_ocelot_8021q: add support for PTP timestampingVladimir Oltean
For TX timestamping, we use the felix_txtstamp method which is common with the regular (non-8021q) ocelot tagger. This method says that skb deferral is needed, prepares a timestamp request ID, and puts a clone of the skb in a queue waiting for the timestamp IRQ. felix_txtstamp is called by dsa_skb_tx_timestamp() just before the tagger's xmit method. In the tagger xmit, we divert the packets classified by dsa_skb_tx_timestamp() as PTP towards the MMIO-based injection registers, and we declare them as dead towards dsa_slave_xmit. If not PTP, we proceed with normal tag_8021q stuff. Then the timestamp IRQ fires, the clone queued up from felix_txtstamp is matched to the TX timestamp retrieved from the switch's FIFO based on the timestamp request ID, and the clone is delivered to the stack. On RX, thanks to the VCAP IS2 rule that redirects the frames with an EtherType for 1588 towards two destinations: - the CPU port module (for MMIO based extraction) and - if the "no XTR IRQ" workaround is in place, the dsa_8021q CPU port the relevant data path processing starts in the ptp_classify_raw BPF classifier installed by DSA in the RX data path (post tagger, which is completely unaware that it saw a PTP packet). This time we can't reuse the same implementation of .port_rxtstamp that also works with the default ocelot tagger. That is because felix_rxtstamp is given an skb with a freshly stripped DSA header, and it says "I don't need deferral for its RX timestamp, it's right in it, let me show you"; and it just points to the header right behind skb->data, from where it unpacks the timestamp and annotates the skb with it. The same thing cannot happen with tag_ocelot_8021q, because for one thing, the skb did not have an extraction frame header in the first place, but a VLAN tag with no timestamp information. So the code paths in felix_rxtstamp for the regular and 8021q tagger are completely independent. With tag_8021q, the timestamp must come from the packet's duplicate delivered to the CPU port module, but there is potentially complex logic to be handled [ and prone to reordering ] if we were to just start reading packets from the CPU port module, and try to match them to the one we received over Ethernet and which needs an RX timestamp. So we do something simple: we tell DSA "give me some time to think" (we request skb deferral by returning false from .port_rxtstamp) and we just drop the frame we got over Ethernet with no attempt to match it to anything - we just treat it as a notification that there's data to be processed from the CPU port module's queues. Then we proceed to read the packets from those, one by one, which we deliver up the stack, timestamped, using netif_rx - the same function that any driver would use anyway if it needed RX timestamp deferral. So the assumption is that we'll come across the PTP packet that triggered the CPU extraction notification eventually, but we don't know when exactly. Thanks to the VCAP IS2 trap/redirect rule and the exclusion of the CPU port module from the flooding replicators, only PTP frames should be present in the CPU port module's RX queues anyway. There is just one conflict between the VCAP IS2 trapping rule and the semantics of the BPF classifier. Namely, ptp_classify_raw() deems general messages as non-timestampable, but still, those are trapped to the CPU port module since they have an EtherType of ETH_P_1588. So, if the "no XTR IRQ" workaround is in place, we need to run another BPF classifier on the frames extracted over MMIO, to avoid duplicates being sent to the stack (once over Ethernet, once over MMIO). It doesn't look like it's possible to install VCAP IS2 rules based on keys extracted from the 1588 frame headers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: dsa: felix: setup MMIO filtering rules for PTP when using tag_8021qVladimir Oltean
Since the tag_8021q tagger is software-defined, it has no means by itself for retrieving hardware timestamps of PTP event messages. Because we do want to support PTP on ocelot even with tag_8021q, we need to use the CPU port module for that. The RX timestamp is present in the Extraction Frame Header. And because we can't use NPI mode which redirects the CPU queues to an "external CPU" (meaning the ARM CPU running Linux), then we need to poll the CPU port module through the MMIO registers to retrieve TX and RX timestamps. Sadly, on NXP LS1028A, the Felix switch was integrated into the SoC without wiring the extraction IRQ line to the ARM GIC. So, if we want to be notified of any PTP packets received on the CPU port module, we have a problem. There is a possible workaround, which is to use the Ethernet CPU port as a notification channel that packets are available on the CPU port module as well. When a PTP packet is received by the DSA tagger (without timestamp, of course), we go to the CPU extraction queues, poll for it there, then we drop the original Ethernet packet and masquerade the packet retrieved over MMIO (plus the timestamp) as the original when we inject it up the stack. Create a quirk in struct felix is selected by the Felix driver (but not by Seville, since that doesn't support PTP at all). We want to do this such that the workaround is minimally invasive for future switches that don't require this workaround. The only traffic for which we need timestamps is PTP traffic, so add a redirection rule to the CPU port module for this. Currently we only have the need for PTP over L2, so redirection rules for UDP ports 319 and 320 are TBD for now. Note that for the workaround of matching of PTP-over-Ethernet-port with PTP-over-MMIO queues to work properly, both channels need to be absolutely lossless. There are two parts to achieving that: - We keep flow control enabled on the tag_8021q CPU port - We put the DSA master interface in promiscuous mode, so it will never drop a PTP frame (for the profiles we are interested in, these are sent to the multicast MAC addresses of 01-80-c2-00-00-0e and 01-1b-19-00-00-00). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mscc: ocelot: refactor ocelot_xtr_irq_handler into ocelot_xtr_pollVladimir Oltean
Since the felix DSA driver will need to poll the CPU port module for extracted frames as well, let's create some common functions that read an Extraction Frame Header, and then an skb, from a CPU extraction group. We abuse the struct ocelot_ops :: port_to_netdev function a little bit, in order to retrieve the DSA port net_device or the ocelot switchdev net_device based on the source port information from the Extraction Frame Header, but it's all in the benefit of code simplification - netdev_alloc_skb needs it. Originally, the port_to_netdev method was intended for parsing act->dev from tc flower offload code. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: dsa: tag_ocelot: create separate tagger for SevilleVladimir Oltean
The ocelot tagger is a hot mess currently, it relies on memory initialized by the attached driver for basic frame transmission. This is against all that DSA tagging protocols stand for, which is that the transmission and reception of a DSA-tagged frame, the data path, should be independent from the switch control path, because the tag protocol is in principle hot-pluggable and reusable across switches (even if in practice it wasn't until very recently). But if another driver like dsa_loop wants to make use of tag_ocelot, it couldn't. This was done to have common code between Felix and Ocelot, which have one bit difference in the frame header format. Quoting from commit 67c2404922c2 ("net: dsa: felix: create a template for the DSA tags on xmit"): Other alternatives have been analyzed, such as: - Create a separate tag_seville.c: too much code duplication for just 1 bit field difference. - Create a separate DSA_TAG_PROTO_SEVILLE under tag_ocelot.c, just like tag_brcm.c, which would have a separate .xmit function. Again, too much code duplication for just 1 bit field difference. - Allocate the template from the init function of the tag_ocelot.c module, instead of from the driver: couldn't figure out a method of accessing the correct port template corresponding to the correct tagger in the .xmit function. The really interesting part is that Seville should have had its own tagging protocol defined - it is not compatible on the wire with Ocelot, even for that single bit. In principle, a packet generated by DSA_TAG_PROTO_OCELOT when booted on NXP LS1028A would look in a certain way, but when booted on NXP T1040 it would look differently. The reverse is also true: a packet generated by a Seville switch would be interpreted incorrectly by Wireshark if it was told it was generated by an Ocelot switch. Actually things are a bit more nuanced. If we concentrate only on the DSA tag, what I said above is true, but Ocelot/Seville also support an optional DSA tag prefix, which can be short or long, and it is possible to distinguish the two taggers based on an integer constant put in that prefix. Nonetheless, creating a separate tagger is still justified, since the tag prefix is optional, and without it, there is again no way to distinguish. Claiming backwards binary compatibility is a bit more tough, since I've already changed the format of tag_ocelot once, in commit 5124197ce58b ("net: dsa: tag_ocelot: use a short prefix on both ingress and egress"). Therefore I am not very concerned with treating this as a bugfix and backporting it to stable kernels (which would be another mess due to the fact that there would be lots of conflicts with the other DSA_TAG_PROTO* definitions). It's just simpler to say that the string values of the taggers have ABI value starting with kernel 5.12, which will be when the changing of tag protocol via /sys/class/net/<dsa-master>/dsa/tagging goes live. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mscc: ocelot: use common tag parsing code with DSAVladimir Oltean
The Injection Frame Header and Extraction Frame Header that the switch prepends to frames over the NPI port is also prepended to frames delivered over the CPU port module's queues. Let's unify the handling of the frame headers by making the ocelot driver call some helpers exported by the DSA tagger. Among other things, this allows us to get rid of the strange cpu_to_be32 when transmitting the Injection Frame Header on ocelot, since the packing API uses network byte order natively (when "quirks" is 0). The comments above ocelot_gen_ifh talk about setting pop_cnt to 3, and the cpu extraction queue mask to something, but the code doesn't do it, so we don't do it either. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mscc: ocelot: refactor ocelot_port_inject_frame out of ocelot_port_xmitVladimir Oltean
The felix DSA driver will inject some frames through register MMIO, same as ocelot switchdev currently does. So we need to be able to reuse the common code. Also create some shim definitions, since the DSA tagger can be compiled without support for the switch driver. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mscc: ocelot: use DIV_ROUND_UP helper in ocelot_port_inject_frameVladimir Oltean
This looks a bit nicer than the open-coded "(x + 3) % 4" idiom. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mscc: ocelot: better error handling in ocelot_xtr_irq_handlerVladimir Oltean
The ocelot_rx_frame_word() function can return a negative error code, however this isn't being checked for consistently. Errors being ignored have not been seen in practice though. Also, some constructs can be simplified by using "goto" instead of repeated "break" statements. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mscc: ocelot: only drain extraction queue on errorVladimir Oltean
It appears that the intention of this snippet of code is to not exit ocelot_xtr_irq_handler() while in the middle of extracting a frame. The problem in extracting it word by word is that future extraction attempts are really easy to get desynchronized, since the IRQ handler assumes that the first 16 bytes are the IFH, which give further information about the frame, such as frame length. But during normal operation, "err" will not be 0, but 4, set from here: for (i = 0; i < OCELOT_TAG_LEN / 4; i++) { err = ocelot_rx_frame_word(ocelot, grp, true, &ifh[i]); if (err != 4) break; } if (err != 4) break; In that case, draining the extraction queue is a no-op. So explicitly make this code execute only on negative err. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14net: mscc: ocelot: stop returning IRQ_NONE in ocelot_xtr_irq_handlerVladimir Oltean
Since the xtr (extraction) IRQ of the ocelot switch is not shared, then if it fired, it means that some data must be present in the queues of the CPU port module. So simplify the code. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14bnxt_en: Improve logging of error recovery settings information.Michael Chan
We currently only log the error recovery settings if it is enabled. In some cases, firmware disables error recovery after it was initially enabled. Without logging anything, the user will not be aware of this change in setting. Log it when error recovery is disabled. Also, change the reset count value from hexadecimal to decimal. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14bnxt_en: Reply to firmware's echo request async message.Michael Chan
This is a new async message that the firmware can send to check if it can communicate with the driver. This is an added error detection scheme that firmware can use if it suspects errors in the PCIe interface. When the driver receives this async message, it will reply back echoing some data in the async message. If the firmware is not getting the reply with the proper data after some retries, error recovery will kick in. Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14bnxt_en: Initialize "context kind" field for context memory blocks.Michael Chan
If firmware provides the offset to the "context kind" field of the relevant context memory blocks, we'll initialize just that field for each block instead of initializing all of context memory. Populate the bnxt_mem_init structure with the proper offset returned by firmware. If it is older firmware and the information is not available, we set the offset to an invalid value and fall back to the old behavior of initializing every byte. Otherwise, we initialize only the "context kind" byte at the offset. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14bnxt_en: Add context memory initialization infrastructure.Michael Chan
Currently, the driver calls memset() to set all relevant context memory used by the chip to the initial value. This can take many milliseconds with the potentially large number of context pages allocated for the chip. To make this faster, we only need to initialize the "context kind" field of each block of context memory. This patch sets up the infrastructure to do that with the bnxt_mem_init structure. In the next patch, we'll add the logic to obtain the offset of the "context kind" from the firmware. This patch is not changing the current behavior of calling memset() to initialize all relevant context memory. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14bnxt_en: Implement faster recovery for firmware fatal error.Michael Chan
During some fatal firmware error conditions, the PCI config space register 0x2e which normally contains the subsystem ID will become 0xffff. This register will revert back to the normal value after the chip has completed core reset. If we detect this condition, we can poll this config register immediately for the value to revert. Because we use config read cycles to poll this register, there is no possibility of Master Abort if we happen to read it during core reset. This speeds up recovery significantly as we don't have to wait for the conservative min_time before polling MMIO to see if the firmware has come out of reset. As soon as this register changes value we can proceed to re-initialize the device. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14bnxt_en: selectively allocate context memoriesEdwin Peer
Newer devices may have local context memory instead of relying on the host for backing store. In these cases, HWRM_FUNC_BACKING_STORE_QCAPS will return a zero entry size to indicate contexts for which the host should not allocate backing store. Selectively allocate context memory based on device capabilities and only enable backing store for the appropriate contexts. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14bnxt_en: Update firmware interface spec to 1.10.2.16.Michael Chan
The main changes are the echo request/response from firmware for error detection and the NO_FCS feature to transmit frames without FCS. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-14Merge branch 'for-rc8-5.11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED fix from Pavel Machek: "One-liner fixing a build problem" * 'for-rc8-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: rt8515: add V4L2_FLASH_LED_CLASS dependency
2021-02-14leds: rt8515: add V4L2_FLASH_LED_CLASS dependencyArnd Bergmann
The leds-rt8515 driver can optionall use the v4l2 flash led class, but it causes a link error when that class is in a loadable module and the rt8515 driver itself is built-in: ld.lld: error: undefined symbol: v4l2_flash_init >>> referenced by leds-rt8515.c >>> leds/flash/leds-rt8515.o:(rt8515_probe) in archive drivers/built-in.a Adding 'depends on V4L2_FLASH_LED_CLASS' in Kconfig would avoid that, but it would make it impossible to use the driver without the v4l2 support. Add the same dependency that the other users of this class have instead, which just prevents the broken configuration. Fixes: e1c6edcbea13 ("leds: rt8515: Add Richtek RT8515 LED driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-02-14irqchip/imx: IMX_INTMUX should not default to y, unconditionallyGeert Uytterhoeven
Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of IMX_INTMUX to ARCH_MXC, and ask the user in case of compile-testing. Fixes: 66968d7dfc3f5451 ("irqchip: Add COMPILE_TEST support for IMX_INTMUX") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210208145605.422943-1-geert+renesas@glider.be
2021-02-13Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fix from Stephen Boyd: "One small fix for the Allwinner clk driver so that display clks figure out the correct rate to use. This fixes displays running 4k@60Hz and some other resolutions that haven't been exercised and fully understood until now" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: sunxi-ng: mp: fix parent rate change flag check
2021-02-13Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fix from James Bottomley: "One fix for scsi_debug that fixes a memory leak on module removal" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: scsi_debug: Fix a memory leak
2021-02-13staging: hikey9xx: Fix alignment of function parametersMukul Mehar
This patch fixes the following checkpatch.pl check: CHECK: Alignment should match open parenthesis Signed-off-by: Mukul Mehar <mukulmehar02@gmail.com> Link: https://lore.kernel.org/r/20210213120556.73579-1-mukulmehar02@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13staging: greybus: Fixed a misspelling in hid.cPritthijit Nath
Fixed the spelling of 'transfered' to 'transferred'. Signed-off-by: Pritthijit Nath <pritthijit.nath@icloud.com> Link: https://lore.kernel.org/r/20210212101324.12391-1-pritthijit.nath@icloud.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13staging: wimax/i2400m: fix some byte order issues found by sparseAnirudh Rayabharam
Fix sparse byte-order warnings in the i2400m_bm_cmd_prepare() function: wimax/i2400m/fw.c:194:36: warning: restricted __le32 degrades to integer wimax/i2400m/fw.c:195:34: warning: invalid assignment: += wimax/i2400m/fw.c:195:34: left side has type unsigned int wimax/i2400m/fw.c:195:34: right side has type restricted __le32 wimax/i2400m/fw.c:196:32: warning: restricted __le32 degrades to integer wimax/i2400m/fw.c:196:47: warning: restricted __le32 degrades to integer wimax/i2400m/fw.c:196:66: warning: restricted __le32 degrades to integer Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Link: https://lore.kernel.org/r/20210212153843.8554-1-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13staging: wimax: i2400m: fix some incorrect type warningsAyush
Fix some "incorrect type in assignment" warnings reported by sparse in tx.c sparse warnings: wimax/i2400m/tx.c:788:35: warning: cast to restricted __le16 wimax/i2400m/tx.c:788:33: warning: incorrect type in assignment (different base types) wimax/i2400m/tx.c:788:33: expected restricted __le16 [usertype] num_pls wimax/i2400m/tx.c:788:33: got unsigned short [usertype] wimax/i2400m/tx.c:896:32: warning: cast to restricted __le32 wimax/i2400m/tx.c:896:30: warning: incorrect type in assignment (different base types) wimax/i2400m/tx.c:896:30: expected restricted __le32 [usertype] barker wimax/i2400m/tx.c:896:30: got unsigned int [usertype] wimax/i2400m/tx.c:897:34: warning: cast to restricted __le32 wimax/i2400m/tx.c:897:32: warning: incorrect type in assignment (different base types) wimax/i2400m/tx.c:897:32: expected restricted __le32 [usertype] sequence wimax/i2400m/tx.c:897:32: got unsigned int [usertype] wimax/i2400m/tx.c:899:15: warning: cast to restricted __le32 wimax/i2400m/tx.c:899:15: warning: cast from restricted __le16 Signed-off-by: Ayush <ayush@disroot.org> Link: https://lore.kernel.org/r/20210212213628.801642-1-ayush@disroot.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13staging: greybus: minor code style fixManikantan Ravichandran
checkpatch warning fix for string split across lines Signed-off-by: Manikantan Ravichandran <ravman1991@gmail.com> Link: https://lore.kernel.org/r/20210212225035.GA16260@whach Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13staging:wlan-ng: use memdup_user instead of kmalloc/copy_from_userIvan Safonov
memdup_user() is shorter and safer equivalent of kmalloc/copy_from_user pair. Signed-off-by: Ivan Safonov <insafonov@gmail.com> Link: https://lore.kernel.org/r/20210213120527.451531-1-insafonov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13staging:r8188eu: use IEEE80211_FCTL_* kernel definitionsIvan Safonov
_TO_DS_, _FROM_DS_, _MORE_FRAG_, _RETRY_, _PWRMGT_, _MORE_DATA_, _PRIVACY_, _ORDER_ definitions are duplicate IEEE80211_FCTL_* kernel definitions. Signed-off-by: Ivan Safonov <insafonov@gmail.com> Link: https://lore.kernel.org/r/20210213131148.458582-1-insafonov@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13staging: rtl8192e: remove multiple blank linesWilliam Durand
This patch removes some blank lines in order to fix a checkpatch issue. Signed-off-by: William Durand <will+git@drnd.me> Link: https://lore.kernel.org/r/20210213034711.14823-1-will+git@drnd.me Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13Merge branch 'i2c/for-current' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fix from Wolfram Sang: "One more I2C driver bugfix" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: stm32f7: fix configuration of the digital filter
2021-02-12net: axienet: Support dynamic switching between 1000BaseX and SGMIIRobert Hancock
Newer versions of the Xilinx AXI Ethernet core (specifically version 7.2 or later) allow the core to be configured with a PHY interface mode of "Both", allowing either 1000BaseX or SGMII modes to be selected at runtime. Add support for this in the driver to allow better support for applications which can use both fiber and copper SFP modules. Signed-off-by: Robert Hancock <robert.hancock@calian.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12net: axienet: hook up nway_reset ethtool operationRobert Hancock
Hook up the nway_reset ethtool operation to the corresponding phylink function so that "ethtool -r" can be supported. Signed-off-by: Robert Hancock <robert.hancock@calian.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12net: axienet: Handle deferred probe on clock properlyRobert Hancock
This driver is set up to use a clock mapping in the device tree if it is present, but still work without one for backward compatibility. However, if getting the clock returns -EPROBE_DEFER, then we need to abort and return that error from our driver initialization so that the probe can be retried later after the clock is set up. Move clock initialization to earlier in the process so we do not waste as much effort if the clock is not yet available. Switch to use devm_clk_get_optional and abort initialization on any error reported. Also enable the clock regardless of whether the controller is using an MDIO bus, as the clock is required in any case. Fixes: 09a0354cadec267be7f ("net: axienet: Use clock framework to get device clock rate") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12Merge branch '40GbE' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== 40GbE Intel Wired LAN Driver Updates 2021-02-12 This series contains updates to i40e, ice, and ixgbe drivers. Maciej does cleanups on the following drivers. For i40e, removes redundant check for XDP prog, cleans up no longer relevant information, and removes an unused function argument. For ice, removes local variable use, instead returning values directly. Moves skb pointer from buffer to ring and removes an unneeded check for xdp_prog in zero copy path. Also removes a redundant MTU check when changing it. For i40e, ice, and ixgbe, stores the rx_offset in the Rx ring as the value is constant so there's no need for continual calls. Bjorn folds a decrement into a while statement. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12ibmvnic: change IBMVNIC_MAX_IND_DESCS to 16Dany Madden
The supported indirect subcrq entries on Power8 is 16. Power9 supports 128. Redefined this value to 16 to minimize the driver from having to reset when migrating between Power9 and Power8. In our rx/tx performance testing, we found no performance difference between 16 and 128 at this time. Fixes: f019fb6392e5 ("ibmvnic: Introduce indirect subordinate Command Response Queue buffer") Signed-off-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-02-12net: dsa: sja1105: offload bridge port flags to deviceVladimir Oltean
The chip can configure unicast flooding, broadcast flooding and learning. Learning is per port, while flooding is per {ingress, egress} port pair and we need to configure the same value for all possible ingress ports towards the requested one. While multicast flooding is not officially supported, we can hack it by using a feature of the second generation (P/Q/R/S) devices, which is that FDB entries are maskable, and multicast addresses always have an odd first octet. So by putting a match-all for 00:01:00:00:00:00 addr and 00:01:00:00:00:00 mask at the end of the FDB, we make sure that it is always checked last, and does not take precedence in front of any other MDB. So it behaves effectively as an unknown multicast entry. For the first generation switches, this feature is not available, so unknown multicast will always be treated the same as unknown unicast. So the only thing we can do is request the user to offload the settings for these 2 flags in tandem, i.e. ip link set swp2 type bridge_slave flood off Error: sja1105: This chip cannot configure multicast flooding independently of unicast. ip link set swp2 type bridge_slave flood off mcast_flood off ip link set swp2 type bridge_slave mcast_flood on Error: sja1105: This chip cannot configure multicast flooding independently of unicast. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>