Age | Commit message (Collapse) | Author |
|
commit 620d8745b35d ("Introduce cifs_copy_file_range()") changes the
behaviour of the cifs ioctl call CIFS_IOC_COPYCHUNK_FILE. In case of
successful writes, it now returns the number of bytes written. This
return value is treated as an error by the xfstest cifs/001. Depending
on the errno set at that time, this may or may not result in the test
failing.
The patch fixes this by setting the return value to 0 in case of
successful writes.
Fixes: commit 620d8745b35d ("Introduce cifs_copy_file_range()")
Reported-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Acked-by: Pavel Shilovsky <pshilov@microsoft.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <smfrench@gmail.com>
|
|
Incorrect return value for shares not using the prefix path means that
we will never match superblocks for these shares.
Fixes: commit c1d8b24d1819 ("Compare prepaths when comparing superblocks")
Cc: stable@vger.kernel.org
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <smfrench@gmail.com>
|
|
The ls1046a datasheet specified that the max SD clock frequency
for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet
specified it's 125MHz for ls1012a. So this patch is to add the
limitation.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Have proper request id filled in the SCHED_SCAN_RESULTS and
SCHED_SCAN_STOPPED notifications toward user-space by having the
driver provide it through the api.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The loop to poll ESDHC_CLOCK_STABLE bit with mdelay would waste time
because the time to stabilize is much less than 1 ms. This patch is
to use udelay instead to avoid time wasting.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The default value of LOGIC_TIMING_ADJUST register in eMMC 5.0 PHY is
different from that in eMMC 5.1 PHY. Set the specific value for that
register in eMMC 5.0 PHY.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Reported-by: Jisheng Zhang <jszhang@marvell.com>
Tested-by: Jisheng Zhang <jszhang@marvell.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
sdhci_remove_host() might execute SOFT_RESET_ALL. Inside xenon_remove(),
Xenon SDHC should be enabled during sdhci_remove_host().
Move xenon_sdhc_unprepare after sdhci_remove_host() such that Xenon SDHC is
disabled after sdhci_remove_host() completes.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Reported-by: Jisheng Zhang <jszhang@marvell.com>
Tested-by: Jisheng Zhang <jszhang@marvell.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
Parse the BSS max idle period element and set the BSS configuration
accordingly so the driver can use this information to configure the
max idle period and to use protected management frames for keep alive
when required.
The BSS max idle period element is defined in IEEE802.11-2016,
section 9.4.2.79
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
cfg80211_roamed() and cfg80211_roamed_bss() take the same arguments
except that cfg80211_roamed() requires the BSSID and
cfg80211_roamed_bss() requires the bss entry.
Unify the two functions by using a struct for driver initiated
roaming information so that either the BSSID or the bss entry can be
passed as an argument to the unified function.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
[modified the ath6k, brcm80211, rndis and wlan-ng drivers accordingly]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
[modify brcmfmac to remove the useless cast, spotted by Arend]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even
if the channel context configuration is NULL. This crashes for chipsets
which support 5 Ghz alone when it tries to access members of 'sband'.
Channel context configuration can be NULL in multivif case and when
channel switch is in progress (or) when it fails. Fix this by replacing
the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which
returns a NULL pointer for sband when the channel configuration is NULL.
An example scenario is as below:
In multivif mode (AP + STA) with drivers like ath10k, when we do a
channel switch in the AP vif (which has a number of clients connected)
and a STA vif which is connected to some other AP, when the channel
switch in AP vif fails, while the STA vifs tries to connect to the
other AP, there is a window where the channel context is NULL/invalid
and this results in a crash while the clients connected to the AP vif
tries to reconnect and this race is very similar to the one investigated
by Michal in https://patchwork.kernel.org/patch/3788161/ and this does
happens with hardware that supports 5Ghz alone after long hours of
testing with continuous channel switch on the AP vif
ieee80211 phy0: channel context reservation cannot be finalized because
some interfaces aren't switching
wlan0: failed to finalize CSA, disconnecting
wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice
(Reason: 3=DEAUTH_LEAVING)
WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211]
[<bf77272c>] (sta_info_alloc [mac80211])
[<bf78776c>] (ieee80211_add_station [mac80211]))
[<bf73cc50>] (nl80211_new_station [cfg80211])
Unable to handle kernel NULL pointer dereference at virtual
address 00000014
pgd = d5f4c000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
PC is at sta_info_alloc+0x380/0x3fc [mac80211]
LR is at sta_info_alloc+0x37c/0x3fc [mac80211]
[<bf772738>] (sta_info_alloc [mac80211])
[<bf78776c>] (ieee80211_add_station [mac80211])
[<bf73cc50>] (nl80211_new_station [cfg80211]))
Cc: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When creating a new ipvs service, ipv6 addresses are always accepted
if CONFIG_IP_VS_IPV6 is enabled. On dest creation the address family
is not explicitly checked.
This allows the user-space to configure ipvs services even if the
system is booted with ipv6.disable=1. On specific configuration, ipvs
can try to call ipv6 routing code at setup time, causing the kernel to
oops due to fib6_rules_ops being NULL.
This change addresses the issue adding a check for the ipv6
module being enabled while validating ipv6 service operations and
adding the same validation for dest operations.
According to git history, this issue is apparently present since
the introduction of ipv6 support, and the oops can be triggered
since commit 09571c7ae30865ad ("IPVS: Add function to determine
if IPv6 address is local")
Fixes: 09571c7ae30865ad ("IPVS: Add function to determine if IPv6 address is local")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The sync_refresh_period variable is unsigned, so it can never be < 0.
Signed-off-by: Aaron Conole <aconole@bytheb.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There are no in-tree callers of this function and it isn't exported.
Signed-off-by: Aaron Conole <aconole@bytheb.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fairchild FUSB302 Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and
USB Type-C functionalities.
Signed-off-by: Yueyao Zhu <yueyao.zhu@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The port controller interface driver interconnects the Type-C Port
Manager with a Type-C Port Controller Interface (TCPCI) compliant
port controller.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This driver implements the USB Type-C Power Delivery state machine
for both source and sink ports. Alternate mode support is not
fully implemented.
The driver attaches to the USB Type-C class code implemented in
the following patches.
usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
usb: USB Type-C connector class
This driver only implements the state machine. Lower level drivers are
responsible for
- Reporting VBUS status and activating VBUS
- Setting CC lines and providing CC line status
- Setting line polarity
- Activating and deactivating VCONN
- Setting the current limit
- Activating and deactivating PD message transfers
- Sending and receiving PD messages
The driver provides both a functional API as well as callbacks for
lower level drivers.
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This allows the driver to pass in struct ieee80211_tx_status directly.
Make ieee80211_tx_status_noskb a wrapper around it.
As with ieee80211_tx_status_noskb, there is no _ni variant of this call,
because it probably won't be needed.
Even if the driver won't provide any extra status info other than what's
in struct ieee80211_tx_info already, it can optimize status reporting
this way by passing in the station pointer.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[use C99 initializers]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Makes further cleanups more readable
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Rename .tx_status_noskb to .tx_status_ext and pass a new on-stack
struct ieee80211_tx_status instead of struct ieee80211_tx_info.
This struct can be used to pass extra information, e.g. for dynamic tx
power control
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of hand-coding the bit manipulations, use the bitfield
macros to generate the code for the encoded bitrate.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This field will need to be used again for HE, so rename it now.
Again, mostly done with this spatch:
@@
expression status;
@@
-status->vht_nss
+status->nss
@@
expression status;
@@
-status.vht_nss
+status.nss
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We currently use a lot of flags that are mutually incompatible,
separate this out into actual encoding and bandwidth enum values.
Much of this again done with spatch, with manual post-editing,
mostly to add the switch statements and get rid of the conversions.
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_80MHZ
+status->bw = RATE_INFO_BW_80
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_40MHZ
+status->bw = RATE_INFO_BW_40
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_20MHZ
+status->bw = RATE_INFO_BW_20
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_160MHZ
+status->bw = RATE_INFO_BW_160
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_5MHZ
+status->bw = RATE_INFO_BW_5
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_10MHZ
+status->bw = RATE_INFO_BW_10
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_VHT
+status->encoding = RX_ENC_VHT
@@
expression status;
@@
-status->enc_flags |= RX_ENC_FLAG_HT
+status->encoding = RX_ENC_HT
@@
expression status;
@@
-status.enc_flags |= RX_ENC_FLAG_VHT
+status.encoding = RX_ENC_VHT
@@
expression status;
@@
-status.enc_flags |= RX_ENC_FLAG_HT
+status.encoding = RX_ENC_HT
@@
expression status;
@@
-(status->enc_flags & RX_ENC_FLAG_HT)
+(status->encoding == RX_ENC_HT)
@@
expression status;
@@
-(status->enc_flags & RX_ENC_FLAG_VHT)
+(status->encoding == RX_ENC_VHT)
@@
expression status;
@@
-(status->enc_flags & RX_ENC_FLAG_5MHZ)
+(status->bw == RATE_INFO_BW_5)
@@
expression status;
@@
-(status->enc_flags & RX_ENC_FLAG_10MHZ)
+(status->bw == RATE_INFO_BW_10)
@@
expression status;
@@
-(status->enc_flags & RX_ENC_FLAG_40MHZ)
+(status->bw == RATE_INFO_BW_40)
@@
expression status;
@@
-(status->enc_flags & RX_ENC_FLAG_80MHZ)
+(status->bw == RATE_INFO_BW_80)
@@
expression status;
@@
-(status->enc_flags & RX_ENC_FLAG_160MHZ)
+(status->bw == RATE_INFO_BW_160)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In preparation for adding support for HE rates, clean up
the driver report encoding for rate/bandwidth reporting
on RX frames.
Much of this patch was done with the following spatch:
@@
expression status;
@@
-status->flag & (RX_FLAG_HT | RX_FLAG_VHT)
+status->enc_flags & (RX_ENC_FLAG_HT | RX_ENC_FLAG_VHT)
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_SHORTPRE
+status->enc_flags op RX_ENC_FLAG_SHORTPRE
@@
expression status;
@@
-status->flag & RX_FLAG_SHORTPRE
+status->enc_flags & RX_ENC_FLAG_SHORTPRE
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_HT
+status->enc_flags op RX_ENC_FLAG_HT
@@
expression status;
@@
-status->flag & RX_FLAG_HT
+status->enc_flags & RX_ENC_FLAG_HT
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_40MHZ
+status->enc_flags op RX_ENC_FLAG_40MHZ
@@
expression status;
@@
-status->flag & RX_FLAG_40MHZ
+status->enc_flags & RX_ENC_FLAG_40MHZ
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_SHORT_GI
+status->enc_flags op RX_ENC_FLAG_SHORT_GI
@@
expression status;
@@
-status->flag & RX_FLAG_SHORT_GI
+status->enc_flags & RX_ENC_FLAG_SHORT_GI
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_HT_GF
+status->enc_flags op RX_ENC_FLAG_HT_GF
@@
expression status;
@@
-status->flag & RX_FLAG_HT_GF
+status->enc_flags & RX_ENC_FLAG_HT_GF
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_VHT
+status->enc_flags op RX_ENC_FLAG_VHT
@@
expression status;
@@
-status->flag & RX_FLAG_VHT
+status->enc_flags & RX_ENC_FLAG_VHT
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_STBC_MASK
+status->enc_flags op RX_ENC_FLAG_STBC_MASK
@@
expression status;
@@
-status->flag & RX_FLAG_STBC_MASK
+status->enc_flags & RX_ENC_FLAG_STBC_MASK
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_LDPC
+status->enc_flags op RX_ENC_FLAG_LDPC
@@
expression status;
@@
-status->flag & RX_FLAG_LDPC
+status->enc_flags & RX_ENC_FLAG_LDPC
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_10MHZ
+status->enc_flags op RX_ENC_FLAG_10MHZ
@@
expression status;
@@
-status->flag & RX_FLAG_10MHZ
+status->enc_flags & RX_ENC_FLAG_10MHZ
@@
assignment operator op;
expression status;
@@
-status->flag op RX_FLAG_5MHZ
+status->enc_flags op RX_ENC_FLAG_5MHZ
@@
expression status;
@@
-status->flag & RX_FLAG_5MHZ
+status->enc_flags & RX_ENC_FLAG_5MHZ
@@
assignment operator op;
expression status;
@@
-status->vht_flag op RX_VHT_FLAG_80MHZ
+status->enc_flags op RX_ENC_FLAG_80MHZ
@@
expression status;
@@
-status->vht_flag & RX_VHT_FLAG_80MHZ
+status->enc_flags & RX_ENC_FLAG_80MHZ
@@
assignment operator op;
expression status;
@@
-status->vht_flag op RX_VHT_FLAG_160MHZ
+status->enc_flags op RX_ENC_FLAG_160MHZ
@@
expression status;
@@
-status->vht_flag & RX_VHT_FLAG_160MHZ
+status->enc_flags & RX_ENC_FLAG_160MHZ
@@
assignment operator op;
expression status;
@@
-status->vht_flag op RX_VHT_FLAG_BF
+status->enc_flags op RX_ENC_FLAG_BF
@@
expression status;
@@
-status->vht_flag & RX_VHT_FLAG_BF
+status->enc_flags & RX_ENC_FLAG_BF
@@
assignment operator op;
expression status, STBC;
@@
-status->flag op STBC << RX_FLAG_STBC_SHIFT
+status->enc_flags op STBC << RX_ENC_FLAG_STBC_SHIFT
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_SHORTPRE
+status.enc_flags op RX_ENC_FLAG_SHORTPRE
@@
expression status;
@@
-status.flag & RX_FLAG_SHORTPRE
+status.enc_flags & RX_ENC_FLAG_SHORTPRE
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_HT
+status.enc_flags op RX_ENC_FLAG_HT
@@
expression status;
@@
-status.flag & RX_FLAG_HT
+status.enc_flags & RX_ENC_FLAG_HT
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_40MHZ
+status.enc_flags op RX_ENC_FLAG_40MHZ
@@
expression status;
@@
-status.flag & RX_FLAG_40MHZ
+status.enc_flags & RX_ENC_FLAG_40MHZ
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_SHORT_GI
+status.enc_flags op RX_ENC_FLAG_SHORT_GI
@@
expression status;
@@
-status.flag & RX_FLAG_SHORT_GI
+status.enc_flags & RX_ENC_FLAG_SHORT_GI
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_HT_GF
+status.enc_flags op RX_ENC_FLAG_HT_GF
@@
expression status;
@@
-status.flag & RX_FLAG_HT_GF
+status.enc_flags & RX_ENC_FLAG_HT_GF
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_VHT
+status.enc_flags op RX_ENC_FLAG_VHT
@@
expression status;
@@
-status.flag & RX_FLAG_VHT
+status.enc_flags & RX_ENC_FLAG_VHT
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_STBC_MASK
+status.enc_flags op RX_ENC_FLAG_STBC_MASK
@@
expression status;
@@
-status.flag & RX_FLAG_STBC_MASK
+status.enc_flags & RX_ENC_FLAG_STBC_MASK
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_LDPC
+status.enc_flags op RX_ENC_FLAG_LDPC
@@
expression status;
@@
-status.flag & RX_FLAG_LDPC
+status.enc_flags & RX_ENC_FLAG_LDPC
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_10MHZ
+status.enc_flags op RX_ENC_FLAG_10MHZ
@@
expression status;
@@
-status.flag & RX_FLAG_10MHZ
+status.enc_flags & RX_ENC_FLAG_10MHZ
@@
assignment operator op;
expression status;
@@
-status.flag op RX_FLAG_5MHZ
+status.enc_flags op RX_ENC_FLAG_5MHZ
@@
expression status;
@@
-status.flag & RX_FLAG_5MHZ
+status.enc_flags & RX_ENC_FLAG_5MHZ
@@
assignment operator op;
expression status;
@@
-status.vht_flag op RX_VHT_FLAG_80MHZ
+status.enc_flags op RX_ENC_FLAG_80MHZ
@@
expression status;
@@
-status.vht_flag & RX_VHT_FLAG_80MHZ
+status.enc_flags & RX_ENC_FLAG_80MHZ
@@
assignment operator op;
expression status;
@@
-status.vht_flag op RX_VHT_FLAG_160MHZ
+status.enc_flags op RX_ENC_FLAG_160MHZ
@@
expression status;
@@
-status.vht_flag & RX_VHT_FLAG_160MHZ
+status.enc_flags & RX_ENC_FLAG_160MHZ
@@
assignment operator op;
expression status;
@@
-status.vht_flag op RX_VHT_FLAG_BF
+status.enc_flags op RX_ENC_FLAG_BF
@@
expression status;
@@
-status.vht_flag & RX_VHT_FLAG_BF
+status.enc_flags & RX_ENC_FLAG_BF
@@
assignment operator op;
expression status, STBC;
@@
-status.flag op STBC << RX_FLAG_STBC_SHIFT
+status.enc_flags op STBC << RX_ENC_FLAG_STBC_SHIFT
@@
@@
-RX_FLAG_STBC_SHIFT
+RX_ENC_FLAG_STBC_SHIFT
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
A break statement was obviously intended here.
Fixes: d69843e416d3 ("gpio: f7188x: Add F71889A GPIO support.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Add missing pinctrl binding these which would be used in
devicetree related files.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
omap_gpio_debounce() does not validate that the requested debounce
is within a range it can handle. Instead it lets the register value
wrap silently, and always returns success.
This can lead to all sorts of unexpected behavior, such as gpio_keys
asking for a too-long debounce, but getting a very short debounce in
practice.
Fix this by returning -EINVAL if the requested value does not fit into
the register field. If there is no debounce clock available at all,
return -ENOTSUPP.
Fixes: e85ec6c3047b ("gpio: omap: fix omap2_set_gpio_debounce")
Cc: <stable@vger.kernel.org> # 4.3+
Signed-off-by: David Rivshin <drivshin@allworx.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Add driver for the GPIO block in the ROHM BD9571MWV-W MFD PMIC.
This block is pretty trivial and supports setting GPIO direction
as Input/Output and in case of Output, supports setting value.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
In case of error, the function pinctrl_register() returns
ERR_PTR() not NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
According to Whiskey Cove PMIC spec, bit 7 of GPIOIRQ0_REG belongs to
battery IO. So we should skip this bit when checking for GPIO IRQ pending
status. Otherwise, wcove_gpio_irq_handler() might go into the infinite
loop until IRQ "pending" status becomes 0. This patch fixes this issue.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Dave found that a kdump kernel with KASLR enabled will reset to the BIOS
immediately if physical randomization failed to find a new position for
the kernel. A kernel with the 'nokaslr' option works in this case.
The reason is that KASLR will install a new page table for the identity
mapping, while it missed building it for the original kernel location
if KASLR physical randomization fails.
This only happens in the kexec/kdump kernel, because the identity mapping
has been built for kexec/kdump in the 1st kernel for the whole memory by
calling init_pgtable(). Here if physical randomizaiton fails, it won't build
the identity mapping for the original area of the kernel but change to a
new page table '_pgtable'. Then the kernel will triple fault immediately
caused by no identity mappings.
The normal kernel won't see this bug, because it comes here via startup_32()
and CR3 will be set to _pgtable already. In startup_32() the identity
mapping is built for the 0~4G area. In KASLR we just append to the existing
area instead of entirely overwriting it for on-demand identity mapping
building. So the identity mapping for the original area of kernel is still
there.
To fix it we just switch to the new identity mapping page table when physical
KASLR succeeds. Otherwise we keep the old page table unchanged just like
"nokaslr" does.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Garnier <thgarnie@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1493278940-5885-1-git-send-email-bhe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Lockdep complains about a possible deadlock between mount and unlink
(which is technically impossible), but fixing this improves possible
future multiple-backend support, and keeps locking in the right order.
The lockdep warning could be triggered by unlinking a file in the
pstore filesystem:
-> #1 (&sb->s_type->i_mutex_key#14){++++++}:
lock_acquire+0xc9/0x220
down_write+0x3f/0x70
pstore_mkfile+0x1f4/0x460
pstore_get_records+0x17a/0x320
pstore_fill_super+0xa4/0xc0
mount_single+0x89/0xb0
pstore_mount+0x13/0x20
mount_fs+0xf/0x90
vfs_kern_mount+0x66/0x170
do_mount+0x190/0xd50
SyS_mount+0x90/0xd0
entry_SYSCALL_64_fastpath+0x1c/0xb1
-> #0 (&psinfo->read_mutex){+.+.+.}:
__lock_acquire+0x1ac0/0x1bb0
lock_acquire+0xc9/0x220
__mutex_lock+0x6e/0x990
mutex_lock_nested+0x16/0x20
pstore_unlink+0x3f/0xa0
vfs_unlink+0xb5/0x190
do_unlinkat+0x24c/0x2a0
SyS_unlinkat+0x16/0x30
entry_SYSCALL_64_fastpath+0x1c/0xb1
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&sb->s_type->i_mutex_key#14);
lock(&psinfo->read_mutex);
lock(&sb->s_type->i_mutex_key#14);
lock(&psinfo->read_mutex);
Reported-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Namhyung Kim <namhyung@kernel.org>
|
|
This commit gets rid of some minor errors in Documentation/:
* cputopology.txt: drawes -> drawers
* debugging-via-ohci1394.txt: remove an unnecessary line break
* static-keys: statemnts -> statements
* zorro.txt: busses -> buses
Signed-off-by: Stan Drozd <drozdziak1@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
This commit fixes a repeated "the" in vfio-mediated-device.txt and reflows the
paragraph.
Signed-off-by: Stan Drozd <drozdziak1@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
This commit fixes a misspelled header name in the ioctl numbers list
Signed-off-by: Stan Drozd <drozdziak1@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
The HSI documentation was moved into Documentation/driver-api/hsi.rst in
commit 5e995786850e ("docs: split up serial-interfaces.rst"). Update the
corresponding file entry in MAINTAINERS.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
After commit c950fd6f201a kernel registers pstore write based on flag set.
Pstore write for powerpc is broken as flags(PSTORE_FLAGS_DMESG) is not set for
powerpc architecture. On panic, kernel doesn't write message to
/fs/pstore/dmesg*(Entry doesn't gets created at all).
This patch enables pstore write for powerpc architecture by setting
PSTORE_FLAGS_DMESG flag.
Fixes: c950fd6f201a ("pstore: Split pstore fragile flags")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Ankit Kumar <ankit@linux.vnet.ibm.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
|
|
Since the vmalloc code has been removed from write_pmsg() in the commit
"5bf6d1b pstore/pmsg: drop bounce buffer", remove the unused header
vmalloc.h.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
Kalle Valo says:
====================
wireless-drivers-next patches for 4.12
Few remaining patches for 4.12 submitted during the last week.
Major changes:
iwlwifi
* the firmware for 7265D and 3168 NICs is frozen at version 29
* more support for the upcoming A000 series
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
I/O errors triggered by multipathd incorrectly not enabling the no-flush
flag for DM_DEVICE_SUSPEND or DM_DEVICE_RESUME are hard to debug. Add
more logging to make it easier to debug this.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
No functional change but makes the code easier to read.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Instead of checking MPATHF_QUEUE_IF_NO_PATH,
MPATHF_SAVED_QUEUE_IF_NO_PATH and the no_flush flag to decide whether
or not to push back a request (or bio) if there are no paths available,
only clear MPATHF_QUEUE_IF_NO_PATH in queue_if_no_path() if no_flush has
not been set. The result is that only a single bit has to be tested in
the hot path to decide whether or not a request must be pushed back and
also that m->lock does not have to be taken in the hot path.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Introduce an enumeration type for the queue mode. This patch does
not change any functionality but makes the DM code easier to read.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Verify at runtime that __pg_init_all_paths() is called with
multipath.lock held if lockdep is enabled.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Ensure that the assumptions about the caller holding suspend_lock
are checked at runtime if lockdep is enabled.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
The 'cache_size' argument of dm_block_manager_create() has never been
used. Remove it along with the definitions of the constants passed as
the 'cache_size' argument.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Otherwise the request-based DM blk-mq request_queue will be put into
service without being properly exported via sysfs.
Cc: stable@vger.kernel.org
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
Requeuing a request immediately while path initialization is ongoing
causes high CPU usage, something that is undesired. Hence delay
requeuing while path initialization is in progress.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
If blk_get_request() fails, check whether the failure is due to a path
being removed. If that is the case, fail the path by triggering a call
to fail_path(). This avoids that the following scenario can be
encountered while removing paths:
* CPU usage of a kworker thread jumps to 100%.
* Removing the DM device becomes impossible.
Delay requeueing if blk_get_request() returns -EBUSY or -EWOULDBLOCK,
and the queue is not dying, because in these cases immediate requeuing
is inappropriate.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
In new barrier codes, raise_barrier waits if conf->nr_pending[idx] is not zero.
After all the conditions are true, the resync request can go on be handled. But
it adds conf->nr_pending[idx] again. The next resync request hit the same bucket
idx need to wait the resync request which is submitted before. The performance
of resync/recovery is degraded.
So we should use a new variable to count sync requests which are in flight.
I did a simple test:
1. Without the patch, create a raid1 with two disks. The resync speed:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.00 0.00 166.00 0.00 10.38 0.00 128.00 0.03 0.20 0.20 0.00 0.19 3.20
sdc 0.00 0.00 0.00 166.00 0.00 10.38 128.00 0.96 5.77 0.00 5.77 5.75 95.50
2. With the patch, the result is:
sdb 2214.00 0.00 766.00 0.00 185.69 0.00 496.46 2.80 3.66 3.66 0.00 1.03 79.10
sdc 0.00 2205.00 0.00 769.00 0.00 186.44 496.52 5.25 6.84 0.00 6.84 1.30 100.10
Suggested-by: Shaohua Li <shli@kernel.org>
Signed-off-by: Xiao Ni <xni@redhat.com>
Acked-by: Coly Li <colyli@suse.de>
Signed-off-by: Shaohua Li <shli@fb.com>
|
|
activate_path() is renamed to activate_path_work() which now calls
activate_or_offline_path(). activate_or_offline_path() will be used
by the next commit.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|