Re: [GIT PULL] Staging/IIO driver updates for 5.13-rc1
Hi Greg, On Mon, 26 Apr 2021 14:46:10 +0200 Greg KH wrote: > > All of these have been in linux-next for a while with no reported > issues. There was just these: https://lore.kernel.org/linux-next/20210329165525.32d51...@canb.auug.org.au/ https://lore.kernel.org/linux-next/20210331175151.67fcf...@canb.auug.org.au/ (the scmi tree commit mentioned in the latter is now in the arm-soc tree) Not issues as such, but worth mentioning the conflicts and resolutions. -- Cheers, Stephen Rothwell pgpGUzVR9OafJ.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: emxx_udc: Fix incorrectly defined global
Hi Kumar, On Sun, 7 Feb 2021 05:30:31 +0530 Kumar Kartikeya Dwivedi wrote: > > The global gpio_desc pointer and int were defined in the header, > instead put the definitions in the translation unit and add an extern > declaration for consumers of the header (currently only one, which is > perhaps why the linker didn't complain about symbol collisions). > > This fixes sparse related warnings for this driver: > drivers/staging/emxx_udc/emxx_udc.c: note: in included file: > drivers/staging/emxx_udc/emxx_udc.h:23:18: warning: symbol 'vbus_gpio' was > not declared. Should it be static? > drivers/staging/emxx_udc/emxx_udc.h:24:5: warning: symbol 'vbus_irq' was not > declared. Should it be static? > > Signed-off-by: Kumar Kartikeya Dwivedi Given that drivers/staging/emxx_udc/emxx_udc.h is only included by drivers/staging/emxx_udc/emxx_udc.c, shouldn't these variables just be declared static in emxx_udc.c and removed from emxx_udc.h? > --- > drivers/staging/emxx_udc/emxx_udc.c | 3 +++ > drivers/staging/emxx_udc/emxx_udc.h | 4 ++-- > 2 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/emxx_udc/emxx_udc.c > b/drivers/staging/emxx_udc/emxx_udc.c > index a30b4f5b1..6983c3e31 100644 > --- a/drivers/staging/emxx_udc/emxx_udc.c > +++ b/drivers/staging/emxx_udc/emxx_udc.c > @@ -34,6 +34,9 @@ > #define DRIVER_DESC "EMXX UDC driver" > #define DMA_ADDR_INVALID(~(dma_addr_t)0) > > +struct gpio_desc *vbus_gpio; > +int vbus_irq; > + > static const chardriver_name[] = "emxx_udc"; > static const chardriver_desc[] = DRIVER_DESC; > > diff --git a/drivers/staging/emxx_udc/emxx_udc.h > b/drivers/staging/emxx_udc/emxx_udc.h > index bca614d69..b3c4ccbe5 100644 > --- a/drivers/staging/emxx_udc/emxx_udc.h > +++ b/drivers/staging/emxx_udc/emxx_udc.h > @@ -20,8 +20,8 @@ > /* below hacked up for staging integration */ > #define GPIO_VBUS 0 /* GPIO_P153 on KZM9D */ > #define INT_VBUS 0 /* IRQ for GPIO_P153 */ > -struct gpio_desc *vbus_gpio; > -int vbus_irq; > +extern struct gpio_desc *vbus_gpio; > +extern int vbus_irq; > > /* Board dependence(Wait) */ > > -- > 2.29.2 > -- Cheers, Stephen Rothwell pgpqfbjlwMVnJ.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver changes for 5.11-rc1
Hi Greg, On Tue, 15 Dec 2020 11:17:49 +0100 Greg KH wrote: > > All have been in linux-next for a while with no reported issues. There is, however, a semantic conflict with a commit that is now in Linus' tree: https://lore.kernel.org/lkml/20201207164601.2b9ce...@canb.auug.org.au/ -- Cheers, Stephen Rothwell pgp7wygbVYpNc.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: mmotm 2020-03-28-22-17 uploaded (staging/octeon/)
Hi Randy, On Sun, 29 Mar 2020 09:12:31 -0700 Randy Dunlap wrote: > > On 3/28/20 10:18 PM, a...@linux-foundation.org wrote: > > The mm-of-the-moment snapshot 2020-03-28-22-17 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > > more than once a week. > > > > You will need quilt to apply these patches to the latest Linus release (5.x > > or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > > http://ozlabs.org/~akpm/mmotm/series > > > on i386 or x86_64: > > ../drivers/staging/octeon/ethernet-tx.c: In function ‘cvm_oct_xmit’: > ../drivers/staging/octeon/ethernet-tx.c:358:2: error: implicit declaration of > function ‘skb_reset_tc’; did you mean ‘skb_reserve’? > [-Werror=implicit-function-declaration] > skb_reset_tc(skb); > ^~~~ > > It looks like this inline function has been removed from > . > > > Looks like it should be this change: > > - skb_reset_tc(skb); > + skb_reset_redirect(skb); I applied the above as a merge resolution patch for the staging tree merge today, as the inline removal was a late change to Linus' tree. -- Cheers, Stephen Rothwell pgp67jcLOmpjj.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] erofs: move erofs out of staging
Hi Gao, On Wed, 7 Aug 2019 01:02:58 +0800 Gao Xiang wrote: > > On Wed, Aug 07, 2019 at 01:34:23AM +1000, Stephen Rothwell wrote: > > > > One small suggestion: just remove the file names from the comments at > > the top of the files rather than change them to reflect that they have > > moved. We can usually tell the name of a file by its name :-) > > Thanks for your reply :) > > For this part, EROFS initially followed what ext4, f2fs, even fsverity do, > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/ext4/namei.c > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/f2fs/namei.c > https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/tree/fs/verity/verify.c?h=fsverity > > I think I can remove these filenames as you suggested in the next version. > I thought these are some common practice and there is no obvious right or > wrong of this kind of stuffs. Fair enough. -- Cheers, Stephen Rothwell pgpdz4S5FTKOx.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] erofs: move erofs out of staging
Hi Gao, One small suggestion: just remove the file names from the comments at the top of the files rather than change them to reflect that they have moved. We can usually tell the name of a file by its name :-) -- Cheers, Stephen Rothwell pgpeto9QVOyjN.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 01/24] erofs: add on-disk layout
Hi Gao, On Mon, 22 Jul 2019 10:50:20 +0800 Gao Xiang wrote: > > diff --git a/fs/erofs/erofs_fs.h b/fs/erofs/erofs_fs.h > new file mode 100644 > index ..e418725abfd6 > --- /dev/null > +++ b/fs/erofs/erofs_fs.h > @@ -0,0 +1,316 @@ > +/* SPDX-License-Identifier: GPL-2.0 OR Apache-2.0 */ I think the preferred tag is now GPL-2.0-only (assuming that is what is intended). -- Cheers, Stephen Rothwell pgpGO1xuMQjKg.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging: erofs: disable compiling temporarile"
Hi Chao, On Wed, 12 Sep 2018 15:19:16 +0800 Chao Yu wrote: > > To make sure, did -next tree enable erofs compiling now? Yes, from yesterday. > Xiang has made two patches to fix integration issue with other vfs changes, > and Greg and David have already picked them in their tree. > > staging: erofs: rename superblock flags (MS_xyz -> SB_xyz) > staging: erofs: update .mount and .remount_sb I noticed, thanks. -- Cheers, Stephen Rothwell pgphPCaln6Mel.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Revert "staging: erofs: disable compiling temporarile"
Hi all,
On Wed, 29 Aug 2018 09:44:03 +1000 Stephen Rothwell
wrote:
>
> On Tue, 28 Aug 2018 22:13:02 +0800 Chao Yu wrote:
> >
> > On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
> > > On Tue, Aug 28, 2018 at 04:56:43PM +0800, Chao Yu wrote:
> > >>
> > >> On 2018/8/28 14:28, Gao Xiang wrote:
> > >>>
> > >>> On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
> > >>>> On Tue, Aug 28, 2018 at 11:39:48AM +0800, Gao Xiang wrote:
> > >>>>> This reverts commit 156c3df8d4db4e693c062978186f44079413d74d.
> > >>>>>
> > >>>>> Since XArray and the new mount apis aren't merged in 4.19-rc1
> > >>>>> merge window, the BROKEN mark can be reverted directly without
> > >>>>> any problems.
> > >>>>>
> > >>>>> Fixes: 156c3df8d4db ("staging: erofs: disable compiling temporarile")
> > >>>>> Cc: Matthew Wilcox
> > >>>>> Cc: David Howells
> > >>>>> Reviewed-by: Chao Yu
> > >>>>> Signed-off-by: Gao Xiang
> > >>>>> ---
> > >>>>>
> > >>>>> Hi Greg,
> > >>>>>
> > >>>>> Could you please apply this patch to enable EROFS from 4.19-rc2,
> > >>>>> thanks...
> > >>>>>
> > >>>>> p.s. We would like to provide a more stable EROFS when linux-4.19 is
> > >>>>> out,
> > >>>>> and there are also two patchsets (the one is already sent out
> > >>>>> by Chao
> > >>>>> and me, the other is previewing in linux-erofs mailing list and
> > >>>>> it will
> > >>>>> be sent out after gathering enough testdata and feedback from
> > >>>>> community
> > >>>>> and carefully reviewed), could you also please consider
> > >>>>> applying these
> > >>>>> two patchsets in the later 4.19-rc (both >2, or the first
> > >>>>> patchset
> > >>>>> could be in rc2 in advance) if it is convenient to do so, or
> > >>>>> the next
> > >>>>> 4.20 is also ok...
> > >>>>>
> > >>>>> LINK:
> > >>>>> https://lore.kernel.org/lkml/20180821144937.20555-1-c...@kernel.org/
> > >>>>>
> > >>>>> https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxian...@huawei.com/
> > >>>>>
> > >>>>
> > >>>> I applied those patch sets to my -next branch already, right? So
> > >>>> those
> > >>>
> > >>> Yes, Thank you for applying those patches. :)
> > >>>
> > >>>> would be going into 4.20-rc1, it is time now for "bugfixes only" for
> > >>>> 4.19-final.
> > >>>>
> > >>>> So perhaps we should just leave it as "BROKEN" for now for 4.19 and add
> > >>>> this to my tree now and let people work on it for the next few months
> > >>>> in
> > >>
> > >> I'm worry about that once we plan to reenable erofs in next x.xx-rc1, in
> > >> the
> > >> merge window, if there are any other features change common api or
> > >> structure in
> > >> vfs/mm/block, but related patch didn't cover erofs, that would make
> > >> conflict
> > >> with erofs.
> > >>
> > >> So if that happens, we can just reminder them to cover erofs? or we
> > >> should
> > >> handle this by just delay removing 'BROKEN' state?
> > >>
> > >> Thanks,
> > >>
> > >>>> linux-next so that 4.20 has a solid base to start with?
> > >>>>
> > >>>
> > >>> EROFS is be marked as "BROKEN" just because of conflict with
> > >>> XArray and the new mount apis, as Stephen Rothwell suggested in
> > >>>
> > >>> https://lore.kernel.org/lkml/20180802010705.24a72...@canb.auug.org.au/
> > >>>
> > >>>> It might be easiest for Greg to add the disabling CONFIG_EROFS_FS patch
> > >>>> to the staging tree itself for his first pull request during t
Re: [PATCH] Revert "staging: erofs: disable compiling temporarile"
Hi all,
On Tue, 28 Aug 2018 22:13:02 +0800 Chao Yu wrote:
>
> On 2018/8/28 21:05, Greg Kroah-Hartman wrote:
> > On Tue, Aug 28, 2018 at 04:56:43PM +0800, Chao Yu wrote:
> >> Hi Greg,
> >>
> >> On 2018/8/28 14:28, Gao Xiang wrote:
> >>> Hi Greg,
> >>>
> >>> On 2018/8/28 13:44, Greg Kroah-Hartman wrote:
> >>>> On Tue, Aug 28, 2018 at 11:39:48AM +0800, Gao Xiang wrote:
> >>>>> This reverts commit 156c3df8d4db4e693c062978186f44079413d74d.
> >>>>>
> >>>>> Since XArray and the new mount apis aren't merged in 4.19-rc1
> >>>>> merge window, the BROKEN mark can be reverted directly without
> >>>>> any problems.
> >>>>>
> >>>>> Fixes: 156c3df8d4db ("staging: erofs: disable compiling temporarile")
> >>>>> Cc: Matthew Wilcox
> >>>>> Cc: David Howells
> >>>>> Reviewed-by: Chao Yu
> >>>>> Signed-off-by: Gao Xiang
> >>>>> ---
> >>>>>
> >>>>> Hi Greg,
> >>>>>
> >>>>> Could you please apply this patch to enable EROFS from 4.19-rc2,
> >>>>> thanks...
> >>>>>
> >>>>> p.s. We would like to provide a more stable EROFS when linux-4.19 is
> >>>>> out,
> >>>>> and there are also two patchsets (the one is already sent out by
> >>>>> Chao
> >>>>> and me, the other is previewing in linux-erofs mailing list and
> >>>>> it will
> >>>>> be sent out after gathering enough testdata and feedback from
> >>>>> community
> >>>>> and carefully reviewed), could you also please consider applying
> >>>>> these
> >>>>> two patchsets in the later 4.19-rc (both >2, or the first patchset
> >>>>> could be in rc2 in advance) if it is convenient to do so, or the
> >>>>> next
> >>>>> 4.20 is also ok...
> >>>>>
> >>>>> LINK:
> >>>>> https://lore.kernel.org/lkml/20180821144937.20555-1-c...@kernel.org/
> >>>>>
> >>>>> https://lore.kernel.org/lkml/1535076160-99466-1-git-send-email-gaoxian...@huawei.com/
> >>>>>
> >>>>
> >>>> I applied those patch sets to my -next branch already, right? So those
> >>>
> >>> Yes, Thank you for applying those patches. :)
> >>>
> >>>> would be going into 4.20-rc1, it is time now for "bugfixes only" for
> >>>> 4.19-final.
> >>>>
> >>>> So perhaps we should just leave it as "BROKEN" for now for 4.19 and add
> >>>> this to my tree now and let people work on it for the next few months in
> >>>>
> >>
> >> I'm worry about that once we plan to reenable erofs in next x.xx-rc1, in
> >> the
> >> merge window, if there are any other features change common api or
> >> structure in
> >> vfs/mm/block, but related patch didn't cover erofs, that would make
> >> conflict
> >> with erofs.
> >>
> >> So if that happens, we can just reminder them to cover erofs? or we should
> >> handle this by just delay removing 'BROKEN' state?
> >>
> >> Thanks,
> >>
> >>>> linux-next so that 4.20 has a solid base to start with?
> >>>>
> >>>
> >>> EROFS is be marked as "BROKEN" just because of conflict with
> >>> XArray and the new mount apis, as Stephen Rothwell suggested in
> >>>
> >>> https://lore.kernel.org/lkml/20180802010705.24a72...@canb.auug.org.au/
> >>>
> >>>> It might be easiest for Greg to add the disabling CONFIG_EROFS_FS patch
> >>>> to the staging tree itself for his first pull request during the merge
> >>>> window and then send a second pull request (after the vfs and maybe the
> >>>> Xarray stuff has been merged by Linus) with these patches followed by a
> >>>> revert of the disabling patch.
> >>>
> >>> But these two features was still discussing in the mailing list even at
> >>> the
> >>> last time of 4.19-rc1 merge window. I cannot decide whether they were
> >>> eventually
> >>> get merged in 4.19
Re: [PATCH v2] staging: emxx_udc: allow modular build
r = {
.probe = nbu2ss_drv_probe,
.shutdown = nbu2ss_drv_shutdown,
+ .remove = nbu2ss_drv_remove,
.suspend= nbu2ss_drv_suspend,
.resume = nbu2ss_drv_resume,
.driver = {
- .name = driver_name,
- .suppress_bind_attrs= true,
+ .name = driver_name,
},
};
-builtin_platform_driver(udc_driver);
+module_platform_driver(udc_driver);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_AUTHOR("Renesas Electronics Corporation");
+MODULE_LICENSE("GPL");
--
Cheers,
Stephen Rothwell
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/rdma/hfi1: Fix for module parameter hdrq_entsize when it's 0
Hi Mike, On Thu, 10 Dec 2015 16:02:49 -0500 Mike Marciniszyn wrote: > > From: Sebastian Sanchez linux-nxt doesn't really need to be informed about random changes to stuff in staging unless it fixes a linux-next specific problem. -- Cheers, Stephen Rothwells...@canb.auug.org.au ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: linux-next: Tree for Aug 17 (staging/hfi1)
Hi Mike, On Tue, 18 Aug 2015 14:24:32 + "Marciniszyn, Mike" wrote: > > > A: these and other similar errors: > > > > In file included from ../drivers/staging/hfi1/chip.c:61:0: > > ../drivers/staging/hfi1/chip.c: In function â__hfi1_trace_LINKVERBâ: > > ../drivers/staging/hfi1/trace.h:1357:20: error: function > > â__hfi1_trace_LINKVERBâ can never be inlined because it uses variable > > argument lists static inline void __hfi1_trace_##fn(const char *func, char > > *fmt, ...) \ > > > > This was corrected with > https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg27221.html, which > I think Doug has picked up. > > Doug, Randy, Stephen how do we want to handle fixing drivers/staging/hfi1 via > the staging list vs. the linux-rdma list? Since the problem was only introduced in the rdma tree (and the trace.h file only exists there), it needs to be fixed there. -- Cheers, Stephen Rothwells...@canb.auug.org.au ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: board: Kconfig: Let STAGING_BOARD depend on CLKDEV_LOOKUP
Hi Paul, On Mon, 6 Jul 2015 09:42:47 -0400 Paul Gortmaker wrote: > > [Re: [PATCH] staging: board: Kconfig: Let STAGING_BOARD depend on > CLKDEV_LOOKUP] On 06/07/2015 (Mon 08:48) Stephen Rothwell wrote: > > > On Sun, 5 Jul 2015 18:57:51 +0200 Geert Uytterhoeven > > wrote: > > > > > > On Sat, Jul 4, 2015 at 11:35 PM, Chen Gang > > > wrote: > > > > It needs clk_add_alias() from clk drivers, which is implemented in > > > > "drivers/clk/clkdev.c" which depends on CLKDEV_LOOKUP. > > > > > > > > Normally, archs and clk driver its own will decide whether select > > > > CLKDEV_LOOKUP, and common drivers will decide whether depend on it. > > > > > > > > The related error (with allmodconfig under cris for next-20150702): > > > > > > > > drivers/built-in.o: In function `board_staging_register_clock': > > > > drivers/staging/board/board.c:131: undefined reference to > > > > `clk_add_alias' > > > > > > > > > > > > Signed-off-by: Chen Gang > > > > > > Fix available for the last 15 days: > > > > > > https://lkml.org/lkml/2015/6/20/215 > > > > I added Chen's patch to my fixes tree today (only because I couldn't > > easily find a copy of Paul's patch (sorry Paul) i.e. how does one get a > > full mail message from lkml.org? Or Geert, maybe that is not the best > > place to link to. > > I have had reasonable success pulling stuff out of lkml patchworks: > > https://patchwork.kernel.org/patch/6651831/ > > BTW, Chen's patch is missing the OF_IRQ dependency Geert found in > his build coverage; I'd folded that into the v2 above, figuring > that is what he'd desired I do with it. I have replaced Chen's patch with your patch in my fixes tree ... hopefully it won;t need to be there long. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpbvCvKGzZh9.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: board: Kconfig: Let STAGING_BOARD depend on CLKDEV_LOOKUP
Hi all, On Sun, 5 Jul 2015 18:57:51 +0200 Geert Uytterhoeven wrote: > > On Sat, Jul 4, 2015 at 11:35 PM, Chen Gang > wrote: > > It needs clk_add_alias() from clk drivers, which is implemented in > > "drivers/clk/clkdev.c" which depends on CLKDEV_LOOKUP. > > > > Normally, archs and clk driver its own will decide whether select > > CLKDEV_LOOKUP, and common drivers will decide whether depend on it. > > > > The related error (with allmodconfig under cris for next-20150702): > > > > drivers/built-in.o: In function `board_staging_register_clock': > > drivers/staging/board/board.c:131: undefined reference to `clk_add_alias' > > > > > > Signed-off-by: Chen Gang > > Fix available for the last 15 days: > > https://lkml.org/lkml/2015/6/20/215 I added Chen's patch to my fixes tree today (only because I couldn't easily find a copy of Paul's patch (sorry Paul) i.e. how does one get a full mail message from lkml.org? Or Geert, maybe that is not the best place to link to. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpJyhd41fnMB.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h
Hi Dave, On Mon, 01 Jun 2015 15:59:31 -0700 (PDT) David Miller wrote: > > From: Stephen Rothwell > Date: Fri, 29 May 2015 19:18:47 +1000 > > > Nothing in asm/io.h uses anything from vmalloc.h, so remove the include > > and fix up the build problems in an allmodconfig (64 bit and 32 bit) > > build. > > > > This may be the place where x86 builds get vmalloc.h implicitly included > > and that tends to hide places where vmalloc() et al are added to files > > but the include of vmalloc.h is forgotten. > > > ... > > Suggested-by: David Miller > > Signed-off-by: Stephen Rothwell > > With the follow-on allnoconfig fixes: > > Acked-by: David S. Miller Noted, thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpvhmUBWAOxR.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h
Hi Takashi, On Fri, 29 May 2015 14:43:14 +0200 Takashi Iwai wrote: > > For the sound bits, > Acked-by: Takashi Iwai Thanks, noted. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpcAWfsHc9aM.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h
Hi Ingo, On Fri, 29 May 2015 11:21:05 +0200 Ingo Molnar wrote: > > Good idea. > > Acked-by: Ingo Molnar Thanks. > Please also test x86 allnoconfig and defconfig 32/64, that tends to unearth > the > remaining places. People doing randconfig testing will find the rest. Good idea. the allnoconfigs produced this further patch. I will squash it into the original. The defconfigs built ok. From: Stephen Rothwell Date: Fri, 29 May 2015 22:01:41 +1000 Subject: [PATCH] x86: more fixes for removing vmalloc.h fron asm/io.h Signed-off-by: Stephen Rothwell --- arch/x86/include/asm/io.h | 1 + include/linux/io.h| 1 + 2 files changed, 2 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 5791e7ace9db..2a3543a4db1d 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -40,6 +40,7 @@ #include #include #include +#include #define build_mmio_read(name, size, type, reg, barrier) \ static inline type name(const volatile void __iomem *addr) \ diff --git a/include/linux/io.h b/include/linux/io.h index 986f2bffea1e..cb753a2450b8 100644 --- a/include/linux/io.h +++ b/include/linux/io.h @@ -19,6 +19,7 @@ #define _LINUX_IO_H #include +#include #include #include -- 2.1.4 -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp3xKtZ8kJk0.pgp Description: OpenPGP digital signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFC][PATCH] x86: remove vmalloc.h from asm/io.h
Nothing in asm/io.h uses anything from vmalloc.h, so remove the include and fix up the build problems in an allmodconfig (64 bit and 32 bit) build. This may be the place where x86 builds get vmalloc.h implicitly included and that tends to hide places where vmalloc() et al are added to files but the include of vmalloc.h is forgotten. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Cc: Konrad Rzeszutek Wilk Cc: Boris Ostrovsky Cc: David Vrabel Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Tony Luck Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Kristen Carlson Accardi Cc: Viresh Kumar Cc: Vinod Koul Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Hiral Patel Cc: Suma Ramars Cc: Brian Uchino Cc: "James E.J. Bottomley" Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Andrew Morton Suggested-by: David Miller Signed-off-by: Stephen Rothwell --- Based in Linus' tree of today. There are probably more places that need vmalloc.h included, but this passes 64 bit and 32 bit allmodconfig builds, so is a place to start. Dave Miller suggested that I start this journey. arch/x86/include/asm/io.h | 2 -- arch/x86/kernel/crash.c| 1 + arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/mm/pageattr-test.c| 1 + arch/x86/mm/pageattr.c | 1 + arch/x86/xen/p2m.c | 1 + drivers/acpi/apei/erst.c | 1 + drivers/cpufreq/intel_pstate.c | 1 + drivers/dma/mic_x100_dma.c | 1 + drivers/net/hyperv/netvsc.c| 1 + drivers/net/hyperv/rndis_filter.c | 1 + drivers/scsi/fnic/fnic_debugfs.c | 1 + drivers/scsi/fnic/fnic_trace.c | 1 + sound/pci/asihpi/hpioctl.c | 1 + 14 files changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 34a5b93704d3..5791e7ace9db 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -197,8 +197,6 @@ extern void set_iounmap_nonlazy(void); #include -#include - /* * Convert a virtual cached pointer to an uncached pointer */ diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c index c76d3e37c6e1..e068d6683dba 100644 --- a/arch/x86/kernel/crash.c +++ b/arch/x86/kernel/crash.c @@ -22,6 +22,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index 415480d3ea84..11546b462fa6 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/mm/pageattr-test.c b/arch/x86/mm/pageattr-test.c index 6629f397b467..8ff686aa7e8c 100644 --- a/arch/x86/mm/pageattr-test.c +++ b/arch/x86/mm/pageattr-test.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 89af288ec674..bedfc794b4ba 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c index b47124d4cd67..8b7f18e200aa 100644 --- a/arch/x86/xen/p2m.c +++ b/arch/x86/xen/p2m.c @@ -67,6 +67,7 @@ #include #include #include +#include #include #include diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c index ed65e9c4b5b0..3670bbab57a3 100644 --- a/drivers/acpi/apei/erst.c +++ b/drivers/acpi/apei/erst.c @@ -35,6 +35,7 @@ #include #include #include +#include #include #include "apei-internal.h" diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index 6414661ac1c4..2ba53f4f6af2 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include diff --git a/drivers/dma/mic_x100_dma.c b/drivers/dma/mic_x100_dma.c index 6de2e677be04..74d9db05a5ad 100644 --- a/drivers/dma/mic_x100_dma.c +++ b/drivers/dma/mic_x100_dma.c @@ -22,6 +22,7 @@ #include #include #include +#include #include "mic_x100_dma.h" diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c index ea091bc5ff09..1e09243d5449 100644 --- a/drivers/net/hyperv/netvsc.c +++ b/drivers/net/hyperv/netvsc.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include "hyperv_net.h" diff --git a/drivers/net/hyperv/rndis_filter.c b/drivers/net/hyperv/rndis_filter.c index 9118cea91882..35a482d526d9 100644 --- a/drivers/net/hyperv/rndis_filter.c +++ b/drivers/net/hyperv/rndis_filter.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "hyperv_net.h" diff --git a/drivers/scsi/fnic/fnic_debugfs.c b/drivers/scsi/fnic/fnic_debugfs.c index 5980c10c734d..d6498fabe628 100644 --- a/drivers/scsi/fnic/fnic_debugfs.c +++
Re: [PATCH] gpio: removes all usage of gpiochip_remove retval
Hi abdoulaye, On Fri, 30 May 2014 01:16:22 +0200 abdoulaye berthe wrote: > > The aim of this patch is to make gpiochip_remove() behavior consistent, > especially when issuing a remove request while the chipio chip is > still requested. A patch has been submitted to change the return value of > gpiochip_remove() from int to void. This one updates users of the return > value: Then you need to keep these two patch in a series with this one first to make sure that the other patch is not applied without this one. And you should add the above explanation to the changelog for this patch. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH linux-next] imx-drm: imx-tve: remove unused variable
Hi all,
On Sun, 25 May 2014 15:12:35 -0700 Greg Kroah-Hartman
wrote:
>
> On Sun, May 25, 2014 at 11:54:14PM +0200, Vincent Stehlé wrote:
> > Commit f9b0e251dfbf 'drm: make mode_valid callback optional' left variable
> > ret
> > unused; remove it.
> >
> > This fixes the following compilation warning:
> >
> > drivers/staging/imx-drm/imx-tve.c: In function
> > ‘imx_tve_connector_mode_valid’:
> > drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’
> > [-Wunused-variable]
>
> It doesn't apply to my tree :(
Yeah, commit f9b0e251dfbf 'drm: make mode_valid callback optional' is
in the drm tree, so this patch needs to go to Dave Airlie (cc'd).
Though Daniel Vetter may want to send it on.
For Dave's benefit, here is the patch again:
From: Vincent Stehlé
Subject: [PATCH linux-next] imx-drm: imx-tve: remove unused variable
Date: Sun, 25 May 2014 23:54:14 +0200
Commit f9b0e251dfbf 'drm: make mode_valid callback optional' left variable ret
unused; remove it.
This fixes the following compilation warning:
drivers/staging/imx-drm/imx-tve.c: In function ‘imx_tve_connector_mode_valid’:
drivers/staging/imx-drm/imx-tve.c:252:6: warning: unused variable ‘ret’
[-Wunused-variable]
Signed-off-by: Vincent Stehlé
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
---
Hi,
This can be seen with e.g. linux next-20140523 and arm allmodconfig.
Best regards,
V.
drivers/staging/imx-drm/imx-tve.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/imx-drm/imx-tve.c
b/drivers/staging/imx-drm/imx-tve.c
index 3e8b0a1..4caef2b1 100644
--- a/drivers/staging/imx-drm/imx-tve.c
+++ b/drivers/staging/imx-drm/imx-tve.c
@@ -249,7 +249,6 @@ static int imx_tve_connector_mode_valid(struct
drm_connector *connector,
{
struct imx_tve *tve = con_to_tve(connector);
unsigned long rate;
- int ret;
/* pixel clock with 2x oversampling */
rate = clk_round_rate(tve->clk, 2000UL * mode->clock) / 2000;
--
2.0.0.rc2
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next,v3] hyperv: Add support for virtual Receive Side Scaling (vRSS)
On Thu, 20 Mar 2014 00:56:05 +0300 Sergei Shtylyov wrote: > > On 03/19/2014 11:40 PM, David Miller wrote: > > >> +extern u8 netvsc_hash_key[]; > > > We no longer use extern in header file function declarations. > > Wait, this is a variable declaration. :-) And the need for the extern on variable declarations was one reason I gave for not removing it from the function declarations (consistency is good :-)). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpCLASopPHsO.pgp Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
linux-next: build failure after merge of the wireless-next tree
Hi John,
[I started by reverting commit 161d78555435 "Revert "Staging: rtl8812ae:
remove modules field of rate_control_ops""]
After merging the wireless-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/staging/wlan-ng/p80211netdev.c:91:0:
drivers/staging/wlan-ng/cfg80211.c: In function 'prism2_scan':
drivers/staging/wlan-ng/cfg80211.c:419:10: error: implicit declaration of
function 'ieee80211_dsss_chan_to_freq' [-Werror=implicit-function-declaration]
ieee80211_dsss_chan_to_freq(msg2.dschannel.data)),
^
Caused by commit 3ebe8e257307 ("ieee80211: remove function ieee80211_
{dsss_chan_to_freq, freq_to_dsss_chan}").
I disabled the staging tree driver like this:
From: Stephen Rothwell
Date: Thu, 6 Mar 2014 13:17:16 +1100
Subject: [PATCH] staging: disable Prism2.5/3 USB driver
it is currently broken by changes in the wireless-next tree
Signed-off-by: Stephen Rothwell
---
drivers/staging/wlan-ng/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/wlan-ng/Kconfig b/drivers/staging/wlan-ng/Kconfig
index 426d4efbabc3..56caa46e4791 100644
--- a/drivers/staging/wlan-ng/Kconfig
+++ b/drivers/staging/wlan-ng/Kconfig
@@ -1,6 +1,7 @@
config PRISM2_USB
tristate "Prism2.5/3 USB driver"
depends on WLAN && USB && CFG80211
+ depends on BROKEN
select WIRELESS_EXT
select WEXT_PRIV
default n
--
1.9.0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpK6wt6ONzcH.pgp
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
