Linux v2.6.18-rc1

Ok,
the merge window for 2.6.18 is closed, and -rc1 is out there (git trees
updated, the tar-ball and patches are still uploading over my pitiful DSL line - and as usual it may take a short while before mirroring takes place and distributes things across the globe).

The changes are too big for the mailing list, even just the shortlog. As usual, lots of stuff happened. Most architectures got updated, ACPI updates, networking, SCSI and sound, IDE, infiniband, input, DVB etc etc etc.

There's also a fair amount of basic infrastructure updates here, with things like the generic IRQ layer, the lockdep (oh, and priority- inheritance mutex support) stuff by Ingo &co, some generic timekeeping infrastructure ("clocksource") stuff, memory hotplug (and page migration) support, etc etc.

Git users should generally just select the part they are interested in, and do something like

	git log v2.6.17.. -- drivers/usb/ | git shortlog | less -S

to get a better and more focused view of what has changed.

Have fun,

Linus

Linus Torvalds wrote:

[snip snip]

[snip snip]

[snip snip]

Is it possible to get a URL to a shortlog on a web git somewhere? Has this information been posted before and I have missed it?

Matt

Dunno if there's a web git version anywhere, but I did put a copy of the shortlog with the LWN announcement: http://lwn.net/Articles/190301/

jon

The most recent version of "gitweb" can actually do this kind of thing for you on the web, but the version currently installed on kernel.org only does it per-file, not per directory, making it less useful.

I suspect it will get upgraded one of these days, and when it does, you can generate the above kind of listing without even having git installed by going to

	http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git

and then selecting the "tree" view (it defaults to "summary" - see the top line that says "summary"/"shortlog"/"log"/"commit"/"commitdiff"/"tree", and select "tree" from there). Then you can walk down the tree, and when you find the file (or, eventually, directory) you are interested in, click on "history".

So even without git, you can get a lot of this kind of information. However, with just the web interface, you do lose a lot of browsing capability, like browsing multiple files/directories at the same time, and doing things like limiting the output since just a particular version.

So you could just get git on your own, and read the docs, and play with it. The place to start is probably the git homepage:

	http://git.or.cz/

(also look up the Wiki there - click on "Wiki" in the header to see some Wiki resources that probably get updated a bit more often than the home page itself).

Linus

ACPI problem here. Doesn't seem to actively break anything, but the messages look bad (HP NC6000 notebook). Haven't tried suspending. The error popped up roughly 90 minutes after booting. Laptop has been on AC power throughout.

ACPI Error (exmutex-0248): Cannot release Mutex [C0E8], not acquired [20060623]
ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.C044.C057.C0E7.C12F] (Node c1aeca40), AE_AML_MUTEX_NOT_ACQUIRED ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.C12F] (Node c1aeecfc), AE_AML_MUTEX_NOT_ACQUIRED ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.C137._BST] (Node c1aeec84), AE_AML_MUTEX_NOT_ACQUIRED ACPI Exception (acpi_battery-0206): AE_AML_MUTEX_NOT_ACQUIRED, Evaluating _BST [20060623]

Cheers,
Alistair.

Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

I've queued the below for sending via Len. Whether it is correct/sufficient I do not know. The comment from Alexey:

It seems that there is an error in our code, that either releases ASL mutex twice, etc. In either case the correct behavior seems to not abort execution. Error seems to vanish in 2.6.17, so we should just apply this patch.

is discouraging.

From: Alexey Starikovskiy <[email protected]>

See http://bugme.osdl.org/show_bug.cgi?id=6687
Closes: #50088

patch location:
http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=commitdiff;h=202ddb5b6498af53e110f78edd41a217587c1ffb

---

 drivers/acpi/executer/exmutex.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/acpi/executer/exmutex.c~acpi-do-not-abort-method-execution-if-asked-to-release drivers/acpi/executer/exmutex.c
