Re: [PATCH] staging: comedi: Removed not necessary braces for single block
"interesting" email name you used here :) Please fix up, it has to match the signed-off-by line. I fixed and resent the patch again. --- Jitendra ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
On Wed, Jan 16, 2019 at 07:42:02AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 11:03:02PM -0700, Nathan Chancellor wrote:
> > When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
> > '-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
> > Clang failed at the modpost stage:
> >
> > ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> > undefined!
> > ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
> > ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> > undefined!
> >
> > These functions were marked as extern inline, meaning that if inlining
> > doesn't happen, the function will be undefined, as it is above.
> >
> > This happens to work with GCC because the '-fno-inline-functions' option
> > respects the __inline attribute so all instances of these functions are
> > inlined as expected and the definition doesn't actually matter. However,
> > with Clang and '-fno-inline-functions', a function has to be marked with
> > the __always_inline attribute to be considered for inlining, which none
> > of these functions are. Clang tries to find the symbol definition
> > elsewhere as it was told and fails, which trickles down to modpost.
> >
> > To make sure that this code compiles regardless of compiler and make the
> > intention of the code clearer, use 'static __always_inline' to ensure
> > that these functions are always inlined. Some alternative solutions
> > included 'extern __always_inline' or converting these functions to
> > macros (so the preprocessor deals with them) but I would argue this is
> > the more "standard" solution.
> >
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
> > b/drivers/staging/rtl8723bs/include/ieee80211.h
> > index bcc8dfa8e672..959e822315b5 100644
> > --- a/drivers/staging/rtl8723bs/include/ieee80211.h
> > +++ b/drivers/staging/rtl8723bs/include/ieee80211.h
> > @@ -850,18 +850,18 @@ enum ieee80211_state {
> > #define IP_FMT "%pI4"
> > #define IP_ARG(x) (x)
> >
> > -extern __inline int is_multicast_mac_addr(const u8 *addr)
> > +static __always_inline int is_multicast_mac_addr(const u8 *addr)
>
> Ick, really? This is in a .h file, the .c file sees this, so why isn't
> clang picking it up? Worst case it just makes it a "normal" function
> and doesn't inline it, right?
>
As I understand it, the meaning of 'extern inline' is basically use this
defintion when inlining, otherwise use one from a different file or
translation unit. See commit d0a8d9378d16 ("x86/paravirt: Make
native_save_fl() extern inline"). These functions don't have any other
declaration/definition so when they aren't inlined, they don't exist.
> How about just replacing "extern" with "static", that should solve this,
> adding "__always_inline" everywhere is not going to be fun and doesn't
> make any sense.
>
Yes, that would work (and what I originally tested). My assumption with
the code is that it was intended for this function to always be inlined
but if you'd rather it just be 'static', I am happy to send a v2!
> thanks,
>
> greg k-h
Thanks for the quick reply and review,
Nathan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 07:28:26AM +0100, Christian Brauner wrote:
> On Wed, Jan 16, 2019 at 07:25:46AM +0100, Christian Brauner wrote:
> > On Wed, Jan 16, 2019 at 03:01:04AM +, Wei Yongjun wrote:
> > > Fix to return a negative error code -ENOMEM from the new_inode() and
> > > d_make_root() error handling cases instead of 0, as done elsewhere in
> > > this function.
> > >
> > > Fixes: 3ad20fe393b3 ("binder: implement binderfs")
>
> This Fixes tag is technically wrong since this codepath was introduced
> by a commit that is still sitting in Greg's char-misc-linus branch. Not
> sure how to handle that though. Might just leave it.
Use the git commit id of the patch in that branch, it is not going to
change as I do not rebase that branch.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5] staging: Mediatek: Use individual config flags in Makefile
These drivers can be useful on other MT76xx SoCs, which have compatible peripherals. The drivers were selectable in Kconfig, but they were quietly excluded from the build because the SOC_MT7621 chip was not selected. So, make the Makefiles use the same flags as Kconfig for these drivers. mt7621-dma and mt7621-dts are left alone because they truly do require that SoC. I have personally confirmed that the mt7621-spi driver works on the MT7688, which was what prompted this change. Cc: linux-ker...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: NeilBrown Cc: sergio.paracuel...@gmail.com Signed-off-by: George Hilliard --- Changelog: v2: - Also make the change for skipped/forgotten drivers such as mt7621-eth v3..v4: - Rebase against staging-testing - Also make the change for new PCIe PHY driver - Slightly change commit wording v5: - Fix dependency issue in mt7621-mmc/Kconfig; it now needs to explicitly depend on RALINK because SOC_MT7621 is not required now - Remove check for nonexistent config MTD_NAND_RALINK from mt7621-mmc/Kconfig drivers/staging/Makefile| 14 +++--- drivers/staging/mt7621-mmc/Kconfig | 2 +- drivers/staging/mt7621-pci-phy/Makefile | 2 +- drivers/staging/mt7621-pci/Makefile | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 4d563ed0bc79..cc5530cc996b 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -41,14 +41,14 @@ obj-$(CONFIG_GREYBUS) += greybus/ obj-$(CONFIG_BCM2835_VCHIQ)+= vc04_services/ obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/ obj-$(CONFIG_PI433)+= pi433/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci-phy/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ -obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ +obj-$(CONFIG_PCI_MT7621) += mt7621-pci/ +obj-$(CONFIG_PCI_MT7621_PHY) += mt7621-pci-phy/ +obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/ +obj-$(CONFIG_SPI_MT7621) += mt7621-spi/ obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ -obj-$(CONFIG_SOC_MT7621) += ralink-gdma/ -obj-$(CONFIG_SOC_MT7621) += mt7621-mmc/ -obj-$(CONFIG_SOC_MT7621) += mt7621-eth/ +obj-$(CONFIG_DMA_RALINK) += ralink-gdma/ +obj-$(CONFIG_MTK_MMC) += mt7621-mmc/ +obj-$(CONFIG_NET_MEDIATEK_SOC_STAGING) += mt7621-eth/ obj-$(CONFIG_SOC_MT7621) += mt7621-dts/ obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/ obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/ diff --git a/drivers/staging/mt7621-mmc/Kconfig b/drivers/staging/mt7621-mmc/Kconfig index c6dfe8c637dc..1eb79cd6e22f 100644 --- a/drivers/staging/mt7621-mmc/Kconfig +++ b/drivers/staging/mt7621-mmc/Kconfig @@ -1,6 +1,6 @@ config MTK_MMC tristate "MTK SD/MMC" - depends on !MTD_NAND_RALINK && MMC + depends on RALINK && MMC config MTK_AEE_KDUMP bool "MTK AEE KDUMP" diff --git a/drivers/staging/mt7621-pci-phy/Makefile b/drivers/staging/mt7621-pci-phy/Makefile index 2b82ccfc28c6..a970056f05c1 100644 --- a/drivers/staging/mt7621-pci-phy/Makefile +++ b/drivers/staging/mt7621-pci-phy/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621-phy.o +obj-$(CONFIG_PCI_MT7621_PHY) += pci-mt7621-phy.o diff --git a/drivers/staging/mt7621-pci/Makefile b/drivers/staging/mt7621-pci/Makefile index 607b84bedcc3..d4655a726b61 100644 --- a/drivers/staging/mt7621-pci/Makefile +++ b/drivers/staging/mt7621-pci/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621.o +obj-$(CONFIG_PCI_MT7621) += pci-mt7621.o -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
On Tue, Jan 15, 2019 at 11:03:02PM -0700, Nathan Chancellor wrote:
> When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
> '-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
> Clang failed at the modpost stage:
>
> ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> undefined!
> ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
> ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko]
> undefined!
>
> These functions were marked as extern inline, meaning that if inlining
> doesn't happen, the function will be undefined, as it is above.
>
> This happens to work with GCC because the '-fno-inline-functions' option
> respects the __inline attribute so all instances of these functions are
> inlined as expected and the definition doesn't actually matter. However,
> with Clang and '-fno-inline-functions', a function has to be marked with
> the __always_inline attribute to be considered for inlining, which none
> of these functions are. Clang tries to find the symbol definition
> elsewhere as it was told and fails, which trickles down to modpost.
>
> To make sure that this code compiles regardless of compiler and make the
> intention of the code clearer, use 'static __always_inline' to ensure
> that these functions are always inlined. Some alternative solutions
> included 'extern __always_inline' or converting these functions to
> macros (so the preprocessor deals with them) but I would argue this is
> the more "standard" solution.
>
> Signed-off-by: Nathan Chancellor
> ---
> drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
> b/drivers/staging/rtl8723bs/include/ieee80211.h
> index bcc8dfa8e672..959e822315b5 100644
> --- a/drivers/staging/rtl8723bs/include/ieee80211.h
> +++ b/drivers/staging/rtl8723bs/include/ieee80211.h
> @@ -850,18 +850,18 @@ enum ieee80211_state {
> #define IP_FMT "%pI4"
> #define IP_ARG(x) (x)
>
> -extern __inline int is_multicast_mac_addr(const u8 *addr)
> +static __always_inline int is_multicast_mac_addr(const u8 *addr)
Ick, really? This is in a .h file, the .c file sees this, so why isn't
clang picking it up? Worst case it just makes it a "normal" function
and doesn't inline it, right?
How about just replacing "extern" with "static", that should solve this,
adding "__always_inline" everywhere is not going to be fun and doesn't
make any sense.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 07:25:46AM +0100, Christian Brauner wrote:
> On Wed, Jan 16, 2019 at 03:01:04AM +, Wei Yongjun wrote:
> > Fix to return a negative error code -ENOMEM from the new_inode() and
> > d_make_root() error handling cases instead of 0, as done elsewhere in
> > this function.
> >
> > Fixes: 3ad20fe393b3 ("binder: implement binderfs")
This Fixes tag is technically wrong since this codepath was introduced
by a commit that is still sitting in Greg's char-misc-linus branch. Not
sure how to handle that though. Might just leave it.
> > Signed-off-by: Wei Yongjun
> > ---
> > drivers/android/binderfs.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > index 9518e2e..2bf4b2b 100644
> > --- a/drivers/android/binderfs.c
> > +++ b/drivers/android/binderfs.c
> > @@ -519,8 +519,10 @@ static int binderfs_fill_super(struct super_block *sb,
> > void *data, int silent)
> > sb->s_fs_info = info;
> >
> > inode = new_inode(sb);
> > - if (!inode)
> > + if (!inode) {
> > + ret = -ENOMEM;
>
> Hey, thanks for the patch. Just a nit:
> can you please just do?
>
> ret = -ENOMEM;
> inode = new_inode(sb);
>
> This is more consistent with how we do it everywhere else and let's us
> avoid shoving ret = -ENOMEM into two places.
>
> Thanks!
> Christian
>
> > goto err_without_dentry;
> > + }
> >
> > inode->i_ino = FIRST_INODE;
> > inode->i_fop = _dir_operations;
> > @@ -530,8 +532,10 @@ static int binderfs_fill_super(struct super_block *sb,
> > void *data, int silent)
> > set_nlink(inode, 2);
> >
> > sb->s_root = d_make_root(inode);
> > - if (!sb->s_root)
> > + if (!sb->s_root) {
> > + ret = -ENOMEM;
> > goto err_without_dentry;
> > + }
> >
> > ret = binderfs_binder_ctl_create(sb);
> > if (ret)
> >
> >
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH -next] binderfs: fix error return code in binderfs_fill_super()
On Wed, Jan 16, 2019 at 03:01:04AM +, Wei Yongjun wrote:
> Fix to return a negative error code -ENOMEM from the new_inode() and
> d_make_root() error handling cases instead of 0, as done elsewhere in
> this function.
>
> Fixes: 3ad20fe393b3 ("binder: implement binderfs")
> Signed-off-by: Wei Yongjun
> ---
> drivers/android/binderfs.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 9518e2e..2bf4b2b 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -519,8 +519,10 @@ static int binderfs_fill_super(struct super_block *sb,
> void *data, int silent)
> sb->s_fs_info = info;
>
> inode = new_inode(sb);
> - if (!inode)
> + if (!inode) {
> + ret = -ENOMEM;
Hey, thanks for the patch. Just a nit:
can you please just do?
ret = -ENOMEM;
inode = new_inode(sb);
This is more consistent with how we do it everywhere else and let's us
avoid shoving ret = -ENOMEM into two places.
Thanks!
Christian
> goto err_without_dentry;
> + }
>
> inode->i_ino = FIRST_INODE;
> inode->i_fop = _dir_operations;
> @@ -530,8 +532,10 @@ static int binderfs_fill_super(struct super_block *sb,
> void *data, int silent)
> set_nlink(inode, 2);
>
> sb->s_root = d_make_root(inode);
> - if (!sb->s_root)
> + if (!sb->s_root) {
> + ret = -ENOMEM;
> goto err_without_dentry;
> + }
>
> ret = binderfs_binder_ctl_create(sb);
> if (ret)
>
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8723bs: Fix build error with Clang when inlining is disabled
When CONFIG_NO_AUTO_INLINE was present in linux-next (which added
'-fno-inline-functions' to KBUILD_CFLAGS), an allyesconfig build with
Clang failed at the modpost stage:
ERROR: "is_broadcast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_zero_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
ERROR: "is_multicast_mac_addr" [drivers/staging/rtl8723bs/r8723bs.ko] undefined!
These functions were marked as extern inline, meaning that if inlining
doesn't happen, the function will be undefined, as it is above.
This happens to work with GCC because the '-fno-inline-functions' option
respects the __inline attribute so all instances of these functions are
inlined as expected and the definition doesn't actually matter. However,
with Clang and '-fno-inline-functions', a function has to be marked with
the __always_inline attribute to be considered for inlining, which none
of these functions are. Clang tries to find the symbol definition
elsewhere as it was told and fails, which trickles down to modpost.
To make sure that this code compiles regardless of compiler and make the
intention of the code clearer, use 'static __always_inline' to ensure
that these functions are always inlined. Some alternative solutions
included 'extern __always_inline' or converting these functions to
macros (so the preprocessor deals with them) but I would argue this is
the more "standard" solution.
Signed-off-by: Nathan Chancellor
---
drivers/staging/rtl8723bs/include/ieee80211.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/ieee80211.h
b/drivers/staging/rtl8723bs/include/ieee80211.h
index bcc8dfa8e672..959e822315b5 100644
--- a/drivers/staging/rtl8723bs/include/ieee80211.h
+++ b/drivers/staging/rtl8723bs/include/ieee80211.h
@@ -850,18 +850,18 @@ enum ieee80211_state {
#define IP_FMT "%pI4"
#define IP_ARG(x) (x)
-extern __inline int is_multicast_mac_addr(const u8 *addr)
+static __always_inline int is_multicast_mac_addr(const u8 *addr)
{
return ((addr[0] != 0xff) && (0x01 & addr[0]));
}
-extern __inline int is_broadcast_mac_addr(const u8 *addr)
+static __always_inline int is_broadcast_mac_addr(const u8 *addr)
{
return ((addr[0] == 0xff) && (addr[1] == 0xff) && (addr[2] == 0xff) &&
\
(addr[3] == 0xff) && (addr[4] == 0xff) && (addr[5] == 0xff));
}
-extern __inline int is_zero_mac_addr(const u8 *addr)
+static __always_inline int is_zero_mac_addr(const u8 *addr)
{
return ((addr[0] == 0x00) && (addr[1] == 0x00) && (addr[2] == 0x00) &&
\
(addr[3] == 0x00) && (addr[4] == 0x00) && (addr[5] == 0x00));
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: Mediatek: Use individual config flags in Makefile
Hi George,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[cannot apply to v5.0-rc2 next-20190115]
[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/George-Hilliard/staging-Mediatek-Use-individual-config-flags-in-Makefile/20190116-084915
config: x86_64-randconfig-e0-201902 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-14) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from drivers/staging/mt7621-mmc/dbg.c:51:
drivers/staging/mt7621-mmc/mt6575_sd.h: In function 'sdr_set_bits':
drivers/staging/mt7621-mmc/mt6575_sd.h:459:12: error: implicit declaration
of function 'readl'; did you mean 'd_real'?
[-Werror=implicit-function-declaration]
u32 val = readl(reg);
^
d_real
>> drivers/staging/mt7621-mmc/mt6575_sd.h:462:2: error: implicit declaration of
>> function 'writel'; did you mean 'wrmsrl'?
>> [-Werror=implicit-function-declaration]
writel(val, reg);
^~
wrmsrl
cc1: some warnings being treated as errors
vim +462 drivers/staging/mt7621-mmc/mt6575_sd.h
8b634a9c John Crispin 2018-03-15 456
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 457 static inline void
sdr_set_bits(void __iomem *reg, u32 bs)
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 458 {
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 @459 u32 val = readl(reg);
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 460
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 461 val |= bs;
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 @462 writel(val, reg);
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 463 }
0b78f05d Christian Lütke-Stetzkamp 2018-04-24 464
:: The code at line 462 was first introduced by commit
:: 0b78f05d510b01e353481f5bccb63661d2cb5c32 staging: mt7621-mmc: Correct
datatypes for io and sanitize io access
:: TO: Christian Lütke-Stetzkamp
:: CC: Greg Kroah-Hartman
---
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 -next] binderfs: fix error return code in binderfs_fill_super()
Fix to return a negative error code -ENOMEM from the new_inode() and
d_make_root() error handling cases instead of 0, as done elsewhere in
this function.
Fixes: 3ad20fe393b3 ("binder: implement binderfs")
Signed-off-by: Wei Yongjun
---
drivers/android/binderfs.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
index 9518e2e..2bf4b2b 100644
--- a/drivers/android/binderfs.c
+++ b/drivers/android/binderfs.c
@@ -519,8 +519,10 @@ static int binderfs_fill_super(struct super_block *sb,
void *data, int silent)
sb->s_fs_info = info;
inode = new_inode(sb);
- if (!inode)
+ if (!inode) {
+ ret = -ENOMEM;
goto err_without_dentry;
+ }
inode->i_ino = FIRST_INODE;
inode->i_fop = _dir_operations;
@@ -530,8 +532,10 @@ static int binderfs_fill_super(struct super_block *sb,
void *data, int silent)
set_nlink(inode, 2);
sb->s_root = d_make_root(inode);
- if (!sb->s_root)
+ if (!sb->s_root) {
+ ret = -ENOMEM;
goto err_without_dentry;
+ }
ret = binderfs_binder_ctl_create(sb);
if (ret)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/14/19 11:13 AM, Liam Mark wrote:
> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>
>> Buffers may not be mapped from the CPU so skip cache maintenance here.
>> Accesses from the CPU to a cached heap should be bracketed with
>> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
>>
>> Signed-off-by: Andrew F. Davis
>> ---
>> drivers/staging/android/ion/ion.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 14e48f6eb734..09cb5a8e2b09 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
>> dma_buf_attachment *attachment,
>>
>> table = a->table;
>>
>> -if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>> -direction))
>> +if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
>
> Unfortunately I don't think you can do this for a couple reasons.
> You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
> If the calls to {begin,end}_cpu_access were made before the call to
> dma_buf_attach then there won't have been a device attached so the calls
> to {begin,end}_cpu_access won't have done any cache maintenance.
>
That should be okay though, if you have no attachments (or all
attachments are IO-coherent) then there is no need for cache
maintenance. Unless you mean a sequence where a non-io-coherent device
is attached later after data has already been written. Does that
sequence need supporting? DMA-BUF doesn't have to allocate the backing
memory until map_dma_buf() time, and that should only happen after all
the devices have attached so it can know where to put the buffer. So we
shouldn't expect any CPU access to buffers before all the devices are
attached and mapped, right?
> Also ION no longer provides DMA ready memory, so if you are not doing CPU
> access then there is no requirement (that I am aware of) for you to call
> {begin,end}_cpu_access before passing the buffer to the device and if this
> buffer is cached and your device is not IO-coherent then the cache maintenance
> in ion_map_dma_buf and ion_unmap_dma_buf is required.
>
If I am not doing any CPU access then why do I need CPU cache
maintenance on the buffer?
Andrew
>> return ERR_PTR(-ENOMEM);
>>
>> return table;
>> @@ -272,7 +272,8 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment
>> *attachment,
>>struct sg_table *table,
>>enum dma_data_direction direction)
>> {
>> -dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
>> +dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents,
>> + direction, DMA_ATTR_SKIP_CPU_SYNC);
>> }
>>
>> static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
>> --
>> 2.19.1
>>
>> ___
>> devel mailing list
>> de...@linuxdriverproject.org
>> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>>
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: imx: capture: Allow event subscribe/unsubscribe
Implement the vidioc_(un)subscribe_event operations. Imx will allow
subscribing to the imx-specific frame interval error events, events
from subdevices (V4L2_EVENT_SOURCE_CHANGE), and control events.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-capture.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/staging/media/imx/imx-media-capture.c
b/drivers/staging/media/imx/imx-media-capture.c
index b37e1186eb2f..4dfbe05d203e 100644
--- a/drivers/staging/media/imx/imx-media-capture.c
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -335,6 +335,21 @@ static int capture_s_parm(struct file *file, void *fh,
return 0;
}
+static int capture_subscribe_event(struct v4l2_fh *fh,
+ const struct v4l2_event_subscription *sub)
+{
+ switch (sub->type) {
+ case V4L2_EVENT_IMX_FRAME_INTERVAL_ERROR:
+ return v4l2_event_subscribe(fh, sub, 0, NULL);
+ case V4L2_EVENT_SOURCE_CHANGE:
+ return v4l2_src_change_event_subscribe(fh, sub);
+ case V4L2_EVENT_CTRL:
+ return v4l2_ctrl_subscribe_event(fh, sub);
+ default:
+ return -EINVAL;
+ }
+}
+
static const struct v4l2_ioctl_ops capture_ioctl_ops = {
.vidioc_querycap= vidioc_querycap,
@@ -362,6 +377,9 @@ static const struct v4l2_ioctl_ops capture_ioctl_ops = {
.vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon= vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
+
+ .vidioc_subscribe_event = capture_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
/*
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] media: imx: queue subdev events to reachable video devices
In order to receive events generated by subdevices on the video capture
nodes, those events need to be forwarded to the subdevice's list of
reachable video capture devices.
Note this will queue the event to a video device even if there is
no actual _enabled_ media path from the sub-device to the video device.
So a future improvement is to skip the video device if there is no enabled
path to it from the sub-device. The entity->pipe pointer can't be
used for this check because in imx-media a sub-device can be a
member to more than one streaming pipeline at a time.
Signed-off-by: Steve Longerbeam
---
Changes in v2:
- split out the implementation of (un)subscribe_event on the video
capture device to a separate patch.
---
drivers/staging/media/imx/imx-media-dev.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index 4b344a4a3706..25e916562c66 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -442,6 +442,29 @@ static const struct media_device_ops imx_media_md_ops = {
.link_notify = imx_media_link_notify,
};
+static void imx_media_notify(struct v4l2_subdev *sd,
+unsigned int notification,
+void *arg)
+{
+ struct media_entity *entity = >entity;
+ int i;
+
+ if (notification != V4L2_DEVICE_NOTIFY_EVENT)
+ return;
+
+ for (i = 0; i < entity->num_pads; i++) {
+ struct media_pad *pad = >pads[i];
+ struct imx_media_pad_vdev *pad_vdev;
+ struct list_head *pad_vdev_list;
+
+ pad_vdev_list = to_pad_vdev_list(sd, pad->index);
+ if (!pad_vdev_list)
+ continue;
+ list_for_each_entry(pad_vdev, pad_vdev_list, list)
+ v4l2_event_queue(pad_vdev->vdev->vfd, arg);
+ }
+}
+
static int imx_media_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
@@ -462,6 +485,7 @@ static int imx_media_probe(struct platform_device *pdev)
mutex_init(>mutex);
imxmd->v4l2_dev.mdev = >md;
+ imxmd->v4l2_dev.notify = imx_media_notify;
strscpy(imxmd->v4l2_dev.name, "imx-media",
sizeof(imxmd->v4l2_dev.name));
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper
On 1/15/19 10:43 AM, Laura Abbott wrote:
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
backing memory.
Based originally on the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.
Suggested-by: Etienne Carriere
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Kconfig | 10 ++
drivers/staging/android/ion/Makefile | 1 +
drivers/staging/android/ion/ion.h | 16 +++
.../staging/android/ion/ion_unmapped_heap.c | 123 ++
drivers/staging/android/uapi/ion.h | 3 +
5 files changed, 153 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 0fdda6f62953..a117b8b91b14 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -42,3 +42,13 @@ config ION_CMA_HEAP
Choose this option to enable CMA heaps with Ion. This heap is
backed
by the Contiguous Memory Allocator (CMA). If your system has
these
regions, you should say Y here.
+
+config ION_UNMAPPED_HEAP
+ bool "ION unmapped heap support"
+ depends on ION
+ help
+ Choose this option to enable UNMAPPED heaps with Ion. This heap is
+ backed in specific memory pools, carveout from the Linux memory.
+ Unlike carveout heaps these are assumed to be not mappable by
+ kernel or user-space.
+ Unless you know your system has these regions, you should say N
here.
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 17f3a7569e3d..c71a1f3de581 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o
ion_page_pool.o
obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 97b2876b165a..ce74332018ba 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -341,4 +341,20 @@ static inline struct ion_heap
*ion_chunk_heap_create(phys_addr_t base, size_t si
}
#endif
+#ifdef CONFIG_ION_UNMAPPED_HEAP
+/**
+ * ion_unmapped_heap_create
+ * @base: base address of carveout memory
+ * @size: size of carveout memory region
+ *
+ * Creates an unmapped ion_heap using the passed in data
+ */
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t
size);
+#else
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
#endif /* _ION_H */
diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c
b/drivers/staging/android/ion/ion_unmapped_heap.c
new file mode 100644
index ..7602b659c2ec
--- /dev/null
+++ b/drivers/staging/android/ion/ion_unmapped_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator unmapped heap helper
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated -
http://www.ti.com/
+ * Andrew F. Davis
+ *
+ * ION "unmapped" heaps are physical memory heaps not by default
mapped into
+ * a virtual address space. The buffer owner can explicitly request
kernel
+ * space mappings but the underlying memory may still not be
accessible for
+ * various reasons, such as firewalls.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ion.h"
+
+#define ION_UNMAPPED_ALLOCATE_FAIL -1
+
+struct ion_unmapped_heap {
+ struct ion_heap heap;
+ struct gen_pool *pool;
+};
+
+static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+ unsigned long offset;
+
+ offset = gen_pool_alloc(unmapped_heap->pool, size);
+ if (!offset)
+ return ION_UNMAPPED_ALLOCATE_FAIL;
+
+ return offset;
+}
+
+static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+
+ gen_pool_free(unmapped_heap->pool, addr, size);
+}
+
+static int ion_unmapped_heap_allocate(struct ion_heap *heap,
+ struct ion_buffer *buffer,
+ unsigned long size,
+
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap should be bracketed with
{begin,end}_cpu_access calls so maintenance should not be needed anyway.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 14e48f6eb734..09cb5a8e2b09 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
dma_buf_attachment *attachment,
table = a->table;
- if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
- direction))
+ if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
+ direction, DMA_ATTR_SKIP_CPU_SYNC))
Unfortunately I don't think you can do this for a couple reasons.
You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
If the calls to {begin,end}_cpu_access were made before the call to
dma_buf_attach then there won't have been a device attached so the calls
to {begin,end}_cpu_access won't have done any cache maintenance.
That should be okay though, if you have no attachments (or all
attachments are IO-coherent) then there is no need for cache
maintenance. Unless you mean a sequence where a non-io-coherent device
is attached later after data has already been written. Does that
sequence need supporting?
Yes, but also I think there are cases where CPU access can happen before
in Android, but I will focus on later for now.
DMA-BUF doesn't have to allocate the backing
memory until map_dma_buf() time, and that should only happen after all
the devices have attached so it can know where to put the buffer. So we
shouldn't expect any CPU access to buffers before all the devices are
attached and mapped, right?
Here is an example where CPU access can happen later in Android.
Camera device records video -> software post processing -> video device
(who does compression of raw data) and writes to a file
In this example assume the buffer is cached and the devices are not
IO-coherent (quite common).
This is the start of the problem, having cached mappings of memory that
is also being accessed non-coherently is going to cause issues one way
or another. On top of the speculative cache fills that have to be
constantly fought back against with CMOs like below; some coherent
interconnects behave badly when you mix coherent and non-coherent access
(snoop filters get messed up).
The solution is to either always have the addresses marked non-coherent
(like device memory, no-map carveouts), or if you really want to use
regular system memory allocated at runtime, then all cached mappings of
it need to be dropped, even the kernel logical address (area as painful
as that would be).
I agree it's broken, hence my desire to remove it :)
The other problem is that uncached buffers are being used for
performance reason so anything that would involve getting
rid of the logical address would probably negate any performance
benefit.
ION buffer is allocated.
//Camera device records video
dma_buf_attach
dma_map_attachment (buffer needs to be cleaned)
Why does the buffer need to be cleaned here? I just got through reading
the thread linked by Laura in the other reply. I do like +Brian's
suggestion of tracking if the buffer has had CPU access since the last
time and only flushing the cache if it has. As unmapped heaps never get
CPU mapped this would never be the case for unmapped heaps, it solves my
problem.
[camera device writes to buffer]
dma_buf_unmap_attachment (buffer needs to be invalidated)
It doesn't know there will be any further CPU access, it could get freed
after this for all we know, the invalidate can be saved until the CPU
requests access again.
dma_buf_detach (device cannot stay attached because it is being sent down
the pipeline and Camera doesn't know the end of the use case)
This seems like a broken use-case, I understand the desire to keep
everything as modular as possible and separate the steps, but at this
point no one owns this buffers backing memory, not the CPU or any
device. I would go as far as to say DMA-BUF should be free now to
de-allocate the backing storage if it wants, that way it could get ready
for the next attachment, which may change the required backing memory
completely.
All devices should attach before the first mapping, and only let go
after the task is complete, otherwise this buffers data needs copied off
to a different location or the CPU needs to take ownership in-between.
Maybe it's broken but it's the status quo and we spent a good
Re: [PATCH 00/14] Misc ION cleanups and adding unmapped heap
On 1/15/19 9:47 AM, Andrew F. Davis wrote: On 1/14/19 8:39 PM, Laura Abbott wrote: On 1/11/19 10:05 AM, Andrew F. Davis wrote: Hello all, This is a set of (hopefully) non-controversial cleanups for the ION framework and current set of heaps. These were found as I start to familiarize myself with the framework to help in whatever way I can in getting all this up to the standards needed for de-staging. I would like to get some ideas of what is left to work on to get ION out of staging. Has there been some kind of agreement on what ION should eventually end up being? To me it looks like it is being whittled away at to it's most core functions. To me that is looking like being a DMA-BUF user-space front end, simply advertising available memory backings in a system and providing allocations as DMA-BUF handles. If this is the case then it looks close to being ready to me at least, but I would love to hear any other opinions and concerns. Yes, at this point the only functionality that people are really depending on is the ability to allocate a dma_buf easily from userspace. Back to this patchset, the last patch may be a bit different than the others, it adds an unmapped heaps type and creation helper. I wanted to get this in to show off another heap type and maybe some issues we may have with the current ION framework. The unmapped heap is used when the backing memory should not (or cannot) be touched. Currently this kind of heap is used for firewalled secure memory that can be allocated like normal heap memory but only used by secure devices (OP-TEE, crypto HW, etc). It is basically just copied from the "carveout" heap type with the only difference being it is not mappable to userspace and we do not clear the memory (as we should not map it either). So should this really be a new heap type? Or maybe advertised as a carveout heap but with an additional allocation flag? Perhaps we do away with "types" altogether and just have flags, coherent/non-coherent, mapped/unmapped, etc. Maybe more thinking will be needed afterall.. So the cleanup looks okay (I need to finish reviewing) but I'm not a fan of adding another heaptype without solving the problem of adding some sort of devicetree binding or other method of allocating and placing Ion heaps. That plus uncached buffers are one of the big open problems that need to be solved for destaging Ion. See https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/ for some background on that problem. I'm under the impression that adding heaps like carveouts/chunk will be rather system specific and so do not lend themselves well to a universal DT style exporter. For instance a carveout memory space can be reported by a device at runtime, then the driver managing that device should go and use the carveout heap helpers to export that heap. If this is the case then I'm not sure it is a problem for the ION core framework to solve, but rather the users of it to figure out how best to create the various heaps. All Ion needs to do is allow exporting and advertising them IMHO. I think it is a problem for the Ion core framework to take care of. Ion is useless if you don't actually have the heaps. Nobody has actually gotten a full Ion solution end-to-end with a carveout heap working in mainline because any proposals have been rejected. I think we need at least one example in mainline of how creating a carveout heap would work. Thanks for the background thread link, I've been looking for some info on current status of all this and "ion" is a bit hard to search the lists for. The core reason for posting this cleanup series is to throw my hat into the ring of all this Ion work and start getting familiar with the pending issues. The last two patches are not all that important to get in right now. In that thread you linked above, it seems we may have arrived at a similar problem for different reasons. I think the root issue is the Ion core makes too many assumptions about the heap memory. My proposal would be to allow the heap exporters more control over the DMA-BUF ops, maybe even going as far as letting them provide their own complete struct dma_buf_ops. Let me give an example where I think this is going to be useful. We have the classic constraint solving problem on our SoCs. Our SoCs are full of various coherent and non-coherent devices, some require contiguous memory allocations, others have in-line IOMMUs so can operate on non-contiguous, etc.. DMA-BUF has a solution designed in for this we can use, namely allocation at map time after all the attachments have come in. The checking of each attached device to find the right backing memory is something the DMA-BUF exporter has to do, and so this SoC specific logic would have to be added to each exporting framework (DRM, V4L2, etc), unless we have one unified system exporter everyone uses, Ion. That's how dmabuf is supposed to work in theory but in practice we also have the case
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark wrote:
>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> Buffers may not be mapped from the CPU so skip cache maintenance here.
> Accesses from the CPU to a cached heap should be bracketed with
> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/staging/android/ion/ion.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 14e48f6eb734..09cb5a8e2b09 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
> dma_buf_attachment *attachment,
>
> table = a->table;
>
> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> - direction))
> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
> + direction, DMA_ATTR_SKIP_CPU_SYNC))
Unfortunately I don't think you can do this for a couple reasons.
You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
If the calls to {begin,end}_cpu_access were made before the call to
dma_buf_attach then there won't have been a device attached so the calls
to {begin,end}_cpu_access won't have done any cache maintenance.
>>>
>>> That should be okay though, if you have no attachments (or all
>>> attachments are IO-coherent) then there is no need for cache
>>> maintenance. Unless you mean a sequence where a non-io-coherent device
>>> is attached later after data has already been written. Does that
>>> sequence need supporting?
>>
>> Yes, but also I think there are cases where CPU access can happen before
>> in Android, but I will focus on later for now.
>>
>>> DMA-BUF doesn't have to allocate the backing
>>> memory until map_dma_buf() time, and that should only happen after all
>>> the devices have attached so it can know where to put the buffer. So we
>>> shouldn't expect any CPU access to buffers before all the devices are
>>> attached and mapped, right?
>>>
>>
>> Here is an example where CPU access can happen later in Android.
>>
>> Camera device records video -> software post processing -> video device
>> (who does compression of raw data) and writes to a file
>>
>> In this example assume the buffer is cached and the devices are not
>> IO-coherent (quite common).
>>
>
> This is the start of the problem, having cached mappings of memory that
> is also being accessed non-coherently is going to cause issues one way
> or another. On top of the speculative cache fills that have to be
> constantly fought back against with CMOs like below; some coherent
> interconnects behave badly when you mix coherent and non-coherent access
> (snoop filters get messed up).
>
> The solution is to either always have the addresses marked non-coherent
> (like device memory, no-map carveouts), or if you really want to use
> regular system memory allocated at runtime, then all cached mappings of
> it need to be dropped, even the kernel logical address (area as painful
> as that would be).
>
>> ION buffer is allocated.
>>
>> //Camera device records video
>> dma_buf_attach
>> dma_map_attachment (buffer needs to be cleaned)
>
> Why does the buffer need to be cleaned here? I just got through reading
> the thread linked by Laura in the other reply. I do like +Brian's
Actually +Brian this time :)
> suggestion of tracking if the buffer has had CPU access since the last
> time and only flushing the cache if it has. As unmapped heaps never get
> CPU mapped this would never be the case for unmapped heaps, it solves my
> problem.
>
>> [camera device writes to buffer]
>> dma_buf_unmap_attachment (buffer needs to be invalidated)
>
> It doesn't know there will be any further CPU access, it could get freed
> after this for all we know, the invalidate can be saved until the CPU
> requests access again.
>
>> dma_buf_detach (device cannot stay attached because it is being sent down
>> the pipeline and Camera doesn't know the end of the use case)
>>
>
> This seems like a broken use-case, I understand the desire to keep
> everything as modular as possible and separate the steps, but at this
> point no one owns this buffers backing memory, not the CPU or any
> device. I would go as far as to say DMA-BUF should be free now to
> de-allocate the backing storage if it wants, that way it could get ready
> for the next attachment, which may change the required backing memory
> completely.
>
> All devices should attach before the first mapping, and only let go
> after the task is complete, otherwise this buffers data needs copied off
> to a different
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On 1/15/19 11:45 AM, Liam Mark wrote:
> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap should be bracketed with
{begin,end}_cpu_access calls so maintenance should not be needed anyway.
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/ion.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 14e48f6eb734..09cb5a8e2b09 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
dma_buf_attachment *attachment,
table = a->table;
- if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
- direction))
+ if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
+direction, DMA_ATTR_SKIP_CPU_SYNC))
>>>
>>> Unfortunately I don't think you can do this for a couple reasons.
>>> You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
>>> If the calls to {begin,end}_cpu_access were made before the call to
>>> dma_buf_attach then there won't have been a device attached so the calls
>>> to {begin,end}_cpu_access won't have done any cache maintenance.
>>>
>>
>> That should be okay though, if you have no attachments (or all
>> attachments are IO-coherent) then there is no need for cache
>> maintenance. Unless you mean a sequence where a non-io-coherent device
>> is attached later after data has already been written. Does that
>> sequence need supporting?
>
> Yes, but also I think there are cases where CPU access can happen before
> in Android, but I will focus on later for now.
>
>> DMA-BUF doesn't have to allocate the backing
>> memory until map_dma_buf() time, and that should only happen after all
>> the devices have attached so it can know where to put the buffer. So we
>> shouldn't expect any CPU access to buffers before all the devices are
>> attached and mapped, right?
>>
>
> Here is an example where CPU access can happen later in Android.
>
> Camera device records video -> software post processing -> video device
> (who does compression of raw data) and writes to a file
>
> In this example assume the buffer is cached and the devices are not
> IO-coherent (quite common).
>
This is the start of the problem, having cached mappings of memory that
is also being accessed non-coherently is going to cause issues one way
or another. On top of the speculative cache fills that have to be
constantly fought back against with CMOs like below; some coherent
interconnects behave badly when you mix coherent and non-coherent access
(snoop filters get messed up).
The solution is to either always have the addresses marked non-coherent
(like device memory, no-map carveouts), or if you really want to use
regular system memory allocated at runtime, then all cached mappings of
it need to be dropped, even the kernel logical address (area as painful
as that would be).
> ION buffer is allocated.
>
> //Camera device records video
> dma_buf_attach
> dma_map_attachment (buffer needs to be cleaned)
Why does the buffer need to be cleaned here? I just got through reading
the thread linked by Laura in the other reply. I do like +Brian's
suggestion of tracking if the buffer has had CPU access since the last
time and only flushing the cache if it has. As unmapped heaps never get
CPU mapped this would never be the case for unmapped heaps, it solves my
problem.
> [camera device writes to buffer]
> dma_buf_unmap_attachment (buffer needs to be invalidated)
It doesn't know there will be any further CPU access, it could get freed
after this for all we know, the invalidate can be saved until the CPU
requests access again.
> dma_buf_detach (device cannot stay attached because it is being sent down
> the pipeline and Camera doesn't know the end of the use case)
>
This seems like a broken use-case, I understand the desire to keep
everything as modular as possible and separate the steps, but at this
point no one owns this buffers backing memory, not the CPU or any
device. I would go as far as to say DMA-BUF should be free now to
de-allocate the backing storage if it wants, that way it could get ready
for the next attachment, which may change the required backing memory
completely.
All devices should attach before the first mapping, and only let go
after the task is complete, otherwise this buffers data needs copied off
to a different location or the CPU needs to take ownership in-between.
> //buffer is send down the pipeline
>
> // Usersapce software post processing occurs
> mmap buffer
Perhaps the invalidate should happen here in mmap.
>
Re: [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
backing memory.
Based originally on the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.
Suggested-by: Etienne Carriere
Signed-off-by: Andrew F. Davis
---
drivers/staging/android/ion/Kconfig | 10 ++
drivers/staging/android/ion/Makefile | 1 +
drivers/staging/android/ion/ion.h | 16 +++
.../staging/android/ion/ion_unmapped_heap.c | 123 ++
drivers/staging/android/uapi/ion.h | 3 +
5 files changed, 153 insertions(+)
create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 0fdda6f62953..a117b8b91b14 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -42,3 +42,13 @@ config ION_CMA_HEAP
Choose this option to enable CMA heaps with Ion. This heap is
backed
by the Contiguous Memory Allocator (CMA). If your system has
these
regions, you should say Y here.
+
+config ION_UNMAPPED_HEAP
+ bool "ION unmapped heap support"
+ depends on ION
+ help
+ Choose this option to enable UNMAPPED heaps with Ion. This heap is
+ backed in specific memory pools, carveout from the Linux memory.
+ Unlike carveout heaps these are assumed to be not mappable by
+ kernel or user-space.
+ Unless you know your system has these regions, you should say N
here.
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 17f3a7569e3d..c71a1f3de581 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o
ion_page_pool.o
obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 97b2876b165a..ce74332018ba 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -341,4 +341,20 @@ static inline struct ion_heap
*ion_chunk_heap_create(phys_addr_t base, size_t si
}
#endif
+#ifdef CONFIG_ION_UNMAPPED_HEAP
+/**
+ * ion_unmapped_heap_create
+ * @base: base address of carveout memory
+ * @size: size of carveout memory region
+ *
+ * Creates an unmapped ion_heap using the passed in data
+ */
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t
size);
+#else
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
#endif /* _ION_H */
diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c
b/drivers/staging/android/ion/ion_unmapped_heap.c
new file mode 100644
index ..7602b659c2ec
--- /dev/null
+++ b/drivers/staging/android/ion/ion_unmapped_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator unmapped heap helper
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated -
http://www.ti.com/
+ * Andrew F. Davis
+ *
+ * ION "unmapped" heaps are physical memory heaps not by default
mapped into
+ * a virtual address space. The buffer owner can explicitly request
kernel
+ * space mappings but the underlying memory may still not be
accessible for
+ * various reasons, such as firewalls.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ion.h"
+
+#define ION_UNMAPPED_ALLOCATE_FAIL -1
+
+struct ion_unmapped_heap {
+ struct ion_heap heap;
+ struct gen_pool *pool;
+};
+
+static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+ unsigned long offset;
+
+ offset = gen_pool_alloc(unmapped_heap->pool, size);
+ if (!offset)
+ return ION_UNMAPPED_ALLOCATE_FAIL;
+
+ return offset;
+}
+
+static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
+ unsigned long size)
+{
+ struct ion_unmapped_heap *unmapped_heap =
+ container_of(heap, struct ion_unmapped_heap, heap);
+
+ gen_pool_free(unmapped_heap->pool, addr, size);
+}
+
+static int ion_unmapped_heap_allocate(struct ion_heap *heap,
+ struct ion_buffer *buffer,
+ unsigned long size,
+ unsigned long flags)
+{
+
Re: [PATCH 00/14] Misc ION cleanups and adding unmapped heap
On 1/14/19 8:39 PM, Laura Abbott wrote: > On 1/11/19 10:05 AM, Andrew F. Davis wrote: >> Hello all, >> >> This is a set of (hopefully) non-controversial cleanups for the ION >> framework and current set of heaps. These were found as I start to >> familiarize myself with the framework to help in whatever way I >> can in getting all this up to the standards needed for de-staging. >> >> I would like to get some ideas of what is left to work on to get ION >> out of staging. Has there been some kind of agreement on what ION should >> eventually end up being? To me it looks like it is being whittled away at >> to it's most core functions. To me that is looking like being a DMA-BUF >> user-space front end, simply advertising available memory backings in a >> system and providing allocations as DMA-BUF handles. If this is the case >> then it looks close to being ready to me at least, but I would love to >> hear any other opinions and concerns. >> > > Yes, at this point the only functionality that people are really > depending on is the ability to allocate a dma_buf easily from userspace. > >> Back to this patchset, the last patch may be a bit different than the >> others, it adds an unmapped heaps type and creation helper. I wanted to >> get this in to show off another heap type and maybe some issues we may >> have with the current ION framework. The unmapped heap is used when the >> backing memory should not (or cannot) be touched. Currently this kind >> of heap is used for firewalled secure memory that can be allocated like >> normal heap memory but only used by secure devices (OP-TEE, crypto HW, >> etc). It is basically just copied from the "carveout" heap type with the >> only difference being it is not mappable to userspace and we do not clear >> the memory (as we should not map it either). So should this really be a >> new heap type? Or maybe advertised as a carveout heap but with an >> additional allocation flag? Perhaps we do away with "types" altogether >> and just have flags, coherent/non-coherent, mapped/unmapped, etc. >> >> Maybe more thinking will be needed afterall.. >> > > So the cleanup looks okay (I need to finish reviewing) but I'm not a > fan of adding another heaptype without solving the problem of adding > some sort of devicetree binding or other method of allocating and > placing Ion heaps. That plus uncached buffers are one of the big > open problems that need to be solved for destaging Ion. See > https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/ > > for some background on that problem. > I'm under the impression that adding heaps like carveouts/chunk will be rather system specific and so do not lend themselves well to a universal DT style exporter. For instance a carveout memory space can be reported by a device at runtime, then the driver managing that device should go and use the carveout heap helpers to export that heap. If this is the case then I'm not sure it is a problem for the ION core framework to solve, but rather the users of it to figure out how best to create the various heaps. All Ion needs to do is allow exporting and advertising them IMHO. Thanks for the background thread link, I've been looking for some info on current status of all this and "ion" is a bit hard to search the lists for. The core reason for posting this cleanup series is to throw my hat into the ring of all this Ion work and start getting familiar with the pending issues. The last two patches are not all that important to get in right now. In that thread you linked above, it seems we may have arrived at a similar problem for different reasons. I think the root issue is the Ion core makes too many assumptions about the heap memory. My proposal would be to allow the heap exporters more control over the DMA-BUF ops, maybe even going as far as letting them provide their own complete struct dma_buf_ops. Let me give an example where I think this is going to be useful. We have the classic constraint solving problem on our SoCs. Our SoCs are full of various coherent and non-coherent devices, some require contiguous memory allocations, others have in-line IOMMUs so can operate on non-contiguous, etc.. DMA-BUF has a solution designed in for this we can use, namely allocation at map time after all the attachments have come in. The checking of each attached device to find the right backing memory is something the DMA-BUF exporter has to do, and so this SoC specific logic would have to be added to each exporting framework (DRM, V4L2, etc), unless we have one unified system exporter everyone uses, Ion. Then each system can define one (maybe typeless) heap, the correct backing type is system specific anyway, so let the system specific backing logic in the unified system exporter heap handle picking that. To allow that heaps need direct control of dma_buf_ops. Direct heap control of dma_buf_ops also fixes the cache/non-cache issue, and my unmapped memory issue, each heap
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> On 1/14/19 11:13 AM, Liam Mark wrote:
> > On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> >
> >> Buffers may not be mapped from the CPU so skip cache maintenance here.
> >> Accesses from the CPU to a cached heap should be bracketed with
> >> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
> >>
> >> Signed-off-by: Andrew F. Davis
> >> ---
> >> drivers/staging/android/ion/ion.c | 7 ---
> >> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/staging/android/ion/ion.c
> >> b/drivers/staging/android/ion/ion.c
> >> index 14e48f6eb734..09cb5a8e2b09 100644
> >> --- a/drivers/staging/android/ion/ion.c
> >> +++ b/drivers/staging/android/ion/ion.c
> >> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct
> >> dma_buf_attachment *attachment,
> >>
> >>table = a->table;
> >>
> >> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> >> - direction))
> >> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
> >> +direction, DMA_ATTR_SKIP_CPU_SYNC))
> >
> > Unfortunately I don't think you can do this for a couple reasons.
> > You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
> > If the calls to {begin,end}_cpu_access were made before the call to
> > dma_buf_attach then there won't have been a device attached so the calls
> > to {begin,end}_cpu_access won't have done any cache maintenance.
> >
>
> That should be okay though, if you have no attachments (or all
> attachments are IO-coherent) then there is no need for cache
> maintenance. Unless you mean a sequence where a non-io-coherent device
> is attached later after data has already been written. Does that
> sequence need supporting?
Yes, but also I think there are cases where CPU access can happen before
in Android, but I will focus on later for now.
> DMA-BUF doesn't have to allocate the backing
> memory until map_dma_buf() time, and that should only happen after all
> the devices have attached so it can know where to put the buffer. So we
> shouldn't expect any CPU access to buffers before all the devices are
> attached and mapped, right?
>
Here is an example where CPU access can happen later in Android.
Camera device records video -> software post processing -> video device
(who does compression of raw data) and writes to a file
In this example assume the buffer is cached and the devices are not
IO-coherent (quite common).
ION buffer is allocated.
//Camera device records video
dma_buf_attach
dma_map_attachment (buffer needs to be cleaned)
[camera device writes to buffer]
dma_buf_unmap_attachment (buffer needs to be invalidated)
dma_buf_detach (device cannot stay attached because it is being sent down
the pipeline and Camera doesn't know the end of the use case)
//buffer is send down the pipeline
// Usersapce software post processing occurs
mmap buffer
DMA_BUF_IOCTL_SYNC IOCT with flags DMA_BUF_SYNC_START // No CMO since no
devices attached to buffer
[CPU reads/writes to the buffer]
DMA_BUF_IOCTL_SYNC IOCTL with flags DMA_BUF_SYNC_END // No CMO since no
devices attached to buffer
munmap buffer
//buffer is send down the pipeline
// Buffer is send to video device (who does compression of raw data) and
writes to a file
dma_buf_attach
dma_map_attachment (buffer needs to be cleaned)
[video device writes to buffer]
dma_buf_unmap_attachment
dma_buf_detach (device cannot stay attached because it is being sent down
the pipeline and Video doesn't know the end of the use case)
> > Also ION no longer provides DMA ready memory, so if you are not doing CPU
> > access then there is no requirement (that I am aware of) for you to call
> > {begin,end}_cpu_access before passing the buffer to the device and if this
> > buffer is cached and your device is not IO-coherent then the cache
> > maintenance
> > in ion_map_dma_buf and ion_unmap_dma_buf is required.
> >
>
> If I am not doing any CPU access then why do I need CPU cache
> maintenance on the buffer?
>
Because ION no longer provides DMA ready memory.
Take the above example.
ION allocates memory from buddy allocator and requests zeroing.
Zeros are written to the cache.
You pass the buffer to the camera device which is not IO-coherent.
The camera devices writes directly to the buffer in DDR.
Since you didn't clean the buffer a dirty cache line (one of the zeros) is
evicted from the cache, this zero overwrites data the camera device has
written which corrupts your data.
Liam
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: Mediatek: Use individual config flags in Makefile
On Tue, Jan 15, 2019 at 10:29:18AM -0700, George Hilliard wrote: > These drivers can be useful on other MT76xx SoCs, which have compatible > peripherals. The drivers were selectable in Kconfig, but they were > quietly excluded from the build because the SOC_MT7621 chip was not > selected. So, make the Makefiles use the same flags as Kconfig for > these drivers. > > mt7621-dma and mt7621-dts are left alone because they truly do require > that SoC. > > I have personally confirmed that the mt7621-spi driver works on the > MT7688, which was what prompted this change. > > Cc: linux-ker...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: NeilBrown > Cc: sergio.paracuel...@gmail.com > Signed-off-by: George Hilliard > --- > Changes in v2..v4: > - Also use individual flags for mt7621-pci and the new mt7621-pci-phy > - Slightly revise commit message You also rebased this patch, right? Anyway, applying this patch, I get the following build error: CC [M] drivers/staging/mt7621-mmc/sd.o CC [M] drivers/staging/mt7621-mmc/dbg.o drivers/staging/mt7621-mmc/sd.c:48:10: fatal error: asm/mach-ralink/ralink_regs.h: No such file or directory #include ^~~ compilation terminated. make[3]: *** [scripts/Makefile.build:277: drivers/staging/mt7621-mmc/sd.o] Error 1 make[3]: *** Waiting for unfinished jobs drivers/staging/mt7621-mmc/dbg.c: In function ‘msdc_debug_proc_write’: drivers/staging/mt7621-mmc/dbg.c:237:12: warning: unused variable ‘size’ [-Wunused-variable] int mode, size; ^~~~ drivers/staging/mt7621-mmc/dbg.c:237:6: warning: unused variable ‘mode’ [-Wunused-variable] int mode, size; ^~~~ make[2]: *** [scripts/Makefile.build:492: drivers/staging/mt7621-mmc] Error 2 make[2]: *** Waiting for unfinished jobs make[1]: *** [scripts/Makefile.build:492: drivers/staging] Error 2 make[1]: *** Waiting for unfinished jobs So I can't take this patch as is, sorry. Please fix. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: Mediatek: Use individual config flags in Makefile
On Tue, Jan 15, 2019 at 10:20 AM Greg Kroah-Hartman wrote: > What changed from v2 and v1? That always goes below the --- line. > > Please fix that up and resend v4. > Sent. Didn't know to do that - first time contributor here. Sorry about the churn and thanks for your patience! Cheers, George ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v4] staging: Mediatek: Use individual config flags in Makefile
These drivers can be useful on other MT76xx SoCs, which have compatible peripherals. The drivers were selectable in Kconfig, but they were quietly excluded from the build because the SOC_MT7621 chip was not selected. So, make the Makefiles use the same flags as Kconfig for these drivers. mt7621-dma and mt7621-dts are left alone because they truly do require that SoC. I have personally confirmed that the mt7621-spi driver works on the MT7688, which was what prompted this change. Cc: linux-ker...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: NeilBrown Cc: sergio.paracuel...@gmail.com Signed-off-by: George Hilliard --- Changes in v2..v4: - Also use individual flags for mt7621-pci and the new mt7621-pci-phy - Slightly revise commit message drivers/staging/Makefile| 14 +++--- drivers/staging/mt7621-pci-phy/Makefile | 2 +- drivers/staging/mt7621-pci/Makefile | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 4d563ed0bc79..cc5530cc996b 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -41,14 +41,14 @@ obj-$(CONFIG_GREYBUS) += greybus/ obj-$(CONFIG_BCM2835_VCHIQ)+= vc04_services/ obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/ obj-$(CONFIG_PI433)+= pi433/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci-phy/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ -obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ +obj-$(CONFIG_PCI_MT7621) += mt7621-pci/ +obj-$(CONFIG_PCI_MT7621_PHY) += mt7621-pci-phy/ +obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/ +obj-$(CONFIG_SPI_MT7621) += mt7621-spi/ obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ -obj-$(CONFIG_SOC_MT7621) += ralink-gdma/ -obj-$(CONFIG_SOC_MT7621) += mt7621-mmc/ -obj-$(CONFIG_SOC_MT7621) += mt7621-eth/ +obj-$(CONFIG_DMA_RALINK) += ralink-gdma/ +obj-$(CONFIG_MTK_MMC) += mt7621-mmc/ +obj-$(CONFIG_NET_MEDIATEK_SOC_STAGING) += mt7621-eth/ obj-$(CONFIG_SOC_MT7621) += mt7621-dts/ obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/ obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/ diff --git a/drivers/staging/mt7621-pci-phy/Makefile b/drivers/staging/mt7621-pci-phy/Makefile index 2b82ccfc28c6..a970056f05c1 100644 --- a/drivers/staging/mt7621-pci-phy/Makefile +++ b/drivers/staging/mt7621-pci-phy/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621-phy.o +obj-$(CONFIG_PCI_MT7621_PHY) += pci-mt7621-phy.o diff --git a/drivers/staging/mt7621-pci/Makefile b/drivers/staging/mt7621-pci/Makefile index 607b84bedcc3..d4655a726b61 100644 --- a/drivers/staging/mt7621-pci/Makefile +++ b/drivers/staging/mt7621-pci/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621.o +obj-$(CONFIG_PCI_MT7621) += pci-mt7621.o -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: Mediatek: Use individual config flags in Makefile
On Tue, Jan 15, 2019 at 10:02:21AM -0700, George Hilliard wrote: > These drivers can be useful on other MT76xx SoCs, which have compatible > peripherals. The drivers were selectable in Kconfig, but they were > quietly excluded from the build because the SOC_MT7621 chip was not > selected. So, make the Makefiles use the same flags as Kconfig for > these drivers. > > mt7621-dma and mt7621-dts are left alone because they truly do require > that SoC. > > I have personally confirmed that the mt7621-spi driver works on the > MT7688, which was what prompted this change. > > Cc: linux-ker...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: NeilBrown > Cc: sergio.paracuel...@gmail.com > Signed-off-by: George Hilliard > --- > drivers/staging/Makefile| 14 +++--- > drivers/staging/mt7621-pci-phy/Makefile | 2 +- > drivers/staging/mt7621-pci/Makefile | 2 +- > 3 files changed, 9 insertions(+), 9 deletions(-) What changed from v2 and v1? That always goes below the --- line. Please fix that up and resend v4. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: Mediatek: Use individual config flags in Makefile
These drivers can be useful on other MT76xx SoCs, which have compatible peripherals. The drivers were selectable in Kconfig, but they were quietly excluded from the build because the SOC_MT7621 chip was not selected. So, make the Makefiles use the same flags as Kconfig for these drivers. mt7621-dma and mt7621-dts are left alone because they truly do require that SoC. I have personally confirmed that the mt7621-spi driver works on the MT7688, which was what prompted this change. Cc: linux-ker...@vger.kernel.org Cc: de...@driverdev.osuosl.org Cc: NeilBrown Cc: sergio.paracuel...@gmail.com Signed-off-by: George Hilliard --- drivers/staging/Makefile| 14 +++--- drivers/staging/mt7621-pci-phy/Makefile | 2 +- drivers/staging/mt7621-pci/Makefile | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index 4d563ed0bc79..cc5530cc996b 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -41,14 +41,14 @@ obj-$(CONFIG_GREYBUS) += greybus/ obj-$(CONFIG_BCM2835_VCHIQ)+= vc04_services/ obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/ obj-$(CONFIG_PI433)+= pi433/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pci-phy/ -obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ -obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ +obj-$(CONFIG_PCI_MT7621) += mt7621-pci/ +obj-$(CONFIG_PCI_MT7621_PHY) += mt7621-pci-phy/ +obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/ +obj-$(CONFIG_SPI_MT7621) += mt7621-spi/ obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ -obj-$(CONFIG_SOC_MT7621) += ralink-gdma/ -obj-$(CONFIG_SOC_MT7621) += mt7621-mmc/ -obj-$(CONFIG_SOC_MT7621) += mt7621-eth/ +obj-$(CONFIG_DMA_RALINK) += ralink-gdma/ +obj-$(CONFIG_MTK_MMC) += mt7621-mmc/ +obj-$(CONFIG_NET_MEDIATEK_SOC_STAGING) += mt7621-eth/ obj-$(CONFIG_SOC_MT7621) += mt7621-dts/ obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/ obj-$(CONFIG_XIL_AXIS_FIFO)+= axis-fifo/ diff --git a/drivers/staging/mt7621-pci-phy/Makefile b/drivers/staging/mt7621-pci-phy/Makefile index 2b82ccfc28c6..a970056f05c1 100644 --- a/drivers/staging/mt7621-pci-phy/Makefile +++ b/drivers/staging/mt7621-pci-phy/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621-phy.o +obj-$(CONFIG_PCI_MT7621_PHY) += pci-mt7621-phy.o diff --git a/drivers/staging/mt7621-pci/Makefile b/drivers/staging/mt7621-pci/Makefile index 607b84bedcc3..d4655a726b61 100644 --- a/drivers/staging/mt7621-pci/Makefile +++ b/drivers/staging/mt7621-pci/Makefile @@ -1 +1 @@ -obj-$(CONFIG_SOC_MT7621) += pci-mt7621.o +obj-$(CONFIG_PCI_MT7621) += pci-mt7621.o -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: imx-csi: Input connections to CSI should be optional
On Wed, Jan 9, 2019 at 10:34 AM Steve Longerbeam wrote:
>
> Some imx platforms do not have fwnode connections to all CSI input
> ports, and should not be treated as an error. This includes the
> imx6q SabreAuto, which has no connections to ipu1_csi1 and ipu2_csi0.
> Return -ENOTCONN in imx_csi_parse_endpoint() so that v4l2-fwnode
> endpoint parsing will not treat an unconnected CSI input port as
> an error.
>
> Fixes: c893500a16baf ("media: imx: csi: Register a subdev notifier")
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/staging/media/imx/imx-media-csi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/imx/imx-media-csi.c
> b/drivers/staging/media/imx/imx-media-csi.c
> index 4223f8d418ae..30b1717982ae 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -1787,7 +1787,7 @@ static int imx_csi_parse_endpoint(struct device *dev,
> struct v4l2_fwnode_endpoint *vep,
> struct v4l2_async_subdev *asd)
> {
> - return fwnode_device_is_available(asd->match.fwnode) ? 0 : -EINVAL;
> + return fwnode_device_is_available(asd->match.fwnode) ? 0 : -ENOTCONN;
> }
>
> static int imx_csi_async_register(struct csi_priv *priv)
> --
> 2.17.1
>
Steve,
Thanks, this fixes adv7180 the capture regression on the Gateworks
Ventana boards as well. This should go to stable to fix 4.20 so please
add a 'Cc: sta...@vger.kernel.org' if you re-submit (else we can send
it to sta...@vger.kernel.org later).
Acked-by: Tim Harvey
Tim
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: rtl8188eu: cleanup declarations in os_intfs.c
Replace tabs with spaces and/or remove extra spaces in declarations.
Signed-off-by: Michael Straube
---
v1 -> v2
added missing Signed-off-by
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index 6681383579ee..6ed4a06a0796 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -137,7 +137,7 @@ static int netdev_close(struct net_device *pnetdev);
static void loadparam(struct adapter *padapter, struct net_device *pnetdev)
{
- struct registry_priv *registry_par = >registrypriv;
+ struct registry_priv *registry_par = >registrypriv;
GlobalDebugLevel = rtw_debug;
@@ -248,7 +248,7 @@ static u16 rtw_select_queue(struct net_device *dev, struct
sk_buff *skb,
struct net_device *sb_dev,
select_queue_fallback_t fallback)
{
- struct adapter *padapter = rtw_netdev_priv(dev);
+ struct adapter *padapter = rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = >mlmepriv;
skb->priority = rtw_classify8021d(skb);
@@ -263,7 +263,7 @@ u16 rtw_recv_select_queue(struct sk_buff *skb)
{
struct iphdr *piphdr;
unsigned int dscp;
- __be16 eth_type;
+ __be16 eth_type;
u32 priority;
u8 *pdata = skb->data;
@@ -286,7 +286,7 @@ static const struct net_device_ops rtw_netdev_ops = {
.ndo_open = netdev_open,
.ndo_stop = netdev_close,
.ndo_start_xmit = rtw_xmit_entry,
- .ndo_select_queue = rtw_select_queue,
+ .ndo_select_queue = rtw_select_queue,
.ndo_set_mac_address = rtw_net_set_mac_address,
.ndo_get_stats = rtw_net_get_stats,
.ndo_do_ioctl = rtw_ioctl,
@@ -361,7 +361,7 @@ void rtw_stop_drv_threads(struct adapter *padapter)
static u8 rtw_init_default_value(struct adapter *padapter)
{
struct registry_priv *pregistrypriv = >registrypriv;
- struct xmit_priv*pxmitpriv = >xmitpriv;
+ struct xmit_priv *pxmitpriv = >xmitpriv;
struct mlme_priv *pmlmepriv = >mlmepriv;
struct security_priv *psecuritypriv = >securitypriv;
@@ -431,7 +431,7 @@ u8 rtw_reset_drv_sw(struct adapter *padapter)
u8 rtw_init_drv_sw(struct adapter *padapter)
{
- u8 ret8 = _SUCCESS;
+ u8 ret8 = _SUCCESS;
RT_TRACE(_module_os_intfs_c_, _drv_info_, ("+rtw_init_drv_sw\n"));
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: rtl8188eu: add spaces around operators in os_intfs.c
Add spaces around '+', '<<' and '*' to follow kernel coding style.
Reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index 6ed4a06a0796..dfba6b725790 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -267,11 +267,11 @@ u16 rtw_recv_select_queue(struct sk_buff *skb)
u32 priority;
u8 *pdata = skb->data;
- memcpy(_type, pdata+(ETH_ALEN<<1), 2);
+ memcpy(_type, pdata + (ETH_ALEN << 1), 2);
switch (eth_type) {
case htons(ETH_P_IP):
- piphdr = (struct iphdr *)(pdata+ETH_HLEN);
+ piphdr = (struct iphdr *)(pdata + ETH_HLEN);
dscp = piphdr->tos & 0xfc;
priority = dscp >> 5;
break;
@@ -323,7 +323,7 @@ struct net_device *rtw_init_netdev(struct adapter
*old_padapter)
padapter->pnetdev = pnetdev;
DBG_88E("register rtw_netdev_ops to netdev_ops\n");
pnetdev->netdev_ops = _netdev_ops;
- pnetdev->watchdog_timeo = HZ*3; /* 3 second timeout */
+ pnetdev->watchdog_timeo = HZ * 3; /* 3 second timeout */
pnetdev->wireless_handlers = (struct iw_handler_def *)_handlers_def;
loadparam(padapter, pnetdev);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] rtl8188eu: Refactoring struct ndis_802_11_ssid from CamelCase to correct code style.
rtl8188eu uses CamelCase for many struct members.
Refactors the ndis_802_11_ssid members Ssid and SsidLength to keep correct code
style.
Issue found by checkpatch.
Signed-off-by: Florian Büstgens
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 8 ++--
drivers/staging/rtl8188eu/core/rtw_cmd.c | 12 ++---
.../staging/rtl8188eu/core/rtw_ieee80211.c| 6 +--
.../staging/rtl8188eu/core/rtw_ioctl_set.c| 12 ++---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 44 +--
drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 38
.../staging/rtl8188eu/core/rtw_wlan_util.c| 18
drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 2 +-
.../staging/rtl8188eu/include/wlan_bssdef.h | 6 +--
.../staging/rtl8188eu/os_dep/ioctl_linux.c| 34 +++---
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 4 +-
.../staging/rtl8188eu/os_dep/rtw_android.c| 2 +-
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 6 +--
13 files changed, 96 insertions(+), 96 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 1f232ba6651c..94c9d9f8ee5c 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -82,7 +82,7 @@ static void update_BCNTIM(struct adapter *padapter)
/* calculate head_len */
offset = _FIXED_IE_LENGTH_;
- offset += pnetwork_mlmeext->Ssid.SsidLength + 2;
+ offset += pnetwork_mlmeext->ssid.ssid_length + 2;
/* get supported rates len */
p = rtw_get_ie(pie + _BEACON_IE_OFFSET_, _SUPPORTEDRATES_IE_,
@@ -785,9 +785,9 @@ int rtw_check_beacon_data(struct adapter *padapter, u8
*pbuf, int len)
/* SSID */
p = rtw_get_ie(ie + _BEACON_IE_OFFSET_, _SSID_IE_, _len,
(pbss_network->ie_length - _BEACON_IE_OFFSET_));
if (p && ie_len > 0) {
- memset(_network->Ssid, 0, sizeof(struct ndis_802_11_ssid));
- memcpy(pbss_network->Ssid.Ssid, (p + 2), ie_len);
- pbss_network->Ssid.SsidLength = ie_len;
+ memset(_network->ssid, 0, sizeof(struct ndis_802_11_ssid));
+ memcpy(pbss_network->ssid.ssid, (p + 2), ie_len);
+ pbss_network->ssid.ssid_length = ie_len;
}
/* channel */
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 407f65cf7150..83a2e58aef53 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -263,7 +263,7 @@ u8 rtw_sitesurvey_cmd(struct adapter *padapter, struct
ndis_802_11_ssid *ssid,
int i;
for (i = 0; i < ssid_num && i < RTW_SSID_SCAN_AMOUNT; i++) {
- if (ssid[i].SsidLength) {
+ if (ssid[i].ssid_length) {
memcpy(>ssid[i], [i],
sizeof(struct ndis_802_11_ssid));
psurveyPara->ssid_num++;
}
@@ -316,10 +316,10 @@ u8 rtw_createbss_cmd(struct adapter *padapter)
led_control_8188eu(padapter, LED_CTL_START_TO_LINK);
- if (pmlmepriv->assoc_ssid.SsidLength == 0)
- RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, (" createbss for
Any SSid:%s\n", pmlmepriv->assoc_ssid.Ssid));
+ if (pmlmepriv->assoc_ssid.ssid_length == 0)
+ RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, (" createbss for
Any SSid:%s\n", pmlmepriv->assoc_ssid.ssid));
else
- RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, (" createbss for
SSid:%s\n", pmlmepriv->assoc_ssid.Ssid));
+ RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, (" createbss for
SSid:%s\n", pmlmepriv->assoc_ssid.ssid));
pcmd = kzalloc(sizeof(*pcmd), GFP_ATOMIC);
if (!pcmd) {
@@ -358,10 +358,10 @@ u8 rtw_joinbss_cmd(struct adapter *padapter, struct
wlan_network *pnetwork)
led_control_8188eu(padapter, LED_CTL_START_TO_LINK);
- if (pmlmepriv->assoc_ssid.SsidLength == 0)
+ if (pmlmepriv->assoc_ssid.ssid_length == 0)
RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, ("+Join cmd: Any
SSid\n"));
else
- RT_TRACE(_module_rtl871x_cmd_c_, _drv_notice_, ("+Join cmd:
SSid =[%s]\n", pmlmepriv->assoc_ssid.Ssid));
+ RT_TRACE(_module_rtl871x_cmd_c_, _drv_notice_, ("+Join cmd:
SSid =[%s]\n", pmlmepriv->assoc_ssid.ssid));
pcmd = kzalloc(sizeof(*pcmd), GFP_ATOMIC);
if (!pcmd) {
diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index 5c4ff81987bd..6ef67c25fdb7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -234,7 +234,7 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
ie += 2;
/* SSID */
- ie = rtw_set_ie(ie, _SSID_IE_,
Re: [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper
On 1/14/19 8:32 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> The "unmapped" heap is very similar to the carveout heap except
>> the backing memory is presumed to be unmappable by the host, in
>> my specific case due to firewalls. This memory can still be
>> allocated from and used by devices that do have access to the
>> backing memory.
>>
>> Based originally on the secure/unmapped heap from Linaro for
>> the OP-TEE SDP implementation, this was re-written to match
>> the carveout heap helper code.
>>
>> Suggested-by: Etienne Carriere
>> Signed-off-by: Andrew F. Davis
>> ---
>> drivers/staging/android/ion/Kconfig | 10 ++
>> drivers/staging/android/ion/Makefile | 1 +
>> drivers/staging/android/ion/ion.h | 16 +++
>> .../staging/android/ion/ion_unmapped_heap.c | 123 ++
>> drivers/staging/android/uapi/ion.h | 3 +
>> 5 files changed, 153 insertions(+)
>> create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c
>>
>> diff --git a/drivers/staging/android/ion/Kconfig
>> b/drivers/staging/android/ion/Kconfig
>> index 0fdda6f62953..a117b8b91b14 100644
>> --- a/drivers/staging/android/ion/Kconfig
>> +++ b/drivers/staging/android/ion/Kconfig
>> @@ -42,3 +42,13 @@ config ION_CMA_HEAP
>> Choose this option to enable CMA heaps with Ion. This heap is
>> backed
>> by the Contiguous Memory Allocator (CMA). If your system has
>> these
>> regions, you should say Y here.
>> +
>> +config ION_UNMAPPED_HEAP
>> + bool "ION unmapped heap support"
>> + depends on ION
>> + help
>> + Choose this option to enable UNMAPPED heaps with Ion. This heap is
>> + backed in specific memory pools, carveout from the Linux memory.
>> + Unlike carveout heaps these are assumed to be not mappable by
>> + kernel or user-space.
>> + Unless you know your system has these regions, you should say N
>> here.
>> diff --git a/drivers/staging/android/ion/Makefile
>> b/drivers/staging/android/ion/Makefile
>> index 17f3a7569e3d..c71a1f3de581 100644
>> --- a/drivers/staging/android/ion/Makefile
>> +++ b/drivers/staging/android/ion/Makefile
>> @@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o
>> ion_page_pool.o
>> obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
>> obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
>> obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
>> +obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
>> diff --git a/drivers/staging/android/ion/ion.h
>> b/drivers/staging/android/ion/ion.h
>> index 97b2876b165a..ce74332018ba 100644
>> --- a/drivers/staging/android/ion/ion.h
>> +++ b/drivers/staging/android/ion/ion.h
>> @@ -341,4 +341,20 @@ static inline struct ion_heap
>> *ion_chunk_heap_create(phys_addr_t base, size_t si
>> }
>> #endif
>> +#ifdef CONFIG_ION_UNMAPPED_HEAP
>> +/**
>> + * ion_unmapped_heap_create
>> + * @base: base address of carveout memory
>> + * @size: size of carveout memory region
>> + *
>> + * Creates an unmapped ion_heap using the passed in data
>> + */
>> +struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t
>> size);
>> +#else
>> +struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
>> +{
>> + return ERR_PTR(-ENODEV);
>> +}
>> +#endif
>> +
>> #endif /* _ION_H */
>> diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c
>> b/drivers/staging/android/ion/ion_unmapped_heap.c
>> new file mode 100644
>> index ..7602b659c2ec
>> --- /dev/null
>> +++ b/drivers/staging/android/ion/ion_unmapped_heap.c
>> @@ -0,0 +1,123 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * ION Memory Allocator unmapped heap helper
>> + *
>> + * Copyright (C) 2015-2016 Texas Instruments Incorporated -
>> http://www.ti.com/
>> + * Andrew F. Davis
>> + *
>> + * ION "unmapped" heaps are physical memory heaps not by default
>> mapped into
>> + * a virtual address space. The buffer owner can explicitly request
>> kernel
>> + * space mappings but the underlying memory may still not be
>> accessible for
>> + * various reasons, such as firewalls.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "ion.h"
>> +
>> +#define ION_UNMAPPED_ALLOCATE_FAIL -1
>> +
>> +struct ion_unmapped_heap {
>> + struct ion_heap heap;
>> + struct gen_pool *pool;
>> +};
>> +
>> +static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
>> + unsigned long size)
>> +{
>> + struct ion_unmapped_heap *unmapped_heap =
>> + container_of(heap, struct ion_unmapped_heap, heap);
>> + unsigned long offset;
>> +
>> + offset = gen_pool_alloc(unmapped_heap->pool, size);
>> + if (!offset)
>> + return ION_UNMAPPED_ALLOCATE_FAIL;
>> +
>> + return offset;
>> +}
>> +
>> +static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
>> + unsigned long size)
>> +{
>> + struct ion_unmapped_heap
[PATCH] staging: comedi: Removed not necessary braces for single block
This patch is used to remove not necessary braces for single if block.
Signed-off-by: Jitendra Khasdev
---
drivers/staging/comedi/comedi_fops.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index 5d2fcbfe02af..38980fad8be4 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -1605,9 +1605,9 @@ static int do_insn_ioctl(struct comedi_device *dev,
unsigned int n_data = MIN_SAMPLES;
int ret = 0;
- if (copy_from_user(, arg, sizeof(insn))) {
+ if (copy_from_user(, arg, sizeof(insn)))
return -EFAULT;
- }
+
n_data = max(n_data, insn.n);
--
2.13.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] staging: Mediatek: Use individual config flags in Makefile
On Thu, Jan 10, 2019 at 05:43:37PM -0700, thirtythreefo...@gmail.com wrote: > From: George Hilliard > > These drivers are useful on other MT76xx SoCs, which have compatible > peripherals. The drivers are selectable in Kconfig, but they were > quietly excluded from the build because the SOC_MT7621 chip was not > selected. So, make the main staging Makefile use the same flags as > everything else for these drivers. > > mt7621-dma and mt7621-dts are left alone because they truly do require > that SoC. > > I have personally confirmed that the mt7621-spi driver works on the > MT7688, which was what prompted this change. > > Cc: linux-ker...@vger.kernel.org > Cc: de...@driverdev.osuosl.org > Cc: NeilBrown > Signed-off-by: George Hilliard > --- > drivers/staging/Makefile | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index e095f427177c..4b78ea2c7848 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -42,12 +42,12 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/ > obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/ > obj-$(CONFIG_PI433) += pi433/ > obj-$(CONFIG_SOC_MT7621) += mt7621-pci/ > -obj-$(CONFIG_SOC_MT7621) += mt7621-pinctrl/ > -obj-$(CONFIG_SOC_MT7621) += mt7621-spi/ > +obj-$(CONFIG_PINCTRL_RT2880) += mt7621-pinctrl/ > +obj-$(CONFIG_SPI_MT7621) += mt7621-spi/ > obj-$(CONFIG_SOC_MT7621) += mt7621-dma/ > -obj-$(CONFIG_SOC_MT7621) += ralink-gdma/ > -obj-$(CONFIG_SOC_MT7621) += mt7621-mmc/ > -obj-$(CONFIG_SOC_MT7621) += mt7621-eth/ > +obj-$(CONFIG_DMA_RALINK) += ralink-gdma/ > +obj-$(CONFIG_MTK_MMC)+= mt7621-mmc/ > +obj-$(CONFIG_NET_MEDIATEK_SOC_STAGING) += mt7621-eth/ > obj-$(CONFIG_SOC_MT7621) += mt7621-dts/ > obj-$(CONFIG_STAGING_GASKET_FRAMEWORK) += gasket/ > obj-$(CONFIG_XIL_AXIS_FIFO) += axis-fifo/ This patch doesn't apply to my tree at all, can you rebase and resend? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/3] staging: rtl8188eu: add spaces around operators in os_intfs.c
On Tue, Jan 15, 2019 at 09:24:02AM +0100, Michael Straube wrote: > Add spaces around '+', '<<' and '*' to follow kernel coding style. > Reported by checkpatch. > --- > drivers/staging/rtl8188eu/os_dep/os_intfs.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) No signed-off-by :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] staging: rtl8188eu: cleanup declarations in os_intfs.c
On Tue, Jan 15, 2019 at 09:24:01AM +0100, Michael Straube wrote: > Replace tabs with spaces and/or remove extra spaces in declarations. > --- > drivers/staging/rtl8188eu/os_dep/os_intfs.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) No signed off by :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: Removed not necessary braces for single block
On Tue, Jan 15, 2019 at 08:21:08PM +0530, root wrote: > This patch is used to remove not necessary braces for single if block. > > Signed-off-by: Jitendra Kumar Khasdev > --- > drivers/staging/comedi/comedi_fops.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) "interesting" email name you used here :) Please fix up, it has to match the signed-off-by line. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 1/3] staging: greybus: gpio: switch GPIO portions to use GPIOLIB_IRQCHIP
On Tue, Jan 15, 2019 at 04:13:17PM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 14, 2019 at 08:26:16PM +0530, Nishad Kamdar wrote: > > Convert the GPIO driver to use the GPIO irqchip library > > GPIOLIB_IRQCHIP instead of reimplementing the same. > > > > Reviewed-by: Johan Hovold > > Signed-off-by: Nishad Kamdar > > Did you test build this patch? > > It fails horribly for me: > > drivers/staging/greybus/gpio.c: In function ‘gb_gpio_request_handler’: > drivers/staging/greybus/gpio.c:389:34: error: ‘struct gpio_chip’ has no > member named ‘irq’ > irq = irq_find_mapping(ggc->chip.irq.domain, event->which); > ^ > CC [M] drivers/staging/rtl8712/usb_intf.o > drivers/staging/greybus/gpio.c: In function ‘gb_gpio_probe’: > drivers/staging/greybus/gpio.c:577:8: error: implicit declaration of function > ‘gpiochip_irqchip_add’; did you mean ‘gpiochip_add’? > [-Werror=implicit-function-declaration] > ret = gpiochip_irqchip_add(gpio, irqc, 0, handle_level_irq, > ^~~~ > gpiochip_add > > > Please be more careful... Hm, this seems to be a problem on my side. You selected the new config symbol, but my quick build system didn't catch that and it didnt regenerate the kernel configuration, which causes this problem. So this is fine, sorry for the noise, my fault. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 1/3] staging: greybus: gpio: switch GPIO portions to use GPIOLIB_IRQCHIP
On Mon, Jan 14, 2019 at 08:26:16PM +0530, Nishad Kamdar wrote: > Convert the GPIO driver to use the GPIO irqchip library > GPIOLIB_IRQCHIP instead of reimplementing the same. > > Reviewed-by: Johan Hovold > Signed-off-by: Nishad Kamdar Did you test build this patch? It fails horribly for me: drivers/staging/greybus/gpio.c: In function ‘gb_gpio_request_handler’: drivers/staging/greybus/gpio.c:389:34: error: ‘struct gpio_chip’ has no member named ‘irq’ irq = irq_find_mapping(ggc->chip.irq.domain, event->which); ^ CC [M] drivers/staging/rtl8712/usb_intf.o drivers/staging/greybus/gpio.c: In function ‘gb_gpio_probe’: drivers/staging/greybus/gpio.c:577:8: error: implicit declaration of function ‘gpiochip_irqchip_add’; did you mean ‘gpiochip_add’? [-Werror=implicit-function-declaration] ret = gpiochip_irqchip_add(gpio, irqc, 0, handle_level_irq, ^~~~ gpiochip_add Please be more careful... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android/vsoc: Remove duplicate header
On Tue, Jan 15, 2019 at 03:59:42PM +0100, Greg KH wrote: > On Wed, Jan 09, 2019 at 08:55:59PM +0530, Brajeswar Ghosh wrote: > > Remove linux/mutex.h which is included more than once > > > > Signed-off-by: Brajeswar Ghosh > > Acked-by: Souptick Joarder > > --- > > drivers/staging/android/vsoc.c | 1 - > > 1 file changed, 1 deletion(-) > > This does not apply as it is already in the tree, are you sure you are > working against the latest release? Ugh, my fault, nevermind... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: fbtft: Switch to the gpio descriptor interface
On Tue, Jan 15, 2019 at 10:17:09AM +0530, Nishad Kamdar wrote: > This switches the fbtft driver to use GPIO descriptors > rather than numerical gpios: > > Utilize the GPIO library's intrinsic handling of OF GPIOs > and polarity. If the line is flagged active low, gpiolib > will deal with this. > > Remove gpios from platform device structure. Neither assign > statically numbers to gpios in platform device nor allow > gpios to be parsed as module parameters. > > Signed-off-by: Nishad Kamdar > Changes in v2: > - Merge all patches in a single patch. This is because the >first patch changes par->gpio from an int to a pointer >so all the checks have to be updated in the same patch. >Otherwie it breaks 'git bisect'. The "v2" information goes below the --- line please. Also, I got 2 copies of this, both different, so I have no idea which to apply. Please fix up and resend a v3. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android/vsoc: Remove duplicate header
On Wed, Jan 09, 2019 at 08:55:59PM +0530, Brajeswar Ghosh wrote: > Remove linux/mutex.h which is included more than once > > Signed-off-by: Brajeswar Ghosh > Acked-by: Souptick Joarder > --- > drivers/staging/android/vsoc.c | 1 - > 1 file changed, 1 deletion(-) This does not apply as it is already in the tree, are you sure you are working against the latest release? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/android/vsoc: Remove duplicate header
On Wed, Jan 09, 2019 at 08:55:59PM +0530, Brajeswar Ghosh wrote: > Remove linux/mutex.h.h which is included more than once I think you have one too many ".h" in that line :) I'll go fix it up... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: Removed not necessary braces for single block
This patch is used to remove not necessary braces for single if block.
Signed-off-by: Jitendra Kumar Khasdev
---
drivers/staging/comedi/comedi_fops.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/comedi_fops.c
b/drivers/staging/comedi/comedi_fops.c
index 5d2fcbfe02af..0caae4a5c471 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -1605,9 +1605,8 @@ static int do_insn_ioctl(struct comedi_device *dev,
unsigned int n_data = MIN_SAMPLES;
int ret = 0;
- if (copy_from_user(, arg, sizeof(insn))) {
+ if (copy_from_user(, arg, sizeof(insn)))
return -EFAULT;
- }
n_data = max(n_data, insn.n);
--
2.13.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC 2/4] media: v4l2-mem2mem: Add an optional job_done operation
On Mon, 2019-01-14 at 14:38 +0100, Paul Kocialkowski wrote: > Introduce a new optional job_done operation, which allows calling back > to the driver when a job is done. Since the job might be completed > from interrupt context where some operations are not available, having > a callback from non-atomic context allows performing these operations > upon completion of a job. This is particularly useful for releasing > access to a reference buffer, which cannot be done in atomic context. > I'm not exactly sure it makes a lot of sense to review this patch, since the approach could change. However, let me point out a few fundamental issues here. > Use the already existing v4l2_m2m_device_run_work work queue for that > and clear the M2M device current context after calling job_done in the > worker thread, so that the private data can be passed to the operation. > > Delaying the current context clearing should not be a problem since the > next call to v4l2_m2m_try_run happens right after that. > Careful here. It's misleading to think an event will happen "right after". I'd say it's either synchronously, or asynchronously. It's quite the opposite I'd say, the clearing will happen "who-knows-when the scheduler picks the thread to run" :-) Before this patch the curr_ctx was cleared in v4l2_m2m_job_finish, atomically with the ctx job flags clearing and before waking up threads waiting in v4l2_m2m_cancel_job. You are now changing this, by clearing curr_ctx in a worker. It's perfectly possible that v4l2_m2m_try_schedule will run before the worker, trying to run with the old context, which apparently would be safely refused. > Signed-off-by: Paul Kocialkowski > --- > drivers/media/v4l2-core/v4l2-mem2mem.c | 8 ++-- > include/media/v4l2-mem2mem.h | 4 > 2 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c > b/drivers/media/v4l2-core/v4l2-mem2mem.c > index 631f4e2aa942..d5bccb0192f9 100644 > --- a/drivers/media/v4l2-core/v4l2-mem2mem.c > +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c > @@ -376,6 +376,11 @@ static void v4l2_m2m_device_run_work(struct work_struct > *work) > struct v4l2_m2m_dev *m2m_dev = > container_of(work, struct v4l2_m2m_dev, job_work); > > + if (m2m_dev->m2m_ops->job_done && m2m_dev->curr_ctx) > + m2m_dev->m2m_ops->job_done(m2m_dev->curr_ctx->priv); > + > + m2m_dev->curr_ctx = NULL; > + I don't think you can access this without taking the job spinlock. > v4l2_m2m_try_run(m2m_dev); > } > Aside from this, it seems we might need this hook sooner or later. Thanks, Eze ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: rtl8188eu: add spaces around operators in os_intfs.c
Add spaces around '+', '<<' and '*' to follow kernel coding style.
Reported by checkpatch.
---
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index 6ed4a06a0796..dfba6b725790 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -267,11 +267,11 @@ u16 rtw_recv_select_queue(struct sk_buff *skb)
u32 priority;
u8 *pdata = skb->data;
- memcpy(_type, pdata+(ETH_ALEN<<1), 2);
+ memcpy(_type, pdata + (ETH_ALEN << 1), 2);
switch (eth_type) {
case htons(ETH_P_IP):
- piphdr = (struct iphdr *)(pdata+ETH_HLEN);
+ piphdr = (struct iphdr *)(pdata + ETH_HLEN);
dscp = piphdr->tos & 0xfc;
priority = dscp >> 5;
break;
@@ -323,7 +323,7 @@ struct net_device *rtw_init_netdev(struct adapter
*old_padapter)
padapter->pnetdev = pnetdev;
DBG_88E("register rtw_netdev_ops to netdev_ops\n");
pnetdev->netdev_ops = _netdev_ops;
- pnetdev->watchdog_timeo = HZ*3; /* 3 second timeout */
+ pnetdev->watchdog_timeo = HZ * 3; /* 3 second timeout */
pnetdev->wireless_handlers = (struct iw_handler_def *)_handlers_def;
loadparam(padapter, pnetdev);
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: rtl8188eu: remove unnecessary parentheses in os_intfs.c
Remove unnecessary parentheses reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index abcce2240f15..6681383579ee 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -198,8 +198,8 @@ static int rtw_net_set_mac_address(struct net_device
*pnetdev, void *p)
static struct net_device_stats *rtw_net_get_stats(struct net_device *pnetdev)
{
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(pnetdev);
- struct xmit_priv *pxmitpriv = &(padapter->xmitpriv);
- struct recv_priv *precvpriv = &(padapter->recvpriv);
+ struct xmit_priv *pxmitpriv = >xmitpriv;
+ struct recv_priv *precvpriv = >recvpriv;
padapter->stats.tx_packets = pxmitpriv->tx_pkts;
padapter->stats.rx_packets = precvpriv->rx_pkts;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: rtl8188eu: cleanup declarations in os_intfs.c
Replace tabs with spaces and/or remove extra spaces in declarations.
---
drivers/staging/rtl8188eu/os_dep/os_intfs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
index 6681383579ee..6ed4a06a0796 100644
--- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c
+++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c
@@ -137,7 +137,7 @@ static int netdev_close(struct net_device *pnetdev);
static void loadparam(struct adapter *padapter, struct net_device *pnetdev)
{
- struct registry_priv *registry_par = >registrypriv;
+ struct registry_priv *registry_par = >registrypriv;
GlobalDebugLevel = rtw_debug;
@@ -248,7 +248,7 @@ static u16 rtw_select_queue(struct net_device *dev, struct
sk_buff *skb,
struct net_device *sb_dev,
select_queue_fallback_t fallback)
{
- struct adapter *padapter = rtw_netdev_priv(dev);
+ struct adapter *padapter = rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = >mlmepriv;
skb->priority = rtw_classify8021d(skb);
@@ -263,7 +263,7 @@ u16 rtw_recv_select_queue(struct sk_buff *skb)
{
struct iphdr *piphdr;
unsigned int dscp;
- __be16 eth_type;
+ __be16 eth_type;
u32 priority;
u8 *pdata = skb->data;
@@ -286,7 +286,7 @@ static const struct net_device_ops rtw_netdev_ops = {
.ndo_open = netdev_open,
.ndo_stop = netdev_close,
.ndo_start_xmit = rtw_xmit_entry,
- .ndo_select_queue = rtw_select_queue,
+ .ndo_select_queue = rtw_select_queue,
.ndo_set_mac_address = rtw_net_set_mac_address,
.ndo_get_stats = rtw_net_get_stats,
.ndo_do_ioctl = rtw_ioctl,
@@ -361,7 +361,7 @@ void rtw_stop_drv_threads(struct adapter *padapter)
static u8 rtw_init_default_value(struct adapter *padapter)
{
struct registry_priv *pregistrypriv = >registrypriv;
- struct xmit_priv*pxmitpriv = >xmitpriv;
+ struct xmit_priv *pxmitpriv = >xmitpriv;
struct mlme_priv *pmlmepriv = >mlmepriv;
struct security_priv *psecuritypriv = >securitypriv;
@@ -431,7 +431,7 @@ u8 rtw_reset_drv_sw(struct adapter *padapter)
u8 rtw_init_drv_sw(struct adapter *padapter)
{
- u8 ret8 = _SUCCESS;
+ u8 ret8 = _SUCCESS;
RT_TRACE(_module_os_intfs_c_, _drv_info_, ("+rtw_init_drv_sw\n"));
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
