Re: [PATCH v4] staging: vboxvideo: Add vboxvideo to drivers/staging

[kbuild test robot]

Hi Hans,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.12-rc7 next-20170626]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/staging-vboxvideo-Add-vboxvideo-to-drivers-staging/20170627-035353
config: x86_64-randconfig-n0-06270721 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "framebuffer_release" [drivers/staging/vboxvideo/vboxvideo.ko] 
>> undefined!
>> ERROR: "fb_set_suspend" [drivers/staging/vboxvideo/vboxvideo.ko] undefined!
>> ERROR: "fb_dealloc_cmap" [drivers/staging/vboxvideo/vboxvideo.ko] undefined!
>> ERROR: "unregister_framebuffer" [drivers/staging/vboxvideo/vboxvideo.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 08/10] x86/hyper-v: use hypercall for remote TLB flush

[Andy Lutomirski]

On Tue, May 23, 2017 at 5:36 AM, Vitaly Kuznetsov  wrote:
> Andy Lutomirski  writes:
>
>>
>> Also, can you share the benchmark you used for these patches?
>
> I didn't do much while writing the patchset, mostly I was running the
> attached dumb trasher (32 pthreads doing mmap/munmap). On a 16 vCPU
> Hyper-V 2016 guest I get the following (just re-did the test with
> 4.12-rc1):
>
> Before the patchset:
> # time ./pthread_mmap ./randfile
>
> real3m33.118s
> user0m3.698s
> sys 3m16.624s
>
> After the patchset:
> # time ./pthread_mmap ./randfile
>
> real2m19.920s
> user0m2.662s
> sys 2m9.948s
>
> K. Y.'s guys at Microsoft did additional testing for the patchset on
> different Hyper-V deployments including Azure, they may share their
> findings too.

I ran this benchmark on my big TLB patchset, mainly to make sure I
didn't regress your test.  I seem to have sped it up by 30% or so
instead.  I need to study this a little bit to figure out why to make
sure that the reason isn't that I'm failing to do flushes I need to
do.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: visorbus: Fix coding style warning from checkpatch.pl.

[Quytelda Kahja]

Replace the literal function name "create_bus_instance" with the format
specifier "%s" so it can be dynamically filled by the __func__ macro.

Signed-off-by: Quytelda Kahja 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index a692561c81c8..b6caa7a98692 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1032,7 +1032,7 @@ create_bus_instance(struct visor_device *dev)
 err_debugfs_dir:
debugfs_remove_recursive(dev->debugfs_dir);
kfree(hdr_info);
-   dev_err(>device, "create_bus_instance failed: %d\n", err);
+   dev_err(>device, "%s failed: %d\n", __func__, err);
return err;
 }
 
-- 
2.13.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

[Julia Lawall]

On Mon, 26 Jun 2017, Frans Klaver wrote:

> On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote:
> >
> >
> > On Sat, 24 Jun 2017, Frans Klaver wrote:
> >
> > > Hm. For some reason the great mail filtering scheme decided to push
> > > this past my inbox :-/
> > >
> > > On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches  wrote:
> > > > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> > > >> The header field in struct pd_message is declared as an __le16 type. 
> > > >> The
> > > >> data in the message is supposed to be little endian. This means we 
> > > >> don't
> > > >> have to go and shift the individual bytes into position when we're
> > > >> filling the buffer, we can just copy the contents right away. As an
> > > >> added benefit we don't get fishy results on big endian systems anymore.
> > > >
> > > > Thanks for pointing this out.
> > > >
> > > > There are several instances of this class of error.
> > >
> > > There are other smells around __(le|be) types that show up in staging
> > > that might be worth checking in the rest of the kernel as well. e.g.
> > > converting to cpu and storing it back into itself (possibly with its
> > > bytes reversed), direct assignments without conversion and what else
> > > you might have. sparse obviously already flags anything fishy going on
> > > with these types, but cannot distinguish between the classes of
> > > errors. I'll need to acquaint myself with spatch a bit more to be able
> > > to track that down.
> >
> > If you have concrete code examples, even fake ones, illustrating a class
> > of problem, then that would be great.
>
> Alright, I'll describe two fairly simple cases for starters.
>
> One class of issue that I have on top of mind is simply
>
>   __le16 val;
>
>   val = le16_to_cpu(val);
>
> The problem there obviously being that val is supposed to be guaranteed
> little endian. Sparse will throw a warning at this. It may also appear
> as (or be 'fixed' as)
>
>   __le16 val;
>
>   le16_to_cpus(val);
>
> Sparse doesn't flag this second version as an issue, while it causes the
> same problem. It is especially a potential problem when the value is
> stored in driver data.
>
> Another smell that is prevalent, at least in staging, is
>
>   u16 in;
>   u16 out;
>
>   out = cpu_to_le16(in);
>
> or in one instance (drivers/staging/fbtft/fbtft-io.c) I saw
>
>   u64 tmp;
>
>   *(u64*)dst = cpu_to_be64(tmp);
>
> Now these aren't necessarily problematic. Usually this typo of code is
> preparing the data to be sent out in a specific byte ordering, but again
> issues may arise if this specifically ordered data is stored somewhere.
>
> I'll leave it at that for now.

OK, thanks!

julia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH 08/10] x86/hyper-v: use hypercall for remote TLB flush

[KY Srinivasan]

> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On
> Behalf Of Vitaly Kuznetsov
> Sent: Monday, June 26, 2017 1:15 AM
> To: k...@exchange.microsoft.com
> Cc: o...@aepfle.de; Stephen Hemminger ;
> gre...@linuxfoundation.org; jasow...@redhat.com; x...@kernel.org; linux-
> ker...@vger.kernel.org; a...@canonical.com; kbuild-...@01.org; Andy
> Lutomirski ; marcelo.ce...@canonical.com;
> de...@linuxdriverproject.org; leann.ogasaw...@canonical.com
> Subject: Re: [PATCH 08/10] x86/hyper-v: use hypercall for remote TLB flush
> 
> kbuild test robot  writes:
> 
> > Hi Vitaly,
> >
> > [auto build test ERROR on next-20170619]
> > [cannot apply to tip/x86/core linus/master linux/master v4.12-rc6 v4.12-rc5
> v4.12-rc4 v4.12-rc7]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help
> improve the system]
> >
> > url:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
> .com%2F0day-ci%2Flinux%2Fcommits%2Fkys-exchange-microsoft-
> com%2Fx86-hyper-v-include-hyperv-only-when-CONFIG_HYPERV-is-
> set%2F20170626-
> 133601=02%7C01%7Ckys%40microsoft.com%7Ce74ee37675c1404b0388
> 08d4bc6b7458%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636340
> 617088680557=EkwUQ0zdqgG%2B5NkK65oz%2FSPMwPiXyUz3Otck0x
> EKGFA%3D=0
> > config: i386-randconfig-a0-06250447 (attached as .config)
> > compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386
> >
> > All errors (new ones prefixed by >>):
> >
> >arch/x86/hyperv/mmu.c: In function 'hyperv_flush_tlb_others':
> >>> arch/x86/hyperv/mmu.c:120:32: error: passing argument 2 of
> 'native_flush_tlb_others' from incompatible pointer type [-
> Werror=incompatible-pointer-types]
> >  native_flush_tlb_others(cpus, mm, start, end);
> >^
> 
> It seems we're clashing with Andy's
> 
> commit a2055abe9c6789cedef29abbdaa488a087faccc3
> Author: Andy Lutomirski 
> Date:   Sun May 28 10:00:10 2017 -0700
> 
> x86/mm: Pass flush_tlb_info to flush_tlb_others() etc
> 
> The fix should be simple but in case you want me to rebase/resend please
> let me know.

I can make the necessary adjustments; but I am not sure how we will
address the inter-tree dependencies.

We are planning to take this patch-set through Greg's tree. 
If I make these adjustments for linux-next, Greg's tree
will be broken. Should we just wait until Greg picks up these changes in
his tree.

This patch-set also has an issue with the PCI tree.

Regards,

K. Y
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

[Frans Klaver]

On Fri, Jun 23, 2017 at 07:37:28PM -0400, Julia Lawall wrote:
> 
> 
> On Sat, 24 Jun 2017, Frans Klaver wrote:
> 
> > Hm. For some reason the great mail filtering scheme decided to push
> > this past my inbox :-/
> >
> > On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches  wrote:
> > > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> > >> The header field in struct pd_message is declared as an __le16 type. The
> > >> data in the message is supposed to be little endian. This means we don't
> > >> have to go and shift the individual bytes into position when we're
> > >> filling the buffer, we can just copy the contents right away. As an
> > >> added benefit we don't get fishy results on big endian systems anymore.
> > >
> > > Thanks for pointing this out.
> > >
> > > There are several instances of this class of error.
> >
> > There are other smells around __(le|be) types that show up in staging
> > that might be worth checking in the rest of the kernel as well. e.g.
> > converting to cpu and storing it back into itself (possibly with its
> > bytes reversed), direct assignments without conversion and what else
> > you might have. sparse obviously already flags anything fishy going on
> > with these types, but cannot distinguish between the classes of
> > errors. I'll need to acquaint myself with spatch a bit more to be able
> > to track that down.
> 
> If you have concrete code examples, even fake ones, illustrating a class
> of problem, then that would be great.

Alright, I'll describe two fairly simple cases for starters.

One class of issue that I have on top of mind is simply

__le16 val;

val = le16_to_cpu(val);

The problem there obviously being that val is supposed to be guaranteed
little endian. Sparse will throw a warning at this. It may also appear
as (or be 'fixed' as)

