Linux-Next discussions
 help / color / mirror / Atom feed
* Re: linux-next: build failure after merge of the final tree
From: Randy Dunlap @ 2011-08-23 14:32 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: James Morris, linux-next, linux-kernel, David Howells
In-Reply-To: <20110823154811.527ae4929dd2078e694fe32a@canb.auug.org.au>

On Tue, 23 Aug 2011 15:48:11 +1000 Stephen Rothwell wrote:

> Hi all,
> 
> After merging the final tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
> 
> kernel/cred.c: In function 'prepare_kernel_cred':
> kernel/cred.c:657:2: error: 'tgcred' undeclared (first use in this function)
> 
> Caused by commit 012146d0728f ("CRED: Fix prepare_kernel_cred() to
> provide a new thread_group_cred struct").  CONFIG_KEYS is not set in this
> build ...
> 
> Please, please build test with and without CONFIG settings that affect
> your changes.
> 
> I discovered this after releaseing linux-next for today.

This one also causes UML (defconfig) builds to fail today.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply

* [PATCH -next] usb: fix dwc3 build when USB_GADGET_DWC3 is not enabled
From: Randy Dunlap @ 2011-08-23 18:07 UTC (permalink / raw)
  To: Stephen Rothwell, akpm, gregkh; +Cc: linux-next, LKML, Felipe Balbi, linux-omap
In-Reply-To: <20110823160432.d24f8cad00951286bc18461e@canb.auug.org.au>

From: Randy Dunlap <rdunlap@xenotime.net>

Fix build error when CONFIG_USB_GADGET_DWC3 is not enabled:

ERROR: "dwc3_send_gadget_ep_cmd" [drivers/usb/dwc3/dwc3.ko] undefined!

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 drivers/usb/dwc3/debugfs.c |    4 ++++
 1 file changed, 4 insertions(+)

--- linux-next-20110823.orig/drivers/usb/dwc3/debugfs.c
+++ linux-next-20110823/drivers/usb/dwc3/debugfs.c
@@ -437,7 +437,9 @@ static int dwc3_testmode_open(struct ino
 	struct dwc3_gadget_ep_cmd_params par0;
 	struct dwc3_gadget_ep_cmd_params par1;
 	struct dwc3_trb         trb;
+#ifdef CONFIG_USB_GADGET_DWC3
 	int ret;
+#endif
 	u8 *buf0;
 	u8 *buf1;
 
@@ -478,8 +480,10 @@ static int dwc3_testmode_open(struct ino
 
 	dwc3_send_testmode_cmd(dwc, 1);
 
+#ifdef CONFIG_USB_GADGET_DWC3
 	ret = dwc3_send_gadget_ep_cmd(dwc, 0, DWC3_DEPCMD_STARTTRANSFER, &par0);
 	ret = dwc3_send_gadget_ep_cmd(dwc, 1, DWC3_DEPCMD_STARTTRANSFER, &par1);
+#endif
 
 	dwc3_send_testmode_cmd(dwc, 0);
 	return -EBUSY;

^ permalink raw reply

* Re: linux-next: manual merge of the net tree with the  tree
From: Niklaus Giger @ 2011-08-23 18:10 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: David Miller, netdev, linux-next, linux-kernel, Josh Boyer,
	Tony Breeds
In-Reply-To: <20110822115118.e5d97beb22befc4ba9396e9d@canb.auug.org.au>

> Hi all,
> 
> Today's linux-next merge of the net tree got a conflict in
> arch/powerpc/configs/40x/hcu4_defconfig between commit 9fcd768d0cc8
> ("powerpc/40x: Remove obsolete HCU4 board") from the 4xx tree and commit
> 3b3bceef26f8 ("net: fix IBM EMAC driver after rename") from the net tree.
> 
> The former commit removes the file, so I just did that.
Thanks!

Best regards

^ permalink raw reply

* [PATCH -next] usb: fix ipw.c build error, select USB_SERIAL_WWAN
From: Randy Dunlap @ 2011-08-23 18:22 UTC (permalink / raw)
  To: Stephen Rothwell, akpm, lud; +Cc: linux-next, LKML, gregkh
In-Reply-To: <20110823160432.d24f8cad00951286bc18461e@canb.auug.org.au>

From: Randy Dunlap <rdunlap@xenotime.net>

USB_SERIAL_IPW needs to select USB_SERIAL_WWAN to fix build errors:

ipw.c:(.text+0x333841): undefined reference to `usb_wwan_close'
ipw.c:(.text+0x3339e6): undefined reference to `usb_wwan_open'
ipw.c:(.text+0x333bb9): undefined reference to `usb_wwan_release'
drivers/built-in.o:(.data+0x29dac): undefined reference to `usb_wwan_startup'
drivers/built-in.o:(.data+0x29db4): undefined reference to `usb_wwan_disconnect'
drivers/built-in.o:(.data+0x29dd4): undefined reference to `usb_wwan_write'

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 drivers/usb/serial/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- linux-next-20110823.orig/drivers/usb/serial/Kconfig
+++ linux-next-20110823/drivers/usb/serial/Kconfig
@@ -252,6 +252,7 @@ config USB_SERIAL_GARMIN
 
 config USB_SERIAL_IPW
         tristate "USB IPWireless (3G UMTS TDD) Driver"
+	select USB_SERIAL_WWAN
 	help
 	  Say Y here if you want to use a IPWireless USB modem such as
 	  the ones supplied by Axity3G/Sentech South Africa.

^ permalink raw reply

* Re: [PATCH -next] usb: fix dwc3 build when USB_GADGET_DWC3 is not enabled
From: Felipe Balbi @ 2011-08-23 18:52 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, akpm, gregkh, linux-next, LKML, Felipe Balbi,
	linux-omap
In-Reply-To: <20110823110702.f5ea377c.rdunlap@xenotime.net>

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

Hi,

On Tue, Aug 23, 2011 at 11:07:02AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Fix build error when CONFIG_USB_GADGET_DWC3 is not enabled:
> 
> ERROR: "dwc3_send_gadget_ep_cmd" [drivers/usb/dwc3/dwc3.ko] undefined!
> 
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> ---
>  drivers/usb/dwc3/debugfs.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> --- linux-next-20110823.orig/drivers/usb/dwc3/debugfs.c
> +++ linux-next-20110823/drivers/usb/dwc3/debugfs.c
> @@ -437,7 +437,9 @@ static int dwc3_testmode_open(struct ino
>  	struct dwc3_gadget_ep_cmd_params par0;
>  	struct dwc3_gadget_ep_cmd_params par1;
>  	struct dwc3_trb         trb;
> +#ifdef CONFIG_USB_GADGET_DWC3
>  	int ret;
> +#endif
>  	u8 *buf0;
>  	u8 *buf1;
>  
> @@ -478,8 +480,10 @@ static int dwc3_testmode_open(struct ino
>  
>  	dwc3_send_testmode_cmd(dwc, 1);
>  
> +#ifdef CONFIG_USB_GADGET_DWC3
>  	ret = dwc3_send_gadget_ep_cmd(dwc, 0, DWC3_DEPCMD_STARTTRANSFER, &par0);
>  	ret = dwc3_send_gadget_ep_cmd(dwc, 1, DWC3_DEPCMD_STARTTRANSFER, &par1);
> +#endif

instead of adding the ifdef here, would you add it gadget.h and provide
a nop when we're not building the gadget side ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: [PATCH -next] staging: fix comedi build when COMEDI_PCI is not enabled
From: Greg KH @ 2011-08-23 18:58 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, driverdevel, akpm, linux-next, LKML, an Abbott,
	ori Hess
In-Reply-To: <20110822111314.bf7a526f.rdunlap@xenotime.net>

On Mon, Aug 22, 2011 at 11:13:14AM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> Fix build when CONFIG_ISA_DMA_API is enabled but
> CONFIG_COMEDI_PCI[_DRIVERS] is not enabled.
> Fixes these build errors:
> 
> drivers/staging/comedi/drivers/ni_labpc.c: In function 'labpc_ai_cmd':
> drivers/staging/comedi/drivers/ni_labpc.c:1351: error: implicit declaration of function 'labpc_suggest_transfer_size'
> drivers/staging/comedi/drivers/ni_labpc.c: At top level:
> drivers/staging/comedi/drivers/ni_labpc.c:1802: error: conflicting types for 'labpc_suggest_transfer_size'
> drivers/staging/comedi/drivers/ni_labpc.c:1351: note: previous implicit declaration of 'labpc_suggest_transfer_size' was here
> 
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> ---
>  drivers/staging/comedi/drivers/ni_labpc.c |    4 +++-

I applied your older patch, which causes this one to not apply.  Is it
still needed as well?

thanks,

greg k-h

^ permalink raw reply

* [PATCH -next v2] usb: fix dwc3 build when USB_GADGET_DWC3 is not enabled
From: Randy Dunlap @ 2011-08-23 19:52 UTC (permalink / raw)
  To: balbi; +Cc: Stephen Rothwell, akpm, gregkh, linux-next, LKML, linux-omap
In-Reply-To: <20110823185235.GA11299@legolas.emea.dhcp.ti.com>

From: Randy Dunlap <rdunlap@xenotime.net>

Fix build error when CONFIG_USB_GADGET_DWC3 is not enabled:

ERROR: "dwc3_send_gadget_ep_cmd" [drivers/usb/dwc3/dwc3.ko] undefined!

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
---
 drivers/usb/dwc3/gadget.h |    5 +++++
 1 file changed, 5 insertions(+)

--- linux-next-20110823.orig/drivers/usb/dwc3/gadget.h
+++ linux-next-20110823/drivers/usb/dwc3/gadget.h
@@ -202,6 +202,11 @@ void dwc3_gadget_exit(struct dwc3 *dwc);
 #else
 static inline int dwc3_gadget_init(struct dwc3 *dwc) { return 0; }
 static inline void dwc3_gadget_exit(struct dwc3 *dwc) { }
+static inline int dwc3_send_gadget_ep_cmd(struct dwc3 *dwc, unsigned ep,
+		unsigned cmd, struct dwc3_gadget_ep_cmd_params *params)
+{
+	return 0;
+}
 #endif
 
 void dwc3_gadget_giveback(struct dwc3_ep *dep, struct dwc3_request *req,

^ permalink raw reply

* Re: [PATCH -next] staging: fix comedi build when COMEDI_PCI is not enabled
From: Randy Dunlap @ 2011-08-23 20:03 UTC (permalink / raw)
  To: Greg KH
  Cc: Stephen Rothwell, driverdevel, akpm, linux-next, LKML, an Abbott,
	ori Hess
In-Reply-To: <20110823185805.GA11786@kroah.com>

On Tue, 23 Aug 2011 11:58:05 -0700 Greg KH wrote:

> On Mon, Aug 22, 2011 at 11:13:14AM -0700, Randy Dunlap wrote:
> > From: Randy Dunlap <rdunlap@xenotime.net>
> > 
> > Fix build when CONFIG_ISA_DMA_API is enabled but
> > CONFIG_COMEDI_PCI[_DRIVERS] is not enabled.
> > Fixes these build errors:
> > 
> > drivers/staging/comedi/drivers/ni_labpc.c: In function 'labpc_ai_cmd':
> > drivers/staging/comedi/drivers/ni_labpc.c:1351: error: implicit declaration of function 'labpc_suggest_transfer_size'
> > drivers/staging/comedi/drivers/ni_labpc.c: At top level:
> > drivers/staging/comedi/drivers/ni_labpc.c:1802: error: conflicting types for 'labpc_suggest_transfer_size'
> > drivers/staging/comedi/drivers/ni_labpc.c:1351: note: previous implicit declaration of 'labpc_suggest_transfer_size' was here
> > 
> > Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
> > ---
> >  drivers/staging/comedi/drivers/ni_labpc.c |    4 +++-
> 
> I applied your older patch, which causes this one to not apply.  Is it
> still needed as well?

Nope, the second (more recent) one is not needed.  Thanks.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply

* Re: linux-next: build failure after merge of the final tree (wireless & staging trees related)
From: Greg KH @ 2011-08-23 21:30 UTC (permalink / raw)
  To: Kalle Valo
  Cc: John W. Linville, Stephen Rothwell, Greg KH, linux-next,
	linux-kernel, Vasanthakumar Thiagarajan, Raja Mani,
	linux-wireless
In-Reply-To: <4E453502.4000401@qca.qualcomm.com>

On Fri, Aug 12, 2011 at 05:13:22PM +0300, Kalle Valo wrote:
> On 08/12/2011 04:51 PM, John W. Linville wrote:
> > On Fri, Aug 12, 2011 at 12:12:16PM +1000, Stephen Rothwell wrote:
> >> On Thu, 11 Aug 2011 18:50:57 +0300 Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> >>>
> >>> Yes, please delete ath6kl from staging for the 3.2 release as the
> >>> cleanup version is now in wireless-next.
> >>>
> >>> Thank you everyone and sorry for the mess.
> >>
> >> I think that the removal should be done in the wirelesss tree so that
> >> Linus' tree is not broken during the next merge window.
> >>
> >> I have added the removal patch as a merge fixup one the merge of the
> >> wireless tree for today.
> > 
> > Makes sense to me -- probably also is more sane if there is some fool
> > out there relying on the ath6kl driver in staging that doesn't know
> > about the switch to the wireless tree.
> 
> Ok, I'll send a patch to John which removes the staging driver.

Note, I also applied this to the staging-next tree to keep people from
sending me cleanup patches against the driver.  git will resolve the
fact that it was deleted in both branches just fine when we merge with
Linus for 3.2.

thanks,

greg k-h

^ permalink raw reply

* Re: [PATCH -next] drivers/base/inode.c: let vmstat_text be optional
From: Andrew Morton @ 2011-08-23 21:39 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Stephen Rothwell, Amerigo Wang, gregkh, linux-next, LKML,
	linux-mm
In-Reply-To: <20110804152211.ea10e3e7.rdunlap@xenotime.net>


> Subject: [PATCH -next] drivers/base/inode.c: let vmstat_text be optional

The patch-against-next thing always disturbs me.  It implies that the
patch is only needed in linux-next, but often that's wrong.  So I have
to go off and work out what kernel it really is applicable to.

And that's OK, it keeps me healthy.  But two minds are better than one,
and if the originator has already worked this out, they should state it
explicitly, please.

On Thu, 4 Aug 2011 15:22:11 -0700
Randy Dunlap <rdunlap@xenotime.net> wrote:

> From: Randy Dunlap <rdunlap@xenotime.net>
> 
> vmstat_text is only available when PROC_FS or SYSFS is enabled.
> This causes build errors in drivers/base/node.c when they are
> both disabled:
> 
> drivers/built-in.o: In function `node_read_vmstat':
> node.c:(.text+0x10e28f): undefined reference to `vmstat_text'
> 
> Rather than litter drivers/base/node.c with #ifdef/#endif around
> the affected lines of code, add macros for optional sysdev
> attributes so that those lines of code will be ignored, without
> using #ifdef/#endif in the .c file(s).  I.e., the ifdeffery
> is done only in a header file with sysdev_create_file_optional()
> and sysdev_remove_file_optional().
> 
> --- linux-next-20110804.orig/include/linux/vmstat.h
> +++ linux-next-20110804/include/linux/vmstat.h
> @@ -258,6 +258,8 @@ static inline void refresh_zone_stat_thr
>  
>  #endif		/* CONFIG_SMP */
>  
> +#if defined(CONFIG_PROC_FS) || defined(CONFIG_SYSFS)
>  extern const char * const vmstat_text[];
> +#endif
>

The ifdef around the declaration isn't needed, really.  If we remove
it then a build-time error becomes a link-time (or even moddep-time) error,
which is a bit of a pain.  But it's less painful than having ifdefs
around squillions of declarations.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: linux-next: manual merge of the pm tree with the mfd tree
From: Rafael J. Wysocki @ 2011-08-23 22:16 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Felipe Balbi, Samuel Ortiz, Mark Brown
In-Reply-To: <20110823135619.be8b64d2eec7cb78bc0160a8@canb.auug.org.au>

On Tuesday, August 23, 2011, Stephen Rothwell wrote:
> Hi Rafael,
> 
> Today's linux-next merge of the pm tree got a conflict in
> drivers/mfd/twl4030-irq.c between commit 99efe0d4c992 ("mfd: Drop the
> twl4030-irq kthread") from the mfd tree and commit febab68efa45
> ("freezer: don't unnecessarily set PF_NOFREEZE explicitly") from the pm
> tree.
> 
> The former dropped the code modified by the latter, so I did that.

Thanks!

Unfortunately, I don't think we can really fix that other that making
one tree depend on the other.

^ permalink raw reply

* Re: linux-next: Tree for Aug 22 (evm)
From: Randy Dunlap @ 2011-08-23 23:40 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: Arnaud Lacombe, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
	linux-kbuild
In-Reply-To: <1314065358.3225.44.camel@localhost.localdomain>

On Mon, 22 Aug 2011 22:09:18 -0400 Mimi Zohar wrote:

> On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
> > On Mon, 22 Aug 2011 20:47:00 -0400 Arnaud Lacombe wrote:
> > 
> > > Hi,
> > > 
> > > On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> > > > On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> [The kernel.org mirroring is a bit low today]
> > > >
> > > > (on x86_64:)
> > > >
> > > > When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
> > > > CONFIG_ENCRYPTED_KEYS=m, the build fails with:
> > > >
> > > You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
> > > 'm'. That said, correct me if I'm wrong, but we currently have:
> > 
> > Yes, it was 'm'.
> > 
> > > menuconfig TCG_TPM
> > >         tristate "TPM Hardware Support"
> > > 
> > > [...]
> > > 
> > > config EVM
> > >         boolean "EVM support"
> > >         depends on SECURITY && KEYS && TCG_TPM
> > > 
> > > which seems terribly broken to me... How can you have a built-in
> > > feature, which depends on another potentially-not-built-in feature ?
> > 
> > Yup.
> 
> Easy, different use cases. The TPM has been around and used for a while,
> not requiring it to be built-in.  EVM, a new use case, requires it to be
> built-in.
> 
> > > If you change EVM to 'tristate', you will see that you are not allowed
> > > to make it built-in if TCG_TPM is not built-in.
> > 
> > Right.
> 
> The TPM, crypto, trusted and encrypted keys are tristate.  Like the
> LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> the tristates to built-in.  The tristate/boolean mismatches aren't
> corrected, when .config is edited directly.


> Mimi:

This isn't a problem about editing .config directly.  I haven't done that
here.  Also, if 'make xconfig' would convert tristates to built-in, then
so would 'make oldconfig', which is done automatically if configs have
changed (or maybe it's 'make silentoldconfig').

I think that you are going to need to do something like Arnaud suggested
and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
unless you can convince someone that this is a kconfig bug.


> > >  - Arnaud
> > > 
> > > > (.text+0x378aa): undefined reference to `key_type_encrypted'
> > > > evm_crypto.c:(.text+0x37992): undefined reference to `crypto_alloc_shash'
> > > > evm_crypto.c:(.text+0x37a24): undefined reference to `crypto_shash_setkey'
> > > > evm_crypto.c:(.text+0x37ad9): undefined reference to `crypto_shash_update'
> > > > evm_crypto.c:(.text+0x37aeb): undefined reference to `crypto_shash_final'
> > > > (.text+0x37b4b): undefined reference to `crypto_shash_update'
> > > > (.text+0x37c61): undefined reference to `crypto_shash_update'
> > > > (.text+0x37cb9): undefined reference to `crypto_shash_update'
> > > >
> > > > even though EVM (Kconfig) selects ENCRYPTED_KEYS and TRUSTED_KEYS..
> > > > and even after I add "select CRYPTO_HASH2".
> > > >
> > > > Is this because EVM is bool and kconfig is confused about 'select's
> > > > when a bool is selecting tristates?  Shouldn't the tristates become
> > > > 'y' instead of 'm' if they are selected by a bool that is 'y'?
> > > >
> > > >
> > > > xconfig shows these symbol values:
> > > >
> > > > Symbol: EVM [=y]
> > > > Type : boolean
> > > > Prompt: EVM support
> > > > Defined at security/integrity/evm/Kconfig:1
> > > > Depends on: SECURITY [=y] && KEYS [=y] && TCG_TPM [=m]
> > > > Location:
> > > > -> Security options
> > > > Selects: CRYPTO_HMAC [=m] && CRYPTO_MD5 [=m] && CRYPTO_SHA1 [=m] && CRYPTO_HASH2 [=m] && ENCRYPTED_KEYS [=m] && TRUSTED_KEYS [=m]
> > > >
> > > >
> > > > Hm, changing TCG_TPM to =y also changes TRUSTED_KEYS and ENCRYPTED_KEYS and
> > > > lots of CRYPTO_ symbols from =m to =y.  There must be some kind of min/max
> > > > symbol checking that is confused?
> > > >
> > > there is definitively an underlying min/max, but I would not point
> > > finger too fast.
> > 
> > 
> > Thanks for your help.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply

* Re: linux-next: build failure after merge of the final tree (wireless & staging trees related)
From: Stephen Rothwell @ 2011-08-24  1:06 UTC (permalink / raw)
  To: Greg KH
  Cc: Kalle Valo, John W. Linville, Greg KH, linux-next, linux-kernel,
	Vasanthakumar Thiagarajan, Raja Mani, linux-wireless
In-Reply-To: <20110823213013.GC3679@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Hi Greg,

On Tue, 23 Aug 2011 14:30:13 -0700 Greg KH <greg@kroah.com> wrote:
>
> Note, I also applied this to the staging-next tree to keep people from
> sending me cleanup patches against the driver.  git will resolve the
> fact that it was deleted in both branches just fine when we merge with
> Linus for 3.2.

Clearly, I should read ahead in my email before replying :-)
-- 
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

* Re: linux-next: manual merge of the pm tree with the mfd tree
From: Stephen Rothwell @ 2011-08-24  1:12 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: linux-next, linux-kernel, Felipe Balbi, Samuel Ortiz, Mark Brown
In-Reply-To: <201108240016.33529.rjw@sisk.pl>

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Hi Rafael,

On Wed, 24 Aug 2011 00:16:33 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> On Tuesday, August 23, 2011, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the pm tree got a conflict in
> > drivers/mfd/twl4030-irq.c between commit 99efe0d4c992 ("mfd: Drop the
> > twl4030-irq kthread") from the mfd tree and commit febab68efa45
> > ("freezer: don't unnecessarily set PF_NOFREEZE explicitly") from the pm
> > tree.
> > 
> > The former dropped the code modified by the latter, so I did that.
> 
> Thanks!
> 
> Unfortunately, I don't think we can really fix that other that making
> one tree depend on the other.

We can just leave it for Linus to fix up during the next merge window.
After all, I figured it out.  :-)

("git rerere" takes care of fixing it up for me from now on)
-- 
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

* Re: linux-next: manual merge of the net tree with the unicore32 tree
From: Guan Xuetao @ 2011-08-24  1:28 UTC (permalink / raw)
  To: jeffrey.t.kirsher
  Cc: Stephen Rothwell, David Miller, netdev@vger.kernel.org,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Zhang Shu, Chu Xiaowei, Su Yonggang
In-Reply-To: <1314090049.2128.224.camel@jtkirshe-mobl>

On Tue, 2011-08-23 at 02:00 -0700, Jeff Kirsher wrote:
> On Mon, 2011-08-22 at 20:02 -0700, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the net tree got conflicts in
> > drivers/net/Kconfig and drivers/net/Makefile between commit
> > e8787de6fa83
> > ("unicore32: add pkunity-v3 mac/net driver (umal)") from the unicore32
> > tree and the network driver rearrangement from the net tree.
> > 
> > I just added the new driver from the unicore32 tree commit into each
> > file
> > (see below).
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au 
> 
> Hmm, well with the latest series of patches I sent out, I am pretty sure
> this patch would not apply.
Ok, I see.
Thanks Jeff, and thanks Stephen.

Guan Xuetao

> 
> Is it best that this patch not be sent to netdev for driver
> inclusion? :)

^ permalink raw reply

* Re: linux next: Native Linux KVM tool inclusion request
From: Stephen Rothwell @ 2011-08-24  1:52 UTC (permalink / raw)
  To: Sasha Levin
  Cc: linux-kernel, Avi Kivity, Ingo Molnar, Andrew Morton,
	Linus Torvalds, Pekka Enberg, linux-next, Christoph Hellwig
In-Reply-To: <1314044960.3668.9.camel@lappy>

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

Hi Sasha,

On Mon, 22 Aug 2011 23:29:20 +0300 Sasha Levin <levinsasha928@gmail.com> wrote:
>
> I would like to ask you to include the Native Linux KVM tool in the
> linux-next tree.
> 
> The branch is named 'master' and is located in:
> 
> 	git://github.com/penberg/linux-kvm.git

I have included your tree from today and called it "kvmtool". I have you
and Pekka currently listed as teh contacts (since it looks like it is his
tree on github).  Please consider adding a MAINTAINERS entry for this.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* Re: linux-next: Tree for Aug 22 (evm)
From: Mimi Zohar @ 2011-08-24  2:07 UTC (permalink / raw)
  To: Arnaud Lacombe
  Cc: Randy Dunlap, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
	linux-kbuild
In-Reply-To: <CACqU3MV-MfWxvVebcxiJK8BmxHG8epf=0bpsL7qoska65aVzSw@mail.gmail.com>

On Mon, 2011-08-22 at 22:24 -0400, Arnaud Lacombe wrote:
> Hi,
> 
> On Mon, Aug 22, 2011 at 10:09 PM, Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> > On Mon, 2011-08-22 at 17:49 -0700, Randy Dunlap wrote:
> >> On Mon, 22 Aug 2011 20:47:00 -0400 Arnaud Lacombe wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Aug 22, 2011 at 3:53 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> >> > > On Mon, 22 Aug 2011 14:53:04 +1000 Stephen Rothwell wrote:
> >> > >
> >> > >> Hi all,
> >> > >>
> >> > >> [The kernel.org mirroring is a bit low today]
> >> > >
> >> > > (on x86_64:)
> >> > >
> >> > > When CONFIG_EVM=y, CONFIG_CRYPTO_HASH2=m, CONFIG_TRUSTED_KEYS=m,
> >> > > CONFIG_ENCRYPTED_KEYS=m, the build fails with:
> >> > >
> >> > You did not provide the value of CONFIG_TCG_TPM, I'll assume it was
> >> > 'm'. That said, correct me if I'm wrong, but we currently have:
> >>
> >> Yes, it was 'm'.
> >>
> >> > menuconfig TCG_TPM
> >> >         tristate "TPM Hardware Support"
> >> >
> >> > [...]
> >> >
> >> > config EVM
> >> >         boolean "EVM support"
> >> >         depends on SECURITY && KEYS && TCG_TPM
> >> >
> >> > which seems terribly broken to me... How can you have a built-in
> >> > feature, which depends on another potentially-not-built-in feature ?
> >>
> >> Yup.
> >
> > Easy, different use cases. The TPM has been around and used for a while,
> > not requiring it to be built-in.  EVM, a new use case, requires it to be
> > built-in.
> >
> What behavior is expected when TPM is built as a module ? Would you
> expect EVM to be accessible ?
> 
> >> > If you change EVM to 'tristate', you will see that you are not allowed
> >> > to make it built-in if TCG_TPM is not built-in.
> >>
> >> Right.
> >
> > The TPM, crypto, trusted and encrypted keys are tristate.  Like the
> > LSMs, EVM is boolean, which when selected using 'make xconfig', converts
> > the tristates to built-in.  The tristate/boolean mismatches aren't
> > corrected, when .config is edited directly.
> >
> well, ... no. 'xconfig' would seem to let you think they have been
> changed to 'y', but they have not. I have been able to generate a bad
> configuration (TPM module, EVM built-in) using only {menu,x}config.
> 
> btw, I never edit the configuration manually, there is a big fat "DO
> NOT EDIT" header in the beginning.
> 
> Depending on what you expect, one way to fix that is to make EVM
> depends on TCG_TPM = y, not just TCG_TPM.
> 
>  - Arnaud

Thanks, that seems to work for now.  I'd really like to remove the
trusted-key and TCG_TPM dependencies from encrypted keys.  Thus removing
the TCG_TPM dependency from EVM.  But then, trusted keys could be
enabled differently than encrypted keys.  

Is there a way of allowing 'A' not to be dependent on 'B', but if 'B' is
defined, force 'B' to be built-in if 'A' is built-in, or as a module if
'A' is a module?

thanks,

Mimi


^ permalink raw reply

* Re: linux-next: Tree for Aug 22 (evm)
From: Arnaud Lacombe @ 2011-08-24  2:10 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Mimi Zohar, Stephen Rothwell, Mimi Zohar, linux-next, LKML,
	linux-kbuild
In-Reply-To: <20110823164035.ca28fdc6.rdunlap@xenotime.net>

Hi,

On Tue, Aug 23, 2011 at 7:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> I think that you are going to need to do something like Arnaud suggested
> and use "depends on TCG_TPM=y" instead of just "depends on TCG_TPM",
> unless you can convince someone that this is a kconfig bug.
>
dammit... I guess there is...

If you consider the following Kconfig:

config MOD
        bool
        default y
        option modules

config EXPERIMENTAL
        bool
        default y

menuconfig A
        tristate "A"
        depends on EXPERIMENTAL

config B
        bool "B"

config B0
        bool

config C
        tristate "C"
        depends on B

config C0
        tristate

config D
        boolean "D"
        depends on A && B
        select C
        select C0

config E
        tristate "E"

config F
        tristate "F"
        select E

B (KEYS) allows to set C (TRUSTED_KEYS). Also, B (KEYS) and A
(TCG_TPM) allows to set D (EVM), which will select (C). Now,
menuconfig highlight the problem very well. Proceeding as following
A=m, B=y, C=m, E=y, F=y, we ends up having:

 <M> A  --->
 [*] B
 {M} C
 [*] D
 -*- E
 <*> F

which translate in the following config:

CONFIG_MOD=y
CONFIG_EXPERIMENTAL=y
CONFIG_A=m
CONFIG_B=y
CONFIG_C=m
CONFIG_C0=m
CONFIG_D=y
CONFIG_E=y
CONFIG_F=y

I would have expected CONFIG_C and CONFIG_C0 to be 'y', just as 'E'.
If you remove D's dependency on 'A', everything works as expected. So
it would seem direct dependency state influence the state of reverse
dependencies...

Will have a look...

 - Arnaud

^ permalink raw reply

* [Patch] numa: introduce CONFIG_NUMA_SYSFS for drivers/base/node.c
From: Cong Wang @ 2011-08-24  3:34 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Randy Dunlap, Stephen Rothwell, gregkh, linux-next, LKML,
	linux-mm
In-Reply-To: <20110823143912.0691d442.akpm@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 77 bytes --]

Hi, Andrew,

Do you think my patch below is better?

Thanks!

------------->

[-- Attachment #2: numa-depends-on-sysfs.diff --]
[-- Type: text/plain, Size: 1334 bytes --]

Introduce a new Kconfig CONFIG_NUMA_SYSFS for drivers/base/node.c
which just provides sysfs interface, so that when we select
CONFIG_NUMA, we don't have to enable the sysfs interface too.

This by the way fixes a randconfig build error when NUMA && !SYSFS.

Signed-off-by: WANG Cong <amwang@redhat.com>

---
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 99a375a..e382338 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_HAS_DMA)	+= dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
 obj-$(CONFIG_ISA)	+= isa.o
 obj-$(CONFIG_FW_LOADER)	+= firmware_class.o
-obj-$(CONFIG_NUMA)	+= node.o
+obj-$(CONFIG_NUMA_SYSFS)	+= node.o
 obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
 obj-$(CONFIG_SMP)	+= topology.o
 ifeq ($(CONFIG_SYSFS),y)
diff --git a/mm/Kconfig b/mm/Kconfig
index f2f1ca1..77345e7 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -340,6 +340,16 @@ choice
 	  benefit.
 endchoice
 
+config NUMA_SYSFS
+	bool "Enable NUMA sysfs interface for user-space"
+	depends on NUMA
+	depends on SYSFS
+	default y
+	help
+	  This enables NUMA sysfs interface, /sys/devices/system/node/*
+	  files, for user-space tools, like numactl. If you have enabled
+	  NUMA, probably you also need this one.
+
 #
 # UP and nommu archs use km based percpu allocator
 #

^ permalink raw reply related

* linux-next: build warning after merge of the rcu tree
From: Stephen Rothwell @ 2011-08-24  4:23 UTC (permalink / raw)
  To: Paul E. McKenney; +Cc: linux-next, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

Hi Paul,

After merging the rcu tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:

kernel/rtmutex.c: In function '__rt_mutex_slowlock':
kernel/rtmutex.c:605:3: warning: suggest parentheses around assignment used as truth value

Introduced by commit 83841f021d4b ("rcu: Permit rt_mutex_unlock() with
irqs disabled").

-- 
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

* linux-next: build failure after merge of the tty tree
From: Stephen Rothwell @ 2011-08-24  4:33 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-next, linux-kernel, Jamie Iles, Arnd Bergmann

[-- Attachment #1: Type: text/plain, Size: 562 bytes --]

Hi Greg,

After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

drivers/built-in.o: In function `dw8250_handle_irq':
8250_dw.c:(.text+0xcad9c): undefined reference to `serial8250_handle_irq'

CONFIG_SERIAL_8250 is 'm' and CONFIG_SERIAL_8250_DW is 'y' ...

Caused by commit 6b1a98d1c485 ("tty: serial8250: add helpers for the
DesignWare 8250").

I have used the ttye tree form next-20110823 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

* Re: linux next: Native Linux KVM tool inclusion request
From: Sasha Levin @ 2011-08-24  4:33 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-kernel, Avi Kivity, Ingo Molnar, Andrew Morton,
	Linus Torvalds, Pekka Enberg, linux-next, Christoph Hellwig
In-Reply-To: <20110824115233.4b515a6ceee8910e9c21fc50@canb.auug.org.au>

On Wed, 2011-08-24 at 11:52 +1000, Stephen Rothwell wrote:
> Hi Sasha,
> 
> On Mon, 22 Aug 2011 23:29:20 +0300 Sasha Levin <levinsasha928@gmail.com> wrote:
> >
> > I would like to ask you to include the Native Linux KVM tool in the
> > linux-next tree.
> > 
> > The branch is named 'master' and is located in:
> > 
> > 	git://github.com/penberg/linux-kvm.git
> 
> I have included your tree from today and called it "kvmtool". I have you
> and Pekka currently listed as teh contacts (since it looks like it is his
> tree on github).  Please consider adding a MAINTAINERS entry for this.
> 
> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgment of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window. 
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>      * submitted under GPL v2 (or later) and include the Contributor's
> 	Signed-off-by,
>      * posted to the relevant mailing list,
>      * reviewed by you (or another maintainer of your subsystem tree),
>      * successfully unit tested, and 
>      * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.
> 

Thank you for the inclusion.

We will add a MAINTAINERS file.

-- 

Sasha.

^ permalink raw reply

* linux-next: manual merge of the staging tree with the fbdev tree
From: Stephen Rothwell @ 2011-08-24  4:41 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-next, linux-kernel, Aaro Koskinen, Laurent Pinchart,
	Paul Mundt

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/xgifb/XGI_main_26.c between commit c42a3d543d2b
("staging: xgifb: use display information in info not in var for
panning") from the fbdev tree and commit c39aada6926c ("staging: xgifb:
eliminate #ifdef XGIFB_PAN") from the staging tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/xgifb/XGI_main_26.c
index f8b88ad,4415d4a..0000000
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@@ -1363,8 -1357,7 +1357,7 @@@ static int XGIfb_do_set_var(struct fb_v
  	return 0;
  }
  
- #ifdef XGIFB_PAN
 -static int XGIfb_pan_var(struct fb_var_screeninfo *var)
 +static int XGIfb_pan_var(struct fb_var_screeninfo *var, struct fb_info *info)
  {
  	unsigned int base;
  

^ permalink raw reply

* Re: linux-next: build failure after merge of the tty tree
From: Greg KH @ 2011-08-24  4:50 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Jamie Iles, Arnd Bergmann
In-Reply-To: <20110824143354.d32c86b5143631442aca3700@canb.auug.org.au>

On Wed, Aug 24, 2011 at 02:33:54PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> drivers/built-in.o: In function `dw8250_handle_irq':
> 8250_dw.c:(.text+0xcad9c): undefined reference to `serial8250_handle_irq'
> 
> CONFIG_SERIAL_8250 is 'm' and CONFIG_SERIAL_8250_DW is 'y' ...
> 
> Caused by commit 6b1a98d1c485 ("tty: serial8250: add helpers for the
> DesignWare 8250").
> 
> I have used the ttye tree form next-20110823 for today.

Ick.

Jamie, can you please send me a patch that fixes this up?

thanks,

greg k-h

^ permalink raw reply

* Re: linux-next: manual merge of the staging tree with the fbdev tree
From: Greg KH @ 2011-08-24  4:48 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: linux-next, linux-kernel, Aaro Koskinen, Laurent Pinchart,
	Paul Mundt
In-Reply-To: <20110824144134.00bd3a688fb39b5d5563ff13@canb.auug.org.au>

On Wed, Aug 24, 2011 at 02:41:34PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/xgifb/XGI_main_26.c between commit c42a3d543d2b
> ("staging: xgifb: use display information in info not in var for
> panning") from the fbdev tree and commit c39aada6926c ("staging: xgifb:
> eliminate #ifdef XGIFB_PAN") from the staging tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Wonderful, thanks for the fix.

greg k-h

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox