Re: [PATCH] staging: sm750fb: cleanup white space and indent
On Thu, Apr 23, 2015 at 05:04:08PM -0400, Charles Rose wrote: > This patch fixes "space prohibited" errors reported by checkpatch.pl > and related indentation. The module builds without error. > > Signed-off-by: Charles Rose > - if ( x == 800 && y == 600 ) > - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL41); > + if (x == 800 && y == 600) > + dispControl = FIELD_SET(dispControl, > + CRT_DISPLAY_CTRL, CLK, PLL41); Alignment should match open parenthesis regards sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 3/6] Drivers: hv: vmbus: decrease num_sc on subchannel removal
> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, April 21, 2015 22:28 > To: KY Srinivasan > Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org; Dexuan Cui > Subject: [PATCH 3/6] Drivers: hv: vmbus: decrease num_sc on subchannel > removal > > It is unlikely that that host will ask us to close only one subchannel for a > device but let's be consistent. Do both num_sc++ and num_sc-- with > channel->lock to be on the safe side. > > Signed-off-by: Vitaly Kuznetsov > --- > drivers/hv/channel_mgmt.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c > index b28cbdf..8b4b561 100644 > --- a/drivers/hv/channel_mgmt.c > +++ b/drivers/hv/channel_mgmt.c > @@ -205,6 +205,7 @@ void hv_process_channel_removal(struct > vmbus_channel *channel, u32 relid) > primary_channel = channel->primary_channel; > spin_lock_irqsave(&primary_channel->lock, flags); > list_del(&channel->sc_list); > + channel->num_sc--; Hi Vitaly, Here it should be primary_channel->num_sc--; Thanks, -- Dexuan > spin_unlock_irqrestore(&primary_channel->lock, flags); > } > free_channel(channel); > @@ -265,8 +266,8 @@ static void vmbus_process_offer(struct > vmbus_channel *newchannel) > newchannel->primary_channel = channel; > spin_lock_irqsave(&channel->lock, flags); > list_add_tail(&newchannel->sc_list, &channel- > >sc_list); > - spin_unlock_irqrestore(&channel->lock, flags); > channel->num_sc++; > + spin_unlock_irqrestore(&channel->lock, flags); > } else > goto err_free_chan; > } > -- > 1.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: fbtft: Disable DMA support if DMA is not available
On Thu, Apr 23, 2015 at 9:17 PM, Greg Kroah-Hartman
wrote:
> On Thu, Apr 23, 2015 at 08:47:15PM +0200, Geert Uytterhoeven wrote:
>> If NO_DMA=y:
>>
>> drivers/built-in.o: In function `fbtft_framebuffer_alloc':
>> (.text+0xb53cae): undefined reference to `dmam_alloc_coherent'
>>
>> As DMA support is already optional, make it depend on HAS_DMA.
>>
>> If !HAS_DMA, "dma" will always be false, and the compiler will optimize
>> away the call to dmam_alloc_coherent().
>
> Oh that's "sneaky" and not good, let's just make this driver be
> dependant on DMA and be done with it. I don't like to rely on the
> optimizer to get things to work properly.
Alternatively, I can stick in one more #ifdef, to no longer rely on the compiler
optimization?
AFAICS, the driver itself considers DMA optional, and will work without.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: fbtft: Disable DMA support if DMA is not available
On Fri, Apr 24, 2015 at 09:15:00AM +0200, Geert Uytterhoeven wrote: > On Thu, Apr 23, 2015 at 9:17 PM, Greg Kroah-Hartman > wrote: > > On Thu, Apr 23, 2015 at 08:47:15PM +0200, Geert Uytterhoeven wrote: > >> If NO_DMA=y: > >> > >> drivers/built-in.o: In function `fbtft_framebuffer_alloc': > >> (.text+0xb53cae): undefined reference to `dmam_alloc_coherent' > >> > >> As DMA support is already optional, make it depend on HAS_DMA. > >> > >> If !HAS_DMA, "dma" will always be false, and the compiler will optimize > >> away the call to dmam_alloc_coherent(). > > > > Oh that's "sneaky" and not good, let's just make this driver be > > dependant on DMA and be done with it. I don't like to rely on the > > optimizer to get things to work properly. > > Alternatively, I can stick in one more #ifdef, to no longer rely on the > compiler > optimization? That would be better. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: 答复: [PATCH] staging: sm750: Fixthe Makefile option error
Hi, Sudip, Upstream driver still can't show logo, we are debugging. Huacai -- Original -- From: "Sudip Mukherjee"; Date: Thu, Apr 23, 2015 09:45 PM To: "陈华才"; Cc: "Teddy Wang 王力强"; "Binbin Zhou"; "Greg Kroah-Hartman"; "devel"; "Fuxin Zhang"; Subject: Re: 答复: [PATCH] staging: sm750: Fixthe Makefile option error On Thu, Apr 23, 2015 at 10:29:48AM +0530, Sudip Mukherjee wrote: > On Thu, Apr 23, 2015 at 12:43:40PM +0800, 陈华才 wrote: > > Hi, Teddy, > > > > In the code It seems that only SM718/SM750 is supported in Sudip's driver. > > Hi Huacai, > > The driver that Teddy gave me originally was a mix driver of > SM712/SM750/SM502. The one in staging is only SM750, since we already > have SM712 in staging. It will not support SM718 also, few places where > the name is still left will be cleared. > > I was looking at your driver yesterday, hardware initializaion parts I > have not yet seen, but just on initial look, your driver is not > supporting dual head. > If displaying of logo is the only problem that you are facing with this > driver, then we can see how to fix that. Hi Huacai, I was testing for the logo problem that you mentioned. But I am getting the boot time penguin logo in my test system. Just make sure you have CONFIG_LOGO=y and CONFIG_FB_SM750=y . logo will not show if you have CONFIG_FB_SM750=m. regards sudip > > > regards > sudip > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: fbtft: Disable DMA support if DMA is not available
If NO_DMA=y:
drivers/built-in.o: In function `fbtft_framebuffer_alloc':
(.text+0xb53cae): undefined reference to `dmam_alloc_coherent'
As DMA support is already optional, make it depend on HAS_DMA.
Signed-off-by: Geert Uytterhoeven
---
v3:
- Use an #ifdef instead of relying on compiler optimization,
v2:
- Explain better how it works,
- Keep the "= false" to avoid breakage (seen not only with gcc 4.1.2,
but also with 4.6.3 and 4.9.0).
---
drivers/staging/fbtft/fbtft-core.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 53b748be27124793..ce645213a5393b8b 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -47,9 +47,11 @@ static unsigned long debug;
module_param(debug, ulong, 0);
MODULE_PARM_DESC(debug, "override device debug level");
+#ifdef CONFIG_HAS_DMA
static bool dma = true;
module_param(dma, bool, 0);
MODULE_PARM_DESC(dma, "Use DMA buffer");
+#endif
void fbtft_dbg_hex(const struct device *dev, int groupsize,
@@ -856,10 +858,13 @@ struct fb_info *fbtft_framebuffer_alloc(struct
fbtft_display *display,
#endif
if (txbuflen > 0) {
+#ifdef CONFIG_HAS_DMA
if (dma) {
dev->coherent_dma_mask = ~0;
txbuf = dmam_alloc_coherent(dev, txbuflen,
&par->txbuf.dma, GFP_DMA);
- } else {
+ } else
+#endif
+ {
txbuf = devm_kzalloc(par->info->device, txbuflen,
GFP_KERNEL);
}
if (!txbuf)
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: declare file operations structure as static
The fops structure is referenced only locally and hence could be made static
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/lustre/lustre/mdc/lproc_mdc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
index acfe08e..fbeddf9 100644
--- a/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
+++ b/drivers/staging/lustre/lustre/mdc/lproc_mdc.c
@@ -147,7 +147,7 @@ static ssize_t mdc_kuc_write(struct file *file,
return count;
}
-struct file_operations mdc_kuc_fops = {
+static const struct file_operations mdc_kuc_fops = {
.open = mdc_kuc_open,
.write = mdc_kuc_write,
.release= single_release,
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: 答复: [PATCH] staging: sm750: Fixthe Makefile option error
On Fri, Apr 24, 2015 at 03:33:58PM +0800, 陈华才 wrote: > Hi, Sudip, > > Upstream driver still can't show logo, we are debugging. Hi Huacai, I checked with the upstream driver only. I checked with next-20150423 and it showed me the penguin logo on upper left hand corner of my screen when CONFIG_FB_SM750=y. only extra thing was that your patch of the Makefile was applied. maybe you can consider gifting me one your notepads so that I can also see the problem :) regards sudip > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
payment notification.
WESTERN UNION MONEY TRANSFER ITALY PAY-OUT CENTER Dear Western Union Beneficiary, UNITED NATIONS PAYMENT NOTIFICATION. We wish to inform you that the United Nations (UN) has authorized us to remit to you a total amount of $500,000.00, (Five Hundred Thousand United States Dollars). Your Cash prize was paid out to us by the United Nations, and they have successfully succeeded in depositing your whole funds with us Here at Western Union Italy. They have now ordered us to take full responsibility in the transfer process of your funds and thus commence the immediate remittance of your funds to you. Be duly informed that because of our Western Union transfer policy, your funds will be paid to you via our Western Union Daily Transfer limit of $4,400.00 USD. This means that you will Continuously receive a daily amount of $5,600.00 USD, and this amount Can be collected from any of our numerous Western Union outlets in your current location. To begin the claim process of your daily payment as stated above, kindly furnish us with the following; Full Name: Address: Phone Number: Upon the receipt of the above mentioned details, your first transaction will be activated and we shall then Proceed to provide you with the Money Transfer Control Number (MTCN) for the First installment and we will continue to email you others after 12 hours of Receiving each payment. For more information on your payment status; Contact Person Angela Moretti For Dario Pellizzari OR call our 24 hours Helpline @ +39 339 1292924 , for any inquiries on the above message. Yours truly, Angela Moretti. For: Western Union Italy. WESTERN UNION... Over 380,000 Outlets Worldwide ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: sm750fb: cleanup white space and indent
On Thu, Apr 23, 2015 at 05:04:08PM -0400, Charles Rose wrote: > This patch fixes "space prohibited" errors reported by checkpatch.pl > and related indentation. The module builds without error. That's two different things, can you break this up into one "logical" patch per thing you are changing here? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 4/6] Drivers: hv: vmbus: move init_vp_index() call to vmbus_process_offer()
> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, April 21, 2015 22:28 > To: KY Srinivasan > Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org; Dexuan Cui > Subject: [PATCH 4/6] Drivers: hv: vmbus: move init_vp_index() call to > vmbus_process_offer() > > We need to call init_vp_index() after we added the channel to the > appropriate > list (global or subchannel) to be able to use this information when assigning > the channel to the particular vcpu. To do so we need to move a couple of > functions around. The only real change is the init_vp_index() call. This is a > small refactoring without a functional change. IMO we don't have to move such a big block of code -- we only need to add a forward function declaration of init_vp_index()? Thanks, -- Dexuan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/6] Drivers: hv: vmbus: decrease num_sc on subchannel removal
Dexuan Cui writes: >> -Original Message- >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] >> Sent: Tuesday, April 21, 2015 22:28 >> To: KY Srinivasan >> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- >> ker...@vger.kernel.org; Dexuan Cui >> Subject: [PATCH 3/6] Drivers: hv: vmbus: decrease num_sc on subchannel >> removal >> >> It is unlikely that that host will ask us to close only one subchannel for a >> device but let's be consistent. Do both num_sc++ and num_sc-- with >> channel->lock to be on the safe side. >> >> Signed-off-by: Vitaly Kuznetsov >> --- >> drivers/hv/channel_mgmt.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c >> index b28cbdf..8b4b561 100644 >> --- a/drivers/hv/channel_mgmt.c >> +++ b/drivers/hv/channel_mgmt.c >> @@ -205,6 +205,7 @@ void hv_process_channel_removal(struct >> vmbus_channel *channel, u32 relid) >> primary_channel = channel->primary_channel; >> spin_lock_irqsave(&primary_channel->lock, flags); >> list_del(&channel->sc_list); >> +channel->num_sc--; > > Hi Vitaly, > Here it should be > primary_channel->num_sc--; Ah, of course. I'll fix and resend, thanks! > > Thanks, > -- Dexuan > >> spin_unlock_irqrestore(&primary_channel->lock, flags); >> } >> free_channel(channel); >> @@ -265,8 +266,8 @@ static void vmbus_process_offer(struct >> vmbus_channel *newchannel) >> newchannel->primary_channel = channel; >> spin_lock_irqsave(&channel->lock, flags); >> list_add_tail(&newchannel->sc_list, &channel- >> >sc_list); >> -spin_unlock_irqrestore(&channel->lock, flags); >> channel->num_sc++; >> +spin_unlock_irqrestore(&channel->lock, flags); >> } else >> goto err_free_chan; >> } >> -- >> 1.9.3 -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 5/6] Drivers: hv: vmbus: distribute subchannels among all vcpus
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Tuesday, April 21, 2015 22:28
> To: KY Srinivasan
> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; Dexuan Cui
> Subject: [PATCH 5/6] Drivers: hv: vmbus: distribute subchannels among all
> vcpus
>
> Primary channels are distributed evenly across all vcpus we have. When the
> host asks us to create subchannels it usually makes us num_cpus-1 offers
Hi Vitaly,
AFAIK, in the VSP of storvsc, the number of subchannel is
(the_number_of_vcpus - 1) / 4.
This means for a 8-vCPU guest, there is only 1 subchannel.
Your new algorithm tends to make the vCPUs with small-number busier:
e.g., in the 8-vCPU case, assuming we have 4 SCSI controllers:
vCPU0: scsi0's PrimaryChannel (P)
vCPU1: scsi0's SubChannel (S) + scsi1's P
vCPU2: scsi1's S + scsi2's P
vCPU3: scsi2's S + scsi3's P
vCPU4: scsi3's S
vCPU5, 6 and 7 are idle.
In this special case, the existing algorithm is better. :-)
However, I do like this idea in your patch, that is, making sure a device's
primary/sub channels are assigned to differents vCPUs.
I'm just wondering if we should use an even better (and complex) algorithm :-)
PS, yeah, for netvsc(HV_NIC_GUID), the number of SC is indeed
the_number_vcpus -1. I'm not sure about the upcoming HV_ND_GUID --
maybe it's the same as HV_NIC_GUID.
Thanks,
-- Dexuan
> and we are supposed to distribute the work evenly among the channel
> itself and all its subchannels. Make sure they are all assigned to
> different vcpus.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/hv/channel_mgmt.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 8f2761f..daa6417 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -270,6 +270,8 @@ static void init_vp_index(struct vmbus_channel
> *channel,
> int i;
> bool perf_chn = false;
> u32 max_cpus = num_online_cpus();
> + struct vmbus_channel *primary = channel->primary_channel, *prev;
> + unsigned long flags;
>
> for (i = IDE; i < MAX_PERF_CHN; i++) {
> if (!memcmp(type_guid->b, hp_devs[i].guid,
> @@ -290,7 +292,32 @@ static void init_vp_index(struct vmbus_channel
> *channel,
> channel->target_vp = 0;
> return;
> }
> - cur_cpu = (++next_vp % max_cpus);
> +
> + /*
> + * Primary channels are distributed evenly across all vcpus we have.
> + * When the host asks us to create subchannels it usually makes us
> + * num_cpus-1 offers and we are supposed to distribute the work
> evenly
> + * among the channel itself and all its subchannels. Make sure they
> are
> + * all assigned to different vcpus.
> + */
> + if (!primary)
> + cur_cpu = (++next_vp % max_cpus);
> + else {
> + /*
> + * Let's assign the first subchannel of a channel to the
> + * primary->target_cpu+1 and all the subsequent channels
> to
> + * the prev->target_cpu+1.
> + */
> + spin_lock_irqsave(&primary->lock, flags);
> + if (primary->num_sc == 1)
> + cur_cpu = (primary->target_cpu + 1) % max_cpus;
> + else {
> + prev = list_prev_entry(channel, sc_list);
> + cur_cpu = (prev->target_cpu + 1) % max_cpus;
> + }
> + spin_unlock_irqrestore(&primary->lock, flags);
> + }
> +
> channel->target_cpu = cur_cpu;
> channel->target_vp = hv_context.vp_index[cur_cpu];
> }
> --
> 1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 6/6] Drivers: hv: vmbus: do a fair round robin when selecting an outgoing channel
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Tuesday, April 21, 2015 22:28
> To: KY Srinivasan
> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org; Dexuan Cui
> Subject: [PATCH 6/6] Drivers: hv: vmbus: do a fair round robin when
> selecting an outgoing channel
>
> vmbus_get_outgoing_channel() implements the following algorithm for
> selecting
> an outgoing channel (despite the comment before the function saying it
> distributes the load equally):
Yeah, I also found the issue.
> 1) If we have no subchannels return the primary channel;
> 2) If primary->next_oc is grater than primary->num_sc reset the primary-
> >next_oc
>to 0 and return the primary channel;
> 3) Aim for the primary->next_oc subchannel, increment primary->next_oc;
> 4) Loop through all opened subchannels. If we see a channel which has
> target_cpu == current_cpu return it. If we reached the primary->next_oc'th
> open subchannel return it;
> 5) Return the primary channel.
> The implementation also skips the subchannel No. 0 unless it matches the
> current
> cpu as we assign i to 1 in the initialization.
>
> This is not a fair round robin as subchannels in the beginning of the list are
> more likely to be returned and checking for current cpu aslo creates
I suppose the current algorithm is trying to make use of cache locality?
KY may share more information.
> additional
> complexity. Simplify the vmbus_get_outgoing_channel() function, make it
> do what the comment before it says.
Hi Vitaly,
It looks your algorithm also has an issue:
Assuming primary->num_sc == 3 (SC1, SC2, SC3)
1st time: we choose SC1 and primary->next_oc is set to 1.
2nd time: we choose SC2 and primary->next_oc is set to 2.
3rd time: we choose SC3 and primary->next_oc is set to 3.
4th time and later: since i varies among 1~3 and can't be bigger than 3,
we always choose the primary channel.
BTW, IMO it's not easy to achieve complete fairness because
vmbus_get_outgoing_channel() can run simultaneously on different
CPUs (so primary->next_oc can be modified at the same time by multiple
CPUs), and we believe it should be lockless.
Maybe atomic_t can help(?)
Thanks,
-- Dexuan
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/hv/channel_mgmt.c | 27 +--
> 1 file changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index daa6417..df82442 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -827,39 +827,30 @@ cleanup:
> struct vmbus_channel *vmbus_get_outgoing_channel(struct
> vmbus_channel *primary)
> {
> struct list_head *cur, *tmp;
> - int cur_cpu;
> struct vmbus_channel *cur_channel;
> - struct vmbus_channel *outgoing_channel = primary;
> - int next_channel;
> - int i = 1;
> + int i = 0;
>
> if (list_empty(&primary->sc_list))
> - return outgoing_channel;
> + return primary;
>
> - next_channel = primary->next_oc++;
> -
> - if (next_channel > (primary->num_sc)) {
> + if (primary->next_oc > primary->num_sc) {
> primary->next_oc = 0;
> - return outgoing_channel;
> + return primary;
> }
>
> - cur_cpu = hv_context.vp_index[get_cpu()];
> - put_cpu();
> list_for_each_safe(cur, tmp, &primary->sc_list) {
> + i++;
> cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
> if (cur_channel->state != CHANNEL_OPENED_STATE)
> continue;
>
> - if (cur_channel->target_vp == cur_cpu)
> - return cur_channel;
> -
> - if (i == next_channel)
> + if (i > primary->next_oc) {
> + primary->next_oc = i;
> return cur_channel;
> -
> - i++;
> + }
> }
>
> - return outgoing_channel;
> + return primary;
> }
> EXPORT_SYMBOL_GPL(vmbus_get_outgoing_channel);
>
> --
> 1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4/6] Drivers: hv: vmbus: move init_vp_index() call to vmbus_process_offer()
Dexuan Cui writes: >> -Original Message- >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] >> Sent: Tuesday, April 21, 2015 22:28 >> To: KY Srinivasan >> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- >> ker...@vger.kernel.org; Dexuan Cui >> Subject: [PATCH 4/6] Drivers: hv: vmbus: move init_vp_index() call to >> vmbus_process_offer() >> >> We need to call init_vp_index() after we added the channel to the >> appropriate >> list (global or subchannel) to be able to use this information when assigning >> the channel to the particular vcpu. To do so we need to move a couple of >> functions around. The only real change is the init_vp_index() call. This is a >> small refactoring without a functional change. > > IMO we don't have to move such a big block of code -- we only need to add a > forward function declaration of init_vp_index()? Ok, let's make the change smaller. I'll fix and resend, thanks! > > Thanks, > -- Dexuan -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6] Drivers: hv: vmbus: do a fair round robin when selecting an outgoing channel
Dexuan Cui writes:
>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Tuesday, April 21, 2015 22:28
>> To: KY Srinivasan
>> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux-
>> ker...@vger.kernel.org; Dexuan Cui
>> Subject: [PATCH 6/6] Drivers: hv: vmbus: do a fair round robin when
>> selecting an outgoing channel
>>
>> vmbus_get_outgoing_channel() implements the following algorithm for
>> selecting
>> an outgoing channel (despite the comment before the function saying it
>> distributes the load equally):
>
> Yeah, I also found the issue.
>
>> 1) If we have no subchannels return the primary channel;
>> 2) If primary->next_oc is grater than primary->num_sc reset the primary-
>> >next_oc
>>to 0 and return the primary channel;
>> 3) Aim for the primary->next_oc subchannel, increment primary->next_oc;
>> 4) Loop through all opened subchannels. If we see a channel which has
>> target_cpu == current_cpu return it. If we reached the primary->next_oc'th
>> open subchannel return it;
>> 5) Return the primary channel.
>> The implementation also skips the subchannel No. 0 unless it matches the
>> current
>> cpu as we assign i to 1 in the initialization.
>>
>> This is not a fair round robin as subchannels in the beginning of the list
>> are
>> more likely to be returned and checking for current cpu aslo creates
>
> I suppose the current algorithm is trying to make use of cache locality?
> KY may share more information.
>
>> additional
>> complexity. Simplify the vmbus_get_outgoing_channel() function, make it
>> do what the comment before it says.
>
> Hi Vitaly,
> It looks your algorithm also has an issue:
> Assuming primary->num_sc == 3 (SC1, SC2, SC3)
> 1st time: we choose SC1 and primary->next_oc is set to 1.
> 2nd time: we choose SC2 and primary->next_oc is set to 2.
> 3rd time: we choose SC3 and primary->next_oc is set to 3.
> 4th time and later: since i varies among 1~3 and can't be bigger than 3,
> we always choose the primary channel.
You're right, it seems 'if (primary->next_oc > primary->num_sc)' is
off-by-one, it should be >=
>
> BTW, IMO it's not easy to achieve complete fairness because
> vmbus_get_outgoing_channel() can run simultaneously on different
> CPUs (so primary->next_oc can be modified at the same time by multiple
> CPUs), and we believe it should be lockless.
> Maybe atomic_t can help(?)
This thing bothered me a bit but then I realized that we don't actually
care - doing a mistake once is better than suffering from the slowness
of locks/atomics. I'd suggest we keep it this way (with the fix
mentioned above).
Thanks!
>
> Thanks,
> -- Dexuan
>
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/hv/channel_mgmt.c | 27 +--
>> 1 file changed, 9 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
>> index daa6417..df82442 100644
>> --- a/drivers/hv/channel_mgmt.c
>> +++ b/drivers/hv/channel_mgmt.c
>> @@ -827,39 +827,30 @@ cleanup:
>> struct vmbus_channel *vmbus_get_outgoing_channel(struct
>> vmbus_channel *primary)
>> {
>> struct list_head *cur, *tmp;
>> -int cur_cpu;
>> struct vmbus_channel *cur_channel;
>> -struct vmbus_channel *outgoing_channel = primary;
>> -int next_channel;
>> -int i = 1;
>> +int i = 0;
>>
>> if (list_empty(&primary->sc_list))
>> -return outgoing_channel;
>> +return primary;
>>
>> -next_channel = primary->next_oc++;
>> -
>> -if (next_channel > (primary->num_sc)) {
>> +if (primary->next_oc > primary->num_sc) {
>> primary->next_oc = 0;
>> -return outgoing_channel;
>> +return primary;
>> }
>>
>> -cur_cpu = hv_context.vp_index[get_cpu()];
>> -put_cpu();
>> list_for_each_safe(cur, tmp, &primary->sc_list) {
>> +i++;
>> cur_channel = list_entry(cur, struct vmbus_channel, sc_list);
>> if (cur_channel->state != CHANNEL_OPENED_STATE)
>> continue;
>>
>> -if (cur_channel->target_vp == cur_cpu)
>> -return cur_channel;
>> -
>> -if (i == next_channel)
>> +if (i > primary->next_oc) {
>> +primary->next_oc = i;
>> return cur_channel;
>> -
>> -i++;
>> +}
>> }
>>
>> -return outgoing_channel;
>> +return primary;
>> }
>> EXPORT_SYMBOL_GPL(vmbus_get_outgoing_channel);
>>
>> --
>> 1.9.3
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/6] Drivers: hv: vmbus: distribute subchannels among all vcpus
Dexuan Cui writes:
>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Tuesday, April 21, 2015 22:28
>> To: KY Srinivasan
>> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux-
>> ker...@vger.kernel.org; Dexuan Cui
>> Subject: [PATCH 5/6] Drivers: hv: vmbus: distribute subchannels among all
>> vcpus
>>
>> Primary channels are distributed evenly across all vcpus we have. When the
>> host asks us to create subchannels it usually makes us num_cpus-1 offers
>
> Hi Vitaly,
> AFAIK, in the VSP of storvsc, the number of subchannel is
> (the_number_of_vcpus - 1) / 4.
>
> This means for a 8-vCPU guest, there is only 1 subchannel.
>
> Your new algorithm tends to make the vCPUs with small-number busier:
> e.g., in the 8-vCPU case, assuming we have 4 SCSI controllers:
> vCPU0: scsi0's PrimaryChannel (P)
> vCPU1: scsi0's SubChannel (S) + scsi1's P
> vCPU2: scsi1's S + scsi2's P
> vCPU3: scsi2's S + scsi3's P
> vCPU4: scsi3's S
> vCPU5, 6 and 7 are idle.
>
> In this special case, the existing algorithm is better. :-)
>
> However, I do like this idea in your patch, that is, making sure a device's
> primary/sub channels are assigned to differents vCPUs.
Under special circumstances with the current code we can end up with
having all subchannels on the same vCPU with the primary channel I guess
:-) This is not something common, but possible.
>
> I'm just wondering if we should use an even better (and complex)
> algorithm :-)
The question here is - does sticking to the current vCPU help? If it
does, I can suggest the following (I think I even mentioned that in my
PATCH 00): first we try to find a (sub)channel with target_cpu ==
current_vcpu and only when we fail we do the round robin. I'd like to
hear K.Y.'s opinion here as he's the original author :-)
>
> PS, yeah, for netvsc(HV_NIC_GUID), the number of SC is indeed
> the_number_vcpus -1. I'm not sure about the upcoming HV_ND_GUID --
> maybe it's the same as HV_NIC_GUID.
>
> Thanks,
> -- Dexuan
>
>> and we are supposed to distribute the work evenly among the channel
>> itself and all its subchannels. Make sure they are all assigned to
>> different vcpus.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/hv/channel_mgmt.c | 29 -
>> 1 file changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
>> index 8f2761f..daa6417 100644
>> --- a/drivers/hv/channel_mgmt.c
>> +++ b/drivers/hv/channel_mgmt.c
>> @@ -270,6 +270,8 @@ static void init_vp_index(struct vmbus_channel
>> *channel,
>> int i;
>> bool perf_chn = false;
>> u32 max_cpus = num_online_cpus();
>> + struct vmbus_channel *primary = channel->primary_channel, *prev;
>> + unsigned long flags;
>>
>> for (i = IDE; i < MAX_PERF_CHN; i++) {
>> if (!memcmp(type_guid->b, hp_devs[i].guid,
>> @@ -290,7 +292,32 @@ static void init_vp_index(struct vmbus_channel
>> *channel,
>> channel->target_vp = 0;
>> return;
>> }
>> - cur_cpu = (++next_vp % max_cpus);
>> +
>> + /*
>> + * Primary channels are distributed evenly across all vcpus we have.
>> + * When the host asks us to create subchannels it usually makes us
>> + * num_cpus-1 offers and we are supposed to distribute the work
>> evenly
>> + * among the channel itself and all its subchannels. Make sure they
>> are
>> + * all assigned to different vcpus.
>> + */
>> + if (!primary)
>> + cur_cpu = (++next_vp % max_cpus);
>> + else {
>> + /*
>> + * Let's assign the first subchannel of a channel to the
>> + * primary->target_cpu+1 and all the subsequent channels
>> to
>> + * the prev->target_cpu+1.
>> + */
>> + spin_lock_irqsave(&primary->lock, flags);
>> + if (primary->num_sc == 1)
>> + cur_cpu = (primary->target_cpu + 1) % max_cpus;
>> + else {
>> + prev = list_prev_entry(channel, sc_list);
>> + cur_cpu = (prev->target_cpu + 1) % max_cpus;
>> + }
>> + spin_unlock_irqrestore(&primary->lock, flags);
>> + }
>> +
>> channel->target_cpu = cur_cpu;
>> channel->target_vp = hv_context.vp_index[cur_cpu];
>> }
>> --
>> 1.9.3
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 0/3] Drivers: hv: vmbus: additional fixes for the setup/teardown path
> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Wednesday, April 22, 2015 0:22 > To: KY Srinivasan > Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org; Dexuan Cui; Dan Carpenter > Subject: [PATCH v2 0/3] Drivers: hv: vmbus: additional fixes for the > setup/teardown path > > Changes since v1 (PATCH 1/3): > - Return -EAGAIN instead of open_info->response.open_result.status > [Dexuan Cui] > - Avoid 'if (ret != 0)' statement [Dan Carpenter] > > Original description: > K. Y., > > Here are 3 additional patches for your "[PATCH 0/5] Drivers: hv: vmbus: > Cleanup > the vmbus unload path" series (with the fix I suggested). I tested the whole > set on Gen2 Win2012R2 guest, load/unload path seems being stable. Can > you > please take a look? > > Thanks, > > Vitaly Kuznetsov (3): > Drivers: hv: vmbus: do cleanup on all vmbus_open() failure paths > Drivers: hv: vmbus: kill tasklets on module unload > Drivers: hv: vmbus: setup irq after synic is initialized > > drivers/hv/channel.c | 13 ++--- > drivers/hv/vmbus_drv.c | 10 +++--- > 2 files changed, 13 insertions(+), 10 deletions(-) The patchset seems good to me. Reviewed-by: Dexuan Cui Thanks, -- Dexuan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/3] Drivers: hv: vmbus: additional fixes for the setup/teardown path
Dexuan Cui writes: >> -Original Message- >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] >> Sent: Wednesday, April 22, 2015 0:22 >> To: KY Srinivasan >> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- >> ker...@vger.kernel.org; Dexuan Cui; Dan Carpenter >> Subject: [PATCH v2 0/3] Drivers: hv: vmbus: additional fixes for the >> setup/teardown path >> >> Changes since v1 (PATCH 1/3): >> - Return -EAGAIN instead of open_info->response.open_result.status >> [Dexuan Cui] >> - Avoid 'if (ret != 0)' statement [Dan Carpenter] >> >> Original description: >> K. Y., >> >> Here are 3 additional patches for your "[PATCH 0/5] Drivers: hv: vmbus: >> Cleanup >> the vmbus unload path" series (with the fix I suggested). I tested the whole >> set on Gen2 Win2012R2 guest, load/unload path seems being stable. Can >> you >> please take a look? >> >> Thanks, >> >> Vitaly Kuznetsov (3): >> Drivers: hv: vmbus: do cleanup on all vmbus_open() failure paths >> Drivers: hv: vmbus: kill tasklets on module unload >> Drivers: hv: vmbus: setup irq after synic is initialized >> >> drivers/hv/channel.c | 13 ++--- >> drivers/hv/vmbus_drv.c | 10 +++--- >> 2 files changed, 13 insertions(+), 10 deletions(-) > > The patchset seems good to me. > > Reviewed-by: Dexuan Cui > Thanks! -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: Remove unwanted lines of code
On 23/04/15 20:14, Gujulan Elango, Hari Prasath (H.) wrote:
This patch removes a few lines of code & retains the same functionality
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/comedi/drivers/cb_pcimdda.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcimdda.c
b/drivers/staging/comedi/drivers/cb_pcimdda.c
index a4781db..19210d8 100644
--- a/drivers/staging/comedi/drivers/cb_pcimdda.c
+++ b/drivers/staging/comedi/drivers/cb_pcimdda.c
@@ -164,11 +164,7 @@ static int cb_pcimdda_auto_attach(struct comedi_device
*dev,
s = &dev->subdevices[1];
/* digital i/o subdevice */
- ret = subdev_8255_init(dev, s, NULL, PCIMDDA_8255_BASE_REG);
- if (ret)
- return ret;
-
- return 0;
+ return subdev_8255_init(dev, s, NULL, PCIMDDA_8255_BASE_REG);
}
static struct comedi_driver cb_pcimdda_driver = {
Reviewed-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: gsc_hdpi: Remove dead code
On 24/04/15 07:58, Gujulan Elango, Hari Prasath (H.) wrote:
This patch removes commented code from this driver.
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/comedi/drivers/gsc_hpdi.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/staging/comedi/drivers/gsc_hpdi.c
b/drivers/staging/comedi/drivers/gsc_hpdi.c
index 3cb6409..d9715ea 100644
--- a/drivers/staging/comedi/drivers/gsc_hpdi.c
+++ b/drivers/staging/comedi/drivers/gsc_hpdi.c
@@ -135,13 +135,6 @@ static const struct hpdi_board hpdi_boards[] = {
.device_id = PCI_DEVICE_ID_PLX_9080,
.subdevice_id = 0x2400,
},
-#if 0
- {
- .name = "pxi-hpdi32",
- .device_id = 0x9656,
- .subdevice_id = 0x2705,
-},
-#endif
};
struct hpdi_private {
Reviewed-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: lustre: Avoid creating two variables
This patch avoids creating two variables in the final assembly output
i.e. a string and a pointer to the string.
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
index c8e2930..8882707 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
@@ -241,7 +241,7 @@ void cfs_print_to_console(struct ptldebug_header *hdr, int
mask,
const char *buf, int len, const char *file,
const char *fn)
{
- char *prefix = "Lustre", *ptype = NULL;
+ char prefix[] = "Lustre", *ptype = NULL;
if ((mask & D_EMERG) != 0) {
prefix = dbghdr_to_err_string(hdr);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: MAINTAINERS: add maintainer for wilc1000 device
Add myself as maintainer for atmel wilc1000 Signed-off-by: Johnny Kim Signed-off-by: Rachel Kim Signed-off-by: Dean Lee Signed-off-by: Chris Park --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1b8263c..e4252b5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9473,6 +9473,16 @@ M: Forest Bond S: Odd Fixes F: drivers/staging/vt665?/ +STAGING - WILC1000 WIFI DRIVER +M: Johnny Kim +M: Rachel Kim +M: Dean Lee +M: Chris Park +L: de...@driverdev.osuosl.org +L: linux-wirel...@vger.kernel.org +S: Supported +F: drivers/staging/atmel/wilc1000/ + STAGING - XGI Z7,Z9,Z11 PCI DISPLAY DRIVER M: Arnaud Patard S: Odd Fixes -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: lustre: Avoid creating two variables
On 24 April 2015 at 15:46, Gujulan Elango, Hari Prasath (H.)
wrote:
> This patch avoids creating two variables in the final assembly output
> i.e. a string and a pointer to the string.
>
> Signed-off-by: Hari Prasath Gujulan Elango
> ---
> drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
> b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
> index c8e2930..8882707 100644
> --- a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
> +++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
> @@ -241,7 +241,7 @@ void cfs_print_to_console(struct ptldebug_header *hdr,
> int mask,
> const char *buf, int len, const char *file,
> const char *fn)
> {
> - char *prefix = "Lustre", *ptype = NULL;
> + char prefix[] = "Lustre", *ptype = NULL;
>
> if ((mask & D_EMERG) != 0) {
> prefix = dbghdr_to_err_string(hdr);
> --
> 1.9.1
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Please discard this change as it breaks the build. I had build a
different copy of the source and assumed it succeeded. Sorry for the
mistake.
--
Regards,
G.E.Hari Prasath
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: MAINTAINERS: add maintainer for wilc1000 device
> +L: de...@driverdev.osuosl.org You don't need to add this. It's automatic for everything in drivers/staging. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: dgnc: Replace snprintf instead of sprintf
This patch replaces snprintf instead of sprintf to avoid buffer overflow Signed-off-by: Gnanachandran Dhanapal --- drivers/staging/dgnc/dgnc_mgmt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c index b13318a..aa20a66 100644 --- a/drivers/staging/dgnc/dgnc_mgmt.c +++ b/drivers/staging/dgnc/dgnc_mgmt.c @@ -116,7 +116,7 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, unsigned long arg) spin_lock_irqsave(&dgnc_global_lock, flags); ddi.dinfo_nboards = dgnc_NumBoards; - sprintf(ddi.dinfo_version, "%s", DG_PART); + snprintf(ddi.dinfo_version, strlen(DG_PART)+1, "%s", DG_PART); spin_unlock_irqrestore(&dgnc_global_lock, flags); -- 1.7.9.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: dgnc: Replace snprintf instead of sprintf
On Fri, Apr 24, 2015 at 11:22:24AM +, DHANAPAL, GNANACHANDRAN (G.) wrote: > This patch replaces snprintf instead of sprintf to avoid buffer overflow > > Signed-off-by: Gnanachandran Dhanapal > --- > drivers/staging/dgnc/dgnc_mgmt.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/dgnc/dgnc_mgmt.c > b/drivers/staging/dgnc/dgnc_mgmt.c > index b13318a..aa20a66 100644 > --- a/drivers/staging/dgnc/dgnc_mgmt.c > +++ b/drivers/staging/dgnc/dgnc_mgmt.c > @@ -116,7 +116,7 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd, > unsigned long arg) > spin_lock_irqsave(&dgnc_global_lock, flags); > > ddi.dinfo_nboards = dgnc_NumBoards; > - sprintf(ddi.dinfo_version, "%s", DG_PART); > + snprintf(ddi.dinfo_version, strlen(DG_PART)+1, "%s", DG_PART); This change makes no sense. If the original had memory corruption then the new code has memory corruption as well. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8192e: Use time_after macro
This patch replaces a condition check for time elapsea with a
simple time_after macro
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/rtl8192e/rtl8192e/rtl_ps.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
index 0bbffec..602a189 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
@@ -28,6 +28,7 @@
#include "r8192E_phyreg.h"
#include "r8190P_rtl8256.h" /* RTL8225 Radio frontend */
#include "r8192E_cmdpkt.h"
+#include
static void rtl8192_hw_sleep_down(struct net_device *dev)
{
@@ -105,7 +106,7 @@ void rtl8192_hw_to_sleep(struct net_device *dev, u64 time)
return;
}
- if ((time - jiffies) > msecs_to_jiffies(MAX_SLEEP_TIME)) {
+ if (time_after(time, jiffies + msecs_to_jiffies(MAX_SLEEP_TIME))) {
netdev_info(dev, ">too long to sleep:%lld > %ld\n",
time - jiffies, msecs_to_jiffies(MAX_SLEEP_TIME));
spin_unlock_irqrestore(&priv->ps_lock, flags);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8712e: use time_before() macro
This patch replaces the condition check for time elapsed with a
simplified time_before() macro
Signed-off-by: Hari Prasath Gujulan Elango
---
drivers/staging/rtl8192e/rtl8192e/rtl_ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
b/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
index 602a189..88233cc 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_ps.c
@@ -99,7 +99,7 @@ void rtl8192_hw_to_sleep(struct net_device *dev, u64 time)
time -= msecs_to_jiffies(8 + 16 + 7);
- if ((time - jiffies) <= msecs_to_jiffies(MIN_SLEEP_TIME)) {
+ if (time_before(time, jiffies + msecs_to_jiffies(MIN_SLEEP_TIME))) {
spin_unlock_irqrestore(&priv->ps_lock, flags);
netdev_info(dev, "too short to sleep::%lld < %ld\n",
time - jiffies, msecs_to_jiffies(MIN_SLEEP_TIME));
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: sm750fb: cleanup white space
This patch fixes "space prohibited" errors reported by checkpatch.pl
Signed-off-by: Charles Rose
---
drivers/staging/sm750fb/ddk750_chip.c | 12 ++--
drivers/staging/sm750fb/ddk750_mode.c | 2 +-
drivers/staging/sm750fb/ddk750_power.c | 8
drivers/staging/sm750fb/sm750_accel.c | 2 +-
drivers/staging/sm750fb/sm750_help.h | 2 +-
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c
b/drivers/staging/sm750fb/ddk750_chip.c
index 7b28328..60ae39a 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -268,7 +268,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
#endif
- if (pInitParam->powerMode != 0 )
+ if (pInitParam->powerMode != 0)
pInitParam->powerMode = 0;
setPowerMode(pInitParam->powerMode);
@@ -285,7 +285,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
ulReg = FIELD_SET(ulReg, VGA_CONFIGURATION, MODE, GRAPHIC);
POKE32(VGA_CONFIGURATION, ulReg);
} else {
-#if defined(__i386__) || defined( __x86_64__)
+#if defined(__i386__) || defined(__x86_64__)
/* set graphic mode via IO method */
outb_p(0x88, 0x3d4);
outb_p(0x06, 0x3d5);
@@ -382,7 +382,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
unsigned int absDiff(unsigned int a, unsigned int b)
{
- if ( a > b )
+ if (a > b)
return(a - b);
else
return(b - a);
@@ -606,9 +606,9 @@ unsigned int formatPllReg(pll_value_t *pPLL)
On returning a 32 bit number, the value can be applied to any PLL in
the calling function.
*/
ulPllReg =
- FIELD_SET( 0, PANEL_PLL_CTRL, BYPASS, OFF)
- | FIELD_SET( 0, PANEL_PLL_CTRL, POWER, ON)
- | FIELD_SET( 0, PANEL_PLL_CTRL, INPUT, OSC)
+ FIELD_SET(0, PANEL_PLL_CTRL, BYPASS, OFF)
+ | FIELD_SET(0, PANEL_PLL_CTRL, POWER, ON)
+ | FIELD_SET(0, PANEL_PLL_CTRL, INPUT, OSC)
#ifndef VALIDATION_CHIP
| FIELD_VALUE(0, PANEL_PLL_CTRL, POD,pPLL->POD)
#endif
diff --git a/drivers/staging/sm750fb/ddk750_mode.c
b/drivers/staging/sm750fb/ddk750_mode.c
index 2e418fb..8e7b9d4 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -43,7 +43,7 @@ static unsigned long
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
/* Set bit 29:27 of display control register for the right clock */
/* Note that SM750LE only need to supported 7 resoluitons. */
- if ( x == 800 && y == 600 )
+ if (x == 800 && y == 600)
dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL41);
else if (x == 1024 && y == 768)
dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL65);
diff --git a/drivers/staging/sm750fb/ddk750_power.c
b/drivers/staging/sm750fb/ddk750_power.c
index cbb9767..0e3c028 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -59,17 +59,17 @@ void setPowerMode(unsigned int powerMode)
{
control_value =
#ifdef VALIDATION_CHIP
-FIELD_SET( control_value, POWER_MODE_CTRL, 336CLK, OFF) |
+ FIELD_SET(control_value, POWER_MODE_CTRL, 336CLK, OFF) |
#endif
-FIELD_SET( control_value, POWER_MODE_CTRL, OSC_INPUT, OFF);
+ FIELD_SET(control_value, POWER_MODE_CTRL, OSC_INPUT, OFF);
}
else
{
control_value =
#ifdef VALIDATION_CHIP
-FIELD_SET( control_value, POWER_MODE_CTRL, 336CLK, ON) |
+ FIELD_SET(control_value, POWER_MODE_CTRL, 336CLK, ON) |
#endif
-FIELD_SET( control_value, POWER_MODE_CTRL, OSC_INPUT, ON);
+ FIELD_SET(control_value, POWER_MODE_CTRL, OSC_INPUT, ON);
}
/* Program new power mode. */
diff --git a/drivers/staging/sm750fb/sm750_accel.c
b/drivers/staging/sm750fb/sm750_accel.c
index c5a3726..e308646 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -364,7 +364,7 @@ int hw_imageblit(struct lynx_accel *accel,
Note that input pitch is BYTE value, but the 2D Pitch register uses
pixel values. Need Byte to pixel convertion.
*/
- if(bytePerPixel == 3 ){
+ if (bytePerPixel == 3) {
dx *= 3;
width *= 3;
startBit *= 3;
diff --git a/drivers/staging/sm750fb/sm750_help.h
b/drivers/staging/sm750fb/sm750_help.h
index e0128d2..cdac9e2 100644
--- a/drivers/staging/sm750fb/sm750_help.h
+++ b/drivers/staging/sm750fb/sm750_help.h
@@ -57,7 +57,7 @@
#define FIELD_CLEAR(reg, field) \
( \
-~ _F_MASK(reg ## _ ## field) \
+ ~_F_MASK(reg ## _ ## field) \
)
--
2.1.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: sm750fb: cleanup indentation
This patch fixes indentation errors/warnings reported by checkpatch.pl. Signed-off-by: Charles Rose --- drivers/staging/sm750fb/ddk750_mode.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c index 8e7b9d4..eac5712 100644 --- a/drivers/staging/sm750fb/ddk750_mode.c +++ b/drivers/staging/sm750fb/ddk750_mode.c @@ -44,21 +44,29 @@ static unsigned long displayControlAdjust_SM750LE(mode_parameter_t *pModeParam, /* Set bit 29:27 of display control register for the right clock */ /* Note that SM750LE only need to supported 7 resoluitons. */ if (x == 800 && y == 600) - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL41); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL41); else if (x == 1024 && y == 768) - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL65); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL65); else if (x == 1152 && y == 864) - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL80); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL80); else if (x == 1280 && y == 768) - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL80); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL80); else if (x == 1280 && y == 720) - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL74); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL74); else if (x == 1280 && y == 960) - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL108); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL108); else if (x == 1280 && y == 1024) - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL108); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL108); else /* default to VGA clock */ - dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CLK, PLL25); + dispControl = FIELD_SET(dispControl, + CRT_DISPLAY_CTRL, CLK, PLL25); /* Set bit 25:24 of display controller */ dispControl = FIELD_SET(dispControl, CRT_DISPLAY_CTRL, CRTSELECT, CRT); -- 2.1.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 5/6] Drivers: hv: vmbus: distribute subchannels among all vcpus
> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Friday, April 24, 2015 2:05 AM > To: Dexuan Cui > Cc: KY Srinivasan; Haiyang Zhang; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH 5/6] Drivers: hv: vmbus: distribute subchannels among > all vcpus > > Dexuan Cui writes: > > >> -Original Message- > >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > >> Sent: Tuesday, April 21, 2015 22:28 > >> To: KY Srinivasan > >> Cc: Haiyang Zhang; de...@linuxdriverproject.org; linux- > >> ker...@vger.kernel.org; Dexuan Cui > >> Subject: [PATCH 5/6] Drivers: hv: vmbus: distribute subchannels among all > >> vcpus > >> > >> Primary channels are distributed evenly across all vcpus we have. When > the > >> host asks us to create subchannels it usually makes us num_cpus-1 offers > > > > Hi Vitaly, > > AFAIK, in the VSP of storvsc, the number of subchannel is > > (the_number_of_vcpus - 1) / 4. > > > > This means for a 8-vCPU guest, there is only 1 subchannel. > > > > Your new algorithm tends to make the vCPUs with small-number busier: > > e.g., in the 8-vCPU case, assuming we have 4 SCSI controllers: > > vCPU0: scsi0's PrimaryChannel (P) > > vCPU1: scsi0's SubChannel (S) + scsi1's P > > vCPU2: scsi1's S + scsi2's P > > vCPU3: scsi2's S + scsi3's P > > vCPU4: scsi3's S > > vCPU5, 6 and 7 are idle. > > > > In this special case, the existing algorithm is better. :-) > > > > However, I do like this idea in your patch, that is, making sure a device's > > primary/sub channels are assigned to differents vCPUs. > > Under special circumstances with the current code we can end up with > having all subchannels on the same vCPU with the primary channel I guess > :-) This is not something common, but possible. > > > > > I'm just wondering if we should use an even better (and complex) > > algorithm :-) > > The question here is - does sticking to the current vCPU help? If it > does, I can suggest the following (I think I even mentioned that in my > PATCH 00): first we try to find a (sub)channel with target_cpu == > current_vcpu and only when we fail we do the round robin. I'd like to > hear K.Y.'s opinion here as he's the original author :-) Sorry for the delayed response. Initially I had implemented a scheme that would pick an outgoing CPU that was closest to the CPU on which the request came (to maintain cache locality especially on NUMA systems). I changed this algorithm to spread the load more uniformly as we were trying to improve Linux IOPS on Azure XIO (premium storage). We are currently testing this code on our Converged Offering - CPS and I am finding that the perf as measured by IOS has regressed. I have not narrowed the reason for this regression and it may very well be the change in the algorithm for selecting the outgoing channel. In general, I don't think the logic here needs to be exact and locality (being on the same CPU or within the same NUMA node) is important. Any change to this algorithm will have to be validated on different MSFT environments (Azure XIO, CPS etc.). Regards, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next, v2, 1/1] hv_netvsc: introduce netif-msg into netvsc module
From: Simon Xiao
1. Introduce netif-msg to netvsc to control debug logging output
and keep msg_enable in netvsc_device_context so that it is
kept persistently.
2. Only call dump_rndis_message() when NETIF_MSG_RX_ERR or above
is specified in netvsc module debug param.
In non-debug mode, in current code, dump_rndis_message() will not
dump anything but it still initialize some local variables and
process the switch logic which is unnecessary, especially in
high network throughput situation.
Signed-off-by: Simon Xiao
Reviewed-by: K. Y. Srinivasan
Reviewed-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 12
drivers/net/hyperv/netvsc.c | 3 +++
drivers/net/hyperv/netvsc_drv.c | 20 ++--
drivers/net/hyperv/rndis_filter.c | 3 ++-
4 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index a10b316..e55c8f4 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -612,6 +612,15 @@ struct multi_send_data {
u32 count; /* counter of batched packets */
};
+/* The context of the netvsc device */
+struct net_device_context {
+ /* point back to our device context */
+ struct hv_device *device_ctx;
+ struct delayed_work dwork;
+ struct work_struct work;
+ u32 msg_enable; /* debug level */
+};
+
/* Per netvsc device */
struct netvsc_device {
struct hv_device *dev;
@@ -667,6 +676,9 @@ struct netvsc_device {
struct multi_send_data msd[NR_CPUS];
u32 max_pkt; /* max number of pkt in one send, e.g. 8 */
u32 pkt_align; /* alignment bytes, e.g. 8 */
+
+ /* The net device context */
+ struct net_device_context *nd_ctx;
};
/* NdisInitialize message */
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 2e8ad06..c651d4d 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -1197,6 +1197,9 @@ int netvsc_device_add(struct hv_device *device, void
*additional_info)
*/
ndev = net_device->ndev;
+ /* Add netvsc_device context to netvsc_device */
+ net_device->nd_ctx = netdev_priv(ndev);
+
/* Initialize the NetVSC channel extension */
init_completion(&net_device->channel_init_wait);
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index a3a9d38..a9609d2 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -40,18 +40,21 @@
#include "hyperv_net.h"
-struct net_device_context {
- /* point back to our device context */
- struct hv_device *device_ctx;
- struct delayed_work dwork;
- struct work_struct work;
-};
#define RING_SIZE_MIN 64
static int ring_size = 128;
module_param(ring_size, int, S_IRUGO);
MODULE_PARM_DESC(ring_size, "Ring buffer size (# of pages)");
+static const u32 default_msg = NETIF_MSG_DRV | NETIF_MSG_PROBE |
+ NETIF_MSG_LINK | NETIF_MSG_IFUP |
+ NETIF_MSG_IFDOWN | NETIF_MSG_RX_ERR |
+ NETIF_MSG_TX_ERR;
+
+static int debug = -1;
+module_param(debug, int, S_IRUGO);
+MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
+
static void do_set_multicast(struct work_struct *w)
{
struct net_device_context *ndevctx =
@@ -888,6 +891,11 @@ static int netvsc_probe(struct hv_device *dev,
net_device_ctx = netdev_priv(net);
net_device_ctx->device_ctx = dev;
+ net_device_ctx->msg_enable = netif_msg_init(debug, default_msg);
+ if (netif_msg_probe(net_device_ctx))
+ netdev_dbg(net, "netvsc msg_enable: %d",
+ net_device_ctx->msg_enable);
+
hv_set_drvdata(dev, net);
INIT_DELAYED_WORK(&net_device_ctx->dwork, netvsc_link_change);
INIT_WORK(&net_device_ctx->work, do_set_multicast);
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 0d92efe..9118cea 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -429,7 +429,8 @@ int rndis_filter_receive(struct hv_device *dev,
rndis_msg = pkt->data;
- dump_rndis_message(dev, rndis_msg);
+ if (netif_msg_rx_err(net_dev->nd_ctx))
+ dump_rndis_message(dev, rndis_msg);
switch (rndis_msg->ndis_msg_type) {
case RNDIS_MSG_PACKET:
--
1.8.5.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: slicoss: Break string into two lines.
This patch fixes the checkpatch.pl warning about line over 80 characters. Signed-off-by: Navya Sri Nizamkari --- drivers/staging/slicoss/slicoss.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/slicoss/slicoss.c b/drivers/staging/slicoss/slicoss.c index 45f6a5f..3031545 100644 --- a/drivers/staging/slicoss/slicoss.c +++ b/drivers/staging/slicoss/slicoss.c @@ -98,7 +98,8 @@ #include "slic.h" static uint slic_first_init = 1; -static char *slic_banner = "Alacritech SLIC Technology(tm) Server and Storage Accelerator (Non-Accelerated)"; +static char *slic_banner = "Alacritech SLIC Technology(tm) Server + and Storage Accelerator (Non-Accelerated)"; static char *slic_proc_version = "2.0.351 2006/07/14 12:26:00"; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: slicoss: Break string into two lines.
On Sat, 2015-04-25 at 00:22 +0530, Navya Sri Nizamkari wrote: > This patch fixes the checkpatch.pl warning > about line over 80 characters. Don't give checkpatch any respect when it's being stupid. > diff --git a/drivers/staging/slicoss/slicoss.c > b/drivers/staging/slicoss/slicoss.c [] > @@ -98,7 +98,8 @@ > #include "slic.h" > > static uint slic_first_init = 1; > -static char *slic_banner = "Alacritech SLIC Technology(tm) Server and > Storage Accelerator (Non-Accelerated)"; > +static char *slic_banner = "Alacritech SLIC Technology(tm) Server > + and Storage Accelerator (Non-Accelerated)"; You've added a defect here as the string now contains a newline and new tabs and spaces between "Server" and "and" ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: wilc1000: Add SDIO/SPI 802.11 driver
On Fri, Apr 24, 2015 at 07:20:00PM +0900, Johnny Kim wrote: > This driver is for the wilc1000 which is a single chip IEEE 802.11 > b/g/n device. > The driver works together with cfg80211, which is the kernel side of > configuration management for wireless devices because the wilc1000 > chipset is fullmac where the MLME is managed in hardware. > > The driver worked from kernel version 2.6.38 and being now ported > to several others since then. > A TODO file is included as well in this commit. > > Signed-off-by: Johnny Kim > Signed-off-by: Rachel Kim > Signed-off-by: Dean Lee > Signed-off-by: Chris Park > --- > drivers/staging/Kconfig|2 + > drivers/staging/Makefile |1 + > drivers/staging/atmel/Kconfig | 14 + > drivers/staging/atmel/Makefile |1 + > drivers/staging/atmel/TODO |8 + > drivers/staging/atmel/wilc1000/Kconfig | 61 + > drivers/staging/atmel/wilc1000/Makefile| 41 + > .../staging/atmel/wilc1000/coreconfigsimulator.h | 20 + > drivers/staging/atmel/wilc1000/coreconfigurator.c | 2201 ++ > drivers/staging/atmel/wilc1000/coreconfigurator.h | 498 ++ > drivers/staging/atmel/wilc1000/fifo_buffer.c | 142 + > drivers/staging/atmel/wilc1000/fifo_buffer.h | 23 + > drivers/staging/atmel/wilc1000/host_interface.c| 8074 > > drivers/staging/atmel/wilc1000/host_interface.h| 1344 > drivers/staging/atmel/wilc1000/itypes.h| 60 + > drivers/staging/atmel/wilc1000/linux_mon.c | 643 ++ > drivers/staging/atmel/wilc1000/linux_wlan.c| 2953 +++ > drivers/staging/atmel/wilc1000/linux_wlan_common.h | 170 + > drivers/staging/atmel/wilc1000/linux_wlan_sdio.c | 249 + > drivers/staging/atmel/wilc1000/linux_wlan_sdio.h | 14 + > drivers/staging/atmel/wilc1000/linux_wlan_spi.c| 510 ++ > drivers/staging/atmel/wilc1000/linux_wlan_spi.h| 14 + > drivers/staging/atmel/wilc1000/wilc_debugfs.c | 185 + > drivers/staging/atmel/wilc1000/wilc_errorsupport.h | 84 + > drivers/staging/atmel/wilc1000/wilc_event.h| 123 + > drivers/staging/atmel/wilc1000/wilc_exported_buf.c | 76 + > drivers/staging/atmel/wilc1000/wilc_log.h | 47 + > drivers/staging/atmel/wilc1000/wilc_memory.c | 63 + > drivers/staging/atmel/wilc1000/wilc_memory.h | 330 + > drivers/staging/atmel/wilc1000/wilc_msgqueue.c | 211 + > drivers/staging/atmel/wilc1000/wilc_msgqueue.h | 133 + > drivers/staging/atmel/wilc1000/wilc_osconfig.h | 55 + > drivers/staging/atmel/wilc1000/wilc_oswrapper.h| 133 + > drivers/staging/atmel/wilc1000/wilc_platform.h | 181 + > drivers/staging/atmel/wilc1000/wilc_sdio.c | 1298 > drivers/staging/atmel/wilc1000/wilc_semaphore.c| 70 + > drivers/staging/atmel/wilc1000/wilc_semaphore.h| 115 + > drivers/staging/atmel/wilc1000/wilc_sleep.c| 36 + > drivers/staging/atmel/wilc1000/wilc_sleep.h| 45 + > drivers/staging/atmel/wilc1000/wilc_spi.c | 1475 > drivers/staging/atmel/wilc1000/wilc_strutils.c | 431 ++ > drivers/staging/atmel/wilc1000/wilc_strutils.h | 412 + > drivers/staging/atmel/wilc1000/wilc_thread.c | 35 + > drivers/staging/atmel/wilc1000/wilc_thread.h | 153 + > drivers/staging/atmel/wilc1000/wilc_time.c | 163 + > drivers/staging/atmel/wilc1000/wilc_time.h | 205 + > drivers/staging/atmel/wilc1000/wilc_timer.c| 51 + > drivers/staging/atmel/wilc1000/wilc_timer.h| 153 + > drivers/staging/atmel/wilc1000/wilc_type.h | 34 + > .../atmel/wilc1000/wilc_wfi_cfgoperations.c| 4550 +++ > .../atmel/wilc1000/wilc_wfi_cfgoperations.h| 134 + > .../staging/atmel/wilc1000/wilc_wfi_netdevice.c| 960 +++ > .../staging/atmel/wilc1000/wilc_wfi_netdevice.h| 277 + > drivers/staging/atmel/wilc1000/wilc_wlan.c | 2434 ++ > drivers/staging/atmel/wilc1000/wilc_wlan.h | 321 + > drivers/staging/atmel/wilc1000/wilc_wlan_cfg.c | 643 ++ > drivers/staging/atmel/wilc1000/wilc_wlan_cfg.h | 33 + > drivers/staging/atmel/wilc1000/wilc_wlan_if.h | 991 +++ > 58 files changed, 33683 insertions(+) > mode change 100644 => 100755 drivers/staging/Kconfig > mode change 100644 => 100755 drivers/staging/Makefile Why did you change these files to be executable? > create mode 100755 drivers/staging/atmel/Kconfig > create mode 100755 drivers/staging/atmel/Makefile > create mode 100755 drivers/staging/atmel/TODO > create mode 100755 drivers/staging/atmel/wilc1000/Kconfig > create mode 100755 drivers/staging/atmel/wilc1000/Makefile Why do you have two levels of directories here? Just move this to drivers/staging/wlc1000, no need for "atmel" to be in the middle, right? > create mode 100755 drivers/sta
Re: [PATCH net-next,v2,1/1] hv_netvsc: introduce netif-msg into netvsc module
On Fri, 2015-04-24 at 11:34 -0700, six...@microsoft.com wrote: > From: Simon Xiao > > 1. Introduce netif-msg to netvsc to control debug logging output > and keep msg_enable in netvsc_device_context so that it is > kept persistently. > 2. Only call dump_rndis_message() when NETIF_MSG_RX_ERR or above > is specified in netvsc module debug param. > In non-debug mode, in current code, dump_rndis_message() will not > dump anything but it still initialize some local variables and > process the switch logic which is unnecessary, especially in > high network throughput situation. [] > diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c [] > @@ -888,6 +891,11 @@ static int netvsc_probe(struct hv_device *dev, > > net_device_ctx = netdev_priv(net); > net_device_ctx->device_ctx = dev; > + net_device_ctx->msg_enable = netif_msg_init(debug, default_msg); > + if (netif_msg_probe(net_device_ctx)) > + netdev_dbg(net, "netvsc msg_enable: %d", > +net_device_ctx->msg_enable); Please use newlines to terminate formats. It helps prevent log content interleaving when multiple processes are emitting output at the same time. This could be shortened to use netif_ like: netif_dbg(net_device_ctx, probe, net, "netvsc_msg_enable: %d\n", net_device_ctx->msg_enable); ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] scsi: storvsc: Set the SRB flags correctly when no data transfer is needed
Set the SRB flags correctly when there is no data transfer. Cc: Signed-off-by: K. Y. Srinivasan Reviewed-by: Long Li --- drivers/scsi/storvsc_drv.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index d9dad90..3c6584f 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1600,8 +1600,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd) break; default: vm_srb->data_in = UNKNOWN_TYPE; - vm_srb->win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN | -SRB_FLAGS_DATA_OUT); + vm_srb->win8_extension.srb_flags |= SRB_FLAGS_NO_DATA_TRANSFER; break; } -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: vnc over ssh with tp-link tl-wn725n causes laptop to freeze
On Wed, 2015-04-22 at 13:18 -0500, Larry Finger wrote:
> On 04/22/2015 11:45 AM, dborlau...@gmail.com wrote:
> > Dear Mr. Carpenter,
> >
> > Thank you kindly for your help and these nice suggestions. Thank you
> > for CCing Mr. Finger. Actually, I stumbled across his name in my online
> > searches as on of the developers of this driver, and that's why I tried
> > to seek help here.
> >
> > I was able to repeat the problem and then capture /var/log/messages. It
> > is attached to this email. hopefully it went through? It's hard for me
> > to help locate the problem, but I believe I initiated the vnc over ssh
> > action around line 2892-2910 of the attached
> > ("201504220906-0700-messages.txt"), with corresponding messages
> > 2892-2910 being:
> > "
> > Apr 22 08:33:28 x120ea rsyslogd-2177: imuxsock begins to drop messages
> > from pid 3112 due to rate-limiting
> > Apr 22 08:33:30 x120ea rsyslogd-2177: imuxsock lost 49 messages from pid
> > 3112 due to rate-limiting
> > Apr 22 08:35:29 x120ea kernel: [ 153.267088] atkbd serio0: Unknown key
> > pressed (translated set 2, code 0xf1 on isa0060/serio0).
> > Apr 22 08:35:29 x120ea kernel: [ 153.267102] atkbd serio0: Use
> > 'setkeycodes e071 ' to make it known.
> > Apr 22 08:35:29 x120ea kernel: [ 153.277905] atkbd serio0: Unknown key
> > released (translated set 2, code 0xf1 on isa0060/serio0).
> > Apr 22 08:35:29 x120ea kernel: [ 153.277920] atkbd serio0: Use
> > 'setkeycodes e071 ' to make it known.
> > Apr 22 08:35:30 x120ea kernel: [ 153.762396] thinkpad_acpi: unknown
> > possible thermal alarm or keyboard event received
> > Apr 22 08:35:30 x120ea kernel: [ 153.767324] thinkpad_acpi:
> > temperatures (Celsius): 46 0 46 0 0 0 25 0
> > Apr 22 08:35:30 x120ea kernel: [ 153.767352] thinkpad_acpi: unhandled
> > HKEY event 0x6040
> > Apr 22 08:35:30 x120ea kernel: [ 153.767361] thinkpad_acpi: please
> > report the conditions when this event happened to
> > ibm-acpi-de...@lists.sourceforge.net
> > Apr 22 08:35:44 x120ea kernel: [ 167.636259] atkbd serio0: Unknown key
> > pressed (translated set 2, code 0xf1 on isa0060/serio0).
> > Apr 22 08:35:44 x120ea kernel: [ 167.636274] atkbd serio0: Use
> > 'setkeycodes e071 ' to make it known.
> > Apr 22 08:35:44 x120ea kernel: [ 167.646902] atkbd serio0: Unknown key
> > released (translated set 2, code 0xf1 on isa0060/serio0).
> > Apr 22 08:35:44 x120ea kernel: [ 167.646917] atkbd serio0: Use
> > 'setkeycodes e071 ' to make it known.
> > Apr 22 08:35:44 x120ea kernel: [ 168.131693] thinkpad_acpi: unknown
> > possible thermal alarm or keyboard event received
> > Apr 22 08:35:44 x120ea kernel: [ 168.143598] thinkpad_acpi:
> > temperatures (Celsius): 47 0 47 0 0 0 25 0
> > Apr 22 08:35:44 x120ea kernel: [ 168.143627] thinkpad_acpi: unhandled
> > HKEY event 0x6040
> > Apr 22 08:35:44 x120ea kernel: [ 168.143636] thinkpad_acpi: please
> > report the conditions when this event happened to
> > ibm-acpi-de...@lists.sourceforge.net
> > Apr 22 08:40:59 x120ea rsyslogd: [origin software="rsyslogd"
> > swVersion="5.8.11" x-pid="2253" x-info="http://www.rsyslog.com";]
> > rsyslogd was HUPed
> > "
>
> Unfortunately, that log segment does not have help for the problem. In fact,
> the
> logs seldom have any useful information. When a critical error occurs, the
> results are sent to an in-memory buffer and may be sent to the disk, but they
> write is not usually completed. When the system is restarted, the info does
> not
> make it to the logging file.
>
> At the moment, I am running x11vnc server over an ssh link with vnxviewer
> displaying the image. Other than the slowness of the network link, I am
> having
> no problems - the v4.1.8_2499 branch is what is running.
>
> Next, I will try the master branch.
>
> Larry
>
>
Dear Larry,
I am happy to report that I had success with the
("https://github.com/lwfinger/rtl8188eu";) master branch. I no longer
have any problems. Thank you kindly for your help! Very much
appreciated!
Kind regards,
anon
[Solved]
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH net-next,v2,1/1] hv_netvsc: introduce netif-msg into netvsc module
> -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Friday, April 24, 2015 1:29 PM > To: Simon Xiao > Cc: KY Srinivasan; Haiyang Zhang; de...@linuxdriverproject.org; > net...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH net-next,v2,1/1] hv_netvsc: introduce netif-msg into > netvsc module > > On Fri, 2015-04-24 at 11:34 -0700, six...@microsoft.com wrote: > > From: Simon Xiao > > > > 1. Introduce netif-msg to netvsc to control debug logging output and > > keep msg_enable in netvsc_device_context so that it is kept > > persistently. > > 2. Only call dump_rndis_message() when NETIF_MSG_RX_ERR or above is > > specified in netvsc module debug param. > > In non-debug mode, in current code, dump_rndis_message() will not > dump > > anything but it still initialize some local variables and process the > > switch logic which is unnecessary, especially in high network > > throughput situation. > > [] > > > diff --git a/drivers/net/hyperv/netvsc_drv.c > > b/drivers/net/hyperv/netvsc_drv.c > [] > > @@ -888,6 +891,11 @@ static int netvsc_probe(struct hv_device *dev, > > > > net_device_ctx = netdev_priv(net); > > net_device_ctx->device_ctx = dev; > > + net_device_ctx->msg_enable = netif_msg_init(debug, default_msg); > > + if (netif_msg_probe(net_device_ctx)) > > + netdev_dbg(net, "netvsc msg_enable: %d", > > + net_device_ctx->msg_enable); > > Please use newlines to terminate formats. > > It helps prevent log content interleaving when multiple processes are > emitting output at the same time. > > This could be shortened to use netif_ like: > > netif_dbg(net_device_ctx, probe, net, "netvsc_msg_enable: %d\n", > net_device_ctx->msg_enable); > Thanks Joe. I would like to leave this to my next patch as there are some places else in netvsc (rndis_filter.c) have the same usage. I would like to fix them in one patch to make them consistent. Thanks, Simon ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] scsi: storvsc: Set the SRB flags correctly when no data transfer is needed
Set the SRB flags correctly when there is no data transfer. Cc: Signed-off-by: K. Y. Srinivasan Reviewed-by: Long Li --- drivers/scsi/storvsc_drv.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index d9dad90..3c6584f 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1600,8 +1600,7 @@ static int storvsc_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *scmnd) break; default: vm_srb->data_in = UNKNOWN_TYPE; - vm_srb->win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN | -SRB_FLAGS_DATA_OUT); + vm_srb->win8_extension.srb_flags |= SRB_FLAGS_NO_DATA_TRANSFER; break; } -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next,v2,1/1] hv_netvsc: introduce netif-msg into netvsc module
On Fri, 2015-04-24 at 22:52 +, Simon Xiao wrote: > > From: Joe Perches [mailto:j...@perches.com] > > On Fri, 2015-04-24 at 11:34 -0700, six...@microsoft.com wrote: > > > From: Simon Xiao > > > > > > 1. Introduce netif-msg to netvsc to control debug logging output and > > > keep msg_enable in netvsc_device_context so that it is kept > > > persistently. [] > > > diff --git a/drivers/net/hyperv/netvsc_drv.c [] > > > + if (netif_msg_probe(net_device_ctx)) > > > + netdev_dbg(net, "netvsc msg_enable: %d", > > > +net_device_ctx->msg_enable); > > > > Please use newlines to terminate formats. > > > > It helps prevent log content interleaving when multiple processes are > > emitting output at the same time. > > > > This could be shortened to use netif_ like: > > > > netif_dbg(net_device_ctx, probe, net, "netvsc_msg_enable: %d\n", > > net_device_ctx->msg_enable); > > > > Thanks Joe. I would like to leave this to my next patch as there are some > places else in netvsc (rndis_filter.c) > have the same usage. I would like to fix them in one patch to make them > consistent. Oh sure no worries. It is nicer though to not introduce new formats with missing newline defects. cheers, Joe ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
