* linux-next: build failure after merge of the staging tree
@ 2017-04-18 5:53 Stephen Rothwell
2017-04-18 7:04 ` Johannes Berg
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-04-18 5:53 UTC (permalink / raw)
To: Greg KH, Johannes Berg
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Hans de Goede
Hi all,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.change_virtual_intf = cfg80211_rtw_change_iface,
^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3426:25: note: (near initialization for 'rtw_cfg80211_ops.change_virtual_intf')
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3445:22: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.add_virtual_intf = cfg80211_rtw_add_virtual_intf,
^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3445:22: note: (near initialization for 'rtw_cfg80211_ops.add_virtual_intf')
Caused by commit
554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
interacting with commit
818a986e4eba ("cfg80211: move add/change interface monitor flags into params")
from the mac80211-next tree.
I have added the following merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 Apr 2017 15:43:43 +1000
Subject: [PATCH] staging: merge fix for add/change_virtual-intf API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 52aa65bfd890..f17f4fbd3396 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1310,7 +1310,7 @@ extern int netdev_open(struct net_device *pnetdev);
static int cfg80211_rtw_change_iface(struct wiphy *wiphy,
struct net_device *ndev,
- enum nl80211_iftype type, u32 *flags,
+ enum nl80211_iftype type,
struct vif_params *params)
{
enum nl80211_iftype old_type;
@@ -2711,7 +2711,7 @@ static struct wireless_dev *
struct wiphy *wiphy,
const char *name,
unsigned char name_assign_type,
- enum nl80211_iftype type, u32 *flags, struct vif_params *params)
+ enum nl80211_iftype type, struct vif_params *params)
{
int ret = 0;
struct net_device* ndev = NULL;
--
2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-18 5:53 linux-next: build failure after merge of the staging tree Stephen Rothwell
@ 2017-04-18 7:04 ` Johannes Berg
0 siblings, 0 replies; 143+ messages in thread
From: Johannes Berg @ 2017-04-18 7:04 UTC (permalink / raw)
To: Stephen Rothwell, Greg KH
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Hans de Goede
On Tue, 2017-04-18 at 15:53 +1000, Stephen Rothwell wrote:
> Caused by commit
>
> 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Oh, another new driver :)
> interacting with commit
>
> 818a986e4eba ("cfg80211: move add/change interface monitor flags
> into params")
>
> from the mac80211-next tree.
>
> I have added the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 18 Apr 2017 15:43:43 +1000
> Subject: [PATCH] staging: merge fix for add/change_virtual-intf API
> change
That looks good, evidently it doesn't care about the parameter then.
Thanks!
johannes
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-10-08 4:15 Stephen Rothwell
@ 2021-10-08 5:39 ` Sergio Paracuellos
0 siblings, 0 replies; 143+ messages in thread
From: Sergio Paracuellos @ 2021-10-08 5:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, Linux Kernel Mailing List, Linux Next Mailing List,
Thomas Bogendoerfer
Hi Stephen,
[+cc Thomas Bogendoerfer as mips maintainer]
On Fri, Oct 8, 2021 at 6:15 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the staging tree, today's linux-next build (mips
> nlm_xlp_defconfig) failed like this:
>
> drivers/pci/pci.c:4210: undefined reference to `pci_remap_iospace'
>
> Caused by commit
>
> 9f76779f2418 ("MIPS: implement architecture-specific 'pci_remap_iospace()'")
>
> CONFIG_PCI_DRIVERS_GENERIC is not set for this build, so
> arch/mips/pci/pci-generic.c is not built.
I don't know what should be the correct fix for this.
'pci_remap_iospace' for mips is added in 'pci-generic.c' which in only
compiled when 'CONFIG_PCI_DRIVERS_GENERIC' is selected. In mips there
is also 'CONFIG_PCI_DRIVERS_LEGACY' option that include 'pci-legacy.c'
and drivers in 'arch/mips/pci' are normally defining this
'CONFIG_PCI_DRIVERS_LEGACY'. For the failing build
mips_nlm_xlp_defconfig, none of them are defined and code (I guess
./arch/mips/pci/pci-xlp.c) is just initializing PCI calling
'pcibios_init' and not using PCI core apis and 'pci_remap_iospace' at
all like other drivers inside 'arch/mips/pci'. So I think the correct
thing to do would be just move this mips architecture dependent define
to be dependant of CONFIG_PCI_DRIVERS_GENERIC. The following patch
would be enough:
diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
index 35270984a5f0..421231f55935 100644
--- a/arch/mips/include/asm/pci.h
+++ b/arch/mips/include/asm/pci.h
@@ -20,7 +20,9 @@
#include <linux/list.h>
#include <linux/of.h>
+#ifdef CONFIG_PCI_DRIVERS_GENERIC
#define pci_remap_iospace pci_remap_iospace
+#endif
#ifdef CONFIG_PCI_DRIVERS_LEGACY
Thomas, if you are ok with this, let me know and I'll send this patch
to be added to staging tree for fixing this issue.
Best regards,
Sergio Paracuellos
>
> --
> Cheers,
> Stephen Rothwell
^ permalink raw reply related [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2021-10-08 4:15 Stephen Rothwell
2021-10-08 5:39 ` Sergio Paracuellos
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2021-10-08 4:15 UTC (permalink / raw)
To: Greg KH
Cc: Sergio Paracuellos, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
Hi all,
After merging the staging tree, today's linux-next build (mips
nlm_xlp_defconfig) failed like this:
drivers/pci/pci.c:4210: undefined reference to `pci_remap_iospace'
Caused by commit
9f76779f2418 ("MIPS: implement architecture-specific 'pci_remap_iospace()'")
CONFIG_PCI_DRIVERS_GENERIC is not set for this build, so
arch/mips/pci/pci-generic.c is not built.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-08-16 15:10 ` Greg KH
@ 2021-08-16 21:46 ` Stephen Rothwell
0 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2021-08-16 21:46 UTC (permalink / raw)
To: Greg KH
Cc: David Miller, Networking, Cai Huoqing, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 852 bytes --]
Hi Greg,
On Mon, 16 Aug 2021 17:10:18 +0200 Greg KH <greg@kroah.com> wrote:
>
> On Mon, Aug 16, 2021 at 01:52:16PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/staging/r8188eu/core/rtw_br_ext.c:8:10: fatal error: ../include/net/ipx.h: No such file or directory
> > 8 | #include "../include/net/ipx.h"
> > | ^~~~~~~~~~~~~~~~~~~~~~
> >
> > Caused by commit
> >
> > 6c9b40844751 ("net: Remove net/ipx.h and uapi/linux/ipx.h header files")
> >
> > from the net-next tree.
> >
> > I have reverted that commit for today.
>
> Should now be fixed up in my tree so that you do not need to drop that
> networking patch anymore.
Excellent, thanks.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-08-16 3:52 Stephen Rothwell
2021-08-16 5:24 ` Greg KH
@ 2021-08-16 15:10 ` Greg KH
2021-08-16 21:46 ` Stephen Rothwell
1 sibling, 1 reply; 143+ messages in thread
From: Greg KH @ 2021-08-16 15:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Cai Huoqing, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Aug 16, 2021 at 01:52:16PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/r8188eu/core/rtw_br_ext.c:8:10: fatal error: ../include/net/ipx.h: No such file or directory
> 8 | #include "../include/net/ipx.h"
> | ^~~~~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> 6c9b40844751 ("net: Remove net/ipx.h and uapi/linux/ipx.h header files")
>
> from the net-next tree.
>
> I have reverted that commit for today.
Should now be fixed up in my tree so that you do not need to drop that
networking patch anymore.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-08-16 3:52 Stephen Rothwell
@ 2021-08-16 5:24 ` Greg KH
2021-08-16 15:10 ` Greg KH
1 sibling, 0 replies; 143+ messages in thread
From: Greg KH @ 2021-08-16 5:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Cai Huoqing, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Aug 16, 2021 at 01:52:16PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/r8188eu/core/rtw_br_ext.c:8:10: fatal error: ../include/net/ipx.h: No such file or directory
> 8 | #include "../include/net/ipx.h"
> | ^~~~~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> 6c9b40844751 ("net: Remove net/ipx.h and uapi/linux/ipx.h header files")
>
> from the net-next tree.
>
> I have reverted that commit for today.
>
That's not fair to the networking developers, I'll work on a patch for
this driver to remove that later today...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2021-08-16 3:52 Stephen Rothwell
2021-08-16 5:24 ` Greg KH
2021-08-16 15:10 ` Greg KH
0 siblings, 2 replies; 143+ messages in thread
From: Stephen Rothwell @ 2021-08-16 3:52 UTC (permalink / raw)
To: Greg KH, David Miller, Networking
Cc: Cai Huoqing, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi all,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/r8188eu/core/rtw_br_ext.c:8:10: fatal error: ../include/net/ipx.h: No such file or directory
8 | #include "../include/net/ipx.h"
| ^~~~~~~~~~~~~~~~~~~~~~
Caused by commit
6c9b40844751 ("net: Remove net/ipx.h and uapi/linux/ipx.h header files")
from the net-next tree.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-03-29 5:55 Stephen Rothwell
2021-03-29 6:14 ` Greg KH
2021-04-26 1:29 ` Stephen Rothwell
@ 2021-04-26 22:07 ` Stephen Rothwell
2 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2021-04-26 22:07 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Alexandru Ardelean, Jonathan Cameron, Tomislav Denis,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]
Hi all,
On Mon, 29 Mar 2021 16:55:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_read_reg':
> drivers/iio/adc/ti-ads131e08.c:180:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> 180 | .delay_usecs = st->sdecode_delay_us,
> | ^~~~~~~~~~~
> drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_write_reg':
> drivers/iio/adc/ti-ads131e08.c:206:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> 206 | .delay_usecs = st->sdecode_delay_us,
> | ^~~~~~~~~~~
>
> Caused by commit
>
> d935eddd2799 ("iio: adc: Add driver for Texas Instruments ADS131E0x ADC family")
>
> interacting with commit
>
> 3ab1cce55337 ("spi: core: remove 'delay_usecs' field from spi_transfer")
>
> from the spi tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 29 Mar 2021 16:51:22 +1100
> Subject: [PATCH] iio: adc: merge fix for "spi: core: remove 'delay_usecs'
> field from spi_transfer"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/iio/adc/ti-ads131e08.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
> index 0060d5f0abb0..764dab087b41 100644
> --- a/drivers/iio/adc/ti-ads131e08.c
> +++ b/drivers/iio/adc/ti-ads131e08.c
> @@ -177,7 +177,10 @@ static int ads131e08_read_reg(struct ads131e08_state *st, u8 reg)
> {
> .tx_buf = &st->tx_buf,
> .len = 2,
> - .delay_usecs = st->sdecode_delay_us,
> + .delay = {
> + .value = st->sdecode_delay_us,
> + .unit = SPI_DELAY_UNIT_USECS,
> + },
> }, {
> .rx_buf = &st->rx_buf,
> .len = 1,
> @@ -203,7 +206,10 @@ static int ads131e08_write_reg(struct ads131e08_state *st, u8 reg, u8 value)
> {
> .tx_buf = &st->tx_buf,
> .len = 3,
> - .delay_usecs = st->sdecode_delay_us,
> + .delay = {
> + .value = st->sdecode_delay_us,
> + .unit = SPI_DELAY_UNIT_USECS,
> + },
> }
> };
>
> --
> 2.30.0
This is now a conflict between the spi (and spi-fixes) tree and Linus' tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-04-26 16:23 ` Greg KH
@ 2021-04-26 16:40 ` Mark Brown
0 siblings, 0 replies; 143+ messages in thread
From: Mark Brown @ 2021-04-26 16:40 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Alexandru Ardelean, Jonathan Cameron,
Tomislav Denis, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 791 bytes --]
On Mon, Apr 26, 2021 at 06:23:29PM +0200, Greg KH wrote:
> On Mon, Apr 26, 2021 at 03:41:21PM +0100, Mark Brown wrote:
> > spi: Rename enable1 to activate in spi_set_cs() (2021-04-23 15:36:18 +0100)
> I don't think I want to pull the full SPI merge into my staging tree at
> this point in time, is that wise?
I don't either, just putting it there in case you wanted it.
> I already submitted a pull request to Linus for the staging tree as-is,
> if there are problems we can work to address them then.
If it were a new API I'd have expected a cross tree merge of a tag with
just the API being added in it, though in this case since the API was
already there in mainline I'd been expecting it to get cleaned up with
Stephen's patch or something similar as part of the work in staging.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-04-26 14:41 ` Mark Brown
@ 2021-04-26 16:23 ` Greg KH
2021-04-26 16:40 ` Mark Brown
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2021-04-26 16:23 UTC (permalink / raw)
To: Mark Brown
Cc: Stephen Rothwell, Alexandru Ardelean, Jonathan Cameron,
Tomislav Denis, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Apr 26, 2021 at 03:41:21PM +0100, Mark Brown wrote:
> On Mon, Mar 29, 2021 at 08:14:50AM +0200, Greg KH wrote:
>
> > Thanks for the fix, looks correct to me.
>
> Here's the SPI pull request if you want to pull it in:
>
> The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
>
> Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.13
>
> for you to fetch changes up to 86527bcbc88922ea40df05d28189ee15489d2cf1:
>
> spi: Rename enable1 to activate in spi_set_cs() (2021-04-23 15:36:18 +0100)
I don't think I want to pull the full SPI merge into my staging tree at
this point in time, is that wise?
I already submitted a pull request to Linus for the staging tree as-is,
if there are problems we can work to address them then.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-03-29 6:14 ` Greg KH
2021-03-29 7:25 ` Alexandru Ardelean
@ 2021-04-26 14:41 ` Mark Brown
2021-04-26 16:23 ` Greg KH
1 sibling, 1 reply; 143+ messages in thread
From: Mark Brown @ 2021-04-26 14:41 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Alexandru Ardelean, Jonathan Cameron,
Tomislav Denis, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 15739 bytes --]
On Mon, Mar 29, 2021 at 08:14:50AM +0200, Greg KH wrote:
> Thanks for the fix, looks correct to me.
Here's the SPI pull request if you want to pull it in:
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-v5.13
for you to fetch changes up to 86527bcbc88922ea40df05d28189ee15489d2cf1:
spi: Rename enable1 to activate in spi_set_cs() (2021-04-23 15:36:18 +0100)
----------------------------------------------------------------
spi: Updates for v5.13
The only core work for SPI this time around is the completion of the
conversion to the new style method for specifying transfer delays,
meaning we can cope with what most controllers support more directly
using conversions in the core rather than open coding in drivers.
Otherwise it's a good stack of cleanups and fixes plus a few new
drivers.
The conversion to new style transfer delay will cause an issue with a
newly added staging driver which has a straightforward resolution in
-next.
- Completion of the conversion to new style transfer delay
configuration.
- Introduction and use of module_parport_driver() helper, merged here
as there's no parport tree.
- Support for Altera SoCs on DFL buses, NXP i.MX8DL, HiSilicon Kunpeng,
MediaTek MT8195,
----------------------------------------------------------------
Alain Volmat (2):
spi: stm32: avoid ifdef CONFIG_PM for pm callbacks
spi: stm32: Fix use-after-free on unbind
Alexander Sverdlin (1):
spi: omap2-mcspi: Activate pinctrl idle state during runtime suspend
Alexandru Ardelean (10):
spi: spi-axi-spi-engine: remove usage of delay_usecs
spi: bcm63xx-spi: don't check 'delay_usecs' field
spi: spi-bcm-qspi: replace 'delay_usecs' with 'delay.value' check
spi: spi-sh: replace 'delay_usecs' with 'delay.value' in pr_debug
spi: spi-tegra20-flash: don't check 'delay_usecs' field for spi transfer
staging: greybus: spilib: use 'spi_delay_to_ns' for getting xfer delay
spi: spi-falcon: remove check for 'delay_usecs'
spi: fsl-espi: remove usage of 'delay_usecs' field
spi: core: remove 'delay_usecs' field from spi_transfer
spi: docs: update info about 'delay_usecs'
Amit Kumar Mahapatra (1):
spi: spi-zynqmp-gqspi: Resolved slab-out-of-bounds bug
Andy Shevchenko (5):
parport: Introduce module_parport_driver() helper macro
spi: butterfly: Switch to use module_parport_driver()
spi: lm70llp: Switch to use module_parport_driver()
spi: Make error handling of gpiod_count() call cleaner
spi: Rename enable1 to activate in spi_set_cs()
Antonio Borneo (1):
spi: stm32: drop devres version of spi_register_master
Arnd Bergmann (2):
spi: rockchip: avoid objtool warning
spi: stm32-qspi: fix debug format string
Christophe JAILLET (1):
spi: fsi: add a missing of_node_put
Christophe Kerello (1):
spi: stm32-qspi: fix pm_runtime usage_count counter
Clark Wang (1):
spi: imx: add a check for speed_hz before calculating the clock
Colin Ian King (1):
spi: Fix spelling mistake "softwade" -> "software"
David Bauer (3):
spi: ath79: always call chipselect function
spi: ath79: remove spi-master setup and cleanup assignment
spi: sync up initial chipselect state
Dinghao Liu (2):
spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe
spi: spi-zynqmp-gqspi: Fix runtime PM imbalance in zynqmp_qspi_probe
Eddie James (1):
spi: fsi: Remove multiple sequenced ops for restricted chips
Fabio Estevam (1):
spi: imx: Improve driver description
Han Xu (1):
spi: spi-nxp-fspi: Add imx8dxl driver support
Heikki Krogerus (4):
spi: Add support for software nodes
ARM: pxa: icontrol: Constify the software node
ARM: pxa: zeus: Constify the software node
spi: Remove support for dangling device properties
Heiko Schocher (2):
spi: fspi: enable fspi driver for on imx8mp
dt-bindings: spi: add compatible entry for imx8mp in FlexSPI controller
Jarkko Nikula (1):
spi: pxa2xx: Add support for Intel Alder Lake PCH-M
Jay Fang (14):
spi: cadence-quadspi: Silence shiftTooManyBitsSigned warning
spi: spi-topcliff-pch: Fix checkpatch spacing error
spi: sprd: Fix checkpatch spacing error
spi: pxa2xx: Fix checkpatch spacing errors
spi: omap-100k: Fix checkpatch spacing errors
spi: spi-mtk-nor: Fix checkpatch spacing error
spi: dln2: Fix open brace following function definitions go on the next line
spi: spi-bitbang: Fix open brace following function definitions go on the next line
spi: jcore: Fix trailing statements should be on next line
spi: spi-mem: Fix code indent should use tabs where possible
spi: rockchip: Fix code indent should use tabs where possible
spi: pl022: Fix trailing whitespace
spi: Add HiSilicon SPI Controller Driver for Kunpeng SoCs
spi: hisi-kunpeng: Fix Woverflow warning on conversion
Joe Burmeister (1):
spi: Handle SPI device setup callback failure.
Junlin Yang (1):
spi: cadence-quadspi: add missing of_node_put
Krzysztof Kozlowski (3):
spi: s3c64xx: simplify getting of_device_id match data
spi: s3c64xx: correct kerneldoc of s3c64xx_spi_port_config
spi: s3c64xx: constify driver/match data
Kuldeep Singh (4):
spi: spi-nxp-fspi: Add support for IP read only
spi: spi-nxp-fspi: Implement errata workaround for LS1028A
spi: spi-nxp-fspi: Add imx8dxl support
spi: Convert Freescale QSPI binding to json schema
Leilk Liu (4):
spi: update spi master bindings for MT8195 SoC
spi: update spi slave bindings for MT8195 SoC
spi: mediatek: add mtk_spi_compatible support
spi: mediatek: add mt8195 spi slave support
Linus Walleij (5):
spi: pl022: User more sensible defaults
spi: pl022: Drop custom per-chip cs_control
spi: pl022: Use GPIOs looked up by the core
spi: pl022: Convert to use GPIO descriptors
ARM/spi: spear: Drop PL022 num_chipselect
Mark Brown (11):
Merge existing fixes from spi/for-5.12
Merge series "parport: Introduce module_parport_driver() and use it" from Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
Merge series "spi: finalize 'delay_usecs' removal/transition" from Alexandru Ardelean <aardelean@deviqon.com>:
Merge series "spi: Adding support for software nodes" from Heikki Krogerus <heikki.krogerus@linux.intel.com>:
Merge series "enable flexspi support on imx8mp" from Heiko Schocher <hs@denx.de>:
Merge series "Convert Cadence QSPI bindings to yaml" from Pratyush Yadav <p.yadav@ti.com>:
Merge series "spi: spi-zynqmp-gpspi: fix some issues" from quanyang.wang@windriver.com Quanyang Wang <quanyang.wang@windriver.com>:
Merge series "Minor updates for hisi-sfc-v3xx" from Yicong Yang <yangyicong@hisilicon.com>:
Merge branch 'for-5.12' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.13
Merge series "spi: stm32-qspi: Fix and update" from <patrice.chotard@foss.st.com> Patrice Chotard <patrice.chotard@foss.st.com>:
Merge series "spi: altera: Add DFL bus support for Altera SPI" from matthew.gerlach@linux.intel.com Matthew Gerlach <matthew.gerlach@linux.intel.com>:
Mason Zhang (1):
spi: mt6779: update spi document
Matthew Gerlach (2):
spi: altera: separate core code from platform code
spi: altera: Add DFL bus driver for Altera API Controller
Muhammad Usama Anjum (1):
spi: orion: set devdata properly as it is being used later
Patrice Chotard (3):
spi: stm32-qspi: Trigger DMA only if more than 4 bytes to transfer
spi: stm32-qspi: Add dirmap support
spi: stm32-qspi: Fix compilation warning in ARM64
Quanyang Wang (9):
spi: spi-zynqmp-gqspi: use wait_for_completion_timeout to make zynqmp_qspi_exec_op not interruptible
spi: spi-zynqmp-gqspi: add mutex locking for exec_op
spi: spi-zynqmp-gqspi: transmit dummy circles by using the controller's internal functionality
spi: spi-zynqmp-gqspi: fix incorrect operating mode in zynqmp_qspi_read_op
spi: spi-zynqmp-gqspi: fix clk_enable/disable imbalance issue
spi: spi-zynqmp-gqspi: fix hang issue when suspend/resume
spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op
spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails
spi: tools: make a symbolic link to the header file spi.h
Rafał Miłecki (1):
spi: brcm,spi-bcm-qspi: convert to the json-schema
Ramuthevar Vadivel Murugan (1):
spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
Seiya Wang (1):
dt-bindings: spi: Add compatible for Mediatek MT8195
Shivamurthy Shastri (1):
spidev: Add Micron SPI NOR Authenta device compatible
Tian Tao (3):
spi: orion: Use device_get_match_data() helper
spi: simplify devm_spi_register_controller
spi: davinci: Use device_get_match_data() helper
Tudor Ambarus (3):
spi: spi-ti-qspi: Free DMA resources
spi: spi-ti-qspi: Free DMA resources
spi: atmel: Drop unused variable
Wan Jiabing (1):
spi: Remove repeated struct declaration
Wang Li (2):
spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware()
spi: qup: fix PM reference leak in spi_qup_remove()
Wei Yongjun (3):
spi: dln2: Fix reference leak to master
spi: omap-100k: Fix reference leak to master
spi: spi-zynqmp-gqspi: Fix missing unlock on error in zynqmp_qspi_exec_op()
William A. Kennington III (1):
spi: Fix use-after-free with devm_spi_alloc_*
Yang Yingliang (1):
spi: fsl: add missing iounmap() on error in of_fsl_spi_probe()
Yicong Yang (2):
spi: hisi-sfc-v3xx: fix potential irq race condition
spi: hisi-sfc-v3xx: drop unnecessary ACPI_PTR and related ifendif protection
Álvaro Fernández Rojas (4):
spi: bcm63xx-spi: fix pm_runtime
spi: bcm63xx-hsspi: fix pm_runtime
spi: bcm63xx-spi: fix pm_runtime
spi: bcm63xx-hsspi: fix pm_runtime
.../devicetree/bindings/spi/brcm,spi-bcm-qspi.txt | 245 ----------
.../devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml | 198 ++++++++
.../devicetree/bindings/spi/cadence-quadspi.txt | 68 ---
.../devicetree/bindings/spi/cdns,qspi-nor.yaml | 143 ++++++
.../devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml | 96 ++++
.../bindings/spi/mediatek,spi-mtk-nor.yaml | 1 +
.../devicetree/bindings/spi/spi-fsl-qspi.txt | 66 ---
.../devicetree/bindings/spi/spi-mt65xx.txt | 2 +
.../devicetree/bindings/spi/spi-nxp-fspi.txt | 2 +
.../devicetree/bindings/spi/spi-slave-mt27xx.txt | 1 +
Documentation/spi/spi-summary.rst | 7 +-
MAINTAINERS | 10 +-
arch/arm/mach-pxa/icontrol.c | 12 +-
arch/arm/mach-pxa/zeus.c | 6 +-
arch/arm/mach-spear/spear320.c | 2 -
arch/arm/mach-spear/spear3xx.c | 10 -
drivers/spi/Kconfig | 28 +-
drivers/spi/Makefile | 5 +-
drivers/spi/{spi-altera.c => spi-altera-core.c} | 166 +------
drivers/spi/spi-altera-dfl.c | 204 +++++++++
drivers/spi/spi-altera-platform.c | 172 +++++++
drivers/spi/spi-ath79.c | 3 +-
drivers/spi/spi-atmel.c | 4 -
drivers/spi/spi-axi-spi-engine.c | 12 +-
drivers/spi/spi-bcm-qspi.c | 2 +-
drivers/spi/spi-bcm63xx-hsspi.c | 7 +-
drivers/spi/spi-bcm63xx.c | 8 +-
drivers/spi/spi-bitbang.c | 9 +-
drivers/spi/spi-butterfly.c | 13 +-
drivers/spi/spi-cadence-quadspi.c | 8 +-
drivers/spi/spi-davinci.c | 9 +-
drivers/spi/spi-dln2.c | 5 +-
drivers/spi/spi-falcon.c | 2 +-
drivers/spi/spi-fsi.c | 31 +-
drivers/spi/spi-fsl-espi.c | 17 +-
drivers/spi/spi-fsl-lpspi.c | 2 +-
drivers/spi/spi-fsl-spi.c | 23 +-
drivers/spi/spi-hisi-kunpeng.c | 505 +++++++++++++++++++++
drivers/spi/spi-hisi-sfc-v3xx.c | 7 +-
drivers/spi/spi-imx.c | 39 +-
drivers/spi/spi-jcore.c | 3 +-
drivers/spi/spi-lm70llp.c | 13 +-
drivers/spi/spi-mem.c | 6 +-
drivers/spi/spi-mtk-nor.c | 2 +-
drivers/spi/spi-nxp-fspi.c | 115 ++++-
drivers/spi/spi-omap-100k.c | 14 +-
drivers/spi/spi-omap2-mcspi.c | 24 +-
drivers/spi/spi-orion.c | 5 +-
drivers/spi/spi-pl022.c | 108 +----
drivers/spi/spi-pxa2xx-pci.c | 2 +-
drivers/spi/spi-pxa2xx.c | 6 +-
drivers/spi/spi-qup.c | 2 +-
drivers/spi/spi-rockchip.c | 19 +-
drivers/spi/spi-s3c64xx.c | 31 +-
drivers/spi/spi-sh.c | 4 +-
drivers/spi/spi-slave-mt27xx.c | 36 +-
drivers/spi/spi-sprd-adi.c | 2 +-
drivers/spi/spi-stm32-qspi.c | 106 ++++-
drivers/spi/spi-stm32.c | 39 +-
drivers/spi/spi-tegra20-sflash.c | 3 +-
drivers/spi/spi-ti-qspi.c | 20 +-
drivers/spi/spi-topcliff-pch.c | 3 +-
drivers/spi/spi-zynqmp-gqspi.c | 178 ++++----
drivers/spi/spi.c | 97 ++--
drivers/spi/spidev.c | 1 +
drivers/staging/greybus/spilib.c | 5 +-
include/linux/amba/pl022.h | 10 -
include/linux/parport.h | 12 +-
include/linux/spi/altera.h | 21 +
include/linux/spi/spi.h | 23 +-
tools/spi/Makefile | 5 +-
71 files changed, 2003 insertions(+), 1062 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
create mode 100644 Documentation/devicetree/bindings/spi/fsl,spi-fsl-qspi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
rename drivers/spi/{spi-altera.c => spi-altera-core.c} (56%)
create mode 100644 drivers/spi/spi-altera-dfl.c
create mode 100644 drivers/spi/spi-altera-platform.c
create mode 100644 drivers/spi/spi-hisi-kunpeng.c
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-03-29 5:55 Stephen Rothwell
2021-03-29 6:14 ` Greg KH
@ 2021-04-26 1:29 ` Stephen Rothwell
2021-04-26 22:07 ` Stephen Rothwell
2 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2021-04-26 1:29 UTC (permalink / raw)
To: Greg KH, Mark Brown
Cc: Alexandru Ardelean, Jonathan Cameron, Tomislav Denis,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]
Hi all,
On Mon, 29 Mar 2021 16:55:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_read_reg':
> drivers/iio/adc/ti-ads131e08.c:180:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> 180 | .delay_usecs = st->sdecode_delay_us,
> | ^~~~~~~~~~~
> drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_write_reg':
> drivers/iio/adc/ti-ads131e08.c:206:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> 206 | .delay_usecs = st->sdecode_delay_us,
> | ^~~~~~~~~~~
>
> Caused by commit
>
> d935eddd2799 ("iio: adc: Add driver for Texas Instruments ADS131E0x ADC family")
>
> interacting with commit
>
> 3ab1cce55337 ("spi: core: remove 'delay_usecs' field from spi_transfer")
>
> from the spi tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 29 Mar 2021 16:51:22 +1100
> Subject: [PATCH] iio: adc: merge fix for "spi: core: remove 'delay_usecs'
> field from spi_transfer"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/iio/adc/ti-ads131e08.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
> index 0060d5f0abb0..764dab087b41 100644
> --- a/drivers/iio/adc/ti-ads131e08.c
> +++ b/drivers/iio/adc/ti-ads131e08.c
> @@ -177,7 +177,10 @@ static int ads131e08_read_reg(struct ads131e08_state *st, u8 reg)
> {
> .tx_buf = &st->tx_buf,
> .len = 2,
> - .delay_usecs = st->sdecode_delay_us,
> + .delay = {
> + .value = st->sdecode_delay_us,
> + .unit = SPI_DELAY_UNIT_USECS,
> + },
> }, {
> .rx_buf = &st->rx_buf,
> .len = 1,
> @@ -203,7 +206,10 @@ static int ads131e08_write_reg(struct ads131e08_state *st, u8 reg, u8 value)
> {
> .tx_buf = &st->tx_buf,
> .len = 3,
> - .delay_usecs = st->sdecode_delay_us,
> + .delay = {
> + .value = st->sdecode_delay_us,
> + .unit = SPI_DELAY_UNIT_USECS,
> + },
> }
> };
>
> --
> 2.30.0
With the merge window opening, this is a reminder that I am still
applying the above fix to the merge of the staging tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-03-29 6:14 ` Greg KH
@ 2021-03-29 7:25 ` Alexandru Ardelean
2021-04-26 14:41 ` Mark Brown
1 sibling, 0 replies; 143+ messages in thread
From: Alexandru Ardelean @ 2021-03-29 7:25 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Mark Brown, Jonathan Cameron, Tomislav Denis,
Linux Kernel Mailing List, Linux Next Mailing List
On Mon, 29 Mar 2021 at 09:15, Greg KH <greg@kroah.com> wrote:
>
> On Mon, Mar 29, 2021 at 04:55:25PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_read_reg':
> > drivers/iio/adc/ti-ads131e08.c:180:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> > 180 | .delay_usecs = st->sdecode_delay_us,
> > | ^~~~~~~~~~~
> > drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_write_reg':
> > drivers/iio/adc/ti-ads131e08.c:206:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> > 206 | .delay_usecs = st->sdecode_delay_us,
> > | ^~~~~~~~~~~
> >
> > Caused by commit
> >
> > d935eddd2799 ("iio: adc: Add driver for Texas Instruments ADS131E0x ADC family")
> >
> > interacting with commit
> >
> > 3ab1cce55337 ("spi: core: remove 'delay_usecs' field from spi_transfer")
> >
> > from the spi tree.
> >
> > I have applied the following merge fix patch.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Mon, 29 Mar 2021 16:51:22 +1100
> > Subject: [PATCH] iio: adc: merge fix for "spi: core: remove 'delay_usecs'
> > field from spi_transfer"
> >
Reviewed-by: Alexandru Ardelean <aardelean@deviqon.com>
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/iio/adc/ti-ads131e08.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
> > index 0060d5f0abb0..764dab087b41 100644
> > --- a/drivers/iio/adc/ti-ads131e08.c
> > +++ b/drivers/iio/adc/ti-ads131e08.c
> > @@ -177,7 +177,10 @@ static int ads131e08_read_reg(struct ads131e08_state *st, u8 reg)
> > {
> > .tx_buf = &st->tx_buf,
> > .len = 2,
> > - .delay_usecs = st->sdecode_delay_us,
> > + .delay = {
> > + .value = st->sdecode_delay_us,
> > + .unit = SPI_DELAY_UNIT_USECS,
> > + },
> > }, {
> > .rx_buf = &st->rx_buf,
> > .len = 1,
> > @@ -203,7 +206,10 @@ static int ads131e08_write_reg(struct ads131e08_state *st, u8 reg, u8 value)
> > {
> > .tx_buf = &st->tx_buf,
> > .len = 3,
> > - .delay_usecs = st->sdecode_delay_us,
> > + .delay = {
> > + .value = st->sdecode_delay_us,
> > + .unit = SPI_DELAY_UNIT_USECS,
> > + },
> > }
> > };
> >
> > --
> > 2.30.0
> >
>
> Thanks for the fix, looks correct to me.
>
> greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2021-03-29 5:55 Stephen Rothwell
@ 2021-03-29 6:14 ` Greg KH
2021-03-29 7:25 ` Alexandru Ardelean
2021-04-26 14:41 ` Mark Brown
2021-04-26 1:29 ` Stephen Rothwell
2021-04-26 22:07 ` Stephen Rothwell
2 siblings, 2 replies; 143+ messages in thread
From: Greg KH @ 2021-03-29 6:14 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mark Brown, Alexandru Ardelean, Jonathan Cameron, Tomislav Denis,
Linux Kernel Mailing List, Linux Next Mailing List
On Mon, Mar 29, 2021 at 04:55:25PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_read_reg':
> drivers/iio/adc/ti-ads131e08.c:180:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> 180 | .delay_usecs = st->sdecode_delay_us,
> | ^~~~~~~~~~~
> drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_write_reg':
> drivers/iio/adc/ti-ads131e08.c:206:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
> 206 | .delay_usecs = st->sdecode_delay_us,
> | ^~~~~~~~~~~
>
> Caused by commit
>
> d935eddd2799 ("iio: adc: Add driver for Texas Instruments ADS131E0x ADC family")
>
> interacting with commit
>
> 3ab1cce55337 ("spi: core: remove 'delay_usecs' field from spi_transfer")
>
> from the spi tree.
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 29 Mar 2021 16:51:22 +1100
> Subject: [PATCH] iio: adc: merge fix for "spi: core: remove 'delay_usecs'
> field from spi_transfer"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/iio/adc/ti-ads131e08.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
> index 0060d5f0abb0..764dab087b41 100644
> --- a/drivers/iio/adc/ti-ads131e08.c
> +++ b/drivers/iio/adc/ti-ads131e08.c
> @@ -177,7 +177,10 @@ static int ads131e08_read_reg(struct ads131e08_state *st, u8 reg)
> {
> .tx_buf = &st->tx_buf,
> .len = 2,
> - .delay_usecs = st->sdecode_delay_us,
> + .delay = {
> + .value = st->sdecode_delay_us,
> + .unit = SPI_DELAY_UNIT_USECS,
> + },
> }, {
> .rx_buf = &st->rx_buf,
> .len = 1,
> @@ -203,7 +206,10 @@ static int ads131e08_write_reg(struct ads131e08_state *st, u8 reg, u8 value)
> {
> .tx_buf = &st->tx_buf,
> .len = 3,
> - .delay_usecs = st->sdecode_delay_us,
> + .delay = {
> + .value = st->sdecode_delay_us,
> + .unit = SPI_DELAY_UNIT_USECS,
> + },
> }
> };
>
> --
> 2.30.0
>
Thanks for the fix, looks correct to me.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2021-03-29 5:55 Stephen Rothwell
2021-03-29 6:14 ` Greg KH
` (2 more replies)
0 siblings, 3 replies; 143+ messages in thread
From: Stephen Rothwell @ 2021-03-29 5:55 UTC (permalink / raw)
To: Greg KH, Mark Brown
Cc: Alexandru Ardelean, Jonathan Cameron, Tomislav Denis,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
Hi all,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_read_reg':
drivers/iio/adc/ti-ads131e08.c:180:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
180 | .delay_usecs = st->sdecode_delay_us,
| ^~~~~~~~~~~
drivers/iio/adc/ti-ads131e08.c: In function 'ads131e08_write_reg':
drivers/iio/adc/ti-ads131e08.c:206:5: error: 'struct spi_transfer' has no member named 'delay_usecs'
206 | .delay_usecs = st->sdecode_delay_us,
| ^~~~~~~~~~~
Caused by commit
d935eddd2799 ("iio: adc: Add driver for Texas Instruments ADS131E0x ADC family")
interacting with commit
3ab1cce55337 ("spi: core: remove 'delay_usecs' field from spi_transfer")
from the spi tree.
I have applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 29 Mar 2021 16:51:22 +1100
Subject: [PATCH] iio: adc: merge fix for "spi: core: remove 'delay_usecs'
field from spi_transfer"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/iio/adc/ti-ads131e08.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/ti-ads131e08.c b/drivers/iio/adc/ti-ads131e08.c
index 0060d5f0abb0..764dab087b41 100644
--- a/drivers/iio/adc/ti-ads131e08.c
+++ b/drivers/iio/adc/ti-ads131e08.c
@@ -177,7 +177,10 @@ static int ads131e08_read_reg(struct ads131e08_state *st, u8 reg)
{
.tx_buf = &st->tx_buf,
.len = 2,
- .delay_usecs = st->sdecode_delay_us,
+ .delay = {
+ .value = st->sdecode_delay_us,
+ .unit = SPI_DELAY_UNIT_USECS,
+ },
}, {
.rx_buf = &st->rx_buf,
.len = 1,
@@ -203,7 +206,10 @@ static int ads131e08_write_reg(struct ads131e08_state *st, u8 reg, u8 value)
{
.tx_buf = &st->tx_buf,
.len = 3,
- .delay_usecs = st->sdecode_delay_us,
+ .delay = {
+ .value = st->sdecode_delay_us,
+ .unit = SPI_DELAY_UNIT_USECS,
+ },
}
};
--
2.30.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2020-12-07 5:46 Stephen Rothwell
2020-12-07 9:26 ` Greg KH
@ 2020-12-14 20:27 ` Stephen Rothwell
1 sibling, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2020-12-14 20:27 UTC (permalink / raw)
To: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
Hi all,
On Mon, 7 Dec 2020 16:46:01 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/iio/trigger/iio-trig-sysfs.c: In function 'iio_sysfs_trigger_probe':
> drivers/iio/trigger/iio-trig-sysfs.c:164:21: error: 'struct irq_work' has no member named 'flags'
> 164 | atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
> | ^
>
> Caused by commit
>
> 0449fc4eead7 ("iio: sysfs-trigger: Mark irq_work to expire in hardirq context")
>
> interacting with commit
>
> 7a9f50a05843 ("irq_work: Cleanup")
>
> from the tip tree.
>
> I applied the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 7 Dec 2020 16:42:18 +1100
> Subject: [PATCH] fixup for "irq_work: Cleanup"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/iio/trigger/iio-trig-sysfs.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/iio/trigger/iio-trig-sysfs.c b/drivers/iio/trigger/iio-trig-sysfs.c
> index 10a3fd29362b..0f6b512a5c37 100644
> --- a/drivers/iio/trigger/iio-trig-sysfs.c
> +++ b/drivers/iio/trigger/iio-trig-sysfs.c
> @@ -160,8 +160,7 @@ static int iio_sysfs_trigger_probe(int id)
> t->trig->dev.parent = &iio_sysfs_trig_dev;
> iio_trigger_set_drvdata(t->trig, t);
>
> - init_irq_work(&t->work, iio_sysfs_trigger_work);
> - atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
> + t->work = IRQ_WORK_INIT_HARD(iio_sysfs_trigger_work);
>
> ret = iio_trigger_register(t->trig);
> if (ret)
Just a reminder that I am still applying this merge fix.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2020-12-07 9:26 ` Greg KH
@ 2020-12-07 9:45 ` Stephen Rothwell
0 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2020-12-07 9:45 UTC (permalink / raw)
To: Greg KH
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 946 bytes --]
Hi Greg,
On Mon, 7 Dec 2020 10:26:06 +0100 Greg KH <greg@kroah.com> wrote:
>
> > diff --git a/drivers/iio/trigger/iio-trig-sysfs.c b/drivers/iio/trigger/iio-trig-sysfs.c
> > index 10a3fd29362b..0f6b512a5c37 100644
> > --- a/drivers/iio/trigger/iio-trig-sysfs.c
> > +++ b/drivers/iio/trigger/iio-trig-sysfs.c
> > @@ -160,8 +160,7 @@ static int iio_sysfs_trigger_probe(int id)
> > t->trig->dev.parent = &iio_sysfs_trig_dev;
> > iio_trigger_set_drvdata(t->trig, t);
> >
> > - init_irq_work(&t->work, iio_sysfs_trigger_work);
> > - atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
> > + t->work = IRQ_WORK_INIT_HARD(iio_sysfs_trigger_work);
> >
> > ret = iio_trigger_register(t->trig);
> > if (ret)
> > --
> > 2.29.2
>
> Is this patch "safe" to take now, if the tip tree isn't part of my tree?
Unfortunately not, as IRQ_WORK_INIT_HARD() is introduced by the tip tree
commit.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2020-12-07 5:46 Stephen Rothwell
@ 2020-12-07 9:26 ` Greg KH
2020-12-07 9:45 ` Stephen Rothwell
2020-12-14 20:27 ` Stephen Rothwell
1 sibling, 1 reply; 143+ messages in thread
From: Greg KH @ 2020-12-07 9:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Dec 07, 2020 at 04:46:01PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/iio/trigger/iio-trig-sysfs.c: In function 'iio_sysfs_trigger_probe':
> drivers/iio/trigger/iio-trig-sysfs.c:164:21: error: 'struct irq_work' has no member named 'flags'
> 164 | atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
> | ^
>
> Caused by commit
>
> 0449fc4eead7 ("iio: sysfs-trigger: Mark irq_work to expire in hardirq context")
>
> interacting with commit
>
> 7a9f50a05843 ("irq_work: Cleanup")
>
> from the tip tree.
>
> I applied the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 7 Dec 2020 16:42:18 +1100
> Subject: [PATCH] fixup for "irq_work: Cleanup"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/iio/trigger/iio-trig-sysfs.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/iio/trigger/iio-trig-sysfs.c b/drivers/iio/trigger/iio-trig-sysfs.c
> index 10a3fd29362b..0f6b512a5c37 100644
> --- a/drivers/iio/trigger/iio-trig-sysfs.c
> +++ b/drivers/iio/trigger/iio-trig-sysfs.c
> @@ -160,8 +160,7 @@ static int iio_sysfs_trigger_probe(int id)
> t->trig->dev.parent = &iio_sysfs_trig_dev;
> iio_trigger_set_drvdata(t->trig, t);
>
> - init_irq_work(&t->work, iio_sysfs_trigger_work);
> - atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
> + t->work = IRQ_WORK_INIT_HARD(iio_sysfs_trigger_work);
>
> ret = iio_trigger_register(t->trig);
> if (ret)
> --
> 2.29.2
Is this patch "safe" to take now, if the tip tree isn't part of my tree?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2020-12-07 5:46 Stephen Rothwell
2020-12-07 9:26 ` Greg KH
2020-12-14 20:27 ` Stephen Rothwell
0 siblings, 2 replies; 143+ messages in thread
From: Stephen Rothwell @ 2020-12-07 5:46 UTC (permalink / raw)
To: Greg KH, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: Jonathan Cameron, Lars-Peter Clausen, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]
Hi all,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/iio/trigger/iio-trig-sysfs.c: In function 'iio_sysfs_trigger_probe':
drivers/iio/trigger/iio-trig-sysfs.c:164:21: error: 'struct irq_work' has no member named 'flags'
164 | atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
| ^
Caused by commit
0449fc4eead7 ("iio: sysfs-trigger: Mark irq_work to expire in hardirq context")
interacting with commit
7a9f50a05843 ("irq_work: Cleanup")
from the tip tree.
I applied the following merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 Dec 2020 16:42:18 +1100
Subject: [PATCH] fixup for "irq_work: Cleanup"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/iio/trigger/iio-trig-sysfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iio/trigger/iio-trig-sysfs.c b/drivers/iio/trigger/iio-trig-sysfs.c
index 10a3fd29362b..0f6b512a5c37 100644
--- a/drivers/iio/trigger/iio-trig-sysfs.c
+++ b/drivers/iio/trigger/iio-trig-sysfs.c
@@ -160,8 +160,7 @@ static int iio_sysfs_trigger_probe(int id)
t->trig->dev.parent = &iio_sysfs_trig_dev;
iio_trigger_set_drvdata(t->trig, t);
- init_irq_work(&t->work, iio_sysfs_trigger_work);
- atomic_set(&t->work.flags, IRQ_WORK_HARD_IRQ);
+ t->work = IRQ_WORK_INIT_HARD(iio_sysfs_trigger_work);
ret = iio_trigger_register(t->trig);
if (ret)
--
2.29.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2019-10-08 2:49 Stephen Rothwell
@ 2019-10-08 12:46 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2019-10-08 12:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Jérôme Pouiller
On Tue, Oct 08, 2019 at 01:49:07PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/linux/gpio/consumer.h:5,
> from drivers/staging/wfx/bh.c:8:
> drivers/staging/wfx/bh.c: In function 'rx_helper':
> drivers/staging/wfx/bh.c:86:19: warning: passing argument 1 of '__swab16s' makes pointer from integer without a cast [-Wint-conversion]
> 86 | le16_to_cpus(hif->len);
> include/uapi/linux/byteorder/big_endian.h:97:38: note: in definition of macro '__le16_to_cpus'
> 97 | #define __le16_to_cpus(x) __swab16s((x))
> | ^
> drivers/staging/wfx/bh.c:86:3: note: in expansion of macro 'le16_to_cpus'
> 86 | le16_to_cpus(hif->len);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/linux/gpio/consumer.h:5,
> from drivers/staging/wfx/bh.c:8:
> include/uapi/linux/swab.h:230:37: note: expected '__u16 *' {aka 'short unsigned int *'} but argument is of type 'uint16_t' {aka 'short unsigned int'}
> 230 | static inline void __swab16s(__u16 *p)
> | ~~~~~~~^
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/linux/gpio/consumer.h:5,
> from drivers/staging/wfx/bh.c:8:
> drivers/staging/wfx/bh.c:91:19: warning: passing argument 1 of '__swab16s' makes pointer from integer without a cast [-Wint-conversion]
> 91 | le16_to_cpus(hif->len);
> include/uapi/linux/byteorder/big_endian.h:97:38: note: in definition of macro '__le16_to_cpus'
> 97 | #define __le16_to_cpus(x) __swab16s((x))
> | ^
> drivers/staging/wfx/bh.c:91:3: note: in expansion of macro 'le16_to_cpus'
> 91 | le16_to_cpus(hif->len);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/linux/gpio/consumer.h:5,
> from drivers/staging/wfx/bh.c:8:
> include/uapi/linux/swab.h:230:37: note: expected '__u16 *' {aka 'short unsigned int *'} but argument is of type 'uint16_t' {aka 'short unsigned int'}
> 230 | static inline void __swab16s(__u16 *p)
> | ~~~~~~~^
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/key.c:8:
> drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
> drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 139 | cpu_to_le32s(&val);
> include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
> 94 | #define __cpu_to_le32s(x) __swab32s((x))
> | ^
> drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
> 139 | cpu_to_le32s(&val);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/key.c:8:
> include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
> 242 | static __always_inline void __swab32s(__u32 *p)
> | ~~~~~~~^
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/scan.c:8:
> drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
> drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 139 | cpu_to_le32s(&val);
> include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
> 94 | #define __cpu_to_le32s(x) __swab32s((x))
> | ^
> drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
> 139 | cpu_to_le32s(&val);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/scan.c:8:
> include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
> 242 | static __always_inline void __swab32s(__u32 *p)
> | ~~~~~~~^
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/linux/list.h:9,
> from include/linux/module.h:9,
> from drivers/staging/wfx/main.c:13:
> drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
> drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 139 | cpu_to_le32s(&val);
> include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
> 94 | #define __cpu_to_le32s(x) __swab32s((x))
> | ^
> drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
> 139 | cpu_to_le32s(&val);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/linux/list.h:9,
> from include/linux/module.h:9,
> from drivers/staging/wfx/main.c:13:
> include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
> 242 | static __always_inline void __swab32s(__u32 *p)
> | ~~~~~~~^
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/data_tx.c:8:
> drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
> drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 139 | cpu_to_le32s(&val);
> include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
> 94 | #define __cpu_to_le32s(x) __swab32s((x))
> | ^
> drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
> 139 | cpu_to_le32s(&val);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/data_tx.c:8:
> include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
> 242 | static __always_inline void __swab32s(__u32 *p)
> | ~~~~~~~^
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/data_tx.c:8:
> drivers/staging/wfx/data_tx.c: In function 'wfx_tx_inner':
> include/uapi/linux/byteorder/big_endian.h:35:26: warning: conversion from 'short unsigned int' to 'uint8_t' {aka 'unsigned char'} changes value from '1024' to '0' [-Woverflow]
> 35 | #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
> | ^
> include/linux/byteorder/generic.h:90:21: note: in expansion of macro '__cpu_to_le16'
> 90 | #define cpu_to_le16 __cpu_to_le16
> | ^~~~~~~~~~~~~
> drivers/staging/wfx/data_tx.c:623:16: note: in expansion of macro 'cpu_to_le16'
> 623 | hif_msg->id = cpu_to_le16(HIF_REQ_ID_TX);
> | ^~~~~~~~~~~
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/sta.c:8:
> drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
> drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 139 | cpu_to_le32s(&val);
> include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
> 94 | #define __cpu_to_le32s(x) __swab32s((x))
> | ^
> drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
> 139 | cpu_to_le32s(&val);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/asm-generic/bug.h:19,
> from arch/powerpc/include/asm/bug.h:120,
> from include/linux/bug.h:5,
> from include/net/mac80211.h:16,
> from drivers/staging/wfx/sta.c:8:
> include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
> 242 | static __always_inline void __swab32s(__u32 *p)
> | ~~~~~~~^
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/linux/list.h:9,
> from include/linux/wait.h:7,
> from include/linux/wait_bit.h:8,
> from include/linux/fs.h:6,
> from include/linux/debugfs.h:15,
> from drivers/staging/wfx/debug.c:8:
> drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
> drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 139 | cpu_to_le32s(&val);
> include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
> 94 | #define __cpu_to_le32s(x) __swab32s((x))
> | ^
> drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
> 139 | cpu_to_le32s(&val);
> | ^~~~~~~~~~~~
> In file included from include/linux/swab.h:5,
> from include/uapi/linux/byteorder/big_endian.h:13,
> from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:6,
> from arch/powerpc/include/asm/bitops.h:243,
> from include/linux/bitops.h:26,
> from include/linux/kernel.h:12,
> from include/linux/list.h:9,
> from include/linux/wait.h:7,
> from include/linux/wait_bit.h:8,
> from include/linux/fs.h:6,
> from include/linux/debugfs.h:15,
> from drivers/staging/wfx/debug.c:8:
> include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
> 242 | static __always_inline void __swab32s(__u32 *p)
> | ~~~~~~~^
>
> Caused by commits from the staging tree.
>
> I have disabled CONFIG_WFX for today.
Should be fixed soon, thanks for the report.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2019-10-08 2:49 Stephen Rothwell
2019-10-08 12:46 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2019-10-08 2:49 UTC (permalink / raw)
To: Greg KH
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Jérôme Pouiller
[-- Attachment #1: Type: text/plain, Size: 18682 bytes --]
Hi all,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/linux/gpio/consumer.h:5,
from drivers/staging/wfx/bh.c:8:
drivers/staging/wfx/bh.c: In function 'rx_helper':
drivers/staging/wfx/bh.c:86:19: warning: passing argument 1 of '__swab16s' makes pointer from integer without a cast [-Wint-conversion]
86 | le16_to_cpus(hif->len);
include/uapi/linux/byteorder/big_endian.h:97:38: note: in definition of macro '__le16_to_cpus'
97 | #define __le16_to_cpus(x) __swab16s((x))
| ^
drivers/staging/wfx/bh.c:86:3: note: in expansion of macro 'le16_to_cpus'
86 | le16_to_cpus(hif->len);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/linux/gpio/consumer.h:5,
from drivers/staging/wfx/bh.c:8:
include/uapi/linux/swab.h:230:37: note: expected '__u16 *' {aka 'short unsigned int *'} but argument is of type 'uint16_t' {aka 'short unsigned int'}
230 | static inline void __swab16s(__u16 *p)
| ~~~~~~~^
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/linux/gpio/consumer.h:5,
from drivers/staging/wfx/bh.c:8:
drivers/staging/wfx/bh.c:91:19: warning: passing argument 1 of '__swab16s' makes pointer from integer without a cast [-Wint-conversion]
91 | le16_to_cpus(hif->len);
include/uapi/linux/byteorder/big_endian.h:97:38: note: in definition of macro '__le16_to_cpus'
97 | #define __le16_to_cpus(x) __swab16s((x))
| ^
drivers/staging/wfx/bh.c:91:3: note: in expansion of macro 'le16_to_cpus'
91 | le16_to_cpus(hif->len);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/linux/gpio/consumer.h:5,
from drivers/staging/wfx/bh.c:8:
include/uapi/linux/swab.h:230:37: note: expected '__u16 *' {aka 'short unsigned int *'} but argument is of type 'uint16_t' {aka 'short unsigned int'}
230 | static inline void __swab16s(__u16 *p)
| ~~~~~~~^
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/key.c:8:
drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
139 | cpu_to_le32s(&val);
include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
94 | #define __cpu_to_le32s(x) __swab32s((x))
| ^
drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
139 | cpu_to_le32s(&val);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/key.c:8:
include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
242 | static __always_inline void __swab32s(__u32 *p)
| ~~~~~~~^
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/scan.c:8:
drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
139 | cpu_to_le32s(&val);
include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
94 | #define __cpu_to_le32s(x) __swab32s((x))
| ^
drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
139 | cpu_to_le32s(&val);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/scan.c:8:
include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
242 | static __always_inline void __swab32s(__u32 *p)
| ~~~~~~~^
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/staging/wfx/main.c:13:
drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
139 | cpu_to_le32s(&val);
include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
94 | #define __cpu_to_le32s(x) __swab32s((x))
| ^
drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
139 | cpu_to_le32s(&val);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/linux/list.h:9,
from include/linux/module.h:9,
from drivers/staging/wfx/main.c:13:
include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
242 | static __always_inline void __swab32s(__u32 *p)
| ~~~~~~~^
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/data_tx.c:8:
drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
139 | cpu_to_le32s(&val);
include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
94 | #define __cpu_to_le32s(x) __swab32s((x))
| ^
drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
139 | cpu_to_le32s(&val);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/data_tx.c:8:
include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
242 | static __always_inline void __swab32s(__u32 *p)
| ~~~~~~~^
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/data_tx.c:8:
drivers/staging/wfx/data_tx.c: In function 'wfx_tx_inner':
include/uapi/linux/byteorder/big_endian.h:35:26: warning: conversion from 'short unsigned int' to 'uint8_t' {aka 'unsigned char'} changes value from '1024' to '0' [-Woverflow]
35 | #define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
| ^
include/linux/byteorder/generic.h:90:21: note: in expansion of macro '__cpu_to_le16'
90 | #define cpu_to_le16 __cpu_to_le16
| ^~~~~~~~~~~~~
drivers/staging/wfx/data_tx.c:623:16: note: in expansion of macro 'cpu_to_le16'
623 | hif_msg->id = cpu_to_le16(HIF_REQ_ID_TX);
| ^~~~~~~~~~~
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/sta.c:8:
drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
139 | cpu_to_le32s(&val);
include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
94 | #define __cpu_to_le32s(x) __swab32s((x))
| ^
drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
139 | cpu_to_le32s(&val);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/powerpc/include/asm/bug.h:120,
from include/linux/bug.h:5,
from include/net/mac80211.h:16,
from drivers/staging/wfx/sta.c:8:
include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
242 | static __always_inline void __swab32s(__u32 *p)
| ~~~~~~~^
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/debugfs.h:15,
from drivers/staging/wfx/debug.c:8:
drivers/staging/wfx/hif_tx_mib.h: In function 'hif_set_mfp':
drivers/staging/wfx/hif_tx_mib.h:139:15: error: passing argument 1 of '__swab32s' from incompatible pointer type [-Werror=incompatible-pointer-types]
139 | cpu_to_le32s(&val);
include/uapi/linux/byteorder/big_endian.h:94:38: note: in definition of macro '__cpu_to_le32s'
94 | #define __cpu_to_le32s(x) __swab32s((x))
| ^
drivers/staging/wfx/hif_tx_mib.h:139:2: note: in expansion of macro 'cpu_to_le32s'
139 | cpu_to_le32s(&val);
| ^~~~~~~~~~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:6,
from arch/powerpc/include/asm/bitops.h:243,
from include/linux/bitops.h:26,
from include/linux/kernel.h:12,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/debugfs.h:15,
from drivers/staging/wfx/debug.c:8:
include/uapi/linux/swab.h:242:46: note: expected '__u32 *' {aka 'unsigned int *'} but argument is of type 'struct hif_mib_protected_mgmt_policy *'
242 | static __always_inline void __swab32s(__u32 *p)
| ~~~~~~~^
Caused by commits from the staging tree.
I have disabled CONFIG_WFX for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2019-06-24 7:38 Stephen Rothwell
@ 2019-06-24 8:46 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2019-06-24 8:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Next Mailing List, Linux Kernel Mailing List, YueHaibing
On Mon, Jun 24, 2019 at 05:38:55PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the staging tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> lib/Kconfig:132:error: recursive dependency detected!
> lib/Kconfig:132: symbol CRC32 is selected by XZ_DEC
> lib/xz/Kconfig:2: symbol XZ_DEC is selected by FW_LOADER_COMPRESS
> drivers/base/firmware_loader/Kconfig:158: symbol FW_LOADER_COMPRESS depends on FW_LOADER
> drivers/base/firmware_loader/Kconfig:4: symbol FW_LOADER is selected by KS7010
> drivers/staging/ks7010/Kconfig:2: symbol KS7010 depends on CRYPTO_HASH
> crypto/Kconfig:65: symbol CRYPTO_HASH is selected by CRYPTO_CRC32_ARM_CE
> arch/arm/crypto/Kconfig:123: symbol CRYPTO_CRC32_ARM_CE depends on CRC32
> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> subsection "Kconfig recursive dependency limitations"
>
> This is just while doing the "make multi_v7_defconfig".
>
> Caused by commit
>
> 3e5bc68fa596 ("staging: ks7010: Fix build error")
>
> I have reverted that commit for today.
Odd. I'll go revert this now too.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2019-06-24 7:38 Stephen Rothwell
2019-06-24 8:46 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2019-06-24 7:38 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Next Mailing List, Linux Kernel Mailing List, YueHaibing
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
Hi all,
After merging the staging tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
lib/Kconfig:132:error: recursive dependency detected!
lib/Kconfig:132: symbol CRC32 is selected by XZ_DEC
lib/xz/Kconfig:2: symbol XZ_DEC is selected by FW_LOADER_COMPRESS
drivers/base/firmware_loader/Kconfig:158: symbol FW_LOADER_COMPRESS depends on FW_LOADER
drivers/base/firmware_loader/Kconfig:4: symbol FW_LOADER is selected by KS7010
drivers/staging/ks7010/Kconfig:2: symbol KS7010 depends on CRYPTO_HASH
crypto/Kconfig:65: symbol CRYPTO_HASH is selected by CRYPTO_CRC32_ARM_CE
arch/arm/crypto/Kconfig:123: symbol CRYPTO_CRC32_ARM_CE depends on CRC32
For a resolution refer to Documentation/kbuild/kconfig-language.rst
subsection "Kconfig recursive dependency limitations"
This is just while doing the "make multi_v7_defconfig".
Caused by commit
3e5bc68fa596 ("staging: ks7010: Fix build error")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-08-02 7:14 ` Greg KH
@ 2018-08-02 7:48 ` Chao Yu
0 siblings, 0 replies; 143+ messages in thread
From: Chao Yu @ 2018-08-02 7:48 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Gao Xiang, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, David Howells, Miao Xie, Chao Yu
On 2018/8/2 15:14, Greg KH wrote:
> On Thu, Aug 02, 2018 at 03:01:59PM +0800, Chao Yu wrote:
>> Hi Greg,
>>
>> On 2018/8/2 14:15, Greg KH wrote:
>>> On Wed, Aug 01, 2018 at 05:09:13PM +0800, Chao Yu wrote:
>>>> Hi Stephen,
>>>>
>>>> On 2018/7/30 14:31, Gao Xiang wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> On 2018/7/30 14:16, Stephen Rothwell wrote:
>>>>>> Hi Greg,
>>>>>>
>>>>>> After merging the staging tree, today's linux-next build (x86_64
>>>>>> allmodconfig) failed like this:
>>>>>>
>>>>>> drivers/staging/erofs/super.c: In function 'erofs_read_super':
>>>>>> drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
>>>>>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>>>>>> ^~~~~~~~~
>>>>>> IS_RDONLY
>>>>>> drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is reported only once for each function it appears in
>>>>>> drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first use in this function); did you mean 'S_NOATIME'?
>>>>>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>>>>>> ^~~~~~~~~~
>>>>>> S_NOATIME
>>>>>> drivers/staging/erofs/super.c: In function 'erofs_mount':
>>>>>> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
>>>>>> &priv, erofs_fill_super);
>>>>>> ^~~~~~~~~~~~~~~~
>>>>>> In file included from include/linux/buffer_head.h:12:0,
>>>>>> from drivers/staging/erofs/super.c:14:
>>>>>> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
>>>>>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>>>>>> ^~~~~~~~~~
>>>>>> drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
>>>>>> return mount_bdev(fs_type, flags, dev_name,
>>>>>> ^~~~~~~~~~
>>>>>> In file included from include/linux/buffer_head.h:12:0,
>>>>>> from drivers/staging/erofs/super.c:14:
>>>>>> include/linux/fs.h:2151:23: note: declared here
>>>>>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>>>>>> ^~~~~~~~~~
>>>>>> drivers/staging/erofs/super.c: At top level:
>>>>>> drivers/staging/erofs/super.c:518:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>>>>> .mount = erofs_mount,
>>>>>> ^~~~~~~~~~~
>>>>>> drivers/staging/erofs/super.c:518:20: note: (near initialization for 'erofs_fs_type.mount')
>>>>>> drivers/staging/erofs/super.c: In function 'erofs_remount':
>>>>>> drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
>>>>>> *flags |= MS_RDONLY;
>>>>>> ^~~~~~~~~
>>>>>> IS_RDONLY
>>>>>> drivers/staging/erofs/super.c: At top level:
>>>>>> drivers/staging/erofs/super.c:640:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>>>>> .remount_fs = erofs_remount,
>>>>>> ^~~~~~~~~~~~~
>>>>>>
>>>>>> Caused by various commits creating erofs in the staging tree interacting
>>>>>> with various commits redoing the mount infrastructure in the vfs tree.
>>>>>>
>>>>>> I have disabed CONFIG_EROFS_FS for now:
>>>>
>>>> Xiang has submitted several patches as below to fix compiling error on -next
>>>> tree, could you consider to merge those temporary fixes into -next after merging
>>>> staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
>>>> compiling and test?
>>>>
>>>> staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
>>>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
>>>>
>>>> staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
>>>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
>>>>
>>>> staging: erofs: update .mount and .remount_sb
>>>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
>>>
>>> Why have these not been submitted to me for inclusion in my tree?
>> Oh, let me explain, that is because the compiling error only occurs in -next
>> tree, since -next collects and merges developing patches including common vfs
>> stuff from multi-trees, but those patches didn't cover erofs, such as:
>>
>> ('vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled")
>> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=for-next&id=109b45090d7d3ce2797bb1ef7f70eead5bfe0ff3
>>
>> ("vfs: Require specification of size of mount data for internal mounts")
>> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=for-next&id=0a191e4505a4f255e6513b49426213da69bf0e80
>>
>> As I checked, above vfs related patches has not been merged in staging tree, if
>> I submit those erofs patches to you and after including them in
>> staging-{test,nexts} tree, it can easily cause compiling error. So I just send
>> them to Stephen first for fixing integrity compiling error.
>>
>> Then I'd like to ask how to handle this condition to avoid potential conflict in
>> between erofs and vfs changes during merging window. As Stephen suggested, we
>> can disabling CONFIG_EROFS_FS temporarily to pass merge window, and after that
>> we reenable CONFIG_EROFS_FS and apply those fixing patches.
>
> Ok, doing that will work.
>
>> I'd like to ask and make sure, do you agree that we can handle the condition by
>> this way? or do you have any suggestion about solving this issue?
>
> This is a side affect of being in the staging tree only at this point in
> time. It will get easier once things get merged correctly.
Yeah, that's correct, so let me send one patch to disable CONFIG_EROFS_FS
temporarily. :)
Thanks,
>
> thanks,
>
> greg k-h
>
> .
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-08-02 7:01 ` Chao Yu
@ 2018-08-02 7:14 ` Greg KH
2018-08-02 7:48 ` Chao Yu
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2018-08-02 7:14 UTC (permalink / raw)
To: Chao Yu
Cc: Stephen Rothwell, Gao Xiang, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, David Howells, Miao Xie, Chao Yu
On Thu, Aug 02, 2018 at 03:01:59PM +0800, Chao Yu wrote:
> Hi Greg,
>
> On 2018/8/2 14:15, Greg KH wrote:
> > On Wed, Aug 01, 2018 at 05:09:13PM +0800, Chao Yu wrote:
> >> Hi Stephen,
> >>
> >> On 2018/7/30 14:31, Gao Xiang wrote:
> >>> Hi Stephen,
> >>>
> >>> On 2018/7/30 14:16, Stephen Rothwell wrote:
> >>>> Hi Greg,
> >>>>
> >>>> After merging the staging tree, today's linux-next build (x86_64
> >>>> allmodconfig) failed like this:
> >>>>
> >>>> drivers/staging/erofs/super.c: In function 'erofs_read_super':
> >>>> drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
> >>>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
> >>>> ^~~~~~~~~
> >>>> IS_RDONLY
> >>>> drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is reported only once for each function it appears in
> >>>> drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first use in this function); did you mean 'S_NOATIME'?
> >>>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
> >>>> ^~~~~~~~~~
> >>>> S_NOATIME
> >>>> drivers/staging/erofs/super.c: In function 'erofs_mount':
> >>>> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
> >>>> &priv, erofs_fill_super);
> >>>> ^~~~~~~~~~~~~~~~
> >>>> In file included from include/linux/buffer_head.h:12:0,
> >>>> from drivers/staging/erofs/super.c:14:
> >>>> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
> >>>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> >>>> ^~~~~~~~~~
> >>>> drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
> >>>> return mount_bdev(fs_type, flags, dev_name,
> >>>> ^~~~~~~~~~
> >>>> In file included from include/linux/buffer_head.h:12:0,
> >>>> from drivers/staging/erofs/super.c:14:
> >>>> include/linux/fs.h:2151:23: note: declared here
> >>>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> >>>> ^~~~~~~~~~
> >>>> drivers/staging/erofs/super.c: At top level:
> >>>> drivers/staging/erofs/super.c:518:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> >>>> .mount = erofs_mount,
> >>>> ^~~~~~~~~~~
> >>>> drivers/staging/erofs/super.c:518:20: note: (near initialization for 'erofs_fs_type.mount')
> >>>> drivers/staging/erofs/super.c: In function 'erofs_remount':
> >>>> drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
> >>>> *flags |= MS_RDONLY;
> >>>> ^~~~~~~~~
> >>>> IS_RDONLY
> >>>> drivers/staging/erofs/super.c: At top level:
> >>>> drivers/staging/erofs/super.c:640:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> >>>> .remount_fs = erofs_remount,
> >>>> ^~~~~~~~~~~~~
> >>>>
> >>>> Caused by various commits creating erofs in the staging tree interacting
> >>>> with various commits redoing the mount infrastructure in the vfs tree.
> >>>>
> >>>> I have disabed CONFIG_EROFS_FS for now:
> >>
> >> Xiang has submitted several patches as below to fix compiling error on -next
> >> tree, could you consider to merge those temporary fixes into -next after merging
> >> staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
> >> compiling and test?
> >>
> >> staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
> >> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
> >>
> >> staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
> >> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
> >>
> >> staging: erofs: update .mount and .remount_sb
> >> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
> >
> > Why have these not been submitted to me for inclusion in my tree?
> Oh, let me explain, that is because the compiling error only occurs in -next
> tree, since -next collects and merges developing patches including common vfs
> stuff from multi-trees, but those patches didn't cover erofs, such as:
>
> ('vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled")
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=for-next&id=109b45090d7d3ce2797bb1ef7f70eead5bfe0ff3
>
> ("vfs: Require specification of size of mount data for internal mounts")
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=for-next&id=0a191e4505a4f255e6513b49426213da69bf0e80
>
> As I checked, above vfs related patches has not been merged in staging tree, if
> I submit those erofs patches to you and after including them in
> staging-{test,nexts} tree, it can easily cause compiling error. So I just send
> them to Stephen first for fixing integrity compiling error.
>
> Then I'd like to ask how to handle this condition to avoid potential conflict in
> between erofs and vfs changes during merging window. As Stephen suggested, we
> can disabling CONFIG_EROFS_FS temporarily to pass merge window, and after that
> we reenable CONFIG_EROFS_FS and apply those fixing patches.
Ok, doing that will work.
> I'd like to ask and make sure, do you agree that we can handle the condition by
> this way? or do you have any suggestion about solving this issue?
This is a side affect of being in the staging tree only at this point in
time. It will get easier once things get merged correctly.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-08-02 6:15 ` Greg KH
@ 2018-08-02 7:01 ` Chao Yu
2018-08-02 7:14 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Chao Yu @ 2018-08-02 7:01 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Gao Xiang, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, David Howells, Miao Xie, Chao Yu
Hi Greg,
On 2018/8/2 14:15, Greg KH wrote:
> On Wed, Aug 01, 2018 at 05:09:13PM +0800, Chao Yu wrote:
>> Hi Stephen,
>>
>> On 2018/7/30 14:31, Gao Xiang wrote:
>>> Hi Stephen,
>>>
>>> On 2018/7/30 14:16, Stephen Rothwell wrote:
>>>> Hi Greg,
>>>>
>>>> After merging the staging tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> drivers/staging/erofs/super.c: In function 'erofs_read_super':
>>>> drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
>>>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>>>> ^~~~~~~~~
>>>> IS_RDONLY
>>>> drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is reported only once for each function it appears in
>>>> drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first use in this function); did you mean 'S_NOATIME'?
>>>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>>>> ^~~~~~~~~~
>>>> S_NOATIME
>>>> drivers/staging/erofs/super.c: In function 'erofs_mount':
>>>> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
>>>> &priv, erofs_fill_super);
>>>> ^~~~~~~~~~~~~~~~
>>>> In file included from include/linux/buffer_head.h:12:0,
>>>> from drivers/staging/erofs/super.c:14:
>>>> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
>>>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>>>> ^~~~~~~~~~
>>>> drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
>>>> return mount_bdev(fs_type, flags, dev_name,
>>>> ^~~~~~~~~~
>>>> In file included from include/linux/buffer_head.h:12:0,
>>>> from drivers/staging/erofs/super.c:14:
>>>> include/linux/fs.h:2151:23: note: declared here
>>>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>>>> ^~~~~~~~~~
>>>> drivers/staging/erofs/super.c: At top level:
>>>> drivers/staging/erofs/super.c:518:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>>> .mount = erofs_mount,
>>>> ^~~~~~~~~~~
>>>> drivers/staging/erofs/super.c:518:20: note: (near initialization for 'erofs_fs_type.mount')
>>>> drivers/staging/erofs/super.c: In function 'erofs_remount':
>>>> drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
>>>> *flags |= MS_RDONLY;
>>>> ^~~~~~~~~
>>>> IS_RDONLY
>>>> drivers/staging/erofs/super.c: At top level:
>>>> drivers/staging/erofs/super.c:640:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>>>> .remount_fs = erofs_remount,
>>>> ^~~~~~~~~~~~~
>>>>
>>>> Caused by various commits creating erofs in the staging tree interacting
>>>> with various commits redoing the mount infrastructure in the vfs tree.
>>>>
>>>> I have disabed CONFIG_EROFS_FS for now:
>>
>> Xiang has submitted several patches as below to fix compiling error on -next
>> tree, could you consider to merge those temporary fixes into -next after merging
>> staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
>> compiling and test?
>>
>> staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
>>
>> staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
>>
>> staging: erofs: update .mount and .remount_sb
>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
>
> Why have these not been submitted to me for inclusion in my tree?
Oh, let me explain, that is because the compiling error only occurs in -next
tree, since -next collects and merges developing patches including common vfs
stuff from multi-trees, but those patches didn't cover erofs, such as:
('vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled")
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=for-next&id=109b45090d7d3ce2797bb1ef7f70eead5bfe0ff3
("vfs: Require specification of size of mount data for internal mounts")
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git/commit/?h=for-next&id=0a191e4505a4f255e6513b49426213da69bf0e80
As I checked, above vfs related patches has not been merged in staging tree, if
I submit those erofs patches to you and after including them in
staging-{test,nexts} tree, it can easily cause compiling error. So I just send
them to Stephen first for fixing integrity compiling error.
Then I'd like to ask how to handle this condition to avoid potential conflict in
between erofs and vfs changes during merging window. As Stephen suggested, we
can disabling CONFIG_EROFS_FS temporarily to pass merge window, and after that
we reenable CONFIG_EROFS_FS and apply those fixing patches.
I'd like to ask and make sure, do you agree that we can handle the condition by
this way? or do you have any suggestion about solving this issue?
Thanks,
>
> thanks,
>
> greg k-h
>
> .
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-08-01 9:09 ` Chao Yu
2018-08-01 15:07 ` Stephen Rothwell
@ 2018-08-02 6:15 ` Greg KH
2018-08-02 7:01 ` Chao Yu
1 sibling, 1 reply; 143+ messages in thread
From: Greg KH @ 2018-08-02 6:15 UTC (permalink / raw)
To: Chao Yu
Cc: Stephen Rothwell, Gao Xiang, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, David Howells, Miao Xie
On Wed, Aug 01, 2018 at 05:09:13PM +0800, Chao Yu wrote:
> Hi Stephen,
>
> On 2018/7/30 14:31, Gao Xiang wrote:
> > Hi Stephen,
> >
> > On 2018/7/30 14:16, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> After merging the staging tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/staging/erofs/super.c: In function 'erofs_read_super':
> >> drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
> >> sb->s_flags |= MS_RDONLY | MS_NOATIME;
> >> ^~~~~~~~~
> >> IS_RDONLY
> >> drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is reported only once for each function it appears in
> >> drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first use in this function); did you mean 'S_NOATIME'?
> >> sb->s_flags |= MS_RDONLY | MS_NOATIME;
> >> ^~~~~~~~~~
> >> S_NOATIME
> >> drivers/staging/erofs/super.c: In function 'erofs_mount':
> >> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
> >> &priv, erofs_fill_super);
> >> ^~~~~~~~~~~~~~~~
> >> In file included from include/linux/buffer_head.h:12:0,
> >> from drivers/staging/erofs/super.c:14:
> >> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
> >> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> >> ^~~~~~~~~~
> >> drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
> >> return mount_bdev(fs_type, flags, dev_name,
> >> ^~~~~~~~~~
> >> In file included from include/linux/buffer_head.h:12:0,
> >> from drivers/staging/erofs/super.c:14:
> >> include/linux/fs.h:2151:23: note: declared here
> >> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> >> ^~~~~~~~~~
> >> drivers/staging/erofs/super.c: At top level:
> >> drivers/staging/erofs/super.c:518:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> >> .mount = erofs_mount,
> >> ^~~~~~~~~~~
> >> drivers/staging/erofs/super.c:518:20: note: (near initialization for 'erofs_fs_type.mount')
> >> drivers/staging/erofs/super.c: In function 'erofs_remount':
> >> drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
> >> *flags |= MS_RDONLY;
> >> ^~~~~~~~~
> >> IS_RDONLY
> >> drivers/staging/erofs/super.c: At top level:
> >> drivers/staging/erofs/super.c:640:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> >> .remount_fs = erofs_remount,
> >> ^~~~~~~~~~~~~
> >>
> >> Caused by various commits creating erofs in the staging tree interacting
> >> with various commits redoing the mount infrastructure in the vfs tree.
> >>
> >> I have disabed CONFIG_EROFS_FS for now:
>
> Xiang has submitted several patches as below to fix compiling error on -next
> tree, could you consider to merge those temporary fixes into -next after merging
> staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
> compiling and test?
>
> staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
>
> staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
>
> staging: erofs: update .mount and .remount_sb
> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
Why have these not been submitted to me for inclusion in my tree?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-08-01 15:07 ` Stephen Rothwell
@ 2018-08-02 6:12 ` Chao Yu
0 siblings, 0 replies; 143+ messages in thread
From: Chao Yu @ 2018-08-02 6:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Gao Xiang, Greg KH, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, David Howells, Miao Xie, Linus,
Matthew Wilcox
Hi Stephen,
Sorry, yesterday I missed this email due to my email filter.
On 2018/8/1 23:07, Stephen Rothwell wrote:
> Hi Chao,
>
> On Wed, 1 Aug 2018 17:09:13 +0800 Chao Yu <yuchao0@huawei.com> wrote:
>>
>> Xiang has submitted several patches as below to fix compiling error on -next
>> tree, could you consider to merge those temporary fixes into -next after merging
>> staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
>> compiling and test?
>>
>> staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
>>
>> staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
>>
>> staging: erofs: update .mount and .remount_sb
>> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
>
> OK, I will apply those tomorrow (actually later today :-)) and and stop
> disabling CONFIG_EROFS_FS.
OK, thanks for doing that, I and Xiang will keep an eye on compile result.
>
>> BTW, for this condition that erofs was not covered by some common vfs
>> stuff changes in other one's tree, who should take care of those
>> missing fixes during coming next merge window?
>
> 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.
Thanks for the advice, I think that's a good way to solve the issue, let me send
a patch to disable erofs compiling temporarily to avoid conflict during merge
window. :)
Thanks,
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-08-01 9:09 ` Chao Yu
@ 2018-08-01 15:07 ` Stephen Rothwell
2018-08-02 6:12 ` Chao Yu
2018-08-02 6:15 ` Greg KH
1 sibling, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2018-08-01 15:07 UTC (permalink / raw)
To: Chao Yu
Cc: Gao Xiang, Greg KH, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, David Howells, Miao Xie, Linus,
Matthew Wilcox
[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]
Hi Chao,
On Wed, 1 Aug 2018 17:09:13 +0800 Chao Yu <yuchao0@huawei.com> wrote:
>
> Xiang has submitted several patches as below to fix compiling error on -next
> tree, could you consider to merge those temporary fixes into -next after merging
> staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
> compiling and test?
>
> staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
>
> staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
>
> staging: erofs: update .mount and .remount_sb
> https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
OK, I will apply those tomorrow (actually later today :-)) and and stop
disabling CONFIG_EROFS_FS.
> BTW, for this condition that erofs was not covered by some common vfs
> stuff changes in other one's tree, who should take care of those
> missing fixes during coming next merge window?
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.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-30 6:31 ` Gao Xiang
@ 2018-08-01 9:09 ` Chao Yu
2018-08-01 15:07 ` Stephen Rothwell
2018-08-02 6:15 ` Greg KH
0 siblings, 2 replies; 143+ messages in thread
From: Chao Yu @ 2018-08-01 9:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Gao Xiang, Greg KH, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, David Howells, Miao Xie
Hi Stephen,
On 2018/7/30 14:31, Gao Xiang wrote:
> Hi Stephen,
>
> On 2018/7/30 14:16, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> After merging the staging tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/staging/erofs/super.c: In function 'erofs_read_super':
>> drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>> ^~~~~~~~~
>> IS_RDONLY
>> drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first use in this function); did you mean 'S_NOATIME'?
>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>> ^~~~~~~~~~
>> S_NOATIME
>> drivers/staging/erofs/super.c: In function 'erofs_mount':
>> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
>> &priv, erofs_fill_super);
>> ^~~~~~~~~~~~~~~~
>> In file included from include/linux/buffer_head.h:12:0,
>> from drivers/staging/erofs/super.c:14:
>> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>> ^~~~~~~~~~
>> drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
>> return mount_bdev(fs_type, flags, dev_name,
>> ^~~~~~~~~~
>> In file included from include/linux/buffer_head.h:12:0,
>> from drivers/staging/erofs/super.c:14:
>> include/linux/fs.h:2151:23: note: declared here
>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>> ^~~~~~~~~~
>> drivers/staging/erofs/super.c: At top level:
>> drivers/staging/erofs/super.c:518:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>> .mount = erofs_mount,
>> ^~~~~~~~~~~
>> drivers/staging/erofs/super.c:518:20: note: (near initialization for 'erofs_fs_type.mount')
>> drivers/staging/erofs/super.c: In function 'erofs_remount':
>> drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
>> *flags |= MS_RDONLY;
>> ^~~~~~~~~
>> IS_RDONLY
>> drivers/staging/erofs/super.c: At top level:
>> drivers/staging/erofs/super.c:640:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
>> .remount_fs = erofs_remount,
>> ^~~~~~~~~~~~~
>>
>> Caused by various commits creating erofs in the staging tree interacting
>> with various commits redoing the mount infrastructure in the vfs tree.
>>
>> I have disabed CONFIG_EROFS_FS for now:
Xiang has submitted several patches as below to fix compiling error on -next
tree, could you consider to merge those temporary fixes into -next after merging
staging-next's updates, and reenable CONFIG_EROFS_FS for further integrity
compiling and test?
staging: erofs: fix superblock/inode flags (MS_RDONLY -> SB_RDONLY, S_NOATIME)
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
staging: erofs: remove RADIX_TREE_EXCEPTIONAL_{ENTRY, SHIFT}
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000283.html
staging: erofs: update .mount and .remount_sb
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000285.html
BTW, for this condition that erofs was not covered by some common vfs stuff
changes in other one's tree, who should take care of those missing fixes during
coming next merge window?
Thanks,
>
> I will fix them as soon as possible, and test it with the latest linux-next code.
> It seems caused by some vfs changes.
>
> Thanks,
> Gao Xiang
>
> .
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-30 11:18 ` David Howells
@ 2018-07-30 11:23 ` Gao Xiang
0 siblings, 0 replies; 143+ messages in thread
From: Gao Xiang @ 2018-07-30 11:23 UTC (permalink / raw)
To: David Howells
Cc: Stephen Rothwell, Greg KH, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, Miao Xie, Chao Yu
On 2018/7/30 19:18, David Howells wrote:
> Gao Xiang <gaoxiang25@huawei.com> wrote:
>
>> struct erofs_mount_private priv = {
>> .dev_name = dev_name,
>> .options = data
>> };
>> return mount_bdev(fs_type, flags, dev_name, &priv, erofs_fill_super);
>>
>>
>> However, I have no idea if it is safe to do so in the future, so I also
>> change it into a more stardard way.
>
> Hopefully, in the near future, you won't do it like this at all, but rather
> create an fs_context and then your filesystem would be able to munge that
> directly before calling mount_bdev().
>
OK, got you. Look forword to the new fs_context feature and thanks for your help :)
Thanks,
Gao Xiang
> David
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-30 9:47 ` David Howells
2018-07-30 10:45 ` Gao Xiang
@ 2018-07-30 11:18 ` David Howells
2018-07-30 11:23 ` Gao Xiang
1 sibling, 1 reply; 143+ messages in thread
From: David Howells @ 2018-07-30 11:18 UTC (permalink / raw)
To: Gao Xiang
Cc: dhowells, Stephen Rothwell, Greg KH, Al Viro,
Linux-Next Mailing List, Linux Kernel Mailing List, Miao Xie,
Chao Yu
Gao Xiang <gaoxiang25@huawei.com> wrote:
> struct erofs_mount_private priv = {
> .dev_name = dev_name,
> .options = data
> };
> return mount_bdev(fs_type, flags, dev_name, &priv, erofs_fill_super);
>
>
> However, I have no idea if it is safe to do so in the future, so I also
> change it into a more stardard way.
Hopefully, in the near future, you won't do it like this at all, but rather
create an fs_context and then your filesystem would be able to munge that
directly before calling mount_bdev().
David
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-30 9:47 ` David Howells
@ 2018-07-30 10:45 ` Gao Xiang
2018-07-30 11:18 ` David Howells
1 sibling, 0 replies; 143+ messages in thread
From: Gao Xiang @ 2018-07-30 10:45 UTC (permalink / raw)
To: David Howells
Cc: Stephen Rothwell, Greg KH, Al Viro, Linux-Next Mailing List,
Linux Kernel Mailing List, Miao Xie, Chao Yu
Hi David,
Thanks for your reply :)
On 2018/7/30 17:47, David Howells wrote:
> Gao Xiang <gaoxiang25@huawei.com> wrote:
>
>>> sb->s_flags |= MS_RDONLY | MS_NOATIME;
>
> This should be using SB_* rather than MS_* for interaction with sb->s_flags.
Yes, I saw the related discussion and your submission in the linux-fsdevel mailing list last year. :D
The code of erofs once had to support from 3.13 ~ the current kernel, therefore I didn't turn MS_RDONLY into SB_RDONLY.
But it seems that "vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled" tends to remove them all.
I have submitted a patch to linux-erofs mailing list for preview.
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000282.html
>
>>> drivers/staging/erofs/super.c: In function 'erofs_mount':
>>> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
>>> &priv, erofs_fill_super);
>>> ^~~~~~~~~~~~~~~~
>>> In file included from include/linux/buffer_head.h:12:0,
>>> from drivers/staging/erofs/super.c:14:
>>> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
>>> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
>>> ^~~~~~~~~~
>>> drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
>>> return mount_bdev(fs_type, flags, dev_name,
>>> ^~~~~~~~~~
>
> There's a patch in Al Viro's tree that passes a size_t argument indicating the
> size of the mount data from mount down into the filesystem and into the
> helpers as the data may be on a kernel stack or in kernel .rodata rather than
> in a full page of its own.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
>
> Currently this is commit 0a191e4505a4f255e6513b49426213da69bf0e80
>
> vfs: Require specification of size of mount data for internal mounts
I just fixed according to the latest linux-next tree (the same patchset, also for preview)
https://lists.ozlabs.org/pipermail/linux-erofs/2018-July/000284.html
Once I tend to use void *data to pass more mount arguments on stack, eg.
struct erofs_mount_private {
const char *dev_name;
char *options;
};
...
struct erofs_mount_private priv = {
.dev_name = dev_name,
.options = data
};
return mount_bdev(fs_type, flags, dev_name, &priv, erofs_fill_super);
However, I have no idea if it is safe to do so in the future, so I also change it into a more stardard way.
BTW, It seems that Greg's staging tree doesn't have Al Viro's submission...
And I have little experience to handle that, so I just ask Chao for help...
Thanks for your kindly reminder :)
Thanks,
Gao Xiang
>
> David
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-30 6:16 Stephen Rothwell
2018-07-30 6:31 ` Gao Xiang
@ 2018-07-30 9:47 ` David Howells
2018-07-30 10:45 ` Gao Xiang
2018-07-30 11:18 ` David Howells
1 sibling, 2 replies; 143+ messages in thread
From: David Howells @ 2018-07-30 9:47 UTC (permalink / raw)
To: Gao Xiang
Cc: dhowells, Stephen Rothwell, Greg KH, Al Viro,
Linux-Next Mailing List, Linux Kernel Mailing List, Miao Xie,
Chao Yu
Gao Xiang <gaoxiang25@huawei.com> wrote:
> > sb->s_flags |= MS_RDONLY | MS_NOATIME;
This should be using SB_* rather than MS_* for interaction with sb->s_flags.
> > drivers/staging/erofs/super.c: In function 'erofs_mount':
> > drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
> > &priv, erofs_fill_super);
> > ^~~~~~~~~~~~~~~~
> > In file included from include/linux/buffer_head.h:12:0,
> > from drivers/staging/erofs/super.c:14:
> > include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
> > extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> > ^~~~~~~~~~
> > drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
> > return mount_bdev(fs_type, flags, dev_name,
> > ^~~~~~~~~~
There's a patch in Al Viro's tree that passes a size_t argument indicating the
size of the mount data from mount down into the filesystem and into the
helpers as the data may be on a kernel stack or in kernel .rodata rather than
in a full page of its own.
https://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
Currently this is commit 0a191e4505a4f255e6513b49426213da69bf0e80
vfs: Require specification of size of mount data for internal mounts
David
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-30 6:16 Stephen Rothwell
@ 2018-07-30 6:31 ` Gao Xiang
2018-08-01 9:09 ` Chao Yu
2018-07-30 9:47 ` David Howells
1 sibling, 1 reply; 143+ messages in thread
From: Gao Xiang @ 2018-07-30 6:31 UTC (permalink / raw)
To: Stephen Rothwell, Greg KH, Al Viro
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
David Howells, Miao Xie, Chao Yu
Hi Stephen,
On 2018/7/30 14:16, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/erofs/super.c: In function 'erofs_read_super':
> drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
> sb->s_flags |= MS_RDONLY | MS_NOATIME;
> ^~~~~~~~~
> IS_RDONLY
> drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is reported only once for each function it appears in
> drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first use in this function); did you mean 'S_NOATIME'?
> sb->s_flags |= MS_RDONLY | MS_NOATIME;
> ^~~~~~~~~~
> S_NOATIME
> drivers/staging/erofs/super.c: In function 'erofs_mount':
> drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
> &priv, erofs_fill_super);
> ^~~~~~~~~~~~~~~~
> In file included from include/linux/buffer_head.h:12:0,
> from drivers/staging/erofs/super.c:14:
> include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> ^~~~~~~~~~
> drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
> return mount_bdev(fs_type, flags, dev_name,
> ^~~~~~~~~~
> In file included from include/linux/buffer_head.h:12:0,
> from drivers/staging/erofs/super.c:14:
> include/linux/fs.h:2151:23: note: declared here
> extern struct dentry *mount_bdev(struct file_system_type *fs_type,
> ^~~~~~~~~~
> drivers/staging/erofs/super.c: At top level:
> drivers/staging/erofs/super.c:518:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .mount = erofs_mount,
> ^~~~~~~~~~~
> drivers/staging/erofs/super.c:518:20: note: (near initialization for 'erofs_fs_type.mount')
> drivers/staging/erofs/super.c: In function 'erofs_remount':
> drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
> *flags |= MS_RDONLY;
> ^~~~~~~~~
> IS_RDONLY
> drivers/staging/erofs/super.c: At top level:
> drivers/staging/erofs/super.c:640:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .remount_fs = erofs_remount,
> ^~~~~~~~~~~~~
>
> Caused by various commits creating erofs in the staging tree interacting
> with various commits redoing the mount infrastructure in the vfs tree.
>
> I have disabed CONFIG_EROFS_FS for now:
I will fix them as soon as possible, and test it with the latest linux-next code.
It seems caused by some vfs changes.
Thanks,
Gao Xiang
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2018-07-30 6:16 Stephen Rothwell
2018-07-30 6:31 ` Gao Xiang
2018-07-30 9:47 ` David Howells
0 siblings, 2 replies; 143+ messages in thread
From: Stephen Rothwell @ 2018-07-30 6:16 UTC (permalink / raw)
To: Greg KH, Al Viro
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
David Howells, Gao Xiang, Miao Xie, Chao Yu
[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/erofs/super.c: In function 'erofs_read_super':
drivers/staging/erofs/super.c:343:17: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
sb->s_flags |= MS_RDONLY | MS_NOATIME;
^~~~~~~~~
IS_RDONLY
drivers/staging/erofs/super.c:343:17: note: each undeclared identifier is reported only once for each function it appears in
drivers/staging/erofs/super.c:343:29: error: 'MS_NOATIME' undeclared (first use in this function); did you mean 'S_NOATIME'?
sb->s_flags |= MS_RDONLY | MS_NOATIME;
^~~~~~~~~~
S_NOATIME
drivers/staging/erofs/super.c: In function 'erofs_mount':
drivers/staging/erofs/super.c:501:10: warning: passing argument 5 of 'mount_bdev' makes integer from pointer without a cast [-Wint-conversion]
&priv, erofs_fill_super);
^~~~~~~~~~~~~~~~
In file included from include/linux/buffer_head.h:12:0,
from drivers/staging/erofs/super.c:14:
include/linux/fs.h:2151:23: note: expected 'size_t {aka long unsigned int}' but argument is of type 'int (*)(struct super_block *, void *, int)'
extern struct dentry *mount_bdev(struct file_system_type *fs_type,
^~~~~~~~~~
drivers/staging/erofs/super.c:500:9: error: too few arguments to function 'mount_bdev'
return mount_bdev(fs_type, flags, dev_name,
^~~~~~~~~~
In file included from include/linux/buffer_head.h:12:0,
from drivers/staging/erofs/super.c:14:
include/linux/fs.h:2151:23: note: declared here
extern struct dentry *mount_bdev(struct file_system_type *fs_type,
^~~~~~~~~~
drivers/staging/erofs/super.c: At top level:
drivers/staging/erofs/super.c:518:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.mount = erofs_mount,
^~~~~~~~~~~
drivers/staging/erofs/super.c:518:20: note: (near initialization for 'erofs_fs_type.mount')
drivers/staging/erofs/super.c: In function 'erofs_remount':
drivers/staging/erofs/super.c:630:12: error: 'MS_RDONLY' undeclared (first use in this function); did you mean 'IS_RDONLY'?
*flags |= MS_RDONLY;
^~~~~~~~~
IS_RDONLY
drivers/staging/erofs/super.c: At top level:
drivers/staging/erofs/super.c:640:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.remount_fs = erofs_remount,
^~~~~~~~~~~~~
Caused by various commits creating erofs in the staging tree interacting
with various commits redoing the mount infrastructure in the vfs tree.
I have disabed CONFIG_EROFS_FS for now:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Jul 2018 16:10:57 +1000
Subject: [PATCH] disable erofs for now
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/erofs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/erofs/Kconfig b/drivers/staging/erofs/Kconfig
index 663b755bf2fb..b37d994aa687 100644
--- a/drivers/staging/erofs/Kconfig
+++ b/drivers/staging/erofs/Kconfig
@@ -3,6 +3,7 @@
config EROFS_FS
tristate "EROFS filesystem support"
depends on BLOCK
+ depends on BROKEN
help
EROFS(Enhanced Read-Only File System) is a lightweight
read-only file system with modern designs (eg. page-sized
--
2.18.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-17 6:49 ` Ivan Safonov
@ 2018-07-17 8:06 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2018-07-17 8:06 UTC (permalink / raw)
To: Ivan Safonov
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, Hans de Goede, Michael Straube
On Tue, Jul 17, 2018 at 09:49:45AM +0300, Ivan Safonov wrote:
> On 07/17/2018 09:28 AM, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/staging/rtl8188eu/core/rtw_security.c: In function 'rtw_tkip_decrypt':
> > drivers/staging/rtl8188eu/core/rtw_security.c:399:21: error: storage size of 'mycontext' isn't known
> > struct arc4context mycontext;
> > ^~~~~~~~~
> > drivers/staging/rtl8188eu/core/rtw_security.c:437:4: error: implicit declaration of function 'phase1' [-Werror=implicit-function-declaration]
> > phase1((u16 *)&ttkey[0], prwskey, &prxattrib->ta[0], pnh);
> > ^~~~~~
> > drivers/staging/rtl8188eu/core/rtw_security.c:438:4: error: implicit declaration of function 'phase2' [-Werror=implicit-function-declaration]
> > phase2(&rc4key[0], prwskey, (unsigned short *)&ttkey[0], pnl);
> > ^~~~~~
> > drivers/staging/rtl8188eu/core/rtw_security.c:442:4: error: implicit declaration of function 'arcfour_init'; did you mean 'rcu_init'? [-Werror=implicit-function-declaration]
> > arcfour_init(&mycontext, rc4key, 16);
> > ^~~~~~~~~~~~
> > rcu_init
> > drivers/staging/rtl8188eu/core/rtw_security.c:443:4: error: implicit declaration of function 'arcfour_encrypt'; did you mean 'rtw_wep_encrypt'? [-Werror=implicit-function-declaration]
> > arcfour_encrypt(&mycontext, payload, payload, length);
> > ^~~~~~~~~~~~~~~
> > rtw_wep_encrypt
> > drivers/staging/rtl8188eu/core/rtw_security.c:445:23: error: implicit declaration of function 'getcrc32'; did you mean 'get_cred'? [-Werror=implicit-function-declaration]
> > *((__le32 *)crc) = getcrc32(payload, length-4);
> > ^~~~~~~~
> > get_cred
> > drivers/staging/rtl8188eu/core/rtw_security.c:399:21: warning: unused variable 'mycontext' [-Wunused-variable]
> > struct arc4context mycontext;
> > ^~~~~~~~~
> >
> > Caused by commit
> >
> > 0d4876f4e977 ("staging:r8188eu: Use lib80211 to encrypt (TKIP) tx frames")
> >
> > interacting with commit
> >
> > 69a1d98c831e ("Revert "staging:r8188eu: Use lib80211 to support TKIP"")
> >
> > from the staging.current tree.
> >
> > I just reverted the staging.current commit ...
> >
> All commits using lib8022 in r8188eu cause the system to crash. I will
> revert 5 commits in the near future (2 for decryption and 3 for encryption)
> in one patch, it will be bit easier.
>
> I apologize for such an unpleasant situation.
Not a problem, thanks for fixing this up. If you need me to merge the
two branches together right now in order to make the patch apply easier,
please let me know and I will be glad to do so.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2018-07-17 6:28 Stephen Rothwell
@ 2018-07-17 6:49 ` Ivan Safonov
2018-07-17 8:06 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Ivan Safonov @ 2018-07-17 6:49 UTC (permalink / raw)
To: Stephen Rothwell, Greg KH
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Hans de Goede, Michael Straube
On 07/17/2018 09:28 AM, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/rtl8188eu/core/rtw_security.c: In function 'rtw_tkip_decrypt':
> drivers/staging/rtl8188eu/core/rtw_security.c:399:21: error: storage size of 'mycontext' isn't known
> struct arc4context mycontext;
> ^~~~~~~~~
> drivers/staging/rtl8188eu/core/rtw_security.c:437:4: error: implicit declaration of function 'phase1' [-Werror=implicit-function-declaration]
> phase1((u16 *)&ttkey[0], prwskey, &prxattrib->ta[0], pnh);
> ^~~~~~
> drivers/staging/rtl8188eu/core/rtw_security.c:438:4: error: implicit declaration of function 'phase2' [-Werror=implicit-function-declaration]
> phase2(&rc4key[0], prwskey, (unsigned short *)&ttkey[0], pnl);
> ^~~~~~
> drivers/staging/rtl8188eu/core/rtw_security.c:442:4: error: implicit declaration of function 'arcfour_init'; did you mean 'rcu_init'? [-Werror=implicit-function-declaration]
> arcfour_init(&mycontext, rc4key, 16);
> ^~~~~~~~~~~~
> rcu_init
> drivers/staging/rtl8188eu/core/rtw_security.c:443:4: error: implicit declaration of function 'arcfour_encrypt'; did you mean 'rtw_wep_encrypt'? [-Werror=implicit-function-declaration]
> arcfour_encrypt(&mycontext, payload, payload, length);
> ^~~~~~~~~~~~~~~
> rtw_wep_encrypt
> drivers/staging/rtl8188eu/core/rtw_security.c:445:23: error: implicit declaration of function 'getcrc32'; did you mean 'get_cred'? [-Werror=implicit-function-declaration]
> *((__le32 *)crc) = getcrc32(payload, length-4);
> ^~~~~~~~
> get_cred
> drivers/staging/rtl8188eu/core/rtw_security.c:399:21: warning: unused variable 'mycontext' [-Wunused-variable]
> struct arc4context mycontext;
> ^~~~~~~~~
>
> Caused by commit
>
> 0d4876f4e977 ("staging:r8188eu: Use lib80211 to encrypt (TKIP) tx frames")
>
> interacting with commit
>
> 69a1d98c831e ("Revert "staging:r8188eu: Use lib80211 to support TKIP"")
>
> from the staging.current tree.
>
> I just reverted the staging.current commit ...
>
All commits using lib8022 in r8188eu cause the system to crash. I will
revert 5 commits in the near future (2 for decryption and 3 for
encryption) in one patch, it will be bit easier.
I apologize for such an unpleasant situation.
Ivan Safonov.
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2018-07-17 6:28 Stephen Rothwell
2018-07-17 6:49 ` Ivan Safonov
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2018-07-17 6:28 UTC (permalink / raw)
To: Greg KH
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Hans de Goede, Ivan Safonov
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8188eu/core/rtw_security.c: In function 'rtw_tkip_decrypt':
drivers/staging/rtl8188eu/core/rtw_security.c:399:21: error: storage size of 'mycontext' isn't known
struct arc4context mycontext;
^~~~~~~~~
drivers/staging/rtl8188eu/core/rtw_security.c:437:4: error: implicit declaration of function 'phase1' [-Werror=implicit-function-declaration]
phase1((u16 *)&ttkey[0], prwskey, &prxattrib->ta[0], pnh);
^~~~~~
drivers/staging/rtl8188eu/core/rtw_security.c:438:4: error: implicit declaration of function 'phase2' [-Werror=implicit-function-declaration]
phase2(&rc4key[0], prwskey, (unsigned short *)&ttkey[0], pnl);
^~~~~~
drivers/staging/rtl8188eu/core/rtw_security.c:442:4: error: implicit declaration of function 'arcfour_init'; did you mean 'rcu_init'? [-Werror=implicit-function-declaration]
arcfour_init(&mycontext, rc4key, 16);
^~~~~~~~~~~~
rcu_init
drivers/staging/rtl8188eu/core/rtw_security.c:443:4: error: implicit declaration of function 'arcfour_encrypt'; did you mean 'rtw_wep_encrypt'? [-Werror=implicit-function-declaration]
arcfour_encrypt(&mycontext, payload, payload, length);
^~~~~~~~~~~~~~~
rtw_wep_encrypt
drivers/staging/rtl8188eu/core/rtw_security.c:445:23: error: implicit declaration of function 'getcrc32'; did you mean 'get_cred'? [-Werror=implicit-function-declaration]
*((__le32 *)crc) = getcrc32(payload, length-4);
^~~~~~~~
get_cred
drivers/staging/rtl8188eu/core/rtw_security.c:399:21: warning: unused variable 'mycontext' [-Wunused-variable]
struct arc4context mycontext;
^~~~~~~~~
Caused by commit
0d4876f4e977 ("staging:r8188eu: Use lib80211 to encrypt (TKIP) tx frames")
interacting with commit
69a1d98c831e ("Revert "staging:r8188eu: Use lib80211 to support TKIP"")
from the staging.current tree.
I just reverted the staging.current commit ...
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-09-26 3:54 Stephen Rothwell
@ 2017-09-26 6:15 ` Jonathan Cameron
0 siblings, 0 replies; 143+ messages in thread
From: Jonathan Cameron @ 2017-09-26 6:15 UTC (permalink / raw)
To: Stephen Rothwell, Greg KH
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Jonathan Cameron, Lars-Peter Clausen
On 26 September 2017 04:54:41 BST, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>Hi Greg,
>
>After merging the staging tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>drivers/iio/counter/stm32-lptimer-cnt.c:181:2: error: unknown field
>'driver_module' specified in initializer
> .driver_module = THIS_MODULE,
> ^
>In file included from include/linux/linkage.h:6:0,
> from include/linux/kernel.h:6,
> from include/asm-generic/bug.h:15,
> from arch/x86/include/asm/bug.h:81,
> from include/linux/bug.h:4,
> from include/linux/bitfield.h:18,
> from drivers/iio/counter/stm32-lptimer-cnt.c:13:
>include/linux/export.h:35:21: error: initialization from incompatible
>pointer type [-Werror=incompatible-pointer-types]
> #define THIS_MODULE (&__this_module)
> ^
>drivers/iio/counter/stm32-lptimer-cnt.c:181:19: note: in expansion of
>macro 'THIS_MODULE'
> .driver_module = THIS_MODULE,
> ^
>include/linux/export.h:35:21: note: (near initialization for
>'stm32_lptim_cnt_iio_info.write_raw_get_fmt')
> #define THIS_MODULE (&__this_module)
> ^
>drivers/iio/counter/stm32-lptimer-cnt.c:181:19: note: in expansion of
>macro 'THIS_MODULE'
> .driver_module = THIS_MODULE,
> ^
>
>Caused by commit
>
>97623c0a80a6 ("iio: drop iio_info.driver_module and
>iio_trigger_ops.owner.")
>
>I have used the staging tree from next-20170922 for today.
Sorry, my mess up. Will send a patch dropping that line shortly..
Jonathan
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2017-09-26 3:54 Stephen Rothwell
2017-09-26 6:15 ` Jonathan Cameron
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-09-26 3:54 UTC (permalink / raw)
To: Greg KH
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Jonathan Cameron, Lars-Peter Clausen
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/iio/counter/stm32-lptimer-cnt.c:181:2: error: unknown field 'driver_module' specified in initializer
.driver_module = THIS_MODULE,
^
In file included from include/linux/linkage.h:6:0,
from include/linux/kernel.h:6,
from include/asm-generic/bug.h:15,
from arch/x86/include/asm/bug.h:81,
from include/linux/bug.h:4,
from include/linux/bitfield.h:18,
from drivers/iio/counter/stm32-lptimer-cnt.c:13:
include/linux/export.h:35:21: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
#define THIS_MODULE (&__this_module)
^
drivers/iio/counter/stm32-lptimer-cnt.c:181:19: note: in expansion of macro 'THIS_MODULE'
.driver_module = THIS_MODULE,
^
include/linux/export.h:35:21: note: (near initialization for 'stm32_lptim_cnt_iio_info.write_raw_get_fmt')
#define THIS_MODULE (&__this_module)
^
drivers/iio/counter/stm32-lptimer-cnt.c:181:19: note: in expansion of macro 'THIS_MODULE'
.driver_module = THIS_MODULE,
^
Caused by commit
97623c0a80a6 ("iio: drop iio_info.driver_module and iio_trigger_ops.owner.")
I have used the staging tree from next-20170922 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-05-01 4:42 Stephen Rothwell
@ 2017-05-04 23:41 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2017-05-04 23:41 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Johannes Berg, Linux-Next Mailing List,
Linux Kernel Mailing List, Hans de Goede, Avraham Stern,
Luca Coelho
On Mon, May 01, 2017 at 02:42:18PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_indicate_connect':
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:552:6: error: passing argument 2 of 'cfg80211_roamed' from incompatible pointer type [-Werror=incompatible-pointer-types]
> , notify_channel
> ^
> In file included from drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
> from drivers/staging/rtl8723bs/include/osdep_service.h:23,
> from drivers/staging/rtl8723bs/include/drv_types.h:29,
> from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
> include/net/cfg80211.h:5435:6: note: expected 'struct cfg80211_roam_info *' but argument is of type 'struct ieee80211_channel *'
> void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
> ^
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:553:6: warning: passing argument 3 of 'cfg80211_roamed' makes integer from pointer without a cast [-Wint-conversion]
> , cur_network->network.MacAddress
> ^
> In file included from drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
> from drivers/staging/rtl8723bs/include/osdep_service.h:23,
> from drivers/staging/rtl8723bs/include/drv_types.h:29,
> from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
> include/net/cfg80211.h:5435:6: note: expected 'gfp_t {aka unsigned int}' but argument is of type 'unsigned char *'
> void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
> ^
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:551:3: error: too many arguments to function 'cfg80211_roamed'
> cfg80211_roamed(padapter->pnetdev
> ^
> In file included from drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
> from drivers/staging/rtl8723bs/include/osdep_service.h:23,
> from drivers/staging/rtl8723bs/include/drv_types.h:29,
> from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
> include/net/cfg80211.h:5435:6: note: declared here
> void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
> ^
>
> Caused by commit
>
> 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
>
> interacting with commit
>
> 29ce6ecbb83c ("cfg80211: unify cfg80211_roamed() and cfg80211_roamed_bss()")
>
> from the mac80211-next tree.
>
> I applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 1 May 2017 14:34:17 +1000
> Subject: [PATCH] staging: rtl8723bs: fix up for cfg80211_roamed() API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> index f092a72bffda..5e7a61f24f8d 100644
> --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> @@ -542,20 +542,24 @@ void rtw_cfg80211_indicate_connect(struct adapter *padapter)
> struct ieee80211_channel *notify_channel;
> u32 freq;
> u16 channel = cur_network->network.Configuration.DSConfig;
> + struct cfg80211_roam_info roam_info = {};
>
> freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
>
> notify_channel = ieee80211_get_channel(wiphy, freq);
>
> DBG_871X(FUNC_ADPT_FMT" call cfg80211_roamed\n", FUNC_ADPT_ARG(padapter));
> - cfg80211_roamed(padapter->pnetdev
> - , notify_channel
> - , cur_network->network.MacAddress
> - , pmlmepriv->assoc_req+sizeof(struct ieee80211_hdr_3addr)+2
> - , pmlmepriv->assoc_req_len-sizeof(struct ieee80211_hdr_3addr)-2
> - , pmlmepriv->assoc_rsp+sizeof(struct ieee80211_hdr_3addr)+6
> - , pmlmepriv->assoc_rsp_len-sizeof(struct ieee80211_hdr_3addr)-6
> - , GFP_ATOMIC);
> + roam_info.channel = notify_channel;
> + roam_info.bssid = cur_network->network.MacAddress;
> + roam_info.req_ie =
> + pmlmepriv->assoc_req+sizeof(struct ieee80211_hdr_3addr)+2;
> + roam_info.req_ie_len =
> + pmlmepriv->assoc_req_len-sizeof(struct ieee80211_hdr_3addr)-2;
> + roam_info.resp_ie =
> + pmlmepriv->assoc_rsp+sizeof(struct ieee80211_hdr_3addr)+6;
> + roam_info.resp_ie_len =
> + pmlmepriv->assoc_rsp_len-sizeof(struct ieee80211_hdr_3addr)-6;
> + cfg80211_roamed(padapter->pnetdev, &roam_info, GFP_ATOMIC);
> }
> else
> {
> --
> 2.11.0
>
Thanks for the patch, that's the joy of adding new drivers...
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2017-05-01 4:42 Stephen Rothwell
2017-05-04 23:41 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-05-01 4:42 UTC (permalink / raw)
To: Greg KH, Johannes Berg
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Hans de Goede, Avraham Stern, Luca Coelho
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_indicate_connect':
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:552:6: error: passing argument 2 of 'cfg80211_roamed' from incompatible pointer type [-Werror=incompatible-pointer-types]
, notify_channel
^
In file included from drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
from drivers/staging/rtl8723bs/include/osdep_service.h:23,
from drivers/staging/rtl8723bs/include/drv_types.h:29,
from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
include/net/cfg80211.h:5435:6: note: expected 'struct cfg80211_roam_info *' but argument is of type 'struct ieee80211_channel *'
void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:553:6: warning: passing argument 3 of 'cfg80211_roamed' makes integer from pointer without a cast [-Wint-conversion]
, cur_network->network.MacAddress
^
In file included from drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
from drivers/staging/rtl8723bs/include/osdep_service.h:23,
from drivers/staging/rtl8723bs/include/drv_types.h:29,
from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
include/net/cfg80211.h:5435:6: note: expected 'gfp_t {aka unsigned int}' but argument is of type 'unsigned char *'
void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
^
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:551:3: error: too many arguments to function 'cfg80211_roamed'
cfg80211_roamed(padapter->pnetdev
^
In file included from drivers/staging/rtl8723bs/include/osdep_service_linux.h:50:0,
from drivers/staging/rtl8723bs/include/osdep_service.h:23,
from drivers/staging/rtl8723bs/include/drv_types.h:29,
from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:17:
include/net/cfg80211.h:5435:6: note: declared here
void cfg80211_roamed(struct net_device *dev, struct cfg80211_roam_info *info,
^
Caused by commit
554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
interacting with commit
29ce6ecbb83c ("cfg80211: unify cfg80211_roamed() and cfg80211_roamed_bss()")
from the mac80211-next tree.
I applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 1 May 2017 14:34:17 +1000
Subject: [PATCH] staging: rtl8723bs: fix up for cfg80211_roamed() API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f092a72bffda..5e7a61f24f8d 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -542,20 +542,24 @@ void rtw_cfg80211_indicate_connect(struct adapter *padapter)
struct ieee80211_channel *notify_channel;
u32 freq;
u16 channel = cur_network->network.Configuration.DSConfig;
+ struct cfg80211_roam_info roam_info = {};
freq = rtw_ieee80211_channel_to_frequency(channel, NL80211_BAND_2GHZ);
notify_channel = ieee80211_get_channel(wiphy, freq);
DBG_871X(FUNC_ADPT_FMT" call cfg80211_roamed\n", FUNC_ADPT_ARG(padapter));
- cfg80211_roamed(padapter->pnetdev
- , notify_channel
- , cur_network->network.MacAddress
- , pmlmepriv->assoc_req+sizeof(struct ieee80211_hdr_3addr)+2
- , pmlmepriv->assoc_req_len-sizeof(struct ieee80211_hdr_3addr)-2
- , pmlmepriv->assoc_rsp+sizeof(struct ieee80211_hdr_3addr)+6
- , pmlmepriv->assoc_rsp_len-sizeof(struct ieee80211_hdr_3addr)-6
- , GFP_ATOMIC);
+ roam_info.channel = notify_channel;
+ roam_info.bssid = cur_network->network.MacAddress;
+ roam_info.req_ie =
+ pmlmepriv->assoc_req+sizeof(struct ieee80211_hdr_3addr)+2;
+ roam_info.req_ie_len =
+ pmlmepriv->assoc_req_len-sizeof(struct ieee80211_hdr_3addr)-2;
+ roam_info.resp_ie =
+ pmlmepriv->assoc_rsp+sizeof(struct ieee80211_hdr_3addr)+6;
+ roam_info.resp_ie_len =
+ pmlmepriv->assoc_rsp_len-sizeof(struct ieee80211_hdr_3addr)-6;
+ cfg80211_roamed(padapter->pnetdev, &roam_info, GFP_ATOMIC);
}
else
{
--
2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-27 4:20 Stephen Rothwell
@ 2017-04-30 12:15 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2017-04-30 12:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Johannes Berg, Linux-Next Mailing List,
Linux Kernel Mailing List, Hans de Goede, Arend Van Spriel
On Thu, Apr 27, 2017 at 02:20:21PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_preinit_wiphy':
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3409:18: error: 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' undeclared (first use in this function)
> wiphy->flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN;
> ^
>
> Caused by commit
>
> 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
>
> interacting with commit
>
> ca986ad9bcd3 ("nl80211: allow multiple active scheduled scan requests")
>
> from the mac80211-next tree.
>
> I applied the below merge fix patch.
>
> Also, I noticed that CONFIG_PNO_SUPPORT is checked for in several
> files, but there is no such Kconfig option ...
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 27 Apr 2017 14:12:12 +1000
> Subject: [PATCH] staging: merge fix for "nl80211: allow multiple active
> scheduled scan requests"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> index f17f4fbd3396..c1977b11b6ac 100644
> --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> @@ -3406,7 +3406,7 @@ static void rtw_cfg80211_preinit_wiphy(struct adapter *padapter, struct wiphy *w
> wiphy->flags |= WIPHY_FLAG_OFFCHAN_TX | WIPHY_FLAG_HAVE_AP_SME;
>
> #if defined(CONFIG_PM)
> - wiphy->flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN;
> + wiphy->max_sched_scan_reqs = 1;
> #ifdef CONFIG_PNO_SUPPORT
> wiphy->max_sched_scan_ssids = MAX_PNO_LIST_COUNT;
> #endif
Thanks for the patch, looks good to me.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2017-04-27 4:20 Stephen Rothwell
2017-04-30 12:15 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-04-27 4:20 UTC (permalink / raw)
To: Greg KH, Johannes Berg
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Hans de Goede, Arend Van Spriel
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_preinit_wiphy':
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3409:18: error: 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' undeclared (first use in this function)
wiphy->flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN;
^
Caused by commit
554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
interacting with commit
ca986ad9bcd3 ("nl80211: allow multiple active scheduled scan requests")
from the mac80211-next tree.
I applied the below merge fix patch.
Also, I noticed that CONFIG_PNO_SUPPORT is checked for in several
files, but there is no such Kconfig option ...
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 27 Apr 2017 14:12:12 +1000
Subject: [PATCH] staging: merge fix for "nl80211: allow multiple active
scheduled scan requests"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index f17f4fbd3396..c1977b11b6ac 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -3406,7 +3406,7 @@ static void rtw_cfg80211_preinit_wiphy(struct adapter *padapter, struct wiphy *w
wiphy->flags |= WIPHY_FLAG_OFFCHAN_TX | WIPHY_FLAG_HAVE_AP_SME;
#if defined(CONFIG_PM)
- wiphy->flags |= WIPHY_FLAG_SUPPORTS_SCHED_SCAN;
+ wiphy->max_sched_scan_reqs = 1;
#ifdef CONFIG_PNO_SUPPORT
wiphy->max_sched_scan_ssids = MAX_PNO_LIST_COUNT;
#endif
--
2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-18 6:26 ` Stephen Rothwell
@ 2017-04-18 11:16 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2017-04-18 11:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Alan Cox, Linux-Next Mailing List, Linux Kernel Mailing List
On Tue, Apr 18, 2017 at 04:26:52PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Tue, 18 Apr 2017 07:54:40 +0200 Greg KH <greg@kroah.com> wrote:
> >
> > On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote:
> > > Hi Greg,
> > >
> > > After merging the staging tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > make[7]: *** No rule to make target 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o', needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'. Stop.
> > >
> > > Caused by commit
> > >
> > > 7afe8f84f793 ("atomisp: remove UDS kernel code")
> > >
> > > I have used the staging tree from next-20170413 for today.
> >
> > Ok, the 0-day bot reported something odd like this, with Alan's original
> > patches, but I couldn't reproduce it, and then when I applied them, the
> > 0-day bot worked just fine. But now you are having the same issue.
> >
> > I'm totally confused, Alan, any ideas?
>
> Well, drivers/staging/media/atomisp/pci/atomisp2/Makefile lists
> css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o in atomisp-objs.
>
> The above commit deleted
> drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.c
{sigh} It was a long last week... My tree had a "stale" .o file laying
around from the previous build, I can reproduce this now, sorry for the
noise. I'll go fix it...
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-18 5:54 ` Greg KH
@ 2017-04-18 6:26 ` Stephen Rothwell
2017-04-18 11:16 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-04-18 6:26 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Cox, Linux-Next Mailing List, Linux Kernel Mailing List
Hi Greg,
On Tue, 18 Apr 2017 07:54:40 +0200 Greg KH <greg@kroah.com> wrote:
>
> On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > make[7]: *** No rule to make target 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o', needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'. Stop.
> >
> > Caused by commit
> >
> > 7afe8f84f793 ("atomisp: remove UDS kernel code")
> >
> > I have used the staging tree from next-20170413 for today.
>
> Ok, the 0-day bot reported something odd like this, with Alan's original
> patches, but I couldn't reproduce it, and then when I applied them, the
> 0-day bot worked just fine. But now you are having the same issue.
>
> I'm totally confused, Alan, any ideas?
Well, drivers/staging/media/atomisp/pci/atomisp2/Makefile lists
css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o in atomisp-objs.
The above commit deleted
drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.c
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-18 5:32 Stephen Rothwell
@ 2017-04-18 5:54 ` Greg KH
2017-04-18 6:26 ` Stephen Rothwell
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2017-04-18 5:54 UTC (permalink / raw)
To: Stephen Rothwell, Alan Cox
Cc: Linux-Next Mailing List, Linux Kernel Mailing List
On Tue, Apr 18, 2017 at 03:32:20PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> make[7]: *** No rule to make target 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o', needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'. Stop.
>
> Caused by commit
>
> 7afe8f84f793 ("atomisp: remove UDS kernel code")
>
> I have used the staging tree from next-20170413 for today.
Ok, the 0-day bot reported something odd like this, with Alan's original
patches, but I couldn't reproduce it, and then when I applied them, the
0-day bot worked just fine. But now you are having the same issue.
I'm totally confused, Alan, any ideas?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2017-04-18 5:32 Stephen Rothwell
2017-04-18 5:54 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-04-18 5:32 UTC (permalink / raw)
To: Greg KH; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Alan Cox
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
make[7]: *** No rule to make target 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o', needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'. Stop.
Caused by commit
7afe8f84f793 ("atomisp: remove UDS kernel code")
I have used the staging tree from next-20170413 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-11 5:38 ` Greg KH
@ 2017-04-11 5:48 ` Stephen Rothwell
0 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2017-04-11 5:48 UTC (permalink / raw)
To: Greg KH; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Hans de Goede
Hi Greg,
On Tue, 11 Apr 2017 07:38:32 +0200 Greg KH <greg@kroah.com> wrote:
>
> I should have this fixed now, sorry for taking so long.
Thanks and no worries.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-11 5:15 ` Greg KH
@ 2017-04-11 5:38 ` Greg KH
2017-04-11 5:48 ` Stephen Rothwell
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2017-04-11 5:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Hans de Goede
On Tue, Apr 11, 2017 at 07:15:42AM +0200, Greg KH wrote:
> On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (powerpc
> > allyesconfig - I presume that an x86_64 allyesconfig will fail the
> > same way) failed like this:
> >
> > drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function `.rtw_get_oper_ch':
> > (.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
> > drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined here
> >
> > and many, many more ...
> >
> > Presumably caused by commit
> >
> > 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
> >
> > I guess this driver was copied from drivers/staging/rtl8188eu/ at some
> > point and modified (or they have the same ancestor) since they share a
> > large number of global symbols.
> >
> > I have applied the following patch for today:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 11 Apr 2017 14:53:55 +1000
> > Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/staging/rtl8723bs/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/staging/rtl8723bs/Kconfig b/drivers/staging/rtl8723bs/Kconfig
> > index 71450eee3b28..04706d3148d6 100644
> > --- a/drivers/staging/rtl8723bs/Kconfig
> > +++ b/drivers/staging/rtl8723bs/Kconfig
> > @@ -1,6 +1,7 @@
> > config RTL8723BS
> > tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
> > depends on WLAN && MMC && CFG80211
> > + depends on BROKEN
> > select WIRELESS_EXT
> > select WEXT_PRIV
> > ---help---
>
> Yes, thanks, we are going to force this to be built as a module which
> should resolve the issues...
I should have this fixed now, sorry for taking so long.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-04-11 5:04 Stephen Rothwell
@ 2017-04-11 5:15 ` Greg KH
2017-04-11 5:38 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2017-04-11 5:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Hans de Goede
On Tue, Apr 11, 2017 at 03:04:40PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig - I presume that an x86_64 allyesconfig will fail the
> same way) failed like this:
>
> drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function `.rtw_get_oper_ch':
> (.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
> drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined here
>
> and many, many more ...
>
> Presumably caused by commit
>
> 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
>
> I guess this driver was copied from drivers/staging/rtl8188eu/ at some
> point and modified (or they have the same ancestor) since they share a
> large number of global symbols.
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 11 Apr 2017 14:53:55 +1000
> Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/rtl8723bs/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/rtl8723bs/Kconfig b/drivers/staging/rtl8723bs/Kconfig
> index 71450eee3b28..04706d3148d6 100644
> --- a/drivers/staging/rtl8723bs/Kconfig
> +++ b/drivers/staging/rtl8723bs/Kconfig
> @@ -1,6 +1,7 @@
> config RTL8723BS
> tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
> depends on WLAN && MMC && CFG80211
> + depends on BROKEN
> select WIRELESS_EXT
> select WEXT_PRIV
> ---help---
Yes, thanks, we are going to force this to be built as a module which
should resolve the issues...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2017-04-11 5:04 Stephen Rothwell
2017-04-11 5:15 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-04-11 5:04 UTC (permalink / raw)
To: Greg KH; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Hans de Goede
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig - I presume that an x86_64 allyesconfig will fail the
same way) failed like this:
drivers/staging/rtl8188eu/core/rtw_wlan_util.o: In function `.rtw_get_oper_ch':
(.text+0x9d0): multiple definition of `.rtw_get_oper_ch'
drivers/staging/rtl8723bs/core/rtw_wlan_util.o:(.text+0x9a0): first defined here
and many, many more ...
Presumably caused by commit
554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
I guess this driver was copied from drivers/staging/rtl8188eu/ at some
point and modified (or they have the same ancestor) since they share a
large number of global symbols.
I have applied the following patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 11 Apr 2017 14:53:55 +1000
Subject: [PATCH] staging: disable the rtl8723bs sdio wifi driver for now
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8723bs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8723bs/Kconfig b/drivers/staging/rtl8723bs/Kconfig
index 71450eee3b28..04706d3148d6 100644
--- a/drivers/staging/rtl8723bs/Kconfig
+++ b/drivers/staging/rtl8723bs/Kconfig
@@ -1,6 +1,7 @@
config RTL8723BS
tristate "Realtek RTL8723BS SDIO Wireless LAN NIC driver"
depends on WLAN && MMC && CFG80211
+ depends on BROKEN
select WIRELESS_EXT
select WEXT_PRIV
---help---
--
2.11.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2017-04-10 5:10 Stephen Rothwell
0 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2017-04-10 5:10 UTC (permalink / raw)
To: Greg KH; +Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Hans de Goede
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8723bs/core/rtw_ieee80211.c: In function 'rtw_macaddr_cfg':
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:22: error: implicit declaration of function 'of_get_property' [-Werror=implicit-function-declaration]
(addr = of_get_property(np, "local-mac-address", &len)) &&
^
drivers/staging/rtl8723bs/core/rtw_ieee80211.c:1193:20: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
(addr = of_get_property(np, "local-mac-address", &len)) &&
^
Caused by commit
554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
I have used the staging tree from next-20170407 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-03-07 9:49 ` Stephen Rothwell
@ 2017-03-07 12:24 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2017-03-07 12:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alan Cox
On Tue, Mar 07, 2017 at 08:49:47PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Tue, 7 Mar 2017 09:47:29 +0100 Greg KH <greg@kroah.com> wrote:
> >
> > I really can't duplicate this here, but you and the kbuild bot are
> > hitting this now. in drivers/staging/media/atomisp/Makefile we have:
> > LINUXINCLUDE += -I drivers/staging/media/atomisp/include/
> > to point the include path at where atomisp_gmin_platform.h is at.
> >
> > So I don't understand what is going on here. Alan, any hints?
>
> I use a separate object dir (O=...) so maybe you need
>
> LINUXINCLUDE += -I$(srctree)/drivers/staging/media/atomisp/include/
Ah! yeah, using LINUXINCLUDE sucks, I'll go make all of those include
files relative references to make just building a subdir work properly.
thanks for the pointer, this should get fixed in my tree soon...
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-03-07 8:47 ` Greg KH
@ 2017-03-07 9:49 ` Stephen Rothwell
2017-03-07 12:24 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2017-03-07 9:49 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alan Cox
Hi Greg,
On Tue, 7 Mar 2017 09:47:29 +0100 Greg KH <greg@kroah.com> wrote:
>
> I really can't duplicate this here, but you and the kbuild bot are
> hitting this now. in drivers/staging/media/atomisp/Makefile we have:
> LINUXINCLUDE += -I drivers/staging/media/atomisp/include/
> to point the include path at where atomisp_gmin_platform.h is at.
>
> So I don't understand what is going on here. Alan, any hints?
I use a separate object dir (O=...) so maybe you need
LINUXINCLUDE += -I$(srctree)/drivers/staging/media/atomisp/include/
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-03-07 1:25 Stephen Rothwell
2017-03-07 4:46 ` Greg KH
@ 2017-03-07 8:47 ` Greg KH
2017-03-07 9:49 ` Stephen Rothwell
1 sibling, 1 reply; 143+ messages in thread
From: Greg KH @ 2017-03-07 8:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alan Cox
On Tue, Mar 07, 2017 at 12:25:42PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/media/atomisp/i2c/mt9m114.c:38:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
> drivers/staging/media/atomisp/i2c/gc2235.c:32:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
> drivers/staging/media/atomisp/i2c/ov2722.c:32:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
I really can't duplicate this here, but you and the kbuild bot are
hitting this now. in drivers/staging/media/atomisp/Makefile we have:
LINUXINCLUDE += -I drivers/staging/media/atomisp/include/
to point the include path at where atomisp_gmin_platform.h is at.
So I don't understand what is going on here. Alan, any hints?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2017-03-07 1:25 Stephen Rothwell
@ 2017-03-07 4:46 ` Greg KH
2017-03-07 8:47 ` Greg KH
1 sibling, 0 replies; 143+ messages in thread
From: Greg KH @ 2017-03-07 4:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alan Cox
On Tue, Mar 07, 2017 at 12:25:42PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/media/atomisp/i2c/mt9m114.c:38:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
> drivers/staging/media/atomisp/i2c/gc2235.c:32:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
> drivers/staging/media/atomisp/i2c/ov2722.c:32:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
> drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c:25:35: fatal error: linux/vlv2_plat_clock.h: No such file or directory
> drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c:28:38: fatal error: asm/intel_mid_pcihelpers.h: No such file or directory
> drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:10:35: fatal error: linux/vlv2_plat_clock.h: No such file or directory
> In file included from drivers/staging/media/atomisp/pci/atomisp2/./atomisp_drvfs.c:26:0:
> drivers/staging/media/atomisp/pci/atomisp2/./atomisp_compat.h:27:27: fatal error: linux/atomisp.h: No such file or directory
>
> Caused by commit
>
> a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
>
> or maybe some of the followups?
>
> I have used the staging tree from next-20170306 for today.
I just got a report from the kbuild bot about this as well, it didn't
used to happen before, and I can't duplicate it myself. Alan, any hints
as to what broke here?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2017-03-07 1:25 Stephen Rothwell
2017-03-07 4:46 ` Greg KH
2017-03-07 8:47 ` Greg KH
0 siblings, 2 replies; 143+ messages in thread
From: Stephen Rothwell @ 2017-03-07 1:25 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alan Cox
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/media/atomisp/i2c/mt9m114.c:38:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
drivers/staging/media/atomisp/i2c/gc2235.c:32:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
drivers/staging/media/atomisp/i2c/ov2722.c:32:41: fatal error: linux/atomisp_gmin_platform.h: No such file or directory
drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c:25:35: fatal error: linux/vlv2_plat_clock.h: No such file or directory
drivers/staging/media/atomisp/platform/intel-mid/intel_mid_pcihelpers.c:28:38: fatal error: asm/intel_mid_pcihelpers.h: No such file or directory
drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c:10:35: fatal error: linux/vlv2_plat_clock.h: No such file or directory
In file included from drivers/staging/media/atomisp/pci/atomisp2/./atomisp_drvfs.c:26:0:
drivers/staging/media/atomisp/pci/atomisp2/./atomisp_compat.h:27:27: fatal error: linux/atomisp.h: No such file or directory
Caused by commit
a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
or maybe some of the followups?
I have used the staging tree from next-20170306 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2016-05-13 3:15 Stephen Rothwell
@ 2016-05-13 8:36 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2016-05-13 8:36 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Leon Romanovsky, linux-next, linux-kernel, Dmitry Eremin,
Li Dongyang, James Simmons, Christoph Hellwig, Bart Van Assche
On Fri, May 13, 2016 at 01:15:38PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1706:9:
> error: too few arguments to function 'ib_map_mr_sg'
> n = ib_map_mr_sg(mr, tx->tx_frags,
> ^
> In file included from /home/sfr/next/next/include/rdma/ib_addr.h:47:0,
> from /home/sfr/next/next/include/rdma/rdma_cm.h:39,
> from /home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h:63,
> from /home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:43:
> /home/sfr/next/next/include/rdma/ib_verbs.h:3147:5: note: declared here
> int ib_map_mr_sg(struct ib_mr *mr, struct scatterlist *sg, int sg_nents,
> ^
>
> Caused by commit
>
> 80e05b34f882 ("staging: lustre: o2iblnd: Add Fast Reg memory registration support")
>
> interacting with commits
>
> aa42d65b5e20 ("IB/core: allow passing mapping an offset into the SG in ib_map_mr_sg")
> f0cf99be3251 ("IB/core: Enhance ib_map_mr_sg()")
>
> from the rdma-leon-test tree.
>
> I added the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 13 May 2016 13:10:47 +1000
> Subject: [PATCH] staging: lustre: o2iblnd: fix for ib_map_mr_sg() API changes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> index d99b4fac0c39..6c59f2ff2220 100644
> --- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
> @@ -1704,7 +1704,7 @@ int kiblnd_fmr_pool_map(kib_fmr_poolset_t *fps, kib_tx_t *tx,
> }
>
> n = ib_map_mr_sg(mr, tx->tx_frags,
> - tx->tx_nfrags, PAGE_SIZE);
> + tx->tx_nfrags, NULL, PAGE_SIZE);
> if (unlikely(n != tx->tx_nfrags)) {
> CERROR("Failed to map mr %d/%d elements\n",
> n, tx->tx_nfrags);
Looks good, thanks for the fix.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2016-05-13 3:15 Stephen Rothwell
2016-05-13 8:36 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2016-05-13 3:15 UTC (permalink / raw)
To: Greg KH, Leon Romanovsky
Cc: linux-next, linux-kernel, Dmitry Eremin, Li Dongyang,
James Simmons, Christoph Hellwig, Bart Van Assche
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:1706:9:
error: too few arguments to function 'ib_map_mr_sg'
n = ib_map_mr_sg(mr, tx->tx_frags,
^
In file included from /home/sfr/next/next/include/rdma/ib_addr.h:47:0,
from /home/sfr/next/next/include/rdma/rdma_cm.h:39,
from /home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h:63,
from /home/sfr/next/next/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:43:
/home/sfr/next/next/include/rdma/ib_verbs.h:3147:5: note: declared here
int ib_map_mr_sg(struct ib_mr *mr, struct scatterlist *sg, int sg_nents,
^
Caused by commit
80e05b34f882 ("staging: lustre: o2iblnd: Add Fast Reg memory registration support")
interacting with commits
aa42d65b5e20 ("IB/core: allow passing mapping an offset into the SG in ib_map_mr_sg")
f0cf99be3251 ("IB/core: Enhance ib_map_mr_sg()")
from the rdma-leon-test tree.
I added the following merge fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 13 May 2016 13:10:47 +1000
Subject: [PATCH] staging: lustre: o2iblnd: fix for ib_map_mr_sg() API changes
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index d99b4fac0c39..6c59f2ff2220 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1704,7 +1704,7 @@ int kiblnd_fmr_pool_map(kib_fmr_poolset_t *fps, kib_tx_t *tx,
}
n = ib_map_mr_sg(mr, tx->tx_frags,
- tx->tx_nfrags, PAGE_SIZE);
+ tx->tx_nfrags, NULL, PAGE_SIZE);
if (unlikely(n != tx->tx_nfrags)) {
CERROR("Failed to map mr %d/%d elements\n",
n, tx->tx_nfrags);
--
2.7.0
--
Cheers,
Stephen Rothwell
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2015-06-03 7:16 Stephen Rothwell
@ 2015-06-03 7:23 ` Johannes Berg
0 siblings, 0 replies; 143+ messages in thread
From: Johannes Berg @ 2015-06-03 7:23 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, David Miller, netdev, linux-next, linux-kernel,
Arnd Bergmann, Johnny Kim
Hi Stephen, all,
> Caused by commit c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11
> driver") from the staging tree interacting with commit 80279fb7ba5b
> ("cfg80211: properly send NL80211_ATTR_DISCONNECTED_BY_AP in
> disconnect") from the net-next tree.
I thought I fixed it all, but it looks like this is a new driver.
> I applied the below merge fix patch (I didn't know if it should be
> "true" or "false" - advise would be nice).
As far as I can tell from looking at a few lines of context it's
handling a disconnect event from the firmware, which presumably sends
the event upon deauth from the AP; thus it should be 'true' instead,
since the argument says "from_ap".
johannes
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2015-06-03 7:16 Stephen Rothwell
2015-06-03 7:23 ` Johannes Berg
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2015-06-03 7:16 UTC (permalink / raw)
To: Greg KH, David Miller, netdev
Cc: linux-next, linux-kernel, Johannes Berg, Arnd Bergmann, Johnny Kim
[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:681:3: error: too few arguments to function 'cfg80211_disconnected'
cfg80211_disconnected(dev, pstrDisconnectNotifInfo->u16reason, pstrDisconnectNotifInfo->ie,
^
In file included from drivers/staging/wilc1000/wilc_wfi_netdevice.h:40:0,
from drivers/staging/wilc1000/wilc_wfi_cfgoperations.h:11,
from drivers/staging/wilc1000/wilc_wfi_cfgoperations.c:13:
include/net/cfg80211.h:4584:6: note: declared here
void cfg80211_disconnected(struct net_device *dev, u16 reason,
^
Caused by commit c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11
driver") from the staging tree interacting with commit 80279fb7ba5b
("cfg80211: properly send NL80211_ATTR_DISCONNECTED_BY_AP in
disconnect") from the net-next tree.
I applied the below merge fix patch (I didn't know if it should be
"true" or "false" - advise would be nice). However, there are still
way to many warnings from this driver, so I have disabled it again.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Jun 2015 17:09:03 +1000
Subject: [PATCH] staging: wilc1000: fix call to cfg80211_disconnecteddue to API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index f5eff0933e7d..1685669762e8 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -679,7 +679,7 @@ static void CfgConnectResult(tenuConnDisconnEvent enuConnDisconnEvent,
pstrDisconnectNotifInfo->u16reason = 1;
}
cfg80211_disconnected(dev, pstrDisconnectNotifInfo->u16reason, pstrDisconnectNotifInfo->ie,
- pstrDisconnectNotifInfo->ie_len, GFP_KERNEL);
+ pstrDisconnectNotifInfo->ie_len, false, GFP_KERNEL);
}
--
2.1.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2015-03-10 15:08 ` Greg KH
2015-03-10 15:53 ` Sudip Mukherjee
@ 2015-03-10 20:57 ` Stephen Rothwell
1 sibling, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2015-03-10 20:57 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Sudip Mukherjee
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
Hi Greg,
On Tue, 10 Mar 2015 16:08:15 +0100 Greg KH <greg@kroah.com> wrote:
>
> Sorry about that. Yes, I know it's a mess. The build error on ppc
> should now be fixed in my tree. The build warnings are still there
> (some are gone). I should just go fix them up myself, and will do so
> tonight if I don't get a patch from someone else that does so first...
>
> So it should be safe to enable again.
OK, will do.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2015-03-10 15:08 ` Greg KH
@ 2015-03-10 15:53 ` Sudip Mukherjee
2015-03-10 20:57 ` Stephen Rothwell
1 sibling, 0 replies; 143+ messages in thread
From: Sudip Mukherjee @ 2015-03-10 15:53 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Tue, Mar 10, 2015 at 04:08:15PM +0100, Greg KH wrote:
> On Tue, Mar 10, 2015 at 04:07:28PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > In file included from include/linux/module.h:17:0,
> > from drivers/staging/sm750fb/sm750.c:2:
> > drivers/staging/sm750fb/sm750.c: In function '__check_g_option':
> > drivers/staging/sm750fb/sm750.c:1436:14: error: 'g_option' undeclared (first use in this function)
> > module_param(g_option,charp,S_IRUGO);
<snip>
> > to enable it again.
>
> Sorry about that. Yes, I know it's a mess. The build error on ppc
> should now be fixed in my tree. The build warnings are still there
> (some are gone). I should just go fix them up myself, and will do so
> tonight if I don't get a patch from someone else that does so first...
>
> So it should be safe to enable again.
i am so sorry for the mess. I thought patchset to fix the build failures will buy me some time to fix the other warnings.
I am sending another series to fix the remainig warnings.
reagrds
sudip
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2015-03-10 5:07 Stephen Rothwell
@ 2015-03-10 15:08 ` Greg KH
2015-03-10 15:53 ` Sudip Mukherjee
2015-03-10 20:57 ` Stephen Rothwell
0 siblings, 2 replies; 143+ messages in thread
From: Greg KH @ 2015-03-10 15:08 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Sudip Mukherjee
On Tue, Mar 10, 2015 at 04:07:28PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> In file included from include/linux/module.h:17:0,
> from drivers/staging/sm750fb/sm750.c:2:
> drivers/staging/sm750fb/sm750.c: In function '__check_g_option':
> drivers/staging/sm750fb/sm750.c:1436:14: error: 'g_option' undeclared (first use in this function)
> module_param(g_option,charp,S_IRUGO);
> ^
>
> Caused by commit 81dee67e215b ("staging: sm750fb: add sm750 to staging").
>
> This driver also produced a large number of warnings ... a lot like this:
>
> drivers/staging/sm750fb/sm750.c: In function 'lynxfb_ops_mmap':
> drivers/staging/sm750fb/sm750.c:533:2: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
> printk("lynxfb mmap pgoff: %x\n", vma->vm_pgoff);
> ^
>
> Also note:
>
> In file included from drivers/staging/sm750fb/ddk750_mode.h:4:0,
> from drivers/staging/sm750fb/ddk750.h:15,
> from drivers/staging/sm750fb/sm750_hw.c:24:
> drivers/staging/sm750fb/ddk750_chip.h:4:0: warning: "SM750LE_REVISION_ID" redefined
> #define SM750LE_REVISION_ID (char)0xfe
> ^
> In file included from drivers/staging/sm750fb/sm750_hw.c:23:0:
> drivers/staging/sm750fb/sm750_hw.h:8:0: note: this is the location of the previous definition
> #define SM750LE_REVISION_ID (unsigned char)0xfe
> ^
>
> I have disabled this driver for now, please let me know when it is OK
> to enable it again.
Sorry about that. Yes, I know it's a mess. The build error on ppc
should now be fixed in my tree. The build warnings are still there
(some are gone). I should just go fix them up myself, and will do so
tonight if I don't get a patch from someone else that does so first...
So it should be safe to enable again.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2015-03-10 5:07 Stephen Rothwell
2015-03-10 15:08 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2015-03-10 5:07 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Sudip Mukherjee
[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig) failed like this:
In file included from include/linux/module.h:17:0,
from drivers/staging/sm750fb/sm750.c:2:
drivers/staging/sm750fb/sm750.c: In function '__check_g_option':
drivers/staging/sm750fb/sm750.c:1436:14: error: 'g_option' undeclared (first use in this function)
module_param(g_option,charp,S_IRUGO);
^
Caused by commit 81dee67e215b ("staging: sm750fb: add sm750 to staging").
This driver also produced a large number of warnings ... a lot like this:
drivers/staging/sm750fb/sm750.c: In function 'lynxfb_ops_mmap':
drivers/staging/sm750fb/sm750.c:533:2: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=]
printk("lynxfb mmap pgoff: %x\n", vma->vm_pgoff);
^
Also note:
In file included from drivers/staging/sm750fb/ddk750_mode.h:4:0,
from drivers/staging/sm750fb/ddk750.h:15,
from drivers/staging/sm750fb/sm750_hw.c:24:
drivers/staging/sm750fb/ddk750_chip.h:4:0: warning: "SM750LE_REVISION_ID" redefined
#define SM750LE_REVISION_ID (char)0xfe
^
In file included from drivers/staging/sm750fb/sm750_hw.c:23:0:
drivers/staging/sm750fb/sm750_hw.h:8:0: note: this is the location of the previous definition
#define SM750LE_REVISION_ID (unsigned char)0xfe
^
I have disabled this driver for now, please let me know when it is OK
to enable it again.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 Mar 2015 16:02:45 +1100
Subject: [PATCH] staging: disable the Silicon Motion SM750 framebuffer support
due to build problems
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/sm750fb/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index c40d088a4d3b..24f3a7f787da 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -1,6 +1,7 @@
config FB_SM750
tristate "Silicon Motion SM750 framebuffer support"
depends on FB && PCI
+ depends on BROKEN
help
Frame buffer driver for the Silicon Motion SM750 chip
with 2D accelearion and dual head support.
--
2.1.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-09-30 8:04 Stephen Rothwell
@ 2014-10-02 16:31 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2014-10-02 16:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tapasweni Pathak
On Tue, Sep 30, 2014 at 06:04:16PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/media/cxd2099/cxd2099.c: In function 'slot_reset':
> drivers/staging/media/cxd2099/cxd2099.c:537:4: error: expected ';' before 'if'
> if (ci->ready)
> ^
>
> Caused by commit 7b86477c0e5b ("staging: media: cxd2099: use
> usleep_range()").
>
> I have reverted that commit for today.
Now fixed, thanks.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2014-09-30 8:04 Stephen Rothwell
2014-10-02 16:31 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2014-09-30 8:04 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Tapasweni Pathak
[-- Attachment #1: Type: text/plain, Size: 485 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/media/cxd2099/cxd2099.c: In function 'slot_reset':
drivers/staging/media/cxd2099/cxd2099.c:537:4: error: expected ';' before 'if'
if (ci->ready)
^
Caused by commit 7b86477c0e5b ("staging: media: cxd2099: use
usleep_range()").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-06-20 4:18 Stephen Rothwell
2014-06-20 16:53 ` Greg KH
@ 2014-09-22 10:25 ` Geert Uytterhoeven
1 sibling, 0 replies; 143+ messages in thread
From: Geert Uytterhoeven @ 2014-09-22 10:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, Linux-Next, linux-kernel, Magnus Damm, devicetree
On Fri, Jun 20, 2014 at 6:18 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/staging/board/board.c: In function 'find_by_address':
> drivers/staging/board/board.c:14:3: error: implicit declaration of function 'of_can_translate_address' [-Werror=implicit-function-declaration]
> if (of_can_translate_address(dn)
> ^
>
> Caused by commit 382063d91e15 ("staging: board: Initial board staging
> support").
Or by commit d9c6866be8a145e32da616d8dcbae806032d75b5
Author: Rob Herring <robh@kernel.org>
Date: Wed May 7 15:23:56 2014 -0500
of: kill off of_can_translate_address
;-)
> I have disabled that driver for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 20 Jun 2014 14:14:17 +1000
> Subject: [PATCH] staging: board: disable
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/board/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
> index 09d94b48c9c9..7eda0b8b7aab 100644
> --- a/drivers/staging/board/Kconfig
> +++ b/drivers/staging/board/Kconfig
> @@ -1,6 +1,7 @@
> config STAGING_BOARD
> boolean "Staging Board Support"
> depends on OF_ADDRESS
> + depends on BROKEN
> help
> Select to enable per-board staging support code.
>
> --
> 2.0.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2014-08-17 22:47 Stephen Rothwell
0 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2014-08-17 22:47 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, navin patidar
[-- Attachment #1: Type: text/plain, Size: 7796 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc allyesconfig)
failed like this:
drivers/staging/built-in.o:(.opd+0xaab8): multiple definition of `rtl88e_phy_rf_config'
drivers/net/built-in.o:(.opd+0x78840): first defined here
drivers/staging/built-in.o:(.opd+0xa9f8): multiple definition of `rtl88e_download_fw'
drivers/net/built-in.o:(.opd+0x781b0): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_rf_config':
(.text+0xe0a00): multiple definition of `.rtl88e_phy_rf_config'
drivers/net/built-in.o:(.text+0xe85a48): first defined here
drivers/staging/built-in.o: In function `.rtl88e_download_fw':
(.text+0xdf28c): multiple definition of `.rtl88e_download_fw'
drivers/net/built-in.o:(.text+0xe6f330): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_mac_config':
(.text+0xdf984): multiple definition of `.rtl88e_phy_mac_config'
drivers/net/built-in.o:(.text+0xe84a8c): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_bb_config':
(.text+0xdfa2c): multiple definition of `.rtl88e_phy_bb_config'
drivers/net/built-in.o:(.text+0xe84d14): first defined here
drivers/staging/built-in.o:(.opd+0xaa58): multiple definition of `rtl88e_phy_bb_config'
drivers/net/built-in.o:(.opd+0x78828): first defined here
drivers/staging/built-in.o:(.opd+0xaa28): multiple definition of `rtl88e_phy_mac_config'
Caused by commits d6c28c23f89b ("staging: rtl8188eu: Cleanup firmware
initialization code") and 586b60877244 ("staging: rtl8188eu: Cleanup
and simplify RF configuration code") and probably others.
I applied this fix up patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 18 Aug 2014 08:40:48 +1000
Subject: [PATCH] staging: rtl8188eu: using unique names is good
fixes:
drivers/staging/built-in.o:(.opd+0xaab8): multiple definition of `rtl88e_phy_rf_config'
drivers/net/built-in.o:(.opd+0x78840): first defined here
drivers/staging/built-in.o:(.opd+0xa9f8): multiple definition of `rtl88e_download_fw'
drivers/net/built-in.o:(.opd+0x781b0): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_rf_config':
(.text+0xe0a00): multiple definition of `.rtl88e_phy_rf_config'
drivers/net/built-in.o:(.text+0xe85a48): first defined here
drivers/staging/built-in.o: In function `.rtl88e_download_fw':
(.text+0xdf28c): multiple definition of `.rtl88e_download_fw'
drivers/net/built-in.o:(.text+0xe6f330): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_mac_config':
(.text+0xdf984): multiple definition of `.rtl88e_phy_mac_config'
drivers/net/built-in.o:(.text+0xe84a8c): first defined here
drivers/staging/built-in.o: In function `.rtl88e_phy_bb_config':
(.text+0xdfa2c): multiple definition of `.rtl88e_phy_bb_config'
drivers/net/built-in.o:(.text+0xe84d14): first defined here
drivers/staging/built-in.o:(.opd+0xaa58): multiple definition of `rtl88e_phy_bb_config'
drivers/net/built-in.o:(.opd+0x78828): first defined here
drivers/staging/built-in.o:(.opd+0xaa28): multiple definition of `rtl88e_phy_mac_config'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c | 2 +-
drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c | 2 +-
drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c | 2 +-
drivers/staging/rtl8188eu/hal/fw.c | 2 +-
drivers/staging/rtl8188eu/hal/usb_halinit.c | 8 ++++----
drivers/staging/rtl8188eu/include/fw.h | 2 +-
drivers/staging/rtl8188eu/include/phy.h | 6 +++---
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c
index 00f9cd737193..0c5dc26fd5a2 100644
--- a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c
+++ b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_BB.c
@@ -687,7 +687,7 @@ static bool config_parafile(struct adapter *adapt)
return true;
}
-bool rtl88e_phy_bb_config(struct adapter *adapt)
+bool rtl88eu_phy_bb_config(struct adapter *adapt)
{
int rtstatus = true;
struct hal_data_8188e *hal_data = GET_HAL_DATA(adapt);
diff --git a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c
index ccca6a496b2b..7d22dd1abaed 100644
--- a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c
+++ b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_MAC.c
@@ -116,7 +116,7 @@ static u32 array_MAC_REG_8188E[] = {
0x70B, 0x00000087,
};
-bool rtl88e_phy_mac_config(struct adapter *adapt)
+bool rtl88eu_phy_mac_config(struct adapter *adapt)
{
u32 i;
u32 arraylength;
diff --git a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c
index 2648840f9e20..94ee740efd1f 100644
--- a/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c
+++ b/drivers/staging/rtl8188eu/hal/HalHWImg8188E_RF.c
@@ -312,7 +312,7 @@ static bool rtl88e_phy_rf6052_config(struct adapter *adapt)
return rf6052_conf_para(adapt);
}
-bool rtl88e_phy_rf_config(struct adapter *adapt)
+bool rtl88eu_phy_rf_config(struct adapter *adapt)
{
return rtl88e_phy_rf6052_config(adapt);
}
diff --git a/drivers/staging/rtl8188eu/hal/fw.c b/drivers/staging/rtl8188eu/hal/fw.c
index 09324ae80e72..17b7f3750547 100644
--- a/drivers/staging/rtl8188eu/hal/fw.c
+++ b/drivers/staging/rtl8188eu/hal/fw.c
@@ -181,7 +181,7 @@ exit:
return err;
}
-int rtl88e_download_fw(struct adapter *adapt)
+int rtl88eu_download_fw(struct adapter *adapt)
{
struct hal_data_8188e *rtlhal = GET_HAL_DATA(adapt);
struct dvobj_priv *dvobj = adapter_to_dvobj(adapt);
diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c b/drivers/staging/rtl8188eu/hal/usb_halinit.c
index c5559dfa4e92..1f057b32876d 100644
--- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
+++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
@@ -743,7 +743,7 @@ static u32 rtl8188eu_hal_init(struct adapter *Adapter)
Adapter->bFWReady = false;
haldata->fw_ractrl = false;
} else {
- status = rtl88e_download_fw(Adapter);
+ status = rtl88eu_download_fw(Adapter);
if (status) {
DBG_88E("%s: Download Firmware failed!!\n", __func__);
@@ -758,11 +758,11 @@ static u32 rtl8188eu_hal_init(struct adapter *Adapter)
}
rtl8188e_InitializeFirmwareVars(Adapter);
- rtl88e_phy_mac_config(Adapter);
+ rtl88eu_phy_mac_config(Adapter);
- rtl88e_phy_bb_config(Adapter);
+ rtl88eu_phy_bb_config(Adapter);
- rtl88e_phy_rf_config(Adapter);
+ rtl88eu_phy_rf_config(Adapter);
HAL_INIT_PROFILE_TAG(HAL_INIT_STAGES_EFUSE_PATCH);
status = rtl8188e_iol_efuse_patch(Adapter);
diff --git a/drivers/staging/rtl8188eu/include/fw.h b/drivers/staging/rtl8188eu/include/fw.h
index c7c7e7e5ffac..d5faaff3db59 100644
--- a/drivers/staging/rtl8188eu/include/fw.h
+++ b/drivers/staging/rtl8188eu/include/fw.h
@@ -54,6 +54,6 @@ struct rtl92c_firmware_header {
u32 rsvd5;
};
-int rtl88e_download_fw(struct adapter *adapt);
+int rtl88eu_download_fw(struct adapter *adapt);
#endif
diff --git a/drivers/staging/rtl8188eu/include/phy.h b/drivers/staging/rtl8188eu/include/phy.h
index 676a66c44264..e3efa8fd69a8 100644
--- a/drivers/staging/rtl8188eu/include/phy.h
+++ b/drivers/staging/rtl8188eu/include/phy.h
@@ -1,3 +1,3 @@
-bool rtl88e_phy_mac_config(struct adapter *adapt);
-bool rtl88e_phy_rf_config(struct adapter *adapt);
-bool rtl88e_phy_bb_config(struct adapter *adapt);
+bool rtl88eu_phy_mac_config(struct adapter *adapt);
+bool rtl88eu_phy_rf_config(struct adapter *adapt);
+bool rtl88eu_phy_bb_config(struct adapter *adapt);
--
2.1.0.rc1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-07-10 0:27 ` Stephen Rothwell
@ 2014-07-10 3:09 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2014-07-10 3:09 UTC (permalink / raw)
To: Stephen Rothwell, Magnus Damm; +Cc: linux-next, linux-kernel
On Thu, Jul 10, 2014 at 10:27:00AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Fri, 20 Jun 2014 09:53:53 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > On Fri, Jun 20, 2014 at 02:18:07PM +1000, Stephen Rothwell wrote:
> > > Hi Greg,
> > >
> > > After merging the staging tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > >
> > > drivers/staging/board/board.c: In function 'find_by_address':
> > > drivers/staging/board/board.c:14:3: error: implicit declaration of function 'of_can_translate_address' [-Werror=implicit-function-declaration]
> > > if (of_can_translate_address(dn)
> > > ^
> > >
> > > Caused by commit 382063d91e15 ("staging: board: Initial board staging
> > > support").
> > >
> > > I have disabled that driver for today.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Fri, 20 Jun 2014 14:14:17 +1000
> > > Subject: [PATCH] staging: board: disable
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > > drivers/staging/board/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
> > > index 09d94b48c9c9..7eda0b8b7aab 100644
> > > --- a/drivers/staging/board/Kconfig
> > > +++ b/drivers/staging/board/Kconfig
> > > @@ -1,6 +1,7 @@
> > > config STAGING_BOARD
> > > boolean "Staging Board Support"
> > > depends on OF_ADDRESS
> > > + depends on BROKEN
> > > help
> > > Select to enable per-board staging support code.
> > >
> >
> > Magnus, can you send me a proper patch for this to get the code back to
> > building condition?
>
> Ping?
Magnus went quiet...
Magnus?
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-06-20 16:53 ` Greg KH
@ 2014-07-10 0:27 ` Stephen Rothwell
2014-07-10 3:09 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2014-07-10 0:27 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Magnus Damm
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
Hi Greg,
On Fri, 20 Jun 2014 09:53:53 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Fri, Jun 20, 2014 at 02:18:07PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > drivers/staging/board/board.c: In function 'find_by_address':
> > drivers/staging/board/board.c:14:3: error: implicit declaration of function 'of_can_translate_address' [-Werror=implicit-function-declaration]
> > if (of_can_translate_address(dn)
> > ^
> >
> > Caused by commit 382063d91e15 ("staging: board: Initial board staging
> > support").
> >
> > I have disabled that driver for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 20 Jun 2014 14:14:17 +1000
> > Subject: [PATCH] staging: board: disable
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/staging/board/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
> > index 09d94b48c9c9..7eda0b8b7aab 100644
> > --- a/drivers/staging/board/Kconfig
> > +++ b/drivers/staging/board/Kconfig
> > @@ -1,6 +1,7 @@
> > config STAGING_BOARD
> > boolean "Staging Board Support"
> > depends on OF_ADDRESS
> > + depends on BROKEN
> > help
> > Select to enable per-board staging support code.
> >
>
> Magnus, can you send me a proper patch for this to get the code back to
> building condition?
Ping?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-06-20 4:18 Stephen Rothwell
@ 2014-06-20 16:53 ` Greg KH
2014-07-10 0:27 ` Stephen Rothwell
2014-09-22 10:25 ` Geert Uytterhoeven
1 sibling, 1 reply; 143+ messages in thread
From: Greg KH @ 2014-06-20 16:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Magnus Damm
On Fri, Jun 20, 2014 at 02:18:07PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/staging/board/board.c: In function 'find_by_address':
> drivers/staging/board/board.c:14:3: error: implicit declaration of function 'of_can_translate_address' [-Werror=implicit-function-declaration]
> if (of_can_translate_address(dn)
> ^
>
> Caused by commit 382063d91e15 ("staging: board: Initial board staging
> support").
>
> I have disabled that driver for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 20 Jun 2014 14:14:17 +1000
> Subject: [PATCH] staging: board: disable
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/board/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
> index 09d94b48c9c9..7eda0b8b7aab 100644
> --- a/drivers/staging/board/Kconfig
> +++ b/drivers/staging/board/Kconfig
> @@ -1,6 +1,7 @@
> config STAGING_BOARD
> boolean "Staging Board Support"
> depends on OF_ADDRESS
> + depends on BROKEN
> help
> Select to enable per-board staging support code.
>
Magnus, can you send me a proper patch for this to get the code back to
building condition?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2014-06-20 4:18 Stephen Rothwell
2014-06-20 16:53 ` Greg KH
2014-09-22 10:25 ` Geert Uytterhoeven
0 siblings, 2 replies; 143+ messages in thread
From: Stephen Rothwell @ 2014-06-20 4:18 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Magnus Damm
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/staging/board/board.c: In function 'find_by_address':
drivers/staging/board/board.c:14:3: error: implicit declaration of function 'of_can_translate_address' [-Werror=implicit-function-declaration]
if (of_can_translate_address(dn)
^
Caused by commit 382063d91e15 ("staging: board: Initial board staging
support").
I have disabled that driver for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 20 Jun 2014 14:14:17 +1000
Subject: [PATCH] staging: board: disable
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/board/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
index 09d94b48c9c9..7eda0b8b7aab 100644
--- a/drivers/staging/board/Kconfig
+++ b/drivers/staging/board/Kconfig
@@ -1,6 +1,7 @@
config STAGING_BOARD
boolean "Staging Board Support"
depends on OF_ADDRESS
+ depends on BROKEN
help
Select to enable per-board staging support code.
--
2.0.0
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-01-24 4:04 ` Stephen Rothwell
@ 2014-01-24 4:08 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2014-01-24 4:08 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Luis R. Rodriguez, David Miller
On Fri, Jan 24, 2014 at 03:04:01PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Thu, 23 Jan 2014 19:53:12 -0800 Greg KH <greg@kroah.com> wrote:
> >
> > On Fri, Jan 24, 2014 at 01:01:22PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the staging tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_beaconing_flags':
> > > drivers/staging/rtl8821ae/regd.c:200:20: error: 'IEEE80211_CHAN_NO_IBSS' undeclared (first use in this function)
> > > ch->flags &= ~IEEE80211_CHAN_NO_IBSS;
> >
> > Wait, I can't duplicate this at all here, either on just my staging-next
> > branch, or when merged together with Linus's tree.
> >
> > Can you send me your .config that you used to cause this to fail
> > (allmodconfig works just fine here.)
> >
> > Could this all be due to some wireless patches that aren't merged with
> > Linus yet but are in linux-next?
>
> Yep, commit 8fe02e167efa ("cfg80211: consolidate passive-scan and no-ibss
> flags") from the net-next tree.
Ah, that makes more sense now, thanks.
> > If this is going to be a pain, I can easily drop it all and just wait
> > for 3.15-rc1, but it being a stand-alone driver, that works for hardware
> > I have here (and rumor has it, Linus also has this box), I figured I
> > would try to stay ahead of the curve and get it merged :)
>
> That would require that I fix up the semantic merge conflicts on
> Tuesday (I have a long weekend). Unless you wait just until Dave merges
> his tree and then base on top of that (or do a back merge of Linus' tree).
I'll wait till Dave merges his tree and then fix it up here before
sending it on. After 3.14-rc1 is out is fine as well. Don't worry
about doing any work on your end, it's a staging driver, it isn't worth
it :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-01-24 3:53 ` Greg KH
@ 2014-01-24 4:04 ` Stephen Rothwell
2014-01-24 4:08 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2014-01-24 4:04 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Luis R. Rodriguez, David Miller
[-- Attachment #1: Type: text/plain, Size: 1569 bytes --]
Hi Greg,
On Thu, 23 Jan 2014 19:53:12 -0800 Greg KH <greg@kroah.com> wrote:
>
> On Fri, Jan 24, 2014 at 01:01:22PM +1100, Stephen Rothwell wrote:
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_beaconing_flags':
> > drivers/staging/rtl8821ae/regd.c:200:20: error: 'IEEE80211_CHAN_NO_IBSS' undeclared (first use in this function)
> > ch->flags &= ~IEEE80211_CHAN_NO_IBSS;
>
> Wait, I can't duplicate this at all here, either on just my staging-next
> branch, or when merged together with Linus's tree.
>
> Can you send me your .config that you used to cause this to fail
> (allmodconfig works just fine here.)
>
> Could this all be due to some wireless patches that aren't merged with
> Linus yet but are in linux-next?
Yep, commit 8fe02e167efa ("cfg80211: consolidate passive-scan and no-ibss
flags") from the net-next tree.
> If this is going to be a pain, I can easily drop it all and just wait
> for 3.15-rc1, but it being a stand-alone driver, that works for hardware
> I have here (and rumor has it, Linus also has this box), I figured I
> would try to stay ahead of the curve and get it merged :)
That would require that I fix up the semantic merge conflicts on
Tuesday (I have a long weekend). Unless you wait just until Dave merges
his tree and then base on top of that (or do a back merge of Linus' tree).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-01-24 2:01 Stephen Rothwell
2014-01-24 2:34 ` Greg KH
@ 2014-01-24 3:53 ` Greg KH
2014-01-24 4:04 ` Stephen Rothwell
1 sibling, 1 reply; 143+ messages in thread
From: Greg KH @ 2014-01-24 3:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
On Fri, Jan 24, 2014 at 01:01:22PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_beaconing_flags':
> drivers/staging/rtl8821ae/regd.c:200:20: error: 'IEEE80211_CHAN_NO_IBSS' undeclared (first use in this function)
> ch->flags &= ~IEEE80211_CHAN_NO_IBSS;
Wait, I can't duplicate this at all here, either on just my staging-next
branch, or when merged together with Linus's tree.
Can you send me your .config that you used to cause this to fail
(allmodconfig works just fine here.)
Could this all be due to some wireless patches that aren't merged with
Linus yet but are in linux-next?
If this is going to be a pain, I can easily drop it all and just wait
for 3.15-rc1, but it being a stand-alone driver, that works for hardware
I have here (and rumor has it, Linus also has this box), I figured I
would try to stay ahead of the curve and get it merged :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2014-01-24 2:01 Stephen Rothwell
@ 2014-01-24 2:34 ` Greg KH
2014-01-24 3:53 ` Greg KH
1 sibling, 0 replies; 143+ messages in thread
From: Greg KH @ 2014-01-24 2:34 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
On Fri, Jan 24, 2014 at 01:01:22PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_beaconing_flags':
> drivers/staging/rtl8821ae/regd.c:200:20: error: 'IEEE80211_CHAN_NO_IBSS' undeclared (first use in this function)
> ch->flags &= ~IEEE80211_CHAN_NO_IBSS;
> ^
> drivers/staging/rtl8821ae/regd.c:200:20: note: each undeclared identifier is reported only once for each function it appears in
> drivers/staging/rtl8821ae/regd.c:204:11: error: 'IEEE80211_CHAN_PASSIVE_SCAN' undeclared (first use in this function)
> ~IEEE80211_CHAN_PASSIVE_SCAN;
> ^
> drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_active_scan_flags':
> drivers/staging/rtl8821ae/regd.c:237:19: error: 'IEEE80211_CHAN_PASSIVE_SCAN' undeclared (first use in this function)
> if (ch->flags & IEEE80211_CHAN_PASSIVE_SCAN)
> ^
> drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_radar_flags':
> drivers/staging/rtl8821ae/regd.c:312:8: error: 'IEEE80211_CHAN_NO_IBSS' undeclared (first use in this function)
> IEEE80211_CHAN_NO_IBSS |
> ^
> drivers/staging/rtl8821ae/regd.c:313:8: error: 'IEEE80211_CHAN_PASSIVE_SCAN' undeclared (first use in this function)
> IEEE80211_CHAN_PASSIVE_SCAN;
> ^
> drivers/staging/rtl8821ae/regd.c: In function '_rtl_regd_init_wiphy':
> drivers/staging/rtl8821ae/regd.c:410:18: error: 'WIPHY_FLAG_CUSTOM_REGULATORY' undeclared (first use in this function)
> wiphy->flags |= WIPHY_FLAG_CUSTOM_REGULATORY;
> ^
> drivers/staging/rtl8821ae/regd.c:411:19: error: 'WIPHY_FLAG_STRICT_REGULATORY' undeclared (first use in this function)
> wiphy->flags &= ~WIPHY_FLAG_STRICT_REGULATORY;
> ^
> drivers/staging/rtl8821ae/regd.c:412:19: error: 'WIPHY_FLAG_DISABLE_BEACON_HINTS' undeclared (first use in this function)
> wiphy->flags &= ~WIPHY_FLAG_DISABLE_BEACON_HINTS;
> ^
> drivers/staging/rtl8821ae/base.c: In function '_rtl_init_mac80211':
> drivers/staging/rtl8821ae/base.c:372:4: error: 'struct ieee80211_hw' has no member named 'channel_change_time'
> hw->channel_change_time = 100;
> ^
> drivers/staging/rtl8821ae/base.c: In function 'rtl_beacon_statistic':
> drivers/staging/rtl8821ae/base.c:1185:2: error: implicit declaration of function 'compare_ether_addr' [-Werror=implicit-function-declaration]
> if (compare_ether_addr(hdr->addr3, rtlpriv->mac80211.bssid))
> ^
> drivers/staging/rtl8821ae/ps.c: In function 'rtl_swlps_beacon':
> drivers/staging/rtl8821ae/ps.c:530:2: error: implicit declaration of function 'compare_ether_addr' [-Werror=implicit-function-declaration]
> if (compare_ether_addr(hdr->addr3, rtlpriv->mac80211.bssid))
> ^
> drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8812ae_dm_txpwr_track_set_pwr':
> drivers/staging/rtl8821ae/rtl8821ae/dm.c:1476:5: warning: array subscript has type 'char' [-Wchar-subscripts]
> rtl_set_bbreg(hw, RA_TXSCALE, 0xFFE00000, rtl8812ae_txscaling_table[final_ofdm_swing_index]);
> ^
> drivers/staging/rtl8821ae/rtl8821ae/dm.c:1525:5: warning: array subscript has type 'char' [-Wchar-subscripts]
> rtl_set_bbreg(hw, RB_TXSCALE, 0xFFE00000, rtl8812ae_txscaling_table[final_ofdm_swing_index]);
> ^
> drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8821ae_dm_txpwr_track_set_pwr':
> drivers/staging/rtl8821ae/rtl8821ae/dm.c:2113:5: warning: array subscript has type 'char' [-Wchar-subscripts]
> rtl_set_bbreg(hw, RA_TXSCALE, 0xFFE00000, rtl8812ae_txscaling_table[final_ofdm_swing_index]);
> ^
> drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8821ae_dm_check_edca_turbo':
> drivers/staging/rtl8821ae/rtl8821ae/dm.c:2656:3: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'u64' [-Wformat=]
> RT_TRACE(COMP_TURBO, DBG_LOUD,
> ^
> drivers/staging/rtl8821ae/rtl8821ae/dm.c:2658:3: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'u64' [-Wformat=]
> RT_TRACE(COMP_TURBO, DBG_LOUD,
> ^
> drivers/staging/rtl8821ae/rtl8821ae/trx.c: In function '_rtl8821ae_translate_rx_signal_stuff':
> drivers/staging/rtl8821ae/rtl8821ae/trx.c:461:7: error: implicit declaration of function 'compare_ether_addr' [-Werror=implicit-function-declaration]
> (!compare_ether_addr(mac->bssid, (fc & IEEE80211_FCTL_TODS) ?
> ^
> drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8821ae_dm_clear_txpower_tracking_state':
> drivers/staging/rtl8821ae/rtl8821ae/dm.c:487:31: warning: iteration 2u invokes undefined behavior [-Waggressive-loop-optimizations]
> rtldm->bb_swing_idx_ofdm[p] = rtldm->default_ofdm_index;
> ^
> drivers/staging/rtl8821ae/rtl8821ae/dm.c:485:2: note: containing loop
> for (p = RF90_PATH_A; p < MAX_RF_PATH; ++p) {
> ^
>
> Caused by commit 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI
> WIFI driver"). Did you really want to merge a new driver right now, not
> wait until after the merge window?
Yes, it's stand-alone and worked for me and is shipping in at least one
distro already. Looks like I need another depends option in the Kconfig
file, I'll fix this up, thanks.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2014-01-24 2:01 Stephen Rothwell
2014-01-24 2:34 ` Greg KH
2014-01-24 3:53 ` Greg KH
0 siblings, 2 replies; 143+ messages in thread
From: Stephen Rothwell @ 2014-01-24 2:01 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 5944 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_beaconing_flags':
drivers/staging/rtl8821ae/regd.c:200:20: error: 'IEEE80211_CHAN_NO_IBSS' undeclared (first use in this function)
ch->flags &= ~IEEE80211_CHAN_NO_IBSS;
^
drivers/staging/rtl8821ae/regd.c:200:20: note: each undeclared identifier is reported only once for each function it appears in
drivers/staging/rtl8821ae/regd.c:204:11: error: 'IEEE80211_CHAN_PASSIVE_SCAN' undeclared (first use in this function)
~IEEE80211_CHAN_PASSIVE_SCAN;
^
drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_active_scan_flags':
drivers/staging/rtl8821ae/regd.c:237:19: error: 'IEEE80211_CHAN_PASSIVE_SCAN' undeclared (first use in this function)
if (ch->flags & IEEE80211_CHAN_PASSIVE_SCAN)
^
drivers/staging/rtl8821ae/regd.c: In function '_rtl_reg_apply_radar_flags':
drivers/staging/rtl8821ae/regd.c:312:8: error: 'IEEE80211_CHAN_NO_IBSS' undeclared (first use in this function)
IEEE80211_CHAN_NO_IBSS |
^
drivers/staging/rtl8821ae/regd.c:313:8: error: 'IEEE80211_CHAN_PASSIVE_SCAN' undeclared (first use in this function)
IEEE80211_CHAN_PASSIVE_SCAN;
^
drivers/staging/rtl8821ae/regd.c: In function '_rtl_regd_init_wiphy':
drivers/staging/rtl8821ae/regd.c:410:18: error: 'WIPHY_FLAG_CUSTOM_REGULATORY' undeclared (first use in this function)
wiphy->flags |= WIPHY_FLAG_CUSTOM_REGULATORY;
^
drivers/staging/rtl8821ae/regd.c:411:19: error: 'WIPHY_FLAG_STRICT_REGULATORY' undeclared (first use in this function)
wiphy->flags &= ~WIPHY_FLAG_STRICT_REGULATORY;
^
drivers/staging/rtl8821ae/regd.c:412:19: error: 'WIPHY_FLAG_DISABLE_BEACON_HINTS' undeclared (first use in this function)
wiphy->flags &= ~WIPHY_FLAG_DISABLE_BEACON_HINTS;
^
drivers/staging/rtl8821ae/base.c: In function '_rtl_init_mac80211':
drivers/staging/rtl8821ae/base.c:372:4: error: 'struct ieee80211_hw' has no member named 'channel_change_time'
hw->channel_change_time = 100;
^
drivers/staging/rtl8821ae/base.c: In function 'rtl_beacon_statistic':
drivers/staging/rtl8821ae/base.c:1185:2: error: implicit declaration of function 'compare_ether_addr' [-Werror=implicit-function-declaration]
if (compare_ether_addr(hdr->addr3, rtlpriv->mac80211.bssid))
^
drivers/staging/rtl8821ae/ps.c: In function 'rtl_swlps_beacon':
drivers/staging/rtl8821ae/ps.c:530:2: error: implicit declaration of function 'compare_ether_addr' [-Werror=implicit-function-declaration]
if (compare_ether_addr(hdr->addr3, rtlpriv->mac80211.bssid))
^
drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8812ae_dm_txpwr_track_set_pwr':
drivers/staging/rtl8821ae/rtl8821ae/dm.c:1476:5: warning: array subscript has type 'char' [-Wchar-subscripts]
rtl_set_bbreg(hw, RA_TXSCALE, 0xFFE00000, rtl8812ae_txscaling_table[final_ofdm_swing_index]);
^
drivers/staging/rtl8821ae/rtl8821ae/dm.c:1525:5: warning: array subscript has type 'char' [-Wchar-subscripts]
rtl_set_bbreg(hw, RB_TXSCALE, 0xFFE00000, rtl8812ae_txscaling_table[final_ofdm_swing_index]);
^
drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8821ae_dm_txpwr_track_set_pwr':
drivers/staging/rtl8821ae/rtl8821ae/dm.c:2113:5: warning: array subscript has type 'char' [-Wchar-subscripts]
rtl_set_bbreg(hw, RA_TXSCALE, 0xFFE00000, rtl8812ae_txscaling_table[final_ofdm_swing_index]);
^
drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8821ae_dm_check_edca_turbo':
drivers/staging/rtl8821ae/rtl8821ae/dm.c:2656:3: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'u64' [-Wformat=]
RT_TRACE(COMP_TURBO, DBG_LOUD,
^
drivers/staging/rtl8821ae/rtl8821ae/dm.c:2658:3: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 has type 'u64' [-Wformat=]
RT_TRACE(COMP_TURBO, DBG_LOUD,
^
drivers/staging/rtl8821ae/rtl8821ae/trx.c: In function '_rtl8821ae_translate_rx_signal_stuff':
drivers/staging/rtl8821ae/rtl8821ae/trx.c:461:7: error: implicit declaration of function 'compare_ether_addr' [-Werror=implicit-function-declaration]
(!compare_ether_addr(mac->bssid, (fc & IEEE80211_FCTL_TODS) ?
^
drivers/staging/rtl8821ae/rtl8821ae/dm.c: In function 'rtl8821ae_dm_clear_txpower_tracking_state':
drivers/staging/rtl8821ae/rtl8821ae/dm.c:487:31: warning: iteration 2u invokes undefined behavior [-Waggressive-loop-optimizations]
rtldm->bb_swing_idx_ofdm[p] = rtldm->default_ofdm_index;
^
drivers/staging/rtl8821ae/rtl8821ae/dm.c:485:2: note: containing loop
for (p = RF90_PATH_A; p < MAX_RF_PATH; ++p) {
^
Caused by commit 3c05bedb5fef ("Staging: rtl8812ae: Add Realtek 8821 PCI
WIFI driver"). Did you really want to merge a new driver right now, not
wait until after the merge window?
I have disabled that driver for today using this patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 24 Jan 2014 12:57:38 +1100
Subject: [PATCH] Staging: rtl8812ae: disable due to build errors
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8821ae/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8821ae/Kconfig b/drivers/staging/rtl8821ae/Kconfig
index 2aa5dac2f1df..a432e1aa7405 100644
--- a/drivers/staging/rtl8821ae/Kconfig
+++ b/drivers/staging/rtl8821ae/Kconfig
@@ -2,6 +2,7 @@ config R8821AE
tristate "RealTek RTL8821AE Wireless LAN NIC driver"
depends on PCI && WLAN
depends on m
+ depends on BROKEN
select WIRELESS_EXT
select WEXT_PRIV
select EEPROM_93CX6
--
1.8.5.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-07-26 23:28 ` Greg KH
@ 2013-07-27 13:30 ` Eli Billauer
0 siblings, 0 replies; 143+ messages in thread
From: Eli Billauer @ 2013-07-27 13:30 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel
Hello Greg,
I upgraded sparse 0.4.2 -> 0.4.4 and now we see the same error messages.
It will take me a few days to prepare a patch for that.
Thanks for your patience.
Eli
On 27/07/13 02:28, Greg KH wrote:
> $ make M=drivers/staging/xillybus/ C=1
> LD drivers/staging/xillybus//built-in.o
> CHECK drivers/staging/xillybus//xillybus_core.c
> drivers/staging/xillybus//xillybus_core.c:76:25: warning: symbol 'xillybus_wq' was not declared. Should it be static?
> drivers/staging/xillybus//xillybus_core.c:175:57: warning: incorrect type in argument 2 (different address spaces)
> drivers/staging/xillybus//xillybus_core.c:175:57: expected void [noderef]<asn:2>*<noident>
> drivers/staging/xillybus//xillybus_core.c:175:57: got unsigned int [usertype] *
> drivers/staging/xillybus//xillybus_core.c:309:39: warning: incorrect type in argument 2 (different address spaces)
> drivers/staging/xillybus//xillybus_core.c:309:39: expected void [noderef]<asn:2>*<noident>
> drivers/staging/xillybus//xillybus_core.c:309:39: got unsigned int [usertype] *
> drivers/staging/xillybus//xillybus_core.c:606:55: warning: incorrect type in argument 2 (different address spaces)
> drivers/staging/xillybus//xillybus_core.c:606:55: expected void [noderef]<asn:2>*<noident>
> drivers/staging/xillybus//xillybus_core.c:606:55: got unsigned int [usertype] *
>
> and goes on for a few screens.
>
> $ sparse --version
> 0.4.4
>
> Try a newer version and see if that fixes things.
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-07-26 22:54 ` Eli Billauer
@ 2013-07-26 23:28 ` Greg KH
2013-07-27 13:30 ` Eli Billauer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2013-07-26 23:28 UTC (permalink / raw)
To: Eli Billauer; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Sat, Jul 27, 2013 at 01:54:44AM +0300, Eli Billauer wrote:
> On 27/07/13 00:56, Greg KH wrote:
> >No, I need you to do that. Can you do a kernel build with:
> > make M=drivers/staging/xillybus C=1
> >and fix up the errors that sparse reports and send a patch for that?
> >
> I'm not sure it's related to me. I get the same errors whether I
> compile my own modules or something in e.g. drivers/tty/ . This is
> what I get after make allmodconfig on the current staging git repo:
>
> $ make M=drivers/staging/xillybus C=1
> /home/eli/xillybus/submission/staging/arch/x86/Makefile:107:
> CONFIG_X86_X32 enabled but no binutils support
> CHECK drivers/staging/xillybus/xillybus_core.c
> /home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
> error: Expected ( after asm
> /home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
> error: got goto
> CC [M] drivers/staging/xillybus/xillybus_core.o
> CHECK drivers/staging/xillybus/xillybus_pcie.c
> /home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
> error: Expected ( after asm
> /home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
> error: got goto
> CC [M] drivers/staging/xillybus/xillybus_pcie.o
>
> I'll spare you the output from modules in drivers/tty. But it's
> exactly the same messages on each of these modules.
>
> Am I doing something wrong?
Odd, you might need to upgrade the version of sparse you have. My
output looks like:
$ make M=drivers/staging/xillybus/ C=1
LD drivers/staging/xillybus//built-in.o
CHECK drivers/staging/xillybus//xillybus_core.c
drivers/staging/xillybus//xillybus_core.c:76:25: warning: symbol 'xillybus_wq' was not declared. Should it be static?
drivers/staging/xillybus//xillybus_core.c:175:57: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/xillybus//xillybus_core.c:175:57: expected void [noderef] <asn:2>*<noident>
drivers/staging/xillybus//xillybus_core.c:175:57: got unsigned int [usertype] *
drivers/staging/xillybus//xillybus_core.c:309:39: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/xillybus//xillybus_core.c:309:39: expected void [noderef] <asn:2>*<noident>
drivers/staging/xillybus//xillybus_core.c:309:39: got unsigned int [usertype] *
drivers/staging/xillybus//xillybus_core.c:606:55: warning: incorrect type in argument 2 (different address spaces)
drivers/staging/xillybus//xillybus_core.c:606:55: expected void [noderef] <asn:2>*<noident>
drivers/staging/xillybus//xillybus_core.c:606:55: got unsigned int [usertype] *
and goes on for a few screens.
$ sparse --version
0.4.4
Try a newer version and see if that fixes things.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-07-26 21:56 ` Greg KH
@ 2013-07-26 22:54 ` Eli Billauer
2013-07-26 23:28 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Eli Billauer @ 2013-07-26 22:54 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel
On 27/07/13 00:56, Greg KH wrote:
> No, I need you to do that. Can you do a kernel build with:
> make M=drivers/staging/xillybus C=1
> and fix up the errors that sparse reports and send a patch for that?
>
>
I'm not sure it's related to me. I get the same errors whether I compile
my own modules or something in e.g. drivers/tty/ . This is what I get
after make allmodconfig on the current staging git repo:
$ make M=drivers/staging/xillybus C=1
/home/eli/xillybus/submission/staging/arch/x86/Makefile:107:
CONFIG_X86_X32 enabled but no binutils support
CHECK drivers/staging/xillybus/xillybus_core.c
/home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
error: Expected ( after asm
/home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
error: got goto
CC [M] drivers/staging/xillybus/xillybus_core.o
CHECK drivers/staging/xillybus/xillybus_pcie.c
/home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
error: Expected ( after asm
/home/eli/xillybus/submission/staging/arch/x86/include/asm/jump_label.h:16:13:
error: got goto
CC [M] drivers/staging/xillybus/xillybus_pcie.o
I'll spare you the output from modules in drivers/tty. But it's exactly
the same messages on each of these modules.
Am I doing something wrong?
Regards,
Eli
P.S. Regarding the missing Reported-By header, I learned something new
today. Thanks. :)
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-07-26 21:22 ` Eli Billauer
@ 2013-07-26 21:56 ` Greg KH
2013-07-26 22:54 ` Eli Billauer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2013-07-26 21:56 UTC (permalink / raw)
To: Eli Billauer; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Sat, Jul 27, 2013 at 12:22:44AM +0300, Eli Billauer wrote:
> Hello Greg,
>
> I was just about to submit a patch fixing this issue. Should arrive
> in a few minutes. Sorry.
Got it, thanks.
> Will this be the follow-on patch you mentioned for fixing the
> "sparse errors" this driver produced? I'm wasn't sure what you meant
> with that.
No, I need you to do that. Can you do a kernel build with:
make M=drivers/staging/xillybus C=1
and fix up the errors that sparse reports and send a patch for that?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-07-26 21:03 ` Greg KH
@ 2013-07-26 21:22 ` Eli Billauer
2013-07-26 21:56 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Eli Billauer @ 2013-07-26 21:22 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel
Hello Greg,
I was just about to submit a patch fixing this issue. Should arrive in a
few minutes. Sorry.
Will this be the follow-on patch you mentioned for fixing the "sparse
errors" this driver produced? I'm wasn't sure what you meant with that.
Oddly enough, I failed to repeat the compilation issue with allmodconfig
on x86_64, but it did appear on allyesconfig. The problem is obvious,
and it's strange my own test compilations went through even so.
Regards,
Eli
On 27/07/13 00:03, Greg KH wrote:
> On Fri, Jul 26, 2013 at 04:02:54PM +1000, Stephen Rothwell wrote:
>
>> Hi Greg,
>>
>> After merging the staging tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/staging/xillybus/xillybus_pcie.o:(.data+0x6d8): multiple definition of `xillyname'
>> drivers/staging/xillybus/xillybus_core.o:(.data+0x888): first defined here
>>
>> Caused by commit 48bae0507410 ("staging: New driver: Xillybus generic
>> interface for FPGA").
>>
>> I have disabled that driver.
>>
> I think I need to just always make any new staging driver only build as
> a module, and not allowed to be built into the kernel. That will save
> you time dealing with this, and me the extra time of marking them all as
> modules-only every time :)
>
> Sorry about this, I'll go fix this up now...
>
> greg k-h
>
>
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-07-26 6:02 Stephen Rothwell
@ 2013-07-26 21:03 ` Greg KH
2013-07-26 21:22 ` Eli Billauer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2013-07-26 21:03 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Eli Billauer
On Fri, Jul 26, 2013 at 04:02:54PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/xillybus/xillybus_pcie.o:(.data+0x6d8): multiple definition of `xillyname'
> drivers/staging/xillybus/xillybus_core.o:(.data+0x888): first defined here
>
> Caused by commit 48bae0507410 ("staging: New driver: Xillybus generic
> interface for FPGA").
>
> I have disabled that driver.
I think I need to just always make any new staging driver only build as
a module, and not allowed to be built into the kernel. That will save
you time dealing with this, and me the extra time of marking them all as
modules-only every time :)
Sorry about this, I'll go fix this up now...
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2013-07-26 6:02 Stephen Rothwell
2013-07-26 21:03 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2013-07-26 6:02 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Eli Billauer
[-- Attachment #1: Type: text/plain, Size: 483 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/xillybus/xillybus_pcie.o:(.data+0x6d8): multiple definition of `xillyname'
drivers/staging/xillybus/xillybus_core.o:(.data+0x888): first defined here
Caused by commit 48bae0507410 ("staging: New driver: Xillybus generic
interface for FPGA").
I have disabled that driver.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-07-25 3:19 Stephen Rothwell
@ 2013-07-25 4:25 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2013-07-25 4:25 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Won Kang
On Thu, Jul 25, 2013 at 01:19:59PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/gdm724x/built-in.o: In function `netlink_init':
> (.text+0x19b6): multiple definition of `netlink_init'
> drivers/staging/gdm72xx/built-in.o:(.text+0x19d5): first defined here
> drivers/staging/gdm724x/built-in.o: In function `netlink_exit':
> (.text+0x1a2a): multiple definition of `netlink_exit'
> drivers/staging/gdm72xx/built-in.o:(.text+0x1a49): first defined here
> drivers/staging/gdm724x/built-in.o: In function `netlink_send':
> (.text+0x1a4f): multiple definition of `netlink_send'
> drivers/staging/gdm72xx/built-in.o:(.text+0x1a67): first defined here
>
> Presumably caused by commit 61e121047645 ("staging: gdm7240: adding LTE
> USB driver"). I disabled this driver using this patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 25 Jul 2013 13:16:30 +1000
> Subject: [PATCH] staging: disable the gdm724x driver due to build problems
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/gdm724x/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/gdm724x/Kconfig b/drivers/staging/gdm724x/Kconfig
> index 10f7be1..85141bd 100644
> --- a/drivers/staging/gdm724x/Kconfig
> +++ b/drivers/staging/gdm724x/Kconfig
> @@ -5,6 +5,7 @@
> config LTE_GDM724X
> tristate "GCT GDM724x LTE support"
> depends on NET && USB
> + depends on BROKEN
Ugh, that means this can't be built into the kernel, due to symbol
issues, I'll go fix that up with a "depends on m" patch.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2013-07-25 3:19 Stephen Rothwell
2013-07-25 4:25 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2013-07-25 3:19 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Won Kang
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/gdm724x/built-in.o: In function `netlink_init':
(.text+0x19b6): multiple definition of `netlink_init'
drivers/staging/gdm72xx/built-in.o:(.text+0x19d5): first defined here
drivers/staging/gdm724x/built-in.o: In function `netlink_exit':
(.text+0x1a2a): multiple definition of `netlink_exit'
drivers/staging/gdm72xx/built-in.o:(.text+0x1a49): first defined here
drivers/staging/gdm724x/built-in.o: In function `netlink_send':
(.text+0x1a4f): multiple definition of `netlink_send'
drivers/staging/gdm72xx/built-in.o:(.text+0x1a67): first defined here
Presumably caused by commit 61e121047645 ("staging: gdm7240: adding LTE
USB driver"). I disabled this driver using this patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 25 Jul 2013 13:16:30 +1000
Subject: [PATCH] staging: disable the gdm724x driver due to build problems
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/gdm724x/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/gdm724x/Kconfig b/drivers/staging/gdm724x/Kconfig
index 10f7be1..85141bd 100644
--- a/drivers/staging/gdm724x/Kconfig
+++ b/drivers/staging/gdm724x/Kconfig
@@ -5,6 +5,7 @@
config LTE_GDM724X
tristate "GCT GDM724x LTE support"
depends on NET && USB
+ depends on BROKEN
help
This driver supports GCT GDM724x LTE chip based USB modem devices.
It exposes 4 network devices to be used per PDN and 2 tty devices to be
--
1.8.3.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-06-04 5:42 ` Greg KH
@ 2013-06-04 8:55 ` Peng Tao
0 siblings, 0 replies; 143+ messages in thread
From: Peng Tao @ 2013-06-04 8:55 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, Linux Kernel Mailing List,
Lukas Czerner, Theodore Ts'o, Andreas Dilger
On Tue, Jun 4, 2013 at 1:42 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Jun 04, 2013 at 02:57:00PM +1000, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> After merging the staging tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> In file included from drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:44:0,
>> from drivers/staging/lustre/lustre/fid/../include/linux/lvfs.h:48,
>> from drivers/staging/lustre/lustre/fid/../include/lvfs.h:45,
>> from drivers/staging/lustre/lustre/fid/../include/obd_support.h:41,
>> from drivers/staging/lustre/lustre/fid/../include/linux/obd.h:44,
>> from drivers/staging/lustre/lustre/fid/../include/obd.h:40,
>> from drivers/staging/lustre/lustre/fid/fid_store.c:48:
>> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h: In function 'truncate_complete_page':
>> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:56:3: error: too few arguments to function 'page->mapping->a_ops->invalidatepage'
>> page->mapping->a_ops->invalidatepage(page, 0);
>> ^
>>
>> Lots of times.
>>
>> Caused by the Lustre client patches interacting with commit d47992f86b30
>> ("mm: change invalidatepage prototype to accept length") from the ext4
>> tree.
>>
>> I added this merge fix patch:
>>
>> From 3873636f50eb89ba5e4f8e4e0523fd62f681edc8 Mon Sep 17 00:00:00 2001
>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>> Date: Tue, 4 Jun 2013 14:41:00 +1000
>> Subject: [PATCH] staging/lustre: fix for invalidatepage() API change
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
>> index f050808..67c4644 100644
>> --- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
>> +++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
>> @@ -53,7 +53,7 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
>> return;
>>
>> if (PagePrivate(page))
>> - page->mapping->a_ops->invalidatepage(page, 0);
>> + page->mapping->a_ops->invalidatepage(page, 0, PAGE_CACHE_SIZE);
>>
>> cancel_dirty_page(page, PAGE_SIZE);
>> ClearPageMappedToDisk(page);
>> --
>> 1.8.1
>>
>> diff --git a/drivers/staging/lustre/lustre/llite/rw26.c b/drivers/staging/lustre/lustre/llite/rw26.c
>> index 27e4e64..f1a1c5f 100644
>> --- a/drivers/staging/lustre/lustre/llite/rw26.c
>> +++ b/drivers/staging/lustre/lustre/llite/rw26.c
>> @@ -72,7 +72,8 @@
>> * aligned truncate). Lustre leaves partially truncated page in the cache,
>> * relying on struct inode::i_size to limit further accesses.
>> */
>> -static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
>> +static void ll_invalidatepage(struct page *vmpage, unsigned int offset,
>> + unsigned int length)
>> {
>> struct inode *inode;
>> struct lu_env *env;
>> @@ -89,7 +90,7 @@ static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
>> * below because they are run with page locked and all our io is
>> * happening with locked page too
>> */
>> - if (offset == 0) {
>> + if (offset == 0 && length == PAGE_CACHE_SIZE) {
>> env = cl_env_get(&refcheck);
>> if (!IS_ERR(env)) {
>> inode = vmpage->mapping->host;
>
> That patch makes sense.
>
> But then:
>
>> But then got these errors:
>>
>> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c: In function 'cfs_cpt_bind':
>> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c:630:3: error: implicit declaration of function 'set_cpus_allowed' [-Werror=implicit-function-declaration]
>> rc = set_cpus_allowed(current, *cpumask);
>> ^
>> cc1: some warnings being treated as errors
>> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'key_fini':
>> drivers/staging/lustre/lustre/obdclass/lu_object.c:1354:4: error: implicit declaration of function 'module_refcount' [-Werror=implicit-function-declaration]
>> LINVRNT(module_refcount(key->lct_owner) > 0);
>> ^
>> In file included from drivers/staging/lustre/include/linux/libcfs/libcfs.h:203:0,
>> from drivers/staging/lustre/lustre/obdclass/lu_object.c:47:
>> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'lu_context_keys_dump':
>> drivers/staging/lustre/lustre/obdclass/lu_object.c:1936:42: error: dereferencing pointer to incomplete type
>> key->lct_owner ? key->lct_owner->name : "",
>> ^
>> drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:221:41: note: in definition of macro '__CDEBUG'
>> libcfs_debug_msg(&msgdata, format, ## __VA_ARGS__); \
>> ^
>> drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:238:30: note: in expansion of macro 'CDEBUG_LIMIT'
>> #define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)
>> ^
>> drivers/staging/lustre/lustre/obdclass/lu_object.c:1932:4: note: in expansion of macro 'CERROR'
>> CERROR("[%d]: %p %x (%p,%p,%p) %d %d \"%s\"@%p\n",
>> ^
>> cc1: some warnings being treated as errors
>> drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c: In function 'ptlrpcd':
>> drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c:398:4: error: implicit declaration of function 'set_cpus_allowed' [-Werror=implicit-function-declaration]
>> cfs_set_cpus_allowed(current,
>> ^
>> cc1: some warnings being treated as errors
>
> That must be some #include files needed for ppc.
>
>> So I gave up and just reverted commit 52f6317528c6 ("staging/lustre: drop
>> CONFIG_BROKEN dependency") (thus disabling the code again) for now.
>
> That makes sense.
>
> Any of the lustre developers want to send me patches to fix the build
> issues up please?
Hi Greg,
I have just sent you a patch fixing the build failure. It was because
of some CONFIG_ options that Lustre was not well tested against.
1. set_cpus_allowed() is not available with CONFIG_CPUMASK_OFFSTACK on
2. CONFIG_MODULES may not be defined and it causes accessing
module->name field to fail.
3. CONFIG_MODULE_UNLOAD may not be defined, and it causes missing
module_refcount()
--
Thanks,
Tao
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-06-04 4:57 Stephen Rothwell
@ 2013-06-04 5:42 ` Greg KH
2013-06-04 8:55 ` Peng Tao
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2013-06-04 5:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Lukas Czerner, Theodore Ts'o,
Peng Tao, Andreas Dilger
On Tue, Jun 04, 2013 at 02:57:00PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:44:0,
> from drivers/staging/lustre/lustre/fid/../include/linux/lvfs.h:48,
> from drivers/staging/lustre/lustre/fid/../include/lvfs.h:45,
> from drivers/staging/lustre/lustre/fid/../include/obd_support.h:41,
> from drivers/staging/lustre/lustre/fid/../include/linux/obd.h:44,
> from drivers/staging/lustre/lustre/fid/../include/obd.h:40,
> from drivers/staging/lustre/lustre/fid/fid_store.c:48:
> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h: In function 'truncate_complete_page':
> drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:56:3: error: too few arguments to function 'page->mapping->a_ops->invalidatepage'
> page->mapping->a_ops->invalidatepage(page, 0);
> ^
>
> Lots of times.
>
> Caused by the Lustre client patches interacting with commit d47992f86b30
> ("mm: change invalidatepage prototype to accept length") from the ext4
> tree.
>
> I added this merge fix patch:
>
> From 3873636f50eb89ba5e4f8e4e0523fd62f681edc8 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 4 Jun 2013 14:41:00 +1000
> Subject: [PATCH] staging/lustre: fix for invalidatepage() API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
> index f050808..67c4644 100644
> --- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
> +++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
> @@ -53,7 +53,7 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
> return;
>
> if (PagePrivate(page))
> - page->mapping->a_ops->invalidatepage(page, 0);
> + page->mapping->a_ops->invalidatepage(page, 0, PAGE_CACHE_SIZE);
>
> cancel_dirty_page(page, PAGE_SIZE);
> ClearPageMappedToDisk(page);
> --
> 1.8.1
>
> diff --git a/drivers/staging/lustre/lustre/llite/rw26.c b/drivers/staging/lustre/lustre/llite/rw26.c
> index 27e4e64..f1a1c5f 100644
> --- a/drivers/staging/lustre/lustre/llite/rw26.c
> +++ b/drivers/staging/lustre/lustre/llite/rw26.c
> @@ -72,7 +72,8 @@
> * aligned truncate). Lustre leaves partially truncated page in the cache,
> * relying on struct inode::i_size to limit further accesses.
> */
> -static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
> +static void ll_invalidatepage(struct page *vmpage, unsigned int offset,
> + unsigned int length)
> {
> struct inode *inode;
> struct lu_env *env;
> @@ -89,7 +90,7 @@ static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
> * below because they are run with page locked and all our io is
> * happening with locked page too
> */
> - if (offset == 0) {
> + if (offset == 0 && length == PAGE_CACHE_SIZE) {
> env = cl_env_get(&refcheck);
> if (!IS_ERR(env)) {
> inode = vmpage->mapping->host;
That patch makes sense.
But then:
> But then got these errors:
>
> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c: In function 'cfs_cpt_bind':
> drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c:630:3: error: implicit declaration of function 'set_cpus_allowed' [-Werror=implicit-function-declaration]
> rc = set_cpus_allowed(current, *cpumask);
> ^
> cc1: some warnings being treated as errors
> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'key_fini':
> drivers/staging/lustre/lustre/obdclass/lu_object.c:1354:4: error: implicit declaration of function 'module_refcount' [-Werror=implicit-function-declaration]
> LINVRNT(module_refcount(key->lct_owner) > 0);
> ^
> In file included from drivers/staging/lustre/include/linux/libcfs/libcfs.h:203:0,
> from drivers/staging/lustre/lustre/obdclass/lu_object.c:47:
> drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'lu_context_keys_dump':
> drivers/staging/lustre/lustre/obdclass/lu_object.c:1936:42: error: dereferencing pointer to incomplete type
> key->lct_owner ? key->lct_owner->name : "",
> ^
> drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:221:41: note: in definition of macro '__CDEBUG'
> libcfs_debug_msg(&msgdata, format, ## __VA_ARGS__); \
> ^
> drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:238:30: note: in expansion of macro 'CDEBUG_LIMIT'
> #define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)
> ^
> drivers/staging/lustre/lustre/obdclass/lu_object.c:1932:4: note: in expansion of macro 'CERROR'
> CERROR("[%d]: %p %x (%p,%p,%p) %d %d \"%s\"@%p\n",
> ^
> cc1: some warnings being treated as errors
> drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c: In function 'ptlrpcd':
> drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c:398:4: error: implicit declaration of function 'set_cpus_allowed' [-Werror=implicit-function-declaration]
> cfs_set_cpus_allowed(current,
> ^
> cc1: some warnings being treated as errors
That must be some #include files needed for ppc.
> So I gave up and just reverted commit 52f6317528c6 ("staging/lustre: drop
> CONFIG_BROKEN dependency") (thus disabling the code again) for now.
That makes sense.
Any of the lustre developers want to send me patches to fix the build
issues up please?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2013-06-04 4:57 Stephen Rothwell
2013-06-04 5:42 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2013-06-04 4:57 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Lukas Czerner, Theodore Ts'o,
Peng Tao, Andreas Dilger
[-- Attachment #1: Type: text/plain, Size: 5643 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/staging/lustre/lustre/fid/../include/linux/lustre_compat25.h:44:0,
from drivers/staging/lustre/lustre/fid/../include/linux/lvfs.h:48,
from drivers/staging/lustre/lustre/fid/../include/lvfs.h:45,
from drivers/staging/lustre/lustre/fid/../include/obd_support.h:41,
from drivers/staging/lustre/lustre/fid/../include/linux/obd.h:44,
from drivers/staging/lustre/lustre/fid/../include/obd.h:40,
from drivers/staging/lustre/lustre/fid/fid_store.c:48:
drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h: In function 'truncate_complete_page':
drivers/staging/lustre/lustre/fid/../include/linux/lustre_patchless_compat.h:56:3: error: too few arguments to function 'page->mapping->a_ops->invalidatepage'
page->mapping->a_ops->invalidatepage(page, 0);
^
Lots of times.
Caused by the Lustre client patches interacting with commit d47992f86b30
("mm: change invalidatepage prototype to accept length") from the ext4
tree.
I added this merge fix patch:
From 3873636f50eb89ba5e4f8e4e0523fd62f681edc8 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 4 Jun 2013 14:41:00 +1000
Subject: [PATCH] staging/lustre: fix for invalidatepage() API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
index f050808..67c4644 100644
--- a/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
+++ b/drivers/staging/lustre/lustre/include/linux/lustre_patchless_compat.h
@@ -53,7 +53,7 @@ truncate_complete_page(struct address_space *mapping, struct page *page)
return;
if (PagePrivate(page))
- page->mapping->a_ops->invalidatepage(page, 0);
+ page->mapping->a_ops->invalidatepage(page, 0, PAGE_CACHE_SIZE);
cancel_dirty_page(page, PAGE_SIZE);
ClearPageMappedToDisk(page);
--
1.8.1
diff --git a/drivers/staging/lustre/lustre/llite/rw26.c b/drivers/staging/lustre/lustre/llite/rw26.c
index 27e4e64..f1a1c5f 100644
--- a/drivers/staging/lustre/lustre/llite/rw26.c
+++ b/drivers/staging/lustre/lustre/llite/rw26.c
@@ -72,7 +72,8 @@
* aligned truncate). Lustre leaves partially truncated page in the cache,
* relying on struct inode::i_size to limit further accesses.
*/
-static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
+static void ll_invalidatepage(struct page *vmpage, unsigned int offset,
+ unsigned int length)
{
struct inode *inode;
struct lu_env *env;
@@ -89,7 +90,7 @@ static void ll_invalidatepage(struct page *vmpage, unsigned long offset)
* below because they are run with page locked and all our io is
* happening with locked page too
*/
- if (offset == 0) {
+ if (offset == 0 && length == PAGE_CACHE_SIZE) {
env = cl_env_get(&refcheck);
if (!IS_ERR(env)) {
inode = vmpage->mapping->host;
But then got these errors:
drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c: In function 'cfs_cpt_bind':
drivers/staging/lustre/lustre/libcfs/linux/linux-cpu.c:630:3: error: implicit declaration of function 'set_cpus_allowed' [-Werror=implicit-function-declaration]
rc = set_cpus_allowed(current, *cpumask);
^
cc1: some warnings being treated as errors
drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'key_fini':
drivers/staging/lustre/lustre/obdclass/lu_object.c:1354:4: error: implicit declaration of function 'module_refcount' [-Werror=implicit-function-declaration]
LINVRNT(module_refcount(key->lct_owner) > 0);
^
In file included from drivers/staging/lustre/include/linux/libcfs/libcfs.h:203:0,
from drivers/staging/lustre/lustre/obdclass/lu_object.c:47:
drivers/staging/lustre/lustre/obdclass/lu_object.c: In function 'lu_context_keys_dump':
drivers/staging/lustre/lustre/obdclass/lu_object.c:1936:42: error: dereferencing pointer to incomplete type
key->lct_owner ? key->lct_owner->name : "",
^
drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:221:41: note: in definition of macro '__CDEBUG'
libcfs_debug_msg(&msgdata, format, ## __VA_ARGS__); \
^
drivers/staging/lustre/include/linux/libcfs/libcfs_debug.h:238:30: note: in expansion of macro 'CDEBUG_LIMIT'
#define CERROR(format, ...) CDEBUG_LIMIT(D_ERROR, format, ## __VA_ARGS__)
^
drivers/staging/lustre/lustre/obdclass/lu_object.c:1932:4: note: in expansion of macro 'CERROR'
CERROR("[%d]: %p %x (%p,%p,%p) %d %d \"%s\"@%p\n",
^
cc1: some warnings being treated as errors
drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c: In function 'ptlrpcd':
drivers/staging/lustre/lustre/ptlrpc/ptlrpcd.c:398:4: error: implicit declaration of function 'set_cpus_allowed' [-Werror=implicit-function-declaration]
cfs_set_cpus_allowed(current,
^
cc1: some warnings being treated as errors
So I gave up and just reverted commit 52f6317528c6 ("staging/lustre: drop
CONFIG_BROKEN dependency") (thus disabling the code again) for now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2013-01-08 4:29 ` Stephen Rothwell
@ 2013-01-08 16:46 ` H Hartley Sweeten
0 siblings, 0 replies; 143+ messages in thread
From: H Hartley Sweeten @ 2013-01-08 16:46 UTC (permalink / raw)
To: Stephen Rothwell, Greg KH; +Cc: linux-next, linux-kernel, Ian Abbott
On Monday, January 07, 2013 9:30 PM, Stephen Rothwell wrote:
> On Mon, 7 Jan 2013 20:27:30 -0800 Greg KH <greg@kroah.com> wrote:
>> On Tue, Jan 08, 2013 at 01:23:52PM +1100, Stephen Rothwell wrote:
>>> After merging the staging tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> drivers/staging/comedi/comedi_fops.c: In function 'comedi_unlocked_ioctl':
>>> drivers/staging/comedi/comedi_fops.c:1665:4: error: 'dev_file_info' undeclared (first use in this function)
>>>
>>> Caused by commit 4da5fa9a439f ("staging: comedi: use comedi_dev_from_minor
>>> ()") interacting with commit 7d3135af399e ("staging: comedi: prevent
>>> auto-unconfig of manually configured devices") from the staging.current
>>> tree.
>>>
>>> I just reverted the latter commit in the hope that the bug is fixed in
>>> some other way in the staging tree.
>>
>> Yes, I had to do some manual fixup when merging the branches together to
>> get it to work properly, which is what I did in my staging-next tree.
>> As the fixup was done in the merge commit, maybe you didn't get it when
>> you did the pull?
>
> Presumably not (my top of staging-next is d7f9729f6e06) - it was changing
> pretty rapidly this morning as I was fetching trees ...
>
> At least it will be OK tomorrow.
Greg's staging tree on git.kernel.org looks correct.
If there is anything I need to do to help resolve this please let me know.
Thanks,
Hartley
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-01-08 4:27 ` Greg KH
@ 2013-01-08 4:29 ` Stephen Rothwell
2013-01-08 16:46 ` H Hartley Sweeten
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2013-01-08 4:29 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Ian Abbott, H Hartley Sweeten
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
Hi Greg,
On Mon, 7 Jan 2013 20:27:30 -0800 Greg KH <greg@kroah.com> wrote:
>
> On Tue, Jan 08, 2013 at 01:23:52PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/staging/comedi/comedi_fops.c: In function 'comedi_unlocked_ioctl':
> > drivers/staging/comedi/comedi_fops.c:1665:4: error: 'dev_file_info' undeclared (first use in this function)
> >
> > Caused by commit 4da5fa9a439f ("staging: comedi: use comedi_dev_from_minor
> > ()") interacting with commit 7d3135af399e ("staging: comedi: prevent
> > auto-unconfig of manually configured devices") from the staging.current
> > tree.
> >
> > I just reverted the latter commit in the hope that the bug is fixed in
> > some other way in the staging tree.
>
> Yes, I had to do some manual fixup when merging the branches together to
> get it to work properly, which is what I did in my staging-next tree.
> As the fixup was done in the merge commit, maybe you didn't get it when
> you did the pull?
Presumably not (my top of staging-next is d7f9729f6e06) - it was changing
pretty rapidly this morning as I was fetching trees ...
At least it will be OK tomorrow.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2013-01-08 2:23 Stephen Rothwell
@ 2013-01-08 4:27 ` Greg KH
2013-01-08 4:29 ` Stephen Rothwell
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2013-01-08 4:27 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Ian Abbott, H Hartley Sweeten
On Tue, Jan 08, 2013 at 01:23:52PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/comedi/comedi_fops.c: In function 'comedi_unlocked_ioctl':
> drivers/staging/comedi/comedi_fops.c:1665:4: error: 'dev_file_info' undeclared (first use in this function)
>
> Caused by commit 4da5fa9a439f ("staging: comedi: use comedi_dev_from_minor
> ()") interacting with commit 7d3135af399e ("staging: comedi: prevent
> auto-unconfig of manually configured devices") from the staging.current
> tree.
>
> I just reverted the latter commit in the hope that the bug is fixed in
> some other way in the staging tree.
Yes, I had to do some manual fixup when merging the branches together to
get it to work properly, which is what I did in my staging-next tree.
As the fixup was done in the merge commit, maybe you didn't get it when
you did the pull?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2013-01-08 2:23 Stephen Rothwell
2013-01-08 4:27 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2013-01-08 2:23 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Ian Abbott, H Hartley Sweeten
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/comedi/comedi_fops.c: In function 'comedi_unlocked_ioctl':
drivers/staging/comedi/comedi_fops.c:1665:4: error: 'dev_file_info' undeclared (first use in this function)
Caused by commit 4da5fa9a439f ("staging: comedi: use comedi_dev_from_minor
()") interacting with commit 7d3135af399e ("staging: comedi: prevent
auto-unconfig of manually configured devices") from the staging.current
tree.
I just reverted the latter commit in the hope that the bug is fixed in
some other way in the staging tree.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-09-12 6:07 Stephen Rothwell
2012-09-12 16:13 ` Greg KH
2012-09-14 7:55 ` Samuel Ortiz
@ 2012-09-18 20:40 ` Jonathan Cameron
2 siblings, 0 replies; 143+ messages in thread
From: Jonathan Cameron @ 2012-09-18 20:40 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, srinivas pandruvada,
Jiri Kosina, Mark Brown, Samuel Ortiz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/12/2012 07:07 AM, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/hid/hid-sensor-hub.c: In function 'sensor_hub_probe': drivers/hid/hid-sensor-hub.c:599:3: error: too few
> arguments to function 'mfd_add_devices'
>
> Caused by commit 401ca24fb34a ("HID: sensors: introduce sensor framework") interacting with commit 6607bad3d763
> ("mfd: core: Push irqdomain mapping out into devices") from the mfd tree.
>
> I have added the following merge fix patch and can carry it as necessary (no action is required).
Just as a heads up, this issue has now bitten us directly in the staging-next
tree as the mfd change is now in Linus' tree and that was merged into
staging-next at rc6.
I'll queue up Stephen's patch but might be a few days before I send the pull
containing it to Greg.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 12 Sep 2012 16:03:55 +1000 Subject: [PATCH] HID: sensors:
> fix up for mfd_add_devices() API change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/hid/hid-sensor-hub.c | 2 +- 1 file changed, 1
> insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c index 34a35ba..4ac759c 100644 ---
> a/drivers/hid/hid-sensor-hub.c +++ b/drivers/hid/hid-sensor-hub.c @@ -596,7 +596,7 @@ static int
> sensor_hub_probe(struct hid_device *hdev, } } ret = mfd_add_devices(&hdev->dev, 0, sd->hid_sensor_hub_client_devs,
> - sd->hid_sensor_client_cnt, NULL, 0); + sd->hid_sensor_client_cnt, NULL, 0, NULL); if (ret < 0) goto
> err_free_names;
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQWNxTAAoJEFSFNJnE9BaInz4QALIn+9yuYA/I+W7dl8miwb6T
QN+tEpTO7gdgBkLt6AWC4apjmN1Lk4FXu2qS0U8evKwtCGN+v0IdDjjWq3qloAF+
I7zdthLnjstOqFIv0wr3dmf2ZiURv7oERdiBtp8h92j6NZHDPAHnoF7xRvn08Tsc
EWOsUKURIr245hd0ApTfuZdor696SXx8HVCYjDDIPXpP/7yY/yE07ID+QESRwhxh
znFiGyLvPw3zTQYE2IqRPAMdKQrJbX7wOLY7bAMKniwI43jEU6HHcZRCGSDOHaPq
4Nxc6WrqqAyWD3zDqurQvM3OgIgL/QC4b88WuUhcyWGZhumK4ivW0evCq8BM10jn
gJqJnAu/JX8Q/JLMl0z0sPFjmSdfkWmywz0zOQEOPvwoXNENdT5kalYA51sP9vqe
bCOnGMATrDb+76o4RxkOnwp2CAMoDrDqeSqtH1FM2UJPFZhB9ly0eQvmh1zmeJlV
FD4iB8tjJnHIUX3ZW12/ylP6vpYSZnoWDH0kSVSfNNJXWYqoaWKXODxsiaMJRwX3
tFGzR/KrRKkKwowV4VAWyVmO+U7jne0cV3VvWX4CHQRSsrzjAmX3mVm915rCLTkT
zAed3Svr/LjBeXY5IGU2gY4o4TPvyJwhBh9rRfmIYuLM6qE15itT5q7CQjFu/jrs
Apz5hKLeGuMepT1EokNb
=/JJX
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-09-12 6:07 Stephen Rothwell
2012-09-12 16:13 ` Greg KH
@ 2012-09-14 7:55 ` Samuel Ortiz
2012-09-18 20:40 ` Jonathan Cameron
2 siblings, 0 replies; 143+ messages in thread
From: Samuel Ortiz @ 2012-09-14 7:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, srinivas pandruvada,
Jiri Kosina, Jonathan Cameron, Mark Brown
Hi Stephen,
On Wed, Sep 12, 2012 at 04:07:19PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/hid/hid-sensor-hub.c: In function 'sensor_hub_probe':
> drivers/hid/hid-sensor-hub.c:599:3: error: too few arguments to function 'mfd_add_devices'
>
> Caused by commit 401ca24fb34a ("HID: sensors: introduce sensor
> framework") interacting with commit 6607bad3d763 ("mfd: core: Push
> irqdomain mapping out into devices") from the mfd tree.
>
> I have added the following merge fix patch and can carry it as necessary
> (no action is required).
Thanks for fixing this one.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-09-12 6:07 Stephen Rothwell
@ 2012-09-12 16:13 ` Greg KH
2012-09-14 7:55 ` Samuel Ortiz
2012-09-18 20:40 ` Jonathan Cameron
2 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2012-09-12 16:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, srinivas pandruvada, Jiri Kosina,
Jonathan Cameron, Mark Brown, Samuel Ortiz
On Wed, Sep 12, 2012 at 04:07:19PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/hid/hid-sensor-hub.c: In function 'sensor_hub_probe':
> drivers/hid/hid-sensor-hub.c:599:3: error: too few arguments to function 'mfd_add_devices'
>
> Caused by commit 401ca24fb34a ("HID: sensors: introduce sensor
> framework") interacting with commit 6607bad3d763 ("mfd: core: Push
> irqdomain mapping out into devices") from the mfd tree.
>
> I have added the following merge fix patch and can carry it as necessary
> (no action is required).
Looks good to me, thanks for this.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2012-09-12 6:07 Stephen Rothwell
2012-09-12 16:13 ` Greg KH
` (2 more replies)
0 siblings, 3 replies; 143+ messages in thread
From: Stephen Rothwell @ 2012-09-12 6:07 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, srinivas pandruvada, Jiri Kosina,
Jonathan Cameron, Mark Brown, Samuel Ortiz
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/hid/hid-sensor-hub.c: In function 'sensor_hub_probe':
drivers/hid/hid-sensor-hub.c:599:3: error: too few arguments to function 'mfd_add_devices'
Caused by commit 401ca24fb34a ("HID: sensors: introduce sensor
framework") interacting with commit 6607bad3d763 ("mfd: core: Push
irqdomain mapping out into devices") from the mfd tree.
I have added the following merge fix patch and can carry it as necessary
(no action is required).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 12 Sep 2012 16:03:55 +1000
Subject: [PATCH] HID: sensors: fix up for mfd_add_devices() API change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/hid/hid-sensor-hub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 34a35ba..4ac759c 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -596,7 +596,7 @@ static int sensor_hub_probe(struct hid_device *hdev,
}
}
ret = mfd_add_devices(&hdev->dev, 0, sd->hid_sensor_hub_client_devs,
- sd->hid_sensor_client_cnt, NULL, 0);
+ sd->hid_sensor_client_cnt, NULL, 0, NULL);
if (ret < 0)
goto err_free_names;
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2012-02-17 17:04 ` Greg KH
@ 2012-02-17 17:23 ` Dan Magenheimer
0 siblings, 0 replies; 143+ messages in thread
From: Dan Magenheimer @ 2012-02-17 17:23 UTC (permalink / raw)
To: Greg KH, Stephen Rothwell; +Cc: linux-next, linux-kernel, Konrad Wilk
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Friday, February 17, 2012 10:04 AM
> To: Stephen Rothwell
> Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Dan Magenheimer
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> On Fri, Feb 17, 2012 at 03:10:30PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/built-in.o: In function `r2hb_hb_group_drop_item':
> > heartbeat.c:(.text+0x12cd7a): undefined reference to `config_item_put'
> > <snip>
> > drivers/built-in.o: In function `exit_r2nm':
> > nodemanager.c:(.exit.text+0x99b): undefined reference to `configfs_unregister_subsystem'
> >
> > This after I moved the tmem tree to before the staging tree to fix
> > yesterday's build failure.
> >
> > I have cherry-picked Greg's patch to disable building of the ramster code
> > for today (since it wasn't in his tree when I fetched it this morning).
>
> Thank you for doing that, sorry I didn't get any of these build errors
> on my own. That's what I get for applying patches while on the road and
> away from my big build systems to verify this :(
Yes, thanks from me also. It occurs only for allmodconfig and I already have
a Kconfig fix* but not fully-tested yet so, figuring that Greg's CONFIG_BROKEN
patch would turn ramster off for now anyway, I didn't rush the fix to you or Greg.
Apologies again, but I am (slowly) learning. :-(
Dan
* RAMster does work very nicely but, for various reasons, requires
CONFIG_RAMSTER=y and CONFIG_CONFIGFS_FS=y, so ramster Kconfig needs
"depends on CONFIGFS_FS=y" not just "depends on CONFIGFS_FS".
(Patch forthcoming Greg.)
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-17 4:10 Stephen Rothwell
@ 2012-02-17 17:04 ` Greg KH
2012-02-17 17:23 ` Dan Magenheimer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2012-02-17 17:04 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Dan Magenheimer
On Fri, Feb 17, 2012 at 03:10:30PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/built-in.o: In function `r2hb_hb_group_drop_item':
> heartbeat.c:(.text+0x12cd7a): undefined reference to `config_item_put'
> drivers/built-in.o: In function `r2hb_hb_group_make_item':
> heartbeat.c:(.text+0x12cdc7): undefined reference to `config_item_put'
> drivers/built-in.o: In function `r2hb_alloc_hb_set':
> (.text+0x12cf2f): undefined reference to `config_group_init_type_name'
> drivers/built-in.o: In function `r2nm_cluster_group_drop_item':
> nodemanager.c:(.text+0x12d34f): undefined reference to `config_item_put'
> nodemanager.c:(.text+0x12d378): undefined reference to `config_item_put'
> drivers/built-in.o: In function `r2nm_node_put':
> (.text+0x12d3a0): undefined reference to `config_item_put'
> drivers/built-in.o: In function `r2nm_node_group_drop_item':
> nodemanager.c:(.text+0x12dc4d): undefined reference to `config_item_put'
> drivers/built-in.o: In function `r2nm_node_get':
> (.text+0x12e407): undefined reference to `config_item_get'
> drivers/built-in.o: In function `r2nm_get_node_by_ip':
> (.text+0x12e482): undefined reference to `config_item_get'
> drivers/built-in.o: In function `r2nm_get_node_by_num':
> (.text+0x12e514): undefined reference to `config_item_get'
> drivers/built-in.o: In function `r2nm_node_group_make_item':
> nodemanager.c:(.text+0x12e664): undefined reference to `config_item_init_type_name'
> drivers/built-in.o: In function `r2nm_cluster_group_make_group':
> nodemanager.c:(.text+0x12e762): undefined reference to `config_group_init_type_name'
> nodemanager.c:(.text+0x12e77f): undefined reference to `config_group_init_type_name'
> drivers/built-in.o: In function `r2nm_depend_item':
> (.text+0x12e878): undefined reference to `configfs_depend_item'
> drivers/built-in.o: In function `r2nm_undepend_item':
> (.text+0x12e8a0): undefined reference to `configfs_undepend_item'
> drivers/built-in.o: In function `r2nm_depend_this_node':
> (.text+0x12e907): undefined reference to `config_item_put'
> drivers/built-in.o: In function `r2nm_undepend_this_node':
> (.text+0x12e973): undefined reference to `config_item_put'
> drivers/built-in.o: In function `init_r2nm':
> nodemanager.c:(.init.text+0xefdb): undefined reference to `config_group_init'
> nodemanager.c:(.init.text+0xf00f): undefined reference to `configfs_register_subsystem'
> drivers/built-in.o: In function `exit_r2nm':
> nodemanager.c:(.exit.text+0x99b): undefined reference to `configfs_unregister_subsystem'
>
> This after I moved the tmem tree to before the staging tree to fix
> yesterday's build failure.
>
> I have cherry-picked Greg's patch to disable building of the ramster code
> for today (since it wasn't in his tree when I fetched it this morning).
Thank you for doing that, sorry I didn't get any of these build errors
on my own. That's what I get for applying patches while on the road and
away from my big build systems to verify this :(
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-16 21:25 ` Stephen Rothwell
2012-02-16 21:49 ` Dan Magenheimer
@ 2012-02-17 16:01 ` Konrad Rzeszutek Wilk
1 sibling, 0 replies; 143+ messages in thread
From: Konrad Rzeszutek Wilk @ 2012-02-17 16:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Dan Magenheimer, Greg KH, linux-next, linux-kernel,
Seth Jennings, Nitin Gupta
> It is in next-20120215 (and has been since next-20120124). However, I
> merge Konrad's (tmem) tree *after* I merge the staging tree, so that commit
> was not present when I tried to build linux-next after merging the
> staging tree.
>
> > > > Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem").
> > > >
> > > > I have used the staging tree from next-20120215 for today.
> > >
> > > Dan, can you please fix this?
> >
> > Hmmm... moving target. I'm trying to get in touch with Konrad
> > to see if we can determine what is going on.
>
> See above.
>
> > The good news is that there seems to be an increasing number
> > of people contributing to and building things on top of
> > cleancache/frontswap stuff. The bad news is that it is difficult
> > to avoid ordering dependencies that affect -next. My apologies
> > and if you have any dependency-savvy processes that would solve
> > this that we are not using, please let me/us know.
>
> Well, if anyone had bothered to tell me, I could have reordered the
> trees. However, that does not change the fact that the staging tree is
> now broken on its own. Which means that Greg can't even do unit testing
> on his tree with your code in it. :-(
Yikes. Stephen, if it is not too much trouble could you move my tree up
just a notch (or a couple) in your awesome build system? I hadn't realized
this dependency (thought it is obvious in hindsight).
Thanks!
P.S.
That won't fix Greg building his own linux-tree by itself, and the option of
using CONFIG_BROKEN should work just fine until 3.4 and which point that can be
reverted.
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2012-02-17 4:10 Stephen Rothwell
2012-02-17 17:04 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2012-02-17 4:10 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Dan Magenheimer
[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/built-in.o: In function `r2hb_hb_group_drop_item':
heartbeat.c:(.text+0x12cd7a): undefined reference to `config_item_put'
drivers/built-in.o: In function `r2hb_hb_group_make_item':
heartbeat.c:(.text+0x12cdc7): undefined reference to `config_item_put'
drivers/built-in.o: In function `r2hb_alloc_hb_set':
(.text+0x12cf2f): undefined reference to `config_group_init_type_name'
drivers/built-in.o: In function `r2nm_cluster_group_drop_item':
nodemanager.c:(.text+0x12d34f): undefined reference to `config_item_put'
nodemanager.c:(.text+0x12d378): undefined reference to `config_item_put'
drivers/built-in.o: In function `r2nm_node_put':
(.text+0x12d3a0): undefined reference to `config_item_put'
drivers/built-in.o: In function `r2nm_node_group_drop_item':
nodemanager.c:(.text+0x12dc4d): undefined reference to `config_item_put'
drivers/built-in.o: In function `r2nm_node_get':
(.text+0x12e407): undefined reference to `config_item_get'
drivers/built-in.o: In function `r2nm_get_node_by_ip':
(.text+0x12e482): undefined reference to `config_item_get'
drivers/built-in.o: In function `r2nm_get_node_by_num':
(.text+0x12e514): undefined reference to `config_item_get'
drivers/built-in.o: In function `r2nm_node_group_make_item':
nodemanager.c:(.text+0x12e664): undefined reference to `config_item_init_type_name'
drivers/built-in.o: In function `r2nm_cluster_group_make_group':
nodemanager.c:(.text+0x12e762): undefined reference to `config_group_init_type_name'
nodemanager.c:(.text+0x12e77f): undefined reference to `config_group_init_type_name'
drivers/built-in.o: In function `r2nm_depend_item':
(.text+0x12e878): undefined reference to `configfs_depend_item'
drivers/built-in.o: In function `r2nm_undepend_item':
(.text+0x12e8a0): undefined reference to `configfs_undepend_item'
drivers/built-in.o: In function `r2nm_depend_this_node':
(.text+0x12e907): undefined reference to `config_item_put'
drivers/built-in.o: In function `r2nm_undepend_this_node':
(.text+0x12e973): undefined reference to `config_item_put'
drivers/built-in.o: In function `init_r2nm':
nodemanager.c:(.init.text+0xefdb): undefined reference to `config_group_init'
nodemanager.c:(.init.text+0xf00f): undefined reference to `configfs_register_subsystem'
drivers/built-in.o: In function `exit_r2nm':
nodemanager.c:(.exit.text+0x99b): undefined reference to `configfs_unregister_subsystem'
This after I moved the tmem tree to before the staging tree to fix
yesterday's build failure.
I have cherry-picked Greg's patch to disable building of the ramster code
for today (since it wasn't in his tree when I fetched it this morning).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-16 23:39 ` Stephen Rothwell
@ 2012-02-17 0:17 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2012-02-17 0:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Dan Magenheimer, linux-next, linux-kernel, Konrad Wilk,
Seth Jennings, Nitin Gupta
On Fri, Feb 17, 2012 at 10:39:17AM +1100, Stephen Rothwell wrote:
> Hi Dan,
>
> On Thu, 16 Feb 2012 13:49:53 -0800 (PST) Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
> >
> > Huh? Do you do allyesconfig/allmodconfig build testing after you pull
> > each individual tree or only after all trees are pulled? (Apparently
> > the former, as otherwise the ordering shouldn't matter, right?)
>
> From my daily release note:
>
> "Between each merge, the tree was built with
> a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
> final fixups (if any), it is also built with powerpc allnoconfig (32 and
> 64 bit), ppc44x_defconfig and allyesconfig (minus
> CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
> and sparc64 defconfig. These builds also have
> CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
> CONFIG_DEBUG_INFO disabled when necessary."
>
> So yes, I build between each merge. It allows me to isolate where
> problems are occurring so that they can be easily fixed in isolation.
>
> > If you are doing the after-every-individual-tree build testing,
> > yes, if you could pull konrad's tmem tree first, that would
> > solve this problem I believe.**
>
> Yes, I can do that (and will for today). However, it does mean that the
> staging tree now cannot be merged into Linus' tree until after the tmem
> tree has been merged. And if Linus decides not to take it, then Greg
> will have to remove these commits from his tree (or revert them) before
> he can get all the rest of the staging tree into Linus' tree.
>
> > I suspect unit testing doesn't make much as much sense in staging
> > as it does in the core kernel. I did testing of ramster in my
>
> Of course it makes sense - at least at the "make sure it builds" level.
>
> > public git tree (which includes the tmem patchset coming to you via
> > konrad) but, since it is a staging driver, the bits have to go
> > through Greg.
>
> Maybe you should seek a dispensation from Greg to allow your ramster tree
> to exist independently in linux-next and be merged independently by
> Linus'. Greg may want to keep watch in your tree, but that should not be
> much more effort than reviewing and applying your patches to the staging
> tree.
Ick, no, I'll just mark this as CONFIG_BROKEN for now, and things can be
fixed up later, during the 3.4 window as it should all settle down then.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-16 21:49 ` Dan Magenheimer
@ 2012-02-16 23:39 ` Stephen Rothwell
2012-02-17 0:17 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2012-02-16 23:39 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Greg KH, linux-next, linux-kernel, Konrad Wilk, Seth Jennings,
Nitin Gupta
[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]
Hi Dan,
On Thu, 16 Feb 2012 13:49:53 -0800 (PST) Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>
> Huh? Do you do allyesconfig/allmodconfig build testing after you pull
> each individual tree or only after all trees are pulled? (Apparently
> the former, as otherwise the ordering shouldn't matter, right?)
From my daily release note:
"Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary."
So yes, I build between each merge. It allows me to isolate where
problems are occurring so that they can be easily fixed in isolation.
> If you are doing the after-every-individual-tree build testing,
> yes, if you could pull konrad's tmem tree first, that would
> solve this problem I believe.**
Yes, I can do that (and will for today). However, it does mean that the
staging tree now cannot be merged into Linus' tree until after the tmem
tree has been merged. And if Linus decides not to take it, then Greg
will have to remove these commits from his tree (or revert them) before
he can get all the rest of the staging tree into Linus' tree.
> I suspect unit testing doesn't make much as much sense in staging
> as it does in the core kernel. I did testing of ramster in my
Of course it makes sense - at least at the "make sure it builds" level.
> public git tree (which includes the tmem patchset coming to you via
> konrad) but, since it is a staging driver, the bits have to go
> through Greg.
Maybe you should seek a dispensation from Greg to allow your ramster tree
to exist independently in linux-next and be merged independently by
Linus'. Greg may want to keep watch in your tree, but that should not be
much more effort than reviewing and applying your patches to the staging
tree.
> Yes, there are a number of parts from different companies/timezones
> now flying in close formation. The name change (flush->invalidate)
> causing this problem was insisted upon by Andrew Morton (and has been
> in linux-next for several months), otherwise it wouldn't have happened
> and wouldn't be causing these issues :-( But better to work through
> them in -next than in Linus' merge window I guess.
Definitely.
I do realise that the staging tree is "special", but I am trying to deal
with this in a generic manner (as I would for dependencies between any
other two trees).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2012-02-16 21:25 ` Stephen Rothwell
@ 2012-02-16 21:49 ` Dan Magenheimer
2012-02-16 23:39 ` Stephen Rothwell
2012-02-17 16:01 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 143+ messages in thread
From: Dan Magenheimer @ 2012-02-16 21:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, Konrad Wilk, Seth Jennings,
Nitin Gupta
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> Hi Dan,
Hi Stephen --
Thanks for the reply and sorry for the hassle. See below for
important question.
> > which changed the names of those fields from "flush*" to "invalidate*".
> > I am the author of that commit but it is pulled through Konrad Wilk
> > (cc'ed). Perhaps Konrad's pull succeeded in next-20120214 but
> > failed in next-20120215?
>
> If a fetch fails for a particular tree on a particular day, I use the
> version of that tree from the day before, so that is not the problem (and
> in any case, the fetch did not fail).
>
> > Kernel.org seems to be down so I can't see if that commit is
> > in next-20120215 but if it is not that would likely cause
> > the above errors.
>
> It is in next-20120215 (and has been since next-20120124). However, I
> merge Konrad's (tmem) tree *after* I merge the staging tree, so that commit
> was not present when I tried to build linux-next after merging the
> staging tree.
Huh? Do you do allyesconfig/allmodconfig build testing after you pull
each individual tree or only after all trees are pulled? (Apparently
the former, as otherwise the ordering shouldn't matter, right?)
> > The good news is that there seems to be an increasing number
> > of people contributing to and building things on top of
> > cleancache/frontswap stuff. The bad news is that it is difficult
> > to avoid ordering dependencies that affect -next. My apologies
> > and if you have any dependency-savvy processes that would solve
> > this that we are not using, please let me/us know.
>
> Well, if anyone had bothered to tell me, I could have reordered the
> trees. However, that does not change the fact that the staging tree is
> now broken on its own. Which means that Greg can't even do unit testing
> on his tree with your code in it. :-(
If you are doing the after-every-individual-tree build testing,
yes, if you could pull konrad's tmem tree first, that would
solve this problem I believe.**
I suspect unit testing doesn't make much as much sense in staging
as it does in the core kernel. I did testing of ramster in my
public git tree (which includes the tmem patchset coming to you via
konrad) but, since it is a staging driver, the bits have to go
through Greg.
> One solutions is for Greg to merge Konrad's tree (or a subset of it) into
> the staging tree. Another is for this work to become a separate tree
> (however, I think other stuff in the staging tree depends on this work,
> right?).
Yes, there are a number of parts from different companies/timezones
now flying in close formation. The name change (flush->invalidate)
causing this problem was insisted upon by Andrew Morton (and has been
in linux-next for several months), otherwise it wouldn't have happened
and wouldn't be causing these issues :-( But better to work through
them in -next than in Linus' merge window I guess.
Thanks,
Dan
** I just found another problem that occurs with allmodconfig
so will be submitting a patch for that to GregKH shortly and
will cc you.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-16 14:39 ` Dan Magenheimer
@ 2012-02-16 21:25 ` Stephen Rothwell
2012-02-16 21:49 ` Dan Magenheimer
2012-02-17 16:01 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 143+ messages in thread
From: Stephen Rothwell @ 2012-02-16 21:25 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Greg KH, linux-next, linux-kernel, Konrad Wilk, Seth Jennings,
Nitin Gupta
[-- Attachment #1: Type: text/plain, Size: 3138 bytes --]
Hi Dan,
On Thu, 16 Feb 2012 06:39:42 -0800 (PST) Dan Magenheimer <dan.magenheimer@oracle.com> wrote:
>
> > From: Greg KH [mailto:greg@kroah.com]
> > Subject: Re: linux-next: build failure after merge of the staging tree
> >
> > On Thu, Feb 16, 2012 at 03:23:16PM +1100, Stephen Rothwell wrote:
> > > Hi Greg,
> > >
> > > After merging the staging tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > drivers/staging/ramster/zcache-main.c:2969:2: error: unknown field 'invalidate_page' specified in
> > initializer
> > > drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in
> > initializer
> > > drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in
> > initializer
> > >
> > > I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ...
>
> Absolutely, against next-20120214, which contained commit
>
> 91c6cc9b5c216bd067f9af2cc64fcbe190755865
>
> which changed the names of those fields from "flush*" to "invalidate*".
> I am the author of that commit but it is pulled through Konrad Wilk
> (cc'ed). Perhaps Konrad's pull succeeded in next-20120214 but
> failed in next-20120215?
If a fetch fails for a particular tree on a particular day, I use the
version of that tree from the day before, so that is not the problem (and
in any case, the fetch did not fail).
> Kernel.org seems to be down so I can't see if that commit is
> in next-20120215 but if it is not that would likely cause
> the above errors.
It is in next-20120215 (and has been since next-20120124). However, I
merge Konrad's (tmem) tree *after* I merge the staging tree, so that commit
was not present when I tried to build linux-next after merging the
staging tree.
> > > Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem").
> > >
> > > I have used the staging tree from next-20120215 for today.
> >
> > Dan, can you please fix this?
>
> Hmmm... moving target. I'm trying to get in touch with Konrad
> to see if we can determine what is going on.
See above.
> The good news is that there seems to be an increasing number
> of people contributing to and building things on top of
> cleancache/frontswap stuff. The bad news is that it is difficult
> to avoid ordering dependencies that affect -next. My apologies
> and if you have any dependency-savvy processes that would solve
> this that we are not using, please let me/us know.
Well, if anyone had bothered to tell me, I could have reordered the
trees. However, that does not change the fact that the staging tree is
now broken on its own. Which means that Greg can't even do unit testing
on his tree with your code in it. :-(
One solutions is for Greg to merge Konrad's tree (or a subset of it) into
the staging tree. Another is for this work to become a separate tree
(however, I think other stuff in the staging tree depends on this work,
right?).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2012-02-16 5:15 ` Greg KH
@ 2012-02-16 14:39 ` Dan Magenheimer
2012-02-16 21:25 ` Stephen Rothwell
0 siblings, 1 reply; 143+ messages in thread
From: Dan Magenheimer @ 2012-02-16 14:39 UTC (permalink / raw)
To: Greg KH, Stephen Rothwell
Cc: linux-next, linux-kernel, Konrad Wilk, Seth Jennings, Nitin Gupta
> From: Greg KH [mailto:greg@kroah.com]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> On Thu, Feb 16, 2012 at 03:23:16PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/staging/ramster/zcache-main.c:2969:2: error: unknown field 'invalidate_page' specified in
> initializer
> > drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in
> initializer
> > drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in
> initializer
> >
> > I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ...
Absolutely, against next-20120214, which contained commit
91c6cc9b5c216bd067f9af2cc64fcbe190755865
which changed the names of those fields from "flush*" to "invalidate*".
I am the author of that commit but it is pulled through Konrad Wilk
(cc'ed). Perhaps Konrad's pull succeeded in next-20120214 but
failed in next-20120215?
Kernel.org seems to be down so I can't see if that commit is
in next-20120215 but if it is not that would likely cause
the above errors.
> > Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem").
> >
> > I have used the staging tree from next-20120215 for today.
>
> Dan, can you please fix this?
Hmmm... moving target. I'm trying to get in touch with Konrad
to see if we can determine what is going on.
The good news is that there seems to be an increasing number
of people contributing to and building things on top of
cleancache/frontswap stuff. The bad news is that it is difficult
to avoid ordering dependencies that affect -next. My apologies
and if you have any dependency-savvy processes that would solve
this that we are not using, please let me/us know.
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-16 4:23 Stephen Rothwell
@ 2012-02-16 5:15 ` Greg KH
2012-02-16 14:39 ` Dan Magenheimer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2012-02-16 5:15 UTC (permalink / raw)
To: Dan Magenheimer, Stephen Rothwell; +Cc: linux-next, linux-kernel
On Thu, Feb 16, 2012 at 03:23:16PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/ramster/zcache-main.c:2969:2: error: unknown field 'invalidate_page' specified in initializer
> drivers/staging/ramster/zcache-main.c:2969:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/staging/ramster/zcache-main.c:2969:2: warning: (near initialization for 'zcache_cleancache_ops.put_page') [enabled by default]
> drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in initializer
> drivers/staging/ramster/zcache-main.c:2970:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/staging/ramster/zcache-main.c:2970:2: warning: (near initialization for 'zcache_cleancache_ops.flush_page') [enabled by default]
> drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in initializer
> drivers/staging/ramster/zcache-main.c:2971:2: warning: initialization from incompatible pointer type [enabled by default]
> drivers/staging/ramster/zcache-main.c:2971:2: warning: (near initialization for 'zcache_cleancache_ops.flush_inode') [enabled by default]
> drivers/staging/ramster/zcache-main.c:913:13: warning: 'zcache_do_remotify_ops' defined but not used [-Wunused-function]
> drivers/staging/ramster/zcache-main.c:1002:13: warning: 'ramster_remotify_init' defined but not used [-Wunused-function]
>
> I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ...
>
> Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem").
>
> I have used the staging tree from next-20120215 for today.
Dan, can you please fix this?
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2012-02-16 4:23 Stephen Rothwell
2012-02-16 5:15 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2012-02-16 4:23 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/ramster/zcache-main.c:2969:2: error: unknown field 'invalidate_page' specified in initializer
drivers/staging/ramster/zcache-main.c:2969:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/staging/ramster/zcache-main.c:2969:2: warning: (near initialization for 'zcache_cleancache_ops.put_page') [enabled by default]
drivers/staging/ramster/zcache-main.c:2970:2: error: unknown field 'invalidate_inode' specified in initializer
drivers/staging/ramster/zcache-main.c:2970:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/staging/ramster/zcache-main.c:2970:2: warning: (near initialization for 'zcache_cleancache_ops.flush_page') [enabled by default]
drivers/staging/ramster/zcache-main.c:2971:2: error: unknown field 'invalidate_fs' specified in initializer
drivers/staging/ramster/zcache-main.c:2971:2: warning: initialization from incompatible pointer type [enabled by default]
drivers/staging/ramster/zcache-main.c:2971:2: warning: (near initialization for 'zcache_cleancache_ops.flush_inode') [enabled by default]
drivers/staging/ramster/zcache-main.c:913:13: warning: 'zcache_do_remotify_ops' defined but not used [-Wunused-function]
drivers/staging/ramster/zcache-main.c:1002:13: warning: 'ramster_remotify_init' defined but not used [-Wunused-function]
I do wonder if any of this was build tested with CONFIG_CLEANCACHE enabled ...
Caused by commit 19ee3ef5f4bb ("staging: ramster: local compression + tmem").
I have used the staging tree from next-20120215 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2012-02-15 2:33 ` Greg KH
@ 2012-02-15 16:14 ` Dan Magenheimer
0 siblings, 0 replies; 143+ messages in thread
From: Dan Magenheimer @ 2012-02-15 16:14 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, linux-kernel, Seth Jennings,
Nitin Gupta, Konrad Wilk
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
>
> On Tue, Feb 14, 2012 at 04:54:37PM -0800, Dan Magenheimer wrote:
> > > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > > Subject: Re: linux-next: build failure after merge of the staging tree
> > >
> > > > OK, I have just posted the ramster v5 patchset which applies against
> > > > linux-3.2. I've test-built it against linux-next... it only gets
> > > > the normal minor merge conflicts for adding a line to
> > > > drivers/staging/Makefile and Kconfig.
> > >
> > > Please resend after fixing that conflict, as it would require me to edit
> > > it by hand in order to apply this. As you have already redone the
> > > patch, there's no reason I should have to do this, right?
> >
> > Do you want me to resend all 6 patches? The only patch
> > affected is patch 6 of 6. All others apply cleanly.
> > Let me know and I will resend one or all tomorrow.
>
> All would be best, also please thread them properly, 'git send-email'
> will do this for you, please use it.
OK, posted (*). BTW, I _was_ using git send-email, just didn't know
that "git send-email patch0 patch1 patch2 ..." would cause them
to be threaded. (I was using git send-email patch0;
git send-email patch1; git send-email patch2...)
Thanks again for your patience and help! I think RAMster
can now be successfully queued with no linux-next merge issues!
Dan
* http://driverdev.linuxdriverproject.org/pipermail/devel/2012-February/024614.html
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-15 0:54 ` Dan Magenheimer
@ 2012-02-15 2:33 ` Greg KH
2012-02-15 16:14 ` Dan Magenheimer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2012-02-15 2:33 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Stephen Rothwell, linux-next, linux-kernel, Seth Jennings,
Nitin Gupta, Konrad Wilk
On Tue, Feb 14, 2012 at 04:54:37PM -0800, Dan Magenheimer wrote:
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Subject: Re: linux-next: build failure after merge of the staging tree
> >
> > > > Ok, now reverted, what a mess...
> > > >
> > > > greg k-h
> > >
> > > OK, I have just posted the ramster v5 patchset which applies against
> > > linux-3.2. I've test-built it against linux-next... it only gets
> > > the normal minor merge conflicts for adding a line to
> > > drivers/staging/Makefile and Kconfig.
> >
> > Please resend after fixing that conflict, as it would require me to edit
> > it by hand in order to apply this. As you have already redone the
> > patch, there's no reason I should have to do this, right?
>
> OK. I'm not quite sure how to generate a patchset or a
> git commit-set that applies cleanly against two different
> trees (3.2 and linux-next), but I guess common sense should
> tell me that, since the patches have to go through staging-next
> first and you are applying patches rather than git-pull'ing,
> staging-next should be my preferred choice for a base.
Exactly, how could I apply them to two trees? For that case, how can I
go back in time and apply them to 3.2?
> Do you want me to resend all 6 patches? The only patch
> affected is patch 6 of 6. All others apply cleanly.
> Let me know and I will resend one or all tomorrow.
All would be best, also please thread them properly, 'git send-email'
will do this for you, please use it.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2012-02-15 0:03 ` Greg KH
@ 2012-02-15 0:54 ` Dan Magenheimer
2012-02-15 2:33 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Dan Magenheimer @ 2012-02-15 0:54 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, linux-kernel, Seth Jennings,
Nitin Gupta, Konrad Wilk
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> > > Ok, now reverted, what a mess...
> > >
> > > greg k-h
> >
> > OK, I have just posted the ramster v5 patchset which applies against
> > linux-3.2. I've test-built it against linux-next... it only gets
> > the normal minor merge conflicts for adding a line to
> > drivers/staging/Makefile and Kconfig.
>
> Please resend after fixing that conflict, as it would require me to edit
> it by hand in order to apply this. As you have already redone the
> patch, there's no reason I should have to do this, right?
OK. I'm not quite sure how to generate a patchset or a
git commit-set that applies cleanly against two different
trees (3.2 and linux-next), but I guess common sense should
tell me that, since the patches have to go through staging-next
first and you are applying patches rather than git-pull'ing,
staging-next should be my preferred choice for a base.
Do you want me to resend all 6 patches? The only patch
affected is patch 6 of 6. All others apply cleanly.
Let me know and I will resend one or all tomorrow.
Sorry for the noise/hassle, but this is a learning process...
Dan
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-14 23:43 ` Dan Magenheimer
@ 2012-02-15 0:03 ` Greg KH
2012-02-15 0:54 ` Dan Magenheimer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2012-02-15 0:03 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Stephen Rothwell, linux-next, linux-kernel, Seth Jennings,
Nitin Gupta, Konrad Wilk
On Tue, Feb 14, 2012 at 03:43:31PM -0800, Dan Magenheimer wrote:
> > From: Greg KH [mailto:gregkh@linuxfoundation.org]
> > Subject: Re: linux-next: build failure after merge of the staging tree
> >
> > On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
> > > > From: Greg KH [mailto:greg@kroah.com]
> > > > Subject: Re: linux-next: build failure after merge of the staging tree
> > > >
> > > > On Fri, Feb 10, 2012 at 03:58:00PM +1100, Stephen Rothwell wrote:
> > > > > Hi Greg,
> > > > >
> > > > > After merging the staging tree, today's linux-next build (x86_64
> > > > > allmodconfig) failed like this:
> > > > >
> > > > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > > > > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> > > > 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > > > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > > > > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> > > > 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> > > > directory
> > > > >
> > > > > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > > > > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> > > > >
> > > > > I have used the version of the staging tree from next-20120209 for today.
> > > >
> > > > Ugh, I wonder why it builds here, very odd.
> > > >
> > > > Dan, care to send me a patch to fix this?
> > >
> > > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
> > >
> > > Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
> > > removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
> > > is still depending on it. :-( I hadn't planned for both ramster
> > > and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
> > > this is exactly the kind of problem linux-next is designed to wring out!
> > >
> > > Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
> > > I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
> > > code into it for now and, since Seth's patch should be in linux-next
> > > by the time I am done (hopefully next week), I can test build ramster v5
> > > with linux-next to ensure all the above problems are resolved before
> > > resubmitting.
> > >
> > > (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
> > > xvmalloc, but since I've done all my ramster testing on xvmalloc,
> > > I think I would prefer to make that transition later.)
> > >
> > > Sorry, Stephen and Greg, for the hassle!
> >
> > Ok, now reverted, what a mess...
> >
> > greg k-h
>
> OK, I have just posted the ramster v5 patchset which applies against
> linux-3.2. I've test-built it against linux-next... it only gets
> the normal minor merge conflicts for adding a line to
> drivers/staging/Makefile and Kconfig.
Please resend after fixing that conflict, as it would require me to edit
it by hand in order to apply this. As you have already redone the
patch, there's no reason I should have to do this, right?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2012-02-10 17:43 ` Greg KH
2012-02-10 18:22 ` Seth Jennings
@ 2012-02-14 23:43 ` Dan Magenheimer
2012-02-15 0:03 ` Greg KH
1 sibling, 1 reply; 143+ messages in thread
From: Dan Magenheimer @ 2012-02-14 23:43 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, linux-kernel, Seth Jennings,
Nitin Gupta, Konrad Wilk
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
> > > From: Greg KH [mailto:greg@kroah.com]
> > > Subject: Re: linux-next: build failure after merge of the staging tree
> > >
> > > On Fri, Feb 10, 2012 at 03:58:00PM +1100, Stephen Rothwell wrote:
> > > > Hi Greg,
> > > >
> > > > After merging the staging tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > > > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> > > 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > > > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> > > 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> > > directory
> > > >
> > > > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > > > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> > > >
> > > > I have used the version of the staging tree from next-20120209 for today.
> > >
> > > Ugh, I wonder why it builds here, very odd.
> > >
> > > Dan, care to send me a patch to fix this?
> >
> > > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
> >
> > Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
> > removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
> > is still depending on it. :-( I hadn't planned for both ramster
> > and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
> > this is exactly the kind of problem linux-next is designed to wring out!
> >
> > Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
> > I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
> > code into it for now and, since Seth's patch should be in linux-next
> > by the time I am done (hopefully next week), I can test build ramster v5
> > with linux-next to ensure all the above problems are resolved before
> > resubmitting.
> >
> > (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
> > xvmalloc, but since I've done all my ramster testing on xvmalloc,
> > I think I would prefer to make that transition later.)
> >
> > Sorry, Stephen and Greg, for the hassle!
>
> Ok, now reverted, what a mess...
>
> greg k-h
OK, I have just posted the ramster v5 patchset which applies against
linux-3.2. I've test-built it against linux-next... it only gets
the normal minor merge conflicts for adding a line to
drivers/staging/Makefile and Kconfig.
Sorry again for the inconvenience. At least V5 has some nice
improvements over V4, see: https://lkml.org/lkml/2012/2/14/396
Thanks,
Dan
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-10 17:43 ` Greg KH
@ 2012-02-10 18:22 ` Seth Jennings
2012-02-14 23:43 ` Dan Magenheimer
1 sibling, 0 replies; 143+ messages in thread
From: Seth Jennings @ 2012-02-10 18:22 UTC (permalink / raw)
To: Greg KH
Cc: Dan Magenheimer, Stephen Rothwell, linux-next, linux-kernel,
Nitin Gupta, Konrad Wilk
On 02/10/2012 11:43 AM, Greg KH wrote:
> On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
>>> From: Greg KH [mailto:greg@kroah.com]
>>> Subject: Re: linux-next: build failure after merge of the staging tree
>>>
>>> On Fri, Feb 10, 2012 at 03:58:00PM +1100, Stephen Rothwell wrote:
>>>> Hi Greg,
>>>>
>>>> After merging the staging tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
>>>> drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
>>> 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
>>>> drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
>>>> drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
>>> 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
>>>> drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
>>> directory
>>>>
>>>> Caused by commits ba351b02ab11 ("staging: ramster: local compression +
>>>> tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
>>>>
>>>> I have used the version of the staging tree from next-20120209 for today.
>>>
>>> Ugh, I wonder why it builds here, very odd.
>>>
>>> Dan, care to send me a patch to fix this?
>>
>>>> drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
>>
>> Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
>> removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
>> is still depending on it. :-( I hadn't planned for both ramster
>> and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
>> this is exactly the kind of problem linux-next is designed to wring out!
>>
>> Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
>> I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
>> code into it for now and, since Seth's patch should be in linux-next
>> by the time I am done (hopefully next week), I can test build ramster v5
>> with linux-next to ensure all the above problems are resolved before
>> resubmitting.
>>
>> (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
>> xvmalloc, but since I've done all my ramster testing on xvmalloc,
>> I think I would prefer to make that transition later.)
>>
>> Sorry, Stephen and Greg, for the hassle!
>
> Ok, now reverted, what a mess...
Sounds like the ramster has been reverted already, but the removal
of xvmalloc was done in its own commit (from staging-next):
b154ff05e1b0d749231a71896c90e38657f8e675 staging: zram: remove xvmalloc
If you revert just this commit, that should restore the xvmalloc files.
Of course this doesn't resolve the "implicit declaration of function"
errors.
--
Seth
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-10 17:21 ` Dan Magenheimer
@ 2012-02-10 17:43 ` Greg KH
2012-02-10 18:22 ` Seth Jennings
2012-02-14 23:43 ` Dan Magenheimer
0 siblings, 2 replies; 143+ messages in thread
From: Greg KH @ 2012-02-10 17:43 UTC (permalink / raw)
To: Dan Magenheimer
Cc: Stephen Rothwell, linux-next, linux-kernel, Seth Jennings,
Nitin Gupta, Konrad Wilk
On Fri, Feb 10, 2012 at 09:21:46AM -0800, Dan Magenheimer wrote:
> > From: Greg KH [mailto:greg@kroah.com]
> > Subject: Re: linux-next: build failure after merge of the staging tree
> >
> > On Fri, Feb 10, 2012 at 03:58:00PM +1100, Stephen Rothwell wrote:
> > > Hi Greg,
> > >
> > > After merging the staging tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> > 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> > 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> > directory
> > >
> > > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> > >
> > > I have used the version of the staging tree from next-20120209 for today.
> >
> > Ugh, I wonder why it builds here, very odd.
> >
> > Dan, care to send me a patch to fix this?
>
> > > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
>
> Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
> removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
> is still depending on it. :-( I hadn't planned for both ramster
> and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
> this is exactly the kind of problem linux-next is designed to wring out!
>
> Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
> I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
> code into it for now and, since Seth's patch should be in linux-next
> by the time I am done (hopefully next week), I can test build ramster v5
> with linux-next to ensure all the above problems are resolved before
> resubmitting.
>
> (Seth, I could also switch ramster v5 to depend on zsmalloc instead of
> xvmalloc, but since I've done all my ramster testing on xvmalloc,
> I think I would prefer to make that transition later.)
>
> Sorry, Stephen and Greg, for the hassle!
Ok, now reverted, what a mess...
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* RE: linux-next: build failure after merge of the staging tree
2012-02-10 5:29 ` Greg KH
@ 2012-02-10 17:21 ` Dan Magenheimer
2012-02-10 17:43 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Dan Magenheimer @ 2012-02-10 17:21 UTC (permalink / raw)
To: Greg KH, Stephen Rothwell
Cc: linux-next, linux-kernel, Seth Jennings, Nitin Gupta, Konrad Wilk
> From: Greg KH [mailto:greg@kroah.com]
> Subject: Re: linux-next: build failure after merge of the staging tree
>
> On Fri, Feb 10, 2012 at 03:58:00PM +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> > drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function
> 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> > drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> > drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function
> 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or
> directory
> >
> > Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> > tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
> >
> > I have used the version of the staging tree from next-20120209 for today.
>
> Ugh, I wonder why it builds here, very odd.
>
> Dan, care to send me a patch to fix this?
> > drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such
Hmmm... it appears that Seth's zsmalloc patch for drivers/staging/zcache
removed xvmalloc.[ch] from drivers/staging/zram while drivers/staging/ramster
is still depending on it. :-( I hadn't planned for both ramster
and zsmalloc-replacing-xvmalloc to be merged at the same time... I guess
this is exactly the kind of problem linux-next is designed to wring out!
Greg, FOR NOW, PLEASE JUST REVERT the ramster patchset from staging-next.
I am working on a v5 anyway and will roll in a copy of the xvmalloc.[ch]
code into it for now and, since Seth's patch should be in linux-next
by the time I am done (hopefully next week), I can test build ramster v5
with linux-next to ensure all the above problems are resolved before
resubmitting.
(Seth, I could also switch ramster v5 to depend on zsmalloc instead of
xvmalloc, but since I've done all my ramster testing on xvmalloc,
I think I would prefer to make that transition later.)
Sorry, Stephen and Greg, for the hassle!
Dan
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2012-02-10 4:58 Stephen Rothwell
@ 2012-02-10 5:29 ` Greg KH
2012-02-10 17:21 ` Dan Magenheimer
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2012-02-10 5:29 UTC (permalink / raw)
To: Stephen Rothwell, Dan Magenheimer; +Cc: linux-next, linux-kernel
On Fri, Feb 10, 2012 at 03:58:00PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
> drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
> drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
> drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
> drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or directory
>
> Caused by commits ba351b02ab11 ("staging: ramster: local compression +
> tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
>
> I have used the version of the staging tree from next-20120209 for today.
Ugh, I wonder why it builds here, very odd.
Dan, care to send me a patch to fix this?
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2012-02-10 4:58 Stephen Rothwell
2012-02-10 5:29 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2012-02-10 4:58 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Dan Magenheimer
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_async_get_request_handler':
drivers/staging/ramster/ramster_o2net.c:91:2: error: implicit declaration of function 'o2net_force_data_magic' [-Werror=implicit-function-declaration]
drivers/staging/ramster/ramster_o2net.c: In function 'ramster_remote_put':
drivers/staging/ramster/ramster_o2net.c:250:2: error: implicit declaration of function 'o2net_nn_from_num' [-Werror=implicit-function-declaration]
drivers/staging/ramster/zcache-main.c:40:64: fatal error: ../zram/xvmalloc.h: No such file or directory
Caused by commits ba351b02ab11 ("staging: ramster: local compression +
tmem") and 14a3cd58dd4f ("staging: ramster: ramster-specific new files").
I have used the version of the staging tree from next-20120209 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2011-08-25 5:15 ` Larry Finger
@ 2011-08-25 15:39 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2011-08-25 15:39 UTC (permalink / raw)
To: Larry Finger
Cc: Stephen Rothwell, linux-next, linux-kernel, wlanfae, Jiri Pirko,
David Miller, netdev
On Thu, Aug 25, 2011 at 12:15:56AM -0500, Larry Finger wrote:
> On 08/25/2011 12:02 AM, Stephen Rothwell wrote:
> >Hi Greg,
> >
> >After merging the staging tree, today's linux-next build (x86_64
> >allmodconfig) failed like this:
> >
> >drivers/staging/rtl8192e/rtl_core.c:2917:2: error: unknown field 'ndo_set_multicast_list' specified in initializer
> >
> >Caused by commit 94a799425eee ("From: wlanfae<wlanfae@realtek.com>" -
> >really "[PATCH 1/8] rtl8192e: Import new version of driver from realtek"
> >Larry, that patch was badly imported ...) interacting with commit
> >b81693d9149c ("net: remove ndo_set_multicast_list callback") from the net
> >tree.
> >
> >I applied the following patch (which seems to be what was done to the
> >other drivers in the net tree - there is probably more required):
> >
> >From: Stephen Rothwell<sfr@canb.auug.org.au>
> >Date: Thu, 25 Aug 2011 14:57:55 +1000
> >Subject: [PATCH] rtl8192e: update for ndo_set_multicast_list removal.
> >
> >Signed-off-by: Stephen Rothwell<sfr@canb.auug.org.au>
> >---
> > drivers/staging/rtl8192e/rtl_core.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> >diff --git a/drivers/staging/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl_core.c
> >index f8a13d9..b38f626 100644
> >--- a/drivers/staging/rtl8192e/rtl_core.c
> >+++ b/drivers/staging/rtl8192e/rtl_core.c
> >@@ -2914,7 +2914,7 @@ static const struct net_device_ops rtl8192_netdev_ops = {
> > .ndo_stop = rtl8192_close,
> > .ndo_tx_timeout = rtl8192_tx_timeout,
> > .ndo_do_ioctl = rtl8192_ioctl,
> >- .ndo_set_multicast_list = r8192_set_multicast,
> >+ .ndo_set_rx_mode = r8192_set_multicast,
> > .ndo_set_mac_address = r8192_set_mac_adr,
> > .ndo_validate_addr = eth_validate_addr,
> > .ndo_change_mtu = eth_change_mtu,
>
> Stephan,
>
> Thanks for the notice. It seems that commit b81693d9149c had not
> made it into my copy of staging. I'll look into the issue.
It wouldn't ever make it there, as that's coming from the net-next tree,
so this will have to wait until stuff merges together in Linus's tree.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2011-08-25 5:02 Stephen Rothwell
@ 2011-08-25 5:15 ` Larry Finger
2011-08-25 15:39 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Larry Finger @ 2011-08-25 5:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, wlanfae, Jiri Pirko,
David Miller, netdev
On 08/25/2011 12:02 AM, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/rtl8192e/rtl_core.c:2917:2: error: unknown field 'ndo_set_multicast_list' specified in initializer
>
> Caused by commit 94a799425eee ("From: wlanfae<wlanfae@realtek.com>" -
> really "[PATCH 1/8] rtl8192e: Import new version of driver from realtek"
> Larry, that patch was badly imported ...) interacting with commit
> b81693d9149c ("net: remove ndo_set_multicast_list callback") from the net
> tree.
>
> I applied the following patch (which seems to be what was done to the
> other drivers in the net tree - there is probably more required):
>
> From: Stephen Rothwell<sfr@canb.auug.org.au>
> Date: Thu, 25 Aug 2011 14:57:55 +1000
> Subject: [PATCH] rtl8192e: update for ndo_set_multicast_list removal.
>
> Signed-off-by: Stephen Rothwell<sfr@canb.auug.org.au>
> ---
> drivers/staging/rtl8192e/rtl_core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl_core.c
> index f8a13d9..b38f626 100644
> --- a/drivers/staging/rtl8192e/rtl_core.c
> +++ b/drivers/staging/rtl8192e/rtl_core.c
> @@ -2914,7 +2914,7 @@ static const struct net_device_ops rtl8192_netdev_ops = {
> .ndo_stop = rtl8192_close,
> .ndo_tx_timeout = rtl8192_tx_timeout,
> .ndo_do_ioctl = rtl8192_ioctl,
> - .ndo_set_multicast_list = r8192_set_multicast,
> + .ndo_set_rx_mode = r8192_set_multicast,
> .ndo_set_mac_address = r8192_set_mac_adr,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_change_mtu = eth_change_mtu,
Stephan,
Thanks for the notice. It seems that commit b81693d9149c had not made it into my
copy of staging. I'll look into the issue.
Larry
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2011-08-25 5:02 Stephen Rothwell
2011-08-25 5:15 ` Larry Finger
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2011-08-25 5:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, wlanfae, Larry Finger, Jiri Pirko,
David Miller, netdev
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8192e/rtl_core.c:2917:2: error: unknown field 'ndo_set_multicast_list' specified in initializer
Caused by commit 94a799425eee ("From: wlanfae <wlanfae@realtek.com>" -
really "[PATCH 1/8] rtl8192e: Import new version of driver from realtek"
Larry, that patch was badly imported ...) interacting with commit
b81693d9149c ("net: remove ndo_set_multicast_list callback") from the net
tree.
I applied the following patch (which seems to be what was done to the
other drivers in the net tree - there is probably more required):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 25 Aug 2011 14:57:55 +1000
Subject: [PATCH] rtl8192e: update for ndo_set_multicast_list removal.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8192e/rtl_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl_core.c
index f8a13d9..b38f626 100644
--- a/drivers/staging/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl_core.c
@@ -2914,7 +2914,7 @@ static const struct net_device_ops rtl8192_netdev_ops = {
.ndo_stop = rtl8192_close,
.ndo_tx_timeout = rtl8192_tx_timeout,
.ndo_do_ioctl = rtl8192_ioctl,
- .ndo_set_multicast_list = r8192_set_multicast,
+ .ndo_set_rx_mode = r8192_set_multicast,
.ndo_set_mac_address = r8192_set_mac_adr,
.ndo_validate_addr = eth_validate_addr,
.ndo_change_mtu = eth_change_mtu,
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2011-07-25 5:21 Stephen Rothwell
0 siblings, 0 replies; 143+ messages in thread
From: Stephen Rothwell @ 2011-07-25 5:21 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alan Cox, Andrew Morton
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "__bad_udelay" [drivers/staging/gma500/psb_gfx.ko] undefined!
Caused by commit 1e585b52fd8e ("gma500: Add the Oaktrail HDMI support")
interacting with commit a87e553fabe8 ("asm-generic: delay.h fix udelay
and ndelay for 8 bit args"). I have applied the follwowing patch for
today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 25 Jul 2011 15:18:44 +1000
Subject: [PATCH] gma500: udelay(20000) it too long again
so replace it with mdelay(20).
Fixes build error:
ERROR: "__bad_udelay" [drivers/staging/gma500/psb_gfx.ko] undefined!
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/gma500/mrst_hdmi.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/gma500/mrst_hdmi.c b/drivers/staging/gma500/mrst_hdmi.c
index d6a5179..e66607e 100644
--- a/drivers/staging/gma500/mrst_hdmi.c
+++ b/drivers/staging/gma500/mrst_hdmi.c
@@ -129,7 +129,7 @@ static void wait_for_vblank(struct drm_device *dev)
{
/* FIXME: Can we do this as a sleep ? */
/* Wait for 20ms, i.e. one cycle at 50hz. */
- udelay(20000);
+ mdelay(20);
}
static void scu_busy_loop(void *scu_base)
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2011-07-16 23:39 ` Alan Cox
@ 2011-07-17 9:15 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2011-07-17 9:15 UTC (permalink / raw)
To: Alan Cox; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Sun, Jul 17, 2011 at 12:39:38AM +0100, Alan Cox wrote:
> On Sat, 16 Jul 2011 23:15:11 +1000
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/video/Kconfig:36:error: recursive dependency detected!
> > drivers/video/Kconfig:36: symbol FB is selected by
> > DRM_KMS_HELPER drivers/gpu/drm/Kconfig:22: symbol
> > DRM_KMS_HELPER is selected by DRM_PSB
> > drivers/staging/gma500/Kconfig:1: symbol DRM_PSB depends on
> > ACPI_VIDEO
> >
> > Caused by commit 66dca5178c70 ("gma500: Fix dependencies").
>
> Can you drop that one of your tree Greg - duplicated here and I need to
> think somewhat harder about how we sort that out.
Ok, now reverted.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2011-07-16 13:18 Stephen Rothwell
@ 2011-07-17 9:13 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2011-07-17 9:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alan Cox
On Sat, Jul 16, 2011 at 11:18:00PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/staging/gma500/backlight.c:23:0:
> drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
> In file included from drivers/staging/gma500/accel_2d.c:39:0:
> drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
> In file included from drivers/staging/gma500/gem.c:29:0:
> drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
> In file included from drivers/staging/gma500/framebuffer.c:36:0:
> drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
> In file included from drivers/staging/gma500/gtt.c:23:0:
> drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
> In file included from drivers/staging/gma500/intel_bios.c:24:0:
> drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
>
> Caused by commit 3caa89e93364 ("gma500: resync with Medfield progress").
>
> I have used the staging tree from next-20110707 for today.
This should now be fixed.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2011-07-16 13:15 Stephen Rothwell
@ 2011-07-16 23:39 ` Alan Cox
2011-07-17 9:15 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Alan Cox @ 2011-07-16 23:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel
On Sat, 16 Jul 2011 23:15:11 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/video/Kconfig:36:error: recursive dependency detected!
> drivers/video/Kconfig:36: symbol FB is selected by
> DRM_KMS_HELPER drivers/gpu/drm/Kconfig:22: symbol
> DRM_KMS_HELPER is selected by DRM_PSB
> drivers/staging/gma500/Kconfig:1: symbol DRM_PSB depends on
> ACPI_VIDEO
>
> Caused by commit 66dca5178c70 ("gma500: Fix dependencies").
Can you drop that one of your tree Greg - duplicated here and I need to
think somewhat harder about how we sort that out.
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2011-07-16 13:18 Stephen Rothwell
2011-07-17 9:13 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2011-07-16 13:18 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alan Cox
[-- Attachment #1: Type: text/plain, Size: 1284 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/staging/gma500/backlight.c:23:0:
drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
In file included from drivers/staging/gma500/accel_2d.c:39:0:
drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
In file included from drivers/staging/gma500/gem.c:29:0:
drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
In file included from drivers/staging/gma500/framebuffer.c:36:0:
drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
In file included from drivers/staging/gma500/gtt.c:23:0:
drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
In file included from drivers/staging/gma500/intel_bios.c:24:0:
drivers/staging/gma500/psb_drv.h:34:22: fatal error: medfield.h: No such file or directory
Caused by commit 3caa89e93364 ("gma500: resync with Medfield progress").
I have used the staging tree from next-20110707 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2011-07-16 13:15 Stephen Rothwell
2011-07-16 23:39 ` Alan Cox
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2011-07-16 13:15 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alan Cox
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (powerpc ppc64_defconfig)
failed like this:
drivers/video/Kconfig:36:error: recursive dependency detected!
drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:22: symbol DRM_KMS_HELPER is selected by DRM_PSB
drivers/staging/gma500/Kconfig:1: symbol DRM_PSB depends on ACPI_VIDEO
Caused by commit 66dca5178c70 ("gma500: Fix dependencies").
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2011-07-06 5:02 Stephen Rothwell
@ 2011-07-06 15:12 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2011-07-06 15:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Alexey Dobriyan, David Miller, netdev
On Wed, Jul 06, 2011 at 03:02:49PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:599:24: error: field 'tasklet' has incomplete type
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_bus_stop':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:3068:3: error: implicit declaration of function 'tasklet_kill'
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5376:3: error: implicit declaration of function 'tasklet_init'
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe_attach':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5505:14: warning: cast to pointer from integer of different size
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_chip_recognition':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6056:19: warning: cast from pointer to integer of different size
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_dpc_tasklet':
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6593:4: error: implicit declaration of function 'tasklet_schedule'
>
> Caused by commit a6b7a407865a ("net: remove interrupt.h inclusion from netdevice.h") from the net tree interacting with commit ("") from the atsging tree.
>
> I have applied the following merge fixup patch for today (it should be
> applicable to the staging tree directly).
Ok, I'll go queue this up right now so this doesn't cause a problem in
the future.
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2011-07-06 5:09 Stephen Rothwell
@ 2011-07-06 15:12 ` Greg KH
0 siblings, 0 replies; 143+ messages in thread
From: Greg KH @ 2011-07-06 15:12 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alan Cox
On Wed, Jul 06, 2011 at 03:09:16PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> make[4]: *** No rule to make target `drivers/staging/gma500/cdv_intel_crt.o', needed by `drivers/staging/gma500/psb_gfx.o'. Stop.
> drivers/staging/gma500/cdv_device.c:28:24: fatal error: cdv_device.h: No such file or directory
>
> I see that these have already been reported elsewhere - it would have
> been nice if these patches had not been added to the staging tree
> destined for linux-next until *after* they were build tested (and
> fixed). :-(
I had to push out so that Alan could sync up and fix the error. You
pulled inbetween his responding to me and hit the problem window. My
tree is now building correctly and this will not happen tomorrow.
Sorry for the inconvenience,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2011-07-06 5:09 Stephen Rothwell
2011-07-06 15:12 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2011-07-06 5:09 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alan Cox
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
make[4]: *** No rule to make target `drivers/staging/gma500/cdv_intel_crt.o', needed by `drivers/staging/gma500/psb_gfx.o'. Stop.
drivers/staging/gma500/cdv_device.c:28:24: fatal error: cdv_device.h: No such file or directory
I see that these have already been reported elsewhere - it would have
been nice if these patches had not been added to the staging tree
destined for linux-next until *after* they were build tested (and
fixed). :-(
I have used the version of the staging tree from next-20110705 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2011-07-06 5:02 Stephen Rothwell
2011-07-06 15:12 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2011-07-06 5:02 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alexey Dobriyan, David Miller, netdev
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:599:24: error: field 'tasklet' has incomplete type
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_bus_stop':
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:3068:3: error: implicit declaration of function 'tasklet_kill'
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe':
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5376:3: error: implicit declaration of function 'tasklet_init'
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_probe_attach':
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:5505:14: warning: cast to pointer from integer of different size
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_chip_recognition':
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6056:19: warning: cast from pointer to integer of different size
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c: In function 'brcmf_sdbrcm_dpc_tasklet':
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c:6593:4: error: implicit declaration of function 'tasklet_schedule'
Caused by commit a6b7a407865a ("net: remove interrupt.h inclusion from netdevice.h") from the net tree interacting with commit ("") from the atsging tree.
I have applied the following merge fixup patch for today (it should be
applicable to the staging tree directly).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 6 Jul 2011 14:54:48 +1000
Subject: [PATCH] staging: use of tasklets requires including interrupt.h
The implicit include of linux/interrupt.h is being removed from
netdevice.h.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/brcm80211/brcmfmac/dhd_sdio.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c b/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c
index da5a2ff..78a6a0c 100644
--- a/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c
+++ b/drivers/staging/brcm80211/brcmfmac/dhd_sdio.c
@@ -20,6 +20,7 @@
#include <linux/printk.h>
#include <linux/pci_ids.h>
#include <linux/netdevice.h>
+#include <linux/interrupt.h>
#include <linux/sched.h>
#include <linux/mmc/sdio.h>
#include <linux/mmc/sdio_func.h>
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2010-05-05 2:37 ` Stephen Rothwell
@ 2010-05-05 8:39 ` Tobias Klauser
0 siblings, 0 replies; 143+ messages in thread
From: Tobias Klauser @ 2010-05-05 8:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel
Hi Stephen,
On 2010-05-05 at 04:37:54 +0200, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Mon, 3 May 2010 18:17:21 +0200 Tobias Klauser <tklauser@distanz.ch> wrote:
> >
> > I just built the current linux-next (20100503) with the patches applied
> > (including Greg's Kconfig change) on x86_64 with allmodconfig and wasn't
> > able to reproduce the build failure.
> >
> > Any pointers on how to reproduce and/or fix this would be appreciated.
>
> Of course, if you force this driver to be built in (as Greg's Kconfig
> change presumably did), then you won't get these errors.
>
> The real solution is that SERIAL_ALTERA_JTAGUART_CONSOLE needs to depend
> on SERIAL_ALTERA_JTAGUART=y (instead of just SERIAL_ALTERA_JTAGUART) and
> similarly for the other.
Thanks for your help! I resubmitted an updated version of the patches
([1], [2]) including the changes pointed out above (compile tested
against linux-next as of 20100505 with allmodconfig on x86_64).
[1] Message-Id:
095aab012b2a6b3bbf4c7bc04294bb9c19316318.1273048151.git.tklauser@distanz.ch
[2] Message-Id:
e83e74abd82079284d5c8f62b78f2417ebc9ee27.1273048151.git.tklauser@distanz.ch
Cheers,
Tobias
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2010-05-03 16:17 ` Tobias Klauser
@ 2010-05-05 2:37 ` Stephen Rothwell
2010-05-05 8:39 ` Tobias Klauser
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2010-05-05 2:37 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Greg KH, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
Hi Tobias,
On Mon, 3 May 2010 18:17:21 +0200 Tobias Klauser <tklauser@distanz.ch> wrote:
>
> I just built the current linux-next (20100503) with the patches applied
> (including Greg's Kconfig change) on x86_64 with allmodconfig and wasn't
> able to reproduce the build failure.
>
> Any pointers on how to reproduce and/or fix this would be appreciated.
Of course, if you force this driver to be built in (as Greg's Kconfig
change presumably did), then you won't get these errors.
The real solution is that SERIAL_ALTERA_JTAGUART_CONSOLE needs to depend
on SERIAL_ALTERA_JTAGUART=y (instead of just SERIAL_ALTERA_JTAGUART) and
similarly for the other.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2010-04-28 15:28 ` Greg KH
2010-05-01 15:42 ` Tobias Klauser
@ 2010-05-03 16:17 ` Tobias Klauser
2010-05-05 2:37 ` Stephen Rothwell
1 sibling, 1 reply; 143+ messages in thread
From: Tobias Klauser @ 2010-05-03 16:17 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel
On 2010-04-28 at 17:28:09 +0200, Greg KH <greg@kroah.com> wrote:
> On Wed, Apr 28, 2010 at 04:14:25PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > On Tue, 27 Apr 2010 08:13:05 -0700 Greg KH <greg@kroah.com> wrote:
> > >
> > > On Tue, Apr 27, 2010 at 02:12:24PM +1000, Stephen Rothwell wrote:
> > > >
> > > > After merging the staging tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > ERROR: "uart_console_device" [drivers/serial/altera_uart.ko] undefined!
> > > > ERROR: "uart_console_device" [drivers/serial/altera_jtaguart.ko] undefined!
> > > >
> > > > Introduced by commits 76bdbd933febe791fee114e7bb6c42bbd1a3f4f3 ("serial:
> > > > Add driver for the Altera UART") and
> > > > 11c59b34b299d7214b466cf799410a9a540476e3 ("serial: Add driver for the
> > > > Altera JTAG UART").
> > > >
> > > > I have reverted those commits for today.
> > >
> > > Those came in through the tty quilt tree, not the staging tree, right?
> >
> > Yeah, I just don't do a build between merging the tty and staging trees.
>
> Ok, that makes sense.
>
> > > Tobias, care to send me a patch to resolve this? I already fixed one
> > > Kconfig issue in these patches (forcing the driver to always be built
> > > in.) Is that what caused this symbol issue?
> >
> > I have reverted those commits again today.
>
> I think I'll go drop these patches now. Tobias, care to resend them
> when you have them working properly?
I just built the current linux-next (20100503) with the patches applied
(including Greg's Kconfig change) on x86_64 with allmodconfig and wasn't
able to reproduce the build failure.
Any pointers on how to reproduce and/or fix this would be appreciated.
Thanks,
Tobias
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2010-04-28 15:28 ` Greg KH
@ 2010-05-01 15:42 ` Tobias Klauser
2010-05-03 16:17 ` Tobias Klauser
1 sibling, 0 replies; 143+ messages in thread
From: Tobias Klauser @ 2010-05-01 15:42 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel
On 2010-04-28 at 17:28:09 +0200, Greg KH <greg@kroah.com> wrote:
> On Wed, Apr 28, 2010 at 04:14:25PM +1000, Stephen Rothwell wrote:
> > On Tue, 27 Apr 2010 08:13:05 -0700 Greg KH <greg@kroah.com> wrote:
> > >
> > > On Tue, Apr 27, 2010 at 02:12:24PM +1000, Stephen Rothwell wrote:
> > > >
> > > > After merging the staging tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > ERROR: "uart_console_device" [drivers/serial/altera_uart.ko] undefined!
> > > > ERROR: "uart_console_device" [drivers/serial/altera_jtaguart.ko] undefined!
> > > >
> > > > Introduced by commits 76bdbd933febe791fee114e7bb6c42bbd1a3f4f3 ("serial:
> > > > Add driver for the Altera UART") and
> > > > 11c59b34b299d7214b466cf799410a9a540476e3 ("serial: Add driver for the
> > > > Altera JTAG UART").
> > > >
> > > > I have reverted those commits for today.
> > >
> > > Those came in through the tty quilt tree, not the staging tree, right?
> >
> > Yeah, I just don't do a build between merging the tty and staging trees.
>
> Ok, that makes sense.
>
> > > Tobias, care to send me a patch to resolve this? I already fixed one
> > > Kconfig issue in these patches (forcing the driver to always be built
> > > in.) Is that what caused this symbol issue?
> >
> > I have reverted those commits again today.
>
> I think I'll go drop these patches now. Tobias, care to resend them
> when you have them working properly?
Yepp, I'll have a look at it and will send the updated patches as soon
as I resolved it.
Thanks
Tobias
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2010-04-28 6:14 ` Stephen Rothwell
@ 2010-04-28 15:28 ` Greg KH
2010-05-01 15:42 ` Tobias Klauser
2010-05-03 16:17 ` Tobias Klauser
0 siblings, 2 replies; 143+ messages in thread
From: Greg KH @ 2010-04-28 15:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tobias Klauser
On Wed, Apr 28, 2010 at 04:14:25PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Tue, 27 Apr 2010 08:13:05 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > On Tue, Apr 27, 2010 at 02:12:24PM +1000, Stephen Rothwell wrote:
> > >
> > > After merging the staging tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > ERROR: "uart_console_device" [drivers/serial/altera_uart.ko] undefined!
> > > ERROR: "uart_console_device" [drivers/serial/altera_jtaguart.ko] undefined!
> > >
> > > Introduced by commits 76bdbd933febe791fee114e7bb6c42bbd1a3f4f3 ("serial:
> > > Add driver for the Altera UART") and
> > > 11c59b34b299d7214b466cf799410a9a540476e3 ("serial: Add driver for the
> > > Altera JTAG UART").
> > >
> > > I have reverted those commits for today.
> >
> > Those came in through the tty quilt tree, not the staging tree, right?
>
> Yeah, I just don't do a build between merging the tty and staging trees.
Ok, that makes sense.
> > Tobias, care to send me a patch to resolve this? I already fixed one
> > Kconfig issue in these patches (forcing the driver to always be built
> > in.) Is that what caused this symbol issue?
>
> I have reverted those commits again today.
I think I'll go drop these patches now. Tobias, care to resend them
when you have them working properly?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2010-04-27 15:13 ` Greg KH
@ 2010-04-28 6:14 ` Stephen Rothwell
2010-04-28 15:28 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2010-04-28 6:14 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Tobias Klauser
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
Hi Greg,
On Tue, 27 Apr 2010 08:13:05 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Tue, Apr 27, 2010 at 02:12:24PM +1000, Stephen Rothwell wrote:
> >
> > After merging the staging tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > ERROR: "uart_console_device" [drivers/serial/altera_uart.ko] undefined!
> > ERROR: "uart_console_device" [drivers/serial/altera_jtaguart.ko] undefined!
> >
> > Introduced by commits 76bdbd933febe791fee114e7bb6c42bbd1a3f4f3 ("serial:
> > Add driver for the Altera UART") and
> > 11c59b34b299d7214b466cf799410a9a540476e3 ("serial: Add driver for the
> > Altera JTAG UART").
> >
> > I have reverted those commits for today.
>
> Those came in through the tty quilt tree, not the staging tree, right?
Yeah, I just don't do a build between merging the tty and staging trees.
> Tobias, care to send me a patch to resolve this? I already fixed one
> Kconfig issue in these patches (forcing the driver to always be built
> in.) Is that what caused this symbol issue?
I have reverted those commits again today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
* Re: linux-next: build failure after merge of the staging tree
2010-04-27 4:12 Stephen Rothwell
@ 2010-04-27 15:13 ` Greg KH
2010-04-28 6:14 ` Stephen Rothwell
0 siblings, 1 reply; 143+ messages in thread
From: Greg KH @ 2010-04-27 15:13 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tobias Klauser
On Tue, Apr 27, 2010 at 02:12:24PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "uart_console_device" [drivers/serial/altera_uart.ko] undefined!
> ERROR: "uart_console_device" [drivers/serial/altera_jtaguart.ko] undefined!
>
> Introduced by commits 76bdbd933febe791fee114e7bb6c42bbd1a3f4f3 ("serial:
> Add driver for the Altera UART") and
> 11c59b34b299d7214b466cf799410a9a540476e3 ("serial: Add driver for the
> Altera JTAG UART").
>
> I have reverted those commits for today.
Those came in through the tty quilt tree, not the staging tree, right?
Tobias, care to send me a patch to resolve this? I already fixed one
Kconfig issue in these patches (forcing the driver to always be built
in.) Is that what caused this symbol issue?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 143+ messages in thread
* linux-next: build failure after merge of the staging tree
@ 2010-04-27 4:12 Stephen Rothwell
2010-04-27 15:13 ` Greg KH
0 siblings, 1 reply; 143+ messages in thread
From: Stephen Rothwell @ 2010-04-27 4:12 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Tobias Klauser
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "uart_console_device" [drivers/serial/altera_uart.ko] undefined!
ERROR: "uart_console_device" [drivers/serial/altera_jtaguart.ko] undefined!
Introduced by commits 76bdbd933febe791fee114e7bb6c42bbd1a3f4f3 ("serial:
Add driver for the Altera UART") and
11c59b34b299d7214b466cf799410a9a540476e3 ("serial: Add driver for the
Altera JTAG UART").
I have reverted those commits for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 143+ messages in thread
end of thread, other threads:[~2021-10-08 5:40 UTC | newest]
Thread overview: 143+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-18 5:53 linux-next: build failure after merge of the staging tree Stephen Rothwell
2017-04-18 7:04 ` Johannes Berg
-- strict thread matches above, loose matches on Subject: below --
2021-10-08 4:15 Stephen Rothwell
2021-10-08 5:39 ` Sergio Paracuellos
2021-08-16 3:52 Stephen Rothwell
2021-08-16 5:24 ` Greg KH
2021-08-16 15:10 ` Greg KH
2021-08-16 21:46 ` Stephen Rothwell
2021-03-29 5:55 Stephen Rothwell
2021-03-29 6:14 ` Greg KH
2021-03-29 7:25 ` Alexandru Ardelean
2021-04-26 14:41 ` Mark Brown
2021-04-26 16:23 ` Greg KH
2021-04-26 16:40 ` Mark Brown
2021-04-26 1:29 ` Stephen Rothwell
2021-04-26 22:07 ` Stephen Rothwell
2020-12-07 5:46 Stephen Rothwell
2020-12-07 9:26 ` Greg KH
2020-12-07 9:45 ` Stephen Rothwell
2020-12-14 20:27 ` Stephen Rothwell
2019-10-08 2:49 Stephen Rothwell
2019-10-08 12:46 ` Greg KH
2019-06-24 7:38 Stephen Rothwell
2019-06-24 8:46 ` Greg KH
2018-07-30 6:16 Stephen Rothwell
2018-07-30 6:31 ` Gao Xiang
2018-08-01 9:09 ` Chao Yu
2018-08-01 15:07 ` Stephen Rothwell
2018-08-02 6:12 ` Chao Yu
2018-08-02 6:15 ` Greg KH
2018-08-02 7:01 ` Chao Yu
2018-08-02 7:14 ` Greg KH
2018-08-02 7:48 ` Chao Yu
2018-07-30 9:47 ` David Howells
2018-07-30 10:45 ` Gao Xiang
2018-07-30 11:18 ` David Howells
2018-07-30 11:23 ` Gao Xiang
2018-07-17 6:28 Stephen Rothwell
2018-07-17 6:49 ` Ivan Safonov
2018-07-17 8:06 ` Greg KH
2017-09-26 3:54 Stephen Rothwell
2017-09-26 6:15 ` Jonathan Cameron
2017-05-01 4:42 Stephen Rothwell
2017-05-04 23:41 ` Greg KH
2017-04-27 4:20 Stephen Rothwell
2017-04-30 12:15 ` Greg KH
2017-04-18 5:32 Stephen Rothwell
2017-04-18 5:54 ` Greg KH
2017-04-18 6:26 ` Stephen Rothwell
2017-04-18 11:16 ` Greg KH
2017-04-11 5:04 Stephen Rothwell
2017-04-11 5:15 ` Greg KH
2017-04-11 5:38 ` Greg KH
2017-04-11 5:48 ` Stephen Rothwell
2017-04-10 5:10 Stephen Rothwell
2017-03-07 1:25 Stephen Rothwell
2017-03-07 4:46 ` Greg KH
2017-03-07 8:47 ` Greg KH
2017-03-07 9:49 ` Stephen Rothwell
2017-03-07 12:24 ` Greg KH
2016-05-13 3:15 Stephen Rothwell
2016-05-13 8:36 ` Greg KH
2015-06-03 7:16 Stephen Rothwell
2015-06-03 7:23 ` Johannes Berg
2015-03-10 5:07 Stephen Rothwell
2015-03-10 15:08 ` Greg KH
2015-03-10 15:53 ` Sudip Mukherjee
2015-03-10 20:57 ` Stephen Rothwell
2014-09-30 8:04 Stephen Rothwell
2014-10-02 16:31 ` Greg KH
2014-08-17 22:47 Stephen Rothwell
2014-06-20 4:18 Stephen Rothwell
2014-06-20 16:53 ` Greg KH
2014-07-10 0:27 ` Stephen Rothwell
2014-07-10 3:09 ` Greg KH
2014-09-22 10:25 ` Geert Uytterhoeven
2014-01-24 2:01 Stephen Rothwell
2014-01-24 2:34 ` Greg KH
2014-01-24 3:53 ` Greg KH
2014-01-24 4:04 ` Stephen Rothwell
2014-01-24 4:08 ` Greg KH
2013-07-26 6:02 Stephen Rothwell
2013-07-26 21:03 ` Greg KH
2013-07-26 21:22 ` Eli Billauer
2013-07-26 21:56 ` Greg KH
2013-07-26 22:54 ` Eli Billauer
2013-07-26 23:28 ` Greg KH
2013-07-27 13:30 ` Eli Billauer
2013-07-25 3:19 Stephen Rothwell
2013-07-25 4:25 ` Greg KH
2013-06-04 4:57 Stephen Rothwell
2013-06-04 5:42 ` Greg KH
2013-06-04 8:55 ` Peng Tao
2013-01-08 2:23 Stephen Rothwell
2013-01-08 4:27 ` Greg KH
2013-01-08 4:29 ` Stephen Rothwell
2013-01-08 16:46 ` H Hartley Sweeten
2012-09-12 6:07 Stephen Rothwell
2012-09-12 16:13 ` Greg KH
2012-09-14 7:55 ` Samuel Ortiz
2012-09-18 20:40 ` Jonathan Cameron
2012-02-17 4:10 Stephen Rothwell
2012-02-17 17:04 ` Greg KH
2012-02-17 17:23 ` Dan Magenheimer
2012-02-16 4:23 Stephen Rothwell
2012-02-16 5:15 ` Greg KH
2012-02-16 14:39 ` Dan Magenheimer
2012-02-16 21:25 ` Stephen Rothwell
2012-02-16 21:49 ` Dan Magenheimer
2012-02-16 23:39 ` Stephen Rothwell
2012-02-17 0:17 ` Greg KH
2012-02-17 16:01 ` Konrad Rzeszutek Wilk
2012-02-10 4:58 Stephen Rothwell
2012-02-10 5:29 ` Greg KH
2012-02-10 17:21 ` Dan Magenheimer
2012-02-10 17:43 ` Greg KH
2012-02-10 18:22 ` Seth Jennings
2012-02-14 23:43 ` Dan Magenheimer
2012-02-15 0:03 ` Greg KH
2012-02-15 0:54 ` Dan Magenheimer
2012-02-15 2:33 ` Greg KH
2012-02-15 16:14 ` Dan Magenheimer
2011-08-25 5:02 Stephen Rothwell
2011-08-25 5:15 ` Larry Finger
2011-08-25 15:39 ` Greg KH
2011-07-25 5:21 Stephen Rothwell
2011-07-16 13:18 Stephen Rothwell
2011-07-17 9:13 ` Greg KH
2011-07-16 13:15 Stephen Rothwell
2011-07-16 23:39 ` Alan Cox
2011-07-17 9:15 ` Greg KH
2011-07-06 5:09 Stephen Rothwell
2011-07-06 15:12 ` Greg KH
2011-07-06 5:02 Stephen Rothwell
2011-07-06 15:12 ` Greg KH
2010-04-27 4:12 Stephen Rothwell
2010-04-27 15:13 ` Greg KH
2010-04-28 6:14 ` Stephen Rothwell
2010-04-28 15:28 ` Greg KH
2010-05-01 15:42 ` Tobias Klauser
2010-05-03 16:17 ` Tobias Klauser
2010-05-05 2:37 ` Stephen Rothwell
2010-05-05 8:39 ` Tobias Klauser
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).