summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2017-09-27crypto: ccp - Fix XTS-AES-128 support on v5 CCPsGary R Hook4-10/+41
commit e652399edba99a5497f0d80f240c9075d3b43493 upstream. Version 5 CCPs have some new requirements for XTS-AES: the type field must be specified, and the key requires 512 bits, with each part occupying 256 bits and padded with zeroes. Signed-off-by: Gary R Hook <ghook@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27Input: i8042 - add Gigabyte P57 to the keyboard reset tableKai-Heng Feng1-0/+7
commit 697c5d8a36768b36729533fb44622b35d56d6ad0 upstream. Similar to other Gigabyte laptops, the touchpad on P57 requires a keyboard reset to detect Elantech touchpad correctly. BugLink: https://bugs.launchpad.net/bugs/1594214 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27pinctrl/amd: save pin registers over suspend/resumeDaniel Drake2-0/+76
commit 79d2c8bede2c93f9432d7da0bc2f76a195c90fc0 upstream. The touchpad in the Asus laptop models X505BA/BP and X542BA/BP is unresponsive after suspend/resume. The following error appears during resume: i2c_hid i2c-ELAN1300:00: failed to reset device. The problem here is that i2c_hid does not notice the interrupt being generated at this point, because the GPIO is no longer configured for interrupts. Fix this by saving pinctrl-amd pin registers during suspend and restoring them at resume time. Based on code from pinctrl-intel. Signed-off-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27pinctrl: samsung: Fix NULL pointer exception on external interrupts on S3C24xxKrzysztof Kozlowski4-38/+50
commit cee7413d84044a0c1919a7c70a2d761ae24390de upstream. After commit 8b1bd11c1f8f ("pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank"), the S3C24xx (and probably S3C64xx as well) fails: Unable to handle kernel NULL pointer dereference at virtual address 000000a8 ... (s3c24xx_demux_eint4_7) from [<c004469c>] (__handle_domain_irq+0x6c/0xcc) (__handle_domain_irq) from [<c0009444>] (s3c24xx_handle_irq+0x6c/0x12c) (s3c24xx_handle_irq) from [<c000e5fc>] (__irq_svc+0x5c/0x78) Mentioned commit moved the pointer to controller's base IO memory address from each controller's driver data (samsung_pinctrl_drv_data) to per-bank structure (samsung_pin_bank). The external interrupt demux handlers (s3c24xx_demux_eint()) tried to get this base address from opaque pointer stored under irq_chip data: struct irq_data *irqd = irq_desc_get_irq_data(desc); struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd); ... pend = readl(bank->eint_base + EINTPEND_REG); which is wrong because this is hardware irq and it bank was never set for this irq_chip. For S3C24xx and S3C64xx, this partially reverts mentioned commit by bringing back the virt_base stored under each controller's driver data (samsung_pinctrl_drv_data). This virt_base address will be now duplicated: - samsung_pinctrl_drv_data->virt_base: used on S3C24xx and S3C64xx, - samsung_pin_bank->pctl_base: used on Exynos. Fixes: 8b1bd11c1f8f ("pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank") Cc: Sergio Prado <sergio.prado@e-labworks.com> Reported-by: Sergio Prado <sergio.prado@e-labworks.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Lihua Yao <ylhuajnu@163.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27pinctrl: samsung: Fix invalid register offset used for Exynos5433 external ↵Krzysztof Kozlowski1-4/+4
interrupts commit af0b0baa89953aed07034725023371b2fa50a1e6 upstream. When setting the pin function for external interrupts, the driver used wrong IO memory address base. The pin function register is always under pctl_base, not the eint_base. By updating wrong register, the external interrupts for chosen GPIO would not work at all and some other GPIO might be configured to wrong value. For example on Exynos5433-based boards, the external interrupts for gpf{1-5}-X GPIOs should not work at all (driver toggled reserved registers from ALIVE bank instead). Platforms other than Exynos5433 should not be affected as eint_base equals pctl_base in such case. Fixes: 8b1bd11c1f8f ("pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank") Reported-by: Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27tty: fix __tty_insert_flip_char regressionArnd Bergmann1-1/+2
commit 8a5a90a2a477b86a3dc2eaa5a706db9bfdd647ca upstream. Sergey noticed a small but fatal mistake in __tty_insert_flip_char, leading to an oops in an interrupt handler when using any serial port. The problem is that I accidentally took the tty_buffer pointer before calling __tty_buffer_request_room(), which replaces the buffer. This moves the pointer lookup to the right place after allocating the new buffer space. Fixes: 979990c62848 ("tty: improve tty_insert_flip_char() fast path") Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27tty: improve tty_insert_flip_char() slow pathArnd Bergmann1-2/+3
commit 065ea0a7afd64d6cf3464bdd1d8cd227527e2045 upstream. While working on improving the fast path of tty_insert_flip_char(), I noticed that by calling tty_buffer_request_room(), we needlessly move to the separate flag buffer mode for the tty, even when all characters use TTY_NORMAL as the flag. This changes the code to call __tty_buffer_request_room() with the correct flag, which will then allocate a regular buffer when it rounds out of space but no special flags have been used. I'm guessing that this is the behavior that Peter Hurley intended when he introduced the compacted flip buffers. Fixes: acc0f67f307f ("tty: Halve flip buffer GFP_ATOMIC memory consumption") Cc: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27tty: improve tty_insert_flip_char() fast pathArnd Bergmann1-0/+24
commit 979990c6284814617d8f2179d197f72ff62b5d85 upstream. kernelci.org reports a crazy stack usage for the VT code when CONFIG_KASAN is enabled: drivers/tty/vt/keyboard.c: In function 'kbd_keycode': drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] The problem is that tty_insert_flip_char() gets inlined many times into kbd_keycode(), and also into other functions, and each copy requires 128 bytes for stack redzone to check for a possible out-of-bounds access on the 'ch' and 'flags' arguments that are passed into tty_insert_flip_string_flags as a variable-length string. This introduces a new __tty_insert_flip_char() function for the slow path, which receives the two arguments by value. This completely avoids the problem and the stack usage goes back down to around 100 bytes. Without KASAN, this is also slightly better, as we don't have to spill the arguments to the stack but can simply pass 'ch' and 'flag' in registers, saving a few bytes in .text for each call site. This should be backported to linux-4.0 or later, which first introduced the stack sanitizer in the kernel. Fixes: c420f167db8c ("kasan: enable stack instrumentation") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27drm/amdgpu: read reg in each iterator of psp_wait_for loopZhang, Jerry2-4/+1
commit 2890decfd9969cac21067ca0c734fbccaf74d634 upstream. v2: fix the SOS loading failure for PSP v3.1 Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> (v1) Acked-by: Huang Rui <ray.huang@amd.com> (v1) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27Input: xpad - validate USB endpoint type during probeCameron Gutman1-4/+6
commit 122d6a347329818419b032c5a1776e6b3866d9b9 upstream. We should only see devices with interrupt endpoints. Ignore any other endpoints that we find, so we don't send try to send them interrupt URBs and trigger a WARN down in the USB stack. Reported-by: Andrey Konovalov <andreyknvl@google.com> Tested-by: Andrey Konovalov <andreyknvl@google.com> Signed-off-by: Cameron Gutman <aicommander@gmail.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27IB/mlx5: Fix cached MR allocation flowMajd Dibbiny1-5/+13
commit 4c25b7a39005c9243a492b577c3e940eeac36a25 upstream. When we have a miss in one order of the mkey cache, we try to get an mkey from a higher order. We still need to check that the higher order can be used with UMR before using it. Otherwise, we will get an mkey with 0 entries and the post send operation that is used to fill it will complete with the following error: mlx5_0:dump_cqe:275:(pid 0): dump error cqe 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0f007806 25000025 49ce59d2 Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib") Signed-off-by: Majd Dibbiny <majd@mellanox.com> Reviewed-by: Ilya Lesokhin <ilyal@mellanox.com> Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27IB/{qib, hfi1}: Avoid flow control testing for RDMA write operationMike Marciniszyn2-3/+4
commit 5b0ef650bd0f820e922fcc42f1985d4621ae19cf upstream. Section 9.7.7.2.5 of the 1.3 IBTA spec clearly says that receive credits should never apply to RDMA write. qib and hfi1 were doing that. The following situation will result in a QP hang: - A prior SEND or RDMA_WRITE with immmediate consumed the last credit for a QP using RC receive buffer credits - The prior op is acked so there are no more acks - The peer ULP fails to post receive for some reason - An RDMA write sees that the credits are exhausted and waits - The peer ULP posts receive buffers - The ULP posts a send or RDMA write that will be hung The fix is to avoid the credit test for the RDMA write operation. Reviewed-by: Kaike Wan <kaike.wan@intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-27IB/hfi1: Revert egress pkey check enforcementAlex Estrin1-1/+0
commit ecdb19f4b513033e6f2c4326cd5b81e04393e5e1 upstream. Current code has some serious flaws. Disarm the flag pending an appropriate patch. Fixes: 53526500f301 ("IB/hfi1: Permanently enable P_Key checking in HFI") Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com> Signed-off-by: Alex Estrin <alex.estrin@intel.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20md/raid5: release/flush io in raid5_do_work()Song Liu1-0/+4
commit 9c72a18e46ebe0f09484cce8ebf847abdab58498 upstream. In raid5, there are scenarios where some ios are deferred to a later time, and some IO need a flush to complete. To make sure we make progress with these IOs, we need to call the following functions: flush_deferred_bios(conf); r5l_flush_stripe_to_raid(conf->log); Both of these functions are called in raid5d(), but missing in raid5_do_work(). As a result, these functions are not called when multi-threading (group_thread_cnt > 0) is enabled. This patch adds calls to these function to raid5_do_work(). Note for stable branches: r5l_flush_stripe_to_raid(conf->log) is need for 4.4+ flush_deferred_bios(conf) is only needed for 4.11+ Signed-off-by: Song Liu <songliubraving@fb.com> Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20md/raid1/10: reset bio allocated from mempoolShaohua Li2-4/+50
commit 208410b546207cfc4c832635fa46419cfa86b4cd upstream. Data allocated from mempool doesn't always get initialized, this happens when the data is reused instead of fresh allocation. In the raid1/10 case, we must reinitialize the bios. Reported-by: Jonathan G. Underwood <jonathan.underwood@gmail.com> Fixes: f0250618361d(md: raid10: don't use bio's vec table to manage resync pages) Fixes: 98d30c5812c3(md: raid1: don't use bio's vec table to manage resync pages) Cc: Ming Lei <ming.lei@redhat.com> Signed-off-by: Shaohua Li <shli@fb.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20libnvdimm: fix integer overflow static analysis warningDan Williams1-8/+9
commit 58738c495e15badd2015e19ff41f1f1ed55200bc upstream. Dan reports: The patch 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus and nvdimm devices" from Jun 8, 2015, leads to the following static checker warning: drivers/nvdimm/bus.c:1018 __nd_ioctl() warn: integer overflows 'buf_len' From a casual review, this seems like it might be a real bug. On the first iteration we load some data into in_env[]. On the second iteration we read a use controlled "in_size" from nd_cmd_in_size(). It can go up to UINT_MAX - 1. A high number means we will fill the whole in_env[] buffer. But we potentially keep looping and adding more to in_len so now it can be any value. It simple enough to change, but it feels weird that we keep looping even though in_env is totally full. Shouldn't we just return an error if we don't have space for desc->in_num. We keep looping because the size of the total input is allowed to be bigger than the 'envelope' which is a subset of the payload that tells us how much data to expect. For safety explicitly check that buf_len does not overflow which is what the checker flagged. Fixes: 62232e45f4a2: "libnvdimm: control (ioctl) messages for nvdimm_bus..." Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20libnvdimm, btt: check memory allocation failureChristophe Jaillet1-0/+2
commit ed36b4dba54a421ce5551638f6a9790b2c2116b1 upstream. Check memory allocation failures and return -ENOMEM in such cases, as already done few lines below for another memory allocation. This avoids NULL pointers dereference. Fixes: 14e494542636 ("libnvdimm, btt: BTT updates for UEFI 2.7 format") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Vishal Verma <vishal.l.verma@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20thunderbolt: Allow clearing the keyBernat, Yehezkel1-4/+11
commit e545f0d8a54a9594fe604d67d80ca6fddf72ca59 upstream. If secure authentication of a devices fails, either because the device already has another key uploaded, or there is some other error sending challenge to the device, and the user only wants to approve the device just once (without a new key being uploaded to the device) the current implementation does not allow this because the key cannot be cleared once set even if we allow it to be changed. Make this scenario possible and allow clearing the key by writing empty string to the key sysfs file. Signed-off-by: Yehezkel Bernat <yehezkel.bernat@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20thunderbolt: Make key root-only accessibleBernat, Yehezkel1-1/+1
commit 0956e41169222822d3557871fcd1d32e4fa7e934 upstream. Non-root user may read the key back after root wrote it there. This removes read access to everyone but root. Signed-off-by: Yehezkel Bernat <yehezkel.bernat@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20thunderbolt: Remove superfluous checkBernat, Yehezkel1-3/+0
commit 8fdd6ab36197ad891233572c57781b1f537da0ac upstream. The key size is tested by hex2bin() already (as '\0' isn't an hex digit) Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Yehezkel Bernat <yehezkel.bernat@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20vhost_net: correctly check tx avail during rx busy pollingJason Wang1-1/+6
[ Upstream commit 8b949bef9172ca69d918e93509a4ecb03d0355e0 ] We check tx avail through vhost_enable_notify() in the past which is wrong since it only checks whether or not guest has filled more available buffer since last avail idx synchronization which was just done by vhost_vq_avail_empty() before. What we really want is checking pending buffers in the avail ring. Fix this by calling vhost_vq_avail_empty() instead. This issue could be noticed by doing netperf TCP_RR benchmark as client from guest (but not host). With this fix, TCP_RR from guest to localhost restores from 1375.91 trans per sec to 55235.28 trans per sec on my laptop (Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz). Fixes: 030881372460 ("vhost_net: basic polling support") Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20gianfar: Fix Tx flow control deactivationClaudiu Manoil1-1/+1
[ Upstream commit 5d621672bc1a1e5090c1ac5432a18c79e0e13e03 ] The wrong register is checked for the Tx flow control bit, it should have been maccfg1 not maccfg2. This went unnoticed for so long probably because the impact is hardly visible, not to mention the tangled code from adjust_link(). First, link flow control (i.e. handling of Rx/Tx link level pause frames) is disabled by default (needs to be enabled via 'ethtool -A'). Secondly, maccfg2 always returns 0 for tx_flow_oldval (except for a few old boards), which results in Tx flow control remaining always on once activated. Fixes: 45b679c9a3ccd9e34f28e6ec677b812a860eb8eb ("gianfar: Implement PAUSE frame generation support") Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14rt2800: fix TX_PIN_CFG setting for non MT7620 chipsStanislaw Gruszka1-1/+4
commit 83ec489193894e52bd395eec470f4f7c4286d4a5 upstream. Since commit 41977e86c984 ("rt2x00: add support for MT7620") we do not initialize TX_PIN_CFG setting. This cause breakage at least on some RT3573 devices. To fix the problem patch restores previous behaviour for non MT7620 chips. Fixes: 41977e86c984 ("rt2x00: add support for MT7620") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1480829 Reported-and-tested-by: Jussi Eloranta <jussi.eloranta@csun.edu> Cc: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Daniel Golle <daniel@makrotopia.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14Revert "firmware: add sanity check on shutdown/suspend"Linus Torvalds1-99/+0
commit f007cad159e99fa2acd3b2e9364fbb32ad28b971 upstream. This reverts commit 81f95076281fdd3bc382e004ba1bce8e82fccbce. It causes random failures of firmware loading at resume time (well, random for me, it seems to be more reliable for others) because the firmware disabling is not actually synchronous with any particular resume event, and at least the btusb driver that uses a workqueue to load the firmware at resume seems to occasionally hit the "firmware loading is disabled" logic because the firmware loader hasn't gotten the resume event yet. Some kind of sanity check for not trying to load firmware when it's not possible might be a good thing, but this commit was not it. Greg seems to have silently suffered the same issue, and pointed to the likely culprit, and Gabriel C verified the revert fixed it for him too. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Pointed-at-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Tested-by: Gabriel C <nix.or.die@gmail.com> Cc: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devicesIan W MORRISON1-1/+2
commit f957dd3c8db2781c8a334b166800788feb618625 upstream. The firmware feature check introduced for multi-scheduled scan is also failing for bcm4345 devices resulting in a firmware crash. The reason for this crash has not yet been root cause so this patch avoids the feature check for those device as a short-term fix. Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature") Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14rtlwifi: btcoexist: Fix antenna selection codeLarry Finger1-7/+16
commit 6d622692836950b3c943776f84c4557ff6c02f3b upstream. In commit 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex"), the code turns on a call to exhalbtc_bind_bt_coex_withadapter(). This routine contains a bug that causes incorrect antenna selection for those HP laptops with only one antenna and an incorrectly programmed EFUSE. These boxes are the ones that need the ant_sel module parameter. Fixes: 87d8a9f35202 ("rtlwifi: btcoex: call bind to setup btcoex") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Cc: Birming Chiu <birming@realtek.com> Cc: Shaofu <shaofu@realtek.com> Cc: Steven Ting <steventing@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14rtlwifi: btcoexist: Fix breakage of ant_sel for rtl8723beLarry Finger1-1/+4
commit a33fcba6ec01efcca33b1afad91057020f247f15 upstream. In commit bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when hw initialisation done"), there is an additional error when the module parameter ant_sel is used to select the auxilary antenna. The error is that the antenna selection is not checked when writing the antenna selection register. Fixes: bcd37f4a0831 ("rtlwifi: btcoex: 23b 2ant: let bt transmit when hw initialisation done") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Yan-Hsuan Chuang <yhchuang@realtek.com> Cc: Birming Chiu <birming@realtek.com> Cc: Shaofu <shaofu@realtek.com> Cc: Steven Ting <steventing@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14nvme-fabrics: generate spec-compliant UUID NQNsDaniel Verkamp1-1/+1
commit 40a5fce495715c48c2e02668144e68a507ac5a30 upstream. The default host NQN, which is generated based on the host's UUID, does not follow the UUID-based NQN format laid out in the NVMe 1.3 specification. Remove the "NVMf:" portion of the NQN to match the spec. Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com> Reviewed-by: Max Gurtovoy <maxg@mellanox.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14mtd: nand: qcom: fix config error for BCHAbhishek Sahu1-1/+1
commit 10777de570016471fd929869c7830a7772893e39 upstream. The configuration for BCH is not correct in the current driver. The ECC_CFG_ECC_DISABLE bit defines whether to enable or disable the BCH ECC in which 0x1 : BCH_DISABLED 0x0 : BCH_ENABLED But currently host->bch_enabled is being assigned to BCH_DISABLED. Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver") Signed-off-by: Abhishek Sahu <absahu@codeaurora.org> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14mtd: nand: qcom: fix read failure without complete bootchainAbhishek Sahu1-4/+12
commit d8a9b320a26c1ea28e51e4f3ecfb593d5aac2910 upstream. The NAND page read fails without complete boot chain since NAND_DEV_CMD_VLD value is not proper. The default power on reset value for this register is 0xe - ERASE_START_VALID | WRITE_START_VALID | READ_STOP_VALID The READ_START_VALID should be enabled for sending PAGE_READ command. READ_STOP_VALID should be cleared since normal NAND page read does not require READ_STOP command. Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver") Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Abhishek Sahu <absahu@codeaurora.org> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14mtd: nand: mxc: Fix mxc_v1 ooblayoutBoris Brezillon1-3/+4
commit 3bff08dffe3115a25ce04b95ea75f6d868572c60 upstream. Commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops") introduced a bug in the OOB layout description. Even if the driver claims that 3 ECC bytes are reserved to protect 512 bytes of data, it's actually 5 ECC bytes to protect 512+6 bytes of data (some OOB bytes are also protected using extra ECC bytes). Fix the mxc_v1_ooblayout_{free,ecc}() functions to reflect this behavior. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Fixes: a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops") Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14mtd: nand: hynix: add support for 20nm NAND chipsMartin Blumenstingl1-2/+2
commit fd213b5bae800dc00a2930dcd07f63ab9bbff3f9 upstream. According to the datasheet of the H27UCG8T2BTR the NAND Technology field (6th byte of the "Device Identifier Description", bits 0-2) the following values are possible: - 0x0 = 48nm - 0x1 = 41nm - 0x2 = 32nm - 0x3 = 26nm - 0x4 = 20nm - (all others are reserved) Fix this by extending the mask for this field to allow detecting value 0x4 (20nm) as valid NAND technology. Without this the detection of the ECC requirements fails, because the code assumes that the device is a 48nm device (0x4 & 0x3 = 0x0) and aborts with "Invalid ECC requirements" because it cannot map the "ECC Level". Extending the mask makes the ECC requirement detection code recognize this chip as <= 26nm and sets up the ECC step size and ECC strength correctly. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Fixes: 78f3482d7480 ("mtd: nand: hynix: Rework NAND ID decoding to extract more information") Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-14mtd: nand: make Samsung SLC NAND usable againLothar Waßmann1-2/+5
commit 69fc01296c92814b62dbfba1600fe7ed2ed304f5 upstream. commit c51d0ac59f24 ("mtd: nand: Move Samsung specific init/detection logic in nand_samsung.c") introduced a regression for Samsung SLC NAND chips. Prior to this commit chip->bits_per_cell was initialized by calling nand_get_bits_per_cell() before using nand_is_slc(). With the offending commit this call is skipped, leaving chip->bits_per_cell cleared to zero when the manufacturer specific '.detect' function calls nand_is_slc() which in turn interprets bits_per_cell != 1 as indication for an MLC chip. The effect is that e.g. a K9F1G08U0F NAND chip is falsely detected as MLC NAND with 4KiB page size rather than SLC with 2KiB page size. Add a call to nand_get_bits_per_cell() before calling the .detect hook function in nand_manufacturer_detect(), so that the nand_is_slc() calls in the manufacturer specific code will return correct results. Fixes: c51d0ac59f24 ("mtd: nand: Move Samsung specific init/detection logic in nand_samsung.c") Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09rtlwifi: Fix fallback firmware loadingSven Joachim2-24/+10
commit 1d9b168d8ea9a0f51947d0e2f84856e77d2fe7ff upstream. Commit f70e4df2b384 ("rtlwifi: Add code to read new versions of firmware") added code to load an old firmware file if the new one is not available. Unfortunately that code is never reached because request_firmware_nowait() does not wait for the firmware to show up and returns 0 even if the file is not there. Use the existing fallback mechanism introduced by commit 62009b7f1279 ("rtlwifi: rtl8192cu: Add new firmware") instead. Fixes: f70e4df2b384 ("rtlwifi: Add code to read new versions of firmware") Signed-off-by: Sven Joachim <svenjoac@gmx.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09rtlwifi: Fix memory leak when firmware request failsSouptick Joarder9-0/+24
commit f2764f61fa10593204b0c5e4e9a68dba02112e50 upstream. This patch will fix memory leak when firmware request fails Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Cc: Sven Joachim <svenjoac@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09of/device: Prevent buffer overflow in of_device_modalias()Bjorn Andersson1-0/+2
commit 08ab58d9de3eb8498ae0585001d0975e46217a39 upstream. As of_device_get_modalias() returns the number of bytes that would have been written to the target string, regardless of how much did fit in the buffer, it's possible that the returned index points beyond the buffer passed to of_device_modalias() - causing memory beyond the buffer to be null terminated. Fixes: 0634c2958927 ("of: Add function for generating a DT modalias with a newline") Cc: Rob Herring <robh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09scsi: sg: recheck MMAP_IO request length with lock heldTodd Poynor1-2/+5
commit 8d26f491116feaa0b16de370b6a7ba40a40fa0b4 upstream. Commit 1bc0eb044615 ("scsi: sg: protect accesses to 'reserved' page array") adds needed concurrency protection for the "reserve" buffer. Some checks that are initially made outside the lock are replicated once the lock is taken to ensure the checks and resulting decisions are made using consistent state. The check that a request with flag SG_FLAG_MMAP_IO set fits in the reserve buffer also needs to be performed again under the lock to ensure the reserve buffer length compared against matches the value in effect when the request is linked to the reserve buffer. An -ENOMEM should be returned in this case, instead of switching over to an indirect buffer as for non-MMAP_IO requests. Signed-off-by: Todd Poynor <toddpoynor@google.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09scsi: sg: protect against races between mmap() and SG_SET_RESERVED_SIZETodd Poynor1-3/+9
commit 6a8dadcca81fceff9976e8828cceb072873b7bd5 upstream. Take f_mutex around mmap() processing to protect against races with the SG_SET_RESERVED_SIZE ioctl. Ensure the reserve buffer length remains consistent during the mapping operation, and set the "mmap called" flag to prevent further changes to the reserved buffer size as an atomic operation with the mapping. [mkp: fixed whitespace] Signed-off-by: Todd Poynor <toddpoynor@google.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09cs5536: add support for IDE controller variantAndrey Korolyov2-0/+2
commit 591b6bb605785c12a21e8b07a08a277065b655a5 upstream. Several legacy devices such as Geode-based Cisco ASA appliances and DB800 development board do possess CS5536 IDE controller with different PCI id than existing one. Using pata_generic is not always feasible as at least DB800 requires MSR quirk from pata_cs5536 to be used with vendor firmware. Signed-off-by: Andrey Korolyov <andrey@xdel.ru> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09ahci: don't use MSI for devices with the silly Intel NVMe remapping schemeChristoph Hellwig1-1/+8
commit f723fa4e69920f6a5dd5fa0d10ce90e2f14d189c upstream. Intel AHCI controllers that also hide NVMe devices in their bar can't use MSI interrupts, so disable them. Reported-by: John Loy <john.robert.loy@gmail.com> Tested-by: John Loy <john.robert.loy@gmail.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Fixes: d684a90d38e2 ("ahci: per-port msix support") Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09drm/nouveau: Fix error handling in nv50_disp_atomic_commitMaarten Lankhorst1-2/+5
commit 813a7e1604eaad1c2792d37d402e1b48b8d0eb3f upstream. Make it more clear that post commit return ret is really return 0, and add a missing drm_atomic_helper_cleanup_planes when drm_atomic_helper_wait_for_fences fails. Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces internally") Cc: Ben Skeggs <bskeggs@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-2-maarten.lankhorst@linux.intel.com Reviewed-by: Sean Paul <seanpaul@chromium.org> [mlankhorst: Use if (ret) to remove the goto in success case.] Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09drm/nouveau/pci/msi: disable MSI on big-endian platforms by defaultIlia Mirkin1-0/+4
commit bc60c90f472b6e762ea96ef384072145adc8d4af upstream. It appears that MSI does not work on either G5 PPC nor on a E5500-based platform, where other hardware is reported to work fine with MSI. Both tests were conducted with NV4x hardware, so perhaps other (or even this) hardware can be made to work. It's still possible to force-enable with config=NvMSI=1 on load. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09MCB: add support for SC31 to mcb-lpcMichael Moese1-0/+15
commit acf5e051ac44d5dc60b21bc4734ef1b844d55551 upstream. This patch adds the resources and DMI ID's for the MEN SC31, which uses a different address region to map the LPC bus than the one used for the existing SC24. Signed-off-by: Michael Moese <michael.moese@men.de> [jth add stable tag] Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09mwifiex: correct channel stat buffer overflowsBrian Norris2-1/+7
commit 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream. 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: bf35443314ac ("mwifiex: channel statistics support for mwifiex") Cc: Avinash Patil <patila@marvell.com> Cc: Xinming Hu <huxm@marvell.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Ganapathi Bhat <gbhat@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09iwlwifi: pci: add new PCI ID for 7265DLuca Coelho1-0/+1
commit 3f7a5e13e85026b6e460bbd6e87f87379421d272 upstream. We have a new PCI subsystem ID for 7265D. Add it to the list. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09Bluetooth: Add support of 13d3:3494 RTL8723BE deviceDmitry Tunin1-0/+1
commit a81d72d2002d6a932bd83022cbf8c442b1b97512 upstream. T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3494 Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09rtlwifi: rtl_pci_probe: Fix fail path of _rtl_pci_find_adapterMalcolm Priestley1-2/+2
commit fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream. _rtl_pci_find_adapter fail path will jump to label fail3 for unsupported adapter types. However, on course for fail3 there will be call rtl_deinit_core before rtl_init_core. For the inclusion of checking pci_iounmap this fail can be moved to fail2. Fixes [ 4.492963] BUG: unable to handle kernel NULL pointer dereference at (null) [ 4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi] Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctlyVille Syrjälä1-4/+4
commit 56a91c4932bd038f3d1f6555ddc349ca4e6933b0 upstream. On failure drm_atomic_get_private_obj_state() returns and error pointer instead of NULL. Adjust the checks in the callers to match. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release vcpi slots") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712155102.26276-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09drm/ttm: Fix accounting error when fail to get pages for poolXiangliang.Yu1-1/+1
commit 9afae2719273fa1d406829bf3498f82dbdba71c7 upstream. When fail to get needed page for pool, need to put allocated pages into pool. But current code has a miscalculation of allocated pages, correct it. Signed-off-by: Xiangliang.Yu <Xiangliang.Yu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-09drm/vgem: Pin our pages for dmabuf exportsChris Wilson2-21/+64
commit 71bb23c707c141b176bc084179ca5ee58d5fd26a upstream. When the caller maps their dmabuf and we return an sg_table, the caller doesn't expect the pages beneath that sg_table to vanish on a whim (i.e. under mempressure). The contract is that the pages are pinned for the duration of the mapping (from dma_buf_map_attachment() to dma_buf_unmap_attachment). To comply, we need to introduce our own vgem_object.pages_pin_count and elevate it across the mapping. However, the drm_prime interface we use calls drv->prime_pin on dma_buf_attach and drv->prime_unpin on dma_buf_detach, which while that does cover the mapping is much broader than is desired -- but it will do for now. v2: also hold the pin across prime_vmap/vunmap Reported-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Testcase: igt/gem_concurrent_blit/*swap*vgem* Fixes: 5ba6c9ff961a ("drm/vgem: Fix mmaping") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Laura Abbott <labbott@redhat.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # needs a backport Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170622134617.17912-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-15 18:30:48 +0300