__le16 val;

le16_to_cpus(val);

Sparse doesn't flag this second version as an issue, while it causes the
same problem. It is especially a potential problem when the value is
stored in driver data.

Another smell that is prevalent, at least in staging, is

u16 in;
u16 out;

out = cpu_to_le16(in);

or in one instance (drivers/staging/fbtft/fbtft-io.c) I saw

u64 tmp;

*(u64*)dst = cpu_to_be64(tmp);

Now these aren't necessarily problematic. Usually this typo of code is
preparing the data to be sent out in a specific byte ordering, but again
issues may arise if this specifically ordered data is stored somewhere.

I'll leave it at that for now. 

Frans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 6/7] staging: wilc1000: Change ac based on acm status

[kbuild test robot]

Hi Aditya,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.12-rc7 next-20170626]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Aditya-Shankar/staging-wilc1000-Add-support-for-AC-classification/20170627-015835
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/staging/wilc1000/wilc_wlan.c: In function 'ac_change':
>> drivers/staging/wilc1000/wilc_wlan.c:457:11: error: 'struct wilc' has no 
>> member named 'txq'
  if (wilc->txq[*ac].acm == 0)
  ^~

vim +457 drivers/staging/wilc1000/wilc_wlan.c

   451  pkt_count[AC_VO_Q] = (reg & 0xfe00) >> VO_AC_COUNT_POS;
   452  }
   453  
   454  static inline u8 ac_change(struct wilc *wilc, u8 *ac)
   455  {
   456  do {
 > 457  if (wilc->txq[*ac].acm == 0)
   458  return 0;
   459  (*ac)++;
   460  } while (*ac < NQUEUES);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] staging: sm750fb: always take the lock

[AbdAllah-MEZITI]

This patch
- Always take the lock:
The current code only takes the lock if multiple instances are in use.
This is error-prone, and confuses static analyzers.
As taking the lock in case of a single instance is harmless and cheap,
change the code to always take the lock.
- That also fix the sparse warning:
drivers/staging/sm750fb/sm750.c:159:13: warning: context imbalance in 
'lynxfb_ops_fillrect' - different lock contexts for basic block
drivers/staging/sm750fb/sm750.c:231:9: warning: context imbalance in 
'lynxfb_ops_copyarea' - different lock contexts for basic block
drivers/staging/sm750fb/sm750.c:235:13: warning: context imbalance in 
'lynxfb_ops_imageblit' - different lock contexts for basic block

Signed-off-by: AbdAllah MEZITI 

v2:
 - add and fix the changelog text.
---
 drivers/staging/sm750fb/sm750.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 386d4ad..4a22190 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -186,16 +186,14 @@ static void lynxfb_ops_fillrect(struct fb_info *info,
 * If not use spin_lock,system will die if user load driver
 * and immediately unload driver frequently (dual)
 */
-   if (sm750_dev->fb_count > 1)
-   spin_lock(_dev->slock);
+   spin_lock(_dev->slock);
 
sm750_dev->accel.de_fillrect(_dev->accel,
 base, pitch, Bpp,
 region->dx, region->dy,
 region->width, region->height,
 color, rop);
-   if (sm750_dev->fb_count > 1)
-   spin_unlock(_dev->slock);
+   spin_unlock(_dev->slock);
 }
 
 static void lynxfb_ops_copyarea(struct fb_info *info,
@@ -220,16 +218,14 @@ static void lynxfb_ops_copyarea(struct fb_info *info,
 * If not use spin_lock, system will die if user load driver
 * and immediately unload driver frequently (dual)
 */
-   if (sm750_dev->fb_count > 1)
-   spin_lock(_dev->slock);
+   spin_lock(_dev->slock);
 
sm750_dev->accel.de_copyarea(_dev->accel,
 base, pitch, region->sx, region->sy,
 base, pitch, Bpp, region->dx, region->dy,
 region->width, region->height,
 HW_ROP2_COPY);
-   if (sm750_dev->fb_count > 1)
-   spin_unlock(_dev->slock);
+   spin_unlock(_dev->slock);
 }
 
 static void lynxfb_ops_imageblit(struct fb_info *info,
@@ -269,8 +265,7 @@ static void lynxfb_ops_imageblit(struct fb_info *info,
 * If not use spin_lock, system will die if user load driver
 * and immediately unload driver frequently (dual)
 */
-   if (sm750_dev->fb_count > 1)
-   spin_lock(_dev->slock);
+   spin_lock(_dev->slock);
 
sm750_dev->accel.de_imageblit(_dev->accel,
  image->data, image->width >> 3, 0,
@@ -278,8 +273,7 @@ static void lynxfb_ops_imageblit(struct fb_info *info,
  image->dx, image->dy,
  image->width, image->height,
  fgcol, bgcol, HW_ROP2_COPY);
-   if (sm750_dev->fb_count > 1)
-   spin_unlock(_dev->slock);
+   spin_unlock(_dev->slock);
 }
 
 static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] staging: vboxvideo: Add vboxvideo to drivers/staging

[Hans de Goede]

Hi,

On 26-06-17 18:24, Daniel Vetter wrote:

On Mon, Jun 26, 2017 at 06:06:19PM +0200, Hans de Goede wrote:

Hi,

On 23-06-17 11:31, Daniel Vetter wrote:

On Thu, Jun 22, 2017 at 11:11:37AM +0200, Hans de Goede wrote:

This commit adds the vboxvideo drm/kms driver for the virtual graphics
card used in Virtual Box virtual machines to drivers/staging.

Why drivers/staging? This driver is already being patched into the kernel
by several distros, thus it is good to get this driver upstream soon, so
that work on the driver can be easily shared.

At the same time we want to take our time to get this driver properly
cleaned up (mainly converted to the new atomic modesetting APIs) before
submitting it as a normal driver under drivers/gpu/drm, putting this
driver in staging for now allows both.

Note this driver has already been significantly cleaned up, when I started
working on this the files under /usr/src/vboxguest/vboxvideo as installed
by Virtual Box 5.1.18 Guest Additions had a total linecount of 52681
lines. The version in this commit has 4874 lines.

Cc: vbox-...@virtualbox.org
Cc: Michael Thayer 
Signed-off-by: Hans de Goede 
Signed-off-by: Michael Thayer 
---
Changes in v2:
-Add Michael's S-o-b
-Improve Kconfig help text
-Remove .config changes which accidentally got added to the commit

Changes in v3:
-Convert the files shared with the video-driver for other operating-systems
   to kernel coding style too
-Remove unused code from these files


In the end it's up to you, but our experience in drm with -staging has
been that's both a pain (separate tree, which makes coordination harder
for drm drivers) and a ghetto (no one from drm will look at your patches).

Especially for small drivers (and this is one, and I expect if you use all
the latest and greates helpers atomic will provide it'll shrink
considerably) it's just not worth the pain to polish stuff twice.

0toh I see the benefit of putting stuff into staging so in the end it's up
to you, just beware pls.


Thanks for the heads up Daniel, for now I would like to move forward with
getting this in staging, but I do agree that it would be good to get it
into drivers/gpu soon. Michael do you think you will have some time soon
to look at moving this to the atomic helpers ?


To make it clear what I think is the minimal path towards drivers/gpu:
- switch to atomic helpers (well probably simple_display_pipe if it fits)
- delete half the driver code by dropping optional hooks and using helpers
- make sure you don't use any callback/functions where the kerneldoc says
   it's deprecated (e.g. load/unload)
- merge


Thank you for this list, that is very helpful.


We can do the checkpatch/style bikeshedding once merged into drivers/gpu/
imo, that's real good fodder for newbies anyway :-)


Actually for v3 I've already converted everything to kernel coding style,
so that is already done :)

Regards,

Hans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] staging: vboxvideo: Add vboxvideo to drivers/staging

[Hans de Goede]

Hi,

On 22-06-17 14:03, Dan Carpenter wrote:
> This is obviously much better and easier to review.  I ended up
> reviewing it like I would normal code instead of staging code.  My main
> thing is could you please re-write the module init error handling so
> that each function does its own error handling instead of just calling
> vbox_driver_unload().  Doing it that way is always going to buggy and
> impossible to review.

Thanks for the review I'm preparing a v4 addressing all your comments,
one small remark and one question about your remarks:



>> +int vbox_irq_init(struct vbox_private *vbox)
>> +{
>> +  int ret;
>> +
>> +  vbox_update_mode_hints(vbox);
>> +  ret = drm_irq_install(vbox->dev, vbox->dev->pdev->irq);
>> +  if (unlikely(ret != 0)) {
>
>
> This is a slow path so don't use likely/unlikely.  Just say:
>
>if (ret)
>
>> +  vbox_irq_fini(vbox);
>
> No need.  Btw, the error handling in this driver is very frustrating for
> me.  There is a massive do-everything cleanup function we call if init
> fails or we need to unload the module.  But here we are doing our own
> cleanup so vbox_irq_fini() is called twice.  And, of course, if the
> resource isn't needed for the entire lifetime of the module then we have
> to do normal kernel style error handling.  And then there is
> vbox_mode_fini() which is not implemented.  The not implemented function
> is not a coincidence, I see that a lot when people start down the path
> of writing do-everything-style error handling.
>
> My suggestion is to use normal kernel style error handling everywhere
> because it's simpler in the end.  Every function cleans up after itself
> so you never return half the allocations you wanted.  Choose the label
> name to reflect what you are doing at the label.  You only need to
> remember the most recent allocation instead of remembering every single
> thing you allocated.
>
>one = alloc();
>if (!one)
>return -ENOMEM;
>
>two = alloc();
>if (!two) {
>rc = -ENOMEM;
>goto free_one;
>}
>
>three = alloc();
>if (!three) {
>rc = -ENOMEM;
>goto free_two;
>}
>
> It's really simple if you plod along one thing at time.

Ack, I had already converted some functions to this style,
also to avoid nested success checks leading to an indentation
ever further to the right. I will move more code over to
this style for v4.

>> +  DRM_ERROR("Failed installing irq: %d\n", ret);
>> +  return 1;
>
> Preserve the error code.  "return ret;"
>
>
>> +  }
>> +  INIT_WORK(>hotplug_work, vbox_hotplug_worker);
>> +  vbox->isr_installed = true;
>
> The isr_installed variable is not needed.
>
>> +  return 0;
>> +}
>> +
>> +void vbox_irq_fini(struct vbox_private *vbox)
>> +{
>> +  if (vbox->isr_installed) {
>> +  drm_irq_uninstall(vbox->dev);
>> +  flush_work(>hotplug_work);
>
> These should be freed in the reverse order from how they were allocated
> so I don't have to audit for use after frees or whatever.

You're right in principle, but your example is wrong:

> void vbox_irq_fini(struct vbox_private *vbox)
> {
>flush_work(>hotplug_work);
>drm_irq_uninstall(vbox->dev);
> }

The irq can schedule the work, so we need to uninstall it
and then wait for any pending work to finish, so the original
fini order is right, the init order is wrong however. So I've
fixed the init order to be the reverse of the fini code.



>> +int vbox_dumb_create(struct drm_file *file,
>> +   struct drm_device *dev, struct drm_mode_create_dumb 
*args)
>> +{
>> +  int ret;
>> +  struct drm_gem_object *gobj;
>> +  u32 handle;
>> +
>> +  args->pitch = args->width * ((args->bpp + 7) / 8);
>> +  args->size = args->pitch * args->height;
>> +
>> +  ret = vbox_gem_create(dev, args->size, false, );
>> +  if (ret)
>> +  return ret;
>> +
>> +  ret = drm_gem_handle_create(file, gobj, );
>> +  drm_gem_object_unreference_unlocked(gobj);
>> +  if (ret)
>> +  return ret;
>
> This is a resource leak.

What makes you say that? Note the unreference done before the
ret check. I could be missing something here, but I think this is fine ?

<2nd mega-snip>

Regards,

Hans

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [staging:staging-testing 357/367] make[5]: *** No rule to make target 'drivers/staging/fsl-mc/bus/dpmng.o', needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.

[Laurentiu Tudor]

> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Monday, June 26, 2017 2:55 PM
> To: Laurentiu Tudor 
> 
> On Mon, Jun 26, 2017 at 01:48:01PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jun 26, 2017 at 09:06:11AM +, Laurentiu Tudor wrote:
> > > Hi Greg,
> > >
> > > > -Original Message-
> > > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > > > Sent: Monday, June 26, 2017 11:50 AM
> > > > To: Laurentiu Tudor 
> > > >
> > > > On Mon, Jun 26, 2017 at 08:39:20AM +, Laurentiu Tudor wrote:
> > > > > Hi Greg,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > > > > >
> > > > > > On Sat, Jun 24, 2017 at 08:17:59PM +0800, kbuild test robot wrote:
> > > > > > > tree:
> > > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%
> > > > > > 2F%2Fg
> > > > > > it.ker
> > > > > >
> > > >
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fgregkh%2Fstaging.git&
> > > > da
> > > > > > ta
> > > > > >
> > > >
> =01%7C01%7Claurentiu.tudor%40nxp.com%7C751676566b8f465b5fa108d4bb1
> > > > > >
> > > >
> 69974%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=hDMOrVmq8h6I
> > > > > > MBDuCHgARD44vX58GOPYWIQSqMsdAjo%3D=0 staging-
> testing
> > > > > > > head:   18cd9021ea035db85519391dbc429a5b1d0dd25b
> > > > > > > commit: b065307fe0ad7859f01ce8560e6bdc590324561a [357/367]
> > > > staging:
> > > > > > > fsl-mc: remove dpmng API files
> > > > > > > config: arm64-allyesconfig (attached as .config)
> > > > > > > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1
> > > > > > > 20160705
> > > > > > > reproduce:
> > > > > > > wget
> > > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%
> > > > > > 2F%2Fr
> > > > > > aw.git
> > > > > > hubusercontent.com%2F01org%2Flkp-
> > > > > >
> > > >
> tests%2Fmaster%2Fsbin%2Fmake.cross=01%7C01%7Claurentiu.tudor%
> > > > 40
> > > > > >
> > > >
> nxp.com%7C751676566b8f465b5fa108d4bb169974%7C686ea1d3bc2b4c6fa92c
> > > > > >
> > > >
> d99c5c301635%7C0=JvBQcG8MAs7PwDoXxYXe89sqs%2B2ADAiQd7sYCq
> > > > > > 0YbPE%3D=0 -O ~/bin/make.cross
> > > > > > > chmod +x ~/bin/make.cross
> > > > > > > git checkout b065307fe0ad7859f01ce8560e6bdc590324561a
> > > > > > > # save the attached .config to linux build tree
> > > > > > > make.cross ARCH=arm64
> > > > > > >
> > > > > > > All errors (new ones prefixed by >>):
> > > > > > >
> > > > > > > >> make[5]: *** No rule to make target
> > > > > > > >> 'drivers/staging/fsl-mc/bus/dpmng.o',
> > > > > > needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.
> > > > > > >make[5]: Target '__build' not remade because of errors.
> > > > > >
> > > > > > Crap, this isn't good.  But it looks like further patches fixes 
> > > > > > this issue,
> right?
> > > > >
> > > > > Wow, doesn't look like so. I don't know how I managed to screw
> > > > > this up so badly. :-(
> > > > >
> > > > > > Laurentiu, any ideas here?  You do always test every
> > > > > > individual patch, right? :)
> > > > >
> > > > > Usually yes, but looks like this time I managed to mess it up.
> > > > > Sorry for the
> > > > trouble.
> > > > >
> > > > > > Note, if you all ever got multi-arch building working for this
> > > > > > code, I would have caught this a lot earlier, that should be
> > > > > > something you fix up to get this out of staging, no reason to only
> depend on one arch.
> > > > >
> > > > > Got it. I don't think there's any arch depended stuff in the
> > > > > code so there
> > > > shouldn't be issues.
> > > > > I'll fix up this series and submit a v2 of the whole patch set
> > > > > and after that look
> > > > into the multi-arch stuff.
> > > > > Is this ok?
> > > >
> > > > No, it's already in my tree, so either I revert the patch series,
> > > > or I take a fixup patch for it.  Which do you want me to do?
> > >
> > > Let's go with reverting the whole series and me to resubmit a v2
> > > because there are also a couple of comments from Joe Perches that
> > > I'd like to include.
> >
> > Ugh, ok, will do...
> >
> 
> Now all reverted and pushed out for 0-day to run on it.
> 
> Please be more careful in the future.

Will do, sorry again for all the trouble.

BTW, I think I found out what happened: I didn't try a clean build. :-(
I'll make sure to include this in my pre-submission validations.

---
Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [staging:staging-testing 357/367] make[5]: *** No rule to make target 'drivers/staging/fsl-mc/bus/dpmng.o', needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.

[Greg Kroah-Hartman]

On Mon, Jun 26, 2017 at 01:48:01PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 26, 2017 at 09:06:11AM +, Laurentiu Tudor wrote:
> > Hi Greg,
> > 
> > > -Original Message-
> > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > > Sent: Monday, June 26, 2017 11:50 AM
> > > To: Laurentiu Tudor 
> > > 
> > > On Mon, Jun 26, 2017 at 08:39:20AM +, Laurentiu Tudor wrote:
> > > > Hi Greg,
> > > >
> > > > > -Original Message-
> > > > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > > > >
> > > > > On Sat, Jun 24, 2017 at 08:17:59PM +0800, kbuild test robot wrote:
> > > > > > tree:
> > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
> > > > > it.ker
> > > > >
> > > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fgregkh%2Fstaging.git
> > > > > ta
> > > > >
> > > =01%7C01%7Claurentiu.tudor%40nxp.com%7C751676566b8f465b5fa108d4bb1
> > > > >
> > > 69974%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=hDMOrVmq8h6I
> > > > > MBDuCHgARD44vX58GOPYWIQSqMsdAjo%3D=0 staging-testing
> > > > > > head:   18cd9021ea035db85519391dbc429a5b1d0dd25b
> > > > > > commit: b065307fe0ad7859f01ce8560e6bdc590324561a [357/367]
> > > staging:
> > > > > > fsl-mc: remove dpmng API files
> > > > > > config: arm64-allyesconfig (attached as .config)
> > > > > > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> > > > > > reproduce:
> > > > > > wget
> > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fr
> > > > > aw.git
> > > > > hubusercontent.com%2F01org%2Flkp-
> > > > >
> > > tests%2Fmaster%2Fsbin%2Fmake.cross=01%7C01%7Claurentiu.tudor%40
> > > > >
> > > nxp.com%7C751676566b8f465b5fa108d4bb169974%7C686ea1d3bc2b4c6fa92c
> > > > >
> > > d99c5c301635%7C0=JvBQcG8MAs7PwDoXxYXe89sqs%2B2ADAiQd7sYCq
> > > > > 0YbPE%3D=0 -O ~/bin/make.cross
> > > > > > chmod +x ~/bin/make.cross
> > > > > > git checkout b065307fe0ad7859f01ce8560e6bdc590324561a
> > > > > > # save the attached .config to linux build tree
> > > > > > make.cross ARCH=arm64
> > > > > >
> > > > > > All errors (new ones prefixed by >>):
> > > > > >
> > > > > > >> make[5]: *** No rule to make target
> > > > > > >> 'drivers/staging/fsl-mc/bus/dpmng.o',
> > > > > needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.
> > > > > >make[5]: Target '__build' not remade because of errors.
> > > > >
> > > > > Crap, this isn't good.  But it looks like further patches fixes this 
> > > > > issue, right?
> > > >
> > > > Wow, doesn't look like so. I don't know how I managed to screw this up
> > > > so badly. :-(
> > > >
> > > > > Laurentiu, any ideas here?  You do always test every individual
> > > > > patch, right? :)
> > > >
> > > > Usually yes, but looks like this time I managed to mess it up. Sorry 
> > > > for the
> > > trouble.
> > > >
> > > > > Note, if you all ever got multi-arch building working for this code,
> > > > > I would have caught this a lot earlier, that should be something you
> > > > > fix up to get this out of staging, no reason to only depend on one 
> > > > > arch.
> > > >
> > > > Got it. I don't think there's any arch depended stuff in the code so 
> > > > there
> > > shouldn't be issues.
> > > > I'll fix up this series and submit a v2 of the whole patch set and 
> > > > after that look
> > > into the multi-arch stuff.
> > > > Is this ok?
> > > 
> > > No, it's already in my tree, so either I revert the patch series, or I 
> > > take a fixup
> > > patch for it.  Which do you want me to do?
> > 
> > Let's go with reverting the whole series and me to resubmit a v2
> > because there are also a couple of comments from Joe Perches that I'd
> > like to include.
> 
> Ugh, ok, will do...
> 

Now all reverted and pushed out for 0-day to run on it.

Please be more careful in the future.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [staging:staging-testing 357/367] make[5]: *** No rule to make target 'drivers/staging/fsl-mc/bus/dpmng.o', needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.

[Greg Kroah-Hartman]

On Mon, Jun 26, 2017 at 09:06:11AM +, Laurentiu Tudor wrote:
> Hi Greg,
> 
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > Sent: Monday, June 26, 2017 11:50 AM
> > To: Laurentiu Tudor 
> > 
> > On Mon, Jun 26, 2017 at 08:39:20AM +, Laurentiu Tudor wrote:
> > > Hi Greg,
> > >
> > > > -Original Message-
> > > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > > >
> > > > On Sat, Jun 24, 2017 at 08:17:59PM +0800, kbuild test robot wrote:
> > > > > tree:
> > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
> > > > it.ker
> > > >
> > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fgregkh%2Fstaging.git
> > > > ta
> > > >
> > =01%7C01%7Claurentiu.tudor%40nxp.com%7C751676566b8f465b5fa108d4bb1
> > > >
> > 69974%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=hDMOrVmq8h6I
> > > > MBDuCHgARD44vX58GOPYWIQSqMsdAjo%3D=0 staging-testing
> > > > > head:   18cd9021ea035db85519391dbc429a5b1d0dd25b
> > > > > commit: b065307fe0ad7859f01ce8560e6bdc590324561a [357/367]
> > staging:
> > > > > fsl-mc: remove dpmng API files
> > > > > config: arm64-allyesconfig (attached as .config)
> > > > > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> > > > > reproduce:
> > > > > wget
> > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fr
> > > > aw.git
> > > > hubusercontent.com%2F01org%2Flkp-
> > > >
> > tests%2Fmaster%2Fsbin%2Fmake.cross=01%7C01%7Claurentiu.tudor%40
> > > >
> > nxp.com%7C751676566b8f465b5fa108d4bb169974%7C686ea1d3bc2b4c6fa92c
> > > >
> > d99c5c301635%7C0=JvBQcG8MAs7PwDoXxYXe89sqs%2B2ADAiQd7sYCq
> > > > 0YbPE%3D=0 -O ~/bin/make.cross
> > > > > chmod +x ~/bin/make.cross
> > > > > git checkout b065307fe0ad7859f01ce8560e6bdc590324561a
> > > > > # save the attached .config to linux build tree
> > > > > make.cross ARCH=arm64
> > > > >
> > > > > All errors (new ones prefixed by >>):
> > > > >
> > > > > >> make[5]: *** No rule to make target
> > > > > >> 'drivers/staging/fsl-mc/bus/dpmng.o',
> > > > needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.
> > > > >make[5]: Target '__build' not remade because of errors.
> > > >
> > > > Crap, this isn't good.  But it looks like further patches fixes this 
> > > > issue, right?
> > >
> > > Wow, doesn't look like so. I don't know how I managed to screw this up
> > > so badly. :-(
> > >
> > > > Laurentiu, any ideas here?  You do always test every individual
> > > > patch, right? :)
> > >
> > > Usually yes, but looks like this time I managed to mess it up. Sorry for 
> > > the
> > trouble.
> > >
> > > > Note, if you all ever got multi-arch building working for this code,
> > > > I would have caught this a lot earlier, that should be something you
> > > > fix up to get this out of staging, no reason to only depend on one arch.
> > >
> > > Got it. I don't think there's any arch depended stuff in the code so there
> > shouldn't be issues.
> > > I'll fix up this series and submit a v2 of the whole patch set and after 
> > > that look
> > into the multi-arch stuff.
> > > Is this ok?
> > 
> > No, it's already in my tree, so either I revert the patch series, or I take 
> > a fixup
> > patch for it.  Which do you want me to do?
> 
> Let's go with reverting the whole series and me to resubmit a v2
> because there are also a couple of comments from Joe Perches that I'd
> like to include.

Ugh, ok, will do...

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 4/8] staging: wilc1000: Add function to balance packet count

[Aditya Shankar]

Add a new function to track the cound of packets and
determine the ratio of current number of packets to
maximum count of packets.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index d1ed3ba8..655f229 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -426,6 +426,23 @@ static inline u8 ac_classify(struct wilc *wilc, struct 
txq_entry_t *tqe)
return ac;
 }
 
+static inline int ac_balance(u8 *count, u8 *ratio)
+{
+   u8 i, max_count = 0;
+
+   if (!count || !ratio)
+   return -1;
+
+   for (i = 0; i < NQUEUES; i++)
+   if (count[i] > max_count)
+   max_count = count[i];
+
+   for (i = 0; i < NQUEUES; i++)
+   ratio[i] = max_count - count[i];
+
+   return 0;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 6/8] staging: wilc1000: Get packet count from firmware

[Aditya Shankar]

Add a new function to get packet count from the firmware.

31:25   24  23:17   16  15:98   7:2 1   0
VO CNT  VO ACM  VI CNT  VI ACM  BE CNT  BE ACM  BK CNT  BK ACM  VMM ready

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 655f229..b3e1136 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -443,6 +443,14 @@ static inline int ac_balance(u8 *count, u8 *ratio)
return 0;
 }
 
