RE: [PATCH] PCI: hv: use effective affinity mask
Hi,
I've also tested this and it's working good. Kernels tested:
- next-20171109 on top of Ubuntu 16.04
- MSFT kernel - 4.14.0-rc5 with patch applied - on top of RHEL 7.3
Adrian
-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org]
Sent: Wednesday, November 8, 2017 3:08 AM
To: Dexuan Cui
Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; Jake Oshins
; KY Srinivasan ; Stephen Hemminger
; de...@linuxdriverproject.org;
linux-ker...@vger.kernel.org; Haiyang Zhang ; Jork
Loeser ; Chris Valean (Cloudbase Solutions SRL)
; Adrian Suhov (Cloudbase Solutions SRL)
; Simon Xiao ; 'Eyal Mizrachi'
; Jack Morgenstein ; Armen Guezalian
; Firas Mahameed ; Tziporet Koren
; Daniel Jurgens
Subject: Re: [PATCH] PCI: hv: use effective affinity mask
On Wed, Nov 01, 2017 at 08:30:53PM +, Dexuan Cui wrote:
>
> The effective_affinity_mask is always set when an interrupt is
> assigned in
> __assign_irq_vector() -> apic->cpu_mask_to_apicid(), e.g. for struct
> apic
> apic_physflat: -> default_cpu_mask_to_apicid() ->
> irq_data_update_effective_affinity(), but it looks d->common->affinity
> remains all-1's before the user space or the kernel changes it later.
>
> In the early allocation/initialization phase of an irq, we should use
> the effective_affinity_mask, otherwise Hyper-V may not deliver the
> interrupt to the expected cpu. Without the patch, if we assign 7
> Mellanox ConnectX-3 VFs to a 32-vCPU VM, one of the VFs may fail to receive
> interrupts.
>
> Signed-off-by: Dexuan Cui
> Cc: Jake Oshins
> Cc: Jork Loeser
> Cc: Stephen Hemminger
> Cc: K. Y. Srinivasan
> ---
>
> Please consider this for v4.14, if it's not too late.
What would be the rationale for putting it in v4.14? After the merge window, I
usually only merge fixes for problems introduced during the merge window, or
for serious regressions. I can't tell if this fits into that or not.
> drivers/pci/host/pci-hyperv.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/host/pci-hyperv.c
> b/drivers/pci/host/pci-hyperv.c index 5ccb47d..8b5f66d 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -879,7 +879,7 @@ static void hv_irq_unmask(struct irq_data *data)
> int cpu;
> u64 res;
>
> - dest = irq_data_get_affinity_mask(data);
> + dest = irq_data_get_effective_affinity_mask(data);
> pdev = msi_desc_to_pci_dev(msi_desc);
> pbus = pdev->bus;
> hbus = container_of(pbus->sysdata, struct hv_pcibus_device,
> sysdata); @@ -1042,6 +1042,7 @@ static void hv_compose_msi_msg(struct
> irq_data *data, struct msi_msg *msg)
> struct hv_pci_dev *hpdev;
> struct pci_bus *pbus;
> struct pci_dev *pdev;
> + struct cpumask *dest;
> struct compose_comp_ctxt comp;
> struct tran_int_desc *int_desc;
> struct {
> @@ -1056,6 +1057,7 @@ static void hv_compose_msi_msg(struct irq_data *data,
> struct msi_msg *msg)
> int ret;
>
> pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
> + dest = irq_data_get_effective_affinity_mask(data);
> pbus = pdev->bus;
> hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
> hpdev = get_pcichild_wslot(hbus, devfn_to_wslot(pdev->devfn)); @@
> -1081,14 +1083,14 @@ static void hv_compose_msi_msg(struct irq_data *data,
> struct msi_msg *msg)
> switch (pci_protocol_version) {
> case PCI_PROTOCOL_VERSION_1_1:
> size = hv_compose_msi_req_v1(&ctxt.int_pkts.v1,
> - irq_data_get_affinity_mask(data),
> + dest,
> hpdev->desc.win_slot.slot,
> cfg->vector);
> break;
>
> case PCI_PROTOCOL_VERSION_1_2:
> size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2,
> - irq_data_get_affinity_mask(data),
> + dest,
> hpdev->desc.win_slot.slot,
> cfg->vector);
> break;
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC] hv_netvsc: safer orderly shutdown
Stephen Hemminger writes:
> Several types of control operations require that the underlying RNDIS
> infrastructure be restarted. This patch changes the ordering of the
> shutdown to avoid race conditions.
> Stop all transmits before doing RNDIS halt. This involves stopping the
> network device transmit queues, then waiting for all outstanding
> sends before informing host to halt.
>
> Also, check for successful restart of the device when after the
> change is done.
>
> For review, not tested on Hyper-V yet.
>
> Signed-off-by: Stephen Hemminger
> ---
> drivers/net/hyperv/netvsc_drv.c | 40
> ++-
> drivers/net/hyperv/rndis_filter.c | 23 +++---
> 2 files changed, 42 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index da216ca4f2b2..3afa082e093d 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -855,8 +855,10 @@ static int netvsc_set_channels(struct net_device *net,
>
> orig = nvdev->num_chn;
> was_opened = rndis_filter_opened(nvdev);
> - if (was_opened)
> + if (was_opened) {
> + netif_tx_disable(net);
> rndis_filter_close(nvdev);
> + }
I was also experimenting with this and I think it may also make sense to
add napi_disable() for all queues here.
It also seems that the usual TX disable pattern is
netif_tx_stop_all_queues(net);
netif_tx_disable(net);
not sure why..
>
> memset(&device_info, 0, sizeof(device_info));
> device_info.num_chn = count;
> @@ -881,8 +883,13 @@ static int netvsc_set_channels(struct net_device *net,
> }
> }
>
> - if (was_opened)
> - rndis_filter_open(nvdev);
> + if (was_opened) {
> + ret = rndis_filter_open(nvdev);
> + if (ret)
> + netdev_err(net, "reopening device failed: %d\n", ret);
> + else
> + netif_tx_start_all_queues(net);
> + }
>
> /* We may have missed link change notifications */
> net_device_ctx->last_reconfig = 0;
> @@ -971,8 +978,10 @@ static int netvsc_change_mtu(struct net_device *ndev,
> int mtu)
>
> netif_device_detach(ndev);
> was_opened = rndis_filter_opened(nvdev);
> - if (was_opened)
> + if (was_opened) {
> + netif_tx_disable(net);
> rndis_filter_close(nvdev);
> + }
Shall we just nove netif_tx_disable() & friends to rndis_filter_close()?
>
> memset(&device_info, 0, sizeof(device_info));
> device_info.ring_size = ring_size;
> @@ -1004,8 +1013,13 @@ static int netvsc_change_mtu(struct net_device *ndev,
> int mtu)
> }
> }
>
> - if (was_opened)
> - rndis_filter_open(nvdev);
> + if (was_opened) {
> + ret = rndis_filter_open(nvdev);
> + if (ret)
> + netdev_err(net, "reopening device failed: %d\n", ret);
> + else
> + netif_tx_start_all_queues(net);
> + }
Yea, the main problem here is that we can't do much if we fail, the
device will be completely unusable. That's not something users exepct
doing MTU change...
>
> netif_device_attach(ndev);
>
> @@ -1547,8 +1561,10 @@ static int netvsc_set_ringparam(struct net_device
> *ndev,
>
> netif_device_detach(ndev);
> was_opened = rndis_filter_opened(nvdev);
> - if (was_opened)
> + if (was_opened) {
> + netif_tx_disable(net);
> rndis_filter_close(nvdev);
> + }
>
> rndis_filter_device_remove(hdev, nvdev);
>
> @@ -1566,8 +1582,14 @@ static int netvsc_set_ringparam(struct net_device
> *ndev,
> }
> }
>
> - if (was_opened)
> - rndis_filter_open(nvdev);
> + if (was_opened) {
> + ret = rndis_filter_open(nvdev);
> + if (ret)
> + netdev_err(net, "reopening device failed: %d\n", ret);
> + else
> + netif_tx_start_all_queues(net);
> + }
> +
> netif_device_attach(ndev);
>
> /* We may have missed link change notifications */
> diff --git a/drivers/net/hyperv/rndis_filter.c
> b/drivers/net/hyperv/rndis_filter.c
> index 0648eebda829..164f5ffe9c50 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -948,11 +948,20 @@ static void rndis_filter_halt_device(struct
> rndis_device *dev)
> struct net_device_context *net_device_ctx = netdev_priv(dev->ndev);
> struct netvsc_device *nvdev = rtnl_dereference(net_device_ctx->nvdev);
>
> + /* tell bottom half that deice is being closed */
> + nvdev->destroy = true;
> +
> + /* Force flag to be ordered before waiting */
> + wmb();
> +
> + /* Wait for all send completions */
> + wait_event(nvdev->wait_drain, netvsc_device_idle(nvdev));
> +
> /* Attempt to do a rndis device halt */
>
Re: [PATCH] staging: pi433: fix missing break in switch statement.
Hi all!
Tryed to cross check...
Don't get it, sorry.
On my private version control (my SVN), where I initially developed the
driver the break isn't missing.
Same with my git copy of Gregs staging tree. Break is there...
Who removed it, why is it missing in Colins copy?
Am I working on a wrong version?
marcus@Laptop-Wolf:~/staging/drivers/staging/pi433$ git remote show origin
* remote origin
Fetch URL:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
Push URL:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
Can anybody help me?
Thanks,
Marcus
Am 09.11.2017 um 19:19 schrieb Colin King:
From: Colin Ian King
The PI433_IOC_WR_RX_CFG case is missing a break and will fall through
to the default case and errorenously return -EINVAL. Fix this by
adding in missing break.
Detected by CoverityScan, CID#1461286 ("Missing break in switch")
Fixes: f81f0b5c9a30 ("pi433: sanitize ioctl")
Signed-off-by: Colin Ian King
---
drivers/staging/pi433/pi433_if.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 3bcb59811cdf..a960fe2e7875 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -811,6 +811,7 @@ pi433_ioctl(struct file *filp, unsigned int cmd, unsigned
long arg)
}
mutex_unlock(&device->rx_lock);
+ break;
default:
retval = -EINVAL;
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: pi433: fix missing break in switch statement.
On 10/11/17 16:49, Marcus Wolf wrote:
> Hi all!
>
> Tryed to cross check...
>
> Don't get it, sorry.
>
> On my private version control (my SVN), where I initially developed the
> driver the break isn't missing.
> Same with my git copy of Gregs staging tree. Break is there...
>
> Who removed it, why is it missing in Colins copy?
>
> Am I working on a wrong version?
I was working on the latest, that got landed into linux-next. This had
picked up some modifications from Al-Viro.
Hope that clarifies things
Colin
>
> marcus@Laptop-Wolf:~/staging/drivers/staging/pi433$ git remote show origin
> * remote origin
> Fetch URL:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> Push URL:
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
>
>
> Can anybody help me?
>
> Thanks,
>
> Marcus
>
>
> Am 09.11.2017 um 19:19 schrieb Colin King:
>> From: Colin Ian King
>>
>> The PI433_IOC_WR_RX_CFG case is missing a break and will fall through
>> to the default case and errorenously return -EINVAL. Fix this by
>> adding in missing break.
>>
>> Detected by CoverityScan, CID#1461286 ("Missing break in switch")
>>
>> Fixes: f81f0b5c9a30 ("pi433: sanitize ioctl")
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/staging/pi433/pi433_if.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/staging/pi433/pi433_if.c
>> b/drivers/staging/pi433/pi433_if.c
>> index 3bcb59811cdf..a960fe2e7875 100644
>> --- a/drivers/staging/pi433/pi433_if.c
>> +++ b/drivers/staging/pi433/pi433_if.c
>> @@ -811,6 +811,7 @@ pi433_ioctl(struct file *filp, unsigned int cmd,
>> unsigned long arg)
>> }
>> mutex_unlock(&device->rx_lock);
>> + break;
>> default:
>> retval = -EINVAL;
>> }
>>
> --
> To unsubscribe from this list: send the line "unsubscribe
> kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: pi433: fix missing break in switch statement.
Hi Colin,
thanks for clarification.
Should I switch to that repo for further work, too?
If so, can anybody provide me the link?
Do I need Gregs staging any longer, or is it kind of dead for devel on
pi433 driver?
Thank you so much!
Marcus
Am 10.11.2017 um 18:04 schrieb Colin Ian King:
> On 10/11/17 16:49, Marcus Wolf wrote:
>> Hi all!
>>
>> Tryed to cross check...
>>
>> Don't get it, sorry.
>>
>> On my private version control (my SVN), where I initially developed the
>> driver the break isn't missing.
>> Same with my git copy of Gregs staging tree. Break is there...
>>
>> Who removed it, why is it missing in Colins copy?
>>
>> Am I working on a wrong version?
>
> I was working on the latest, that got landed into linux-next. This had
> picked up some modifications from Al-Viro.
>
> Hope that clarifies things
>
> Colin
>
>>
>> marcus@Laptop-Wolf:~/staging/drivers/staging/pi433$ git remote show origin
>> * remote origin
>> Fetch URL:
>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
>> Push URL:
>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
>>
>>
>> Can anybody help me?
>>
>> Thanks,
>>
>> Marcus
>>
>>
>> Am 09.11.2017 um 19:19 schrieb Colin King:
>>> From: Colin Ian King
>>>
>>> The PI433_IOC_WR_RX_CFG case is missing a break and will fall through
>>> to the default case and errorenously return -EINVAL. Fix this by
>>> adding in missing break.
>>>
>>> Detected by CoverityScan, CID#1461286 ("Missing break in switch")
>>>
>>> Fixes: f81f0b5c9a30 ("pi433: sanitize ioctl")
>>> Signed-off-by: Colin Ian King
>>> ---
>>> drivers/staging/pi433/pi433_if.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/staging/pi433/pi433_if.c
>>> b/drivers/staging/pi433/pi433_if.c
>>> index 3bcb59811cdf..a960fe2e7875 100644
>>> --- a/drivers/staging/pi433/pi433_if.c
>>> +++ b/drivers/staging/pi433/pi433_if.c
>>> @@ -811,6 +811,7 @@ pi433_ioctl(struct file *filp, unsigned int cmd,
>>> unsigned long arg)
>>> }
>>> mutex_unlock(&device->rx_lock);
>>> + break;
>>> default:
>>> retval = -EINVAL;
>>> }
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> kernel-janitors" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
staging: pi433: Possible bug in rf69.c
Hi everybody! Just comparing the master of Gregs statging of pi433 with my local SVN to review all changes, that were done the last monthes. I am not sure, but maybe we imported a bug in rf69.c lines 378 and following: Gregs repo: case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) & LNA_GAIN_AUTO) ); case max:return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) & LNA_GAIN_MAX) ); case maxMinus6: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_6) ); case maxMinus12: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_12) ); case maxMinus24: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_24) ); case maxMinus36: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_36) ); case maxMinus48: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) & LNA_GAIN_MAX_MINUS_48) ); my repo: case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | LNA_GAIN_AUTO) ); case max:return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | LNA_GAIN_MAX) ); case maxMinus6: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_6) ); case maxMinus12: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_12) ); case maxMinus24: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_24) ); case maxMinus36: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_36) ); case maxMinus48: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) & ~MASK_LNA_GAIN) | LNA_GAIN_MAX_MINUS_48) ); Up to my opinion, my (old) version is better then Gregs (new) version. If you agree, I'll prepare a patch, to revert the modification. Thanks, Marcus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] PCI: hv: use effective affinity mask
On Fri, Nov 10, 2017 at 08:55:07AM +, Adrian Suhov (Cloudbase Solutions
SRL) wrote:
> Hi,
>
> I've also tested this and it's working good. Kernels tested:
> - next-20171109 on top of Ubuntu 16.04
> - MSFT kernel - 4.14.0-rc5 with patch applied - on top of RHEL 7.3
>
> Adrian
Thanks, Adrian. I added this to the patch:
Tested-by: Adrian Suhov
> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Wednesday, November 8, 2017 3:08 AM
> To: Dexuan Cui
> Cc: Bjorn Helgaas ; linux-...@vger.kernel.org; Jake
> Oshins ; KY Srinivasan ; Stephen
> Hemminger ; de...@linuxdriverproject.org;
> linux-ker...@vger.kernel.org; Haiyang Zhang ; Jork
> Loeser ; Chris Valean (Cloudbase Solutions SRL)
> ; Adrian Suhov (Cloudbase Solutions SRL)
> ; Simon Xiao ; 'Eyal Mizrachi'
> ; Jack Morgenstein ; Armen Guezalian
> ; Firas Mahameed ; Tziporet Koren
> ; Daniel Jurgens
> Subject: Re: [PATCH] PCI: hv: use effective affinity mask
>
> On Wed, Nov 01, 2017 at 08:30:53PM +, Dexuan Cui wrote:
> >
> > The effective_affinity_mask is always set when an interrupt is
> > assigned in
> > __assign_irq_vector() -> apic->cpu_mask_to_apicid(), e.g. for struct
> > apic
> > apic_physflat: -> default_cpu_mask_to_apicid() ->
> > irq_data_update_effective_affinity(), but it looks d->common->affinity
> > remains all-1's before the user space or the kernel changes it later.
> >
> > In the early allocation/initialization phase of an irq, we should use
> > the effective_affinity_mask, otherwise Hyper-V may not deliver the
> > interrupt to the expected cpu. Without the patch, if we assign 7
> > Mellanox ConnectX-3 VFs to a 32-vCPU VM, one of the VFs may fail to receive
> > interrupts.
> >
> > Signed-off-by: Dexuan Cui
> > Cc: Jake Oshins
> > Cc: Jork Loeser
> > Cc: Stephen Hemminger
> > Cc: K. Y. Srinivasan
> > ---
> >
> > Please consider this for v4.14, if it's not too late.
>
> What would be the rationale for putting it in v4.14? After the merge window,
> I usually only merge fixes for problems introduced during the merge window,
> or for serious regressions. I can't tell if this fits into that or not.
>
> > drivers/pci/host/pci-hyperv.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-hyperv.c
> > b/drivers/pci/host/pci-hyperv.c index 5ccb47d..8b5f66d 100644
> > --- a/drivers/pci/host/pci-hyperv.c
> > +++ b/drivers/pci/host/pci-hyperv.c
> > @@ -879,7 +879,7 @@ static void hv_irq_unmask(struct irq_data *data)
> > int cpu;
> > u64 res;
> >
> > - dest = irq_data_get_affinity_mask(data);
> > + dest = irq_data_get_effective_affinity_mask(data);
> > pdev = msi_desc_to_pci_dev(msi_desc);
> > pbus = pdev->bus;
> > hbus = container_of(pbus->sysdata, struct hv_pcibus_device,
> > sysdata); @@ -1042,6 +1042,7 @@ static void hv_compose_msi_msg(struct
> > irq_data *data, struct msi_msg *msg)
> > struct hv_pci_dev *hpdev;
> > struct pci_bus *pbus;
> > struct pci_dev *pdev;
> > + struct cpumask *dest;
> > struct compose_comp_ctxt comp;
> > struct tran_int_desc *int_desc;
> > struct {
> > @@ -1056,6 +1057,7 @@ static void hv_compose_msi_msg(struct irq_data *data,
> > struct msi_msg *msg)
> > int ret;
> >
> > pdev = msi_desc_to_pci_dev(irq_data_get_msi_desc(data));
> > + dest = irq_data_get_effective_affinity_mask(data);
> > pbus = pdev->bus;
> > hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
> > hpdev = get_pcichild_wslot(hbus, devfn_to_wslot(pdev->devfn)); @@
> > -1081,14 +1083,14 @@ static void hv_compose_msi_msg(struct irq_data *data,
> > struct msi_msg *msg)
> > switch (pci_protocol_version) {
> > case PCI_PROTOCOL_VERSION_1_1:
> > size = hv_compose_msi_req_v1(&ctxt.int_pkts.v1,
> > - irq_data_get_affinity_mask(data),
> > + dest,
> > hpdev->desc.win_slot.slot,
> > cfg->vector);
> > break;
> >
> > case PCI_PROTOCOL_VERSION_1_2:
> > size = hv_compose_msi_req_v2(&ctxt.int_pkts.v2,
> > - irq_data_get_affinity_mask(data),
> > + dest,
> > hpdev->desc.win_slot.slot,
> > cfg->vector);
> > break;
> > --
> > 2.7.4
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/5] x86: add enum for hypervisors to replace x86_hyper
On Thu, Nov 09, 2017 at 02:27:36PM +0100, Juergen Gross wrote:
> The x86_hyper pointer is only used for checking whether a virtual
> device is supporting the hypervisor the system is running on.
>
> Use an enum for that purpose instead and drop the x86_hyper pointer.
>
> Cc: k...@microsoft.com
> Cc: haiya...@microsoft.com
> Cc: sthem...@microsoft.com
> Cc: akata...@vmware.com
> Cc: pbonz...@redhat.com
> Cc: rkrc...@redhat.com
> Cc: boris.ostrov...@oracle.com
> Cc: de...@linuxdriverproject.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: k...@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-graphics-maintai...@vmware.com
> Cc: pv-driv...@vmware.com
> Cc: dmitry.torok...@gmail.com
> Cc: xdeguill...@vmware.com
> Cc: moltm...@vmware.com
> Cc: a...@arndb.de
> Cc: gre...@linuxfoundation.org
> Cc: linux-in...@vger.kernel.org
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/hyperv/hv_init.c | 2 +-
> arch/x86/include/asm/hypervisor.h | 23 ++-
> arch/x86/kernel/cpu/hypervisor.c | 12 +---
> arch/x86/kernel/cpu/mshyperv.c| 4 ++--
> arch/x86/kernel/cpu/vmware.c | 4 ++--
> arch/x86/kernel/kvm.c | 4 ++--
> arch/x86/xen/enlighten_hvm.c | 4 ++--
> arch/x86/xen/enlighten_pv.c | 4 ++--
> drivers/hv/vmbus_drv.c| 2 +-
> drivers/input/mouse/vmmouse.c | 10 --
Acked-by: Dmitry Torokhov
> drivers/misc/vmw_balloon.c| 2 +-
> 11 files changed, 40 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index a5db63f728a2..a0b86cf486e0 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -113,7 +113,7 @@ void hyperv_init(void)
> u64 guest_id;
> union hv_x64_msr_hypercall_contents hypercall_msr;
>
> - if (x86_hyper != &x86_hyper_ms_hyperv)
> + if (x86_hyper_type != X86_HYPER_MS_HYPERV)
> return;
>
> /* Allocate percpu VP index */
> diff --git a/arch/x86/include/asm/hypervisor.h
> b/arch/x86/include/asm/hypervisor.h
> index 0eca7239a7aa..1b0a5abcd8ae 100644
> --- a/arch/x86/include/asm/hypervisor.h
> +++ b/arch/x86/include/asm/hypervisor.h
> @@ -29,6 +29,16 @@
> /*
> * x86 hypervisor information
> */
> +
> +enum x86_hypervisor_type {
> + X86_HYPER_NATIVE = 0,
> + X86_HYPER_VMWARE,
> + X86_HYPER_MS_HYPERV,
> + X86_HYPER_XEN_PV,
> + X86_HYPER_XEN_HVM,
> + X86_HYPER_KVM,
> +};
> +
> struct hypervisor_x86 {
> /* Hypervisor name */
> const char *name;
> @@ -36,6 +46,9 @@ struct hypervisor_x86 {
> /* Detection routine */
> uint32_t(*detect)(void);
>
> + /* Hypervisor type */
> + enum x86_hypervisor_type type;
> +
> /* init time callbacks */
> struct x86_hyper_init init;
>
> @@ -43,15 +56,7 @@ struct hypervisor_x86 {
> struct x86_hyper_runtime runtime;
> };
>
> -extern const struct hypervisor_x86 *x86_hyper;
> -
> -/* Recognized hypervisors */
> -extern const struct hypervisor_x86 x86_hyper_vmware;
> -extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
> -extern const struct hypervisor_x86 x86_hyper_xen_pv;
> -extern const struct hypervisor_x86 x86_hyper_xen_hvm;
> -extern const struct hypervisor_x86 x86_hyper_kvm;
> -
> +extern enum x86_hypervisor_type x86_hyper_type;
> extern void init_hypervisor_platform(void);
> #else
> static inline void init_hypervisor_platform(void) { }
> diff --git a/arch/x86/kernel/cpu/hypervisor.c
> b/arch/x86/kernel/cpu/hypervisor.c
> index 6c1bf092..bea8d3e24f50 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -26,6 +26,12 @@
> #include
> #include
>
> +extern const struct hypervisor_x86 x86_hyper_vmware;
> +extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
> +extern const struct hypervisor_x86 x86_hyper_xen_pv;
> +extern const struct hypervisor_x86 x86_hyper_xen_hvm;
> +extern const struct hypervisor_x86 x86_hyper_kvm;
> +
> static const __initconst struct hypervisor_x86 * const hypervisors[] =
> {
> #ifdef CONFIG_XEN_PV
> @@ -41,8 +47,8 @@ static const __initconst struct hypervisor_x86 * const
> hypervisors[] =
> #endif
> };
>
> -const struct hypervisor_x86 *x86_hyper;
> -EXPORT_SYMBOL(x86_hyper);
> +enum x86_hypervisor_type x86_hyper_type;
> +EXPORT_SYMBOL(x86_hyper_type);
>
> static inline const struct hypervisor_x86 * __init
> detect_hypervisor_vendor(void)
> @@ -87,6 +93,6 @@ void __init init_hypervisor_platform(void)
> copy_array(&h->init, &x86_init.hyper, sizeof(h->init));
> copy_array(&h->runtime, &x86_platform.hyper, sizeof(h->runtime));
>
> - x86_hyper = h;
> + x86_hyper_type = h->type;
> x86_init.hyper.init_platform();
> }
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 6bb84d655e4b..85eb5fc180c8 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -254,9
Re: staging: pi433: Possible bug in rf69.c
On Fri, Nov 10, 2017 at 06:23:32PM +0100, Marcus Wolf wrote:
> Hi everybody!
>
> Just comparing the master of Gregs statging of pi433 with my local SVN
> to review all changes, that were done the last monthes.
>
> I am not sure, but maybe we imported a bug in rf69.c lines 378 and
> following:
>
> Gregs repo:
> case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) & LNA_GAIN_AUTO) );
> my repo:
> case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
> ~MASK_LNA_GAIN) | LNA_GAIN_AUTO) );
I edited the lines for clarity. The difference is that your repo does
a bitwise OR "| LNA_GAIN_AUTO" and the kernel.org code does a bitwise
"& LNA_GAIN_AUTO".
The kernel repo hasn't changed since you sent us the driver in commit
874bcba65f9a ('staging: pi433: New driver'). I agree that & doesn't
seem to make sense and I'm disapointed that it doesn't cause a Smatch
warning.
But LNA_GAIN_AUTO is zero so maybe | BIT(LNA_GAIN_AUTO) was intended
instead of | LNA_GAIN_AUTO. I don't know... No one on this list knows
the answer probably. :/
regards,
dan caprenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 2/5] x86: add enum for hypervisors to replace x86_hyper
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Sent: Friday, November 10, 2017 10:26 AM
> To: Juergen Gross
> Cc: linux-ker...@vger.kernel.org; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; x...@kernel.org; KY Srinivasan ;
> Haiyang Zhang ; Stephen Hemminger
> ; akata...@vmware.com;
> pbonz...@redhat.com; rkrc...@redhat.com; boris.ostrov...@oracle.com;
> de...@linuxdriverproject.org; virtualizat...@lists.linux-foundation.org;
> k...@vger.kernel.org; xen-de...@lists.xenproject.org; linux-graphics-
> maintai...@vmware.com; pv-driv...@vmware.com;
> xdeguill...@vmware.com; moltm...@vmware.com; a...@arndb.de;
> gre...@linuxfoundation.org; linux-in...@vger.kernel.org
> Subject: Re: [PATCH v2 2/5] x86: add enum for hypervisors to replace
> x86_hyper
>
> On Thu, Nov 09, 2017 at 02:27:36PM +0100, Juergen Gross wrote:
> > The x86_hyper pointer is only used for checking whether a virtual
> > device is supporting the hypervisor the system is running on.
> >
> > Use an enum for that purpose instead and drop the x86_hyper pointer.
> >
> > Cc: k...@microsoft.com
> > Cc: haiya...@microsoft.com
> > Cc: sthem...@microsoft.com
> > Cc: akata...@vmware.com
> > Cc: pbonz...@redhat.com
> > Cc: rkrc...@redhat.com
> > Cc: boris.ostrov...@oracle.com
> > Cc: de...@linuxdriverproject.org
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: k...@vger.kernel.org
> > Cc: xen-de...@lists.xenproject.org
> > Cc: linux-graphics-maintai...@vmware.com
> > Cc: pv-driv...@vmware.com
> > Cc: dmitry.torok...@gmail.com
> > Cc: xdeguill...@vmware.com
> > Cc: moltm...@vmware.com
> > Cc: a...@arndb.de
> > Cc: gre...@linuxfoundation.org
> > Cc: linux-in...@vger.kernel.org
> >
> > Signed-off-by: Juergen Gross
> > ---
> > arch/x86/hyperv/hv_init.c | 2 +-
> > arch/x86/include/asm/hypervisor.h | 23 ++-
> > arch/x86/kernel/cpu/hypervisor.c | 12 +---
> > arch/x86/kernel/cpu/mshyperv.c| 4 ++--
> > arch/x86/kernel/cpu/vmware.c | 4 ++--
> > arch/x86/kernel/kvm.c | 4 ++--
> > arch/x86/xen/enlighten_hvm.c | 4 ++--
> > arch/x86/xen/enlighten_pv.c | 4 ++--
> > drivers/hv/vmbus_drv.c| 2 +-
> > drivers/input/mouse/vmmouse.c | 10 --
>
> Acked-by: Dmitry Torokhov
Acked-by: K. Y. Srinivasan
>
> > drivers/misc/vmw_balloon.c| 2 +-
> > 11 files changed, 40 insertions(+), 31 deletions(-)
> >
> > diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> > index a5db63f728a2..a0b86cf486e0 100644
> > --- a/arch/x86/hyperv/hv_init.c
> > +++ b/arch/x86/hyperv/hv_init.c
> > @@ -113,7 +113,7 @@ void hyperv_init(void)
> > u64 guest_id;
> > union hv_x64_msr_hypercall_contents hypercall_msr;
> >
> > - if (x86_hyper != &x86_hyper_ms_hyperv)
> > + if (x86_hyper_type != X86_HYPER_MS_HYPERV)
> > return;
> >
> > /* Allocate percpu VP index */
> > diff --git a/arch/x86/include/asm/hypervisor.h
> b/arch/x86/include/asm/hypervisor.h
> > index 0eca7239a7aa..1b0a5abcd8ae 100644
> > --- a/arch/x86/include/asm/hypervisor.h
> > +++ b/arch/x86/include/asm/hypervisor.h
> > @@ -29,6 +29,16 @@
> > /*
> > * x86 hypervisor information
> > */
> > +
> > +enum x86_hypervisor_type {
> > + X86_HYPER_NATIVE = 0,
> > + X86_HYPER_VMWARE,
> > + X86_HYPER_MS_HYPERV,
> > + X86_HYPER_XEN_PV,
> > + X86_HYPER_XEN_HVM,
> > + X86_HYPER_KVM,
> > +};
> > +
> > struct hypervisor_x86 {
> > /* Hypervisor name */
> > const char *name;
> > @@ -36,6 +46,9 @@ struct hypervisor_x86 {
> > /* Detection routine */
> > uint32_t(*detect)(void);
> >
> > + /* Hypervisor type */
> > + enum x86_hypervisor_type type;
> > +
> > /* init time callbacks */
> > struct x86_hyper_init init;
> >
> > @@ -43,15 +56,7 @@ struct hypervisor_x86 {
> > struct x86_hyper_runtime runtime;
> > };
> >
> > -extern const struct hypervisor_x86 *x86_hyper;
> > -
> > -/* Recognized hypervisors */
> > -extern const struct hypervisor_x86 x86_hyper_vmware;
> > -extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
> > -extern const struct hypervisor_x86 x86_hyper_xen_pv;
> > -extern const struct hypervisor_x86 x86_hyper_xen_hvm;
> > -extern const struct hypervisor_x86 x86_hyper_kvm;
> > -
> > +extern enum x86_hypervisor_type x86_hyper_type;
> > extern void init_hypervisor_platform(void);
> > #else
> > static inline void init_hypervisor_platform(void) { }
> > diff --git a/arch/x86/kernel/cpu/hypervisor.c
> b/arch/x86/kernel/cpu/hypervisor.c
> > index 6c1bf092..bea8d3e24f50 100644
> > --- a/arch/x86/kernel/cpu/hypervisor.c
> > +++ b/arch/x86/kernel/cpu/hypervisor.c
> > @@ -26,6 +26,12 @@
> > #include
> > #include
> >
> > +extern const struct hypervisor_x86 x86_hyper_vmware;
> > +extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
> > +extern const struct hypervisor_x86 x86_hyper_xen_pv;
> > +extern const struct hypervisor_x86 x86_hyper_xen_hvm;
> > +extern const
[PATCH] staging: speakup: selection: replace _manual_ swap with swap macro
Make use of the swap macro instead of _manually_ swapping values
and remove unnecessary variable tmp.
This makes the code easier to read and maintain.
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/staging/speakup/selection.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/speakup/selection.c
b/drivers/staging/speakup/selection.c
index 66061b5..0ed1fef 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -64,13 +64,8 @@ int speakup_set_selection(struct tty_struct *tty)
ps = spk_ys * vc->vc_size_row + (spk_xs << 1);
pe = spk_ye * vc->vc_size_row + (spk_xe << 1);
- if (ps > pe) {
- /* make sel_start <= sel_end */
- int tmp = ps;
-
- ps = pe;
- pe = tmp;
- }
+ if (ps > pe)/* make sel_start <= sel_end */
+ swap(ps, pe);
if (spk_sel_cons != vc_cons[fg_console].d) {
speakup_clear_selection();
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/9] include: Move compat_timespec/ timeval to compat_time.h
All the current architecture specific defines for these
are the same. Refactor these common defines to a common
header file.
The new common linux/compat_time.h is also useful as it
will eventually be used to hold all the defines that
are needed for compat time types that support non y2038
safe types. New architectures need not have to define these
new types as they will only use new y2038 safe syscalls.
This file can be deleted after y2038 when we stop supporting
non y2038 safe syscalls.
The patch also requires an operation similar to:
git grep "asm/compat\.h" | cut -d ":" -f 1 | xargs -n 1 sed -i -e
"s%asm/compat.h%linux/compat.h%g"
Cc: a...@kernel.org
Cc: b...@kernel.crashing.org
Cc: borntrae...@de.ibm.com
Cc: catalin.mari...@arm.com
Cc: cmetc...@mellanox.com
Cc: coh...@redhat.com
Cc: da...@davemloft.net
Cc: del...@gmx.de
Cc: de...@driverdev.osuosl.org
Cc: gerald.schae...@de.ibm.com
Cc: gre...@linuxfoundation.org
Cc: heiko.carst...@de.ibm.com
Cc: hoepp...@linux.vnet.ibm.com
Cc: h...@zytor.com
Cc: j...@parisc-linux.org
Cc: j...@linux.vnet.ibm.com
Cc: linux-ker...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: mark.rutl...@arm.com
Cc: mi...@redhat.com
Cc: m...@ellerman.id.au
Cc: ober...@linux.vnet.ibm.com
Cc: oprofile-l...@lists.sf.net
Cc: pau...@samba.org
Cc: pet...@infradead.org
Cc: r...@linux-mips.org
Cc: rost...@goodmis.org
Cc: r...@kernel.org
Cc: schwidef...@de.ibm.com
Cc: seb...@linux.vnet.ibm.com
Cc: sparcli...@vger.kernel.org
Cc: s...@linux.vnet.ibm.com
Cc: ubr...@linux.vnet.ibm.com
Cc: will.dea...@arm.com
Cc: x...@kernel.org
Signed-off-by: Deepa Dinamani
---
arch/arm64/include/asm/compat.h | 11 ---
arch/arm64/include/asm/stat.h | 1 +
arch/arm64/kernel/hw_breakpoint.c | 1 -
arch/arm64/kernel/perf_regs.c | 2 +-
arch/arm64/kernel/process.c | 1 -
arch/mips/include/asm/compat.h| 11 ---
arch/mips/kernel/signal32.c | 2 +-
arch/parisc/include/asm/compat.h | 11 ---
arch/powerpc/include/asm/compat.h | 11 ---
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/oprofile/backtrace.c | 2 +-
arch/s390/hypfs/hypfs_sprp.c | 1 -
arch/s390/include/asm/compat.h| 11 ---
arch/s390/include/asm/elf.h | 3 +--
arch/s390/kvm/priv.c | 1 -
arch/s390/pci/pci_clp.c | 1 -
arch/sparc/include/asm/compat.h | 11 ---
arch/tile/include/asm/compat.h| 11 ---
arch/x86/events/core.c| 2 +-
arch/x86/include/asm/compat.h | 11 ---
arch/x86/include/asm/ftrace.h | 2 +-
arch/x86/include/asm/sys_ia32.h | 2 +-
arch/x86/kernel/sys_x86_64.c | 2 +-
drivers/s390/block/dasd_ioctl.c | 1 -
drivers/s390/char/fs3270.c| 1 -
drivers/s390/char/sclp_ctl.c | 1 -
drivers/s390/char/vmcp.c | 1 -
drivers/s390/cio/chsc_sch.c | 1 -
drivers/s390/net/qeth_core_main.c | 2 +-
drivers/staging/pi433/pi433_if.c | 2 +-
include/linux/compat.h| 1 +
include/linux/compat_time.h | 19 +++
32 files changed, 32 insertions(+), 110 deletions(-)
create mode 100644 include/linux/compat_time.h
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index e39d487bf724..d4f9c9ee3b15 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -34,7 +34,6 @@
typedef u32compat_size_t;
typedef s32compat_ssize_t;
-typedef s32compat_time_t;
typedef s32compat_clock_t;
typedef s32compat_pid_t;
typedef u16__compat_uid_t;
@@ -66,16 +65,6 @@ typedef u32 compat_ulong_t;
typedef u64compat_u64;
typedef u32compat_uptr_t;
-struct compat_timespec {
- compat_time_t tv_sec;
- s32 tv_nsec;
-};
-
-struct compat_timeval {
- compat_time_t tv_sec;
- s32 tv_usec;
-};
-
struct compat_stat {
#ifdef __AARCH64EB__
short st_dev;
diff --git a/arch/arm64/include/asm/stat.h b/arch/arm64/include/asm/stat.h
index 15e35598ac40..eab738019707 100644
--- a/arch/arm64/include/asm/stat.h
+++ b/arch/arm64/include/asm/stat.h
@@ -20,6 +20,7 @@
#ifdef CONFIG_COMPAT
+#include
#include
/*
diff --git a/arch/arm64/kernel/hw_breakpoint.c
b/arch/arm64/kernel/hw_breakpoint.c
index 749f81779420..bfa2b78cf0e3 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -29,7 +29,6 @@
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
index 1d091d048d04..929fc369d0be 100644
--- a/arch/arm64/kernel/perf_regs.c
+++ b/arch/arm64/kernel/perf_regs.c
@@ -5,7 +5,7 @@
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/proc
[PATCH 0/9] posix_clocks: Prepare syscalls for 64 bit time_t conversion
The series is a preparation series for individual architectures to use 64 bit time_t syscalls in compat and 32 bit emulation modes. This is a follow up to the series Arnd Bergmann posted: https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html Big picture is as per the lwn article: https://lwn.net/Articles/643234/ The series is directed at converting posix clock syscalls: clock_gettime, clock_settime, clock_getres and clock_nanosleep to use a new data structure __kernel_timespec at syscall boundaries. __kernel_timespec maintains 64 bit time_t across all execution modes. vdso will be handled as part of each architecture when they enable support for 64 bit time_t. The compat syscalls are repurposed to provide backward compatibility by using them as native syscalls as well for 32 bit architectures. They will continue to use timespec at syscall boundaries. CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec or timespec at syscall boundaries. The series does the following: 1. Enable compat syscalls unconditionally. 2. Add a new __kernel_timespec type to be used as the data structure for all the new syscalls. 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in [1] and [2] to switch to new definition of __kernel_timespec. It is the same as struct timespec otherwise. Arnd Bergmann (1): y2038: introduce CONFIG_64BIT_TIME Deepa Dinamani (8): include: Move compat_timespec/ timeval to compat_time.h compat: Make compat helpers independent of CONFIG_COMPAT compat: enable compat_get/put_timespec64 always posix-clocks: Enable compat syscalls always include: Add new y2038 safe __kernel_timespec fix get_timespec64() for y2038 safe compat interfaces change time types to new y2038 safe __kernel_* types nanosleep: change time types to safe __kernel_* types arch/Kconfig | 11 arch/arm64/include/asm/compat.h| 11 arch/arm64/include/asm/stat.h | 1 + arch/arm64/kernel/hw_breakpoint.c | 1 - arch/arm64/kernel/perf_regs.c | 2 +- arch/arm64/kernel/process.c| 1 - arch/mips/include/asm/compat.h | 11 arch/mips/kernel/signal32.c| 2 +- arch/parisc/include/asm/compat.h | 11 arch/powerpc/include/asm/compat.h | 11 arch/powerpc/kernel/asm-offsets.c | 2 +- arch/powerpc/oprofile/backtrace.c | 2 +- arch/s390/hypfs/hypfs_sprp.c | 1 - arch/s390/include/asm/compat.h | 11 arch/s390/include/asm/elf.h| 3 +- arch/s390/kvm/priv.c | 1 - arch/s390/pci/pci_clp.c| 1 - arch/sparc/include/asm/compat.h| 11 arch/tile/include/asm/compat.h | 11 arch/x86/events/core.c | 2 +- arch/x86/include/asm/compat.h | 11 arch/x86/include/asm/ftrace.h | 2 +- arch/x86/include/asm/sys_ia32.h| 2 +- arch/x86/kernel/sys_x86_64.c | 2 +- drivers/s390/block/dasd_ioctl.c| 1 - drivers/s390/char/fs3270.c | 1 - drivers/s390/char/sclp_ctl.c | 1 - drivers/s390/char/vmcp.c | 1 - drivers/s390/cio/chsc_sch.c| 1 - drivers/s390/net/qeth_core_main.c | 2 +- drivers/staging/pi433/pi433_if.c | 2 +- include/linux/compat.h | 7 ++- include/linux/compat_time.h| 23 + include/linux/restart_block.h | 7 +-- include/linux/syscalls.h | 12 ++--- include/linux/time.h | 4 +- include/linux/time64.h | 10 +++- include/uapi/asm-generic/posix_types.h | 1 + include/uapi/linux/time.h | 7 +++ kernel/Makefile| 2 +- kernel/compat.c| 92 ++ kernel/time/hrtimer.c | 7 +-- kernel/time/posix-stubs.c | 12 ++--- kernel/time/posix-timers.c | 20 kernel/time/time.c | 10 +++- 45 files changed, 152 insertions(+), 195 deletions(-) create mode 100644 include/linux/compat_time.h base-commit: d9e0e63d9a6f88440eb201e1491fcf730272c706 -- 2.11.0 Cc: a...@kernel.org Cc: b...@kernel.crashing.org Cc: borntrae...@de.ibm.com Cc: catalin.mari...@arm.com Cc: cmetc...@mellanox.com Cc: coh...@redhat.com Cc: da...@davemloft.net Cc: del...@gmx.de Cc: de...@driverdev.osuosl.org Cc: gerald.schae...@de.ibm.com Cc: gre...@linuxfoundation.org Cc: heiko.carst...@de.ibm.com Cc: hoepp...@linux.vnet.ibm.com Cc: h...@zytor.com Cc: j...@parisc-linux.org Cc: j...@linux.vnet.ibm.com Cc: linux-...@vger.kernel.org Cc: linux-a...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-m...@linux-mips.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-...@lists.ozlabs.org Cc: linux-s...@vger.kernel.org Cc: mark.rutl...@arm.com Cc: mi...@redhat.com Cc: m...@ellerman.id.au Cc: ober...@linux.vnet.ibm.com Cc: oprofile-
Re: [PATCH] staging: speakup: selection: replace _manual_ swap with swap macro
Gustavo A. R. Silva, on ven. 10 nov. 2017 16:13:03 -0600, wrote:
> Make use of the swap macro instead of _manually_ swapping values
> and remove unnecessary variable tmp.
>
> This makes the code easier to read and maintain.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Acked-by: Samuel Thibault
> ---
> drivers/staging/speakup/selection.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/speakup/selection.c
> b/drivers/staging/speakup/selection.c
> index 66061b5..0ed1fef 100644
> --- a/drivers/staging/speakup/selection.c
> +++ b/drivers/staging/speakup/selection.c
> @@ -64,13 +64,8 @@ int speakup_set_selection(struct tty_struct *tty)
> ps = spk_ys * vc->vc_size_row + (spk_xs << 1);
> pe = spk_ye * vc->vc_size_row + (spk_xe << 1);
>
> - if (ps > pe) {
> - /* make sel_start <= sel_end */
> - int tmp = ps;
> -
> - ps = pe;
> - pe = tmp;
> - }
> + if (ps > pe)/* make sel_start <= sel_end */
> + swap(ps, pe);
>
> if (spk_sel_cons != vc_cons[fg_console].d) {
> speakup_clear_selection();
> --
> 2.7.4
>
--
Samuel
il faut combien de chevaux pour tirer une doloréan à 88 morph ?
***b vient de remarque que 88 mph c'est 142 km/h
ah
c'est pour ça qu'ils limitent à 130 km/h sur les autoroutes
c'est pour éviter que les gens voyagent dans le temps
probablement
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/9] include: Move compat_timespec/ timeval to compat_time.h
On Fri, 10 Nov 2017 14:42:51 -0800 Deepa Dinamani wrote: > diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h > index 09ad88572746..db25aa15b705 100644 > --- a/arch/x86/include/asm/ftrace.h > +++ b/arch/x86/include/asm/ftrace.h > @@ -49,7 +49,7 @@ int ftrace_int3_handler(struct pt_regs *regs); > #if !defined(__ASSEMBLY__) && !defined(COMPILE_OFFSETS) > > #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_IA32_EMULATION) > -#include > +#include > Acked-by: Steven Rostedt (VMware) -- Steve ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: pi433: Possible bug in rf69.c
Hi Dan,
I checked it on my local SVN. You are right. I submitted the code with '&'.
Accodring to a check-in message on my SVN, there was a bugreport end of
July and most probably a patch - either from me, you, Joseph Wright,
Colin King or Julia Lawall, changing '&' to '|'. I guess the patch for
some reason wasn't accepted, but fortunatley I introduced the change to
my SVN.
So from my point of view, we need a change from '&' to '|'.
I could prepare such a patch, but I am still unsure, which repo to use.
Shortly befor I fell ill, you proposed me to use Gregs staging for my
further development. But Colin yesterday was working on a repo, called
linux-next.
Can you (or anyone else) please tell me, when (or for which kind of
patches) to use the Gregs staging and wehen (or for which kind of
patches) to use the linux-next? Sorry for not being familiar with that
stuff!
Thanks a lot,
Marcus
Am 10.11.2017 um 20:32 schrieb Dan Carpenter:
> On Fri, Nov 10, 2017 at 06:23:32PM +0100, Marcus Wolf wrote:
>> Hi everybody!
>>
>> Just comparing the master of Gregs statging of pi433 with my local SVN
>> to review all changes, that were done the last monthes.
>>
>> I am not sure, but maybe we imported a bug in rf69.c lines 378 and
>> following:
>>
>> Gregs repo:
>> case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
>> ~MASK_LNA_GAIN) & LNA_GAIN_AUTO) );
>> my repo:
>> case automatic: return WRITE_REG(REG_LNA, ( (READ_REG(REG_LNA) &
>> ~MASK_LNA_GAIN) | LNA_GAIN_AUTO) );
>
> I edited the lines for clarity. The difference is that your repo does
> a bitwise OR "| LNA_GAIN_AUTO" and the kernel.org code does a bitwise
> "& LNA_GAIN_AUTO".
>
> The kernel repo hasn't changed since you sent us the driver in commit
> 874bcba65f9a ('staging: pi433: New driver'). I agree that & doesn't
> seem to make sense and I'm disapointed that it doesn't cause a Smatch
> warning.
>
> But LNA_GAIN_AUTO is zero so maybe | BIT(LNA_GAIN_AUTO) was intended
> instead of | LNA_GAIN_AUTO. I don't know... No one on this list knows
> the answer probably. :/
>
> regards,
> dan caprenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
