skge missing ifdefs.

with CONFIG_PM undefined, the build breaks due to
undefined symbols.

-- linux-2.6.12/drivers/net/sk98lin/skge.c~ 2005-08-01 16:32:42.000000000 -0400
+++ linux-2.6.12/drivers/net/sk98lin/skge.c 2005-08-01 16:33:10.000000000 -0400
@@ -5233,8 +5233,10 @@ static struct pci_driver skge_driver = {
.id_table = skge_pci_tbl,
.probe = skge_probe_one,
.remove = __devexit_p(skge_remove_one),
+#ifdef CONFIG_PM
.suspend = skge_suspend,
.resume = skge_resume,
+#endif
};

static int __init skge_init(void)

akpm already sent a fix to Linus.

Jeff

This is still broken afaics in todays -git.

Dave

From: Dave Jones <[email protected]>
Date: Mon, 22 Aug 2005 15:59:13 -0400

They are certainly there in Linus's current GIT tree.

...
#ifdef CONFIG_PM
static int skge_suspend(struct pci_dev *pdev, pm_message_t state)
...
static int skge_resume(struct pci_dev *pdev)
...
#endif
static struct pci_driver skge_driver = {
...
#ifdef CONFIG_PM
.suspend = skge_suspend,
.resume = skge_resume,
#endif
};

Works for me. CONFIG_PM=n, CONFIG_SKGE=y or m, CONFIG_SK98LIN=y or m.

btw, is one of the recent `%td' fans going to, like, implement it in printk()?

Sent to Linus, sits in his queue... Last iteration had been

mail -s '[PATCH] (45/46) %t... in vsnprintf' [email protected] <<'EOF' handling of %t... (ptrdiff_t) in vsnprintf

----

diff -urN RC13-rc6-git10-m68k-adb.patch/lib/vsprintf.c RC13-rc6-git10-printf-t/lib/vsprintf.c
@@ -269,6 +269,7 @@
 	int qualifier;		/* 'h', 'l', or 'L' for integer fields */
 				/* 'z' support added 23/7/1999 S.H.    */
 				/* 'z' changed to 'Z' --davidm 1/25/99 */
+				/* 't' added for ptrdiff_t */
 
 	/* Reject out-of-range values early */
 	if (unlikely((int) size < 0)) {

@@ -339,7 +340,7 @@
 		/* get the conversion qualifier */
 		qualifier = -1;
 		if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L' ||
-		    *fmt =='Z' || *fmt == 'z') {
+		    *fmt =='Z' || *fmt == 'z' || *fmt == 't') {
 			qualifier = *fmt;
 			++fmt;
 			if (qualifier == 'l' && *fmt == 'l') {

@@ -467,6 +468,8 @@
 				num = (signed long) num;
 		} else if (qualifier == 'Z' || qualifier == 'z') {
 			num = va_arg(args, size_t);
+		} else if (qualifier == 't') {
+			num = va_arg(args, ptrdiff_t);
 		} else if (qualifier == 'h') {
 			num = (unsigned short) va_arg(args, int);
 			if (flags & SIGN)

EOF

<wonders what the other 45 patches did>

Could you copy a mailing list on patches, please?

Hi,

Seconded.
Al, I'd like to know which of the m68k related patches you want to merge.

bye, Roman

See ftp.linux.org.uk/pub/people/viro/patchset/T* + adb.h delta from CVS. That's a minimum getting mainline m68k to sane state and not breaking other platforms. These are against -rc6-git2, but their counterparts in more recent patchset have not changed. BTW, m68k patches were not in the series sent to Linus and I would definitely Cc m68k folks on them if they would go there.

As for your s/thread_info/stack/ - I don't believe it's doable in mainline right now. It's definitely separate from m68k merge and should not be mixed into it. Moreover, mandatory changes to every platform arch-specific code over basically cosmetic issue (renaming a field of task_struct) at this point are going to be gratitious PITA for every architecture with out-of-tree development. And m68k folks, of all people, should know what fun it is.

When folks start using task_thread_info() in arch/* (i.e. by 2.6.1[45]) the size of that delta will go down big way and it will be less painful. Until then... Not a good idea.

Hi,

No, I don't know it. Sometimes merging can be tricky, but then I check the original diff and apply it manually. What I'm planning involves no logical changes, so it would be an absolute no-brainer to merge. It's the logical changes that may even compile normally, that can be the a real PITA.

I already did the complete conversion (and I did it forward and backward to be sure the result is the same), so I dont see the problem to merge it in 2.6.13. The final removal of the thread_info field can happen in 2.6.14 and any missed changes in external trees are trivially fixable.

bye, Roman

Ask and you shall regret it - next iteration of patchbomb (without adding more pending chunks to it) Cc'd to l-k.

I missed the ..

#define skge_suspend NULL
#define skge_resume NULL

in drivers/net/sk98lin/skge.c, and wondered why my drivers/net/skge.c style fix still applied.

Never mind, both drivers seem fine.

Dave