+static inline void ac_pkt_count(u32 reg, u8 *pkt_count)
+{
+   pkt_count[AC_BK_Q] = (reg & 0x00fa) >> BK_AC_COUNT_POS;
+   pkt_count[AC_BE_Q] = (reg & 0xfe00) >> BE_AC_COUNT_POS;
+   pkt_count[AC_VI_Q] = (reg & 0x00fe) >> VI_AC_COUNT_POS;
+   pkt_count[AC_VO_Q] = (reg & 0xfe00) >> VO_AC_COUNT_POS;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 8/8] staging: wilc1000: Update ACM bit status

[Aditya Shankar]

Add a new function to update ACM bit status for a queue
for all access categories.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index e323fd4..929166a 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -461,6 +461,14 @@ static inline u8 ac_change(struct wilc *wilc, u8 *ac)
return 1;
 }
 
+static inline void ac_acm_bit(struct wilc *wilc, u32 reg)
+{
+   wilc->txq[AC_BK_Q].acm = (reg & 0x0002) >> BK_AC_ACM_STAT_POS;
+   wilc->txq[AC_BE_Q].acm = (reg & 0x0100) >> BE_AC_ACM_STAT_POS;
+   wilc->txq[AC_VI_Q].acm = (reg & 0x0001) >> VI_AC_ACM_STAT_POS;
+   wilc->txq[AC_VO_Q].acm = (reg & 0x0100) >> VO_AC_ACM_STAT_POS;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 7/8] staging: wilc1000: Change ac based on acm status

[Aditya Shankar]

Add a new function to check and alter the ac if needed
based on the acm status for a particular queue.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index b3e1136..e323fd4 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -451,6 +451,16 @@ static inline void ac_pkt_count(u32 reg, u8 *pkt_count)
pkt_count[AC_VO_Q] = (reg & 0xfe00) >> VO_AC_COUNT_POS;
 }
 
+static inline u8 ac_change(struct wilc *wilc, u8 *ac)
+{
+   do {
+   if (wilc->txq[*ac].acm == 0)
+   return 0;
+   (*ac)++;
+   } while (*ac < NQUEUES);
+   return 1;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 3/8] staging: wilc1000: WMM classification of data

[Aditya Shankar]

This patch adds a new function to classify data to available
WMM access categories based on the DSCP value in the header.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 51 
 1 file changed, 51 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 8c997ba..d1ed3ba8 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -375,6 +375,57 @@ static inline void ac_q_limit(u8 ac, u16 *q_limit)
  sum) + 1;
 }
 