@@ -246,7 +246,7 @@ acpi_ex_release_mutex(union acpi_operand
 		ACPI_ERROR((AE_INFO,
 			    "Cannot release Mutex [%4.4s], not acquired",
 			    acpi_ut_get_node_name(obj_desc->mutex.node)));
-		return_ACPI_STATUS(AE_AML_MUTEX_NOT_ACQUIRED);
+		return_ACPI_STATUS(AE_OK);
 	}
 
 	/* Sanity check -- we must have a valid thread ID */

_

Hi.

On my amd64 based laptop, I had a failures with both suspend implementations (swsusp and suspend2) when I had iommu debugging on. The same config worked fine with 2.6.17. I guess something in the delta didn't like iommu usage being forced on a Turion. I'm not sure how much time I'll find for further debugging, so I'll report it now.

Regards,

Nigel

Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

Most things seem fine here with rc1, but I do see a permissions issue with my USB scanner.

In 2.6.17

david@davidux:/dev/bus/usb/001 # l
total 0

drwxr-xr-x 2 root  root    100 2006-07-06 20:19 ./
drwxr-xr-x 4 root  root     80 2006-07-06 20:19 ../
crw-r--r-- 1 root  root 189, 0 2006-07-06 20:19 001

crw-r--r-- 1 david root 189, 1 2006-07-06 20:19 002 crw-r--r-- 1 root root 189, 4 2006-07-06 20:19 005

but with 2.6.18

david@davidux:/dev/bus/usb/001> l
total 0
drwxr-xr-x 2 root root 100 2006-07-06 20:24 ./
drwxr-xr-x 4 root root 80 2006-07-06 20:24 ../
crw-r--r-- 1 root root 189, 0 2006-07-06 20:24 001 crw-r--r-- 1 root root 189, 1 2006-07-06 20:24 002 crw-r--r-- 1 root root 189, 4 2006-07-06 20:24 005

Does something need tweaking with udev scripts maybe? This is a SuSE 10.1 system.

Cheers
David

Perhaps, that is odd. The scanner should default to the logged in user, right? Please file a bug at bugzilla.novell.com and the SuSE people can work on it there.

thanks,

greg k-h

Done. I may also try to chase down any divergence in the udev/hal scripts the weekend. Not a massive deal anyhow, I can always chown the device if I need the scanner. It all works just fine.

Thanks
David

We had the same problem with openGL applications here at the university. Suse 10 uses a daemon called resmgr that changes the /dev files ownership to the current user who logs in. check /etc/resmgr.conf.d/*, /etc/resmgr.conf and the docs for resmgr on how to add yourself to the, I think is the "desktop" group in resmgr terms, in order to change ownership.

Regards,
Boris.

___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

It's a bug in HAL, that feeds resmgr to grand access to the local user. It should be fixed soon.

Thanks,
Kay

I hope you mean in the kernel or did user space compatibility get broken again?

-Andi

I have a similar problem with my printer. But /dev/usblp0, /dev/usb/lp0 don't even appear, no matter what the permissions are.

-Andi

What version of udev are you using? It works fine for me here with a USB printer (that's what I tested the changes with.)

thanks,

greg k-h

udev-068git20050831-9 (from SUSE 10.0 I think)

-Andi

That's the issue, look in Documentation/Changes for the proper version of udev for the past few kernel versions to handle this kind of issue (again, it was a stupid libsysfs problem, which caused us to finally drop that piece of crud from udev...) This has been documented as such since last October, see commit ad7e14a55ed7648d02a4df8e460e291d80a18c98.

It was necessary to do this for the input drivers to get them to all work properly, please see the old archives for details as to the necessity of it.

Also, that change caused the creation of Documentation/ABI/ which describes the rules that programs that look at sysfs class stuff, must be able to handle a symlink there.

That older version of udev in 10.0 can't handle the symlink, but I think that Kay had a version somewhere that was patched to handle it. I'd just recommend upgrading to 10.1 :)

thanks,

greg k-h

Why is your prompt different? # first, then >. Could it be that your system thought you were root in the second case? Just a stupid thought...

In a world without walls and fences, who needs Windows and Gates?

We've got a ppc64 machine that won't boot with this due to an IDE error.

[snip]
Freeing unused kernel memory: 256k freed
running (1:2) /init autobench_args: ABAT:1152213829

creating device nodes .hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt

Steve Fox
IBM Linux Technology Center

What machine precisely ?

I see a slightly more verbose version on a JS20 blade.

hda: dma_timer_expiry: dma status == 0x24
hda: DMA interrupt recovery
hda: lost interrupt

Ar Llu, 2006-07-10 am 08:21 -0500, ysgrifennodd Will Schmidt:

That in repeat generally means the IRQ logic on the platform has been broken. If we don't get interrupts we don't work very well.

Also check if booting with "nodma" set on the relevant ide interface makes a difference. Just to be sure. If it does then submit patches to fix the bug.

Alan

it's most certainly an irq problem as I just rewrote the irq logic of powerpc :) There have been some issues and I've just sent some new patches fixing them, let's see if that's enough. I'll give a js20 a try today at work.

Ben.

FWIW, I tried applying the 3 non-Apple-specific patches posted on 7/10 but this didn't help.

Steve Fox
IBM Linux Technology Center

Can you try with the new patches I posted yesterday ?

Ben.

It's called bl5-6 in ABAT and lists itself as a 970 (8842-P1Z).

Also, booting with ide=nodma, as Alan suggested to Will, did not help.

Steve Fox
IBM Linux Technology Center

I'm not sure if it was due to using the nodma parameter or not, but I did get a few more details during this boot. No idea if they're useful or not.

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide:
Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:04.1 AMD8111: chipset revision 3 AMD8111: 0000:00:04.1 (rev 03) UDMA133 controller AMD8111: 100% native mode on irq 17

    ide0: BM-DMA at 0x7c00-0x7c07, BIOS settings: hda:pio, hdb:pio ide1:
    BM-DMA at 0x7c08-0x7c0f, BIOS settings: hdc:pio, hdd:pio

hda: TOSHIBA MK4019GAXB, ATA DISK drive ide0 at 0x7400-0x7407,0x6c02 on irq 17 hda: max request size: 128KiB
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: 78140160 sectors (40007 MB), CHS=65535/16/63 hda: lost interrupt hda:
cache flushes supported
hda:<4>hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda1 hda2 hda3 hda4 <<4>hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda5<4>hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt

Steve Fox
IBM Linux Technology Center

... and cpufreq-nforce2.ko fails to work. Module can't be loaded:
FATAL: Error inserting cpufreq_nforce2 (/lib/modules/2.6.18-rc1/kernel/arch/i386/kernel/cpu/cpufreq/cpufreq-nforce2.ko):
Device or resource busy

Here's relevant difference between dmesg of 2.6.17 and 2.6.18-rc1:

@@ -244,7 +240,6 @@
lp: driver loaded but no devices found
cpufreq: Detected nForce2 chipset revision C1
cpufreq: FSB changing is maybe unstable and can lead to crashes and data loss.
-cpufreq: FSB currently at 165 MHz, FID 10.5
usbcore: registered new driver usbfs
usbcore: registered new driver hub

Motherboard is Abit, NF7,NF7-V (nVidia-nForce2), Version: 2.X,1.0, (according to dmidecode).

Also alsactl restore didn't restore PCM volume and mute state. Some
mixer elements changed name? Module is snd_intel8x0, chip is integrated in above mentioned motherboard.

Tomasz Torcz                "Funeral in the morning, IDE hacking
[email protected]    in the afternoon and evening." - Alan Cox

No.

Tomasz Torcz                 Morality must always be based on practicality.
[email protected]                -- Baron Vladimir Harkonnen

That's puzzling, as the only other changes to cpufreq-nforce are completely cosmetic (whitespace and the like).

Dave

http://www.codemonkey.org.uk

At Fri, 7 Jul 2006 19:52:39 +0200,

Hm, I don't remember any relevant changes.
Could you compare the mixer states from "alsactl -f somefile store" with old and new kernels?

Takashi

The new pc8736x_gpio driver has at least 1 bug, which manifests when module is rmmod'd then re-modprobe'd. This 3 part patchset addresses it as follows:

1 - add constant defines - preparatory patch

- adds #define CONSTs for max-pin, gpio-addr-range (for reserving region)
- fix wrong max-pin check in gpio_open()
- add 'Winbond' to module description: NSC sold the product, Winbond has us / lm-sensors

pc-const-decl - define several symbolic constants
pc-open-const - use reduced max-pin to what hardware supports
pc-req-region-const - can wait, but why
pc-mod-desc-add-winbond -

since this is just preparatory work, it still exhibits the bug:

soekris:~# rmmod pc8736x_gpio
soekris:~# modprobe pc8736x_gpio
[  498.970735] kobject_add failed for pc8736x_gpio.0 with -EEXIST, don't try to register things with the same name in the same directory.
[  498.985568]  [<c0102fbf>] show_trace_log_lvl+0x54/0xfd
[  498.991398]  [<c0103fba>] show_trace+0xd/0x10
[  498.996629]  [<c0103fd4>] dump_stack+0x17/0x1b
[  499.001759]  [<c01d1c6a>] kobject_add+0x17d/0x19c
[  499.014898]  [<c0203362>] device_add+0x7a/0x2cc
[  499.029917]  [<c020616d>] platform_device_add+0xdc/0x10c
[  499.045902]  [<c8820028>] pc8736x_gpio_init+0x28/0x258 [pc8736x_gpio]
[  499.053212]  [<c012a67a>] sys_init_module+0x1381/0x1463
[  499.061327]  [<c0102657>] syscall_call+0x7/0xb
FATAL: Error inserting pc8736x_gpio (/lib/modules/2.6.18-rc1-jimc-sk/kernel/drivers/char/pc8736x_gpio.ko): No such device

2 - pc-init-fix-undo-region-rollup

this patch fixes module-init-func by repairing usage of platform_device_del/put in module-exit-func, ie it imitates Ingo's 'mishaps' patch, which fixed the module-init-func's undo handling. Also fixes lack of release_region to undo the earlier registration.

Also included:
- add include <linux/cdev.h> - needed by next patches and cuz theyre within the diff-context-window:
- remove include <linux/config.h> everyone's doing it
- copyright updates - current date is 'wrong'

the patch fixes the above bug, reducing it to a different one; (which is fixed by 3rd patch)

soekris:~# rmmod pc8736x_gpio
soekris:~# modprobe pc8736x_gpio
[  283.618997] platform pc8736x_gpio.0: NatSemi pc8736x GPIO Driver Initializing
[  283.626534] platform pc8736x_gpio.0: GPIO ioport 6600 reserved
[  283.633319] platform pc8736x_gpio.0: register-chrdev failed: -16
FATAL: Error inserting pc8736x_gpio (/lib/modules/2.6.18-rc1-jimc-sk/kernel/drivers/char/pc8736x_gpio.ko): Device or resource busy

3 - pc-init-fix-chrdev-region-rollup

- Switch from register_chrdev() to (register|alloc)_chrdev_region().

- use a cdev. This was intended for original patchset, but was overlooked.
We use a single cdev for all pins (minor device-numbers), as gleaned from cs5535_gpio, and in contrast to whats currently done in scx200_gpio (which I'll fix soon)

By some reasoning, this patch should have been combined with patch 2; the fixes are to the same 2 mod-init/exit functions, and both touch cdevs, regions, etc. Despite this, I separated them (incompletely). I'll combine them if thats better..

Given that this is a brand new driver, can I assume a bit more latitude to
clean up and normalize the code ? For example, s/DEVNAME/DRVNAME/
would improve consistency with other drivers. The scx200_gpio driver could also stand some improvements; a single cdev, and same DRVNAME normalization.

Whats the right way to mark this as (NEW/EXPERIMENTAL) ? Is either appropriate for a reworked / existing driver (scx200_gpio)

cc'g AKPM since (I think) he pushed this driver to mainline.

thanks
Jim Cromie

1 - add constant defines - preparatory patch

- adds #define CONSTs for max-pin, gpio-addr-range (for reserving region)
- fix wrong max-pin check in gpio_open()
- add 'Winbond' to module description. NSC sold the product, Winbond has supported us / lm-sensors

$ diffstat fxd1/pc-const-rollup
pc8736x_gpio.c |   10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)

diff -ruNp -X dontdiff -X exclude-diffs x4h-0/drivers/char/pc8736x_gpio.c x4h-1/drivers/char/pc8736x_gpio.c
@@ -25,7 +25,7 @@

#define DEVNAME "pc8736x_gpio"

MODULE_AUTHOR("Jim Cromie <[email protected]>"); -MODULE_DESCRIPTION("NatSemi PC-8736x GPIO Pin Driver"); +MODULE_DESCRIPTION("NatSemi/Winbond PC-8736x GPIO Pin Driver"); MODULE_LICENSE("GPL");

static int major; /* default to dynamic major */
@@ -38,14 +38,14 @@ static u8 pc8736x_gpio_shadow[4];

#define SIO_BASE1 0x2E /* 1st command-reg to check */
#define SIO_BASE2 0x4E /* alt command-reg to check */
-#define SIO_BASE_OFFSET 0x20

#define SIO_SID 0x20 /* SuperI/O ID Register */
#define SIO_SID_VALUE 0xe9 /* Expected value in SuperI/O ID Register */

#define SIO_CF1 0x21 /* chip config, bit0 is chip enable */

-#define PC8736X_GPIO_SIZE 16
+#define PC8736X_GPIO_RANGE 16 /* ioaddr range */
+#define PC8736X_GPIO_CT 32 /* minors matching 4 8 bit ports */

#define SIO_UNIT_SEL 0x7 /* unit select reg */
#define SIO_UNIT_ACT 0x30 /* unit enable */
@@ -231,7 +231,7 @@ static int pc8736x_gpio_open(struct inod

	dev_dbg(&pdev->dev, "open %d\n", m);

- if (m > 63)
+ if (m >= PC8736X_GPIO_CT)

		return -EINVAL;
	return nonseekable_open(inode, file);
}
@@ -297,7 +297,7 @@ static int __init pc8736x_gpio_init(void
	pc8736x_gpio_base = (superio_inb(SIO_BASE_HADDR) << 8
			     | superio_inb(SIO_BASE_LADDR));

- if (!request_region(pc8736x_gpio_base, 16, DEVNAME)) {

+	if (!request_region(pc8736x_gpio_base, PC8736X_GPIO_RANGE, DEVNAME)) {
		rc = -ENODEV;
		dev_err(&pdev->dev, "GPIO ioport %x busy\n",
			pc8736x_gpio_base);

2 - pc-init-fix-undo-region-rollup

this patch fixes module-init-func by repairing usage of platform_device_del/put in module-exit-func. IOW, it imitates Ingo's 'mishaps' patch, which fixed the module-init-func's undo handling. Also fixes lack of release_region to undo the earlier registration.

Also starts to 'use a cdev' which was originally intended (its present in scx200_gpio). Code compiles and runs, exhibits a lesser error than previously. (re-register-chrdev fails)

Since I had to add "include <linux/cdev.h>", I went ahead and made 2 tweaks that fell into diff-context-window:
- remove include <linux/config.h> everyone's doing it
- copyright updates - current date is 'wrong'

---

$ diffstat fxd1/pc-init-fix-undo-region-rollup
pc8736x_gpio.c |   19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
[jimc@harpo gpio-stuff]$

---

diff -ruNp -X dontdiff -X exclude-diffs x4h-1/drivers/char/pc8736x_gpio.c x4h-2/drivers/char/pc8736x_gpio.c
@@ -3,18 +3,18 @@
   National Semiconductor PC8736x GPIO driver.  Allows a user space
   process to play with the GPIO pins.
 
-   Copyright (c) 2005 Jim Cromie <[email protected]>
+   Copyright (c) 2005,2006 Jim Cromie <[email protected]>
 
   adapted from linux/drivers/char/scx200_gpio.c
   Copyright (c) 2001,2002 Christer Weinigel <[email protected]>,

*/

-#include <linux/config.h>
#include <linux/fs.h>
#include <linux/module.h>
#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/init.h>
+#include <linux/cdev.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/mutex.h>
@@ -255,6 +255,8 @@ static void __init pc8736x_init_shadow(v

}

+static struct cdev pc8736x_gpio_cdev;
+
static int __init pc8736x_gpio_init(void)

{
	int rc = 0;
@@ -308,7 +310,7 @@ static int __init pc8736x_gpio_init(void
	rc = register_chrdev(major, DEVNAME, &pc8736x_gpio_fops);
	if (rc < 0) {
		dev_err(&pdev->dev, "register-chrdev failed: %d\n", rc);
-		goto undo_platform_dev_add;
+		goto undo_request_region;
	}
	if (!major) {
		major = rc;
@@ -318,6 +320,8 @@ static int __init pc8736x_gpio_init(void
	pc8736x_init_shadow();
	return 0;

+undo_request_region:
+ release_region(pc8736x_gpio_base, PC8736X_GPIO_RANGE);
undo_platform_dev_add:

	platform_device_del(pdev);

undo_platform_dev_alloc:
@@ -328,11 +332,14 @@ undo_platform_dev_alloc:

static void __exit pc8736x_gpio_cleanup(void)
{
- dev_dbg(&pdev->dev, " cleanup\n");
+ dev_dbg(&pdev->dev, "cleanup\n");

- release_region(pc8736x_gpio_base, 16);
+ cdev_del(&pc8736x_gpio_cdev);
+ unregister_chrdev_region(MKDEV(major,0), PC8736X_GPIO_CT);
+ release_region(pc8736x_gpio_base, PC8736X_GPIO_RANGE);

- unregister_chrdev(major, DEVNAME);
+ platform_device_del(pdev);
+ platform_device_put(pdev);
}

EXPORT_SYMBOL(pc8736x_access);

3 - pc-init-fix-chrdev-region-rollup

- Switch from register_chrdev() to (register|alloc)_chrdev_region().

- use a cdev. This was intended for original patchset, but was overlooked.
We use a single cdev for all pins (minor device-numbers), as gleaned from cs5535_gpio, and in contrast to whats currently done in scx200_gpio (which I'll fix soon)

$ diffstat pc-init-fix-chrdev-region-rollup
pc8736x_gpio.c |   15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletion(-)

---

diff -ruNp -X dontdiff -X exclude-diffs x4k-2/drivers/char/pc8736x_gpio.c x4k-3/drivers/char/pc8736x_gpio.c
@@ -260,6 +260,7 @@ static struct cdev pc8736x_gpio_cdev;

static int __init pc8736x_gpio_init(void)

{
	int rc = 0;

+ dev_t devid;

	pdev = platform_device_alloc(DEVNAME, 0);
	if (!pdev)
@@ -307,7 +308,14 @@ static int __init pc8736x_gpio_init(void
	}
	dev_info(&pdev->dev, "GPIO ioport %x reserved\n", pc8736x_gpio_base);

- rc = register_chrdev(major, DEVNAME, &pc8736x_gpio_fops);
+ if (major) {
+ devid = MKDEV(major, 0);
+ rc = register_chrdev_region(devid, PC8736X_GPIO_CT, DEVNAME);
+ } else {
+ rc = alloc_chrdev_region(&devid, 0, PC8736X_GPIO_CT, DEVNAME);
+ major = MAJOR(devid);
+ }
+

	if (rc < 0) {
		dev_err(&pdev->dev, "register-chrdev failed: %d\n", rc);
		goto undo_request_region;
@@ -318,6 +326,11 @@ static int __init pc8736x_gpio_init(void
	}

	pc8736x_init_shadow();

+
+ /* ignore minor errs, and succeed */
+ cdev_init(&pc8736x_gpio_cdev, &pc8736x_gpio_fops);
+ cdev_add(&pc8736x_gpio_cdev, devid, PC8736X_GPIO_CT);
+

	return 0;

undo_request_region: