[PATCH] staging: iio: ad2s1210: fix 'assignment operator' style checks
This patch fixes all "Assignment operator '=' should be on the previous
line" checks found in ad2s1210.c by checkpatch.pl.
Signed-off-by: Matheus Tavares
---
drivers/staging/iio/resolver/ad2s1210.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/resolver/ad2s1210.c
b/drivers/staging/iio/resolver/ad2s1210.c
index ac13b99bd9cb..d4b1c2c010f2 100644
--- a/drivers/staging/iio/resolver/ad2s1210.c
+++ b/drivers/staging/iio/resolver/ad2s1210.c
@@ -301,8 +301,8 @@ static ssize_t ad2s1210_store_control(struct device *dev,
"ad2s1210: write control register fail\n");
goto error_ret;
}
-st->resolution
-= ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
+st->resolution =
+ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
if (st->pdata->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
@@ -363,8 +363,8 @@ static ssize_t ad2s1210_store_resolution(struct device *dev,
dev_err(dev, "ad2s1210: setting resolution fail\n");
goto error_ret;
}
-st->resolution
-= ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
+st->resolution =
+ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION];
if (st->pdata->gpioin) {
data = ad2s1210_read_resolution_pin(st);
if (data != st->resolution)
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/rtlwifi: Fixing formatting warnings from checkpatch.pl.
On Fri, Oct 5, 2018 at 6:37 PM Joe Perches wrote: > > On Fri, 2018-10-05 at 16:58 -0600, Scott Tracy wrote: > > Fixing formatting warnings in rtlwifi found by checkpatch.pl > > Changes include breaking up functions calls into multi line calls. > > No functional/logical changes. > > I believe the code is better before most of these changes. > > There are various tradeoffs do source code formatting. > > Here you are changing some alignment to open parentheses > and converting to < 80 columns. > > Joe, Thanks for the criticism. Fair comments all. I was just working through the KernelNewbies.org tutorial looking for low value changes to get my feet wet and assumed that a "check" was better than a "warning". A also didn't feel confident enough to refactor the code to get under the 80 character limit. Maybe I will spend a little more time refactoring something and then submitting that. Thanks again, Scott Tracy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[no subject]
linux-ker...@vger.kernel.org Cc: Bcc: Subject: [PATCH] staging/rtlwifi: Fixing formatting warnings from checkpatch.pl. Reply-To: On Fri, 10/5/18 at 6:37PM Joe Perches wrote: >On Fri, 2018-10-05 at 16:58 -0600, Scott Tracy wrote: >> Fixing formatting warnings in rtlwifi found by checkpatch.pl >> Changes include breaking up functions calls into multi line calls. >> No functional/logical changes. > >I believe the code is better before most of these changes. > >There are various tradeoffs do source code formatting. > >Here you are changing some alignment to open parentheses >and converting to < 80 columns. Fair critisim. I was learning from the tutorial on kernelnewbies.org, and picked simple warnings to correct. The initial thought was that a "check" was better than a "warning". I just hesitated to jumping into refactoring the code to get it under the 80 column limit. I will look for a better target to change. Thanks, Scott Tracy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: erofs: fix indenting to conform to kernel coding style
Hi Ioannis,
Thanks for your patch.
Could you please resend this patch to the staging-devel/erofs-devel mailing
list?
Since we are in the China National Day holiday and I can only send email in
the corporation by the HUAWEI mailbox, I cannot reply emails in time...
It could be better to Cc patches to the proper mailing lists...
On 2018/10/6 1:23, Ioannis Valasakis wrote:
> Cleanup all inconsistent indenting to conform to kernel coding style.
> Reported by checkpatch.
It should be fixed, but out of curiousity, could you fix all
the indentings of erofs in this patch?
>
> Signed-off-by: Ioannis Valasakis
> ---
> drivers/staging/erofs/data.c | 56 ++--
> 1 file changed, 28 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/staging/erofs/data.c b/drivers/staging/erofs/data.c
> index 6384f73e5418..ffd392e74803 100644
> --- a/drivers/staging/erofs/data.c
> +++ b/drivers/staging/erofs/data.c
> @@ -40,7 +40,7 @@ static inline void read_endio(struct bio *bio)
>
> /* prio -- true is used for dir */
> struct page *__erofs_get_meta_page(struct super_block *sb,
> - erofs_blk_t blkaddr, bool prio, bool nofail)
> +erofs_blk_t blkaddr, bool prio, bool nofail)
> {
> struct inode *const bd_inode = sb->s_bdev->bd_inode;
> struct address_space *const mapping = bd_inode->i_mapping;
> @@ -53,7 +53,7 @@ struct page *__erofs_get_meta_page(struct super_block *sb,
>
> repeat:
> page = find_or_create_page(mapping, blkaddr, gfp);
> - if (unlikely(page == NULL)) {
> + if (unlikely(!page)) {
Here should be fixed too, but it is another case.
Could you make another patch to fix the NULL pointer checks?
Thanks,
Gao Xiang
> DBG_BUGON(nofail);
> return ERR_PTR(-ENOMEM);
> }
> @@ -76,7 +76,7 @@ struct page *__erofs_get_meta_page(struct super_block *sb,
> }
>
> __submit_bio(bio, REQ_OP_READ,
> - REQ_META | (prio ? REQ_PRIO : 0));
> + REQ_META | (prio ? REQ_PRIO : 0));
>
> lock_page(page);
>
> @@ -107,7 +107,7 @@ struct page *__erofs_get_meta_page(struct super_block *sb,
> }
>
> static int erofs_map_blocks_flatmode(struct inode *inode,
> - struct erofs_map_blocks *map,
> + struct erofs_map_blocks *map,
> int flags)
> {
> int err = 0;
> @@ -151,7 +151,7 @@ static int erofs_map_blocks_flatmode(struct inode *inode,
> map->m_flags |= EROFS_MAP_META;
> } else {
> errln("internal error @ nid: %llu (size %llu), m_la 0x%llx",
> - vi->nid, inode->i_size, map->m_la);
> + vi->nid, inode->i_size, map->m_la);
> DBG_BUGON(1);
> err = -EIO;
> goto err_out;
> @@ -167,16 +167,17 @@ static int erofs_map_blocks_flatmode(struct inode
> *inode,
>
> #ifdef CONFIG_EROFS_FS_ZIP
> extern int z_erofs_map_blocks_iter(struct inode *,
> - struct erofs_map_blocks *, struct page **, int);
> +struct erofs_map_blocks *,
> +struct page **, int);
> #endif
>
> int erofs_map_blocks_iter(struct inode *inode,
> - struct erofs_map_blocks *map,
> + struct erofs_map_blocks *map,
> struct page **mpage_ret, int flags)
> {
> /* by default, reading raw data never use erofs_map_blocks_iter */
> if (unlikely(!is_inode_layout_compression(inode))) {
> - if (*mpage_ret != NULL)
> + if (*mpage_ret)
> put_page(*mpage_ret);
> *mpage_ret = NULL;
>
> @@ -192,27 +193,27 @@ int erofs_map_blocks_iter(struct inode *inode,
> }
>
> int erofs_map_blocks(struct inode *inode,
> - struct erofs_map_blocks *map, int flags)
> + struct erofs_map_blocks *map, int flags)
> {
> if (unlikely(is_inode_layout_compression(inode))) {
> struct page *mpage = NULL;
> int err;
>
> err = erofs_map_blocks_iter(inode, map, , flags);
> - if (mpage != NULL)
> + if (mpage)
> put_page(mpage);
> return err;
> }
> return erofs_map_blocks_flatmode(inode, map, flags);
> }
>
> -static inline struct bio *erofs_read_raw_page(
> - struct bio *bio,
> - struct address_space *mapping,
> - struct page *page,
> - erofs_off_t *last_block,
> - unsigned int nblocks,
> - bool ra)
> +static inline struct bio *erofs_read_raw_page
> + (struct bio *bio,
> + struct address_space *mapping,
> + struct page *page,
> + erofs_off_t *last_block,
> + unsigned int nblocks,
> + bool ra)
> {
> struct inode *inode = mapping->host;
> erofs_off_t current_block = (erofs_off_t)page->index;
> @@ -232,15 +233,15 @@ static inline struct bio *erofs_read_raw_page(
>
[PATCH] staging/rtlwifi: Fixing formatting warnings from checkpatch.pl.
Fixing formatting warnings in rtlwifi found by checkpatch.pl
Changes include breaking up functions calls into multi line calls.
No functional/logical changes.
Signed-off-by: Scott Tracy
---
drivers/staging/rtlwifi/core.c | 5 +++--
drivers/staging/rtlwifi/efuse.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
index ca37f7511c4d..a36cb44a5388 100644
--- a/drivers/staging/rtlwifi/core.c
+++ b/drivers/staging/rtlwifi/core.c
@@ -1109,7 +1109,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw
*hw,
if (rtlpriv->dm.supp_phymode_switch) {
if (sta->ht_cap.ht_supported)
rtl_send_smps_action(hw, sta,
-
IEEE80211_SMPS_STATIC);
+ IEEE80211_SMPS_STATIC);
}
if (rtlhal->current_bandtype == BAND_ON_5G) {
@@ -1882,7 +1882,8 @@ bool rtl_hal_pwrseqcmdparsing(struct rtl_priv *rtlpriv,
u8 cut_version,
return true;
default:
WARN_ONCE(true,
- "rtlwifi: %s(): Unknown CMD!!\n",
__func__);
+"rtlwifi: %s(): Unknown CMD!!\n",
+ __func__);
break;
}
}
diff --git a/drivers/staging/rtlwifi/efuse.c b/drivers/staging/rtlwifi/efuse.c
index 1dc71455f270..5b8afdb3e0fe 100644
--- a/drivers/staging/rtlwifi/efuse.c
+++ b/drivers/staging/rtlwifi/efuse.c
@@ -245,7 +245,8 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16
_size_byte, u8 *pbuf)
if (!efuse_word)
goto out;
for (i = 0; i < EFUSE_MAX_WORD_UNIT; i++) {
- efuse_word[i] = kcalloc(efuse_max_section, sizeof(u16),
GFP_ATOMIC);
+ efuse_word[i] = kcalloc(efuse_max_section,
+ sizeof(u16), GFP_ATOMIC);
if (!efuse_word[i])
goto done;
}
@@ -375,7 +376,7 @@ bool efuse_shadow_update_chk(struct ieee80211_hw *hw)
for (i = 0; i < 8; i = i + 2) {
if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) ||
- (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1]
!=
+ (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
1])) {
words_need++;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] STAGING/EMXX_UDC: emxx_udc.c: Fixed all meaningful sparse errors: 1. Added static to udc_controller 2. Added mising __iomem modifier to handle p_regs 3. Added missing le16_to_cpu
On Fri, Oct 05, 2018 at 01:04:27PM -0400, Carmeli Tamir wrote: > Signed-off-by: Tamir Carmeli > --- > drivers/staging/emxx_udc/Makefile | 2 +- > drivers/staging/emxx_udc/emxx_udc.c | 69 > +++-- > drivers/staging/emxx_udc/emxx_udc.h | 2 +- > 3 files changed, 38 insertions(+), 35 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/rtlwifi: Fixing formatting warnings.
On Fri, Oct 05, 2018 at 02:58:15PM -0600, Scott Tracy wrote: > Signed-off-by: Scott Tracy > --- > drivers/staging/rtlwifi/core.c | 5 +++-- > drivers/staging/rtlwifi/efuse.c | 5 +++-- > 2 files changed, 6 insertions(+), 4 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: > Marcelo Tosatti writes: > > > On Wed, Oct 03, 2018 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: > >> > >> There is a very long history of different (hardware) issues Marcelo was > >> fighting with and the current code is the survived Frankenstein. > > > > Right, the code has to handle different TSC modes. > > > >> E.g. it > >> is very, very unclear what "catchup", "always catchup" and > >> masterclock-less mode in general are and if we still need them. > > > > Catchup means handling exposed (to guest) TSC frequency smaller than > > HW TSC frequency. > > > > That is "frankenstein" code, could be removed. > > > >> That said I'm all for simplification. I'm not sure if we still need to > >> care about buggy hardware though. > > > > What simplification is that again? > > > > I was hoping to hear this from you :-) If I am to suggest how we can > move forward I'd propose: > - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling > is supported). In that case just use TSC clocksource on the guest directly: i am writing code for that now (its faster than pvclock syscall). > - Check if non-masterclock mode is still needed. E.g. HyperV's TSC page > clocksource is a single page for the whole VM, not a per-cpu thing. Can > we think that all the buggy hardware is already gone? As Peter mentioned, non sync TSC hardware might exist in the future. And older hardware must be supported. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/rtlwifi: Fixing formatting warnings.
On 10/5/18 10:58 PM, Scott Tracy wrote:
> Signed-off-by: Scott Tracy
> ---
> drivers/staging/rtlwifi/core.c | 5 +++--
> drivers/staging/rtlwifi/efuse.c | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
> index ca37f7511c4d..a36cb44a5388 100644
> --- a/drivers/staging/rtlwifi/core.c
> +++ b/drivers/staging/rtlwifi/core.c
> @@ -1109,7 +1109,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw
> *hw,
> if (rtlpriv->dm.supp_phymode_switch) {
> if (sta->ht_cap.ht_supported)
> rtl_send_smps_action(hw, sta,
> -
> IEEE80211_SMPS_STATIC);
> + IEEE80211_SMPS_STATIC);
> }
>
> if (rtlhal->current_bandtype == BAND_ON_5G) {
> @@ -1882,7 +1882,8 @@ bool rtl_hal_pwrseqcmdparsing(struct rtl_priv *rtlpriv,
> u8 cut_version,
> return true;
> default:
> WARN_ONCE(true,
> - "rtlwifi: %s(): Unknown CMD!!\n",
> __func__);
> + "rtlwifi: %s(): Unknown CMD!!\n",
> + __func__);
> break;
> }
> }
> diff --git a/drivers/staging/rtlwifi/efuse.c b/drivers/staging/rtlwifi/efuse.c
> index 1dc71455f270..5b8afdb3e0fe 100644
> --- a/drivers/staging/rtlwifi/efuse.c
> +++ b/drivers/staging/rtlwifi/efuse.c
> @@ -245,7 +245,8 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16
> _size_byte, u8 *pbuf)
> if (!efuse_word)
> goto out;
> for (i = 0; i < EFUSE_MAX_WORD_UNIT; i++) {
> - efuse_word[i] = kcalloc(efuse_max_section, sizeof(u16),
> GFP_ATOMIC);
> + efuse_word[i] = kcalloc(efuse_max_section,
> + sizeof(u16), GFP_ATOMIC);
> if (!efuse_word[i])
> goto done;
> }
> @@ -375,7 +376,7 @@ bool efuse_shadow_update_chk(struct ieee80211_hw *hw)
> for (i = 0; i < 8; i = i + 2) {
> if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
>rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) ||
> - (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1]
> !=
> +(rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
>rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
> 1])) {
> words_need++;
>
Hi,
Please, always add a commit log explaining what exactly are you trying to fix.
Thanks
--
Gustavo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/rtlwifi: Fixing formatting warnings.
Signed-off-by: Scott Tracy
---
drivers/staging/rtlwifi/core.c | 5 +++--
drivers/staging/rtlwifi/efuse.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
index ca37f7511c4d..a36cb44a5388 100644
--- a/drivers/staging/rtlwifi/core.c
+++ b/drivers/staging/rtlwifi/core.c
@@ -1109,7 +1109,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw
*hw,
if (rtlpriv->dm.supp_phymode_switch) {
if (sta->ht_cap.ht_supported)
rtl_send_smps_action(hw, sta,
-
IEEE80211_SMPS_STATIC);
+ IEEE80211_SMPS_STATIC);
}
if (rtlhal->current_bandtype == BAND_ON_5G) {
@@ -1882,7 +1882,8 @@ bool rtl_hal_pwrseqcmdparsing(struct rtl_priv *rtlpriv,
u8 cut_version,
return true;
default:
WARN_ONCE(true,
- "rtlwifi: %s(): Unknown CMD!!\n",
__func__);
+"rtlwifi: %s(): Unknown CMD!!\n",
+ __func__);
break;
}
}
diff --git a/drivers/staging/rtlwifi/efuse.c b/drivers/staging/rtlwifi/efuse.c
index 1dc71455f270..5b8afdb3e0fe 100644
--- a/drivers/staging/rtlwifi/efuse.c
+++ b/drivers/staging/rtlwifi/efuse.c
@@ -245,7 +245,8 @@ void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16
_size_byte, u8 *pbuf)
if (!efuse_word)
goto out;
for (i = 0; i < EFUSE_MAX_WORD_UNIT; i++) {
- efuse_word[i] = kcalloc(efuse_max_section, sizeof(u16),
GFP_ATOMIC);
+ efuse_word[i] = kcalloc(efuse_max_section,
+ sizeof(u16), GFP_ATOMIC);
if (!efuse_word[i])
goto done;
}
@@ -375,7 +376,7 @@ bool efuse_shadow_update_chk(struct ieee80211_hw *hw)
for (i = 0; i < 8; i = i + 2) {
if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) ||
- (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1]
!=
+ (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
1])) {
words_need++;
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] STAGING/EMXX_UDC: emxx_udc.c: Fixed all meaningful sparse errors: 1. Added static to udc_controller 2. Added mising __iomem modifier to handle p_regs 3. Added missing le16_to_cpu
Signed-off-by: Tamir Carmeli
---
drivers/staging/emxx_udc/Makefile | 2 +-
drivers/staging/emxx_udc/emxx_udc.c | 69 +++--
drivers/staging/emxx_udc/emxx_udc.h | 2 +-
3 files changed, 38 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 3e51476..83eb430 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -56,25 +56,25 @@ static void _nbu2ss_fifo_flush(struct nbu2ss_udc *, struct
nbu2ss_ep *);
/*===*/
/* Global */
-struct nbu2ss_udc udc_controller;
+static struct nbu2ss_udc udc_controller;
/*-*/
/* Read */
-static inline u32 _nbu2ss_readl(void *address)
+static inline u32 _nbu2ss_readl(void __iomem *address)
{
return __raw_readl(address);
}
/*-*/
/* Write */
-static inline void _nbu2ss_writel(void *address, u32 udata)
+static inline void _nbu2ss_writel(void __iomem *address, u32 udata)
{
__raw_writel(udata, address);
}
/*-*/
/* Set Bit */
-static inline void _nbu2ss_bitset(void *address, u32 udata)
+static inline void _nbu2ss_bitset(void __iomem *address, u32 udata)
{
u32 reg_dt = __raw_readl(address) | (udata);
@@ -83,7 +83,7 @@ static inline void _nbu2ss_bitset(void *address, u32 udata)
/*-*/
/* Clear Bit */
-static inline void _nbu2ss_bitclr(void *address, u32 udata)
+static inline void _nbu2ss_bitclr(void __iomem *address, u32 udata)
{
u32 reg_dt = __raw_readl(address) & ~(udata);
@@ -135,6 +135,7 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep, struct
usb_request *_req)
{
u8 recipient;
u16 selector;
+ u16 wIndex;
u32 test_mode;
struct usb_ctrlrequest *p_ctrl;
struct nbu2ss_udc *udc;
@@ -149,10 +150,11 @@ static void _nbu2ss_ep0_complete(struct usb_ep *_ep,
struct usb_request *_req)
/*-*/
/* SET_FEATURE */
recipient = (u8)(p_ctrl->bRequestType & USB_RECIP_MASK);
- selector = p_ctrl->wValue;
+ selector = le16_to_cpu(p_ctrl->wValue);
if ((recipient == USB_RECIP_DEVICE) &&
(selector == USB_DEVICE_TEST_MODE)) {
- test_mode = (u32)(p_ctrl->wIndex >> 8);
+ wIndex = le16_to_cpu(p_ctrl->wIndex);
+ test_mode = (u32)(wIndex >> 8);
_nbu2ss_set_test_mode(udc, test_mode);
}
}
@@ -184,7 +186,7 @@ static u32 _nbu2ss_get_begin_ram_address(struct nbu2ss_udc
*udc)
u32 num, buf_type;
u32 data, last_ram_adr, use_ram_size;
- struct ep_regs *p_ep_regs;
+ struct ep_regs __iomem *p_ep_regs;
last_ram_adr = (D_RAM_SIZE_CTRL / sizeof(u32)) * 2;
use_ram_size = 0;
@@ -377,7 +379,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc,
struct nbu2ss_ep *ep)
{
u32 num;
u32 data;
- struct fc_regs *preg = udc->p_regs;
+ struct fc_regs __iomem *preg = udc->p_regs;
if (udc->vbus_active == 0)
return; /* VBUS OFF */
@@ -408,7 +410,7 @@ static void _nbu2ss_ep_dma_exit(struct nbu2ss_udc *udc,
struct nbu2ss_ep *ep)
/* Abort DMA */
static void _nbu2ss_ep_dma_abort(struct nbu2ss_udc *udc, struct nbu2ss_ep *ep)
{
- struct fc_regs *preg = udc->p_regs;
+ struct fc_regs __iomem *preg = udc->p_regs;
_nbu2ss_bitclr(>EP_DCR[ep->epnum - 1].EP_DCR1, DCR1_EPN_REQEN);
mdelay(DMA_DISABLE_TIME); /* DCR1_EPN_REQEN Clear */
@@ -426,7 +428,7 @@ static void _nbu2ss_ep_in_end(
{
u32 data;
u32 num;
- struct fc_regs *preg = udc->p_regs;
+ struct fc_regs __iomem *preg = udc->p_regs;
if (length >= sizeof(u32))
return;
@@ -817,7 +819,7 @@ static int _nbu2ss_out_dma(
u32 burst = 1;
u32 data;
int result = -EINVAL;
- struct fc_regs *preg = udc->p_regs;
+ struct fc_regs __iomem *preg = udc->p_regs;
if (req->dma_flag)
return 1; /* DMA is forwarded */
@@ -880,7 +882,7 @@ static int _nbu2ss_epn_out_pio(
union usb_reg_accesstemp_32;
union usb_reg_access*p_buf_32;
int result = 0;
-
Re: [PATCH resend 00/15] staging: vboxvideo: Convert to atomic modesetting API
On Mon, Oct 01, 2018 at 11:20:04AM +0200, Hans de Goede wrote: > Hi, > > On 01-10-18 09:25, Dan Carpenter wrote: > > Why are you resending this? It's because you added some more patches > > on the end? Just send those as a new series... > > I accidentally numbered the cover-letter of the original series > 01/15 instea dof 00/15 this confused Greg, so he asked for a resend. > > Nothing is changed in the resend, otherwise I would have made > the series a v2 and not a resend. I'm assuming this all lands for 4.20/5.0, since I've just merged the series to nuke the transitional helpers for good for 2.21/5.1. Worst case we just need to pull this in as a topic branch, based on a sufficiently old-enough kernel. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: greybus: loopback.c: simplify prototype of gb_loopback_bus_id_compare
gb_loopback_bus_id_compare only has a single caller, and it no longer
needs to have a prototype compatible with being a callback for
list_sort.
Signed-off-by: Rasmus Villemoes
---
drivers/staging/greybus/loopback.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 89c3f6fd8ddf..2c7bad66bb31 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -987,11 +987,8 @@ static const struct file_operations
gb_loopback_debugfs_latency_ops = {
.release= single_release,
};
-static int gb_loopback_bus_id_compare(void *priv, struct list_head *lha,
- struct list_head *lhb)
+static int gb_loopback_bus_id_compare(struct gb_loopback *a, struct
gb_loopback *b)
{
- struct gb_loopback *a = list_entry(lha, struct gb_loopback, entry);
- struct gb_loopback *b = list_entry(lhb, struct gb_loopback, entry);
struct gb_connection *ca = a->connection;
struct gb_connection *cb = b->connection;
@@ -1022,7 +1019,7 @@ static void gb_loopback_insert_id(struct gb_loopback *gb)
* and we thus insert at the end.
*/
list_for_each_entry(gb_list, _dev.list, entry) {
- if (gb_loopback_bus_id_compare(NULL, >entry,
_list->entry) < 0)
+ if (gb_loopback_bus_id_compare(gb, gb_list) < 0)
break;
}
list_add_tail(>entry, _list->entry);
--
2.19.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: greybus: loopback.c: remove unused gb_loopback::lbid
It's not obvious how the code prevents adding more than 31 elements to
the list and thus invoking undefined behaviour in the 1 << new_lbid
expression, and in practice causing ->lbid values to repeat every 32
elements.
But the definition of struct gb_loopback is local to loopback.c, and the
lbid field is entirely unused outside of this function, so it seems we
can just drop it entirely.
Signed-off-by: Rasmus Villemoes
---
Since lbid isn't mentioned anywhere else in greybus/, it's hard to
figure out how it was meant to be used. It does seem like entirely
dead (write-only) code.
drivers/staging/greybus/loopback.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 42f6f3de967c..7080294f705c 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -97,7 +97,6 @@ struct gb_loopback {
u32 timeout_min;
u32 timeout_max;
u32 outstanding_operations_max;
- u32 lbid;
u64 elapsed_nsecs;
u32 apbridge_latency_ts;
u32 gbphy_latency_ts;
@@ -1014,16 +1013,9 @@ static int gb_loopback_bus_id_compare(void *priv, struct
list_head *lha,
static void gb_loopback_insert_id(struct gb_loopback *gb)
{
- struct gb_loopback *gb_list;
- u32 new_lbid = 0;
-
/* perform an insertion sort */
list_add_tail(>entry, _dev.list);
list_sort(NULL, _dev.list, gb_loopback_bus_id_compare);
- list_for_each_entry(gb_list, _dev.list, entry) {
- gb_list->lbid = 1 << new_lbid;
- new_lbid++;
- }
}
#define DEBUGFS_NAMELEN 32
--
2.19.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: greybus: loopback.c: do insertion in O(n) instead of O(n lg n)
"Append to the list and do a merge sort" is not really an insertion
sort. While a few more lines of code, we can keep the list sorted doing
at most n comparisons by iterating until we find the first element
strictly greater than gb.
Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the followup cleanup.
drivers/staging/greybus/loopback.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/greybus/loopback.c
b/drivers/staging/greybus/loopback.c
index 7080294f705c..89c3f6fd8ddf 100644
--- a/drivers/staging/greybus/loopback.c
+++ b/drivers/staging/greybus/loopback.c
@@ -1013,9 +1013,19 @@ static int gb_loopback_bus_id_compare(void *priv, struct
list_head *lha,
static void gb_loopback_insert_id(struct gb_loopback *gb)
{
- /* perform an insertion sort */
- list_add_tail(>entry, _dev.list);
- list_sort(NULL, _dev.list, gb_loopback_bus_id_compare);
+ struct gb_loopback *gb_list;
+
+ /*
+* Keep the list sorted. Insert gb before the first element it
+* compares strictly less than. If no such element exists, the
+* loop terminates with _list->entry being _dev.list,
+* and we thus insert at the end.
+*/
+ list_for_each_entry(gb_list, _dev.list, entry) {
+ if (gb_loopback_bus_id_compare(NULL, >entry,
_list->entry) < 0)
+ break;
+ }
+ list_add_tail(>entry, _list->entry);
}
#define DEBUGFS_NAMELEN 32
--
2.19.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] staging: axis-fifo: remove duplicated include from axis-fifo.c
Remove duplicated include. Signed-off-by: YueHaibing --- drivers/staging/axis-fifo/axis-fifo.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/axis-fifo/axis-fifo.c b/drivers/staging/axis-fifo/axis-fifo.c index 63c8efd..48a9877 100644 --- a/drivers/staging/axis-fifo/axis-fifo.c +++ b/drivers/staging/axis-fifo/axis-fifo.c @@ -27,8 +27,6 @@ #include #include #include -#include -#include #include #include #include ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] [media] media: drop pointless static qualifier in vpfe_ipipeif_init()
There is no need to have the 'resource_size_t res_len' variable static since new value always be assigned before use it. Signed-off-by: YueHaibing --- drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c index a53231b..e191829 100644 --- a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c @@ -998,7 +998,7 @@ int vpfe_ipipeif_init(struct vpfe_ipipeif_device *ipipeif, struct v4l2_subdev *sd = >subdev; struct media_pad *pads = >pads[0]; struct media_entity *me = >entity; - static resource_size_t res_len; + resource_size_t res_len; struct resource *res; int ret; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH -next] [media] media: drop pointless static qualifier in vpfe_resizer_init()
There is no need to have the 'resource_size_t res_len' variable static since new value always be assigned before use it. Signed-off-by: YueHaibing --- drivers/staging/media/davinci_vpfe/dm365_resizer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/davinci_vpfe/dm365_resizer.c b/drivers/staging/media/davinci_vpfe/dm365_resizer.c index aac6dbf..b2b23a7 100644 --- a/drivers/staging/media/davinci_vpfe/dm365_resizer.c +++ b/drivers/staging/media/davinci_vpfe/dm365_resizer.c @@ -1884,7 +1884,7 @@ int vpfe_resizer_init(struct vpfe_resizer_device *vpfe_rsz, struct v4l2_subdev *sd = _rsz->crop_resizer.subdev; struct media_pad *pads = _rsz->crop_resizer.pads[0]; struct media_entity *me = >entity; - static resource_size_t res_len; + resource_size_t res_len; struct resource *res; int ret; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 10/11] media: imx: Allow interweave with top/bottom lines swapped
Hi Steve,
On Thu, 2018-10-04 at 11:54 -0700, Steve Longerbeam wrote:
> Allow sequential->interlaced interweaving but with top/bottom
> lines swapped to the output buffer.
>
> This can be accomplished by adding one line length to IDMAC output
> channel address, with a negative line length for the interlace offset.
>
> This is to allow the seq-bt -> interlaced-bt transformation, where
> bottom lines are still dominant (older in time) but with top lines
> first in the interweaved output buffer.
>
> With this support, the CSI can now allow seq-bt at its source pads,
> e.g. the following transformations are allowed in CSI from sink to
> source:
>
> seq-tb -> seq-bt
> seq-bt -> seq-bt
> alternate -> seq-bt
>
> Suggested-by: Philipp Zabel
> Signed-off-by: Steve Longerbeam
> ---
> drivers/staging/media/imx/imx-ic-prpencvf.c | 17 +++-
> drivers/staging/media/imx/imx-media-csi.c | 46 +
> 2 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c
> b/drivers/staging/media/imx/imx-ic-prpencvf.c
> index cf76b0432371..1499b0c62d74 100644
> --- a/drivers/staging/media/imx/imx-ic-prpencvf.c
> +++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
> @@ -106,6 +106,8 @@ struct prp_priv {
> u32 frame_sequence; /* frame sequence counter */
> bool last_eof; /* waiting for last EOF at stream off */
> bool nfb4eof;/* NFB4EOF encountered during streaming */
> + u32 interweave_offset; /* interweave line offset to swap
> + top/bottom lines */
We have to store this instead of using vdev->fmt.fmt.bytesperline
because this potentially is the pre-rotation stride instead?
> struct completion last_eof_comp;
> };
>
> @@ -235,6 +237,9 @@ static void prp_vb2_buf_done(struct prp_priv *priv,
> struct ipuv3_channel *ch)
> if (ipu_idmac_buffer_is_ready(ch, priv->ipu_buf_num))
> ipu_idmac_clear_buffer(ch, priv->ipu_buf_num);
>
> + if (ch == priv->out_ch)
> + phys += priv->interweave_offset;
> +
> ipu_cpmem_set_buffer(ch, priv->ipu_buf_num, phys);
> }
>
> @@ -388,6 +393,13 @@ static int prp_setup_channel(struct prp_priv *priv,
> (image.pix.width * outcc->bpp) >> 3;
> }
>
> + priv->interweave_offset = 0;
> +
> + if (interweave && image.pix.field == V4L2_FIELD_INTERLACED_BT) {
> + image.rect.top = 1;
> + priv->interweave_offset = image.pix.bytesperline;
> + }
> +
> image.phys0 = addr0;
> image.phys1 = addr1;
>
> @@ -425,7 +437,10 @@ static int prp_setup_channel(struct prp_priv *priv,
> ipu_cpmem_set_rotation(channel, rot_mode);
>
> if (interweave)
> - ipu_cpmem_interlaced_scan(channel, image.pix.bytesperline,
> + ipu_cpmem_interlaced_scan(channel,
> + priv->interweave_offset ?
> + -image.pix.bytesperline :
> + image.pix.bytesperline,
> image.pix.pixelformat);
>
> ret = ipu_ic_task_idma_init(priv->ic, channel,
> diff --git a/drivers/staging/media/imx/imx-media-csi.c
> b/drivers/staging/media/imx/imx-media-csi.c
> index 679295da5dde..592f7d6edec1 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -114,6 +114,8 @@ struct csi_priv {
> u32 frame_sequence; /* frame sequence counter */
> bool last_eof; /* waiting for last EOF at stream off */
> bool nfb4eof;/* NFB4EOF encountered during streaming */
> + u32 interweave_offset; /* interweave line offset to swap
> + top/bottom lines */
This doesn't seem necessary. Since there is no rotation here, the offset
is just vdev->fmt.fmt.pix.bytesperline if interweave_swap is enabled.
Maybe turn this into a bool interweave_swap?
> struct completion last_eof_comp;
> };
>
> @@ -286,7 +288,8 @@ static void csi_vb2_buf_done(struct csi_priv *priv)
> if (ipu_idmac_buffer_is_ready(priv->idmac_ch, priv->ipu_buf_num))
> ipu_idmac_clear_buffer(priv->idmac_ch, priv->ipu_buf_num);
>
> - ipu_cpmem_set_buffer(priv->idmac_ch, priv->ipu_buf_num, phys);
> + ipu_cpmem_set_buffer(priv->idmac_ch, priv->ipu_buf_num,
> + phys + priv->interweave_offset);
> }
>
> static irqreturn_t csi_idmac_eof_interrupt(int irq, void *dev_id)
> @@ -396,10 +399,10 @@ static void csi_idmac_unsetup_vb2_buf(struct csi_priv
> *priv,
> static int csi_idmac_setup_channel(struct csi_priv *priv)
> {
> struct imx_media_video_dev *vdev = priv->vdev;
> + bool passthrough, interweave, interweave_swap;
> const struct imx_media_pixfmt *incc;
> struct v4l2_mbus_framefmt *infmt;
> struct v4l2_mbus_framefmt *outfmt;
> - bool passthrough, interweave;
> struct
Re: [PATCH v4 09/11] media: imx-csi: Move crop/compose reset after filling default mbus fields
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote: > If caller passes un-initialized field type V4L2_FIELD_ANY to CSI > sink pad, the reset CSI crop window would not be correct, because > the crop window depends on a valid input field type. To fix move > the reset of crop and compose windows to after the call to > imx_media_fill_default_mbus_fields(). > > Signed-off-by: Steve Longerbeam Reviewed-by: Philipp Zabel regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 06/11] media: imx: interweave and odd-chroma-row skip are incompatible
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote: > If IDMAC interweaving is enabled in a write channel, the channel must > write the odd chroma rows for 4:2:0 formats. Skipping writing the odd > chroma rows produces corrupted captured 4:2:0 images when interweave > is enabled. > > Reported-by: Krzysztof Hałasa > Signed-off-by: Steve Longerbeam Reviewed-by: Philipp Zabel regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 07/11] media: imx-csi: Allow skipping odd chroma rows for YVU420
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote: > Skip writing U/V components to odd rows for YVU420 in addition to > YUV420 and NV12. > > Signed-off-by: Steve Longerbeam > Reviewed-by: Philipp Zabel > --- > drivers/staging/media/imx/imx-media-csi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/media/imx/imx-media-csi.c > b/drivers/staging/media/imx/imx-media-csi.c > index 4b075bc949de..6dd53a8e35d2 100644 > --- a/drivers/staging/media/imx/imx-media-csi.c > +++ b/drivers/staging/media/imx/imx-media-csi.c > @@ -452,6 +452,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv) > passthrough_bits = 16; > break; > case V4L2_PIX_FMT_YUV420: > + case V4L2_PIX_FMT_YVU420: > case V4L2_PIX_FMT_NV12: > burst_size = (image.pix.width & 0x3f) ? >((image.pix.width & 0x1f) ? Reviewed-by: Philipp Zabel regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 05/11] media: imx-csi: Double crop height for alternate fields at sink
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote: > If the incoming sink field type is alternate, the reset crop height > and crop height bounds must be set to twice the incoming height, > because in alternate field mode, upstream will report only the > lines for a single field, and the CSI captures the whole frame. > > Signed-off-by: Steve Longerbeam Reviewed-by: Philipp Zabel regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 04/11] media: imx: Fix field negotiation
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote: > IDMAC interlaced scan, a.k.a. interweave, should be enabled in the > IDMAC output channels only if the IDMAC output pad field type is > 'seq-bt' or 'seq-tb', and field type at the capture interface is > 'interlaced*'. > > V4L2_FIELD_HAS_BOTH() macro should not be used on the input to determine > enabling interlaced/interweave scan. That macro includes the 'interlaced' > field types, and in those cases the data is already interweaved with > top/bottom field lines. > > The CSI will capture whole frames when the source specifies alternate > field mode. So the CSI also enables interweave for alternate input > field type and the field type at capture interface is interlaced. > > Fix the logic for setting field type in try_fmt in CSI entity. > The behavior should be: > > - No restrictions on field type at sink pad. > > - At the output pads, allow sequential fields in TB order, if the sink pad > field type is sequential or alternate. Otherwise passthrough the field > type from sink to source pad. > > Move this logic to new function csi_try_field(). > > These changes result in the following allowed field transformations > from CSI sink -> source pads (all other field types at sink are passed > through to source): > > seq-tb -> seq-tb > seq-bt -> seq-tb > alternate -> seq-tb > > In a future patch, the CSI sink -> source will allow: > > seq-tb -> seq-bt > seq-bt -> seq-bt > alternate -> seq-bt > > This will require supporting interweave with top/bottom line swapping. > Until then seq-bt is not allowed at the CSI source pad because there is > no way to swap top/bottom lines when interweaving to INTERLACED_BT -- > note that despite the name, INTERLACED_BT is top-bottom order in memory. > The BT in this case refers to field dominance: the bottom lines are > older in time than the top lines. > > The capture interface device allows selecting IDMAC interweave by > choosing INTERLACED_TB if the CSI/PRPENCVF source pad is seq-tb and > INTERLACED_BT if the source pad is seq-bt (for future support of seq-bt). > > Signed-off-by: Steve Longerbeam Reviewed-by: Philipp Zabel regards Philipp ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 02/11] gpu: ipu-csi: Swap fields according to input/output field types
Hi Steve,
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote:
[...]
> int ipu_csi_init_interface(struct ipu_csi *csi,
> struct v4l2_mbus_config *mbus_cfg,
> -struct v4l2_mbus_framefmt *mbus_fmt)
> +struct v4l2_mbus_framefmt *infmt,
> +struct v4l2_mbus_framefmt *outfmt)
> {
[...]
> + std = V4L2_STD_UNKNOWN;
> + if (width == 720) {
> + switch (height) {
> + case 480:
> + std = V4L2_STD_NTSC;
> + break;
> + case 576:
> + std = V4L2_STD_PAL;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + if (std == V4L2_STD_UNKNOWN) {
> dev_err(csi->ipu->dev,
[...]
> + "Unsupported interlaced video mode\n");
> + ret = -EINVAL;
> + goto out_unlock;
> }
[...]
> +
> + /* framelines for NTSC / PAL */
> + height = (std & V4L2_STD_525_60) ? 525 : 625;
I think this is a bit convoluted. Instead of initializing std, then
possibly changing it, and then comparing to the inital value, and then
checking it again to determine the new height, why not just:
if (width == 720 && height == 480) {
std = V4L2_STD_NTSC;
height = 525;
} else if (width == 720 && height == 576) {
std = V4L2_STD_PAL;
height = 625;
} else {
dev_err(csi->ipu->dev,
"Unsupported interlaced video mode\n");
ret = -EINVAL;
goto out_unlock;
}
?
> break;
> case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_DDR:
> case IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_SDR:
> @@ -476,9 +529,10 @@ int ipu_csi_init_interface(struct ipu_csi *csi,
> dev_dbg(csi->ipu->dev, "CSI_ACT_FRM_SIZE = 0x%08X\n",
> ipu_csi_read(csi, CSI_ACT_FRM_SIZE));
>
> +out_unlock:
> spin_unlock_irqrestore(>lock, flags);
>
> - return 0;
> + return ret;
> }
> EXPORT_SYMBOL_GPL(ipu_csi_init_interface);
>
> diff --git a/drivers/staging/media/imx/imx-media-csi.c
> b/drivers/staging/media/imx/imx-media-csi.c
> index 4acdd7ae612b..ad66f007d395 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -666,7 +666,6 @@ static int csi_setup(struct csi_priv *priv)
> struct v4l2_mbus_framefmt *infmt, *outfmt;
> const struct imx_media_pixfmt *incc;
> struct v4l2_mbus_config mbus_cfg;
> - struct v4l2_mbus_framefmt if_fmt;
> struct v4l2_rect crop;
>
> infmt = >format_mbus[CSI_SINK_PAD];
> @@ -679,22 +678,14 @@ static int csi_setup(struct csi_priv *priv)
> priv->upstream_ep.bus.parallel.flags :
> priv->upstream_ep.bus.mipi_csi2.flags;
>
> - /*
> - * we need to pass input frame to CSI interface, but
> - * with translated field type from output format
> - */
> - if_fmt = *infmt;
> - if_fmt.field = outfmt->field;
> crop = priv->crop;
>
> /*
>* if cycles is set, we need to handle this over multiple cycles as
>* generic/bayer data
>*/
> - if (is_parallel_bus(>upstream_ep) && incc->cycles) {
> - if_fmt.width *= incc->cycles;
If the input format width passed to ipu_csi_init_interface is not
multiplied by the number of cycles per pixel anymore, width in the
CSI_SENS_FRM_SIZE register will be set to the unmultiplied value from
infmt.
This breaks 779680e2e793 ("media: imx: add support for RGB565_2X8 on
parallel bus").
> + if (is_parallel_bus(>upstream_ep) && incc->cycles)
> crop.width *= incc->cycles;
> - }
>
> ipu_csi_set_window(priv->csi, );
>
> @@ -702,7 +693,7 @@ static int csi_setup(struct csi_priv *priv)
>priv->crop.width == 2 * priv->compose.width,
>priv->crop.height == 2 * priv->compose.height);
>
> - ipu_csi_init_interface(priv->csi, _cfg, _fmt);
> + ipu_csi_init_interface(priv->csi, _cfg, infmt, outfmt);
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 03/11] gpu: ipu-v3: Add planar support to interlaced scan
On Thu, 2018-10-04 at 11:53 -0700, Steve Longerbeam wrote:
> To support interlaced scan with planar formats, cpmem SLUV must
> be programmed with the correct chroma line stride. For full and
> partial planar 4:2:2 (YUV422P, NV16), chroma line stride must
> be doubled. For full and partial planar 4:2:0 (YUV420, YVU420, NV12),
> chroma line stride must _not_ be doubled, since a single chroma line
> is shared by two luma lines.
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/gpu/ipu-v3/ipu-cpmem.c | 26 +++--
> drivers/staging/media/imx/imx-ic-prpencvf.c | 3 ++-
> drivers/staging/media/imx/imx-media-csi.c | 3 ++-
> include/video/imx-ipu-v3.h | 3 ++-
> 4 files changed, 30 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c
> index a9d2501500a1..d41df8034c5b 100644
> --- a/drivers/gpu/ipu-v3/ipu-cpmem.c
> +++ b/drivers/gpu/ipu-v3/ipu-cpmem.c
> @@ -273,9 +273,10 @@ void ipu_cpmem_set_uv_offset(struct ipuv3_channel *ch,
> u32 u_off, u32 v_off)
> }
> EXPORT_SYMBOL_GPL(ipu_cpmem_set_uv_offset);
>
> -void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride)
> +void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch, int stride,
> +u32 pixelformat)
> {
> - u32 ilo, sly;
> + u32 ilo, sly, sluv;
>
> if (stride < 0) {
> stride = -stride;
> @@ -286,9 +287,30 @@ void ipu_cpmem_interlaced_scan(struct ipuv3_channel *ch,
> int stride)
>
> sly = (stride * 2) - 1;
>
> + switch (pixelformat) {
> + case V4L2_PIX_FMT_YUV420:
> + case V4L2_PIX_FMT_YVU420:
> + sluv = stride / 2 - 1;
> + break;
> + case V4L2_PIX_FMT_NV12:
> + sluv = stride - 1;
> + break;
> + case V4L2_PIX_FMT_YUV422P:
> + sluv = stride - 1;
> + break;
> + case V4L2_PIX_FMT_NV16:
> + sluv = stride * 2 - 1;
> + break;
> + default:
> + sluv = 0;
> + break;
> + }
> +
> ipu_ch_param_write_field(ch, IPU_FIELD_SO, 1);
> ipu_ch_param_write_field(ch, IPU_FIELD_ILO, ilo);
> ipu_ch_param_write_field(ch, IPU_FIELD_SLY, sly);
> + if (sluv)
> + ipu_ch_param_write_field(ch, IPU_FIELD_SLUV, sluv);
> };
> EXPORT_SYMBOL_GPL(ipu_cpmem_interlaced_scan);
[...]
Reviewed-by: Philipp Zabel
and
Acked-by: Philipp Zabel
to be merged with the rest of the series via the media tree. I'll take
care not to introduce nontrivial conflicts in imx-drm.
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v5 1/2] memory_hotplug: Free pages as higher order
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%. Modify external
providers of online callback to align with the change.
Signed-off-by: Arun KS
---
Changes since v4:
- As suggested by Michal Hocko,
- Simplify logic in online_pages_block() by using get_order().
- Seperate out removal of prefetch from __free_pages_core().
Changes since v3:
- Renamed _free_pages_boot_core -> __free_pages_core.
- Removed prefetch from __free_pages_core.
- Removed xen_online_page().
Changes since v2:
- Reuse code from __free_pages_boot_core().
Changes since v1:
- Removed prefetch().
Changes since RFC:
- Rebase.
- As suggested by Michal Hocko remove pages_per_block.
- Modifed external providers of online_page_callback.
v4: https://lore.kernel.org/patchwork/patch/995111/
v3: https://lore.kernel.org/patchwork/patch/992348/
v2: https://lore.kernel.org/patchwork/patch/991363/
v1: https://lore.kernel.org/patchwork/patch/989445/
RFC: https://lore.kernel.org/patchwork/patch/984754/
---
drivers/hv/hv_balloon.c| 6 --
drivers/xen/balloon.c | 23 +++
include/linux/memory_hotplug.h | 2 +-
mm/internal.h | 1 +
mm/memory_hotplug.c| 42 ++
mm/page_alloc.c| 8
6 files changed, 55 insertions(+), 27 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index b1b7880..c5bc0b5 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -771,7 +771,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned
long size,
}
}
-static void hv_online_page(struct page *pg)
+static int hv_online_page(struct page *pg, unsigned int order)
{
struct hv_hotadd_state *has;
unsigned long flags;
@@ -783,10 +783,12 @@ static void hv_online_page(struct page *pg)
if ((pfn < has->start_pfn) || (pfn >= has->end_pfn))
continue;
- hv_page_online_one(has, pg);
+ hv_bring_pgs_online(has, pfn, (1UL << order));
break;
}
spin_unlock_irqrestore(_device.ha_lock, flags);
+
+ return 0;
}
static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e12bb25..58ddf48 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -390,8 +390,8 @@ static enum bp_state reserve_additional_memory(void)
/*
* add_memory_resource() will call online_pages() which in its turn
-* will call xen_online_page() callback causing deadlock if we don't
-* release balloon_mutex here. Unlocking here is safe because the
+* will call xen_bring_pgs_online() callback causing deadlock if we
+* don't release balloon_mutex here. Unlocking here is safe because the
* callers drop the mutex before trying again.
*/
mutex_unlock(_mutex);
@@ -411,15 +411,22 @@ static enum bp_state reserve_additional_memory(void)
return BP_ECANCELED;
}
-static void xen_online_page(struct page *page)
+static int xen_bring_pgs_online(struct page *pg, unsigned int order)
{
- __online_page_set_limits(page);
+ unsigned long i, size = (1 << order);
+ unsigned long start_pfn = page_to_pfn(pg);
+ struct page *p;
+ pr_debug("Online %lu pages starting at pfn 0x%lx\n", size, start_pfn);
mutex_lock(_mutex);
-
- __balloon_append(page);
-
+ for (i = 0; i < size; i++) {
+ p = pfn_to_page(start_pfn + i);
+ __online_page_set_limits(p);
+ __balloon_append(p);
+ }
mutex_unlock(_mutex);
+
+ return 0;
}
static int xen_memory_notifier(struct notifier_block *nb, unsigned long val,
void *v)
@@ -744,7 +751,7 @@ static int __init balloon_init(void)
balloon_stats.max_retry_count = RETRY_UNLIMITED;
#ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
- set_online_page_callback(_online_page);
+ set_online_page_callback(_bring_pgs_online);
register_memory_notifier(_memory_nb);
register_sysctl_table(xen_root);
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 34a2822..7b04c1d 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -87,7 +87,7 @@ extern int test_pages_in_a_zone(unsigned long start_pfn,
unsigned long end_pfn,
unsigned long *valid_start, unsigned long *valid_end);
extern void __offline_isolated_pages(unsigned long, unsigned long);
-typedef void (*online_page_callback_t)(struct page *page);
+typedef int (*online_page_callback_t)(struct page *page, unsigned int order);
extern int set_online_page_callback(online_page_callback_t
[PATCH v5 2/2] mm/page_alloc: remove software prefetching in __free_pages_core
They not only increase the code footprint, they actually make things
slower rather than faster. Remove them as contemporary hardware doesn't
need any hint.
Suggested-by: Dan Williams
Signed-off-by: Arun KS
---
mm/page_alloc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7ab5274..90db431 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1258,14 +1258,10 @@ void __free_pages_core(struct page *page, unsigned int
order)
struct page *p = page;
unsigned int loop;
- prefetchw(p);
- for (loop = 0; loop < (nr_pages - 1); loop++, p++) {
- prefetchw(p + 1);
+ for (loop = 0; loop < nr_pages ; loop++, p++) {
__ClearPageReserved(p);
set_page_count(p, 0);
}
- __ClearPageReserved(p);
- set_page_count(p, 0);
page_zone(page)->managed_pages += nr_pages;
set_page_refcounted(page);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: iio: cdc: ad7150: use value copy to shorten the line length
By using the copy of channel attribute, we can now make the lines short
enough to eliminate the checkpatch.pl problem:
CHECK: Alignment should match open parenthesis
Signed-off-by: Slawomir Stepien
---
drivers/staging/iio/cdc/ad7150.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c
index d16084d7068c..e2c70063fa0f 100644
--- a/drivers/staging/iio/cdc/ad7150.c
+++ b/drivers/staging/iio/cdc/ad7150.c
@@ -102,18 +102,19 @@ static int ad7150_read_raw(struct iio_dev *indio_dev,
{
int ret;
struct ad7150_chip_info *chip = iio_priv(indio_dev);
+ int channel = chan->channel;
switch (mask) {
case IIO_CHAN_INFO_RAW:
ret = i2c_smbus_read_word_data(chip->client,
- ad7150_addresses[chan->channel][0]);
+ ad7150_addresses[channel][0]);
if (ret < 0)
return ret;
*val = swab16(ret);
return IIO_VAL_INT;
case IIO_CHAN_INFO_AVERAGE_RAW:
ret = i2c_smbus_read_word_data(chip->client,
- ad7150_addresses[chan->channel][1]);
+ ad7150_addresses[channel][1]);
if (ret < 0)
return ret;
*val = swab16(ret);
--
2.19.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: iio: cdc: ad7150: fix misaligned lines
These lines were misaligned, but the checkpatch.pl didn't indicate them as such. Signed-off-by: Slawomir Stepien --- drivers/staging/iio/cdc/ad7150.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/cdc/ad7150.c b/drivers/staging/iio/cdc/ad7150.c index e2c70063fa0f..24f74ce60f80 100644 --- a/drivers/staging/iio/cdc/ad7150.c +++ b/drivers/staging/iio/cdc/ad7150.c @@ -183,8 +183,8 @@ static int ad7150_write_event_params(struct iio_dev *indio_dev, case IIO_EV_TYPE_THRESH: value = chip->threshold[rising][chan]; return i2c_smbus_write_word_data(chip->client, - ad7150_addresses[chan][3], - swab16(value)); +ad7150_addresses[chan][3], +swab16(value)); case IIO_EV_TYPE_MAG_ADAPTIVE: sens = chip->mag_sensitivity[rising][chan]; timeout = chip->mag_timeout[rising][chan]; -- 2.19.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/2] Fix style problems in ad7150 driver
This series will fix simple style problems inside the ad7150 driver. --- Changes since v1: - Use channel value copy rather than pointer - for better readability - Change "problem" -> "problems" in cover letter description --- Slawomir Stepien (2): staging: iio: cdc: ad7150: use value copy to shorten the line length staging: iio: cdc: ad7150: fix misaligned lines drivers/staging/iio/cdc/ad7150.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) -- 2.19.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
On 04/10/2018 19:50, Michal Suchánek wrote: > On Thu, 4 Oct 2018 17:45:13 +0200 > David Hildenbrand wrote: > >> On 04/10/2018 17:28, Michal Suchánek wrote: > >>> >>> The state of the art is to determine what to do with hotplugged >>> memory in userspace based on platform and virtualization type. >> >> Exactly. >> >>> >>> Changing the default to depend on the driver that added the memory >>> rather than platform type should solve the issue of VMs growing >>> different types of memory device emulation. >> >> Yes, my original proposal (this patch) was to handle it in the kernel >> for known types. But as we learned, there might be some use cases that >> might still require to make a decision in user space. >> >> So providing the user space either with some type hint (auto-online >> vs. standby) or the driver that added it (system vs. hyper-v ...) >> would solve the issue. > > Is that not available in the udev event? > Not that I am aware. Memory blocks "devices" have no drivers. ls -la /sys/devices/system/memory/memory0/subsystem/drivers total 0 (add_memory()/add_memory_resource() creates the memory block devices when called from a driver) > Thanks > > Michal > -- Thanks, David / dhildenb ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] memory_hotplug: Free pages as higher order
On 2018-10-04 20:21, Michal Hocko wrote:
On Wed 03-10-18 19:09:39, Arun KS wrote:
[...]
+static int online_pages_blocks(unsigned long start, unsigned long
nr_pages)
+{
+ unsigned long end = start + nr_pages;
+ int order, ret, onlined_pages = 0;
+
+ while (start < end) {
+ order = min(MAX_ORDER - 1UL, __ffs(start));
+
+ while (start + (1UL << order) > end)
+ order--;
this really made me scratch my head. Wouldn't it be much simpler to do
the following?
order = min(MAX_ORDER - 1, get_order(end - start))?
Yes. Much better. Will change to,
order = min(MAX_ORDER - 1,
get_order(PFN_PHYS(end) - PFN_PHYS(start)));
+
+ ret = (*online_page_callback)(pfn_to_page(start), order);
+ if (!ret)
+ onlined_pages += (1UL << order);
+ else if (ret > 0)
+ onlined_pages += ret;
+
+ start += (1UL << order);
+ }
+ return onlined_pages;
}
[...]
-static void __init __free_pages_boot_core(struct page *page, unsigned
int order)
+void __free_pages_core(struct page *page, unsigned int order)
{
unsigned int nr_pages = 1 << order;
struct page *p = page;
unsigned int loop;
- prefetchw(p);
- for (loop = 0; loop < (nr_pages - 1); loop++, p++) {
- prefetchw(p + 1);
+ for (loop = 0; loop < nr_pages; loop++, p++) {
__ClearPageReserved(p);
set_page_count(p, 0);
}
- __ClearPageReserved(p);
- set_page_count(p, 0);
page_zone(page)->managed_pages += nr_pages;
set_page_refcounted(page);
I think this is wort a separate patch as it is unrelated to the patch.
Sure. Will split the patch.
Regards,
Arun
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock
On Thu, Sep 27, 2018 at 11:25:50AM +0200, David Hildenbrand wrote: > Reviewed-by: Pavel Tatashin > Reviewed-by: Rafael J. Wysocki > Reviewed-by: Rashmica Gupta > Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador -- Oscar Salvador SUSE L3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock
On Thu, Sep 27, 2018 at 11:25:49AM +0200, David Hildenbrand wrote: > Reviewed-by: Pavel Tatashin > Reviewed-by: Rafael J. Wysocki > Reviewed-by: Rashmica Gupta > Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador -- Oscar Salvador SUSE L3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 6/6] memory-hotplug.txt: Add some details about locking internals
On Thu, Sep 27, 2018 at 11:25:54AM +0200, David Hildenbrand wrote: > Cc: Jonathan Corbet > Cc: Michal Hocko > Cc: Andrew Morton > Reviewed-by: Pavel Tatashin > Reviewed-by: Rashmica Gupta > Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador -- Oscar Salvador SUSE L3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock
On Thu, Sep 27, 2018 at 11:25:51AM +0200, David Hildenbrand wrote: > Reviewed-by: Pavel Tatashin > Reviewed-by: Rashmica Gupta > Signed-off-by: David Hildenbrand Reviewed-by: Oscar Salvador -- Oscar Salvador SUSE L3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