+static inline u8 ac_classify(struct wilc *wilc, struct txq_entry_t *tqe)
+{
+   u8 *eth_hdr_ptr;
+   u8 *buffer = tqe->buffer;
+   u8 ac;
+   u16 h_proto;
+
+   spin_lock_irqsave(>txq_spinlock, wilc->txq_spinlock_flags);
+
+   eth_hdr_ptr = [0];
+   h_proto = ntohs(*((unsigned short *)_hdr_ptr[12]));
+   if (h_proto == ETH_P_IP) {
+   u8 *ip_hdr_ptr;
+   u32 IHL, DSCP;
+
+   ip_hdr_ptr = [ETHERNET_HDR_LEN];
+   IHL = (ip_hdr_ptr[0] & 0xf) << 2;
+   DSCP = (ip_hdr_ptr[1] & 0xfc);
+
+   switch (DSCP) {
+   case 0x20:
+   case 0x40:
+   case 0x08:
+   ac = AC_BK_Q;
+   break;
+   case 0x80:
+   case 0xA0:
+   case 0x28:
+   ac = AC_VI_Q;
+   break;
+   case 0xC0:
+   case 0xd0:
+   case 0xE0:
+   case 0x88:
+   case 0xB8:
+   ac = AC_VO_Q;
+   break;
+   default:
+   ac = AC_BE_Q;
+   break;
+   }
+   } else {
+   ac  = AC_BE_Q;
+   }
+
+   tqe->q_num = ac;
+   spin_unlock_irqrestore(>txq_spinlock, wilc->txq_spinlock_flags);
+
+   return ac;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/8] staging: wilc1000: Add support for AC classification.

[Aditya Shankar]

This patch adds new variables and defines for adding access
category classification

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.h 
b/drivers/staging/wilc1000/wilc_wlan.h
index 7a5eba9..c97f94a 100644
--- a/drivers/staging/wilc1000/wilc_wlan.h
+++ b/drivers/staging/wilc1000/wilc_wlan.h
@@ -133,6 +133,17 @@
 
 #define MODALIAS   "WILC_SPI"
 #define GPIO_NUM   0x44
+
+#define NQUEUES4
+#define VO_AC_COUNT_POS25
+#define VO_AC_ACM_STAT_POS 24
+#define VI_AC_COUNT_POS17
+#define VI_AC_ACM_STAT_POS 16
+#define BE_AC_COUNT_POS9
+#define BE_AC_ACM_STAT_POS 8
+#define BK_AC_COUNT_POS2
+#define BK_AC_ACM_STAT_POS 1
+#define AC_BUFFER_SIZE 1000
 /***/
 /*E0 and later Interrupt flags.*/
 /***/
@@ -206,11 +217,25 @@ typedef void (*wilc_debug_func)(u32, char *, ...);
  *  Tx/Rx Queue Structure
  *
  /
+struct txq_handle {
+   struct txq_entry_t *txq_head;
+   struct txq_entry_t *txq_tail;
+   u16 count;
+   u8 acm;
+};
+
+enum ip_pkt_priority {
+   AC_VO_Q = 0,
+   AC_VI_Q = 1,
+   AC_BE_Q = 2,
+   AC_BK_Q = 3
+};
 
 struct txq_entry_t {
struct txq_entry_t *next;
struct txq_entry_t *prev;
int type;
+   u8 q_num;
int tcp_pending_ack_idx;
u8 *buffer;
int buffer_size;
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 5/8] staging: wilc1000: Add new variable for ac queue management

[Aditya Shankar]

This patch adds a new variable in the wilc struct to manage
ac queues.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wfi_netdevice.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index c89bf43..e830bc5 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -200,6 +200,7 @@ struct wilc {
 
struct txq_entry_t *txq_head;
struct txq_entry_t *txq_tail;
+   struct txq_handle txq[NQUEUES];
int txq_entries;
int txq_exit;
 
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 0/8] Enable access category classification on Tx path

[Aditya Shankar]

This patch series adds changes made to implement access
category based data classification and manages buffers allocation
between different access categories on the Tx path.

Aditya Shankar (8):
  staging: wilc1000: Add support for AC classification.
  staging: wilc1000: Add function to calculate ac queue limit
  staging: wilc1000: WMM classification of data
  staging: wilc1000: Add function to balance packet count
  staging: wilc1000: Add new variable for ac queue management
  staging: wilc1000: Get packet count from firmware
  staging: wilc1000: Change ac based on acm status
  staging: wilc1000: Update ACM bit status

Change in v2:
Add a missing patch in the patchset

 drivers/staging/wilc1000/wilc_wfi_netdevice.h |   1 +
 drivers/staging/wilc1000/wilc_wlan.c  | 136 ++
 drivers/staging/wilc1000/wilc_wlan.h  |  25 +
 3 files changed, 162 insertions(+)

-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 2/8] staging: wilc1000: Add function to calculate ac queue limit

[Aditya Shankar]

This patch adds a function which calculates the queue limit
for a given access category queue.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 42 
 1 file changed, 42 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 9addef1..8c997ba 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -333,6 +333,48 @@ static int wilc_wlan_txq_add_cfg_pkt(struct wilc_vif *vif, 
u8 *buffer,
return 1;
 }
 
+static inline void ac_q_limit(u8 ac, u16 *q_limit)
+{
+   static bool initialized;
+   static u8 buffer[AC_BUFFER_SIZE];
+   static u16 cnt[NQUEUES];
+   u8 factors[NQUEUES] = {1, 1, 1, 1};
+   static u16 sum;
+   u16 i;
+   static u16 end_index;
+
+   if (!initialized) {
+   for (i = 0; i < AC_BUFFER_SIZE; i++)
+   buffer[i] = i % NQUEUES;
+
+   for (i = 0; i < NQUEUES; i++) {
+   cnt[i] = AC_BUFFER_SIZE * factors[i] / NQUEUES;
+   sum += cnt[i];
+   }
+   end_index = AC_BUFFER_SIZE - 1;
+   initialized = 1;
+   }
+   if (end_index > AC_BUFFER_SIZE - 1)
+   end_index = AC_BUFFER_SIZE - 1;
+
+   cnt[buffer[end_index]] -= factors[buffer[end_index]];
+   cnt[ac] += factors[ac];
+   sum += (factors[ac] - factors[buffer[end_index]]);
+
+   buffer[end_index] = ac;
+   if (end_index > 0)
+   end_index--;
+   else
+   end_index = AC_BUFFER_SIZE - 1;
+
+   for (i = 0; i < NQUEUES; i++)
+   if (!sum)
+   q_limit[i] = 1;
+   else
+   q_limit[i] = (cnt[i] * FLOW_CONTROL_UPPER_THRESHOLD /
+ sum) + 1;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

[Julia Lawall]

On Mon, 26 Jun 2017, Frans Klaver wrote:

> On Sat, Jun 24, 2017 at 1:37 AM, Julia Lawall  wrote:
> >
> >
> > On Sat, 24 Jun 2017, Frans Klaver wrote:
> >
> >> Hm. For some reason the great mail filtering scheme decided to push
> >> this past my inbox :-/
> >>
> >> On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches  wrote:
> >> > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
> >> >> The header field in struct pd_message is declared as an __le16 type. The
> >> >> data in the message is supposed to be little endian. This means we don't
> >> >> have to go and shift the individual bytes into position when we're
> >> >> filling the buffer, we can just copy the contents right away. As an
> >> >> added benefit we don't get fishy results on big endian systems anymore.
> >> >
> >> > Thanks for pointing this out.
> >> >
> >> > There are several instances of this class of error.
> >>
> >> There are other smells around __(le|be) types that show up in staging
> >> that might be worth checking in the rest of the kernel as well. e.g.
> >> converting to cpu and storing it back into itself (possibly with its
> >> bytes reversed), direct assignments without conversion and what else
> >> you might have. sparse obviously already flags anything fishy going on
> >> with these types, but cannot distinguish between the classes of
> >> errors. I'll need to acquaint myself with spatch a bit more to be able
> >> to track that down.
> >
> > If you have concrete code examples, even fake ones, illustrating a class
> > of problem, then that would be great.
>
> I'll see if I can produce some somewhere this week.

Thanks.

julia
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: sm750fb: always take the lock

[Geert Uytterhoeven]

On Mon, Jun 26, 2017 at 11:16 AM, Frans Klaver  wrote:
> On Mon, Jun 26, 2017 at 11:11 AM, Geert Uytterhoeven
>  wrote:
>> On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI
>>  wrote:
>>> This patch
>>> - will always take the lock
>>
>> Why?
>>
>> "The current code only takes the lock if multiple instances are in use.
>>  This is error-prone, and confuses static analyzers.
>>  As taking the lock in case of a single instance is harmful and cheap,
>>  change the code to always take the lock."
>
> I would argue that it's not harmful, lest people get confused about

Sorry, I meant "harmless". I should start caring as much for commit
messages I write for other people as for those I write for myself ;-)

> it. And I agree that this explanation is much more useful than just
> mentioning the warnings that you saw.

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] staging: sm750fb: always take the lock

[Frans Klaver]

On Mon, Jun 26, 2017 at 11:11 AM, Geert Uytterhoeven
 wrote:
> On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI
>  wrote:
>> This patch
>> - will always take the lock
>
> Why?
>
> "The current code only takes the lock if multiple instances are in use.
>  This is error-prone, and confuses static analyzers.
>  As taking the lock in case of a single instance is harmful and cheap,
>  change the code to always take the lock."

I would argue that it's not harmful, lest people get confused about
it. And I agree that this explanation is much more useful than just
mentioning the warnings that you saw.

Thanks,
Frans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: sm750fb: always take the lock

[Geert Uytterhoeven]

On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI
 wrote:
> This patch
> - will always take the lock

Why?

"The current code only takes the lock if multiple instances are in use.
 This is error-prone, and confuses static analyzers.
 As taking the lock in case of a single instance is harmful and cheap,
 change the code to always take the lock."

> - fix the sparse warning:
> drivers/staging/sm750fb/sm750.c:159:13: warning: context imbalance in 
> 'lynxfb_ops_fillrect' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:231:9: warning: context imbalance in 
> 'lynxfb_ops_copyarea' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:235:13: warning: context imbalance in 
> 'lynxfb_ops_imageblit' - different lock contexts for basic block

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: [staging:staging-testing 357/367] make[5]: *** No rule to make target 'drivers/staging/fsl-mc/bus/dpmng.o', needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.

[Laurentiu Tudor]

Hi Greg,

> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> Sent: Monday, June 26, 2017 11:50 AM
> To: Laurentiu Tudor 
> 
> On Mon, Jun 26, 2017 at 08:39:20AM +, Laurentiu Tudor wrote:
> > Hi Greg,
> >
> > > -Original Message-
> > > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > >
> > > On Sat, Jun 24, 2017 at 08:17:59PM +0800, kbuild test robot wrote:
> > > > tree:
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
> > > it.ker
> > >
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fgregkh%2Fstaging.git
> > > ta
> > >
> =01%7C01%7Claurentiu.tudor%40nxp.com%7C751676566b8f465b5fa108d4bb1
> > >
> 69974%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=hDMOrVmq8h6I
> > > MBDuCHgARD44vX58GOPYWIQSqMsdAjo%3D=0 staging-testing
> > > > head:   18cd9021ea035db85519391dbc429a5b1d0dd25b
> > > > commit: b065307fe0ad7859f01ce8560e6bdc590324561a [357/367]
> staging:
> > > > fsl-mc: remove dpmng API files
> > > > config: arm64-allyesconfig (attached as .config)
> > > > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> > > > reproduce:
> > > > wget
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fr
> > > aw.git
> > > hubusercontent.com%2F01org%2Flkp-
> > >
> tests%2Fmaster%2Fsbin%2Fmake.cross=01%7C01%7Claurentiu.tudor%40
> > >
> nxp.com%7C751676566b8f465b5fa108d4bb169974%7C686ea1d3bc2b4c6fa92c
> > >
> d99c5c301635%7C0=JvBQcG8MAs7PwDoXxYXe89sqs%2B2ADAiQd7sYCq
> > > 0YbPE%3D=0 -O ~/bin/make.cross
> > > > chmod +x ~/bin/make.cross
> > > > git checkout b065307fe0ad7859f01ce8560e6bdc590324561a
> > > > # save the attached .config to linux build tree
> > > > make.cross ARCH=arm64
> > > >
> > > > All errors (new ones prefixed by >>):
> > > >
> > > > >> make[5]: *** No rule to make target
> > > > >> 'drivers/staging/fsl-mc/bus/dpmng.o',
> > > needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.
> > > >make[5]: Target '__build' not remade because of errors.
> > >
> > > Crap, this isn't good.  But it looks like further patches fixes this 
> > > issue, right?
> >
> > Wow, doesn't look like so. I don't know how I managed to screw this up
> > so badly. :-(
> >
> > > Laurentiu, any ideas here?  You do always test every individual
> > > patch, right? :)
> >
> > Usually yes, but looks like this time I managed to mess it up. Sorry for the
> trouble.
> >
> > > Note, if you all ever got multi-arch building working for this code,
> > > I would have caught this a lot earlier, that should be something you
> > > fix up to get this out of staging, no reason to only depend on one arch.
> >
> > Got it. I don't think there's any arch depended stuff in the code so there
> shouldn't be issues.
> > I'll fix up this series and submit a v2 of the whole patch set and after 
> > that look
> into the multi-arch stuff.
> > Is this ok?
> 
> No, it's already in my tree, so either I revert the patch series, or I take a 
> fixup
> patch for it.  Which do you want me to do?

Let's go with reverting the whole series and me to resubmit a v2 because there 
are also a couple of comments from Joe Perches that I'd like to include.

---
Thanks & Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [staging:staging-testing 357/367] make[5]: *** No rule to make target 'drivers/staging/fsl-mc/bus/dpmng.o', needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.

[Greg Kroah-Hartman]

On Mon, Jun 26, 2017 at 08:39:20AM +, Laurentiu Tudor wrote:
> Hi Greg,
> 
> > -Original Message-
> > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> > 
> > On Sat, Jun 24, 2017 at 08:17:59PM +0800, kbuild test robot wrote:
> > > tree:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fgregkh%2Fstaging.git
> > =01%7C01%7Claurentiu.tudor%40nxp.com%7C751676566b8f465b5fa108d4bb1
> > 69974%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=hDMOrVmq8h6I
> > MBDuCHgARD44vX58GOPYWIQSqMsdAjo%3D=0 staging-testing
> > > head:   18cd9021ea035db85519391dbc429a5b1d0dd25b
> > > commit: b065307fe0ad7859f01ce8560e6bdc590324561a [357/367] staging:
> > > fsl-mc: remove dpmng API files
> > > config: arm64-allyesconfig (attached as .config)
> > > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> > > reproduce:
> > > wget
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.git
> > hubusercontent.com%2F01org%2Flkp-
> > tests%2Fmaster%2Fsbin%2Fmake.cross=01%7C01%7Claurentiu.tudor%40
> > nxp.com%7C751676566b8f465b5fa108d4bb169974%7C686ea1d3bc2b4c6fa92c
> > d99c5c301635%7C0=JvBQcG8MAs7PwDoXxYXe89sqs%2B2ADAiQd7sYCq
> > 0YbPE%3D=0 -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > git checkout b065307fe0ad7859f01ce8560e6bdc590324561a
> > > # save the attached .config to linux build tree
> > > make.cross ARCH=arm64
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > >> make[5]: *** No rule to make target 
> > > >> 'drivers/staging/fsl-mc/bus/dpmng.o',
> > needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.
> > >make[5]: Target '__build' not remade because of errors.
> > 
> > Crap, this isn't good.  But it looks like further patches fixes this issue, 
> > right?
> 
> Wow, doesn't look like so. I don't know how I managed to screw this up so 
> badly. :-(
> 
> > Laurentiu, any ideas here?  You do always test every individual patch, 
> > right? :)
> 
> Usually yes, but looks like this time I managed to mess it up. Sorry for the 
> trouble.
> 
> > Note, if you all ever got multi-arch building working for this code, I 
> > would have
> > caught this a lot earlier, that should be something you fix up to get this 
> > out of
> > staging, no reason to only depend on one arch.
> 
> Got it. I don't think there's any arch depended stuff in the code so there 
> shouldn't be issues.
> I'll fix up this series and submit a v2 of the whole patch set and after that 
> look into the multi-arch stuff.
> Is this ok?

No, it's already in my tree, so either I revert the patch series, or I
take a fixup patch for it.  Which do you want me to do?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [staging:staging-testing 357/367] make[5]: *** No rule to make target 'drivers/staging/fsl-mc/bus/dpmng.o', needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.

[Laurentiu Tudor]

Hi Greg,

> -Original Message-
> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
> 
> On Sat, Jun 24, 2017 at 08:17:59PM +0800, kbuild test robot wrote:
> > tree:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fgregkh%2Fstaging.git
> =01%7C01%7Claurentiu.tudor%40nxp.com%7C751676566b8f465b5fa108d4bb1
> 69974%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=hDMOrVmq8h6I
> MBDuCHgARD44vX58GOPYWIQSqMsdAjo%3D=0 staging-testing
> > head:   18cd9021ea035db85519391dbc429a5b1d0dd25b
> > commit: b065307fe0ad7859f01ce8560e6bdc590324561a [357/367] staging:
> > fsl-mc: remove dpmng API files
> > config: arm64-allyesconfig (attached as .config)
> > compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> > reproduce:
> > wget
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.git
> hubusercontent.com%2F01org%2Flkp-
> tests%2Fmaster%2Fsbin%2Fmake.cross=01%7C01%7Claurentiu.tudor%40
> nxp.com%7C751676566b8f465b5fa108d4bb169974%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0=JvBQcG8MAs7PwDoXxYXe89sqs%2B2ADAiQd7sYCq
> 0YbPE%3D=0 -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > git checkout b065307fe0ad7859f01ce8560e6bdc590324561a
> > # save the attached .config to linux build tree
> > make.cross ARCH=arm64
> >
> > All errors (new ones prefixed by >>):
> >
> > >> make[5]: *** No rule to make target 'drivers/staging/fsl-mc/bus/dpmng.o',
> needed by 'drivers/staging/fsl-mc/bus/mc-bus-driver.o'.
> >make[5]: Target '__build' not remade because of errors.
> 
> Crap, this isn't good.  But it looks like further patches fixes this issue, 
> right?

Wow, doesn't look like so. I don't know how I managed to screw this up so 
badly. :-(

> Laurentiu, any ideas here?  You do always test every individual patch, right? 
> :)

Usually yes, but looks like this time I managed to mess it up. Sorry for the 
trouble.

> Note, if you all ever got multi-arch building working for this code, I would 
> have
> caught this a lot earlier, that should be something you fix up to get this 
> out of
> staging, no reason to only depend on one arch.

Got it. I don't think there's any arch depended stuff in the code so there 
shouldn't be issues.
I'll fix up this series and submit a v2 of the whole patch set and after that 
look into the multi-arch stuff.
Is this ok?

