summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* net: Update address for MediaTek ethernet driver in MAINTAINERSSean Wang2019-10-171-1/+1
| | | | | | | | | | Update maintainers for MediaTek ethernet driver with Mark Lee. He is familiar with MediaTek mt762x series ethernet devices and will keep following maintenance from the vendor side. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Mark Lee <Mark-MC.Lee@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv4: fix race condition between route lookup and invalidationWei Wang2019-10-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jesse and Ido reported the following race condition: <CPU A, t0> - Received packet A is forwarded and cached dst entry is taken from the nexthop ('nhc->nhc_rth_input'). Calls skb_dst_set() <t1> - Given Jesse has busy routers ("ingesting full BGP routing tables from multiple ISPs"), route is added / deleted and rt_cache_flush() is called <CPU B, t2> - Received packet B tries to use the same cached dst entry from t0, but rt_cache_valid() is no longer true and it is replaced in rt_cache_route() by the newer one. This calls dst_dev_put() on the original dst entry which assigns the blackhole netdev to 'dst->dev' <CPU A, t3> - dst_input(skb) is called on packet A and it is dropped due to 'dst->dev' being the blackhole netdev There are 2 issues in the v4 routing code: 1. A per-netns counter is used to do the validation of the route. That means whenever a route is changed in the netns, users of all routes in the netns needs to redo lookup. v6 has an implementation of only updating fn_sernum for routes that are affected. 2. When rt_cache_valid() returns false, rt_cache_route() is called to throw away the current cache, and create a new one. This seems unnecessary because as long as this route does not change, the route cache does not need to be recreated. To fully solve the above 2 issues, it probably needs quite some code changes and requires careful testing, and does not suite for net branch. So this patch only tries to add the deleted cached rt into the uncached list, so user could still be able to use it to receive packets until it's done. Fixes: 95c47f9cf5e0 ("ipv4: call dst_dev_put() properly") Signed-off-by: Wei Wang <weiwan@google.com> Reported-by: Ido Schimmel <idosch@idosch.org> Reported-by: Jesse Hathaway <jesse@mbuki-mvuki.org> Tested-by: Jesse Hathaway <jesse@mbuki-mvuki.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Cc: David Ahern <dsahern@gmail.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* ipv4: Return -ENETUNREACH if we can't create route but saddr is validStefano Brivio2019-10-171-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...instead of -EINVAL. An issue was found with older kernel versions while unplugging a NFS client with pending RPCs, and the wrong error code here prevented it from recovering once link is back up with a configured address. Incidentally, this is not an issue anymore since commit 4f8943f80883 ("SUNRPC: Replace direct task wakeups from softirq context"), included in 5.2-rc7, had the effect of decoupling the forwarding of this error by using SO_ERROR in xs_wake_error(), as pointed out by Benjamin Coddington. To the best of my knowledge, this isn't currently causing any further issue, but the error code doesn't look appropriate anyway, and we might hit this in other paths as well. In detail, as analysed by Gonzalo Siero, once the route is deleted because the interface is down, and can't be resolved and we return -EINVAL here, this ends up, courtesy of inet_sk_rebuild_header(), as the socket error seen by tcp_write_err(), called by tcp_retransmit_timer(). In turn, tcp_write_err() indirectly calls xs_error_report(), which wakes up the RPC pending tasks with a status of -EINVAL. This is then seen by call_status() in the SUN RPC implementation, which aborts the RPC call calling rpc_exit(), instead of handling this as a potentially temporary condition, i.e. as a timeout. Return -EINVAL only if the input parameters passed to ip_route_output_key_hash_rcu() are actually invalid (this is the case if the specified source address is multicast, limited broadcast or all zeroes), but return -ENETUNREACH in all cases where, at the given moment, the given source address doesn't allow resolving the route. While at it, drop the initialisation of err to -ENETUNREACH, which was added to __ip_route_output_key() back then by commit 0315e3827048 ("net: Fix behaviour of unreachable, blackhole and prohibit routes"), but actually had no effect, as it was, and is, overwritten by the fib_lookup() return code assignment, and anyway ignored in all other branches, including the if (fl4->saddr) one: I find this rather confusing, as it would look like -ENETUNREACH is the "default" error, while that statement has no effect. Also note that after commit fc75fc8339e7 ("ipv4: dont create routes on down devices"), we would get -ENETUNREACH if the device is down, but -EINVAL if the source address is specified and we can't resolve the route, and this appears to be rather inconsistent. Reported-by: Stefan Walter <walteste@inf.ethz.ch> Analysed-by: Benjamin Coddington <bcodding@redhat.com> Analysed-by: Gonzalo Siero <gsierohu@redhat.com> Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: micrel: Update KSZ87xx PHY nameMarek Vasut2019-10-172-3/+3
| | | | | | | | | | | | | | | | | The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches. Update the PHY ID and name to reflect that, as this family of switches is commonly refered to as KSZ87xx Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: micrel: Discern KSZ8051 and KSZ8795 PHYsMarek Vasut2019-10-171-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs in the micrel PHY driver, it is used even with the KSZ87xx switch. This is wrong, since the KSZ8051 configures registers of the PHY which are not present on the simplified KSZ87xx switch PHYs and misconfigures other registers of the KSZ87xx switch PHYs. Fortunatelly, it is possible to tell apart the KSZ8051 PHY from the KSZ87xx switch by checking the Basic Status register Bit 0, which is read-only and indicates presence of the Extended Capability Registers. The KSZ8051 PHY has those registers while the KSZ87xx switch does not. This patch implements simple check for the presence of this bit for both the KSZ8051 PHY and KSZ87xx switch, to let both use the correct PHY driver instance. Fixes: 9d162ed69f51 ("net: phy: micrel: add support for KSZ8795") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: microchip: Add shared regmap mutexMarek Vasut2019-10-175-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | The KSZ driver uses one regmap per register width (8/16/32), each with it's own lock, but accessing the same set of registers. In theory, it is possible to create a race condition between these regmaps, although the underlying bus (SPI or I2C) locking should assure nothing bad will really happen and the accesses would be correct. To make the driver do the right thing, add one single shared mutex for all the regmaps used by the driver instead. This assures that even if some future hardware is on a bus which does not serialize the accesses the same way SPI or I2C does, nothing bad will happen. Note that the status_mutex was unused and only initied, hence it was renamed and repurposed as the regmap mutex. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: microchip: Do not reinit mutexes on KSZ87xxMarek Vasut2019-10-171-4/+0
| | | | | | | | | | | | | | | | The KSZ87xx driver calls mutex_init() on mutexes already inited in ksz_common.c ksz_switch_register(). Do not do it twice, drop the reinitialization. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andrew Lunn <andrew@lunn.ch> Cc: David S. Miller <davem@davemloft.net> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Tristram Ha <Tristram.Ha@microchip.com> Cc: Woojung Huh <woojung.huh@microchip.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: stmmac: fix argument to stmmac_pcs_ctrl_ane()Ben Dooks (Codethink)2019-10-171-1/+1
| | | | | | | | | | | | | | | The stmmac_pcs_ctrl_ane() expects a register address as argument 1, but for some reason the mac_device_info is being passed. Fix the warning (and possible bug) from sparse: drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces) drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: expected void [noderef] <asn:2> *ioaddr drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: got struct mac_device_info *hw Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'dpaa2-eth-misc-fixes'David S. Miller2019-10-172-2/+53
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ioana Ciornei says: ==================== dpaa2-eth: misc fixes This patch set adds a couple of fixes around updating configuration on MAC change. Depending on when MC connects the DPNI to a MAC, both the MAC address and TX FQIDs should be updated everytime there is a change in configuration. Changes in v2: - used reverse christmas tree ordering in patch 2/2 Changes in v3: - add a missing new line - go back to FQ based enqueueing after a transient error ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * dpaa2-eth: Fix TX FQID valuesIoana Radulescu2019-10-171-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on when MC connects the DPNI to a MAC, Tx FQIDs may not be available during probe time. Read the FQIDs each time the link goes up to avoid using invalid values. In case an error occurs or an invalid value is retrieved, fall back to QDID-based enqueueing. Fixes: 1fa0f68c9255 ("dpaa2-eth: Use FQ-based DPIO enqueue API") Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * dpaa2-eth: add irq for the dpmac connect/disconnect eventFlorin Chiculita2019-10-172-2/+9
|/ | | | | | | | | | Add IRQ for the DPNI endpoint change event, resolving the issue when a dynamically created DPNI gets a randomly generated hw address when the endpoint is a DPMAC object. Signed-off-by: Florin Chiculita <florinlaurentiu.chiculita@nxp.com> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* usb: hso: obey DMA rules in tiocmgetOliver Neukum2019-10-171-4/+9
| | | | | | | | | | | | | The serial state information must not be embedded into another data structure, as this interferes with cache handling for DMA on architectures without cache coherence.. That would result in data corruption on some architectures Allocating it separately. v2: fix syntax error Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: stmmac: disable/enable ptp_ref_clk in suspend/resume flowBiao Huang2019-10-161-4/+8
| | | | | | | | disable ptp_ref_clk in suspend flow, and enable it in resume flow. Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure") Signed-off-by: Biao Huang <biao.huang@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: phy: Fix "link partner" information disappear issueYonglong Liu2019-10-163-4/+12
| | | | | | | | | | | | | | | | | | | | | | Some drivers just call phy_ethtool_ksettings_set() to set the links, for those phy drivers that use genphy_read_status(), if autoneg is on, and the link is up, than execute "ethtool -s ethx autoneg on" will cause "link partner" information disappear. The call trace is phy_ethtool_ksettings_set()->phy_start_aneg() ->linkmode_zero(phydev->lp_advertising)->genphy_read_status(), the link didn't change, so genphy_read_status() just return, and phydev->lp_advertising is zero now. This patch moves the clear operation of lp_advertising from phy_start_aneg() to genphy_read_lpa()/genphy_c45_read_lpa(), and if autoneg on and autoneg not complete, just clear what the generic functions care about. Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status") Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* rxrpc: use rcu protection while reading sk->sk_user_dataEric Dumazet2019-10-161-4/+8
| | | | | | | | | | | | | | | We need to extend the rcu_read_lock() section in rxrpc_error_report() and use rcu_dereference_sk_user_data() instead of plain access to sk->sk_user_data to make sure all rules are respected. The compiler wont reload sk->sk_user_data at will, and RCU rules prevent memory beeing freed too soon. Fixes: f0308fb07080 ("rxrpc: Fix possible NULL pointer access in ICMP handling") Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Revert "blackhole_netdev: fix syzkaller reported issue"Mahesh Bandewar2019-10-162-12/+10
| | | | | | | | | | | | | | | | | | This reverts commit b0818f80c8c1bc215bba276bd61c216014fab23b. Started seeing weird behavior after this patch especially in the IPv6 code path. Haven't root caused it, but since this was applied to net branch, taking a precautionary measure to revert it and look / analyze those failures Revert this now and I'll send a better fix after analysing / fixing the weirdness observed. CC: Eric Dumazet <edumazet@google.com> CC: Wei Wang <weiwan@google.com> CC: David S. Miller <davem@davemloft.net> Signed-off-by: Mahesh Bandewar <maheshb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: usb: sr9800: fix uninitialized local variableValentin Vidic2019-10-151-1/+1
| | | | | | | | | Make sure res does not contain random value if the call to sr_read_cmd fails for some reason. Reported-by: syzbot+f1842130bbcfb335bac1@syzkaller.appspotmail.com Signed-off-by: Valentin Vidic <vvidic@valentin-vidic.from.hr> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: bcmgenet: Fix RGMII_MODE_EN value for GENET v1/2/3Florian Fainelli2019-10-152-1/+6
| | | | | | | | | | The RGMII_MODE_EN bit value was 0 for GENET versions 1 through 3, and became 6 for GENET v4 and above, account for that difference. Fixes: aa09677cba42 ("net: bcmgenet: add MDIO routines") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Doug Berger <opendmb@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: stmmac: make tc_flow_parsers staticBen Dooks (Codethink)2019-10-151-1/+1
| | | | | | | | | | The tc_flow_parsers is not used outside of the driver, so make it static to avoid the following sparse warning: drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c:516:3: warning: symbol 'tc_flow_parsers' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
* davinci_cpdma: make cpdma_chan_split_pool staticBen Dooks (Codethink)2019-10-151-1/+1
| | | | | | | | | | | The cpdma_chan_split_pool() function is not used outside of the driver, so make it static to avoid the following sparse warning: drivers/net/ethernet/ti/davinci_cpdma.c:725:5: warning: symbol 'cpdma_chan_split_pool' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: i82596: fix dma_alloc_attr for sni_82596Thomas Bogendoerfer2019-10-153-4/+8
| | | | | | | | | | | | Commit 7f683b920479 ("i825xx: switch to switch to dma_alloc_attrs") switched dma allocation over to dma_alloc_attr, but didn't convert the SNI part to request consistent DMA memory. This broke sni_82596 since driver doesn't do dma_cache_sync for performance reasons. Fix this by using different DMA_ATTRs for lasi_82596 and sni_82596. Fixes: 7f683b920479 ("i825xx: switch to switch to dma_alloc_attrs") Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
* sctp: change sctp_prot .no_autobind with trueXin Long2019-10-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | syzbot reported a memory leak: BUG: memory leak, unreferenced object 0xffff888120b3d380 (size 64): backtrace: [...] slab_alloc mm/slab.c:3319 [inline] [...] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483 [...] sctp_bucket_create net/sctp/socket.c:8523 [inline] [...] sctp_get_port_local+0x189/0x5a0 net/sctp/socket.c:8270 [...] sctp_do_bind+0xcc/0x200 net/sctp/socket.c:402 [...] sctp_bindx_add+0x4b/0xd0 net/sctp/socket.c:497 [...] sctp_setsockopt_bindx+0x156/0x1b0 net/sctp/socket.c:1022 [...] sctp_setsockopt net/sctp/socket.c:4641 [inline] [...] sctp_setsockopt+0xaea/0x2dc0 net/sctp/socket.c:4611 [...] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3147 [...] __sys_setsockopt+0x10f/0x220 net/socket.c:2084 [...] __do_sys_setsockopt net/socket.c:2100 [inline] It was caused by when sending msgs without binding a port, in the path: inet_sendmsg() -> inet_send_prepare() -> inet_autobind() -> .get_port/sctp_get_port(), sp->bind_hash will be set while bp->port is not. Later when binding another port by sctp_setsockopt_bindx(), a new bucket will be created as bp->port is not set. sctp's autobind is supposed to call sctp_autobind() where it does all things including setting bp->port. Since sctp_autobind() is called in sctp_sendmsg() if the sk is not yet bound, it should have skipped the auto bind. THis patch is to avoid calling inet_autobind() in inet_send_prepare() by changing sctp_prot .no_autobind with true, also remove the unused .get_port. Reported-by: syzbot+d44f7bbebdea49dbc84a@syzkaller.appspotmail.com Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* sched: etf: Fix ordering of packets with same txtimeVinicius Costa Gomes2019-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | When a application sends many packets with the same txtime, they may be transmitted out of order (different from the order in which they were enqueued). This happens because when inserting elements into the tree, when the txtime of two packets are the same, the new packet is inserted at the left side of the tree, causing the reordering. The only effect of this change should be that packets with the same txtime will be transmitted in the order they are enqueued. The application in question (the AVTP GStreamer plugin, still in development) is sending video traffic, in which each video frame have a single presentation time, the problem is that when packetizing, multiple packets end up with the same txtime. The receiving side was rejecting packets because they were being received out of order. Fixes: 25db26a91364 ("net/sched: Introduce the ETF Qdisc") Reported-by: Ederson de Souza <ederson.desouza@intel.com> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: avoid potential infinite loop in tc_ctl_action()Eric Dumazet2019-10-151-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tc_ctl_action() has the ability to loop forever if tcf_action_add() returns -EAGAIN. This special case has been done in case a module needed to be loaded, but it turns out that tcf_add_notify() could also return -EAGAIN if the socket sk_rcvbuf limit is hit. We need to separate the two cases, and only loop for the module loading case. While we are at it, add a limit of 10 attempts since unbounded loops are always scary. syzbot repro was something like : socket(PF_NETLINK, SOCK_RAW|SOCK_NONBLOCK, NETLINK_ROUTE) = 3 write(3, ..., 38) = 38 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [0], 4) = 0 sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{..., 388}], msg_controllen=0, msg_flags=0x10}, ...) NMI backtrace for cpu 0 CPU: 0 PID: 1054 Comm: khungtaskd Not tainted 5.4.0-rc1+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 nmi_cpu_backtrace.cold+0x70/0xb2 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x23b/0x28b lib/nmi_backtrace.c:62 arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38 trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline] check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline] watchdog+0x9d0/0xef0 kernel/hung_task.c:289 kthread+0x361/0x430 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 8859 Comm: syz-executor910 Not tainted 5.4.0-rc1+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:arch_local_save_flags arch/x86/include/asm/paravirt.h:751 [inline] RIP: 0010:lockdep_hardirqs_off+0x1df/0x2e0 kernel/locking/lockdep.c:3453 Code: 5c 08 00 00 5b 41 5c 41 5d 5d c3 48 c7 c0 58 1d f3 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 0f 85 d3 00 00 00 <48> 83 3d 21 9e 99 07 00 0f 84 b9 00 00 00 9c 58 0f 1f 44 00 00 f6 RSP: 0018:ffff8880a6f3f1b8 EFLAGS: 00000046 RAX: 1ffffffff11e63ab RBX: ffff88808c9c6080 RCX: 0000000000000000 RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff88808c9c6914 RBP: ffff8880a6f3f1d0 R08: ffff88808c9c6080 R09: fffffbfff16be5d1 R10: fffffbfff16be5d0 R11: 0000000000000003 R12: ffffffff8746591f R13: ffff88808c9c6080 R14: ffffffff8746591f R15: 0000000000000003 FS: 00000000011e4880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff600400 CR3: 00000000a8920000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: trace_hardirqs_off+0x62/0x240 kernel/trace/trace_preemptirq.c:45 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] _raw_spin_lock_irqsave+0x6f/0xcd kernel/locking/spinlock.c:159 __wake_up_common_lock+0xc8/0x150 kernel/sched/wait.c:122 __wake_up+0xe/0x10 kernel/sched/wait.c:142 netlink_unlock_table net/netlink/af_netlink.c:466 [inline] netlink_unlock_table net/netlink/af_netlink.c:463 [inline] netlink_broadcast_filtered+0x705/0xb80 net/netlink/af_netlink.c:1514 netlink_broadcast+0x3a/0x50 net/netlink/af_netlink.c:1534 rtnetlink_send+0xdd/0x110 net/core/rtnetlink.c:714 tcf_add_notify net/sched/act_api.c:1343 [inline] tcf_action_add+0x243/0x370 net/sched/act_api.c:1362 tc_ctl_action+0x3b5/0x4bc net/sched/act_api.c:1410 rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5386 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5404 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:657 ___sys_sendmsg+0x803/0x920 net/socket.c:2311 __sys_sendmsg+0x105/0x1d0 net/socket.c:2356 __do_sys_sendmsg net/socket.c:2365 [inline] __se_sys_sendmsg net/socket.c:2363 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363 do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440939 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot+cf0adbb9c28c8866c788@syzkaller.appspotmail.com Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: sja1105: Use the correct style for SPDX License IdentifierNishad Kamdar2019-10-155-10/+10
| | | | | | | | | | | | | | | | This patch corrects the SPDX License Identifier style in header files related to Distributed Switch Architecture drivers for NXP SJA1105 series Ethernet switch support. It uses an expilict block comment for the SPDX License Identifier. Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* tcp: fix a possible lockdep splat in tcp_done()Eric Dumazet2019-10-151-2/+6
| | | | | | | | | | | | | | syzbot found that if __inet_inherit_port() returns an error, we call tcp_done() after inet_csk_prepare_forced_close(), meaning the socket lock is no longer held. We might fix this in a different way in net-next, but for 5.4 it seems safer to relax the lockdep check. Fixes: d983ea6f16b8 ("tcp: add rcu protection around tp->fastopen_rsk") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'Update-MT7629-to-support-PHYLINK-API'David S. Miller2019-10-153-3/+13
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MarkLee says: ==================== Update MT7629 to support PHYLINK API This patch set has two goals : 1. Fix mt7629 GMII mode issue after apply mediatek PHYLINK support patch. 2. Update mt7629 dts to reflect the latest dt-binding with PHYLINK support. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * arm: dts: mediatek: Update mt7629 dts to reflect the latest dt-bindingMarkLee2019-10-152-3/+12
| | | | | | | | | | | | | | | | | | * Removes mediatek,physpeed property from dtsi that is useless in PHYLINK * Use the fixed-link property speed = <2500> to set the phy in 2.5Gbit. * Set gmac1 to gmii mode that connect to a internal gphy Signed-off-by: MarkLee <Mark-MC.Lee@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: ethernet: mediatek: Fix MT7629 missing GMII mode supportMarkLee2019-10-151-0/+1
|/ | | | | | | | | | | | | | In the original design, mtk_phy_connect function will set ge_mode=1 if phy-mode is GMII(PHY_INTERFACE_MODE_GMII) and then set the correct ge_mode to ETHSYS_SYSCFG0 register. This logic was broken after apply mediatek PHYLINK patch(Fixes tag), the new mtk_mac_config function will not set ge_mode=1 for GMII mode hence the final ETHSYS_SYSCFG0 setting will be incorrect for mt7629 GMII mode. This patch add the missing logic back to fix it. Fixes: b8fc9f30821e ("net: ethernet: mediatek: Add basic PHYLINK support") Signed-off-by: MarkLee <Mark-MC.Lee@mediatek.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'mpls-push-pop-fix'David S. Miller2019-10-154-17/+26
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Davide Caratti says: ==================== net/sched: fix wrong behavior of MPLS push/pop action this series contains two fixes for TC 'act_mpls', that try to address two problems that can be observed configuring simple 'push' / 'pop' operations: - patch 1/2 avoids dropping non-MPLS packets that pass through the MPLS 'pop' action. - patch 2/2 fixes corruption of the L2 header that occurs when 'push' or 'pop' actions are configured in TC egress path. v2: - change commit message in patch 1/2 to better describe that the patch impacts only TC, thanks to Simon Horman - fix missing documentation of 'mac_len' in patch 2/2 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * net/sched: fix corrupted L2 header with MPLS 'push' and 'pop' actionsDavide Caratti2019-10-154-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the following script: # tc qdisc add dev eth0 clsact # tc filter add dev eth0 egress protocol ip matchall \ > action mpls push protocol mpls_uc label 0x355aa bos 1 causes corruption of all IP packets transmitted by eth0. On TC egress, we can't rely on the value of skb->mac_len, because it's 0 and a MPLS 'push' operation will result in an overwrite of the first 4 octets in the packet L2 header (e.g. the Destination Address if eth0 is an Ethernet); the same error pattern is present also in the MPLS 'pop' operation. Fix this error in act_mpls data plane, computing 'mac_len' as the difference between the network header and the mac header (when not at TC ingress), and use it in MPLS 'push'/'pop' core functions. v2: unbreak 'make htmldocs' because of missing documentation of 'mac_len' in skb_mpls_pop(), reported by kbuild test robot CC: Lorenzo Bianconi <lorenzo@kernel.org> Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") Reviewed-by: Simon Horman <simon.horman@netronome.com> Acked-by: John Hurley <john.hurley@netronome.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
| * net: avoid errors when trying to pop MLPS header on non-MPLS packetsDavide Caratti2019-10-151-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | the following script: # tc qdisc add dev eth0 clsact # tc filter add dev eth0 egress matchall action mpls pop implicitly makes the kernel drop all packets transmitted by eth0, if they don't have a MPLS header. This behavior is uncommon: other encapsulations (like VLAN) just let the packet pass unmodified. Since the result of MPLS 'pop' operation would be the same regardless of the presence / absence of MPLS header(s) in the original packet, we can let skb_mpls_pop() return 0 when dealing with non-MPLS packets. For the OVS use-case, this is acceptable because __ovs_nla_copy_actions() already ensures that MPLS 'pop' operation only occurs with packets having an MPLS Ethernet type (and there are no other callers in current code, so the semantic change should be ok). v2: better documentation of use-cases for skb_mpls_pop(), thanks to Simon Horman Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") Reviewed-by: Simon Horman <simon.horman@netronome.com> Acked-by: John Hurley <john.hurley@netronome.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: cavium: Use the correct style for SPDX License IdentifierNishad Kamdar2019-10-151-1/+1
| | | | | | | | | | | | | | | This patch corrects the SPDX License Identifier style in header files related to Cavium Ethernet drivers. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: dsa: microchip: Use the correct style for SPDX License IdentifierNishad Kamdar2019-10-152-4/+4
| | | | | | | | | | | | | | | | This patch corrects the SPDX License Identifier style in header files related to Distributed Switch Architecture drivers for Microchip KSZ series switch support. For C header files Documentation/process/license-rules.rst mandates C-like comments (opposed to C source files where C++ style should be used) Changes made by using a script provided by Joe Perches here: https://lkml.org/lkml/2019/2/7/46. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: ethernet: broadcom: have drivers select DIMLIB as neededRandy Dunlap2019-10-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | NET_VENDOR_BROADCOM is intended to control a kconfig menu only. It should not have anything to do with code generation. As such, it should not select DIMLIB for all drivers under NET_VENDOR_BROADCOM. Instead each driver that needs DIMLIB should select it (being the symbols SYSTEMPORT, BNXT, and BCMGENET). Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1907021810220.13058@ramsan.of.borg/ Fixes: 4f75da3666c0 ("linux/dim: Move implementation to .c files") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Uwe Kleine-König <uwe@kleine-koenig.org> Cc: Tal Gilboa <talgi@mellanox.com> Cc: Saeed Mahameed <saeedm@mellanox.com> Cc: netdev@vger.kernel.org Cc: linux-rdma@vger.kernel.org Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Doug Ledford <dledford@redhat.com> Cc: Jason Gunthorpe <jgg@mellanox.com> Cc: Leon Romanovsky <leonro@mellanox.com> Cc: Or Gerlitz <ogerlitz@mellanox.com> Cc: Sagi Grimberg <sagi@grimberg.me> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: Update address for vrf and l3mdev in MAINTAINERSDavid Ahern2019-10-151-2/+2
| | | | | | | Use my kernel.org address for all entries in MAINTAINERS. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* net: bcmgenet: Set phydev->dev_flags only for internal PHYsFlorian Fainelli2019-10-151-2/+3
| | | | | | | | | | | | phydev->dev_flags is entirely dependent on the PHY device driver which is going to be used, setting the internal GENET PHY revision in those bits only makes sense when drivers/net/phy/bcm7xxx.c is the PHY driver being used. Fixes: 487320c54143 ("net: bcmgenet: communicate integrated PHY revision to PHY driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Doug Berger <opendmb@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* blackhole_netdev: fix syzkaller reported issueMahesh Bandewar2019-10-152-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | While invalidating the dst, we assign backhole_netdev instead of loopback device. However, this device does not have idev pointer and hence no ip6_ptr even if IPv6 is enabled. Possibly this has triggered the syzbot reported crash. The syzbot report does not have reproducer, however, this is the only device that doesn't have matching idev created. Crash instruction is : static inline bool ip6_ignore_linkdown(const struct net_device *dev) { const struct inet6_dev *idev = __in6_dev_get(dev); return !!idev->cnf.ignore_routes_with_linkdown; <= crash } Also ipv6 always assumes presence of idev and never checks for it being NULL (as does the above referenced code). So adding a idev for the blackhole_netdev to avoid this class of crashes in the future. Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'wireless-drivers-for-davem-2019-10-15' of ↵David S. Miller2019-10-1511-189/+239
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for 5.4 Second set of fixes for 5.4. ath10k regression and iwlwifi BAD_COMMAND bug are the ones getting most reports at the moment. ath10k * fix throughput regression on QCA98XX iwlwifi * fix initialization of 3168 devices (the infamous BAD_COMMAND bug) * other smaller fixes rt2x00 * don't include input-polldev.h header * fix hw reset to work during first 5 minutes of system run ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * ath10k: fix latency issue for QCA988xMiaoqing Pan2019-10-141-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (kvalo: cherry picked from commit 1340cc631bd00431e2f174525c971f119df9efa1 in wireless-drivers-next to wireless-drivers as this a frequently reported regression) Bad latency is found on QCA988x, the issue was introduced by commit 4504f0e5b571 ("ath10k: sdio: workaround firmware UART pin configuration bug"). If uart_pin_workaround is false, this change will set uart pin even if uart_print is false. Tested HW: QCA9880 Tested FW: 10.2.4-1.0-00037 Fixes: 4504f0e5b571 ("ath10k: sdio: workaround firmware UART pin configuration bug") Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
| * Merge tag 'iwlwifi-for-kalle-2019-10-09' of ↵Kalle Valo2019-10-098-181/+229
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes First batch of fixes intended for v5.4 * fix for an ACPI table parsing bug; * a fix for a NULL pointer dereference in the cfg with specific devices; * fix the rb_allocator; * prevent multiple phy configuration with new devices; * fix a race-condition in the rx queue; * prevent a couple of memory leaks; * fix initialization of 3168 devices (the infamous BAD_COMMAND bug); * fix recognition of some newer systems with integrated MAC;
| | * iwlwifi: pcie: change qu with jf devices to use qu configurationLuca Coelho2019-10-091-137/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were a bunch of devices with qu and jf that were loading the configuration with pu and jf, which is wrong. Fix them all accordingly. Additionally, remove 0x1010 and 0x1210 subsytem IDs from the list, since they are obviously wrong, and 0x0044 and 0x0244, which were duplicate. Cc: stable@vger.kernel.org # 5.1+ Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: exclude GEO SAR support for 3168Luca Coelho2019-10-091-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently support two NICs in FW version 29, namely 7265D and 3168. Out of these, only 7265D supports GEO SAR, so adjust the function that checks for it accordingly. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: f5a47fae6aa3 ("iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support") Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: pcie: fix memory leaks in iwl_pcie_ctxt_info_gen3_initNavid Emamdoost2019-10-091-11/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In iwl_pcie_ctxt_info_gen3_init there are cases that the allocated dma memory is leaked in case of error. DMA memories prph_scratch, prph_info, and ctxt_info_gen3 are allocated and initialized to be later assigned to trans_pcie. But in any error case before such assignment the allocated memories should be released. First of such error cases happens when iwl_pcie_init_fw_sec fails. Current implementation correctly releases prph_scratch. But in two sunsequent error cases where dma_alloc_coherent may fail, such releases are missing. This commit adds release for prph_scratch when allocation for prph_info fails, and adds releases for prph_scratch and prph_info when allocation for ctxt_info_gen3 fails. Fixes: 2ee824026288 ("iwlwifi: pcie: support context information for 22560 devices") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: dbg_ini: fix memory leak in alloc_sgtableNavid Emamdoost2019-10-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | In alloc_sgtable if alloc_page fails, the alocated table should be released. Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: pcie: fix rb_allocator workqueue allocationJohannes Berg2019-10-091-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't handle failures in the rb_allocator workqueue allocation correctly. To fix that, move the code earlier so the cleanup is easier and we don't have to undo all the interrupt allocations in this case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: pcie: fix indexing in command dump for new HWJohannes Berg2019-10-091-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We got a crash in iwl_trans_pcie_get_cmdlen(), while the TFD was being accessed to sum up the lengths. We want to access the TFD here, which is the information for the hardware. We always only allocate 32 buffers for the cmd queue, but on newer hardware (using TFH) we can also allocate only a shorter hardware array, also only 32 TFDs. Prior to the TFH, we had to allocate a bigger TFD array but would make those point to a smaller set of buffers. Additionally, now max_tfd_queue_size is up to 65536, so we can access *way* out of bounds of a really only 32-entry array, so it crashes. Fix this by making the TFD index depend on which hardware we are using right now. While changing the calculation, also fix it to not use void ptr arithmetic, but cast to u8 * before. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: mvm: fix race in sync rx queue notificationNaftali Goldstein2019-10-091-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following flow: 1. Driver starts to sync the rx queues due to a delba. mvm->queue_sync_cookie=1. This rx-queues-sync is synchronous, so it doesn't increment the cookie until all rx queues handle the notification from FW. 2. During this time, driver starts to sync rx queues due to nssn sync required. The cookie's value is still 1, but it doesn't matter since this rx-queue-sync is non-synchronous so in the notification handler the cookie is ignored. What _does_ matter is that this flow increments the cookie to 2 immediately. Remember though that the FW won't start servicing this command until it's done with the previous one. 3. FW is still handling the first command, so it sends a notification with internal_notif->sync=1, and internal_notif->cookie=0, which triggers a WARN_ONCE. The solution for this race is to only use the mvm->queue_sync_cookie in case of a synchronous sync-rx-queues. This way in step 2 the cookie's value won't change so we avoid the WARN. The commit in the "fixes" field is the first commit to introduce non-synchronous sending of this command to FW. Fixes: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues") Signed-off-by: Naftali Goldstein <naftali.goldstein@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: mvm: force single phy initHaim Dreyfuss2019-10-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PHY is initialized during device initialization, but devices with the tx_siso_diversity flag set need to send PHY_CONFIGURATION_CMD first, otherwise the PHY would be reinitialized, causing a SYSASSERT. To fix this, use a bit that tells the FW not to complete the PHY initialization before a PHY_CONFIGURATION_CMD is received. Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
| | * iwlwifi: fix ACPI table revision checksLuca Coelho2019-10-092-10/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can't check for the ACPI table revision validity in the same if where we check if the package was read correctly, because we return PTR_ERR(pkg) and if the table is not valid but the pointer is, we would return a valid pointer as an error. Fix that by moving the table checks to a separate if and return -EINVAL if it's not valid. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-13 01:32:08 +0000