Re: [PATCH v4] staging: nrf24: add new driver for 2.4GHz radio transceiver
On Fri, Feb 22, 2019 at 09:20:56PM +0100, Marcin Ciupak wrote: > On Tue, Feb 19, 2019 at 11:20:10AM +0100, Greg Kroah-Hartman wrote: > > On Wed, Feb 13, 2019 at 08:40:35PM +0100, Marcin Ciupak wrote: > > > This patch adds driver for Nordic Semiconductor nRF24L01+ radio > > > transceiver. > > > > > > Signed-off-by: Marcin Ciupak > > > --- > > > Changes in v2: > > > - add terminating newlines to all logging formats > > > Changes in v3: > > > - patch subject > > > - comments cleanup > > > - goto labels cleanup > > > - scnprintf bugfix > > > - ida_simple_remove bugfix > > > Changes in v4: > > > - fix smatch warnings > > > > What is preventing this from being merged today with the normal > > subsystem for this type of drivers? Why does this have to go into > > staging? > > > > thanks, > > > > greg k-h > > As per TODO file: > +Todo: > +- opening and closing pipes via sysfs That's not what sysfs is for, so that can't be a TODO item :) > +- improve switching in between RX and TX > +- improve handling of MAX_RT interrupt That's just logic cleanup, no reason to have it in staging. > +- find and fix bugs Same here. > +- code cleanup What specifically do you mean by this? And why can't you just spend a day and do it now? > > Additionally, I would like to add ioctl (or any similar) interface > as configuration via sysfs is not very efficent in here. sysfs is not for configuration, that is what configfs is for, please use that instead. > My beliefes are that this driver needs some time in staging, but I might > be wrong and if you believe otherwise just let me know and I will try to > push it ti regular sybsystem. I think you need to use the standard apis that the kernel has for drivers like this (v4l?) and work on getting the driver into the proper subsystem first. I don't see what the goal of getting it into staging is going to do to help you out with that. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/ks7070: Removed unused varibale
On Sat, Feb 23, 2019 at 08:43:20AM +0100, Greg KH wrote:
On Sat, Feb 23, 2019 at 01:39:39AM -0500, Bo YU wrote:
From: Bo Yu
Compiling the kernel with W=1 results in the following warning:
drivers/staging/ks7010/ks_hostif.c:465:6: warning: variable ‘mib_val_type’
set but not used [-Wunused-but-set-variable]
u16 mib_val_type;
drivers/staging/ks7010/ks_hostif.c:464:6: warning: variable ‘mib_val_size’
set but not used [-Wunused-but-set-variable]
u16 mib_val_size;
drivers/staging/ks7010/ks_hostif.c:786:6: warning: variable ‘result_code’
set but not used [-Wunused-but-set-variable]
u16 result_code;
Remove these variables.
Rebase on next-20190222
Cc: Greg Kroah-Hartman
Cc: Sergio Paracuellos
Cc: Quytelda Kahja
Signed-off-by: Bo Yu
---
drivers/staging/ks7010/ks_hostif.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index d938b0997a53..913d8996437a 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -461,13 +461,9 @@ void hostif_mib_get_confirm(struct ks_wlan_private *priv)
struct net_device *dev = priv->net_dev;
u32 mib_status;
u32 mib_attribute;
- u16 mib_val_size;
- u16 mib_val_type;
mib_status = get_dword(priv);
mib_attribute = get_dword(priv);
- mib_val_size = get_word(priv);
- mib_val_type = get_word(priv);
The function get_word() actually does something to the priv structure,
so you just broke the driver :(
if (mib_status) {
netdev_err(priv->net_dev, "attribute=%08X, status=%08X\n",
@@ -783,9 +779,7 @@ void hostif_ps_adhoc_set_confirm(struct ks_wlan_private
*priv)
static
void hostif_infrastructure_set_confirm(struct ks_wlan_private *priv)
{
- u16 result_code;
- result_code = get_word(priv);
priv->infra_status = 1; /* infrastructure mode set */
hostif_sme_enqueue(priv, SME_MODE_SET_CONFIRM);
Same here, odds are you just broke things :(
Please be more careful.
Ok, I have through get_word() and get_byte() before modifing the code.
I think it should be better to encapsulate get_word without return value to do
some operations
like that? right?
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/ks7070: Removed unused varibale
On Sat, Feb 23, 2019 at 03:09:42AM -0500, YU Bo wrote:
> On Sat, Feb 23, 2019 at 08:43:20AM +0100, Greg KH wrote:
> > On Sat, Feb 23, 2019 at 01:39:39AM -0500, Bo YU wrote:
> > > From: Bo Yu
> > >
> > > Compiling the kernel with W=1 results in the following warning:
> > >
> > > drivers/staging/ks7010/ks_hostif.c:465:6: warning: variable ‘mib_val_type’
> > > set but not used [-Wunused-but-set-variable]
> > > u16 mib_val_type;
> > >
> > > drivers/staging/ks7010/ks_hostif.c:464:6: warning: variable ‘mib_val_size’
> > > set but not used [-Wunused-but-set-variable]
> > > u16 mib_val_size;
> > >
> > > drivers/staging/ks7010/ks_hostif.c:786:6: warning: variable ‘result_code’
> > > set but not used [-Wunused-but-set-variable]
> > > u16 result_code;
> > >
> > > Remove these variables.
> > >
> > > Rebase on next-20190222
> > >
> > > Cc: Greg Kroah-Hartman
> > > Cc: Sergio Paracuellos
> > > Cc: Quytelda Kahja
> > >
> > > Signed-off-by: Bo Yu
> > > ---
> > > drivers/staging/ks7010/ks_hostif.c | 6 --
> > > 1 file changed, 6 deletions(-)
> > >
> > > diff --git a/drivers/staging/ks7010/ks_hostif.c
> > > b/drivers/staging/ks7010/ks_hostif.c
> > > index d938b0997a53..913d8996437a 100644
> > > --- a/drivers/staging/ks7010/ks_hostif.c
> > > +++ b/drivers/staging/ks7010/ks_hostif.c
> > > @@ -461,13 +461,9 @@ void hostif_mib_get_confirm(struct ks_wlan_private
> > > *priv)
> > > struct net_device *dev = priv->net_dev;
> > > u32 mib_status;
> > > u32 mib_attribute;
> > > - u16 mib_val_size;
> > > - u16 mib_val_type;
> > >
> > > mib_status = get_dword(priv);
> > > mib_attribute = get_dword(priv);
> > > - mib_val_size = get_word(priv);
> > > - mib_val_type = get_word(priv);
> >
> > The function get_word() actually does something to the priv structure,
> > so you just broke the driver :(
> >
> > >
> > > if (mib_status) {
> > > netdev_err(priv->net_dev, "attribute=%08X, status=%08X\n",
> > > @@ -783,9 +779,7 @@ void hostif_ps_adhoc_set_confirm(struct
> > > ks_wlan_private *priv)
> > > static
> > > void hostif_infrastructure_set_confirm(struct ks_wlan_private *priv)
> > > {
> > > - u16 result_code;
> > >
> > > - result_code = get_word(priv);
> > > priv->infra_status = 1; /* infrastructure mode set */
> > > hostif_sme_enqueue(priv, SME_MODE_SET_CONFIRM);
> >
> > Same here, odds are you just broke things :(
> >
> > Please be more careful.
> Ok, I have through get_word() and get_byte() before modifing the code.
> I think it should be better to encapsulate get_word without return value to
> do some operations
> like that? right?
Something should be done, as that api is pretty horrible. But I think
that might be a lot more work to accomplish :)
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH net] staging: fsl-dpaa2: ethsw: Add missing netdevice check
> Subject: [PATCH net] staging: fsl-dpaa2: ethsw: Add missing netdevice check
>
> port_switchdev_event() does not check that the target network device is
> actually backed by the ethsw driver, this could be problematic in a stacked
> environment case.
>
Just FYI, I sent a patch set containing a similar patch verifying if the netdev
is backed by the ethsw:
https://lkml.org/lkml/2019/2/6/216
I sent the entire patch set against the staging tree.
Ioana C
> Fixes: 44baaa43d7cc ("staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet
> Switch driver")
> Signed-off-by: Florian Fainelli
> ---
> drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c b/drivers/staging/fsl-
> dpaa2/ethsw/ethsw.c
> index daabaceeea52..2edd82f5229a 100644
> --- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
> +++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
> @@ -1047,6 +1047,9 @@ static int port_switchdev_event(struct notifier_block
> *unused,
> struct ethsw_switchdev_event_work *switchdev_work;
> struct switchdev_notifier_fdb_info *fdb_info = ptr;
>
> + if (!ethsw_port_dev_check(dev))
> + return NOTIFY_DONE;
> +
> switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC);
> if (!switchdev_work)
> return NOTIFY_BAD;
> --
> 2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 7/8] net: switchdev: Replace port attr set SDO with a notification
On Fri, Feb 22, 2019 at 03:59:25PM -0800, Florian Fainelli wrote:
> Drop switchdev_ops.switchdev_port_attr_set. Drop the uses of this field
> from all clients, which were migrated to use switchdev notification in
> the previous patches.
>
> Add a new function switchdev_port_attr_notify() that sends the switchdev
> notifications SWITCHDEV_PORT_ATTR_SET and takes care, depending on
> SWITCHDEV_F_DEFER to call the blocking (process) or non-blocking
> (atomic) notifier chain accordingly.
>
> Drop __switchdev_port_attr_set() and update switchdev_port_attr_set()
> likewise.
>
> Signed-off-by: Florian Fainelli
> ---
> net/switchdev/switchdev.c | 96 +++
> 1 file changed, 26 insertions(+), 70 deletions(-)
>
> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
> index 94400f5b8e07..a1f16836ef89 100644
> --- a/net/switchdev/switchdev.c
> +++ b/net/switchdev/switchdev.c
> @@ -174,81 +174,35 @@ static int switchdev_deferred_enqueue(struct net_device
> *dev,
> return 0;
> }
>
> -/**
> - * switchdev_port_attr_get - Get port attribute
Hmm, why do you remove it here? Can't you remove it in a separate patch?
I thought we already got rid of it :p
> - *
> - * @dev: port device
> - * @attr: attribute to get
> - */
> -int switchdev_port_attr_get(struct net_device *dev, struct switchdev_attr
> *attr)
> +static int switchdev_port_attr_notify(enum switchdev_notifier_type nt,
> + struct net_device *dev,
> + const struct switchdev_attr *attr,
> + struct switchdev_trans *trans)
> {
> - const struct switchdev_ops *ops = dev->switchdev_ops;
> - struct net_device *lower_dev;
> - struct list_head *iter;
> - struct switchdev_attr first = {
> - .id = SWITCHDEV_ATTR_ID_UNDEFINED
> - };
> - int err = -EOPNOTSUPP;
> + int err;
> + int rc;
>
> - if (ops && ops->switchdev_port_attr_get)
> - return ops->switchdev_port_attr_get(dev, attr);
> + struct switchdev_notifier_port_attr_info attr_info = {
> + .attr = attr,
> + .trans = trans,
> + .handled = false,
> + };
>
> - if (attr->flags & SWITCHDEV_F_NO_RECURSE)
> + if (attr & SWITCHDEV_F_DEFER)
> + rc = call_switchdev_blocking_notifiers(nt, dev,
> +&attr_info.info, NULL);
> + else
> + rc = call_switchdev_notifiers(nt, dev, &attr_info.info, NULL);
I don't believe this is needed. You're calling this function from
switchdev_port_attr_set_now() which is always called from process
context. switchdev_port_attr_set() takes care of that. Similar to
switchdev_port_obj_add().
The event `SWITCHDEV_PORT_ATTR_SET` is therefore always blocking and
drivers only need to take care of it from their blocking notifier.
> + err = notifier_to_errno(rc);
> + if (err) {
> + WARN_ON(!attr_info.handled);
> return err;
> -
> - /* Switch device port(s) may be stacked under
> - * bond/team/vlan dev, so recurse down to get attr on
> - * each port. Return -ENODATA if attr values don't
> - * compare across ports.
> - */
> -
> - netdev_for_each_lower_dev(dev, lower_dev, iter) {
> - err = switchdev_port_attr_get(lower_dev, attr);
> - if (err)
> - break;
> - if (first.id == SWITCHDEV_ATTR_ID_UNDEFINED)
> - first = *attr;
> - else if (memcmp(&first, attr, sizeof(*attr)))
> - return -ENODATA;
> }
>
> - return err;
> -}
> -EXPORT_SYMBOL_GPL(switchdev_port_attr_get);
> -
> -static int __switchdev_port_attr_set(struct net_device *dev,
> - const struct switchdev_attr *attr,
> - struct switchdev_trans *trans)
> -{
> - const struct switchdev_ops *ops = dev->switchdev_ops;
> - struct net_device *lower_dev;
> - struct list_head *iter;
> - int err = -EOPNOTSUPP;
> -
> - if (ops && ops->switchdev_port_attr_set) {
> - err = ops->switchdev_port_attr_set(dev, attr, trans);
> - goto done;
> - }
> -
> - if (attr->flags & SWITCHDEV_F_NO_RECURSE)
> - goto done;
> -
> - /* Switch device port(s) may be stacked under
> - * bond/team/vlan dev, so recurse down to set attr on
> - * each port.
> - */
> -
> - netdev_for_each_lower_dev(dev, lower_dev, iter) {
> - err = __switchdev_port_attr_set(lower_dev, attr, trans);
> - if (err)
> - break;
> - }
> -
> -done:
> - if (err == -EOPNOTSUPP && attr->flags & SWITCHDEV_F_SKIP_EOPNOTSUPP)
> - err = 0;
> + if (!attr_info.handled)
> + return -EOPNOTSUPP;
>
> - return err;
> + return 0;
> }
>
> static int switchdev_port_att
Re: [PATCH net-next 1/8] switchdev: Add SWITCHDEV_PORT_ATTR_SET
On Fri, Feb 22, 2019 at 03:59:19PM -0800, Florian Fainelli wrote:
> In preparation for allowing switchdev enabled drivers to veto specific
> attribute settings from within the context of the caller, introduce a
> new switchdev notifier type for port attributes.
>
> Suggested-by: Ido Schimmel
> Signed-off-by: Florian Fainelli
> ---
> include/net/switchdev.h | 27 +
> net/switchdev/switchdev.c | 51 +++
> 2 files changed, 78 insertions(+)
>
> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
> index 45310ddf2d7e..ca56b7487540 100644
> --- a/include/net/switchdev.h
> +++ b/include/net/switchdev.h
> @@ -136,6 +136,7 @@ enum switchdev_notifier_type {
>
> SWITCHDEV_PORT_OBJ_ADD, /* Blocking. */
> SWITCHDEV_PORT_OBJ_DEL, /* Blocking. */
> + SWITCHDEV_PORT_ATTR_SET, /* May be blocking . */
See my comment on 7/8. IIUC, this is always blocking, so comment needs to
be changed.
>
> SWITCHDEV_VXLAN_FDB_ADD_TO_BRIDGE,
> SWITCHDEV_VXLAN_FDB_DEL_TO_BRIDGE,
> @@ -164,6 +165,13 @@ struct switchdev_notifier_port_obj_info {
> bool handled;
> };
>
> +struct switchdev_notifier_port_attr_info {
> + struct switchdev_notifier_info info; /* must be first */
> + const struct switchdev_attr *attr;
> + struct switchdev_trans *trans;
> + bool handled;
> +};
> +
> static inline struct net_device *
> switchdev_notifier_info_to_dev(const struct switchdev_notifier_info *info)
> {
> @@ -216,7 +224,15 @@ int switchdev_handle_port_obj_del(struct net_device *dev,
> int (*del_cb)(struct net_device *dev,
> const struct switchdev_obj *obj));
>
> +int switchdev_handle_port_attr_set(struct net_device *dev,
> + struct switchdev_notifier_port_attr_info
> *port_attr_info,
> + bool (*check_cb)(const struct net_device *dev),
> + int (*set_cb)(struct net_device *dev,
> + const struct switchdev_attr *attr,
> + struct switchdev_trans *trans));
> +
> #define SWITCHDEV_SET_OPS(netdev, ops) ((netdev)->switchdev_ops = (ops))
> +
> #else
>
> static inline void switchdev_deferred_process(void)
> @@ -303,6 +319,17 @@ switchdev_handle_port_obj_del(struct net_device *dev,
> return 0;
> }
>
> +static inline int
> +switchdev_handle_port_attr_set(struct net_device *dev,
> + struct switchdev_notifier_port_attr_info
> *port_attr_info,
> + bool (*check_cb)(const struct net_device *dev),
> + int (*set_cb)(struct net_device *dev,
> + const struct switchdev_attr *attr,
> + struct switchdev_trans *trans))
> +{
> + return 0;
> +}
> +
> #define SWITCHDEV_SET_OPS(netdev, ops) do {} while (0)
>
> #endif
> diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
> index 7e1357db33d7..94400f5b8e07 100644
> --- a/net/switchdev/switchdev.c
> +++ b/net/switchdev/switchdev.c
> @@ -697,3 +697,54 @@ int switchdev_handle_port_obj_del(struct net_device *dev,
> return err;
> }
> EXPORT_SYMBOL_GPL(switchdev_handle_port_obj_del);
> +
> +static int __switchdev_handle_port_attr_set(struct net_device *dev,
> + struct switchdev_notifier_port_attr_info
> *port_attr_info,
> + bool (*check_cb)(const struct net_device *dev),
> + int (*set_cb)(struct net_device *dev,
> + const struct switchdev_attr *attr,
> + struct switchdev_trans *trans))
> +{
> + struct net_device *lower_dev;
> + struct list_head *iter;
> + int err = -EOPNOTSUPP;
> +
> + if (check_cb(dev)) {
> + port_attr_info->handled = true;
> + return set_cb(dev, port_attr_info->attr,
> + port_attr_info->trans);
> + }
> +
> + /* Switch ports might be stacked under e.g. a LAG. Ignore the
> + * unsupported devices, another driver might be able to handle them. But
> + * propagate to the callers any hard errors.
> + *
> + * If the driver does its own bookkeeping of stacked ports, it's not
> + * necessary to go through this helper.
> + */
> + netdev_for_each_lower_dev(dev, lower_dev, iter) {
> + err = __switchdev_handle_port_attr_set(lower_dev,
> port_attr_info,
> +check_cb, set_cb);
> + if (err && err != -EOPNOTSUPP)
> + return err;
> + }
> +
> + return err;
> +}
> +
> +int switchdev_handle_port_attr_set(struct net_device *dev,
> + struct switchdev_notifier_port_attr_info
> *port_attr_info,
> + bool (*check_cb)(const struct net_device *dev),
> + int (*set_cb)(struct
Re: [PATCH net-next 4/8] mlxsw: spectrum_switchdev: Handle SWITCHDEV_PORT_ATTR_SET
On Fri, Feb 22, 2019 at 03:59:22PM -0800, Florian Fainelli wrote:
> Following patches will change the way we communicate setting a port's
> attribute and use a notifier to perform those tasks.
>
> Prepare mlxsw to support receiving notifier events targeting
> SWITCHDEV_PORT_ATTR_SET and utilize the switchdev_handle_port_attr_set()
> to handle stacking of devices.
>
> Signed-off-by: Florian Fainelli
> ---
> .../net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> index 766f5b5f1cf5..c1aedfea3a31 100644
> --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
> @@ -3123,6 +3123,13 @@ static int mlxsw_sp_switchdev_event(struct
> notifier_block *unused,
> struct net_device *br_dev;
> int err;
>
> + if (event == SWITCHDEV_PORT_ATTR_SET) {
> + err = switchdev_handle_port_attr_set(dev, ptr,
> + mlxsw_sp_port_dev_check,
> + mlxsw_sp_port_attr_set);
> + return notifier_from_errno(err);
I don't think this code is ever executed. And if it was executed, we
would have problems because switchdev_handle_port_attr_set() might
block.
> + }
> +
> /* Tunnel devices are not our uppers, so check their master instead */
> br_dev = netdev_master_upper_dev_get_rcu(dev);
> if (!br_dev)
> @@ -3446,6 +3453,11 @@ static int mlxsw_sp_switchdev_blocking_event(struct
> notifier_block *unused,
> mlxsw_sp_port_dev_check,
> mlxsw_sp_port_obj_del);
> return notifier_from_errno(err);
> + case SWITCHDEV_PORT_ATTR_SET:
> + err = switchdev_handle_port_attr_set(dev, ptr,
> + mlxsw_sp_port_dev_check,
> + mlxsw_sp_port_attr_set);
> + return notifier_from_errno(err);
> }
>
> return NOTIFY_DONE;
> --
> 2.17.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] x86/Hyper-V: Fix definition HV_MAX_FLUSH_REP_COUNT
On Fri, Feb 22, 2019 at 10:32 PM Greg KH wrote:
>
> On Fri, Feb 22, 2019 at 06:48:44PM +0800, lantianyu1...@gmail.com wrote:
> > From: Lan Tianyu
> >
> > The max flush rep count of HvFlushGuestPhysicalAddressList hypercall
> > is equal with how many entries of union hv_gpa_page_range can be populated
> > into the input parameter page. The origin code lacks parenthesis around
> > PAGE_SIZE - 2 * sizeof(u64). This patch is to fix it.
> >
> > Cc:
> > Fixs: cc4edae4b9(x86/hyper-v: Add HvFlushGuestAddressList hypercall support)
>
> Please use this format instead:
>
> Fixes: cc4edae4b924 ("x86/hyper-v: Add HvFlushGuestAddressList hypercall
> support")
>
> And don't type it by hand, use a git alias for it:
> git show -s --abbrev-commit --abbrev=12 --pretty=format:"%h
> (\"%s\")%n"
>
OK. Will update. Thanks.
> You also messed up your To: line, keeping anyone from being able to
> respond to this message who do not know how to hand-edit the response
> line :(
I put all expected reviewers in the Cc line and will put into To line.
>
> thanks,
>
> greg k-h
--
Best regards
Tianyu Lan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V3 00/10] X86/KVM/Hyper-V: Add HV ept tlb range list flush support in KVM
On Sat, Feb 23, 2019 at 2:26 AM Paolo Bonzini wrote: > > On 22/02/19 16:06, lantianyu1...@gmail.com wrote: > > From: Lan Tianyu > > > > This patchset is to introduce hv ept tlb range list flush function > > support in the KVM MMU component. Flushing ept tlbs of several address > > range can be done via single hypercall and new list flush function is > > used in the kvm_mmu_commit_zap_page() and FNAME(sync_page). This patchset > > also adds more hv ept tlb range flush support in more KVM MMU function. > > > > This patchset is based on the fix patch "x86/Hyper-V: Fix definition > > HV_MAX_FLUSH_REP_COUNT". > > (https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1939455.html) > > Note that this won't make it in 5.1 unless Linus releases an -rc8. > Otherwise, I'll get to it next week. Hi Paolo: Sure. Thanks for your review. -- Best regards Tianyu Lan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: speakup: Replace simple_strtoul with kstrtoul
simple_strtoul is obsolete. Change it to kstrtoul. Kernel is building and booting successfully. Signed-off-by: Bharath Vedartham --- drivers/staging/speakup/kobjects.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/staging/speakup/kobjects.c b/drivers/staging/speakup/kobjects.c index 2e36d87..ad5a2b2 100644 --- a/drivers/staging/speakup/kobjects.c +++ b/drivers/staging/speakup/kobjects.c @@ -787,7 +787,9 @@ static ssize_t message_store_helper(const char *buf, size_t count, continue; } - index = simple_strtoul(cp, &temp, 10); + retval = kstrtoul(cp, 0, &index); + if (retval) + return retval; while ((temp < linefeed) && (*temp == ' ' || *temp == '\t')) temp++; -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: Note that simple_strtoul can't simply be replaced by kstrtoul
We often receive patches which erroneously try to use kstrtoul in these
places.
Signed-off-by: Samuel Thibault
---
drivers/staging/speakup/kobjects.c|2 ++
drivers/staging/speakup/main.c|1 +
drivers/staging/speakup/varhandlers.c |1 +
3 files changed, 4 insertions(+)
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -154,6 +154,7 @@ static ssize_t chars_chartab_store(struc
continue;
}
+ /* Do not replace with kstrtoul: here we need temp to be
updated */
index = simple_strtoul(cp, &temp, 10);
if (index > 255) {
rejected++;
@@ -787,6 +788,7 @@ static ssize_t message_store_helper(cons
continue;
}
+ /* Do not replace with kstrtoul: here we need temp to be
updated */
index = simple_strtoul(cp, &temp, 10);
while ((temp < linefeed) && (*temp == ' ' || *temp == '\t'))
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -1979,6 +1979,7 @@ oops:
return 1;
}
+ /* Do not replace with kstrtoul: here we need cp to be updated */
goto_pos = simple_strtoul(goto_buf, &cp, 10);
if (*cp == 'x') {
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -328,6 +328,7 @@ char *spk_s2uchar(char *start, char *des
{
int val;
+ /* Do not replace with kstrtoul: here we need start to be updated */
val = simple_strtoul(skip_spaces(start), &start, 10);
if (*start == ',')
start++;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: Replace simple_strtoul with kstrtoul
Bharath Vedartham, le dim. 24 févr. 2019 01:01:21 +0530, a ecrit: > simple_strtoul is obsolete. Change it to kstrtoul. Kernel is building > and booting successfully. Please recheck your patch, temp is used after the simple_strtoul call. Samuel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: Replace simple_strtoul with kstrtoul
On Sat, Feb 23, 2019 at 08:37:50PM +0100, Samuel Thibault wrote: > Bharath Vedartham, le dim. 24 févr. 2019 01:01:21 +0530, a ecrit: > > simple_strtoul is obsolete. Change it to kstrtoul. Kernel is building > > and booting successfully. > > Please recheck your patch, temp is used after the simple_strtoul call. > > Samuel Sorry about that. After some thought, I feel this is a special case in replacing simple_strtoul to kstrtoul. simple_strtoul can give back a pointer to the end of the parsed string, whereas kstrtoul does not give any thing of that kind. In our case, temp is the end of the parsed cp string. To replace simple_strtoul to kstrtoul, we need to know the length of the unsigned long int returned and shift the cp pointer by that length to get temp. This might involve a bit of code refactoring. Bharath ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging : speakup: replace ---help--- with help in Kconfig
Fix the checkpatch.pl warning to replace ---help--- with help in Kconfig. Signed-off-by: Bharath Vedartham --- drivers/staging/speakup/Kconfig | 32 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/staging/speakup/Kconfig b/drivers/staging/speakup/Kconfig index efd6f45..d8ec780 100644 --- a/drivers/staging/speakup/Kconfig +++ b/drivers/staging/speakup/Kconfig @@ -3,7 +3,7 @@ menu "Speakup console speech" config SPEAKUP depends on VT tristate "Speakup core" - ---help--- + help This is the Speakup screen reader. Think of it as a video console for blind people. If built in to the kernel, it can speak everything on the text console from @@ -43,7 +43,7 @@ config SPEAKUP if SPEAKUP config SPEAKUP_SYNTH_ACNTSA tristate "Accent SA synthesizer support" - ---help--- + help This is the Speakup driver for the Accent SA synthesizer. You can say y to build it into the kernel, or m to build it as a module. See the configuration @@ -52,7 +52,7 @@ config SPEAKUP_SYNTH_ACNTSA config SPEAKUP_SYNTH_ACNTPC tristate "Accent PC synthesizer support" depends on ISA || COMPILE_TEST - ---help--- + help This is the Speakup driver for the accent pc synthesizer. You can say y to build it into the kernel, or m to build it as a module. See the configuration @@ -60,7 +60,7 @@ config SPEAKUP_SYNTH_ACNTPC config SPEAKUP_SYNTH_APOLLO tristate "Apollo II synthesizer support" - ---help--- + help This is the Speakup driver for the Apollo II synthesizer. You can say y to build it into the kernel, or m to build it as a module. See the configuration @@ -68,7 +68,7 @@ config SPEAKUP_SYNTH_APOLLO config SPEAKUP_SYNTH_AUDPTR tristate "Audapter synthesizer support" - ---help--- + help This is the Speakup driver for the Audapter synthesizer. You can say y to build it into the kernel, or m to build it as a module. See the configuration help on the @@ -76,7 +76,7 @@ config SPEAKUP_SYNTH_AUDPTR config SPEAKUP_SYNTH_BNS tristate "Braille 'n' Speak synthesizer support" - ---help--- + help This is the Speakup driver for the Braille 'n' Speak synthesizer. You can say y to build it into the kernel, or m to build it as a module. See the configuration @@ -84,7 +84,7 @@ config SPEAKUP_SYNTH_BNS config SPEAKUP_SYNTH_DECTLK tristate "DECtalk Express synthesizer support" - ---help--- + help This is the Speakup driver for the DecTalk Express synthesizer. You can say y to build it into the kernel, @@ -93,7 +93,7 @@ config SPEAKUP_SYNTH_DECTLK config SPEAKUP_SYNTH_DECEXT tristate "DECtalk External (old) synthesizer support" - ---help--- + help This is the Speakup driver for the DecTalk External (old) synthesizer. You can say y to build it into the @@ -105,7 +105,7 @@ config SPEAKUP_SYNTH_DECPC depends on m depends on ISA || COMPILE_TEST tristate "DECtalk PC (big ISA card) synthesizer support" - ---help--- + help This is the Speakup driver for the DecTalk PC (full length ISA) synthesizer. You can say m to build it as @@ -127,7 +127,7 @@ config SPEAKUP_SYNTH_DECPC config SPEAKUP_SYNTH_DTLK tristate "DoubleTalk PC synthesizer support" depends on ISA || COMPILE_TEST - ---help--- + help This is the Speakup driver for the internal DoubleTalk PC synthesizer. You can say y to build it into the @@ -138,7 +138,7 @@ config SPEAKUP_SYNTH_DTLK config SPEAKUP_SYNTH_KEYPC tristate "Keynote Gold PC synthesizer support" depends on ISA || COMPILE_TEST - ---help--- + help This is the Speakup driver for the Keynote Gold PC synthesizer. You can say y to build it into the @@ -148,7 +148,7 @@ config SPEAKUP_SYNTH_KEYPC config SPEAKUP_SYNTH_LTLK tristate "DoubleTalk LT/LiteTalk synthesizer support" help--- +help This is the Speakup driver for the LiteTalk/DoubleTalk LT synthesizer. You can say y to build it into the @@ -158,7 +158,7 @@ config SPEAKUP_SYNTH_LTLK config SPEAKUP_SYNTH_SOFT tristate "Userspace software synthesizer support" - ---help--- + help This is the software synthesizer device node. It will register a device /dev/softsynth which midware programs @@ -169,7 +169,7 @@ config SPEAKUP_SYNTH_SOFT config SPEAKUP_SYNTH_SPKOUT tristate "Speak Out synthesizer s
Re: [PATCH] staging : speakup: replace ---help--- with help in Kconfig
Hello, and thanks for your patch, Bharath Vedartham, le dim. 24 févr. 2019 01:51:17 +0530, a ecrit: > @@ -148,7 +148,7 @@ config SPEAKUP_SYNTH_KEYPC > > config SPEAKUP_SYNTH_LTLK > tristate "DoubleTalk LT/LiteTalk synthesizer support" > help--- > +help I'd say while at it, align it with tristate? Samuel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH AUTOSEL 4.4 04/26] IB/{hfi1, qib}: Fix WC.byte_len calculation for UD_SEND_WITH_IMM
From: Brian Welty
[ Upstream commit 904bba211acc2112fdf866e5a2bc6cd9ecd0de1b ]
The work completion length for a receiving a UD send with immediate is
short by 4 bytes causing application using this opcode to fail.
The UD receive logic incorrectly subtracts 4 bytes for immediate
value. These bytes are already included in header length and are used to
calculate header/payload split, so the result is these 4 bytes are
subtracted twice, once when the header length subtracted from the overall
length and once again in the UD opcode specific path.
Remove the extra subtraction when handling the opcode.
Fixes: 7724105686e7 ("IB/hfi1: add driver files")
Reviewed-by: Michael J. Ruhl
Signed-off-by: Brian Welty
Signed-off-by: Mike Marciniszyn
Signed-off-by: Dennis Dalessandro
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/hw/qib/qib_ud.c | 1 -
drivers/staging/rdma/hfi1/ud.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_ud.c
b/drivers/infiniband/hw/qib/qib_ud.c
index 59193f67ea787..56bd59bc08b54 100644
--- a/drivers/infiniband/hw/qib/qib_ud.c
+++ b/drivers/infiniband/hw/qib/qib_ud.c
@@ -515,7 +515,6 @@ void qib_ud_rcv(struct qib_ibport *ibp, struct
qib_ib_header *hdr,
opcode == IB_OPCODE_UD_SEND_ONLY_WITH_IMMEDIATE) {
wc.ex.imm_data = ohdr->u.ud.imm_data;
wc.wc_flags = IB_WC_WITH_IMM;
- tlen -= sizeof(u32);
} else if (opcode == IB_OPCODE_UD_SEND_ONLY) {
wc.ex.imm_data = 0;
wc.wc_flags = 0;
diff --git a/drivers/staging/rdma/hfi1/ud.c b/drivers/staging/rdma/hfi1/ud.c
index 5a9c784bec04c..a88e37444be0e 100644
--- a/drivers/staging/rdma/hfi1/ud.c
+++ b/drivers/staging/rdma/hfi1/ud.c
@@ -793,7 +793,6 @@ void hfi1_ud_rcv(struct hfi1_packet *packet)
opcode == IB_OPCODE_UD_SEND_ONLY_WITH_IMMEDIATE) {
wc.ex.imm_data = ohdr->u.ud.imm_data;
wc.wc_flags = IB_WC_WITH_IMM;
- tlen -= sizeof(u32);
} else if (opcode == IB_OPCODE_UD_SEND_ONLY) {
wc.ex.imm_data = 0;
wc.wc_flags = 0;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Note that simple_strtoul can't simply be replaced by kstrtoul
On Sat, Feb 23, 2019 at 08:42:19PM +0100, Samuel Thibault wrote: > We often receive patches which erroneously try to use kstrtoul in these > places. > > Signed-off-by: Samuel Thibault Awe, it's fun to try to see people do this and not really think about the consequences :) Anyway, seriously, thanks for this, I'll go queue it up later today... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
