Re: [RFC 1/2] netvsc: reference counting fix

[David Miller]

From: Stephen Hemminger 
Date: Sat, 13 Aug 2016 11:35:59 -0700

> This is how I think it should be fixed, but not tested yet.
> 
> Subjec: netvsc: use device not module reference counts
> 
> Fix how the cross-device reference counting is handled.  When VF is
> associated with the synthetic interface, the VF driver module should
> still be able to be unloaded.  The module unload code will callback
> with NETDEV_UNREGISTER event which breaks the connection safely.
> (Fixes 9f4b5ba5db4 hv_netvsc: Implement support for VF drivers on Hyper-V)
> 
> Signed-off-by: Stephen Hemminger 

This might not work.

It is assumed that when a netdev unregister happens, it may be done so
at any point in time.

Therefore that NETDEV_UNREGISTER event must eliminate any and all
references to a given netdev.  And that works perfectly fine right now
with all existing subsystems that take references to netdevs.

You'll have to add something so that a NETDEV_UNREGISTER event tears
this VF down and thus releases it's reference to the synthetic device.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue

[Joe Perches]

On Sun, 2016-08-14 at 14:15 +0200, Johannes Berg wrote:
> > 
> > It's a sparse defect.
> > 
> > Try again after patching sparse with Jes' patch:
> > http://marc.info/?l=linux-sparse=147091200720267=3
> Mine, not Jes's ;-)

Right, sorry 'bout that.

> But there's another patch going into the kernel to fix it:
> 
> https://www.ozlabs.org/~akpm/mmotm/broken-out/byteswap-dont-use-__builtin_bswap-with-sparse.patch

Thanks.

Maybe this test should be sparse version checked after
sparse is updated.

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

Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue

[Joe Perches]

On Sat, 2016-08-13 at 17:26 +0800, sunbing wrote:
> On Aug 12, 2016, at 22:30, Jes Sorensen  wrote:
> > sunbing  writes:
> > > On Aug 11, 2016, at 23:25, Jes Sorensen  wrote:
> > > > Bing Sun  writes:
> > > > > 
> > > > > Fixed sparse parse error:
> > > > > Expected constant expression in case statement.
[]
> > > > Pardon me here, but I find it really hard to see how this change is an
> > > > improvement over the old code in any shape or form.
> > > There is no functional improvement. 
> > > But before this patch, when we do: make C=1 M=drivers/staging/rtl8723au/
> > > An error output: 
> > > drivers/staging/rtl8723au//os_dep/os_intfs.c:287:14: error: Expected
> > > constant expression in case statement
> > > To avoid sparse parse error, a case statement converts to an if statement.
> > > So we got this patch.
> > Hello
> > 
> > I understand this part, but it seems to me we are changing the code due
> > to a broken test case in sparse. Does the warning go away if you use
> > __constant_htons() instead of htons()?
> > 
> > Jes
> Thanks for your guidance.
> 
> 1. If I use __constant_htons, checkpatch.pl will warning:
> WARNING: __constant_htons should be htons
> 
> 2. In os_intfs.c: rtw_classify8021d, there are only one case statement and a 
> default statement. So, convert "switch case" to "if else" is more readable in 
> my opinion.
> 
> So, I pushed this patch.
> 
> There are some patches convert use of __constant_htons to htons in kernel 
> logs. 
> Will there be a new patch convert to htons in the future if I use  
> __constant_htons now ?
> 
> After search through kernel code, there are 158 "case htons(...)" statements 
> and 
> 2 "case __constant_htons(...)" statements. Does this mean we can ignore 
> sparse 
> error and use "case htons(...)" ?
> 
> It makes me confused. More help, please.

It's a sparse defect.

Try again after patching sparse with Jes' patch:
http://marc.info/?l=linux-sparse=147091200720267=3

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

Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue

[Johannes Berg]

> It's a sparse defect.
> 
> Try again after patching sparse with Jes' patch:
> http://marc.info/?l=linux-sparse=147091200720267=3

Mine, not Jes's ;-)

But there's another patch going into the kernel to fix it:

https://www.ozlabs.org/~akpm/mmotm/broken-out/byteswap-dont-use-__builtin_bswap-with-sparse.patch

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

Re: [Linaro-mm-sig] [RESEND][PATCH 0/5] Ion cleanup

[Benjamin Gaignard]

This series of patches look good for me, thanks for the clean up

Reviewed-by: Benjamin Gaignard 

2016-08-08 18:52 GMT+02:00 Laura Abbott :
> I never saw any feedback or action on these patches so this is a resend.
> Probably hit the window when everyone was busy/traveling.
>
> ---
>
> Hi,
>
> This is some clean up of old Ion interfaces and APIs. These are interfaces 
> that
> mostly existed before dma_buf was well integrated into the kernel along with
> reservations for board files.
>
> If there are objections to deletion I expect it to turn into a discussion 
> about
> what other APIs need to be extended.
>
> Thanks,
> Laura
>
> Laura Abbott (5):
>   staging: android: ion: Get rid of ion_sg_table
>   staging: android: ion: Drop ion_phys interface
>   staging: android: ion: Get rid of map_dma/unmap_dma
>   staging: android: ion: Drop ion_carveout_allocate definitions
>   staging: android: ion: Get rid of ion_reserve
>
>  drivers/staging/android/ion/ion.c   | 103 
> ++--
>  drivers/staging/android/ion/ion.h   |  41 --
>  drivers/staging/android/ion/ion_carveout_heap.c |  33 +---
>  drivers/staging/android/ion/ion_chunk_heap.c|  17 +---
>  drivers/staging/android/ion/ion_cma_heap.c  |  34 +---
>  drivers/staging/android/ion/ion_priv.h  |  30 +--
>  drivers/staging/android/ion/ion_system_heap.c   |  44 +-
>  7 files changed, 19 insertions(+), 283 deletions(-)
>
> --
> 2.5.5
>
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel