Re: [PATCH v2] staging: rtl8723bs: core: fix line over 80 characters warning
Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC PATCH 22/68] vfs: Convert binderfs to use the new mount API
Convert the binderfs filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells
Reviewed-by: Christian Brauner
cc: Greg Kroah-Hartman
cc: "Arve Hjønnevåg"
cc: Todd Kjos
cc: Martijn Coenen
cc: Joel Fernandes
cc: de...@driverdev.osuosl.org
---
drivers/android/binderfs.c | 173
1 file changed, 96 insertions(+), 77 deletions(-)
diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index e773f45d19d9..0a16ecc9594f 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -18,7 +18,8 @@
#include
#include
#include
-#include
+#include
+#include
#include
#include
#include
@@ -48,22 +49,18 @@ static dev_t binderfs_dev;
static DEFINE_MUTEX(binderfs_minors_mutex);
static DEFINE_IDA(binderfs_minors);
-/**
- * binderfs_mount_opts - mount options for binderfs
- * @max: maximum number of allocatable binderfs binder devices
- */
-struct binderfs_mount_opts {
- int max;
-};
-
enum {
Opt_max,
- Opt_err
};
-static const match_table_t tokens = {
- { Opt_max, "max=%d" },
- { Opt_err, NULL }
+static const struct fs_parameter_spec binderfs_param_specs[] = {
+ fsparam_s32 ("max", Opt_max),
+ {}
+};
+
+static const struct fs_parameter_description binderfs_fs_parameters = {
+ .name = "binderfs",
+ .specs = binderfs_param_specs,
};
/**
@@ -75,7 +72,7 @@ static const match_table_t tokens = {
* created.
* @root_gid: gid that needs to be used when a new binder device is
* created.
- * @mount_opts: The mount options in use.
+ * @max: Maximum number of allocatable binderfs binder devices.
* @device_count: The current number of allocated binder devices.
*/
struct binderfs_info {
@@ -83,7 +80,7 @@ struct binderfs_info {
struct dentry *control_dentry;
kuid_t root_uid;
kgid_t root_gid;
- struct binderfs_mount_opts mount_opts;
+ int max;
int device_count;
};
@@ -138,7 +135,7 @@ static int binderfs_binder_device_create(struct inode
*ref_inode,
/* Reserve new minor number for the new device. */
mutex_lock(_minors_mutex);
- if (++info->device_count <= info->mount_opts.max)
+ if (++info->device_count <= info->max)
minor = ida_alloc_max(_minors,
use_reserve ? BINDERFS_MAX_MINOR :
BINDERFS_MAX_MINOR_CAPPED,
@@ -285,46 +282,36 @@ static void binderfs_evict_inode(struct inode *inode)
}
/**
- * binderfs_parse_mount_opts - parse binderfs mount options
- * @data: options to set (can be NULL in which case defaults are used)
+ * binderfs_parse_param - parse a binderfs mount option
+ * @fc: The context to be configured
+ * @param: The parameter to apply
*/
-static int binderfs_parse_mount_opts(char *data,
-struct binderfs_mount_opts *opts)
+static int binderfs_parse_param(struct fs_context *fc, struct fs_parameter
*param)
{
- char *p;
- opts->max = BINDERFS_MAX_MINOR;
-
- while ((p = strsep(, ",")) != NULL) {
- substring_t args[MAX_OPT_ARGS];
- int token;
- int max_devices;
-
- if (!*p)
- continue;
-
- token = match_token(p, tokens, args);
- switch (token) {
- case Opt_max:
- if (match_int([0], _devices) ||
- (max_devices < 0 ||
-(max_devices > BINDERFS_MAX_MINOR)))
- return -EINVAL;
-
- opts->max = max_devices;
- break;
- default:
- pr_err("Invalid mount options\n");
- return -EINVAL;
- }
+ struct fs_parse_result result;
+ struct binderfs_info *info = fc->s_fs_info;
+ int opt;
+
+ opt = fs_parse(fc, _fs_parameters, param, );
+ if (opt < 0)
+ return opt;
+
+ switch (opt) {
+ case Opt_max:
+ info->max = result.int_32;
+ break;
}
return 0;
}
-static int binderfs_remount(struct super_block *sb, int *flags, char *data)
+static int binderfs_reconfigure(struct fs_context *fc)
{
- struct binderfs_info *info = sb->s_fs_info;
- return binderfs_parse_mount_opts(data, >mount_opts);
+ struct binderfs_info *info = fc->root->d_sb->s_fs_info;
+ struct binderfs_info *cfg = fc->s_fs_info;
+
+ info->max = cfg->max;
+ return 0;
}
static int
[PATCH v2] staging: rtl8192u: ieee80211: ieee80211_wx: add space before open brace
Fix checkpatch error "ERROR: space required before the open brace
'{'" in ieee80211_wx.c.
Signed-off-by: Julius Hemanth Pitti
---
Changes in v2:
- Corrected commit message typo
drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index fa59c71..ebcc642 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -195,7 +195,7 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
if (iwe.u.data.length)
start = iwe_stream_add_point(info, start, stop, , custom);
- if (ieee->wpa_enabled && network->wpa_ie_len){
+ if (ieee->wpa_enabled && network->wpa_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
// printk("WPA IE\n");
u8 *p = buf;
@@ -210,7 +210,7 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
start = iwe_stream_add_point(info, start, stop, , buf);
}
- if (ieee->wpa_enabled && network->rsn_ie_len){
+ if (ieee->wpa_enabled && network->rsn_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
u8 *p = buf;
@@ -766,15 +766,13 @@ int ieee80211_wx_set_auth(struct ieee80211_device *ieee,
case IW_AUTH_80211_AUTH_ALG:
//printk("==>%s():data->value is
%d\n",__func__,data->value);
// ieee->open_wep = (data->value_AUTH_ALG_OPEN_SYSTEM)?1:0;
- if(data->value & IW_AUTH_ALG_SHARED_KEY){
+ if (data->value & IW_AUTH_ALG_SHARED_KEY) {
ieee->open_wep = 0;
ieee->auth_mode = 1;
- }
- else if(data->value & IW_AUTH_ALG_OPEN_SYSTEM){
+ } else if (data->value & IW_AUTH_ALG_OPEN_SYSTEM) {
ieee->open_wep = 1;
ieee->auth_mode = 0;
- }
- else if(data->value & IW_AUTH_ALG_LEAP){
+ } else if (data->value & IW_AUTH_ALG_LEAP) {
ieee->open_wep = 1;
ieee->auth_mode = 2;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u: ieee80211: ieee80211_wx: add space before open brace
On Wed, Mar 27, 2019 at 02:53:35PM -0700, Julius Hemanth Pitti wrote:
> Fix checkpatch error "ERROR: that open brace { should be on
> the previous line" in ieee80211_wx.c.
>
> Signed-off-by: Julius Hemanth Pitti
> ---
> drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> index fa59c71..ebcc642 100644
> --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
> @@ -195,7 +195,7 @@ static inline char *rtl819x_translate_scan(struct
> ieee80211_device *ieee,
> if (iwe.u.data.length)
> start = iwe_stream_add_point(info, start, stop, , custom);
>
> - if (ieee->wpa_enabled && network->wpa_ie_len){
> + if (ieee->wpa_enabled && network->wpa_ie_len) {
> char buf[MAX_WPA_IE_LEN * 2 + 30];
> // printk("WPA IE\n");
> u8 *p = buf;
> @@ -210,7 +210,7 @@ static inline char *rtl819x_translate_scan(struct
> ieee80211_device *ieee,
> start = iwe_stream_add_point(info, start, stop, , buf);
> }
>
> - if (ieee->wpa_enabled && network->rsn_ie_len){
> + if (ieee->wpa_enabled && network->rsn_ie_len) {
> char buf[MAX_WPA_IE_LEN * 2 + 30];
>
> u8 *p = buf;
> @@ -766,15 +766,13 @@ int ieee80211_wx_set_auth(struct ieee80211_device *ieee,
> case IW_AUTH_80211_AUTH_ALG:
> //printk("==>%s():data->value is
> %d\n",__func__,data->value);
> // ieee->open_wep = (data->value_AUTH_ALG_OPEN_SYSTEM)?1:0;
> - if(data->value & IW_AUTH_ALG_SHARED_KEY){
> + if (data->value & IW_AUTH_ALG_SHARED_KEY) {
> ieee->open_wep = 0;
> ieee->auth_mode = 1;
> - }
> - else if(data->value & IW_AUTH_ALG_OPEN_SYSTEM){
> + } else if (data->value & IW_AUTH_ALG_OPEN_SYSTEM) {
> ieee->open_wep = 1;
> ieee->auth_mode = 0;
> - }
> - else if(data->value & IW_AUTH_ALG_LEAP){
> + } else if (data->value & IW_AUTH_ALG_LEAP) {
> ieee->open_wep = 1;
> ieee->auth_mode = 2;
> }
> --
> 2.7.4
>
Sorry for typo in commit message, please ignore this patch.
Will send updated one as v2.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192u: ieee80211: ieee80211_wx: add space before open brace
Fix checkpatch error "ERROR: that open brace { should be on
the previous line" in ieee80211_wx.c.
Signed-off-by: Julius Hemanth Pitti
---
drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index fa59c71..ebcc642 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -195,7 +195,7 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
if (iwe.u.data.length)
start = iwe_stream_add_point(info, start, stop, , custom);
- if (ieee->wpa_enabled && network->wpa_ie_len){
+ if (ieee->wpa_enabled && network->wpa_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
// printk("WPA IE\n");
u8 *p = buf;
@@ -210,7 +210,7 @@ static inline char *rtl819x_translate_scan(struct
ieee80211_device *ieee,
start = iwe_stream_add_point(info, start, stop, , buf);
}
- if (ieee->wpa_enabled && network->rsn_ie_len){
+ if (ieee->wpa_enabled && network->rsn_ie_len) {
char buf[MAX_WPA_IE_LEN * 2 + 30];
u8 *p = buf;
@@ -766,15 +766,13 @@ int ieee80211_wx_set_auth(struct ieee80211_device *ieee,
case IW_AUTH_80211_AUTH_ALG:
//printk("==>%s():data->value is
%d\n",__func__,data->value);
// ieee->open_wep = (data->value_AUTH_ALG_OPEN_SYSTEM)?1:0;
- if(data->value & IW_AUTH_ALG_SHARED_KEY){
+ if (data->value & IW_AUTH_ALG_SHARED_KEY) {
ieee->open_wep = 0;
ieee->auth_mode = 1;
- }
- else if(data->value & IW_AUTH_ALG_OPEN_SYSTEM){
+ } else if (data->value & IW_AUTH_ALG_OPEN_SYSTEM) {
ieee->open_wep = 1;
ieee->auth_mode = 0;
- }
- else if(data->value & IW_AUTH_ALG_LEAP){
+ } else if (data->value & IW_AUTH_ALG_LEAP) {
ieee->open_wep = 1;
ieee->auth_mode = 2;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wilc1000: assign scan result callback before starting the scan
From: Adham Abozaeid When scan is triggered, sometimes scan results are received before the scan result callback is assigned, causing the recieved results to be ignored. Signed-off-by: Adham Abozaeid --- drivers/staging/wilc1000/host_interface.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index 91ea16a6ae2e..e1a35bb426f9 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -313,6 +313,9 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 scan_type, wid_list[index].val = (s8 *)_source; index++; + hif_drv->usr_scan_req.scan_result = scan_result_fn; + hif_drv->usr_scan_req.arg = user_arg; + result = wilc_send_config_pkt(vif, WILC_SET_CFG, wid_list, index, wilc_get_vif_idx(vif)); @@ -321,8 +324,6 @@ int wilc_scan(struct wilc_vif *vif, u8 scan_source, u8 scan_type, goto error; } - hif_drv->usr_scan_req.scan_result = scan_result_fn; - hif_drv->usr_scan_req.arg = user_arg; hif_drv->scan_timer_vif = vif; mod_timer(_drv->scan_timer, jiffies + msecs_to_jiffies(WILC_HIF_SCAN_TIMEOUT_MS)); -- 2.17.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vt6655: Remove vif check from vnt_interrupt
A check for vif is made in vnt_interrupt_work.
There is a small chance of leaving interrupt disabled while vif
is NULL and the work hasn't been scheduled.
Signed-off-by: Malcolm Priestley
CC: sta...@vger.kernel.org # v4.2+
---
drivers/staging/vt6655/device_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/vt6655/device_main.c
b/drivers/staging/vt6655/device_main.c
index 83f1a1cf9182..c6bb4aaf9bd0 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1137,8 +1137,7 @@ static irqreturn_t vnt_interrupt(int irq, void *arg)
{
struct vnt_private *priv = arg;
- if (priv->vif)
- schedule_work(>interrupt_work);
+ schedule_work(>interrupt_work);
MACvIntDisable(priv->PortOffset);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] driver : staging : ion: optimization for decreasing memory fragmentaion
On Wed, Mar 20, 2019 at 02:38:23PM +0800, Zhaoyang Huang wrote: > From: Zhaoyang Huang > > Two action for this patch: > 1. set a batch size for system heap's shrinker, which can have it buffer > reasonable page blocks in pool for future allocation. > 2. reverse the order sequence when free page blocks, the purpose is also > to have system heap keep as more big blocks as it can. > > By testing on an android system with 2G RAM, the changes with setting > batch = 48MB can help reduce the fragmentation obviously and improve > big block allocation speed for 15%. > > Signed-off-by: Zhaoyang Huang > --- > drivers/staging/android/ion/ion_heap.c| 16 +++- > drivers/staging/android/ion/ion_system_heap.c | 2 +- > 2 files changed, 16 insertions(+), 2 deletions(-) What changed from v1? Always put that below the --- line as the documentation asks you to. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: emxx_udc: emxx_udc: Fixed a coding style error
On Tue, Mar 26, 2019 at 09:47:23AM -0400, Will Cunningham wrote: > Removed unnecessary parentheses. > > Signed-off-by: Will Cunningham > --- > drivers/staging/emxx_udc/emxx_udc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Someone else sent this patch right before you did, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging/android: use multiple futex wait queues
On Fri, Feb 15, 2019 at 08:44:01AM +0100, Hugo Lefeuvre wrote: > Use multiple per-offset wait queues instead of one big wait queue per > region. > > Signed-off-by: Hugo Lefeuvre > --- > Changes in v2: > - dereference the it pointer instead of wait_queue (which is not set > yet) in handle_vsoc_cond_wait() How did you test this change? This code needs a lot of testing by someone before I can take it. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: rtl8723bs: core: fix line over 80 characters warning
Checkpatch.pl complains that these lines are over 80 characters. Use the
"psecuritypriv" pointer for consistency, remove unnecessary parantheses
and fix the alignment.
This patch just cleans up a condition, it doesn't affect runtime.
Signed-off-by: Anirudh Rayabharam
---
v2: Made the commit message clearer, removed unnecessary parantheses and fixed
the alignment as suggested by Dan Carpenter
drivers/staging/rtl8723bs/core/rtw_ap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index 18fabf5ff44b..8062b7f36de2 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -2336,8 +2336,8 @@ void rtw_ap_restore_network(struct adapter *padapter)
Update_RA_Entry(padapter, psta);
/* pairwise key */
/* per sta pairwise key and settings */
- if ((padapter->securitypriv.dot11PrivacyAlgrthm ==
_TKIP_) ||
- (padapter->securitypriv.dot11PrivacyAlgrthm ==
_AES_)) {
+ if (psecuritypriv->dot11PrivacyAlgrthm == _TKIP_ ||
+ psecuritypriv->dot11PrivacyAlgrthm == _AES_) {
rtw_setstakey_cmd(padapter, psta, true, false);
}
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.19 131/192] staging: spi: mt7621: Add return code check on device_reset()
From: Stefan Roese
[ Upstream commit 46c337872f34bc6387b0c29a4964f562c70139e3 ]
This patch adds a return code check on device_reset() and removes the
compile warning.
Signed-off-by: Stefan Roese
Cc: Mark Brown
Cc: Sankalp Negi
Cc: Chuanhong Guo
Cc: John Crispin
Reviewed-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/mt7621-spi/spi-mt7621.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
b/drivers/staging/mt7621-spi/spi-mt7621.c
index d045b5568e0f..578aa6824ad3 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -429,6 +429,7 @@ static int mt7621_spi_probe(struct platform_device *pdev)
int status = 0;
struct clk *clk;
struct mt7621_spi_ops *ops;
+ int ret;
match = of_match_device(mt7621_spi_match, >dev);
if (!match)
@@ -476,7 +477,11 @@ static int mt7621_spi_probe(struct platform_device *pdev)
rs->pending_write = 0;
dev_info(>dev, "sys_freq: %u\n", rs->sys_freq);
- device_reset(>dev);
+ ret = device_reset(>dev);
+ if (ret) {
+ dev_err(>dev, "SPI reset failed!\n");
+ return ret;
+ }
mt7621_spi_reset(rs, 0);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.19 019/192] x86/hyperv: Fix kernel panic when kexec on HyperV
From: Kairui Song
[ Upstream commit 179fb36abb097976997f50733d5b122a29158cba ]
After commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments"),
kexec fails with a kernel panic:
kexec_core: Starting new kernel
BUG: unable to handle kernel NULL pointer dereference at
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS
Hyper-V UEFI Release v3.0 03/02/2018
RIP: 0010:0xc901d000
Call Trace:
? __send_ipi_mask+0x1c6/0x2d0
? hv_send_ipi_mask_allbutself+0x6d/0xb0
? mp_save_irq+0x70/0x70
? __ioapic_read_entry+0x32/0x50
? ioapic_read_entry+0x39/0x50
? clear_IO_APIC_pin+0xb8/0x110
? native_stop_other_cpus+0x6e/0x170
? native_machine_shutdown+0x22/0x40
? kernel_kexec+0x136/0x156
That happens if hypercall based IPIs are used because the hypercall page is
reset very early upon kexec reboot, but kexec sends IPIs to stop CPUs,
which invokes the hypercall and dereferences the unusable page.
To fix his, reset hv_hypercall_pg to NULL before the page is reset to avoid
any misuse, IPI sending will fall back to the non hypercall based
method. This only happens on kexec / kdump so just setting the pointer to
NULL is good enough.
Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song
Signed-off-by: Thomas Gleixner
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Sasha Levin
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Vitaly Kuznetsov
Cc: Dave Young
Cc: de...@linuxdriverproject.org
Link: https://lkml.kernel.org/r/20190306111827.14131-1-kas...@redhat.com
Signed-off-by: Sasha Levin
---
arch/x86/hyperv/hv_init.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 20c876c7c5bf..87abd5145cc9 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -387,6 +387,13 @@ void hyperv_cleanup(void)
/* Reset our OS id */
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
+ /*
+* Reset hypercall page reference before reset the page,
+* let hypercall operations fail safely rather than
+* panic the kernel for using invalid hypercall page
+*/
+ hv_hypercall_pg = NULL;
+
/* Reset the hypercall page */
hypercall_msr.as_uint64 = 0;
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.0 253/262] staging: iio: adt7316: fix dac_bits assignment
From: Jeremy Fertic
[ Upstream commit e9de475723de5bf207a5b7b88bdca863393e42c8 ]
The value of dac_bits is used in adt7316_show_DAC() and adt7316_store_DAC(),
and it should be either 8, 10, or 12 bits depending on the device in use. The
driver currently only assigns a value to dac_bits in
adt7316_store_da_high_resolution(). The purpose of the dac high resolution
option is not to change dac resolution for normal operation. Instead, it
is specific to an optional feature where one or two of the four dacs can
be set to output voltage proportional to temperature. If the user chooses
to set dac a and/or dac b to output voltage proportional to temperature,
the da_high_resolution attribute can optionally be enabled to use 10 bit
resolution rather than the default 8 bits. This is only available on the
10 and 12 bit dac devices. If the user attempts to read or write dacs a
or b under these settings, the driver's current behaviour is to return an
error. Dacs c and d continue to operate normally under these conditions.
With the above in mind, remove the dac_bits assignments from this function
since the value of dac_bits as used in the driver is not dependent on this
dac high resolution option.
Since the dac_bits assignments discussed above are currently the only ones
in this driver, the default value of dac_bits is 0. This results in incorrect
calculations when the dacs are read or written in adt7316_show_DAC() and
adt7316_store_DAC(). To correct this, assign a value to dac_bits in
adt7316_probe() to ensure correct operation as soon as the device is
registered and available to userspace.
Fixes: 35f6b6b86ede ("staging: iio: new ADT7316/7/8 and ADT7516/7/9 driver")
Signed-off-by: Jeremy Fertic
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
drivers/staging/iio/addac/adt7316.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/iio/addac/adt7316.c
b/drivers/staging/iio/addac/adt7316.c
index dc93e85808e0..7839d869d25d 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -651,17 +651,10 @@ static ssize_t adt7316_store_da_high_resolution(struct
device *dev,
u8 config3;
int ret;
- chip->dac_bits = 8;
-
- if (buf[0] == '1') {
+ if (buf[0] == '1')
config3 = chip->config3 | ADT7316_DA_HIGH_RESOLUTION;
- if (chip->id == ID_ADT7316 || chip->id == ID_ADT7516)
- chip->dac_bits = 12;
- else if (chip->id == ID_ADT7317 || chip->id == ID_ADT7517)
- chip->dac_bits = 10;
- } else {
+ else
config3 = chip->config3 & (~ADT7316_DA_HIGH_RESOLUTION);
- }
ret = chip->bus.write(chip->bus.client, ADT7316_CONFIG3, config3);
if (ret)
@@ -2123,6 +2116,13 @@ int adt7316_probe(struct device *dev, struct adt7316_bus
*bus,
else
return -ENODEV;
+ if (chip->id == ID_ADT7316 || chip->id == ID_ADT7516)
+ chip->dac_bits = 12;
+ else if (chip->id == ID_ADT7317 || chip->id == ID_ADT7517)
+ chip->dac_bits = 10;
+ else
+ chip->dac_bits = 8;
+
chip->ldac_pin = devm_gpiod_get_optional(dev, "adi,ldac",
GPIOD_OUT_LOW);
if (IS_ERR(chip->ldac_pin)) {
ret = PTR_ERR(chip->ldac_pin);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.0 181/262] staging: spi: mt7621: Add return code check on device_reset()
From: Stefan Roese
[ Upstream commit 46c337872f34bc6387b0c29a4964f562c70139e3 ]
This patch adds a return code check on device_reset() and removes the
compile warning.
Signed-off-by: Stefan Roese
Cc: Mark Brown
Cc: Sankalp Negi
Cc: Chuanhong Guo
Cc: John Crispin
Reviewed-by: NeilBrown
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/mt7621-spi/spi-mt7621.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
b/drivers/staging/mt7621-spi/spi-mt7621.c
index 513b6e79b985..e1f50efd0922 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -330,6 +330,7 @@ static int mt7621_spi_probe(struct platform_device *pdev)
int status = 0;
struct clk *clk;
struct mt7621_spi_ops *ops;
+ int ret;
match = of_match_device(mt7621_spi_match, >dev);
if (!match)
@@ -377,7 +378,11 @@ static int mt7621_spi_probe(struct platform_device *pdev)
rs->pending_write = 0;
dev_info(>dev, "sys_freq: %u\n", rs->sys_freq);
- device_reset(>dev);
+ ret = device_reset(>dev);
+ if (ret) {
+ dev_err(>dev, "SPI reset failed!\n");
+ return ret;
+ }
mt7621_spi_reset(rs);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.0 126/262] media: rockchip/vpu: Correct return type for mem2mem buffer helpers
From: Ezequiel Garcia
[ Upstream commit 29701c3612fa025d5e8dc64c7a4ae8dc4763912e ]
Fix the assigned type of mem2mem buffer handling API.
Namely, these functions:
v4l2_m2m_next_buf
v4l2_m2m_last_buf
v4l2_m2m_buf_remove
v4l2_m2m_next_src_buf
v4l2_m2m_next_dst_buf
v4l2_m2m_last_src_buf
v4l2_m2m_last_dst_buf
v4l2_m2m_src_buf_remove
v4l2_m2m_dst_buf_remove
return a struct vb2_v4l2_buffer, and not a struct vb2_buffer.
Fixing this is necessary to fix the mem2mem buffer handling API,
changing the return to the correct struct vb2_v4l2_buffer instead
of a void pointer.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 6 +++---
drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
index 5282236d1bb1..06daea66fb49 100644
--- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
@@ -80,7 +80,7 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
{
struct rockchip_vpu_dev *vpu = ctx->dev;
- struct vb2_buffer *src_buf, *dst_buf;
+ struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct rockchip_vpu_jpeg_ctx jpeg_ctx;
u32 reg;
@@ -88,7 +88,7 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
memset(_ctx, 0, sizeof(jpeg_ctx));
- jpeg_ctx.buffer = vb2_plane_vaddr(dst_buf, 0);
+ jpeg_ctx.buffer = vb2_plane_vaddr(_buf->vb2_buf, 0);
jpeg_ctx.width = ctx->dst_fmt.width;
jpeg_ctx.height = ctx->dst_fmt.height;
jpeg_ctx.quality = ctx->jpeg_quality;
@@ -99,7 +99,7 @@ void rk3288_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
VEPU_REG_ENC_CTRL);
rk3288_vpu_set_src_img_ctrl(vpu, ctx);
- rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
+ rk3288_vpu_jpeg_enc_set_buffers(vpu, ctx, _buf->vb2_buf);
rk3288_vpu_jpeg_enc_set_qtable(vpu,
rockchip_vpu_jpeg_get_qtable(_ctx,
0),
rockchip_vpu_jpeg_get_qtable(_ctx,
1));
diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
index dbc86d95fe3b..3d438797692e 100644
--- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
@@ -111,7 +111,7 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev *vpu,
void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
{
struct rockchip_vpu_dev *vpu = ctx->dev;
- struct vb2_buffer *src_buf, *dst_buf;
+ struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct rockchip_vpu_jpeg_ctx jpeg_ctx;
u32 reg;
@@ -119,7 +119,7 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
memset(_ctx, 0, sizeof(jpeg_ctx));
- jpeg_ctx.buffer = vb2_plane_vaddr(dst_buf, 0);
+ jpeg_ctx.buffer = vb2_plane_vaddr(_buf->vb2_buf, 0);
jpeg_ctx.width = ctx->dst_fmt.width;
jpeg_ctx.height = ctx->dst_fmt.height;
jpeg_ctx.quality = ctx->jpeg_quality;
@@ -130,7 +130,7 @@ void rk3399_vpu_jpeg_enc_run(struct rockchip_vpu_ctx *ctx)
VEPU_REG_ENCODE_START);
rk3399_vpu_set_src_img_ctrl(vpu, ctx);
- rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, src_buf);
+ rk3399_vpu_jpeg_enc_set_buffers(vpu, ctx, _buf->vb2_buf);
rk3399_vpu_jpeg_enc_set_qtable(vpu,
rockchip_vpu_jpeg_get_qtable(_ctx,
0),
rockchip_vpu_jpeg_get_qtable(_ctx,
1));
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 5.0 028/262] x86/hyperv: Fix kernel panic when kexec on HyperV
From: Kairui Song
[ Upstream commit 179fb36abb097976997f50733d5b122a29158cba ]
After commit 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments"),
kexec fails with a kernel panic:
kexec_core: Starting new kernel
BUG: unable to handle kernel NULL pointer dereference at
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS
Hyper-V UEFI Release v3.0 03/02/2018
RIP: 0010:0xc901d000
Call Trace:
? __send_ipi_mask+0x1c6/0x2d0
? hv_send_ipi_mask_allbutself+0x6d/0xb0
? mp_save_irq+0x70/0x70
? __ioapic_read_entry+0x32/0x50
? ioapic_read_entry+0x39/0x50
? clear_IO_APIC_pin+0xb8/0x110
? native_stop_other_cpus+0x6e/0x170
? native_machine_shutdown+0x22/0x40
? kernel_kexec+0x136/0x156
That happens if hypercall based IPIs are used because the hypercall page is
reset very early upon kexec reboot, but kexec sends IPIs to stop CPUs,
which invokes the hypercall and dereferences the unusable page.
To fix his, reset hv_hypercall_pg to NULL before the page is reset to avoid
any misuse, IPI sending will fall back to the non hypercall based
method. This only happens on kexec / kdump so just setting the pointer to
NULL is good enough.
Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Signed-off-by: Kairui Song
Signed-off-by: Thomas Gleixner
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Stephen Hemminger
Cc: Sasha Levin
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Vitaly Kuznetsov
Cc: Dave Young
Cc: de...@linuxdriverproject.org
Link: https://lkml.kernel.org/r/20190306111827.14131-1-kas...@redhat.com
Signed-off-by: Sasha Levin
---
arch/x86/hyperv/hv_init.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 7abb09e2eeb8..d3f42b6bbdac 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -406,6 +406,13 @@ void hyperv_cleanup(void)
/* Reset our OS id */
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
+ /*
+* Reset hypercall page reference before reset the page,
+* let hypercall operations fail safely rather than
+* panic the kernel for using invalid hypercall page
+*/
+ hv_hypercall_pg = NULL;
+
/* Reset the hypercall page */
hypercall_msr.as_uint64 = 0;
wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFCv2 0/4] mm/memory_hotplug: Introduce memory block types
On 20.12.18 14:08, Michal Hocko wrote:
> On Thu 20-12-18 13:58:16, David Hildenbrand wrote:
>> On 30.11.18 18:59, David Hildenbrand wrote:
>>> This is the second approach, introducing more meaningful memory block
>>> types and not changing online behavior in the kernel. It is based on
>>> latest linux-next.
>>>
>>> As we found out during dicussion, user space should always handle onlining
>>> of memory, in any case. However in order to make smart decisions in user
>>> space about if and how to online memory, we have to export more information
>>> about memory blocks. This way, we can formulate rules in user space.
>>>
>>> One such information is the type of memory block we are talking about.
>>> This helps to answer some questions like:
>>> - Does this memory block belong to a DIMM?
>>> - Can this DIMM theoretically ever be unplugged again?
>>> - Was this memory added by a balloon driver that will rely on balloon
>>> inflation to remove chunks of that memory again? Which zone is advised?
>>> - Is this special standby memory on s390x that is usually not automatically
>>> onlined?
>>>
>>> And in short it helps to answer to some extend (excluding zone imbalances)
>>> - Should I online this memory block?
>>> - To which zone should I online this memory block?
>>> ... of course special use cases will result in different anwers. But that's
>>> why user space has control of onlining memory.
>>>
>>> More details can be found in Patch 1 and Patch 3.
>>> Tested on x86 with hotplugged DIMMs. Cross-compiled for PPC and s390x.
>>>
>>>
>>> Example:
>>> $ udevadm info -q all -a /sys/devices/system/memory/memory0
>>> KERNEL=="memory0"
>>> SUBSYSTEM=="memory"
>>> DRIVER==""
>>> ATTR{online}=="1"
>>> ATTR{phys_device}=="0"
>>> ATTR{phys_index}==""
>>> ATTR{removable}=="0"
>>> ATTR{state}=="online"
>>> ATTR{type}=="boot"
>>> ATTR{valid_zones}=="none"
>>> $ udevadm info -q all -a /sys/devices/system/memory/memory90
>>> KERNEL=="memory90"
>>> SUBSYSTEM=="memory"
>>> DRIVER==""
>>> ATTR{online}=="1"
>>> ATTR{phys_device}=="0"
>>> ATTR{phys_index}=="005a"
>>> ATTR{removable}=="1"
>>> ATTR{state}=="online"
>>> ATTR{type}=="dimm"
>>> ATTR{valid_zones}=="Normal"
>>>
>>>
>>> RFC -> RFCv2:
>>> - Now also taking care of PPC (somehow missed it :/ )
>>> - Split the series up to some degree (some ideas on how to split up patch 3
>>> would be very welcome)
>>> - Introduce more memory block types. Turns out abstracting too much was
>>> rather confusing and not helpful. Properly document them.
>>>
>>> Notes:
>>> - I wanted to convert the enum of types into a named enum but this
>>> provoked all kinds of different errors. For now, I am doing it just like
>>> the other types (e.g. online_type) we are using in that context.
>>> - The "removable" property should never have been named like that. It
>>> should have been "offlinable". Can we still rename that? E.g. boot memory
>>> is sometimes marked as removable ...
>>>
>>
>>
>> Any feedback regarding the suggested block types would be very much
>> appreciated!
>
> I still do not like this much to be honest. I just didn't get to think
> through this properly. My fear is that this is conflating an actual API
> with the current implementation and as such will cause problems in
> future. But I haven't really looked into your patches closely so I might
> be wrong. Anyway I won't be able to look into it by the end of year.
>
So I started to think about this again, and I guess somehow exposing an
identification of the device driver that added the memory section could
be sufficient.
E.g. "hyperv", "xen", "acpi", "sclp", "virtio-mem" ...
Via separate device driver interfaces, other information about the
memory could be exposed. (e.g. for ACPI: which memory devices belong to
one physical device). So stuff would not have to centered around
/sys/devices/system/memory/ , uglifying it for special cases.
We would have to write udev rules to deal with these values, should be
easy. If no DRIVER is given, it is simply memory detected and detected
during boot. ACPI changing the DRIVER might be tricky (from no DRIVER ->
ACPI), but I guess it could be done.
Now, the question would be how to get the DRIVER value in there. Adding
a bunch of fake device drivers would work, however this might get a
little messy ... and then there is unbining and rebinding which can be
triggered by userspace. Thinks to care about? Most probably not.
--
Thanks,
David / dhildenb
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: ni_tio: Use data[insn->n-1] in ni_tio_insn_write()
The `insn_write` handler for the counter subdevices
(`ni_tio_insn_write()`) writes a single data value `data[0]` to the
channel. Technically, `insn->n` specifies the number of successive
values from `data[]` to write to the channel, but when there is little
benefit in writing multiple data values, the usual Comedi convention is
to just write the last data value `data[insn->n - 1]`. Change the
function to follow that convention and use `data[insn->n - 1]` instead
of `data[0]`. (In practice, `insn->n` would normally be 1 anyway.)
Also follow the usual Comedi convention and return `insn->n` from the
handler to indicate success instead of 0 (although any non-negative
return value will do).
Signed-off-by: Ian Abbott
---
drivers/staging/comedi/drivers/ni_tio.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_tio.c
b/drivers/staging/comedi/drivers/ni_tio.c
index 048cb35723ad..943c5177cbea 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -1682,9 +1682,11 @@ int ni_tio_insn_write(struct comedi_device *dev,
unsigned int cidx = counter->counter_index;
unsigned int chip = counter->chip_index;
unsigned int load_reg;
+ unsigned int load_val;
if (insn->n < 1)
return 0;
+ load_val = data[insn->n - 1];
switch (channel) {
case 0:
/*
@@ -1697,7 +1699,7 @@ int ni_tio_insn_write(struct comedi_device *dev,
* load register is already selected.
*/
load_reg = ni_tio_next_load_register(counter);
- ni_tio_write(counter, data[0], load_reg);
+ ni_tio_write(counter, load_val, load_reg);
ni_tio_set_bits_transient(counter, NITIO_CMD_REG(cidx),
0, 0, GI_LOAD);
/* restore load reg */
@@ -1705,17 +1707,17 @@ int ni_tio_insn_write(struct comedi_device *dev,
load_reg);
break;
case 1:
- counter_dev->regs[chip][NITIO_LOADA_REG(cidx)] = data[0];
- ni_tio_write(counter, data[0], NITIO_LOADA_REG(cidx));
+ counter_dev->regs[chip][NITIO_LOADA_REG(cidx)] = load_val;
+ ni_tio_write(counter, load_val, NITIO_LOADA_REG(cidx));
break;
case 2:
- counter_dev->regs[chip][NITIO_LOADB_REG(cidx)] = data[0];
- ni_tio_write(counter, data[0], NITIO_LOADB_REG(cidx));
+ counter_dev->regs[chip][NITIO_LOADB_REG(cidx)] = load_val;
+ ni_tio_write(counter, load_val, NITIO_LOADB_REG(cidx));
break;
default:
return -EINVAL;
}
- return 0;
+ return insn->n;
}
EXPORT_SYMBOL_GPL(ni_tio_insn_write);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] vc04_services: vchiq_arm: fix a NULL pointer dereference
On 3/25/2019 4:13 AM, Kangjie Lu wrote: When kzalloc fails, "platform_state->inited = 1" is a NULL pointer dereference. The fix returns VCHIQ_ERROR in case it failed to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Reviewed-by: Mukesh Ojha -Mukesh --- .../staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c index dd4898861b83..0f12fe617575 100644 --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c @@ -209,6 +209,8 @@ vchiq_platform_init_state(struct vchiq_state *state) struct vchiq_2835_state *platform_state; state->platform_state = kzalloc(sizeof(*platform_state), GFP_KERNEL); + if (!state->platform_state) + return VCHIQ_ERROR; platform_state = (struct vchiq_2835_state *)state->platform_state; platform_state->inited = 1; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: media: imx: imx7-mipi-csis: simplify getting .driver_data
On Tue, Mar 19, 2019 at 05:36:22PM +0100, Wolfram Sang wrote:
> We should get 'driver_data' from 'struct device' directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Simon Horman
> ---
>
> Build tested only. buildbot is happy.
>
> drivers/staging/media/imx/imx7-mipi-csis.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/media/imx/imx7-mipi-csis.c
> b/drivers/staging/media/imx/imx7-mipi-csis.c
> index 2ddcc42ab8ff..44569c63e4de 100644
> --- a/drivers/staging/media/imx/imx7-mipi-csis.c
> +++ b/drivers/staging/media/imx/imx7-mipi-csis.c
> @@ -1039,8 +1039,7 @@ static int mipi_csis_probe(struct platform_device *pdev)
>
> static int mipi_csis_pm_suspend(struct device *dev, bool runtime)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct v4l2_subdev *mipi_sd = platform_get_drvdata(pdev);
> + struct v4l2_subdev *mipi_sd = dev_get_drvdata(dev);
> struct csi_state *state = mipi_sd_to_csis_state(mipi_sd);
> int ret = 0;
>
> @@ -1064,8 +1063,7 @@ static int mipi_csis_pm_suspend(struct device *dev,
> bool runtime)
>
> static int mipi_csis_pm_resume(struct device *dev, bool runtime)
> {
> - struct platform_device *pdev = to_platform_device(dev);
> - struct v4l2_subdev *mipi_sd = platform_get_drvdata(pdev);
> + struct v4l2_subdev *mipi_sd = dev_get_drvdata(dev);
> struct csi_state *state = mipi_sd_to_csis_state(mipi_sd);
> int ret = 0;
>
> --
> 2.11.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: pi433: Fix rf69_set_tx_cfg() logic
On Wed, Mar 27, 2019 at 08:11:20AM +, Sidong Yang wrote:
> Moved code to configure sync to where check enable_sync option before.
> There is no need to check enable_sync twice. Configuring sync should be
> executed immediately after enabling sync.
>
> Signed-off-by: Sidong Yang
> ---
> drivers/staging/pi433/pi433_if.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/pi433/pi433_if.c
> b/drivers/staging/pi433/pi433_if.c
> index 53928af696a6..0a48d6cb9547 100644
> --- a/drivers/staging/pi433/pi433_if.c
> +++ b/drivers/staging/pi433/pi433_if.c
> @@ -318,10 +318,17 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
> pi433_tx_cfg *tx_cfg)
> return ret;
> }
>
> + /* configure sync, if enabled */
This comment is obvious. Just delete it.
> if (tx_cfg->enable_sync == OPTION_ON) {
> ret = rf69_enable_sync(dev->spi);
> if (ret < 0)
> return ret;
> + ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
> + if (ret < 0)
> + return ret;
> + ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
> + if (ret < 0)
> + return ret;
It's weird that we enable sync before we et the size or sync values...
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: pi433: Fix rf69_set_tx_cfg() logic
Moved code to configure sync to where check enable_sync option before.
There is no need to check enable_sync twice. Configuring sync should be
executed immediately after enabling sync.
Signed-off-by: Sidong Yang
---
drivers/staging/pi433/pi433_if.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 53928af696a6..0a48d6cb9547 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -318,10 +318,17 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
return ret;
}
+ /* configure sync, if enabled */
if (tx_cfg->enable_sync == OPTION_ON) {
ret = rf69_enable_sync(dev->spi);
if (ret < 0)
return ret;
+ ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
+ if (ret < 0)
+ return ret;
+ ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
+ if (ret < 0)
+ return ret;
} else {
ret = rf69_disable_sync(dev->spi);
if (ret < 0)
@@ -348,16 +355,6 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
return ret;
}
- /* configure sync, if enabled */
- if (tx_cfg->enable_sync == OPTION_ON) {
- ret = rf69_set_sync_size(dev->spi, tx_cfg->sync_length);
- if (ret < 0)
- return ret;
- ret = rf69_set_sync_values(dev->spi, tx_cfg->sync_pattern);
- if (ret < 0)
- return ret;
- }
-
return 0;
}
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: core: fix line over 80 characters warning
On Tue, Mar 26, 2019 at 11:55:07PM +0530, Anirudh Rayabharam wrote:
> Shorten the expression by re-using the part that was already computed to
This confused me. Better to phrase it like:
Shorten the expression by using the "psecuritypriv" pointer.
> fix the line over 80 characters warning reported by checkpatch.pl.
>
> Signed-off-by: Anirudh Rayabharam
> ---
> drivers/staging/rtl8723bs/core/rtw_ap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c
> b/drivers/staging/rtl8723bs/core/rtw_ap.c
> index 18fabf5ff44b..bc0230672457 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_ap.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
> @@ -2336,8 +2336,8 @@ void rtw_ap_restore_network(struct adapter *padapter)
> Update_RA_Entry(padapter, psta);
> /* pairwise key */
> /* per sta pairwise key and settings */
> - if ((padapter->securitypriv.dot11PrivacyAlgrthm ==
> _TKIP_) ||
> - (padapter->securitypriv.dot11PrivacyAlgrthm ==
> _AES_)) {
> + if ((psecuritypriv->dot11PrivacyAlgrthm == _TKIP_) ||
> + (psecuritypriv->dot11PrivacyAlgrthm == _AES_)) {
It's better to align it slightly different as well. In the kernel we
would normally align the second condition to match the first one.
I probably would have gotten rid of the parenthesis as well. I don't
like double parenthesis around == because I reserve that for =
assignment conditions.
if (psecuritypriv->dot11PrivacyAlgrthm == _TKIP_ ||
psecuritypriv->dot11PrivacyAlgrthm == _AES_) {
rtw_setstakey_cmd(padapter, psta, true, false);
When you're changing just a couple lines like this you can get away with
making multiple white space changes at the same time because the One
Thing that the patch does is "Clean up a Condition". There is some
flexibility in the One thing Per Patch rule, but you have to sell it in
the right way. The patch description would be:
Checkpatch.pl complains that this line is over 80 characters. We
should use the "psecuritypriv" for consistency. It's not aligned
properly and there are too many parenthesis.
This patch just cleans up a condition, it doesn't affect runtime.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
