- 28 7月, 2017 14 次提交
-
-
由 Brian Norris 提交于
After removing the interrupt loop in commit 5d5ddb5e ("mwifiex: pcie: don't loop/retry interrupt status checks"), we don't need to keep track of the cleared interrupts (actually, we didn't need to do that before, but we *really* don't need to now). Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
It's always called with 'true' -- we only determine it 'false' locally within this function. So drop the parameter. Also, this should be 'bool' (since we use true/false), not 'u32'. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
We're open-coding these. Just use the helpers. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
It doesn't fail. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
Despite the name (and meticulous comments), this function frees no memory and does not touch any locks. All it does is "delete" the list heads -- which just means they'll be dangling, and we'll need to re-init them if we use them again. It seems like this code would work OK as a sort of canary for using the list after we've torn everything down, so it's fine to keep the code; let's just get the name and comments to match what's actually happening. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
The .idle_time field *should* be unused, but technically, we're allowing unitialized stack garbage to pass all the way through to the firmware host command. Let's zero it out instead. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
In reading through _mwifiex_fw_dpc(), I noticed that after we've registered our wiphy, we still have error paths that don't free it back up. Let's do that. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
When we leave the delete interface function, there are still netdev hooks that might try to process the device. We're short-circuiting some of that by changing the interface type and clearing ieee80211_ptr. This means we skip NETDEV_UNREGISTER_FINAL in cfg80211. Fortunately, that is currently a no-op. We don't need most of the cleanup here anyway: * the connection state will get (un)set as part of the disconnect process (which cfg80211 already initiates for us) * the interface type doesn't actually need to be cleared at all (it'll trigger a WARN_ON() in cfg80211 if we do) * the iee80211_ptr isn't really "ours" to clear anyway So stop resetting those 3 things. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
It's possible for some control interfaces (e.g., scans, set freq) to be active after we've stopped our main work queue and the netif TX queues. These don't get completely shut out until we've unregistered the wdevs and wiphy. So let's only free command buffers and poison our lists after wiphy_unregister(). This resolves various use-after-free issues seen when resetting the device. Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
In general, it's helpful to use the same code for device removal as for device reset, as this tends to have fewer bugs. Let's move the wiphy unregistration code into the common reset and removal code. In particular, it's very hard to properly handle the reset sequence when something fails. Currently, if mwifiex_reinit_sw() fails, we've failed to unregister the associated wiphy, and so running something as simple as "iw phy" can trigger an OOPS, as the wiphy still has hooks back into freed mwifiex data structures. For example, KASAN complained: [... see reset fail for other reasons ...] [ 1184.821158] mwifiex_pcie 0000:01:00.0: info: dnld wifi firmware from 174948 bytes [ 1186.870914] mwifiex_pcie 0000:01:00.0: info: FW download over, size 608396 bytes [ 1187.685990] mwifiex_pcie 0000:01:00.0: WLAN FW is active [ 1187.692673] mwifiex_pcie 0000:01:00.0: cmd_wait_q terminated: -512 [ 1187.699075] mwifiex_pcie 0000:01:00.0: info: _mwifiex_fw_dpc: unregister device [ 1187.713476] mwifiex: Failed to bring up adapter: -5 [ 1187.718644] mwifiex_pcie 0000:01:00.0: reinit failed: -5 [... run `iw phy` ...] [ 1212.902419] ================================================================== [ 1212.909806] BUG: KASAN: use-after-free in mwifiex_cfg80211_get_antenna+0x54/0xfc [mwifiex] at addr ffffffc0ad1a8028 [ 1212.920246] Read of size 1 by task iw/3127 [...] [ 1212.934946] page dumped because: kasan: bad access detected [...] [ 1212.950665] Call trace: [ 1212.953148] [<ffffffc00020a69c>] dump_backtrace+0x0/0x190 [ 1212.958572] [<ffffffc00020a96c>] show_stack+0x20/0x28 [ 1212.963648] [<ffffffc0005ce18c>] dump_stack+0xa4/0xcc [ 1212.968723] [<ffffffc0003c4430>] kasan_report+0x378/0x500 [ 1212.974140] [<ffffffc0003c3358>] __asan_load1+0x44/0x4c [ 1212.979462] [<ffffffbffc2e8360>] mwifiex_cfg80211_get_antenna+0x54/0xfc [mwifiex] [ 1212.987131] [<ffffffbffc084fc4>] nl80211_send_wiphy+0x75c/0x2de0 [cfg80211] [ 1212.994246] [<ffffffbffc094f60>] nl80211_dump_wiphy+0x32c/0x438 [cfg80211] [ 1213.001149] [<ffffffc000ab6404>] genl_lock_dumpit+0x48/0x64 [ 1213.006746] [<ffffffc000ab3474>] netlink_dump+0x178/0x398 [ 1213.012171] [<ffffffc000ab3d18>] __netlink_dump_start+0x1bc/0x260 [...] This all goes away if we just tear down the wiphy on the way down, and set it back up if/when we bring the device back up. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
In rogue cases (due to other bugs) it's possible we try to process an old command response *after* resetting the device. This could trigger a double-free (or the SKB can get reallocated elsewhere...causing other memory corruptions) in mwifiex_pcie_process_cmd_complete(). For safety (and symmetry) let's always NULL out the command buffer as we free it up. We're already doing this for the command response buffer. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
When resetting the device, we might have queued up interrupts that didn't get a chance to finish processing. We really don't need to handle them at this point; we just want to make sure they don't cause us to try to process old commands from before the device was reset. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
When PCIe FLR code was added, it explicitly copy-and-pasted much of mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary, as almost all of the code should be reused. Let's reunite what we can for now. The only functional changes for now: * call netif_device_detach() in the remove() code path -- this wasn't done before, but it really should be a no-op, when the device is getting totally unregistered soon anyway * call the ->down_dev() driver callback only after we've finished all SW teardown -- this should have no significant effect, since the only user (pcie.c) does very minimal work there, and it doesn't matter that we reorder this Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 27 7月, 2017 1 次提交
-
-
由 Brian Norris 提交于
mwifiex records information about various channels as it receives scan information. It does this by appending to a buffer that was sized to the max number of supported channels on any band, but there are numerous problems: (a) scans can return info from more than one band (e.g., both 2.4 and 5 GHz), so the determined "max" is not large enough (b) some firmware appears to return multiple results for a given channel, so the max *really* isn't large enough (c) there is no bounds checking when stashing these stats, so problems (a) and (b) can easily lead to buffer overflows Let's patch this by setting a slightly-more-correct max (that accounts for a combination of both 2.4G and 5G bands) and adding a bounds check when writing to our statistics buffer. Due to problem (b), we still might not properly report all known survey information (e.g., with "iw <dev> survey dump"), since duplicate results (or otherwise "larger than expected" results) will cause some truncation. But that's a problem for a future bugfix. (And because of this known deficiency, only log the excess at the WARN level, since that isn't visible by default in this driver and would otherwise be a bit too noisy.) Fixes: bf354433 ("mwifiex: channel statistics support for mwifiex") Cc: <stable@vger.kernel.org> Cc: Avinash Patil <patila@marvell.com> Cc: Xinming Hu <huxm@marvell.com> Signed-off-by: NBrian Norris <briannorris@chromium.org> Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 03 7月, 2017 1 次提交
-
-
由 Christoph Hellwig 提交于
The pci_error_handlers->reset_notify() method had a flag to indicate whether to prepare for or clean up after a reset. The prepare and done cases have no shared functionality whatsoever, so split them into separate methods. [bhelgaas: changelog, update locking comments] Link: http://lkml.kernel.org/r/20170601111039.8913-3-hch@lst.deSigned-off-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 30 6月, 2017 1 次提交
-
-
由 Ganapathi Bhat 提交于
We should not copy the MCS set from hostapd RX-STBC. We have to just use the MCS set supported by the hardware. This fixes an issue, where mwifiex is advertising wrong MCS sets in beacons. Fixes: 474a41e9 ("mwifiex: update MCS set as per RX-STBC bit from hostapd") Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 29 6月, 2017 2 次提交
-
-
由 Colin Ian King 提交于
Trivial fix to spelling mistake in mwifiex_dbg message Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Ganapathi Bhat 提交于
When user adds a virtual interface driver will set the bss_type to the iface_type given by the user. When supplicant is started on the same interface, a call to change_virtual_intf will be triggered if if_type is not NL80211_IFTYPE_STATION. Here driver should not update it's bss_type, because bss_type is intended to indicate the original iface_type and changing the same will defeat the purpose of creating this interface. Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 21 6月, 2017 2 次提交
-
-
由 Shawn Lin 提交于
debugfs_remove already check mwifiex_dfs_dir, so remove it. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Caesar Wang 提交于
This patch uses WARN level is not printed by default. In some cases, some boards have always met the unused log be printed as follows. ... [23193.523182] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp: cannot find cfp by band 2 & channel=13 freq=0 [23378.633684] mwifiex_pcie 0000:01:00.0: mwifiex_get_cfp: cannot find cfp by band 2 & channel=13 freq=0 Due to we used the wifi default area was US and didn't support 12~14 channels. As Frequencies: * 2412 MHz [1] (30.0 dBm) * 2417 MHz [2] (30.0 dBm) * 2422 MHz [3] (30.0 dBm) * 2427 MHz [4] (30.0 dBm) * 2432 MHz [5] (30.0 dBm) * 2437 MHz [6] (30.0 dBm) * 2442 MHz [7] (30.0 dBm) * 2447 MHz [8] (30.0 dBm) * 2452 MHz [9] (30.0 dBm) * 2457 MHz [10] (30.0 dBm) * 2462 MHz [11] (30.0 dBm) * 2467 MHz [12] (disabled) * 2472 MHz [13] (disabled) * 2484 MHz [14] (disabled) Also, as the commit 1b499cb7 ("mwifiex: disable channel filtering feature in firmware"), it proved to be a feature to get better scan result from overlapping channel. Even there could be AP from overlapping channel (might be 12/13/14 in this case), it will be filtered depend on reg domain rules. e.g: ... if (ch->flags & IEEE80211_CHAN_DISABLED) continue; So it should not been an ERROR, use the WARN level to instead it for now. Signed-off-by: NCaesar Wang <wxt@rock-chips.com> Acked-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 16 6月, 2017 3 次提交
-
-
由 Johannes Berg 提交于
It seems like a historic accident that these return unsigned char *, and in many places that means casts are required, more often than not. Make these functions (skb_put, __skb_put and pskb_put) return void * and remove all the casts across the tree, adding a (u8 *) cast only where the unsigned char pointer was used directly, all done with the following spatch: @@ expression SKB, LEN; typedef u8; identifier fn = { skb_put, __skb_put }; @@ - *(fn(SKB, LEN)) + *(u8 *)fn(SKB, LEN) @@ expression E, SKB, LEN; identifier fn = { skb_put, __skb_put }; type T; @@ - E = ((T *)(fn(SKB, LEN))) + E = fn(SKB, LEN) which actually doesn't cover pskb_put since there are only three users overall. A handful of stragglers were converted manually, notably a macro in drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many instances in net/bluetooth/hci_sock.c. In the former file, I also had to fix one whitespace problem spatch introduced. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
A common pattern with skb_put() is to just want to memcpy() some data into the new space, introduce skb_put_data() for this. An spatch similar to the one for skb_put_zero() converts many of the places using it: @@ identifier p, p2; expression len, skb, data; type t, t2; @@ ( -p = skb_put(skb, len); +p = skb_put_data(skb, data, len); | -p = (t)skb_put(skb, len); +p = skb_put_data(skb, data, len); ) ( p2 = (t2)p; -memcpy(p2, data, len); | -memcpy(p, data, len); ) @@ type t, t2; identifier p, p2; expression skb, data; @@ t *p; ... ( -p = skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); | -p = (t *)skb_put(skb, sizeof(t)); +p = skb_put_data(skb, data, sizeof(t)); ) ( p2 = (t2)p; -memcpy(p2, data, sizeof(*p)); | -memcpy(p, data, sizeof(*p)); ) @@ expression skb, len, data; @@ -memcpy(skb_put(skb, len), data, len); +skb_put_data(skb, data, len); (again, manually post-processed to retain some comments) Reviewed-by: NStephen Hemminger <stephen@networkplumber.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
There were many places that my previous spatch didn't find, as pointed out by yuan linyu in various patches. The following spatch found many more and also removes the now unnecessary casts: @@ identifier p, p2; expression len; expression skb; type t, t2; @@ ( -p = skb_put(skb, len); +p = skb_put_zero(skb, len); | -p = (t)skb_put(skb, len); +p = skb_put_zero(skb, len); ) ... when != p ( p2 = (t2)p; -memset(p2, 0, len); | -memset(p, 0, len); ) @@ type t, t2; identifier p, p2; expression skb; @@ t *p; ... ( -p = skb_put(skb, sizeof(t)); +p = skb_put_zero(skb, sizeof(t)); | -p = (t *)skb_put(skb, sizeof(t)); +p = skb_put_zero(skb, sizeof(t)); ) ... when != p ( p2 = (t2)p; -memset(p2, 0, sizeof(*p)); | -memset(p, 0, sizeof(*p)); ) @@ expression skb, len; @@ -memset(skb_put(skb, len), 0, len); +skb_put_zero(skb, len); Apply it to the tree (with one manual fixup to keep the comment in vxlan.c, which spatch removed.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 14 6月, 2017 1 次提交
-
-
由 Johannes Berg 提交于
Use the recently introduced helper to replace the pattern of skb_put() && memset(), this transformation was done with the following spatch: @@ identifier p; expression len; expression skb; @@ -p = skb_put(skb, len); -memset(p, 0, len); +p = skb_put_zero(skb, len); Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 6月, 2017 2 次提交
-
-
由 Binoy Jayan 提交于
The semaphore 'async_sem' is used as a simple mutex, so it should be written as one. Semaphores are going away in the future. Signed-off-by: NBinoy Jayan <binoy.jayan@linaro.org> Reviewed-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Colin Ian King 提交于
function mwifiex_ret_pkt_aggr_ctrl can be made static as it does not need to be in global scope. Cleans up sparse warning: "symbol 'mwifiex_ret_pkt_aggr_ctrl' was not declared. Should it be static?" Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 08 6月, 2017 1 次提交
-
-
由 David S. Miller 提交于
Network devices can allocate reasources and private memory using netdev_ops->ndo_init(). However, the release of these resources can occur in one of two different places. Either netdev_ops->ndo_uninit() or netdev->destructor(). The decision of which operation frees the resources depends upon whether it is necessary for all netdev refs to be released before it is safe to perform the freeing. netdev_ops->ndo_uninit() presumably can occur right after the NETDEV_UNREGISTER notifier completes and the unicast and multicast address lists are flushed. netdev->destructor(), on the other hand, does not run until the netdev references all go away. Further complicating the situation is that netdev->destructor() almost universally does also a free_netdev(). This creates a problem for the logic in register_netdevice(). Because all callers of register_netdevice() manage the freeing of the netdev, and invoke free_netdev(dev) if register_netdevice() fails. If netdev_ops->ndo_init() succeeds, but something else fails inside of register_netdevice(), it does call ndo_ops->ndo_uninit(). But it is not able to invoke netdev->destructor(). This is because netdev->destructor() will do a free_netdev() and then the caller of register_netdevice() will do the same. However, this means that the resources that would normally be released by netdev->destructor() will not be. Over the years drivers have added local hacks to deal with this, by invoking their destructor parts by hand when register_netdevice() fails. Many drivers do not try to deal with this, and instead we have leaks. Let's close this hole by formalizing the distinction between what private things need to be freed up by netdev->destructor() and whether the driver needs unregister_netdevice() to perform the free_netdev(). netdev->priv_destructor() performs all actions to free up the private resources that used to be freed by netdev->destructor(), except for free_netdev(). netdev->needs_free_netdev is a boolean that indicates whether free_netdev() should be done at the end of unregister_netdevice(). Now, register_netdevice() can sanely release all resources after ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit() and netdev->priv_destructor(). And at the end of unregister_netdevice(), we invoke netdev->priv_destructor() and optionally call free_netdev(). Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 01 6月, 2017 2 次提交
-
-
由 Xinming Hu 提交于
AP interface need process remain-on-channel firmware event and notify cfg80211, this will be used in the listen-stage of p2p find procedure. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Shawn Lin 提交于
We don't need to check if the list is empty separately as we could use list_first_entry_or_null to cover it. Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com> Reviewed-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 31 5月, 2017 5 次提交
-
-
由 Xinming Hu 提交于
The next packet length will be used by interface driver, to check if the next packet still could be aggregated. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
Aggregation will wait for next packet until limit aggr size/number reach. Packet might be drop and also packet dequeue will be stop in some cases. This patch add timer to flush packets in aggregation list to avoid long time waiting. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
Instead of using 4KB packet buffer for data transfer, new chipset have more device memory. This patch try to aggregation packets in an 16KB buffer. In this way, totally usb transaction cost will be reduced. Thoughput test on usb 2.0 show both TCP TX and UPD TX promote ~40M, from ~240M to ~280M. This feature is default disabled, and can be enabled by module parameter, like: insmod mwifiex.ko aggr_ctrl=1 Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
we have observed host system hang when device firmware crash, stack trace show it was an use-after-free case: previous submitted urb will be holding in usbcore, and given back to device driver when device disconnected, while the urb have been freed in usb device disconnect handler. This patch kill the holding urb before free its memory. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Xinming Hu 提交于
Usb tx aggregation feature will utilize 4-bytes bus interface header, otherwise it will be set to zero in default case. Signed-off-by: NXinming Hu <huxm@marvell.com> Signed-off-by: NCathy Luo <cluo@marvell.com> Signed-off-by: NGanapathi Bhat <gbhat@marvell.com> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
- 19 5月, 2017 5 次提交
-
-
由 Johan Hovold 提交于
Add the missing endianness conversions to a debug statement printing the USB device-descriptor bcdUSB field during probe. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
These are already handled by mwifiex_shutdown_sw() and mwifiex_reinit_sw(). Ideally, we'll kill the flag entirely eventually, as I suspect it breeds race conditions. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
These pointers are retrieved via container_of(). There's no way they are NULL. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-
由 Brian Norris 提交于
We're using 'adapter' right before calling this. Stop being unnecessarily paranoid. Signed-off-by: NBrian Norris <briannorris@chromium.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
-