---
Thanks & Best Regards, Laurentiu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/10] x86/hyper-v: use hypercall for remote TLB flush

[Vitaly Kuznetsov]

kbuild test robot <l...@intel.com> writes:

> Hi Vitaly,
>
> [auto build test ERROR on next-20170619]
> [cannot apply to tip/x86/core linus/master linux/master v4.12-rc6 v4.12-rc5 
> v4.12-rc4 v4.12-rc7]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/kys-exchange-microsoft-com/x86-hyper-v-include-hyperv-only-when-CONFIG_HYPERV-is-set/20170626-133601
> config: i386-randconfig-a0-06250447 (attached as .config)
> compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
>
> All errors (new ones prefixed by >>):
>
>arch/x86/hyperv/mmu.c: In function 'hyperv_flush_tlb_others':
>>> arch/x86/hyperv/mmu.c:120:32: error: passing argument 2 of 
>>> 'native_flush_tlb_others' from incompatible pointer type 
>>> [-Werror=incompatible-pointer-types]
>  native_flush_tlb_others(cpus, mm, start, end);
>^

It seems we're clashing with Andy's 

commit a2055abe9c6789cedef29abbdaa488a087faccc3
Author: Andy Lutomirski <l...@kernel.org>
Date:   Sun May 28 10:00:10 2017 -0700

x86/mm: Pass flush_tlb_info to flush_tlb_others() etc

The fix should be simple but in case you want me to rebase/resend please
let me know.

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: endian bitshift defects [ was: staging: fusb302: don't bitshift __le16 type ]

[Frans Klaver]

On Sat, Jun 24, 2017 at 1:37 AM, Julia Lawall  wrote:
>
>
> On Sat, 24 Jun 2017, Frans Klaver wrote:
>
>> Hm. For some reason the great mail filtering scheme decided to push
>> this past my inbox :-/
>>
>> On Sat, Jun 17, 2017 at 12:44 AM, Joe Perches  wrote:
>> > On Fri, 2017-06-16 at 19:45 +0200, Frans Klaver wrote:
>> >> The header field in struct pd_message is declared as an __le16 type. The
>> >> data in the message is supposed to be little endian. This means we don't
>> >> have to go and shift the individual bytes into position when we're
>> >> filling the buffer, we can just copy the contents right away. As an
>> >> added benefit we don't get fishy results on big endian systems anymore.
>> >
>> > Thanks for pointing this out.
>> >
>> > There are several instances of this class of error.
>>
>> There are other smells around __(le|be) types that show up in staging
>> that might be worth checking in the rest of the kernel as well. e.g.
>> converting to cpu and storing it back into itself (possibly with its
>> bytes reversed), direct assignments without conversion and what else
>> you might have. sparse obviously already flags anything fishy going on
>> with these types, but cannot distinguish between the classes of
>> errors. I'll need to acquaint myself with spatch a bit more to be able
>> to track that down.
>
> If you have concrete code examples, even fake ones, illustrating a class
> of problem, then that would be great.

I'll see if I can produce some somewhere this week.

Thanks,
Frans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 7/7] staging: wilc1000: Update ACM bit status

[Aditya Shankar]

Add a new function to update ACM bit status for a queue
for all access categories.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index e323fd4..929166a 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -461,6 +461,14 @@ static inline u8 ac_change(struct wilc *wilc, u8 *ac)
return 1;
 }
 
+static inline void ac_acm_bit(struct wilc *wilc, u32 reg)
+{
+   wilc->txq[AC_BK_Q].acm = (reg & 0x0002) >> BK_AC_ACM_STAT_POS;
+   wilc->txq[AC_BE_Q].acm = (reg & 0x0100) >> BE_AC_ACM_STAT_POS;
+   wilc->txq[AC_VI_Q].acm = (reg & 0x0001) >> VI_AC_ACM_STAT_POS;
+   wilc->txq[AC_VO_Q].acm = (reg & 0x0100) >> VO_AC_ACM_STAT_POS;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/7] staging: wilc1000: WMM classification of data

[Aditya Shankar]

This patch adds a new function to classify data to available
WMM access categories based on the DSCP value in the header.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 51 
 1 file changed, 51 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 8c997ba..d1ed3ba8 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -375,6 +375,57 @@ static inline void ac_q_limit(u8 ac, u16 *q_limit)
  sum) + 1;
 }
 
+static inline u8 ac_classify(struct wilc *wilc, struct txq_entry_t *tqe)
+{
+   u8 *eth_hdr_ptr;
+   u8 *buffer = tqe->buffer;
+   u8 ac;
+   u16 h_proto;
+
+   spin_lock_irqsave(>txq_spinlock, wilc->txq_spinlock_flags);
+
+   eth_hdr_ptr = [0];
+   h_proto = ntohs(*((unsigned short *)_hdr_ptr[12]));
+   if (h_proto == ETH_P_IP) {
+   u8 *ip_hdr_ptr;
+   u32 IHL, DSCP;
+
+   ip_hdr_ptr = [ETHERNET_HDR_LEN];
+   IHL = (ip_hdr_ptr[0] & 0xf) << 2;
+   DSCP = (ip_hdr_ptr[1] & 0xfc);
+
+   switch (DSCP) {
+   case 0x20:
+   case 0x40:
+   case 0x08:
+   ac = AC_BK_Q;
+   break;
+   case 0x80:
+   case 0xA0:
+   case 0x28:
+   ac = AC_VI_Q;
+   break;
+   case 0xC0:
+   case 0xd0:
+   case 0xE0:
+   case 0x88:
+   case 0xB8:
+   ac = AC_VO_Q;
+   break;
+   default:
+   ac = AC_BE_Q;
+   break;
+   }
+   } else {
+   ac  = AC_BE_Q;
+   }
+
+   tqe->q_num = ac;
+   spin_unlock_irqrestore(>txq_spinlock, wilc->txq_spinlock_flags);
+
+   return ac;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 5/7] staging: wilc1000: Get packet count from firmware

[Aditya Shankar]

Add a new function to get packet count from the firmware.

31:25   24  23:17   16  15:98   7:2 1   0
VO CNT  VO ACM  VI CNT  VI ACM  BE CNT  BE ACM  BK CNT  BK ACM  VMM ready

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 655f229..b3e1136 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -443,6 +443,14 @@ static inline int ac_balance(u8 *count, u8 *ratio)
return 0;
 }
 
+static inline void ac_pkt_count(u32 reg, u8 *pkt_count)
+{
+   pkt_count[AC_BK_Q] = (reg & 0x00fa) >> BK_AC_COUNT_POS;
+   pkt_count[AC_BE_Q] = (reg & 0xfe00) >> BE_AC_COUNT_POS;
+   pkt_count[AC_VI_Q] = (reg & 0x00fe) >> VI_AC_COUNT_POS;
+   pkt_count[AC_VO_Q] = (reg & 0xfe00) >> VO_AC_COUNT_POS;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/7] staging: wilc1000: Add function to calculate ac queue limit

[Aditya Shankar]

This patch adds a function which calculates the queue limit
for a given access category queue.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 42 
 1 file changed, 42 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index 9addef1..8c997ba 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -333,6 +333,48 @@ static int wilc_wlan_txq_add_cfg_pkt(struct wilc_vif *vif, 
u8 *buffer,
return 1;
 }
 
+static inline void ac_q_limit(u8 ac, u16 *q_limit)
+{
+   static bool initialized;
+   static u8 buffer[AC_BUFFER_SIZE];
+   static u16 cnt[NQUEUES];
+   u8 factors[NQUEUES] = {1, 1, 1, 1};
+   static u16 sum;
+   u16 i;
+   static u16 end_index;
+
+   if (!initialized) {
+   for (i = 0; i < AC_BUFFER_SIZE; i++)
+   buffer[i] = i % NQUEUES;
+
+   for (i = 0; i < NQUEUES; i++) {
+   cnt[i] = AC_BUFFER_SIZE * factors[i] / NQUEUES;
+   sum += cnt[i];
+   }
+   end_index = AC_BUFFER_SIZE - 1;
+   initialized = 1;
+   }
+   if (end_index > AC_BUFFER_SIZE - 1)
+   end_index = AC_BUFFER_SIZE - 1;
+
+   cnt[buffer[end_index]] -= factors[buffer[end_index]];
+   cnt[ac] += factors[ac];
+   sum += (factors[ac] - factors[buffer[end_index]]);
+
+   buffer[end_index] = ac;
+   if (end_index > 0)
+   end_index--;
+   else
+   end_index = AC_BUFFER_SIZE - 1;
+
+   for (i = 0; i < NQUEUES; i++)
+   if (!sum)
+   q_limit[i] = 1;
+   else
+   q_limit[i] = (cnt[i] * FLOW_CONTROL_UPPER_THRESHOLD /
+ sum) + 1;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 6/7] staging: wilc1000: Change ac based on acm status

[Aditya Shankar]

Add a new function to check and alter the ac if needed
based on the acm status for a particular queue.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index b3e1136..e323fd4 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -451,6 +451,16 @@ static inline void ac_pkt_count(u32 reg, u8 *pkt_count)
pkt_count[AC_VO_Q] = (reg & 0xfe00) >> VO_AC_COUNT_POS;
 }
 
+static inline u8 ac_change(struct wilc *wilc, u8 *ac)
+{
+   do {
+   if (wilc->txq[*ac].acm == 0)
+   return 0;
+   (*ac)++;
+   } while (*ac < NQUEUES);
+   return 1;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/7] staging: wilc1000: Add support for AC classification.

[Aditya Shankar]

This patch adds new variables and defines for adding access
category classification

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.h 
b/drivers/staging/wilc1000/wilc_wlan.h
index 7a5eba9..c97f94a 100644
--- a/drivers/staging/wilc1000/wilc_wlan.h
+++ b/drivers/staging/wilc1000/wilc_wlan.h
@@ -133,6 +133,17 @@
 
 #define MODALIAS   "WILC_SPI"
 #define GPIO_NUM   0x44
+
+#define NQUEUES4
+#define VO_AC_COUNT_POS25
+#define VO_AC_ACM_STAT_POS 24
+#define VI_AC_COUNT_POS17
+#define VI_AC_ACM_STAT_POS 16
+#define BE_AC_COUNT_POS9
+#define BE_AC_ACM_STAT_POS 8
+#define BK_AC_COUNT_POS2
+#define BK_AC_ACM_STAT_POS 1
+#define AC_BUFFER_SIZE 1000
 /***/
 /*E0 and later Interrupt flags.*/
 /***/
@@ -206,11 +217,25 @@ typedef void (*wilc_debug_func)(u32, char *, ...);
  *  Tx/Rx Queue Structure
  *
  /
+struct txq_handle {
+   struct txq_entry_t *txq_head;
+   struct txq_entry_t *txq_tail;
+   u16 count;
+   u8 acm;
+};
+
+enum ip_pkt_priority {
+   AC_VO_Q = 0,
+   AC_VI_Q = 1,
+   AC_BE_Q = 2,
+   AC_BK_Q = 3
+};
 
 struct txq_entry_t {
struct txq_entry_t *next;
struct txq_entry_t *prev;
int type;
+   u8 q_num;
int tcp_pending_ack_idx;
u8 *buffer;
int buffer_size;
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/7] Enable access category classification on Tx path

[Aditya Shankar]

This patch series adds changes made to implement access
category based data classification and manages buffers allocation
between different access categories on the Tx path.

Aditya Shankar (7):
  staging: wilc1000: Add support for AC classification.
  staging: wilc1000: Add function to calculate ac queue limit
  staging: wilc1000: WMM classification of data
  staging: wilc1000: Add function to balance packet count
  staging: wilc1000: Get packet count from firmware
  staging: wilc1000: Change ac based on acm status
  staging: wilc1000: Update ACM bit status

 drivers/staging/wilc1000/wilc_wlan.c | 136 +++
 drivers/staging/wilc1000/wilc_wlan.h |  25 +++
 2 files changed, 161 insertions(+)

-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4/7] staging: wilc1000: Add function to balance packet count

[Aditya Shankar]

Add a new function to track the cound of packets and
determine the ratio of current number of packets to
maximum count of packets.

Signed-off-by: Aditya Shankar 
---
 drivers/staging/wilc1000/wilc_wlan.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index d1ed3ba8..655f229 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -426,6 +426,23 @@ static inline u8 ac_classify(struct wilc *wilc, struct 
txq_entry_t *tqe)
return ac;
 }
 
+static inline int ac_balance(u8 *count, u8 *ratio)
+{
+   u8 i, max_count = 0;
+
+   if (!count || !ratio)
+   return -1;
+
+   for (i = 0; i < NQUEUES; i++)
+   if (count[i] > max_count)
+   max_count = count[i];
+
+   for (i = 0; i < NQUEUES; i++)
+   ratio[i] = max_count - count[i];
+
+   return 0;
+}
+
 int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void *priv, u8 *buffer,
  u32 buffer_size, wilc_tx_complete_func_t func)
 {
-- 
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/10] x86/hyper-v: use hypercall for remote TLB flush

[kbuild test robot]

Hi Vitaly,

[auto build test ERROR on next-20170619]
[cannot apply to tip/x86/core linus/master linux/master v4.12-rc6 v4.12-rc5 
v4.12-rc4 v4.12-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/kys-exchange-microsoft-com/x86-hyper-v-include-hyperv-only-when-CONFIG_HYPERV-is-set/20170626-133601
config: i386-randconfig-a0-06250447 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   arch/x86/hyperv/mmu.c: In function 'hyperv_flush_tlb_others':
>> arch/x86/hyperv/mmu.c:120:32: error: passing argument 2 of 
>> 'native_flush_tlb_others' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 native_flush_tlb_others(cpus, mm, start, end);
   ^
   In file included from arch/x86/hyperv/mmu.c:9:0:
   arch/x86/include/asm/tlbflush.h:256:6: note: expected 'const struct 
flush_tlb_info *' but argument is of type 'struct mm_struct *'
void native_flush_tlb_others(const struct cpumask *cpumask,
 ^
>> arch/x86/hyperv/mmu.c:120:2: error: too many arguments to function 
>> 'native_flush_tlb_others'
 native_flush_tlb_others(cpus, mm, start, end);
 ^
   In file included from arch/x86/hyperv/mmu.c:9:0:
   arch/x86/include/asm/tlbflush.h:256:6: note: declared here
void native_flush_tlb_others(const struct cpumask *cpumask,
 ^
   arch/x86/hyperv/mmu.c: In function 'hyperv_setup_mmu_ops':
>> arch/x86/hyperv/mmu.c:127:31: error: assignment from incompatible pointer 
>> type [-Werror=incompatible-pointer-types]
  pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
  ^
   cc1: some warnings being treated as errors

vim +/native_flush_tlb_others +120 arch/x86/hyperv/mmu.c

   114  
   115  local_irq_restore(flags);
   116  
   117  if (!(status & HV_HYPERCALL_RESULT_MASK))
   118  return;
   119  do_native:
 > 120  native_flush_tlb_others(cpus, mm, start, end);
   121  }
   122  
   123  void hyperv_setup_mmu_ops(void)
   124  {
   125  if (ms_hyperv.hints & HV_X64_REMOTE_TLB_FLUSH_RECOMMENDED) {
   126  pr_info("Hyper-V: Using hypercall for remote TLB 
flush\n");
 > 127  pv_mmu_ops.flush_tlb_others = hyperv_flush_tlb_others;
   128  }
   129  }
   130  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: sm750fb: always take the lock

[Frans Klaver]

There's no version number. Which one is the correct one?

On Mon, Jun 26, 2017 at 7:45 AM, AbdAllah-MEZITI
 wrote:
> This patch
> - will always take the lock
> - fix the sparse warning:
> drivers/staging/sm750fb/sm750.c:159:13: warning: context imbalance in 
> 'lynxfb_ops_fillrect' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:231:9: warning: context imbalance in 
> 'lynxfb_ops_copyarea' - different lock contexts for basic block
> drivers/staging/sm750fb/sm750.c:235:13: warning: context imbalance in 
> 'lynxfb_ops_imageblit' - different lock contexts for basic block
>
> Signed-off-by: AbdAllah MEZITI 
> ---
>  drivers/staging/sm750fb/sm750.c | 18 ++
>  1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 386d4ad..4a22190 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -186,16 +186,14 @@ static void lynxfb_ops_fillrect(struct fb_info *info,
>  * If not use spin_lock,system will die if user load driver
>  * and immediately unload driver frequently (dual)
>  */
> -   if (sm750_dev->fb_count > 1)
> -   spin_lock(_dev->slock);
> +   spin_lock(_dev->slock);
>
> sm750_dev->accel.de_fillrect(_dev->accel,
>  base, pitch, Bpp,
>  region->dx, region->dy,
>  region->width, region->height,
>  color, rop);
> -   if (sm750_dev->fb_count > 1)
> -   spin_unlock(_dev->slock);
> +   spin_unlock(_dev->slock);
>  }
>
>  static void lynxfb_ops_copyarea(struct fb_info *info,
> @@ -220,16 +218,14 @@ static void lynxfb_ops_copyarea(struct fb_info *info,
>  * If not use spin_lock, system will die if user load driver
>  * and immediately unload driver frequently (dual)
>  */
> -   if (sm750_dev->fb_count > 1)
> -   spin_lock(_dev->slock);
> +   spin_lock(_dev->slock);
>
> sm750_dev->accel.de_copyarea(_dev->accel,
>  base, pitch, region->sx, region->sy,
>  base, pitch, Bpp, region->dx, region->dy,
>  region->width, region->height,
>  HW_ROP2_COPY);
> -   if (sm750_dev->fb_count > 1)
> -   spin_unlock(_dev->slock);
> +   spin_unlock(_dev->slock);
>  }
>
>  static void lynxfb_ops_imageblit(struct fb_info *info,
> @@ -269,8 +265,7 @@ static void lynxfb_ops_imageblit(struct fb_info *info,
>  * If not use spin_lock, system will die if user load driver
>  * and immediately unload driver frequently (dual)
>  */
> -   if (sm750_dev->fb_count > 1)
> -   spin_lock(_dev->slock);
> +   spin_lock(_dev->slock);
>
> sm750_dev->accel.de_imageblit(_dev->accel,
>   image->data, image->width >> 3, 0,
> @@ -278,8 +273,7 @@ static void lynxfb_ops_imageblit(struct fb_info *info,
>   image->dx, image->dy,
>   image->width, image->height,
>   fgcol, bgcol, HW_ROP2_COPY);
> -   if (sm750_dev->fb_count > 1)
> -   spin_unlock(_dev->slock);
> +   spin_unlock(_dev->slock);
>  }
>
>  static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: sm750fb: always take the lock

[Frans Klaver]

On Sun, Jun 25, 2017 at 11:39 PM, AbdAllah-MEZITI
 wrote:
> Subject: [PATCH] staging: sm750fb: always take the lock

When sending a new version of your patch, include a version number:

Subject: [PATCH V2] staging: ...

Frans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel